Re: [Exim] cyrus NUL failures

Top Page
Delete this message
Reply to this message
Author: Chris Edwards
Date:  
To: PM Lashley
CC: Exim Users Mailing List
Subject: Re: [Exim] cyrus NUL failures
| > We thought about using exiscan's rexexp feature to detect and reject such
| > messages during the dialog. But we couldn't get this to work. Regexp
| > looking for NULL never triggered.

|
| Hmm. I've had no problem with this one:

|
|     deny    log_message     = NUL in body
|             message         = Unescaped NUL character in message body\n\
|                 (See RFC 2822, section 2.3; and RFC 2045, sections 2.7 & 2.8)
|             condition       = ${if match {$message_body} {\N\x00\N} {yes} {no}}


That only checks the first $message_body_visible bytes of the message.
In our environment this is currently set at 50KB. We sometimes get much
bigger messages coming in with a NULL right at the end.

( often the very last byte of an appended .sig - broken MUA )



| > Nowadays we deliver to those destinations using a transport filter which
| > uses "tr" to bin the damm things:
| >
| > transport_filter = /usr/bin/tr -d \\000

|
| Personally, I'd rather reject these messages. Every one I've seen so
| far has been spam.


We see some that aren't spam...


| 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], then we thought we may as well
emulate this for our Netmail servers.

Exim, sendmail pass NULLs cleanly. Exchange seems to turn them into spaces...