-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On 2011-05-20 at 09:36 +0000, Ian Eiloart wrote: > On 19 May 2011, at 19:05, W B Hacker wrote: > > If nothing has reverted, I read that as a U Cambridge server having > > accepted 8BITMIME with a 250-Ok many years and versions ago. > > It doesn't advertise 8bitmime now. I'm not sure what would happen if I > ignored that and sent 8bitmime anyway. Maybe it would be OK, but there > may be other sites that would simply bounce the messages.
If you happened to just send email which contains characters from outside the 7-bit ASCII range, then I would expect the server to accept it and process it cleanly. Exim is 8-bit clean and always has been (as far as I know; perhaps Exim 1 or 2 wasn't?). 8BITMIME is distinct from "having content making full use of the available bits". 8BITMIME is a protocol extension which establishes a contract for handling of email when forwarding it on. If an Exim MTA does not have accept_8bitmime turned on, then it will not implement the protocol extensions (adverbs on the MAIL command) and 8BITMIME attempts will be rejected as protocol errors -- as they should be. This recently was encountered by Ted Cooper, posting on exim-users: http://www.exim.org/lurker/thread/20110313.035235.07b8c3b8.en.html#i20110313.035235.07b8c3b8 wherein a spambot was ignoring the non-presence of 8BITMIME in the announced capabilities (EHLO keywords) and was using BODY=7BIT on the MAIL line. If an Exim MTA *does* have accept_8bitmime turned on, then: * it will advertise the keyword in the EHLO response * if EHLO was used, then it will accept the extra adverbs on MAIL * it will do nothing else special with the message Note that this means that turning on accept_8bitmime: * for a system handling only in-bound mail is fine, and probably a _very_ good idea (unless your POP3/IMAP servers are not 8-bit clean) * for a system which can forward mail outwards again will result in your install violating the RFC 1652 protocol's contract Now, how bad it is to break the contract of RFC 1652 is debatable; email protocol debaters being what they are, any debate would become boringly contentious with vitriol, character assassination and flame-wars on both sides. See, I just performed an act of character assassination! If you wish to implement DJB's recommended behaviour per http://cr.yp.to/smtp/8bitmime.html then just turn on "accept_8bitmime" in Exim and you'll get exactly that. I suspect that what we'll end up doing is implementing protocol conversion, defaulting accept_8bitmime to true and having an option "8bitmime_ignore" which defaults to "off" for strict RFC adherence. Then about 7 years later, when everyone's using raw UTF-8 mail domains and LHSs (ignoring punycode and the other baroque pieces of infrastructure dreamed up by people who hate simplicity), we'll default "8bitmime_ignore" to "on" before removing the protocol conversion functionality and heaving a huge sigh of relief. That, or at some point in the next year I'll drink enough whiskey to decide to tell some people where they can stick their idiot 7-bit systems and just commit a change defaulting accept_8bitmime to on, then after the next release of Exim take a month-long holiday from the Internet to avoid the flame-wars until they settle down and everyone realises that in fact, DJB is right, Phil Hazel was right to refuse to implement protocol conversion and people are making a big fuss about a non-issue. - -Phil -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk3WP4YACgkQQDBDFTkDY38rcACgkfNqNaavuXo6LgKdWIRwb8R8 n4MAn18SFTc9PJ16TznN3qT88ra8SMgd =Qbdj -----END PGP SIGNATURE----- -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
