RFC Errata
Found 20 records.
Status: Verified (4)
RFC 7489, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", March 2015
Note: This RFC has been updated by RFC 8553, RFC 8616
Source of RFC: INDEPENDENT
Errata ID: 5365
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gary Palmer
Date Reported: 2018-05-22
Verifier Name: Eliot Lear (ISE)
Date Verified: 2022-09-30
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: 5371
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Cris van Pelt
Date Reported: 2018-05-28
Verifier Name: Eliot Lear (ISE)
Date Verified: 2022-09-30
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: 5440
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
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.
Errata ID: 6439
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Norton
Date Reported: 2021-02-23
Verifier Name: Adrian Farrel
Date Verified: 2021-02-24
Section 7.1 says:
For example, if a DMARC policy query for "blue.example.com" contained
"rua=mailto:reports@red.example.net", the host extracted from the
latter ("red.example.net") does not match "blue.example.com", so this
procedure is enacted.
It should say:
For example, if a DMARC policy query for "blue.example.com" contained
"rua=mailto:reports@red.example.net", the Organizational Domain of the
host extracted from the latter ("example.net") does not match the
Organizational Domain "example.com", so this procedure is enacted.
Notes:
Section 7.1 (third paragraph) is clear that it is the Organizational Domains which are to be compared in order to make a determination on the need to perform validation steps. The example incorrectly makes this determination by comparing the hostnames instead of the Organizational Domains.
Status: Reported (9)
RFC 7489, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", March 2015
Note: This RFC has been updated by RFC 8553, RFC 8616
Source of RFC: INDEPENDENT
Errata ID: 5220
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Steven Hilton
Date Reported: 2017-12-31
Edited by: Adrian Farrel
Date Edited: 2021-06-01
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: Technical
Publication Format(s) : TEXT
Reported By: Steven Hilton
Date Reported: 2017-12-31
Edited by: Adrian Farrel
Date Edited: 2021-06-01
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).
Errata ID: 5229
Status: Reported
Type: Technical
Publication Format(s) : TEXT
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: 5495
Status: Reported
Type: Technical
Publication Format(s) : TEXT
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: 5773
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Freddie Leeman
Date Reported: 2019-07-03
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"/>
<!-- The SPF alignment mode. -->
<xs:element name="aspf" type="AlignmentType"/>
<!-- 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. -->
<xs:element name="fo" type="xs:string" />
</xs:all>
</xs:complexType>
Notes:
The name "PolicyPublishedType" suggests that the elements within it represent the domain's published policy. But the comment from element "fo" describes itself as "Failure reporting options IN EFFECT".
A lot of organizations do not send failure (forensic) reports and do not publish the "fo" element in their aggregate reports (Google, Yahoo!, Zoho) . This is reasonable since the description says "in effect". But the field also has a (default) MinOccurs of 1 because MinOccurs is not defined. So by omitting the element, the reports from these organizations are in violation of the guidelines.
Should an aggregate report have a mandatory "fo" element, even if the organization doesn't do failure (forensic) reporting? If so, than the comment "<!-- Failure reporting options in effect. -->" should be "<!-- Failure reporting options. -->". And if not, than the minOccurs="0" should be added to the "fo" element to allow it to be optional.
Even if DMARC policy options are OPTIONAL and not specified, the messages are processed by the receiver with the default values. This is also the case for adkim and aspf, which also have a minOccurs of 0.
So i would suggest the following:
The PolicyPublishedType describe the policy that is applied tot the messages in the reports. Elements that are not defined by the domain's DMARC policy should be filled with the default values, as they would also be processed that way. So when adkim is not configured in the policy, the report should state value "r" as this is the default value. Same applies to aspf ("r"), sp (same as "p"), pct (100) and fo (0). Even if an organization doesn't send out failure reports it MUST mention the "fo" value from the domain's policy, or, when not specified, the default value of 0.
Errata ID: 6729
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Kitterman
Date Reported: 2021-11-01
Section 3.2 says:
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".
It should say:
3. Search the ICANN DOMAINS section of 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".
Notes:
The PSL includes both public and private domains. RFC 7489 should have limited name matching to the public, ICANN DOMAINS section of the PSL. As an example, using the current PSL, the organizational domain for example.s3.dualstack.ap-northeast-1.amazonaws.com is example.s3.dualstack.ap-northeast-1.amazonaws.com, not amazonaws.com since it is listed in the private section of the PSL. This is clearly the wrong result.
Errata ID: 7099
Status: Reported
Type: Technical
Publication Format(s) : TEXT
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: 7100
Status: Reported
Type: Technical
Publication Format(s) : TEXT
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: 7865
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Fränz Friederes
Date Reported: 2024-03-23
Appendix C says:
<!-- Credit to Roger L. Costello for IPv4 regex
http://mailman.ic.ac.uk/pipermail/xml-dev/1999-December/
018018.html -->
<!-- Credit to java2s.com for IPv6 regex
http://www.java2s.com/Code/XML/XML-Schema/
IPv6addressesareeasiertodescribeusingasimpleregex.htm -->
<xs:simpleType name="IPAddress">
<xs:restriction base="xs:string">
<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}"/>
</xs:restriction>
</xs:simpleType>
It should say:
<!-- Credit to Roger L. Costello for IPv4 regex
http://mailman.ic.ac.uk/pipermail/xml-dev/1999-December/
018050.html -->
<!-- Credit to java2s.com for IPv6 regex
http://www.java2s.com/Code/XML/XML-Schema/
IPv6addressesareeasiertodescribeusingasimpleregex.htm -->
<xs:simpleType name="IPAddress">
<xs:restriction base="xs:string">
<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}"/>
</xs:restriction>
</xs:simpleType>
Notes:
The IPv4 regex contains a period "." that should be corrected to an escaped period "\." As stated in the follow up message of the one referenced in the IPv4 regex credit: "I just realized that there is a bug [...] The period (.) is a special character meaning 'any character'. To indicate that we want a period and not 'any character' the period must be escaped with a backslash, i.e., \." Following the XML schema provided in the original Appendix C, strings like "1a1a1a1" and "1111111" are considered valid IPv4 addresses, although they are not usable.
Status: Held for Document Update (4)
RFC 7489, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", March 2015
Note: This RFC has been updated by RFC 8553, RFC 8616
Source of RFC: INDEPENDENT
Errata ID: 6485
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Kaspar Etter
Date Reported: 2021-03-15
Held for Document Update by: Eliot Lear (ISE)
Date Held: 2022-10-01
Section 7.2.1.1. says:
dmarc-subject = %x52.65.70.6f.72.74 1*FWS ; "Report"
%x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:"
domain-name 1*FWS ; from RFC 6376
%x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:"
1*FWS domain-name 1*FWS
%x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:"
msg-id ; from RFC 5322
It should say:
dmarc-subject = %x52.65.70.6f.72.74 1*FWS ; "Report"
%x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:"
domain-name 1*FWS ; from RFC 6376
%x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:"
1*FWS domain-name 1*FWS
%x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:"
1*FWS %x3c dot-atom-text %x3e ; from RFC 5322
Notes:
According to RFC 5322, msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]. The example given in Section 7.2.1.1. (<2002.02.15.1>) does not adhere to this and neither do reports in the wild. Instead of referring to the msg-id ABNF, I suggest that we refer to the dot-atom-text ABNF and include "<" and ">" as ASCII characters. This also has the advantage of getting rid of CFWS. According to RFC 5322, "comments may be included in structured field bodies" but "Subject" is not a structured header field.
Errata ID: 7835
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Giuseppe Trotta
Date Reported: 2024-03-04
Held for Document Update by: Eliot Lear
Date Held: 2024-03-11
Section 6.6.3 says:
2. Records that do not start with a "v=" tag that identifies the
current version of DMARC are discarded.
3. If the set is now empty, the Mail Receiver MUST query the DNS for
a DMARC TXT record at the DNS domain matching the Organizational
Domain in place of the RFC5322.From domain in the message (if
different). This record can contain policy to be asserted for
subdomains of the Organizational Domain. A possibly empty set of
records is returned.
4. Records that do not start with a "v=" tag that identifies the
current version of DMARC are discarded.
It should say:
2. Records that do not start with a "v=" tag that identifies the
current version of DMARC are discarded.
3. If the set is now empty, the Mail Receiver MUST query the DNS for
a DMARC TXT record at the DNS domain matching the Organizational
Domain in place of the RFC5322.From domain in the message (if
different). This record can contain policy to be asserted for
subdomains of the Organizational Domain. A possibly empty set of
records is returned.
Notes:
The intent of the original text is that indeed step 2 should be repeated as follows:
(1) Go get a set of things.
(2) Filter them.
(3) If the set is now empty, go get a set of things from a different location.
(4) Filter them.
At the time of this writing, draft-ietf-dmarc-dmarcbis is being developed, and so that text may clarify this point. As such we will hold this erratum for update.
Errata ID: 5151
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
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.
Errata ID: 5774
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Freddie Leeman
Date Reported: 2019-07-03
Held for Document Update by: Adrian Farrel
Date Held: 2021-06-01
Section Appendix C says:
<!-- The DMARC disposition applying to matching
messages. -->
<xs:element name="policy_evaluated"
type="PolicyEvaluatedType"
minOccurs="1"/>
<!-- The RFC5321.MailFrom domain. -->
<xs:element name="envelope_from" type="xs:string"
minOccurs="1"/>
<!-- The RFC5322.From domain. -->
<xs:element name="header_from" type="xs:string"
minOccurs="1"/>
<!-- The "d=" parameter in the signature. -->
<xs:element name="domain" type="xs:string"
minOccurs="1"/>
<!-- The DKIM verification result. -->
<xs:element name="result" type="DKIMResultType"
minOccurs="1"/>
<!-- The checked domain. -->
<xs:element name="domain" type="xs:string" minOccurs="1"/>
<!-- The scope of the checked domain. -->
<xs:element name="scope" type="SPFDomainScope" minOccurs="1"/>
<!-- The SPF verification result. -->
<xs:element name="result" type="SPFResultType"
minOccurs="1"/>
<!-- There will always be at least one SPF result. -->
<xs:element name="spf" type="SPFAuthResultType" minOccurs="1"
maxOccurs="unbounded"/>
It should say:
<!-- The DMARC disposition applying to matching
messages. -->
<xs:element name="policy_evaluated"
type="PolicyEvaluatedType"/>
<!-- The RFC5321.MailFrom domain. -->
<xs:element name="envelope_from" type="xs:string"/>
<!-- The RFC5322.From domain. -->
<xs:element name="header_from" type="xs:string"/>
<!-- The "d=" parameter in the signature. -->
<xs:element name="domain" type="xs:string"/>
<!-- The DKIM verification result. -->
<xs:element name="result" type="DKIMResultType"/>
<!-- The checked domain. -->
<xs:element name="domain" type="xs:string"/>
<!-- The scope of the checked domain. -->
<xs:element name="scope" type="SPFDomainScope"/>
<!-- The SPF verification result. -->
<xs:element name="result" type="SPFResultType"/>
<!-- There will always be at least one SPF result. -->
<xs:element name="spf" type="SPFAuthResultType"
maxOccurs="unbounded"/>
Notes:
Removed all minOccurs="1" from the DMARC XML Schema since the NOTE at the beginning of the appendix already states that 'unless otherwise specified, the minOccurs and maxOccurs values for each element are set to 1'. These (9) unnecessary specifications of minOccurs can cause confusion and lead to incorrect implementations.
While this report is technically correct, it is hard to see that the text as currently present is harmful or confusing. This is left for an update if/when the document is revised.
Status: Rejected (3)
RFC 7489, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", March 2015
Note: This RFC has been updated by RFC 8553, RFC 8616
Source of RFC: INDEPENDENT
Errata ID: 4907
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
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.
Errata ID: 5370
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Cris van Pelt
Date Reported: 2018-05-28
Rejected by: Eliot Lear (ISE)
Date Rejected: 2022-08-21
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").
--VERIFIER NOTES--
Thank you for your report. This is a duplicate of another erratum: 5365.
Errata ID: 5552
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Borislav Petrov
Date Reported: 2018-11-09
Rejected by: Eliot Lear (ISE)
Date Rejected: 2022-09-30
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.
--VERIFIER NOTES--
The reporter has quoted from the wrong section of RFC 5321, and that that section does not discuss Message Submission Servers.