Message contains NUL characters ...

[Greg A. Woods]

[ On Sunday, May 8, 2005 at 21:35:58 (+0200), John Fawcett wrote: ]
> Subject: Re: Message contains NUL characters ...
>
> the reason is that at the moment I can have nuls rejected by cyrus
> and potentially bounced to some innocent third party in the case
> of forged sender addresses.

That's the right reason for certain -- but the wrong fix!  ;-)

I'm all for preventing unnecessary bounces!


> My reading of the earlier posts was that nuls were acceptable but
> had to be stripped, even by cyrus.

Destructive modification of mail in transit is never acceptable, at
least not if it can be avoided.


> If cyrus is correct to reject then we really need mta patches
> (maybe apart from sendmail where I understand the rejection is
> configurable).

Exim and Smail can certainly be configured to reject incoming messages
containing NUL bytes, and you're probably right that Sendmail can be
configured to do so as well (those silly MILTER things run while the
SMTP connection is open and can return SMTP error responses, right?).


> I am very happy with postfix!

Apparently Postfix suffers a design flaw in that its internal dictionary
lookup API uses NUL-terminated strings so it is not possible for it to
easily use any regex pattern in header_checks or body_checks to match
NULs -- the regex engine simply won't ever see the NUL in a header or
body line passed to it to be matched, and instead it'll just see a
shorter NUL.  (Note this is a bit more serious than one might suspect on
first glance since it probably means an embedded NUL can hide further
content on the line from header_checks and body_checks!)

However once upon a time not so long ago (2005/04/02), on the Postfix
users mailing list, Wietse Venema said:

    Postfix has an option to flag and reject 8-bit content in message
    bodies that are announced as 7bit; this could be duplicated with
    minor change to flag and reject nulls in body content. It's only
    a dozen lines of code, and a dozen or lines of documentation. I
    won't do it as I am working on other stuff.

So apparently the proper fix should be quite easy to implement, and done
right a patch is likely to be accepted back by Wietse as well.

-- 
						Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>          Secrets of the Weird <woods at weird.com>
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html