From: Erik Faye-Lund Date: Mon, 14 Jun 2010 11:57:21 GMT Subject: Re: vger doesn't like UTF-8 from send-email Message-ID: In-Reply-To: On Sun, Jun 13, 2010 at 6:15 AM, Michael Witten wrote: > On Sat, Jun 12, 2010 at 05:11, Thomas Rast wrote: >> AFAICT the original message did not declare an encoding: >> >> Subject: [PATCH v2 0/2] bash completion: Support "divergence from upstream" warnings in __git_ps1 >> Date: Sat, 12 Jun 2010 12:02:14 +0200 >> Message-ID: >> X-Mailer: git-send-email 1.7.1.561.g94582 >> In-Reply-To: <20100612000002.GA30196@neumann> >> References: <20100612000002.GA30196@neumann> >> MIME-Version: 1.0 >> Content-Type: text/plain >> Return-Path: trast@student.ethz.ch >> ... >> Is this a new vger policy, or am I hitting a send-email bug? > > Let's assume the headers themselves are already properly encoded. > > According to: > >    http://www.faqs.org/rfcs/rfc2045.html > > we have: > >    The proper Content-Transfer-Encoding >    label must always be used. > > and: > >    An encoding type of 7BIT requires that >    the body is already in a 7bit mail-ready >    representation.  This is the default value >    -- that is, "Content-Transfer-Encoding: 7BIT" >    is assumed if the Content-Transfer-Encoding >    header field is not present. > > Moreover, according to: > >    http://www.faqs.org/rfcs/rfc2046.html > > we have: > >    4.1.2    Charset Parameter >    ... >    The default character set, which must be >    assumed in the absence of a charset parameter, >    is US-ASCII. > > So, your email is indeed incorrect in 2 ways if the body contains > UTF-8 encoded data. > > From what I've skimmed, the mail user agent (MUA)---such as > send-email---could send your unmodified message body by producing > these headers: > >    MIME-Version: 1.0 >    Content-type: text/plain; charset=utf-8 >    Content-transfer-encoding: 8bit > > but only 7bit transfer encodings are guaranteed to make it intact to > the destination; consequently, it would probably be a good idea for > the MUA to transform your message into some 7bit encoding, preferably > a human-readable one such as the 'quoted-printable' encoding; after > such a transformation, the headers could be: > >    MIME-Version: 1.0 >    Content-type: text/plain; charset=utf-8 >    Content-transfer-encoding: quoted-printable > QP-encoding is sometimes destructive, and as such not recommended for patches - in fact, Documentation/SubmittingPatches forbid it. For the cover-letter the destruction might not be an issue (IIRC it's some line-feeds that might be added because QP can a line longer than the maximum line-length), but special casing the encoding for cover-letters doesn't strike me as The Right Thing To Do(tm). I think the only real alternative to 8-bit encoding is Base64, and it sacrifices human-readability. Dunno how bad that is, though. -- Erik "kusma" Faye-Lund