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:[EMAIL PROTECTED] 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