There is an even better reason: security. Since a multipart wrapped
in QP (or base64) is undefined, there is no correct way to deal with
it, and therefore nobody will deal with it "correctly" â?? if that was
even possible. This means broken parsers generating stack overflows,
ripe for exploitation by viruses. I would *really* like to see the raw
source for a couple of these messages, as I'm starting to wonder if
these aren't actual virus payloads.
So, I've been meditating on this for a bit, and let me speak to some of
this.
- The interpretation of Postel's Law is ... not universal. See:
http://en.wikipedia.org/wiki/Robustness_principle
http://tools.ietf.org/html/rfc3117
http://queue.acm.org/detail.cfm?id=1999945
So, the _right_ thing to do here is not clear, at least to me. The MIME
RFCs don't spell out what to do when you receive a message that is
malformed; are you supposed to error out? Fall back to something else?
Try to do a best effort-guess? It's okay to drop stuff on the floor
when we're talking about network packets since it's expected there will
be loss, but I'm not sure the same expectation applies to email.
- I am 100%, absolutely sure that at least in my case the message in
question was not a virus payload. In my case the multipart claimed
that the Content-Transfer-Encoding was q-p, but since there were plenty
of equal signs that were not encoded it was clear that it wasn't. I
edited by hand the encoding to 7bit and I was able to extract out the
content (my tickets) fine.
- If our fallback position is that multipart types that have a bogus
encoding such as quoted-printable or base64 are interpreted as 7bit
(or 8bit) I fail to see how that will generate any NEW security issues
in terms of parsing MIME headers. I have a strong suspicion that this
is how other mailers deal with such messages.
- I actually got our admins to restore my home directory from backups and
I was able to locate the offending message in question. However, it
is AFTER I edited the Content-Transfer-Encoding from quoted-printable
to 7bit. There are actually two C-T-E headers in that message;
a toplevel multipart/mixed type and one of the parts had a
multipart/related type. I don't recall if only one or both of those
were quoted-printable (I believe it was both, but I honestly can't be
sure). The multipart/related type also included a charset parameter
which makes me think it's especially bogus. I made no other changes
to this message. If you want a copy of it, I'm glad to send it to you
off-list.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers