On Wed, Apr 7, 2021 at 8:04 AM Douglas Foster < [email protected]> 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. > > 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. > > > I'm of the opinion that you're overthinking things, and that you're trying to bolt things onto DMARC that don't need to be bolted onto DMARC. The purpose of DMARC is simple. It attempts to establish the authenticity of the claimed identity of the RFC5322.From domain, and does this by requiring either an aligned pass verdict for SPF or an aligned pass verdict for DKIM. The results of DMARC validation checks usually lead to one of three paths: 1. If the domain is proven authentic through these checks, then I, as the receiver of the message, can reliably add this message to the set of data points that I maintain that make up the domain's reputation (for whatever that means) and I can reliably apply local policy rules to that message based on that domain's accumulated reputation. 2. If the domain publishes a DMARC policy and the message fails DMARC checks, I can use the policy record, if I choose, as input into the message handling decision that I ultimately make. 3. If the domain doesn't publish a DMARC policy record, then I've got less information to go on for the message, and so I'm likely to focus on the source IP's reputation, unless my own internal systems are so sophisticated and robust enough for me to track reputation data for unauthenticated traffic. We haven't yet reached a point in the ecosystem where "no auth, no entry" is in widespread adoption, and so lack of a DMARC record is not likely to be a reason to reject a message. DMARC is just a data point to add to other data points that ultimately determine what handling a given message will receive. At some sites, I'd posit that the majority of inbound messages never make it to the DMARC check stage, because the messages are rejected prior to the issuance of the DATA command. If I were still engaged in the operations side of email, especially at a mailbox provider, I personally would see no need to log anything about the results of the MX/A/AAAA check, whether it's done for RFC5321.From or RFC5322.From. The mail system would be constructed such that the fact that the message was accepted was in itself evidence that an MX and/or A/AAAA record existed for the domain; note that this probably wouldn't be the only acceptance criteria, but it would be one of them. While my decision to include this as an acceptance criteria may be a common one, I don't think it rises to the level of standard; I think it is better labeled a BCP. Also worth noting is that I haven't worked in email operations since 2010, long before RFC 7489 was published, but I was doing the MX and A/AAAA checks back then, so if there's interest in documenting the practice, it might be better documented in the latest updates to RFCs 5321 and 5322 and any associated applicability statements that the emailcore working group is doing. I think that requiring that the MX/A/AAAA address match the Source IP address class is perhaps a bridge too far; third-party ESPs employed by many larger senders aren't typically in the business of handling inbound mail for their customers, and so you're likely to see a lot of diversion, especially for checks done on RFC5322.From addresses. For example: washingtonpost.com. 43200 IN TXT "v=spf1 ip4:198.72.14.0/23 ip4: 192.72.255.0/24 ip4:54.156.98.51 ip4:54.210.51.17 include: spf.protection.outlook.com include:madgexjb.com include: spf-001a3c01.pphosted.com include:amazonses.com -all" washingtonpost.com. 3600 IN MX 10 mxa-001a3c01.gslb.pphosted.com. washingtonpost.com. 3600 IN MX 10 mxb-001a3c01.gslb.pphosted.com. As for the overall validity of the MX or A/AAAA record, specifically does it point to something that is reachable and willing to accept mail for the domain in question, that's what periodic inspection of one's own queues and bounce logs are for. If one notices that a significant amount of mail destined for a remote domain isn't leaving your platform, and troubleshooting doesn't rectify the problem, and it appears that the domain in question is one that's sending unwanted mail, one can always block the offending domain as a matter of local policy on the grounds that it's mail is unwanted and can't be responded to. Accepting mail that can't be replied to due to the remote site not answering isn't a problem that DMARC is designed to diagnose or solve, though. -- *Todd Herr* | Sr. Technical Program Manager *e:* [email protected] *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 [email protected] https://www.ietf.org/mailman/listinfo/dmarc
