[EMAIL PROTECTED] wrote:
I've recently upgraded imapd from 1.5.19 to 2.1.11, and instead of havingI noticed it here as well after switching from UW IMAP to Cyrus 2.1.11, and I am currently still running everything through a perl delivery program which does a number of clean-ups including stripping NUL characters. The problem is that a number of large mailing lists (such as some on Yahoo Groups) include NULs, so just dropping the mail wasn't an option. Eventually, I want to get back to the stock deliver but I will need to patch it to include an option to strip NULs similarly (as well as other issues currently being handled in the perl script) before I can.
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?
--
John A. Tamplin Unix System Administrator
Emory University, School of Public Health +1 404/727-9931
