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  > > 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  and .) This would violate RFC 1652 section 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  (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.  https://en.wikipedia.org/wiki/Extended_SMTP#8BITMIME  http://www.exim.org/exim-html-3.20/doc/html/spec_11.html  https://tools.ietf.org/html/rfc1652#section-3  https://tools.ietf.org/html/rfc6152#section-3 -- Chris -- Chris Knadle Chris.Knadle@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74
Description: This is a digitally signed message part.