[Mimedefang] Sendmail 8.13.7 relased

[Jan-Pieter Cornet]

On Wed, Jun 14, 2006 at 02:51:33PM -0400, Cormack, Ken wrote:
> Sendmail.org has released sendmail 8.13.7.  I see nothing in there that
> should/would cause any issues for MIMEDefang, except for one overlapping
> feature between the two packages.  The sample mimedefang-filter.example sets
> "$MaxMIMEParts = 50", where if I'm reading the sendmail release notes
> correctly, sendmail 8.13.7 now sets this limit at 20...

It's a different limit. MaxMIMEParts sets the total number of
mime parts a single mail may have, the sendmail 8.13.7 MAXMIMENESTING
sets the maximum _nesting_depth_ you can have.

While the sendmail workaround of treating the 20th nesting level
as opaque data, and pass that on literally is, from a sendmail
perspective, the most graceful thing to do, I'm somewhat concerned
about the security implications of that. It means you can pass 8 bit
data to subsystems that expect 7-bit-clean input, and you can send
over long MIME headers, possibly exploiting buffer overruns in MTAs
that are currently protected.

David: I was already looking at this issue, would you accept a patch
to MIME-Tools (MIME::Parser) that added an optional maximum _nesting_
depth, next to the max_parts setting?

> David, would this "opaque remaining content" present a problem for
> MIMEDefang?

David wrote:
> I'm not sure.  I'd have to study the Sendmail source code to see if
> MIMEDefang gets the original, raw body, or the body after Sendmail
> has done 8->7 conversion.

The mime 8->7 conversion is called in deliver.c, ie: from the M -- Mailer,
which means the milter gets a chance first, and sees the raw data
(as long as it isn't changed by a previous milter).

So my current guess is that MD installations with MaxMIMEParts = 50
are already pretty "safe", provided that 50 nested MIME parts don't
trip your stack. The sendmail limit of 20 just seems like a nice
safe, conservative limit that nobody really should exceed (but some
do... I've seen bounce loops producing a near-infinite nesting of
message/rfc822 parts. That sort of stuff tends to break lots of
software, in this case it broke some MUA).

But I'm just speculating here: handwaving, educated guesses, some
astrology, and reading the intestines of a freshly slaughtered goat,
which is the first thing to consult in case of sendmail troubles
anyway.

-- 
Jan-Pieter Cornet <johnpc at xs4all.nl>
!! Disc lamer: The addressee of this email is not the intended recipient. !!
!! This is only a test of the echelon and data retention systems. Please  !!
!! archive this message indefinitely to allow verification of the logs.   !!