Re: [PATCH] Allow hand-editing of patches before sending

From: Karl Hasselström <kha@treskal.com>
Date: Nov 5, 2006, 11:43 UTC
Message-ID: <20061105114353.GB19707@diana.vm.bytemark.co.uk>
In-Reply-To: <Pine.LNX.4.64.0611031034520.25218@g5.osdl.org>

On 2006-11-03 10:48:49 -0800, Linus Torvalds wrote:

Show 27 quoted lines

> If your ISP mailer doesn't answer with "8BITMIME" to your EHLO, your
> mail client is supposed to downgrade to a 7-bit format (or the same
> thing can happen anywhere in between on one of the other hops). Of
> course, that would be a really old and broken mailer, and if you
> find one of those at the ISP you use, you should probably switch
> ISPs.
>
> Some other mailers have other issues, and qmail for example is
> apparently totally broken (it accepts 8-bit input, but cannot
> forward it properly to somebody who wants it converted to 7-bit).
>
> And some of us use "fetchmail" and ask it do do mimedecode for us,
> so that even if it arrived as 7-bit crud, we don't have to see it.
> So the fact that some people see it as 8-bit can be because the hops
> to them didn't involve a broken remailer, but it could also be
> because something in between (like fetchmail) tries to fix it up
> after the fact.
>
> That said: it tends to be unusual to see true 7-bit mailer setups
> these days.
>
> So the most _likely_ cause of unnecessary 7-bit QP crud is not in
> fact a 7-bit mailserver, but usually just the mail client that is
> just lazy and just sends out everything as 7-bit because it's too
> bothersome to even look at whether the mail server supports 8-bit
> data. Check your Thunderbird settings - it's quite possible that
> there's a flag there somewhere to turn on 8-bit mail transfers.

So the right thing to do would be to teach StGIT to generate 8bit-encoded output, and trust the SMTP transfer path do mangle it correctly? (Hmm. No, since StGIT talks directly with the first SMTP server in the chain, it needs to be able to QP-encode the mail itself if necessary -- but it should seldom be necessary, then.)

In that case, the problem with the current implementation (without my patch applied) is likely to be that it fails to provide the headers needed for the SMTP path to be able to transform it losslessly.

[ ... digs through old mail ... ]

This is the interesting part of such a mail that was sent from my computer, passed through the list, and ended up back at my computer again:

  Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
          id S1750700AbWJVMCV (ORCPT <rfc822;kha-list-git@hemma.treskal.com>);
          Sun, 22 Oct 2006 08:02:21 -0400
  X-Warning: Original message contained 8-bit characters, however during
             the SMTP transport session the receiving system did not announce
             capability of receiving 8-bit SMTP (RFC 1651-1653), and as this
             message does not have MIME headers (RFC 2045-2049) to enable
             encoding change, we had very little choice.
  X-Warning: We ASSUME it is less harmful to add the MIME headers, and
             convert the text to Quoted-Printable, than not to do so,
             and to strip the message to 7-bits.. (RFC 1428 Appendix A)
  X-Warning: We don't know what character set the user used, thus we had to
             write these MIME-headers with our local system default value.
  MIME-Version: 1.0
  Content-Transfer-Encoding: QUOTED-PRINTABLE
  Content-Type: TEXT/PLAIN; charset=ISO-8859-1
  Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751780AbWJVMCV
          (ORCPT <rfc822;git-outgoing>); Sun, 22 Oct 2006 08:02:21 -0400

The mail server (vger talking to itself, if the Received: headers were added in order) complained that there were no MIME headers, so it had to guess the charset. As it happened, it guessed wrong, so the non-ascii characters of the mail body was garbled.

My stab at fixing this was to make StGIT QP-encode the mail from the outset, but if I've not misunderstood things yet again, the actual problem was that StGIT did not produce the right MIME headers.

-- 
Karl Hasselström, kha@treskal.com