On Fri, 10 Jan 2003 [EMAIL PROTECTED] wrote: > 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?
Have you tried F=1 mailer flag? This may only work in Sendmail 8.12.x. >From op.txt: 1 Don't send null characters ('\0') to this mailer. I have not tried this flag yet, so I am not sure if NULL chars are removed or if the message is rejected. > And out of general curiosity, have other sites moving to lmtpd encountered > this, or are we just particularly weird? This is not new, Cyrus 1.6.x 'deliver' rejects such messages as well. -- Igor