Re: [dmarc-ietf] Why are MUAs hiding or removing the From address?

[Brandon Long <[e-mail]>]

Do sms/mms programs show the phone number any more?  I think there's been a
deliberate strategy to make email clients more like
other messaging clients, and the technical parts like the actual address
are details that most of the time aren't useful to the user... when
they're not being spoofed, of course, or otherwise need to differentiate
between multiple addresses for the same person.

Brandon

On Tue, Jul 21, 2020 at 4:06 AM Douglas E. Foster <
[e-mail]> wrote:

> I would like a better understanding of why MUAs are hiding or removing the
> FROM address.
>
> I have one mail store that formerly used hover-to-view, but recently
> changed to always-show.   This was done in response to a client request on
> their support forum.  I have never seen a user ask for the From address to
> be hidden or removed.  I wonder if this trend is driven only by attempts to
> optimize display space.   It would be a shame to weaken our protocols in
> response to this trend, if the trend lacks a theoretical foundation.
>
> I also wonder if the trust indicator research is being over-applied when
> it is applied to the From Address.    From Address is a unique identifier,
> while Friendly Name is not.   A trust indicator is like putting a green
> check mark next to the From Address as a trust indicator.   They have
> different levels of relevance.
>
> One attack method steals a contact list, then emails people in that
> contact list using friendly names of others in that list.   Hiding the From
> Address plays into that attack.
>
> This trust-indicator research also promotes despair.  The conclusion is
> that users process information poorly.   This result then becomes an excuse
> to withhold information from those users, or to allow misleading
> information to be presented to them.    I am not convinced that those are
> appropriate responses.   "Never" is a hard thing to prove.  So it is risky
> to say users "Never" use available information correctly, and "cannot be
> taught" to do better.
>
> Attack filtering is designed on a layered defense and a sequence of
> probabilities:
>
>    - What is the probability that this attack will get through my spam
>    filter?
>    - What is the probability that the user will read the message?
>    - What is the probability that the user will click on the hostile link?
>    - What is the probability that my web filter will allow access to the
>    hostile website?
>    - What is the probability that the web filter will allow the attack to
>    be downloaded?
>    - What is the probability that my antivirus program will allow the
>    attack to proceed?
>
> The goal is to decrease the probability of a wrong decision at each point
> in the process.   All I need is for some people to act smarter on some
> occasions in response to some available clue.   But this cannot happen if
> the clue is not provided..
>
> Doug Foster
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>