lmtpd NUL rejection

[simon.brady at otago.ac.nz]

I've recently upgraded imapd from 1.5.19 to 2.1.11, and instead of having
sendmail invoke deliver it now talks to lmtpd over a Unix socket. All is
well, except that lmtpd is much more scrupulous about checking its input
than deliver was - in the space of a week, it's detected three otherwise
normal messages containing embedded NULs and has rejected them with DSN
"554 5.6.0 Message contains NUL characters" (status
IMAP_MESSAGE_CONTAINSNULL in imap/lmtpengine.c).

OK, fair enough, except that sendmail responds to the bounce by trying to 
copy the message to postmaster. Via lmtpd. Oops.

Clearly the input is bad and lmtpd is justified in rejecting it. However,
broken mail clients (or whatever - we haven't identified any common factor
yet) are a fact of life, and having mail stuck in a non-delivery loop
isn't very helpful for our users.

What's the Right Thing to do here? Should sendmail (8.11.2) be configured
to somehow report the failure without forwarding the message, or perhaps
do NUL filtering on the fly? Or is there some way of configuring the lmtp
mailer definition to get around this problem?

And out of general curiosity, have other sites moving to lmtpd encountered 
this, or are we just particularly weird?

Thanks...

Simon Brady                             mailto:simon.brady at otago.ac.nz
Systems Specialist                                  Ph. +64 3 479-5217
ITS Technical Services                              Fax +64 3 479-5080
University of Otago, Dunedin, New Zealand       Mobile +64 27 411-6045