Subject: [marf] [Technical Errata Reported] RFC5965 (3120)

From: RFC Errata System <[email-masked]>
Date: Tue, 14 Feb 2012 10:26:16 -0800 (PST)

The following errata report has been submitted for RFC5965,
"An Extensible Format for Email Feedback Reports".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5965&eid=3120

--------------------------------------
Type: Technical
Reported by: John Levine <[email-masked]>

Section: 2.d.

Original Text
-------------
This part MUST be included (contrary to [REPORT])

Corrected Text
--------------
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.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5965 (draft-ietf-marf-base-06)
--------------------------------------
Title               : An Extensible Format for Email Feedback Reports
Publication Date    : August 2010
Author(s)           : Y. Shafranovich, J. Levine, M. Kucherawy
Category            : PROPOSED STANDARD
Source              : Messaging Abuse Reporting Format
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 14 Feb 2012 13:33:38 -0500

> "An Extensible Format for Email Feedback Reports".
...

John,

Thanks for taking care of reporting it.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 16 Feb 2012 13:44:07 -0500

...
> 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.
...

Based on the discussions on the list, I looked at including the 'fix' for this 
in the SPF draft and having it update 5965.  When I get into the text though, 
I don't think this works.  The current draft (correctly) says:

   This document extends [SPF] to add an optional reporting address and
   other parameters.  Extension of [ARF] to add features required for
   the reporting of these incidents is covered in
   [I-D.IETF-MARF-AUTHFAILURE-REPORT] and [I-D.IETF-MARF-AS].

So it seems more than a little awkward to shove an ARF fix in here.  Ideally, 
if we were going to fix it in one of the current drafts it should be I-D.IETF-
MARF-AUTHFAILURE-REPORT, but I guess it's too late for that.

I'm going to proceed on the assumption that the errata will eventually be 
confirmed and that's sufficient or some was will be found to stuff it into I-
D.IETF-MARF-AUTHFAILURE-REPORT/AS and that I don't need to directly address it 
in the SPF draft.  I don't see an non-contrived way to do it.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 16 Feb 2012 10:49:05 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Thursday, February 16, 2012 10:44 AM
> To: [email-masked]
> Subject: Re: [marf] [Technical Errata Reported] RFC5965 (3120)
> 
> So it seems more than a little awkward to shove an ARF fix in here.
> Ideally, if we were going to fix it in one of the current drafts it
> should be I-D.IETF- MARF-AUTHFAILURE-REPORT, but I guess it's too late
> for that.
> 
> I'm going to proceed on the assumption that the errata will eventually
> be confirmed and that's sufficient or some was will be found to stuff
> it into I- D.IETF-MARF-AUTHFAILURE-REPORT/AS and that I don't need to
> directly address it in the SPF draft.  I don't see an non-contrived way
> to do it.

We can post an erratum for authfailure-report when it publishes to tie it all together.

For now I would proceed, and if you feel like adding more explanation would be useful, include it in an appendix.  The IESG can make the choice about whether or not that's really needed and ask the RFC Editor to strike the section if not.

And in the interim, I'll ask our intrepid AD for guidance.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 16 Feb 2012 20:10:57 -0000

>in the SPF draft.  I don't see an non-contrived way to do it.

Since I'm the one who gets to confirm it, that seems like a safe assumption.

R's,
John