From nsb@guppylake.com Sun Oct 2 05:56:36 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 771C721F8C6A for ; Sun, 2 Oct 2011 05:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 4AwrBvVZeW-w for ; Sun, 2 Oct 2011 05:56:35 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id 3B98D21F8C63 for ; Sun, 2 Oct 2011 05:56:35 -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:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=AZAZTk/64gRrcFd066oWgSOXEz27cM26ASqP4SdVrgJcmEGLOXnvt+6XD7lZX9eatbY5MM+wqFrBWlUJELugVIPk750282xcd5rMADYbg6o8oxaRXuHEdiVYKaW52gbv; Received: from 184-217-9-150.pools.spcsdns.net ([184.217.9.150] helo=[192.168.0.197]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1RALda-0008Qp-QJ; Sun, 02 Oct 2011 08:59:25 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: Date: Sun, 2 Oct 2011 08:59:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4401A1D2-BD8C-40AC-81F9-AC4BC17D15B8@guppylake.com> References: <4E6E8C31.7040808@dcrocker.net> 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" , "dcrocker@bbiw.net" 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: Sun, 02 Oct 2011 12:56:36 -0000 I'm fine with all of Dave's comments, though some of them may be tricky = to word correctly. The one that concerns me most is this one: > 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? I definitely want to avoid the redundancy, but I also want the model doc = to convey enough information that a fresh reader can figure out what the = point is. I'm sure it can be done, but it may take a few drafts. I was hoping to get a few more people to comment before I put together = another draft. Can we beat the bushes for more reviewers, perhaps? -- = Nathaniel On Sep 22, 2011, at 3:03 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] = On Behalf 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 = 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.) >=20 > Originally, I fully expected this to exit the working group as a = document cluster. I'm less convinced now though. >=20 > I'd be fine removing that chunk from all the documents. >=20 >> 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. >=20 > That seems a fine substitute. >=20 >> 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? >=20 > That also seems fine, although I realize now I'm volunteering = Nathaniel to do this work since he's taking over the -model document. = :-) >=20 >> 2. Potential redundancy and synchronization challenges. >>=20 >> 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? >=20 > That'd probably be fine. >=20 >> 3. Bias >>=20 >> 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. >>=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 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. >>=20 >> But fundamentally it is about representing and obtaining data in a = standardized >> way, rather than assessing its merits. >=20 > 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 reputation about example.com, with no other parameters, = leaves the requesting entity in a position where it must assume what the = reply means, or must request a detailed reply that allows it to confirm = such an understanding; the reputation of example.com when used in DKIM = signatures might be different that the reputation of example.com when = delivered by SPF. >=20 > The assumption (which is necessary for the lightweight query) means = the requesting entity already has a good understanding of what the data = mean. Perhaps the reputation service it's querying has declared that it = only produces reputations based on DKIM signatures, or something like = that, so the additional detail isn't needed. >=20 > The heavyweight query on the other hand is structured that it can say = something like "reputation of example.com is X when based on DKIM". >=20 > 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 worry that a 0.5 from provider A means something totally = different than it would from provider B (say, one of them is linear = while the other is logarithmic). But I think that goes in the specific = vocabulary documents, though the general concept can be introduced in = the model document. > _______________________________________________ > domainrep mailing list > domainrep@ietf.org > https://www.ietf.org/mailman/listinfo/domainrep From Jeff.Hodges@KingsMountain.com Tue Oct 4 09:42: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 DD13E21F8AEE for ; Tue, 4 Oct 2011 09:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.184 X-Spam-Level: X-Spam-Status: No, score=-99.184 tagged_above=-999 required=5 tests=[AWL=-1.289, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 R2IMXVhh4zxT for ; Tue, 4 Oct 2011 09:42:37 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 5389321F8801 for ; Tue, 4 Oct 2011 09:42:33 -0700 (PDT) Received: (qmail 7312 invoked by uid 0); 4 Oct 2011 16:45:37 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 4 Oct 2011 16:45:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=YQItciI7E99uuNH8trgMzHk+4Nrm5hqSt9uyctxsCLA=; b=75wq6ahgrLtYweTaLRp8UKWsinLu4IZjpCq87NdKigtmUX4nHHJn9jtlhFXZdFglm+Z4gBEbTYxGhvWyL9izA0LnrxcJZT15w9XHs1CT/HGtL/OicX8kiYS3DR+3E8V7; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.226]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RB87d-0005Il-4Y for domainrep@ietf.org; Tue, 04 Oct 2011 10:45:37 -0600 Message-ID: <4E8B3830.9040707@KingsMountain.com> Date: Tue, 04 Oct 2011 09:45:36 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: domainrep@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [domainrep] fyi: eliciting truthful and useful ratings online 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, 04 Oct 2011 16:42:38 -0000 of possible related interest... Subject: PCD 10/7/11 - Lada Adamic, University of Michigan, To Friend and Trust From: Terry Winograd Date: Mon, 3 Oct 2011 13:34:37 -0700 To: pcd-seminar@mailman.stanford.edu, colloq-local-list@mailman.stanford.edu, post@seminarfeed.com, hci-research@mailman.stanford.edu, hci-students@mailman.stanford.edu, symsys-students@mailman.stanford.edu, froshsem-cs47n@lists.stanford.edu Cc: adamic@umich.edu, wit@psych.stanford.edu Stanford Seminar on People, Computers, and Design (CS547: HCI Seminar) http://hci.stanford.edu/seminar/ October 7, 2011 12:50-2:00 pm, Gates B01 Lada Adamic, University of Michigan ladamic@umich.edu To friend and to trust: eliciting truthful and useful ratings online Online rating and reputation systems have shown themselves to be essential for filtering content, building trust, and fostering communities. However, these ratings should not be taken at face value. When individuals submit ratings online, especially ratings of other people, they are being asked to quantify inherently subjective feelings. To complicate matters, they may formulate their ratings differently if these are shown to others, and if those others can reciprocate. In this talk I will present two studies that combine data analysis of several online data sets. For one such system, CouchSurfing.org, I will discuss findings from a large- scale survey and in-depth interviews to examine from multiple angles the challenges that users have in providing useful and truthful ratings. We find, for example, that the potential to reciprocate produces higher and more correlated ratings than when individuals are unable to see how others rated them. Ratings further can depend on the gender, age and nationalities of the raters and rates.All of these findings indicate that ratings should not be taken at face value without considering social nuances. NEXT WEEK: Paul (Whitmore) Sas, Interaction Design for the Quantified Self From dhc@dcrocker.net Mon Oct 10 18:10:57 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 E163E21F8922 for ; Mon, 10 Oct 2011 18:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 jDfB8-lOvSj9 for ; Mon, 10 Oct 2011 18:10:57 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1721521F87F0 for ; Mon, 10 Oct 2011 18:10:55 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p9B1Amtn004794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 Oct 2011 18:10:54 -0700 Message-ID: <4E939792.6040102@dcrocker.net> Date: Mon, 10 Oct 2011 18:10:42 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 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, 10 Oct 2011 18:10:54 -0700 (PDT) Subject: [domainrep] Discussion items for Repute session at Taipei 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, 11 Oct 2011 01:10:58 -0000 Folks, Howdy. It looks as if we will have a one-hour session in Taipei. We're trying to assemble and agenda. Are there specific items you would like to see discussed, especially items of some disagreement that might be able to make some progress? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Thu Oct 13 15:24: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 1241021F8B84 for ; Thu, 13 Oct 2011 15:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.162 X-Spam-Level: X-Spam-Status: No, score=-103.162 tagged_above=-999 required=5 tests=[AWL=0.438, 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 l-i68uFafCzf for ; Thu, 13 Oct 2011 15:24:40 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9711F21F8B8F for ; Thu, 13 Oct 2011 15:24:40 -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, 13 Oct 2011 15:24:40 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Thu, 13 Oct 2011 15:24:38 -0700 Thread-Topic: [domainrep] Discussion items for Repute session at Taipei Thread-Index: AcyHsqzNFcLad98nSxGUr1Ox4o11LQCQrLHw Message-ID: References: <4E939792.6040102@dcrocker.net> In-Reply-To: <4E939792.6040102@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] Discussion items for Repute session at Taipei 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, 13 Oct 2011 22:24:41 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Dave CROCKER > Sent: Monday, October 10, 2011 6:11 PM > To: domainrep@ietf.org > Subject: [domainrep] Discussion items for Repute session at Taipei >=20 > It looks as if we will have a one-hour session in Taipei. We're trying t= o > assemble and agenda. >=20 > Are there specific items you would like to see discussed, especially item= s of > some disagreement that might be able to make some progress? In general, a review of the established charter and the documents we have (= and who's editing them) would be good to set the stage and start getting wo= rk done. I think our current documents cover most of the pre-BoF topics, b= ut not necessarily some of the concerns that were brought up during the BoF= . Beginning to track those would be a good idea to make sure they don't ge= t lost. There are two discussions we might consider having in person, time permitti= ng, just to get our debate and decisions about them on the record: 1) XML vs. JSON; the drafts currently use XML, but JSON is the new hotness = especially for small objects, which nicely describes the reputon. My own p= reference is for XML because the availability of mature parsing code is mor= e widespread than it is for JSON, but that view could be myopic. 2) DNS vs. a new UDP thing: We have stub drafts for both. It's hardly a ne= w argument. By the time of Taipei, I will have a sample implementation based on our cur= rent drafts and will have some implementation and operational anecdotes to = share. In particular, I made one change to the long-form query, adding an = "updated" field that indicates as of what timestamp the reported reputation= was considered "current"; a new draft has been uploaded already reflecting= this. Also, Mark Nottingham pointed me at http://tools.ietf.org/html/draft-gregor= io-uritemplate-07, a proposed method for describing to an application how t= o construct a URI for doing queries. The template for REPUTE could be stor= ed in the DNS in a predictable TXT record or some other discovery method wi= th a default specified in our draft; the REPUTE client retrieves this and t= hen uses it, or the default, to construct the actual REPUTE query. It look= s good to me, especially as I am in the midst of implementing a sample serv= er and have run into a difficulty in this area. I'll also have that to tal= k about by the time of Taipei. -MSK From dhc@dcrocker.net Thu Oct 13 15:52: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 F39CA21F8B34 for ; Thu, 13 Oct 2011 15:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 HlVwHvg5bi6Q for ; Thu, 13 Oct 2011 15:52:51 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCC821F8AC3 for ; Thu, 13 Oct 2011 15:52:51 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p9DMqgcf012230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Oct 2011 15:52:49 -0700 Message-ID: <4E976BB1.4040300@dcrocker.net> Date: Thu, 13 Oct 2011 15:52:33 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <4E939792.6040102@dcrocker.net> In-Reply-To: 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]); Thu, 13 Oct 2011 15:52:50 -0700 (PDT) Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Discussion items for Repute session at Taipei 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: Thu, 13 Oct 2011 22:52:52 -0000 On 10/13/2011 3:24 PM, Murray S. Kucherawy wrote: > There are two discussions we might consider having in person, time > permitting, just to get our debate and decisions about them on the record: > > 1) XML vs. JSON; the drafts currently use XML, but JSON is the new hotness > especially for small objects, which nicely describes the reputon. My own > preference is for XML because the availability of mature parsing code is more > widespread than it is for JSON, but that view could be myopic. > > 2) DNS vs. a new UDP thing: We have stub drafts for both. It's hardly a new > argument. Because face2face time at IETF meetings is so scarce, the long-standing and very strong preference in the IETF is to focus on "issues" rather than "review" or "tutorial". As such, the "time permitting" should apply to the review more than to these 2 isues. In other words, swap the prioritization. However since it doesn't make sense to have the review come second, I think it's a matter of biasing the time allocation towards discussion of these two issues, at the expense of the introductory material. Happily, as you note, these are topic with well-understood underlying details. Their resolution is more a matter of exploring preferences than in understanding differences. Still, any discussion takes time. I'll > Also, Mark Nottingham pointed me at > http://tools.ietf.org/html/draft-gregorio-uritemplate-07, a proposed method > for describing to an application how to construct a URI for doing queries. > The template for REPUTE ... I assume that this would be a way of having a service declare what attributes it supports having queried? Does that need anything as lofty as a URI or as complex as this proposal permits? And with that latter question, I think I'm demonstrating that this is likely a fuzzier (ie, more interesting) topic. My own reaction is to suggest that we allocate 45 minutes for these 3 items, trying to keep the first two to about 10 minutes each. And, yes, that means 15 minutes total for "hello and this is the set of documents we are working on and this is what they cover". I'll suggest leaving the implementation report to the end, if there is time. That's a proposal for revising the proposed agenda. Reactions? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dfs@roaringpenguin.com Thu Oct 13 19:03:30 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 C600E21F8C04 for ; Thu, 13 Oct 2011 19:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 7j5Avo5oPL8k for ; Thu, 13 Oct 2011 19:03:30 -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 1592121F8BA0 for ; Thu, 13 Oct 2011 19:03:29 -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 p9E23OUg009046 for ; Thu, 13 Oct 2011 22:03:25 -0400 Received: from eee (dfs-eee.vpn.roaringpenguin.com [192.168.7.14]) by vanadium.roaringpenguin.com (8.14.3/8.14.3/Debian-9.4) with ESMTP id p9E23K8v024602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 13 Oct 2011 22:03:24 -0400 Date: Thu, 13 Oct 2011 22:03:14 -0400 From: "David F. Skoll" To: domainrep@ietf.org Message-ID: <20111013220314.713cd9be@eee> In-Reply-To: References: <4E939792.6040102@dcrocker.net> Organization: Roaring Penguin Software Inc. X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i486-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=A4EzzNuMasWT gdA3k640QZP/cls=; b=f35sHJT/gDQsoo44ELTmkeRGPZ5t6KpfM0P5YNPmwMpq wuUU98k2QbTydj2dZe5YQfU625oYtZmtYArJVkHsWe2h7A2XIdATybW82059H9p9 7qcKsBmM2oStZNVWXPZokMPJxoo/RgikTe7diQbsfbFrJKXpnY8moVJmYkiOvBE= 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/20111013 / 01FIq3oHb Subject: Re: [domainrep] Discussion items for Repute session at Taipei 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, 14 Oct 2011 02:03:30 -0000 On Thu, 13 Oct 2011 15:24:38 -0700 "Murray S. Kucherawy" wrote: > 1) XML vs. JSON; the drafts currently use XML, but JSON is the new > hotness especially for small objects, which nicely describes the > reputon. My own preference is for XML because the availability of > mature parsing code is more widespread than it is for JSON, but that > view could be myopic. +1 for ABX (Anything But XML) :) I like JSON. There are pretty good JSON parsers for most programming languages. My beef with XML is that it's ugly, hard for humans to read, and prone to abuse (eg, people encoding bitfields in XML... ugh.) Regards, David. From johnl@iecc.com Thu Oct 13 19:25: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 008B321F8BF6 for ; Thu, 13 Oct 2011 19:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.477 X-Spam-Level: X-Spam-Status: No, score=-108.477 tagged_above=-999 required=5 tests=[AWL=2.722, 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 sOmC1E+ST9Qx for ; Thu, 13 Oct 2011 19:25:00 -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 6891D21F8BF4 for ; Thu, 13 Oct 2011 19:25:00 -0700 (PDT) Received: (qmail 12016 invoked from network); 14 Oct 2011 02:24:59 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 14 Oct 2011 02:24:59 -0000 Received: (qmail 1271 invoked from network); 14 Oct 2011 02:24:58 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Oct 2011 02:24:58 -0000 Date: 14 Oct 2011 02:24:36 -0000 Message-ID: <20111014022436.3309.qmail@joyce.lan> From: "John Levine" To: domainrep@ietf.org In-Reply-To: <20111013220314.713cd9be@eee> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [domainrep] Discussion items for Repute session at Taipei 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, 14 Oct 2011 02:25:01 -0000 >> 1) XML vs. JSON; the drafts currently use XML, but JSON is the new >> hotness especially for small objects, which nicely describes the >> reputon. Unless there's some technical issue beyond the generic XML vs. JSON ones, this doesn't sound like it would be particularly productive to try and resolve this in Taipei. Either could work, which might work better depends on whether the only issue is defining a container format (advantage JSON) or whether we turn out to be doing something that the mountain of existing tools already does (advantage XML.) R's, John From dhc@dcrocker.net Fri Oct 14 09:25: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 856DF21F8C65 for ; Fri, 14 Oct 2011 09:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 5Gbvehcb99Qp for ; Fri, 14 Oct 2011 09:25:23 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 09AAF21F8C55 for ; Fri, 14 Oct 2011 09:25:23 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p9EGPH45013865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Oct 2011 09:25:22 -0700 Message-ID: <4E986263.5050602@dcrocker.net> Date: Fri, 14 Oct 2011 09:25:07 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 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]); Fri, 14 Oct 2011 09:25:22 -0700 (PDT) Subject: [domainrep] Repute session slot @ taipei 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, 14 Oct 2011 16:25:23 -0000 The one-hour session for Repute has been scheduled at 3:10-4:10pm, Wednesday. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Mon Oct 17 11:42:40 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 BCBC721F8B5C for ; Mon, 17 Oct 2011 11:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.72 X-Spam-Level: X-Spam-Status: No, score=-102.72 tagged_above=-999 required=5 tests=[AWL=-0.121, 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 c8VCkhJJwqcG for ; Mon, 17 Oct 2011 11:42:40 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 455D221F8B62 for ; Mon, 17 Oct 2011 11:42:40 -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, 17 Oct 2011 11:42:23 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Mon, 17 Oct 2011 11:42:22 -0700 Thread-Topic: [domainrep] Discussion items for Repute session at Taipei Thread-Index: AcyJ+tYgyC1Xo8/BTCygZ5pj3S5oHgDACgng Message-ID: References: <4E939792.6040102@dcrocker.net> <4E976BB1.4040300@dcrocker.net> In-Reply-To: <4E976BB1.4040300@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] Discussion items for Repute session at Taipei 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, 17 Oct 2011 18:42:40 -0000 > -----Original Message----- > From: Dave CROCKER [mailto:dhc@dcrocker.net] > Sent: Thursday, October 13, 2011 3:53 PM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] Discussion items for Repute session at Taipei >=20 > > 1) XML vs. JSON; the drafts currently use XML, but JSON is the new hotn= ess > > especially for small objects, which nicely describes the reputon. My o= wn > > preference is for XML because the availability of mature parsing code i= s more > > widespread than it is for JSON, but that view could be myopic. > > > > 2) DNS vs. a new UDP thing: We have stub drafts for both. It's hardly = a new > > argument. >=20 > Because face2face time at IETF meetings is so scarce, the long-standing a= nd very > strong preference in the IETF is to focus on "issues" rather than "review= " or > "tutorial". As such, the "time permitting" should apply to the review mo= re than > to these 2 isues. In other words, swap the prioritization. Both arguments are interesting but I'm prepared to accept consensus. For t= he first question, I'm currently partial to XML but only because the parsin= g libraries are mature and supported, and that's what my sample implementat= ion has used. I also only did the heavyweight (XML) query and not the ligh= tweight (DNS) one, so I have no skin in the game there yet. > I assume that this would be a way of having a service declare what attrib= utes it > supports having queried? Does that need anything as lofty as a URI or as > complex as this proposal permits? Mark states that current practice on the web side of things is to support t= emplates like this, so any given reputation service can announce how it wan= ts clients to format queries rather than having a fixed URI format specifie= d in an RFC to which both sides must conform. What's missing (deliberately= ) from that draft is the mechanism by which a particular service's URI temp= late is discovered, so our HTTP document would need to come up with somethi= ng. Off the top of my head, the best ideas are a DNS TXT query to a fixed = name (e.g., for a reputation service based at "repute.example.com", do a TX= T query to "_qt.repute.example.com" to ask for a template, falling back to = something in the draft if none is found), or to do an HTTP query to a fixed= URI relative to the reputation service looking for the template (again wit= h a fallback to something documented). > And with that latter question, I think I'm demonstrating that this is lik= ely a > fuzzier (ie, more interesting) topic. I'll aim to implement one or the other in time for Taipei and let that be f= odder for discussion. > My own reaction is to suggest that we allocate 45 minutes for these 3 ite= ms, > trying to keep the first two to about 10 minutes each. >=20 > And, yes, that means 15 minutes total for "hello and this is the set of > documents we are working on and this is what they cover". >=20 > I'll suggest leaving the implementation report to the end, if there is > time. Sounds good to me. -MSK From leifj@mnt.se Mon Oct 17 17:41: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 E3A7911E80AE for ; Mon, 17 Oct 2011 17:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 KB-WjaefRri8 for ; Mon, 17 Oct 2011 17:41:46 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id C32DF11E8095 for ; Mon, 17 Oct 2011 17:41:45 -0700 (PDT) Received: from [10.66.224.31] (h-64-236-139-254.aoltw.net [64.236.139.254]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p9I0fapo009306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Oct 2011 02:41:43 +0200 (CEST) Message-ID: <4E9CCB40.8010208@mnt.se> Date: Tue, 18 Oct 2011 02:41:36 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: domainrep@ietf.org References: <4E939792.6040102@dcrocker.net> <20111013220314.713cd9be@eee> In-Reply-To: <20111013220314.713cd9be@eee> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Discussion items for Repute session at Taipei 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, 18 Oct 2011 00:41:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/14/2011 04:03 AM, David F. Skoll wrote: > On Thu, 13 Oct 2011 15:24:38 -0700 > "Murray S. Kucherawy" wrote: > >> 1) XML vs. JSON; the drafts currently use XML, but JSON is the new >> hotness especially for small objects, which nicely describes the >> reputon. My own preference is for XML because the availability of >> mature parsing code is more widespread than it is for JSON, but that >> view could be myopic. > > +1 for ABX (Anything But XML) :) > > I like JSON. There are pretty good JSON parsers for most programming > languages. > > My beef with XML is that it's ugly, hard for humans to read, and prone > to abuse (eg, people encoding bitfields in XML... ugh.) A word of warning though - JSON gets really ugly if you have to do namespace managment. Usually this winds up being an issue with extensibility so if you can keep extensibility suitably "bottled up" then JSON has a clear advantage in terms of readability. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6cy0AACgkQ8Jx8FtbMZneXIgCgoYXhND2NnEZMdt3PD9dHJTsS AKgAoLk3pPyzziC/cEp8dNkTj5WC3LrO =pKFL -----END PGP SIGNATURE----- From dotis@mail-abuse.org Mon Oct 17 19:08: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 07BF61F0C43 for ; Mon, 17 Oct 2011 19:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 oUQgD3yePKjN for ; Mon, 17 Oct 2011 19:08:27 -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 06AC711E80AF for ; Mon, 17 Oct 2011 19:08:26 -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 D80D0308147 for ; Tue, 18 Oct 2011 02:08:24 +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 879BFA9443B for ; Tue, 18 Oct 2011 02:08:25 +0000 (UTC) Message-ID: <4E9CDF91.7050704@mail-abuse.org> Date: Mon, 17 Oct 2011 19:08:17 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: domainrep@ietf.org References: <4E939792.6040102@dcrocker.net> <4E976BB1.4040300@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Discussion items for Repute session at Taipei 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, 18 Oct 2011 02:08:28 -0000 On 10/17/11 11:42 AM, Murray S. Kucherawy wrote: >>> 1) XML vs. JSON; the drafts currently use XML, but JSON is the new hotness >>> especially for small objects, which nicely describes the reputon. My own >>> preference is for XML because the availability of mature parsing code is more >>> widespread than it is for JSON, but that view could be myopic. >>> >>> 2) DNS vs. a new UDP thing: We have stub drafts for both. It's hardly a new >>> argument. >> Because face2face time at IETF meetings is so scarce, the long-standing and very >> strong preference in the IETF is to focus on "issues" rather than "review" or >> "tutorial". As such, the "time permitting" should apply to the review more than >> to these 2 isues. In other words, swap the prioritization. > Both arguments are interesting but I'm prepared to accept consensus. For the first question, I'm currently partial to XML but only because the parsing libraries are mature and supported, and that's what my sample implementation has used. I also only did the heavyweight (XML) query and not the lightweight (DNS) one, so I have no skin in the game there yet. Overhead is a significant concern affecting performance, where JSON (JavaScript Object Notation) wins over XML. It uses name/value pairs and ordered value lists. http://www.json.org/ Twitter now exclusively uses JSON, for example. You'll find JSON language extensions for all computer languages for this lighter weight structuring. >> I assume that this would be a way of having a service declare what attributes it >> supports having queried? Does that need anything as lofty as a URI or as >> complex as this proposal permits? > Mark states that current practice on the web side of things is to support templates like this, so any given reputation service can announce how it wants clients to format queries rather than having a fixed URI format specified in an RFC to which both sides must conform. What's missing (deliberately) from that draft is the mechanism by which a particular service's URI template is discovered, so our HTTP document would need to come up with something. Off the top of my head, the best ideas are a DNS TXT query to a fixed name (e.g., for a reputation service based at "repute.example.com", do a TXT query to "_qt.repute.example.com" to ask for a template, falling back to something in the draft if none is found), or to do an HTTP query to a fixed URI relative to the reputation service looking for the template (again with a fallback to something documented). Please do not reinvent yet another discovery mechanism. Use SRV records and conventions and not TXT records. It seems email suffers from the NIH factor and has already invented a significant number of TXT record formats. There are already many services and systems able to immediately use standard SRV conventions in an effective manner. >> And with that latter question, I think I'm demonstrating that this is likely a >> fuzzier (ie, more interesting) topic. > I'll aim to implement one or the other in time for Taipei and let that be fodder for discussion. Although I was in Taipei this time last year, I won't be able to make it, but I am sure others will take my place. :^) >> My own reaction is to suggest that we allocate 45 minutes for these 3 items, >> trying to keep the first two to about 10 minutes each. >> >> And, yes, that means 15 minutes total for "hello and this is the set of >> documents we are working on and this is what they cover". >> >> I'll suggest leaving the implementation report to the end, if there is >> time. > Sounds good to me. The world has remained fairly litigious. What has changed is that people have been trained that complaining is a waste and grow frustrated instead. As a result, there is a shrinking percentage of these duffers left. It seems setting aside some time to consider the merits of defending reputations through use of authentication as an expressed minimum requirement could provide benefits by changing the negative trends. Neither SPF nor DKIM can properly defend domains. This is not about semantics, it is about the differences between authorization, and signatures that omit senders and intended recipients against actually authenticating _accountable_ domains. These two schemes largely support white-listing of domains considered "too big to block" and glaringly lack a practical means to defend smaller domains or at inhibiting spam. It is interesting that services like twitter's ad revenue unique criteria gives them an incentive to quickly cancel abusive accounts. Two seconds later, they may reappear under a different name. For email to compete with social networks, a light weight method to authenticate outbound MTAs is needed, or eventually email will be supplanted by various proprietary services. Many domains are not aware of their incoming connection failures due to loads they don't see in SMTP logs. Incoming messages might not be blocked, but may never get through the noise. In the face of IPv6, address authorizations schemes will become increasingly problematic and disruptive. Email needs to take a lesson from social networks, where each develops their own "buddy" list as an overlay to what is maintained by individual users. To: Postmaster@example.com From: Postmaster@new.example.com Please add this new service to your "buddy" list. I understand failure to respond to your complaints in a timely manner may cause my domain to be removed from your "buddy" list. -Doug From vesely@tana.it Tue Oct 18 03:57: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 7352F21F89B8 for ; Tue, 18 Oct 2011 03:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.392 X-Spam-Level: X-Spam-Status: No, score=-3.392 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 AbtwMj89np+s for ; Tue, 18 Oct 2011 03:57:10 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id CD02321F8A35 for ; Tue, 18 Oct 2011 03:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1318935427; bh=DEVsXcslf7IoTJ37MtScI2+o1t1aXrqBKOZk0vexCtc=; l=320; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ILoKGPHCq+NbSELrZpkeMB4Atf7q48HlWkdrm9wSL42j5I6ERcGCp9Adizsxm7u4s C6pO09ui1JJt+acwjUdKP4jzcCu8Ex/ki1PyQKdMZZqtIdDWDxgjgkEh4OZc6WiVnn +sSG+YESfULXFvcM1SkdC2A0iYKbyo5Sn1GuS590= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 18 Oct 2011 12:57:07 +0200 id 00000000005DC047.000000004E9D5B83.00004C22 Message-ID: <4E9D5B82.6070606@tana.it> Date: Tue, 18 Oct 2011 12:57:06 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: domainrep@ietf.org References: <4E939792.6040102@dcrocker.net> <4E976BB1.4040300@dcrocker.net> <4E9CDF91.7050704@mail-abuse.org> In-Reply-To: <4E9CDF91.7050704@mail-abuse.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Discussion items for Repute session at Taipei 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, 18 Oct 2011 10:57:10 -0000 On 18/Oct/11 04:08, Douglas Otis wrote: > For email to compete with social networks, a light weight method to > authenticate outbound MTAs is needed, or eventually email will be > supplanted by various proprietary services. That's already happening, albeit gradually. What a shame to be unable to preserve SMTP! From clewis+ietf@mustelids.ca Tue Oct 18 16:37:30 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 838B121F8AF2 for ; Tue, 18 Oct 2011 16:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 hswcm7nbvbin for ; Tue, 18 Oct 2011 16:37:30 -0700 (PDT) Received: from mail.mustelids.ca (unknown [174.35.130.2]) by ietfa.amsl.com (Postfix) with ESMTP id C649C21F8AF1 for ; Tue, 18 Oct 2011 16:37:29 -0700 (PDT) Received: from [192.168.0.8] (otter.mustelids.ca [192.168.0.8]) (authenticated bits=0) by mail.mustelids.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p9INWbjw030627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 18 Oct 2011 19:32:38 -0400 Message-ID: <4E9E0DAB.7000502@mustelids.ca> Date: Tue, 18 Oct 2011 19:37:15 -0400 From: Chris Lewis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: domainrep@ietf.org References: <4E939792.6040102@dcrocker.net> <4E976BB1.4040300@dcrocker.net> In-Reply-To: <4E976BB1.4040300@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Discussion items for Repute session at Taipei 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, 18 Oct 2011 23:37:30 -0000 On 11-10-13 06:52 PM, Dave CROCKER wrote: > My own reaction is to suggest that we allocate 45 minutes for these 3 > items, trying to keep the first two to about 10 minutes each. > > And, yes, that means 15 minutes total for "hello and this is the set of > documents we are working on and this is what they cover". > > I'll suggest leaving the implementation report to the end, if there is > time. > > That's a proposal for revising the proposed agenda. > > Reactions? This seems to be the best way. Expend the valuable time on the stuff that needs discussion and decision, the rest is more administrivia that is more amenable to email if necessary. I'd also suggest that in the first two sessions the time be expended in a straightforward listing of pros and cons, and then a vote. That way you can more easily keep within the time constraints. If you push the expectation of 13 minutes worth of "let's exhaustively list the pros and cons, do a show of hands", it should go smoothly. I wuz there when they voted between SSLv3 and whatever that was for TLS. _Months_ of fruitless wheel spinning ended in just a few minutes. I don't have any useful familiarity with either XML or JSON. I personally tend towards JSON, because of simplicity and readability while still being much more compact. The overhead in JSON parsing (both in time and space) is bound to be considerably less than that of XML. It really doesn't look like JSON tools are lacking despite the perception it being "new". On the DNS vs. "other UDP" light weight. From a pure practicality/adoption standpoint, the existing DNSBL mechanism handles surprisingly well what _most_ sites would contemplate (and often already are) using for the short and medium term - meaning manual discovery of policy&meaning&interpretation of resulting A records (via the issuer's service description (usually web site)). Given that most usage now and for the short-medium term future is adequately handled by DNSBL technology as it stands, anything else would have a pretty poor chance of achieving critical mass and success, even if it's "better" at the "fancier" end. Reinventing the wheel seems a poor use of our time. Putting an automatible discovery layer on top of what already exists should be interesting enough, and go a long way towards making the more sophisticated uses standardizable. From msk@cloudmark.com Fri Oct 21 15:16:30 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 2B0561F0C55 for ; Fri, 21 Oct 2011 15:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.102 X-Spam-Level: X-Spam-Status: No, score=-102.102 tagged_above=-999 required=5 tests=[AWL=-0.705, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, USER_IN_WHITELIST=-100, WEIRD_PORT=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 yZfDZeKXFT1s for ; Fri, 21 Oct 2011 15:16:28 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id E5BAE1F0C35 for ; Fri, 21 Oct 2011 15:16:28 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 21 Oct 2011 15:16:28 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Fri, 21 Oct 2011 15:16:27 -0700 Thread-Topic: [domainrep] Possible changes to the standard (HTTP) Thread-Index: AcxFTaf70d3xSMsPQZCkvV/FL7rFqRK71mYg Message-ID: References: <4E24335A.9000203@trustsphere.com> In-Reply-To: <4E24335A.9000203@trustsphere.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_F5833273385BB34F99288B3648C4F06F19C6C14BCFEXCHC2corpclo_" MIME-Version: 1.0 Subject: Re: [domainrep] Possible changes to the standard (HTTP) 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, 21 Oct 2011 22:16:30 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C14BCFEXCHC2corpclo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3RldmUsDQoNCknigJl2ZSBiZWVuIHdvcmtpbmcgb24gYSBmaXJzdCBpbXBsZW1lbnRhdGlv biBvZiB0aGUgcHJvcG9zZWQgc3lzdGVtIHVzaW5nIHRoZSBsb25nLWZvcm0gKEhUVFApIHF1ZXJ5 L3JlcGx5IGZvcm1hdC4gIEZpbmFsbHkgSSBoYXZlIHNvbWV0aGluZyB0byBzYXkgYWJvdXQgeW91 ciBtZXNzYWdlIGZyb20gYmFjayBpbiBKdWx5LiAg4pi6DQoNClRoZSBuZXcgc3BlY2lmaWNhdGlv biAoLTAyIHBvc3RlZCBhIGNvdXBsZSBvZiBkYXlzIGFnbykgbWFrZXMgdGhlIHF1ZXJ5IGZvcm1h dCB2YXJpYWJsZSBiYXNlZCBvbiBhIHRlbXBsYXRlIHRoZSBzZXJ2ZXIgcHJvdmlkZXMuICBCYXNp Y2FsbHksIGEgY2xpZW50IGNvbmZpZ3VyZWQgdG8gdXNlIHlvdXIgc2VydmVyIHdvdWxkIGhpdCBh IHJlc2VydmVkLCB3ZWxsLWtub3duIFVSSSBhdCB5b3VyIHNlcnZlciB0byBkb3dubG9hZCB0aGUg VVJJIHRlbXBsYXRlIGl0IHNob3VsZCB1c2UgdG8gbWFrZSBxdWVyaWVzIHRvIHlvdXIgc2Vydmlj ZS4gIFRoZW4gd2l0aCB2YWx1ZXMgdGhlIGNsaWVudCBjb21wdXRlcywgaXQgY29uc3RydWN0cyB0 aGUgYWN0dWFsIHF1ZXJ5IFVSSSBhbmQgbWFrZXMgdGhlIHF1ZXJ5Lg0KDQpJbiB5b3VyIGV4YW1w bGUsIHlvdSB1c2VkIGEgdm9jYWJ1bGFyeSBmb3Igc2VuZGVyIHJlcHV0YXRpb24sIOKAnHNlbmRl ci1yZXDigJ0uICBTbyBpbiB0aGUgY29udGV4dCBvZiB0aGUgUkVQVVRFIGZyYW1ld29yaywgeW91 IHdvdWxkIGNyZWF0ZSBhIHZvY2FidWxhcnkgZm9yIGVtYWlsIHNlbmRlciByZXB1dGF0aW9uIChz ZWUgdGhlIOKAnHZvY2Fi4oCdIGRyYWZ0cyBmb3IgYW4gZXhhbXBsZSkgdGhhdCBjcmVhdGVzIOKA nHNlbmRlci1yZXDigJ0gYXMgYSBSRVBVVEUgYXBwbGljYXRpb24sIGFuZCBzcGVjaWZ5IHdoYXQg YXNzZXJ0aW9ucyBhbmQgZXh0ZW5zaW9ucyBhcmUgZGVmaW5lZCB3aXRoaW4gaXQuICBUaGlzIGJh c2ljYWxseSBnaXZlcyB5b3UgdGhlIGZvcm1hdCB0aGF0IHRoZSByZXBseSB3aWxsIHRha2UuDQoN ClRoZSBxdWVyeeKAmXMgZm9ybWF0IGlzIHNwZWNpZmllZCBieSB0aGUgdGVtcGxhdGUuICBJbiB0 aGUgY3VycmVudCBIVFRQIGRyYWZ0LCB0aGUgZm91ciBtYW5kYXRvcnkgdmFsdWVzIGFyZSDigJxh cHBsaWNhdGlvbuKAnSwg4oCcc2NoZW1l4oCdLCDigJxzdWJqZWN04oCdIGFuZCDigJxzZXJ2aWNl 4oCdLiAgSW4geW91ciBhcHBsaWNhdGlvbiwgeW914oCZZCB3YW50IHRvIGluY2x1ZGUgYWRkaXRp b25hbCBtYW5kYXRvcnkgcGFyYW1ldGVycyB0byBhY2NvbW1vZGF0ZSB3aGF0IHlvdeKAmXJlIGRv aW5nIGhlcmUuICBUaGlzIG1lYW5zIEnigJlsbCBoYXZlIHRvIG1vZGlmeSB0aGUgSFRUUCBkb2N1 bWVudCB0byBtZW50aW9uIHRoYXQgdm9jYWJ1bGFyaWVzIGRlZmluZWQgYnkgb3RoZXIgZG9jdW1l bnRzIG1heSBhbHNvIGFkZCBvdGhlciBtYW5kYXRvcnkgcXVlcnkgcGFyYW1ldGVycy4gIEFuZCBp dCBsb29rcyBsaWtlIGVpdGhlciB0aGUg4oCcbW9kZWzigJ0gb3Ig4oCcbWVkaWEgdHlwZeKAnSBk b2N1bWVudCBuZWVkcyB0byBjcmVhdGUgdGhlIHZvY2FidWxhcnkgcmVnaXN0cnkgYW5kIHNwZWNp ZnkgcmVnaXN0cmF0aW9uIHByb2NlZHVyZXMsIGluY2x1ZGluZyBsaXN0aW5nIG90aGVyIG1hbmRh dG9yeSBxdWVyeSBwYXJhbWV0ZXJzLg0KDQpBbGwgdGhpcyB0YWxrIG9mIHF1ZXJ5IHRlbXBsYXRl cyBhbmQgc28gZm9ydGggaXMgc3RhcnRpbmcgdG8gbWFrZSBtZSB3b25kZXIgaWYgYSBsaWdodHdl aWdodCBETlMtYmFzZWQgbWVjaGFuaXNtIGlzIGV2ZW4gcGxhdXNpYmxlLCBzaW5jZSB0aGUgb25s eSB3YXkgdG8gZW5jb2RlIHBhcmFtZXRlcnMgaXMgdG8gc3R1ZmYgdGhlbSBpbnRvIHRoZSBxdWVy eSBuYW1lIHNvbWVob3cuICBSYXRoZXIsIGRvaW5nIHNvbWUgb3RoZXIgVURQIHRoaW5nIG1pZ2h0 IGJlIG1vcmUgcGxhdXNpYmxlLCBvciBwZXJoYXBzIGRyb3BwaW5nIHRoZSBsaWdodHdlaWdodCB0 aGluZyBhbHRvZ2V0aGVyIGlzIHRoZSB3YXkgdG8gZ28uDQoNCi1NU0sNCg0KRnJvbTogZG9tYWlu cmVwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkb21haW5yZXAtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFN0ZXZlIEFsbGFtDQpTZW50OiBNb25kYXksIEp1bHkgMTgsIDIwMTEgNjoy MiBBTQ0KVG86IGRvbWFpbnJlcEBpZXRmLm9yZw0KU3ViamVjdDogW2RvbWFpbnJlcF0gUG9zc2li bGUgY2hhbmdlcyB0byB0aGUgc3RhbmRhcmQgKEhUVFApDQoNCkFsbCwNCg0KVGhlIG90aGVyIGlu dGVyZmFjZSB3ZSB1c2UgdG8gY29ubmVjdCB0byBvdXIgJ3JlcHV0YXRpb24gZW5naW5lJyAodGhl IExvZ2lRIHByb2R1Y3QpIHVzZXMgYW4gSFRUUCBHRVQgcXVlcnkuICBBIHR5cGljYWwgcXVlcnkg d291bGQgYmU6DQoNCmh0dHA6Ly9sb2dpcS5zZXJ2ZXIuY29tOjgwMDAvY2hlY2tfc2VuZGVyP2k9 MTkzLjQuNS4yJnM9bXVycmF5QHRoZXJlLmNvbSZyPXN0ZXZlQGhlcmUuY29tJmQ9aW5ib3VuZDxo dHRwOi8vbG9naXEuc2VydmVyLmNvbTo4MDAwL2NoZWNrX3NlbmRlcj9pPTE5My40LjUuMiZzPW11 cnJheUB0aGVyZS5jb20mcj1zdGV2ZUBoZXJlLmNvbSZzcGY9cGFzcyZka2ltPXBhc3Mmdj1zcGFt JnN1YmplY3Q9dGVzdD4NCg0KYW5kIHRoaXMgY2FuIGJlIGV4dGVuZGVkIHVzaW5nIGEgdmFyaWV0 eSBvZiBvdGhlciBwYXJhbWV0ZXJzIHN1Y2ggYXM6DQoNCmh0dHA6Ly9sb2dpcS5zZXJ2ZXIuY29t OjgwMDAvY2hlY2tfc2VuZGVyP2k9MTkzLjQuNS4yJnM9bXVycmF5QHRoZXJlLmNvbSZyPXN0ZXZl QGhlcmUuY29tJnNwZj1wYXNzJmRraW09cGFzcyZ2PXNwYW0mc3ViamVjdD10ZXN0X21lc3NhZ2Um ZD1pbmJvdW5kPGh0dHA6Ly9sb2dpcS5zZXJ2ZXIuY29tOjgwMDAvY2hlY2tfc2VuZGVyP2k9MTkz LjQuNS4yJnM9bXVycmF5QHRoZXJlLmNvbSZyPXN0ZXZlQGhlcmUuY29tJnNwZj1wYXNzJmRraW09 cGFzcyZ2PXNwYW0mc3ViamVjdD10ZXN0Pg0KDQpJZiB3ZSB0cnkgYW5kIGVuY29kZSB0aGF0IGlu IHRoZSBjdXJyZW50IHByb3Bvc2VkIHN0YW5kYXJkLCB3ZSBjYW4gZ2V0IGFzIGZhciBhcyBwZXJo YXBzOg0KDQpodHRwOi8vbG9naXEuc2VydmVyLmNvbTo4MDAwL2VtYWlsL2hlcmUuY29tL3NlbmRl ci1yZXA8aHR0cDovL2xvZ2lxLnNlcnZlci5jb206ODAwMC9lbWFpbC9oZXJlLmNvbS9zZW5kZXIt cmVwP2k9MTkzLjQuNS4yJnM9bXVycmF5QHRoZXJlLmNvbSZyPXN0ZXZlQGhlcmUuY29tJnNwZj1w YXNzJmRraW09cGFzcyZ2PXNwYW0mc3ViamVjdD10ZXN0Pg0KDQpCdXQgdGhlbiBuZWVkIHRvIGRl ZmluZSB0aGUgc2VuZGVyIGFuZCBvdGhlciBwYXJhbWV0ZXJzLiAgVGhpcyBpcyBteSBtYWluIGNv bW1lbnQgLSB0aGVyZSBuZWVkcyB0byBiZSBhIG1lY2hhbmlzbSBmb3IgcGVvcGxlIHRvIGFkZCBl eHRlbnNpYmxlIHBhcmFtZXRlcnMgdG8gdGhlIGJhc2ljIHF1ZXJ5Lg0KDQpXaGVuIHdlIGRlY2lk ZWQgb24gdGhlIHF1ZXJ5IHdlcmUgd2VyZSBnb2luZyB0byB1c2UsIHdlIHRvb2sgYSBudW1iZXIg b2YgZmFjdG9ycyBpbnRvIGNvbnNpZGVyYXRpb246DQoNCjEuICBXaGVyZSB3aWxsIHRoZSB1cmwg cGFyc2luZyB0YWtlIHBsYWNlPw0KICAgIC0gd2UgZGVjaWRlZCB0byBrZWVwIHRoZSB1cmwgZml4 ZWQgZm9yIGFsbCBxdWVyaWVzLCBhbmQgcGFzcyB0aGUgdmFyaWFibGUgZGF0YSBpbiB2aWEgcGFy YW1ldGVycy4gIE1haW5seSB0aGlzIHdhcyBkdWUgdG8gaGF2aW5nIG1hbnkgcGFyYW1ldGVycyB0 byBwYXJzZSwgYW5kIGtlZXBpbmcgdGhlIGh0dHAgZW5naW5lIGZvciB3aGF0IGl0IHdhcyBnb29k IGF0LCBwYXNzaW5nIGFsbCB0aGUgcGFyYW1ldGVycyB0byB0aGUgYXBwbGljYXRpb24gdG8gaGFu ZGxlLiAgV2UgZG8gaG93ZXZlciBkbyBzb21lIHdvcmsgaW4gdGhlIEhUVFAgc2VydmVyIChuZ2lu eCkgYmFzZWQgb24gdGhlIHBhcmFtcyAtIGZvciBpbnN0YW5jZSwgZGVwZW5kaW5nIG9uIHdoZXRo ZXIgd2UgZ2V0IGQ9aW5ib3VuZCBvciBkPW91dGJvdW5kLCB3ZSBzZXQgZGlmZmVyZW50IHJhdGUg bGltaXRpbmcgdmFsdWVzLiAgSG93ZXZlciwgdGhlIGJhc2ljIHByZW1pc2Ugd2FzIC0ga2VlcCB0 aGUgYXBwbGljYXRpb24gc2VwYXJhdGUgZnJvbSB0aGUgd2ViIHNlcnZlciAtIGFsdGhvdWdoIGNs ZWFybHkgYW4gYXBwbGljYXRpb24gaXMgcXVpdGUgY2FwYWJsZSBvZiBwYXJzaW5nIGEgVVJMIGFz IHdlbGwgYXMgYSBwYXJhbSBzdHJlYW0uDQoNCjIuIERvIHdlIHVzZSBhIEdFVCBvciBhIFBPU1Qg dG8gcHJvdmlkZSBwYXJhbXM/DQogICAgLSB3ZSBkZWNpZGVkIHRoYXQgYXMgd2Ugd2VyZW4ndCBz ZW5kaW5nIGV4dGVuZGVkIHBhcmFtZXRlciBkYXRhLCB3ZSBjb3VsZCBsaXZlIHdpdGhvdXQgdGhl IGV4dHJhIG92ZXJoZWFkIG9mIGEgUE9TVCBjb21tYW5kIC0gb25lIG9mIHRoZSBwdXJwb3NlcyBv ZiBvdXIgZW5naW5lIGlzIHRvIHdvcmsgYXMgZmFzdCBhcyBwb3NzaWJsZSBhZnRlciBhbGwuDQog ICAgLSBwYXJhbWV0ZXIgbmFtZXMgd2VyZSBhZ2FpbiBzaW1wbHkgbWFkZSBhcyBzbWFsbCBhcyBw b3NzaWJsZSB0byBlbnN1cmUgdGhlIHF1ZXJ5IGZpdHRlZCBpbnRvIGFzIGZldyBwYWNrZXRzIGFz IHBvc3NpYmxlIC0gYSBsaXR0bGUgdGhpbmcgcGVyaGFwcy4uLi4NCg0KMy4gIFJlc3BvbnNlcy4u Li4NCiAgICAtIExvZ2lRIGlzIGNhcGFibGUgb2YgcmV0dXJuaW5nIHJlc3BvbnNlcyBpbiB0aHJl ZSBmb3JtYXRzOg0KICAgICAgICAtIFhNTDogIHdlIHdhbnRlZCB0byB1c2UgdGhpcyBhcyBpdCBp cyBuaWNlbHkgZXh0ZW5zaWJsZS4gIEluIHByYWN0aWNlLCBub3QgbWFueSBvZiBvdXIgaW50ZXJm YWNlcyB1c2UgaXQ7IHBhcnRseSBiZWNhdXNlIHdoZW4gcGVvcGxlIHN0YXJ0IHVzaW5nIGl0IHRo ZXkgbG9hZCB1cCBhbiBYTUwgcGFyc2VyIGFuZCBwcm9jZXNzIHRoZSByZXN1bHQuLi4ud2hvb3Bz Li4udGhhdCdzIGdvbmUgc2xvdyBmb3Igc29tZSByZWFzb24uLi4uDQogICAgICAgIC0gVGV4dDog ICBBcyB0aGUgcmVzcG9uc2UgbGluZSBpcyB1c3VhbGx5IGEgc2luZ2xlIGxpbmUsIGl0cyBzaW1w bGUuLi4uLg0KICAgICAgICAtIEhUVFAgcmVzcG9uc2UgY29kZSAtIHRoaXMgaXMgdGhlIGZhc3Rl c3QgYW5kIHVzZWQgZGlyZWN0bHkgaW4gb3V0IGludGVyZmFjZSB3aXRoIHRoZSBDbG91ZG1hcmsg R2F0ZXdheSAtIGFzIGl0IGNhbiBzdXBwb3J0IGRpcmVjdCBIVFRQIGdldCBxdWVyaWVzIGluIGl0 cyBydWxlcyB0aGUgTG9naVEgaW50ZXJmYWNlIG5lZWRzIG5vIGV4dHJhIG1vZHVsZXMuICBJbiBv cmRlciB0byBnZXQgdGhlIHF1aWNrZXN0IGludGVncmF0aW9uLCB0aGUgZ2F0ZXdheSBtZXJlbHkg dXNlcyB0aGUgcmVzcG9uc2UgY29kZSB0byBkZXRlcm1pbmUgcmVwdXRhdGlvbiwgYW5kIGNhbiBk cmlsbCBkb3duIGludG8gdGhlIHJlc3BvbnNlIGJvZHkgaWYgbW9yZSBpbmZvcm1hdGlvbiBpcyBu ZWVkZWQuICBJIGRvbid0IGV4cGVjdCB0aGlzIHRvIGJlIGNvbnNpZGVyZWQgZm9yIGEgc3RhbmRh cmQgaG93ZXZlci4gIEkgY2FuJ3QgcmVtZW1iZXIgdGhlIGV4YWN0IHJlc3BvbnNlcyB3ZSB1c2Ug YnV0IGl0cyBzb21ldGhpbmcgbGlrZSAyMDEgZm9yIGdvb2QgcmVwdXRhdGlvbiwgNDA0IGZvciB1 bmtub3duIGFuZCA1MDMgZm9yIGEgYmFkIHJlcHV0YXRpb24uDQoNCg0KSSBrbm93IHBlcmhhcHMg SSBoYXZlIHJhbWJsZWQgYSBiaXQgaGVyZSAtIGJ1dCBJIGhvcGUgaXQgZ2l2ZXMgYW4gaWRlYSBv ZiBob3cgd2UgYXJlIHVzaW5nIHNpbWlsYXIgbWVjaGFuaXNtcyBmb3IgcmVwdXRhdGlvbiBxdWVy eS9yZXNwb25zZSAtIHBsZWFzZSBsZXQgbWUga25vdyBpZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25z Lg0KDQpSZWdhcmRzLA0KDQpTdGV2ZQ0KLS0NCg0KU3RldmUgQWxsYW0gfCBDaGllZiBUZWNobm9s b2d5IE9mZmljZXIgfCBUcnVzdFNwaGVyZQ0KDQozIFBoaWxsaXAgU3RyZWV0LCAjMTMtMDMgQ29t bWVyY2UgUG9pbnQsIFNpbmdhcG9yZSwgMDQ4NjkzDQpUZWw6ICs2NSA2NTM2IDUyMDMgfCBGYXg6 ICs2NSA2NTM2IDU0NjMNCnN0ZXZlLmFsbGFtQHRydXN0c3BoZXJlLmNvbTxtYWlsdG86c3RldmUu YWxsYW1AdHJ1c3RzcGhlcmUuY29tPiB8IHd3dy50cnVzdHNwaGVyZS5jb208aHR0cDovL3d3dy50 cnVzdHNwaGVyZS5jb20+DQo= --_000_F5833273385BB34F99288B3648C4F06F19C6C14BCFEXCHC2corpclo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgYmdjb2xvcj13aGl0ZSBsYW5nPUVO LVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGkgU3RldmUsPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5J4oCZdmUgYmVlbiB3b3JraW5nIG9uIGEgZmlyc3QgaW1wbGVtZW50YXRpb24gb2Yg dGhlIHByb3Bvc2VkIHN5c3RlbSB1c2luZyB0aGUgbG9uZy1mb3JtIChIVFRQKSBxdWVyeS9yZXBs eSBmb3JtYXQuwqAgRmluYWxseSBJIGhhdmUgc29tZXRoaW5nIHRvIHNheSBhYm91dCB5b3VyIG1l c3NhZ2UgZnJvbSBiYWNrIGluIEp1bHkuwqAgPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEJz5KPC9zcGFuPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGUgbmV3IHNwZWNpZmljYXRp b24gKC0wMiBwb3N0ZWQgYSBjb3VwbGUgb2YgZGF5cyBhZ28pIG1ha2VzIHRoZSBxdWVyeSBmb3Jt YXQgdmFyaWFibGUgYmFzZWQgb24gYSB0ZW1wbGF0ZSB0aGUgc2VydmVyIHByb3ZpZGVzLsKgIEJh c2ljYWxseSwgYSBjbGllbnQgY29uZmlndXJlZCB0byB1c2UgeW91ciBzZXJ2ZXIgd291bGQgaGl0 IGEgcmVzZXJ2ZWQsIHdlbGwta25vd24gVVJJIGF0IHlvdXIgc2VydmVyIHRvIGRvd25sb2FkIHRo ZSBVUkkgdGVtcGxhdGUgaXQgc2hvdWxkIHVzZSB0byBtYWtlIHF1ZXJpZXMgdG8geW91ciBzZXJ2 aWNlLsKgIFRoZW4gd2l0aCB2YWx1ZXMgdGhlIGNsaWVudCBjb21wdXRlcywgaXQgY29uc3RydWN0 cyB0aGUgYWN0dWFsIHF1ZXJ5IFVSSSBhbmQgbWFrZXMgdGhlIHF1ZXJ5LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+SW4geW91ciBleGFtcGxlLCB5b3UgdXNlZCBhIHZvY2FidWxhcnkgZm9yIHNlbmRlciBy ZXB1dGF0aW9uLCDigJxzZW5kZXItcmVw4oCdLsKgIFNvIGluIHRoZSBjb250ZXh0IG9mIHRoZSBS RVBVVEUgZnJhbWV3b3JrLCB5b3Ugd291bGQgY3JlYXRlIGEgdm9jYWJ1bGFyeSBmb3IgZW1haWwg c2VuZGVyIHJlcHV0YXRpb24gKHNlZSB0aGUg4oCcdm9jYWLigJ0gZHJhZnRzIGZvciBhbiBleGFt cGxlKSB0aGF0IGNyZWF0ZXMg4oCcc2VuZGVyLXJlcOKAnSBhcyBhIFJFUFVURSBhcHBsaWNhdGlv biwgYW5kIHNwZWNpZnkgd2hhdCBhc3NlcnRpb25zIGFuZCBleHRlbnNpb25zIGFyZSBkZWZpbmVk IHdpdGhpbiBpdC7CoCBUaGlzIGJhc2ljYWxseSBnaXZlcyB5b3UgdGhlIGZvcm1hdCB0aGF0IHRo ZSByZXBseSB3aWxsIHRha2UuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGUgcXVlcnnigJlzIGZvcm1h dCBpcyBzcGVjaWZpZWQgYnkgdGhlIHRlbXBsYXRlLsKgIEluIHRoZSBjdXJyZW50IEhUVFAgZHJh ZnQsIHRoZSBmb3VyIG1hbmRhdG9yeSB2YWx1ZXMgYXJlIOKAnGFwcGxpY2F0aW9u4oCdLCDigJxz Y2hlbWXigJ0sIOKAnHN1YmplY3TigJ0gYW5kIOKAnHNlcnZpY2XigJ0uwqAgSW4geW91ciBhcHBs aWNhdGlvbiwgeW914oCZZCB3YW50IHRvIGluY2x1ZGUgYWRkaXRpb25hbCBtYW5kYXRvcnkgcGFy YW1ldGVycyB0byBhY2NvbW1vZGF0ZSB3aGF0IHlvdeKAmXJlIGRvaW5nIGhlcmUuwqAgVGhpcyBt ZWFucyBJ4oCZbGwgaGF2ZSB0byBtb2RpZnkgdGhlIEhUVFAgZG9jdW1lbnQgdG8gbWVudGlvbiB0 aGF0IHZvY2FidWxhcmllcyBkZWZpbmVkIGJ5IG90aGVyIGRvY3VtZW50cyBtYXkgYWxzbyBhZGQg b3RoZXIgbWFuZGF0b3J5IHF1ZXJ5IHBhcmFtZXRlcnMuwqAgQW5kIGl0IGxvb2tzIGxpa2UgZWl0 aGVyIHRoZSDigJxtb2RlbOKAnSBvciDigJxtZWRpYSB0eXBl4oCdIGRvY3VtZW50IG5lZWRzIHRv IGNyZWF0ZSB0aGUgdm9jYWJ1bGFyeSByZWdpc3RyeSBhbmQgc3BlY2lmeSByZWdpc3RyYXRpb24g cHJvY2VkdXJlcywgaW5jbHVkaW5nIGxpc3Rpbmcgb3RoZXIgbWFuZGF0b3J5IHF1ZXJ5IHBhcmFt ZXRlcnMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5BbGwgdGhpcyB0YWxrIG9mIHF1ZXJ5IHRlbXBsYXRl cyBhbmQgc28gZm9ydGggaXMgc3RhcnRpbmcgdG8gbWFrZSBtZSB3b25kZXIgaWYgYSBsaWdodHdl aWdodCBETlMtYmFzZWQgbWVjaGFuaXNtIGlzIGV2ZW4gcGxhdXNpYmxlLCBzaW5jZSB0aGUgb25s eSB3YXkgdG8gZW5jb2RlIHBhcmFtZXRlcnMgaXMgdG8gc3R1ZmYgdGhlbSBpbnRvIHRoZSBxdWVy eSBuYW1lIHNvbWVob3cuwqAgUmF0aGVyLCBkb2luZyBzb21lIG90aGVyIFVEUCB0aGluZyBtaWdo dCBiZSBtb3JlIHBsYXVzaWJsZSwgb3IgcGVyaGFwcyBkcm9wcGluZyB0aGUgbGlnaHR3ZWlnaHQg dGhpbmcgYWx0b2dldGhlciBpcyB0aGUgd2F5IHRvIGdvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LU1T SzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO2NvbG9yOndpbmRvd3RleHQnPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6d2luZG93 dGV4dCc+IGRvbWFpbnJlcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZG9tYWlucmVwLWJvdW5j ZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+U3RldmUgQWxsYW08YnI+PGI+U2VudDo8 L2I+IE1vbmRheSwgSnVseSAxOCwgMjAxMSA2OjIyIEFNPGJyPjxiPlRvOjwvYj4gZG9tYWlucmVw QGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBbZG9tYWlucmVwXSBQb3NzaWJsZSBjaGFuZ2Vz IHRvIHRoZSBzdGFuZGFyZCAoSFRUUCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD5BbGwsPGJyPjxicj5UaGUgb3RoZXIgaW50ZXJmYWNlIHdlIHVzZSB0byBjb25uZWN0IHRvIG91 ciAncmVwdXRhdGlvbiBlbmdpbmUnICh0aGUgTG9naVEgcHJvZHVjdCkgdXNlcyBhbiBIVFRQIEdF VCBxdWVyeS4mbmJzcDsgQSB0eXBpY2FsIHF1ZXJ5IHdvdWxkIGJlOjxicj48YnI+PGEgaHJlZj0i aHR0cDovL2xvZ2lxLnNlcnZlci5jb206ODAwMC9jaGVja19zZW5kZXI/aT0xOTMuNC41LjImYW1w O3M9bXVycmF5QHRoZXJlLmNvbSZhbXA7cj1zdGV2ZUBoZXJlLmNvbSZhbXA7c3BmPXBhc3MmYW1w O2RraW09cGFzcyZhbXA7dj1zcGFtJmFtcDtzdWJqZWN0PXRlc3QiPmh0dHA6Ly9sb2dpcS5zZXJ2 ZXIuY29tOjgwMDAvY2hlY2tfc2VuZGVyP2k9MTkzLjQuNS4yJmFtcDtzPW11cnJheUB0aGVyZS5j b20mYW1wO3I9c3RldmVAaGVyZS5jb20mYW1wO2Q9aW5ib3VuZDwvYT48YnI+PGJyPmFuZCB0aGlz IGNhbiBiZSBleHRlbmRlZCB1c2luZyBhIHZhcmlldHkgb2Ygb3RoZXIgcGFyYW1ldGVycyBzdWNo IGFzOjxicj48YnI+PGEgaHJlZj0iaHR0cDovL2xvZ2lxLnNlcnZlci5jb206ODAwMC9jaGVja19z ZW5kZXI/aT0xOTMuNC41LjImYW1wO3M9bXVycmF5QHRoZXJlLmNvbSZhbXA7cj1zdGV2ZUBoZXJl LmNvbSZhbXA7c3BmPXBhc3MmYW1wO2RraW09cGFzcyZhbXA7dj1zcGFtJmFtcDtzdWJqZWN0PXRl c3QiPmh0dHA6Ly9sb2dpcS5zZXJ2ZXIuY29tOjgwMDAvY2hlY2tfc2VuZGVyP2k9MTkzLjQuNS4y JmFtcDtzPW11cnJheUB0aGVyZS5jb20mYW1wO3I9c3RldmVAaGVyZS5jb20mYW1wO3NwZj1wYXNz JmFtcDtka2ltPXBhc3MmYW1wO3Y9c3BhbSZhbXA7c3ViamVjdD10ZXN0X21lc3NhZ2UmYW1wO2Q9 aW5ib3VuZDwvYT48YnI+PGJyPklmIHdlIHRyeSBhbmQgZW5jb2RlIHRoYXQgaW4gdGhlIGN1cnJl bnQgcHJvcG9zZWQgc3RhbmRhcmQsIHdlIGNhbiBnZXQgYXMgZmFyIGFzIHBlcmhhcHM6PGJyPjxi cj48YSBocmVmPSJodHRwOi8vbG9naXEuc2VydmVyLmNvbTo4MDAwL2VtYWlsL2hlcmUuY29tL3Nl bmRlci1yZXA/aT0xOTMuNC41LjImYW1wO3M9bXVycmF5QHRoZXJlLmNvbSZhbXA7cj1zdGV2ZUBo ZXJlLmNvbSZhbXA7c3BmPXBhc3MmYW1wO2RraW09cGFzcyZhbXA7dj1zcGFtJmFtcDtzdWJqZWN0 PXRlc3QiPmh0dHA6Ly9sb2dpcS5zZXJ2ZXIuY29tOjgwMDAvZW1haWwvaGVyZS5jb20vc2VuZGVy LXJlcDwvYT48YnI+PGJyPkJ1dCB0aGVuIG5lZWQgdG8gZGVmaW5lIHRoZSBzZW5kZXIgYW5kIG90 aGVyIHBhcmFtZXRlcnMuJm5ic3A7IFRoaXMgaXMgbXkgbWFpbiBjb21tZW50IC0gdGhlcmUgbmVl ZHMgdG8gYmUgYSBtZWNoYW5pc20gZm9yIHBlb3BsZSB0byBhZGQgZXh0ZW5zaWJsZSBwYXJhbWV0 ZXJzIHRvIHRoZSBiYXNpYyBxdWVyeS48YnI+PGJyPldoZW4gd2UgZGVjaWRlZCBvbiB0aGUgcXVl cnkgd2VyZSB3ZXJlIGdvaW5nIHRvIHVzZSwgd2UgdG9vayBhIG51bWJlciBvZiBmYWN0b3JzIGlu dG8gY29uc2lkZXJhdGlvbjo8YnI+PGJyPjEuJm5ic3A7IFdoZXJlIHdpbGwgdGhlIHVybCBwYXJz aW5nIHRha2UgcGxhY2U/PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyAtIHdlIGRlY2lkZWQgdG8ga2Vl cCB0aGUgdXJsIGZpeGVkIGZvciBhbGwgcXVlcmllcywgYW5kIHBhc3MgdGhlIHZhcmlhYmxlIGRh dGEgaW4gdmlhIHBhcmFtZXRlcnMuJm5ic3A7IE1haW5seSB0aGlzIHdhcyBkdWUgdG8gaGF2aW5n IG1hbnkgcGFyYW1ldGVycyB0byBwYXJzZSwgYW5kIGtlZXBpbmcgdGhlIGh0dHAgZW5naW5lIGZv ciB3aGF0IGl0IHdhcyBnb29kIGF0LCBwYXNzaW5nIGFsbCB0aGUgcGFyYW1ldGVycyB0byB0aGUg YXBwbGljYXRpb24gdG8gaGFuZGxlLiZuYnNwOyBXZSBkbyBob3dldmVyIGRvIHNvbWUgd29yayBp biB0aGUgSFRUUCBzZXJ2ZXIgKG5naW54KSBiYXNlZCBvbiB0aGUgcGFyYW1zIC0gZm9yIGluc3Rh bmNlLCBkZXBlbmRpbmcgb24gd2hldGhlciB3ZSBnZXQgZD1pbmJvdW5kIG9yIGQ9b3V0Ym91bmQs IHdlIHNldCBkaWZmZXJlbnQgcmF0ZSBsaW1pdGluZyB2YWx1ZXMuJm5ic3A7IEhvd2V2ZXIsIHRo ZSBiYXNpYyBwcmVtaXNlIHdhcyAtIGtlZXAgdGhlIGFwcGxpY2F0aW9uIHNlcGFyYXRlIGZyb20g dGhlIHdlYiBzZXJ2ZXIgLSBhbHRob3VnaCBjbGVhcmx5IGFuIGFwcGxpY2F0aW9uIGlzIHF1aXRl IGNhcGFibGUgb2YgcGFyc2luZyBhIFVSTCBhcyB3ZWxsIGFzIGEgcGFyYW0gc3RyZWFtLjxicj48 YnI+Mi4gRG8gd2UgdXNlIGEgR0VUIG9yIGEgUE9TVCB0byBwcm92aWRlIHBhcmFtcz88YnI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0gd2UgZGVjaWRlZCB0aGF0IGFzIHdlIHdlcmVuJ3Qgc2VuZGluZyBl eHRlbmRlZCBwYXJhbWV0ZXIgZGF0YSwgd2UgY291bGQgbGl2ZSB3aXRob3V0IHRoZSBleHRyYSBv dmVyaGVhZCBvZiBhIFBPU1QgY29tbWFuZCAtIG9uZSBvZiB0aGUgcHVycG9zZXMgb2Ygb3VyIGVu Z2luZSBpcyB0byB3b3JrIGFzIGZhc3QgYXMgcG9zc2libGUgYWZ0ZXIgYWxsLjxicj4mbmJzcDsm bmJzcDsmbmJzcDsgLSBwYXJhbWV0ZXIgbmFtZXMgd2VyZSBhZ2FpbiBzaW1wbHkgbWFkZSBhcyBz bWFsbCBhcyBwb3NzaWJsZSB0byBlbnN1cmUgdGhlIHF1ZXJ5IGZpdHRlZCBpbnRvIGFzIGZldyBw YWNrZXRzIGFzIHBvc3NpYmxlIC0gYSBsaXR0bGUgdGhpbmcgcGVyaGFwcy4uLi48YnI+PGJyPjMu Jm5ic3A7IFJlc3BvbnNlcy4uLi48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gTG9naVEgaXMgY2Fw YWJsZSBvZiByZXR1cm5pbmcgcmVzcG9uc2VzIGluIHRocmVlIGZvcm1hdHM6PGJyPiZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgLSBYTUw6Jm5ic3A7IHdlIHdhbnRlZCB0byB1 c2UgdGhpcyBhcyBpdCBpcyBuaWNlbHkgZXh0ZW5zaWJsZS4mbmJzcDsgSW4gcHJhY3RpY2UsIG5v dCBtYW55IG9mIG91ciBpbnRlcmZhY2VzIHVzZSBpdDsgcGFydGx5IGJlY2F1c2Ugd2hlbiBwZW9w bGUgc3RhcnQgdXNpbmcgaXQgdGhleSBsb2FkIHVwIGFuIFhNTCBwYXJzZXIgYW5kIHByb2Nlc3Mg dGhlIHJlc3VsdC4uLi53aG9vcHMuLi50aGF0J3MgZ29uZSBzbG93IGZvciBzb21lIHJlYXNvbi4u Li48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAtIFRleHQ6Jm5ic3A7 Jm5ic3A7IEFzIHRoZSByZXNwb25zZSBsaW5lIGlzIHVzdWFsbHkgYSBzaW5nbGUgbGluZSwgaXRz IHNpbXBsZS4uLi4uPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgLSBI VFRQIHJlc3BvbnNlIGNvZGUgLSB0aGlzIGlzIHRoZSBmYXN0ZXN0IGFuZCB1c2VkIGRpcmVjdGx5 IGluIG91dCBpbnRlcmZhY2Ugd2l0aCB0aGUgQ2xvdWRtYXJrIEdhdGV3YXkgLSBhcyBpdCBjYW4g c3VwcG9ydCBkaXJlY3QgSFRUUCBnZXQgcXVlcmllcyBpbiBpdHMgcnVsZXMgdGhlIExvZ2lRIGlu dGVyZmFjZSBuZWVkcyBubyBleHRyYSBtb2R1bGVzLiZuYnNwOyBJbiBvcmRlciB0byBnZXQgdGhl IHF1aWNrZXN0IGludGVncmF0aW9uLCB0aGUgZ2F0ZXdheSBtZXJlbHkgdXNlcyB0aGUgcmVzcG9u c2UgY29kZSB0byBkZXRlcm1pbmUgcmVwdXRhdGlvbiwgYW5kIGNhbiBkcmlsbCBkb3duIGludG8g dGhlIHJlc3BvbnNlIGJvZHkgaWYgbW9yZSBpbmZvcm1hdGlvbiBpcyBuZWVkZWQuJm5ic3A7IEkg ZG9uJ3QgZXhwZWN0IHRoaXMgdG8gYmUgY29uc2lkZXJlZCBmb3IgYSBzdGFuZGFyZCBob3dldmVy LiZuYnNwOyBJIGNhbid0IHJlbWVtYmVyIHRoZSBleGFjdCByZXNwb25zZXMgd2UgdXNlIGJ1dCBp dHMgc29tZXRoaW5nIGxpa2UgMjAxIGZvciBnb29kIHJlcHV0YXRpb24sIDQwNCBmb3IgdW5rbm93 biBhbmQgNTAzIGZvciBhIGJhZCByZXB1dGF0aW9uLjxicj48YnI+PGJyPkkga25vdyBwZXJoYXBz IEkgaGF2ZSByYW1ibGVkIGEgYml0IGhlcmUgLSBidXQgSSBob3BlIGl0IGdpdmVzIGFuIGlkZWEg b2YgaG93IHdlIGFyZSB1c2luZyBzaW1pbGFyIG1lY2hhbmlzbXMgZm9yIHJlcHV0YXRpb24gcXVl cnkvcmVzcG9uc2UgLSBwbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91IGhhdmUgYW55IHF1ZXN0aW9u cy48YnI+PGJyPlJlZ2FyZHMsPGJyPjxicj5TdGV2ZTxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPi0tIDxicj48Yj48YnI+PC9iPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5TdGV2ZSBBbGxhbSB8IDwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiInPkNoaWVmIFRlY2hub2xvZ3kgT2ZmaWNlciA8Yj58IFRydXN0U3BoZXJl IDwvYj48L3NwYW4+PGJyPjxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+MyBQaGlsbGlwIFN0cmVldCwgIzEzLTAzIENvbW1l cmNlIFBvaW50LCZuYnNwO1NpbmdhcG9yZSwgMDQ4NjkzPGJyPlRlbDogKzY1IDY1MzYgNTIwMyB8 IEZheDogKzY1IDY1MzYgNTQ2Mzxicj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNThBMSc+PGEgaHJl Zj0ibWFpbHRvOnN0ZXZlLmFsbGFtQHRydXN0c3BoZXJlLmNvbSI+c3RldmUuYWxsYW1AdHJ1c3Rz cGhlcmUuY29tPC9hPiB8IDxhIGhyZWY9Imh0dHA6Ly93d3cudHJ1c3RzcGhlcmUuY29tIj53d3cu dHJ1c3RzcGhlcmUuY29tPC9hPiA8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9k aXY+PC9ib2R5PjwvaHRtbD4= --_000_F5833273385BB34F99288B3648C4F06F19C6C14BCFEXCHC2corpclo_-- From clewis+ietf@mustelids.ca Fri Oct 21 15:59:19 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 AE92F21F888A for ; Fri, 21 Oct 2011 15:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.441 X-Spam-Level: X-Spam-Status: No, score=0.441 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 oKq7wtr80rl7 for ; Fri, 21 Oct 2011 15:59:19 -0700 (PDT) Received: from mail.mustelids.ca (unknown [174.35.130.2]) by ietfa.amsl.com (Postfix) with ESMTP id E38D521F87FC for ; Fri, 21 Oct 2011 15:59:18 -0700 (PDT) Received: from [10.115.135.178] (62-50-218-55.client.stsn.net [62.50.218.55]) (authenticated bits=0) by mail.mustelids.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p9LMrqSH026570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 21 Oct 2011 18:54:00 -0400 Message-ID: <4EA1F932.3000902@mustelids.ca> Date: Sat, 22 Oct 2011 00:58:58 +0200 From: Chris Lewis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: domainrep@ietf.org References: <4E24335A.9000203@trustsphere.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Possible changes to the standard (HTTP) 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, 21 Oct 2011 22:59:19 -0000 On 11-10-22 12:16 AM, Murray S. Kucherawy wrote: > All this talk of query templates and so forth is starting to make me > wonder if a lightweight DNS-based mechanism is even plausible, since the > only way to encode parameters is to stuff them into the query name > somehow. Rather, doing some other UDP thing might be more plausible, or > perhaps dropping the lightweight thing altogether is the way to go. Some DNSBLs already do encode parameters into the query name - the multi-subzone types. Eg: the various SURBLs, spamhaus' offerings etc. If there's not many, and the lengths are kept in bounds, it should still be doable. An alternate approach is to have the template for the lightweight mechanism specify the interpretation of the result, rather than the formation of the query. Which is to a great extent simply providing a machine description of the return values that existing systems do as a web page intended for humans to read. From msk@cloudmark.com Fri Oct 21 17:05: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 22B8611E808C for ; Fri, 21 Oct 2011 17:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 GbPewNR0ygII for ; Fri, 21 Oct 2011 17:05:27 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id B148D11E8082 for ; Fri, 21 Oct 2011 17:05:27 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 21 Oct 2011 17:05:27 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Fri, 21 Oct 2011 17:05:26 -0700 Thread-Topic: [domainrep] Possible changes to the standard (HTTP) Thread-Index: AcyQRRISCLDNtSUqQYaYwnfO3JcAdgACLZKQ Message-ID: References: <4E24335A.9000203@trustsphere.com> <4EA1F932.3000902@mustelids.ca> In-Reply-To: <4EA1F932.3000902@mustelids.ca> 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] Possible changes to the standard (HTTP) 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: Sat, 22 Oct 2011 00:05:28 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Chris Lewis > Sent: Friday, October 21, 2011 3:59 PM > To: domainrep@ietf.org > Subject: Re: [domainrep] Possible changes to the standard (HTTP) >=20 > Some DNSBLs already do encode parameters into the query name - the > multi-subzone types. Eg: the various SURBLs, spamhaus' offerings etc. > If there's not many, and the lengths are kept in bounds, it should still > be doable. In the implementation I imagine, effectively there's a template to construc= ting the query, like there is with URIs but shorter. The more elements the= re are in the generated name, though, the more constrained the space is; if= you have to spend 40 characters encoding query parameters and another ten = for the name of the service, one could prevent queries from ever happening = by registering a domain name that's 207 bytes long. That's an extreme exam= ple, but if we try to pack a lot of query parameters in, it becomes more pl= ausible that one could hide. > An alternate approach is to have the template for the lightweight > mechanism specify the interpretation of the result, rather than the > formation of the query. Which is to a great extent simply providing a > machine description of the return values that existing systems do as a > web page intended for humans to read. I think that's more plausible in the long run, except that it may not be to= o lightweight anymore since the reply might have to encode quite a bit of i= nformation rather than just a "score" and "confidence", which was the origi= nal target, and the specification gets more and more complex (and thus pron= e to errors). I don't really know right now which is ultimately better as I haven't reall= y taken a run at it. Just cogitating so far. From msk@cloudmark.com Sun Oct 23 13:39: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 DF00421F8B33 for ; Sun, 23 Oct 2011 13:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.687 X-Spam-Level: X-Spam-Status: No, score=-102.687 tagged_above=-999 required=5 tests=[AWL=-0.089, 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 IodjpC-LG1FP for ; Sun, 23 Oct 2011 13:39:52 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 11D6E21F8B3B for ; Sun, 23 Oct 2011 13:39:52 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sun, 23 Oct 2011 13:39:51 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Sun, 23 Oct 2011 13:39:51 -0700 Thread-Topic: A document about reputation data meta-issues Thread-Index: AcyRquMWQhpg9s3uTAqFFQHM4YK9WA== Message-ID: 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_F5833273385BB34F99288B3648C4F06F19C6C14BF5EXCHC2corpclo_" MIME-Version: 1.0 Subject: [domainrep] A document about reputation data meta-issues 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: Sun, 23 Oct 2011 20:39:53 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C14BF5EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We included in our charter the need to produce an "informational document, = discussing issues of data transparency, redress, meta-reputation and other = important operational considerations." This comes from some fairly passion= ate discussion at the BoF in Quebec City. Does anyone have some thoughts about this that might be a good starting poi= nt for constructing that draft? -MSK --_000_F5833273385BB34F99288B3648C4F06F19C6C14BF5EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We included i= n our charter the need to produce an “informational document, discuss= ing issues of data transparency, redress, meta-reputation and other importa= nt operational considerations.”  This comes from some fairly pas= sionate discussion at the BoF in Quebec City.

 

Does anyone have some= thoughts about this that might be a good starting point for constructing t= hat draft?

 

-MSK

 

= --_000_F5833273385BB34F99288B3648C4F06F19C6C14BF5EXCHC2corpclo_-- From msk@cloudmark.com Sun Oct 23 13:40:02 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 6309521F8B43 for ; Sun, 23 Oct 2011 13:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.685 X-Spam-Level: X-Spam-Status: No, score=-102.685 tagged_above=-999 required=5 tests=[AWL=-0.086, 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 nqyM3xck6rJP for ; Sun, 23 Oct 2011 13:40:01 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id C371B21F8B2B for ; Sun, 23 Oct 2011 13:40:01 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sun, 23 Oct 2011 13:40:01 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Sun, 23 Oct 2011 13:40:00 -0700 Thread-Topic: [domainrep] Discussion items for Repute session at Taipei Thread-Index: AcyJ+tYgyC1Xo8/BTCygZ5pj3S5oHgDACgngASwdgJA= Message-ID: References: <4E939792.6040102@dcrocker.net> <4E976BB1.4040300@dcrocker.net> In-Reply-To: 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] Discussion items for Repute session at Taipei 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: Sun, 23 Oct 2011 20:40:02 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Murray S. Kucherawy > Sent: Monday, October 17, 2011 11:42 AM > To: domainrep@ietf.org > Subject: Re: [domainrep] Discussion items for Repute session at Taipei >=20 > Mark states that current practice on the web side of things is to > support templates like this, so any given reputation service can > announce how it wants clients to format queries rather than having a > fixed URI format specified in an RFC to which both sides must conform. > What's missing (deliberately) from that draft is the mechanism by which > a particular service's URI template is discovered, so our HTTP document > would need to come up with something. Off the top of my head, the best > ideas are a DNS TXT query to a fixed name (e.g., for a reputation > service based at "repute.example.com", do a TXT query to > "_qt.repute.example.com" to ask for a template, falling back to > something in the draft if none is found), or to do an HTTP query to a > fixed URI relative to the reputation service looking for the template > (again with a fallback to something documented). Mark further advises that the conventional solution to template discovery i= s a well-known URI, registered with IANA. Version -02 of the "query-http" = draft thus introduces this concept. It also means if the template can't be= downloaded, the query has to be aborted (i.e., applications typically don'= t define hard-coded default templates). I've updated my implementation accordingly. Seems to work nicely. -MSK From sm@resistor.net Sun Oct 23 13:56:13 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 F14A021F86FF for ; Sun, 23 Oct 2011 13:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 296uy-rud6Ip for ; Sun, 23 Oct 2011 13:56:12 -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 C76C421F852E for ; Sun, 23 Oct 2011 13:56:12 -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 p9NKtxQK016876; Sun, 23 Oct 2011 13:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1319403365; bh=M6eEZvFmAKVeGEb8TOQ44sJIsLWOMAIf1wyvbtxWzf4=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=F34VBuS7qCduOP6QoQ/fgAcheAXV8TVCoL/xXHR8v6XUvLbOrLeX7jqAcV8H7eZTt 1hT8pKDPSHnZK37nustjIzptMjKU0NWXSGhBaeFV2tmkXGKoL2lnCoj7l2XSSwV8C9 o/a3NSoULf4IHBiBd2QBGBOzi92XbOe/ywzbKk8k= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1319403365; bh=M6eEZvFmAKVeGEb8TOQ44sJIsLWOMAIf1wyvbtxWzf4=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=IpM8hSO7lsH9FXBnyLF+bGspkyB/itnjMK35+aHb8ZeebHeFePHMvOJYZxp8bGjxK 90C8o8oaeBmgw4+92RJ+c3IYbLPrDJx7GaNDA7+ZLq5HLlINwjtQIqbJJ31Tz6zfb9 bxAL8hva5O7VVnINMaD18ef+9TToXoq9HpcXu3R8= Message-Id: <6.2.5.6.2.20111023134720.0b64ddc8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 23 Oct 2011 13:55:02 -0700 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: domainrep@ietf.org Subject: Re: [domainrep] A document about reputation data meta-issues 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: Sun, 23 Oct 2011 20:56:14 -0000 Hi Murray, At 13:39 23-10-2011, Murray S. Kucherawy wrote: >We included in our charter the need to produce an "informational >document, discussing issues of data transparency, redress, >meta-reputation and other important operational >considerations." This comes from some fairly passionate discussion >at the BoF in Quebec City. The data transparency and redress discussion is going to be highly controversial. Does this have to be done before the technical work? Regards, -sm From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Tue Oct 25 03:17: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 A8D5321F8B10 for ; Tue, 25 Oct 2011 03:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.804 X-Spam-Level: X-Spam-Status: No, score=-102.804 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 G54UXnS2ryLC for ; Tue, 25 Oct 2011 03:17:08 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0268321F8B09 for ; Tue, 25 Oct 2011 03:17:04 -0700 (PDT) Received: by wyh22 with SMTP id 22so396634wyh.31 for ; Tue, 25 Oct 2011 03:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xdhB290Fle0iuCjBMVz8s1Jx9/RynSZzlQO0h+4BEic=; b=he6GGq75LgmCqMq3kK8tvaGoh5CR1K6AcOEYgyIRnna81wnQQyR6tziAcVEcuI8CPw sEd5pb9BcsyGYW8pQQkCwR0M0e52Q8/aTDMuuDL2pNkiN3GazwhEWl5nD65zrjDBhGiy 5V1OGQ3lTsmZShN3Idea4CffMFZaSs+CgqrSs= Received: by 10.227.208.77 with SMTP id gb13mr2978001wbb.4.1319537824202; Tue, 25 Oct 2011 03:17:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.80.134 with HTTP; Tue, 25 Oct 2011 03:16:23 -0700 (PDT) In-Reply-To: References: From: Frank Ellermann Date: Tue, 25 Oct 2011 12:16:23 +0200 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] A document about reputation data meta-issues 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, 25 Oct 2011 10:17:08 -0000 On 23 October 2011 22:39, Murray S. Kucherawy wrote: > Does anyone have some thoughts about this that > might be a good starting point for constructing > that draft? I'd be interested to learn why SIQ / DNSBL / VBR are not good enough for whatever will be created here. As neutral as possible, I'm not ready to get into any flame wars before I know some facts. -Frank From msk@cloudmark.com Tue Oct 25 04:26:14 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 E1F8C21F84D1 for ; Tue, 25 Oct 2011 04:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.218 X-Spam-Level: X-Spam-Status: No, score=-103.218 tagged_above=-999 required=5 tests=[AWL=0.381, 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 DnuhZFuVStNf for ; Tue, 25 Oct 2011 04:26:14 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9A221F84D8 for ; Tue, 25 Oct 2011 04:26:14 -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, 25 Oct 2011 04:26:03 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 25 Oct 2011 04:26:03 -0700 Thread-Topic: [domainrep] A document about reputation data meta-issues Thread-Index: AcyS/0HTxyRFF6TRTTWEnv7H6TxXzwACW0Bg Message-ID: References: In-Reply-To: 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] A document about reputation data meta-issues 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, 25 Oct 2011 11:26:15 -0000 > -----Original Message----- > From: Frank Ellermann [mailto:hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com] > Sent: Tuesday, October 25, 2011 3:16 AM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] A document about reputation data meta-issues Hi Frank, > > Does anyone have some thoughts about this that > > might be a good starting point for constructing > > that draft? >=20 > I'd be interested to learn why SIQ / DNSBL / VBR > are not good enough for whatever will be created > here. As neutral as possible, I'm not ready to > get into any flame wars before I know some facts. Have you read the drafts that are out already? I think they answer that qu= estion quite readily, but I'm happy to improve them if there's information = missing. And the question posed had nothing to do with specific protocols, but rathe= r they referred to issues that were brought up during the BoF about managem= ent of reputation services, use of them, and the potential impacts thereof.= The issues are protocol agnostic. From prvs=0279529e8c=steve.allam@trustsphere.com Tue Oct 25 07:21: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 5609C21F84FC for ; Tue, 25 Oct 2011 07:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.663 X-Spam-Level: X-Spam-Status: No, score=0.663 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, WEIRD_PORT=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 lX9U8jl6YARw for ; Tue, 25 Oct 2011 07:21:13 -0700 (PDT) Received: from st3.realmail-asp.co.uk (fe1.securerealmail.com [80.249.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id 386AD21F84CE for ; Tue, 25 Oct 2011 07:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=trustsphere.com; s=rmdkim; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=BnyJqNIFh79R+iGihqL7HX2uqQU4e03n5GarVI+R3sI=; b=Ox/qDiSc8m3czKJlBHb0OVZCJcQkGOTpbjnQ2o+cSOVCJ/+HhxxezVWl0EhqslfY8VU+vaj1munPpjOtJftDwY+8Q4l73R3pmBIAUzdtFqbqZlsTkLQ1HGLprWGKQ6M+4RJ/JXhpzVsBDqMPzBsZMEL/nV2yWK1ELdrDmfNrehI=; Received: from [116.12.149.130] (helo=cgpro.boxsentry.com) by st3.realmail-asp.co.uk with esmtp id 1RIhsK-0001Fo-V6 for domainrep@ietf.org; Tue, 25 Oct 2011 15:21:09 +0100 Received: by cgpro.boxsentry.com (CommuniGate Pro PIPE 5.4.0) with PIPE id 1703338; Tue, 25 Oct 2011 22:18:27 +0800 Received: from [88.97.130.81] (account steve.allam@trustsphere.com HELO [10.1.1.34]) by cgpro.boxsentry.com (CommuniGate Pro SMTP 5.4.0) with ESMTPSA id 1703339 for domainrep@ietf.org; Tue, 25 Oct 2011 22:18:20 +0800 Message-ID: <4EA6C529.5080303@trustsphere.com> Date: Tue, 25 Oct 2011 15:18:17 +0100 From: Steve Allam User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: domainrep@ietf.org References: <4E24335A.9000203@trustsphere.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010202030609010405010200" X-RMR-rmalert: true X-LogiQ-query: 116.12.149.130/steve.allam@trustsphere.com/domainrep@ietf.org (error socket failure) X-RealMail-Category: UNKNOWN/UNKNOWN X-RealMail-Ref: UNKNOWN/str=0001.0A0B0208.4EA6C5D5.01E7,ss=1,re=0.000,fgs=0 X-RealMail-IWF: NO X-CTCH-SenderID: steve.allam@trustsphere.com X-CTCH-SenderID-Flags: 0 X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-Total-Spam: 0 X-CTCH-SenderID-Total-Suspected: 0 Subject: Re: [domainrep] Possible changes to the standard (HTTP) 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, 25 Oct 2011 14:21:17 -0000 This is a multi-part message in MIME format. --------------010202030609010405010200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Murray, That approach sounds plausible - having to look up a template in order to get instructions on how to build a valid URI wouldn't have to happen very often - perhaps the template should also have a TTL value in it so that clients know how long the template is expected to be valid for - for our system, I would expect a template to be modified on software version changes only, but I guess other systems might wish to use a changing template (can't think why). I shall have a look at the drafts (before July!) and comment further. Regarding the lightweight DNS/UDP mechanisms, - the same system I think would work - it seems to me that it might still be worth pursuing, on the basis that the client can still look up the template to be used for the DNS mechanism, so that a proper query can be formed - again, the template lookup need only happen infrequently, so it wouldn't over burden the client application. - Also, it could perhaps share the same template lookup mechanism as the long-form query, to save inventing a DNS-based template lookup mechanism, but I guess you had that bit already. - We will continue to use our own DNS based reputation lookup, and there is a possibility we might be extending it soon - I'll let you know how that goes! I hope you are all enjoying Paris - ironic that this is the first Maawg I've missed in 4 years I think, and its the closest to me (London) ! Regards, Steve On 21/10/2011 11:16 PM, Murray S. Kucherawy wrote: > > Hi Steve, > > I've been working on a first implementation of the proposed system > using the long-form (HTTP) query/reply format. Finally I have > something to say about your message from back in July. J > > The new specification (-02 posted a couple of days ago) makes the > query format variable based on a template the server provides. > Basically, a client configured to use your server would hit a > reserved, well-known URI at your server to download the URI template > it should use to make queries to your service. Then with values the > client computes, it constructs the actual query URI and makes the query. > > In your example, you used a vocabulary for sender reputation, > "sender-rep". So in the context of the REPUTE framework, you would > create a vocabulary for email sender reputation (see the "vocab" > drafts for an example) that creates "sender-rep" as a REPUTE > application, and specify what assertions and extensions are defined > within it. This basically gives you the format that the reply will take. > > The query's format is specified by the template. In the current HTTP > draft, the four mandatory values are "application", "scheme", > "subject" and "service". In your application, you'd want to include > additional mandatory parameters to accommodate what you're doing > here. This means I'll have to modify the HTTP document to mention > that vocabularies defined by other documents may also add other > mandatory query parameters. And it looks like either the "model" or > "media type" document needs to create the vocabulary registry and > specify registration procedures, including listing other mandatory > query parameters. > > All this talk of query templates and so forth is starting to make me > wonder if a lightweight DNS-based mechanism is even plausible, since > the only way to encode parameters is to stuff them into the query name > somehow. Rather, doing some other UDP thing might be more plausible, > or perhaps dropping the lightweight thing altogether is the way to go. > > -MSK > > *From:*domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] > *On Behalf Of *Steve Allam > *Sent:* Monday, July 18, 2011 6:22 AM > *To:* domainrep@ietf.org > *Subject:* [domainrep] Possible changes to the standard (HTTP) > > All, > > The other interface we use to connect to our 'reputation engine' (the > LogiQ product) uses an HTTP GET query. A typical query would be: > > http://logiq.server.com:8000/check_sender?i=193.4.5.2&s=murray@there.com&r=steve@here.com&d=inbound > > > and this can be extended using a variety of other parameters such as: > > http://logiq.server.com:8000/check_sender?i=193.4.5.2&s=murray@there.com&r=steve@here.com&spf=pass&dkim=pass&v=spam&subject=test_message&d=inbound > > > If we try and encode that in the current proposed standard, we can get > as far as perhaps: > > http://logiq.server.com:8000/email/here.com/sender-rep > > > But then need to define the sender and other parameters. This is my > main comment - there needs to be a mechanism for people to add > extensible parameters to the basic query. > > When we decided on the query were were going to use, we took a number > of factors into consideration: > > 1. Where will the url parsing take place? > - we decided to keep the url fixed for all queries, and pass the > variable data in via parameters. Mainly this was due to having many > parameters to parse, and keeping the http engine for what it was good > at, passing all the parameters to the application to handle. We do > however do some work in the HTTP server (nginx) based on the params - > for instance, depending on whether we get d=inbound or d=outbound, we > set different rate limiting values. However, the basic premise was - > keep the application separate from the web server - although clearly > an application is quite capable of parsing a URL as well as a param > stream. > > 2. Do we use a GET or a POST to provide params? > - we decided that as we weren't sending extended parameter data, > we could live without the extra overhead of a POST command - one of > the purposes of our engine is to work as fast as possible after all. > - parameter names were again simply made as small as possible to > ensure the query fitted into as few packets as possible - a little > thing perhaps.... > > 3. Responses.... > - LogiQ is capable of returning responses in three formats: > - XML: we wanted to use this as it is nicely extensible. In > practice, not many of our interfaces use it; partly because when > people start using it they load up an XML parser and process the > result....whoops...that's gone slow for some reason.... > - Text: As the response line is usually a single line, its > simple..... > - HTTP response code - this is the fastest and used directly > in out interface with the Cloudmark Gateway - as it can support direct > HTTP get queries in its rules the LogiQ interface needs no extra > modules. In order to get the quickest integration, the gateway merely > uses the response code to determine reputation, and can drill down > into the response body if more information is needed. I don't expect > this to be considered for a standard however. I can't remember the > exact responses we use but its something like 201 for good reputation, > 404 for unknown and 503 for a bad reputation. > > > I know perhaps I have rambled a bit here - but I hope it gives an idea > of how we are using similar mechanisms for reputation query/response - > please let me know if you have any questions. > > Regards, > > Steve > > -- > * > **Steve Allam | *Chief Technology Officer *| TrustSphere * > > 3 Phillip Street, #13-03 Commerce Point, Singapore, 048693 > Tel: +65 6536 5203 | Fax: +65 6536 5463 > steve.allam@trustsphere.com | > www.trustsphere.com > > > > _______________________________________________ > domainrep mailing list > domainrep@ietf.org > https://www.ietf.org/mailman/listinfo/domainrep -- * Steve Allam | * Chief Technology Officer *| TrustSphere * 3 Phillip Street, #13-03 Commerce Point, Singapore, 048693 Tel: +65 6536 5203 | Fax: +65 6536 5463 steve.allam@trustsphere.com | www.trustsphere.com --------------010202030609010405010200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Murray,

That approach sounds plausible - having to look up a template in order to get instructions on how to build a valid URI wouldn't have to happen very often - perhaps the template should also have a TTL value in it so that clients know how long the template is expected to be valid for - for our system, I would expect a template to be modified on software version changes only, but I guess other systems might wish to use a changing template (can't think why).

I shall have a look at the drafts (before July!) and comment further.

Regarding the lightweight DNS/UDP mechanisms, - the same system I think would work - it seems to me that it might still be worth pursuing, on the basis that the client can still look up the template to be used for the DNS mechanism, so that a proper query can be formed - again, the template lookup need only happen infrequently, so it wouldn't over burden the client application.
    - Also, it could perhaps share the same template lookup mechanism as the long-form query, to save inventing a DNS-based template lookup mechanism, but I guess you had that bit already.
    - We will continue to use our own DNS based reputation lookup, and there is a possibility we might be extending it soon - I'll let you know how that goes!

I hope you are all enjoying Paris - ironic that this is the first Maawg I've missed in 4 years I think, and its the closest to me (London) !

Regards,

Steve

On 21/10/2011 11:16 PM, Murray S. Kucherawy wrote:

Hi Steve,

 

I’ve been working on a first implementation of the proposed system using the long-form (HTTP) query/reply format.  Finally I have something to say about your message from back in July.  J

 

The new specification (-02 posted a couple of days ago) makes the query format variable based on a template the server provides.  Basically, a client configured to use your server would hit a reserved, well-known URI at your server to download the URI template it should use to make queries to your service.  Then with values the client computes, it constructs the actual query URI and makes the query.

 

In your example, you used a vocabulary for sender reputation, “sender-rep”.  So in the context of the REPUTE framework, you would create a vocabulary for email sender reputation (see the “vocab” drafts for an example) that creates “sender-rep” as a REPUTE application, and specify what assertions and extensions are defined within it.  This basically gives you the format that the reply will take.

 

The query’s format is specified by the template.  In the current HTTP draft, the four mandatory values are “application”, “scheme”, “subject” and “service”.  In your application, you’d want to include additional mandatory parameters to accommodate what you’re doing here.  This means I’ll have to modify the HTTP document to mention that vocabularies defined by other documents may also add other mandatory query parameters.  And it looks like either the “model” or “media type” document needs to create the vocabulary registry and specify registration procedures, including listing other mandatory query parameters.

 

All this talk of query templates and so forth is starting to make me wonder if a lightweight DNS-based mechanism is even plausible, since the only way to encode parameters is to stuff them into the query name somehow.  Rather, doing some other UDP thing might be more plausible, or perhaps dropping the lightweight thing altogether is the way to go.

 

-MSK

 

From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On Behalf Of Steve Allam
Sent: Monday, July 18, 2011 6:22 AM
To: domainrep@ietf.org
Subject: [domainrep] Possible changes to the standard (HTTP)

 

All,

The other interface we use to connect to our 'reputation engine' (the LogiQ product) uses an HTTP GET query.  A typical query would be:

http://logiq.server.com:8000/check_sender?i=193.4.5.2&s=murray@there.com&r=steve@here.com&d=inbound

and this can be extended using a variety of other parameters such as:

http://logiq.server.com:8000/check_sender?i=193.4.5.2&s=murray@there.com&r=steve@here.com&spf=pass&dkim=pass&v=spam&subject=test_message&d=inbound

If we try and encode that in the current proposed standard, we can get as far as perhaps:

http://logiq.server.com:8000/email/here.com/sender-rep

But then need to define the sender and other parameters.  This is my main comment - there needs to be a mechanism for people to add extensible parameters to the basic query.

When we decided on the query were were going to use, we took a number of factors into consideration:

1.  Where will the url parsing take place?
    - we decided to keep the url fixed for all queries, and pass the variable data in via parameters.  Mainly this was due to having many parameters to parse, and keeping the http engine for what it was good at, passing all the parameters to the application to handle.  We do however do some work in the HTTP server (nginx) based on the params - for instance, depending on whether we get d=inbound or d=outbound, we set different rate limiting values.  However, the basic premise was - keep the application separate from the web server - although clearly an application is quite capable of parsing a URL as well as a param stream.

2. Do we use a GET or a POST to provide params?
    - we decided that as we weren't sending extended parameter data, we could live without the extra overhead of a POST command - one of the purposes of our engine is to work as fast as possible after all.
    - parameter names were again simply made as small as possible to ensure the query fitted into as few packets as possible - a little thing perhaps....

3.  Responses....
    - LogiQ is capable of returning responses in three formats:
        - XML:  we wanted to use this as it is nicely extensible.  In practice, not many of our interfaces use it; partly because when people start using it they load up an XML parser and process the result....whoops...that's gone slow for some reason....
        - Text:   As the response line is usually a single line, its simple.....
        - HTTP response code - this is the fastest and used directly in out interface with the Cloudmark Gateway - as it can support direct HTTP get queries in its rules the LogiQ interface needs no extra modules.  In order to get the quickest integration, the gateway merely uses the response code to determine reputation, and can drill down into the response body if more information is needed.  I don't expect this to be considered for a standard however.  I can't remember the exact responses we use but its something like 201 for good reputation, 404 for unknown and 503 for a bad reputation.


I know perhaps I have rambled a bit here - but I hope it gives an idea of how we are using similar mechanisms for reputation query/response - please let me know if you have any questions.

Regards,

Steve

--

Steve Allam | Chief Technology Officer | TrustSphere

3 Phillip Street, #13-03 Commerce Point, Singapore, 048693
Tel: +65 6536 5203 | Fax: +65 6536 5463
steve.allam@trustsphere.com | www.trustsphere.com 



_______________________________________________
domainrep mailing list
domainrep@ietf.org
https://www.ietf.org/mailman/listinfo/domainrep

--

Steve Allam | Chief Technology Officer | TrustSphere

3 Phillip Street, #13-03 Commerce Point, Singapore, 048693
Tel: +65 6536 5203 | Fax: +65 6536 5463
 steve.allam@trustsphere.com | www.trustsphere.com
--------------010202030609010405010200-- From dfs@roaringpenguin.com Tue Oct 25 09:04:55 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 2F99021F8C8D for ; Tue, 25 Oct 2011 09:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 xJd+27LZWMQi for ; Tue, 25 Oct 2011 09:04:54 -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 675D821F8C8C for ; Tue, 25 Oct 2011 09:04:53 -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 p9PG4oLQ011168 for ; Tue, 25 Oct 2011 12:04:51 -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 p9PG4lP2016336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 25 Oct 2011 12:04:50 -0400 Date: Tue, 25 Oct 2011 12:04:47 -0400 From: "David F. Skoll" To: "domainrep@ietf.org" Message-ID: <20111025120447.5155ba24@hydrogen.roaringpenguin.com> 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:mime-version:content-type :content-transfer-encoding; s=beta; bh=dfeS7DShrGbemxuGP1qdYkB9M I0=; b=TWrSdQlNJRxYK6OnhXfKJarMomsJ7CeBcyNpAk8j8p/lvP/6N1zbF0i57 Cw7e7hDtX9ShjnefAoySUQUYs6ClTBPQyjaHctscIAvE7YGTLFslQYgZTIWBMte3 N1wwmQApArHxTwkw+hu/K/v5hyiYzfFb05484vAPD6h55ekOt4= 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/20111025 / 01FN44Op6 Subject: [domainrep] Comments on drafts 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, 25 Oct 2011 16:04:55 -0000 Hi, all, I sent these comments directly to Murray; he asked me to forward to the list. Comments on draft-kucherawy-reputation-vocab-identity-01: 1) I would add the following assertion: SENDS-TO-NONEXISTENT-RECIPIENT: The subject identity is associated with mail attemmpted to be sent to nonexistent recipients 2) All of the assertions are for "bad" behavior. Should there not be SENDS-HAM and SENDS-TO-VALID-RECIPIENT assertions? Or is that implicit in the numerical value and sample size? Comments on draft-kucherawy-reputation-model-00: It's not clear to me how the "overall rating" and "number of data points" are or should be related. Here's an example: Suppose bill@example.com has sent 1000 spams and 200 non-spams. Suppose we've seen 1200 attempts to valid recipients and 2000 attempts to nonexistent recipients. What is the rating and data-point number for SENDS-SPAM? I would say the rating should be 0.833 and the data points should be 1200. But it needs to be made clear that the number of data points considered should only include those data points specifically indicating an assertion or the negative of that assertion. Saying "the number of data points underlying that score" isn't sufficiently clear, IMO. Comments on draft-kucherawy-reputation-query-http: The URI template is interesting, but I can see naive clients doing two GETs for every lookup. Also, the full URI Template draft is pretty complex and possibly overkill. There should be some wording in there to the effect that a server SHOULD specify and Expires: header when a client retrieves a template and that a client SHOULD cache the header until it expires. Also, it occurs to me that a URI template is likely to be short enough and unchanging enough to be put into a DNS TXT record. :) Would we want to specify that? It would certainly take care of caching. If I have any more thoughts, I will send them. Regards, David. From dotis@mail-abuse.org Tue Oct 25 14:37:36 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 10C6111E8096 for ; Tue, 25 Oct 2011 14:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 jy6+dQflizYy for ; Tue, 25 Oct 2011 14:37:35 -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 9FB1B11E8095 for ; Tue, 25 Oct 2011 14:37:35 -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 CD9556E0147 for ; Tue, 25 Oct 2011 21:37:33 +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 3A0B4A9443B for ; Tue, 25 Oct 2011 21:37:34 +0000 (UTC) Message-ID: <4EA72C1D.1040701@mail-abuse.org> Date: Tue, 25 Oct 2011 14:37:33 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: domainrep@ietf.org References: <6.2.5.6.2.20111023134720.0b64ddc8@resistor.net> In-Reply-To: <6.2.5.6.2.20111023134720.0b64ddc8@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] A document about reputation data meta-issues 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, 25 Oct 2011 21:37:36 -0000 On 10/23/11 1:55 PM, SM wrote: > Hi Murray, > At 13:39 23-10-2011, Murray S. Kucherawy wrote: >> We included in our charter the need to produce an "informational >> document, discussing issues of data transparency, redress, >> meta-reputation and other important operational considerations." >> This comes from some fairly passionate discussion at the BoF in >> Quebec City. > > The data transparency and redress discussion is going to be highly > controversial. Does this have to be done before the technical work? The greatest concern is ramification of using "purported" identities as a basis to establish reputation. After all, IP address authorization or signatures in a message will not "authenticate" the actual domain accountable for abuse. IP address authorization will become disruptive in the face of Large Scale NATs and MTAs not offering IPv6 connectivity. A signature not covering intended recipients and the entity actually sending the message removes nonrepudiation of purported abuse. As such, enforcement on that basis is unable to withstand scrutiny. The only entities likely held harmless are those considered "too big to block". These large domains carry a growing percentage of overall abuse, and have little incentive to remediate compromised accounts. Most users have been trained that complaining is useless, and are now seeking other often proprietary alternatives. Disruptions caused by purported reputations seems certain to reduce reliance on SMTP. -Doug From sm@resistor.net Tue Oct 25 15:04: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 CFA5511E8081 for ; Tue, 25 Oct 2011 15:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 Yc9mZHE4PssE for ; Tue, 25 Oct 2011 15:04:20 -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 9F41F11E807F for ; Tue, 25 Oct 2011 15:04:20 -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 p9PM4Ce1009580; Tue, 25 Oct 2011 15:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1319580259; bh=xRy8sBWqnSoLHwr6lqBjf0UAJE5yzsbsj+x2CXJ68Xc=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=spcV01NaVZ1BbgyWQiLhvxSspa7AdHESEEShDphyrXKXz7WYQA/kYUfMzbE2hw0V7 GcvMQlzOxZuzaFqjFPAyjXcpY//twFiSZox5NefxAFDGdNa1C+oGBlN0xZB7SDHU6C YEiEf7ZW7QckhX9TWnp6sf9EF5ki4lWQH91M3M2U= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1319580259; bh=xRy8sBWqnSoLHwr6lqBjf0UAJE5yzsbsj+x2CXJ68Xc=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=YMRnrwNCsHM12zRH63zOCnks0moOZs4LjjQDOkDrNvYzZ2uceD8pWJ7lelfx7Ncmn vPAi1XSK6+LHOP0mzXcR9JuKgC/smvbxiRKkHSIvIFRZNj4ox2ReDWaVHbpXXNLUPe at1mmaBdLqjrEs6lqAEXcsajxIyDVEGW9w0moUnk= Message-Id: <6.2.5.6.2.20111025145136.0ad62b40@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 25 Oct 2011 15:01:42 -0700 To: Douglas Otis From: SM In-Reply-To: <4EA72C1D.1040701@mail-abuse.org> References: <6.2.5.6.2.20111023134720.0b64ddc8@resistor.net> <4EA72C1D.1040701@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: domainrep@ietf.org Subject: Re: [domainrep] A document about reputation data meta-issues 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, 25 Oct 2011 22:04:22 -0000 Hi Doug, At 14:37 25-10-2011, Douglas Otis wrote: >The greatest concern is ramification of using "purported" identities >as a basis to establish reputation. After all, IP address >authorization or signatures in a message will not "authenticate" the >actual domain accountable for abuse. With all due respect, I do not see anything which is directly related to "data transparency and redress" in the reply. If anyone wants to argue about this, I suggest submitting the arguments as an I-D. Regards, -sm From dotis@mail-abuse.org Tue Oct 25 15:48: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 A817911E808C for ; Tue, 25 Oct 2011 15:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 Z-2-S4ozGcdf for ; Tue, 25 Oct 2011 15:48:37 -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 3E84811E807F for ; Tue, 25 Oct 2011 15:48:37 -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 94116308135; Tue, 25 Oct 2011 22:48:36 +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 0456EA9443B; Tue, 25 Oct 2011 22:48:37 +0000 (UTC) Message-ID: <4EA73CC4.6070109@mail-abuse.org> Date: Tue, 25 Oct 2011 15:48:36 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: SM References: <6.2.5.6.2.20111023134720.0b64ddc8@resistor.net> <4EA72C1D.1040701@mail-abuse.org> <6.2.5.6.2.20111025145136.0ad62b40@resistor.net> In-Reply-To: <6.2.5.6.2.20111025145136.0ad62b40@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: domainrep@ietf.org Subject: Re: [domainrep] A document about reputation data meta-issues 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, 25 Oct 2011 22:48:37 -0000 On 10/25/11 3:01 PM, SM wrote: > Hi Doug, > At 14:37 25-10-2011, Douglas Otis wrote: >> The greatest concern is ramification of using "purported" identities >> as a basis to establish reputation. After all, IP address >> authorization or signatures in a message will not "authenticate" the >> actual domain accountable for abuse. > > With all due respect, I do not see anything which is directly related > to "data transparency and redress" in the reply. > > If anyone wants to argue about this, I suggest submitting the > arguments as an I-D. SM, Whenever reputation is misplaced using methods not controlled by the "purported" abusing sender, there is neither transparency nor redress. There is no transparency with respect to which "message element" formed an authorization and whether an apparent outbound MTA acted to constrain this element. In other words, outbound MTAs MUST be considered opaque when making assumptions about which "message element" offers authorization. When an effort to authorize an outbound MTA for the purpose of ensuring NDNs is misused to assign accountability, data collected on that basis must be considered opaque. Since a mistaken basis for accrual of negative reputation would be well beyond the control of the sender, there is also no redress either. An I-D could be written to clarify the likely outcome of using "purported" rather than "authenticated" identifiers. Is this what you meant? -Doug From sm@resistor.net Tue Oct 25 16:34:16 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 DBC6311E80F5 for ; Tue, 25 Oct 2011 16:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 mPVoMDyxuM1A for ; Tue, 25 Oct 2011 16:34:16 -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 14B6111E80F9 for ; Tue, 25 Oct 2011 16:34:15 -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 p9PNY6ck019710; Tue, 25 Oct 2011 16:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1319585654; bh=KNElfOmIB+cZbSdhlTdjxzCRAsDXmJZ+n8hiapk08DM=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=f/9fPlRIc+XpjaOEq9kwhKWolJBMM88QDkGkLoQYyLFcnSzHaIxtKpIdyg7eO+Mgj XZQoB9T6WydY+eaYTIGNx0Zg2ejzJaSpdABFd5xOSNhrDRcVxL74Aw23cB9fZO2vj4 PZesJ0XBDM9+uE21HTN6xLO4ALvG361JWdYb/D7k= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1319585654; bh=KNElfOmIB+cZbSdhlTdjxzCRAsDXmJZ+n8hiapk08DM=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=Fe1a+yqJ9gcVm7phI6MoKwa05ozfzRSRVDivZe6ow4KOOZVnn3J2msH59xMCEVdBc ydB/PqLQThAKItQ3wjaCLIMUneWLvH2sYGbB7KpqPH+A7a/rZxPKT2p2byPrjfsU9Z xXL4Y2nEtUhRyVZ2gM6p5owDcWRkyj2XHcCAzwX8= Message-Id: <6.2.5.6.2.20111025160939.0a9d77e0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 25 Oct 2011 16:31:15 -0700 To: Douglas Otis From: SM In-Reply-To: <4EA73CC4.6070109@mail-abuse.org> References: <6.2.5.6.2.20111023134720.0b64ddc8@resistor.net> <4EA72C1D.1040701@mail-abuse.org> <6.2.5.6.2.20111025145136.0ad62b40@resistor.net> <4EA73CC4.6070109@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: domainrep@ietf.org Subject: Re: [domainrep] A document about reputation data meta-issues 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, 25 Oct 2011 23:34:17 -0000 Hi Doug, At 15:48 25-10-2011, Douglas Otis wrote: >An I-D could be written to clarify the likely outcome of using >"purported" rather than "authenticated" identifiers. Is this what you meant? The topic was about data transparency and redress. The I-D could be about that. Regards, -sm From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Tue Oct 25 23:08: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 7D4B121F85A8 for ; Tue, 25 Oct 2011 23:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.893 X-Spam-Level: X-Spam-Status: No, score=-102.893 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 lt6mmRYEb2oY for ; Tue, 25 Oct 2011 23:08:06 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EEF0D21F85A7 for ; Tue, 25 Oct 2011 23:08:02 -0700 (PDT) Received: by wwe6 with SMTP id 6so1341443wwe.13 for ; Tue, 25 Oct 2011 23:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=zt0njICS4WY14jHfAyRdh7ZeVseJihYzz8lr8UdzQKY=; b=NLGhuDM0I7zmXBaXy7QYM9o30XGdypcB9aV/rG7IOsmT/x1/4KuasWA8/3m6A9BP9v h4nhrXdVHU/sTGzn/uC+O08LOtIxITQKAkY91mIco2xIyrtBy0LcPIpz/fJ7+GgVEYga cFVSgXOgjBhZu5Nt/BZmpiLce25SAahR8/PtQ= Received: by 10.227.60.131 with SMTP id p3mr8767517wbh.4.1319609282080; Tue, 25 Oct 2011 23:08:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.80.134 with HTTP; Tue, 25 Oct 2011 23:07:22 -0700 (PDT) From: Frank Ellermann Date: Wed, 26 Oct 2011 08:07:22 +0200 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: "domainrep@ietf.org" Subject: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 26 Oct 2011 06:08:07 -0000 On 25 October 2011 13:26, Murray S. Kucherawy wrote: > Have you read the drafts that are out already? I looked into something and got the vague idea that Dave wants percent values instead of simple YES / NO answers. That does not exclude "DNS based lists" as defined in RFC 5782. [[Keith Moore offered a nice flame war about 'DNSBL' and RFC 5782 on the SMTP list recently, but I wasn't in the mood to follow suit.]] Just in case, DNSBLs as defined in RFC 5782 are "DNS based lists", not necessarily black/block/white/... In essence RFC 5782 specifies a way how DNS can be used to encode any kind of reply with up to 23 bits as (pseudo-) IPv4 in the range 127.0.0.0/8 excluding 127.0.0.1/32. Looking in your I-D.*-identity.01 you apparently have that as RFCxxxx+3. IOW, where you can get way with 0.00, 0.01, ..., 0.99, 1.00 for RATING this could be encoded in 7 bits for 0..100 in RFCxxxx+3. You'd end up with 16 available bits x+y in 127.x.y.z for other stuff such as RATER-AUTHENTICITY. Syntax nit for the media type: Please get rid of the case-sensitive ABNF; nobody uses this (unless they MUST); there might be even some BCP about using case-insensitive syntax whenever possible. You can still use upper-case for readability. Admittedly DNSBLs can't help you if you want info in the direction of RATER or SAMPLE-SIZE. And if you'd encode ASSERTION values as bits you'd need a kind of "enumeration registry" with defined ASSERTION values for whatever you intend to enumerate. Semantical nit in I-D.*-vocab.01: If you have a term MAILFROM it is almost certainly pointless to create a different term SPF. Details for folks not familiar with SPF: SPF can be used to check the SMTP "HELO", that is an ordinary host-name or a "domain-literal" (= IP in square brackets) of the "client", i.e., the SMTP sending mail. SPF can also check the "MAIL FROM", that used to be the Return-Path in RFC 821, and today (2821+5321) it is also known as "envelope sender address"; the path business is mostly historic (and removed if present in SPF checks). There is one special case where the "return path" still is (syntactically) a path, the "MAIL FROM" can be empty; notably in "delivery status notifications" (DSNs) not limited to "non-delivery reports" (NDRs, also known as bounces) for obvious reasons. In SPF checks this empty path is mapped to a pseudo- address postmaster@helo-domain, where "helo-domain" is simply the host-name (or domain-literal) as seen in the HELO check. In other words, for the purposes of SPF the reputation of HELO domain example and the reputation of MAIL FROM postmaster@example are the same thing. The MAILFROM identity in I-D.*vocab-identity should be exactly what RFC 4408 and 4408bis say. It makes no sense to use a different term SPF, because there is no meaningful "reputation" for an empty string in MAIL FROM: <> One of the better SPF features (once you get past its various obscure and baroque features), it is strictly built on SMTP, forward, sideward, backward. And DKIM is strictly SMTP-agnostic, DKIM could handle NNTP or avian carrier if desired. -Frank From msk@cloudmark.com Wed Oct 26 00:37:02 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 32D1821F8AA9 for ; Wed, 26 Oct 2011 00:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.227 X-Spam-Level: X-Spam-Status: No, score=-103.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 UjsczldCL7pQ for ; Wed, 26 Oct 2011 00:37:01 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id E9FFD21F8AA8 for ; Wed, 26 Oct 2011 00:36:59 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 26 Oct 2011 00:36:59 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 26 Oct 2011 00:36:59 -0700 Thread-Topic: [domainrep] A document about reputation data meta-issues Thread-Index: AcyRxjOWXdOmDMZwTuieJdD6pKhTdwB67SWw Message-ID: References: <6.2.5.6.2.20111023134720.0b64ddc8@resistor.net> In-Reply-To: <6.2.5.6.2.20111023134720.0b64ddc8@resistor.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] A document about reputation data meta-issues 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, 26 Oct 2011 07:37:02 -0000 > -----Original Message----- > From: SM [mailto:sm@resistor.net] > Sent: Sunday, October 23, 2011 1:55 PM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] A document about reputation data meta-issues >=20 > The data transparency and redress discussion is going to be highly > controversial. Does this have to be done before the technical work? I think they can be done in parallel. I don't think those issues affect th= e technical solution. And if the working group contains people that care a= bout one but not the other, we might be able to bang out some of that work = in parallel. But I'm not partial to either approach. From msk@cloudmark.com Wed Oct 26 00:40: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 03B0E21F8AF4 for ; Wed, 26 Oct 2011 00:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.234 X-Spam-Level: X-Spam-Status: No, score=-103.234 tagged_above=-999 required=5 tests=[AWL=0.365, 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 3CNSM5AMSH9B for ; Wed, 26 Oct 2011 00:40:49 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id B06EF21F8AEC for ; Wed, 26 Oct 2011 00:40:49 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 26 Oct 2011 00:40:49 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 26 Oct 2011 00:40:49 -0700 Thread-Topic: [domainrep] A document about reputation data meta-issues Thread-Index: AcyTXlf2ufhtQM8wS5a/EKS9JNfCkgAU/qDQ Message-ID: References: <6.2.5.6.2.20111023134720.0b64ddc8@resistor.net> <4EA72C1D.1040701@mail-abuse.org> In-Reply-To: <4EA72C1D.1040701@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] A document about reputation data meta-issues 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, 26 Oct 2011 07:40:51 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Douglas Otis > Sent: Tuesday, October 25, 2011 2:38 PM > To: domainrep@ietf.org > Subject: Re: [domainrep] A document about reputation data meta-issues >=20 > The greatest concern is ramification of using "purported" identities as > a basis to establish reputation. After all, IP address authorization > or signatures in a message will not "authenticate" the actual domain > accountable for abuse. This was brought up at the BoF, and is reasonable potential subject matter = for this draft. But my view is that a reputation provider needs to make it= clear to its consumers what data it collects, how it does so, how it proce= sses it to come up with its reputations, and what redress methods it has. = Then the consumers can gauge how safe it is to make use of that data in its= decision engines. From msk@cloudmark.com Wed Oct 26 00:41:34 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 1B55321F8AF6 for ; Wed, 26 Oct 2011 00:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.742 X-Spam-Level: X-Spam-Status: No, score=-102.742 tagged_above=-999 required=5 tests=[AWL=-0.143, 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 v5Xx4MLmk3hE for ; Wed, 26 Oct 2011 00:41:33 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id B0A1D21F8AF4 for ; Wed, 26 Oct 2011 00:41:33 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 26 Oct 2011 00:41:33 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 26 Oct 2011 00:41:33 -0700 Thread-Topic: [domainrep] A document about reputation data meta-issues Thread-Index: AcyTbq5BVypMV9LTRKejmd5oPkJ9/AAQ/N7g Message-ID: References: <6.2.5.6.2.20111023134720.0b64ddc8@resistor.net> <4EA72C1D.1040701@mail-abuse.org> <6.2.5.6.2.20111025145136.0ad62b40@resistor.net> <4EA73CC4.6070109@mail-abuse.org> <6.2.5.6.2.20111025160939.0a9d77e0@resistor.net> In-Reply-To: <6.2.5.6.2.20111025160939.0a9d77e0@resistor.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] A document about reputation data meta-issues 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, 26 Oct 2011 07:41:34 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of SM > Sent: Tuesday, October 25, 2011 4:31 PM > To: Douglas Otis > Cc: domainrep@ietf.org > Subject: Re: [domainrep] A document about reputation data meta-issues >=20 > The topic was about data transparency and redress. The I-D could be > about that. ...and other things. See the BoF minutes. From msk@cloudmark.com Wed Oct 26 01:33:03 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 170DE21F8B03 for ; Wed, 26 Oct 2011 01:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.243 X-Spam-Level: X-Spam-Status: No, score=-103.243 tagged_above=-999 required=5 tests=[AWL=0.356, 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 jVy+K+eKYpfB for ; Wed, 26 Oct 2011 01:33:02 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id AD51A21F8AF8 for ; Wed, 26 Oct 2011 01:33:02 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 26 Oct 2011 01:33:02 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 26 Oct 2011 01:33:02 -0700 Thread-Topic: Comments on draft-kucherawy-reputation-query-http Thread-Index: AcyTL9dvSCwRoZQJQ2e7BZ8XSGPw2AAiTWrQ Message-ID: References: <20111025120447.5155ba24@hydrogen.roaringpenguin.com> In-Reply-To: <20111025120447.5155ba24@hydrogen.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: [domainrep] Comments on draft-kucherawy-reputation-query-http 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, 26 Oct 2011 08:33:03 -0000 Splitting up David Skoll's feedback into the documents they reference: > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of David F. Skoll > Sent: Tuesday, October 25, 2011 9:05 AM > To: domainrep@ietf.org > Subject: [domainrep] Comments on drafts >=20 > Comments on draft-kucherawy-reputation-query-http: >=20 > The URI template is interesting, but I can see naive clients doing two > GETs for every lookup. Also, the full URI Template draft is pretty compl= ex > and possibly overkill. There should be some wording in there to the effe= ct > that a server SHOULD specify and Expires: header when a client retrieves > a template and that a client SHOULD cache the header until it expires. I just asked this question on the list where the templates document is disc= ussed, and got back something pretty much along these lines. I'll add that= in the next version. > Also, it occurs to me that a URI template is likely to be short enough > and unchanging enough to be put into a DNS TXT record. :) Would we want > to specify that? It would certainly take care of caching. Going the route of the well-known URI was the advice I got from one of the = template draft's authors, representing the common way these things are done= in web applications. I'm fine with that because I'm an email guy treading= in web space which isn't my area of expertise, but doing it in a TXT recor= d would be fine with me if there's consensus that that's better. -MSK From msk@cloudmark.com Wed Oct 26 01:41: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 4803121F8487 for ; Wed, 26 Oct 2011 01:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.75 X-Spam-Level: X-Spam-Status: No, score=-102.75 tagged_above=-999 required=5 tests=[AWL=-0.151, 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 7ELf7wnHtMLO for ; Wed, 26 Oct 2011 01:41: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 DD25921F8480 for ; Wed, 26 Oct 2011 01:41: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; Wed, 26 Oct 2011 01:41:04 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 26 Oct 2011 01:41:03 -0700 Thread-Topic: Comments on draft-kucherawy-reputation-vocab-identity Thread-Index: AcyTL9dvSCwRoZQJQ2e7BZ8XSGPw2AAigo/A Message-ID: References: <20111025120447.5155ba24@hydrogen.roaringpenguin.com> In-Reply-To: <20111025120447.5155ba24@hydrogen.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: [domainrep] Comments on draft-kucherawy-reputation-vocab-identity 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, 26 Oct 2011 08:41:05 -0000 Splitting up David Skoll's feedback into the documents they reference: > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of David F. Skoll > Sent: Tuesday, October 25, 2011 9:05 AM > To: domainrep@ietf.org > Subject: [domainrep] Comments on drafts >=20 > Comments on draft-kucherawy-reputation-vocab-identity-01: >=20 > 1) I would add the following assertion: >=20 > SENDS-TO-NONEXISTENT-RECIPIENT: The subject identity is associated with > mail attemmpted to be sent to nonexistent recipients That seems potentially useful. I can add it to the registration. > 2) All of the assertions are for "bad" behavior. Should there not be > SENDS-HAM and SENDS-TO-VALID-RECIPIENT assertions? Or is that implicit > in the numerical value and sample size? That's something we've discussed, especially in the BoF I think, but isn't = reflected in the draft yet. The range of assertions is currently defined a= s being in the range [0, 1], meaning you disagree (0) or agree (1) with the= assertion to varying degrees. But we also considered [-1, 1], which as I = recall means disagree (0), agree (1), or assert the opposite of (-1) what's= being stated in the reply. Maybe it's time to have that conversation now so that it's on the record. What say you all? From msk@cloudmark.com Wed Oct 26 01:46: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 2A1D021F8A7B for ; Wed, 26 Oct 2011 01:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.247 X-Spam-Level: X-Spam-Status: No, score=-103.247 tagged_above=-999 required=5 tests=[AWL=0.352, 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 BdNOKaNFAcYl for ; Wed, 26 Oct 2011 01:46:58 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id BDFD121F8A57 for ; Wed, 26 Oct 2011 01:46:58 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 26 Oct 2011 01:46:58 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 26 Oct 2011 01:46:57 -0700 Thread-Topic: [domainrep] Comments on drafts Thread-Index: AcyTL9dvSCwRoZQJQ2e7BZ8XSGPw2AAizu6A Message-ID: References: <20111025120447.5155ba24@hydrogen.roaringpenguin.com> In-Reply-To: <20111025120447.5155ba24@hydrogen.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] Comments on drafts 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, 26 Oct 2011 08:46:59 -0000 Splitting up David Skoll's feedback into the documents they reference: > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of David F. Skoll > Sent: Tuesday, October 25, 2011 9:05 AM > To: domainrep@ietf.org > Subject: [domainrep] Comments on drafts >=20 > Comments on draft-kucherawy-reputation-model-00: >=20 > It's not clear to me how the "overall rating" and "number of data points" > are or should be related. Here's an example: >=20 > Suppose bill@example.com has sent 1000 spams and 200 non-spams. Suppose > we've seen 1200 attempts to valid recipients and 2000 attempts to nonexis= tent > recipients. >=20 > What is the rating and data-point number for SENDS-SPAM? > I would say the rating should be 0.833 and the data points should be 1200= . > But it needs to be made clear that the number of data points considered s= hould > only include those data points specifically indicating an assertion or th= e > negative of that assertion. Saying "the number of data points underlying > that score" isn't sufficiently clear, IMO. There are two approaches possible here: 1) This is something that a document creating a reputation application and/= or assertions need to define. This constrains service providers in how the= y produce their values, but makes transition between two reputation provide= rs in the same space more painless. 2) This is something that a reputation service provider making those assert= ions defines to consumers in some out-of-band way. This provides more impl= ementation latitude but requires more caution during such transitions and p= ossibly more client complexity. It sounds like the general trend is that people would like to see (1), but = would that limit adoption by reputation service providers? From msk@cloudmark.com Wed Oct 26 01:54:54 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 276F521F8AF5 for ; Wed, 26 Oct 2011 01:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.753 X-Spam-Level: X-Spam-Status: No, score=-102.753 tagged_above=-999 required=5 tests=[AWL=-0.154, 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 ORfHLKpstmZw for ; Wed, 26 Oct 2011 01:54:53 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id B4D4921F8AF4 for ; Wed, 26 Oct 2011 01:54:53 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 26 Oct 2011 01:54:53 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 26 Oct 2011 01:54:53 -0700 Thread-Topic: I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) Thread-Index: AcyTpaIgvsW8R5DTTgyQqSucx+6f0wAFrCHg Message-ID: References: In-Reply-To: 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] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 26 Oct 2011 08:54:54 -0000 > -----Original Message----- > From: Frank Ellermann [mailto:hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com] > Sent: Tuesday, October 25, 2011 11:07 PM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: I-D.*-reputation-*.01 (was: A document about reputation data met= a-issues) >=20 > In essence RFC 5782 specifies a way how DNS can be > used to encode any kind of reply with up to 23 bits > as (pseudo-) IPv4 in the range 127.0.0.0/8 excluding > 127.0.0.1/32. >=20 > Looking in your I-D.*-identity.01 you apparently have > that as RFCxxxx+3. IOW, where you can get way with > 0.00, 0.01, ..., 0.99, 1.00 for RATING this could be > encoded in 7 bits for 0..100 in RFCxxxx+3. You'd end > up with 16 available bits x+y in 127.x.y.z for other > stuff such as RATER-AUTHENTICITY. All true, but the IESG made it clear they don't intend to allow A record ov= erloading to become a standard. We're also considering allowing negative ratings (see other thread). > Syntax nit for the media type: Please get rid of the > case-sensitive ABNF; nobody uses this (unless they MUST); there might > be even some BCP about using case-insensitive syntax whenever possible. > You can still use upper-case for readability. Yeah, that's probably fair. > Semantical nit in I-D.*-vocab.01: If you have a term > MAILFROM it is almost certainly pointless to create > a different term SPF. Details for folks not familiar > with SPF: SPF can be used to check the SMTP "HELO", > that is an ordinary host-name or a "domain-literal" > (=3D IP in square brackets) of the "client", i.e., the > SMTP sending mail. That's not true. You might develop reputation based on SMTP MAIL FROM with= out checking SPF. (Might be a dumb idea, but you could do it.) From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Oct 26 02:24:14 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 0349121F8ABC for ; Wed, 26 Oct 2011 02:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.9 X-Spam-Level: X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 KN8+rIqaMvjg for ; Wed, 26 Oct 2011 02:24:13 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F64621F8AAA for ; Wed, 26 Oct 2011 02:24:13 -0700 (PDT) Received: by wyh22 with SMTP id 22so1684810wyh.31 for ; Wed, 26 Oct 2011 02:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=1DtNaLD9gKLVLjYWflz6mak/PJU73A3lIZrESRzbZjU=; b=RVO/zKdw3EKYzTPyeymXagyFlF8AUESjaANQv3/mEp3UuoQnM72NhU0L9d835y0ZLr FDIQVIeJ90Vl28ajVYcG/dxTJabAH4bpZQXUPvpV2QrbKz/RFz2y1wJG/hL4jwnLMaNG Z7q23ZARobVlrqt7IpiVs/7HyDPJ2xnUGnyJo= Received: by 10.227.60.131 with SMTP id p3mr9801601wbh.4.1319621052064; Wed, 26 Oct 2011 02:24:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.80.134 with HTTP; Wed, 26 Oct 2011 02:23:32 -0700 (PDT) In-Reply-To: References: From: Frank Ellermann Date: Wed, 26 Oct 2011 11:23:32 +0200 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "domainrep@ietf.org" Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 26 Oct 2011 09:24:14 -0000 On 26 October 2011 10:54, Murray S. Kucherawy wrote: [RFC 5287] > All true, but the IESG made it clear they don't > intend to allow A record overloading to become a > standard. Pointer, please. The IESG is supposed to determine the IETF consensus, and I'm not aware of any IETF consensus wrt using DNS as a kind of "23-bits whois": For this purpose UDP is cheaper than TCP, isn't it? > We're also considering allowing negative ratings Okay, but you can do signed int with bits if you really want it, there is even some prior art... ;-) > That's not true. Not sure what you consider as "untrue". It is true that MAILFROM as an identity for reputation can be only defined as in RFC 4408 + 4408bis. It does not imply that SPF is the only way to do something with this identity, it means there is no other plausible way to define what a MAILFROM identity actually is. >=A0You might develop reputation based on SMTP MAIL > FROM without checking SPF. =A0(Might be a dumb idea, > but you could do it.) Sure, you could also apply SenderID on Message-IDs. But you would not suggest a "PRA identity", unless it is what RFC 4407 says. Likewise a MAILFROM id. is what 4408(bis) says. There is no such thing as a different "SPF identity"; just remove the latter from your vocabulary draft. -Frank From msk@cloudmark.com Wed Oct 26 02:44:29 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 34E4421F8AFB for ; Wed, 26 Oct 2011 02:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.251 X-Spam-Level: X-Spam-Status: No, score=-103.251 tagged_above=-999 required=5 tests=[AWL=0.348, 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 qFhz64GlqZqM for ; Wed, 26 Oct 2011 02:44:28 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id C399621F8AF9 for ; Wed, 26 Oct 2011 02:44:28 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 26 Oct 2011 02:44:28 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 26 Oct 2011 02:44:28 -0700 Thread-Topic: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) Thread-Index: AcyTwQnZtgyADmJ7QYOs0+7ak4xtXQAAqBbQ Message-ID: References: In-Reply-To: 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] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 26 Oct 2011 09:44:29 -0000 > -----Original Message----- > From: Frank Ellermann [mailto:hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com] > Sent: Wednesday, October 26, 2011 2:24 AM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about rep= utation data meta-issues) >=20 > On 26 October 2011 10:54, Murray S. Kucherawy wrote: >=20 > [RFC 5287] > > All true, but the IESG made it clear they don't > > intend to allow A record overloading to become a > > standard. >=20 > Pointer, please. The IESG is supposed to determine > the IETF consensus, and I'm not aware of any IETF > consensus wrt using DNS as a kind of "23-bits whois": > For this purpose UDP is cheaper than TCP, isn't it? That would be the DNSBL RFC evaluation record. > > That's not true. >=20 > Not sure what you consider as "untrue". It is true > that MAILFROM as an identity for reputation can be > only defined as in RFC 4408 + 4408bis. RFC821 defined MAIL FROM. Why can that definition not be used to develop r= eputation if someone wanted to do that? From ajs@anvilwalrusden.com Wed Oct 26 03:21: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 AF39F21F8AFB for ; Wed, 26 Oct 2011 03:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 GeU0J3Ns2Xtg for ; Wed, 26 Oct 2011 03:21:37 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 1990D21F8AFA for ; Wed, 26 Oct 2011 03:21:37 -0700 (PDT) Received: from shinkuro.com (unknown [199.91.193.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1ABBE1ECB41C for ; Wed, 26 Oct 2011 10:21:25 +0000 (UTC) Date: Wed, 26 Oct 2011 06:21:34 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20111026102133.GB41225@shinkuro.com> 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] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 26 Oct 2011 10:21:37 -0000 On Wed, Oct 26, 2011 at 11:23:32AM +0200, Frank Ellermann wrote: > Pointer, please. The IESG is supposed to determine > the IETF consensus, and I'm not aware of any IETF > consensus wrt using DNS as a kind of "23-bits whois": > For this purpose UDP is cheaper than TCP, isn't it? Even if the IESG hadn't made remarks about this, I think you'd find a certain part of the community screaming in pain if people tried to recycle the DNSBL mechanism for a new service. This is not to say "don't use DNS" (I'm sure there will be such people, though), but it is to say "don't overload A records". A -- Andrew Sullivan ajs@anvilwalrusden.com From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Oct 26 03:34: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 CDB3A21F8AC9 for ; Wed, 26 Oct 2011 03:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.906 X-Spam-Level: X-Spam-Status: No, score=-102.906 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 sCVs2wv+RlsP for ; Wed, 26 Oct 2011 03:34:52 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EC6AA21F8ABC for ; Wed, 26 Oct 2011 03:34:51 -0700 (PDT) Received: by wwe6 with SMTP id 6so1564134wwe.13 for ; Wed, 26 Oct 2011 03:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iUyqej0HHT5jsZ/OH5dd3X71KOMwuCHehtGgDMLr20s=; b=WZLgGDlKHnVqaVoZD1yEE3iRnjaBaexKuFd1whMMgtLagOByyaR/eif30aMK49H+QC zm1prTJ2SX+WdXMkaTnEa+rCwMz6oO3iU0E+kG0C8dbWPSgh55hs8J5ZDGeUG4/+cJ+F WXF34IXpWlbT20N5tlec+iBnmwDgBtcLuKK2w= Received: by 10.227.208.77 with SMTP id gb13mr9992513wbb.4.1319625291160; Wed, 26 Oct 2011 03:34:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.80.134 with HTTP; Wed, 26 Oct 2011 03:34:11 -0700 (PDT) In-Reply-To: References: From: Frank Ellermann Date: Wed, 26 Oct 2011 12:34:11 +0200 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 26 Oct 2011 10:34:52 -0000 On 26 October 2011 11:44, Murray S. Kucherawy wrote: >> Pointer, please. [...] > That would be the DNSBL RFC evaluation record. , apparently. There's a bunch of [DISCUSS] saying that this should be PS and DNSOPS instead of "research", because it's no research. I don't see that the IETF in 2008 did not like this peculiar 127.0.0.2/8 usage. > RFC821 defined MAIL FROM. I'm talking about the "MAILFROM identity" in your draft. Of course that is based on SMTP MAIL FROM, 821/2821/5321/5321bis. But as an "identity" for reputation it is defined in 4408/4408bis. The SMTP RFCs are not about identities, they don't tell you what to do with an "empty" MAIL FROM if you want to attach some kind of reputation to it. RFC 4408 explains this trick. If some scheme has no use for empty MAIL FROMs it is fine; otherwise it should follow the definition in RFC 4408. Or use another name, "MAILFROM" and "PRA" are already taken. -Frank From msk@cloudmark.com Wed Oct 26 04:21:13 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 2E44621F8ABC for ; Wed, 26 Oct 2011 04:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.257 X-Spam-Level: X-Spam-Status: No, score=-103.257 tagged_above=-999 required=5 tests=[AWL=0.342, 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 k2WTf7eAlEq4 for ; Wed, 26 Oct 2011 04:21:12 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id C0E2021F8A7A for ; Wed, 26 Oct 2011 04:21:12 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 26 Oct 2011 04:20:51 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 26 Oct 2011 04:20:50 -0700 Thread-Topic: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) Thread-Index: AcyTyuksZeQMC5BsTHqQRtnP7p9nRwABhbFQ Message-ID: References: In-Reply-To: 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] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 26 Oct 2011 11:21:13 -0000 > -----Original Message----- > From: Frank Ellermann [mailto:hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com] > Sent: Wednesday, October 26, 2011 3:34 AM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about rep= utation data meta-issues) >=20 > > RFC821 defined MAIL FROM. >=20 > I'm talking about the "MAILFROM identity" in your > draft. Of course that is based on SMTP MAIL FROM, > 821/2821/5321/5321bis. But as an "identity" for > reputation it is defined in 4408/4408bis. I still don't understand what distinction you're making. It sounds like yo= u want SPF to get credit for being the first to present the idea of evaluat= ing what MAIL FROM says in a filtering sense. I think there's plenty of pr= ior art predating SPF in that regard. If that's not it, I'm lost. From dhc@dcrocker.net Wed Oct 26 04:30: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 0D89221F8AFB for ; Wed, 26 Oct 2011 04:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 Oge7H2vz53KT for ; Wed, 26 Oct 2011 04:30:21 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEEA21F8AF4 for ; Wed, 26 Oct 2011 04:30:21 -0700 (PDT) Received: from [10.115.198.211] (62-50-223-232.client.stsn.net [62.50.223.232]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p9QBU7sp023486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Oct 2011 04:30:16 -0700 Message-ID: <4EA7EF3A.4070109@dcrocker.net> Date: Wed, 26 Oct 2011 13:30:02 +0200 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andrew Sullivan References: <20111026102133.GB41225@shinkuro.com> In-Reply-To: <20111026102133.GB41225@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, 26 Oct 2011 04:30:18 -0700 (PDT) Cc: domainrep@ietf.org Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 26 Oct 2011 11:30:22 -0000 Just to comment on history... On 10/26/2011 12:21 PM, Andrew Sullivan wrote: > Even if the IESG hadn't made remarks about this, I think you'd find a > certain part of the community screaming in pain if people tried to > recycle the DNSBL mechanism for a new service. That part of the community is indeed quite vigorous about this point. But the process entirely ignored how thoroughly ingrained this method of overloading the use of A records is in the critical function of global email reputation list publication and use. In other words, the methodology has massive rough consensus IN ITS FAVOR, demonstrated by very widespread adoption and use. However, the fact that this violates a purists' sense of what should be permitted was the basis for rejecting a previous standardization effort. If one tried to compare the size of the rough consensus in one direction versus another, I believe the scale of actual use dwarfs the scale of the purist constituency. That fact appeared to be irrelevant to the IESG, last time, and I wouldn't expect this to have changed. (But I also don't happen to expect the A-record approach to be relevant to the current work...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Oct 26 05:30:54 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 B435021F8AE6 for ; Wed, 26 Oct 2011 05:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.912 X-Spam-Level: X-Spam-Status: No, score=-102.912 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 qlGw32rIm+dW for ; Wed, 26 Oct 2011 05:30:54 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 02DB921F8AE1 for ; Wed, 26 Oct 2011 05:30:53 -0700 (PDT) Received: by wyh22 with SMTP id 22so1877003wyh.31 for ; Wed, 26 Oct 2011 05:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=AYtevr13jeB/1PboTv/QJj4gkVSqp9L8bRLGfB0ruV0=; b=VBnH2EubDye1vxsdqXqfwqXhQJuqNyekvzSu9xnCg0UeQSJNWetXxZo6DKoUimdyz0 61GjRVJr5HuI3u67XtVRoEQGmCgNVHblnuWcgwWkKIvKzv24nv3/OB7J0i/+/WBgm/Zj pPbJj0IT/DGDx+T7eJkteSGOINmvyd7RF+CRw= Received: by 10.227.60.131 with SMTP id p3mr10864861wbh.4.1319632253122; Wed, 26 Oct 2011 05:30:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.80.134 with HTTP; Wed, 26 Oct 2011 05:30:12 -0700 (PDT) In-Reply-To: References: From: Frank Ellermann Date: Wed, 26 Oct 2011 14:30:12 +0200 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "domainrep@ietf.org" Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 26 Oct 2011 12:30:54 -0000 On 26 October 2011 13:20, Murray S. Kucherawy wrote: > I still don't understand what distinction you're > making. =A0It sounds like you want SPF to get credit > for being the first to present the idea of > evaluating what MAIL FROM says in a filtering sense. No. I suggested to delete "SPF" in your vocabulary, and to use 4408bis as a reference for your "MAIL FROM" identity. Quick reality check: There are 29 occurrences of '"MAIL FROM" identity' in 4408bis (not counting "MAIL FROM" without 'identity'). There is no "SPF identity" in 4408bis. As you said there is no other scheme using any other kind of a "MAIL FROM identity", therefore you don't need to reserve this term for something that doesn't exist, just use it "as is". If folks later invent something else they can pick a new name, e.g., "SMTP identity" or "envelope identity" or whatever remotely makes sense from their POV. But they should not create any unnecessary confusion with the '"MAIL FROM" identity' in 4408bis. > If that's not it, I'm lost. How d'you feel if I'd use the term "ARF" for some kind of abuse report format unrelated to RFC 5965? -Frank From msk@cloudmark.com Wed Oct 26 05:45: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 3A69321F8B4D for ; Wed, 26 Oct 2011 05:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.763 X-Spam-Level: X-Spam-Status: No, score=-102.763 tagged_above=-999 required=5 tests=[AWL=-0.164, 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 qog6OKX4IHWj for ; Wed, 26 Oct 2011 05:45:07 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id BC6E321F8B4C for ; Wed, 26 Oct 2011 05:45:07 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 26 Oct 2011 05:45:07 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 26 Oct 2011 05:45:05 -0700 Thread-Topic: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) Thread-Index: AcyT2yTgZDPpiLsJRnCacMMvoIvaLAAAT9GA Message-ID: References: In-Reply-To: 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] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 26 Oct 2011 12:45:08 -0000 > -----Original Message----- > From: Frank Ellermann [mailto:hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com] > Sent: Wednesday, October 26, 2011 5:30 AM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about rep= utation data meta-issues) >=20 > No. I suggested to delete "SPF" in your vocabulary, > and to use 4408bis as a reference for your "MAIL FROM" > identity. Quick reality check: >=20 > There are 29 occurrences of '"MAIL FROM" identity' in > 4408bis (not counting "MAIL FROM" without 'identity'). Assuming you're talking about Section 4.2 of draft-kucherawy-reputation-voc= ab-identity, maybe I can explain by illustration why that's there. Suppose I ask about example.com for a reputation. If the reply comes back = with a value, now you know what the reputation provider thinks about that d= omain. But that value doesn't tell you much if you don't know how it was c= omputed. I wouldn't want to use that value in a system that expresses repu= tation based on DKIM-validated domains if that service is actually collecti= ng data about domains that SPF validated, or indeed domains that weren't va= lidated at all. So the point of the IDENTITY: part of the reply is to give= the client some context, making the reply more meaningful. So if I give you a reputation of X with "IDENTITY: SPF", I'm saying that's = the reputation of X when you're talking about the domain that SPF validated= . If I give you a reputation of X with "IDENTITY: RFC5321.MAILFROM", then = I'm talking about that domain when used in the envelope regardless of what = SPF said about it. In that sense, the distinction is necessary. > There is no "SPF identity" in 4408bis. As you said > there is no other scheme using any other kind of a > "MAIL FROM identity", therefore you don't need to > reserve this term for something that doesn't exist, > just use it "as is". There are such schemes, actually, but they tend to be coupled with other th= ings. -MSK From ietf-dkim@kitterman.com Wed Oct 26 06:43:32 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 5BAF021F8B0C for ; Wed, 26 Oct 2011 06:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Izv6JO1bTMP2 for ; Wed, 26 Oct 2011 06:43:31 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id ACE0921F8AEC for ; Wed, 26 Oct 2011 06:43:31 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D799320E409D; Wed, 26 Oct 2011 09:43:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1319636610; bh=ZWRVvj9hMo/xTwmvHwE4Q7veQwBAGkB9I+rYX5guLqM=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=FlRdLEr1ehZbWIHRijgBMc3v7PzGtj56nJR+h8YDOBRLcDTNNf0AxkydknyCtfhfu bdgu1IOyQhUUnX3DQqkG3AjeyzpIGuvcIow+rYs2BgRhEjjOLbipf8o+nvxquwLZtK YQhzCwT583ETbEh4RdFN6lBW7wl4miPcQdrAb9C0= Received: from [192.168.111.113] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B41AB20E4084; Wed, 26 Oct 2011 09:43:30 -0400 (EDT) Message-ID: <4EA80E82.3020202@kitterman.com> Date: Wed, 26 Oct 2011 09:43:30 -0400 From: Scott Kitterman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: domainrep@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 26 Oct 2011 13:43:32 -0000 On 10/26/2011 08:45 AM, Murray S. Kucherawy wrote: > So if I give you a reputation of X with "IDENTITY: SPF", I'm saying > that's the reputation of X when you're talking about the domain that > SPF validated. If I give you a reputation of X with "IDENTITY: > RFC5321.MAILFROM", then I'm talking about that domain when used in > the envelope regardless of what SPF said about it. > > In that sense, the distinction is necessary. It would be interesting to do an evaluation of if it really is necessary. At some level (and I know I'm generalizing here) both DKIM validation and SPF pass results output a domain that the domain owner have given some level of authorization to. I don't think it's at all clear that this distinction makes enough difference to be worth the complexity associated with maintaining multiple types of identity. Because they have different failure mechanisms, the reverse is not necessarily true, but for messages that successfully validate/pass, I'm not at all convinced we should care through what mechanism they were validated. For just SPF/DKIM, it probably scales, but if you look beyond that, particularly outside the email world, there are a lot of possibilities. If we can fold IDENTITY: $METHOD down to just IDENTITY (where $METHOD is whatever is good enough so we don't need to distinguish) then a lot of complexity can be avoided. Scott K From johnl@iecc.com Thu Oct 27 05:03:34 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 7F8C921F8A97 for ; Thu, 27 Oct 2011 05:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.423 X-Spam-Level: X-Spam-Status: No, score=-109.423 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_05=-1.11, 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 UezzOPXF8M76 for ; Thu, 27 Oct 2011 05:03:34 -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 E729421F8593 for ; Thu, 27 Oct 2011 05:03:33 -0700 (PDT) Received: (qmail 35469 invoked from network); 27 Oct 2011 12:03:32 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 27 Oct 2011 12:03:32 -0000 Received: (qmail 51553 invoked from network); 27 Oct 2011 12:03:32 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 27 Oct 2011 12:03:32 -0000 Date: 27 Oct 2011 12:03:10 -0000 Message-ID: <20111027120310.26350.qmail@joyce.lan> From: "John Levine" To: domainrep@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [domainrep] Comments on drafts 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, 27 Oct 2011 12:03:34 -0000 >It sounds like the general trend is that people would like to see >(1), but would that limit adoption by reputation service providers? Seems to me the main value here would be the ability to switch data sources without reprogramming, which tells me we need (1). You can add all the local extensions you want, but for this to work there needs to be a core vocabulary which always means the same thing no matter who's saying it. R's, John From johnl@iecc.com Thu Oct 27 05:20:02 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 85EEB21F89B8 for ; Thu, 27 Oct 2011 05:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.209 X-Spam-Level: X-Spam-Status: No, score=-110.209 tagged_above=-999 required=5 tests=[AWL=0.990, 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 PD7m-jWhRLzS for ; Thu, 27 Oct 2011 05:20:02 -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 EA11521F858D for ; Thu, 27 Oct 2011 05:20:01 -0700 (PDT) Received: (qmail 40175 invoked from network); 27 Oct 2011 12:19:59 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 27 Oct 2011 12:19:59 -0000 Received: (qmail 62267 invoked from network); 27 Oct 2011 12:19:59 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 27 Oct 2011 12:19:59 -0000 Date: 27 Oct 2011 12:19:37 -0000 Message-ID: <20111027121937.30859.qmail@joyce.lan> From: "John Levine" To: domainrep@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [domainrep] RFC 5782, was I-D.*-reputation-*.01 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, 27 Oct 2011 12:20:02 -0000 >That would be the DNSBL RFC evaluation record. RFC 5782 was originally an IRTF draft. People noted that it was more appropriate for standards track, so I changed it to that. Unfortunately, the IESG has trouble dealing with anything related to spam, and it quickly became clear that it would never get approved, at least not in a usable form. So I flipped it back to the IRTF stream and ran it through that way. So I wouldn't pay much attention to whatever the evaluation record says. I suspect we'll find that we want to return more than 32 bits of results from a DNS query, so we'll use something other than an A record, but it's severely premature optimization to worry about that now. R's, John From ajs@anvilwalrusden.com Thu Oct 27 05:41:57 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 BEFAC21F85A8 for ; Thu, 27 Oct 2011 05:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 9geqmrFyGxR3 for ; Thu, 27 Oct 2011 05:41:57 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD6221F85A7 for ; Thu, 27 Oct 2011 05:41:57 -0700 (PDT) Received: from shinkuro.com (unknown [199.91.193.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A64741ECB41C for ; Thu, 27 Oct 2011 12:41:45 +0000 (UTC) Date: Thu, 27 Oct 2011 08:41:47 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20111027124146.GA46308@shinkuro.com> References: <20111026102133.GB41225@shinkuro.com> <4EA7EF3A.4070109@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EA7EF3A.4070109@dcrocker.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 27 Oct 2011 12:41:57 -0000 On Wed, Oct 26, 2011 at 01:30:02PM +0200, Dave CROCKER wrote: > But the process entirely ignored how thoroughly ingrained this > method of overloading the use of A records is in the critical > function of global email reputation list publication and use. > > In other words, the methodology has massive rough consensus IN ITS > FAVOR, demonstrated by very widespread adoption and use. Pesticide runnoff in streams also has massive rough consensus in its favour, given the frequency with which we observe people doing that. Pollution is never a problem for the polluters, or they wouldn't do it. > However, the fact that this violates a purists' sense of what should What's fun about ever mentioning anything to do with this topic in your presence, Dave, is the way you always stick completely to the point at hand and try very hard to stick to neutral language. Whatever the situation in the past, my point was not about whether A records ought to have been overloaded in the past; my point was that we have _new_ mechanisms and a _new_ sets of protocols in this case, and that therefore we should not repeat the approach used in the past, because some of us believe that approach has negative consequences for a protocol we have to maintain. I recognize that it's not a problem for the email reputation publishers, any more than the death of whole rivers of fish is a problem for the pesticide users. I still think it's a problem. A -- Andrew Sullivan ajs@anvilwalrusden.com From dotis@mail-abuse.org Thu Oct 27 18:26:30 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 18C1D11E808D for ; Thu, 27 Oct 2011 18:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 3PusJy2ETp+G for ; Thu, 27 Oct 2011 18:26:29 -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 865BC11E8073 for ; Thu, 27 Oct 2011 18:26:26 -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 04DF1308108 for ; Fri, 28 Oct 2011 01:26:25 +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 9D781A9443B for ; Fri, 28 Oct 2011 01:26:25 +0000 (UTC) Message-ID: <4EAA04C0.1060908@mail-abuse.org> Date: Thu, 27 Oct 2011 18:26:24 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: domainrep@ietf.org References: <20111026102133.GB41225@shinkuro.com> <4EA7EF3A.4070109@dcrocker.net> <20111027124146.GA46308@shinkuro.com> In-Reply-To: <20111027124146.GA46308@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 28 Oct 2011 01:26:30 -0000 On 10/27/11 5:41 AM, Andrew Sullivan wrote: > On Wed, Oct 26, 2011 at 01:30:02PM +0200, Dave CROCKER wrote: > >> But the process entirely ignored how thoroughly ingrained this >> method of overloading the use of A records is in the critical >> function of global email reputation list publication and use. >> >> In other words, the methodology has massive rough consensus IN ITS >> FAVOR, demonstrated by very widespread adoption and use. > Pesticide runnoff in streams also has massive rough consensus in its > favour, given the frequency with which we observe people doing that. > Pollution is never a problem for the polluters, or they wouldn't do > it. > >> However, the fact that this violates a purists' sense of what should > What's fun about ever mentioning anything to do with this topic in > your presence, Dave, is the way you always stick completely to the > point at hand and try very hard to stick to neutral language. > > Whatever the situation in the past, my point was not about whether A > records ought to have been overloaded in the past; my point was that > we have _new_ mechanisms and a _new_ sets of protocols in this case, > and that therefore we should not repeat the approach used in the past, > because some of us believe that approach has negative consequences for > a protocol we have to maintain. I recognize that it's not a problem > for the email reputation publishers, any more than the death of whole > rivers of fish is a problem for the pesticide users. I still think > it's a problem. Agreed. Use of purported "Authorizations" in conjunction with reputation needs to consider the resources consumed in macro expansion of message elements and unlimited signature transactions processed by recipients. All of this in conjunction with efforts aimed at allowing a level of abuse that unvaryingly forgives the largest domains and is unable to protect other domain reputation's from being poisoned. IP address authorization is potentially damaging for DNS by expecting this protocol to resolve all IPv4 and IPv6 hosts for globally recognized domains in a manner that may not be cachable. In addition to this burden with its potential for network amplification, DKIM also expects recipients to process an indeterminate number of invalid and valid signatures from otherwise unknown sources. IP address authorization is also potentially damaging for SMTP when used in conjunction with shared resources without conventions protecting these authorizations. How can a sender protect themselves or assure delivery when their recipients view them through a LSNs? Does this mean RFC6333, RFC5969, LSNs, or shared MTAs can not be used to exchange email? DKIM is equally bad in this regard, as it offers no validation of a domain being accountable for reported abuse. DKIM only confirms some message content had been seen by a domain, but allows abuse by unknown actors and therefore permits accountability to be refuted. This WG has the cart before the horse. Reputation MUST use scalable protocols that base reputation ONLY on AUTHENTICATED identities. Being able to authenticate MTAs largely supplants a need to rate unknown domains or known domains guilty of prior abuse. SMTP could utilize a Kerberos protocol as an introduction method, perhaps offered by trustworthy third parties. By adding authentication, SMTP itself is likely to experience a substantial reduction where only tickets are processed without increased loads on SMTP, DNS, or other protocols. -Doug From dhc@dcrocker.net Thu Oct 27 20:14: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 54E5A1F0C52 for ; Thu, 27 Oct 2011 20:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 g5VbLOGF5NIt for ; Thu, 27 Oct 2011 20:13:59 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A6DCB1F0C42 for ; Thu, 27 Oct 2011 20:13:59 -0700 (PDT) Received: from [10.115.193.62] (62-50-227-5.client.stsn.net [62.50.227.5]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p9S3Dmvw009400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Oct 2011 20:13:57 -0700 Message-ID: <4EAA1DE7.7090608@dcrocker.net> Date: Fri, 28 Oct 2011 05:13:43 +0200 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andrew Sullivan References: <20111026102133.GB41225@shinkuro.com> <4EA7EF3A.4070109@dcrocker.net> <20111027124146.GA46308@shinkuro.com> In-Reply-To: <20111027124146.GA46308@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]); Thu, 27 Oct 2011 20:13:58 -0700 (PDT) Cc: domainrep@ietf.org Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 28 Oct 2011 03:14:00 -0000 Andrew, On 10/27/2011 2:41 PM, Andrew Sullivan wrote: > On Wed, Oct 26, 2011 at 01:30:02PM +0200, Dave CROCKER wrote: > >> But the process entirely ignored how thoroughly ingrained this >> method of overloading the use of A records is in the critical >> function of global email reputation list publication and use. >> >> In other words, the methodology has massive rough consensus IN ITS >> FAVOR, demonstrated by very widespread adoption and use. > > Pesticide runnoff in streams also has massive rough consensus in its > favour, given the frequency with which we observe people doing that. > Pollution is never a problem for the polluters, or they wouldn't do > it. Please provide empirical data that the widespread and essential practice of IP Address black lists, using A records, has a systems effect equivalent to the environmental impact of pesticide runoff. For that matter, please show /any/ negative consequences other than offense to the sensibilities of purists. Invoking inflammatory parallels imposes an obligation to justify the flames. >> However, the fact that this violates a purists' sense of what should > > What's fun about ever mentioning anything to do with this topic in > your presence, Dave, is the way you always stick completely to the > point at hand and try very hard to stick to neutral language. Thanks for noting that point. Most people would miss the truth of it, here, and think that you were instead intending the comment as an ad hominem dismissive, of the type usually considered inappropriate on IETF mailing lists. Of course, the label 'purists' is unpleasant and does carry some risk of eliciting overreaction from folks claiming to have substantive concerns. Would that they demonstrated the substance. > Whatever the situation in the past, my point was not about whether A > records ought to have been overloaded in the past; my point was that > we have _new_ mechanisms and a _new_ sets of protocols in this case, Indeed we do, which was why your citing a concern about A records was so puzzling, since I missed the part of the new work that proposes using A records. Such a proposal would, after all, be the only reason for referencing this controversial issue (as long as we are citing the challenge of staying on topic...) Otherwise it would be a case of admonishing folks not to do something that they aren't doing and have given no indication of intending to do, and where's the constructive point in doing /that/? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@resistor.net Thu Oct 27 20: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 4E3611F0C5C for ; Thu, 27 Oct 2011 20:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 hchlQxCfaYuh for ; Thu, 27 Oct 2011 20:29:04 -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 3EAA61F0C42 for ; Thu, 27 Oct 2011 20:29:04 -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 p9S3Ste9016480; Thu, 27 Oct 2011 20:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1319772541; bh=C2sLoA1buYbKXtetJWhKG/R2YE0umQCmoL0eaitMZKU=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=rkGhm3Y76TZ8GbZk9Cq+Uan3X6TQTjtDzp9lGQLtdgPYVu6fvwOLPzo93Mxc+n7Bb octLT8zLxyzX6IN/uPiFEAcC8bIZMNyGYPZ6Ln6ZLiRhI9UYOFZYltUBpW/P29Xb+A aBCmaEBY5/zYVk2ih1dvO5AloWGnN7gF4yp0JAPs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1319772541; bh=C2sLoA1buYbKXtetJWhKG/R2YE0umQCmoL0eaitMZKU=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=Ike/5/1BVxeEM5fXXsPm6/27wghP0qqpRPDHneiUQXPi/sWXkoH5Otm6L64QKCDNR 8X4vf1D+9trZ86ahbm5M2bpD0L/8nt3YK3QjWmnGgeNiJukBVMHXV573+cHVaprrZh tmA/Umt9MCL+/bGfIksZ3PZhLNiH2bJU1Sixdsjo= Message-Id: <6.2.5.6.2.20111027200648.0b5b9a68@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 27 Oct 2011 20:18:30 -0700 To: Andrew Sullivan From: SM In-Reply-To: <20111026102133.GB41225@shinkuro.com> References: <20111026102133.GB41225@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: domainrep@ietf.org Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 28 Oct 2011 03:29:07 -0000 Hi Andrew, At 03:21 26-10-2011, Andrew Sullivan wrote: >Even if the IESG hadn't made remarks about this, I think you'd find a >certain part of the community screaming in pain if people tried to >recycle the DNSBL mechanism for a new service. Repurposing a DNS A RR is going to be controversial. BTW, overloading DNS TXT RRs can lead to "incorrect" answers. Regards, -sm From johnl@iecc.com Sat Oct 29 04:35:24 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 4202E21F853E for ; Sat, 29 Oct 2011 04:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 rf2uHzwRCLi6 for ; Sat, 29 Oct 2011 04:35:23 -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 7765121F851F for ; Sat, 29 Oct 2011 04:35:23 -0700 (PDT) Received: (qmail 71380 invoked from network); 29 Oct 2011 11:35:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:vbr-info:user-agent:cleverness; s=116d1.4eabe4f9.k1110; bh=eNFACYqQ8UgEYggtDKV4/hrot69fIozOT6huvihUVpY=; b=AGjcNBIWMn67u1+kt2WRSqd4z5WFWD4kypZYnib0fnq8+oLmVl7S0BKmZl1GFdEGyZ1mVEdEs5++KxsCoGXs41BWSKdYUMemwHg2cS+BU6ouTZT3rvk2KFrOLKbRjh3kg5z6kVBMajmfveKgWDQZYdgNio83LauwTcDPElc4zQs= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 29 Oct 2011 11:34:59 -0000 Date: 29 Oct 2011 07:35:21 -0400 Message-ID: From: "John R. Levine" To: domainrep@ietf.org User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [domainrep] reusing A records, was I-D.*-reputation-*.01 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: Sat, 29 Oct 2011 11:35:24 -0000 >For that matter, please show /any/ negative consequences other than >offense to the sensibilities of purists. There's the well known problem that abandoned DNSBLs are often reregistered by speculators who install a wildcard A record, thereby making the former DNSBL appear to list the world. One can argue that this is a self-inflicted wound by people who outsource their mail management to strangers and don't check what the strangers are doing, but it's certainly the case that if DNSBLs had used a different RR type, this particular problem wouldn't occur. Given the practical difficulty in adding new RR types to real world DNS software, I happen to agree that using A records was a reasonable choice. In the as yet hypothetical world where adding new RR types is easy, they should have used a different RR type, but we don't live there. I also agree with Andrew (who I talked to at the airport this morning) that using A records for non-address data is fragile, since A wildcards are so common. Although it's still a hack, it'd be a lot less fragile to use TXT records with a known tag at the begining of each record, R's, John From nsb@guppylake.com Sun Oct 30 12:59: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 07D9521F8B50 for ; Sun, 30 Oct 2011 12:59:10 -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 cRm8QmAN8X0Q for ; Sun, 30 Oct 2011 12:59:09 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE5D21F8B4E for ; Sun, 30 Oct 2011 12:59:08 -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=NRjWcSKrOznLgH5VN5HJv7lySIINfq7ExTwUnC5f5puNlMbpebbHE0ddcfHS2SDuR9PjArZUA/FkMuipXUdrfkXpd1xaOL+OEgM6vTEoLaNfFY6xEVlneArUovr9XoKQ; Received: from c-24-12-205-52.hsd1.il.comcast.net ([24.12.205.52] helo=[192.168.1.7]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1RKbXA-0007pE-2y; Sun, 30 Oct 2011 15:59:08 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-233-247645409 From: Nathaniel Borenstein In-Reply-To: <20111025120447.5155ba24@hydrogen.roaringpenguin.com> Date: Sun, 30 Oct 2011 14:59:05 -0500 Message-Id: References: <20111025120447.5155ba24@hydrogen.roaringpenguin.com> To: David F. Skoll 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] Comments on drafts 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: Sun, 30 Oct 2011 19:59:10 -0000 --Apple-Mail-233-247645409 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 25, 2011, at 11:04 AM, David F. Skoll wrote: > What is the rating and data-point number for SENDS-SPAM? > I would say the rating should be 0.833 and the data points should be = 1200. > But it needs to be made clear that the number of data points = considered should > only include those data points specifically indicating an assertion or = the > negative of that assertion. Saying "the number of data points = underlying > that score" isn't sufficiently clear, IMO. This is a good point. Would it be sufficient to change that to "the = number of data points used to compute that score?" -- nsb --Apple-Mail-233-247645409 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
What is the = rating and data-point number for SENDS-SPAM?
I would say the rating = should be 0.833 and the data points should be 1200.
But it needs to = be made clear that the number of data points considered should
only = include those data points specifically indicating an assertion or = the
negative of that assertion.  Saying "the number of data = points underlying
that score" isn't sufficiently clear, = IMO.

This is a good point.  Would = it be sufficient to change that to "the number of data points used to = compute that score?" -- nsb

= --Apple-Mail-233-247645409-- From nsb@guppylake.com Sun Oct 30 12:59:13 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 1ACA221F8B56 for ; Sun, 30 Oct 2011 12:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 WloWj92ab2mW for ; Sun, 30 Oct 2011 12:59:12 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id 970A421F8B55 for ; Sun, 30 Oct 2011 12:59:12 -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:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=u1dZh9RHt2U2RJfTGbU0yr5kWGrjj9mpEbZvspOqjK2OtL0VjWhWBoW+sfzhJ+uWUpcJi7SpfCHFVtyWiHxL3YJespPBuCMwcLOw2vKtO4UofWlQiuRz6ypRRGXmKSFf; Received: from c-24-12-205-52.hsd1.il.comcast.net ([24.12.205.52] helo=[192.168.1.7]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1RKbXE-0007pE-4h; Sun, 30 Oct 2011 15:59:12 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: Date: Sun, 30 Oct 2011 14:59:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <147F7F0A-E5D4-40E3-A3B2-50DC2617F7F8@guppylake.com> References: <20111025120447.5155ba24@hydrogen.roaringpenguin.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] Comments on draft-kucherawy-reputation-vocab-identity 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: Sun, 30 Oct 2011 19:59:13 -0000 On Oct 26, 2011, at 3:41 AM, Murray S. Kucherawy wrote: >> 2) All of the assertions are for "bad" behavior. Should there not be >> SENDS-HAM and SENDS-TO-VALID-RECIPIENT assertions? Or is that = implicit >> in the numerical value and sample size? >=20 > That's something we've discussed, especially in the BoF I think, but = isn't reflected in the draft yet. The range of assertions is currently = defined as being in the range [0, 1], meaning you disagree (0) or agree = (1) with the assertion to varying degrees. But we also considered [-1, = 1], which as I recall means disagree (0), agree (1), or assert the = opposite of (-1) what's being stated in the reply. >=20 > Maybe it's time to have that conversation now so that it's on the = record. >=20 > What say you all? My thinking on this one has been changing a bit. I'm afraid that if we = aren't careful, we'll make it too easy to create nonsense answers, e.g. = giving me a high score as both a good guy and a bad guy. If you make it = too easy to do something stupid, people will. So it would be nice to = define the vocabulary in such a way that there were no nonsense-enabling = redundancies; a -1 to 1 spectrum might make that clearer. -- nsb From nsb@guppylake.com Sun Oct 30 13:42: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 B13BE21F8B98 for ; Sun, 30 Oct 2011 13:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.309, 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 oVmw7gesaWCp for ; Sun, 30 Oct 2011 13:42:31 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id 02BCF21F8B7A for ; Sun, 30 Oct 2011 13:42:31 -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=I9/XUA+aR+ets7xyuC0EIimEzeJg8+TKERoCUD/6znXqXARARHrG7vZzKmlG44wNvR78DEQZQiBkFE3foClVKecnfv9TqpWhCoVwc7Fhjt3oJSMH8d3c7Tgnjl2t3gkI; Received: from c-24-12-205-52.hsd1.il.comcast.net ([24.12.205.52] helo=[192.168.1.7]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1RKbXK-0007pE-2Y; Sun, 30 Oct 2011 15:59:18 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-234-247657263 From: Nathaniel Borenstein In-Reply-To: <4EAA04C0.1060908@mail-abuse.org> Date: Sun, 30 Oct 2011 14:59:17 -0500 Message-Id: <5DBB63E2-1E60-48DA-B5D8-6CE55AD2C2C7@guppylake.com> References: <20111026102133.GB41225@shinkuro.com> <4EA7EF3A.4070109@dcrocker.net> <20111027124146.GA46308@shinkuro.com> <4EAA04C0.1060908@mail-abuse.org> To: Douglas Otis 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] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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: Sun, 30 Oct 2011 20:42:31 -0000 --Apple-Mail-234-247657263 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 27, 2011, at 8:26 PM, Douglas Otis wrote: > This WG has the cart before the horse. Reputation MUST use scalable = protocols that base reputation ONLY on AUTHENTICATED identities. I have to disagree, because in principle I don't believe there is such a = thing as an authenticated identity. There are only identities for which = certain kinds of more or less compelling evidence of proof = (authentication) has been provided. With enough supercomputers, I can = break many kinds of cryptographic authentication, while for other = purposes very weak authentication suffices. Is an SPF-verified identity = authenticated? DKIM? PGP? What if I write an AI program that = identifies your writing style with the reliability of a voiceprint? By analogy, DNA is stronger evidence than fingerprints, which are = stronger evidence than eyewitness identification, and yet we often trust = the latter anyway. What matters is knowing what kind of authentication, if any, is = available regarding an identity. If people then differ in which = authentication techniques they trust more or less, that's not our = problem. -- nsb --Apple-Mail-234-247657263 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
This WG has = the cart before the horse.  Reputation MUST use scalable protocols = that base reputation ONLY on AUTHENTICATED = identities.

I have to disagree, = because in principle I don't believe there is such a thing as an = authenticated identity.  There are only identities for which = certain kinds of more or less compelling evidence of proof = (authentication) has been provided.   With enough supercomputers, I = can break many kinds of cryptographic authentication, while for other = purposes very weak authentication suffices.  Is an SPF-verified = identity authenticated?  DKIM?  PGP?  What if I write an = AI program that identifies your writing style with the reliability of a = voiceprint?

By analogy, DNA is stronger = evidence than fingerprints, which are stronger evidence than eyewitness = identification, and yet we often trust the latter = anyway.

What matters is knowing what kind of = authentication, if any, is available regarding an identity.  If = people then differ  in which authentication techniques they trust = more or less, that's not our problem.  -- = nsb

= --Apple-Mail-234-247657263-- From msk@cloudmark.com Sun Oct 30 15:03: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 CD30B21F8BB1 for ; Sun, 30 Oct 2011 15:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.271 X-Spam-Level: X-Spam-Status: No, score=-103.271 tagged_above=-999 required=5 tests=[AWL=0.327, 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 kuGMpXLo37mG for ; Sun, 30 Oct 2011 15:03:45 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFC921F8BB6 for ; Sun, 30 Oct 2011 15:03:45 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sun, 30 Oct 2011 15:03:45 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Sun, 30 Oct 2011 15:03:45 -0700 Thread-Topic: [domainrep] Comments on drafts Thread-Index: AcyXPmqhp0iNsYBQQuCPCRDGJCfE6gAEVHJA Message-ID: References: <20111025120447.5155ba24@hydrogen.roaringpenguin.com> In-Reply-To: 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_F5833273385BB34F99288B3648C4F06F19C6C14D4DEXCHC2corpclo_" MIME-Version: 1.0 Subject: Re: [domainrep] Comments on drafts 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: Sun, 30 Oct 2011 22:03:46 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C14D4DEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think that's how I've been using that value. I can tweak the definition = accordingly in the next version. From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On Beh= alf Of Nathaniel Borenstein Sent: Sunday, October 30, 2011 12:59 PM To: David F. Skoll Cc: domainrep@ietf.org Subject: Re: [domainrep] Comments on drafts On Oct 25, 2011, at 11:04 AM, David F. Skoll wrote: What is the rating and data-point number for SENDS-SPAM? I would say the rating should be 0.833 and the data points should be 1200. But it needs to be made clear that the number of data points considered sho= uld only include those data points specifically indicating an assertion or the negative of that assertion. Saying "the number of data points underlying that score" isn't sufficiently clear, IMO. This is a good point. Would it be sufficient to change that to "the number= of data points used to compute that score?" -- nsb --_000_F5833273385BB34F99288B3648C4F06F19C6C14D4DEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think that’s how I’ve been using that value. = I can tweak the definition accordingly in the next version.

 

From: domainrep-bounces@ietf.org [mailto:doma= inrep-bounces@ietf.org] On Behalf Of Nathaniel Borenstein
Sent= : Sunday, October 30, 2011 12:59 PM
To: David F. Skoll
= Cc: domainrep@ietf.org
Subject: Re: [domainrep] Comments on d= rafts

 

On Oct 25, 2011, at 11:04 AM, David F.= Skoll wrote:



<= /p>

What is the rating and da= ta-point number for SENDS-SPAM?
= I would say the rating should be 0.833 and the data points should be 1200.<= /span>
But it needs to be made clear that= the number of data points considered should
only include those data points specifically indicating an assert= ion or the
negative of that assert= ion.  Saying "the number of data points underlying
that score" isn't sufficiently clear, IMO.<= /span>

 

This is a good point.  Would it be sufficie= nt to change that to "the number of data points used to compute that s= core?" -- nsb

 = ;

= --_000_F5833273385BB34F99288B3648C4F06F19C6C14D4DEXCHC2corpclo_-- From johnl@iecc.com Sun Oct 30 18:29: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 CBED621F851F for ; Sun, 30 Oct 2011 18:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.429 X-Spam-Level: X-Spam-Status: No, score=-110.429 tagged_above=-999 required=5 tests=[AWL=0.770, 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 hX+FwvmYoUV2 for ; Sun, 30 Oct 2011 18:29:53 -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 275D021F8508 for ; Sun, 30 Oct 2011 18:29:52 -0700 (PDT) Received: (qmail 25997 invoked from network); 31 Oct 2011 01:29:51 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 31 Oct 2011 01:29:51 -0000 Received: (qmail 53589 invoked from network); 31 Oct 2011 01:29:51 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 31 Oct 2011 01:29:51 -0000 Date: 31 Oct 2011 01:29:29 -0000 Message-ID: <20111031012929.44531.qmail@joyce.lan> From: "John Levine" To: domainrep@ietf.org In-Reply-To: <5DBB63E2-1E60-48DA-B5D8-6CE55AD2C2C7@guppylake.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 31 Oct 2011 01:29:53 -0000 >base reputation ONLY on AUTHENTICATED identities. > I have to disagree, because in principle I don't believe there is >such a thing as an authenticated identity. We may have a terminology difference here. In this context, an authenticated identity is one that's been validated by an external authority, e.g., a domain in a DKIM signature that has a matching key in the DNS, as opposed to a domain in an address on the From: line of a message. We can have a separate argument about how much to worry about various ways a bad guy might sneak unusually false information into the DNS or wherever the validation info lives. R's, John From johnl@iecc.com Sun Oct 30 18:34:13 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 117B721F867F for ; Sun, 30 Oct 2011 18:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.506 X-Spam-Level: X-Spam-Status: No, score=-110.506 tagged_above=-999 required=5 tests=[AWL=0.693, 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 p8Tt-zIDdKNB for ; Sun, 30 Oct 2011 18:34:12 -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 6DB2221F85DB for ; Sun, 30 Oct 2011 18:34:12 -0700 (PDT) Received: (qmail 26727 invoked from network); 31 Oct 2011 01:34:11 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 31 Oct 2011 01:34:11 -0000 Received: (qmail 55038 invoked from network); 31 Oct 2011 01:34:11 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 31 Oct 2011 01:34:11 -0000 Date: 31 Oct 2011 01:33:49 -0000 Message-ID: <20111031013349.45732.qmail@joyce.lan> From: "John Levine" To: domainrep@ietf.org In-Reply-To: <147F7F0A-E5D4-40E3-A3B2-50DC2617F7F8@guppylake.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [domainrep] Comments on draft-kucherawy-reputation-vocab-identity 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, 31 Oct 2011 01:34:13 -0000 > My thinking on this one has been changing a bit. I'm afraid that if > we aren't careful, we'll make it too easy to create nonsense > answers, e.g. giving me a high score as both a good guy and a bad > guy. I'm pretty sure that any language that's sufficiently expressive to be interesting is sufficiently expressive to have contradictions, and no quantity of assertions can prevent that, e.g.: Is-Male: 1 Number-Of-Pregnancies: 3 Is that contradictory? Are you sure? R's, John From nsb@guppylake.com Mon Oct 31 08:08: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 46F2D21F8DF0 for ; Mon, 31 Oct 2011 08:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 vOdPJDYi9p-V for ; Mon, 31 Oct 2011 08:08:27 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCD321F8DE5 for ; Mon, 31 Oct 2011 08:08:25 -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:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=FuMeO+aUUXJYe0oMrUuw1xPLNV04msQZWwT6l8nW0HYCBQsnFl+nQ4sDIFZaRNAdHi1i2WvO7wuaa1bTqJkaDnaeuAmBA+IF6+W8HsOKc2yrsF4c9W050oiMRZpqhoAz; Received: from c-24-12-205-52.hsd1.il.comcast.net ([24.12.205.52] helo=[192.168.1.7]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1RKtTJ-0004gZ-OC; Mon, 31 Oct 2011 11:08:21 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: <20111031013349.45732.qmail@joyce.lan> Date: Mon, 31 Oct 2011 10:08:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <73A3A77D-0ECD-4B4D-9A6D-653151A4CFF4@guppylake.com> References: <20111031013349.45732.qmail@joyce.lan> To: John Levine 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] Comments on draft-kucherawy-reputation-vocab-identity 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, 31 Oct 2011 15:08:28 -0000 Nothing's ever going to get rid of all possible ambiguities; = transsexuals could be the obvious counterexample to your question. All = I'm suggesting is that we should try to avoid encouraging gratutiously = obvious self-contradiction, such as separate scores for "is good" and = "is bad". But even that may be hopeless, I admit. I can certainly be = good sometimes and bad others... On Oct 30, 2011, at 8:33 PM, John Levine wrote: >> My thinking on this one has been changing a bit. I'm afraid that if >> we aren't careful, we'll make it too easy to create nonsense >> answers, e.g. giving me a high score as both a good guy and a bad >> guy. >=20 > I'm pretty sure that any language that's sufficiently expressive to be > interesting is sufficiently expressive to have contradictions, and no > quantity of assertions can prevent that, e.g.: >=20 > Is-Male: 1 > Number-Of-Pregnancies: 3 >=20 > Is that contradictory? Are you sure? >=20 > R's, > John >=20 >=20 From nsb@guppylake.com Mon Oct 31 08:14: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 2170921F899D for ; Mon, 31 Oct 2011 08:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 obUcSz4N1fhg for ; Mon, 31 Oct 2011 08:14:38 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id 0E99921F8B0D for ; Mon, 31 Oct 2011 08:14:38 -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:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=jXaEzL+B+lRXsGauTRVjEMwDXgEyLGiXceACY8OGlCTywI+QWEPpZwKyUupf5ZV8W4TPqk0L4aQN+D64JiKu5DiZ+N3+sGpv2REBhAH8fgFTZz/XOHyI8E52LvDKnq3c; Received: from c-24-12-205-52.hsd1.il.comcast.net ([24.12.205.52] helo=[192.168.1.7]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1RKtZM-0006kS-WE; Mon, 31 Oct 2011 11:14:37 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: <20111031012929.44531.qmail@joyce.lan> Date: Mon, 31 Oct 2011 10:14:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111031012929.44531.qmail@joyce.lan> To: John Levine 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] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 31 Oct 2011 15:14:39 -0000 I can live with this if the definition of "external authority" is pretty = broad. If, for example, the lower level network software tells me that = a packet comes from a given IP address, I'd contend that an external = authority (sort of the aggregate of the transport-layer stack) has = "authenticated" a network address. And if there's a guy with a Ouija = board telling me that a message really came from user X, I'd say it has = been authenticated by a guy with a Ouija board. That doesn't mean I = necessarily believe either of them, but it means I have a basis for = comparing multiple pieces of data of similarly authenticated provenance. If DKIM authentication says a message came from x@y, but a dozen = eyewitnesses saw it typed by a@b as part of a demonstration of how he = contends he can fool DKIM, I'd contend that both contentions are = authenticated in different ways, and that we have to decide which type = of authentication we trust more. -- Nathaniel On Oct 30, 2011, at 8:29 PM, John Levine wrote: >> base reputation ONLY on AUTHENTICATED identities. >=20 >> I have to disagree, because in principle I don't believe there is >> such a thing as an authenticated identity. >=20 > We may have a terminology difference here. In this context, an > authenticated identity is one that's been validated by an external > authority, e.g., a domain in a DKIM signature that has a matching key > in the DNS, as opposed to a domain in an address on the From: line of > a message. We can have a separate argument about how much to worry > about various ways a bad guy might sneak unusually false information > into the DNS or wherever the validation info lives. >=20 > R's, > John >=20 >=20 >=20 >=20 From ajs@anvilwalrusden.com Mon Oct 31 08:16:19 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 933181F0C4B for ; Mon, 31 Oct 2011 08:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 QYd8BXckHfSj for ; Mon, 31 Oct 2011 08:16:18 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 96CB021F8E06 for ; Mon, 31 Oct 2011 08:16:18 -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 AC09A1ECB41D for ; Mon, 31 Oct 2011 15:16:06 +0000 (UTC) Date: Mon, 31 Oct 2011 11:16:15 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20111031151614.GD48552@shinkuro.com> References: <20111026102133.GB41225@shinkuro.com> <4EA7EF3A.4070109@dcrocker.net> <20111027124146.GA46308@shinkuro.com> <4EAA1DE7.7090608@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EAA1DE7.7090608@dcrocker.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 31 Oct 2011 15:16:19 -0000 I've modified the order of Dave's original mail, because only part of it is directly relevant to the list. On Fri, Oct 28, 2011 at 05:13:43AM +0200, Dave CROCKER wrote: > Indeed we do, which was why your citing a concern about A records > was so puzzling, since I missed the part of the new work that > proposes using A records. > > Such a proposal would, after all, be the only reason for referencing > this controversial issue (as long as we are citing the challenge of > staying on topic...) > You posted in the very thread where Frank Ellerman appeared to be arguing in favour of recycling this mechanism. And indeed, Murray's response to that was what I was trying to emphasise. The thread starts here: . All I was trying to say is that, regardless of what the IESG had said, there are good DNS protocol reasons not to use a similar mechanism for new work. That's why my message said, ". . .if people tried to recycle the DNSBL mechanism for a new service." () It seems to me that "recycle" and "new service" are clear enough, but if not perhaps you could suggest different ways of making that point in future so that I don't end up in a similar rathole with you the next time around. I am also prepared to believe that I misread Frank Ellerman's argument, although I don't see how. If so, perhaps you could explain that to me instead of calling me names. On the wider point (those of you who don't care can tune out now): > Please provide empirical data that the widespread and essential > practice of IP Address black lists, using A records, has a systems > effect equivalent to the environmental impact of pesticide runoff. > > For that matter, please show /any/ negative consequences other than > offense to the sensibilities of purists. If you don't like the comparison to pesticide runoff, perhaps air pollution from cars will be more to your liking. Whatever analogy floats your boat, these blacklists are _still_ pollution of the DNS. First, the negative consequence is obvious: we know that there have been abandoned BLs where the domains controlling them have been abandoned. Afterwards, someone else picks them up and installs an A-record wildcard for queries to the domain referring not to some record in the 127.0.0.0 network, but to an active IP address on the network. The harm comes from the continued lookup of those records, with the concomitant (worthless) load for the rest of the DNS. That this would happen was a straightforward consequence of overloading a datatype that already had a well-defined meaning in the DNS. Second, because of the widespread deployment of DNS-based lists of this sort, protocol maintainers, protocol operators, and for that matter, address space maintainers (since the BL trick uses 127.0.0.0/8 network, providing one more way in which those unassigned addresses can't be repurposed in future) have to take into account these deployments when making future decisions. More importantly, however, you have the burden of proof wrong here. The DNS is a typed database. The A record is a type that is supposed to be used to provide IPv4 addresses. BLs overload the type to mean, instead, "IPv4 addresses or else some metainformation according to the conventions of the data provider", which is a rather gross change to the type system of the DNS, especially since there is no in-protocol way of signalling which of these two mutually-exclusive meanings the A record has. It is not the responsibility of the protocol maintainers to show that someone changing the semantics of protocol elements are doing positive harm; it is instead the responsibility of the would-be semantics-changers to show that what they are doing does not cause harm. As nearly as I can tell, the BL argument always relied on the implicit assumption, "And the data won't leak." Given the evidence we have that any such assumption on the Internet is wrong, I think the argument in favour of the overloading of DNS data types to do all this falls down. Each car on the road, or each application of pesticide, does not by itself do harm to the natural environment. It is still the responsibility of the would-be users to show that they're not going to do such harm -- because as a matter of fact the widespread use of these pollutants has caused problems, even though no particular instance itself does such harm and even though the harms were perhaps not obvious when the substances started being deployed. But all of that history is irrelevant for the point I was originally making; see the beginning of this message. > Thanks for noting that point. Most people would miss the truth of > it, here, and think that you were instead intending the comment as > an ad hominem dismissive, of the type usually considered > inappropriate on IETF mailing lists. If you're going to waive around _ad hominem_ abusives, calling people "purists", Dave, then you might expect responses in kind. But I'll say instead that pointing out that someone is calling people names instead of sticking to the point (and perhaps, noting that it is not the first time) is not an _ad hominem_. It's calling a relevance fallacy what it is: fallacious. There are in fact problems with overloading DNS data types in the way you seem to like to do. In my experience, when I point those out to you, you simply deny that there is a problem, and call me a purist. This is easy for you, because you're not the stuckee when the protocol you're supposed to be maintaining grows all sorts of hairs and warts because of this behaviour on someone else's part. I'd have thought, however, that the difficulty of producing anything like a comprehensible underscore registry, due to the many fun ways that mechanism has been used, would have illustrated to you the very point I'm making. I do not deny that the A-record hack for BLs, and the underscore hacks we have also seen, are sometimes useful; I use them myself sometimes. I also recognize, as you appear not to acknowledge, that it is in practice more difficult than we would like to deploy a new RRTYPE. But none of that changes the fundamental fact that the DNS tricks we are talking about are not terribly clean hacks. They mostly work in practice, but they break the protocol assumptions, thereby making the protocol more fragile. I would have liked to believe that, at the IETF, we already agreed that breaking a protocol's assumptions on purpose was at least not obviously ok, even if we do it sometimes. A -- Andrew Sullivan ajs@anvilwalrusden.com From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Mon Oct 31 09:27: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 AB35C21F8C2B for ; Mon, 31 Oct 2011 09:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.898 X-Spam-Level: X-Spam-Status: No, score=-102.898 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 WHeTV2mNVIH5 for ; Mon, 31 Oct 2011 09:27:01 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EEC2821F8C11 for ; Mon, 31 Oct 2011 09:27:00 -0700 (PDT) Received: by wwi36 with SMTP id 36so1129528wwi.13 for ; Mon, 31 Oct 2011 09:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HGoXTPqAVbMCm2U2YrvXNEVao1XG65M3jksH2fqz2ws=; b=EKljiIEjSBtt+PfBUMX1/itt0hiVz4d+QvwOtCi+hubrjizYDpVYKtw2VAAuz8uB77 rhMq+E5lkb4aGQgzcED6GKHShehsfV2e5rCCSmlgKZrdr0L+xL+UkKaYPBaILR/pFjRn VeLyfRX9J4XehkSzqLx83nnr0emMx1NxY1yBE= Received: by 10.216.88.72 with SMTP id z50mr3346006wee.81.1320078420095; Mon, 31 Oct 2011 09:27:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.80.134 with HTTP; Mon, 31 Oct 2011 09:26:19 -0700 (PDT) In-Reply-To: <20111031151614.GD48552@shinkuro.com> References: <20111026102133.GB41225@shinkuro.com> <4EA7EF3A.4070109@dcrocker.net> <20111027124146.GA46308@shinkuro.com> <4EAA1DE7.7090608@dcrocker.net> <20111031151614.GD48552@shinkuro.com> From: Frank Ellermann Date: Mon, 31 Oct 2011 17:26:19 +0100 Message-ID: To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Cc: domainrep@ietf.org Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 31 Oct 2011 16:27:01 -0000 On 31 October 2011 16:16, Andrew Sullivan wrote: > there are good DNS protocol reasons not to use a > similar mechanism for new work. IMHO the known issues with the 127.0.0.2/8 hack are addressed in the two ASRG RFCs. And it's perfectly fine if REPUTE uses other and/or better mechanisms for its purposes. I didn't look into I-D.irtf-asrg-iar-howe-siq-03 for some years, it didn't suggest DNSBLs. (@Murray: If you didn't know it check it out, there are some similarities with your I-Ds). > I am also prepared to believe that I misread Frank > Ellerman's argument No, but we can dismiss it as irrelevant for the work here, because 2*8+7 bits are apparently never enough for REPUTE, and besides it's not the time to discuss "encoding optimizations", as noted by Dave and John. > there have been abandoned BLs where the domains > controlling them have been abandoned. Yes, on the client side that's addressed by two test queries, one test resulting in a conventional LISTED reply, and another test never resulting in LISTED. If clients use these tests they can detect most silly states (DNSBL down or DNSBL listing the world), and stop to waste bandwidth for pointless DNS queries. Some of the recommendations for DNSBL providers might be also interesting for whatever REPUTE will suggest: "Listing the world" only to get rid of clients still trying to use a long dead service is not funny, no matter how these queries are implemented (DNSBL, SIQ, WHOIS UDP/TCP, HTTP, whatever). -Frank From johnl@iecc.com Mon Oct 31 09:32: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 DD4BC21F8DA0 for ; Mon, 31 Oct 2011 09:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 wQUJqVzeQoPZ for ; Mon, 31 Oct 2011 09:32:28 -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 242BF21F8D9D for ; Mon, 31 Oct 2011 09:32:27 -0700 (PDT) Received: (qmail 50237 invoked from network); 31 Oct 2011 16:32:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=c43c.4eaecd9a.k1110; bh=a/0RU8POzoAlvfs/Dy+XzcpNpesgSuQXZgWgdOmNxv0=; b=XTo+ASi+XvWJXeosAG3Ya4EmJ/B2D+L4B/iZwTr2946qa0TjSu1y3eeqCxvQbTXcvv24WqFsjMfDREETdc7l0KOirFBNa6R58oe2VOl0kcYH1aR+jxv7sEXPvnLFcby9F95K9wX2o7c1tO1Dr/UZs1viQKLYmRMwsZFv5DEStuk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 31 Oct 2011 16:32:04 -0000 Date: 31 Oct 2011 12:32:26 -0400 Message-ID: From: "John R. Levine" To: "Nathaniel Borenstein" In-Reply-To: References: <20111031012929.44531.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: domainrep@ietf.org Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 31 Oct 2011 16:32:29 -0000 On Mon, 31 Oct 2011, Nathaniel Borenstein wrote: > I can live with this if the definition of "external authority" is >pretty broad. If, for example, the lower level network software >tells me that a packet comes from a given IP address, I'd contend >that an external authority (sort of the aggregate of the >transport-layer stack) has "authenticated" a network address. ... I think we generally agree, although I'd consider an IP address from a TCP session more authenticated than one from a single UDP packet. There's a swamp of how credible an authenticator is, but I think we can get by with an arbitrary division between authenticated meaning hard to fake, and unauthenticated meaning easy to fake. > If DKIM authentication says a message came from x@y, ... Please report immediately for self-criticism and re-education. DKIM doesn't do that. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From msk@cloudmark.com Mon Oct 31 13:11: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 4251521F8DE2 for ; Mon, 31 Oct 2011 13:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.781 X-Spam-Level: X-Spam-Status: No, score=-102.781 tagged_above=-999 required=5 tests=[AWL=-0.182, 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 vCFwq8T8bHve for ; Mon, 31 Oct 2011 13:11:31 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id D866721F8DDD for ; Mon, 31 Oct 2011 13:11:30 -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, 31 Oct 2011 13:11:11 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Mon, 31 Oct 2011 13:11:13 -0700 Thread-Topic: [domainrep] Comments on draft-kucherawy-reputation-vocab-identity Thread-Index: AcyXPmuGdnLjy0iNRai4H6UkRZW4agAyfhyQ Message-ID: References: <20111025120447.5155ba24@hydrogen.roaringpenguin.com> <147F7F0A-E5D4-40E3-A3B2-50DC2617F7F8@guppylake.com> In-Reply-To: <147F7F0A-E5D4-40E3-A3B2-50DC2617F7F8@guppylake.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] Comments on draft-kucherawy-reputation-vocab-identity 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, 31 Oct 2011 20:11:33 -0000 > -----Original Message----- > From: Nathaniel Borenstein [mailto:nsb@guppylake.com] > Sent: Sunday, October 30, 2011 12:59 PM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] Comments on draft-kucherawy-reputation-vocab-ide= ntity >=20 > > That's something we've discussed, especially in the BoF I think, but > > isn't reflected in the draft yet. The range of assertions is currently > > defined as being in the range [0, 1], meaning you disagree (0) or agree > > (1) with the assertion to varying degrees. But we also considered [-1, > > 1], which as I recall means disagree (0), agree (1), or assert the > > opposite of (-1) what's being stated in the reply. > > > > Maybe it's time to have that conversation now so that it's on the > > record. > > > > What say you all? >=20 > My thinking on this one has been changing a bit. I'm afraid that if we > aren't careful, we'll make it too easy to create nonsense answers, e.g. > giving me a high score as both a good guy and a bad guy. If you make > it too easy to do something stupid, people will. So it would be nice > to define the vocabulary in such a way that there were no nonsense- > enabling redundancies; a -1 to 1 spectrum might make that clearer. -- > nsb I'm happy to go with consensus on this point, but I've been unable to formu= late text to support it though I've been trying for days. If we say that, for any given assertion, "1" means full agreement and "-1" = actually asserts the opposite, then what does "0" mean? For example, let's= say "1" is SENDS-SPAM, and "-1" is thus SENDS-HAM. What does "0" mean her= e? If we say it means "sends some spam and some ham" then I'd say [-1, 1] is t= he same as [0, 1] only at double the scale, and furthermore the meaning of = "0" is not intuitive (because it could also mean "I have no idea"). If we = say it means "sends neither" then I suggest that's non-linear; if "1" means= "sends mostly spam" and "-1" means "sends mostly ham" then the scale isn't= linear anymore. I couldn't come up with an example assertion that has an opposite for which= [-1, 1] made sense when also considering the meaning of 0. Does someone e= lse have one? -MSK From msk@cloudmark.com Mon Oct 31 13:13:58 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 5C71311E8155 for ; Mon, 31 Oct 2011 13:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.779 X-Spam-Level: X-Spam-Status: No, score=-102.779 tagged_above=-999 required=5 tests=[AWL=-0.180, 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 tS6BEUlUKCan for ; Mon, 31 Oct 2011 13:13:58 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 02B6B11E80C1 for ; Mon, 31 Oct 2011 13:13:58 -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, 31 Oct 2011 13:13:57 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Mon, 31 Oct 2011 13:13:59 -0700 Thread-Topic: [domainrep] Comments on drafts Thread-Index: AcyUoHc77GZzx4MPTtOqmeo9xP9usADaNewg Message-ID: References: <20111027120310.26350.qmail@joyce.lan> In-Reply-To: <20111027120310.26350.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [domainrep] Comments on drafts 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, 31 Oct 2011 20:13:58 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQGllY2MuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyNywgMjAxMSA1OjAz IEFNDQo+IFRvOiBkb21haW5yZXBAaWV0Zi5vcmcNCj4gQ2M6IE11cnJheSBTLiBLdWNoZXJhd3kN Cj4gU3ViamVjdDogUmU6IFtkb21haW5yZXBdIENvbW1lbnRzIG9uIGRyYWZ0cw0KPiANCj4gPkl0 IHNvdW5kcyBsaWtlIHRoZSBnZW5lcmFsIHRyZW5kIGlzIHRoYXQgcGVvcGxlIHdvdWxkIGxpa2Ug dG8gc2VlDQo+ID4oMSksIGJ1dCB3b3VsZCB0aGF0IGxpbWl0IGFkb3B0aW9uIGJ5IHJlcHV0YXRp b24gc2VydmljZSBwcm92aWRlcnM/DQo+IA0KPiBTZWVtcyB0byBtZSB0aGUgbWFpbiB2YWx1ZSBo ZXJlIHdvdWxkIGJlIHRoZSBhYmlsaXR5IHRvIHN3aXRjaCBkYXRhDQo+IHNvdXJjZXMgd2l0aG91 dCByZXByb2dyYW1taW5nLCB3aGljaCB0ZWxscyBtZSB3ZSBuZWVkICgxKS4NCj4gDQo+IFlvdSBj YW4gYWRkIGFsbCB0aGUgbG9jYWwgZXh0ZW5zaW9ucyB5b3Ugd2FudCwgYnV0IGZvciB0aGlzIHRv IHdvcmsgdGhlcmUNCj4gbmVlZHMgdG8gYmUgYSBjb3JlIHZvY2FidWxhcnkgd2hpY2ggYWx3YXlz IG1lYW5zIHRoZSBzYW1lIHRoaW5nIG5vIG1hdHRlcg0KPiB3aG8ncyBzYXlpbmcgaXQuDQoNClNv IHRoaXMgbWVhbnMgdGhlIHJlZ2lzdHJhdGlvbiBmb3IgYXNzZXJ0aW9ucyB3aXRoaW4gYW4gYXBw bGljYXRpb24gbmVlZHMgdG8gZGVmaW5lIHdoYXQgMCBhbmQgMSBib3RoIG1lYW4sIGFuZCBhbHNv IGRlZmluZSB0aGUgcmVsYXRpb25zaGlwcyBhbW9uZyB2YWx1ZXMgaW4gYmV0d2Vlbi4gIEZvciBl eGFtcGxlLCBTRU5EUy1TUEFNIG1pZ2h0IGJlIGRlZmluZWQgYXMgIjAiIGRpc2FncmVlcyBjb21w bGV0ZWx5IHdpdGggdGhlIGFzc2VydGlvbiwgIjEiIGlzIGZ1bGwgYWdyZWVtZW50LCBhbmQgdmFs dWVzIGluIGJldHdlZW4gYXJlIGxpbmVhciAoZS5nLiwgIlgiIG1lYW5zICJzZW5kcyBhYm91dCB0 d2ljZSBhcyBtdWNoIHNwYW0gYXMgc29tZW9uZSB3aXRoIFgvMiIpLiAgRG9lcyB0aGF0IHNvdW5k IHJlYXNvbmFibGU/ICBJZiBzbywgSSdsbCB3cml0ZSB0aGF0IHVwLg0KDQotTVNLDQo= From dfs@roaringpenguin.com Mon Oct 31 13:19: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 4B69F21F8B39 for ; Mon, 31 Oct 2011 13:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 hhICqHiblqMR for ; Mon, 31 Oct 2011 13:19:50 -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 8AC8221F8DEE for ; Mon, 31 Oct 2011 13:19:50 -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 p9VKJnSl027380 for ; Mon, 31 Oct 2011 16:19:49 -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 p9VKJlxR029650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 31 Oct 2011 16:19:49 -0400 Date: Mon, 31 Oct 2011 16:19:46 -0400 From: "David F. Skoll" To: domainrep@ietf.org Message-ID: <20111031161946.33f4379f@hydrogen.roaringpenguin.com> In-Reply-To: References: <20111025120447.5155ba24@hydrogen.roaringpenguin.com> <147F7F0A-E5D4-40E3-A3B2-50DC2617F7F8@guppylake.com> 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=phvmwVnd2Bps /5UfYQ4j8dpJh6c=; b=clxFSR6huCdYIXobZFx/K6dM1xB/c8ahnJ1E6stH13gb xRNtq74/Ww07JfDS0FJ/JjUjVZYCGVi1JhKY91iDXF81m6GPsF5SYqoax1KoBfgw x0pBdER4wvNyR+iQoVd9Z3e9R/sY+yXrCMsqqvAiowjEhzc/EFzSDiZFRf7YG4M= 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/20111031 / 01FPwjN9k Subject: Re: [domainrep] Comments on draft-kucherawy-reputation-vocab-identity 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, 31 Oct 2011 20:19:51 -0000 On Mon, 31 Oct 2011 13:11:13 -0700 "Murray S. Kucherawy" wrote: > If we say that, for any given assertion, "1" means full agreement and > "-1" actually asserts the opposite, then what does "0" mean? For > example, let's say "1" is SENDS-SPAM, and "-1" is thus SENDS-HAM. > What does "0" mean here? It means "Sends the same amount of spam as ham". And the real meaning of "0" depends on the number of data points. So with 100 datapoints: SENDS-SPAM=1 means we've seen 100 spam, 0 ham. SENDS-SPAM=0 means we've seen 50 spam, 50 ham. SENDS-SPAM=-1 means we've seen 0 spam, 100 ham. If we define [-1, 1] to map linearly to [0, NUM-DATA-POINTS] for the events in question, then the meaning is clear. Furthermore, if NUM-DATA-POINTS is 0, then the rating MUST be 0 also. > If we say it means "sends some spam and some ham" then I'd say [-1, > 1] is the same as [0, 1] only at double the scale, and furthermore > the meaning of "0" is not intuitive (because it could also mean "I > have no idea"). "0" means "I have no idea" if NUM-DATA-POINTS is 0 or low. It's only by combining the score with the number of underlying data points that we have a good idea of how well-known the rating is. (And this is why it's important that NUM-DATA-POINTS only count events that actually support the given assertion or its negation.) Regards, David. From msk@cloudmark.com Mon Oct 31 13:20: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 9266A21F8E51 for ; Mon, 31 Oct 2011 13:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.276 X-Spam-Level: X-Spam-Status: No, score=-103.276 tagged_above=-999 required=5 tests=[AWL=0.323, 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 3PHS52fDMWUx for ; Mon, 31 Oct 2011 13:20:26 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2380821F8E3A for ; Mon, 31 Oct 2011 13:20:26 -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, 31 Oct 2011 13:20:25 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Mon, 31 Oct 2011 13:20:27 -0700 Thread-Topic: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) Thread-Index: AcyX3+jSpZ3/WBZrQ5SnnAljMfL2tQAKl8Gg Message-ID: References: <20111031012929.44531.qmail@joyce.lan> In-Reply-To: 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] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 31 Oct 2011 20:20:26 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Nathaniel Borenstein > Sent: Monday, October 31, 2011 8:15 AM > To: John Levine > Cc: domainrep@ietf.org > Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about rep= utation data meta-issues) >=20 > I can live with this if the definition of "external authority" is > pretty broad. If, for example, the lower level network software tells > me that a packet comes from a given IP address, I'd contend that an > external authority (sort of the aggregate of the transport-layer stack) > has "authenticated" a network address. And if there's a guy with a > Ouija board telling me that a message really came from user X, I'd say > it has been authenticated by a guy with a Ouija board. That doesn't > mean I necessarily believe either of them, but it means I have a basis > for comparing multiple pieces of data of similarly authenticated > provenance. > [...] This is why I put the "IDENTITY:" mechanism into the media type. It allows= the server to make clear to the client that "reputation for X is Y, provid= ed you confirmed X through mechanism Z, because that's how I came to this c= onclusion". It allows the client to confirm that apples are being compared= to apples. In my view, deciding which methods to trust, for both parties, is a matter = for those parties to decide on their own and not a topic for REPUTE to reop= en. From dfs@roaringpenguin.com Mon Oct 31 13:22:44 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 09A6911E81CD for ; Mon, 31 Oct 2011 13:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 psg6xkykN3PI for ; Mon, 31 Oct 2011 13:22:43 -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 5259711E80B4 for ; Mon, 31 Oct 2011 13:22:43 -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 p9VKMgSZ028195 for ; Mon, 31 Oct 2011 16:22:42 -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 p9VKMeF2002895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 31 Oct 2011 16:22:42 -0400 Date: Mon, 31 Oct 2011 16:22:40 -0400 From: "David F. Skoll" To: domainrep@ietf.org Message-ID: <20111031162240.6ff43c37@hydrogen.roaringpenguin.com> In-Reply-To: References: <20111027120310.26350.qmail@joyce.lan> 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=Dyw11ONOKyxT l9MBziwTcY7yG3w=; b=gW8dFvghG/16TYhy+T5Mll3urmz2/pmSx/UVs0bsZrAQ YIXPGoHGbzv1syFnbqN8a+3QPkryeWu0C94wSXpKE7TsKDUwCj1ZRocUoHbI5A84 e4gyn9A4o1RbOBM7Fw/TJJwB4Io/MoS5h1r6BgffcjAcNsMDzDbhiRkkZAuC65Q= 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/20111031 / 01FPwmG9o Subject: Re: [domainrep] Comments on drafts 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, 31 Oct 2011 20:22:44 -0000 On Mon, 31 Oct 2011 13:13:59 -0700 "Murray S. Kucherawy" wrote: > So this means the registration for assertions within an application > needs to define what 0 and 1 both mean, and also define the > relationships among values in between. For example, SENDS-SPAM might > be defined as "0" disagrees completely with the assertion, "1" is > full agreement, and values in between are linear (e.g., "X" means > "sends about twice as much spam as someone with X/2"). Hmm... that seems unworkable. I think my suggestion to map either [-1, 1] or [0, 1] linearly to [0, NUM-DATA-POINTS] is easier to implement and has a very clear meaning. If you *really* want to compare how much spam example.org and example.com send, you have both the ratings and the NUM-DATA-POINTS for each, so you can compare apples to apples (sort-of, assuming the reputation collector collects data points in proportion to the volume of email sent.) Regards, David. From msk@cloudmark.com Mon Oct 31 13:31: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 5598211E8238 for ; Mon, 31 Oct 2011 13:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.786 X-Spam-Level: X-Spam-Status: No, score=-102.786 tagged_above=-999 required=5 tests=[AWL=-0.187, 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 XhSA6BtPKyzh for ; Mon, 31 Oct 2011 13:31:18 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id EFEC711E8220 for ; Mon, 31 Oct 2011 13:31:17 -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, 31 Oct 2011 13:31:17 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Mon, 31 Oct 2011 13:31:20 -0700 Thread-Topic: [domainrep] Comments on draft-kucherawy-reputation-vocab-identity Thread-Index: AcyYCnYtFeWOameET3ud4aMJgL42hQAAUr/Q Message-ID: References: <20111025120447.5155ba24@hydrogen.roaringpenguin.com> <147F7F0A-E5D4-40E3-A3B2-50DC2617F7F8@guppylake.com> <20111031161946.33f4379f@hydrogen.roaringpenguin.com> In-Reply-To: <20111031161946.33f4379f@hydrogen.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] Comments on draft-kucherawy-reputation-vocab-identity 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, 31 Oct 2011 20:31:18 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of David F. Skoll > Sent: Monday, October 31, 2011 1:20 PM > To: domainrep@ietf.org > Subject: Re: [domainrep] Comments on draft-kucherawy-reputation-vocab- id= entity >=20 > > If we say that, for any given assertion, "1" means full agreement and > > "-1" actually asserts the opposite, then what does "0" mean? For > > example, let's say "1" is SENDS-SPAM, and "-1" is thus SENDS-HAM. > > What does "0" mean here? >=20 > It means "Sends the same amount of spam as ham". And the real meaning of > "0" depends on the number of data points. What about the case where the assertion has no opposite? For example, IS-P= URPLE. What would "-1" mean? Maybe the registration must also define the range. So: SENDS-SPAM defines the range as [-1, 1], its use is linear (see my other me= ssage), and -1 means SENDS-HAM. Meanwhile, some other thing uses [0, 1] be= cause it has no opposite, and its use is (some expression of how values com= pare). From dfs@roaringpenguin.com Mon Oct 31 13:37:56 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 65EC011E823C for ; Mon, 31 Oct 2011 13:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 lp+sJuzM1HKZ for ; Mon, 31 Oct 2011 13:37:55 -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 9C18711E8239 for ; Mon, 31 Oct 2011 13:37:55 -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 p9VKbsHd031551 for ; Mon, 31 Oct 2011 16:37:54 -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 p9VKbqX0020558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 31 Oct 2011 16:37:54 -0400 Date: Mon, 31 Oct 2011 16:37:52 -0400 From: "David F. Skoll" To: domainrep@ietf.org Message-ID: <20111031163752.0191c09f@hydrogen.roaringpenguin.com> In-Reply-To: References: <20111025120447.5155ba24@hydrogen.roaringpenguin.com> <147F7F0A-E5D4-40E3-A3B2-50DC2617F7F8@guppylake.com> <20111031161946.33f4379f@hydrogen.roaringpenguin.com> 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=iMH7+RjXFkQ9 Qb0eaOaF8Nwu4Go=; b=pbnA5UJ0AbahvdmVosgv8pjVhKKJQ2ViBxEhDp++cZi2 CGj7BIXqNRGaItIIx+RA21xllqgcHJI7XY1rwPTu2aod8RjhDODvU+C7wU+RfLp/ 8okQyK8angKl0cFc+7C25Rsm1vqS+mbsuFeV1CfwWzKl5S0jbJ6AA85AQbeIERQ= 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/20111031 / 01FPwBS9T Subject: Re: [domainrep] Comments on draft-kucherawy-reputation-vocab-identity 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, 31 Oct 2011 20:37:56 -0000 On Mon, 31 Oct 2011 13:31:20 -0700 "Murray S. Kucherawy" wrote: > What about the case where the assertion has no opposite? For > example, IS-PURPLE. What would "-1" mean? Point taken. So I guess the registration MUST define the range and SHOULD define the algorithm for converting data points to value. There should be two predefined algorithms: LINEAR [-1, 1] -> [0, NUM-DATA-POINTS] LINEAR [ 0, 1] -> [0, NUM-DATA-POINTS] Hmm... the more I think about it, the more I think the range should be [0, 1] and we should explicitly have assertions that are opposites like SENDS-HAM and SENDS-SPAM. And we shouldn't worry about contradictions. Regards, David. From msk@cloudmark.com Mon Oct 31 14:32: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 D21A51F0C91 for ; Mon, 31 Oct 2011 14:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.283 X-Spam-Level: X-Spam-Status: No, score=-103.283 tagged_above=-999 required=5 tests=[AWL=0.316, 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 nno6YK3dT94V for ; Mon, 31 Oct 2011 14:32:28 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 076AC1F0C8D for ; Mon, 31 Oct 2011 14:32:28 -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, 31 Oct 2011 14:32:27 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Mon, 31 Oct 2011 14:32:29 -0700 Thread-Topic: [domainrep] Comments on draft-kucherawy-reputation-vocab-identity Thread-Index: AcyYDPzGf2IbTlUhT0ec+1tuMHd53wABx6nw Message-ID: References: <20111025120447.5155ba24@hydrogen.roaringpenguin.com> <147F7F0A-E5D4-40E3-A3B2-50DC2617F7F8@guppylake.com> <20111031161946.33f4379f@hydrogen.roaringpenguin.com> <20111031163752.0191c09f@hydrogen.roaringpenguin.com> In-Reply-To: <20111031163752.0191c09f@hydrogen.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] Comments on draft-kucherawy-reputation-vocab-identity 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, 31 Oct 2011 21:32:29 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of David F. Skoll > Sent: Monday, October 31, 2011 1:38 PM > To: domainrep@ietf.org > Subject: Re: [domainrep] Comments on draft-kucherawy-reputation-vocab- id= entity >=20 > > What about the case where the assertion has no opposite? For > > example, IS-PURPLE. What would "-1" mean? >=20 > Point taken. So I guess the registration MUST define the range > and SHOULD define the algorithm for converting data points to value. > There should be two predefined algorithms: >=20 > LINEAR [-1, 1] -> [0, NUM-DATA-POINTS] > LINEAR [ 0, 1] -> [0, NUM-DATA-POINTS] >=20 > Hmm... the more I think about it, the more I think the range > should be [0, 1] and we should explicitly have assertions that > are opposites like SENDS-HAM and SENDS-SPAM. And we shouldn't worry > about contradictions. That's mostly where I'm at. The remaining point for me has to do with the = data points themselves. You appear to be using data points (in the spam ca= se) as individual messages, but for me they're summarized days of data. Th= at makes the mapping less meaningful. My vision for use of the data count is just to let the client say "I won't = trust your reputation score until you tell me it's based on at least N data= points," regardless of what the units are. From R.E.Sonneveld@sonnection.nl Mon Oct 31 15:24: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 8603321F8CA0 for ; Mon, 31 Oct 2011 15:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 X-5a9M2dvSH1 for ; Mon, 31 Oct 2011 15:24:06 -0700 (PDT) Received: from mx10.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by ietfa.amsl.com (Postfix) with ESMTP id 3561921F8C97 for ; Mon, 31 Oct 2011 15:24: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 <0LTY00N00BFYIJ00@hydrogen.mailtransaction.com>; Mon, 31 Oct 2011 23:24:02 +0100 (CET) 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 <0LTY00811BK2RL00@hydrogen.mailtransaction.com>; Mon, 31 Oct 2011 23:24:02 +0100 (CET) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_rrGtT9lv4g+LypG7arDq6Q)" 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 <0LTY00F0QBK1RG00@lion.sonnection.nl> for domainrep@ietf.org; Mon, 31 Oct 2011 23:24:01 +0100 (CET) Message-id: <4EAF2118.5040001@sonnection.nl> Date: Mon, 31 Oct 2011 23:28:40 +0100 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 To: "Murray S. Kucherawy" References: <20111025120447.5155ba24@hydrogen.roaringpenguin.com> <147F7F0A-E5D4-40E3-A3B2-50DC2617F7F8@guppylake.com> <20111031161946.33f4379f@hydrogen.roaringpenguin.com> <20111031163752.0191c09f@hydrogen.roaringpenguin.com> In-reply-to: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1320099842; bh=sXoT+lOnI6muqAJU62ekoxM+uVmhxePqPIIrZQu9XaM=; h=MIME-version:Content-type:Message-id:Date:From:To:Cc:Subject: References:In-reply-to; b=mZAJoa8pAAZCeXJXcgC4CL51vUye9GNXb01sHYGxblJrNOxOdXb+CXabKMA1xjBWQ uCB/hZCNi7+4Sry51K8S1xIW0pYEE5ypMYdxaLyrNBibwipM80hC0uDwtnlrbqZm09 zKM6lWQ8Z4H0rVwE14QRnfxcKowH78qewoHmaJ5o= X-DKIM: OpenDKIM Filter v2.1.3 hydrogen.mailtransaction.com 0LTY00N00BFYIJ00 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Comments on draft-kucherawy-reputation-vocab-identity 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, 31 Oct 2011 22:24:07 -0000 This is a multi-part message in MIME format. --Boundary_(ID_rrGtT9lv4g+LypG7arDq6Q) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT On 10/31/11 10:32 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On Behalf Of David F. Skoll >> Sent: Monday, October 31, 2011 1:38 PM >> To: domainrep@ietf.org >> Subject: Re: [domainrep] Comments on draft-kucherawy-reputation-vocab- identity >> >>> What about the case where the assertion has no opposite? For >>> example, IS-PURPLE. What would "-1" mean? >> Point taken. So I guess the registration MUST define the range >> and SHOULD define the algorithm for converting data points to value. >> There should be two predefined algorithms: >> >> LINEAR [-1, 1] -> [0, NUM-DATA-POINTS] >> LINEAR [ 0, 1] -> [0, NUM-DATA-POINTS] >> >> Hmm... the more I think about it, the more I think the range >> should be [0, 1] and we should explicitly have assertions that >> are opposites like SENDS-HAM and SENDS-SPAM. And we shouldn't worry >> about contradictions. > That's mostly where I'm at. The remaining point for me has to do with the data points themselves. You appear to be using data points (in the spam case) as individual messages, but for me they're summarized days of data. That makes the mapping less meaningful. > > My vision for use of the data count is just to let the client say "I won't trust your reputation score until you tell me it's based on at least N data points," regardless of what the units are. Two comments on that last sentence: 1. the word 'trust' should be used with great care here: I assume you mean: "I won't consider your reputation score of any value until I learn it's based on at least N data points"? Thats not the same as "I won't trust your reputation score until..." in my view. 2. I'm not sure I understand what you mean with 'regardless of what the units are.'? This only works if server and client have the same understanding of what a 'unit' is (but I think that's what you want to say here, isn't it?) This brings us to the question: shouldn't the query protocol include some sort of filtering 'language'? Like: give me the 'SENDS-SPAM' results for (domain) X where number of data points > Y and 'last updated date' > 1-nov-2011 etc.? This won't work out for DNS of course, but for the HTTP mechanism it might be a valuable extension? /rolf --Boundary_(ID_rrGtT9lv4g+LypG7arDq6Q) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On 10/31/11 10:32 PM, Murray S. Kucherawy wrote: 
-----Original Message-----
From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On Behalf Of David F. Skoll
Sent: Monday, October 31, 2011 1:38 PM
To: domainrep@ietf.org
Subject: Re: [domainrep] Comments on draft-kucherawy-reputation-vocab- identity


What about the case where the assertion has no opposite?  For
example, IS-PURPLE.  What would "-1" mean?

Point taken.  So I guess the registration MUST define the range
and SHOULD define the algorithm for converting data points to value.
There should be two predefined algorithms:

LINEAR [-1, 1] -> [0, NUM-DATA-POINTS]
LINEAR [ 0, 1] -> [0, NUM-DATA-POINTS]

Hmm... the more I think about it, the more I think the range
should be [0, 1] and we should explicitly have assertions that
are opposites like SENDS-HAM and SENDS-SPAM.  And we shouldn't worry
about contradictions.

That's mostly where I'm at.  The remaining point for me has to do with the data points themselves.  You appear to be using data points (in the spam case) as individual messages, but for me they're summarized days of data.  That makes the mapping less meaningful.

My vision for use of the data count is just to let the client say "I won't trust your reputation score until you tell me it's based on at least N data points," regardless of what the units are.

Two comments on that last sentence:

  1. the word 'trust' should be used with great care here: I assume you mean: "I won't consider your reputation score of any value until I learn it's based on at least N data points"? Thats not the same as "I won't trust your reputation score until..." in my view.
  2. I'm not sure I understand what you mean with 'regardless of what the units are.'? This only works if server and client have the same understanding of what a 'unit' is (but I think that's what you want to say here, isn't it?)

This brings us to the question: shouldn't the query protocol include some sort of filtering 'language'? Like: give me the 'SENDS-SPAM' results for (domain) X where number of data points > Y and 'last updated date' > 1-nov-2011 etc.? This won't work out for DNS of course, but for the HTTP mechanism it might be a valuable extension?

/rolf
--Boundary_(ID_rrGtT9lv4g+LypG7arDq6Q)-- From msk@cloudmark.com Mon Oct 31 15:31:19 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 9070E11E832C for ; Mon, 31 Oct 2011 15:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.291 X-Spam-Level: X-Spam-Status: No, score=-103.291 tagged_above=-999 required=5 tests=[AWL=0.307, 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 TZlCFkOl1D0C for ; Mon, 31 Oct 2011 15:31:17 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2C04511E832B for ; Mon, 31 Oct 2011 15:31:17 -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, 31 Oct 2011 15:31:16 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Mon, 31 Oct 2011 15:31:14 -0700 Thread-Topic: [domainrep] Comments on draft-kucherawy-reputation-vocab-identity Thread-Index: AcyYG83g62v/ewpKTc+usi2uyCyTxgAADURw Message-ID: References: <20111025120447.5155ba24@hydrogen.roaringpenguin.com> <147F7F0A-E5D4-40E3-A3B2-50DC2617F7F8@guppylake.com> <20111031161946.33f4379f@hydrogen.roaringpenguin.com> <20111031163752.0191c09f@hydrogen.roaringpenguin.com> <4EAF2118.5040001@sonnection.nl> In-Reply-To: <4EAF2118.5040001@sonnection.nl> 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_F5833273385BB34F99288B3648C4F06F19C6C14D8DEXCHC2corpclo_" MIME-Version: 1.0 Subject: Re: [domainrep] Comments on draft-kucherawy-reputation-vocab-identity 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, 31 Oct 2011 22:31:19 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C14D8DEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rolf, You're right on the "trust" point, and yes, your assumption of my meaning i= s correct. The reason I'm resisting the idea of defining the units for the SAMPLE-SIZE= is that doing so means making additional requirements on the reputation se= rvice provider in terms of implementation. We're already saying the RATING= has to be normalized, but I'm not sure I see the benefit to doing so for t= he sample size as well because it forces a specific quantization of the und= erlying data. Put another way, David's idea appears to be to represent a ratio of spam-to= -ham or something like that, where I want to give you an estimate of the li= kelihood that the next message(s) you get from that source will be spam. H= is units are messages, while my units are days. We go about it quite diffe= rently. Forcing the sample count to be a specific unit means a lot less of= that sort of variation in method is possible. -MSK From: Rolf E. Sonneveld [mailto:R.E.Sonneveld@sonnection.nl] Sent: Monday, October 31, 2011 3:29 PM To: Murray S. Kucherawy Cc: domainrep@ietf.org Subject: Re: [domainrep] Comments on draft-kucherawy-reputation-vocab-ident= ity On 10/31/11 10:32 PM, Murray S. Kucherawy wrote: -----Original Message----- From: domainrep-bounces@ietf.org [mailto= :domainrep-bounces@ietf.org] On Behalf Of David F. Skoll Sent: Monday, October 31, 2011 1:38 PM To: domainrep@ietf.org Subject: Re: [domainrep] Comments on draft-kucherawy-reputation-vocab- iden= tity What about the case where the assertion has no opposite? For example, IS-PURPLE. What would "-1" mean? Point taken. So I guess the registration MUST define the range and SHOULD define the algorithm for converting data points to value. There should be two predefined algorithms: LINEAR [-1, 1] -> [0, NUM-DATA-POINTS] LINEAR [ 0, 1] -> [0, NUM-DATA-POINTS] Hmm... the more I think about it, the more I think the range should be [0, 1] and we should explicitly have assertions that are opposites like SENDS-HAM and SENDS-SPAM. And we shouldn't worry about contradictions. That's mostly where I'm at. The remaining point for me has to do with the = data points themselves. You appear to be using data points (in the spam ca= se) as individual messages, but for me they're summarized days of data. Th= at makes the mapping less meaningful. My vision for use of the data count is just to let the client say "I won't = trust your reputation score until you tell me it's based on at least N data= points," regardless of what the units are. Two comments on that last sentence: 1. the word 'trust' should be used with great care here: I assume you mea= n: "I won't consider your reputation score of any value until I learn it's = based on at least N data points"? Thats not the same as "I won't trust your= reputation score until..." in my view. 2. I'm not sure I understand what you mean with 'regardless of what the u= nits are.'? This only works if server and client have the same understandin= g of what a 'unit' is (but I think that's what you want to say here, isn't = it?) This brings us to the question: shouldn't the query protocol include some s= ort of filtering 'language'? Like: give me the 'SENDS-SPAM' results for (do= main) X where number of data points > Y and 'last updated date' > 1-nov-201= 1 etc.? This won't work out for DNS of course, but for the HTTP mechanism i= t might be a valuable extension? /rolf --_000_F5833273385BB34F99288B3648C4F06F19C6C14D8DEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Rolf,

 = ;

You’re right on the = 220;trust” point, and yes, your assumption of my meaning is correct.<= o:p>

 

The reason I’m resisting the idea of de= fining the units for the SAMPLE-SIZE is that doing so means making addition= al requirements on the reputation service provider in terms of implementati= on.  We’re already saying the RATING has to be normalized, but I= ’m not sure I see the benefit to doing so for the sample size as well= because it forces a specific quantization of the underlying data.

 

Put another way, David’s idea appears to be to = represent a ratio of spam-to-ham or something like that, where I want to gi= ve you an estimate of the likelihood that the next message(s) you get from = that source will be spam.  His units are messages, while my units are = days.  We go about it quite differently.  Forcing the sample coun= t to be a specific unit means a lot less of that sort of variation in metho= d is possible.

 =

-MSK

 

<= p class=3DMsoNormal>From: Rolf E. Sonneveld= [mailto:R.E.Sonneveld@sonnection.nl]
Sent: Monday, October 31, = 2011 3:29 PM
To: Murray S. Kucherawy
Cc: domainrep@ietf= .org
Subject: Re: [domainrep] Comments on draft-kucherawy-reputat= ion-vocab-identity

 

On 10/31/11 10:32 PM, Murray S. Kuc= herawy wrote: 

-----Original Message-----
From: domainrep-bounces@ietf.org [=
mailto:domainrep-bounces@ietf=
.org] On Behalf Of David F. Skoll
Sent: Monday, Oc=
tober 31, 2011 1:38 PM
To: domainrep@ietf.org
Subject: Re: [domain=
rep] Comments on draft-kucherawy-reputation-vocab- identity
 
What about the case where the assertion has no opposite?&=
nbsp; For
example, IS-PURPLE.  What would "-=
1" mean?
 
Point taken.  So I guess the registration MUST define the range<=
/o:p>
and SHOULD define the algorithm for converting data points =
to value.
There should be two predefined algorithms:
 
LINEAR [-1, 1] -> [0, NU=
M-DATA-POINTS]
LINEAR [ 0, 1] -> [0, NUM-DATA-POINT=
S]
 
Hmm... the more I think=
 about it, the more I think the range
should be [0, 1]=
 and we should explicitly have assertions that
are opp=
osites like SENDS-HAM and SENDS-SPAM.  And we shouldn't worry
about contradictions.
&=
nbsp;
That's mostly where I'm at.  The remaining point=
 for me has to do with the data points themselves.  You appear to be u=
sing data points (in the spam case) as individual messages, but for me they=
're summarized days of data.  That makes the mapping less meaningful.<=
o:p>
 
My vision for use of the d=
ata count is just to let the client say "I won't trust your reputation=
 score until you tell me it's based on at least N data points," regard=
less of what the units are.


Two comments on that last sentence:

=
  1. the word 'trust' sho= uld be used with great care here: I assume you mean: "I won't consider= your reputation score of any value until I learn it's based on at least N = data points"? Thats not the same as "I won't trust your reputatio= n score until..." in my view.
  2. I'm not sure I understand what you mean with 'regardless of what the= units are.'? This only works if server and client have the same understand= ing of what a 'unit' is (but I think that's what you want to say here, isn'= t it?)


This brings us to the q= uestion: shouldn't the query protocol include some sort of filtering 'langu= age'? Like: give me the 'SENDS-SPAM' results for (domain) X where number of= data points > Y and 'last updated date' > 1-nov-2011 etc.? This won'= t work out for DNS of course, but for the HTTP mechanism it might be a valu= able extension?

/rolf

= --_000_F5833273385BB34F99288B3648C4F06F19C6C14D8DEXCHC2corpclo_-- From dotis@mail-abuse.org Mon Oct 31 15:33: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 AF6461F0D23 for ; Mon, 31 Oct 2011 15:33:49 -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 3PZfhpXZrDGC for ; Mon, 31 Oct 2011 15:33:49 -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 42F931F0D1A for ; Mon, 31 Oct 2011 15:33:49 -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 6C0186E0133 for ; Mon, 31 Oct 2011 22:33:47 +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 CD607A9443B for ; Mon, 31 Oct 2011 22:33:47 +0000 (UTC) Message-ID: <4EAF224B.6030602@mail-abuse.org> Date: Mon, 31 Oct 2011 15:33:47 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: domainrep@ietf.org References: <20111031012929.44531.qmail@joyce.lan> In-Reply-To: <20111031012929.44531.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 31 Oct 2011 22:33:49 -0000 On 10/30/11 6:29 PM, John Levine wrote: > > base reputation ONLY on AUTHENTICATED identities. > > > > I have to disagree, because in principle I don't believe there is > > such a thing as an authenticated identity. > > We may have a terminology difference here. In this context, an > authenticated identity is one that's been validated by an external > authority, e.g., a domain in a DKIM signature that has a matching > key in the DNS, as opposed to a domain in an address on the From: > line of a message. While DKIM authenticates a domain has signed a portion of a message, it does not authenticate whether this domain transmitted the message to a particular recipient. DKIM signatures do not capture SMTP elements necessary to assign accountability for the transmission of unwanted and abusive messages. By design DKIM does NOT restrict who sent a valid message or to whom. Spammers often lie and have even been known to threaten litigation. Anyone can assert a negative reputation placed against their domain is in error and is causing them harm. Resisting demands that negative reputations be changed must be backed by information able to withstand scrutiny. Clever spammers can easily ensure valid DKIM signatures leave the actual transmitter in doubt. The entity held accountable through reputation assignment for the sending of spam MUST be the entity AUTHENTICATED. SMTP accountability should begin by authenticating the administrative domain of the outbound MTA. In order to safely accomplish the necessary authentications, SMTP Auth, DANE, and Kerberos tickets could be used to establish a basis upon which reputations can be fairly and equitably established. While DKIM may play a role in mitigating phishing attacks, DKIM lacks SMTP specific information necessary to safely hold the transmitters of messages accountable. The transmitters of a message are not authenticated by DKIM, nor are they with SPF. -Doug From dfs@roaringpenguin.com Mon Oct 31 16:55:40 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 56A7711E83E8 for ; Mon, 31 Oct 2011 16:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 4UA9zMdguHe2 for ; Mon, 31 Oct 2011 16:55: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 5CBF711E83BA for ; Mon, 31 Oct 2011 16:55: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 p9VNtbg6008491 for ; Mon, 31 Oct 2011 19:55:38 -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 p9VNtXs9024843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 31 Oct 2011 19:55:36 -0400 Date: Mon, 31 Oct 2011 19:55:32 -0400 From: "David F. Skoll" To: domainrep@ietf.org Message-ID: <20111031195532.66b8eebe@shishi.roaringpenguin.com> In-Reply-To: References: <20111025120447.5155ba24@hydrogen.roaringpenguin.com> <147F7F0A-E5D4-40E3-A3B2-50DC2617F7F8@guppylake.com> <20111031161946.33f4379f@hydrogen.roaringpenguin.com> <20111031163752.0191c09f@hydrogen.roaringpenguin.com> 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=XvNgCQxJ2nvb t3DLVHgTL84DYc4=; b=M22KDZEtykryzXBDAAtAwCvBYk9birpNK3wvbKyd0Iwk m/IfOp2UMUqJY3e5t7Qw+nKJIhyCPWCV0ZKvV0HgGMoOXl88CX+wWicjCqNDuuBx ESz+l8461TWnX6v2/LY0L2GFGePx0/FhRGqUt15vZVHLm+i4yMsErAh9vDXk2PQ= 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/20111031 / 01FPzTBef Subject: Re: [domainrep] Comments on draft-kucherawy-reputation-vocab-identity 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, 31 Oct 2011 23:55:40 -0000 On Mon, 31 Oct 2011 14:32:29 -0700 "Murray S. Kucherawy" wrote: > My vision for use of the data count is just to let the client say "I > won't trust your reputation score until you tell me it's based on at > least N data points," regardless of what the units are. But if you don't know what a data point is, how can you make that decision? In our system, one data point is one "event" as reported by an event collector. If one of your data points is a day's worth of events, then one of your data points will correspond to several million of ours and it's impossible to compare the systems. I think we need a good definition of what a data point is, or failing that, a good way for reputation systems to specify what they consider a data point to be. Regards, David. From johnl@iecc.com Mon Oct 31 17:52: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 D42511F0C52 for ; Mon, 31 Oct 2011 17:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.569 X-Spam-Level: X-Spam-Status: No, score=-110.569 tagged_above=-999 required=5 tests=[AWL=0.630, 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 qHkXuWvjGkue for ; Mon, 31 Oct 2011 17:52:12 -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 450F01F0C49 for ; Mon, 31 Oct 2011 17:52:11 -0700 (PDT) Received: (qmail 52406 invoked from network); 1 Nov 2011 00:52:09 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 1 Nov 2011 00:52:09 -0000 Received: (qmail 84461 invoked from network); 1 Nov 2011 00:52:09 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 1 Nov 2011 00:52:09 -0000 Date: 1 Nov 2011 00:51:47 -0000 Message-ID: <20111101005147.29530.qmail@joyce.lan> From: "John Levine" To: domainrep@ietf.org In-Reply-To: <20111031195532.66b8eebe@shishi.roaringpenguin.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [domainrep] Comments on draft-kucherawy-reputation-vocab-identity 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, 01 Nov 2011 00:52:12 -0000 >I think we need a good definition of what a data point is, or failing that, >a good way for reputation systems to specify what they consider a data point >to be. I would suggest putting that on the list of things to resolve eventually rather than trying to resolve it now. If I were telling you spam ratios per IP, I'd denominate it in perhaps tens or hundreds of messages. If it were somone like Return Path who aggregates data from many large ISPs, it'd probably be hundreds of thousands. I also suspect there will be providers with useful data who will consider the counts proprietary. R's, John From jdfalk-lists@cybernothing.org Mon Oct 31 18:28:32 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 A53C11F0CCA for ; Mon, 31 Oct 2011 18:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 L5FgDglaJIlo for ; Mon, 31 Oct 2011 18:28:32 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id E926A1F0C52 for ; Mon, 31 Oct 2011 18:28:31 -0700 (PDT) Received: from [192.168.11.32] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id pA11SSbg002552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 31 Oct 2011 18:28:30 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: Date: Mon, 31 Oct 2011 18:28:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <680D09EF-84F1-4FAB-BBAC-E495EB03707A@cybernothing.org> References: <20111031012929.44531.qmail@joyce.lan> To: domainrep@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 01 Nov 2011 01:28:32 -0000 On Oct 31, 2011, at 1:20 PM, Murray S. Kucherawy wrote: > In my view, deciding which methods to trust, for both parties, is a = matter for those parties to decide on their own and not a topic for = REPUTE to reopen. +1 -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From jdfalk-lists@cybernothing.org Mon Oct 31 18:35:54 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 4B50011E809B for ; Mon, 31 Oct 2011 18:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 w-94-Uu10ejx for ; Mon, 31 Oct 2011 18:35:53 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id B08DC11E8097 for ; Mon, 31 Oct 2011 18:35:53 -0700 (PDT) Received: from [192.168.11.32] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id pA11ZoXm002590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 31 Oct 2011 18:35:53 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: <20111101005147.29530.qmail@joyce.lan> Date: Mon, 31 Oct 2011 18:35:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111101005147.29530.qmail@joyce.lan> To: domainrep@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [domainrep] Comments on draft-kucherawy-reputation-vocab-identity 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, 01 Nov 2011 01:35:54 -0000 On Oct 31, 2011, at 5:51 PM, John Levine wrote: >> I think we need a good definition of what a data point is, or failing = that, >> a good way for reputation systems to specify what they consider a = data point >> to be. >=20 > I would suggest putting that on the list of things to resolve > eventually rather than trying to resolve it now. If I were telling > you spam ratios per IP, I'd denominate it in perhaps tens or hundreds > of messages. If it were somone like Return Path who aggregates data > from many large ISPs, it'd probably be hundreds of thousands. Even better: not all data sources or types are weighted equally, so a = raw count of email messages would be misleading. > I also suspect there will be providers with useful data who will = consider > the counts proprietary. Yep, and in those cases a self-identified "confidence" score makes more = sense. I think we'll need to leave room for both. -- J.D. Falk Return Path From clewis+ietf@mustelids.ca Mon Oct 31 19:40:09 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 ECA1C11E808C for ; Mon, 31 Oct 2011 19:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 CgL3+l9HTo-C for ; Mon, 31 Oct 2011 19:40:09 -0700 (PDT) Received: from mail.mustelids.ca (unknown [174.35.130.2]) by ietfa.amsl.com (Postfix) with ESMTP id D1AA611E808A for ; Mon, 31 Oct 2011 19:40:08 -0700 (PDT) Received: from [192.168.0.8] (otter.mustelids.ca [192.168.0.8]) (authenticated bits=0) by mail.mustelids.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pA12WlUi004639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 31 Oct 2011 22:32:51 -0400 Message-ID: <4EAF5BF9.7000208@mustelids.ca> Date: Mon, 31 Oct 2011 22:39:53 -0400 From: Chris Lewis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: domainrep@ietf.org References: <20111026102133.GB41225@shinkuro.com> <4EA7EF3A.4070109@dcrocker.net> <20111027124146.GA46308@shinkuro.com> <4EAA1DE7.7090608@dcrocker.net> <20111031151614.GD48552@shinkuro.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues) 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, 01 Nov 2011 02:40:10 -0000 On 11-10-31 12:26 PM, Frank Ellermann wrote: > "Listing the world" only to get rid of clients still > trying to use a long dead service is not funny, no > matter how these queries are implemented (DNSBL, SIQ, > WHOIS UDP/TCP, HTTP, whatever). While the wildcarded domain returning a non 127/8 address is a risk, it seems to be mostly a theoretical one. It's happened before, and the consequences have been unnoticable on the whole. It seems more frequent that individual sites screw up their DNSBL query config to the extent that it always returns what they think is a listing. Eg: misspelling the query zone, or miss-parsing received lines. It seems that most of the clients now insist on 127/8 addresses, if not exact values, and most aren't affected. The "market" has improved in quality over the years. All of the list-the-world instances we've heard about have been _deliberate_, either by the original DNSBL operator, or by the new owner of the domain, where they've arranged it to return the specific 127.x.x.x address that indicates listing. As such, no matter how we defined a reputation service, this same risk of "list the world" remains, and for much the same reasons. We could authenticate the results somehow, but that still won't prevent a reputation provider deliberately going rogue. I don't think we can solve that problem in a protocol specification.