> On Dec 6, 2017, at 11:12 AM, Adrian Zaugg <exim.org@???> wrote:
>
> The mailsploit attack relies on special chars like newline or the nul
> character encoded in base64 or quoted-printable. In my opinion encoded
> strings in mail headers should get decoded for validity checking, e.g
> when setting in an ACL: require verify = headers_syntax
Unfortunately, there's little to check. This is because encoding applies
to the "phrase" portion of the "From:" and some other headers), which
contains free-form text for display along with the address. All content
is legal in that context, when suitably encoded.
> Am I wrong with this assumption?
Mostly, because correctly encoded content is basically valid:
https://tools.ietf.org/html/rfc2047#section-5
in the free-form "phrase" part of the From header. There's a
"should suggestion to avoid non-printable data:
Only printable and white space character data should be encoded using
this scheme. However, since these encoding schemes allow the
encoding of arbitrary octet values, mail readers that implement this
decoding should also ensure that display of the decoded data on the
recipient's terminal will not cause unwanted side-effects.
Use of these methods to encode non-textual data (e.g., pictures or
sounds) is not defined by this memo.
but I don't think that this is something MTAs should be enforcing.
Proper handling of display names is the job of the MUA.
--
Viktor.
