A Reputation Response Set for Email Identifiers
draft-ietf-repute-email-identifiers-10

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

(Pete Resnick; former steering group member) Yes

Yes ( for -09)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Barry Leiba; former steering group member) (was Discuss) No Objection

No Objection (2013-09-11 for -09)
No email
send info
This document registers an item in a registry that is not yet created, but that requires expert review (via specification required).  Changing my DISCUSS on the creating document to clarify that it's not necessary for IETF consensus RFCs.

(Benoît Claise; former steering group member) No Objection

No Objection (2013-09-09 for -09)
No email
send info
See https://datatracker.ietf.org/doc/draft-ietf-repute-model/ballot/#benoit-claise

   That document also defines a media type to
   contain a reputon for transport, and also creates a registry for
   reputation applications and the interesting parameters of each.

This should be: for a reputation application. Right? Since the reputons are valid for a single application.

(Brian Haberman; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Martin Stiemerling; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Richard Barnes; former steering group member) No Objection

No Objection (2013-09-11 for -09)
No email
send info
There appears to be a stray ">" character in "abusive".

There appears to be a stray ")" character in "spf".

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection ( for -09)
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (2013-09-09 for -09)
No email
send info
What's the ">" in 3.1, definition of abusive?

(Stewart Bryant; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Ted Lemon; former steering group member) No Objection

No Objection (2013-09-10 for -09)
No email
send info
From 3.2:
      rfc5321.helo:  The RFC5321.Helo value used by the (see [SMTP])
         client

      rfc5321.mailfrom:  The RFC5321.MailFrom value of the envelope of
         the message (see [SMTP])

      rfc5322.from:  The RFC5322.From field of the message (see [MAIL])

Given that these data are not validated except in the case where SPF is used, it seems like a bad idea to maintain statistics on them.   The fact that someone is joe-jobbing me does not mean that my email address is meaningfully associated with spam, but it'll sure look like that given the way reputations are calculated.

If you want to retain these, you ought to mention the security problems associated with them in the security considerations section, but I really question the validity of using them at all.   They are certainly useful in combination with other information on a per-message basis, but I don't see how that can work with the repute data model.