Re: [Exim] cyrus NUL failures

Página Principal
Apagar esta mensagem
Responder a esta mensagem
Autor: Exim User's Mailing List
Data:  
Para: Pat Lashley
CC: Chris Edwards, Exim Users Mailing List
Assunto: Re: [Exim] cyrus NUL failures
[ On Thursday, December 4, 2003 at 13:24:25 (-0800), Pat Lashley wrote: ]
> Subject: Re: [Exim] cyrus NUL failures
>
> >| And if it isn't spam, the sender needs to know that
> >| their MUA is broken.
> >
> > Arguably yes. However, since almost any sane mail system just handles
> > these things without complaining [1],
>
> For now, yes. But mailadmins are starting to tighten up their RFC
> compliance requirements as a way of blocking some of the more egregious
> spamers.
>
> And NUL characters are potentially a source of problems for content
> filtering programs, or even MUAs that use C string functions.


The problem has far less to do with RFCs and standards and _far_ more to
do with the latter -- particularly the security implications of the latter.

> 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.

> 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.

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.

--
                        Greg A. Woods


+1 416 218-0098                  VE3TCP            RoboHack <woods@???>
Planix, Inc. <woods@???>          Secrets of the Weird <woods@???>