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

"Murray S. Kucherawy" <superuser@gmail.com> Mon, 20 May 2013 03:32 UTC

Return-Path: <superuser@gmail.com>
X-Original-To: domainrep@ietfa.amsl.com
Delivered-To: domainrep@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7296921F8F3E for <domainrep@ietfa.amsl.com>; Sun, 19 May 2013 20:32:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.441
X-Spam-Level:
X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlwbZBPCiF4s for <domainrep@ietfa.amsl.com>; Sun, 19 May 2013 20:32:51 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2524121F8F33 for <domainrep@ietf.org>; Sun, 19 May 2013 20:32:48 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id hq7so1699976wib.4 for <domainrep@ietf.org>; Sun, 19 May 2013 20:32:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZWbKZMwOLEp75Xza3CvTGjjZegh0Eg4MpHoGlxYZQTQ=; b=VeBHg+rS4EPZC6YHl2bwykXuj963MZtRTFKjMEj3xVJ7DDROBHgjoCkq29R8oOVxgY kxoClVzxuH1Ax21M61wm8Qg5i8+dGZv4GpRrmjD7iAg8GT51ob4kWaToJ93oDvM54j/V 2lwcWbsFSagGtSuUjjehGsbPkhs+ajKmF3Odjy4wcSxUhrLULxnCUxt4pdTEFBgelUKZ cBqp+A/1B3LAVH+WLX8KDUc2oNJ83RQ4P7SqXb/DCVviTMvLRaS9gnswl/THC9CHvsua gRM0dhwRrkzufsdsObUvXinO9VI3g/598VBN2L6g6W7IFsbFJlCUsAES8x5nbmHn3ZFL e7ug==
MIME-Version: 1.0
X-Received: by 10.180.37.109 with SMTP id x13mr9411358wij.20.1369020767951; Sun, 19 May 2013 20:32:47 -0700 (PDT)
Received: by 10.180.14.34 with HTTP; Sun, 19 May 2013 20:32:47 -0700 (PDT)
In-Reply-To: <51999455.5060903@gmail.com>
References: <51999455.5060903@gmail.com>
Date: Sun, 19 May 2013 20:32:47 -0700
Message-ID: <CAL0qLwYVXBE_oXWBziJ5SYXuTh-Ka+frCAA_X5+SvHknhG91ig@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Dave Crocker <dcrocker@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8f6473f590601904dd1dfce8
Cc: "domainrep@ietf.org" <domainrep@ietf.org>, draft-ietf-repute-email-identifiers.all@tools.ietf.org
Subject: Re: [domainrep] Review of: draft-ietf-repute-email-identifiers-06
X-BeenThere: domainrep@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Domain Reputation discussion list <domainrep.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/domainrep>, <mailto:domainrep-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/domainrep>
List-Post: <mailto:domainrep@ietf.org>
List-Help: <mailto:domainrep-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/domainrep>, <mailto:domainrep-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 May 2013 03:32:52 -0000

On Sun, May 19, 2013 at 8:11 PM, Dave Crocker <dcrocker@gmail.com> wrote:

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

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


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

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