On 2006-11-03 10:48:49 -0800, Linus Torvalds wrote:
> 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@xxxxxxxxxxxxxxx) by vger.kernel.org via listexpand
id S1750700AbWJVMCV (ORCPT <rfc822;kha-list-git@xxxxxxxxxxxxxxxxx>);
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@xxxxxxxxxxxxxxx) 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@xxxxxxxxxxx
www.treskal.com/kalle
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html