>> The reason an evaluator expends compute cycles on validation is to >> meet their own needs, which are to accept messages that they want and >> block messages that they do not want. Source filtering is the most >> important part of that process. > > Sure, but in the absence of a published DMARC policy, you're assuming > facts not in evidence. If a domain owner publishes a DMARC policy, > they're theoretically saying that they're trying to make sure they're > properly authenticating all their mail (if p=none) or that they're > pretty sure (p=quarantine) or very sure (p=reject) that they're > properly authenticating their mail. You are free to do whatever you > wish with any inbound message, even flat out reject if there's no > DMARC policy; I just don't see the point in trying to do any extra > work to perform DMARC validation if no policy can be found.
More to the point, even, I don't know what "DMARC validation" *is* in the absence of a published DMARC policy. Whatever validation one wants to perform at that point is not DMARC. Before DMARC existed, SPF and DKIM were used as they are specified, and the results of those authentications were used as part of a recipient domain's decision of how to handle the message. That's still the case now, and DMARC adds an ability for the sending domain to advise the recipient domain about its signing policy. *That* is DMARC. >> The market has already rejected the narrow definition of DMARC. > > Please cite your sources for this claim. Indeed: what I see is pretty decent adoption of DMARC, given its non-standard status at this point. Barry _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
