Further to what Todd said: On Wed, Apr 7, 2021 at 5:04 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote:
> I am hearing that we have a defacto standard to check return-path using > MX/A/AAAA. It is implemented with sufficient breadth,that (unlike SPF) > senders should consider it mandatory. Additionally, and more importantly > for this group, it is presumed to be equally applicable for validation of > the RFC5322.From, even though that address is unrelated to the > SMTP return-path. But because the test is not explicitly documented, some > products (my vendors) do not implement it at all, leaving a protection gap. > I think I'm confused about how this ties to DMARC. What you're describing is, I believe, a common anti-spam tactic that was in use even before SPF or DKIM were a thing. It probably still is, irrespective of those protocols. However, RFC 7489's Appendix A.4 points out that earlier versions of DMARC had such a test, but it was removed because of too many false negatives. > If DMARC is to be dependent on return-path-check and inter-dependent with > ARC, then I do not see how we can avoid producing a formal specification > for the test and integrating it into A-R, as a co-requisite to the DMARC > specification. > How is DMARC dependent on a return path check? SPF is, but DMARC isn't. DMARC only cares what the SPF result was, and whether the domain it evaluated is aligned with the RFC5322.From domain. In fact, a DMARC filter could operate correctly with no knowledge of what the return path was, provided the A-R fields are correct and complete. Another perspective: If the RFC5322.From domain doesn't exist, it's not possible for a DMARC policy to be discovered for it, nor is it possible that SPF or DKIM will pass for it or align to it. Therefore, is such a domain even in scope here, much less a need to describe a way to test it? -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
