I’ve updated the charter using this suggestion.=

Anyone else, before I ping our AD?

From: Nathaniel Borenstein [mailto:nsb@guppylake.com]=
Sent: Thursday, September 01, 2011 6:36 PM
To: Murray= S. Kucherawy
Cc: domainrep@ietf.org
Subject: Re: [doma= inrep] Charter adjustments

On Aug 31, 2011, = at 2:08 PM, Murray S. Kucherawy wrote:

= This conflates some important things. Portability is irrelevant to me= chanism, for example; it has to do with the choice of the expressed reputat= ion (and is thus part of the vocabulary), not the protocol by which it's de= livered.

I prefer the curren= t text. Is there other feedback?

If you think portability is irrelevant to mechanism, you should c= ompare the design of, say, a portable infant crib with a crib designed to s= tay in one place.

I like the idea of making it clear that the = format's included. How about

"Both the&n= bsp;mechanism and the reputation data type...."

= --_000_F5833273385BB34F99288B3648C4F06F13512DFA34EXCHC2corpclo_-- From msk@cloudmark.com Thu Sep 1 21:48:39 2011 Return-Path: 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 701E121F945B for ; Thu, 1 Sep 2011 21:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.013 X-Spam-Level: X-Spam-Status: No, score=-103.013 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 vFJF3Kfqw52F for ; Thu, 1 Sep 2011 21:48:38 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 6101121F944C for ; Thu, 1 Sep 2011 21:48:38 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 1 Sep 2011 21:50:13 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Thu, 1 Sep 2011 21:50:11 -0700 Thread-Topic: [domainrep] Charter adjustments Thread-Index: AcxpEKxbYECapMJMTsyo2uZCv8EzTgAGuujg Message-ID: References: <4E5DF0A9.1070404@sonnection.nl> <4E5E5682.5090505@sonnection.nl> <361FE09A-ABC4-4C08-A99E-2AA8328ECE27@guppylake.com> In-Reply-To: <361FE09A-ABC4-4C08-A99E-2AA8328ECE27@guppylake.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F13512DFA37EXCHC2corpclo_" MIME-Version: 1.0 Subject: Re: [domainrep] Charter adjustments X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 04:48:39 -0000 --_000_F5833273385BB34F99288B3648C4F06F13512DFA37EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Portability" in this context, as it was used in the BoF, is the idea that = you could ask two different reputation providers the same question, and the= y mean (roughly) the same thing. For example, one doesn't use a linear sca= le from 0 to 1 while the other uses an exponential or logarithmic scale. S= o if you change providers, you shouldn't have to change anything else. Given that definition, the query should be "portable" regardless of whether= it uses the simple or the extended mechanism. From: Nathaniel Borenstein [mailto:nsb@guppylake.com] Sent: Thursday, September 01, 2011 6:36 PM To: Murray S. Kucherawy Cc: domainrep@ietf.org Subject: Re: [domainrep] Charter adjustments On Aug 31, 2011, at 2:08 PM, Murray S. Kucherawy wrote: This conflates some important things. Portability is irrelevant to mechani= sm, for example; it has to do with the choice of the expressed reputation (= and is thus part of the vocabulary), not the protocol by which it's deliver= ed. I prefer the current text. Is there other feedback? If you think portability is irrelevant to mechanism, you should compare the= design of, say, a portable infant crib with a crib designed to stay in one= place. I like the idea of making it clear that the format's included. How about "Both the mechanism and the reputation data type...." --_000_F5833273385BB34F99288B3648C4F06F13512DFA37EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

“Portability” in this context, as it was used in the= BoF, is the idea that you could ask two different reputation providers the= same question, and they mean (roughly) the same thing. For example, = one doesn’t use a linear scale from 0 to 1 while the other uses an ex= ponential or logarithmic scale. So if you change providers, you shoul= dn’t have to change anything else.

Give= n that definition, the query should be “portable” regardless of= whether it uses the simple or the extended mechanism.

On Aug 31, 2011, = at 2:08 PM, Murray S. Kucherawy wrote:

If you think portability is irrelevant to mechanism, you should c= ompare the design of, say, a portable infant crib with a crib designed to s= tay in one place.

I like the idea of making it clear that the = format's included. How about

"Both the&n= bsp;mechanism and the reputation data type...."

= --_000_F5833273385BB34F99288B3648C4F06F13512DFA37EXCHC2corpclo_-- From nsb@guppylake.com Fri Sep 2 11:19:52 2011 Return-Path: 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 64E7221F8C93 for ; Fri, 2 Sep 2011 11:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=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 DaT+xq6TFxeN for ; Fri, 2 Sep 2011 11:19:51 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id 38F4521F858D for ; Fri, 2 Sep 2011 11:19:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=guppylake.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer; b=c3r40+HI/KwiCdU25B3MnQJlNYbRKlpg4Qv406f91DicmimbSTTatxfSHJnpwOUvv66N1zriY99pzb0KXZXGaqVZG1/a05nbeW6ehhM6e+mj7z+0CFkA5sx/oGHiTdZa; Received: from c-68-42-65-200.hsd1.mi.comcast.net ([68.42.65.200] helo=[192.168.2.4]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1QzYMo-0004eA-Ds; Fri, 02 Sep 2011 14:21:26 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-223--474453157 From: Nathaniel Borenstein In-Reply-To: Date: Fri, 2 Sep 2011 14:21:19 -0400 Message-Id: References: <4E5DF0A9.1070404@sonnection.nl> <4E5E5682.5090505@sonnection.nl> <361FE09A-ABC4-4C08-A99E-2AA8328ECE27@guppylake.com> To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server1.netnutz.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - guppylake.com Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Charter adjustments X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 18:19:52 -0000 --Apple-Mail-223--474453157 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I think "portability" means too many things. (It is too portable a = term.) Alternatives: Proportionality. Comparability. Commensurability. I like commensurability -- it's legitimate but rarely used. = Commensurability *is* independent of mechanism, for example. -- = Nathaniel On Sep 2, 2011, at 12:50 AM, Murray S. Kucherawy wrote: > =93Portability=94 in this context, as it was used in the BoF, is the = idea that you could ask two different reputation providers the same = question, and they mean (roughly) the same thing. For example, one = doesn=92t use a linear scale from 0 to 1 while the other uses an = exponential or logarithmic scale. So if you change providers, you = shouldn=92t have to change anything else. > =20 > Given that definition, the query should be =93portable=94 regardless = of whether it uses the simple or the extended mechanism. > =20 > From: Nathaniel Borenstein [mailto:nsb@guppylake.com]=20 > Sent: Thursday, September 01, 2011 6:36 PM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] Charter adjustments > =20 > On Aug 31, 2011, at 2:08 PM, Murray S. Kucherawy wrote: >=20 >=20 > This conflates some important things. Portability is irrelevant to = mechanism, for example; it has to do with the choice of the expressed = reputation (and is thus part of the vocabulary), not the protocol by = which it's delivered. >=20 > I prefer the current text. Is there other feedback? >=20 > =20 > If you think portability is irrelevant to mechanism, you should = compare the design of, say, a portable infant crib with a crib designed = to stay in one place. > =20 > I like the idea of making it clear that the format's included. How = about > =20 > "Both the mechanism and the reputation data type...." > _______________________________________________ > domainrep mailing list > domainrep@ietf.org > https://www.ietf.org/mailman/listinfo/domainrep --Apple-Mail-223--474453157 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I think "portability" means too many things. = (It is too portable a term.) = Alternatives:

Proportionality. = Comparability. Commensurability.

I = like commensurability -- it's legitimate but rarely used. = Commensurability *is* independent of mechanism, for example. = -- Nathaniel

On Sep 2, 2011, at 12:50 = AM, Murray S. Kucherawy wrote:

=93Portability=94 in = this context, as it was used in the BoF, is the idea that you could ask = two different reputation providers the same question, and they mean = (roughly) the same thing. For example, one doesn=92t use a linear = scale from 0 to 1 while the other uses an exponential or logarithmic = scale. So if you change providers, you shouldn=92t have to change = anything else.
Given = that definition, the query should be =93portable=94 regardless of = whether it uses the simple or the extended = mechanism.
Nathaniel= Borenstein [mailto:nsb@guppylake.com]
Sent: Thursday, September 01, = 2011 6:36 PM
To: Murray S. = Kucherawy
Cc: Re: [domainrep] Charter = adjustments
On Aug 31, 2011, at 2:08 = PM, Murray S. Kucherawy wrote:

This conflates some important = things. Portability is irrelevant to mechanism, for example; it = has to do with the choice of the expressed reputation (and is thus part = of the vocabulary), not the protocol by which it's = delivered.

I = prefer the current text. Is there other = feedback?

If you think portability is irrelevant to mechanism, = you should compare the design of, say, a portable infant crib with a = crib designed to stay in one place.

I like the = idea of making it clear that the format's included. How = about
"Both the mechanism = and the reputation data = type...."

______________________________= _________________
domainrep mailing list
domainrep@ietf.org
for domainrep@ietf.org; Sat, 03 Sep 2011 00:26:04 +0200 (CEST) Message-id: <4E6158E5.1010902@sonnection.nl> Date: Sat, 03 Sep 2011 00:29:57 +0200 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.20) Gecko/20110804 Lightning/1.0b2 Thunderbird/3.1.12 To: Nathaniel Borenstein References: <4E5DF0A9.1070404@sonnection.nl> <4E5E5682.5090505@sonnection.nl> <361FE09A-ABC4-4C08-A99E-2AA8328ECE27@guppylake.com> In-reply-to: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1315002365; bh=0K5RYBUkp6q9GNfsmsGfmctKNl9oGgo18F3A514JdMk=; h=MIME-version:Content-type:Message-id:Date:From:To:Cc:Subject: References:In-reply-to; b=EDW7MssH4Usoq/uJMbleuwFbQEcrgYd6Tbt9DoOUNAWY2SYSfBs8RGeC9RomDlvET WYAfUUSBF+pUS9ocjg99OdJLf/pywUlUVR5d5YtQyghmHBn3UTVWodiztbYWBUtZFs UD1nwC5Jg2F4AnW2o3pz4XO+vfCsyepMGCI7Gty8= X-DKIM: OpenDKIM Filter v2.1.3 hydrogen.mailtransaction.com 0LQX00E002BH3200 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Charter adjustments X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 22:24:31 -0000 This is a multi-part message in MIME format. --Boundary_(ID_PoOQLpdemhUzptHcbfsD3g) Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 8BIT On 9/2/11 8:21 PM, Nathaniel Borenstein wrote: > I think "portability" means too many things. (It is too portable a > term.) Alternatives: > > Proportionality. Comparability. Commensurability. > > I like commensurability +1 > -- it's legitimate but rarely used. Commensurability *is* independent > of mechanism, for example. -- Nathaniel > > On Sep 2, 2011, at 12:50 AM, Murray S. Kucherawy wrote: > >> �Portability� in this context, as it was used in the BoF, is the idea >> that you could ask two different reputation providers the same >> question, and they mean (roughly) the same thing. For example, one >> doesn�t use a linear scale from 0 to 1 while the other uses an >> exponential or logarithmic scale. So if you change providers, you >> shouldn�t have to change anything else. >> Given that definition, the query should be �portable� regardless of >> whether it uses the simple or the extended mechanism. Maybe we shouldn't be too concerned about portability/commensurability, as even apples and oranges have more in common than we often think: http://en.wikipedia.org/wiki/Apples_and_oranges#Scientific. So I suggest we'd express reputation in terms/units of apples and oranges, and we have a solid basis to provide portability/commensurability between reputation providers ;-) /rolf --Boundary_(ID_PoOQLpdemhUzptHcbfsD3g) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: 8BIT On 9/2/11 8:21 PM, Nathaniel Borenstein wrote:
I think "portability" means too many things. �(It is too portable a term.) �Alternatives:

Proportionality. �Comparability. �Commensurability.

I like commensurability

+1

-- it's legitimate but rarely used. �Commensurability *is* independent of mechanism, for example. �-- Nathaniel

On Sep 2, 2011, at 12:50 AM, Murray S. Kucherawy wrote:

�Portability� in this context, as it was used in the BoF, is the idea that you could ask two different reputation providers the same question, and they mean (roughly) the same thing.� For example, one doesn�t use a linear scale from 0 to 1 while the other uses an exponential or logarithmic scale.� So if you change providers, you shouldn�t have to change anything else.

�

Given that definition, the query should be �portable� regardless of whether it uses the simple or the extended mechanism.

Maybe we shouldn't be too concerned about portability/commensurability, as even apples and oranges have more in common than we often think: http://en.wikipedia.org/wiki/Apples_and_oranges#Scientific. So I suggest we'd express reputation in terms/units of apples and oranges, and we have a solid basis to provide portability/commensurability between reputation providers ;-)

/rolf
--Boundary_(ID_PoOQLpdemhUzptHcbfsD3g)-- From R.E.Sonneveld@sonnection.nl Fri Sep 2 15:25:08 2011 Return-Path: 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 6F5A721F8DC2 for ; Fri, 2 Sep 2011 15:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.835 X-Spam-Level: X-Spam-Status: No, score=-3.835 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 as0VAXRbqkza for ; Fri, 2 Sep 2011 15:25:07 -0700 (PDT) Received: from mx10.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by ietfa.amsl.com (Postfix) with ESMTP id DD49D21F8DDF for ; Fri, 2 Sep 2011 15:25:06 -0700 (PDT) Received: from process-dkim-sign-daemon.hydrogen.mailtransaction.com by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0LQX00E002BH3200@hydrogen.mailtransaction.com>; Sat, 03 Sep 2011 00:26:43 +0200 (CEST) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0LQX00C032CI4400@hydrogen.mailtransaction.com>; Sat, 03 Sep 2011 00:26:43 +0200 (CEST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_cV6eiF243WfMFQ4oCcBBfw)" Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0LQX00O2P2CIGX00@lion.sonnection.nl> for domainrep@ietf.org; Sat, 03 Sep 2011 00:26:42 +0200 (CEST) Message-id: <4E61590B.8050005@sonnection.nl> Date: Sat, 03 Sep 2011 00:30:35 +0200 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.20) Gecko/20110804 Lightning/1.0b2 Thunderbird/3.1.12 To: "Murray S. Kucherawy" References: <4E5DF0A9.1070404@sonnection.nl> <4E5E5682.5090505@sonnection.nl> <361FE09A-ABC4-4C08-A99E-2AA8328ECE27@guppylake.com> In-reply-to: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1315002403; bh=b4TjWXMXeB6N64s/kSZ3dJzHU4rGFTsdZoLSX5TLSnQ=; h=MIME-version:Content-type:Message-id:Date:From:To:Cc:Subject: References:In-reply-to; b=I+n9LDZM6/oHomHUewDJAPmexsnhL2YBrHCU+WOuY+KC0jIyFO3QxmPnqlzVz0fwd WRCcYL4p4TEFWosLtHPUQ8yg0zIhD9TmI+G9TLg5nYZhb7XxXMWtuX1HVQ1ptKYmWi nGpKvSkT2mPEoMNfEtyE/YykqureEC8urMCTS+fA= X-DKIM: OpenDKIM Filter v2.1.3 hydrogen.mailtransaction.com 0LQX00E002BH3200 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Charter adjustments X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 22:25:08 -0000 This is a multi-part message in MIME format. --Boundary_(ID_cV6eiF243WfMFQ4oCcBBfw) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT On 9/2/11 6:42 AM, Murray S. Kucherawy wrote: > > I've updated the charter using this suggestion. > > Anyone else, before I ping our AD? > > *From:*Nathaniel Borenstein [mailto:nsb@guppylake.com] > *Sent:* Thursday, September 01, 2011 6:36 PM > *To:* Murray S. Kucherawy > *Cc:* domainrep@ietf.org > *Subject:* Re: [domainrep] Charter adjustments > > On Aug 31, 2011, at 2:08 PM, Murray S. Kucherawy wrote: > > > > This conflates some important things. Portability is irrelevant to > mechanism, for example; it has to do with the choice of the expressed > reputation (and is thus part of the vocabulary), not the protocol by > which it's delivered. > > I prefer the current text. Is there other feedback? > > If you think portability is irrelevant to mechanism, you should > compare the design of, say, a portable infant crib with a crib > designed to stay in one place. > > I like the idea of making it clear that the format's included. How about > > "Both the mechanism and the reputation data type...." > WFM /rolf --Boundary_(ID_cV6eiF243WfMFQ4oCcBBfw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On 9/2/11 6:42 AM, Murray S. Kucherawy wrote:

I’ve updated the charter using this suggestion.

Anyone else, before I ping our AD?

From: Nathaniel Borenstein [mailto:nsb@guppylake.com]
Sent: Thursday, September 01, 2011 6:36 PM
To: Murray S. Kucherawy
Cc: domainrep@ietf.org
Subject: Re: [domainrep] Charter adjustments

On Aug 31, 2011, at 2:08 PM, Murray S. Kucherawy wrote:

This conflates some important things. Portability is irrelevant to mechanism, for example; it has to do with the choice of the expressed reputation (and is thus part of the vocabulary), not the protocol by which it's delivered.

I prefer the current text. Is there other feedback?

If you think portability is irrelevant to mechanism, you should compare the design of, say, a portable infant crib with a crib designed to stay in one place.

I like the idea of making it clear that the format's included. How about

"Both the mechanism and the reputation data type...."

WFM

/rolf

--Boundary_(ID_cV6eiF243WfMFQ4oCcBBfw)-- From msk@cloudmark.com Tue Sep 6 15:14:06 2011 Return-Path: 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 59F1621F8F6A for ; Tue, 6 Sep 2011 15:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.511 X-Spam-Level: X-Spam-Status: No, score=-103.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 ePLWvGQKOCjj for ; Tue, 6 Sep 2011 15:14:03 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id E88D221F8DAC for ; Tue, 6 Sep 2011 15:14:00 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 6 Sep 2011 15:15:48 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 6 Sep 2011 15:15:47 -0700 Thread-Topic: Charter going to the IESG Thread-Index: Acxs4odYxkzgyUB5Q5yaej+rOrBWfQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_F5833273385BB34F99288B3648C4F06F13512DFACEEXCHC2corpclo_" MIME-Version: 1.0 Subject: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 22:14:06 -0000 --_004_F5833273385BB34F99288B3648C4F06F13512DFACEEXCHC2corpclo_ Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F13512DFACEEXCHC2corpclo_" --_000_F5833273385BB34F99288B3648C4F06F13512DFACEEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Some further charter adjustment has been made in conversation with the advi= sing AD, potential co-chairs, Nathaniel and myself. The latest version is = attached. It is substantively the same as what you've already seen but nai= ls down a few points while sticking to the feedback that's been sent to the= list recently. It would help the cause if, once again, people gave it a once-over and indi= cated they read this particular version, and made some indication of what r= ole they intend to play as the work progresses (document editor, document r= eviewer, co-chair, implementer, etc.). The IESG will be discussing it on T= hursday (two days from now) so it's important to get as much of such feedba= ck as is possible by then. I remain dedicated to being in any or all of those roles except for co-chai= r, since I'm too close to the material to be able to be effective in that r= ole. Thanks for your patience as the process rumbles along. -MSK --_000_F5833273385BB34F99288B3648C4F06F13512DFACEEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi all,

Some f= urther charter adjustment has been made in conversation with the advising A= D, potential co-chairs, Nathaniel and myself. The latest version is a= ttached. It is substantively the same as what you’ve already se= en but nails down a few points while sticking to the feedback that’s = been sent to the list recently.
&nb= sp;
It would help the cause if, once again, p= eople gave it a once-over and indicated they read this particular version, = and made some indication of what role they intend to play as the work progr= esses (document editor, document reviewer, co-chair, implementer, etc.).&nb= sp; The IESG will be discussing it on Thursday (two days from now) so it= 217;s important to get as much of such feedback as is possible by then.

I= remain dedicated to being in any or all of those roles except for co-chair= , since I’m too close to the material to be able to be effective in t= hat role.

Thanks for your patience as the process rumbles along.

-MSK<= o:p>
= --_000_F5833273385BB34F99288B3648C4F06F13512DFACEEXCHC2corpclo_-- --_004_F5833273385BB34F99288B3648C4F06F13512DFACEEXCHC2corpclo_ Content-Type: text/plain; name="repute-charter.txt" Content-Description: repute-charter.txt Content-Disposition: attachment; filename="repute-charter.txt"; size=5721; creation-date="Tue, 06 Sep 2011 22:14:08 GMT"; modification-date="Tue, 06 Sep 2011 22:11:02 GMT" Content-Transfer-Encoding: base64 V29ya2luZyBHcm91cCBOYW1lOgoJUmVwdXRhdGlvbiBTZXJ2aWNlcyAoUkVQVVRFKQoKSUVURiBB cmVhOgoJQXBwbGljYXRpb25zIEFyZWEKCkNoYWlyKHMpOgoJVEJECgpBcHBsaWNhdGlvbnMgQXJl YSBEaXJlY3RvcihzKToKCVBldGUgUmVzbmljayA8cHJlc25pY2tAcXVhbGNvbW0uY29tPgoJUGV0 ZXIgU2FpbnQtQW5kcmUgPHN0cGV0ZXJAc3RwZXRlci5pbT4KCkFwcGxpY2F0aW9ucyBBcmVhIEFk dmlzb3I6CglQZXRlIFJlc25pY2sgPHByZXNuaWNrQHF1YWxjb21tLmNvbT4KCk1haWxpbmcgTGlz dHM6CglHZW5lcmFsIERpc2N1c3Npb246IHJlcHV0ZUBpZXRmLm9yZwoJVG8gU3Vic2NyaWJlOgkg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yZXB1dGUKCUFyY2hpdmU6 CSAgICBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcmVwdXRlLwoKRGVzY3Jp cHRpb24gb2YgV29ya2luZyBHcm91cDoKCUluIHRoZSBvcGVuIEludGVybmV0LCBtYWtpbmcgYSBt ZWFuaW5nZnVsIGNob2ljZSBhYm91dCB0aGUgaGFuZGxpbmcKCW9mIGNvbnRlbnQgcmVxdWlyZXMg YW4gYXNzZXNzbWVudCBvZiBpdHMgc2FmZXR5IG9yICJ0cnVzdHdvcnRoaW5lc3MiLgoJVGhpcyBp cyBiYXNlZCBvbiBhIHRydXN0IG1ldHJpYyBmb3IgdGhlIG93bmVyIChpZGVudGl0eSkgb2YgYW4K CWlkZW50aWZpZXIgYXNzb2NpYXRlZCB3aXRoIHRoZSBjb250ZW50LCB0byBkaXN0aW5ndWlzaCAo bGlrZWx5KQoJZ29vZCBhY3RvcnMgZnJvbSBiYWQgYWN0b3JzLiAgVGhlIGdlbmVyaWMgdGVybSBm b3Igc3VjaCBpbmZvcm1hdGlvbgoJaXMgInJlcHV0YXRpb24iLiAgVGhpcyB3b3JraW5nIGdyb3Vw IHdpbGwgZGV2ZWxvcCBtZWNoYW5pc21zIGZvcgoJcmVwdXRhdGlvbiByZXBvcnRpbmcgYnkgaW5k ZXBlbmRlbnQgc2VydmljZXMuICBPbmUgbWVjaGFuaXNtIHdpbGwgYmUKCWZvciBhIGJhc2ljIGFz c2Vzc21lbnQgb2YgdHJ1c3R3b3J0aGluZXNzLiAgQW5vdGhlciB3aWxsIHByb3ZpZGUgYQoJcmFu Z2Ugb2YgYXR0cmlidXRlL3ZhbHVlIGRhdGEgdGhhdCBpcyB1c2VkIGFzIGlucHV0IHRvIHN1Y2gg YW4KCWFzc2Vzc21lbnQuICBFYWNoIHNlcnZpY2UgZGV0ZXJtaW5lcyB0aGUgYXR0cmlidXRlcyBp dCByZXBvcnRzLgoKCVZhcmlvdXMgbWVjaGFuaXNtcyBoYXZlIGJlZW4gZGV2ZWxvcGVkIGZvciBh c3NvY2lhdGluZyBhIHZlcmlmaWVkCglpZGVudGlmaWVyIHdpdGggZW1haWwgY29udGVudCwgc3Vj aCBhcyB3aXRoIFNQRiAoUkZDNDQwOCkgYW5kIERLSU0KCShSRkM0ODcxKS4gIEFuIGV4aXN0aW5n IHJlcHV0YXRpb24gcXVlcnkgbWVjaGFuaXNtIGlzCglWb3VjaC1ieS1SZWZlcmVuY2UgKFJGQzU1 MTgpLiBJdCBwcm92aWRlcyBhIHNpbXBsZSBCb29sZWFuCglyZXNwb25zZSBjb25jZXJuaW5nIGEg ZG9tYWluIG5hbWUgdXNlZCBmb3IgZW1haWwuICBUaGUgY3VycmVudCB3b3JraW5nCglncm91cCBl ZmZvcnQgd2lsbCBleHBhbmQgdXBvbiB0aGlzLCB0byBzdXBwb3J0IGFkZGl0aW9uYWwKCWFwcGxp Y2F0aW9ucyAtLSBzdWNoIGFzIFdlYiBwYWdlcyBhbmQgaG9zdHMgLS0gYW5kIGEgd2lkZXIgcmFu Z2Ugb2YKCXJlcG9ydGluZyBpbmZvcm1hdGlvbi4KCglHaXZlbiB0aGUgcmVjZW50IGFkb3B0aW9u IG9mIGRvbWFpbiBuYW1lIHZlcmlmaWNhdGlvbiBmb3IgZW1haWwsCglieSBTUEYgYW5kIERLSU0s IHRoZSBtb3N0IG9idmlvdXMgaW5pdGlhbCB1c2UgY2FzZSBmb3IgcmVwdXRhdGlvbiBpcwoJZm9y IGVtYWlsLiAgSW5ib3VuZCBlbWFpbCBmaWx0ZXJzIHRoYXQgcGVyZm9ybSBtZXNzYWdlIGF1dGhl bnRpY2F0aW9uCgljYW4gb2J0YWluIGEgdmVyaWZpZWQgZG9tYWluIG5hbWUgYW5kIHRoZW4gY29u c3VsdCBhIHJlcHV0YXRpb24gc2VydmljZQoJcHJvdmlkZXIgdG8gbWFrZSBhIGRldGVybWluYXRp b24gKHBlcmhhcHMgYWxzbyBiYXNlZCBvbiBvdGhlcgoJZmFjdG9ycykgb2Ygd2hldGhlciBvciBu b3QgdGhlIGNvbnRlbnQgaXMgZGVzaXJhYmxlIGFuZCB0YWtlCglhcHByb3ByaWF0ZSBhY3Rpb24g d2l0aCByZXNwZWN0IHRvIGRlbGl2ZXJ5LCByb3V0aW5nIG9yIHJlamVjdGlvbi4KCQoJQW5vdGhl ciBwb3NzaWJsZSB1c2UgY2FzZSBpcyBpZGVudGl0eS1iYXNlZCBldmFsdWF0aW9uIG9mIHdlYgoJ Y29udGVudCB1c2luZyB0ZWNobm9sb2dpZXMgc3VjaCBhcyB0aGUgREtJTS1kZXJpdmVkIERPU0VU QQoJKHdvcmsgaW4gcHJvZ3Jlc3MpLgoKCVRoaXMgd29ya2luZyBncm91cCB3aWxsIHByb2R1Y2Ug c3BlY2lmaWNhdGlvbnMgZm9yOgoKCSAgICogdGhlIGRldGFpbGVkIHJlcXVpcmVtZW50cyBmb3Ig cmVwb3J0aW5nCgoJICAgKiBhbiBlbmQtdG8tZW5kIHN5c3RlbSBhcmNoaXRlY3R1cmUgaW4gd2hp Y2ggcmVwb3J0aW5nIG9jY3VycwoKCSAgICogdGhlIG1lY2hhbmlzbXMgYW5kIGZvcm1hdHMgZm9y IHJlcG9ydGluZwoKCVR3byBtZWNoYW5pc21zIGFyZSB1bmRlciBjb25zaWRlcmF0aW9uOgoKCSAg ICogc2ltcGxlIC0tIGEgcmVwdXRhdGlvbiBpcyBleHByZXNzZWQgaW4gYSBzaW1wbGUgbWFubmVy LAoJICAgICAgICAgICAgICAgdmlhIHJlY29yZHMgaW4gdGhlIEROUwoJCSAgICAgICAoc2VlIGRy YWZ0LWt1Y2hlcmF3eS1yZXB1dGF0aW9uLXF1ZXJ5LWRucykKCgkgICAqIGV4dGVuZGVkIC0tIGEg cmVzcG9uc2UgY2FuIGNvbnRhaW4gbW9yZSBjb21wbGV4IGluZm9ybWF0aW9uCgkJICAgICAgICAg dXNlZnVsIHRvIGFuIGFzc2Vzc29yLCByZXBvcnRlZCBvdmVyIEhUVFAgdXNpbmcKCSAgICAgICAg ICAgICAgICAgYW4gZW5jb2Rpbmcgc3VjaCBhcyBYTUwgb3IgSlNPTgoJCSAgICAgICAgIChzZWUg ZHJhZnQta3VjaGVyYXd5LXJlcHV0YXRpb24tcXVlcnktaHR0cCkKCglUaGUgc3ludGFjdGljIGFu ZCBzZW1hbnRpYyBhc3BlY3RzIG9mIG1lY2hhbmlzbXMgYW5kIGZvcm1hdHMgd2lsbCBiZQoJZGVz aWduZWQgdG8gYmUgYXBwbGljYXRpb24taW5kZXBlbmRlbnQgYW5kIHBvcnRhYmxlIChpLmUuLCBy ZXB1dGF0aW9uCglwcm92aWRlci1pbmRlcGVuZGVudCkuICBCeSBkaXN0aW5ndWlzaGluZyByZXBv cnRpbmcgaW5mb3JtYXRpb24KCShmb3JtYXQpIGZyb20gcmVwb3J0aW5nIG1lY2hhbmlzbSAoY2hh bm5lbCksIHRoZSBzcGVjaWZpY2F0aW9ucwoJd2lsbCBwZXJtaXQgYWRhcHRhdGlvbiB0byBzdXBw b3J0IHJlcG9ydGluZyB0aHJvdWdoIGFkZGl0aW9uYWwKCWNoYW5uZWxzLiAgTGltaXRlZCBhcHBs aWNhdGlvbi1zcGVjaWZpYyB0YWlsb3Jpbmcgd2lsbCBiZQoJcHJvdmlkZWQgZm9yIGVtYWlsLCB0 byBkZW1vbnN0cmF0ZSB0aGUgYXBwcm9hY2gsIHdoaWNoIGNhbiBiZQoJYXBwbGllZCBmb3Igc3Vw cG9ydHRpbmcgYWRkaXRpb25hbCBhcHBsaWNhdGlvbnMuICBUaGUgZGVzaWduIGFuZAoJc3BlY2lm aWNhdGlvbiB3aWxsIGFsc28gcGVybWl0IGFkYXB0YXRpb24gdG8gc3VwcG9ydCByZXBvcnRpbmcK CXRocm91Z2ggYWRkaXRpb25hbCB0cmFuc3BvcnQgY2hhbm5lbHMuCgoJSXRlbXMgdGhhdCBhcmUg c3BlY2lmaWNhbGx5IG91dCBvZiBzY29wZSBmb3IgdGhpcyB3b3JrOgoKCSAgICogU3BlY2lmaWMg YWN0aW9ucyB0byBiZSB0YWtlbiBpbiByZXNwb25zZSB0byBhIHJlcHV0YXRpb24gcmVwbHkuCgkg ICAgIEl0IGlzIHVwIHRvIGFzc2Vzc29ycyAoaS5lLiwgdGhlIGNvbnN1bWVycyBvZiByZXB1dGF0 aW9uIGRhdGEpCgkgICAgIHRvIGRldGVybWluZSB0aGlzLiAgTm9uLW5vcm1hdGl2ZSBpbGx1c3Ry YXRpb25zLCBob3dldmVyLCBjYW4KICAgICAgICAgICAgIGJlIGluY2x1ZGVkIHRvIGRlbW9uc3Ry YXRlIHBvc3NpYmxlIHVzZXMgb2YgcmVwdXRhdGlvbiBkYXRhCgkgICAgIGluIGEgcGFydGljdWxh ciBjb250ZXh0LgoKCSAgICogU2VsZWN0aW9uIG9mIHdoYXQgZGF0YSBtaWdodCBiZSB2YWxpZCBh cyB0aGUgc3ViamVjdCBvZiBhCgkgICAgIHJlcHV0YXRpb24gcXVlcnkuICBJdCBpcyB1cCB0byBy ZXB1dGF0aW9uIHNlcnZpY2UgcHJvdmlkZXJzIGFuZAoJICAgICBhc3Nlc3NvcnMgdG8gc2VsZWN0 IHdoaWNoIHF1YWxpdGllcyBvZiBhIGJvZHkgb2YgZGF0YSBtaWdodAoJICAgICBiZSB1c2VmdWwg aW5wdXQgdG8gcmVwdXRhdGlvbiBldmFsdWF0aW9uLgoKCSAgICogQ29uY2VybnMgYWJvdXQgbWV0 aG9kcyBvZiB2ZXJpZnlpbmcgZG9tYWluIG5hbWVzIHRoYXQgYXJlIHVzZWQKCSAgICAgZm9yIGVt YWlsIHJlcHV0YXRpb24uICBBIHZlcmlmaWVkIGRvbWFpbiBuYW1lIGlzIGEgc3RhcnRpbmcgcG9p bnQKCSAgICAgZm9yIHRoaXMgd29yazsgdGhlIG1lYW5zIGJ5IHdoaWNoIGl0IHdhcyBvYnRhaW5l ZCBhbmQgdGhlCgkgICAgICJtZWFuaW5nIiBvZiB0aGUgbmFtZSBvciBpdHMgdmVyaWZpY2F0aW9u IGFyZSBtYXR0ZXJzIGZvcgoJICAgICBkaXNjdXNzaW9uIGVsc2V3aGVyZS4KCgkgICAqIEFsZ29y aXRobXMgdG8gYmUgYXBwbGllZCB0byBhZ2dyZWdhdGVkIGZlZWRiYWNrIGluIG9yZGVyIHRvCgkg ICAgIGNvbXB1dGUgcmVwdXRhdGlvbnMuICBUaGVzZSBhcmUgcGFydCBvZiBhIGJhY2stZW5kIHN5 c3RlbSwgdXN1YWxseQoJICAgICBwcm9wcmlldGFyeSwgYW5kIG5vdCBhcHByb3ByaWF0ZSBmb3Ig c3BlY2lmaWNhdGlvbiBhcyBwYXJ0IG9mCgkgICAgIGEgcXVlcnkvcmVwbHkgZnJhbWV3b3JrIGFu ZCBwcm90b2NvbC4KCglUaGUgaW5pdGlhbCBkcmFmdCBzZXQ6CgkJZHJhZnQta3VjaGVyYXd5LXJl cHV0YXRpb24tbW9kZWwKCQlkcmFmdC1rdWNoZXJhd3ktcmVwdXRhdGlvbi1tZWRpYS10eXBlCgkJ ZHJhZnQta3VjaGVyYXd5LXJlcHV0YXRpb24tcXVlcnktaHR0cAoJCWRyYWZ0LWt1Y2hlcmF3eS1y ZXB1dGF0aW9uLXF1ZXJ5LWRucwoJCWRyYWZ0LWt1Y2hlcmF3eS1yZXB1dGF0aW9uLXF1ZXJ5LXVk cAoJCWRyYWZ0LWt1Y2hlcmF3eS1yZXB1dGF0aW9uLXZvY2FiLWlkZW50aXR5CgpHb2FscyBhbmQg TWlsZXN0b25lczoKCU1hciAyMDEyOglJbmZvcm1hdGlvbmFsIGRvY3VtZW50LCBkZWZpbmluZyB0 aGUgcHJvYmxlbSBzcGFjZQoJCQlhbmQgc29sdXRpb24gYXJjaGl0ZWN0dXJlLCB0byB0aGUgSUVT RyBmb3IgcHVibGljYXRpb24uCgoJTWFyIDIwMTI6CVNwZWNpZmljYXRpb24gZm9yIHRoZSBtdWx0 aS1hdHRyaWJ1dGUgcmVwb3J0aW5nCgkJCWRhdGEgc3RydWN0dXJlLCB0byB0aGUgSUVTRyBmb3Ig cHVibGljYXRpb24uCgoJTWF5IDIwMTI6CUluZm9ybWF0aW9uYWwgZG9jdW1lbnQsIGRlZmluaW5n IHRoZSB2b2NhYnVsYXJ5CgkJCWZvciBwcm92aWRpbmcgcmVwdXRhdGlvbiBpbiB0aGUgZW1haWwg c3BoZXJlLCB0byB0aGUKCQkJSUVTRyBmb3IgcHVibGljYXRpb24uCgoJSnVsIDIwMTI6ICAJU3Bl Y2lmaWNhdGlvbiBkZWZpbmluZyB0aGUgc2ltcGxlCgkJCXF1ZXJ5IG1lY2hhbmlzbSwgdG8gdGhl IElFU0cgZm9yIHB1YmxpY2F0aW9uLgoKCUp1bCAyMDEyOiAgCVNwZWNpZmljYXRpb24gZm9yIHRo ZSBleHRlbmRlZAoJCQlxdWVyeSBtZWNoYW5pc20sIHRvIHRoZSBJRVNHIGZvciBwdWJsaWNhdGlv bi4KCglPY3QgMjAxMjogIAlJbmZvcm1hdGlvbmFsIGRvY3VtZW50LCBkaXNjdXNzaW5nIGlzc3Vl cwoJCQlvZiBkYXRhIHRyYW5zcGFyZW5jeSwgcmVkcmVzcywgbWV0YS1yZXB1dGF0aW9uCgkJCWFu ZCBvdGhlciBpbXBvcnRhbnQgb3BlcmF0aW9uYWwgY29uc2lkZXJhdGlvbnMsIHRvIHRoZQoJCQlJ RVNHIGZvciBwdWJsaWNhdGlvbi4K --_004_F5833273385BB34F99288B3648C4F06F13512DFACEEXCHC2corpclo_-- From ajs@anvilwalrusden.com Tue Sep 6 19:11:17 2011 Return-Path: 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 E93F921F8B9F for ; Tue, 6 Sep 2011 19:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] 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 Fzh6bcbAog0Y for ; Tue, 6 Sep 2011 19:11:17 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id E45F921F8B9B for ; Tue, 6 Sep 2011 19:11:16 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 4DD141ECB41D for ; Wed, 7 Sep 2011 02:13:03 +0000 (UTC) Date: Tue, 6 Sep 2011 22:13:02 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20110907021302.GC34836@crankycanuck.ca> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 02:11:18 -0000 >From the subscribed address this time: I have read this. Like the previous drafts, I am ok with it. I plan to review things. (I am not at all convinced that the DNS is a good fit for this, and I have particular reservations about the mechanism proposed, but I think that is a discussion for the WG to have once it has a charter. That topic should definitely be in.) A On Tue, Sep 06, 2011 at 03:15:47PM -0700, Murray S. Kucherawy wrote: > Hi all, > > Some further charter adjustment has been made in conversation with the advising AD, potential co-chairs, Nathaniel and myself. The latest version is attached. It is substantively the same as what you've already seen but nails down a few points while sticking to the feedback that's been sent to the list recently. > > It would help the cause if, once again, people gave it a once-over and indicated they read this particular version, and made some indication of what role they intend to play as the work progresses (document editor, document reviewer, co-chair, implementer, etc.). The IESG will be discussing it on Thursday (two days from now) so it's important to get as much of such feedback as is possible by then. > > I remain dedicated to being in any or all of those roles except for co-chair, since I'm too close to the material to be able to be effective in that role. > > Thanks for your patience as the process rumbles along. > > -MSK > Working Group Name: > Reputation Services (REPUTE) > > IETF Area: > Applications Area > > Chair(s): > TBD > > Applications Area Director(s): > Pete Resnick > Peter Saint-Andre > > Applications Area Advisor: > Pete Resnick > > Mailing Lists: > General Discussion: repute@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/repute > Archive: http://www.ietf.org/mail-archive/web/repute/ > > Description of Working Group: > In the open Internet, making a meaningful choice about the handling > of content requires an assessment of its safety or "trustworthiness". > This is based on a trust metric for the owner (identity) of an > identifier associated with the content, to distinguish (likely) > good actors from bad actors. The generic term for such information > is "reputation". This working group will develop mechanisms for > reputation reporting by independent services. One mechanism will be > for a basic assessment of trustworthiness. Another will provide a > range of attribute/value data that is used as input to such an > assessment. Each service determines the attributes it reports. > > Various mechanisms have been developed for associating a verified > identifier with email content, such as with SPF (RFC4408) and DKIM > (RFC4871). An existing reputation query mechanism is > Vouch-by-Reference (RFC5518). It provides a simple Boolean > response concerning a domain name used for email. The current working > group effort will expand upon this, to support additional > applications -- such as Web pages and hosts -- and a wider range of > reporting information. > > Given the recent adoption of domain name verification for email, > by SPF and DKIM, the most obvious initial use case for reputation is > for email. Inbound email filters that perform message authentication > can obtain a verified domain name and then consult a reputation service > provider to make a determination (perhaps also based on other > factors) of whether or not the content is desirable and take > appropriate action with respect to delivery, routing or rejection. > > Another possible use case is identity-based evaluation of web > content using technologies such as the DKIM-derived DOSETA > (work in progress). > > This working group will produce specifications for: > > * the detailed requirements for reporting > > * an end-to-end system architecture in which reporting occurs > > * the mechanisms and formats for reporting > > Two mechanisms are under consideration: > > * simple -- a reputation is expressed in a simple manner, > via records in the DNS > (see draft-kucherawy-reputation-query-dns) > > * extended -- a response can contain more complex information > useful to an assessor, reported over HTTP using > an encoding such as XML or JSON > (see draft-kucherawy-reputation-query-http) > > The syntactic and semantic aspects of mechanisms and formats will be > designed to be application-independent and portable (i.e., reputation > provider-independent). By distinguishing reporting information > (format) from reporting mechanism (channel), the specifications > will permit adaptation to support reporting through additional > channels. Limited application-specific tailoring will be > provided for email, to demonstrate the approach, which can be > applied for supportting additional applications. The design and > specification will also permit adaptation to support reporting > through additional transport channels. > > Items that are specifically out of scope for this work: > > * Specific actions to be taken in response to a reputation reply. > It is up to assessors (i.e., the consumers of reputation data) > to determine this. Non-normative illustrations, however, can > be included to demonstrate possible uses of reputation data > in a particular context. > > * Selection of what data might be valid as the subject of a > reputation query. It is up to reputation service providers and > assessors to select which qualities of a body of data might > be useful input to reputation evaluation. > > * Concerns about methods of verifying domain names that are used > for email reputation. A verified domain name is a starting point > for this work; the means by which it was obtained and the > "meaning" of the name or its verification are matters for > discussion elsewhere. > > * Algorithms to be applied to aggregated feedback in order to > compute reputations. These are part of a back-end system, usually > proprietary, and not appropriate for specification as part of > a query/reply framework and protocol. > > The initial draft set: > draft-kucherawy-reputation-model > draft-kucherawy-reputation-media-type > draft-kucherawy-reputation-query-http > draft-kucherawy-reputation-query-dns > draft-kucherawy-reputation-query-udp > draft-kucherawy-reputation-vocab-identity > > Goals and Milestones: > Mar 2012: Informational document, defining the problem space > and solution architecture, to the IESG for publication. > > Mar 2012: Specification for the multi-attribute reporting > data structure, to the IESG for publication. > > May 2012: Informational document, defining the vocabulary > for providing reputation in the email sphere, to the > IESG for publication. > > Jul 2012: Specification defining the simple > query mechanism, to the IESG for publication. > > Jul 2012: Specification for the extended > query mechanism, to the IESG for publication. > > Oct 2012: Informational document, discussing issues > of data transparency, redress, meta-reputation > and other important operational considerations, to the > IESG for publication. > _______________________________________________ > domainrep mailing list > domainrep@ietf.org > https://www.ietf.org/mailman/listinfo/domainrep -- Andrew Sullivan ajs@crankycanuck.ca From dhc@dcrocker.net Tue Sep 6 20:44:12 2011 Return-Path: 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 D90F121F8D70 for ; Tue, 6 Sep 2011 20:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 guoMfhcpnkt1 for ; Tue, 6 Sep 2011 20:44:12 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 12ADB21F8D61 for ; Tue, 6 Sep 2011 20:44:12 -0700 (PDT) Received: from [192.168.1.5] (adsl-68-122-32-32.dsl.pltn13.pacbell.net [68.122.32.32]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p873jqx8000978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 20:45:58 -0700 Message-ID: <4E66E8EE.9060402@dcrocker.net> Date: Tue, 06 Sep 2011 20:45:50 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Andrew Sullivan References: <20110907021302.GC34836@crankycanuck.ca> In-Reply-To: <20110907021302.GC34836@crankycanuck.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 06 Sep 2011 20:45:59 -0700 (PDT) Cc: domainrep@ietf.org Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 03:44:13 -0000 On 9/6/2011 7:13 PM, Andrew Sullivan wrote: >> From the subscribed address this time: I have read this. Like the > previous drafts, I am ok with it. I plan to review things. Excellent. > (I am not > at all convinced that the DNS is a good fit for this, And yet I believe you have heard of the RBL and know of its importance to anti-spam operations. Given it's history, what's the problem with the 'fit'? > and I have > particular reservations about the mechanism proposed, Formally, there are two, one for the quick-answer mode and another for the more extensive query and answer. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ajs@anvilwalrusden.com Wed Sep 7 04:35:05 2011 Return-Path: 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 5FBA221F8BB6 for ; Wed, 7 Sep 2011 04:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] 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 mjVg7lrPYuQD for ; Wed, 7 Sep 2011 04:35:05 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id E575221F8B8C for ; Wed, 7 Sep 2011 04:35:04 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 424F41ECB41D for ; Wed, 7 Sep 2011 11:36:52 +0000 (UTC) Date: Wed, 7 Sep 2011 07:36:48 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20110907113648.GA35008@shinkuro.com> References: <20110907021302.GC34836@crankycanuck.ca> <4E66E8EE.9060402@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E66E8EE.9060402@dcrocker.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 11:35:05 -0000 On Tue, Sep 06, 2011 at 08:45:50PM -0700, Dave CROCKER wrote: > And yet I believe you have heard of the RBL and know of its > importance to anti-spam operations. Given it's history, what's the > problem with the 'fit'? Since we don't have a charter yet, I'm not sure that now's the time to debate this. But briefly: RBLs use the DNS differently to express their data. (That particular approach also has problems, as discussed in the past, but never mind that.) The basic problem seems to be that the current approach wants to use the DNS as the transport for metadata about the DNS itself, and the reasoning for certain choices in the existing draft boils down to a complaint about the way the DNS works as actually deployed. If you can't get the DNS to do what you want without abusing its design, that's an indication that maybe it doesn't do what you need after all. A -- Andrew Sullivan ajs@anvilwalrusden.com From R.E.Sonneveld@sonnection.nl Wed Sep 7 05:18:48 2011 Return-Path: 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 4A5BA21F8C1D for ; Wed, 7 Sep 2011 05:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.887 X-Spam-Level: X-Spam-Status: No, score=-2.887 tagged_above=-999 required=5 tests=[AWL=-1.148, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 SispUBMRgb50 for ; Wed, 7 Sep 2011 05:18:47 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id A8A1F21F8C09 for ; Wed, 7 Sep 2011 05:18:46 -0700 (PDT) Received: from process-dkim-sign-daemon.helium.mailtransaction.com by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0LR500C00JFYIL00@helium.mailtransaction.com>; Wed, 07 Sep 2011 14:20:32 +0200 (CEST) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0LR500HLLJM8H300@helium.mailtransaction.com>; Wed, 07 Sep 2011 14:20:32 +0200 (CEST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_b/dsR9sr0IRSl9g0pE3AEQ)" Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0LR500N0VJM84G00@lion.sonnection.nl> for domainrep@ietf.org; Wed, 07 Sep 2011 14:20:32 +0200 (CEST) Message-id: <4E67627C.8060409@sonnection.nl> Date: Wed, 07 Sep 2011 14:24:28 +0200 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 To: "Murray S. Kucherawy" References: In-reply-to: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1315398032; bh=EUm0RU/wo+gT5rmRpkGJUdObhfCIiNk9nk1NFD+rnqs=; h=MIME-version:Content-type:Message-id:Date:From:To:Cc:Subject: References:In-reply-to; b=ng4sZ2JoU+4ckfgBfrKvp3FVW8XD+c6Un97Y3joZsSZFvJmc0BMe/rJfG83NUXXUm qYP6m9nHRnb/fnStgs2Gy+SNZhCzUwUcohnLbNpCPYZ8PqCK4trs+pmpp1vOeRV173 VMVf3TjB6woQOzaYNtLZQSJQOpLDT3JBO6NCY44s= X-DKIM: OpenDKIM Filter v2.1.3 helium.mailtransaction.com 0LR500C00JFYIL00 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 12:18:48 -0000 This is a multi-part message in MIME format. --Boundary_(ID_b/dsR9sr0IRSl9g0pE3AEQ) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT On 9/7/11 12:15 AM, Murray S. Kucherawy wrote: > > Hi all, > > Some further charter adjustment has been made in conversation with the > advising AD, potential co-chairs, Nathaniel and myself. The latest > version is attached. It is substantively the same as what you've > already seen but nails down a few points while sticking to the > feedback that's been sent to the list recently. > > It would help the cause if, once again, people gave it a once-over and > indicated they read this particular version, and made some indication > of what role they intend to play as the work progresses (document > editor, document reviewer, co-chair, implementer, etc.). The IESG > will be discussing it on Thursday (two days from now) so it's > important to get as much of such feedback as is possible by then. > > I remain dedicated to being in any or all of those roles except for > co-chair, since I'm too close to the material to be able to be > effective in that role. > > Thanks for your patience as the process rumbles along. > Charter OK. Available for review and/or document editor. /rolf --Boundary_(ID_b/dsR9sr0IRSl9g0pE3AEQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On 9/7/11 12:15 AM, Murray S. Kucherawy wrote:

Hi all,

Some further charter adjustment has been made in conversation with the advising AD, potential co-chairs, Nathaniel and myself. The latest version is attached. It is substantively the same as what you’ve already seen but nails down a few points while sticking to the feedback that’s been sent to the list recently.

It would help the cause if, once again, people gave it a once-over and indicated they read this particular version, and made some indication of what role they intend to play as the work progresses (document editor, document reviewer, co-chair, implementer, etc.). The IESG will be discussing it on Thursday (two days from now) so it’s important to get as much of such feedback as is possible by then.

I remain dedicated to being in any or all of those roles except for co-chair, since I’m too close to the material to be able to be effective in that role.

Thanks for your patience as the process rumbles along.

Charter OK. Available for review and/or document editor.

/rolf
--Boundary_(ID_b/dsR9sr0IRSl9g0pE3AEQ)-- From dhc@dcrocker.net Wed Sep 7 06:23:10 2011 Return-Path: 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 EE6C221F8C31 for ; Wed, 7 Sep 2011 06:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.436 X-Spam-Level: X-Spam-Status: No, score=-6.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vI2yCLe1kGcW for ; Wed, 7 Sep 2011 06:23:05 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B2FE121F8BC4 for ; Wed, 7 Sep 2011 06:23:05 -0700 (PDT) Received: from [192.168.1.7] (adsl-68-122-32-32.dsl.pltn13.pacbell.net [68.122.32.32]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p87DOkaC013019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 06:24:51 -0700 Message-ID: <4E677093.8010208@dcrocker.net> Date: Wed, 07 Sep 2011 06:24:35 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Andrew Sullivan References: <20110907021302.GC34836@crankycanuck.ca> <4E66E8EE.9060402@dcrocker.net> <20110907113648.GA35008@shinkuro.com> In-Reply-To: <20110907113648.GA35008@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 07 Sep 2011 06:24:53 -0700 (PDT) Cc: domainrep@ietf.org Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 13:23:10 -0000 Andrew, On 9/7/2011 4:36 AM, Andrew Sullivan wrote: > RBLs use the DNS differently to express their data. (That particular > approach also has problems, as discussed in the past, but never mind > that.) The comparison wasn't meant to be precise to the level of formats, but about the basic model. You are expressing a very basic concern and, so, I was offering a very basic comparison that seems to me to counter your concern. > The basic problem seems to be that the current approach wants to use > the DNS as the transport for metadata about the DNS itself, I don't understand. > and the > reasoning for certain choices in the existing draft boils down to a > complaint about the way the DNS works as actually deployed. I don't understand. > If you > can't get the DNS to do what you want without abusing its design, > that's an indication that maybe it doesn't do what you need after all. What, in particular, is an "abuse" of the DNS' design? As I understand the current draft specifications, they call upon techniques that are already in production use and for a type of service that is not merely "in use" but is in fact already essential to the conduct of a massively popular Internet service. Since your concern appears to be about the fundamentals of the proposed work, I'm seeking explanation in enough detail to permit serious evaluation of your concern. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ajs@anvilwalrusden.com Wed Sep 7 06:41:28 2011 Return-Path: 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 AF31521F8B14 for ; Wed, 7 Sep 2011 06:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] 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 Q82kQbkmUS1D for ; Wed, 7 Sep 2011 06:41:28 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB6821F8AF1 for ; Wed, 7 Sep 2011 06:41:28 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 88CE31ECB41D for ; Wed, 7 Sep 2011 13:43:15 +0000 (UTC) Date: Wed, 7 Sep 2011 09:43:11 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20110907134311.GA35152@shinkuro.com> References: <20110907021302.GC34836@crankycanuck.ca> <4E66E8EE.9060402@dcrocker.net> <20110907113648.GA35008@shinkuro.com> <4E677093.8010208@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E677093.8010208@dcrocker.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 13:41:28 -0000 On Wed, Sep 07, 2011 at 06:24:35AM -0700, Dave CROCKER wrote: > >The basic problem seems to be that the current approach wants to use > >the DNS as the transport for metadata about the DNS itself, > > I don't understand. Yes, I know, but I've been unable to figure out over time whether that is out of willfullness on your part or out of my failure to explain it clearly enough. Or, perhaps, both. Nevertheless, as I already suggested, I would prefer to wait for the charter before having more debates about substance, because in my experience such disagreements about the substance can sometimes be misconstrued as disagreements about whether the very topic ought to be considered. To be explicit, I argue that the topic should be on-charter even if I have reservations about actually doing what is implied in the charter item. A -- Andrew Sullivan ajs@anvilwalrusden.com From dhc@dcrocker.net Wed Sep 7 07:17:49 2011 Return-Path: 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 A271721F8BE5 for ; Wed, 7 Sep 2011 07:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 arGzqLO7Z2I4 for ; Wed, 7 Sep 2011 07:17:48 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id EA36721F8B94 for ; Wed, 7 Sep 2011 07:17:48 -0700 (PDT) Received: from [192.168.1.7] (adsl-68-122-32-32.dsl.pltn13.pacbell.net [68.122.32.32]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p87EJVua014284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 07:19:37 -0700 Message-ID: <4E677D69.4080903@dcrocker.net> Date: Wed, 07 Sep 2011 07:19:21 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Andrew Sullivan References: <20110907021302.GC34836@crankycanuck.ca> <4E66E8EE.9060402@dcrocker.net> <20110907113648.GA35008@shinkuro.com> <4E677093.8010208@dcrocker.net> <20110907134311.GA35152@shinkuro.com> In-Reply-To: <20110907134311.GA35152@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 07 Sep 2011 07:19:37 -0700 (PDT) Cc: domainrep@ietf.org Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 14:17:49 -0000 On 9/7/2011 6:43 AM, Andrew Sullivan wrote: > On Wed, Sep 07, 2011 at 06:24:35AM -0700, Dave CROCKER wrote: > >>> The basic problem seems to be that the current approach wants to use >>> the DNS as the transport for metadata about the DNS itself, >> >> I don't understand. > > Yes, I know, but I've been unable to figure out over time whether that > is out of willfullness on your part or out of my failure to explain it > clearly enough. Or, perhaps, both. I was soliciting explanation. You gave a terse tag line and I'm asking for more detail. I believe one of the continuing sources of dissonance in the IETF is the tendency to utter labels or catch phrases rather than offering the underlying detail. Since one listener's interpretation of those labels and phrases is often quite different from the speaker's, the exchange begins with a lack of shared reference. I'm asking for enough detail to permit shared reference. > Nevertheless, as I already suggested, I would prefer to wait for the > charter before having more debates about substance, because in my Again, I don't understand. The thing being circulated /is/ the charter that is being submitted to the IESG. > experience such disagreements about the substance can sometimes be > misconstrued as disagreements about whether the very topic ought to be > considered. To be explicit, I argue that the topic should be > on-charter even if I have reservations about actually doing what is > implied in the charter item. What you expressed sounded like fundamental concerns to me. That makes them worth understanding earlier, rather than later. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@resistor.net Wed Sep 7 11:44:00 2011 Return-Path: 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 D462321F8C96 for ; Wed, 7 Sep 2011 11:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ezbkOqeKpS1H for ; Wed, 7 Sep 2011 11:43:59 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D082421F8C93 for ; Wed, 7 Sep 2011 11:43:59 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p87IjfVP014154 for ; Wed, 7 Sep 2011 11:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1315421149; bh=cUWY385OpKsKkQah3qM9pJWhUKoONODJcws1vpgzhcg=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=2zavWdk6nvJ7Gser95wDoZp7Gf8z5l7nuaZBbpymVpsaldM+fA4zag9TaaFJulDfO 45dXQRtIA/wO9x3BNdj9IWx8MxRoPqjRTTpvcSQVvgOrvtWlZ+wbysxXhnjt8fL/8N Hy1GWSZGReVhOQEHWBW5N05bvyZBDYme05+blJ30= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1315421149; bh=cUWY385OpKsKkQah3qM9pJWhUKoONODJcws1vpgzhcg=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=GjS9ESQ89jDE23/LYyoD/T9UPdQJpSAirGu4z3e9lOB7kUKoPwB+eO274p1ngufLb La3HzhGwG2QiPS4rssyAu9MK/vc9vpc2grV0zBLrE88Kh6TJp663Sua+VkpYLtjbf7 7NPXiq2oxQESXxPpzBSgD8OOFVJ9Ot1pJGHCoFwI= Message-Id: <6.2.5.6.2.20110907113904.0738bc70@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 07 Sep 2011 11:44:17 -0700 To: domainrep@ietf.org From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 18:44:00 -0000 At 15:15 06-09-2011, Murray S. Kucherawy wrote: >Some further charter adjustment has been made in conversation with >the advising AD, The proposed charter looks fine. >It would help the cause if, once again, people gave it a once-over >and indicated they read this particular version, and made some >indication of what role they intend to play as the work progresses >(document editor, document reviewer, co-chair, implementer, >etc.). The IESG will be discussing it on Thursday (two days from >now) so it's important to get as much of such feedback as is possible by then. I'll do some reviews. It's likely that I may implement some of the specifications. I am open to being document editor. Regards, -sm From dotis@mail-abuse.org Wed Sep 7 17:16:20 2011 Return-Path: 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 A683421F8CAF for ; Wed, 7 Sep 2011 17:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 fdNf-lxdAPy1 for ; Wed, 7 Sep 2011 17:16:20 -0700 (PDT) Received: from SJDC-SDIRelay3.sdi.trendmicro.com (sjdc-sdirelay3.sdi.trendmicro.com [150.70.69.27]) by ietfa.amsl.com (Postfix) with ESMTP id 26CAC21F8B68 for ; Wed, 7 Sep 2011 17:16:20 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay3.sdi.trendmicro.com (Postfix) with ESMTP id 0A9D86E012C for ; Thu, 8 Sep 2011 00:18:09 +0000 (UTC) Received: from US-DOUGO-MAC.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 76F1BA9443B for ; Thu, 8 Sep 2011 00:18:09 +0000 (UTC) Message-ID: <4E6809C0.1010100@mail-abuse.org> Date: Wed, 07 Sep 2011 17:18:08 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: domainrep@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 00:16:20 -0000 On 9/6/11 3:15 PM, Murray S. Kucherawy wrote: > > Hi all, > > Some further charter adjustment has been made in conversation with the > advising AD, potential co-chairs, Nathaniel and myself. The latest > version is attached. It is substantively the same as what you�ve > already seen but nails down a few points while sticking to the > feedback that�s been sent to the list recently. > Murray, Based upon methods suggested in the charter, reputations created are likely to cause problems where those hosting the name reputation service will be held accountable. As was said in the past and on the MAAWG mailing list, this charter starts out making misstatements that go to the heart of the concern. "Various mechanisms have been developed for associating a verified identifier with email content, such as with SPF (RFC4408) and DKIM (RFC4871). ... Given the recent adoption of domain name verification for email, by SPF and DKIM, the most obvious initial use case for reputation is for email." When reputation of a name is at stake, the verified role in any purported misdeed is critical. While SPF may provide authorization for an outbound MTA, it may not verify a domain's involvement with specific exchanges from a shared MTA. Also spam is often identified by receipt of unsolicited commercial messages but DKIM may not verify a domain's role in selecting a recipient since DKIM does not extend to this parameter. Ignoring such cases would creates a sizable category for spammers to either exploit or abuse. There also remains the issue related with SPF which could damage DNS by leveraging macro expansion of email address local-parts. Before this effort starts, where all but the largest email providers are likely to be unaffected simply because size, a scheme is needed to verify the domain managing outbound MTAs. It should be those managing MTAs who identify entities using their service and not their recipients using risky and unscalable methods. Perhaps DANE and some SMTP auth extension might be able to identify outbound MTAs in a manner that safely scales and ensures fair reputation assessments. Despite good intentions, attempting to leverage methods poorly suited for establishing reputation is likely to create problems difficult to later remedy. -Doug From ajs@anvilwalrusden.com Wed Sep 7 18:01:08 2011 Return-Path: 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 51B5C21F85AE for ; Wed, 7 Sep 2011 18:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] 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 oy4Rq77AhXEd for ; Wed, 7 Sep 2011 18:01:07 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C480321F85AB for ; Wed, 7 Sep 2011 18:01:07 -0700 (PDT) Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 8716C1ECB41D for ; Thu, 8 Sep 2011 01:02:56 +0000 (UTC) Date: Wed, 7 Sep 2011 21:02:55 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20110908010255.GF37065@shinkuro.com> References: <4E6809C0.1010100@mail-abuse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E6809C0.1010100@mail-abuse.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 01:01:08 -0000 Doug, On Wed, Sep 07, 2011 at 05:18:08PM -0700, Douglas Otis wrote: > Before this effort starts, where all but the largest email providers > are likely to be unaffected simply because size, a scheme is needed > to verify the domain managing outbound MTAs. It should be those > managing MTAs who identify entities using their service and not > their recipients using risky and unscalable methods. Perhaps DANE > and some SMTP auth extension might be able to identify outbound MTAs > in a manner that safely scales and ensures fair reputation > assessments. Despite good intentions, attempting to leverage methods > poorly suited for establishing reputation is likely to create > problems difficult to later remedy. The above suggests to me that, regardless of the foundation statements in the proposed charter to which you take exception, you still think that the work is correctly bounded and that these issues would be the proper purview of a WG in this area. Am I misreading you? If so, please state exactly how. If not, then I would like to suggest your message actually supports the charter, even if you think that all of the initial drafts ought to be changed dramatically in respect of their substance. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From dotis@mail-abuse.org Wed Sep 7 18:32:21 2011 Return-Path: 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 97DB121F87FA for ; Wed, 7 Sep 2011 18:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.872 X-Spam-Level: X-Spam-Status: No, score=-103.872 tagged_above=-999 required=5 tests=[AWL=-1.273, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 funWI49vJDYY for ; Wed, 7 Sep 2011 18:32:20 -0700 (PDT) Received: from SJDC-SDIRelay1.sdi.trendmicro.com (sjdc-sdirelay1.sdi.trendmicro.com [150.70.64.59]) by ietfa.amsl.com (Postfix) with ESMTP id CCED621F87F0 for ; Wed, 7 Sep 2011 18:32:20 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay1.sdi.trendmicro.com (Postfix) with ESMTP id 504AA3B0092 for ; Thu, 8 Sep 2011 01:34:08 +0000 (UTC) Received: from US-DOUGO-MAC.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 875A7A9443B for ; Thu, 8 Sep 2011 01:34:10 +0000 (UTC) Message-ID: <4E681B91.7060601@mail-abuse.org> Date: Wed, 07 Sep 2011 18:34:09 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: domainrep@ietf.org References: <4E6809C0.1010100@mail-abuse.org> <20110908010255.GF37065@shinkuro.com> In-Reply-To: <20110908010255.GF37065@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 01:32:21 -0000 On 9/7/11 6:02 PM, Andrew Sullivan wrote: > Doug, > > On Wed, Sep 07, 2011 at 05:18:08PM -0700, Douglas Otis wrote: > >> Before this effort starts, where all but the largest email providers >> are likely to be unaffected simply because size, a scheme is needed >> to verify the domain managing outbound MTAs. It should be those >> managing MTAs who identify entities using their service and not >> their recipients using risky and unscalable methods. Perhaps DANE >> and some SMTP auth extension might be able to identify outbound MTAs >> in a manner that safely scales and ensures fair reputation >> assessments. Despite good intentions, attempting to leverage methods >> poorly suited for establishing reputation is likely to create >> problems difficult to later remedy. > The above suggests to me that, regardless of the foundation statements > in the proposed charter to which you take exception, you still think > that the work is correctly bounded and that these issues would be the > proper purview of a WG in this area. Am I misreading you? If so, > please state exactly how. If not, then I would like to suggest your > message actually supports the charter, even if you think that all of > the initial drafts ought to be changed dramatically in respect of > their substance. There are two separate issues improperly combined in the charter. The incorrect assumption of domain validation by either SPF or DKIM to assess accountability and then the reputation service itself. I think you also raised concerns regarding suitability of protocols used in conjunction with the reputation service. These validation methods may damage DNS and may mis-identify purported actors assessed by the reputation service. With the charter making misleading statements regarding the suitability of the "validating" methods, and then declaring the basis of the reputation service out-of-scope ensures a flawed outcome. I had asked that these statements in the charter be removed and that the validation issue be addressed elsewhere where it can be properly discussed. -Doug From dhc@dcrocker.net Fri Sep 9 13:51:51 2011 Return-Path: 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 ACE8421F8559 for ; Fri, 9 Sep 2011 13:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.811 X-Spam-Level: X-Spam-Status: No, score=-5.811 tagged_above=-999 required=5 tests=[AWL=-0.504, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] 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 RKw75YAnLbqi for ; Fri, 9 Sep 2011 13:51:50 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9885221F872A for ; Fri, 9 Sep 2011 13:51:50 -0700 (PDT) Received: from [192.168.1.7] (adsl-68-122-32-32.dsl.pltn13.pacbell.net [68.122.32.32]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p89KrcwG022380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Sep 2011 13:53:44 -0700 Message-ID: <4E6A7CD0.9090305@dcrocker.net> Date: Fri, 09 Sep 2011 13:53:36 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 References: <4E6809C0.1010100@mail-abuse.org> <20110908010255.GF37065@shinkuro.com> <4E681B91.7060601@mail-abuse.org> In-Reply-To: <4E681B91.7060601@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 09 Sep 2011 13:53:46 -0700 (PDT) Cc: domainrep@ietf.org Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 20:51:51 -0000 On 9/7/2011 6:34 PM, Douglas Otis wrote: > On 9/7/11 6:02 PM, Andrew Sullivan wrote: > There are two separate issues improperly combined in the charter. The incorrect > assumption of domain validation by either SPF or DKIM to assess accountability > and then the reputation service itself. Doug, Over quite few months and in many different fora, you have constantly been citing your concerns about use and discussion of SPF and DKIM. My own perception is that you criticize them every time they are referenced on any and every list you monitor. Such a pattern tends to create an uncomfortable tone for public discussion. In fact it comes quite close to looking like a denial of service attack on any group that commits the sin of mentioning SPF or DKIM. As you note above, validation of an identifier is separate from its use. The Repute working group draft charter, and the work planned for this group, take an identifier as input, independent of the method use for its validation. SPF and DKIM are cited as exemplars for verification because, unlike you, the rest of the industry considers them useful. However let's be clear about a key point: the work of this new group doe not depend on SPF or DKIM. Again: they are merely cited as examples. Hence, details and concerns about SPF and DKIM are out of scope for this domainrep mailing list. Please refrain from further repetition of your concerns about them on this list. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dotis@mail-abuse.org Mon Sep 12 12:20:15 2011 Return-Path: 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 8322021F8C5B for ; Mon, 12 Sep 2011 12:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.816 X-Spam-Level: X-Spam-Status: No, score=-103.816 tagged_above=-999 required=5 tests=[AWL=-1.217, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 6ARdWA0sZsmF for ; Mon, 12 Sep 2011 12:20:14 -0700 (PDT) Received: from SJDC-SDIRelay1.sdi.trendmicro.com (sjdc-sdirelay1.sdi.trendmicro.com [150.70.64.59]) by ietfa.amsl.com (Postfix) with ESMTP id E315F21F8C4F for ; Mon, 12 Sep 2011 12:20:14 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay1.sdi.trendmicro.com (Postfix) with ESMTP id 69B3A3B0076; Mon, 12 Sep 2011 19:22:16 +0000 (UTC) Received: from us-waynej-t42.client.us.trendnet.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id CA1D9A9443C; Mon, 12 Sep 2011 19:22:17 +0000 (UTC) Message-ID: <4E6E5BE7.9090709@mail-abuse.org> Date: Mon, 12 Sep 2011 12:22:15 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4E6809C0.1010100@mail-abuse.org> <20110908010255.GF37065@shinkuro.com> <4E681B91.7060601@mail-abuse.org> <4E6A7CD0.9090305@dcrocker.net> In-Reply-To: <4E6A7CD0.9090305@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: domainrep@ietf.org Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 19:20:15 -0000 On 9/9/11 1:53 PM, Dave CROCKER wrote: > On 9/7/2011 6:34 PM, Douglas Otis wrote: > > On 9/7/11 6:02 PM, Andrew Sullivan wrote: There are two separate > > issues improperly combined in the charter. The incorrect assumption > > of domain validation by either SPF or DKIM to assess > > accountability and then the reputation service itself. > Doug, > > Over quite few months and in many different fora, you have constantly > been citing your concerns about use and discussion of SPF and DKIM. > My own perception is that you criticize them every time they are > referenced on any and every list you monitor. Such a pattern tends > to create an uncomfortable tone for public discussion. In fact it > comes quite close to looking like a denial of service attack on any > group that commits the sin of mentioning SPF or DKIM. Dave, The 50 messages sent to this list and the one to MAAWG's technical list over more than a year's time can not be described as a DoS, especially when 39 were not about the suitability of SPF or DKIM . Only recently during discussions of the charter of the last month has this issue been raised 5 times due to real security concerns. You are also conflating anti-phishing concerns related to valid DKIM results returned for messages having multiple singleton headers. That is another topic where security was also ignored. SPF's authorization of an IP address does not verify or "authenticate" the domain responsible for sending a message. A signature that covers a message's body may not authenticate the domain responsible for sending the message to a specific recipient. When discussing a protocol aimed at blocking domains, authentication of a domain's role in any negative assessment is _critical_. The charter does MORE than suggest example protocols, it misrepresents their function: ,-- "Various mechanisms have been developed for associating a _verified_ identifier with email content, such as with SPF (RFC4408) and DKIM (RFC4871)." ... "Given the recent adoption of domain name _verification_ for email, by SPF and DKIM, the most obvious initial use case for reputation is for email." '-- In the past proponents of SPF often misrepresented authorization as "authenticating" the sending domain. Now the Repute charter continues this tradition. Neither SPF nor DKIM "authenticate" OR "validate" the domain responsible for sending a message. This is critical. A mistake as to which domain played a role in sending a message can create a REAL DoS for an entire domain well beyond their control. > As you note above, validation of an identifier is separate from its > use. The Repute working group draft charter, and the work planned > for this group, take an identifier as input, independent of the > method use for its validation. SPF and DKIM are cited as exemplars > for verification because, unlike you, the rest of the industry > considers them useful. > > However let's be clear about a key point: the work of this new group > doe not depend on SPF or DKIM. Again: they are merely cited as > examples. These protocols are not merely stated as examples, their function is described as offering validation suitable for reputation assessment based upon the domain. > Hence, details and concerns about SPF and DKIM are out of scope for > this domainrep mailing list. > > Please refrain from further repetition of your concerns about them on > this list. Removal of erroneous statements from the charter would also eliminate this discussion. Don't start this effort based upon flawed concepts. Even those willing to make such a mistake of depending upon bad assumptions should not be endorsed in the charter, which is currently under discussion on this list. -Doug From dfs@roaringpenguin.com Mon Sep 12 12:29:07 2011 Return-Path: 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 5976C21F8C87 for ; Mon, 12 Sep 2011 12:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 XCysL4j8nLoq for ; Mon, 12 Sep 2011 12:29:06 -0700 (PDT) Received: from colo3.roaringpenguin.com (www.ipv6.roaringpenguin.com [IPv6:2607:f748:1200:fb:70:38:112:54]) by ietfa.amsl.com (Postfix) with ESMTP id B0C8D21F8C86 for ; Mon, 12 Sep 2011 12:29:06 -0700 (PDT) Received: from vanadium.roaringpenguin.com (vanadium.roaringpenguin.com [192.168.10.23]) by colo3.roaringpenguin.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p8CJV8HD011835 for ; Mon, 12 Sep 2011 15:31:09 -0400 Received: from hydrogen.roaringpenguin.com (hydrogen.roaringpenguin.com [192.168.10.1]) by vanadium.roaringpenguin.com (8.14.3/8.14.3/Debian-9.4) with ESMTP id p8CJV7PC009250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 12 Sep 2011 15:31:08 -0400 Date: Mon, 12 Sep 2011 15:31:06 -0400 From: "David F. Skoll" To: domainrep@ietf.org Message-ID: <20110912153106.5c40e400@hydrogen.roaringpenguin.com> In-Reply-To: <4E6E5BE7.9090709@mail-abuse.org> References: <4E6809C0.1010100@mail-abuse.org> <20110908010255.GF37065@shinkuro.com> <4E681B91.7060601@mail-abuse.org> <4E6A7CD0.9090305@dcrocker.net> <4E6E5BE7.9090709@mail-abuse.org> Organization: Roaring Penguin Software Inc. X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=roaringpenguin.com; h=date :from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=beta; bh=g781DGR0Jr/X ElT1k6i5uyNMOUE=; b=UnGd8GYkT5APhFIJJX2f9SWfT9aFX+W5rX5xkL64gfAS hCnTQEmRjIyXzK0Kk0pBu8/fiFWRCPqMeziJoShiR+8n0zwdQCrYbOtBOXi5RP5X kJ0ODvZUp5DPZ57bg+/jLSMhE17swFX9x51tWZUBNm9FaeP/I1x8lFVxGPG7Lgc= X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.7.18 X-Scanned-By: MIMEDefang 2.72 on 192.168.10.23 X-CanIt-Geo: No geolocation information available for 192.168.10.23 X-CanItPRO-Stream: outgoing (inherits from default) X-CanIt-Archive-Cluster: SQVyZJxqklY5buiWXYCN4T/BjiM X-CanIt-Archived-As: base/20110912 / 01FvTv9Jf Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 19:29:07 -0000 On Mon, 12 Sep 2011 12:22:15 -0700 Douglas Otis wrote: > A signature that covers a message's body may not authenticate the > domain responsible for sending the message to a specific recipient. But DKIM does define a domain that is responsible for the message. The RFC even says that explicitly: DomainKeys Identified Mail (DKIM) defines a mechanism by which email messages can be cryptographically signed, permitting a signing domain to claim responsibility for the introduction of a message into the mail stream. DKIM usually signs the To: and Cc: headers as well, so except in the case of a Bcc: recipient, it does even show that the domain is responsible for sending to particular recipients. Of course, since DKIM public keys are typically distributed via DNS, the security of DKIM is only as good as the security of DNS (ie, it's not secure.) But in that far-off candy-mountain time when everyone uses DNSSEC and no CAs are compromised by hackers or governments, then DKIM will in fact securely declare that a given domain is responsible for a given message. And even without secure DNS, DKIM is pretty useful in practice. Regards, David. From R.E.Sonneveld@sonnection.nl Mon Sep 12 13:50:23 2011 Return-Path: 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 45A9621F8E27 for ; Mon, 12 Sep 2011 13:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.735 X-Spam-Level: X-Spam-Status: No, score=-3.735 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 qs+Afftp4k8x for ; Mon, 12 Sep 2011 13:50:22 -0700 (PDT) Received: from mx10.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by ietfa.amsl.com (Postfix) with ESMTP id 13BEE21F8DF4 for ; Mon, 12 Sep 2011 13:50:21 -0700 (PDT) Received: from process-dkim-sign-daemon.hydrogen.mailtransaction.com by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0LRF00J00FWTV200@hydrogen.mailtransaction.com>; Mon, 12 Sep 2011 22:52:25 +0200 (CEST) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0LRF00A39GNCNI00@hydrogen.mailtransaction.com>; Mon, 12 Sep 2011 22:52:24 +0200 (CEST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0LRF00M2JGNCCF00@lion.sonnection.nl> for domainrep@ietf.org; Mon, 12 Sep 2011 22:52:24 +0200 (CEST) Message-id: <4E6E71F7.30301@sonnection.nl> Date: Mon, 12 Sep 2011 22:56:23 +0200 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 To: "David F. Skoll" References: <4E6809C0.1010100@mail-abuse.org> <20110908010255.GF37065@shinkuro.com> <4E681B91.7060601@mail-abuse.org> <4E6A7CD0.9090305@dcrocker.net> <4E6E5BE7.9090709@mail-abuse.org> <20110912153106.5c40e400@hydrogen.roaringpenguin.com> In-reply-to: <20110912153106.5c40e400@hydrogen.roaringpenguin.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1315860745; bh=CRW/JTTfY+CYA6no0oUioN/EAb74sH7n0+V5gjap1ss=; h=MIME-version:Content-transfer-encoding:Content-type:Message-id: Date:From:To:Cc:Subject:References:In-reply-to; b=ehiVa61uKcLqBNrpBV06zuAPIE3KEgOCuUhUaYqfbgYRJHf9OEPwTaL78siD7of3d s9Qwfaosv5+TwepyoEOw8duq6oCeafA92bMZQdIDt/cI8NAWzEV32jRkhGN2m4TXvd uc6V0He2VU/M23dARDrjOsmxa5rw3Ff0AYkK+NDA= X-DKIM: OpenDKIM Filter v2.1.3 hydrogen.mailtransaction.com 0LRF00J00FWTV200 Cc: domainrep@ietf.org Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 20:50:23 -0000 Hi, David, On 9/12/11 9:31 PM, David F. Skoll wrote: > On Mon, 12 Sep 2011 12:22:15 -0700 > Douglas Otis wrote: > >> A signature that covers a message's body may not authenticate the >> domain responsible for sending the message to a specific recipient. > But DKIM does define a domain that is responsible for the message. > The RFC even says that explicitly: > > DomainKeys Identified Mail (DKIM) defines a mechanism by which email > messages can be cryptographically signed, permitting a signing domain > to claim responsibility for the introduction of a message into the > mail stream. > > DKIM usually signs the To: and Cc: headers as well, so except in the case > of a Bcc: recipient, it does even show that the domain is responsible > for sending to particular recipients. > > Of course, since DKIM public keys are typically distributed via DNS, the > security of DKIM is only as good as the security of DNS (ie, it's not secure.) > > But in that far-off candy-mountain time when everyone uses DNSSEC and > no CAs are compromised by hackers or governments, then DKIM will in fact > securely declare that a given domain is responsible for a given message. > And even without secure DNS, DKIM is pretty useful in practice. Doug means (as far as I can tell) something like: Technologies like GPG/PGP and S/MIME use the private key of the sender in combination with the public key of the recipient and the private key of the recipient in combination with the public key of the sender, to achieve encryption/message integrity/non-repudiation for this specific pair of sender+recipient. DKIM signs header From and optionally header To:, Cc: etc, but the recipient of the message is determined by envelope To, not by header To or Resent-To or any other header. So bad guys, using too-big-to-block domains, can create a signed spam message by sending from this domain to one of their other mailboxes and replay that message, using the original DKIM signature. Doug may speak for himself if I've misunderstood him. However, I strongly agree with Dave that DKIM and SPF are just examples in the context of the charter and are out of scope for the reputation WG. /rolf From dfs@roaringpenguin.com Mon Sep 12 13:59:53 2011 Return-Path: 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 42FC721F8E48 for ; Mon, 12 Sep 2011 13:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 c-elPmiPmGrv for ; Mon, 12 Sep 2011 13:59:52 -0700 (PDT) Received: from colo3.roaringpenguin.com (www.ipv6.roaringpenguin.com [IPv6:2607:f748:1200:fb:70:38:112:54]) by ietfa.amsl.com (Postfix) with ESMTP id 6716021F8E34 for ; Mon, 12 Sep 2011 13:59:52 -0700 (PDT) Received: from vanadium.roaringpenguin.com (vanadium.roaringpenguin.com [192.168.10.23]) by colo3.roaringpenguin.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p8CL1rZS027062 for ; Mon, 12 Sep 2011 17:01:53 -0400 Received: from hydrogen.roaringpenguin.com (hydrogen.roaringpenguin.com [192.168.10.1]) by vanadium.roaringpenguin.com (8.14.3/8.14.3/Debian-9.4) with ESMTP id p8CL1qvE017091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 12 Sep 2011 17:01:53 -0400 Date: Mon, 12 Sep 2011 17:01:52 -0400 From: "David F. Skoll" To: domainrep@ietf.org Message-ID: <20110912170152.32807635@hydrogen.roaringpenguin.com> In-Reply-To: <4E6E71F7.30301@sonnection.nl> References: <4E6809C0.1010100@mail-abuse.org> <20110908010255.GF37065@shinkuro.com> <4E681B91.7060601@mail-abuse.org> <4E6A7CD0.9090305@dcrocker.net> <4E6E5BE7.9090709@mail-abuse.org> <20110912153106.5c40e400@hydrogen.roaringpenguin.com> <4E6E71F7.30301@sonnection.nl> Organization: Roaring Penguin Software Inc. X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=roaringpenguin.com; h=date :from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=beta; bh=bvGyK7rVJ9KP SxJ3VYFZGv8dNl4=; b=X2ebJZGTZ0793rAEdzVH2k6g/6/ZEh/SfFzTJNX82L41 AmcW42I1duwvYMlBsdCUZhS8yt0uM4oTgaVjt/bORLEATIbjNIgdVW9k9mvCht5f a99QlZduRX9bh6Xl0Vi/AjeyJ5iX688Go85lvqB9cNgAAvCd77Vwpo4VyOgn39M= X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.7.18 X-Scanned-By: MIMEDefang 2.72 on 192.168.10.23 X-CanIt-Geo: No geolocation information available for 192.168.10.23 X-CanItPRO-Stream: outgoing (inherits from default) X-CanIt-Archive-Cluster: SQVyZJxqklY5buiWXYCN4T/BjiM X-CanIt-Archived-As: base/20110912 / 01FvV1RLj Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 20:59:53 -0000 On Mon, 12 Sep 2011 22:56:23 +0200 "Rolf E. Sonneveld" wrote: > So bad guys, using too-big-to-block domains, can create a signed > spam message by sending from this domain to one of their other > mailboxes and replay that message, using the original DKIM > signature. Got it. But that's OK; the "too-big-to-block" domains will gravitate towards a neutral or mildly negative reputation, as they should, while domains for which DKIM is really useful (ebay.com, paypal.com, yourbank.com) are unaffected by this attack assuming they don't let bad guys inject arbitrary messages through their signing servers. In other words: A domain that allows "bad guys" to inject arbitrary messages through their DKIM-signing servers really *deserves* a worse reputation than one that doesn't. Regards, David. From dotis@mail-abuse.org Mon Sep 12 14:54:46 2011 Return-Path: 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 7AF4421F8E84 for ; Mon, 12 Sep 2011 14:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.766 X-Spam-Level: X-Spam-Status: No, score=-103.766 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 UoIURQYdpW-v for ; Mon, 12 Sep 2011 14:54:45 -0700 (PDT) Received: from SJDC-SDIRelay2.sdi.trendmicro.com (sjdc-sdirelay2.sdi.trendmicro.com [150.70.68.59]) by ietfa.amsl.com (Postfix) with ESMTP id B2A7621F8E83 for ; Mon, 12 Sep 2011 14:54:45 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay2.sdi.trendmicro.com (Postfix) with ESMTP id 6532130810B for ; Mon, 12 Sep 2011 21:56:48 +0000 (UTC) Received: from us-waynej-t42.client.us.trendnet.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id E52C3A9443B for ; Mon, 12 Sep 2011 21:56:48 +0000 (UTC) Message-ID: <4E6E8020.10307@mail-abuse.org> Date: Mon, 12 Sep 2011 14:56:48 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: domainrep@ietf.org References: <4E6809C0.1010100@mail-abuse.org> <20110908010255.GF37065@shinkuro.com> <4E681B91.7060601@mail-abuse.org> <4E6A7CD0.9090305@dcrocker.net> <4E6E5BE7.9090709@mail-abuse.org> <20110912153106.5c40e400@hydrogen.roaringpenguin.com> In-Reply-To: <20110912153106.5c40e400@hydrogen.roaringpenguin.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 21:54:46 -0000 On 9/12/11 12:31 PM, David F. Skoll wrote: > On Mon, 12 Sep 2011 12:22:15 -0700 > Douglas Otis wrote: >> A signature that covers a message's body may not authenticate the >> domain responsible for sending the message to a specific recipient. > But DKIM does define a domain that is responsible for the message. > The RFC even says that explicitly: > > DomainKeys Identified Mail (DKIM) defines a mechanism by which email > messages can be cryptographically signed, permitting a signing domain > to claim responsibility for the introduction of a message into the > mail stream. > > DKIM usually signs the To: and Cc: headers as well, so except in the case > of a Bcc: recipient, it does even show that the domain is responsible > for sending to particular recipients. David, DKIM is not intended to convey accountability for a sending domain nor intended recipients. Indeed a message might not include intended recipients, which this list's messages do not. Nor should one assume DKIM is related to the domain sending the message. DKIM's overly broad statement should not be read as conferring accountability for any specific outbound MTA for any specific recipient. Only signed message content (which may ignore pre-pended From header fields) is covered by a DKIM signature. This coverage excludes essential aspects of the message envelope needed to properly assess accountability. From a reputation standpoint, DKIM is unable to hold spammers accountable. It fails to authenticate who sent any specific message. Spam is not defined based upon who generated content. The act of spamming is by those domains sending unwanted content to specific recipients. Neither the sending domain nor the recipient can be assumed covered by a valid DKIM signature. It would be dangerous to base domain reputations on an assumption these properties are generally true. Neither DKIM nor SPF provide a suitable basis for establishing reputation. Nor should their shortcoming be excused because high volume domains will be white-listed to protect them from possible false assumptions. Since the desire of this list is to not discuss validation issues, an assumption of specific "validation/authentication" methods should be excluded from the Repute charter. Even as a service that signals which domains are "too big to block", since any DKIM message can be replayed from any outbound MTA to any recipient, such a service would be prone to abuse. -Doug From dfs@roaringpenguin.com Mon Sep 12 15:22:59 2011 Return-Path: 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 889C421F8CFE for ; Mon, 12 Sep 2011 15:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 qWmgMxR27QZw for ; Mon, 12 Sep 2011 15:22:59 -0700 (PDT) Received: from colo3.roaringpenguin.com (www.ipv6.roaringpenguin.com [IPv6:2607:f748:1200:fb:70:38:112:54]) by ietfa.amsl.com (Postfix) with ESMTP id D920421F8CFC for ; Mon, 12 Sep 2011 15:22:58 -0700 (PDT) Received: from vanadium.roaringpenguin.com (vanadium.roaringpenguin.com [192.168.10.23]) by colo3.roaringpenguin.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p8CMP2i1007167 for ; Mon, 12 Sep 2011 18:25:02 -0400 Received: from shishi.roaringpenguin.com (dfs@shishi.roaringpenguin.com [192.168.2.3]) by vanadium.roaringpenguin.com (8.14.3/8.14.3/Debian-9.4) with ESMTP id p8CMP0RA003732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 12 Sep 2011 18:25:02 -0400 Date: Mon, 12 Sep 2011 18:24:59 -0400 From: "David F. Skoll" To: domainrep@ietf.org Message-ID: <20110912182459.643791ac@shishi.roaringpenguin.com> In-Reply-To: <4E6E8020.10307@mail-abuse.org> References: <4E6809C0.1010100@mail-abuse.org> <20110908010255.GF37065@shinkuro.com> <4E681B91.7060601@mail-abuse.org> <4E6A7CD0.9090305@dcrocker.net> <4E6E5BE7.9090709@mail-abuse.org> <20110912153106.5c40e400@hydrogen.roaringpenguin.com> <4E6E8020.10307@mail-abuse.org> Organization: Roaring Penguin Software Inc. X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=roaringpenguin.com; h=date :from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=beta; bh=nD42w23sbv5d 4mSXAWl0SSKxQ0E=; b=YtFHjgqMQ4t1P2Ilzmjrr1wdWVw7FQeW5YgsCsrU+SvM JsyAn+3WRihxkzyGnetixsatjPsLbfob6f4WRSlVHYbsr6Ie07SJ261aFrh0j6BK 58wpsMyuI4cgyynQtf88/3P87go5AvykZMEbkNh187rlJ8rgzmx3VwLL5qMVpaY= X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.7.18 X-Scanned-By: MIMEDefang 2.72 on 192.168.10.23 X-CanIt-Geo: No geolocation information available for 192.168.10.23 X-CanItPRO-Stream: outgoing (inherits from default) X-CanIt-Archive-Cluster: SQVyZJxqklY5buiWXYCN4T/BjiM X-CanIt-Archived-As: base/20110912 / 01FvWp2MK Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 22:22:59 -0000 On Mon, 12 Sep 2011 14:56:48 -0700 Douglas Otis wrote: > Neither DKIM nor SPF provide a suitable basis for establishing > reputation. I disagree WRT DKIM. DKIM doesn't assert that a particular domain sent a particular message, true. It *does* assert that that domain's signing server has seen the message and signed it. So it's perfectly feasible to talk about the reputation of a DKIM signing domain, which is not necessarily the reputation of the message sender, but is still useful. I posted the use-cases earlier. Regards, David. From msk@cloudmark.com Mon Sep 12 15:26:47 2011 Return-Path: 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 3EF4F21F8DE5 for ; Mon, 12 Sep 2011 15:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.509 X-Spam-Level: X-Spam-Status: No, score=-103.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 DNaMGnnWF3uf for ; Mon, 12 Sep 2011 15:26:46 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id B32BC21F8DCC for ; Mon, 12 Sep 2011 15:26:46 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 12 Sep 2011 15:28:50 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Mon, 12 Sep 2011 15:28:49 -0700 Thread-Topic: [domainrep] Charter going to the IESG Thread-Index: AcxxmtYbgnZLPOgYSuSqGMnDWGji2gAACezA Message-ID: References: <4E6809C0.1010100@mail-abuse.org> <20110908010255.GF37065@shinkuro.com> <4E681B91.7060601@mail-abuse.org> <4E6A7CD0.9090305@dcrocker.net> <4E6E5BE7.9090709@mail-abuse.org> <20110912153106.5c40e400@hydrogen.roaringpenguin.com> <4E6E8020.10307@mail-abuse.org> <20110912182459.643791ac@shishi.roaringpenguin.com> In-Reply-To: <20110912182459.643791ac@shishi.roaringpenguin.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 22:26:47 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of David F. Skoll > Sent: Monday, September 12, 2011 3:25 PM > To: domainrep@ietf.org > Subject: Re: [domainrep] Charter going to the IESG >=20 > I disagree WRT DKIM. DKIM doesn't assert that a particular domain > sent a particular message, true. It *does* assert that that domain's > signing server has seen the message and signed it. >=20 > So it's perfectly feasible to talk about the reputation of a DKIM > signing domain, which is not necessarily the reputation of the message > sender, but is still useful. I posted the use-cases earlier. Indeed, I've constructed an experimental reputation system based on this id= ea: Domains that "stamp" a message with a DKIM signature are taking some re= sponsibility for it, and thus it's possible to develop a reputation as to w= hether or not that domain's stamp tends to be associated with spam or not. = The system doesn't care who sent it or who received it, only who stamped i= t. I'm planning to strap the protocols defined in the repute drafts onto the f= ront end as an example implementation. From dhc@dcrocker.net Mon Sep 12 15:44:31 2011 Return-Path: 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 13AFC21F8EA3 for ; Mon, 12 Sep 2011 15:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 mMYlPojuM5V5 for ; Mon, 12 Sep 2011 15:44:30 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAD921F8E98 for ; Mon, 12 Sep 2011 15:44:30 -0700 (PDT) Received: from [192.168.1.7] (adsl-68-122-32-32.dsl.pltn13.pacbell.net [68.122.32.32]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p8CMkTBB011181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Sep 2011 15:46:34 -0700 Message-ID: <4E6E8BC5.4000307@dcrocker.net> Date: Mon, 12 Sep 2011 15:46:29 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: domainrep@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 12 Sep 2011 15:46:34 -0700 (PDT) Subject: [domainrep] Comments on -model-00 X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Dave Crocker List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 22:44:31 -0000 On the current -model-00 document: By citing the related documents, you make the publication of this document be gated on their being published first. That's the reason I'm not a fan of "forward" pointers like this. (It only gets worse as more documents list the component set.) In contrast citing functional divisions, without citing specific documents, lays the groundwork with no gating. The later documents, of course, can have a backward reference that declares which function(s) from the set they cover. The current 'model' is for the localized mechanism, without reference to the larger, systemic framework for identification and assessment that this piece fits into. Figure 1 (RFC 5863) and Figure 1 (RFC 5585) attempt the sort of full-system description. I suggest that the model document, here, should deal with the full architecture, so that it's clear where the current work fits into a true, end-to-end email service. If any of the existing diagrams and discussion are sufficient, just cite them. If they need elaboration, perhaps build on them? In any event, I do suggest a separate diagram for the pieces that the model covers, to show their relationships. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Mon Sep 12 15:46:18 2011 Return-Path: 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 9FA7421F8EB1 for ; Mon, 12 Sep 2011 15:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 sSqF2OBErXqP for ; Mon, 12 Sep 2011 15:46:17 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id CB23C21F8E05 for ; Mon, 12 Sep 2011 15:46:17 -0700 (PDT) Received: from [192.168.1.7] (adsl-68-122-32-32.dsl.pltn13.pacbell.net [68.122.32.32]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p8CMmHEN011227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Sep 2011 15:48:22 -0700 Message-ID: <4E6E8C31.7040808@dcrocker.net> Date: Mon, 12 Sep 2011 15:48:17 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: domainrep@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 12 Sep 2011 15:48:22 -0700 (PDT) Subject: [domainrep] Comments on -model-00 (full set) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 22:46:18 -0000 (oops. left off two more comments...) On the current -model-00 document: 1. By citing the related documents, you make the publication of this document be gated on their being published first. That's the reason I'm not a fan of "forward" pointers like this. (It only gets worse as more documents list the component set.) In contrast citing functional divisions, without citing specific documents, lays the groundwork with no gating. The later documents, of course, can have a backward reference that declares which function(s) from the set they cover. The current 'model' is for the localized mechanism, without reference to the larger, systemic framework for identification and assessment that this piece fits into. Figure 1 (RFC 5863) and Figure 1 (RFC 5585) attempt the sort of full-system description. I suggest that the model document, here, should deal with the full architecture, so that it's clear where the current work fits into a true, end-to-end email service. If any of the existing diagrams and discussion are sufficient, just cite them. If they need elaboration, perhaps build on them? In any event, I do suggest a separate diagram for the pieces that the model covers, to show their relationships. 2. Potential redundancy and synchronization challenges. Section 4 lists information components. I suspect that that is a redundant list with the media-type document and will need to be synchronized. Every change requires updating two documents... Perhaps the model document can be restricted to discussion of core issues about a media-type rather than going into details? 3. Bias I like the intent of Section 7.1 but suspect it lays a trap for itself. Opinion is, by its definition, biased. Objectivity when making an assessment of quality, is really about process and not conclusion. I suspect the real issues are transparency about criteria and consistency in their application. That's not quite the same thing as being unbiased. An essential point about the proposed work is that it has nothing to do with the basis for choosing criteria nor with the way in which they are applied. It does permit listing underlying information, which can aid transparency. But fundamentally it is about representing and obtaining data in a standardized way, rather than assessing its merits. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Mon Sep 12 15:47:41 2011 Return-Path: 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 8816E21F8EC5 for ; Mon, 12 Sep 2011 15:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 BrIPXI1c1Rhf for ; Mon, 12 Sep 2011 15:47:41 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E0B3421F8EC3 for ; Mon, 12 Sep 2011 15:47:40 -0700 (PDT) Received: from [192.168.1.7] (adsl-68-122-32-32.dsl.pltn13.pacbell.net [68.122.32.32]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p8CMndPv011262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Sep 2011 15:49:45 -0700 Message-ID: <4E6E8C84.1090803@dcrocker.net> Date: Mon, 12 Sep 2011 15:49:40 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: domainrep@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 12 Sep 2011 15:49:45 -0700 (PDT) Subject: [domainrep] Comments on -media-type-00 X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 22:47:41 -0000 On the current -media-type-00 document: 1. Same concern about forward references as my first comment in the -model document, just sent. We should avoid redundancy and forward pointers. 2. I suggest that the DNS response be modeled as a subset of this more general media-type, so that one can obtain that kind of good/bad simple information through the same mechanism as the more extensive information. Hence, the DNS-based mechanism becomes a kind of data profile, possibly with a different syntax. On review, I'm also not clear that this isn't already the same as what should be in a DNS response, in which case I'm not clear how the more extensive information that justified an HTTP mechanism is reported. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dotis@mail-abuse.org Mon Sep 12 17:24:46 2011 Return-Path: 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 5CD0121F8E33 for ; Mon, 12 Sep 2011 17:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.714 X-Spam-Level: X-Spam-Status: No, score=-103.714 tagged_above=-999 required=5 tests=[AWL=-1.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 burVUNlXuPzg for ; Mon, 12 Sep 2011 17:24:45 -0700 (PDT) Received: from SJDC-SDIRelay1.sdi.trendmicro.com (sjdc-sdirelay1.sdi.trendmicro.com [150.70.64.59]) by ietfa.amsl.com (Postfix) with ESMTP id CB53321F8E32 for ; Mon, 12 Sep 2011 17:24:45 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay1.sdi.trendmicro.com (Postfix) with ESMTP id C52B13B0079 for ; Tue, 13 Sep 2011 00:26:47 +0000 (UTC) Received: from us-waynej-t42.client.us.trendnet.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id D6FA2A9443B for ; Tue, 13 Sep 2011 00:26:49 +0000 (UTC) Message-ID: <4E6EA349.6050506@mail-abuse.org> Date: Mon, 12 Sep 2011 17:26:49 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: domainrep@ietf.org References: <4E6809C0.1010100@mail-abuse.org> <20110908010255.GF37065@shinkuro.com> <4E681B91.7060601@mail-abuse.org> <4E6A7CD0.9090305@dcrocker.net> <4E6E5BE7.9090709@mail-abuse.org> <20110912153106.5c40e400@hydrogen.roaringpenguin.com> <4E6E8020.10307@mail-abuse.org> <20110912182459.643791ac@shishi.roaringpenguin.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 00:24:46 -0000 On 9/12/11 3:28 PM, Murray S. Kucherawy wrote: > Indeed, I've constructed an experimental reputation system based on this idea: Domains that "stamp" a message with a DKIM signature are taking some responsibility for it, and thus it's possible to develop a reputation as to whether or not that domain's stamp tends to be associated with spam or not. The system doesn't care who sent it or who received it, only who stamped it. > > I'm planning to strap the protocols defined in the repute drafts onto the front end as an example implementation. Murray, An interesting experiment, but not one that should be endorsed within the Repute charter. You are free to have an overly optimistic belief the lack of replay control permitted by ignoring sender and recipient won't be abused. Adding this "optimism" to the charter is still not wise nor necessary for such experimentation. -Doug From dfs@roaringpenguin.com Mon Sep 12 17:41:39 2011 Return-Path: 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 CFF2E21F8CFE for ; Mon, 12 Sep 2011 17:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 2On-xCUf1qbp for ; Mon, 12 Sep 2011 17:41:39 -0700 (PDT) Received: from colo3.roaringpenguin.com (www.ipv6.roaringpenguin.com [IPv6:2607:f748:1200:fb:70:38:112:54]) by ietfa.amsl.com (Postfix) with ESMTP id 2507821F8CEA for ; Mon, 12 Sep 2011 17:41:39 -0700 (PDT) Received: from vanadium.roaringpenguin.com (vanadium.roaringpenguin.com [192.168.10.23]) by colo3.roaringpenguin.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p8D0hhM3031917 for ; Mon, 12 Sep 2011 20:43:43 -0400 Received: from charlie.roaringpenguin.com ([192.168.5.2]) by vanadium.roaringpenguin.com (8.14.3/8.14.3/Debian-9.4) with ESMTP id p8D0hbsV020229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 12 Sep 2011 20:43:42 -0400 Date: Mon, 12 Sep 2011 20:41:32 -0400 From: "David F. Skoll" To: domainrep@ietf.org Message-ID: <20110912204132.7bbcd63b@charlie.roaringpenguin.com> In-Reply-To: <4E6EA349.6050506@mail-abuse.org> References: <4E6809C0.1010100@mail-abuse.org> <20110908010255.GF37065@shinkuro.com> <4E681B91.7060601@mail-abuse.org> <4E6A7CD0.9090305@dcrocker.net> <4E6E5BE7.9090709@mail-abuse.org> <20110912153106.5c40e400@hydrogen.roaringpenguin.com> <4E6E8020.10307@mail-abuse.org> <20110912182459.643791ac@shishi.roaringpenguin.com> <4E6EA349.6050506@mail-abuse.org> Organization: Roaring Penguin Software Inc. X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=roaringpenguin.com; h=date :from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=beta; bh=+FXUHoABDucS AahKSCrFxhJajhU=; b=MeUx990H8oQ12Jn1xRqCucqgc1tybyjwqQkBvh6WSkYO obkPPRwfdLve0IrvCOw0/epVWroi0Gzij2PNe4jrbL9p+jgcp1lj9etYBm87e3+t T0ka7PT0UuP2zQ0EgyY03enEhjR+3VanG9Y3UNnhpXPA6qMgMYaNUu4jtdCvnpk= X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.7.18 X-Scanned-By: MIMEDefang 2.72 on 192.168.10.23 X-CanIt-Geo: No geolocation information available for 192.168.10.23 X-CanItPRO-Stream: outgoing (inherits from default) X-CanIt-Archive-Cluster: SQVyZJxqklY5buiWXYCN4T/BjiM X-CanIt-Archived-As: base/20110912 / 01Fw0HHOy Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 00:41:39 -0000 On Mon, 12 Sep 2011 17:26:49 -0700 Douglas Otis wrote: > You are free to have an overly optimistic belief the lack of replay > control permitted by ignoring sender and recipient won't be abused. Yes, but the whole point of the reputation system is that signing servers that permit abuse will be revealed to have a poor or neutral reputations whereas signing server that do not permit abuse will have a good reputation. We see this even now. DKIM-signing by gmail.com is not worth much, but DKIM-signing by my bank is. Regards, David. From johnl@iecc.com Mon Sep 12 18:32:06 2011 Return-Path: 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 78EA621F8C74 for ; Mon, 12 Sep 2011 18:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.153 X-Spam-Level: X-Spam-Status: No, score=-111.153 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] 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 YWXbwCtqc83H for ; Mon, 12 Sep 2011 18:32:06 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D991421F8C6B for ; Mon, 12 Sep 2011 18:32:05 -0700 (PDT) Received: (qmail 17052 invoked from network); 13 Sep 2011 01:34:08 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 13 Sep 2011 01:34:08 -0000 Received: (qmail 84331 invoked from network); 13 Sep 2011 01:34:08 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Sep 2011 01:34:08 -0000 Date: 13 Sep 2011 01:33:46 -0000 Message-ID: <20110913013346.39851.qmail@joyce.lan> From: "John Levine" To: domainrep@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: [domainrep] Denial of Service X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 01:32:06 -0000 >You are free to have an overly optimistic belief the lack of replay >control permitted by ignoring sender and recipient won't be abused. Doug has been saying, over and over and over again for several years that replay is a terrible problem that we have to solve right away. Various other people say, no, it's not. Wait a few days, and as though this discussion never happened before, he brings it up again. Repeat ad infinitum. As far as I can tell, despite the intense lobbying, he has recruited exactly zero people to this point of view, other than perhaps the occasional short-term visitor. If this kind of repetitive unproductive traffic isn't a DoS, I don't know what it is. Doug is a nice enough guy in person and when not arguing about mail security, but it's time for this to stop. R's, John From dotis@mail-abuse.org Mon Sep 12 18:49:42 2011 Return-Path: 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 980EF21F8CE8 for ; Mon, 12 Sep 2011 18:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.673 X-Spam-Level: X-Spam-Status: No, score=-103.673 tagged_above=-999 required=5 tests=[AWL=-1.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Fx4ura683sWt for ; Mon, 12 Sep 2011 18:49:42 -0700 (PDT) Received: from SJDC-SDIRelay2.sdi.trendmicro.com (sjdc-sdirelay2.sdi.trendmicro.com [150.70.68.59]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC7821F8CE5 for ; Mon, 12 Sep 2011 18:49:42 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay2.sdi.trendmicro.com (Postfix) with ESMTP id 593A7308108 for ; Tue, 13 Sep 2011 01:51:45 +0000 (UTC) Received: from us-waynej-t42.client.us.trendnet.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 054B7A9443B for ; Tue, 13 Sep 2011 01:51:46 +0000 (UTC) Message-ID: <4E6EB731.2080303@mail-abuse.org> Date: Mon, 12 Sep 2011 18:51:45 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: domainrep@ietf.org References: <4E6809C0.1010100@mail-abuse.org> <20110908010255.GF37065@shinkuro.com> <4E681B91.7060601@mail-abuse.org> <4E6A7CD0.9090305@dcrocker.net> <4E6E5BE7.9090709@mail-abuse.org> <20110912153106.5c40e400@hydrogen.roaringpenguin.com> <4E6E8020.10307@mail-abuse.org> <20110912182459.643791ac@shishi.roaringpenguin.com> <4E6EA349.6050506@mail-abuse.org> <20110912204132.7bbcd63b@charlie.roaringpenguin.com> In-Reply-To: <20110912204132.7bbcd63b@charlie.roaringpenguin.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 01:49:42 -0000 On 9/12/11 5:41 PM, David F. Skoll wrote: > On Mon, 12 Sep 2011 17:26:49 -0700 > Douglas Otis wrote: >> You are free to have an overly optimistic belief the lack of replay >> control permitted by ignoring sender and recipient won't be abused. > Yes, but the whole point of the reputation system is that signing servers > that permit abuse will be revealed to have a poor or neutral reputations > whereas signing server that do not permit abuse will have a good reputation. > > We see this even now. DKIM-signing by gmail.com is not worth much, > but DKIM-signing by my bank is. Why wouldn't use of DANE in conjunction with outbound servers offer a safer mechanism which would offer domains true control over what is being sent? This would also help solve the IPv6 dilemma. Why endorse a mechanism that excludes protection for the majority of email sources that could otherwise benefit from a reputation service not easily poisoned? Would such victims of poisoning abuse have any remedy? -Doug From dhc@dcrocker.net Mon Sep 12 20:01:37 2011 Return-Path: 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 80D8E21F853B for ; Mon, 12 Sep 2011 20:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 jSCIqcdHBm7a for ; Mon, 12 Sep 2011 20:01:36 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id DF45D21F84F5 for ; Mon, 12 Sep 2011 20:01:36 -0700 (PDT) Received: from [192.168.1.7] (adsl-68-122-32-32.dsl.pltn13.pacbell.net [68.122.32.32]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p8D33Yri015983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Sep 2011 20:03:40 -0700 Message-ID: <4E6EC806.3090105@dcrocker.net> Date: Mon, 12 Sep 2011 20:03:34 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Douglas Otis References: <4E6809C0.1010100@mail-abuse.org> <20110908010255.GF37065@shinkuro.com> <4E681B91.7060601@mail-abuse.org> <4E6A7CD0.9090305@dcrocker.net> <4E6E5BE7.9090709@mail-abuse.org> <20110912153106.5c40e400@hydrogen.roaringpenguin.com> <4E6E8020.10307@mail-abuse.org> <20110912182459.643791ac@shishi.roaringpenguin.com> <4E6EA349.6050506@mail-abuse.org> <20110912204132.7bbcd63b@charlie.roaringpenguin.com> <4E6EB731.2080303@mail-abuse.org> In-Reply-To: <4E6EB731.2080303@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 12 Sep 2011 20:03:41 -0700 (PDT) Cc: domainrep@ietf.org Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 03:01:37 -0000 On 9/12/2011 6:51 PM, Douglas Otis wrote: >> We see this even now. DKIM-signing by gmail.com is not worth much, >> but DKIM-signing by my bank is. > Why wouldn't use of DANE in conjunction with outbound servers offer a safer > mechanism which would offer domains true control over what is being sent? ... Doug, You seem to have mis-posted your note. Clearly it is intended for the dane working group. For the domainrep mailing list, discussion of dane is clearly out of scope. Really, Doug, most people do not find it that difficult to keep their postings within scope for a mailing list. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Mon Sep 12 21:09:22 2011 Return-Path: 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 ADAC721F8CB0 for ; Mon, 12 Sep 2011 21:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.009 X-Spam-Level: X-Spam-Status: No, score=-103.009 tagged_above=-999 required=5 tests=[AWL=-0.410, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Ey-heosblwLZ for ; Mon, 12 Sep 2011 21:09:22 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFC621F8CAE for ; Mon, 12 Sep 2011 21:09:22 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 12 Sep 2011 21:11:27 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Mon, 12 Sep 2011 21:11:25 -0700 Thread-Topic: [domainrep] Charter going to the IESG Thread-Index: Acxxq9rSa/lcXYMgR3eY8Q51zaXwhgAHrsdw Message-ID: References: <4E6809C0.1010100@mail-abuse.org> <20110908010255.GF37065@shinkuro.com> <4E681B91.7060601@mail-abuse.org> <4E6A7CD0.9090305@dcrocker.net> <4E6E5BE7.9090709@mail-abuse.org> <20110912153106.5c40e400@hydrogen.roaringpenguin.com> <4E6E8020.10307@mail-abuse.org> <20110912182459.643791ac@shishi.roaringpenguin.com> <4E6EA349.6050506@mail-abuse.org> In-Reply-To: <4E6EA349.6050506@mail-abuse.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 04:09:22 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Douglas Otis > Sent: Monday, September 12, 2011 5:27 PM > To: domainrep@ietf.org > Subject: Re: [domainrep] Charter going to the IESG >=20 > You are free to have an overly optimistic belief the lack of replay > control permitted by ignoring sender and recipient won't be abused. > Adding this "optimism" to the charter is still not wise nor necessary > for such experimentation. Indeed, just as you are free to be overly (and singularly) pessimistic abou= t the potential of the concept. Nothing about what I said is in the charter though, except that the charter= doesn't preclude the idea. As Dave said, we are all aware that you have pet peeves with SPF and DKIM, = but there is clear consensus that the flaws you highlight ad nauseam are at= best corner cases that should not deter continued advancement of this work= or work on those protocols. From presnick@qualcomm.com Tue Sep 13 11:58:08 2011 Return-Path: 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 2401521F8B21 for ; Tue, 13 Sep 2011 11:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.518 X-Spam-Level: X-Spam-Status: No, score=-106.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 zfA0UdSsAVV6 for ; Tue, 13 Sep 2011 11:58:07 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 92AE721F8AFC for ; Tue, 13 Sep 2011 11:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1315940414; x=1347476414; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4E6FA7BF.8060300@qualcomm.com>|Date:=20Tu e,=2013=20Sep=202011=2013:58:07=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20John=20Levine=20|CC:=20|Subject:=20Re:=20[domainrep ]=20Denial=20of=20Service|References:=20<20110913013346.3 9851.qmail@joyce.lan>|In-Reply-To:=20<20110913013346.3985 1.qmail@joyce.lan>|Content-Type:=20text/plain=3B=20charse t=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.48.1]; bh=XB/x50NvDOxX7Aoo+bXxJKYBF/uOe7DpdJel5D0bQ/E=; b=cmJ9oXhF2+DeP0dKlVoEEXUdfnXLEy6evoRQF08xcT+BYl7L7gTgeVuw wah0EjCU0bepQU6lOfI4swqBLXH7V9ZoMmzDz8YmgHfT7Dt4GOTOLkEMe nN1Pi9UV7H197/WdrgjOQpGkmPmqp+khG4TW6ygSDbDxh/21naLopNSOj g=; X-IronPort-AV: E=McAfee;i="5400,1158,6467"; a="118109470" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 13 Sep 2011 11:59:42 -0700 X-IronPort-AV: E=Sophos;i="4.68,374,1312182000"; d="scan'208";a="118783518" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 13 Sep 2011 11:59:33 -0700 Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 13 Sep 2011 11:58:08 -0700 Message-ID: <4E6FA7BF.8060300@qualcomm.com> Date: Tue, 13 Sep 2011 13:58:07 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: John Levine References: <20110913013346.39851.qmail@joyce.lan> In-Reply-To: <20110913013346.39851.qmail@joyce.lan> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: domainrep@ietf.org Subject: Re: [domainrep] Denial of Service X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 18:58:08 -0000 AD Interrupt on this: As in every group, there are going to be issues that are raised for which someone is in the rough. The issue needs to be documented (I expect there will be an issue tracker of some sort used for this group), the rough consensus needs to be recorded, and that needs to be the end of the conversation. Repeats of a particular issue shall be answered by whoever turns out to be the chair with, "Issue number 529, understood by the group, consensus not to address further." If the same person continues in the face of that to bring it to the list, the chair will communicate with that person offlist, perhaps with the help of the AD, and the "right thing will happen". (Of course, new people wishing to re-visit the issue will be asked to review the writeup of the issue in the tracker and bring up only new arguments if they feel necessary.) In no event do we need running commentary on the list about participants' perceived misbehaviors. If you have a problem with a participant's behavior, bring it to the chair or the AD, off list. For the time being, until we are chartered, you may bring it to the AD. End of topic. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From dotis@mail-abuse.org Tue Sep 13 12:06:26 2011 Return-Path: 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 06D5521F8ACC for ; Tue, 13 Sep 2011 12:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.635 X-Spam-Level: X-Spam-Status: No, score=-103.635 tagged_above=-999 required=5 tests=[AWL=-1.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Q8INOfReRLOF for ; Tue, 13 Sep 2011 12:06:25 -0700 (PDT) Received: from SJDC-SDIRelay3.sdi.trendmicro.com (sjdc-sdirelay3.sdi.trendmicro.com [150.70.69.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3F41721F8ABB for ; Tue, 13 Sep 2011 12:06:25 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay3.sdi.trendmicro.com (Postfix) with ESMTP id 5D2336E0137 for ; Tue, 13 Sep 2011 19:08:30 +0000 (UTC) Received: from us-waynej-t42.client.us.trendnet.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id AC98FA9443C for ; Tue, 13 Sep 2011 19:08:30 +0000 (UTC) Message-ID: <4E6FAA2B.90400@mail-abuse.org> Date: Tue, 13 Sep 2011 12:08:27 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: domainrep@ietf.org References: <4E6809C0.1010100@mail-abuse.org> <20110908010255.GF37065@shinkuro.com> <4E681B91.7060601@mail-abuse.org> <4E6A7CD0.9090305@dcrocker.net> <4E6E5BE7.9090709@mail-abuse.org> <20110912153106.5c40e400@hydrogen.roaringpenguin.com> <4E6E8020.10307@mail-abuse.org> <20110912182459.643791ac@shishi.roaringpenguin.com> <4E6EA349.6050506@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 19:06:26 -0000 On 9/12/11 9:11 PM, Murray S. Kucherawy wrote: > > -----Original Message----- From: domainrep-bounces@ietf.org > > [mailto:domainrep-bounces@ietf.org] On Behalf Of Douglas Otis Sent: > > Monday, September 12, 2011 5:27 PM To: domainrep@ietf.org Subject: > > Re: [domainrep] Charter going to the IESG > > > > You are free to have an overly optimistic belief the lack of > > replay control permitted by ignoring sender and recipient won't be > > abused. Adding this "optimism" to the charter is still not wise nor > > necessary for such experimentation. > > Indeed, just as you are free to be overly (and singularly) > pessimistic about the potential of the concept. > > Nothing about what I said is in the charter though, except that the > charter doesn't preclude the idea. > > As Dave said, we are all aware that you have pet peeves with SPF and > DKIM, but there is clear consensus that the flaws you highlight ad > nauseam are at best corner cases that should not deter continued > advancement of this work or work on those protocols. Murray, Sorry for the trouble. This is only to challenge erroneous statements made in the charter as it relates to Security. ,-- "Various mechanisms have been developed for associating a verified identifier with email content, such as with SPF (RFC4408) and DKIM (RFC4871). ... Given the recent adoption of domain name verification for email, by SPF and DKIM, the most obvious initial use case for reputation is for email." '-- There are several Security problems with these two statements related to reputation that the Repute mailing list is unwilling to discuss. There is no reason to make them in the charter, where simple removal would be a remedy. Alternatively, this might suggest an experiment using DANE with outbound MTAs and there would also not be any Security concern wasting our time. The Security aspects relate to a domain's inability to defend their reputation when based upon either IP address authorization or signed messages that exclude sending domains and intended recipients. This has real DoS potential. There is no way to know whether statistical exceptions are legitimate. The "at best corner cases" represents every message sent from this mailing list or any message sent using BCC, for example. The same issues occur with shared outbound MTAs where every email potentially falls into easily exploitable "corner cases". Defending this requires that recipients refuse all exceptions. Email reputation is challenged to respond to the introduction of IPv6. Already the announced prefix space (ignoring the lower 64 bits) is more than 56,000 times the entire IPv4 address range and growing exponentially. Perhaps the prefix space alone will soon start flattening out at about 340,000 times that of the entire IPv4 address space. Deployment of IPv6 over IPv4 is problematic. The current strategy is to use Dual-Stack Lite. http://tools.ietf.org/html/rfc6333 http://tools.ietf.org/html/draft-bpw-pcp-nat-pmp-interworking-00 This moves CPE NAT to the ISP or enterprise tunnel over 192.0.0.0/29. This change in Internet infrastructure demands deprecation of IPv4 address based verifications, and replacement with secure end-to-end methods. Neither is meet by SPF or DKIM. There is little time to waste so we need to be smart and use the right tools. -Doug From msk@cloudmark.com Tue Sep 13 12:18:04 2011 Return-Path: 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 9EDBE11E80A2 for ; Tue, 13 Sep 2011 12:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.002 X-Spam-Level: X-Spam-Status: No, score=-103.002 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 yRVnFsCFJJdr for ; Tue, 13 Sep 2011 12:18:04 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 41C8A11E8083 for ; Tue, 13 Sep 2011 12:18:04 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 13 Sep 2011 12:20:11 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 13 Sep 2011 12:20:10 -0700 Thread-Topic: [domainrep] Charter going to the IESG Thread-Index: AcxySJQfVMX/DCOpSwefT8iwShOYyAAAPWjw Message-ID: References: <4E6809C0.1010100@mail-abuse.org> <20110908010255.GF37065@shinkuro.com> <4E681B91.7060601@mail-abuse.org> <4E6A7CD0.9090305@dcrocker.net> <4E6E5BE7.9090709@mail-abuse.org> <20110912153106.5c40e400@hydrogen.roaringpenguin.com> <4E6E8020.10307@mail-abuse.org> <20110912182459.643791ac@shishi.roaringpenguin.com> <4E6EA349.6050506@mail-abuse.org> <4E6FAA2B.90400@mail-abuse.org> In-Reply-To: <4E6FAA2B.90400@mail-abuse.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 19:18:04 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Douglas Otis > Sent: Tuesday, September 13, 2011 12:08 PM > To: domainrep@ietf.org > Subject: Re: [domainrep] Charter going to the IESG >=20 > Sorry for the trouble. This is only to challenge erroneous statements > made in the charter as it relates to Security. > [...] In light of Pete's recent post: I submit that the participants here have read and considered your concerns,= but there is no rough consensus supporting the idea that the charter needs= the change you are suggesting. Rather, consensus appears to agree that cr= eating a general reputation infrastructure with DKIM and SPF as example app= lications within it is the right way to proceed. -MSK From presnick@qualcomm.com Tue Sep 13 12:30:33 2011 Return-Path: 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 A821021F8BF6 for ; Tue, 13 Sep 2011 12:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.519 X-Spam-Level: X-Spam-Status: No, score=-106.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 rnuuyY5WEMSh for ; Tue, 13 Sep 2011 12:30:33 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 314C121F8BF3 for ; Tue, 13 Sep 2011 12:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1315942360; x=1347478360; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4E6FAEF3.7020406@qualcomm.com>|Date:=20Tu e,=2013=20Sep=202011=2014:28:51=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20"Murray=20S.=20Kucherawy"=20|CC:=20"domainrep@ietf.org"=20|Subject:=20Re:=20[domainrep]=20Charter=20going =20to=20the=20IESG|References:=20=09<4E6809 C0.1010100@mail-abuse.org>=09<20110908010255.GF37065@shin kuro.com>=09<4E681B91.7060601@mail-abuse.org>=20<4E6A7CD0 .9090305@dcrocker.net>=09<4E6E5BE7.9090709@mail-abuse.org >=09<20110912153106.5c40e400@hydrogen.roaringpenguin.com> =09<4E6E8020.10307@mail-abuse.org>=09<20110912182459.6437 91ac@shishi.roaringpenguin.com>=09=09<4E6EA 349.6050506@mail-abuse.org>=09=09<4E6FAA2B. 90400@mail-abuse.org>=20|In-Reply-To:=20|Content-Type:=20text/plain=3B=20charset=3D"IS O-8859-1"=3B=20format=3Dflowed|Content-Transfer-Encoding: =207bit|X-Originating-IP:=20[172.30.48.1]; bh=CPFDaG2L+01ToskYAhDv5H2HGE2eUD0kSQY3j58rLfE=; b=Vv+NbipOic64LOriMUzF8fmOTEk/0Gr+MBIHHXg2GHp0w/m0Dg5wSqw3 CYIR/Z8y5htC6q6QnwQsiBRZ7UQZU4qTNR7iADHW2cuGbe4r8W86mD7fE SJ8AJYTpykycbwMP1Uy3348r+ExIhmMcBS3A4ZOsqUKX0IoXVdnV3KdXA 0=; X-IronPort-AV: E=McAfee;i="5400,1158,6468"; a="118121418" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 13 Sep 2011 12:32:05 -0700 X-IronPort-AV: E=Sophos;i="4.68,374,1312182000"; d="scan'208";a="155685196" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 13 Sep 2011 12:32:05 -0700 Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 13 Sep 2011 12:28:53 -0700 Message-ID: <4E6FAEF3.7020406@qualcomm.com> Date: Tue, 13 Sep 2011 14:28:51 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <4E6809C0.1010100@mail-abuse.org> <20110908010255.GF37065@shinkuro.com> <4E681B91.7060601@mail-abuse.org> <4E6A7CD0.9090305@dcrocker.net> <4E6E5BE7.9090709@mail-abuse.org> <20110912153106.5c40e400@hydrogen.roaringpenguin.com> <4E6E8020.10307@mail-abuse.org> <20110912182459.643791ac@shishi.roaringpenguin.com> <4E6EA349.6050506@mail-abuse.org> <4E6FAA2B.90400@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Charter going to the IESG X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 19:30:33 -0000 I agree. And Doug, you are of course free (and encouraged) to make comments to the IESG when the charter goes out for IETF-wide review. I assure you that your comments will be taken under consideration. pr On 9/13/11 2:20 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On >> Behalf Of Douglas Otis >> Sent: Tuesday, September 13, 2011 12:08 PM >> To: domainrep@ietf.org >> Subject: Re: [domainrep] Charter going to the IESG >> >> Sorry for the trouble. This is only to challenge erroneous statements >> made in the charter as it relates to Security. >> [...] >> > In light of Pete's recent post: > > I submit that the participants here have read and considered your concerns, but there is no rough consensus supporting the idea that the charter needs the change you are suggesting. Rather, consensus appears to agree that creating a general reputation infrastructure with DKIM and SPF as example applications within it is the right way to proceed. > > -MSK > -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From msk@cloudmark.com Thu Sep 22 12:01:01 2011 Return-Path: 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 05ED11F0C51 for ; Thu, 22 Sep 2011 12:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.481 X-Spam-Level: X-Spam-Status: No, score=-103.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 Sng4NerR9tJ5 for ; Thu, 22 Sep 2011 12:01:00 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 82DC01F0C58 for ; Thu, 22 Sep 2011 12:00:52 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 22 Sep 2011 12:03:24 -0700 From: "Murray S. Kucherawy" To: "dcrocker@bbiw.net" , "domainrep@ietf.org" Date: Thu, 22 Sep 2011 12:03:23 -0700 Thread-Topic: [domainrep] Comments on -model-00 (full set) Thread-Index: AcxxnhTkRkOF2xjxRbyKJM9Q+oZxQwHuV1cg Message-ID: References: <4E6E8C31.7040808@dcrocker.net> In-Reply-To: <4E6E8C31.7040808@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] Comments on -model-00 (full set) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 19:01:01 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Dave CROCKER > Sent: Monday, September 12, 2011 3:48 PM > To: domainrep@ietf.org > Subject: [domainrep] Comments on -model-00 (full set) >=20 > On the current -model-00 document: >=20 > 1. By citing the related documents, you make the publication of this doc= ument > be gated on their being published first. That's the reason I'm not a fan= of > "forward" pointers like this. (It only gets worse as more documents list = the > component set.) Originally, I fully expected this to exit the working group as a document c= luster. I'm less convinced now though. I'd be fine removing that chunk from all the documents. > In contrast citing functional divisions, without citing specific document= s, lays > the groundwork with no gating. The later documents, of course, can have = a > backward reference that declares which function(s) from the set they > cover. That seems a fine substitute. > The current 'model' is for the localized mechanism, without reference to = the > larger, systemic framework for identification and assessment that this pi= ece > fits into. Figure 1 (RFC 5863) and Figure 1 (RFC 5585) attempt the sort = of > full-system description. I suggest that the model document, here, should= deal > with the full architecture, so that it's clear where the current work fit= s into > a true, end-to-end email service. If any of the existing diagrams and > discussion are sufficient, just cite them. If they need elaboration, per= haps > build on them? That also seems fine, although I realize now I'm volunteering Nathaniel to = do this work since he's taking over the -model document. :-) > 2. Potential redundancy and synchronization challenges. >=20 > Section 4 lists information components. I suspect that that is a redunda= nt list > with the media-type document and will need to be synchronized. Every cha= nge > requires updating two documents... Perhaps the model document can be res= tricted > to discussion of core issues about a media-type rather than going into > details? That'd probably be fine. > 3. Bias >=20 > I like the intent of Section 7.1 but suspect it lays a trap for itself. O= pinion > is, by its definition, biased. Objectivity when making an assessment of > quality, is really about process and not conclusion. >=20 > I suspect the real issues are transparency about criteria and consistency= in > their application. That's not quite the same thing as being unbiased. >=20 > An essential point about the proposed work is that it has nothing to do w= ith the > basis for choosing criteria nor with the way in which they are applied. I= t does > permit listing underlying information, which can aid transparency. >=20 > But fundamentally it is about representing and obtaining data in a standa= rdized > way, rather than assessing its merits. I think the point is to be clear about what the report is trying to say and= how certain the reporter is about the claim being made. Requesting reput= ation about example.com, with no other parameters, leaves the requesting en= tity in a position where it must assume what the reply means, or must reque= st a detailed reply that allows it to confirm such an understanding; the re= putation of example.com when used in DKIM signatures might be different tha= t the reputation of example.com when delivered by SPF. The assumption (which is necessary for the lightweight query) means the req= uesting entity already has a good understanding of what the data mean. Per= haps the reputation service it's querying has declared that it only produce= s reputations based on DKIM signatures, or something like that, so the addi= tional detail isn't needed. The heavyweight query on the other hand is structured that it can say somet= hing like "reputation of example.com is X when based on DKIM". What came up in the BoF was the need for transitivity, so that if you want = to change reputation providers within the email space, you don't have to wo= rry that a 0.5 from provider A means something totally different than it wo= uld from provider B (say, one of them is linear while the other is logarith= mic). But I think that goes in the specific vocabulary documents, though t= he general concept can be introduced in the model document. From msk@cloudmark.com Thu Sep 22 13:19:07 2011 Return-Path: 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 48FF711E8091 for ; Thu, 22 Sep 2011 13:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.981 X-Spam-Level: X-Spam-Status: No, score=-102.981 tagged_above=-999 required=5 tests=[AWL=-0.382, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 smb5xpjb20t2 for ; Thu, 22 Sep 2011 13:19:06 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC4311E808D for ; Thu, 22 Sep 2011 13:19:06 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 22 Sep 2011 13:21:38 -0700 From: "Murray S. Kucherawy" To: "dcrocker@bbiw.net" , "domainrep@ietf.org" Date: Thu, 22 Sep 2011 13:21:38 -0700 Thread-Topic: [domainrep] Comments on -media-type-00 Thread-Index: AcxxnlV/2smcK2w1Qnugl+hxOfd3ZgHxZi8g Message-ID: References: <4E6E8C84.1090803@dcrocker.net> In-Reply-To: <4E6E8C84.1090803@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] Comments on -media-type-00 X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 20:19:07 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Dave CROCKER > Sent: Monday, September 12, 2011 3:50 PM > To: domainrep@ietf.org > Subject: [domainrep] Comments on -media-type-00 >=20 > On the current -media-type-00 document: >=20 > 1. Same concern about forward references as my first comment in the - mod= el > document, just sent. We should avoid redundancy and forward pointers. Agree (see other message). > 2. I suggest that the DNS response be modeled as a subset of this more ge= neral > media-type, so that one can obtain that kind of good/bad simple informati= on > through the same mechanism as the more extensive information. Hence, the > DNS-based mechanism becomes a kind of data profile, possibly with a diffe= rent > syntax. Seems reasonable. > On review, I'm also not clear that this isn't already the same as wha= t > should be in a DNS response, in which case I'm not clear how the more ext= ensive > information that justified an HTTP mechanism is reported. If I understand what you're saying here, it's related to what I said in my = other reply: The lightweight reply doesn't contain any of the meta-data abo= ut the reputation reply that qualifies what it's saying; there's a lot of i= mplicit understanding about the meaning of the reply when using the lightwe= ight method for which space is provisioned in the heavyweight version.