From tmacaulay@2keys.ca Tue May 22 04:20:49 2012 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 2806E21F84BF for ; Tue, 22 May 2012 04:20:49 -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 ijoAL5WOu21U for ; Tue, 22 May 2012 04:20:48 -0700 (PDT) Received: from mail.2keys.ca (mail.2keys.ca [72.1.200.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE1621F848A for ; Tue, 22 May 2012 04:20:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.2keys.ca (Postfix) with ESMTP id 94AB128116E for ; Tue, 22 May 2012 07:12:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at 2keys.ca Received: from mail.2keys.ca ([127.0.0.1]) by localhost (mail.2keys.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ym7wN+sOlw3p for ; Tue, 22 May 2012 07:12:45 -0400 (EDT) Received: from [10.0.0.139] (unknown [65.48.164.194]) by mail.2keys.ca (Postfix) with ESMTPSA id 9A8722810E2 for ; Tue, 22 May 2012 07:12:44 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.2.1.120420 Date: Tue, 22 May 2012 07:20:38 -0400 From: Tyson Macaulay To: Message-ID: Thread-Topic: Test application reg under repute-media-type In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: [domainrep] Test application reg under repute-media-type 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, 22 May 2012 11:20:49 -0000 HI, I took a look at repute-media-type-02 and the proposed IANA application registration in order to see how it might look like if the application was "packet staining", as tentatively defined in draft-macaulay-6man-packet-staining-00. "5.2. Reputation Applications Registry IANA is requested to create the "Reputation Applications" registry. This registry will contain names of applications used with the application/reputon+json media type (and other media types that carry reputons), as defined by this document. New registrations or updates MUST be published in accordance with the "Specification Required" guidelines as described in [IANA-CONSIDERATIONS]." SAMPLE REGISTRATION FOR STAITING New registrations and updates MUST contain the following information: 1. Name: packet staining 2. Purpose: For encoding the reputation of a source address within IPv6 packet header extensions 3. Documentation: Draft-macaulay-6man-packet-staining-00 4. Status: current=20 5. A description of the subject of a query: ip-address, address-range (i.e. /64) domain name <> 6. An optional table of query parameters that are specific to this application; each table entry must include: << I will make a separate post on this topic related to reputation algorithms>> ASSERTIONS:=20 Name: indicator of malice or compromise Description: the degree to which the IP, IP-range, domain is generating traffic indicative of malicious influence or compromised. Example: 0.0 =3D no evidence of malice or compromise / benign IP; 1.0 =3D complete assurance of contemporary malice or compromise-related activity Scale: Not sure how this differs from "Description" above. Also - see other "algorithm" thread in this list. Extension Key Name: (not sure about this either. Perhaps an indicator of with the reputation applies to the ip, /64 or domain name?) Description: Allow a reputation score to be provided based on source IP, adjacent IPs or non-adjacent IPs under the same ASN (mutli-homed environments suffering compromise or acting in a malicious manner) Syntax: Suggestions? Note: This is great work. I believe it is also very complimentary to what is being proposed in 6man, too. Tyson -- Tyson Macaulay, BA CISSP CISA VP =AD Technology 2Keys Security Solutions Phone: +1 613 292 9132 email: tmacaulay@2keys.ca From tmacaulay@2keys.ca Tue May 22 04:24:57 2012 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 C47BC21F852B for ; Tue, 22 May 2012 04:24: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=[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 AztpAyQWu3ld for ; Tue, 22 May 2012 04:24:57 -0700 (PDT) Received: from mail.2keys.ca (mail.2keys.ca [72.1.200.74]) by ietfa.amsl.com (Postfix) with ESMTP id 10E1E21F848F for ; Tue, 22 May 2012 04:24:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.2keys.ca (Postfix) with ESMTP id 224C4281192 for ; Tue, 22 May 2012 07:17:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at 2keys.ca Received: from mail.2keys.ca ([127.0.0.1]) by localhost (mail.2keys.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDztQCqkY9gX for ; Tue, 22 May 2012 07:16:58 -0400 (EDT) Received: from [10.0.0.139] (unknown [65.48.164.194]) by mail.2keys.ca (Postfix) with ESMTPSA id 4B0002810E2 for ; Tue, 22 May 2012 07:16:58 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.2.1.120420 Date: Tue, 22 May 2012 07:24:52 -0400 From: Tyson Macaulay To: Message-ID: Thread-Topic: Reputation algorithms In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: [domainrep] Reputation algorithms 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, 22 May 2012 11:24:57 -0000 HI again, In a soon to be released INFORMATIONAL RFC - draft-macaulay-6man-reputation-intelligence-00 we propose criteria for reputation intelligence algorithms. These appear to partially overlap with your complimentary conclusions in draft-ietf-repute-media-type-02 - Section 3.1, but we have some supplementary criteria. (It will be a few more days before I get the INFORMATIONAL RFC on line due to a family vacation. Email me if you want a pre-00 version right away.) Also - it is entirely possibly your intention that many of these criteria are implicit and not required in the replies to reputation queries.(?) In our current model, all criteria except the reputation score=20 itself is held within the intelligence algorithm rather than communicated in the reputation query-response. Below I have tried to map your reputation criterium against ours - or indicate where there is no mapping: REPUTON "Rater" =3D Implicit in selection of query destination in our model. REPUTON "Application" =3D Implicit intended app is "packet staining" as per draft-macaulay-6man-packet-stain-00 REPUTON "Assertion" =3D no mapping REPUTON "Rated" =3D indicated by the source address of the packet REPUTON "Rating" =3D Reputation score to be encoded in header extension REPUTON "Confidence" =3D no mapping at this time. REPUTON "Authenticity" =3D no mapping. This is a management control (business-level decision) in our model. REPUTON "Sample size" =3D Function 8 (approximately) REPUTON "Updated" =3D Function 2, 6, 7 (approximately) Algorithmic functions as per draft-macaulay-6man-reputation-intelligence-00 Function 1: to account for large Internet portals with many, independent URLs with good reputations, but also some proportion of dangerous (bad reputation) URLs sharing the same IP address =3D no REPUTON mapping? Function 2: to account for the distance in time between the last observed suspicious or illicit behaviour and the present Function 3: to account for the reputations of both adjacent IP addresses or domains =3D REPUTON "Updated" (approximately?) Function 4: to account for the original, per-processed source of the intelligence (open source, closed source, domain of control, uncontrolled domain) =3D no REPUTON mapping Function 5: to account for the velocity of suspicious or illicit behaviour (IE. high Spam rate) =3D no REPUTON mapping Function 6: to account for the duration of suspicious or illicit behaviour (IE. sustained spam at low velocity) =3D REPUTON "Updated" (approximately?) Function 7: to account for lifetime of domain to source IP associations (IE. newly minted domain names or previously unobserved/ un-assigned addresses =3D REPUTON "Updated" (approximately) Function 8: to account for the proportion of traffic from this source which is benign versus demonstrably illicit =3D REPUTON "Sample size" (approximately?) Function 9: to account of the nature of the suspicious or illicit behaviour (automated port scanning versus malware-drop) =3D no REPUTON mapping What are your impressions of this criteria from our draft? Do you feel they are valid in the context of intelligence algorithms? Is there any particular reason they are not explicit in your "Reputon Keys" in Section 3.1? Thanks, Tyson=20 PS - again - we (my co-authors) think your work here is great, and the direction we need to go in order to establish networks with the necessary assurance in the future. -- Tyson Macaulay, BA CISSP CISA VP =AD Technology 2Keys Security Solutions Phone: +1 613 292 9132 email: tmacaulay@2keys.ca From msk@cloudmark.com Thu May 24 23:51:33 2012 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 6189B11E807F for ; Thu, 24 May 2012 23:51:33 -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 rIbyt1pBfzN5 for ; Thu, 24 May 2012 23:51:32 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5121B21F8557 for ; Thu, 24 May 2012 23:51:29 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id E6qv1j0010as01C016qvpV; Thu, 24 May 2012 23:50:55 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=dpJZ+ic4 c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=VNnYJC5z254A:10 a=anuljDEAuyAA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=b6nfwRhkAAAA:8 a=48vgC7mUAAAA:8 a=x_sqSwUm_0SF10j-bGoA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=2tsRMFeD-TUq-lse:21 a=rq0PtIIgmn6llMgg:21 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Thu, 24 May 2012 23:50:56 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Thread-Topic: Test application reg under repute-media-type Thread-Index: AQHNOAzy7bCv7DOhVka4rD2SScIsKZbaEyYg Date: Fri, 25 May 2012 06:50:55 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392812F720@exch-mbx901.corp.cloudmark.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.1.155] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1337928655; bh=kxQW19JfDidtpgBbdZ9uh2M2SAdP3E/vCyWAhRgvE0k=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=FuttBif5mcU1qrQTcZIf6IobieJZDObWqc5GifepQ6e4Pyn6Btl8ktFArga6h5WWX H1z7leDSzLJmZZNSnTx1f0h8hAgxDwXCS7BsUAebvDY6NSeBH6K8T/glgGC013QoXv VoxmQRtAP/M3ENtzTGt66PRPSLIdd6pwgqs/Hjjc= Subject: Re: [domainrep] Test application reg under repute-media-type 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, 25 May 2012 06:51:33 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Tyson Macaulay > Sent: Tuesday, May 22, 2012 4:21 AM > To: domainrep@ietf.org > Subject: [domainrep] Test application reg under repute-media-type >=20 > SAMPLE REGISTRATION FOR STAITING >=20 > New registrations and updates MUST contain the following information: > 1. Name: packet staining I would probably call it "packet-staining" or even something more general l= ike "tcp-sources". > 3. Documentation: draft-macaulay-6man-packet-staining-00 Is that where you plan to define any query or response set extensions? If = so, the registration should just go in that document directly along with wh= atever else is in there. > 5. A description of the subject of a query: ip-address, address-range > (i.e. /64), domain name < distance IANA registrations?>> Saying the subject of the query is either an IP address or a CIDR expressio= n is probably fine. In the reply, you don't have to report on the same thi= ng. For example, you might ask about an IP address and get back a CIDR blo= ck if you've aggregated reputation in that way. (See what ARIN's RESTful W= HOIS query does, for example.) Are you planning to tie "stains" to domain names? How would that work? > ASSERTIONS: > Name: indicator of malice or compromise You would list assertion names here like "MALICIOUS" or "COMPROMISED", and = explain for each what 0 and 1 mean in Description. > Scale: Not sure how this differs from "Description" above. Also - see > other "algorithm" thread in this list. The scale is just an indication if one travels from 0 to 1 linearly, expone= ntially, logarithmically, etc. > Extension Key Name: (not sure about this either. Perhaps an indicator > of with the reputation applies to the ip, /64 or domain name?) You don't have to have extensions to the query or reply if you don't need t= hem. You could reply with the specific IP that was the subject of the quer= y, and then include as extensions the CIDR block you think contains it and = the domain name(s) you think are associated with them. This gives the clie= nt a clearer picture of your view of the subject. > Note: This is great work. I believe it is also very complimentary to > what is being proposed in 6man, too. Happy to hear it's useful! -MSK From msk@cloudmark.com Fri May 25 12:31:37 2012 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 0565A21F85F8 for ; Fri, 25 May 2012 12:31: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=[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 qOvWIUj5dJAf for ; Fri, 25 May 2012 12:31:36 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 26CA821F855B for ; Fri, 25 May 2012 12:31:36 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id EKXQ1j0010as01C01KXQgj; Fri, 25 May 2012 12:31:24 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=dpJZ+ic4 c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=b6nfwRhkAAAA:8 a=48vgC7mUAAAA:8 a=4BwUcuUSC60giPTP7wMA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=WcTQXMxSzMo9ZMkC:21 a=fva4Va-qHeJ2caT8:21 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Fri, 25 May 2012 12:31:25 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Thread-Topic: Reputation algorithms Thread-Index: AQHNOA2SXjK/yrPS3Uyv+UL89j0UGJba5X1A Date: Fri, 25 May 2012 19:31:24 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928130126@exch-mbx901.corp.cloudmark.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1337974284; bh=EfNAip3ZfUQ+pvyyPt9AW7oo+RwzaGr7Pm+iA1slLQk=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=A4viTIab+/CjMPIDUGhpUJrqP+gyWiSPrjSmVKlVbIwgJ5IDLYkSZevfNLUKnFpHN DA9nkbpwXrzmys892r8wdaEJf+3brsKAcYcDplOrU3DuZOGA1l6LhjQ1BJHZHvmIo1 YhzMZGJkwT4wU0bHkP/kP2X+cpNyUQSUDQsOiBeA= Subject: Re: [domainrep] Reputation algorithms 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, 25 May 2012 19:31:37 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Tyson Macaulay > Sent: Tuesday, May 22, 2012 4:25 AM > To: domainrep@ietf.org > Subject: [domainrep] Reputation algorithms >=20 > HI again, >=20 > In a soon to be released INFORMATIONAL RFC - > draft-macaulay-6man-reputation-intelligence-00 we propose criteria for > reputation intelligence algorithms. These appear to partially overlap > with your complimentary conclusions in draft-ietf-repute-media-type-02 > - Section 3.1, but we have some supplementary criteria. > > [...] >=20 > Below I have tried to map your reputation criterium against ours - or > indicate where there is no mapping: >=20 > REPUTON "Rater" =3D Implicit in selection of query destination in our m= odel. It's re-stated in the reply in case the service (host) you used in the quer= y URI is an alias for something else, and you want to know who ultimately a= nswered you. > REPUTON "Application" =3D Implicit intended app is "packet staining" as = per > draft-macaulay-6man-packet-stain-00 Yep; you'll need to re-state it in our model in case the reputation service= operates in many reputation application spaces, to be sure you got a meani= ngful answer. > REPUTON "Assertion" =3D no mapping For repute, the absence of this means "IS-GOOD" (Section 3.1 of our media-t= ype document). > REPUTON "Confidence" =3D no mapping at this time. >=20 > REPUTON "Authenticity" =3D no mapping. This is a management control > (business-level decision) in our model. These are optional anyway. > Algorithmic functions as per > draft-macaulay-6man-reputation-intelligence-00 >=20 > Function 1: to account for large Internet portals with many, > independent URLs with good reputations, but also some proportion of dange= rous (bad > reputation) URLs sharing the same IP address =3D no REPUTON mapping? If you have a source IP address producing several streams with distinct beh= aviours, but are unable to distinguish them, then the best you can do is de= liver a reputon about the source IP address or the/a CIDR block containing = it. > Function 2: to account for the distance in time between the last > observed suspicious or illicit behaviour and the present Function 3: > to account for the reputations of both adjacent IP addresses or domains > =3D REPUTON "Updated" (approximately?) Roughly. "Updated" is meant to indicate "this is when this rating was calc= ulated" so you can see how stale it is. If that's not what you need, you c= an declare an extension. > Function 4: to account for the original, per-processed source of the > intelligence (open source, closed source, domain of control, > uncontrolled > domain) =3D no REPUTON mapping I'm not sure what this is. You might be able to relay this via the "RATER"= parameter in the reply, or if that overloading is distasteful, you can sim= ply declare an extension in your response set that indicates what the intel= ligence source is. > Function 5: to account for the velocity of suspicious or illicit > behaviour (IE. high Spam rate) =3D no REPUTON mapping This would be an extension, maybe "RATE-OF-CHANGE" or "VELOCITY" or somethi= ng. > Function 6: to account for the duration of suspicious or illicit > behaviour (IE. sustained spam at low velocity) =3D REPUTON "Updated" > (approximately?) If your rating scale is such that there's a threshold of interest (0.5, let= 's say), then you could have an extension to indicate how long the subject = has been above that threshold. > Function 7: to account for lifetime of domain to source IP > associations (IE. newly minted domain names or previously unobserved/ > un-assigned addresses =3D REPUTON "Updated" (approximately) Extension, although now your subject is a complex one (i.e., something like= IP:domain). > Function 8: to account for the proportion of traffic from this source > which is benign versus demonstrably illicit =3D REPUTON "Sample size" > (approximately?) I would think that factors into the rating itself. > Function 9: to account of the nature of the suspicious or illicit > behaviour (automated port scanning versus malware-drop) =3D no REPUTON > mapping This would be a set of assertions you define in your response set other tha= n the default "IS-GOOD". -MSK From msk@cloudmark.com Fri May 25 12:39:21 2012 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 1685321F87B6 for ; Fri, 25 May 2012 12:39:21 -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 HyUbi95wsrSi for ; Fri, 25 May 2012 12:39:20 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4B00821F8484 for ; Fri, 25 May 2012 12:39:20 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id EKfK1j0010as01C01KfKj9; Fri, 25 May 2012 12:39:19 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=dpJZ+ic4 c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=b6nfwRhkAAAA:8 a=48vgC7mUAAAA:8 a=Z7TyyKw8cW_oAoLgSh4A:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Fri, 25 May 2012 12:39:19 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Thread-Topic: Reputation algorithms Thread-Index: AQHNOA2SXjK/yrPS3Uyv+UL89j0UGJba5X1AgAAGPdA= Date: Fri, 25 May 2012 19:39:18 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392813016D@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E003928130126@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E003928130126@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1337974759; bh=ECj4HBYZWUc2NJyxr7Uyhb7yeJozMy3MElIwssVY06g=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=IUzENNxoFhFYB8dBlBzvSk0QjINvj0O9Xgt6uYaySChQUJOYF7jgOfVdGvuNsKc+v LUV7t4BDbK6o31X/3cVGU43WiMagAUjTIgDLR7Kp74MNpJ32LJvMuYwIyEPXu3BTZH XtruoskbJlTMt6T6L3vfXwzrmze3RVH/pWdQ5ab4= Subject: Re: [domainrep] Reputation algorithms 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, 25 May 2012 19:39:21 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Murray S. Kucherawy > Sent: Friday, May 25, 2012 12:31 PM > To: domainrep@ietf.org > Subject: Re: [domainrep] Reputation algorithms >=20 > > Below I have tried to map your reputation criterium against ours - or > > indicate where there is no mapping: > > >=20 > It's re-stated in the reply in case the service (host) you used in the > query URI is an alias for something else, and you want to know who > ultimately answered you. > > [...] Tyson, You might want to try drafting up an individual submission that defines you= r repute application. This would be a good test to see if your work is a fi= t for this, and also a good test as to whether we've done a good job with o= ur existing documents. You could use the email-identifiers document as a template. -MSK