Scot raises a valid concern, which calls for a counterproposal, not an end to discussion. I can propose one, but I wonder what the group thinks.
Building on other comments, the strict needs this additional logic: DMARC Policy and the NP test ------------------------------------------ Existence of an exact-match DMARC record is definitely evidence that the domain name exists for purposes of the NP test. This is not an extra DNS lookup, since the tree walk has to occur every time anyway. The evaluator simply needs to remember whether an exact-match policy was found. A domain-level DMARC policy can solve my concern about domain names that are currently not in DNS but are used for mass mailings. The domain owner who wishes to enable the NP test must create a domain-level DMARC policy for any name that cannot satisfy the "existence" test by some other method. DKIM Public Keys and the NP test ---------------------------------------------- A domain also exists if a message has an unverified DKIM signature that (a) has a key published for the scope ID, and (b) is an exact-match for the mail domain name. Of course, If the signature verifies, the result will be DMARC PASS and the NP test will be ignored. If the signature does not have a public key, then the failed signature may be spoofed so it is ignored for purposes of the NP test. The name may still be non-existent I don't think there is any way to answer the more general question, "Does this domain have at least one DKIM public key?" Invalid Names ------------------- A PSD name is always invalid, with or without a DMARC policy found. A name where any segment starts with an underscore is always invalid, with or without a DMARC policy found. Doug Foster On Sun, Dec 5, 2021 at 7:01 PM Scott Kitterman <[email protected]> wrote: > > > 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 >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
