Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language

[Alessandro Vesely <[e-mail]>]

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 [e-mail].  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
--