RFC Errata
Found 8 records.
Status: Verified (2)
RFC 5804, "A Protocol for Remotely Managing Sieve Scripts", July 2010
Note: This RFC has been updated by RFC 7817, RFC 8553
Source of RFC: sieve (app)
Errata ID: 6345
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kaspar Etter
Date Reported: 2020-11-30
Verifier Name: Orie Steele
Date Verified: 2024-04-01
Section 2.6 says:
Examples:
[…]
C: Putscript "mysievescript" {110+}
C: require ["fileinto"];
C:
C: if envelope :contains "to" "tmartin+sent" {
C: fileinto "INBOX.sent";
C: }
S: OK
C: Putscript "myforwards" {190+}
C: redirect "111@example.net";
C:
C: if size :under 10k {
C: redirect "mobile@cell.example.com";
C: }
C:
C: if envelope :contains "to" "tmartin+lists" {
C: redirect "lists@groups.example.com";
C: }
S: OK (WARNINGS) "line 8: server redirect action
limit is 2, this redirect might be ignored"
It should say:
Examples:
[…]
C: Putscript "mysievescript" {99+}
C: require ["fileinto"];
C:
C: if envelope :contains "to" "tmartin+sent" {
C: fileinto "INBOX.sent";
C: }
C:
S: OK
C: Putscript "myforwards" {190+}
C: redirect "111@example.net";
C:
C: if size :under 10k {
C: redirect "mobile@cell.example.com";
C: }
C:
C: if envelope :contains "to" "tmartin+lists" {
C: redirect "lists@groups.example.com";
C: }
C:
S: OK (WARNINGS) "line 8: server redirect action
limit is 2, this redirect might be ignored"
Notes:
The octet count of the second example is wrong. Additionally, both the second and the third example should have an empty client line after the code like the first example. Otherwise, the octet count of the last example is also wrong.
RFC 8162, "Using Secure DNS to Associate Certificates with Domain Names for S/MIME", May 2017
Source of RFC: dane (sec)
Errata ID: 6544
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kaspar Etter
Date Reported: 2021-04-14
Verifier Name: Roman Danyliw
Date Verified: 2022-01-20
Section 1 says:
Others to want mitigate the difficulty of finding certificates from outside the enterprise.
It should say:
Others want to mitigate the difficulty of finding certificates from outside the enterprise.
Notes:
Wrong order of words.
Status: Reported (3)
RFC 6857, "Post-Delivery Message Downgrading for Internationalized Email Messages", March 2013
Source of RFC: eai (app)
Errata ID: 6573
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Kaspar Etter
Date Reported: 2021-05-05
Section A says:
From: =?UTF-8?Q?DISPLAY-LOCAL?=
=?UTF-8?Q?NON-ASCII-LOCAL=40example=2Ecom?= :;
It should say:
From: =?UTF-8?Q?DISPLAY-LOCAL_?=
=?UTF-8?Q?NON-ASCII-LOCAL=40example=2Ecom?= :;
Notes:
Taking the original text from Errata 3955 (https://www.rfc-editor.org/errata/eid3955), the two encoded-words decode to: DISPLAY-LOCALNON-ASCII-LOCAL@example.com :; (According to section 6.2 of RFC 2047, linear whitespace between adjacent encoded-words is ignored.) This is clearly not desirable and thus a space should be encoded at the end of all display names in appendix A.
RFC 7208, "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", April 2014
Note: This RFC has been updated by RFC 7372, RFC 8553, RFC 8616
Source of RFC: spfbis (app)
Errata ID: 6433
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kaspar Etter
Date Reported: 2021-02-17
Section 3 says:
Each SPF record is placed in the DNS tree at the owner name it pertains to, not in a subdomain under the owner name. This is similar to how SRV records [RFC2782] are done.
It should say:
Each SPF record is placed in the DNS tree at the owner name it pertains to, not in a subdomain under the owner name. This is different from how SRV records [RFC2782] are done.
Notes:
SRV records are placed at specific subdomains, which is not the case for SPF records. (I've chosen Editorial instead of Technical because the meaning of this paragraph should be clear from the context and thus this feels more like a typo.)
RFC 8461, "SMTP MTA Strict Transport Security (MTA-STS)", September 2018
Source of RFC: uta (sec)
Errata ID: 6525
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Kaspar Etter
Date Reported: 2021-04-10
Section 4.2 says:
The certificate presented by the receiving MTA MUST not be expired
It should say:
The certificate presented by the receiving MTA MUST NOT be expired
Notes:
NOT should be capitalized.
Status: Held for Document Update (2)
RFC 4343, "Domain Name System (DNS) Case Insensitivity Clarification", January 2006
Note: This RFC has been updated by RFC 5890
Source of RFC: dnsext (int)
Errata ID: 6361
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Kaspar Etter
Date Reported: 2020-12-22
Held for Document Update by: Eric Vyncke
Date Held: 2021-01-04
Section 4.1 says:
No "case conversion" or "case folding" is done during such output operations, thus "preserving" case.
It should say:
?
Notes:
Whose case is preserved? The case of the label in the DNS query or the case of the label in the DNS database? In other words, if there is a DNS record for ietf.org and I query IETF.org, should the DNS response say ietf.org or IETF.org? I would expect it's the former so that the DNS administrator can inform the DNS requester about the preferred capitalization but I can't figure this out on the basis of the RFC. Does output case preservation refer to something else? All I observe is that tools like dig return the latter when I run 'dig IETF.org'. Maybe an errata is not the right place to ask for clarification but given the name of the RFC, I would expect to find a clear answer to this question in the RFC.
-- verifier note --
After discussion with the RFC author and the errata author, the conclusion is that the RFC isn't wrong but is arguably unclear for some readers.
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.
Status: Rejected (1)
RFC 7208, "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", April 2014
Note: This RFC has been updated by RFC 7372, RFC 8553, RFC 8616
Source of RFC: spfbis (app)
Errata ID: 6432
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Kaspar Etter
Date Reported: 2021-02-17
Rejected by: Barry Leiba
Date Rejected: 2021-02-17
Section 4.4 says:
In accordance with how the records are published (see Section 3 above), a DNS query needs to be made for the <domain> name, querying for type TXT only.
It should say:
?
Notes:
Request for clarification: Are CNAME indirections allowed or, in other words, do they have to be followed during record lookup? If yes, do they count towards the DNS lookup limits as defined in section 4.6.4? If yes, the following sentence has to be adapted as well: "SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS." If the answer to the first question is no, then this should be made clear in section 4.4.
Please note that whether using CNAMEs is a good or bad idea is irrelevant to my question. I also know that you can't add a CNAME record to an apex domain but SPF is not limited to such domains. I assume the answer/consensus will be the same for the initial, `a`, `include`, `exists` and `redirect` lookups. If not, this should also be clarified, of course.
--VERIFIER NOTES--
Errata reports are not the place to ask questions. An appropriate mailing list on which to discuss SPF is the <ietf-smtp> list.