Re: [dmarc-ietf] DMARC exceptions
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 > 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
Re: [dmarc-ietf] DMARC exceptions
On Friday, March 15, 2024 10:15:55 AM EDT Todd Herr wrote: > On Fri, Mar 15, 2024 at 1:47 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 disagree with your premise, and I submit that it is not the role of the > IETF, DMARCbis, or any third party to determine either characteristics or > appropriate scope for a policy that is local to a Mail Receiver. > > A Mail Receiver's goal is to make sure that its mailbox holders receive > wanted mail while minimizing the amount of unwanted mail that's accepted, > and how they work to achieve that goal is solely their purview. > > DMARC authentication results can and probably do inform their work, but > they're just one piece of data for doing so. Their work will also be > informed by many other data points, some of which we know (historical > mailbox holder engagement with a given mail stream) and some of which we > don't know, and they adjust their handling decisions all the time based on > whatever signals they deem important. > > I believe that this paragraph in the Introduction section of DMARCbis > concisely describes DMARC to Mail Receivers: > > 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 not required to do so; it might choose > different actions entirely. > > > I further believe that the description of the 'p' tag and of its possible > values of 'none', 'quarantine', and 'reject' in section 5.3, General Record > Format, are enough to help the Mail Receiver understand how reliable the > Domain Owner believes its authentication practices to be and, along with > everything else the Mail Receiver knows about the sending domain, the > source of the mail stream, etc., etc., how much weight can be assigned to a > failed DMARC authentication result for that domain. I agree. Let's move on. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC exceptions
On Fri, Mar 15, 2024 at 1:47 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 disagree with your premise, and I submit that it is not the role of the IETF, DMARCbis, or any third party to determine either characteristics or appropriate scope for a policy that is local to a Mail Receiver. A Mail Receiver's goal is to make sure that its mailbox holders receive wanted mail while minimizing the amount of unwanted mail that's accepted, and how they work to achieve that goal is solely their purview. DMARC authentication results can and probably do inform their work, but they're just one piece of data for doing so. Their work will also be informed by many other data points, some of which we know (historical mailbox holder engagement with a given mail stream) and some of which we don't know, and they adjust their handling decisions all the time based on whatever signals they deem important. I believe that this paragraph in the Introduction section of DMARCbis concisely describes DMARC to Mail Receivers: 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 not required to do so; it might choose different actions entirely. I further believe that the description of the 'p' tag and of its possible values of 'none', 'quarantine', and 'reject' in section 5.3, General Record Format, are enough to help the Mail Receiver understand how reliable the Domain Owner believes its authentication practices to be and, along with everything else the Mail Receiver knows about the sending domain, the source of the mail stream, etc., etc., how much weight can be assigned to a failed DMARC authentication result for that domain. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com Phone: 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DMARC exceptions
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
