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

From: Jeff King <peff@peff.net>
Date: Oct 30, 2007, 14:06 UTC
Message-ID: <20071030140630.GC21342@coredump.intra.peff.net>
In-Reply-To: <20071030095338.GZ6372@mea-ext.zmailer.org>

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

Show 17 quoted lines

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

Show 6 quoted lines

> 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