Hi, > 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"?
The solution I can propose to you is using Cisco AsyncOS ( [ https://www.cisco.com/c/en/us/td/docs/security/esa/esa14-0/user_guide/b_ESA_Admin_Guide_14-0.html | https://www.cisco.com/c/en/us/td/docs/security/esa/esa14-0/user_guide/b_ESA_Admin_Guide_14-0.html ] ) software. Ciscos's solution does have Email authentication global settings where you can bypass the DMARC verification if the message contains a specific header. [ https://www.cisco.com/c/en/us/td/docs/security/esa/esa14-0/user_guide/b_ESA_Admin_Guide_14-0/b_ESA_Admin_Guide_12_1_chapter_010110.html#con_1225789 | https://www.cisco.com/c/en/us/td/docs/security/esa/esa14-0/user_guide/b_ESA_Admin_Guide_14-0/b_ESA_Admin_Guide_12_1_chapter_010110.html#con_1225789 ] Let's assume the header we are looking for is 'X-MAILFROM-SPF-PASS:TRUE' The idea is then to use the Message Filters features of AsyncOs to add a specific header using the action 'insert-header' You can then use the SPF-Status Rule ( [ https://www.cisco.com/c/en/us/td/docs/security/esa/esa14-0/user_guide/b_ESA_Admin_Guide_14-0/b_ESA_Admin_Guide_12_1_chapter_01000.html#con_1132105 | https://www.cisco.com/c/en/us/td/docs/security/esa/esa14-0/user_guide/b_ESA_Admin_Guide_14-0/b_ESA_Admin_Guide_12_1_chapter_01000.html#con_1132105 ] ) and EnvelopeFrom such as : overpass_dmarc_if_spf_mailfrom_pass: if (EnvelopeFrom == "bounceaddtess@listdomain" AND spf-status("mailfrom") == "Pass"){ insert-header("X-MAILFROM-SPF-PASS","TRUE") } I am not a Cisco expert but, to be confirmed. Regards, Olivier Hureau De: "Douglas Foster" <dougfoster.emailstanda...@gmail.com> À: "Dotzero" <dotz...@gmail.com> Cc: "IETF DMARC WG" <dmarc@ietf.org> Envoyé: Jeudi 20 Juillet 2023 04:41:57 Objet: Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it? 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. 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. Doug On Wed, Jul 19, 2023, 8:07 PM Dotzero < [ mailto:dotz...@gmail.com | dotz...@gmail.com ] > wrote: On Wed, Jul 19, 2023 at 6:21 PM Douglas Foster < [ mailto:dougfoster.emailstanda...@gmail.com | dougfoster.emailstanda...@gmail.com ] > wrote: BQ_BEGIN 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. BQ_BEGIN 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. BQ_END 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 BQ_BEGIN Doug On Wed, Jul 19, 2023 at 5:32 PM John Levine < [ mailto:jo...@taugh.com | jo...@taugh.com ] > wrote: BQ_BEGIN It appears that Barry Leiba < [ mailto:barryle...@computer.org | 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 [ mailto:dmarc@ietf.org | dmarc@ietf.org ] [ https://www.ietf.org/mailman/listinfo/dmarc | https://www.ietf.org/mailman/listinfo/dmarc ] BQ_END _______________________________________________ dmarc mailing list [ mailto:dmarc@ietf.org | dmarc@ietf.org ] [ https://www.ietf.org/mailman/listinfo/dmarc | https://www.ietf.org/mailman/listinfo/dmarc ] BQ_END BQ_END _______________________________________________ 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
