RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (1)

RFC 8460, "SMTP TLS Reporting", September 2018

Source of RFC: uta (sec)

Errata ID: 8070
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Freddie Leeman
Date Reported: 2024-08-09
Verifier Name: RFC Editor
Date Verified: 2024-08-12

Section 3 says: 

A receiver MAY opt to only attempt delivery to one of the endpoints;

It should say:

The reporter MAY opt to only attempt delivery to one of the endpoints;

Notes:

The reporter is the entity that delivers the report, not the receiver.

Status: Reported (1)

RFC 8460, "SMTP TLS Reporting", September 2018

Source of RFC: uta (sec)

Errata ID: 8303
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Andreas Schulze
Date Reported: 2025-02-20

Section 3 says: 

The DKIM TXT record SHOULD contain the appropriate service type declaration, "s=tlsrpt"

It should say:

Section 6 does not request IANA to update the DKIM service type list
https://www.iana.org/assignments/dkim-parameters/dkim-parameters.xhtml#dkim-parameters-8 still does not list "tlsrpt" as a valid service type.

Notes:

It seems, the request to IANA to update the list was just forgotten.

Status: Held for Document Update (2)

RFC 8460, "SMTP TLS Reporting", September 2018

Source of RFC: uta (sec)

Errata ID: 5889
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Scott Kitterman
Date Reported: 2019-10-31
Held for Document Update by: Alexey Melnikov
Date Held: 2020-03-25

Section 6.7 says: 

Item is missing entirely

It should say:

6.7 DKIM Service Type

This document registers a new DKIM Service Type in the DomainKeys Identified Mail (DKIM) Parameters registry:

Service Type name: tlsrpt

Reference: RFC 8460

Status Active

Notes:

The new service type is discussed in Section 3, so it should have been added to the registry. It's an IETF Review required registry, not Specification Required, so this can (and should) be addressed in terms at least of the registry now.

Alexey: Murray wrote:

I would guess we can't rectify this oversight via the errata system. What got IETF Review was the need for the registration, but not the registration itself.

I imagine this should either be done through DISPATCH (which is chartered to do minor housekeeping things like this) or through an AD-sponsored document that contains only the registration.

Errata ID: 6241
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Kristian Klausen
Date Reported: 2020-07-27
Held for Document Update by: Barry Leiba
Date Held: 2020-07-29

Section Appendix B. says: 

Appendix B.  Example JSON Report
...
     "policies": [{
       "policy": {
...
         "mx-host": "*.mail.company-y.example"
       },
...

It should say:

Appendix B.  Example JSON Report
...
     "policies": [{
       "policy": {
...
         "mx-host": ["*.mail.company-y.example"]
       },
...

Notes:

"mx-host-pattern" is defined as a JSON array

========== Verifier notes ==========
This is right on the edge of "Verified": the reporter is correct about the error, but the existing implementations don't comply with the proposed fix. So this really needs to be dealt with in a document update, rather than through an errata report.

Report New Errata



Advanced Search