Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> writes:
probably what you want is something like:
- filter out every body part which isn't text/plain, message/rfc822,
image/*, a signature (there are several types), or a multipart/*
(filters apply recursively to components of message/rfc822 and multipart/*)
- if the resulting filter removes every component of a multipart or
a message/rfc822, also filter the enclosing multipart or message/rfc822.
- if this results in the entire message getting filtered, bounce the message
- otherwise, if any of the filtered contents appear to be critical
(for instance they are marked with content-disposition: inline),
bounce the message.
- otherwise, forward the message with the filtered contents removed
it's not exactly a SMOP.
You probably don't actually advocate such an approach, but simply
point out how ridiculously and unmanageably complex it would be.
Such complex and counter-intutitive transformations will inevitably
often fail. The ``if any of the filtered contents *appear* to be
critical'' (emphasis mine) part is especially flaky. Delivery of
message with semantically important parts missing may well be worse
than no delivery at all. Example: ``Here's the latest version of our
FUBAR proposal'', with a uSoft Word attachment. Delivering just the
``Here's...'' part seems pointless. And the poster will, of course,
immediately followup with ``Sorry, forgot to include the attachment.
Here goes again. I hope I got it right now.''
Take it or bounce it with an explanation would seem like a much better
approach. The sender is in a position to make substantive changes to
the message, not the list software.
Heuristics of refusing to take large messages is fine (they probably
contain some garbage anyway, such as proprietary format attachments or
``viruses'' for retarded MUAs--is there a difference between these
categories?).
MAIMed messages per se aren't evil (1KB PNG drawing, message/rfc822,
multipart/signed, etc. are all examples of harmless use of MIME).
Abuse of MIME, OTOH, is often associated with outrageously inflated
messages. At the same time, small messages can naturally be abuse of
MIME and poor style of using it as well (especially evil being
HTML+plain text in the same message).
Is the same IETF that would scream when faced with an idea to fix
IP packets so that they carry what the sender has *actually meant*
advocating fixing RFC2822 messages in just such fashion with "demime"
tools and such?
--
Stanislav Shalunov http://www.internet2.edu/~shalunov/
"I didn't attend the funeral, but I sent a nice letter saying that I
approved of it." -- Mark Twain