From msk@cloudmark.com Fri Jan 7 12:08: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 A08233A694D for ; Fri, 7 Jan 2011 12:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.474 X-Spam-Level: X-Spam-Status: No, score=-103.474 tagged_above=-999 required=5 tests=[AWL=-0.876, 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 MHh--jbSbFfA for ; Fri, 7 Jan 2011 12:08:02 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 2C3D43A6958 for ; Fri, 7 Jan 2011 12:05:09 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 7 Jan 2011 12:07:15 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 7 Jan 2011 12:07:14 -0800 Thread-Topic: Updated DKIM reporting draft Thread-Index: AcuupnoEC1OTcROkQoKih6OByZUUGA== 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_F5833273385BB34F99288B3648C4F06F1341E73D3EEXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] Updated 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: Fri, 07 Jan 2011 20:08:07 -0000 --_000_F5833273385BB34F99288B3648C4F06F1341E73D3EEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, happy new year! I am about to post a revision to the DKIM reporting draft. It has undergon= e some moderate evolution since its original version, partly based on a sma= ll amount of real-world testing (it's been implemented in OpenDKIM and its = antecedent for some time) but also partly based on some substantial contrib= utions of material from others in another forum that I'm shepherding into t= his one. Although the name is draft-ietf-marf-dkim-reporting, it now also contains s= upport for more general authentication failure reporting by enabling the re= porting of SPF-specific data in the report. It also, therefore, changes th= e feedback report type from "dkim" to "auth-failure". A group of implementers have proposed, and I have included, a specific set = of fields that are mandatory in an "auth-failure" report. Most of them we = know already, but a new one is "Delivery-Status" to give some indication of= what happened to the message that's being reported. There is also a section that discusses a proposed standard way to do data r= edaction at a report generator. Simple replacement with a dummy string lik= e "xxxxx" satisfies a report generator's privacy needs but prevents a repor= t consumer from sorting or grouping of reports about a common problem sourc= e. The proposed mechanism covers both things. This is something I'd like = to include in an RFC5965bis effort somewhere down the road. One party that's already seen the draft, whom I hope will pipe up on the li= st once it's posted, has some concerns about the size of the document and t= hus would like us to consider breaking it into a small set of related docum= ents. I'll let that discussion start separately along with any other point= s he may have. We have a chartered deliverable around this work slated for March, so I'd l= ike to see some effort made to bring this to consensus. Thanks, -MSK --_000_F5833273385BB34F99288B3648C4F06F1341E73D3EEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all, happy new year!

 

I am about to post a revision to the DKIM reporting draft.  It has undergone some moderate evolution since its original version, partly based on a small amount of real-world testing (it’s b= een implemented in OpenDKIM and its antecedent for some time) but also partly b= ased on some substantial contributions of material from others in another forum = that I’m shepherding into this one.

 

Although the name is draft-ietf-marf-dkim-reporting, i= t now also contains support for more general authentication failure reporting by = enabling the reporting of SPF-specific data in the report.  It also, therefore, changes the feedback report type from “dkim” to “auth-fai= lure”.

 

A group of implementers have proposed, and I have incl= uded, a specific set of fields that are mandatory in an “auth-failure”= ; report.  Most of them we know already, but a new one is “Deliver= y-Status” to give some indication of what happened to the message that’s being reported.

 

There is also a section that discusses a proposed stan= dard way to do data redaction at a report generator.  Simple replacement wi= th a dummy string like “xxxxx” satisfies a report generator’s privacy needs but prevents a report consumer from sorting or grouping of reports about a common problem source.  The proposed mechanism covers = both things.  This is something I’d like to include in an RFC5965bis effort somewhere down the road.

 

One party that’s already seen the draft, whom I = hope will pipe up on the list once it’s posted, has some concerns about th= e size of the document and thus would like us to consider breaking it into a small set of related documents.  I’ll let that discussion start separately along with any other points he may have.

 

We have a chartered deliverable around this work slate= d for March, so I’d like to see some effort made to bring this to consensus= .

 

Thanks,

-MSK

 

--_000_F5833273385BB34F99288B3648C4F06F1341E73D3EEXCHC2corpclo_-- From Internet-Drafts@ietf.org Fri Jan 7 12:45: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 EBD7E3A6965; Fri, 7 Jan 2011 12:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 c920K8TwQe-A; Fri, 7 Jan 2011 12:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BE7C3A6827; Fri, 7 Jan 2011 12:45:02 -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.10 Message-ID: <20110107204502.9474.61850.idtracker@localhost> Date: Fri, 07 Jan 2011 12:45:02 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action:draft-ietf-marf-dkim-reporting-01.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: Fri, 07 Jan 2011 20:45:05 -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 : Authentication Failure Reporting using the Abuse Report Format Author(s) : M. Kucherawy, H. Fontana Filename : draft-ietf-marf-dkim-reporting-01.txt Pages : 31 Date : 2011-01-07 This memo presents extensions to the Abuse Reporting Format (ARF), DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-dkim-reporting-01.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-dkim-reporting-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-07123031.I-D@ietf.org> --NextPart-- From vesely@tana.it Sat Jan 8 11:39:25 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 E407228C141 for ; Sat, 8 Jan 2011 11:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=-0.484, 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 0m+BeU065rOF for ; Sat, 8 Jan 2011 11:39:25 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id B4D7828C13D for ; Sat, 8 Jan 2011 11:39:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1294515681; bh=MxBXuFG8AVLratP9/phaw5WScmx9z+J4JOrPZvhbX1s=; l=314; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=YZ83v4iKUN+/Yp42N82IfRccI0w6DFX5IKfATtA19FqnRcDQ3oUYDB9cmjgCv/tAK OI7b6yznB4iTf0Y5IfMn9PssO5GRnMEm4ConVeeqoJHH04xqAg0+c7CVuXpoLvsL9V jLCUBafQL+DGxZtcC4YzWM/qG5T74zCuYMccTc9k= 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; Sat, 08 Jan 2011 20:41:21 +0100 id 00000000005DC035.000000004D28BDE1.00006539 Message-ID: <4D28BDE1.3040602@tana.it> Date: Sat, 08 Jan 2011 20:41:21 +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: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Updated 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: Sat, 08 Jan 2011 19:39:26 -0000 On 07/Jan/11 21:07, Murray S. Kucherawy wrote: > Although the name is draft-ietf-marf-dkim-reporting, it now also > contains support for more general authentication failure reporting by > enabling the reporting of SPF-specific data in the report. I like that. I'll forward the i-d-announce to spf-discuss. From jdfalk-lists@cybernothing.org Mon Jan 10 13:23:56 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 7F8EC3A6812 for ; Mon, 10 Jan 2011 13:23:56 -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 mQWsujl08YkH for ; Mon, 10 Jan 2011 13:23:55 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 54CDD3A6801 for ; Mon, 10 Jan 2011 13:23:55 -0800 (PST) Received: from [192.168.11.38] (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 p0ALQ6cH004901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 10 Jan 2011 13:26:09 -0800 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p0ALQ6cH004901 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1294694769; bh=9PTOQMHA/j1DbCA+2vKKOX4MF7IzRS6fW5PXkRoh7 ng=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=UJxF9qgcjhqu NmHRbZwka1kmXMSZvmVN9VC/frUqEzZgRcn1qtEulDJEv7ECF1e+fBYWvVx4XCurrU6 vIR9m6EAhO66Jya5EqVLOy8BwxiaduEMN6qcVssscnkDf+UPXq2Fvrd1fPFrzLTCRAX 39ukGa3aN8lGySPX8CV7Nu7+Y= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1082) From: "J.D. Falk" In-Reply-To: Date: Mon, 10 Jan 2011 13:26:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1082) Subject: Re: [marf] Updated 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: Mon, 10 Jan 2011 21:23:56 -0000 On Jan 7, 2011, at 12:07 PM, Murray S. Kucherawy wrote: > Although the name is draft-ietf-marf-dkim-reporting, it now also = contains support for more general authentication failure reporting by = enabling the reporting of SPF-specific data in the report. It also, = therefore, changes the feedback report type from =93dkim=94 to = =93auth-failure=94. I think this makes a lot of sense; the same people tend to be interested = in reporting on both, for the same mailstreams. > There is also a section that discusses a proposed standard way to do = data redaction at a report generator. Simple replacement with a dummy = string like =93xxxxx=94 satisfies a report generator=92s privacy needs = but prevents a report consumer from sorting or grouping of reports about = a common problem source. The proposed mechanism covers both things. = This is something I=92d like to include in an RFC5965bis effort = somewhere down the road. This isn't the only draft where there's been a need (or at least a = desire) to discuss redaction -- it seems to be an issue that will follow = ARF around forever. It's written really well here, better than most of = the previous attempts (IMHO). I wonder if it'd make sense to split this = section out into a stand-alone draft on the BCP track? That'll make it = easier to reference from other applicable documents. From jdfalk-lists@cybernothing.org Fri Jan 14 15:10:21 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 E9AD13A67F7 for ; Fri, 14 Jan 2011 15:10:21 -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 diForow1857r for ; Fri, 14 Jan 2011 15:10:20 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id B9E823A6BEB for ; Fri, 14 Jan 2011 15:10:19 -0800 (PST) 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 p0ENCh1v016281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 14 Jan 2011 15:12:45 -0800 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p0ENCh1v016281 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1295046765; bh=I5bxL6fGYhGIKTvCv4pJzFVtMbcvcLjj48OKFmAth 1M=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-Id:To:Mime-Version; b=Nlv8vhBoX5L0nrXvBd4bs7+rBzJtG9ErQcdD 7ra3hiNqhOKLnifYttYXZxmYSVikFNP2inu+GZKrebLUpRdoOIFSzbuPjfJCUGxEE4W vgrwVsA+zMAqzk6KMiw9nAd0WEyE4tKSrcZbhsIcz8Mw8R2/R2liBD280AmKBXQHjcH Q= From: "J.D. Falk" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Jan 2011 15:12:42 -0800 Message-Id: To: Message Abuse Report Format working group Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [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: Fri, 14 Jan 2011 23:10:22 -0000 I've uploaded an updated version of the discovery draft: http://tools.ietf.org/html/draft-jdfalk-marf-reporting-discovery-03 Notable changes since version 02: - Removed references to end-user report submissions; those should be = left for a separate document, and probably be discoverable in the same = way as MUA settings. - Rewrote some confusing parts. - Added the examples section. Remaining questions: - should this include IODEF as a format? - should the advertisement be published somewhere other than DNS? - should this document include a description of how the complaint = feedback signup process works today, and how this proposal would change = it? Or is that a separate Informational document? - should the current Privacy Considerations section be moved to a = separate BCP? - why does the submission tool keep thinking my name is "R. Path?" And, most importantly: is there consensus to make this a WG document? = I'm willing to continue as editor. From vesely@tana.it Sun Jan 16 05:57:11 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 51F193A6D21 for ; Sun, 16 Jan 2011 05:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.859 X-Spam-Level: X-Spam-Status: No, score=-4.859 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_21=0.6, 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 oua6zJu-xR9m for ; Sun, 16 Jan 2011 05:57:10 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 00B213A6B61 for ; Sun, 16 Jan 2011 05:57:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1295186375; bh=+/uJeNRkSHakLWR+wHweqqysYU0O886vm/ZAmIeED2A=; l=1699; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=LWbIUmiI9MZC4W1OECp7/b+oyQgiCyPbGGgEXH1wX62Tky0kKRjh9cPLbkGOPsFEs 600NZAYvDIoioPwQfS6LbC9eZDuGFuPQwr2nnh9qcFiHNgHE8uHco8aAG6kUPK6B8r 8YgVgefVKUvaZg/r/0wjQK2K3TJfoUW9osdFOP2M= 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; Sun, 16 Jan 2011 14:59:35 +0100 id 00000000005DC044.000000004D32F9C7.00002DA0 Message-ID: <4D32F9C7.3080607@tana.it> Date: Sun, 16 Jan 2011 14:59:35 +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, "J.D. Falk" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "Kathleen M. Moriarty" 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: Sun, 16 Jan 2011 13:57:11 -0000 On 15/Jan/11 00:12, J.D. Falk wrote: > http://tools.ietf.org/html/draft-jdfalk-marf-reporting-discovery-03 > > Remaining questions: > > - should this include IODEF as a format? I'd say this would be a Good Thing (TM). However, it is them who should ask for it, and define some details. Perhaps, we should prompt them to do so? (I add a CC, in case.) And what about x-arf? A different report format may imply different transports, thus the I-D may need to specify that r= email addresses are only meant for email transport. More importantly, report types may differ: It is highly desirable that report types use the same words to mean the same type, across any format. Otherwise, the rt should be appended to each rf, e.g. as "rf=ARF:abuse,fraud; rf=IODEF:thraud;". > And, most importantly: is there consensus to make this a WG document? I, for 1, vote for this I-D to become a WG doc. Let me recall it is due by Sep 2011, according to the charter. A few more mumblings, in no particular order: * [MARF-BASE] is now RFC 5965. * We probably should devise a tool that works according to this I-D. (Maybe a command line Perl script that forwards complaints to the relevant ADMD...) * In sections 5.1 and 5.2 a phrase like "The following tags are defined for (Consumers/Generators)" before the relevant tags list, would improve readability. * Shouldn't the default r= be abuse@, rather than postmaster@? * Saying that the default policy is rp=o obviously implies that sending complaints to the default address is fine. Should the I-D explicitly say that those defaults may be assumed even when no DNS record (or whatever) is defined at all? From shmuel+gen@patriot.net Tue Jan 18 05:08: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 BBA893A6F35 for ; Tue, 18 Jan 2011 05:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.993 X-Spam-Level: X-Spam-Status: No, score=0.993 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_12_24=0.992] 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 tlIzqswh1Jum for ; Tue, 18 Jan 2011 05:08:46 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 35F643A6E98 for ; Tue, 18 Jan 2011 05:08:46 -0800 (PST) Received: from ECS35455305 (unknown [208.103.155.85]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 3D832F580BA for ; Tue, 18 Jan 2011 08:07:30 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 17 Jan 2011 09:34:44 -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: <20110118130733.3D832F580BA@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, 18 Jan 2011 13:08:51 -0000 In , on 01/14/2011 at 03:12 PM, "J.D. Falk" said: >And, most importantly: is there consensus to make this a WG document? >I'm willing to continue as editor. It would seem to be in scope. -- 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 msk@cloudmark.com Tue Jan 18 09:35:45 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 8F7253A7021 for ; Tue, 18 Jan 2011 09:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.53 X-Spam-Level: X-Spam-Status: No, score=-103.53 tagged_above=-999 required=5 tests=[AWL=-0.931, 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 nV714w7j42xQ for ; Tue, 18 Jan 2011 09:35:44 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 008533A6FAB for ; Tue, 18 Jan 2011 09:35:40 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 18 Jan 2011 09:38:18 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Tue, 18 Jan 2011 09:38:16 -0800 Thread-Topic: [marf] reporting-discovery Thread-Index: Acu3ETlXIHT8ubUsQmCw1JNKJYsAtwAJTOjg Message-ID: References: <20110118130733.3D832F580BA@smtp.patriot.net> In-Reply-To: <20110118130733.3D832F580BA@smtp.patriot.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: [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: Tue, 18 Jan 2011 17:35:45 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Monday, January 17, 2011 6:35 AM > To: marf@ietf.org > Subject: Re: [marf] reporting-discovery >=20 > In , on > 01/14/2011 > at 03:12 PM, "J.D. Falk" said: >=20 > >And, most importantly: is there consensus to make this a WG document? > >I'm willing to continue as editor. >=20 > It would seem to be in scope. [as participant] +1, and it looks to be a good place from which to start this part of our ch= artered work. From jdfalk-lists@cybernothing.org Tue Jan 18 10:51: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 8F5CB3A7061 for ; Tue, 18 Jan 2011 10:51:02 -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=[AWL=0.000, 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 Oij-0RXLurgo for ; Tue, 18 Jan 2011 10:51:00 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 9394B3A6F0B for ; Tue, 18 Jan 2011 10:51:00 -0800 (PST) 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 p0IIrYYn012508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 18 Jan 2011 10:53:37 -0800 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p0IIrYYn012508 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1295376817; bh=lMxzinS3iwu0rjkusDuKbundoc92ofm7enHfaUi40 gc=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-Id:To:Mime-Version; b=TEHiQglGX+1uMJ66JZhKOam9h09nI27xENDJ TnXFEvcaVHtVhRvEEVZsSgcR35PgnkCuExvTkwqtAqFiT8Jyt7s+2KzQ0n/xIvqLplT ppAHD0XBTjR77qnS1cnfeV2BtaY5YCNs4iR6GRQYjXeW5UTxoLRWoSbAb7+kC5rvl8B w= From: "J.D. Falk" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jan 2011 10:53:34 -0800 Message-Id: <93B515D5-8249-4443-8F30-5FFB15AE9A38@cybernothing.org> To: Message Abuse Report Format working group Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [marf] draft-jdfalk-maawg-cfblbcp 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, 18 Jan 2011 18:51:02 -0000 Last week I finally found time to finish converting the MAAWG Complaint = Feedback Loop Best Common Practices document into IETF format, adding = references and (I think) all of the required sections. http://tools.ietf.org/html/draft-jdfalk-maawg-cfblbcp-00 This is intended to fulfill the informational/BCP goal from the MARF = charter: > 2) The group will produce an informational document detailing > guidelines for deploying and using ARF, including descriptions > of current practices and their rationales. The MAAWG Board has decided that they'd prefer to retain change control. = That doesn't mean MARF is locked out, though -- if there are enough = suggestions to warrant publishing a 2.0 version, I think MAAWG would be = open to it. From msk@cloudmark.com Tue Jan 18 10:59:40 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 91EA23A705C for ; Tue, 18 Jan 2011 10:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.958 X-Spam-Level: X-Spam-Status: No, score=-103.958 tagged_above=-999 required=5 tests=[AWL=-0.359, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 dHDsPxQzofTY for ; Tue, 18 Jan 2011 10:59:39 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id B52AB3A7059 for ; Tue, 18 Jan 2011 10:59:39 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 18 Jan 2011 11:02:16 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Tue, 18 Jan 2011 11:02:15 -0800 Thread-Topic: [marf] draft-jdfalk-maawg-cfblbcp Thread-Index: Acu3QQftLMLBFiijToa3M3RlIv7kygAAOMmw Message-ID: References: <93B515D5-8249-4443-8F30-5FFB15AE9A38@cybernothing.org> In-Reply-To: <93B515D5-8249-4443-8F30-5FFB15AE9A38@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] draft-jdfalk-maawg-cfblbcp 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, 18 Jan 2011 18:59:40 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of J= .D. Falk > Sent: Tuesday, January 18, 2011 10:54 AM > To: Message Abuse Report Format working group > Subject: [marf] draft-jdfalk-maawg-cfblbcp >=20 > Last week I finally found time to finish converting the MAAWG Complaint > Feedback Loop Best Common Practices document into IETF format, adding > references and (I think) all of the required sections. >=20 > http://tools.ietf.org/html/draft-jdfalk-maawg-cfblbcp-00 >=20 > This is intended to fulfill the informational/BCP goal from the MARF > charter: >=20 > > 2) The group will produce an informational document detailing > > guidelines for deploying and using ARF, including descriptions > > of current practices and their rationales. >=20 > The MAAWG Board has decided that they'd prefer to retain change > control. That doesn't mean MARF is locked out, though -- if there are > enough suggestions to warrant publishing a 2.0 version, I think MAAWG > would be open to it. This too should probably become a working group document, though I say that= having not yet read it. :-) I will do so this week as I seem to be neck-= deep in document work anyway. On a procedural point, I think that since MAAWG wishes to retain change con= trol for now, we can only produce an Informational document. That's fine, = I believe, since we won't be held to producing something that holds formal = BCP status in IETF terms. (Barry, do you concur?) From jdfalk-lists@cybernothing.org Tue Jan 18 11:43:55 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 67FA53A6FBE for ; Tue, 18 Jan 2011 11:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 jlBHLx+X8GEV for ; Tue, 18 Jan 2011 11:43:54 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id E18403A6E5D for ; Tue, 18 Jan 2011 11:43:53 -0800 (PST) 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 p0IJkPKP013428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 18 Jan 2011 11:46:28 -0800 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p0IJkPKP013428 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1295379989; bh=s+iHrS31x5Vdz+2mgXOtJUXqQca1udqUxpgmWIeKq 7E=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=eTn7P/3u9lFH O4su2QXoRmguuoE3jVkSy3oK1Xi68BoQe3XST1j8UezswX6Jm14qZgwrH8A12a+RuaR rDlnIHFDsSwvFV9rtm9YkHTO7M4tMB8cTQEc2Zt/BL629FOIBJh2G8v/lfJpKmDFmnG nk5tP5mKU4WnQgIku+KIgGyuM= Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "J.D. Falk" In-Reply-To: <4D32F9C7.3080607@tana.it> Date: Tue, 18 Jan 2011 11:46:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D32F9C7.3080607@tana.it> To: Alessandro Vesely X-Mailer: Apple Mail (2.1082) Cc: "Kathleen M. Moriarty" , 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: Tue, 18 Jan 2011 19:43:55 -0000 On Jan 16, 2011, at 5:59 AM, Alessandro Vesely wrote: > On 15/Jan/11 00:12, J.D. Falk wrote: >> http://tools.ietf.org/html/draft-jdfalk-marf-reporting-discovery-03 >>=20 >> Remaining questions: >>=20 >> - should this include IODEF as a format? >=20 > I'd say this would be a Good Thing (TM). However, it is them who > should ask for it, and define some details. Perhaps, we should prompt > them to do so? (I add a CC, in case.) And what about x-arf? The X-ARF authors don't appear to be interested in rejoining the IETF = process, so there's no I-D to refer to. > A different report format may imply different transports, thus the I-D > may need to specify that r=3D email addresses are only meant for email > transport. More importantly, report types may differ: It is highly > desirable that report types use the same words to mean the same type, > across any format. Otherwise, the rt should be appended to each rf, > e.g. as "rf=3DARF:abuse,fraud; rf=3DIODEF:thraud;". Yep, that's what's stopped me from adding IODEF already. Perhaps = someone more familiar with the format could help us figure out how/if to = add it? > * We probably should devise a tool that works according to this I-D. > (Maybe a command line Perl script that forwards complaints to the > relevant ADMD...) Agreed. > * Shouldn't the default r=3D be abuse@, rather than postmaster@? Maybe. I chose postmaster@ because it's required (MUST) for operating a = mail system, but abuse@ may be sufficiently standard by now. Any = thoughts from the rest of the group? > * Saying that the default policy is rp=3Do obviously implies that > sending complaints to the default address is fine. Should the I-D > explicitly say that those defaults may be assumed even when no DNS > record (or whatever) is defined at all? That would impose a requirement that all mail operators accept and = process ARF reports, even if they haven't chosen to participate in any = ARF-related standard. In other words: they'll start getting messages = this weird MIME type they've probably never heard of before, and they'll = probably be annoyed. (Involuntary ARF reporting is also discussed in one of the appendices of = draft-jdfalk-maawg-cfblbcp.) From tony@att.com Tue Jan 18 11:50: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 128983A6EE1 for ; Tue, 18 Jan 2011 11:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 xfuZkckDtyDL for ; Tue, 18 Jan 2011 11:50:57 -0800 (PST) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id C33213A6E5D for ; Tue, 18 Jan 2011 11:50:56 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-10.tower-129.messagelabs.com!1295380413!58430134!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 15213 invoked from network); 18 Jan 2011 19:53:34 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-10.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Jan 2011 19:53:34 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p0IJrtvW031755 for ; Tue, 18 Jan 2011 14:53:55 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p0IJrn3d031572 for ; Tue, 18 Jan 2011 14:53:49 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p0IJrRKk029753 for ; Tue, 18 Jan 2011 14:53:27 -0500 Received: from mailgw1.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p0IJrQWp029621 for ; Tue, 18 Jan 2011 14:53:26 -0500 Received: from [135.70.210.225] (vpn-135-70-210-225.vpn.east.att.com[135.70.210.225]) by maillennium.att.com (mailgw1) with ESMTP id <20110118195325gw1004ll21e> (Authid: tony); Tue, 18 Jan 2011 19:53:26 +0000 X-Originating-IP: [135.70.210.225] Message-ID: <4D35EFB5.8000603@att.com> Date: Tue, 18 Jan 2011 14:53:25 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: marf@ietf.org References: <4D32F9C7.3080607@tana.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Tue, 18 Jan 2011 19:50:58 -0000 From J.D. Falk: >> * Shouldn't the default r= be abuse@, rather than postmaster@? > Maybe. I chose postmaster@ because it's required (MUST) for operating a mail system, but abuse@ may be sufficiently standard by now. Any thoughts from the rest of the group? +1 for abuse@ Tony Hansen From steve@wordtothewise.com Tue Jan 18 11:58:53 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 1FFE03A6FB1 for ; Tue, 18 Jan 2011 11:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.501 X-Spam-Level: X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[AWL=-1.902, 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 7tyIGDcsFUGR for ; Tue, 18 Jan 2011 11:58:51 -0800 (PST) Received: from m.wordtothewise.com (goliath.word-to-the-wise.com [208.187.80.130]) by core3.amsl.com (Postfix) with ESMTP id CDFA63A6E5D for ; Tue, 18 Jan 2011 11:58:51 -0800 (PST) Received: from platter.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id D88652DDD9 for ; Tue, 18 Jan 2011 12:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wordtothewise.com; s=1.wttw; t=1295380889; bh=pnJfEzE6VkI2hueSxCZ1mc12NEESUsc2AxffAnRNJsg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=Tqmbl7ygWXxhq0aizTqFPszkLlwcVQiNedI7z3fmFALF2QNC8bgVMo3uzXtT1wEhV eClV0LncTkUpsLyKYiR09QXjT+EjLhJrPo3WpHvTUJqapUw8vikgokUqjcwxO+SZPq ixOWYzG4n6oFwNZE1mB9Zy+9v9cjH5L+9yLcXGCM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Steve Atkins In-Reply-To: Date: Tue, 18 Jan 2011 12:01:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D32F9C7.3080607@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: Tue, 18 Jan 2011 19:58:53 -0000 On Jan 18, 2011, at 11:46 AM, J.D. Falk wrote: > On Jan 16, 2011, at 5:59 AM, Alessandro Vesely wrote: >=20 >> * Shouldn't the default r=3D be abuse@, rather than postmaster@? >=20 > Maybe. I chose postmaster@ because it's required (MUST) for operating = a mail system, but abuse@ may be sufficiently standard by now. Any = thoughts from the rest of the group? re=3D, I'm guessing, not r=3D? If so, +1 for abuse@.=20 Cheers, Steve= From tk@abusix.org Tue Jan 18 12:21:30 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 8BC893A7078 for ; Tue, 18 Jan 2011 12:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 8hzuWcvBPOxq for ; Tue, 18 Jan 2011 12:21:27 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id E34893A7067 for ; Tue, 18 Jan 2011 12:21:26 -0800 (PST) Received: by eyd10 with SMTP id 10so10955eyd.31 for ; Tue, 18 Jan 2011 12:24:04 -0800 (PST) Received: by 10.14.47.140 with SMTP id t12mr5338127eeb.19.1295382242840; Tue, 18 Jan 2011 12:24:02 -0800 (PST) Received: from imini.local (pinky.abusix.org [83.169.54.8]) by mx.google.com with ESMTPS id t50sm4863472eeh.0.2011.01.18.12.24.01 (version=SSLv3 cipher=RC4-MD5); Tue, 18 Jan 2011 12:24:01 -0800 (PST) Sender: Tobias Knecht Message-ID: <4D35F6DC.9070409@abusix.com> Date: Tue, 18 Jan 2011 21:23:56 +0100 From: Tobias Knecht Organization: abusix User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: marf@ietf.org References: <4D32F9C7.3080607@tana.it> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCFF440568EF716D05AF53A40" Subject: Re: [marf] reporting-discovery X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tk@abusix.com 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, 18 Jan 2011 20:21:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCFF440568EF716D05AF53A40 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello everybody, > The X-ARF authors don't appear to be interested in rejoining the IETF > process, so there's no I-D to refer to. Sorry for the confused question? Which IETF process? The ARF one or the process about reporting-discovery? At the moment we do not have too much to say about the ARF process. We are using ARF for spam reports and that's what it's made for. We are using x-arf for everything else. Unfortunately there was not much movement in the development of x-arf in the last weeks, but this will change soon. Again, if there is somebody interested in xarf. Having ideas, wants to implement it, let me know and we can subscribe you to our mailinglist. About the reporting-discovery draft: I like the idea, even though it is not fitting in our thinking of "global reporting". Never the less I think it would be nice for x-arf being part of it. Thanks, Tobias --=20 abusix --------------enigCFF440568EF716D05AF53A40 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk019t8ACgkQX1iWbSWuwmyM4ACgjOgoQSoIkoCjkVAGMdst3F1F S7UAniVweCx1Wj39cgboo/FRg8v21hkO =g+nC -----END PGP SIGNATURE----- --------------enigCFF440568EF716D05AF53A40-- From sm@resistor.net Tue Jan 18 13:55: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 823CA3A6F58 for ; Tue, 18 Jan 2011 13:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.64 X-Spam-Level: X-Spam-Status: No, score=-103.64 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 tBc0XijCI+jH for ; Tue, 18 Jan 2011 13:55:24 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 77FF53A6F5D for ; Tue, 18 Jan 2011 13:55:24 -0800 (PST) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id p0ILvpFA027002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 13:57:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1295387881; x=1295474281; bh=Y6/uiHBxYYZX2fSh4Q+nAAjLPlqHhyy2pIvVgRnvCx4=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=erdudEBE+ve2iWeq2wtqAXlJ85FDHiN44y3+y53dWLSqJsdHrbQCo6iqfOlqZsq3w E+0igVotR5hcoBT0R7W1E/gsPlUN9B6fIDIWGOG/SII8FhT3zScYwuWEILQW6r1eFL i4mcSgW0gvIj1l2NR0T14hXJvDJ8kNCCzPrIoBgg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1295387881; x=1295474281; bh=Y6/uiHBxYYZX2fSh4Q+nAAjLPlqHhyy2pIvVgRnvCx4=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=xjAR4NI90rmDZRv0gTLjEEv+cMLajLEWYlxce5gGi4Nrc0A9OMXeBEt3JWdbDv4jf GCbHhDeZHqpWT6SWSTRAsLHjzbgbP/Lk76cLnygsCxdNhsjGBK7CWQyr6ZwFrQ5tFB FjfA84dGOsuzTo8CH/kXFfbIH9E4C+W2MrUqyQJ0= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=aktxVd2eK2FOlr7s11GMsXaFMwTllR/zE70uVYWQf9F+9t96kqdulMQbMTS3ZJvP5 xqn07PV41nzbo6QwFwe7ViXioKMrxjIIwPDhXia1D74QhVwOkm0D8jKdmcE5a31cAk9 QJIkRY9OPKf3q+2gXTvLKVbgIXg3UHyzzRDa4iY= Message-Id: <6.2.5.6.2.20110118135009.0e142378@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 18 Jan 2011 13:56:33 -0800 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: <93B515D5-8249-4443-8F30-5FFB15AE9A38@cybernothing.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Message Abuse Report Format working group Subject: Re: [marf] draft-jdfalk-maawg-cfblbcp 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, 18 Jan 2011 21:55:28 -0000 Hi Murray, At 11:02 18-01-11, Murray S. Kucherawy wrote: >On a procedural point, I think that since MAAWG wishes to retain >change control for now, we can only produce an Informational >document. That's fine, I believe, since we won't be The IETF has change control over draft-jdfalk-maawg-cfblbcp-00. There isn't any procedural restrictions on publishing a revision of that draft as a BCP. Regards, -sm From johnl@iecc.com Tue Jan 18 19:53: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 3B32F28C116 for ; Tue, 18 Jan 2011 19:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.06 X-Spam-Level: X-Spam-Status: No, score=-111.06 tagged_above=-999 required=5 tests=[AWL=0.139, 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 QQp8vpytcppu for ; Tue, 18 Jan 2011 19:53:28 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 00B0928C101 for ; Tue, 18 Jan 2011 19:53:27 -0800 (PST) Received: (qmail 45324 invoked from network); 19 Jan 2011 03:56:06 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 19 Jan 2011 03:56:06 -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=c582.4d3660d6.k1101; i=johnl@user.iecc.com; bh=R2GR4LbW2xyae0VED2yqVeyBnBWF/H58cXjf8dO2748=; b=B0xQrB2WdxNcoUBszP20ksM8braIAq67rw/cyHm/XcyW2OunD0aP8puDckm/y+8tIxvfrt2HkYFh+SFIu810mOfsfV+8GFbnd2uF9ODfrZMl0QtyqyKIrtKEAHi2E6aCnPCO8cIkraEpdtToK1nfp4AlQTq9nJHOtgSXGHAr2Lc= 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=c582.4d3660d6.k1101; olt=johnl@user.iecc.com; bh=R2GR4LbW2xyae0VED2yqVeyBnBWF/H58cXjf8dO2748=; b=pq7x1HO9ZDd8D+KYe+LywKBRCoPk7dwk4j0BOCC26cX0paZE8ZVuWfOucTOhGNslNe1QAnAmw6EXJqKkfVlX2l75H7i20xpdwXC0sQjTgBbIHqqh7rRf0NUUuDyEOQSEulR2r59ndOeFU8eCSI8YaGPV2NafCI8UInGP8DwQU2Y= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 19 Jan 2011 03:56:06 -0000 Message-ID: <20110119035606.50561.qmail@joyce.lan> From: John Levine To: marf@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: [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, 19 Jan 2011 03:53:29 -0000 >> * Shouldn't the default r= be abuse@, rather than postmaster@? >Maybe. I chose postmaster@ because it's required (MUST) for >operating a mail system, but abuse@ may be sufficiently standard by >now. Any thoughts from the rest of the group? Mr. Abuse.net says that default to postmaster doesn't work very well. Why not make the full e-mail address mandatory? If you're going to go to the trouble to publish a _report record, it's really not an undue burden to require that you tell people where the reports should go. I sent some notes about the security section, so you can consider them included by reference here. R's, John From barryleiba.mailing.lists@gmail.com Tue Jan 18 20:10:39 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 1CEC628C126 for ; Tue, 18 Jan 2011 20:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.761 X-Spam-Level: X-Spam-Status: No, score=-102.761 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 26ob2PvsQGha for ; Tue, 18 Jan 2011 20:10:36 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id F27FA28C101 for ; Tue, 18 Jan 2011 20:10:34 -0800 (PST) Received: by iyi42 with SMTP id 42so378264iyi.31 for ; Tue, 18 Jan 2011 20:13:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=k+g2J0lFzlRmy4E9QHcATcq7O+tjQwT1wfeelRTnbIE=; b=JQKOrFt1oHMMBhb7ZK9NEaYOJMH6aVW6SGkVkxpGrYf7S4fExzncsOP7wmblBg9wT1 kr8FjQGE8JlVZLhvN0agqWfsllWs2qGHPatD3IM9qGey0vt3OFi70TziK3rXsybqqXG7 p2muUIFA98fnY8olBGzFyuvbWxDLBH019qWXI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Y4TMV1Dy2glimC9eGgQ/JDRUoTRwZ/iMvHFUKesjWM4jnPTzJEFcHBm7wNIIJzpjZO AxwbuRi1kMEs1+YMCwIEy5VfTd3UpVJKeE5h3CGdtAWjTffX1JY72t3l0zLup2yeO5bZ 6r0BEV9CK5RgXOlq4/SlV8EtJyoIa1X1lNXTQ= MIME-Version: 1.0 Received: by 10.42.218.200 with SMTP id hr8mr201130icb.219.1295410393905; Tue, 18 Jan 2011 20:13:13 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.42.227.193 with HTTP; Tue, 18 Jan 2011 20:13:13 -0800 (PST) In-Reply-To: <6.2.5.6.2.20110118135009.0e142378@resistor.net> References: <93B515D5-8249-4443-8F30-5FFB15AE9A38@cybernothing.org> <6.2.5.6.2.20110118135009.0e142378@resistor.net> Date: Tue, 18 Jan 2011 23:13:13 -0500 X-Google-Sender-Auth: uryTtmr3jKxrle70VD2q0VMVSnE Message-ID: From: Barry Leiba To: SM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Message Abuse Report Format working group Subject: Re: [marf] draft-jdfalk-maawg-cfblbcp 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, 19 Jan 2011 04:10:39 -0000 >> On a procedural point, I think that since MAAWG wishes to retain change >> control for now, we can only produce an Informational document. =A0That'= s >> fine, I believe, since we won't be > > The IETF has change control over draft-jdfalk-maawg-cfblbcp-00. =A0There = isn't > any procedural restrictions on publishing a revision of that draft as a B= CP. SM, I have NO idea what you're trying to say here; no interpretations I can come up with seem to make sense. Barry From barryleiba.mailing.lists@gmail.com Tue Jan 18 20:18: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 46AC128C133 for ; Tue, 18 Jan 2011 20:18:02 -0800 (PST) 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.214, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 Khb-S3MUZGnI for ; Tue, 18 Jan 2011 20:18:01 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 675AD28C12E for ; Tue, 18 Jan 2011 20:18:01 -0800 (PST) Received: by iwn40 with SMTP id 40so402295iwn.31 for ; Tue, 18 Jan 2011 20:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iOV2pmvUN9UjwXFPJOomVfY740MuUd6qCuDGSgJfa3Q=; b=OoR2FDyDzo1Uo3cm4C5CK4LbOQKafNkRHE2M6CFe2MIUOlDpdo4D7yb0aDYUSA6PLO 079gWXUitAaIgUAFLcFqFcgNtWVYLuHCqpiiwjRj9xo+1JgNBaeon95dbvfsY8SxzIyX IUnUjEcQcM1dvsqLGetAawsf08Vh45Lb5njUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=LN6YQji+coiVn/Ar0LvZP+90KOld1WslQC6E3KmZMY/8Af5IkXEhigMp4BlB7GujQw M4yi/tOuQkZ6UhEOQHIdqgThEm/tzjfV5NVv5oF6IqNY5lycU6WlJZujYMy7TydUQA+7 bpgNLM4TVxb2FRRrkvI+EU3LVVOvvjYgcLS7w= MIME-Version: 1.0 Received: by 10.42.218.200 with SMTP id hr8mr207517icb.219.1295410840133; Tue, 18 Jan 2011 20:20:40 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.42.227.193 with HTTP; Tue, 18 Jan 2011 20:20:40 -0800 (PST) In-Reply-To: References: <93B515D5-8249-4443-8F30-5FFB15AE9A38@cybernothing.org> Date: Tue, 18 Jan 2011 23:20:40 -0500 X-Google-Sender-Auth: gsI44oSNmykYYSquzZVZTP54uTw Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Message Abuse Report Format working group Subject: Re: [marf] draft-jdfalk-maawg-cfblbcp 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, 19 Jan 2011 04:18:02 -0000 >> This is intended to fulfill the informational/BCP goal from the MARF >> charter: >> >> > =A0 2) The group will produce an informational document detailing >> > =A0 guidelines for deploying and using ARF, including descriptions >> > =A0 of current practices and their rationales. >> >> The MAAWG Board has decided that they'd prefer to retain change >> control. =A0That doesn't mean MARF is locked out, though -- if there are >> enough suggestions to warrant publishing a 2.0 version, I think MAAWG >> would be open to it. > > This too should probably become a working group document, though I say th= at having > not yet read it. =A0:-) =A0I will do so this week as I seem to be neck-de= ep in document > work anyway. No... if MAAWG wants to retain change control, that means I should help JD send it through the Independent Submission stream. It can't be a working-group document if the working group doesn't have change control. That said, as JD points out, it's fine for the working group to discuss it and make comments, which MAAWG might choose to accept. As to the charter item (which was due in September), the working group can formally choose to 1. abandon it after the MAAWG document is published, because we decide that the MAAWG document says what we want to say, or 2. write an informational document that cites the MAAWG document and says whatever we want to say that's different. Or, of course, we can completely ignore the MAAWG document and produce our own. I don't recommend that, but it is the working group's decision. Barry From barryleiba.mailing.lists@gmail.com Tue Jan 18 20:21:00 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 4DD183A7028 for ; Tue, 18 Jan 2011 20:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.765 X-Spam-Level: X-Spam-Status: No, score=-102.765 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 HK9E5RGvDECY for ; Tue, 18 Jan 2011 20:20:59 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 1EAA93A6EEF for ; Tue, 18 Jan 2011 20:20:59 -0800 (PST) Received: by iyi42 with SMTP id 42so384481iyi.31 for ; Tue, 18 Jan 2011 20:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8dBq53Om4w/jqEveLMe9oVghQZtKxVpc2pGsRcBla2U=; b=YzvYS/WT+06gu3s9/sgnPDpYd5hJd2Jt4NhOloqPvBAr6iS3inbiuZuu6GP3gMkQpa 37WsurlPO24x07ya91C8o8n9IS2knwjgnEW+X6ovwAKW9a8jixCx8JKYnNjcvnpaoqie pBiMfmgBXSxolncyFyhKI1/5hOs6OtCqL9ByE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=FEGtKvZQKw4Rk5wdlKuZvIxf4WsCqhpBSUOmBnds6vUvGkT6q2QQyB9jBOcOAAZido e1d+K0gzS9KN32UlSjdFU06K0skNNQM4YA8nbyWZSLWlF6KOBItt9T7P4XoZY46E8XfZ WNSAbPHEwIFwZBw2wWXA1a45gXrgrfZCJ7s88= MIME-Version: 1.0 Received: by 10.42.170.200 with SMTP id g8mr224447icz.85.1295411017998; Tue, 18 Jan 2011 20:23:37 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.42.227.193 with HTTP; Tue, 18 Jan 2011 20:23:37 -0800 (PST) In-Reply-To: <20110119035606.50561.qmail@joyce.lan> References: <20110119035606.50561.qmail@joyce.lan> Date: Tue, 18 Jan 2011 23:23:37 -0500 X-Google-Sender-Auth: jbtsRbvSaDmS-yF6_nGtkzZUF8k Message-ID: From: Barry Leiba To: John Levine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Wed, 19 Jan 2011 04:21:00 -0000 > Why not make the full e-mail address mandatory? =A0If you're going to go > to the trouble to publish a _report record, it's really not an undue > burden to require that you tell people where the reports should go. I agree. There doesn't need to be a default. Barry, as participant From sm@resistor.net Tue Jan 18 23:38: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 C35A03A6F90 for ; Tue, 18 Jan 2011 23:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.639 X-Spam-Level: X-Spam-Status: No, score=-103.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 EdILUu7zm9Kl for ; Tue, 18 Jan 2011 23:38:06 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 7AF323A6F75 for ; Tue, 18 Jan 2011 23:38:06 -0800 (PST) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id p0J7dmca000852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 23:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1295422842; x=1295509242; bh=mfc23NuQDUxX9VFGZJ8UrPIzp1DiE7LVws/hPYENwy4=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=nOc/hLZP2bTVeYo/3Jlj0EKlPtVDt7kQ/YCcG8baSCexjl+JQ0evuoQjIV4P1kpOt 5Olm6dfelrwT/6ty+WObcM+AcxTu6Kc5qt1iMIu+fyB+izahT4OlkLvVa741rnZpIL d5YimYzapYEP4VXlCx8nZ9MkCy42BkoQ3xyRcI8E= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1295422842; x=1295509242; bh=mfc23NuQDUxX9VFGZJ8UrPIzp1DiE7LVws/hPYENwy4=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=DN0iVKjutgu17fYyjbZDlndvnsdJDPKl03LNupfaqRP/fD/9u0HsqyFvsaQ21KUnW Pf5dASamO3hlW/q+w/Wk4RVm+0K4qtuMyzmYCPuoGo/pUCd26oHuKkA7pawC4ZEV6H AteB6Uf1ld/BQWfp4S3kaQtU3arVYr1MSTJGA2xY= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=jm6fZNgTDXX85FdWT5Y2eqz3CYdn+DvyC+OltfdC74MVuZjAPk8Q0HWj+MMhz9oXa f8fLhEI93Ikjy0YD7CfUlzDdRTq+hzgF/lGDLH1ZwaLhhvIfinGjAH8Av0Q123atvM2 fdMur6t40yJeAXSq9cS3Nl5lLP64XoqK+5/3FyQ= Message-Id: <6.2.5.6.2.20110118221428.0f94afa0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 18 Jan 2011 22:25:23 -0800 To: Barry Leiba From: SM In-Reply-To: References: <93B515D5-8249-4443-8F30-5FFB15AE9A38@cybernothing.org> <6.2.5.6.2.20110118135009.0e142378@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Message Abuse Report Format working group Subject: Re: [marf] draft-jdfalk-maawg-cfblbcp 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, 19 Jan 2011 07:38:07 -0000 Hi Barry, At 20:13 18-01-11, Barry Leiba wrote: >SM, I have NO idea what you're trying to say here; no interpretations >I can come up with seem to make sense. I'll ask questions based on the message you posted. At 20:20 18-01-11, Barry Leiba wrote: >No... if MAAWG wants to retain change control, that means I should >help JD send it through the Independent Submission stream. It can't >be a working-group document if the working group doesn't have change >control. Does the IETF have change control over draft-jdfalk-maawg-cfblbcp? Can the MARF working group adopt draft-jdfalk-maawg-cfblbcp as a working group document? Regards, -sm From barryleiba@gmail.com Wed Jan 19 06:11:10 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 CFCB83A713A for ; Wed, 19 Jan 2011 06:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.769 X-Spam-Level: X-Spam-Status: No, score=-102.769 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 sCSO9R4W2p2G for ; Wed, 19 Jan 2011 06:11:02 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id C2AC63A7137 for ; Wed, 19 Jan 2011 06:11:01 -0800 (PST) Received: by iyi42 with SMTP id 42so892980iyi.31 for ; Wed, 19 Jan 2011 06:13:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZTxC2sEvg8XU3HePfEB3Xjc+T6yZ4VyzWCWziN15j08=; b=uuqpKNlxIBeABPcoUmoFpwY+ArpTGUYXUFlZSDSCv2xn+xcX63MqsKb8nlTz3yUeBe 0K6KHCqVBmBG9QYohQjKLGZWvQYnDF1FpEPWa6nsHBo2LtRUYDr/xzViT0Or1tXt6+id cqS7YLfHDntCNROOEYScDF1tmowQkbyOvcLM4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=T1s39hS7K/NXqINvqDvbTjdMO9oEdidJJmlDYZhI7/bnSsgYF5C5a2PB7gPuKTcEUD YZsQ7e6Yo7HKmyqiNEAEdWF7xYpbcHHc0KelBeq0NEJje8ouIkw56bMC1qNdzz8cdAYR vVQy9P3BFUJVtkdpz61eUICsJuLXXeWaykbsI= MIME-Version: 1.0 Received: by 10.231.11.204 with SMTP id u12mr876222ibu.109.1295446421605; Wed, 19 Jan 2011 06:13:41 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.231.208.12 with HTTP; Wed, 19 Jan 2011 06:13:41 -0800 (PST) In-Reply-To: <6.2.5.6.2.20110118221428.0f94afa0@resistor.net> References: <93B515D5-8249-4443-8F30-5FFB15AE9A38@cybernothing.org> <6.2.5.6.2.20110118135009.0e142378@resistor.net> <6.2.5.6.2.20110118221428.0f94afa0@resistor.net> Date: Wed, 19 Jan 2011 09:13:41 -0500 X-Google-Sender-Auth: e-V6SyOUcS-Kb1ZzHX2_ii7OHsU Message-ID: From: Barry Leiba To: SM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Message Abuse Report Format working group Subject: Re: [marf] draft-jdfalk-maawg-cfblbcp 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, 19 Jan 2011 14:11:11 -0000 >> No... if MAAWG wants to retain change control, that means I should >> help JD send it through the Independent Submission stream. =A0It can't >> be a working-group document if the working group doesn't have change >> control. > > Does the IETF have change control over draft-jdfalk-maawg-cfblbcp? > > Can the MARF working group adopt draft-jdfalk-maawg-cfblbcp as a working > group document? As long as a draft belongs to an individual, the individual (JD, in this case) has change control. If the working group asks him to make a change to it, and he does, that's his prerogative. If he does not, that's also his prerogative. If he agrees to turn it over to the working group, and the working group accepts it, then he'd be agreeing to give change control to the working group. If he remains the editor, that would mean he'd be agreeing to make changes that the working group consensus supports. If he should refuse, the chairs could replace him as editor. The working group can not adopt a document that it does not have change control over. When we give the document to the IESG, community last call, directorate reviews, and AD DISCUSS positions may require changes that the author is unwilling to make. With the Independent Stream, it's just between the author and the ISE. The ISE may refuse to publish it, or the author may withdraw it. In any case, it does not represent IETF consensus, and the boilerplate says as much. Barry From shmuel+gen@patriot.net Wed Jan 19 08:19:44 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 9BC9A3A7010 for ; Wed, 19 Jan 2011 08:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.803 X-Spam-Level: X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[AWL=1.796, 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 B6p4oLriZ4iE for ; Wed, 19 Jan 2011 08:19:43 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 351323A6F49 for ; Wed, 19 Jan 2011 08:19:43 -0800 (PST) Received: from ECS35455305 (unknown [208.103.155.174]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 10E97F5808A for ; Wed, 19 Jan 2011 11:18:41 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Wed, 19 Jan 2011 10:56:29 -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: <20110119161843.10E97F5808A@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, 19 Jan 2011 16:19:44 -0000 In , on 01/18/2011 at 11:46 AM, "J.D. Falk" said: >Maybe. I chose postmaster@ because it's required (MUST) for >operating a mail system, but abuse@ may be sufficiently standard by >now. Any thoughts from the rest of the group? While RFC 2142 is only informational, I believe that it is appropriate to use it as the basis for the default. Since the default in draft-jdfalk-marf-reporting-discovery-03.txt only applies after the RR is added, I would expect any e-mail admin without an abuse account to explicitly specify the mailbox that he wants the MARF reports sent to. -- 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 Mon Jan 24 14:33:49 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 731A83A69A6 for ; Mon, 24 Jan 2011 14:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 2yXGVZKKla5j for ; Mon, 24 Jan 2011 14:33:48 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 1BE303A6994 for ; Mon, 24 Jan 2011 14:33:48 -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 p0OMafNO016929 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 24 Jan 2011 14:36:43 -0800 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p0OMafNO016929 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1295908603; bh=YiS7JRx3Ifq1yYlTVQCw27bHnNJV3IJtn2gdEvCJR q4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=YhDskeee8V3b 0Z00iPmvbQOS3Fw/gj2Kj9CY+mYkFsyIu/dyUNibUFN0wv9q8Rl7tHfue5vhZi+6gN/ 8gECEegkRspzwPaySrGrULc7EC+yK5Rttoe7w7KYmXc30dgky7MktVlcJWb6Zv9zCpA 6CLU/3ZZ1fXr6rhDM9ztyXR1I= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: "J.D. Falk" In-Reply-To: Date: Mon, 24 Jan 2011 14:36:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3521EDED-6EB4-4C10-A41F-57144587F951@cybernothing.org> References: <93B515D5-8249-4443-8F30-5FFB15AE9A38@cybernothing.org> <6.2.5.6.2.20110118135009.0e142378@resistor.net> <6.2.5.6.2.20110118221428.0f94afa0@resistor.net> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1082) Subject: Re: [marf] draft-jdfalk-maawg-cfblbcp 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: Mon, 24 Jan 2011 22:33:49 -0000 Sorry to send this out and then immediately drop off the 'net for a = week. (Long story.) In any case...yes, the Independent Submission stream was what I was = thinking of. Sorry about that. I knew there was a key phrase I was = missing. I'm hoping, however, that the MARF WG consensus might indicate that this = particular document is sufficient to fulfill our goal of writing a BCP. From jdfalk-lists@cybernothing.org Mon Jan 24 17:16:41 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 2EAE53A69A4 for ; Mon, 24 Jan 2011 17:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 p0Cd39MPq7TM for ; Mon, 24 Jan 2011 17:16:40 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 1A0AD3A699F for ; Mon, 24 Jan 2011 17:16:39 -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 p0P1JXNH019066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 24 Jan 2011 17:19:35 -0800 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p0P1JXNH019066 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1295918375; bh=NNrUnr/WdaHgFdzSsMN9pc6hRhfXDB9XeD6/iMtIQ Ds=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=iN/W4brdQump 5hpNXm0ymXyRtPIC5wkNECPzd3x4rCHu5tkpcvb9rokR5xCY0GosyBvA49vysWmZuXy 23ijf93TmoUrTeg+z4rMJ9Zkd2cJA8q7sPSLp3wghvltzihrPHF+bHXSi2vARoqXBdx ZAyK4mV5mm9JCD0bo1mByHGqo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: "J.D. Falk" In-Reply-To: <20110119161843.10E97F5808A@smtp.patriot.net> Date: Mon, 24 Jan 2011 17:19:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8AFDA06B-4068-4C95-95DD-2243BEA377C3@cybernothing.org> References: <20110119161843.10E97F5808A@smtp.patriot.net> 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: Tue, 25 Jan 2011 01:16:41 -0000 On Jan 19, 2011, at 7:56 AM, Shmuel (Seymour J.) Metz wrote: > In , on > 01/18/2011 > at 11:46 AM, "J.D. Falk" said: >=20 >> Maybe. I chose postmaster@ because it's required (MUST) for >> operating a mail system, but abuse@ may be sufficiently standard by >> now. Any thoughts from the rest of the group? >=20 > While RFC 2142 is only informational, I believe that it is appropriate > to use it as the basis for the default. Since the default in > draft-jdfalk-marf-reporting-discovery-03.txt only applies after the RR > is added, I would expect any e-mail admin without an abuse account to > explicitly specify the mailbox that he wants the MARF reports sent to. I think I'm seeing about equal consensus for making abuse@ the default, = or for having no default and requiring an address. =20 Personally, I'm leaning towards having a default in order to keep the = record small. Any other opinions? And, any additional thoughts on whether to pull this document into the = WG? From jdfalk-lists@cybernothing.org Mon Jan 24 17:21:24 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 151773A6B49 for ; Mon, 24 Jan 2011 17:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 6RaUl7Q4yIWd for ; Mon, 24 Jan 2011 17:21:23 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id D8AFB3A6B46 for ; Mon, 24 Jan 2011 17:21:22 -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 p0P1ODOS019100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 24 Jan 2011 17:24:16 -0800 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p0P1ODOS019100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1295918656; bh=s9H16R+UaxKlq8wPoXdudsxzu+1OAeEf8mYc9gqnM Qo=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=lVOS64NGdVCz EgQ3W/7VW69vJ+4oXvNxDsHEZBA5pIF2BhLQbqlRmdD7Acq6uZ6bZpxo7465PyY66o5 5/QQeLq7uXykGfPkY4BpCIEE5XdqVGbMif66K7qQ+WwMre9USij9c/GVzCVbneUggVQ J1G/rG7g+x9x//hMnObxKua4o= Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "J.D. Falk" In-Reply-To: <4D35F6DC.9070409@abusix.com> Date: Mon, 24 Jan 2011 17:24:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D32F9C7.3080607@tana.it> <4D35F6DC.9070409@abusix.com> To: tk@abusix.com X-Mailer: Apple Mail (2.1082) 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: Tue, 25 Jan 2011 01:21:24 -0000 On Jan 18, 2011, at 12:23 PM, Tobias Knecht wrote: > Hello everybody, >=20 >> The X-ARF authors don't appear to be interested in rejoining the IETF >> process, so there's no I-D to refer to. >=20 > Sorry for the confused question? Which IETF process? The ARF one or = the > process about reporting-discovery? There's a process for extending ARF, but X-ARF hasn't followed that = process, so I'd assumed y'all just weren't interested in making it an = open standard. From msk@cloudmark.com Mon Jan 24 17:21:59 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 0161B3A6B50 for ; Mon, 24 Jan 2011 17:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.96 X-Spam-Level: X-Spam-Status: No, score=-103.96 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 dSudCxEzQpxM for ; Mon, 24 Jan 2011 17:21:58 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 4596B3A6B49 for ; Mon, 24 Jan 2011 17:21:58 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 24 Jan 2011 17:24:54 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Mon, 24 Jan 2011 17:24:52 -0800 Thread-Topic: [marf] reporting-discovery Thread-Index: Acu8Le/w4XJG2C5aTguDX4kYJn4MwQAAJ0xA Message-ID: References: <20110119161843.10E97F5808A@smtp.patriot.net> <8AFDA06B-4068-4C95-95DD-2243BEA377C3@cybernothing.org> In-Reply-To: <8AFDA06B-4068-4C95-95DD-2243BEA377C3@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] 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: Tue, 25 Jan 2011 01:21:59 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of J= .D. Falk > Sent: Monday, January 24, 2011 5:20 PM > To: Message Abuse Report Format working group > Subject: Re: [marf] reporting-discovery >=20 > I think I'm seeing about equal consensus for making abuse@ the default, > or for having no default and requiring an address. >=20 > Personally, I'm leaning towards having a default in order to keep the > record small. >=20 > Any other opinions? [as participant] I'm leaning toward having the default. In the absence of this record, that= 's what most people will do anyway since there's already an RFC that encour= ages it. From steve@wordtothewise.com Mon Jan 24 17:26:30 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 CAACF3A6B4E for ; Mon, 24 Jan 2011 17:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[AWL=-1.268, 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 yPDk3TW7TfJw for ; Mon, 24 Jan 2011 17:26:29 -0800 (PST) Received: from m.wordtothewise.com (goliath.word-to-the-wise.com [208.187.80.130]) by core3.amsl.com (Postfix) with ESMTP id C112A3A6B49 for ; Mon, 24 Jan 2011 17:26:29 -0800 (PST) Received: from platter.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id CDF152E9CB for ; Mon, 24 Jan 2011 17:29:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wordtothewise.com; s=1.wttw; t=1295918965; bh=Zmjc1DZca3QleGDnccz76xqj1dQjL4YhyR7Evnfl11c=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=LU+QeB+SD24i6RBz7BVWLMVx2ajEXdF16BkLbEDyEMtjDUX7DUbD7m75Ef1LlWomC hz0zLaefC9gTY90ceAups6uEmutcGHjI/ljdJPm6iifYmrgpqU8wGHZrNU7Z8l4zG+ o0Wqub5sLW2EAvOSOnGoTqTWjZ38U1YiM6cXOZqk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Steve Atkins In-Reply-To: <8AFDA06B-4068-4C95-95DD-2243BEA377C3@cybernothing.org> Date: Mon, 24 Jan 2011 17:29:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <37A3875F-0184-4DA9-BD0E-AF8326D44325@wordtothewise.com> References: <20110119161843.10E97F5808A@smtp.patriot.net> <8AFDA06B-4068-4C95-95DD-2243BEA377C3@cybernothing.org> 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: Tue, 25 Jan 2011 01:26:30 -0000 On Jan 24, 2011, at 5:19 PM, J.D. Falk wrote: > On Jan 19, 2011, at 7:56 AM, Shmuel (Seymour J.) Metz wrote: >=20 >>=20 >> While RFC 2142 is only informational, I believe that it is = appropriate >> to use it as the basis for the default. Since the default in >> draft-jdfalk-marf-reporting-discovery-03.txt only applies after the = RR >> is added, I would expect any e-mail admin without an abuse account to >> explicitly specify the mailbox that he wants the MARF reports sent = to. >=20 > I think I'm seeing about equal consensus for making abuse@ the = default, or for having no default and requiring an address. =20 >=20 > Personally, I'm leaning towards having a default in order to keep the = record small. Works for me - I don't have a strong preference either way, but the = record size issue does tilt it slightly towards using a default of = abuse@. > Any other opinions? >=20 > And, any additional thoughts on whether to pull this document into the = WG? I think that would be a good thing. Cheers, Steve= From barryleiba.mailing.lists@gmail.com Mon Jan 24 18:26:39 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 80B403A687E for ; Mon, 24 Jan 2011 18:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.81 X-Spam-Level: X-Spam-Status: No, score=-102.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 3Z0Znw8+t0UL for ; Mon, 24 Jan 2011 18:26:38 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 3791E3A6840 for ; Mon, 24 Jan 2011 18:26:38 -0800 (PST) Received: by iwn40 with SMTP id 40so5122558iwn.31 for ; Mon, 24 Jan 2011 18:29:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Juz2bH8YCP4HFiGkkpTOVfYjxI76fXg2crD1fPN6goM=; b=C85zmAQh1905//GANVvJRvSnLoby6nCTKD0FGAF0uVDXpdIMTV8EDoB25XnNcgskSE TxnpRSh/6bedwMfSocjpM1rVIeaKcwcm+kLStqaZHnsL2Awum751cLEkoCmIZxyfsViS rhLDI1u8mGqsm3yvV88xo2gPogLNFmFfOyvs4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ZKSfvPglgWdjUEBaEvrRpp27yKq78PIM0rtFOxYhA+MPq6o/apOJszHE+objpzn61L pq1adA0hbM6s3pL9BEc4B1dqaXISzAyVr4yAcrd6GrvVKxS2/g4Cy/AUILlf7298W6ME pjH0EQoLe1gNXyWKeOGD9y+fKGOL7Ebue16Rs= MIME-Version: 1.0 Received: by 10.42.222.66 with SMTP id if2mr5803120icb.487.1295922574364; Mon, 24 Jan 2011 18:29:34 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.42.227.193 with HTTP; Mon, 24 Jan 2011 18:29:34 -0800 (PST) In-Reply-To: <8AFDA06B-4068-4C95-95DD-2243BEA377C3@cybernothing.org> References: <20110119161843.10E97F5808A@smtp.patriot.net> <8AFDA06B-4068-4C95-95DD-2243BEA377C3@cybernothing.org> Date: Mon, 24 Jan 2011 21:29:34 -0500 X-Google-Sender-Auth: uMdhD_7cgIdjuwndrSWJ_Bxet-s Message-ID: From: Barry Leiba To: "J.D. Falk" Content-Type: text/plain; charset=ISO-8859-1 Cc: Message Abuse Report Format working group 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: Tue, 25 Jan 2011 02:26:39 -0000 > I think I'm seeing about equal consensus for making abuse@ the default, or for > having no default and requiring an address. > > Personally, I'm leaning towards having a default in order to keep the record small. I favour requiring it because it makes them think about it, and perhaps make sure the specified address really exists and is actively handling messages. Something left to a default can easily be non-existant, or a black hole. That said, I don't feel strongly, and am happy to agree to whichever winds up in the document. Barry (participant) From johnl@iecc.com Mon Jan 24 19:05: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 177573A6A0E for ; Mon, 24 Jan 2011 19:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.072 X-Spam-Level: X-Spam-Status: No, score=-111.072 tagged_above=-999 required=5 tests=[AWL=0.127, 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 rQuv9OAtlEF2 for ; Mon, 24 Jan 2011 19:05:22 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 11E773A699F for ; Mon, 24 Jan 2011 19:05:21 -0800 (PST) Received: (qmail 75568 invoked from network); 25 Jan 2011 03:08:18 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 25 Jan 2011 03:08:18 -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=545e.4d3e3ea2.k1101; i=johnl@user.iecc.com; bh=uZQM8/T+pI3Z6GTkLkjI4JtYqVNhoe6mpXZ1WNvuGKs=; b=HnOlBizhLvWYDuFzq8QBDlfM2XCmtbGoCNr56cpIfvgoY7vZPswPh5HQVoNyjKhbxKI4S2e4IWyhNBufm1rWNTETYlpg0qbYz1nngcWVI4/V12VQrHeUrDl0whf61GRL0knS1wb3d59B1mZEcNmNbkiPWxxv8M6F9niEmAtpPSY= 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=545e.4d3e3ea2.k1101; olt=johnl@user.iecc.com; bh=uZQM8/T+pI3Z6GTkLkjI4JtYqVNhoe6mpXZ1WNvuGKs=; b=C8L4MtqVHh2Xxx353GC9zYmv4YsfoHj2EDcqRfBUPHve7oQ74FgBfeaaVOCr6prCb2jdCI5jscqct0+qi2ARJVfNNRR0mh0TOp9tm72GW1yTDVIwaLsYjiK6ra0v23EMmyLCUedfrs/MYdTIQd6H79Hfl+GQyG8fJf4kHiBKNno= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 25 Jan 2011 03:08:18 -0000 Message-ID: <20110125030818.21597.qmail@joyce.lan> From: John Levine To: marf@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: barryleiba@computer.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: Tue, 25 Jan 2011 03:05:23 -0000 >I favour requiring it because it makes them think about it, and >perhaps make sure the specified address really exists and is actively >handling messages. Something left to a default can easily be >non-existant, or a black hole. > >That said, I don't feel strongly, and am happy to agree to whichever >winds up in the document. Agreed. I don't see the record size as a big deal. R's, John From vesely@tana.it Tue Jan 25 03:59: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 2D5293A6836 for ; Tue, 25 Jan 2011 03:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.133 X-Spam-Level: X-Spam-Status: No, score=-5.133 tagged_above=-999 required=5 tests=[AWL=-0.414, 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 4N-Ud4l00YJq for ; Tue, 25 Jan 2011 03:59:03 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id DCF733A63C9 for ; Tue, 25 Jan 2011 03:59:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1295956916; bh=sct68FamCnhnaoeqyA9xhWtPXLH/AYE/zfaoSra7w/U=; l=1526; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=lg+ion8LcD+xYmJbTMwfiN7oHDgaFjRaFlXP/yGlr+50xX4qM2e81ZsBanEdh6X7w OL36BeI5bfT/oERa/EhjoVH7EmPEKQOzrULJ48iBEuUvLWAalF/fKyayrpjEWEfvzb ipghhdR9cnb7lGSCKU+Gm77Gic2Wtk0cHuYkRJRw= 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, 25 Jan 2011 13:01:56 +0100 id 00000000005DC035.000000004D3EBBB4.00002D67 Message-ID: <4D3EBBB5.9050107@tana.it> Date: Tue, 25 Jan 2011 13:01:57 +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: <20110119161843.10E97F5808A@smtp.patriot.net> <8AFDA06B-4068-4C95-95DD-2243BEA377C3@cybernothing.org> In-Reply-To: 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: Tue, 25 Jan 2011 11:59:04 -0000 On 25/Jan/11 02:24, Murray S. Kucherawy wrote: >> I think I'm seeing about equal consensus for making abuse@ the default, >> or for having no default and requiring an address. >> >> Personally, I'm leaning towards having a default in order to keep the >> record small. > > I'm leaning toward having the default. In the absence of this > record, that's what most people will do anyway since there's > already an RFC that encourages it. Also for "r"? (See Appendix C of draft-jdfalk-maawg-cfblbcp) I wonder if it would make sense to note these concerns explicitly in the I-D, or to require a generator record when assuming default values from non-found consumer records; e.g. something like 5.1.2 Feedback Consumer default As the above provisions imply, mail senders who publish no Feedback Reporting advertisement may happen to receive reports by generators who assume the default values. That is, generators MAY send ARF reports to abuse@ addresses unless different dispositions exist. While this is consistent with RFC 2142, it has to be noted that a default address can easily be non-existant, or a black hole. Thus, consumers are encouraged to publish explicit information even in case it happens to agree with the default values: in addition to better clarity, it may also improve caching. Generators who send reports to abuse@ in the absence of any explicit advertisement record SHOULD publish a generator record as detailed in the following section. From tim@eudaemon.net Tue Jan 25 07:36:27 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 658343A6805 for ; Tue, 25 Jan 2011 07:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_101=0.6] 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 04S9VxN3YKHC for ; Tue, 25 Jan 2011 07:36:26 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by core3.amsl.com (Postfix) with ESMTP id 8E3833A6804 for ; Tue, 25 Jan 2011 07:36:26 -0800 (PST) Received: from [10.0.1.2] (adsl-250-167-35.ard.bellsouth.net [74.250.167.35]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 8522ACB65 for ; Tue, 25 Jan 2011 10:39:23 -0500 (EST) From: Tim Draegen Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Jan 2011 10:39:22 -0500 Message-Id: <20CD3804-8E61-4B88-A65E-ADFD41467051@eudaemon.net> To: marf@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [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: Tue, 25 Jan 2011 15:36:27 -0000 > One party that=92s already seen the draft, whom I hope will pipe up on = the list once it=92s posted, has some concerns about the size of the = document and thus would like us to consider breaking it into a small set = of related documents. I=92ll let that discussion start separately along = with any other points he may have. Murray, My apologies for being tardy! My concern is that too much is covered. AFAICT, this draft is actually 5 separate documents rolled up into one: 1. DKIM reporting extensions 2. ADSP reporting extensions 3. SPF reporting extensions 4. ARF auth-failure extensions 5. ARF "redaction" #1 makes sense as a technical spec. I think it's ready for focused = operational testing. #2 is just like #1. #3 presents interesting ideas, for sure. However the draft contains a = few techno-warts: - I'm having a hard time understanding how the SPF "reportopts" will be = used. The publisher of the record adds the policy piece of SPF that = leads to a (fail, softfail, neutral) result, usually by adding something = like "-all" or "~all" to their record. EG, using the proposed syntax, I could write "v=3Dspf1 ip4:1.2.3.4 = report=3Demail.address reportopts=3Df ~all". This would specify that I = want reports on all SPF "fails" (distinct from "softfails"). However, = my "~all" means that all my non-authorized email will end up receiving = "softfails", resulting in me receiving zero reports. - Lots of real-world SPF records "include:" other records. What if two = report-related extensions appear due to the use of include:? - SPF records describe "mechanisms" for identifying authorized servers = and "modifiers". The extensions are "modifiers", but I'm uncertain if = these will break existing SPF code, or if various implementors did the = right the thing. =20 - "reportsmtp=3D" is redundant with SPF's existing "exp:" modifier. #4 is interesting, but needs another rev of specification (does it = target deployers of authentication? is it meant to allow implementors = to debug their stacks?), preferably with input from real-world = operations. #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. Cheers, =3D- Tim From msk@cloudmark.com Fri Jan 28 11:13:21 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 A1FA43A68D1 for ; Fri, 28 Jan 2011 11:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=-0.849, 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 TtmhcWY6tBlm for ; Fri, 28 Jan 2011 11:13:20 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id EA6AF3A67F7 for ; Fri, 28 Jan 2011 11:13:20 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 28 Jan 2011 11:16:27 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Fri, 28 Jan 2011 11:16:26 -0800 Thread-Topic: [marf] reporting-discovery Thread-Index: Acu0QJCFsz5m6fBzSKSeShGbKzCKjQK3xnDw 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: [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: Fri, 28 Jan 2011 19:13:21 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > J.D. Falk > Sent: Friday, January 14, 2011 3:13 PM > To: Message Abuse Report Format working group > Subject: [marf] reporting-discovery >=20 > I've uploaded an updated version of the discovery draft: >=20 > http://tools.ietf.org/html/draft-jdfalk-marf-reporting-discovery-03 >=20 > [...] [as co-chair] Since we have a chartered item to produce a reporting discovery proposal an= d this is the only draft submitted thus far, and it sparked some discussion= , I believe it's appropriate that we make it into a working group item. If there's no objection, I'll do so next week. If you have an issue with i= t, please say so soon. -MSK From bmcdowell@paypal-inc.com Fri Jan 28 14:00:06 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 CE76B3A6975 for ; Fri, 28 Jan 2011 14:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.611 X-Spam-Level: X-Spam-Status: No, score=-7.611 tagged_above=-999 required=5 tests=[AWL=1.506, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] 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 E8ADed0WBfaQ for ; Fri, 28 Jan 2011 14:00:03 -0800 (PST) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by core3.amsl.com (Postfix) with ESMTP id 1E3483A6897 for ; Fri, 28 Jan 2011 14:00:02 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=Ym+C0zaZQfHaK+jwRRalOYsN5NoBbkaXUJsq45XhfHUUJRYUzvXsSLgq /jnDo/Qak4tDIM7rmPe372B7z92zHNK8/5MHUdykyb8v+uKgYPoAqp723 5Qy7niiQUv0FYrT; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bmcdowell@paypal-inc.com; q=dns/txt; s=ppinc; t=1296252191; x=1327788191; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"McDowell,=20Brett"=20 |To:=20"J.D.=20Falk"=20 |CC:=20Message=20Abuse=20Report=20Format=20working=20grou p=20|Date:=20Fri,=2028=20Jan=202011=2015:0 3:05=20-0700|Subject:=20Re:=20[marf]=20Updated=20DKIM=20r eporting=20draft|Message-ID:=20<50B899D2-3BE6-42A9-8C7C-1 2F66C5B870C@paypal-inc.com>|References:=20 =0D=0A=20|In-Reply-To:=20|Content-Transfer-Encoding:=20quoted -printable|MIME-Version:=201.0; bh=I/9RbkrLZgDXYLCPIY2bozQMWY2nKjs+XupNpCZ2MUA=; b=MIhkNTi3XJsV46Spe02TiZS0d5oyDEwk6CrK23pMTgpWlYyaPF9lz8Ce yt6ni4/nHn1AKTxmUJJ3XnCw5eMK259qmzugfbXzg3S8bRTRuPow5mck8 acoihTNvkJfmPxh; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.60,394,1291622400"; d="scan'208";a="506444" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-002.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 28 Jan 2011 14:03:10 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-002.corp.ebay.com ([10.241.17.53]) with mapi; Fri, 28 Jan 2011 15:03:07 -0700 From: "McDowell, Brett" To: "J.D. Falk" Date: Fri, 28 Jan 2011 15:03:05 -0700 Thread-Topic: [marf] Updated DKIM reporting draft Thread-Index: Acu/NySIpxkQWq58QXuHGqaQutQUqQ== Message-ID: <50B899D2-3BE6-42A9-8C7C-12F66C5B870C@paypal-inc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: Cvsh/wt4G1kwbrjzEg+PwQ== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: Message Abuse Report Format working group Subject: Re: [marf] Updated 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: Fri, 28 Jan 2011 22:00:07 -0000 I really like the expanded scope of the latest draft. Bravo Murray and Hil= da. On Jan 10, 2011, at 4:26 PM, J.D. Falk wrote: > On Jan 7, 2011, at 12:07 PM, Murray S. Kucherawy wrote: >=20 >> Although the name is draft-ietf-marf-dkim-reporting, it now also contain= s support for more general authentication failure reporting by enabling the= reporting of SPF-specific data in the report. It also, therefore, changes= the feedback report type from =93dkim=94 to =93auth-failure=94. >=20 > I think this makes a lot of sense; the same people tend to be interested = in reporting on both, for the same mailstreams. >=20 >> There is also a section that discusses a proposed standard way to do dat= a redaction at a report generator. Simple replacement with a dummy string = like =93xxxxx=94 satisfies a report generator=92s privacy needs but prevent= s a report consumer from sorting or grouping of reports about a common prob= lem source. The proposed mechanism covers both things. This is something = I=92d like to include in an RFC5965bis effort somewhere down the road. >=20 > This isn't the only draft where there's been a need (or at least a desire= ) to discuss redaction -- it seems to be an issue that will follow ARF arou= nd forever. It's written really well here, better than most of the previou= s attempts (IMHO). I wonder if it'd make sense to split this section out i= nto a stand-alone draft on the BCP track? That'll make it easier to refere= nce from other applicable documents. >=20 > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf From kathleen.moriarty@emc.com Sun Jan 30 16:11:08 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 D75C63A6B59 for ; Sun, 30 Jan 2011 16:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 phSM72hyAJD9 for ; Sun, 30 Jan 2011 16:11:06 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 4DA793A6B58 for ; Sun, 30 Jan 2011 16:11:06 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0V0E1Fr028178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Jan 2011 19:14:01 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sun, 30 Jan 2011 19:13:56 -0500 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.221.56.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0V0DZU3028647; Sun, 30 Jan 2011 19:13:35 -0500 Received: from mx06a.corp.emc.com ([169.254.1.241]) by mxhub16.corp.emc.com ([128.221.56.105]) with mapi; Sun, 30 Jan 2011 19:13:35 -0500 From: To: , Date: Sun, 30 Jan 2011 19:13:30 -0500 Thread-Topic: [marf] reporting-discovery Thread-Index: Acu3SHPMtbdCKB6GQFq/xN3GLjqSEAJksPuw Message-ID: References: <4D32F9C7.3080607@tana.it> 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 X-EMM-MHVC: 1 X-Mailman-Approved-At: Sun, 30 Jan 2011 16:15:53 -0800 Cc: trammell@tik.ee.ethz.ch, 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: Mon, 31 Jan 2011 00:11:08 -0000 Sorry for my delay in response. I should be able to look closer at this la= ter in the week. I am copying Brian who helped in the IODEF work as well i= n case he can get to this sooner than I can. The basic question being asked is to know if reports could be provided in a= n IODEF format, right? This should be fine and I think it would be a good = idea to allow for that option as IODEF covers all types of incidents. If t= here are some things not covered in IODEF, an extension may be necessary an= d the specification allows for that. What do you need from us in order to add this option? Thank you, Kathleen -----Original Message----- From: J.D. Falk [mailto:jdfalk-lists@cybernothing.org]=20 Sent: Tuesday, January 18, 2011 2:46 PM To: Alessandro Vesely Cc: marf@ietf.org; Moriarty, Kathleen Subject: Re: [marf] reporting-discovery On Jan 16, 2011, at 5:59 AM, Alessandro Vesely wrote: > On 15/Jan/11 00:12, J.D. Falk wrote: >> http://tools.ietf.org/html/draft-jdfalk-marf-reporting-discovery-03 >>=20 >> Remaining questions: >>=20 >> - should this include IODEF as a format? >=20 > I'd say this would be a Good Thing (TM). However, it is them who > should ask for it, and define some details. Perhaps, we should prompt > them to do so? (I add a CC, in case.) And what about x-arf? The X-ARF authors don't appear to be interested in rejoining the IETF proce= ss, so there's no I-D to refer to. > A different report format may imply different transports, thus the I-D > may need to specify that r=3D email addresses are only meant for email > transport. More importantly, report types may differ: It is highly > desirable that report types use the same words to mean the same type, > across any format. Otherwise, the rt should be appended to each rf, > e.g. as "rf=3DARF:abuse,fraud; rf=3DIODEF:thraud;". Yep, that's what's stopped me from adding IODEF already. Perhaps someone m= ore familiar with the format could help us figure out how/if to add it? > * We probably should devise a tool that works according to this I-D. > (Maybe a command line Perl script that forwards complaints to the > relevant ADMD...) Agreed. > * Shouldn't the default r=3D be abuse@, rather than postmaster@? Maybe. I chose postmaster@ because it's required (MUST) for operating a ma= il system, but abuse@ may be sufficiently standard by now. Any thoughts fr= om the rest of the group? > * Saying that the default policy is rp=3Do obviously implies that > sending complaints to the default address is fine. Should the I-D > explicitly say that those defaults may be assumed even when no DNS > record (or whatever) is defined at all? That would impose a requirement that all mail operators accept and process = ARF reports, even if they haven't chosen to participate in any ARF-related = standard. In other words: they'll start getting messages this weird MIME t= ype they've probably never heard of before, and they'll probably be annoyed= . (Involuntary ARF reporting is also discussed in one of the appendices of dr= aft-jdfalk-maawg-cfblbcp.) From vesely@tana.it Mon Jan 31 05:39:41 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 E70073A67AA for ; Mon, 31 Jan 2011 05:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.969 X-Spam-Level: X-Spam-Status: No, score=-4.969 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 sUtUu7mNOcRl for ; Mon, 31 Jan 2011 05:39:38 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 626473A6C07 for ; Mon, 31 Jan 2011 05:39:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1296481367; bh=j8Azp4tqjthkrEjLBJyC92OCwvPrR2KLRYEZRA+6xNM=; l=4261; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=jUY8CZLcnN7bqlQhT1Uj5/5VgnXLWn1Qf8kl3GXadJxGZSyuU1UdGDPNcTSgatfa4 TdPNKIwJm+43kXVbXBW5RZwd1IOaIVOAgP8yikYGy/tPTXzpAHP5DdLZEnbbOe2UU6 0FSJwodgFovoOqBl2s9ojtc8kMYNNd/xzyfO0kKA= 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; Mon, 31 Jan 2011 14:42:47 +0100 id 00000000005DC044.000000004D46BC57.00006AAF Message-ID: <4D46BC57.7060509@tana.it> Date: Mon, 31 Jan 2011 14:42:47 +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: kathleen.moriarty@emc.com References: <4D32F9C7.3080607@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: marf@ietf.org, trammell@tik.ee.ethz.ch 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: Mon, 31 Jan 2011 13:39:41 -0000 Hi Kathleen, thank you for participating! On 31/Jan/11 01:13, kathleen.moriarty@emc.com wrote: > The basic question being asked is to know if reports could be > provided in an IODEF format, right? This should be fine and I > think it would be a good idea to allow for that option as IODEF > covers all types of incidents. If there are some things not > covered in IODEF, an extension may be necessary and the > specification allows for that. For some background, the (Mail) Abuse Report Format, as its name suggests, is primarily used to report abuse, possibly in relation with feedback loops [FBL]. In some situations, abuse reports could be sent to a domain's abuse@ address without prior agreement, or they may happen to reach some staff mailbox somewhat unexpectedly. For this reason, the format has been designed to be as human readable and self explanatory as possible. Mail abuse reports may be initiated by end users clicking a This-is-Spam button on their MUAs, and thence reach FBL subscribers --a scenario currently limited to a few huge North-American mailbox providers. It is not yet well defined how these reports will, in general, be forwarded, to what addresses, using what format, and what transport. I look forward to further insight from you on this subject. At this early stage, we cannot know in what cases which format conversions may be necessary or advisable in order to forward reports adequately. The idea is that an MTA would look up some kind of reputation service, internal policy, or FBL subscription file in order to determine what ADMDs, if any, deserve a copy of ARs received from end users. Looking up the relevant _report RR in the DNS would then provide the exact address and format to use. > What do you need from us in order to add this option? Four report types [ARF#T] have been standardized for ARF: abuse, fraud, virus, and other. The reporting discovery [RD] resource record definition provides for both feedback consumers and generators to be able to specify the type of reports that they are willing to receive or send, respectively. The syntax of RR specifies the tags rt= and gt=, whose values should be one or more of those tokens, as defined in the [IANA-MARF]. IODEF tokens, instead, are registered in the framework of XML namespaces and schemas, as for example, [IANA-PHISH]. Does this extension cover all email-related IODEF incidents? The phishing extension [PHISH] defines the following fraud types: phishing, recruiting, malware distribution, fraudulent site, dnsspoof, archive, other, unknown, and ext-value. The type can be a key information for deciding what route a report should be forwarded to, or which team will deal with it. How are we going to map these types across format conversions? Or should the type be replaced with some other token or omitted altogether? IODEF and MARF target different users. The global number of network providers seems to be smaller than that of mailbox providers, so that the formers may be expected to have better means to learn the addresses of one another than looking up the DNS. OTOH, a stream of generic IODEF reports may be of interest to generic firewall operators, even if they are not actually network providers. Would it be helpful for a network provider to offer such stream to interested consumers using the DNS? (IOW, why didn't you define the analogous of reporting discovery?) Non-cooperative mail senders, including bots, deserve being reported to some upstream network provider. In case the provider manages the relevant DNS zone, it may publish reporting information. This includes format, type, and address preferences. Are these orthogonal coordinates, or should the RR syntax provide for a different arrangement? -- [FBL] http://en.wikipedia.org/wiki/Feedback_Loop_%28email%29 [ARF#T] http://tools.ietf.org/html/rfc5965#section-7.3 [RD] http://tools.ietf.org/html/draft-jdfalk-marf-reporting-discovery [IANA-MARF] http://www.iana.org/assignments/marf-parameters/marf-parameters.xhtml [IANA-IODEF-PHISH] http://www.iana.org/assignments/xml-registry/schema/iodef-phish-1.0.xsd [PHISH] http://tools.ietf.org/html/rfc5901 From kathleen.moriarty@emc.com Mon Jan 31 06:17:30 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 AADB53A6C05 for ; Mon, 31 Jan 2011 06:17:30 -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 ffPJznumOvel for ; Mon, 31 Jan 2011 06:17:29 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id E5E193A6BF4 for ; Mon, 31 Jan 2011 06:17:28 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0VEKXCu029580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 09:20:33 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 31 Jan 2011 09:16:30 -0500 Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0VEFFGm001383; Mon, 31 Jan 2011 09:15:15 -0500 Received: from mx06a.corp.emc.com ([169.254.1.241]) by mxhub04.corp.emc.com ([10.254.141.106]) with mapi; Mon, 31 Jan 2011 09:15:14 -0500 From: To: Date: Mon, 31 Jan 2011 09:15:06 -0500 Thread-Topic: [marf] reporting-discovery Thread-Index: AcvBTMpTlMZfrbWORa+pKgzw92G6cgAAJ6MQ Message-ID: References: <4D32F9C7.3080607@tana.it> <4D46BC57.7060509@tana.it> In-Reply-To: <4D46BC57.7060509@tana.it> 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-EMM-MHVC: 1 Cc: marf@ietf.org, trammell@tik.ee.ethz.ch 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: Mon, 31 Jan 2011 14:17:30 -0000 Hello Alessandro, Thank you for the additional background, that is very helpful. I am tight = on time today, so I will answer what I can quickly and then may follow up a= gain later in the week. IODEF reports can go to any entity that is handling/managing incidents and = the response to those incidents. I am guessing the use of Network Provider= in the RID document is why it may have been interpreted to be for Network = Providers only. We included CSIRT as well, really meaning any computer sec= urity incident response teams. This interpretation could extend to mail ad= ministrators. I would like to see IODEF as an option in MARF and think the reasons and ju= stification for this is growing. Efforts like CYBEX from ITU.T are working= to combine protocols to automate incident response. Cloud is also driving= the need for unified incident management between cloud providers. With th= ese efforts protocols that include SCAP, IODEF, and RID are getting tied to= gether to automate incident response using a common format to represent inc= idents. If you consider the CSIRT within an organization, having a single = repository to discover, manage, report and track incidents provide several = benefits. There are efficiency gains when using a common reporting format = in that the incident reports can be received and processed without the need= to interpret multiple formats - possibly a different one for each type of = incident. In large organizations, the actions required from any one type o= f incident could be distributed throughout an organization. If all of thes= e incidents were managed in separate systems and different formats, it woul= d become very difficult to normalize all incident types and identify trends= across incident types. A single attacker may launch multiple attacks that= when correlated could assist in the forensics and also the actions taken t= o remediate since the combined attack types may have a greater impact and r= isk level to the organization. If incidents are distributed internally usi= ng IODEF (to the right business units or administrators), the format could = be leveraged to track the incident handling process. The impact can also b= e associated with each attack type and trend analysis could also be perform= ed to help determine areas of risk, need for additional funding, ROI benefi= ts from new security measures implemented, etc.=20 I actually had looked into MARF recently to see what was different, but hav= e not combed through the definition to compare it to the IODEF + phraud sch= ema extension yet. If you have done this and see some areas that appear to= be missing, please let me know as it may help to speed up my response. Ot= herwise, I should be able to dig into the formats/incident representations = later this week. The reason we did not define a way to select the method of transport was th= at we have a defined transport definition (more can be defined) that uses H= TTPS. We were going to use BEEP, but that was changed to HTTPS in the last= call process. Additional transport mechanisms to transmit RID communicati= ons (RID is the wrapper for IODEF that provides security and types of commu= nications that can occur) can be defined, nothing prevents the use of other= transport protocols that get defined. I think that just leaves one open question to see if IODEF and existing ext= ensions accommodate the types of incidents handled by MARF. If the phraud = extension requires new fields, a document update could be possible. If ano= ther extension needs to be defined for IODEF, that is possible as well. Th= ere are 2 right now, one for financial transactions and one for phraud/phis= hing. I have seen a note somewhere that a SPAM extension was needed, but w= ill have to look through the schema to determine if that is the case. Thanks for reaching out and bringing this to my attention. Best regards, Kathleen -----Original Message----- From: Alessandro Vesely [mailto:vesely@tana.it]=20 Sent: Monday, January 31, 2011 8:43 AM To: Moriarty, Kathleen Cc: jdfalk-lists@cybernothing.org; trammell@tik.ee.ethz.ch; marf@ietf.org Subject: Re: [marf] reporting-discovery Hi Kathleen, thank you for participating! On 31/Jan/11 01:13, kathleen.moriarty@emc.com wrote: > The basic question being asked is to know if reports could be > provided in an IODEF format, right? This should be fine and I > think it would be a good idea to allow for that option as IODEF > covers all types of incidents. If there are some things not > covered in IODEF, an extension may be necessary and the > specification allows for that. For some background, the (Mail) Abuse Report Format, as its name suggests, is primarily used to report abuse, possibly in relation with feedback loops [FBL]. In some situations, abuse reports could be sent to a domain's abuse@ address without prior agreement, or they may happen to reach some staff mailbox somewhat unexpectedly. For this reason, the format has been designed to be as human readable and self explanatory as possible. Mail abuse reports may be initiated by end users clicking a This-is-Spam button on their MUAs, and thence reach FBL subscribers --a scenario currently limited to a few huge North-American mailbox providers. It is not yet well defined how these reports will, in general, be forwarded, to what addresses, using what format, and what transport. I look forward to further insight from you on this subject. At this early stage, we cannot know in what cases which format conversions may be necessary or advisable in order to forward reports adequately. The idea is that an MTA would look up some kind of reputation service, internal policy, or FBL subscription file in order to determine what ADMDs, if any, deserve a copy of ARs received from end users. Looking up the relevant _report RR in the DNS would then provide the exact address and format to use. > What do you need from us in order to add this option? Four report types [ARF#T] have been standardized for ARF: abuse, fraud, virus, and other. The reporting discovery [RD] resource record definition provides for both feedback consumers and generators to be able to specify the type of reports that they are willing to receive or send, respectively. The syntax of RR specifies the tags rt=3D and gt=3D, whose values should be one or more of those tokens, as defined in the [IANA-MARF]. IODEF tokens, instead, are registered in the framework of XML namespaces and schemas, as for example, [IANA-PHISH]. Does this extension cover all email-related IODEF incidents? The phishing extension [PHISH] defines the following fraud types: phishing, recruiting, malware distribution, fraudulent site, dnsspoof, archive, other, unknown, and ext-value. The type can be a key information for deciding what route a report should be forwarded to, or which team will deal with it. How are we going to map these types across format conversions? Or should the type be replaced with some other token or omitted altogether? IODEF and MARF target different users. The global number of network providers seems to be smaller than that of mailbox providers, so that the formers may be expected to have better means to learn the addresses of one another than looking up the DNS. OTOH, a stream of generic IODEF reports may be of interest to generic firewall operators, even if they are not actually network providers. Would it be helpful for a network provider to offer such stream to interested consumers using the DNS? (IOW, why didn't you define the analogous of reporting discovery?) Non-cooperative mail senders, including bots, deserve being reported to some upstream network provider. In case the provider manages the relevant DNS zone, it may publish reporting information. This includes format, type, and address preferences. Are these orthogonal coordinates, or should the RR syntax provide for a different arrangement? --=20 [FBL] http://en.wikipedia.org/wiki/Feedback_Loop_%28email%29 [ARF#T] http://tools.ietf.org/html/rfc5965#section-7.3 [RD] http://tools.ietf.org/html/draft-jdfalk-marf-reporting-discovery [IANA-MARF] http://www.iana.org/assignments/marf-parameters/marf-parameters.xhtml [IANA-IODEF-PHISH] http://www.iana.org/assignments/xml-registry/schema/iodef-phish-1.0.xsd [PHISH] http://tools.ietf.org/html/rfc5901 From bmcdowell@paypal-inc.com Mon Jan 31 08:33:06 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 DE58C3A6AE5 for ; Mon, 31 Jan 2011 08:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.988 X-Spam-Level: X-Spam-Status: No, score=-7.988 tagged_above=-999 required=5 tests=[AWL=1.130, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] 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 dcBOpcHVoPda for ; Mon, 31 Jan 2011 08:33:05 -0800 (PST) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id A2B8E3A67F0 for ; Mon, 31 Jan 2011 08:33:05 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:Date: Subject:Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=qQcHtgFT9AYBlx8H2w9HsPCL+RmFbdvx7Ke8jzEGSmuZShbrsjaHDejW 7qm+v61EKHzkmF1vWcjazcRONleOjQbELhVX5o5w3Fzb2gfaWLdAK88fy 7ROS4RWIlZeL+CJ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bmcdowell@paypal-inc.com; q=dns/txt; s=ppinc; t=1296491781; x=1328027781; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; z=From:=20"McDowell,=20Brett"=20 |To:=20"marf@ietf.org=20working=20group"=20|Date:=20Mon,=2031=20Jan=202011=2009:36:19=20-0700 |Subject:=20Re:=20[marf]=20Updated=20DKIM=20reporting=20d raft|Message-ID:=20<3C2F5B52-83AA-486F-AA5E-08612D7766CA@ paypal-inc.com>|References:=20=0D=0A=20=0D=0A =20<50B899D2-3BE6-42A9-8C7C-12F66C5B870C@paypal-inc.com> |In-Reply-To:=20<50B899D2-3BE6-42A9-8C7C-12F66C5B870C@pay pal-inc.com>|Content-Transfer-Encoding:=20quoted-printabl e|MIME-Version:=201.0; bh=njSpQDpIWRRO6MjiAtEosE2dhHZs7SoDogcalZMeeSk=; b=ccqVVWP3Lx2lvVPyoShiBUmjHpvrxe2z8wjJb7LbzzY/rPGrEeBq5pUE AmCx6DrCyfkGBvWIzEVZ3isZMSEg/XmEQ7H8Zp3XMfhlcmftR0LonHi4L yo9QAeNtoxttZe6; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.60,404,1291622400"; d="scan'208";a="1008360" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-001.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 31 Jan 2011 08:36:20 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-001.corp.ebay.com ([10.241.17.52]) with mapi; Mon, 31 Jan 2011 09:36:19 -0700 From: "McDowell, Brett" To: "marf@ietf.org working group" Date: Mon, 31 Jan 2011 09:36:19 -0700 Thread-Topic: [marf] Updated DKIM reporting draft Thread-Index: AcvBZP0CacmKjSlAQbeRgDNUCxWXMg== Message-ID: <3C2F5B52-83AA-486F-AA5E-08612D7766CA@paypal-inc.com> References: <50B899D2-3BE6-42A9-8C7C-12F66C5B870C@paypal-inc.com> In-Reply-To: <50B899D2-3BE6-42A9-8C7C-12F66C5B870C@paypal-inc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: Gc1cRuhJDWNnEfvpiNhWzA== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [marf] Updated 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: Mon, 31 Jan 2011 16:33:07 -0000 To clarify: if this progresses in the general direction proposed by Murray = and Hilda's expanded scope (noting there are still tweaks to be made per Ti= m's follow-up comments), I would advocate that my employer build out suppor= t for consuming such reports, and I would advocate that my employer's partn= ers (many of the big consumer mailbox providers) build out support for the = report generation side. =20 -- Brett On Jan 28, 2011, at 5:03 PM, McDowell, Brett wrote: > I really like the expanded scope of the latest draft. Bravo Murray and H= ilda. >=20 > On Jan 10, 2011, at 4:26 PM, J.D. Falk wrote: >=20 >> On Jan 7, 2011, at 12:07 PM, Murray S. Kucherawy wrote: >>=20 >>> Although the name is draft-ietf-marf-dkim-reporting, it now also contai= ns support for more general authentication failure reporting by enabling th= e reporting of SPF-specific data in the report. It also, therefore, change= s the feedback report type from =93dkim=94 to =93auth-failure=94. >>=20 >> I think this makes a lot of sense; the same people tend to be interested= in reporting on both, for the same mailstreams. >>=20 >>> There is also a section that discusses a proposed standard way to do da= ta redaction at a report generator. Simple replacement with a dummy string= like =93xxxxx=94 satisfies a report generator=92s privacy needs but preven= ts a report consumer from sorting or grouping of reports about a common pro= blem source. The proposed mechanism covers both things. This is something= I=92d like to include in an RFC5965bis effort somewhere down the road. >>=20 >> This isn't the only draft where there's been a need (or at least a desir= e) to discuss redaction -- it seems to be an issue that will follow ARF aro= und forever. It's written really well here, better than most of the previo= us attempts (IMHO). I wonder if it'd make sense to split this section out = into a stand-alone draft on the BCP track? That'll make it easier to refer= ence from other applicable documents. >>=20 >> _______________________________________________ >> marf mailing list >> marf@ietf.org >> https://www.ietf.org/mailman/listinfo/marf >=20 From bmcdowell@paypal-inc.com Mon Jan 31 08:40:36 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 BB5543A6C36 for ; Mon, 31 Jan 2011 08:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.988 X-Spam-Level: X-Spam-Status: No, score=-7.988 tagged_above=-999 required=5 tests=[AWL=1.130, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] 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 ia8QznPncpma for ; Mon, 31 Jan 2011 08:40:36 -0800 (PST) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id 8A4893A6C07 for ; Mon, 31 Jan 2011 08:40:36 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:Date: Subject:Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=XZ2fF+Bn3hAkCg4cI4ShihdkQTXgvXVzBKrEAgBY3F8/q7RktQ5fFZvY kn+du1t8dDNOWIvM9wEXfgTCmqdSO8hrUBshmiZ6waRc7/s8dbq7Uo2HW EMj35Io+WIKpEXn; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bmcdowell@paypal-inc.com; q=dns/txt; s=ppinc; t=1296492232; x=1328028232; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; z=From:=20"McDowell,=20Brett"=20 |To:=20"marf@ietf.org=20working=20group"=20|Date:=20Mon,=2031=20Jan=202011=2009:43:50=20-0700 |Subject:=20Re:=20[marf]=20Updated=20DKIM=20reporting=20d raft|Message-ID:=20<3C2F5B52-83AA-486F-AA5E-08612D7766CA@ paypal-inc.com>|References:=20=0D=0A=20=0D=0A =20<50B899D2-3BE6-42A9-8C7C-12F66C5B870C@paypal-inc.com> |In-Reply-To:=20<50B899D2-3BE6-42A9-8C7C-12F66C5B870C@pay pal-inc.com>|Content-Transfer-Encoding:=20quoted-printabl e|MIME-Version:=201.0; bh=njSpQDpIWRRO6MjiAtEosE2dhHZs7SoDogcalZMeeSk=; b=xoVNZKUgzaXIlJ10+v+S8j6eBVFf21He2hC4MURWMJmiYsCy/Sr+vAQq S+W8ZN86Chh6jt2mzIrm3iSrhg6sxSW7+/K/2axhMj8JfD2vF29Kvh8o5 5te//E7l/mqKH+y; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.60,404,1291622400"; d="scan'208";a="1008493" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-003.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 31 Jan 2011 08:43:51 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-003.corp.ebay.com ([10.241.17.54]) with mapi; Mon, 31 Jan 2011 09:43:50 -0700 From: "McDowell, Brett" To: "marf@ietf.org working group" Date: Mon, 31 Jan 2011 09:43:50 -0700 Thread-Topic: [marf] Updated DKIM reporting draft Thread-Index: AcvBZgmiPqUmz58mQXiANGB9oGMLIQ== Message-ID: <3C2F5B52-83AA-486F-AA5E-08612D7766CA@paypal-inc.com> References: <50B899D2-3BE6-42A9-8C7C-12F66C5B870C@paypal-inc.com> In-Reply-To: <50B899D2-3BE6-42A9-8C7C-12F66C5B870C@paypal-inc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: aiFG/AIHgm0gmCwi51CGQw== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [marf] Updated 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: Mon, 31 Jan 2011 16:40:36 -0000 To clarify: if this progresses in the general direction proposed by Murray = and Hilda's expanded scope (noting there are still tweaks to be made per Ti= m's follow-up comments), I would advocate that my employer build out suppor= t for consuming such reports, and I would advocate that my employer's partn= ers (many of the big consumer mailbox providers) build out support for the = report generation side. =20 -- Brett On Jan 28, 2011, at 5:03 PM, McDowell, Brett wrote: > I really like the expanded scope of the latest draft. Bravo Murray and H= ilda. >=20 > On Jan 10, 2011, at 4:26 PM, J.D. Falk wrote: >=20 >> On Jan 7, 2011, at 12:07 PM, Murray S. Kucherawy wrote: >>=20 >>> Although the name is draft-ietf-marf-dkim-reporting, it now also contai= ns support for more general authentication failure reporting by enabling th= e reporting of SPF-specific data in the report. It also, therefore, change= s the feedback report type from =93dkim=94 to =93auth-failure=94. >>=20 >> I think this makes a lot of sense; the same people tend to be interested= in reporting on both, for the same mailstreams. >>=20 >>> There is also a section that discusses a proposed standard way to do da= ta redaction at a report generator. Simple replacement with a dummy string= like =93xxxxx=94 satisfies a report generator=92s privacy needs but preven= ts a report consumer from sorting or grouping of reports about a common pro= blem source. The proposed mechanism covers both things. This is something= I=92d like to include in an RFC5965bis effort somewhere down the road. >>=20 >> This isn't the only draft where there's been a need (or at least a desir= e) to discuss redaction -- it seems to be an issue that will follow ARF aro= und forever. It's written really well here, better than most of the previo= us attempts (IMHO). I wonder if it'd make sense to split this section out = into a stand-alone draft on the BCP track? That'll make it easier to refer= ence from other applicable documents. >>=20 >> _______________________________________________ >> marf mailing list >> marf@ietf.org >> https://www.ietf.org/mailman/listinfo/marf >=20 From msk@cloudmark.com Mon Jan 31 10:16:03 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 58EFA3A6B32 for ; Mon, 31 Jan 2011 10:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.89 X-Spam-Level: X-Spam-Status: No, score=-103.89 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 JLzOk6V7hnjX for ; Mon, 31 Jan 2011 10:16:02 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id AA3CF3A69A9 for ; Mon, 31 Jan 2011 10:16:02 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 31 Jan 2011 10:19:17 -0800 From: "Murray S. Kucherawy" To: "kathleen.moriarty@emc.com" , "vesely@tana.it" Date: Mon, 31 Jan 2011 10:19:15 -0800 Thread-Topic: [marf] reporting-discovery Thread-Index: AcvBTMpTlMZfrbWORa+pKgzw92G6cgAAJ6MQAAk6kNA= Message-ID: References: <4D32F9C7.3080607@tana.it> <4D46BC57.7060509@tana.it> 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 Cc: "trammell@tik.ee.ethz.ch" , "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: Mon, 31 Jan 2011 18:16:03 -0000 There are a few things I can think of that would need to be done to support= use of IODEF inside the ARF context. The first would be to modify the reporting-discovery draft to include the p= ossibility of advertising IODEF as a capability. This seems a fairly easy = change to make. The second and somewhat more involved step would be to create another docum= ent that registers a new ARF report type which can accommodate an IODEF-for= matted report. However, at the moment ARF is predicated on the multipart/r= eport media type (RFC3462) which stipulates that it must be the outermost m= edia type used (preventing construction of a single message containing many= reports) and further asserts the third MIME part in the report has to cont= ain all or part of the body of the message of interest which appears to pre= vent the inclusion of an IODEF report. It seems we may need a new media type overall to contain ARF reports might = be useful. I have an individual submission already created to remove the "= must be outermost" constraint, specifically so that one could generate a si= ngle message that contains multiple ARF reports. But maybe that should be = abandoned in favour of making up a new media type that can accommodate ARF = and IODEF more comfortably in the ways we want to use them. From vesely@tana.it Mon Jan 31 10:49:27 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 311DF3A6C4D for ; Mon, 31 Jan 2011 10:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.962 X-Spam-Level: X-Spam-Status: No, score=-4.962 tagged_above=-999 required=5 tests=[AWL=-0.243, 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 VN2Y5pgbEG11 for ; Mon, 31 Jan 2011 10:49:26 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id B33363A6847 for ; Mon, 31 Jan 2011 10:49:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1296499954; bh=jsfLwRlzZwJBc3MT6Miqe7U1liWmdR9Osc+teLCpEi8=; l=2872; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=Se84n+UP8BrsiB5ZH0wg/7vFQUGoPaY4fZhkFfT1YKVSGLdm+7JxnIqhhhhRPuQXj ocQEQIlJpSWm6Ca/V/ntqnM3J2zQDht6BZh9P3nHmLcXWyDyB2cFoFFwzwp0uU/oPq /JiHaabF9or/taC1gfLvpKF7pdCnI9CWAi4yUFdQ= 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; Mon, 31 Jan 2011 19:52:34 +0100 id 00000000005DC04C.000000004D4704F2.000007AE Message-ID: <4D4704F2.3020900@tana.it> Date: Mon, 31 Jan 2011 19:52:34 +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: kathleen.moriarty@emc.com References: <4D32F9C7.3080607@tana.it> <4D46BC57.7060509@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: Mon, 31 Jan 2011 18:49:27 -0000 Hi Kathleen, I appreciated your roundup of security efforts (although I didn't quote it.) Mail abuse is different inasmuch sending an email message is not an intrusion/incident by itself. I think the volume and peculiarities of email abuse more than justify an ad hoc approach. However, when email messages become evidence of full-blown incidents they certainly deserve being managed with the appropriate tools, for all the reasons that you described. On 31/Jan/11 15:15, kathleen.moriarty@emc.com wrote: > I actually had looked into MARF recently to see what was different, > but have not combed through the definition to compare it to the > IODEF + phraud schema extension yet. If you have done this and see > some areas that appear to be missing, please let me know as it may > help to speed up my response. ARF (RFC 5965), as you may have noticed, resembles a bounce, i.e. it contains all or part of the original message as its final (third) part. This part may be readily included in the field of the phraud extension (RFC 5901). The machine-readable (second) part of ARF contains a few "name: value" lines, which can be mapped to specific fields and/or included as , unless new fields are added to the phraud extension for this very purpose. RFC 5965 chose not to specify the exact semantics of the fields Reported-Domain and Reported-URI, so they depend on the report's User-Agent and Version. Also, some user-agents redact the original messages, for privacy reasons. > If the phraud extension requires new fields, a document update > could be possible. Yes, whenever we'll get to specifying that conversion. > The reason we did not define a way to select the method of > transport was that we have a defined transport definition (more can > be defined) that uses HTTPS. MARF uses SMTP as its elective transport. This could be used to quickly portray the difference between the respective approaches. More than the transport, I'm puzzled by the discovery mechanisms. Section 4 of RID (RFC 6045) starts with a nice informal description of communication issues among providers. Mailbox providers meet none of those requirements, and I'd bet most of them don't think they should. This more heavily portraits the difference between MARF and IODEF, and explains the need for discovery mechanisms. I found mentions of an X.cybex-disc paper, but have no idea of its content. Do you think it may contain something useful to us? > I have seen a note somewhere that a SPAM extension was needed, but > will have to look through the schema to determine if that is the > case. Probably adding suitable type(s) would suffice. The format defined by the phraud extension seems to be adequate for reporting any kind of abuse, irrespectively of its lure's malice. From shmuel+gen@patriot.net Mon Jan 31 11:16: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 1B5FF3A6B32 for ; Mon, 31 Jan 2011 11:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 lt1ZvRz1PPQU for ; Mon, 31 Jan 2011 11:16:37 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 191823A6ADF for ; Mon, 31 Jan 2011 11:16:34 -0800 (PST) Received: from ECS35455305 (unknown [69.72.27.231]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id C3FC5F580AF for ; Mon, 31 Jan 2011 14:15:47 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 31 Jan 2011 14:24:15 -0500 To: Message Abuse Report Format working group 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: <20110131191547.C3FC5F580AF@smtp.patriot.net> Subject: [marf] Nits in draft-jdfalk-maawg-cfblbcp-00.txt 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: Mon, 31 Jan 2011 19:16:38 -0000 Just a couple of items in the front of draft-jdfalk-maawg-cfblbcp-00.txt that need correction or clarification. The command is MAIL; FROM:reverse-path is an operand. The definition of rDNS should mention that the RR is a PTR, not an A. -- 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 Mon Jan 31 11:22:17 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 573133A6C4E for ; Mon, 31 Jan 2011 11:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 2+gwtsV2VLdJ for ; Mon, 31 Jan 2011 11:22:16 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 039BC3A6C4D for ; Mon, 31 Jan 2011 11:22:15 -0800 (PST) Received: from ECS35455305 (unknown [69.72.27.231]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 7BCDBF580AF for ; Mon, 31 Jan 2011 14:21:29 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 31 Jan 2011 14:29:57 -0500 To: marf@ietf.org In-Reply-To: <4D46BC57.7060509@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: <20110131192129.7BCDBF580AF@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: Mon, 31 Jan 2011 19:22:17 -0000 In <4D46BC57.7060509@tana.it>, on 01/31/2011 at 02:42 PM, Alessandro Vesely said: >For some background, the (Mail) Abuse Report Format, as its name >suggests, is primarily used to report abuse, It's more restrictive than that; the current RFC is for reporting abuse to the sending network, not to networks providing, e.g., drop boxes. -- 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 Mon Jan 31 15:05:12 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 024163A6BFF for ; Mon, 31 Jan 2011 15:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 HU1q+83xlSkG for ; Mon, 31 Jan 2011 15:05:10 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 9A3FC3A6B16 for ; Mon, 31 Jan 2011 15:05:07 -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 p0VN8KvQ013953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 31 Jan 2011 15:08:22 -0800 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p0VN8KvQ013953 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1296515302; bh=Lt2JozKyXHqrDJfGe2XobQmBY5PSa2uFGzblHDHeR 28=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=bzTzBFXhvjRN MUB0gHDUY8teXRI9ycAYkq7zStngEuO7NWleI9xws2eI5s4qnKjhCRzL6j4xVN8zaqJ GeNuoPdXLk1bIRqF9UtG57P7Ryxne4d2MwU4Lw0ynQsqjfM8T1xBDNEgUdt7ZLoWgly gsnRr4HtoFSXcKrytvS6Id5bY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: "J.D. Falk" In-Reply-To: <20110131192129.7BCDBF580AF@smtp.patriot.net> Date: Mon, 31 Jan 2011 15:08:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110131192129.7BCDBF580AF@smtp.patriot.net> 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: Mon, 31 Jan 2011 23:05:12 -0000 On Jan 31, 2011, at 11:29 AM, Shmuel (Seymour J.) Metz wrote: > In <4D46BC57.7060509@tana.it>, on 01/31/2011 > at 02:42 PM, Alessandro Vesely said: >=20 >> For some background, the (Mail) Abuse Report Format, as its name >> suggests, is primarily used to report abuse, >=20 > It's more restrictive than that; the current RFC is for reporting > abuse to the sending network, not to networks providing, e.g., drop > boxes. There's no reason it couldn't be used to report drop boxes, though = that's not a common practice today. That's part of what the = Reported-URI field was intended for. Reported-URI: mailto:dropbox@example.net From msk@cloudmark.com Mon Jan 31 19:51:31 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 403EC3A69E2 for ; Mon, 31 Jan 2011 19:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.081 X-Spam-Level: X-Spam-Status: No, score=-103.081 tagged_above=-999 required=5 tests=[AWL=-1.082, BAYES_00=-2.599, J_CHICKENPOX_101=0.6, 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 MK2a71JoNhWU for ; Mon, 31 Jan 2011 19:51: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 8C61C3A6833 for ; Mon, 31 Jan 2011 19:51:26 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 31 Jan 2011 19:54:42 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 31 Jan 2011 19:54:41 -0800 Thread-Topic: [marf] comments on DKIM Reporting draft Thread-Index: Acu8pg2wH7Wdww/8Rpift7TQmziRGgFG3/oQ Message-ID: References: <20CD3804-8E61-4B88-A65E-ADFD41467051@eudaemon.net> In-Reply-To: <20CD3804-8E61-4B88-A65E-ADFD41467051@eudaemon.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: [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: Tue, 01 Feb 2011 03:51:31 -0000 Hi Tim, and thanks for the feedback! > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of T= im Draegen > Sent: Tuesday, January 25, 2011 7:39 AM > To: marf@ietf.org > Subject: [marf] comments on DKIM Reporting draft >=20 > My apologies for being tardy! My concern is that too much is covered. >=20 > 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" I'd hate to have to split it into five individual documents (and I think ou= r AD might too) but I will if that appears to be the right path. Would any= one be interested in taking up document editor roles should such a split oc= cur? > #3 presents interesting ideas, for sure. However the draft contains a > few techno-warts: >=20 > - I'm having a hard time understanding how the SPF "reportopts" will be > used. The publisher of the record adds the policy piece of SPF that > leads to a (fail, softfail, neutral) result, usually by adding > something like "-all" or "~all" to their record. >=20 > EG, using the proposed syntax, I could write "v=3Dspf1 ip4:1.2.3.4 > report=3Demail.address reportopts=3Df ~all". This would specify that I wa= nt > reports on all SPF "fails" (distinct from "softfails"). However, my > "~all" means that all my non-authorized email will end up receiving > "softfails", resulting in me receiving zero reports. Section 6 of RFC4408 says modifiers (which is what these are) "MAY appear a= nywhere in the record, but SHOULD appear at the end, after all mechanisms".= It would probably be sufficient for this draft to say the results of usin= g these modifiers before any mechanism is undefined, i.e. they SHOULD alway= s go at the end. > - Lots of real-world SPF records "include:" other records. What if two > report-related extensions appear due to the use of include:? True, I hadn't thought of this. My gut reaction is to require that the rep= orting options within an included record SHOULD (or even MUST) be ignored. = Does it make sense to do that? > - SPF records describe "mechanisms" for identifying authorized servers > and "modifiers". The extensions are "modifiers", but I'm uncertain if > these will break existing SPF code, or if various implementors did the > right the thing. I don't think we can really handle the "did the wrong thing" case. RFC4408= makes it pretty clear that unknown modifiers should be ignored regardless = of where they are in the record. > - "reportsmtp=3D" is redundant with SPF's existing "exp:" modifier. Ah, good point. It should be removed. > #4 is interesting, but needs another rev of specification (does it > target deployers of authentication? is it meant to allow implementors > to debug their stacks?), preferably with input from real-world > operations. The auth-failure extensions to ARF are meant to allow relaying of forensic = material about specific message authentication failures, so "yes" to both q= uestions. An earlier version of this has been in use in OpenDKIM for some time now, t= hough I don't know that it's interoperating with anything (yet). > #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. 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 RFC5965b= is, or put it in its own draft updating RFC5965. What do others think? There is also discussion in another thread of supporting the IODEF format. = This draft could certainly include that as an option, although the issue o= f transport of the IODEF report would have to be covered as well. From sklist@kitterman.com Mon Jan 31 21:02:13 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 283163A6B60 for ; Mon, 31 Jan 2011 21:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_101=0.6, J_CHICKENPOX_53=0.6] 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 1ScIW+fvzByE for ; Mon, 31 Jan 2011 21:02:11 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by core3.amsl.com (Postfix) with ESMTP id 7BF823A6B5D for ; Mon, 31 Jan 2011 21:02:11 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id A75E0D04082; Mon, 31 Jan 2011 23:05:26 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1296536726; bh=KklDolMGTEgjnV8JL7z5YCjj7Dub2bVZHlONyTiuMGQ=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=dndqHaWq62kkSZ9ntAORrRqUOoYzKCZehfzAFEO3JLRclBmpoHQu1GqrxrP7PXo/U 4q1JUAi7+JOC/Zv3oPqVFeAYIk1gM1SSwbluGmDHYcAP+wy5g63PA3Zd1j3z3bMNRQ J1iXKWs+MeXtpByCmL8O+iwqohqhhXG8f+1jBDkU= Received: from [10.233.73.35] (40.sub-174-252-115.myvzw.com [174.252.115.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 18EE8D0403D; Mon, 31 Jan 2011 23:05:25 -0600 (CST) X-User-Agent: K-9 Mail for Android References: <20CD3804-8E61-4B88-A65E-ADFD41467051@eudaemon.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 01 Feb 2011 00:05:32 -0500 To: "marf@ietf.org" Message-ID: X-AV-Checked: ClamAV using ClamSMTP 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: Tue, 01 Feb 2011 05:02:13 -0000 "Murray S. Kucherawy" wrote: >Hi Tim, and thanks for the feedback! > >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf >Of Tim Draegen >> Sent: Tuesday, January 25, 2011 7:39 AM >> To: marf@ietf.org >> Subject: [marf] comments on DKIM Reporting draft >> >> My apologies for being tardy! My concern is that too much is >covered. >> >> AFAICT, this draft is actually 5 separate documents rolled up into >one: >> >> 1. DKIM reporting extensions >> 2. ADSP reporting extensions >> 3. SPF reporting extensions >> 4. ARF auth-failure extensions >> 5. ARF "redaction" > >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 do SPF Reporting Extensions. >> #3 presents interesting ideas, for sure. However the draft contains >a >> few techno-warts: >> >> - I'm having a hard time understanding how the SPF "reportopts" will >be >> used. The publisher of the record adds the policy piece of SPF that >> leads to a (fail, softfail, neutral) result, usually by adding >> something like "-all" or "~all" to their record. >> >> EG, using the proposed syntax, I could write "v=spf1 ip4:1.2.3.4 >> report=email.address reportopts=f ~all". This would specify that I >want >> reports on all SPF "fails" (distinct from "softfails"). However, my >> "~all" means that all my non-authorized email will end up receiving >> "softfails", resulting in me receiving zero reports. > >Section 6 of RFC4408 says modifiers (which is what these are) "MAY >appear anywhere in the record, but SHOULD appear at the end, after all >mechanisms". It would probably be sufficient for this draft to say the >results of using these modifiers before any mechanism is undefined, >i.e. they SHOULD always go at the end. > >> - Lots of real-world SPF records "include:" other records. What if >two >> report-related extensions appear due to the use of include:? > >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? > Include can only match,not match, or cause an error, so I think these new modifiers MUST not be processed is they are reached via an include. Alternatively, redirect modifiers MUST be followed. This would be consistent with the treatment of existing modifiers, exp and redirect. I can write spec language for this if you want. Scott K