On Wed, Jul 19, 2023 at 6:21 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote:
> Perhaps you can clarify what you think DMARC is. > > Apparently a significant number of evaluators think that "DMARC Fail with > p=reject always means unwanted mail". Or to use Michael Hammer's > language, "DMARC Fail with p=reject means the domain owner wants it > rejected so I will reject it." These are exactly the attitudes that > cause us so much trouble because (a) DMARC Fail with p=reject does not mean > that rejection is always the correct response, and (b) DMARC Fail with > p=none is an important piece of information. > You are misrepresenting my position by ignoring local policy. A DMARC policy of quarantine or reject is a request by the domain owner or administrator. While consideration of a sending domain's request should be given consideration, a receiving domain is free to do as it wishes. A receiving domain may choose not to implement DMARC validation at all. A sending domain may believe that the risk of some legitimate emails being rejected or quarantined is an acceptable tradeoff in order to protect itself and users/recipients. You appear to have a problem with these choices being made by both the sending domain and the receiving domain. Why do you presume to know better than they as to what they should do? Certainly, if I publish a policy of p=reject and a receiver allows an email that should have been rejected to reach their user/customer and that person contacts me because that message caused them a problem, I'm going to tell them they need to speak with their mail administrator, mailbox provider, etc. I've done that in the past and I'll do it in the future. What others choose to do is their choice. While I may have an opinion, I recognize that it is their choice. > > We have only two ways to block unwanted messages: Identify unwanted and > malicious messages based on the sender, or based on the content. > Impersonation interferes with the sender reputation assessment, so we know > that attackers have an incentive to impersonate. Sender Authentication > provides information about messages that MIGHT be impersonations > because they are not authenticated. Fortunately, most messages can be > authenticated. > You are again misrepresenting what DMARC is and does. It is NOT a guessing game about whether a recipient might want a given email. It is a simple pass/fail that should be automated before a message ever (potentially) gets to a recipient. It may be as simple as the message took an unintended or unexpected path which potentially creates risks from the perspective of the sending domain. DMARC knows nothing about whether email is wanted or unwanted on the receiving side of the mailstream. It knows nothing about reputation. DMARC is not a substitute for other filtering or reputation systems. DMARC is not a Swiss Army knife, was never intended to be one, nor is it appropriate to pretend you can contort it into one. I absolutely agree with John regarding his comments and agree with his sentiment of " I am so tired of people imagining that DMARC is more than it is." Michael Hammer > > Doug > > > > > On Wed, Jul 19, 2023 at 5:32 PM John Levine <jo...@taugh.com> wrote: > >> It appears that Barry Leiba <barryle...@computer.org> said: >> >> - An attacker sends 10 messages that maliciously impersonates a >> >> big bank. With help from DMARC p=reject, the evaluator blocks >> >> them all. The attacker follows up with 10 messages that >> >> maliciously impersonate a major university. The stupid >> >> evaluator says, "p=none means no problem here". The message is >> >> accepted and the user is harmed because the evaluator learned >> >> nothing from blocking the successful attack. >> > >> >This is a useful point, and I think we should do something with it. >> >> Sorry, but I completely disagree. >> >> The interesting filtering data is that a bunch of unauthenticated mail >> arrived from some source. As we have learned over and over, someone's >> DMARC policy tells you nothing about the threat level or whether the >> failure is an attack or a mailing list, only that someone decided for >> whatever reason to publish p=reject. >> >> If a source sends a burst of unauthenticated mail, it could often be a >> good idea to give that source a poor reputation. Or maybe you have a >> reason to believe otherwise, e.g., it's been sending bursts of >> unauthenticated mail for years, nobody's ever marked it as spam, >> because it's some kind of courtesy forward. >> >> Note that you would do exactly the same thing if the burst of >> unauthenticated university mail preceded the burst of bank mail. It's >> the authentication failure that tells you that there may be a problem, >> not the DMARC policy. >> >> Mail filtering is complicated, so much so that handling the signals is >> more than a full time job at many mail systems. I expect that large >> mail systems have their own ideas abou who's a bank, who's a >> university, who's a public mail system, and so forth. You get exactly >> none of that from DMARC. After all, yahoo is p=reject, gmail and >> hotmail/outlook are p=none. >> >> I am so tired of people imagining that DMARC is more than it is. >> >> R's, >> John >> >> _______________________________________________ >> 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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
