On Sun, 5 Nov 2006, Karl Hasselström wrote: > > 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.) Right. You could even just consider it an error if the mailserver doesn't reply to EHLO with 8BITMIME, I really think it's that rare. > 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. I _think_ it should be sufficient to just set the Content-Type and Content-Transfer-Encoding to say something like "text/plain; charset=UTF8" and "8bit" respectively. But somebody who know the SMTP rules better should check. HOWEVER: > 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. This does seem to say that somebody didn't even announce 8-bit capability in the first place. That's a zmailer error message, and it does imply that somebody was running a bad server. That said, _if_ your message had had the proper mime-type specifiers, then zmailer would happily have QP-converted the message for you, so everything would have been fine. > 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. vger itself? Strange. Linus