To supplement Oliver's reply, and Doug's question, most commercial secure email gateways are capable of this in terms of granular inbound email authentication customization. (Proofpoint, Mimecast, Cisco, Barracuda, etc.)
- Mark Alley On Thu, Jul 20, 2023, 4:15 AM OLIVIER HUREAU < [email protected]> wrote: > 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) > 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 > > 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) > 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" <[email protected]> > *À: *"Dotzero" <[email protected]> > *Cc: *"IETF DMARC WG" <[email protected]> > *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 <[email protected]> wrote: > >> >> >> On Wed, Jul 19, 2023 at 6:21 PM Douglas Foster < >> [email protected]> 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 <[email protected]> wrote: >>> >>>> It appears that Barry Leiba <[email protected]> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/dmarc >>>> >>> _______________________________________________ >>> dmarc mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/dmarc >>> >> > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
