freebsd stable - Apr 2003 - post last sendmail upgrade

I've noticed email corruption post the last upgrade to sendmail
	committed to stable.  Is anyone else experiencing this?

	Mark
-- 
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: Mark.Andrews@isc.org

On Thu, Apr 17, 2003, Mark.Andrews@isc.org wrote:
> 
> 	I've noticed email corruption post the last upgrade to sendmail
> 	committed to stable.  Is anyone else experiencing this?
What kind of corruption?

You may want to follow the advise in the last sentence:

	To provide partial protection for internal, unpatched MTAs that may be
		performing 7->8 or 8->7 bit MIME conversions, the default
		for MaxMimeHeaderLength has been changed to 2048/1024.
		Note: this does have a performance impact, and it only
		protects against frontal attacks from the outside.
		To disable the checks and return to pre-8.12.9 defaults,
		set MaxMimeHeaderLength to -1/-1.

It seems that the MaxMimeHeaderLength checks remove '\0' under
certain circumstances.

> 
> > On Thu, Apr 17, 2003, Mark.Andrews@isc.org wrote:
> > > 
> > > 	I've noticed email corruption post the last upgrade to
sendmail
> > > 	committed to stable.  Is anyone else experiencing this?
> > 
> > What kind of corruption?
> 
> 	I've had the tail of the body set to 0x80's.  Most common
> 	failure mode.
	Note the 0x80's end with a ')'.
 
> 	I've had a message (S-P1-P2-E) appear as (S-P2 P1-E),
> 	the chunk P1-P2 appears twice.
> 
> 	
> > You may want to follow the advise in the last sentence:
> > 
> > 	To provide partial protection for internal, unpatched MTAs that may
be
> > 		performing 7->8 or 8->7 bit MIME conversions, the default
> > 		for MaxMimeHeaderLength has been changed to 2048/1024.
> > 		Note: this does have a performance impact, and it only
> > 		protects against frontal attacks from the outside.
> > 		To disable the checks and return to pre-8.12.9 defaults,
> > 		set MaxMimeHeaderLength to -1/-1.
> > 
> > It seems that the MaxMimeHeaderLength checks remove '\0' under
> > certain circumstances.
> > _______________________________________________
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to
"freebsd-stable-unsubscribe@freebsd.org"
> --
> Mark Andrews, Internet Software Consortium
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org

On Thu, Apr 17, 2003 at 01:12:07PM +1000, Mark.Andrews@isc.org
wrote:
> 
> 	I've noticed email corruption post the last upgrade to sendmail
> 	committed to stable.  Is anyone else experiencing this?
I just read through the diff between 8.12.6 (4.7-RELEASE) and 8.12.9 and
didn't see anything in sendmail itself that would cause message corruption.
I did however spot one oddity in mail.local but older versions would have
suffered from the same race condition.  Basically, if the close() on
the mailbox fails (due to disk full, user over quota, or a write error
only caught after the fsync() (which shouldn't happen)), the mailbox
is truncated back to the pre-message size without re-locking the mailbox.
It's doubtful this is happening to you since the chances of close() failing
and the previous fsync() not are pretty low.  You would also see temporary
delivery failures of the form "450 4.2.0 <strerrror(errno)
output>" in
syslog.

Are you using mail.local or some other local delivery agent?  How
are you reading your mail from your mailbox; could that pop/imap/MUA
be responsible?

> 
> 	I've noticed email corruption post the last upgrade to sendmail
> 	committed to stable.  Is anyone else experiencing this?
> 
> 	Mark
	It looks like the imap server was upgraded simultaneously
	to this.  At the moment I'm going to work on the assumption
	that that was the cause.  We caught one case of it corrupting
	a mailbox it was managing.

	The imap server has been further upgraded to see if that
	addresses the problem.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org