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

[Douglas Foster <[e-mail]>]

Below is my proposed language for dealing with the problems that NP is
intended to address:
- unused DNS names
- non-existent DNS names

It provides supporting rationale, and provides a more complete solution
than anything suggested previously, and ties the design directly to the
mailing list problem.

I have labelled the sections starting with "X," because I am not sure of
the best way to position this text into the flow of the current draft.

Doug Foster

x. Reducing the scope of the SP policy

DMARC introduces a method for the domain owner to state "at time of
transmission, authorized emails will always authenticate using DMARC
criteria".   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.  This is a
significant loss, because sp=none opens a vast namespace to domain abuse,
including
- names that are DNS domains but are not protected by a domain-level DMARC
policy
- names that are DNS records records rather than DNS names, and cannot be
protected by a domain-level DMARC policy
- names that are not in DNS at all, and therefore cannot be protected by a
domain-level DMARC policy.

To mitigate these impacts, it is useful to distinguish names used as email
domains from names that are not used for email.   Names that are never used
for email are never authorized at time of transmission, and therefore can
be blocked without concern about in-transit modifications.   Several
methods are presented for addressing this objective.


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.   MX records and SPF policies can be attached to a named resource
record or a wildcard resource record, while DMARC policies can only be
attached to a DNS domain.

Any name that is configured as a DNS resource record can be reconfigured as
a subdomain name supported by resource records which match the subdomain
name, and names that are not in DNS can be added as DNS domain names.  Once
all used mail domain names are configured as DNS domains, they can be
configured with DMARC policies.   Once this is complete, the SP policy will
only apply to unused and non-existent names.  This will permit use of
SP=reject because any such messages will have been unauthenticated at
origin as well as being unauthenticated at reception.   This approach is
fully compatible with RFC 7489 implementations of DMARC.


x.2 Implement an NP policy

The NP policy assumes that names used for mail can be reliably identified,
so that names not used for mail can be categorized as not authorized.  Two
approaches are used:

- For mail domain names that are used with SMTP, the name is assumed to
also be used as an RFC5322.From domain name.   This is indicated by an MX
record which evaluates to an IP address, or an SPF policy which does not
begin with an ALL term.  (RFC 7505 indicates that an MX record which does
not evaluate to an IP address is useful to indicate that a domain does not
accept incoming mail.  Based on RFC 7208, content after an ALL term is
ignored, so a policy of "-ALL" indicates that the name is never used as an
RFC5321.MailFrom domain and an ALL term with any other modifier is a
meaningless policy.)

- 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.

Names which are identified by MX record, SPF policy, or DMARCFROMv1 TXT
record are considered in use names and are evaluated using the P or SP
policy.   Names which do not match these criteria are evaluated using the
NP policy.   This allows unused and non-existent names to be given a
stricter DMARC policy than used names.

To implement an NP policy, domain owners may need to make DNS changes:
- For used domain names that are only identified by an A or AAAA record, an
MX record or DMARCFROMv1 TXT record is needed to explicitly indicate that
the name is used for mail.
- 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.

The NP policy does not require that all mail domains become DNS domains,
but the NP policy will only be understood by evaluators which use this
specification.  Consequently, it is preferable to ensure that all mail
domains are implemented as DNS domains.

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.

To demonstrate, assume that the domain "nomail.example.com" contains only a
webserver at "www.nomail.example.com".   Multiple SPF records are needed to
maximize protection of this subdomain from improper use.   An SPF policy of
"-ALL" is needed on:
- the domain itself, nomail.example.com,
- named resource records, including www.nomail.example.com
- the wildcard resource record, *.example.com.