On 7/21/20 6:05 AM, Douglas E. Foster 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..
I like this way of thinking, and it seems like a good time to mention the following anecdote for the sake of the "end-users can't make security decisions" argument... Specifically to address BEC we strip the friendly from (at our MTA gateways prior to ingestion to O365) conditionally (one example: from domains of free email providers) to force the MUA (Outlook and everything else) to show the From address. It works because now the victims just see "wisc.edu.provos...@gmail.com" instead of "Office of the Provost" and are more likely to consider the message hostile, less likely to click on the weird link, less likely to buy gift cards, and so on. I can count on one finger how many people have noticed that we're doing it (it wasn't an end-user, but it was our CRM team who uses friendly from to soft match on contacts) for a population of 150,000 mailboxes. Meanwhile, we get very few people claiming that we aren't somewhat mitigating BEC scams. Note that other institutions are tagging Subjects and bodies with EXTERNAL warnings, either to all external sourced email or based on some conditional rules, but they are not directly addressing the display name spoofing itself. I suspect that people learn to ignore those warnings over time and still fall victim to some well crafted scams from a spoofed VIP in their organization. I can't say with certainty which tactic works better (DKIM signature breakage is a wash), but I think forcing the MUA to reveal the sender's identity is more effective, less disruptive, and dovetails nicely with DMARC and the security marketing of the DMARC vendors. Jesse _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
