RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 11 records.

Status: Verified (1)

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

Source of RFC: INDEPENDENT

Errata ID: 5440
Status: Verified
Type: Editorial

Reported By: John Levine
Date Reported: 2018-07-25
Verifier Name: Adrian Farrel
Date Verified: 2018-07-26

Section 7.1, B.2.1, B.2.3, B.2.4 says:

==7.1==
In particular, the "v=DMARC1" tag is

comes back containing a tag of "v=DMARC1",

containing at least "v=DMARC1"

==B.2.1==

The version of DMARC being used is "DMARC1" ("v=DMARC1")

==B.2.3==

with the value "=DMARC1".

     % dig +short TXT example.com._report._dmarc.thirdparty.example.net
     "v=DMARC1"

     example.com._report._dmarc   IN   TXT    "v=DMARC1"

==B.2.4==

        o  The version of DMARC being used is "DMARC1" ("v=DMARC1")

It should say:

==7.1==
In particular, the "v=DMARC1;" tag is

comes back containing a tag of "v=DMARC1;",

containing at least "v=DMARC1;"

==B.2.1==

The version of DMARC being used is "DMARC1" ("v=DMARC1;")

==B.2.3==

with the value "v=DMARC1;".

     % dig +short TXT example.com._report._dmarc.thirdparty.example.net
     "v=DMARC1;"

     example.com._report._dmarc   IN   TXT    "v=DMARC1;"

==B.2.4==

   o  The version of DMARC being used is "DMARC1" ("v=DMARC1;")

Notes:

The ABNF of dmarc-record in section 6.4 says that there has to be a semicolon after v=DMARC1, but several of the examples for the _report._dmarc record are missing the semicolon.

Status: Reported (8)

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: 5370
Status: Reported
Type: Technical

Reported By: Cris van Pelt
Date Reported: 2018-05-28

Section 7.2.1.1 says:

   The extension MUST be "xml" for a plain XML file, or "xml.gz" for an
   XML file compressed using GZIP.

   "unique-id" allows an optional unique ID generated by the Mail
   Receiver to distinguish among multiple reports generated
   simultaneously by different sources within the same Domain Owner.

   For example, this is a possible filename for the gzip file of a
   report to the Domain Owner "example.com" from the Mail Receiver
   "mail.receiver.example":

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

It should say:

   The extension MUST be "xml" for a plain XML file, or "xml.gz" for an
   XML file compressed using GZIP.

   "unique-id" allows an optional unique ID generated by the Mail
   Receiver to distinguish among multiple reports generated
   simultaneously by different sources within the same Domain Owner.

   For example, this is a possible filename for the gzip file of a
   report to the Domain Owner "example.com" from the Mail Receiver
   "mail.receiver.example":

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

Notes:

The example filename uses an invalid extension (not one of "xml", "xml.gz").

Errata ID: 5371
Status: Reported
Type: Technical

Reported By: Cris van Pelt
Date Reported: 2018-05-28

Section 7.2.1.1 says:

The aggregate data MUST be an XML file that SHOULD be subjected to
GZIP compression.

It should say:

The aggregate data MUST be an XML file that SHOULD be subjected to
GZIP compression (described in [RFC1952]).

Notes:

The term "GZIP compression" is not defined in the text. To clarify, maintain compatibility with future (potentially incompatible) gzip versions, and to bring the document in line with other RFCs (e.g. 3712, 6713, 6968), a reference to RFC 1952 ("GZIP file format specification version 4.3") should be added.

This is assuming RFC 1952 was the author's intent.

Errata ID: 5495
Status: Reported
Type: Technical

Reported By: Scott Kitterman
Date Reported: 2018-09-08

Section 6.6.3 step 1 says:

   1.  Mail Receivers MUST query the DNS for a DMARC TXT record at the
       DNS domain matching the one found in the RFC5322.From domain in
       the message.  A possibly empty set of records is returned.

It should say:

   1.  Mail Receivers MUST query the DNS for a DMARC TXT record at the
       DNS domain matching the _dmarc subdomain of the one found in
       the RFC5322.From domain in the message.  A possibly empty set
       of records is returned.

Notes:

Section 6.1. DMARC Policy Record states that DMARC records are 'stored as DNS TXT records in subdomains named "_dmarc"'. The policy discovery procedure needs to match. As I read it, it currently doesn't.

Errata ID: 5552
Status: Reported
Type: Technical

Reported By: Borislav Petrov
Date Reported: 2018-11-09

Section 10.3. says:

Everything about it..

Notes:

DMARC relies on inspecting header information. This section suggestion is not allowed by rfc5321 and contradicts it:

...a relay SMTP has no need to inspect or
act upon the header section or body of the message data and MUST NOT
do so except to add its own "Received:" header field..

So the correct behaviour shoud be only the second option - 2xy and decide what to do after that being silent or not.

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