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 [email protected]. 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
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
