Re: [dmarc-ietf] NXDOMAIN

[Todd Herr <[e-mail]>]

On Wed, Apr 7, 2021 at 8:04 AM Douglas Foster <
[e-mail]> 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:* [e-mail]
*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.