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