The only real fix for Friendly Name fraud is to strip it away, except for trusted domains that have been verified with DMARC PASS.
Major vendors are trying lesser solutions by preventing friendly name impersonation of key executives, but the problem is much greater. This topic is material for a subsequent document, but may have to be done outside of IETF since Friendly Name fraud prevention is not a protocol. Doug On Mon, Apr 17, 2023, 9:01 AM Dotzero <dotz...@gmail.com> wrote: > > > On Mon, Apr 17, 2023 at 4:30 AM Laura Atkins <la...@wordtothewise.com> > wrote: > >> Reading through the various discussions about how to document the harm >> DMARC causes for general purpose domains, I started thinking.One way that a >> lot of major SaaS providers have chose to deal with DMARC is spoofing their >> customer’s in the 5322.from Comment string. There are numerous examples of >> this: Paypal, Docusign, Sage, Intuit are 4 big examples I can think of off >> the top of my head. >> >> All of these companies send out financial or business mail on behalf of >> their customers, some of whom do use p=reject on their own domains. Some of >> them also use restrictive DMARC policies for this mail, others don’t. >> >> Is this another issue we should document and make recommendations about? >> I was thinking along the line that transactional SaaS providers should >> fully support DMARC and should not allow companies using p=reject in their >> business mail to access the service? >> > > Let's throw the baby out with the bath water. There are ways a > (transactional) domain owner can enable a vendor to generate/send email on > their behalf without the vendor "spoofing" the domain. A subdomain can be > delegated, private DKIM signing keys can be provided. Another approach is > routing outbound email from the vendor through the customer's mail > servers. In addition, dedicated sending IPs can be required by the > customer. My personal favorite is delegating a subdomain because all of the > obligations can easily be specified contractually. In the past when > potential vendors have said "we don't do that" or "we can't do that" and > I've said "then we can't consider you in our vendor election process", it's > amazing how quickly they figure out how to do things if there is enough > money on the table. I speak from experience. > > If enough people insist then vendors will productize these approaches into > their offerings more generally. It's a competitive differentiator until > enough vendors have offerings, at which time it will become the ante to > play in the game. So no, suggesting that the only solution is vendors > rejecting business from customers who publish p=reject is pretty much a > non-starter. > > >> >> I keep going back and forth that this is not an interoperability issue - >> the mail works fine even when the business is spoofed in the 5322.from >> comment string. But on a practical level it looks exactly like phishing >> mail because it’s financial (or contractual) docs from a particular company >> coming from a random domain. I keep ending up this isn’t an >> interoperability issue, it’s just an end run around DMARC and it’s not the >> IETF’s place to comment on that. >> > > I could see a discussion in a BCP as to why it's a bad practice. I don't > see it having a place in a standard. > > Michael Hammer > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
