Missing MIME-headers in git-email-tool ..

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@analog.com>
  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

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..)

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

The potential incorrectness is with UTF-8 encoded names. Even then it probably is merely nuisance and not real delivery preventing detail.

  /Matti Aarnio -- one of <postmaster @ vger.kernel.org>

Hi,

On Tue, 30 Oct 2007, Matti Aarnio wrote:

AFAICT MIME headers are only added when needed. (But that might only apply to format-patch; however, if you signed off with your name, all should be well.)

No.

Not at all.

ISO-8859-15 is just as wrong as ASCII. You just forget about the majority of the population on this earth. That is just as arrogant and snobbish as the people who thought that ASCII would be good enough for everyone.

Ciao, Dscho

On Tue, Oct 30, 2007 at 10:31:41AM +0000, Johannes Schindelin wrote:

I wish that were true.. We (VGER's Postmasters that is) would not see so much rejections from all over the places... Would it motivate you if we sent all GIT caused ones to you ?

The MIME headers should always be added. The charset= -value can be debated about. If the headers are not there, and VGER is sending email to system which does not report capability of receiving 8BITMIME, then the message will be converted to QUOTED-PRINTABLE (and headers be added)

Worst that can happen when the message is mis-labelled as US-ASCII and still contains 8-bit chars is not outright rejection, but stripping the 8th-bit off..

I wish the world was perfect and everybody would use single unified charset.. which obviously is not true. However as the kernel sources DO NOT SPECIFY COMMENT CHARSET, using ISO-8859-15 is LESS WRONG than picking UTF-8.

The reasoning here is that getting the email thru is more important than absolutely correct labels.

If you wish, you may scan the message content at first to determine if it does indeed include characters outside the US-ASCII range. You may even determine if the charset in question is likely UTF-8 instead of one of the Latins.

Whatever you do, do put the MIME labels in place.

/Matti Aarnio -- one of  <postmaster @ vger.kernel.org>

Hi,

[please Cc: me]

On Tue, 30 Oct 2007, Matti Aarnio wrote:

Heh.

I'm not a send-mail user myself, so I did not ever have any reason to dive into its source code. Sorry.

I understand your pain. But as we assume UTF-8 in git if no other encoding is selected, I think it makes more sense to default to UTF-8.

That said, I actually like the behaviour which I think is intended, to not specify anything when the message can be interpreted as US-ASCII.

BTW I tried to find anything in the message you referenced which would make it non-ASCII, but I did not find anything. But then, I am not subscribed to the lkml, and can only get stripped down versions of the mails via marc or kerneltrap.

Any send-email gurus want to join into this discussion?

Ciao, Dscho

On Tue, Oct 30, 2007 at 11:53:38AM +0200, Matti Aarnio wrote:

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.

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?

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

On Tue, Oct 30, 2007 at 10:06:30AM -0400, Jeff King wrote:

Actually, btw, the code in question is from git-format-patch (it's just that git-send-email doesn't add _any_ mime headers, as it assumes git-format-patch either did it already, or none are needed).

-Peff