I test every message for SPF, aligned SPF, and aligned verified DKIM. With one exception mentioned below, I don't block on FAIL, but I do collect data.
Most legitimate messages produce at least SPF, many messages have DKIM signatures. I receive very little forwarded mail. So most messages pass DMARC tests naturally. Then I tailor my local policies to reflect my message stream, For example, I trust ConstantContact and SendGrid to present accurate identification of their clients. They get a local policy which says everything they send counts as equivalent to DMARC PASS, whether signed or not. This approach solves the Girl Scout troop mass mailing problem that John raised a long time ago. Those types of filter rules add another 1% of domains and 2% of messages to the PASS category. Note that I trust SendGrid identities, not their clients. Any new domain arriving from SendGrid goes to Quarantine until I flag it as allowed or blocked. We have very little legitimate traffic from EDU domains, so when I saw a pattern of EDU impersonators, I added a rule to require PASS for *.EDU. After applying these edits, I have a bunch of stuff that is still FAIL. It has a high percentage of spam or all types. Periodically I do a log review and identify some domains and servers that need to be blocked, as well as some domains that need a special authentication rule so that I will not need to investigate the same identity issue again. I cannot imagine why I would give this up to only evaluate the domains that have given me permission via a DMARC policy. I think documenting this approach would help a lot of other evaluators and software developers. I get angry at products that think DMARC is a checkbox that you turn on or off -- just follow the RFC and block the FAILS. It doesn't work in reality, but it allows them to say that the product does DMARC. I assume a lot of ransomware attacks could be prevented if the product vendors understood the DMARC potential. Doug On Tue, Jan 18, 2022 at 3:38 PM Barry Leiba <[email protected]> wrote: > Maybe I'm misunderstanding what you mean by "testing every message", > so let me ask it this way: > > - A message says it's from [email protected] > - If you can authenticate that through DKIM or SPF, you have an > authenticated message from gloob.example.com. What do you do next, > and how does that relate to what DMARC specifies? > - If you can NOT authenticate that through DKIM nor SPF, DMARC says > you should look for a DMARC policy for gloob.example.com. I presume > you look for one, yes? > - If you find a policy, DMARC would have you follow it. Do you? > - If you do not find a policy, we're now outside the scope of current > DMARC. What do you do now? > > Maybe if we're misunderstanding this and you clarify it, some of us > might agree with you, so let's please try. > > Barry > > On Tue, Jan 18, 2022 at 3:27 PM Douglas Foster > <[email protected]> wrote: > > > > Alas, there is no convincing this group, but the missed opportunity is > so great:. By testing every message, I learn that 81% of domains and 93% > of messages are able to authenticate using DMARC rules. (Statistics taken > after sender reputation blocks have excluded the known offenders.) > Compare that to the 5% of domains that have any DMARC policy, and the tiny > subset of those that are enforceable. > > > > DF > > > > On Tue, Jan 18, 2022 at 1:25 PM Todd Herr <todd.herr= > [email protected]> wrote: > >> > >> On Tue, Jan 18, 2022 at 1:13 PM Douglas Foster < > [email protected]> wrote: > >>> > >>> Michael, you ducked the question. > >>> > >>> If a domain owner has a right to not participate in DMARC, why are we > removing that right with PSD policies? > >> > >> > >> I said in an earlier message in this thread that I did not understand > the tree walk to mean that PSD policies will rule if the org domain doesn't > publish one. Here's what I wrote: > >> > >> If the intent of the tree walk is, at least in part, to allow for > publishing of policy records at the PSD level and for those records to be > inherited by existing subdomains (e.g., _dmarc.tld is inherited by > domain.tld if domain.tld does not publish its own policy record) then I > have badly misunderstood the tree walk. If that's not the intent, then the > next rev of DMARCbis needs to make that more clear. > >> > >> > >> One of us is wrong in our understanding of the point of the tree walk, > and it very well could be me, but I think we need to get consensus here on > this point. > >>> > >>> > >>> Either participation is optional or it is not. Which is it? > >>> > >>> This right to not participate is based on an assumption that DMARC > will be used to block legitimate traffic. That fear is only justified > because we have been unwilling to document how DMARC should be used to > ensure appropriate dispositions. Failure to talk about failure > management has created the problem and we seem determined to perpetuate it > (even though failure management, as applied to mailing lists, was part of > our charter.) > >>> > >> > >> I submit that DMARCbis does say how DMARC should be used to ensure > appropriate dispositions, in the Introduction section: > >> > >> A DMARC pass indicates only that the RFC5322.From domain has been > >> authenticated for that message. Authentication does not carry an > >> explicit or implicit value assertion about that message or about the > >> Domain Owner. Furthermore, a mail-receiving organization that > >> performs DMARC verification can choose to honor the Domain Owner's > >> requested message handling for authentication failures, but it is > >> under no obligation to do so; it might choose different actions > >> entirely. > >> > >> For a mail-receiving organization supporting DMARC, a message that > >> passes verification is part of a message stream that is reliably > >> associated with the RFC5322.From field Domain Owner. Therefore, > >> reputation assessment of that stream by the mail-receiving > >> organization is not encumbered by accounting for unauthorized use of > >> that domain in the RFC5322.From field. A message that fails this > >> verification is not necessarily associated with the Domain Owner's > domain and its reputation > >> > >> > >> -- > >> > >> Todd Herr | Technical Director, Standards and Ecosystem > >> e: [email protected] > >> m: 703.220.4153 > >> > >> This email and all data transmitted with it contains confidential > and/or proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is prohibited > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > >> > >> _______________________________________________ > >> 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
