Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy
On Thu 06/Jan/2022 22:50:42 +0100 John Levine wrote: It appears that Alessandro Vesely said: On Thu 06/Jan/2022 12:32:17 +0100 Douglas Foster wrote: I perceive a false assumption that when a sender does not publish p=reject, then his messages cannot be blocked for failure to validate, and therefore DKIM signatures are unnecessary. Or we could devise a protocol whereby a sender can supply customized policies to different (kinds of) receivers. But that wouldn't be DMARC, so please, let's stop. I'd say customized policies are non-feasible rather than non-DMARC. On the opposite side, enabling DMARC at the receiver, I have a per-domain setup which I think is handy and useful. However, per-domain policies are not feasible because 1) they would break existing base and 2) would be too complicated to set up effectively. I mentioned that (non-) possibility as a brainstorming means to foster thinking about per- kind of receiver policies (see p=validate, for example). Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy
On Thu, Jan 6, 2022 at 8:12 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Protocols are created to solve a problem, and solution design should > include both normal operation and failure management.That’s why > electrical panels use circuit breakers instead of simple on-off switches. > > In this current case, we are defining an access control system for email, > so we have easy parallels with an access control system for doors. The > core protocol defines how the badge is formatted, how the reader > interrogates the badge, and how it interprets the response. But the > solution is much more. The solution needs to include a way to cope with > employees who forgot their badges, badges that don’t work, guests who do > not have a badge, solenoids that don’t open doors when the badge reads > successfully, the emergency exit path if there is a fire, and probably > other things. > > Mailing list messages can be considered equivalent to an employee who > arrives at work without his badge. Assume that an organization wants to > trust mailing list messages from IETF.ORG. How is this accomplished? > My analysis says that there are ways to do this right and ways to do this > wrong. I have seen an abundance of wrong implementations. Defining how > to do it right is an example of failure management. I do not believe that > it is irrelevant to the protocol; rather it should be an integral part of > it. > I think if you extend that logic to its conclusion, the core protocol for email should contain DKIM, SPF, DMARC, maybe MIME, maybe greylisting, DNSXLs, and a host of other things. It would be massive. I would wager that the manual for the badge readers at your place of work or mine probably doesn't talk about what policy you should have for employees who forget badges, handling of guests, emergency exits, or most of the other things you listed. How could it possibly know the right answers to such questions? I'm sure at least for reasons of liability, they are tightly scoped, and such things are left to the purview of the customer who has full context of how the reader is going to be used. Since the email ecosystem evolves, parts are added over time and other parts become obsolete, best practices evolve with new usage, etc., it's more agile for us to be crisp in separating protocol from advice. We commonly publish protocol specifications in Standards Track documents and then include advice of the sort you're advocating in Informational documents. This also allows us to evolve the advice text separately from the protocol documents when doing so is warranted. It also means the protocol can advance toward publication while we might still be haggling about the advice part. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy
Protocols are created to solve a problem, and solution design should include both normal operation and failure management.That’s why electrical panels use circuit breakers instead of simple on-off switches. In this current case, we are defining an access control system for email, so we have easy parallels with an access control system for doors. The core protocol defines how the badge is formatted, how the reader interrogates the badge, and how it interprets the response. But the solution is much more. The solution needs to include a way to cope with employees who forgot their badges, badges that don’t work, guests who do not have a badge, solenoids that don’t open doors when the badge reads successfully, the emergency exit path if there is a fire, and probably other things. Mailing list messages can be considered equivalent to an employee who arrives at work without his badge. Assume that an organization wants to trust mailing list messages from IETF.ORG. How is this accomplished? My analysis says that there are ways to do this right and ways to do this wrong. I have seen an abundance of wrong implementations. Defining how to do it right is an example of failure management. I do not believe that it is irrelevant to the protocol; rather it should be an integral part of it. Doug On Thu, Jan 6, 2022 at 9:03 PM Murray S. Kucherawy wrote: > On Thu, Jan 6, 2022 at 3:32 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> There are good reasons for talking about a default DMARC policy. It is >> certainly not to give evaluators permission, because we know that >> evaluators can do whatever they want, and they will do what they deem to be >> in their best interest. >> >> The point of a specification like this is to understand each >> participant's best interest and channel that toward the common goal. I >> perceive a false assumption that when a sender does not publish p=reject, >> then his messages cannot be blocked for failure to validate, and therefore >> DKIM signatures are unnecessary. Your question about "none" equaling >> "ignore" comes across that way."None" means that the sender provides no >> guidance, it does not mean that the message cannot be blocked because of >> sender authentication failure. >> > > I'm not sure I agree with the second paragraph's assertion. > > DMARC, or any protocol specification really, is about interoperability > between two participants. In DMARC's case, that's a sender and a > receiver. When a policy is published, the receiver has asked the sender's > DNS for that information, received a reply, and put it to use in the DMARC > evaluation machine; the protocol has been followed. However, when no > policy is published, or in the errant case where multiple policies are > published, the protocol cannot be said to have completed, since there was > no interaction between the sender and the receiver. > > Similarly, the notion of a default DMARC policy suggests that when no > policy is published, the receiver has some means to assert "I think I know > what you probably would want" and then completes the protocol on that > basis. But there's been no interoperability here; no interoperable > protocol has been executed. It's on the same basis that Scott earlier said > Best-Guess SPF is not SPF. > > It IS in the interest of an evaluator to apply the DMARC test to every >> message, so I believe it is in the interest of the specification to >> acknowledge that likelihood. If someone in the group believes that it is >> contrary to an evaluator's best interest, we need to discuss and document >> that risk also. >> > > I suggest that this might be the kind of advice we float in a Best Current > Practices document or similar, if that's the consensus opinion, but not in > the protocol itself. At a minimum, I suggest that it should be informative > text, and certainly not mandatory. > > -MSK, participating > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy
On Thu, Jan 6, 2022 at 3:32 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > There are good reasons for talking about a default DMARC policy. It is > certainly not to give evaluators permission, because we know that > evaluators can do whatever they want, and they will do what they deem to be > in their best interest. > > The point of a specification like this is to understand each participant's > best interest and channel that toward the common goal. I perceive a false > assumption that when a sender does not publish p=reject, then his messages > cannot be blocked for failure to validate, and therefore DKIM signatures > are unnecessary. Your question about "none" equaling "ignore" comes > across that way."None" means that the sender provides no guidance, it > does not mean that the message cannot be blocked because of sender > authentication failure. > I'm not sure I agree with the second paragraph's assertion. DMARC, or any protocol specification really, is about interoperability between two participants. In DMARC's case, that's a sender and a receiver. When a policy is published, the receiver has asked the sender's DNS for that information, received a reply, and put it to use in the DMARC evaluation machine; the protocol has been followed. However, when no policy is published, or in the errant case where multiple policies are published, the protocol cannot be said to have completed, since there was no interaction between the sender and the receiver. Similarly, the notion of a default DMARC policy suggests that when no policy is published, the receiver has some means to assert "I think I know what you probably would want" and then completes the protocol on that basis. But there's been no interoperability here; no interoperable protocol has been executed. It's on the same basis that Scott earlier said Best-Guess SPF is not SPF. It IS in the interest of an evaluator to apply the DMARC test to every > message, so I believe it is in the interest of the specification to > acknowledge that likelihood. If someone in the group believes that it is > contrary to an evaluator's best interest, we need to discuss and document > that risk also. > I suggest that this might be the kind of advice we float in a Best Current Practices document or similar, if that's the consensus opinion, but not in the protocol itself. At a minimum, I suggest that it should be informative text, and certainly not mandatory. -MSK, participating ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy
It appears that Alessandro Vesely said: >On Thu 06/Jan/2022 12:32:17 +0100 Douglas Foster wrote: >> The point of a specification like this is to understand each >> participant's best interest and channel that toward the common goal. >> I perceive a false assumption that when a sender does not publish >> p=reject, then his messages cannot be blocked for failure to validate, >> and therefore DKIM signatures are unnecessary. > >Or we could devise a protocol whereby a sender can supply customized policies >to different (kinds of) receivers. But that wouldn't be DMARC, so please, let's stop. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy
On January 6, 2022 9:34:44 PM UTC, Douglas Foster wrote: >Please explain what you think is wrong and why. We are not voting yet, we >are discussing. This being the IETF, we aren't voting. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy
What is the basis of your conviction that everyone knows how to use SPF and DMARC validation properly? It ceased to be my perception when I tried to buy an email filtering product that implements DMARC. Doug On Thu, Jan 6, 2022 at 11:07 AM John Levine wrote: > It appears that Murray S. Kucherawy said: > >I would argue that it's well understood by now that DKIM and SPF "pass" > >results are the only things that convey usable information. > > I agree. I've never seen anyone have any trouble figuring out what SPF or > DKIM inputs to feed into DMARC and don't see anything to change here. > > R's, > John > > ___ > 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] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy
Please explain what you think is wrong and why. We are not voting yet, we are discussing. On Thu, Jan 6, 2022 at 11:18 AM Dave Crocker wrote: > On 1/6/2022 3:32 AM, Douglas Foster wrote: > > Consequently, the best way for senders to avoid delayed or blocked > > messages is to avoid getting close examination. This is facilitated > > by ensuring messages are both DKIM-verifiable and SPF-PASS, regardless > > of DMARC policy. P=NONE or T=Y or no policy are not valid substitutes. > > > That's doubly and impressively wrong. > > > d/ > > -- > Dave Crocker > dcroc...@gmail.com > 408.329.0791 > > Volunteer, Silicon Valley Chapter > Information & Planning Coordinator > American Red Cross > dave.crock...@redcross.org > > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy
On Thu 06/Jan/2022 12:32:17 +0100 Douglas Foster wrote: The point of a specification like this is to understand each participant's best interest and channel that toward the common goal. I perceive a false assumption that when a sender does not publish p=reject, then his messages cannot be blocked for failure to validate, and therefore DKIM signatures are unnecessary. Or we could devise a protocol whereby a sender can supply customized policies to different (kinds of) receivers. For example, I might want to publish p=reject for, say, ietf.org and some other receivers that I trust to verify correctly. Queries could be arranged similar to external reporting authorization, exposing the receiver's FQDN: ; <<>> DiG 9.16.1-Ubuntu <<>> ietfa.amsl.com._dmarc.tana.it txt ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58470 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;ietfa.amsl.com._dmarc.tana.it. IN TXT ;; ANSWER SECTION: _dmarc.tana.it. 86400 IN TXT "v=DMARC1; p=reject; " "rua=mailto:dmarca...@tana.it; " "ruf=mailto:dmarcf...@tana.it;; Hm... no fooling. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy
On 1/6/2022 3:32 AM, Douglas Foster wrote: Consequently, the best way for senders to avoid delayed or blocked messages is to avoid getting close examination. This is facilitated by ensuring messages are both DKIM-verifiable and SPF-PASS, regardless of DMARC policy. P=NONE or T=Y or no policy are not valid substitutes. That's doubly and impressively wrong. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy
>> Consequently, the best way for senders to avoid delayed or blocked >> messages is to avoid getting close examination. This is facilitated by >> ensuring messages are both DKIM-verifiable and SPF-PASS, regardless of >> DMARC policy. P=NONE or T=Y or no policy are not valid substitutes. ... No. Just no. This isn't mission creep, it's mission gallop. DMARC is not a magic bullet to divide good mail from bad mail and we would do nobody any favors by going down this path. DMARC does what it does, and I really do not want to start opining about the way other parts of a mail system should work. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy
It appears that Murray S. Kucherawy said: >I would argue that it's well understood by now that DKIM and SPF "pass" >results are the only things that convey usable information. I agree. I've never seen anyone have any trouble figuring out what SPF or DKIM inputs to feed into DMARC and don't see anything to change here. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy
On Thu, Jan 6, 2022 at 6:32 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > There are good reasons for talking about a default DMARC policy. It is > certainly not to give evaluators permission, because we know that > evaluators can do whatever they want, and they will do what they deem to be > in their best interest. > > The point of a specification like this is to understand each participant's > best interest and channel that toward the common goal. I perceive a false > assumption that when a sender does not publish p=reject, then his messages > cannot be blocked for failure to validate, and therefore DKIM signatures > are unnecessary. Your question about "none" equaling "ignore" comes > across that way."None" means that the sender provides no guidance, it > does not mean that the message cannot be blocked because of sender > authentication failure. > > As an evaluator, EVERY message that does not validate is a potential > impersonation threat, and therefore needs close inspection. Inspection > may produce these outcomes: > - quarantine, manual review, and release, which produces temporary delay, > - quarantine which expires before manual review, producing the same effect > as a block > - manual review which determines that the source sends harmless but > unwanted advertising, resulting in a permanent block on the sender. > - manual review which confirms that the message contains unacceptable > impersonation, resulting in a permanent block on the sender. > > Consequently, the best way for senders to avoid delayed or blocked > messages is to avoid getting close examination. This is facilitated by > ensuring messages are both DKIM-verifiable and SPF-PASS, regardless of > DMARC policy. P=NONE or T=Y or no policy are not valid substitutes. > > It IS in the interest of an evaluator to apply the DMARC test to every > message, so I believe it is in the interest of the specification to > acknowledge that likelihood. If someone in the group believes that it is > contrary to an evaluator's best interest, we need to discuss and document > that risk also. > > I believe there is merit to what you've written here, but I don't think these ideas belong in the DMARC protocol specification but instead in a separate document. Within the IETF, it's my understanding that an Applicability Statement might be a better place for advice on how best to implement a protocol and what impacts various choices may have. Outside of the IETF, there is literature already that describes best practices for email authentication for senders, intermediaries, and receivers; here is a link to one such document - https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.h...@valimail.com *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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy
There are good reasons for talking about a default DMARC policy. It is certainly not to give evaluators permission, because we know that evaluators can do whatever they want, and they will do what they deem to be in their best interest. The point of a specification like this is to understand each participant's best interest and channel that toward the common goal. I perceive a false assumption that when a sender does not publish p=reject, then his messages cannot be blocked for failure to validate, and therefore DKIM signatures are unnecessary. Your question about "none" equaling "ignore" comes across that way."None" means that the sender provides no guidance, it does not mean that the message cannot be blocked because of sender authentication failure. As an evaluator, EVERY message that does not validate is a potential impersonation threat, and therefore needs close inspection. Inspection may produce these outcomes: - quarantine, manual review, and release, which produces temporary delay, - quarantine which expires before manual review, producing the same effect as a block - manual review which determines that the source sends harmless but unwanted advertising, resulting in a permanent block on the sender. - manual review which confirms that the message contains unacceptable impersonation, resulting in a permanent block on the sender. Consequently, the best way for senders to avoid delayed or blocked messages is to avoid getting close examination. This is facilitated by ensuring messages are both DKIM-verifiable and SPF-PASS, regardless of DMARC policy. P=NONE or T=Y or no policy are not valid substitutes. It IS in the interest of an evaluator to apply the DMARC test to every message, so I believe it is in the interest of the specification to acknowledge that likelihood. If someone in the group believes that it is contrary to an evaluator's best interest, we need to discuss and document that risk also. Doug On Tue, Jan 4, 2022 at 10:32 AM Murray S. Kucherawy wrote: > On Mon, Dec 27, 2021 at 8:33 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> I suggest the language should be more like this: >> >> If the set produced by the DNS Tree Walk contains no DMARC policy record >> (i.e., any indication that there is no such record as opposed to a >> transient DNS error), Mail Receivers MAY choose to proceed with the DMARC >> mechanism using a default alignment of "relaxed" and a default policy >> recommendation of "NONE". >> >> > This seems to me to be exactly the sort of thing Best Guess SPF tried to > do, and we've rejected that notion. To paraphrase, this would not be > DMARC, but an action taken unilaterally by a receiver. There's no > interoperation at the DMARC level happening here. > > Moreover, if the default you're applying is "none", isn't that the same as > ignoring the message anyway? > > -MSK, just participating > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy
On Tue, Jan 4, 2022 at 4:53 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > [...] > The PASS-centric approach is the only one that makes sense to me. This is > why I have lobbied for changes to the introduction to explicitly state that > FAIL is an ambiguous result. If you accept that PASS-centric is the goal, > then using default policies becomes the necessary way of coping with > missing information. > I would argue that it's well understood by now that DKIM and SPF "pass" results are the only things that convey usable information. You know something about a message that passes; when they fail, the algorithm itself can't tell you what the exact nature of the failure is. Section 6.3 of RFC 6376 spends some time discussing this. I think in DMARC, a strong policy is a tacit expression that the domain posting that policy understands the narrow but meaningful nature of the "pass" cases of those protocols, and only wants participating receivers to deliver messages within that definition. But if we believe that's not implicit or made clear by the document as-is, or if the industry at large has missed this point, then sure, we could say so here. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy
There are two possible approaches to DMARC. One approach says that FAIL should be reliably true, and non-FAIL for any reason is ambiguous. This means that domain owners should only publish a reject policy when there is no possibility that their messages pass through mailing list or any other path that drops authentication. It also means that they should not publish "reject" if there is any possibility of an "acceptable" impersonation. This is why John says that it is an abuse of DMARC to publish reject for anything other than transaction-only domains. If this approach could be done successfully, it would provide a very limited benefit. But it seems clear from this discussion that FAIL has too many false positives, so the concept has already failed. The opposite approach is to say that PASS is reliably true, and that non-PASS is ambiguous. As I have said before, PASS is very useful to make whitelisting safe, and to identify messages that are free of impersonation risk. I need to worry about impersonation risk whether the sender has no dmarc policy, a "none" policy, or a "reject" policy that oversimplifies reality. Consequently, I classify all messages as either "PASS" (free of impersonation risk") or "non-PASS" (some impersonation risk"). The goal is to supplement DMARC with local policy until the ambiguity is gone - messages from acceptable source are unambiguously PASS, and messages from unacceptable sources are blacklisted. At last check, this approach allowed 85% of my messages to be classified as passing sender authentication. I continue to work on whittling down the remaining 15%. The PASS-centric approach is the only one that makes sense to me. This is why I have lobbied for changes to the introduction to explicitly state that FAIL is an ambiguous result. If you accept that PASS-centric is the goal, then using default policies becomes the necessary way of coping with missing information. Doug On Tue, Jan 4, 2022 at 10:32 AM Murray S. Kucherawy wrote: > On Mon, Dec 27, 2021 at 8:33 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> I suggest the language should be more like this: >> >> If the set produced by the DNS Tree Walk contains no DMARC policy record >> (i.e., any indication that there is no such record as opposed to a >> transient DNS error), Mail Receivers MAY choose to proceed with the DMARC >> mechanism using a default alignment of "relaxed" and a default policy >> recommendation of "NONE". >> >> > This seems to me to be exactly the sort of thing Best Guess SPF tried to > do, and we've rejected that notion. To paraphrase, this would not be > DMARC, but an action taken unilaterally by a receiver. There's no > interoperation at the DMARC level happening here. > > Moreover, if the default you're applying is "none", isn't that the same as > ignoring the message anyway? > > -MSK, just participating > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy
On Mon, Dec 27, 2021 at 8:33 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I suggest the language should be more like this: > > If the set produced by the DNS Tree Walk contains no DMARC policy record > (i.e., any indication that there is no such record as opposed to a > transient DNS error), Mail Receivers MAY choose to proceed with the DMARC > mechanism using a default alignment of "relaxed" and a default policy > recommendation of "NONE". > > This seems to me to be exactly the sort of thing Best Guess SPF tried to do, and we've rejected that notion. To paraphrase, this would not be DMARC, but an action taken unilaterally by a receiver. There's no interoperation at the DMARC level happening here. Moreover, if the default you're applying is "none", isn't that the same as ignoring the message anyway? -MSK, just participating ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy
This question is about this paragraph: 5.7.2.1. DMARC Policy Discovery If the set produced by the DNS Tree Walk contains no DMARC policy record (i.e., any indication that there is no such record as opposed to a transient DNS error), Mail Receivers SHOULD NOT apply the DMARC mechanism to the message. Whether a DMARC policy is missing or NONE, the test can be performed successfully, using default alignment of relaxed. Both PASS and FAIL results can be useful to the evaluator, and a savvy evaluator will choose to do so. If a particular author's messages are trusted to be safe and wanted, the sender may be configured to bypass content filtering. This disposition is only free of impersonation risk when the sender identity has been validated. A result of DMARC PASS provides this assurance. If a test produces DMARC FAIL, this does not demonstrate that the message is malicious or unwanted, but it may be a reason to prioritize the message for review, so that local policies can be updated to ensure that the authorship of future messages can be assessed unambiguously. I suggest the language should be more like this: If the set produced by the DNS Tree Walk contains no DMARC policy record (i.e., any indication that there is no such record as opposed to a transient DNS error), Mail Receivers MAY choose to proceed with the DMARC mechanism using a default alignment of "relaxed" and a default policy recommendation of "NONE". If PSDs embrace the PSD flag, a missing DMARC flag should become a rare event. This may indicate a fraudulent TLD, so I think we also need to document that possibility. The right way to do test for a fraudulent TLD depends on my earlier question of whether all TLDs have implemented DNS SEC. If so, non-existent TLDs will return NXDOMAIN in response to a query on the TLD name, while valid TLDs will return NOERROR or DATA. Doug Foster ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
