From Internet-Drafts@ietf.org Tue Feb 1 10:45:02 2011 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DF063A6FC4; Tue, 1 Feb 2011 10:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pQzGshu4CHw; Tue, 1 Feb 2011 10:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F18A3A6F24; Tue, 1 Feb 2011 10:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.11 Message-ID: <20110201184501.7021.53669.idtracker@localhost> Date: Tue, 01 Feb 2011 10:45:01 -0800 Cc: marf@ietf.org Subject: [marf] I-D ACTION:draft-ietf-marf-reporting-discovery-00.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 18:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Abuse Reporting Format Working Group of the IETF. Title : A DNS TXT Record for Advertising and Discovering Willingness to Provide or Receive ARF Reports Author(s) : J. Falk Filename : draft-ietf-marf-reporting-discovery-00.txt Pages : 15 Date : 2011-1-31 This document defines a method for network operators to advertise their willingness to send feedback about received email to other parties, and for those other parties to advertise their willingness to receive such feedback. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-reporting-discovery-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-marf-reporting-discovery-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-2-1104802.I-D@ietf.org> --NextPart-- From shmuel+gen@patriot.net Tue Feb 1 12:20:02 2011 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56F83A6C5C for ; Tue, 1 Feb 2011 12:20:02 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjflPis7fIjh for ; Tue, 1 Feb 2011 12:20:01 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 784093A6C42 for ; Tue, 1 Feb 2011 12:20:01 -0800 (PST) Received: from ECS35455305 (unknown [209.163.105.152]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 63DD3F580C9 for ; Tue, 1 Feb 2011 15:19:14 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Tue, 01 Feb 2011 15:22:25 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20110201201915.63DD3F580C9@smtp.patriot.net> Subject: Re: [marf] reporting-discovery X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 20:20:03 -0000 In , on 01/31/2011 at 03:08 PM, "J.D. Falk" said: >There's no reason it couldn't be used to report drop boxes, As I recall, the issue was timing; the priority was getting the RFC out the door for the sending network. >though that's not a common practice today. There's at least one provider that will only accept abuse reports in ARF. That makes it difficult to report drop boxes. >That's part of what the Reported-URI field was intended for. However, the current wording of 1.1. Purpose seems to rule out that use o email abuse originating from their networks; o potential issues with the perceived quality of outbound mail, such as email service providers sending mail that attracts the attention of automated abuse detection systems. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From shmuel+gen@patriot.net Tue Feb 1 12:20:07 2011 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A4FA3A6C86 for ; Tue, 1 Feb 2011 12:20:07 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGBGjW0FeT9R for ; Tue, 1 Feb 2011 12:20:06 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id D88B93A6C81 for ; Tue, 1 Feb 2011 12:20:06 -0800 (PST) Received: from ECS35455305 (unknown [209.163.105.152]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 5C2A6F580C8 for ; Tue, 1 Feb 2011 15:19:18 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Tue, 01 Feb 2011 15:22:25 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20110201201919.5C2A6F580C8@smtp.patriot.net> Subject: Re: [marf] reporting-discovery X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 20:20:07 -0000 In , on 01/31/2011 at 03:08 PM, "J.D. Falk" said: >There's no reason it couldn't be used to report drop boxes, As I recall, the issue was timing; the priority was getting the RFC out the door for the sending network. >though that's not a common practice today. There's at least one provider that will only accept abuse reports in ARF. That makes it difficult to report drop boxes. >That's part of what the Reported-URI field was intended for. However, the current wording of 1.1. Purpose seems to rule out that use o email abuse originating from their networks; o potential issues with the perceived quality of outbound mail, such as email service providers sending mail that attracts the attention of automated abuse detection systems. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From vesely@tana.it Wed Feb 2 00:52:23 2011 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 898EF3A6D8B for ; Wed, 2 Feb 2011 00:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.956 X-Spam-Level: X-Spam-Status: No, score=-4.956 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xC4yWakj9ceO for ; Wed, 2 Feb 2011 00:52:22 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 68C173A6B75 for ; Wed, 2 Feb 2011 00:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1296636940; bh=nsdvknGkZc9pXknJYAUUl9J5l++njJ92dkKNBClEYdU=; l=1453; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=IqijVTw69/X8103g7d9srSkDJ6X3btQJkV8GV1bCrqPi+hiMKQUFaNDudJmHzaQOB JX/HYKR9Ad2gonuYxCicpmkKkA9yxYKNrod8t/qI1nPvxmhKRZi45ISwQYe4VSFFy6 8tMX6yplxlJDnAk1FcOca1FHHLTbEvyLTf2JuQxs= 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; Wed, 02 Feb 2011 09:55:40 +0100 id 00000000005DC044.000000004D491C0C.00003247 Message-ID: <4D491C0C.70809@tana.it> Date: Wed, 02 Feb 2011 09:55:40 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: marf@ietf.org References: <20110201201915.63DD3F580C9@smtp.patriot.net> In-Reply-To: <20110201201915.63DD3F580C9@smtp.patriot.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] reporting-discovery X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 08:52:23 -0000 On 01/Feb/11 21:22, Shmuel (Seymour J.) Metz wrote: > In , on > 01/31/2011 > at 03:08 PM, "J.D. Falk" said: >> [report drop boxes is] part of what the Reported-URI field was intended for. > > However, the current wording of 1.1. Purpose seems to rule out that > use > > o email abuse originating from their networks; > > o potential issues with the perceived quality of outbound mail, > such as email service providers sending mail that attracts > the attention of automated abuse detection systems. While the first bullet restricts reported messages to those originating from the networks of a report's recipients, the only hint toward such interpretation in the second bullet lays in the term "outbound". Section 2 of draft-ietf-marf-reporting-discovery repeats the same phrases, and explains how reporting discovery is going to support that purpose. In case the wording in MARF-BASE is misleading, the new I-D should clarify it. For a nit, the I-D "addresses *three* primary use cases", but then only two of them are bulleted. For a core issue, it is a fact that some abuse teams only want reports that concern mail originating from theirs. Thus, we should ask ourselves how prominent the origin of the reported message has to be in reporting discovery. Is it more important than *feedback type*? From shmuel+gen@patriot.net Wed Feb 2 09:05:04 2011 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED4E3A6CEC for ; Wed, 2 Feb 2011 09:05:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnN89cHaJ6Xp for ; Wed, 2 Feb 2011 09:05:03 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 1FF0F3A6C01 for ; Wed, 2 Feb 2011 09:05:02 -0800 (PST) Received: from ECS35455305 (unknown [69.72.27.232]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 2F8DDF580C0 for ; Wed, 2 Feb 2011 12:04:17 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Wed, 02 Feb 2011 12:12:56 -0500 To: marf@ietf.org In-Reply-To: <4D491C0C.70809@tana.it> Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20110202170418.2F8DDF580C0@smtp.patriot.net> Subject: Re: [marf] reporting-discovery X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 17:05:04 -0000 In <4D491C0C.70809@tana.it>, on 02/02/2011 at 09:55 AM, Alessandro Vesely said: >For a core issue, it is a fact that some abuse teams only want >reports that concern mail originating from theirs. Suggesting that the discovery mechanism should have fine enough granularity to allow a consumer to indicate which types of abuse reports they want to receive in ARF format. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From jdfalk-lists@cybernothing.org Wed Feb 2 10:24:58 2011 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C9E73A6DBD for ; Wed, 2 Feb 2011 10:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7Z5ftz3INwT for ; Wed, 2 Feb 2011 10:24:57 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 30B343A6DBB for ; Wed, 2 Feb 2011 10:24:57 -0800 (PST) Received: from [192.168.11.35] (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 p12ISDBu016298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 2 Feb 2011 10:28:16 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: "J.D. Falk" In-Reply-To: Date: Wed, 2 Feb 2011 10:28:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <88020014-68DC-4C64-B7A5-DE5DB1F2E53E@cybernothing.org> References: <20CD3804-8E61-4B88-A65E-ADFD41467051@eudaemon.net> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1082) Subject: Re: [marf] comments on DKIM Reporting draft X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 18:24:58 -0000 On Jan 31, 2011, at 7:54 PM, Murray S. Kucherawy wrote: >> AFAICT, this draft is actually 5 separate documents rolled up into = one: >>=20 >> 1. DKIM reporting extensions >> 2. ADSP reporting extensions >> 3. SPF reporting extensions >> 4. ARF auth-failure extensions >> 5. ARF "redaction" >=20 > I'd hate to have to split it into five individual documents (and I = think our AD might too) but I will if that appears to be the right path. = Would anyone be interested in taking up document editor roles should = such a split occur? I could help with the DKIM, ADSP, and/or ARF portions; I don't know SPF = well enough. As for whether the split is necessary...it'd certainly be easier for = someone who is only implementing DKIM, or only implementing SPF (it's = hard to imagine someone implementing ARF auth-failure without also = implementing DKIM or SPF or both.) But it could be frustrating if = someone is implementing them all at once. So, I'm not sure which way to = go. I'm definitely in favor of splitting out the redaction discussion to a = new Informational or BCP document, because I expect that other MARF docs = will reference it often. >> - Lots of real-world SPF records "include:" other records. What if = two >> report-related extensions appear due to the use of include:? >=20 > True, I hadn't thought of this. My gut reaction is to require that = the reporting options within an included record SHOULD (or even MUST) be = ignored. Does it make sense to do that? Hmm. I could imagine a scenario where someone with hundreds of domains = uses the include mechanism to ensure that all of the domains have the = same SPF record, and they'd want reporting to work. Since SPF isn't in = a service record like _spf.example.net, CNAMEs generally aren't an = option. Maybe all we can do is suggest that includes only be followed a few = levels (or is this already in SPF?) >> #5 isn't anything, except maybe a request to supply unique = identifiers >> when supplying #4. Even then there is a whole lot of stuff involved = to >> get across-the-board anonymized identifies deployed across disparate >> systems within a single organization. Maybe this should be carved = out >> as a common unique-anonymized-identifier algorithm that implementors >> should adopt. >=20 > I think I've said elsewhere that the redaction section is something = RFC5965 should've had. We could certainly pull it out and save it for = an RFC5965bis, or put it in its own draft updating RFC5965. What do = others think? I think it should be in its own draft. ARF probably won't be the only = format where a discussion of redaction is appropriate. > There is also discussion in another thread of supporting the IODEF = format. This draft could certainly include that as an option, although = the issue of transport of the IODEF report would have to be covered as = well. This also gets into the overlap between dkim-reporting and = reporting-discovery, which we should probably discuss further. There's no reason the advertisements described in reporting-discovery = couldn't be used for auth-failure reports -- except that the mechanism = for looking up the advertisement in reporting-discovery may use a = different identifier: R-D Report Consumers advertise at: destination of PTR of outbound SMTP server DKIM d=3D R-D Report Generators advertise at: recipient domain (RCPT TO: =3D use = example.com) D-R Report Consumers DKIM d=3D SPF MAIL or HELO Sometimes they'll match, sometimes they won't. Also, it does make sense to tie reporting of authentication to the = authentication-related DNS records rather than creating a new record. From jdfalk-lists@cybernothing.org Wed Feb 2 10:36:51 2011 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21A3A3A6DBF for ; Wed, 2 Feb 2011 10:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0CyacI8Tu7B for ; Wed, 2 Feb 2011 10:36:50 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 31AB43A6DAF for ; Wed, 2 Feb 2011 10:36:50 -0800 (PST) Received: from [192.168.11.35] (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 p12Ie7Vu016419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 2 Feb 2011 10:40:10 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: "J.D. Falk" In-Reply-To: <4D491C0C.70809@tana.it> Date: Wed, 2 Feb 2011 10:40:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110201201915.63DD3F580C9@smtp.patriot.net> <4D491C0C.70809@tana.it> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1082) Subject: Re: [marf] reporting-discovery X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 18:36:51 -0000 On Feb 2, 2011, at 12:55 AM, Alessandro Vesely wrote: > For a core issue, it is a fact that some abuse teams only want reports > that concern mail originating from theirs. Thus, we should ask > ourselves how prominent the origin of the reported message has to be > in reporting discovery. Is it more important than *feedback type*? The identifiers used in reporting-discovery to identify feedback = consumers may be too limited to make dropbox reporting easier than it is = currently. A message referring to a dropbox at yahoo.com won't (in most = cases) be signed by yahoo.com, so you can't be certain of finding the = appropriate advertisement via the DKIM d=3D domain. It also won't (in = most cases) have been sent by an MTA within the Yahoo! ADMD, so you = can't find it via the PTR record of the border MTA. It's /possible/ that the dropbox address's DNS domain (RHS) will be the = same as that DNS domain's d=3D value, but that's not certain. Dropboxes and other identifiers found solely within the message may be = out of scope for reporting-discovery, unless we can think up a way to = make it work. From msk@cloudmark.com Wed Feb 2 11:02:34 2011 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28DD73A6BFB for ; Wed, 2 Feb 2011 11:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.35 X-Spam-Level: X-Spam-Status: No, score=-103.35 tagged_above=-999 required=5 tests=[AWL=-0.751, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYpe0k2v9QDs for ; Wed, 2 Feb 2011 11:02:33 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 786593A67B7 for ; Wed, 2 Feb 2011 11:02:33 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 2 Feb 2011 11:05:53 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Wed, 2 Feb 2011 11:05:52 -0800 Thread-Topic: [marf] comments on DKIM Reporting draft Thread-Index: AcvDBveWmgRnw7hbTYi14ZTtXA51WgABMqEA Message-ID: References: <20CD3804-8E61-4B88-A65E-ADFD41467051@eudaemon.net> <88020014-68DC-4C64-B7A5-DE5DB1F2E53E@cybernothing.org> In-Reply-To: <88020014-68DC-4C64-B7A5-DE5DB1F2E53E@cybernothing.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: [marf] comments on DKIM Reporting draft X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 19:02:34 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of J= .D. Falk > Sent: Wednesday, February 02, 2011 10:28 AM > To: Message Abuse Report Format working group > Subject: Re: [marf] comments on DKIM Reporting draft >=20 > >> 1. DKIM reporting extensions > >> 2. ADSP reporting extensions > >> 3. SPF reporting extensions > >> 4. ARF auth-failure extensions > >> 5. ARF "redaction" [as participant] I think my preference given the input so far is to leave (1), (2) and (4) i= n one document since there's already one such implementation out there (gra= nted it's mine; I admit to some bias there). (3) could go out on its own a= s an add-on to that one, and Scott has volunteered to edit that; (5) could = also go out on its own, probably as an informational or an update to RFC596= 5, and I think JD is saying he could take that one. How does that sound, especially to those I've actually named here? :-) From jdfalk-lists@cybernothing.org Wed Feb 2 12:02:38 2011 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C97273A6CEB for ; Wed, 2 Feb 2011 12:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwmhLM8QIS4D for ; Wed, 2 Feb 2011 12:02:38 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id EBD553A6BA9 for ; Wed, 2 Feb 2011 12:02:37 -0800 (PST) Received: from [192.168.11.35] (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 p12K5tT9017890 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 2 Feb 2011 12:05:57 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: "J.D. Falk" In-Reply-To: Date: Wed, 2 Feb 2011 12:05:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3C74FF9D-889D-4E93-BABE-7F569065A9DA@cybernothing.org> References: <20CD3804-8E61-4B88-A65E-ADFD41467051@eudaemon.net> <88020014-68DC-4C64-B7A5-DE5DB1F2E53E@cybernothing.org> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1082) Subject: Re: [marf] comments on DKIM Reporting draft X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 20:02:38 -0000 On Feb 2, 2011, at 11:05 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of J.D. Falk >> Sent: Wednesday, February 02, 2011 10:28 AM >> To: Message Abuse Report Format working group >> Subject: Re: [marf] comments on DKIM Reporting draft >>=20 >>>> 1. DKIM reporting extensions >>>> 2. ADSP reporting extensions >>>> 3. SPF reporting extensions >>>> 4. ARF auth-failure extensions >>>> 5. ARF "redaction" >=20 > [as participant] >=20 > I think my preference given the input so far is to leave (1), (2) and = (4) in one document since there's already one such implementation out = there (granted it's mine; I admit to some bias there). (3) could go out = on its own as an add-on to that one, and Scott has volunteered to edit = that; (5) could also go out on its own, probably as an informational or = an update to RFC5965, and I think JD is saying he could take that one. >=20 > How does that sound, especially to those I've actually named here? = :-) Makes sense to me, assuming there's consensus to split. I'm willing to = become editor of (5). From johnl@iecc.com Wed Feb 2 19:01:28 2011 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2A583A6778 for ; Wed, 2 Feb 2011 19:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.088 X-Spam-Level: X-Spam-Status: No, score=-111.088 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbjTpVm1wk1C for ; Wed, 2 Feb 2011 19:01:27 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 7AE573A65A5 for ; Wed, 2 Feb 2011 19:01:27 -0800 (PST) Received: (qmail 76298 invoked from network); 3 Feb 2011 03:04:48 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 3 Feb 2011 03:04:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=3ff0.4d4a1b50.k1102; i=johnl@user.iecc.com; bh=gLuG4MKUESe8To+6YlFZrcD9qQ47s6cZqz41T2pfG7k=; b=H7f0i0r5dpYH2A7ASTaoi5zFzMCB7nQIjBwqR6vfV45RX4nWVqM5oJoqCCPLRczZ5DAikskJFfA5PP9SkURLjTXx/0CS17bOgVbXV6kcBhmoi+sseN1+cAaeTsGfVZYbsKFqFykoD+8SCRfOJYayEF5SUhLE10storkfmcvaykE= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=3ff0.4d4a1b50.k1102; olt=johnl@user.iecc.com; bh=gLuG4MKUESe8To+6YlFZrcD9qQ47s6cZqz41T2pfG7k=; b=IDifYQM0A1skc+iUzKyyVJmoZEIQZShHHY4VLyve4njsW7shGoKNmHezbRQgLcTfJv5Rlhr9U6LF+ZPHt7aPt736uHbFCCdTJOPk9DNOO5vb3sTDsy283r/GtG8Q1SGszLTo5UnQlZkq78LQzm60E9PNcIuIWeKqze7LJwL0IsE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 3 Feb 2011 03:04:48 -0000 Message-ID: <20110203030448.16367.qmail@joyce.lan> From: John Levine To: marf@ietf.org In-Reply-To: <3C74FF9D-889D-4E93-BABE-7F569065A9DA@cybernothing.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] comments on DKIM Reporting draft X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 03:01:29 -0000 >>>>> 1. DKIM reporting extensions >>>>> 2. ADSP reporting extensions >>>>> 3. SPF reporting extensions >>>>> 4. ARF auth-failure extensions >>>>> 5. ARF "redaction" >> I think my preference given the input so far is to leave (1), (2) >and (4) in one document since there's already one such implementation >out there (granted it's mine; I admit to some bias there). (3) could >go out on its own as an add-on to that one, and Scott has volunteered >to edit that If all the work is going to be done at the same time, I don't see any benefit to splitting out the SPF stuff. It may be a political issue to refer to an experimental RFC, but unless the IESG insists, our readers will prefer to read one document. As far as (5) is concerned, I'm one of the authors of 5965 so I'd be happy to work on it with JD. This seems somewhat independent of the rest since it's equally useful (or not) in existing ARF applications. R's, John From vesely@tana.it Thu Feb 3 09:56:09 2011 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C2CF3A69D9 for ; Thu, 3 Feb 2011 09:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.95 X-Spam-Level: X-Spam-Status: No, score=-4.95 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6GVKoRLZzTa for ; Thu, 3 Feb 2011 09:56:07 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id ADA4C3A698E for ; Thu, 3 Feb 2011 09:56:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1296755964; bh=YQclEcjlaxEYN/6lm6Y+dGV4nDbqzC8X9vSILQxj6pk=; l=2177; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=DLZOVaROigzjEY6QSvo4Yp7bM4BNFHC+LjQkiC1NvYLQBD2d/ititLbKUU43bF1Vp pn3YQyOEWm7B2zLNJWslpndOgx4TykxQ2SWRXzt+I17f/kcz19pP9rKpPO5M7iPGFC nBlx1u4Ls8u2aKjD4i4EZlHVSkMKdHdrKuJ8Z4rc= 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; Thu, 03 Feb 2011 18:59:24 +0100 id 00000000005DC04F.000000004D4AECFC.00007DA3 Message-ID: <4D4AECFC.2040309@tana.it> Date: Thu, 03 Feb 2011 18:59:24 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "J.D. Falk" References: <20110201201915.63DD3F580C9@smtp.patriot.net> <4D491C0C.70809@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: marf@ietf.org Subject: Re: [marf] reporting-discovery X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 17:56:09 -0000 On 02/Feb/11 19:40, J.D. Falk wrote: > Dropboxes and other identifiers found solely within the message may > be out of scope for reporting-discovery, unless we can think up a > way to make it work. Currently a record can say _report.example.com. IN TXT ( "r=abuse@example.com; rf=ARF; " "rt=abuse,fraud,virus; re=postmaster@example.net;" ) We could add a tag, say, ro= (o for *origin* of the reported message), and possibly go= for generators. The values would indicate classes of reported messages that are relevant for reporting. For example, classes could be defined like so: *a* reported message is *authenticated* by DKIM, SPF, or other mechanism that proves it originated from the relevant ADMD. *b* reported message is *believed* to originate within the relevant ADMD, as determined by inspecting Received header fields, rDNS, block assignments, and similar ways. *c* reported message is *crap* with the Return-Path and/or From header fields abusively referencing the relevant ADMD. (Hey, this is just an example!) *d* reported message has a *dropbox* in its text, or in the From or Reply-To header fields, referencing a seemingly existing address in the relevant ADMD. For report consumers, the relevant ADMD is the target domain. Thus, by _report.example.com. IN TXT ( "r=abuse@example.com; rf=ARF; " "ro=ad; re=postmaster@example.net;" ) example.com would state that they are interested in records about messages that authentically originated from theirs, or that deploy dropboxes related to them. Note that the latter example omits rt=. We could argue that frauds are probably related with dropboxes, or that reporting abuse is only interesting for messages originating from the relevant ADMD. However, imposing more semantics on the feedback-type doesn't seem to be viable. Hence we add a new classification that is suitable for reporting discovery. Would we still need feedback-type, then? If not, then the new classification would also solve the problem of adding other rf=, like IODEF, whose types are different from those of ARF. From yigang.cai@alcatel-lucent.com Wed Feb 23 08:18:29 2011 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D83A3A67A1 for ; Wed, 23 Feb 2011 08:18:29 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLrEXtwzAuKm for ; Wed, 23 Feb 2011 08:18:28 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 6B2BE3A68AC for ; Wed, 23 Feb 2011 08:18:28 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p1NGJFhu001536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 23 Feb 2011 10:19:15 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p1NGJ2NY025278 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 23 Feb 2011 10:19:15 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Wed, 23 Feb 2011 10:19:12 -0600 From: "Cai, Yigang (Yigang)" To: "marf@ietf.org" Date: Wed, 23 Feb 2011 10:19:11 -0600 Thread-Topic: A New Intenet Draft to MARF - "draft-cai-marf-policy-instruction-operation-00.txt" Thread-Index: AcvS5WsKkianw0x0QH2zkfHAw9zxSQAj39tg Message-ID: <5710F82C0E73B04FA559560098BF95B12506885A58@USNAVSXCHMBSA3.ndc.alcatel-lucent.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: [marf] A New Intenet Draft to MARF - "draft-cai-marf-policy-instruction-operation-00.txt" X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 16:18:29 -0000 Dear All, See below a new internet draft submitted by Alcatel-Lucent for MARF working= group. Thanks, Yigang =20 -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Tuesday, February 22, 2011 5:08 PM To: Zeltsan, Zachary (Zachary) Cc: Cai, Yigang (Yigang); Shanker, Gyan (Gyan); Singh, Sanjeev Kumar (Sanje= ev); Torabi, Mohammad (Moh) Subject: New Version Notification for draft-cai-marf-policy-instruction-ope= ration-00=20 A new version of I-D, draft-cai-marf-policy-instruction-operation-00.txt ha= s been successfully submitted by Zachary Zeltsan and posted to the IETF rep= ository. Filename: draft-cai-marf-policy-instruction-operation Revision: 00 Title: Anti-Spam Policy Instruction/Distribution Operation Creation_date: 2011-02-23 WG ID: Independent Submission Number_of_pages: 26 Abstract: This document defines an anti-spam policy instruction and distribution oper= ation from Spam Reporting Server or Spam Reporting Client to Spam Reporting= Client or Clients. = =20 The IETF Secretariat. From yigang.cai@alcatel-lucent.com Wed Feb 23 08:23:57 2011 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FF613A67A1 for ; Wed, 23 Feb 2011 08:23:57 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNcx6nVw0L7b for ; Wed, 23 Feb 2011 08:23:56 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id A1BD43A690A for ; Wed, 23 Feb 2011 08:23:56 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p1NGOg3P006770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 23 Feb 2011 10:24:42 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p1NGOgBH021400 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 23 Feb 2011 10:24:42 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Wed, 23 Feb 2011 10:24:42 -0600 From: "Cai, Yigang (Yigang)" To: "marf@ietf.org" Date: Wed, 23 Feb 2011 10:24:41 -0600 Thread-Topic: A New Intenet Draft to MARF - "draft-cai-marf-policy-instruction-operation-00.txt" Thread-Index: AcvS5WsKkianw0x0QH2zkfHAw9zxSQAj39tgAABHtYA= Message-ID: <5710F82C0E73B04FA559560098BF95B12506885A6D@USNAVSXCHMBSA3.ndc.alcatel-lucent.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [marf] A New Intenet Draft to MARF - "draft-cai-marf-policy-instruction-operation-00.txt" X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 16:23:57 -0000 Dear All, Please see the URL of this new internet draft: https://datatracker.ietf.org/doc/draft-cai-marf-policy-instruction-operatio= n/=20 Thanks, Yigang -----Original Message----- From: Cai, Yigang (Yigang)=20 Sent: Wednesday, February 23, 2011 10:19 AM To: marf@ietf.org Subject: A New Intenet Draft to MARF - "draft-cai-marf-policy-instruction-o= peration-00.txt"=20 Dear All, See below a new internet draft submitted by Alcatel-Lucent for MARF working= group. Thanks, Yigang =20 -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tuesday, February 22, 2011 5:08 PM To: Zeltsan, Zachary (Zachary) Cc: Cai, Yigang (Yigang); Shanker, Gyan (Gyan); Singh, Sanjeev Kumar (Sanje= ev); Torabi, Mohammad (Moh) Subject: New Version Notification for draft-cai-marf-policy-instruction-ope= ration-00=20 A new version of I-D, draft-cai-marf-policy-instruction-operation-00.txt ha= s been successfully submitted by Zachary Zeltsan and posted to the IETF rep= ository. Filename: draft-cai-marf-policy-instruction-operation Revision: 00 Title: Anti-Spam Policy Instruction/Distribution Operation Creation_date: 2011-02-23 WG ID: Independent Submission Number_of_pages: 26 Abstract: This document defines an anti-spam policy instruction and distribution oper= ation from Spam Reporting Server or Spam Reporting Client to Spam Reporting= Client or Clients. = =20 The IETF Secretariat. From msk@cloudmark.com Thu Feb 24 05:55:34 2011 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464C13A6B31 for ; Thu, 24 Feb 2011 05:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.598 X-Spam-Level: X-Spam-Status: No, score=-104.598 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzV5pdLW+FM3 for ; Thu, 24 Feb 2011 05:55:30 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 2BD433A6B2F for ; Thu, 24 Feb 2011 05:55:30 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 24 Feb 2011 05:56:19 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 24 Feb 2011 05:56:18 -0800 Thread-Topic: Feedback Loops BCP document Thread-Index: AcvUKpx97/oAbxRhRU2tMdzdCEW8jw== 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_F5833273385BB34F99288B3648C4F06F1341E74466EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] Feedback Loops BCP document X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 13:55:34 -0000 --_000_F5833273385BB34F99288B3648C4F06F1341E74466EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, One of our chartered items, and one that's very much past due, is a "best p= ractices" document about feedback loops. JD has submitted a draft that is an I-D version of the MAAWG BCP document (= draft-jdfalk-maawg-cfblbcp). The MAAWG board would like to retain change c= ontrol for now and thus is seeking to progress the document along the Indep= endent Submission path. However, they are also aware that a faster path to= publication would be collaboration with MARF. I would like this group to review the draft and determine how much we agree= with it and would like to have it as an IETF BCP product of MARF. If ther= e are major topics that are absent or with which we disagree, we need to bu= ild that list. Once that's done, we can negotiate with MAAWG whether or no= t we want to incorporate our proposed changes into their version, or use th= eir document as a basis for our own (with, of course, appropriate attributi= ons). Please review the draft and submit comments. Ideally this would be a discu= ssion item in Prague. Thanks, -MSK --_000_F5833273385BB34F99288B3648C4F06F1341E74466EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

One of= our chartered items, and one that’s very much past due, is a “= best practices” document about feedback loops.

 

JD has submitted a d= raft that is an I-D version of the MAAWG BCP document (draft-jdfalk-maawg-c= fblbcp).  The MAAWG board would like to retain change control for now = and thus is seeking to progress the document along the Independent Submissi= on path.  However, they are also aware that a faster path to publicati= on would be collaboration with MARF.

 

I would like this group to review th= e draft and determine how much we agree with it and would like to have it a= s an IETF BCP product of MARF.  If there are major topics that are abs= ent or with which we disagree, we need to build that list.  Once that&= #8217;s done, we can negotiate with MAAWG whether or not we want to incorpo= rate our proposed changes into their version, or use their document as a ba= sis for our own (with, of course, appropriate attributions).

=

 

Please revie= w the draft and submit comments.  Ideally this would be a discussion i= tem in Prague.

 

Thanks,

-MSK=

 

= --_000_F5833273385BB34F99288B3648C4F06F1341E74466EXCHC2corpclo_--