On 2002-03-20 at 09:27 +0000, D.M.Chapman wrote:
> Many of our students (and staff) will be sending to demon users no doubt.
C'est la vie.
> > If a server doesn't advertise 8BITMIME, any server which _does_ have
> > 8bit content, should downgrade the content. Exim doesn't have the
> > ability to do this. Therefore you'll be introducing breakage and
> > corruption by turning the feature on.
>
> Ok. So it sounds like a bad thing to do. Do you have any references to exact
> bits of rfc that say the above (I know I could look - but if you happen to
> know :-) so that I can prepare my defence. I can see this turning into a
> big argument with a deputy director here at the uni :-( If I can provide
> black and white evidence that the remote site should be "down converting"
> to 7 bit as we do not advertise 8bit it will help!
If it's important enough, he can fund writing a patch to Exim to
downgrade. ;^)
RFC:
1652 SMTP Service Extension for 8bit-MIMEtransport. J. Klensin, N.
Freed, M. Rose, E. Stefferud, D. Crocker. July 1994. (Format:
TXT=11842 bytes) (Obsoletes RFC1426) (Status: DRAFT STANDARD)
-----------------------------< cut here >-------------------------------
[...]
Once a server SMTP supporting the 8bit-MIMEtransport service
extension accepts a content body containing octets with the high-
order (8th) bit set, the server SMTP must deliver or relay the
content in such a way as to preserve all bits in each octet.
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).
A client SMTP has two options in this case: first, it may implement a
gateway transformation to convert the message into valid 7bit MIME,
or second, or may treat this as a permanent error and handle it in
[page-break]
the usual manner for delivery failures. The specifics of the
transformation from 8bit MIME to 7bit MIME are not described by this
RFC; the conversion is nevertheless constrained in the following
ways:
[...]
-----------------------------< cut here >-------------------------------
Exim's accept_8bitmime option is disabled by default, so that Exim
behaves correctly in all situations by default. If you have an MTA
which only accepts _incoming_ mail, and only passes it to
8-bit-advertising MTAs (or none), then it's safe to enable the option.
Enabling the option on any system which can pass mail out to the
Internet is A Bad Thing.
Exim is not a protocol converter. That doesn't mean that a protocol
converter can't be tied in, similarly to virus scanners et al. It would
require knowing if the message contains 8-bit content and if the
outgoing SMTP transport has connected to a server _not_ advertising
8BITMIME, together with a way to either then filter the content, or to
take the 8bit messages that were due to go down that connection, send
them out via another router, and if no messages are left to close the
connection.
Got a development budget? :^)
--
(A)bort, (R)etry, (T)ake down entire network?
