Internet-Draft DMARCbis November 2020
Levine Expires 24 May 2021 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-levine-dmarcwalk-00
Published:
Intended Status:
Standards Track
Expires:
Author:
J. Levine
Standcore LLC

DMARC Fallback Domains

Abstract

This document specifies a new tree walk algorithm to find a DMARC Fallback Domain.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 24 May 2021.

Table of Contents

1. Introduction

DMARC allows domains to publish DNS records describing their preference for recipients of mail purporting to be them. The policy record is found in two possible places: the domain in the RFC5322.From[RFC5322] header, or failing that, an ancestor of that domain. In the previous version of DMARC the second domain is called the Organizational Domain, as described below in Section 3. This document describes a new algorithm to find a Fallback Domain.

If a DMARC check uses a Fallback Domain, that domain is used in the same way that a Legacy Organizational Domain is used in [RFC7489].

2. Fallback Domain

The Fallback Domain is found using a tree walk.

  1. Call the RFC5322.From domain the Current domain.

  2. Delete the leftmost (low-order) label from the Current domain. If there are no labels left, stop. Otherwise call the new shorter domain the new Current domain.

  3. Prepend _dmarc. to the Current domain and check for a valid DMARC policy record at that name in the DNS. If one exists, stop.

  4. Otherwise, return to step 2 and repeat until four potential Fallback Domain names have been checked.

For example, if the RFC5322.From domain is sales.examp1e.com, the sequence of names to check would be:

_dmarc.sales.examp1e.com
_dmarc.examp1e.com
_dmarc.com

If the RFC5322.From domain is sales.east.widgets.bigcorp.com.example, the sequence of names would be:

_dmarc.sales.east.widgets.bigcorp.com.example
_dmarc.east.widgets.bigcorp.com.example
_dmarc.widgets.bigcorp.com.example
_dmarc.widgets.bigcorp.com.example
_dmarc.bigcorp.com.example

2.1. Default Fallback Domain

If the process in the previous section terminates after checking the RFC5322.From name and four potential Fallbak Domain names without finding a valid DMARC policy record, synthesize a policy record for the RFC5322.From domain containing:

v=DMARC1; p=reject;

The four label limit is intended to mitigate DNS attacks on mail systems using RFC5322.From addresses with very long labels that would otherwise cause very long tree walks. This avoids the possibility of maliciously avoiding DMARC checks by using very long names. Note that if the RFC5322.From name does not exist in the DNS, DMARC checks will always fail since there can be no SPF or DKIM records to validate the name.

3. Legacy Organizational Domain

The legacy Organizational Domain is determined using the following algorithm:

  1. Acquire a "public suffix" list, i.e., a list of DNS domain names reserved for registrations. Some country Top-Level Domains (TLDs) make specific registration requirements, e.g., the United Kingdom places company registrations under ".co.uk"; other TLDs such as ".com" appear in the IANA registry of top-level DNS domains. A public suffix list is the union of all of these.

  2. Break the subject DNS domain name into a set of "n" ordered labels. Number these labels from right to left; e.g., for "example.com", "com" would be label 1 and "example" would be label 2.

  3. Search the public suffix list for the name that matches the largest number of labels found in the subject DNS domain. Let that number be "x".

  4. Construct a new DNS domain name using the name that matched from the public suffix list and prefixing to it the "x+1"th label from the subject domain. This new name is the Organizational Domain.

Thus, since "com" is an IANA-registered TLD, a subject domain of "a.b.c.d.example.com" would have an Organizational Domain of "example.com".

4. Differences between Fallback and Legacy Organizational Domains

Since the methods of finding the Fallback and Legacy Organization Domains are different, they will not always find the same policy record.

If there is a policy record at the Legacy Organizational domain, and not at any other intermediate name above the RFC5322.From domain, the two methods will yield the same result, so long as there are no more than four labels betwen the Legacy Organizational Domain and the Fallback Domain.

If there are policy records at intermediate names, those records will take precedence over the Legacy Organizational domain. This allows organizations to delegate DMARC policy authority on more finely than the Legacy Organizational domain does.

If there is no policy record at the the Legacy Organizational domain, but there is one at a name higher in the name tree, the result is similar to that in I-D.draft-ietf-dmarc-psd-08.

The use of the Default Fallback domain means that any system that sends mail using a RFC5322.From domain more than five labels long must publish a DMARC policy record or its mail will all fail DMARC checks. In practice, we have rarely seen valid mail domains that long; but if it's an issue, changing the limit from 5 labels to 7 or 10 would still deter DNS attacks.

The Fallback Domain method is deterministic and will always find the same record, while the Legacy Organizational method depends on the contents of the public suffix list that it uses.

5. Informative References

[RFC5322]
Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, , <https://www.rfc-editor.org/info/rfc5322>.
[RFC7489]
Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, , <https://www.rfc-editor.org/info/rfc7489>.

Author's Address

John Levine
Standcore LLC