On Wed, Aug 3, 2022 at 8:42 PM Douglas Foster < [email protected]> wrote:
> Consider: A message has a verified DKIM or SPF domain which exactly > matches the RFC5322.From domain. > > In this case, the only applicable information in a policy record is the > reporting address(es). But the specification does not require evaluators > to send reports and does not require domain owners to request reports, so > these three situations are functionally equivalent: > > 1) The reporting address is not used because the evaluator does not send > reports. > 2) The reporting address is not used because the policy does not provide > an address. > 3) The reporting address is not used because a policy has not been > published. > > However, our specification says that for the third option, the evaluator > must ignore the exact-match verification and therefore treat the message as > having authentication status "unknown". This makes no sense. > I think you meant "none". There's no "unknown" status registered that I can see (if I'm wrong, please point me at it). The reason "none" is there is because according to Section 4.5 the first thing you do is see if there's a published policy for the From domain. If there is not, you don't need to figure out if the DKIM or SPF domains were aligned, because it doesn't matter; the algorithm stops there, and "none" is the result. It might be weird to say "pass" for a domain not participating in DMARC. > More generally, I object to any imposition of "must" on an evaluator. His > only "must" is to act in his own best interest to protect himself from > harm. Ignoring obviously favorable data is not in his interest. > "MUST" applies to you if you want to interoperate with another participant according to the specification. In theory, if you don't do all the MUSTs, your implementation may not work well with others. For example, in SMTP, you MUST end your lines with CRLF, or the other end probably won't understand you. There's no advantage to not doing so. Those MUSTs seem appropriate to me. Another possible interpretation I've seen: If you don't do what the MUSTs say, whatever you're doing isn't DMARC. But that's a compliance argument, not an interoperability one. The policy part of DMARC works fine at both ends if there's no reporting; in that sense, the notion that one MUST produce reports is harder to defend. On the other hand, if you opt to generate reports, you MUST use the format being specified (so the other end can reliably decode them). That also seems fine to me. -MSK, participating
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
