Re: vger doesn't like UTF-8 from send-email

[Erik Faye-Lund <kusmabite@googlemail.com>]

On Sun, Jun 13, 2010 at 6:15 AM, Michael Witten <mfwitten@gmail.com> wrote:
> On Sat, Jun 12, 2010 at 05:11, Thomas Rast <trast@student.ethz.ch> 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: <cover.1276336602.git.trast@student.ethz.ch>
>> 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