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

[Dotzero <[e-mail]>]

On Sat, Jun 12, 2021 at 8:56 AM Douglas Foster <
[e-mail]> wrote:

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

The portion of the above statement is an incorrect assertion and is
meaningless to validators and mailbox receivers. It is well known (at least
to validators and receivers) that there is a significant subset of senders
who publish incorrect SPF records or improperly DKIM sign messages or
improperly publish DKIM in DNS or improperly publish DMARC in DNS. Further,
a validator or mailbox provider can only go by what they see and know at
the time they attempt to determine whether a given message validates or not.


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

Senders may be reluctant to implement DMARC for any number of reasons. I've
given email authentication training to thousands of people through OTA when
it was around and to/through the U.S. Federal government. Not once has
anyone raised the above as reasons for reluctance to implement DMARC,
either in total or for implementing 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.
>

As pointed out above, you are asserting impacts not in evidence when you
state that these impacts are of concern. A difference, in order to be a
difference, must make a difference. You have presented nothing to show that
this is an issue causing senders not to implement DMARC.

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

As you state, it is NOT directly part of DMARC.

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

Anyone sophisticated enough to be concerned that this is a problem is
sophisticated enough to publish the appropriate DNS records if they choose.
Your proposal adds unnecessary complexity to address something that is
essentially a non-issue in the real world of DMARC and interoperability.
The more complexity that is added reduces the likelihood of implementation
OR if implementation is attempted, correct implementation.

This proposed change should not be considered by the working group.

Michael Hammer