[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] mhshow: invalid QUOTED-PRINTABLE encoding

From: Valdis . Kletnieks
Subject: Re: [Nmh-workers] mhshow: invalid QUOTED-PRINTABLE encoding
Date: Mon, 27 Mar 2006 16:37:35 -0500

On Mon, 20 Mar 2006 18:09:41 GMT, address@hidden 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...)

Attachment: pgpwBi0j5yrVc.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]