On Tue, Oct 30, 2007 at 11:53:38AM +0200, Matti Aarnio wrote: > The git-send-email does send posts without any sort of MIME labeling: > > From: / To: removed > > Subject: [PATCH 0/2] Blackfin I2C/TWI driver updates > Date: Tue, 30 Oct 2007 17:33:15 +0800 > Message-Id: <1193736797-9005-1-git-send-email-bryan.wu@xxxxxxxxxx> > X-Mailer: git-send-email 1.5.3.4 > Precedence: bulk > > > which per MIME rules means that the message in question is equivalent > to one with header labels: > > MIME-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit As Johannes explained, this happens only when there are no >7bit characters in the email, so that interpretation is correct. Though I am not opposed to sending those headers all the time, for clarity's sake. > What would be a problem ? Some of us have names that are encoded > in 8-bit form, and some receiving systems get all mighty upset when > they receive unlabelled email carry 8-bit encoded texts. > (Thanks to chinese and russian spammers..) Then git-send-email should be generating the MIME headers if there are 8-bit characters. Can you produce a test case where the most recent version of git-send-email it does not? > Now if the git-send-email would add following three lines in all > outgoing email headers, things would be 99% correct for a long time.. > > MIME-Version: 1.0 > Content-Type: text/plain; charset=ISO-8859-15 > Content-Transfer-Encoding: 8BIT No, this is just wrong. If git-send-email isn't adding headers when it should to 8-bit output, then it's a bug. But papering over it with a randomly chosen, possibly incorrect charset is not the right answer. -Peff - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
