Email Feedback Report Type Value: not-spam
RFC 6430

Note: This ballot was opened for revision 03 and is now closed.

(Pete Resnick) Yes

(Sean Turner) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2011-09-22 for -)
No email
send info
Would be nice if the Abstract gave context by mentioning "email"

---

Random thought: is there also a need for an ARF to report when a
message has mistakenly been reported as mistakenly reported as spam?
That would be a "not-not-spam report". This would seem to be necessary
as you include the possiblity of a user accidentally pressing a "not
spam" button.

---

   There are anti-spam systems that use "not spam" feedback today.

Presumably, this is non-standard "not spam" feedback?

---

Section 2

   In the first MIME part of the feedback report message, the end user
   or the email client can add information to indicate why the message
   is not spam -- for example, because the originator or its domain is
   well known.

s/can/MAY/ ?

---

Overall, I had trouble finding where in this document anything was 
actually defined. I don't suppose that is really a problem, but it
was a bit surprising.

(Stephen Farrell) No Objection

(Russ Housley) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

Comment (2011-09-19 for -)
No email
send info
To avoid endless philosophical debates about what is and is not spam, I suggest changing "Indicates that a message is not spam" to "Indicates that the entity providing the report does not consider the message to be spam" (or somesuch).

(Robert Sparks) No Objection