Subject: [domainrep] I-D Action: draft-ietf-repute-email-identifiers-01.txt

From: [email-masked]
Date: Fri, 16 Dec 2011 11:18:35 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reputation Services Working Group of the IETF.

	Title           : A Reputation Vocabulary for Email Identifiers
	Author(s)       : Nathaniel Borenstein
                          Murray S. Kucherawy
	Filename        : draft-ietf-repute-email-identifiers-01.txt
	Pages           : 7
	Date            : 2011-12-16

   This document defines a vocabulary for describing email identifiers
   (typically authors or signers) with the application/reputon media
   type.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-repute-email-identifiers-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-repute-email-identifiers-01.txt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 16 Dec 2011 11:25:16 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Friday, December 16, 2011 11:19 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D Action: draft-ietf-repute-email-identifiers-01.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Reputation Services
> Working Group of the IETF.
> 

You can look at the diffs via the datatracker, but basically this takes into account some of the feedback about the assertions.  For example, things like "SENDS-SPAM" makes some impossible claims in the DKIM context because DKIM doesn't make any assertions about who actually sent the message.  So this has been softened to just "SPAM", and the description means "is associated with spam".

It also uses the preferred language of "identifiers" in place of "identities", and improves the definition of what SPF provides.

Updates to the media-type and query-http documents are in the hopper, which are mostly reorganization of information per on-list suggestions.  Those should come out next week or the week after.

-MSK

---

From: Douglas Otis <[email-masked]>
Date: Fri, 16 Dec 2011 12:17:46 -0800

> ftp://ftp.ietf.org/internet-drafts/draft-ietf-repute-email-identifiers-01.txt
In the Security Consideration section there should be a list of 
exclusions on use of identifiers used in conjunction with related 
mechanisms that fail to authenticate the claimed actions of Malware, 
Spam, or Invalid Recipients.

For example:

DKIM must be limited to the action of Malware only.  DKIM does not 
authenticate the domain accountable for Invalid Recipients or Spam.  
DKIM signature validity is unrelated to the domain sending messages 
and/or asserting recipient addresses.  DKIM signature validity is also 
unrelated to messages containing misleading pre-pended header fields.  
The misapplication of reputation would represent a disruptive protocol 
enforcement mechanism that will punish domains that failed to anticipate 
invalid formats specifically permitted by SMTP that should have been 
proactively anticipated by the DKIM protocol itself.

SPF in conjunction with RFC5321.MAILFROM or RFC5321.FROM does not 
confirm which possible identifier was intended to reference SPF 
authorizations, and whether these identifiers uniquely relate to SPF 
referenced domains.  Such uncertainty means holding SPF domains 
accountable for any of the listed actions may be open to exploitation.  
Only the RFC5321.Helo in conjunction with SPF offers confirmation of the 
referenced domain's involvement.

A workable and fair reputation system must ensure providers are able to 
defend their reputation.  There is no excuse for not ensuring 
accountability for the purported action.

-Doug