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

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

[Matti Aarnio]

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>

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

[Johannes Schindelin]

Hi,

On Tue, 30 Oct 2007, 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@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

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

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

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

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

[Matti Aarnio]

On Tue, Oct 30, 2007 at 10:31:41AM +0000, Johannes Schindelin wrote:
> Hi,
> 
> On Tue, 30 Oct 2007, 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@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
> 
> 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.)

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


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

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.

> Ciao,
> Dscho


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

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

[Johannes Schindelin]

Hi,

[please Cc: me]

On Tue, 30 Oct 2007, Matti Aarnio wrote:

> On Tue, Oct 30, 2007 at 10:31:41AM +0000, Johannes Schindelin wrote:
> 
> > On Tue, 30 Oct 2007, 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@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
> > 
> > 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.)
> 
> 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 ?

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

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

[Jeff King]

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@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

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

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

[Jeff King]

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

> > 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?

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