On Wed, Jul 19, 2023 at 10:42 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote:
> Can you find a commercial product that can configure a rule which says, > "Don't worry about DMARC if Mail from = bounceaddtess@listdomain and the > MailFrom address produces SPF PASS"? > > Simple enough rule. If vendors understood what we want them to > understand, they would allow creation of multipe-attribute rules like this, > combining authentication results and identifier values, to provide local > authentication overrides. But they don't, or at least I have not found > one after diligently searching. > YOU keep on substituting "we" for "I" when YOU have not gained a consensus on what YOU want. YOU have not searched very diligently if you couldn't find a single vendor who can do what YOU want. As Olivier pointed out, Cisco AsyncOS can do this. I was an early customer of IronPort (when the company was still code named "GodSpeed" and that capability existed in the early 2000's, so even well before DMARC even existed. Another company product that has had that capability is MessageSystems and their Momentum servers. You'd have to write the rule in Lua. A very flexible implementation. The fact that YOU don't know something exists after "searching diligently" doesn't mean it doesn't exist. Perhaps asking the community yields results when "searching diligently" does not. > > On the other hand, finding products that block unconditionally on FAIL is > pretty easy. > > We need to find words in our document that begin to fix this, to obtain > the products and evaluator behavior that we both want and their users need. > YOU are again substituting "we" for "I". You have also wandered from writing a protocol to telling people how they (actually YOUR preference) should implement their operational choices for local policy. Trying to dictate local policy choices is a losing proposition. Trying to dictate to vendors YOUR policy choices is also a losing proposition. Local policy choices != protocol. Michael Hammer > Doug > > On Wed, Jul 19, 2023, 8:07 PM Dotzero <dotz...@gmail.com> wrote: > >> >> >> 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
