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.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc