On Mon, 20 Mar 2006 18:09:41 GMT, pmaydell@chiark.greenend.org.uk said:
RFC 2045 is pretty clear about what MUAs should do in the face of a bad encoding; the idea is to follow that.
(Also, anything you can get through with odd q-p you could have got through literally.)
RFC2045, section 6.7 actually says:
(2) An "=" followed by a character that is neither a
hexadecimal digit (including "abcdef") nor the CR
character of a CRLF pair is illegal. This case can be
the result of US-ASCII text having been included in a
quoted-printable part of a message without itself
having been subjected to quoted-printable encoding. A
reasonable approach by a robust implementation might be
to include the "=" character and the following
character in the decoded data without any
transformation and, if possible, indicate to the user
that proper decoding was not possible at this point in
the data.
...
(4) Control characters other than TAB, or CR and LF as
parts of CRLF pairs, must not appear. The same is true
for octets with decimal values greater than 126. If
found in incoming quoted-printable data by a decoder, a
robust implementation might exclude them from the
decoded data and warn the user that illegal characters
were discovered.
A lot of "reasonables" and "mights" there. :)
(Also, anything you can get through with odd q-p you could have got through literally.)
The fun starts when different things along the way use different rules - if your mail malware scanner deletes bad characters when doing its checks, but your final MUA doesn't, the bad characters can be used as part of a malicious payload invisible to the malware scanner. (It's the same basic attack as malware that uses different TCP/IP stacks' differing rules regarding fragment assembly to get malicious content through a firewall...)
pgpnuPKXsdcif.pgp
Description: PGP signature
_______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers