Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs
> On Mar 15, 2024, at 9:40 AM, Alessandro Vesely wrote: > > On Fri 15/Mar/2024 02:34:15 +0100 Murray S. Kucherawy wrote: >>> On Fri, Mar 15, 2024 at 9:11 AM John Levine wrote: >>> It appears that Todd Herr said: >>> >I agree that clarifying it can't hurt, obviously, ... >>> >>> I disagree, it does hurt. >>> >>> If we say you're allowed to use CNAMEs to point to DMARC records, >>> people are to say uh oh, is there something special here? What about >>> DKIM records? what about SPF records? how about SPF includes? or SPF >>> redirects? >>> >>> Really, there is nothing to say here, so let's not say it. >>> >> +1, I don't understand what needs to be clarified here. If I ask for a TXT >> record at a given name, I expect to get one back (or a non-success code). >> It really doesn't matter to DMARC whether that process traversed a CNAME >> record in the process. (Or if it does matter, I've yet to see a reason >> why.) > > > +1, people who know DNS can derive the possibility to use CNAME on their own. > Those who don't are better off not trying it. It’s mostly ESP’s with large customer bases that ask for CNAMES, providing them with scalability, and the ability to rotate keys. It’s the appropriate choice in some contexts. Why is this a concern of the WG? Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs
On Fri 15/Mar/2024 02:34:15 +0100 Murray S. Kucherawy wrote: On Fri, Mar 15, 2024 at 9:11 AM John Levine wrote: It appears that Todd Herr said: >I agree that clarifying it can't hurt, obviously, ... I disagree, it does hurt. If we say you're allowed to use CNAMEs to point to DMARC records, people are to say uh oh, is there something special here? What about DKIM records? what about SPF records? how about SPF includes? or SPF redirects? Really, there is nothing to say here, so let's not say it. +1, I don't understand what needs to be clarified here. If I ask for a TXT record at a given name, I expect to get one back (or a non-success code). It really doesn't matter to DMARC whether that process traversed a CNAME record in the process. (Or if it does matter, I've yet to see a reason why.) +1, people who know DNS can derive the possibility to use CNAME on their own. Those who don't are better off not trying it. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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
Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)
On Thu 14/Mar/2024 20:23:01 +0100 John Levine wrote: It appears that Scott Kitterman said: SPF it treated in multiple places. We cannot warn against a bad practice in one place (135) and recommend it unconditionally in another (132). That is exactly how one handles Security Considerations. So 132 says do SPF. Security Considerations gives you stuff to think about how you do SPF. There's not need to embed mitigations for the considerations throughout the draft (someone with more IETF experience than me, please correct me if I'm wrong about this). If you're going to provide implementation advice for SPF, which I still think is a bad idea, security considerations is indeed the least bad place to do it. I agree. The point here is not to give a questionable MUST. Telling people they MUST grant a pass to /every/ source is questionable, isn't it? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
