Re: [dmarc-ietf] DMARC is designed to break mail, Example of Indirect Mail Flow Breakage with p=reject?
On Thu, 13 Apr 2023, Dotzero wrote: It also isn't that " IT DOES NOT MATTER IF YOUR MAIL GETS LOST". It matters but there is a calculus regarding the tradeoffs of a very small percentage (in the case of my former a very small fraction of a percent) of email not getting delivered vs the damage caused to recipients of malicious emails involving direct domain abuse. ... Well, yes, I oversimplified a little for effect. In your case, you know all the places that should be sending mail with your name on it, no random third party ESPs or mailing lists, and you know who should be getting it. So if a trickle ends up at mailing lists or ticketing systems or any of the other things that munge messages on the way through, you don't care about that trickle. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC is designed to break mail, Example of Indirect Mail Flow Breakage with p=reject?
On Wed, Apr 12, 2023 at 9:41 AM John R Levine wrote: > On Tue, 11 Apr 2023, Neil Anuskiewicz wrote: > > If DMARC can protect domains from spoofing which I believe ends up > > costing over $14 billion per year. Forget about the $14 billion and > > think how this crime spree affects people’s view > > But it obviously can't do that, and what it does do happens at > considerable cost. > The claim that DMARC protects against spoofing has never been made by the originators of DMARC. We have always been careful that it only addresses direct domain abuse. > > I don't know where that $14B number came from but I am reasonably sure > someone pulled it out of his, er, hat. WHen people talk abbout > "spoofing", they might mean exact domain impersonation or they might mean > lookalikes, or as likely as not mail where the body impersonates someone > and the From address is totally unrelated since, as Dave Crocker often > reminds us, most users don't look at the return address and a lot of mail > software doesn't even show it. DMARC only addresses one modest part of > that. > > If you are someone like Paypal or a big bank, and you have full control > over all the routes of your mail, AND IT DOES NOT MATTER IF YOUR MAIL GETS > LOST, p=reject makes sense. The farther from that you are, the less sense > it makes and the higher the costs you impose on other people. People > chronically forget the capitalized part when thinking about the tradeoffs. > Nobody has full control over all the routes email will take. How does the emitting domain know that a recipient hasn't set up forwarding from one account to another or that a recipient address isn't an exploder or alias representing multiple recipients at multiple domains? It also isn't that " IT DOES NOT MATTER IF YOUR MAIL GETS LOST". It matters but there is a calculus regarding the tradeoffs of a very small percentage (in the case of my former a very small fraction of a percent) of email not getting delivered vs the damage caused to recipients of malicious emails involving direct domain abuse. In one example of direct domain abuse, the malicious actors copied and pasted from real transactional emails and inadvertently included tracking code.Over the course of 48 hours over 180,000 people clicked on the malicious link before the site hosting the malicious content was shut down. And that was all from receiver domains that were not validating DMARC. And again, the original intent of DMARC was mitigating direct domain abuse involving transactional emails. We recognized the tradeoffs involved but to say it didn't (and doesn't) matter if such transactional email gets lost is a gross exaggeration. > > Michael Hammer > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC is designed to break mail, Example of Indirect Mail Flow Breakage with p=reject?
I note that you didn't write "MUST NOT". I heartily concur with "shouldn't" or SHOULD NOT. I still have issues with "MUST NOT". Keep in mind that MUST NOT doesn't mean "do this and you will die", it means "do this and you won't interoperate" which seems exactly correct here. SHOULD NOT means that you have external reasons to believe that you'll interoperate anyway, which doesn't seem right here, unless your plan is to send mail from your p=reject only to people with whom you have private whitelisting agreements. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC is designed to break mail, Example of Indirect Mail Flow Breakage with p=reject?
On Wed, Apr 12, 2023 at 9:41 AM John R Levine wrote: > > When we say that mail systems that don't fit the DMARC threat profile > shouldn't publish DMARC policies, we have good reasons to say so, and > that's what our standards need to say if we're serious about > interoperating. > > R's, > John > " ...shouldn't publish DMARC policies..." I note that you didn't write "MUST NOT". I heartily concur with "shouldn't" or SHOULD NOT. I still have issues with "MUST NOT". Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC is designed to break mail, Example of Indirect Mail Flow Breakage with p=reject?
> On Apr 12, 2023, at 9:41 AM, John R Levine wrote: > > When we say that mail systems that don't fit the DMARC threat profile > shouldn't publish DMARC policies, we have good reasons to say so, and that's > what our standards need to say if we're serious about interoperating. > With DMARCbis, If domains MUST NOT publish p=reject is mandated for certain classes of domain mail, then it should also apply to MUST NOT honor p=reject as a recommendation for verifiers. If so, - Should MDA receivers ignore sender p=reject for local users? - Should MLM strip the submission security (From rewrite)? — HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC is designed to break mail, Example of Indirect Mail Flow Breakage with p=reject?
On Tue, 11 Apr 2023, Neil Anuskiewicz wrote: If DMARC can protect domains from spoofing which I believe ends up costing over $14 billion per year. Forget about the $14 billion and think how this crime spree affects people’s view But it obviously can't do that, and what it does do happens at considerable cost. I don't know where that $14B number came from but I am reasonably sure someone pulled it out of his, er, hat. WHen people talk abbout "spoofing", they might mean exact domain impersonation or they might mean lookalikes, or as likely as not mail where the body impersonates someone and the From address is totally unrelated since, as Dave Crocker often reminds us, most users don't look at the return address and a lot of mail software doesn't even show it. DMARC only addresses one modest part of that. If you are someone like Paypal or a big bank, and you have full control over all the routes of your mail, AND IT DOES NOT MATTER IF YOUR MAIL GETS LOST, p=reject makes sense. The farther from that you are, the less sense it makes and the higher the costs you impose on other people. People chronically forget the capitalized part when thinking about the tradeoffs. There are lots and lots of examples of real costs that DMARC imposes on real people that have nothing to do with mailing lists. I used to handle the mail for my local town government. Many of the users asked me to forward their town addresses to Gmail acounts. In 2020 I noticed in my logs that mail from the US Census Bureau was getting lost due to DMARC rejects when I forwarded it. The Census had implemented DMARC in the cheapest possible way, a bunch of SPF records and no DKIM. Losing that mail was a big deal -- this was in preparation for the 2020 census enumeration, and towns care deeply about that since a decade of revenue sharing depends on the census count. Once I noticed the rejects, I knew that the least bad workaround was to have Google pull the mail, so I had to spend time setting up mailboxes for everyone, spend more time explaining to my users what the problem was, and spend their and my time walking them through and checking the setup on their end. This is all actual costs imposed on actual people, none of which would have been needed if the Census just deleted their DMARC record. Maybe they're a phish target, but the way they treated DMARC as a checklist item suggests not. Or there's Yahoo and AOL, who used DMARC to force the costs of their own security failures on the rest of the Internet. (See many previous messages for details.) When we say that mail systems that don't fit the DMARC threat profile shouldn't publish DMARC policies, we have good reasons to say so, and that's what our standards need to say if we're serious about interoperating. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
