RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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.

Report New Errata



Advanced Search