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.
As best I can tell, return-path-check does not have a unique name, specified result status codes, or a specific SMTP reject result code. At the simplest level, possible results are PASS, FAIL, TEMPERROR and PERMERROR. A more complex result set would probably be desirable for A-R, to indicate which entity produced the pass, which address class was used for the match, whether the match also resolved to the Source IP, and the Source IP itself. Other specification details include clarifying whether the MX/A/AAA address result must match the Source IP address class (presumably yes), and whether the result list should test for and reject addresses that are in the Private, Multicast, or Reserved lists (probably optional) 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. Doug Foster On Tue, Apr 6, 2021 at 12:58 PM Murray S. Kucherawy <superu...@gmail.com> wrote: > On Tue, Apr 6, 2021 at 4:54 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> If the SPF Policy lookup returns NXDOMAIN, then we are at a full stop >> with all the information needed to make a decision. (The sender is >> violating ICANN name registration policies). Ignoring NXDOMAIN and >> continuing to look for MX/A/AAAA is a waste of information and a waste of >> resources. >> > > I agree. > > But clearly, the norm in this group is to check MX/A/AAA because it seems >> likely to be a more powerful filter. I wonder if that is actually true. >> > > In the context of the code doing the SPF evaluation, I don't think it is. > If TXT returns NXDOMAIN for a name, so will any other type. That's the > definition of NXDOMAIN; there are no data of any type for this name. See > also RFC 8020. Fortunately, a properly functioning local nameserver will > cache the answer and just repeat it when subsequent MX, A, or AAAA queries > get issued, so the waste is relatively cheap. > > I imagine some DNS APIs are ambiguous (i.e., lazy) about reporting "That > name does not exist (rcode=NXDOMAIN)" differently from "That name exists, > but there's no record of the type you requested (rcode=NOERROR, > ancount=0)", which can result in some wasted time, but I expect the end > result would be the same. > > 1) A/AAAA is a pretty weak test, since many domains have A/AAAA records >> on the domain name for web purposes. >> > > Independently of SPF, it's not a weak test since the standards allow > exactly this kind of setup for a domain that wants to receive mail. Again, > Section 5.1 of RFC 5321. > > I do respond to SPF NONE by applying a best-guess SPF policy which >> includes MX and A, and sometimes produces SPF PASS. But I no longer do >> that for non-existent domains. >> > > "Best guess SPF" is discouraged. See > http://www.open-spf.org/FAQ/Best_guess_record/. > > -MSK >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
