Doug, since of dawn of electronic messaging, a system local policy always prevails. When implementing the new SMTP filters such as SPF, the more powerful policy was one of detecting failure. The PASS meant nothing since it may not pre-empt any other checking. For us, wcSPF was the exception in the wcSMTP suites of filters out of the box:
- Low Code Reject/Access rules - DNS-RBL - SPF - CBV SPF would pre-empt the final CBV check for a matching source (pass). An SPF Hard Fail is an immediate 550 rejection response. A unknown continues with the CBV check. When it comes to DKIM, we calculate all the valid signatures. When it comes to a DKIM Policy Model - well, we have DMARC. We apply the protocol rules without exceptions. If a Local System does not honor the results for any reason, that is ok. But I don’t think it can define a consistent Local Policy OverRide and expect systems to use same local overrides. Again, my Philosophy has been Failure Detection as the key filtering strength for all the DKIM Policies explored. A PASS or worst unknown/neutral means nothing because good and bad can both apply. Another “Trust” Layer is considered at the local level. All the best, Hector Santos > On Mar 15, 2024, at 1:46 AM, Douglas Foster > <dougfoster.emailstanda...@gmail.com> wrote: > > DMARC is an imperfect tool, as evidenced by the mailing list problem, among > others. DMARCbis has failed to integrate RFC7489 with RFC 7960, because it > provides no discussion of the circumstances where an evaluator should > override the DMARC result. I believe DMARCbis needs a discussion about the > appropriate scope and characteristics of local policy. I have developed an > initial draft of proposed language for that section, which appears below > > Doug Foster > > > x. Exceptions / Local Policy > > A DMARC disposition policy communicates the domain owner’s recommendation for > handling of messages which fail to authenticate. By definition, this > recommendation cannot take into consideration the local interest of specific > receivers, or the specific flow path of any specific message. As a result, > evaluators should anticipate the need to implement local policy exceptions > that override the DMARC recommended disposition when appropriate. These > exceptions can be considered in two groups: policy overrides and > authentication overrides. This section discusses some expected override > scenarios, without intending to be comprehensive, so that product > implementers can create appropriate exception structures for these and > similar possible situations. > > x.1 Policy Overrides > > x.1.1 Override p=none > > A disposition policy of “none” indicates that the domain owner suspects that > some evaluators may receive some legitimate and wanted messages which lack > authentication when received. The evaluator may reasonably conclude that > its risk of allowing a message which maliciously impersonates the domain is > much greater than the risk of hindering a legitimate-but-unauthenticated > message from the domain. In such cases, the local policy will override > p=none and handle the domain with p=quarantine or p=reject. > > x.1.2 Override missing PSL=Y > > Some PSDs have implemented DMARC policies in accordance with RFC 9901, > without a PSL tag because that RFC assumed that organizational domain > determination would be provided by the PSL. Particularly during the early > rollout of this specification, evaluators should use the PSL to identify > DMARC policies which are intended to be treated as PSL=Y even though the > PSD’s policy has not yet been updated to include the PSD=Y tag. > > x.1.3 Override strict alignment > > A domain may publish aspf=s or adkim=s incorrectly, which the evaluator will > detect when legitimate and wanted messages produce a DMARC Fail result, even > though they would produce Pass using relaxed alignment. In this case, the > evaluator overrides the strict alignment rules in the published policy and > applies a local policy of relaxed alignment. > > x.2 Authentication Overrides > > An Authentication Override provides alternate authentication when a message > is acceptable but the DMARC algorithm produces a result of Fail. To ensure > that the exception does not create a vulnerability, the rule should include > at least one verified identifier with a value that indicates the trusted > message source, often coupled with unverified identifiers with specific > values the further narrow scope of the rule. > > x.2.1 Mailing List messages > > Mailing Lists typically add content to the Subject or Body, and replace the > Mail From address, while forwarding a message. As a result, the > RFC5322.From address of the author can no longer produce SPF Pass or DKIM > Pass. If list messages are received directly, without secondary forwarding, > an exception rule can typically use the Mail From address of the list coupled > with a result of SPF Pass on that address. If the message is received after > secondary forwarding, the rule might be based on a DKIM signature matching > the list domain and a List-ID header with the list identity. The specific > parameters will vary based on the list characteristics and the message flow > between the list and the evaluator. > > x.2.2 SPF Distrust > > SPF Pass is designed on the assumption that a submitting server does not have > multiple tenant domains, or does not allow domain tenants to impersonate each > other. Some shared tenancy environments have difficulty ensuring that this > assumption is valid, weakening trust in a result of DMARC Pass based on SPF > Pass. When an evaluator has determined that messages from a particular > domain are reliably signed, and that the SPF policy includes an environment > with weak controls, the evaluator may implement a local policy to reject or > quarantine unsigned messages from that domain, even if the messages produce > SPF PASS > > x.2.3 Non-malicious impersonators > > Some legitimate network services provide services to individual clients from > many domains, and generate messages on behalf of those individual clients > using the client’s email address. These messages fail DMARC authentication > because they originate outside control of the client’s domain owner. While > the intent of DMARC is to encourage such services to identify their email > differently, not all legitimate senders have done so. As with Mailing List > messages, an evaluator will typically need to replace DMARC authentication > with a local policy which allows the message based on Mail From address, SPF > Pass, and the acceptable RFC5322.From domains to which the rule applies. > > > _______________________________________________ > 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
