Thank you for asking. OK., I will use the term "email suffix" for the part of an email address that follows the @ character, and "DNS domain" for a name that appears in DNS as a domain object.
An email suffix can legitimately be associated with an A/AAAA resource record that is not a DNS domain. For example, an alarm monitoring system might send alarms using the server's host name as the email suffix (e.g. ala...@monitore.xample.com). MX and SPF can also be configured for Monitor.Example.Com even though it is not a DNS domain. This is specifically authorized by RFC 5321. A spoofed email address could use any email suffix, such as nots...@trickedyou.example.com. Our interest must extend beyond names that are in DNS. In my mailstream, most messages sent from mailing services use the mailing service domain for the SMTP address. This insures that the message produces SPF PASS. It also means that the FROM domain name has no necessary dependence on any DNS entry. It took me only one day to find examples of this;,non-existent subdomains used on legitimate messages sent by mailing services. The FROM suffix correctly reflects the parent organization, but the full email suffix does not appear in DNS. This situation means that we cannot distinguish between valid and invalid email suffixes using DNS alone, we must require domain owner signalling. How does a domain owner signal that @bounce.e.example.com is valid as a FROM domain, even though the name is only used for mailing service messages? Under the current draft, the domain owner must associate the name with an IP address using an MX, A, or SPF record, even though the name has no legitimate connection to the chosen IP address. I do not consider this acceptable. In the real world, I fear that implementing such a requirement will have unexpected consequences, and network administrators who share my fear will be reluctant to comply with our draft. I focused on SP and NP because it is the SP or NP policy which provides inheritance, Inheritance has to be the primary way that we defend against abuse of unused and non-existent email suffixes You asked a lot of questions. I think I should stop there and give you a chance to respond before going further. Doug Foster On Mon, Jun 14, 2021 at 7:12 AM Alessandro Vesely <ves...@tana.it> wrote: > Doug, > > maybe it's me, but I have problems understanding your proposal. Let me > quote > what seems to hamper my comprehension. > > Besides, #11 in the Subject: is obviously a typo. > > > On Sat 12/Jun/2021 14:55:33 +0200 Douglas Foster wrote: > > ties the design directly to the mailing list problem. > > > I couldn't see where mailing lists are taken into account. > > > > However,this authentication can be lost in transit if message > modification > > occurs in transit, as discussed in RFC 7960. This possibility can make > domain > > owners reluctant to move beyond sp=none. > > > Why do you consider SP irrespective of P? Actually, SP could be used by > "simple" mail sites, those which make no use of subdomains for email. In > such > cases, setting sp=reject can safely prevent generic abuses even for > domains > having p=none. It sounds similar to null SPF records for non-mail hosts. > > > > x.1 Implement mail domains as DNS domains with domain-level DMARC > policies. > > > > Mail domains are often implemented as DNS domains, but this is not > required. > > > Please, stick to well established jargon. Tim made a good synthesis in > section > 2.2 and ensuing ones. A /DNS domain/ is defined by RFC 1034: > > A domain is identified by a domain name, and consists of that part of > the domain name space that is at or below the domain name which > specifies the domain. > > In this sense, the concept of non-existing domain names that are > legitimately > used sounds like a contradiction in terms. > > > > Once all used mail domain names are configured as DNS domains, they can > be > > configured with DMARC policies. > > AFAICS, a /used mail domain name/ which is not a DNS name is a > /non-existent > domain/ found in some (forged) email addresses. I agree that such > practice > should be discouraged. Yet, that doesn't seem to be the point here... > > BTW, are there organizations that use non-existent (sub) domains during > the > delivery of legitimate messages? Years ago I saw sporadic mailing list > authors > forged like john....@nospamexample.com. Is that what you're talking > about? > > > > - For mail domain names that are not used with SMTP, a new TXT record is > > defined, with content "DMARCFROMv1". The presence of this TXT record > > indicates that the associated DNS domain, named DNS resource record, or > > wildcard DNS record should be considered as potentially in use as an > > RFC5322.From domain name. > > > Ok, that is clear, but, IMHO, won't work. Working MXes or IP addresses > are a > necessary condition to receive mail. Thus, a purist receiver has to > accept > such domains as valid. Therefore traditionalist domain operators will not > see > a compelling need to define any auxiliary TXT records. A new RR type of > this > kind would most probably be going to characterize mass mailers who hasten > to > adopt any new trick that seems to offer a chance to increase > deliverability. > Undoubtedly, someone would be tempted to discard senders based on that (as > it > happened to DKIM...) > > An organization which wants to say sp=reject but does use some email > subdomains > had better define plain DMARC records for them. Records can be easily > duplicated by CNAMEs. If we needed to vary some parts but not others, for > example a different policy but the same aggregate reporting address, we > should > define something equivalent to SPF's include. > > > > - For used domain names that are not in DNS at all, a DMARCFROMv1 TXT > record > > is needed to indicate that the name is used for mail. > > Actually, /any/ record definition will turn a domain into an existing one. > However, by Section 2.7 of PSD, which defines the MX/A/AAAA test, such > domain > would still be non-existing. In that sense, DMARCFROMv1 conflicts with > PSD. > > > > x,3 Implement SPF -ALL policies on unused names. > > > > Organizations that have configured SPF to protect their valid > RFC5321.MailFrom > > domains may not have taken the extra measure of using SPF to obstruct > names > > that are not used for mail. While not directly part of DMARC, an > > authentication result of "DMARC=NONE SPF=FAIL" is a more meaningful > result than > > "DMARC=NONE, SPF=NONE". Consequently, it is desirable to ensure > SPF=FAIL for > > any names that are never used as RFC5321.MailFrom domain names. Since > SPF has > > no inheritance, this requires many entries. > > > That's a well known SPF issue: > http://www.open-spf.org/FAQ/Common_mistakes/#all-domains > > There used to circulate scripts to generate null SPF records. It would > help if > DNS hosting services implemented a checkbox to carry out such task. But > this > if far OT. > > > Best > Ale > -- > > > > > > > > > > > > > > > > > > > > > > > > >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
