On December 21, 2021 12:05:35 PM UTC, Alessandro Vesely <[email protected]> wrote:
>On Mon 20/Dec/2021 18:41:25 +0100 Scott Kitterman wrote:
>> On Monday, December 20, 2021 12:39:15 PM EST Alessandro Vesely wrote:
>>> On Sun 19/Dec/2021 21:42:16 +0100 Scott Kitterman wrote:
>>> > If the domain owner has suggested that you reject mail from a sub-domain
>>> > that has none of A, AAAA, or MX records, why would you not do that?
>>> Are we sure that's what the domain owner meant to suggest?
>>> 
>>> An organization can use sp= on its root domain record, or it can define a
>>> DMARC record at some subdomains.  So far so good.
>>> 
>>> Then it turns out that one can also define DMARC record at some non-existing
>>> sub domains, possibly as an alternative to using np=...  Now this begins to
>>> look puzzling.
>>> 
>>> The reason to introduce np= was to select domains that really don't exist. 
>>> Why don't we stick to that definition?
>> 
>> What definition are you wondering why we didn't stick to?
>
>
>Real non-existence.  I'm not sure how to define it formally, because it would 
>be exorbitant to require to try everything.  On the other hand an application 
>probably tried to authenticate SPF, DKIM, and DMARC already.  If any of those 
>record was found, then it's silly to even lookup A/ AAAA/ MX for the purpose 
>to 
>determine if the domain exists.

I don't remember exactly why we settled on A/ AAAA/ MX, but the lack of a 
clear, actionable definition is why we included one. Lack of DNS records 
related to email authentication only means lack of email authentication, which 
is in no way required.  Given the way most systems are typically architected, 
by the time you are doing email authentication, A or AAAA and MX will already 
be in the local cache, so this is a pretty inexpensive thing to check.

Scott K

_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to