On Tuesday, May 01, 2012 04:53:03, Philipp Kern wrote:
> On Tue, May 01, 2012 at 12:48:10AM -0400, Chris Knadle wrote:
> > I think it would be useful to describe what issue(s) there are concerning
> > 8BITMIME and why this is important. I've found some information [1]
> > about this, but it isn't clear what problems are actially *caused* by
> > the lack of 8BITMIME support by default in Exim. Is it just slow
> > sending of outbound attachments?
>
> The only issue I found so far is that Postfix will convert mails when
> sending to an Exim that does not advertise 8BITMIME (like *.d.o). Which
> let me with the need to handle qp although the mails are initially sent
> with 8bit (build logs).
>
> I also assume that Exim does send 8bit mails to non-8bit compliant MTAs
> (i.e. not advertising 8BITMIME). I don't know if that's some sort of
> violation.
I think it is.
If 'accept_8bitmime' is enabled (default is disabled), then Exim will send
email containing 8bit MIME to non-8bit compliant MTAs. (For verification of
this, see [1] and [2].) This would violate RFC 1652 section 3 [3]:
"If a server SMTP does not support the 8-bit MIME transport extension
(either by not responding with code 250 to the EHLO command, or by
not including the EHLO keyword value 8BITMIME in its response), then
the client SMTP must not, under any circumstances, attempt to
transfer a content which contains characters outside the US-ASCII
octet range (hex 00-7F)."
and also RFC 6152 section 3 [4] (which contains the idential paragraph above
from RFC 1652).
I think the reason Exim does not do this protocol conversion is that from the
point of view of an MTA author, the point of an MTA is to transmit the body of
the message without any modification to it once received, and body
modification would be required to convert 8-bit MIME to 7-bit MIME. I seem to
remember reading something along these lines in the Exim documentation years
ago and I'm having another look through it, but haven't found a reference to
this yet.
[1] https://en.wikipedia.org/wiki/Extended_SMTP#8BITMIME
[2] http://www.exim.org/exim-html-3.20/doc/html/spec_11.html
[2] https://tools.ietf.org/html/rfc1652#section-3
[3] https://tools.ietf.org/html/rfc6152#section-3
-- Chris
--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
Attachment:
signature.asc
Description: This is a digitally signed message part.