Re: [exim] Exim 5.x

Top Page
Delete this message
Reply to this message
Author: Phil Pennock
Date:  
To: exim-users
New-Topics: [exim] 8BITMIME
Subject: Re: [exim] Exim 5.x
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