RFC Errata
Found 4 records.
Status: Verified (1)
RFC 5965, "An Extensible Format for Email Feedback Reports", August 2010
Note: This RFC has been updated by RFC 6650
Source of RFC: marf (app)
Errata ID: 4421
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Simon Leinen
Date Reported: 2015-07-19
Verifier Name: Barry Leiba
Date Verified: 2015-07-19
Section B.2 says:
--part1_13d.2e68ed54_boundary
Content-Type: message/rfc822
Content-Disposition: inline
From: <somespammer@example.net>
Received: from mailserver.example.net (mailserver.example.net
[192.0.2.1]) by example.com with ESMTP id M63d4137594e46;
Thu, 08 Mar 2005 14:00:00 -0400
To: <Undisclosed Recipients>
Subject: Earn money
It should say:
--part1_13d.2e68ed54_boundary
Content-Type: message/rfc822
Content-Disposition: inline
From: <somespammer@example.net>
Received: from mailserver.example.net (mailserver.example.net
[192.0.2.1]) by example.com with ESMTP id M63d4137594e46;
Thu, 08 Mar 2005 14:00:00 -0400
To: <Undisclosed Recipients>
Subject: Earn money
Notes:
In the second example report, there is an empty line in the middle of the headers section of the quoted rfc822 message. This seems wrong.
Status: Reported (1)
RFC 5965, "An Extensible Format for Email Feedback Reports", August 2010
Note: This RFC has been updated by RFC 6650
Source of RFC: marf (app)
Errata ID: 5446
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Martijn van der Lee
Date Reported: 2018-07-30
Section B.2 says:
Authentication-Results: mail.example.com;
spf=fail smtp.mail=somespammer@example.com
It should say:
Authentication-Results: mail.example.com;
spf=fail smtp.mail=somespammer@example.net
Notes:
The TLD of the spammer's emailaddress should be `.net` as in the rest of the example.
Status: Held for Document Update (1)
RFC 5965, "An Extensible Format for Email Feedback Reports", August 2010
Note: This RFC has been updated by RFC 6650
Source of RFC: marf (app)
Errata ID: 3120
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: John Levine
Date Reported: 2012-02-14
Held for Document Update by: Pete Resnick
Section 2.d. says:
This part MUST be included (contrary to [REPORT])
It should say:
This part MUST be included if the entity creating the report has received the message.
Notes:
Reports can be created from info collected in SMTP transactions that don't accept a message, a scenario we didn't consider when we wrote this section.
Status: Rejected (1)
RFC 5965, "An Extensible Format for Email Feedback Reports", August 2010
Note: This RFC has been updated by RFC 6650
Source of RFC: marf (app)
Errata ID: 7091
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alessandro Vesely
Date Reported: 2022-08-16
Rejected by: Murray Kucherawy
Date Rejected: 2024-02-03
Section 2 says:
e. Except as discussed below, each feedback report MUST be related
to only a single email message. Summary and aggregate formats
are outside of the scope of this specification.
It should say:
e. Except when using the Incidents field (see below),
each feedback report MUST be related
to only a single email message. Summary and aggregate formats
are outside of the scope of this specification.
Notes:
There doesn't seem to be another discussion of similarity.
--VERIFIER NOTES--
A single report is about a single message, even if it includes a claim that it is similar to other messages.