RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Reported (4)

RFC 7489, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", March 2015

Source of RFC: INDEPENDENT

Errata ID: 5229
Status: Reported
Type: Technical

Reported By: Steven Hilton
Date Reported: 2018-01-07

Section Appendix C says:

   <!-- The DMARC policy that applied to the messages in
        this report. -->
   <xs:complexType name="PolicyPublishedType">
     <xs:all>
       <!-- The domain at which the DMARC record was found. -->
       <xs:element name="domain" type="xs:string"/>
       <!-- The DKIM alignment mode. -->
       <xs:element name="adkim" type="AlignmentType"
                   minOccurs="0"/>
       <!-- The SPF alignment mode. -->
       <xs:element name="aspf" type="AlignmentType"
                   minOccurs="0"/>
       <!-- The policy to apply to messages from the domain. -->
       <xs:element name="p" type="DispositionType"/>
       <!-- The policy to apply to messages from subdomains. -->
       <xs:element name="sp" type="DispositionType"/>
       <!-- The percent of messages to which policy applies. -->
       <xs:element name="pct" type="xs:integer"/>
       <!-- Failure reporting options in effect. -->
       <xs:element name="fo" type="xs:string"/>
     </xs:all>
   </xs:complexType>

It should say:

   <!-- The DMARC policy that applied to the messages in
        this report. -->
   <xs:complexType name="PolicyPublishedType">
     <xs:all>
       <!-- The domain at which the DMARC record was found. -->
       <xs:element name="domain" type="xs:string"/>
       <!-- The DKIM alignment mode. -->
       <xs:element name="adkim" type="AlignmentType"
                   minOccurs="0"/>
       <!-- The SPF alignment mode. -->
       <xs:element name="aspf" type="AlignmentType"
                   minOccurs="0"/>
       <!-- The policy to apply to messages from the domain. -->
       <xs:element name="p" type="DispositionType"/>
       <!-- The policy to apply to messages from subdomains. -->
       <xs:element name="sp" type="DispositionType"/
                   minOccurs="0"/>
       <!-- The percent of messages to which policy applies. -->
       <xs:element name="pct" type="xs:integer"/>
       <!-- Failure reporting options in effect. -->
       <xs:element name="fo" type="xs:string"/
                   minOccurs="0"/>
     </xs:all>
   </xs:complexType>

Notes:

Per section 6.3, "adkim", "aspf", "sp", "pct", and "fo" are optional. All but "sp" have a default value, which is inconsistently applied in Appendix C.

If the Subdomain Policy (sp) is required in aggregate reports, I recommend clarification on how to provide this information for domains that do not publish this information.
For example:
- If a subdomain policy is published on a subdomain of an organizational domain, return an 'ignored' subdomain policy in the aggregate report
- If a subdomain policy is NOT published on an organizational domain, recommend returning the effective subdomain policy in the aggregate report, which is the domain policy per section 6.3
- Recommend addition of the "fo" tag only if the "ruf" tag is published.

Errata ID: 5365
Status: Reported
Type: Technical

Reported By: Gary Palmer
Date Reported: 2018-05-22

Section 7.2.1.1 says:

     mail.receiver.example!example.com!1013662812!1013749130.gz

It should say:

     mail.receiver.example!example.com!1013662812!1013749130.xml.gz

Notes:

The specification states that the suffix should be "xml" for an uncompressed file, and "xml.gz" for a compressed file. The example filename is missing the "xml" component of the suffix

Errata ID: 5220
Status: Reported
Type: Editorial

Reported By: Steven Hilton
Date Reported: 2017-12-31

Section A.6. says:

A.6.  Organizational Domain Discovery Issues

   Although protocols like ADSP are useful for "protecting" a specific
   domain name, they are not helpful at protecting subdomains.  If one
   wished to protect "example.com" by requiring via ADSP that all mail
   bearing an RFC5322.From domain of "example.com" be signed, this would
   "protect" that domain; however, one could then craft an email whose
   RFC5322.From domain is "security.example.com", and ADSP would not
   provide any protection.  One could use a DNS wildcard, but this can
   undesirably interfere with other DNS activity; one could add ADSP
   records as fraudulent domains are discovered, but this solution does
   not scale and is a purely reactive measure against abuse.

   The DNS does not provide a method by which the "domain of record", or
   the domain that was actually registered with a domain registrar, can
   be determined given an arbitrary domain name.  Suggestions have been
   made that attempt to glean such information from SOA or NS resource
   records, but these too are not fully reliable, as the partitioning of
   the DNS is not always done at administrative boundaries.

   When seeking domain-specific policy based on an arbitrary domain
   name, one could "climb the tree", dropping labels off the left end of
   the name until the root is reached or a policy is discovered, but
   then one could craft a name that has a large number of nonsense
   labels; this would cause a Mail Receiver to attempt a large number of
   queries in search of a policy record.  Sending many such messages
   constitutes an amplified denial-of-service attack.

   The Organizational Domain mechanism is a necessary component to the
   goals of DMARC.  The method described in Section 3.2 is far from
   perfect but serves this purpose reasonably well without adding undue
   burden or semantics to the DNS.  If a method is created to do so that
   is more reliable and secure than the use of a public suffix list,
   DMARC should be amended to use that method as soon as it is generally
   available.

It should say:

A.6.  Organizational Domain Discovery Issues

   Although protocols like ADSP are useful for "protecting" a specific
   domain name, they are not helpful at protecting subdomains.  If one
   wished to protect "example.com" by requiring via ADSP that all mail
   bearing an RFC5322.From domain of "example.com" be signed, this would
   "protect" that domain; however, one could then craft an email whose
   RFC5322.From domain is "security.example.com", and ADSP would not
   provide any protection.  One could use a DNS wildcard, but this can
   undesirably interfere with other DNS activity; one could add ADSP
   records as fraudulent domains are discovered, but this solution does
   not scale and is a purely reactive measure against abuse.

   The DNS does not provide a method by which the "domain of record", or
   the domain that was actually registered with a domain registrar, can
   be determined given an arbitrary domain name.  Suggestions have been
   made that attempt to glean such information from SOA or NS resource
   records, but these too are not fully reliable, as the partitioning of
   the DNS is not always done at administrative boundaries.

   When seeking domain-specific policy based on an arbitrary domain
   name, one could "climb the tree", dropping labels off the left end of
   the name until the root is reached or a policy is discovered, but
   then one could craft a name that has a large number of nonsense
   labels; this would cause a Mail Receiver to attempt a large number of
   queries in search of a policy record.  Sending many such messages
   constitutes an amplified denial-of-service attack.

   Certain TLDs could be classified as a Organizational Domains. The 
   benefits to those organizations do not yet justify the necessary 
   modifications to this document. An few organizations may 
   prefer the simplified reporting and DNS configuration of a 
   TLD Organizational Domain. This would require modifications to 
   this document and DMARC receivers for a capability that may not even
   be desired by those organizations that strictly control a TLD.

   The Organizational Domain mechanism is a necessary component to the
   goals of DMARC.  The method described in Section 3.2 is far from
   perfect but serves this purpose reasonably well without adding undue
   burden or semantics to the DNS.  If a method is created to do so that
   is more reliable and secure than the use of a public suffix list,
   DMARC should be amended to use that method as soon as it is generally
   available.

Notes:

RFC7489 does not address Organizational Top Level Domains. There are advantages and disadvantages to using a strictly controlled TLD as an Organizational Domain.

Advantages:
Simplified reporting for nonexistent domains
Simplified external reporting to another email address with the same TLD
Reduced need for multiple wildcard TXT records

Disadvantages:
Decreased flexibility for subdomains
A "_dmarc.tld" record is not be a dotless domain, but may not be recommended
Significant changes to current DMARC processing systems
New requirement to manage which TLDs are eligible to be Organizational Domains
Organizations with a strictly controlled TLD may not desire this change

Errata ID: 5221
Status: Reported
Type: Editorial

Reported By: Steven Hilton
Date Reported: 2017-12-31

Section Appendix C. says:

       <xs:pattern value="((1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]).){3}
                   (1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])|
                   ([A-Fa-f0-9]{1,4}:){7}[A-Fa-f0-9]{1,4}"/>

It should say:

       <xs:pattern value="^((1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]).){3}
                   (1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])$|
                   ^(([0-9A-Fa-f]{1,4}:){7}[A-Fa-f0-9]{1,4})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,1}(:[0-9A-Fa-f]{1,4}){1,6})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,2}(:[0-9A-Fa-f]{1,4}){1,5})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,3}(:[0-9A-Fa-f]{1,4}){1,4})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,4}(:[0-9A-Fa-f]{1,4}){1,3})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,5}(:[0-9A-Fa-f]{1,4}){1,2})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,6}(:[0-9A-Fa-f]{1,4}){1,1})$|
                   ^((([0-9A-Fa-f]{1,4}:){1,7}|:):)$|
                   ^(:(:[0-9A-Fa-f]{1,4}){1,7})$|
                   ^(((([0-9A-Fa-f]{1,4}:){6})
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3}))$|
                   ^((([0-9A-Fa-f]{1,4}:){5}[0-9A-Fa-f]{1,4}:
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3}))$|
                   ^(([0-9A-Fa-f]{1,4}:){5}:[0-9A-Fa-f]{1,4}:
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,1}(:[0-9A-Fa-f]{1,4}){1,4}:
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,2}(:[0-9A-Fa-f]{1,4}){1,3}:
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,3}(:[0-9A-Fa-f]{1,4}){1,2}:
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$|
                   ^(([0-9A-Fa-f]{1,4}:){1,4}(:[0-9A-Fa-f]{1,4}){1,1}:
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$|
                   ^((([0-9A-Fa-f]{1,4}:){1,5}|:):
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$|
                   ^(:(:[0-9A-Fa-f]{1,4}){1,5}:
                     (25[0-5]|2[0-4]\d|[0-1]?\d?\d)
                     (\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3})$"/>

Notes:

The document does not address compressed IPv6 addresses, and the IPv6 regular expression pattern does provided in the proposed XML validation does not match compressed IPv6 addresses.

I recommend using a more comprehensive regular expression, adding another note to the appendix that the IPv6 pattern is only included for brevity, or modifying the document to require fully expanded IPv6 addresses.

Credit for the IPv6 regular expression above goes to Vernon Mauery (http://vernon.mauery.com/content/projects/linux/ipv6_regex).

Status: Held for Document Update (1)

RFC 7489, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", March 2015

Source of RFC: INDEPENDENT

Errata ID: 5151
Status: Held for Document Update
Type: Editorial

Reported By: Clara Nees
Date Reported: 2017-10-10
Held for Document Update by: Adrian Farrel
Date Held: 2018-04-08

Section 1 says:

However, there has been no single widely
accepted or publicly available mechanism to communication of
domain-specific message-handling policies for receivers, or to
request reporting of authentication and disposition of received mail.

It should say:

However, there has been no single widely
accepted or publicly available mechanism to communicate
domain-specific message-handling policies to receivers, or to
request reporting of authentication and disposition of received mail.

Notes:

"Mechanism to communication of [...] policies for receivers" should instead read,
"Mechanism to COMMUNICATE [...] policies TO receivers.

Status: Rejected (1)

RFC 7489, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", March 2015

Source of RFC: INDEPENDENT

Errata ID: 4907
Status: Rejected
Type: Technical

Reported By: Don
Date Reported: 2017-01-16
Rejected by: Nevil Brownlee
Date Rejected: 2017-07-31

Section B.1.1. says:

   Example 3: SPF not in alignment:

        MAIL FROM: <sender@example.net>

        From: sender@child.example.com
        Date: Fri, Feb 15 2002 16:54:30 -0800
        To: receiver@example.org
        Subject: here's a sample

   In this case, the RFC5321.MailFrom parameter includes a DNS domain
   that is neither the same as nor a parent of the RFC5322.From domain.
   Thus, the identifiers are not in alignment.

It should say:

   Example 3: SPF not in alignment:

        MAIL FROM: <sender@example.net>

        From: sender@child.example.com
        Date: Fri, Feb 15 2002 16:54:30 -0800
        To: receiver@example.org
        Subject: here's a sample

   In this case, the RFC5322.From parameter includes a DNS domain
   that is neither the same as nor a parent of the RFC5321.MailFrom
   domain. Thus, the identifiers are not in alignment.

Notes:

Obviously, in the example MailFrom domain IS a parent of From domain.
--VERIFIER NOTES--
example.NET is not a parent of child.example.COM

Further, the explanatory text makes that clear.

Report New Errata