Re: [Exim] cyrus NUL failures

--On Friday, December 05, 2003 12:47:22 -0500 "Greg A. Woods" <woods@???> wrote:

> [ On Thursday, December 4, 2003 at 13:24:25 (-0800), Pat Lashley wrote: ]
>> Subject: Re: [Exim] cyrus NUL failures
>
>> That said, I'll have to admit that my decision to block rather than
>> translate NULs was arrived at rather reluctantly; and may yet be
>> reversed. I may look into automatically sending a warning back to
>> the sender when accepting a non-compliant message. (The major
>> difficulty being avoiding sending such messages to a mailinglist
>> submission address.)
>
> Please do not _ever_ try to send back notices to the apparent sender
> address for any reason whatsoever. Such mechanisms are abused far more
> often than they ever do any good. Do not _ever_ automatically trust any
> data or information received from the network, and that includes the
> sender address.

I am fully aware of these issues. That's why I have my ACLs set up
to try to reject messages at SMTP time rather than bouncing them later.
It's a big part of why I haven't taken the notification approach to
NULs yet. If I ever do, it will only occur when the IP address of
the host that delivered the message matches up with the domain of
the envelope sender. (And, of course, some sort of tests to try to
avoid sending to a mailinglist address.) If there were a mechanism
to send it back during the original connection; I'd set it up to do
that. (But, as I understand it, there is no way to do that unless
the client asks for it via ETRN.)


>> Cyrus is indeed the most strongly RFC-compliance demanding mail
>> related package that I've come across. Their reasons for doing
>> so make sense; but are a lot stronger in an academic environment
>> than they are here in the wild...
>
> Cyrus IMAP is simply protecting its mail readers from the dangers of
> allowing things like embedded NUL characters. The fact that the RFCs
> have the same rules is no mere coincidence, of course.

They are also strict about the RFC requirement that all octets in
the header block be in the range 1..127.


> It's all very well and good for the MTA to be able to transport
> arbitrary binary content, but it's very dangerous to assume that MUAs
> will deal sanely with such content.

Or mail filters. Or archive indexing programs. Or even downstream MTAs...



-Pat