[ My previous message failed to make its point, when "mutt" applied
a second layer of encoding to my hand-constructed From: header.
Please pardon the duplicate post. ]
On Thu, Dec 07, 2017 at 11:14:12AM +0100, Adrian Zaugg wrote:
> The mailsploit attack is not only going to the "free-form phrase", it's
> also affecting the from-address.
Actually, no. A correct implementation of RFC 2047 will not
interpret anything in the encoded phrase as being part of the
mailbox address, the entire content of the encoded phrase is part
of the "display name", no matter what it decodes to. To be more
specific, the parsing of a structured address header as:
From: phrase one <address1>, phrase two <address2>
must happen first, *before* any decoding of "phrase one" and
"phrase two". While "phrase one" might be some encoding of:
phrase three <address3>, phrase four <address4>
that string must not be parsed as though it appeared unencoded in
the From: header. Parsing into display names and addresses must
happen *first* and decoding of display names *second*. Not the
other way around.
How to sanitize and present potentially misleading display names
to the user in a non-confusing way is up to the MUA. The MTA's
job is to transmit the message.
The only rope for enforcement by the MTA is the text that says that
such encodings SHOULD only be for printable text, not arbitrary
binary data. So ASCII control characters (other than TAB), inside
the encoded phrase, are potentially something that an MTA could be
configured to enforce. That would still leave plenty of room for
confusing the recipient when the MUA does a sloppy job of presenting
the From: header.
--
Viktor.
