> On 17 Apr 2023, at 14:01, Dotzero <dotz...@gmail.com> wrote: > > > > On Mon, Apr 17, 2023 at 4:30 AM Laura Atkins <la...@wordtothewise.com > <mailto: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.
That would be why the first part of my statement was that SaaS providers should fully support DMARC. As in, they should have the ability to provide both SPF and DKIM alignment for customers to implement. Many of them don’t currently do that - and many of us aren’t a billion dollar company and get told “well, sorry, that’s simply not something we find important.” >> >> 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. Do you really think the IETF has no role in saying ‘if you send mail on behalf of other companies, you should be able to allow that company to authenticate their email in a DMARC compliant way?’ laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
