Subject: [domainrep] Review of: draft-ietf-repute-email-identifiers-06

From: Dave Crocker <[email-masked]>
Date: Sun, 19 May 2013 20:11:17 -0700

{ This review of provided as part of document shepherding /d }

Review of:    A Reputation Response Set for Email Identifiers
ID:           draft-ietf-repute-email-identifiers-06
Reviewed by:  D. Crocker
Review Date:  19 May 2013

Summary:

This document is part of a series that define a query/response mechanism 
for reporting assessment (reputation) information about an object.  The 
current document builds upon the basic mechanism and tailors is for 
reporting reputation of email-related identifiers.

The document is usable in its current form.  Some very minor changes are 
suggested but not required.

Detailed Comments:

> 1.  Introduction
>
>    This document specifies a response set for describing reputation of
>    an email identifier.  A "response set" in this context is defined in
>    [I-D.REPUTE-MODEL] and is used to describe assertions a reputation
>    service provider can make about email identifiers as well as meta-
>    data that can be included in such a reply beyond the base set
>    specified there.

Should the query (http) and response (media-type) documents also be 
cited explicitly?

> 3.1.  Assertions
>
>    The "email-id" reputation application recognizes the following
>    assertions:
>
>
>
>
>
> Borenstein & Kucherawy    Expires May 23, 2013                  [Page 3]
> 
> Internet-Draft  Email Identifiers Reputation Response Set  November 2012
>
>
>    abusive:  The subject identifier is associated with sending or
>       handling > email of a personally abusive, threatening, or
>       otherwise harassing nature.
>
>    fraud:  The subject identifier is associated with sending or handling
>       of fraudulent email, such as "phishing" (some good discussion on
>       this topic can be found in [IODEF-PHISHING])
>
>    invalid-recipients:  The subject identifier is associated with
>       delivery attempts to nonexistent recipients
>
>    malware:  The subject identifier is associated with the sending or
>       handling of malware via email
>
>    spam:  The subject identifier is associated with sending or handling
>       of unwanted bulk email

This list seems to cover the common behaviors, but I'm wondering whether 
it's worth the email-id application -- and perhaps each application -- 
should have its own sub-registry.  It's likely that whatever list is 
defined for email, usage will identify additional labels.  One that 
comes to mind -- and it's only meant as an example -- is "marketing: The 
subject identifier engages in sending excessive marketing emails to its 
customers".  Formally, that's not spam, but it's irritating enough to 
plausibly warrant a reputation note.  I'm sure there are others.

>
>    For all assertions, the "rating" scale is linear: A value of 0.0
>    means there is no data to support the assertion, a value of 1.0 means
>    all accumulated data support the assertion, and the intervening
>    values have a linear relationship (i.e., a score of "x" is twice as
>    strong of an assertion as a value of "x/2").

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 19 May 2013 20:32:47 -0700

On Sun, May 19, 2013 at 8:11 PM, Dave Crocker <[email-masked]> wrote:

> Should the query (http) and response (media-type) documents also be cited
> explicitly?
>

I think the media-type one is a decent candidate.  Transport is a totally
separate matter so I think that should be omitted.

> defined for email, usage will identify additional labels.  One that comes
> to mind -- and it's only meant as an example -- is "marketing: The subject
> identifier engages in sending excessive marketing emails to its customers".
>  Formally, that's not spam, but it's irritating enough to plausibly warrant
> a reputation note.  I'm sure there are others.
>

The list cited is based on practical experience of categories of abuse that
are currently reported, based partly on the work the MARF working group did
("abuse", "fraud", "malware"), the obvious "spam" one, and also on common
anti-abuse heuristics (in the particular case of "invalid-recipients").  I
don't know of any work dedicated to identifying sources of excessive
marketing mail, for example.

To the question of a dedicated sub-registry, I'm not sure it makes a
difference unless different sub-registries will have different update rules
(e.g., IETF Review vs. Designated Expert).  If that's not the case, then
updating either a master registry or a sub-registry invokes the same
procedure, so the answer to your suggestion reduces to a matter of
organization of the tables with IANA.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Sun, 19 May 2013 20:37:21 -0700

On 5/19/2013 8:32 PM, Murray S. Kucherawy wrote:
> On Sun, May 19, 2013 at 8:11 PM, Dave Crocker <[email-masked]
> <mailto:[email-masked]>> wrote:
> I think the media-type one is a decent candidate.  Transport is a
> totally separate matter so I think that should be omitted.

ack.

> also on common anti-abuse heuristics (in the particular case of
> "invalid-recipients").  I don't know of any work dedicated to
> identifying sources of excessive marketing mail, for example.

oh, it feels entirely practical.  as of now.  my point is about the 
likelihood of wanting to grow the list as experience develops.

and here i thought i was clear that it was meant as an example -- a 
hypothetical.  it was meant to be credible, but not intended to be added 
now.

> difference unless different sub-registries will have different update
> rules (e.g., IETF Review vs. Designated Expert).  If that's not the
> case, then updating either a master registry or a sub-registry invokes
> the same procedure, so the answer to your suggestion reduces to a matter
> of organization of the tables with IANA.

The alternative could be a flat registry, across applications, but that 
requires they not collide.  The benefit might be having sub-sets of 
profiles share some labels.

d/