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 vger.kernel.org) by
vger.kernel.org via listexpand
> id S1750700AbWJVMCV (ORCPT
<rfc822;kha-list-githemma.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.
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 |