On December 5, 2021 9:54:42 PM UTC, Douglas Foster
<[email protected]> wrote:
>It is a relief to finally have this topic open for discussion. The issues
>go deeper than null MX.
>
>The goal is to domain names that the domain owner never uses for
>RFC5321.From addresses. No direct test exists, so there are two candidate
>substitutes:
>- (Relaxed:) A name is rejected if it does not exist in DNS, so a lookup
>returns NXDOMAIN. An example would be "[email protected]"
>- (Strict:) The name is not used for SPF mail. An example would be "
>[email protected]"
>
>There are problems with either of these, so a domain which intends to
>publish an np=reject policy will need to take measures to ensure compliance
>before publishing an NP=REJECT policy.
>
>The MX/A/AAAA test is a version of the strict test, so it needs to be
>addressed first. The most obvious problem is the omission of SPF.
>There have been some assertions that SPF can be omitted because any domain
>which sends mail must be configured to also receive it. This is an
>assertion which is difficult to defend. A mail message can obtain both SPF
>PASS and DMARC PASS based on SPF alignment, without having a valid MX
>record. We are all receiving no-reply messages, so we should not be
>surprised at the existence of no-reply domains. Therefore the existence
>of a valid SPF record must be evidence that the domain exists for purposes
>of the Strict test.
>
>The second problem is the inclusion of A/AAAA as a test of SMTP usage. I
>suspect that there are relatively few DNS names which do not contain a host
>record, so including A/AAA in the strict version of an existence test is
>essentially reducing it to a relaxed test. But this is not necessary.
> We can assume that a domain which wants to use NP=REJECT is willing to
>exert some effort to make this test useful. Requiring domain owners to
>complete the migration from Implicit MX to Explicit MX is a very small ask
>with a very big payback. Therefore, A/AAAA should be dropped from the
>Strict test. Domains that do not wish to migrate to explicit MX can
>choose not to publish NP=REJECT.
>
>A third problem is the one that Scott introduced: If a domain has one or
>more MX records, but none of them can be resolved to a public IP address,
>then the existence of the MX record indicates that the name is NOT used for
>receiving mail. Similarly, an SPF record of "-ALL" indicates that the
>name is not used for sending mail. For purposes of the Strict test,
>invalid MX is equivalent to no MX, and SPF "-ALL" is equivalent to no SPF.
>
>The fourth problem involves domain names that are only used for mass
>mailings from service providers, where the service provider domain is used
>for SMTP. The FROM address domains on such mailings have no need to exist
>in DNS, and we have had no difficulty finding examples of this occurring.
> This problem affects both relaxed and strict tests. For domain owners
>with subdomains that fit this situation, we need to provide a way to create
>something in DNS which indicates that the domain exists for purposes of the
>DMARC NP test. Right now, we have no solution for them.
Nope. See RFC 5321, Section 5.1, paragraph 2 (implicit MX). DMARCbis needs to
be consistent with existing mail standards.
Scott K
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
