Re: [dmarc-ietf] Additions to introduction
On Sun 05/Dec/2021 04:23:45 +0100 Scott Kitterman wrote: On December 4, 2021 10:09:48 PM UTC, Seth Blank wrote: On Sat, Dec 4, 2021 at 1:34 PM Tim Wicinski wrote: I am Ok with adding text of this nature, and I think it's helpful in explaining to folks approaching DMARC for the first time. But I start to lose focus on reading long introductions (okay boomer). >>> Maybe the Intro could get a section or two to help focus it. I am glad to assist wordsmithing Doug's comments if that is useful. as an individual, I don't like the wording that Doug has provided at all. I think I understand what he's trying to say, but the text as proposed is far more confusing than clarifying. Further, with SPF and DKIM, it is explicit that you can treat a pass in certain ways, but that you are to make no such determination when the authentication method does not pass. But DMARC is explicitly about providing policy when the auth methods do not validate in an aligned manner. So, while we all know there are legitimate reasons such validation might fail, this language feels out of place in DMARC because addressing these failures is the purpose of the protocol. As chair, if the group believes some clarification is still needed here, that makes sense and follows from similar text in the other auth methods. My ask would be that it provides clarity to address operational matters, per the charter for this phase of work. I don't think marketing materials belong in the document. If you want to give an overview about utility and usage of DMARC, then it should be something about it being super useful and low risk for automated transactional email, but there are substantial false positive risks for email sent from people. From a practical POV, a filter can reject or pass a message. So quarantine means pass but with Authentication-Results pointing out the fact, so that local delivery scripts can take are of it. What I would add, perhaps in an appendix, is the usefulness of a domain database that the filter leans on. Besides feeding aggregate reports, a database allows users to dynamically enable/ disable DMARC per domain, as well as to whitelist or kill-on-sight specific domains. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Additions to introduction
On December 4, 2021 10:09:48 PM UTC, Seth Blank wrote: >On Sat, Dec 4, 2021 at 1:34 PM Tim Wicinski wrote: > >> >> I am Ok with adding text of this nature, and I think it's helpful in >> explaining to folks approaching >> DMARC for the first time. But I start to lose focus on reading long >> introductions (okay boomer). >> >> Maybe the Intro could get a section or two to help focus it. >> >> I am glad to assist wordsmithing Doug's comments if that is useful. >> >> tim >> > >as an individual, I don't like the wording that Doug has provided at all. I >think I understand what he's trying to say, but the text as proposed is far >more confusing than clarifying. > >Further, with SPF and DKIM, it is explicit that you can treat a pass in >certain ways, but that you are to make no such determination when the >authentication method does not pass. But DMARC is explicitly about >providing policy when the auth methods do not validate in an aligned >manner. So, while we all know there are legitimate reasons such validation >might fail, this language feels out of place in DMARC because addressing >these failures is the purpose of the protocol. > >As chair, if the group believes some clarification is still needed here, >that makes sense and follows from similar text in the other auth methods. >My ask would be that it provides clarity to address operational matters, >per the charter for this phase of work. I don't think marketing materials belong in the document. If you want to give an overview about utility and usage of DMARC, then it should be something about it being super useful and low risk for automated transactional email, but there are substantial false positive risks for email sent from people. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Additions to introduction
On Sat, Dec 4, 2021 at 1:34 PM Tim Wicinski wrote: > > I am Ok with adding text of this nature, and I think it's helpful in > explaining to folks approaching > DMARC for the first time. But I start to lose focus on reading long > introductions (okay boomer). > > Maybe the Intro could get a section or two to help focus it. > > I am glad to assist wordsmithing Doug's comments if that is useful. > > tim > as an individual, I don't like the wording that Doug has provided at all. I think I understand what he's trying to say, but the text as proposed is far more confusing than clarifying. Further, with SPF and DKIM, it is explicit that you can treat a pass in certain ways, but that you are to make no such determination when the authentication method does not pass. But DMARC is explicitly about providing policy when the auth methods do not validate in an aligned manner. So, while we all know there are legitimate reasons such validation might fail, this language feels out of place in DMARC because addressing these failures is the purpose of the protocol. As chair, if the group believes some clarification is still needed here, that makes sense and follows from similar text in the other auth methods. My ask would be that it provides clarity to address operational matters, per the charter for this phase of work. Seth > > > > > On Sat, Dec 4, 2021 at 4:25 PM Murray S. Kucherawy > wrote: > >> On Sat, Dec 4, 2021 at 9:55 AM John Levine wrote: >> >>> The point of a spec is to tell people how to interpoerate. I don't see >>> how this >>> contributes to that. >>> >> >> Lots of specifications include informative guidance or best practices >> advice as well as normative specification. DKIM has loads of it. >> >> -MSK >> ___ >> 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 > -- *Seth Blank * | Chief Product Officer *e:* s...@valimail.com *p:* 415.273.8818 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] Additions to introduction
I am Ok with adding text of this nature, and I think it's helpful in explaining to folks approaching DMARC for the first time. But I start to lose focus on reading long introductions (okay boomer). Maybe the Intro could get a section or two to help focus it. I am glad to assist wordsmithing Doug's comments if that is useful. tim On Sat, Dec 4, 2021 at 4:25 PM Murray S. Kucherawy wrote: > On Sat, Dec 4, 2021 at 9:55 AM John Levine wrote: > >> The point of a spec is to tell people how to interpoerate. I don't see >> how this >> contributes to that. >> > > Lots of specifications include informative guidance or best practices > advice as well as normative specification. DKIM has loads of it. > > -MSK > ___ > 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
Re: [dmarc-ietf] Additions to introduction
On Sat, Dec 4, 2021 at 9:55 AM John Levine wrote: > The point of a spec is to tell people how to interpoerate. I don't see > how this > contributes to that. > Lots of specifications include informative guidance or best practices advice as well as normative specification. DKIM has loads of it. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Additions to introduction
It appears that Douglas Foster said: >-=-=-=-=-=- > >I propose that a paragraph along these lines be inserted into the >introduction: > >The DMARC test is characterized by a one-tailed error distribution: > Messages which pass verification have a low probability of being false >positives of actual impersonation. When a recipient intends to exempt a >high-value sender from content filtering, identity verification ensures >that such special treatment can be done safely, without concern for >impersonation.However, the same cannot be said about verification >failures. Verification failures can occur for many reasons, and many such >messages will be safe and desired by the recipient. Messages which do not >verify are optimally handled with manual review, but this may not be >feasible due to message volume.DMARC provides a way for senders and >receivers to safely cooperate to minimize the probability that automated >disposition decisions will be suboptimal. The point of a spec is to tell people how to interpoerate. I don't see how this contributes to that. Also, as we have found from the past several years of argument, the last sentence is simply wrong. In some cases DMARC lets you make correct decisions, in others it does not/ R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Additions to introduction
After I sent this, I wondered if I needed to add more text to explain that "manual review" means "manual review, followed by local policy changes, so that manual review will no longer be necessary on messages with the same identifiers." If a reader thinks "manual review" means "look at every message individually, now and forever," the reader will laugh it off. But in an introduction, we cannot say everything. So I am open to suggestions. I can say with some confidence that the false-positive problem is not understood in most of the commercial product market. I shopped for a commercial product by asking this question, "Example.com moved to Office365, but did not update their SPF record. How do I treat their Office365 messages as SPF-PASS without enabling impersonation from other sources?" I found many that could not answer. Vendors do not understand that an "allow" override for sender-authentication must mimic the original: Start with a trusted identifier that is also verified, then use it to authenticate an unverified identifier which has an expected value and is received in the same message. This type of rule has three parts (independent identifier, verification mechanism, and dependent identifier), most of the products that I surveyed could only implement single-part rules. Single-part rules work well for message blocking, because a distrusted identifier generally remains untrusted in all contexts and is untrusted whether true or spoofed. But using them for allow rules can undermine security. This text introduces the concept that when an automated process applies a uniform disposition to a mix of wanted and unwanted messages, the results will always be suboptimal. The only way to achieve optimal results is to perform a manual review and classification. Since unverified messages must also pass filters based on source reputation and content, the expected consequences of allowed impersonation is low. Consequently, this draft assumes that the automation will only block sender authentication failure when the probability of a true impersonation has reached a high value. I think this assumption should be made explicit somewhere in the document. Doug Foster On Sat, Dec 4, 2021 at 1:52 AM Murray S. Kucherawy wrote: > On Fri, Dec 3, 2021 at 6:16 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> I propose that a paragraph along these lines be inserted into the >> introduction: >> >> The DMARC test is characterized by a one-tailed error distribution: >> Messages which pass verification have a low probability of being false >> positives of actual impersonation. When a recipient intends to exempt a >> high-value sender from content filtering, identity verification ensures >> that such special treatment can be done safely, without concern for >> impersonation.However, the same cannot be said about verification >> failures. Verification failures can occur for many reasons, and many such >> messages will be safe and desired by the recipient. Messages which do not >> verify are optimally handled with manual review, but this may not be >> feasible due to message volume.DMARC provides a way for senders and >> receivers to safely cooperate to minimize the probability that automated >> disposition decisions will be suboptimal. >> > > I have no objection to adding text such as this. It's worth noting, > though, that DKIM certainly says this already (at least in its Section > 6.1), SPF probably says something similar, and DMARC clearly depends on > those. DMARC alludes to this in RFC 7489, Section 10.5, but it's not as > explicit as what's proposed here. > > -MSK > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Additions to introduction
On Fri, Dec 3, 2021 at 6:16 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I propose that a paragraph along these lines be inserted into the > introduction: > > The DMARC test is characterized by a one-tailed error distribution: > Messages which pass verification have a low probability of being false > positives of actual impersonation. When a recipient intends to exempt a > high-value sender from content filtering, identity verification ensures > that such special treatment can be done safely, without concern for > impersonation.However, the same cannot be said about verification > failures. Verification failures can occur for many reasons, and many such > messages will be safe and desired by the recipient. Messages which do not > verify are optimally handled with manual review, but this may not be > feasible due to message volume.DMARC provides a way for senders and > receivers to safely cooperate to minimize the probability that automated > disposition decisions will be suboptimal. > I have no objection to adding text such as this. It's worth noting, though, that DKIM certainly says this already (at least in its Section 6.1), SPF probably says something similar, and DMARC clearly depends on those. DMARC alludes to this in RFC 7489, Section 10.5, but it's not as explicit as what's proposed here. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Additions to introduction
I propose that a paragraph along these lines be inserted into the introduction: The DMARC test is characterized by a one-tailed error distribution: Messages which pass verification have a low probability of being false positives of actual impersonation. When a recipient intends to exempt a high-value sender from content filtering, identity verification ensures that such special treatment can be done safely, without concern for impersonation.However, the same cannot be said about verification failures. Verification failures can occur for many reasons, and many such messages will be safe and desired by the recipient. Messages which do not verify are optimally handled with manual review, but this may not be feasible due to message volume.DMARC provides a way for senders and receivers to safely cooperate to minimize the probability that automated disposition decisions will be suboptimal. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
