Re: lmtpd NUL rejection
On Fri, 10 Jan 2003, Igor Brezac wrote:
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.
We've gone live with 8.12.7, and F=1 is doing just what we hoped for:
silently deleting NULs in transit. Thanks again for the pointer.
Along the way, I've discovered a related bug in lmtpd (2.1.11). If a
misconfigured client sends a message with lines longer than 8190 chars,
the following code in imap/lmtpengine.c (lines 672-675) will incorrectly
report the presence of NULs:
else if (p[0] != '\n') {
/* line contained a \0 not at the end */
r = IMAP_MESSAGE_CONTAINSNULL;
continue;
(It assumes all lines end with '\n', which prot_fgets() doesn't
guarantee.)
I'm not sure what the right fix is for this. It's trivial to identify the
long-line case, but should lmtpd return an error (and if so, what?), or
should it try to handle this pathological case?
--
Simon Brady mailto:[EMAIL PROTECTED]
ITS Technical Services
University of Otago, Dunedin, New Zealand
Re: lmtpd NUL rejection
From: [EMAIL PROTECTED]
Date: Tue, 14 Jan 2003 17:24:17 +1300 (NZDT)
[...]
Along the way, I've discovered a related bug in lmtpd (2.1.11). If a
misconfigured client sends a message with lines longer than 8190 chars,
the following code in imap/lmtpengine.c (lines 672-675) will incorrectly
report the presence of NULs:
else if (p[0] != '\n') {
/* line contained a \0 not at the end */
r = IMAP_MESSAGE_CONTAINSNULL;
continue;
(It assumes all lines end with '\n', which prot_fgets() doesn't
guarantee.)
I'm not sure what the right fix is for this. It's trivial to identify the
long-line case, but should lmtpd return an error (and if so, what?), or
should it try to handle this pathological case?
SMTP only requires 1000 character line support; 8000 is pretty
generous. I would define a new error in imap_err.et
(IMAP_LINE_TOO_LONG) and return that when appropriate.
Larry
Re: lmtpd NUL rejection
On Fri, 10 Jan 2003, Igor Brezac wrote:
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.
Aha, this sounds like just what we need - and yes, it was added in 8.12.0
so it looks like we've got another upgrade to do. Fortunately the new
edition of the bat book has come out just in time...
Thanks!
--
Simon Brady mailto:[EMAIL PROTECTED]
ITS Technical Services
University of Otago, Dunedin, New Zealand
lmtpd NUL rejection
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
Re: lmtpd NUL rejection
[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? And out of general curiosity, have other sites moving to lmtpd encountered this, or are we just particularly weird? I 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. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: lmtpd NUL rejection
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
