It's one of the things that annoys me about the dumbed down nature of many
modern MUAs: their habit of showing only the display name rather than also
including the email address. For example here Gmail is showing me a
previous message as being fromjust "Adrian Zaugg" unless I actively click a
small drop-down menu to see more details.
This can lead to people embedding a valid-looking email address in the
display name, the recipient seeing that and being fooled into thinking the
address is the sender when it isn't.
Bring back dumb terminals, the CLI and the Pine MUA! :-)
Cheers,
Mike B-)
On 7 December 2017 at 19:33,
=?utf-8?B?0JLQuNC60YLQvtGAINCU0YPRhdC+0LLQvdGL0LkgPGV4aW0tdXNlcnNAZHVraG92?=
=?utf-8?B?bmkub3JnPiwgQWxzbyBLbm93biBBcyBWaWt0b3IgRHVraG92bmkgPGV4aW0tdXNl?""=
=?utf-8?B?cnNAZHVraG92bmkub3JnPgo=?= <exim-users@???> wrote:
> 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.
>
> --
> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/
>
--
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811
Web:
www.york.ac.uk/it-services
Disclaimer:
www.york.ac.uk/docs/disclaimer/email.htm
