From barryleiba.mailing.lists@gmail.com Mon May 3 14:58:42 2010 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 F26FD28C302 for ; Mon, 3 May 2010 14:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.974 X-Spam-Level: X-Spam-Status: No, score=-0.974 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_50=0.001] 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 6LdML-GfXt8I for ; Mon, 3 May 2010 14:58:41 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id CE8963A6A81 for ; Mon, 3 May 2010 14:58:40 -0700 (PDT) Received: by fxm4 with SMTP id 4so2884553fxm.31 for ; Mon, 03 May 2010 14:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=+FlTCuHCZHcMWGAjRoyOVaL36+OTLyvRB/sT01SV/Fk=; b=n9lOvrwj1YgVbH99Y8P1QEPWWWZaUEK7Fc8UJGr86gt5NadCSy+5FENjaEx7TtGHqy FoMTlyR8NIFMNYcmuBB0hFJzehxxNCY7Iksk6yypRlRZ1R1dFIFQqS5Z5v3+5rZlgyzJ 3vdTGt6avas7xh2m+5Q+kLokbVnuyMp4sgx6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=wsnClyOnBU02fXZ2AZsUbnZrCt7p9gfHrqVllTAdQ3Nkl9G6hDvQj1iu8UhAqB6yfX cy8qtJeERGZtqNyi4SxhG56hewrUcU2q6FNqoNcXsh8Bmww8IOTCLJ3rytBQ9J3xvt2S FrW6Ttsfn6g1PLg3TNkRG2X3Zhp6t19/vQjSE= MIME-Version: 1.0 Received: by 10.223.35.12 with SMTP id n12mr3644359fad.35.1272923903588; Mon, 03 May 2010 14:58:23 -0700 (PDT) Received: by 10.223.122.141 with HTTP; Mon, 3 May 2010 14:58:23 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 May 2010 17:58:23 -0400 Message-ID: From: Barry Leiba To: Message Abuse Report Format working group Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexey Melnikov Subject: Re: [marf] Proposed base-04 changes based on AD feedback X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org 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, 03 May 2010 21:58:42 -0000 An issue has come up in AD review and last call of the MARF base document ( http://tools.ietf.org/html/draft-ietf-marf-base ) ...and I think the question needs to be brought back to the working group because I'm not aware of any explicit discussion of it. In section 5, we have this text, which has been there since the working group -00 version (it was not in the pre-working-group versions): Additional report types (extension report types) or report header fields might be defined in the future by later revisions to this specification, or by registrations as described above. Extension report types and report header field names beginning with "x-" will never be defined as standard; such names are reserved for experimental use. Report types and report header field names not beginning with "x-" MUST be registered as described above and published in an Open Specification such as an RFC. Implementations using new report types or new report header fields MUST use the "x-" prefix until such time as the new name is registered by IANA. The issue is that it's questionable whether making this "x-" reservation is a good idea. In the revisions of RFC 822, it was decided that the long-standing presence of it there was very much NOT a good idea, in fact. History, for those who weren't here: In the DRUMS effort ( http://www.ietf.org/wg/concluded/drums ) there was a looooong discussion related to whether or not to carry forward the RFC 822 "x-" header text into what would become RFC 2822. The conclusion, the DRUMS WG consensus, was to drop it, because it causes more problems than it solves. It solves the problem of having a bad idea or a poor implementation grab the good or obvious name, then requiring the good implementation to use a sub-optimal name. But once there's significant deployment of any feature, it's very disruptive to change it. So what happened with RFC 822 was that people either ignored the requirement and used a non-X-name from the start (like "Importance" and "Priority"), or the X-name stuck, and just didn't get registered. So RFC 2822 (and now 5322) say nothing at all about names with "X-". The same situation could come up here, and it's arguable that it's a bad idea to start things out with X- as a reserved, non-registerable prefix. Because for this document the "x-" language has been in there since the -00 WG version, it has WG consensus based purely on having been there and not being objected to. But without specific discussions about it, it has no *explicit* WG consensus. I'm asking the working group, therefore, to discuss it specifically, and come to explicit consensus: either agree that the existing text is what the group wants there, despite the related DRUMS history, or revise those two paragraphs to remove the "x-" special case. Discussion is now open. Barry, as chair From yakov@shaftek.org Mon May 3 15:13:37 2010 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 478C428C314 for ; Mon, 3 May 2010 15:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.166 X-Spam-Level: X-Spam-Status: No, score=-0.166 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 WvGXFCPHUpSc for ; Mon, 3 May 2010 15:13:36 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 573023A6B0C for ; Mon, 3 May 2010 15:13:35 -0700 (PDT) Received: by wyb32 with SMTP id 32so112805wyb.31 for ; Mon, 03 May 2010 15:13:17 -0700 (PDT) Received: by 10.216.165.5 with SMTP id d5mr4357065wel.143.1272924796239; Mon, 03 May 2010 15:13:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.21.143 with HTTP; Mon, 3 May 2010 15:12:56 -0700 (PDT) In-Reply-To: References: From: Yakov Shafranovich Date: Mon, 3 May 2010 18:12:56 -0400 Message-ID: To: marf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [marf] Proposed base-04 changes based on AD feedback 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, 03 May 2010 22:13:37 -0000 This feature was added only in the first MARF draft. All drafts prior to Jan 2010 did not use "x-". I also went back and rechecked the archive and it seems that there was no discussion on this. My personal thoughts is to follow whatever the IESG feels is best for this. Yakov On Mon, May 3, 2010 at 5:58 PM, Barry Leiba wrote: > An issue has come up in AD review and last call of the MARF base document > ( http://tools.ietf.org/html/draft-ietf-marf-base ) > ...and I think the question needs to be brought back to the working > group because I'm not aware of any explicit discussion of it. > > In section 5, we have this text, which has been there since the > working group -00 version (it was not in the pre-working-group > versions): > > =A0 Additional report types (extension report types) or report header > =A0 fields might be defined in the future by later revisions to this > =A0 specification, or by registrations as described above. =A0Extension > =A0 report types and report header field names beginning with "x-" will > =A0 never be defined as standard; such names are reserved for > =A0 experimental use. =A0Report types and report header field names not > =A0 beginning with "x-" MUST be registered as described above and > =A0 published in an Open Specification such as an RFC. > > =A0 Implementations using new report types or new report header fields > =A0 MUST use the "x-" prefix until such time as the new name is > =A0 registered by IANA. > > The issue is that it's questionable whether making this "x-" > reservation is a good idea. =A0In the revisions of RFC 822, it was > decided that the long-standing presence of it there was very much NOT > a good idea, in fact. > > History, for those who weren't here: In the DRUMS effort > ( http://www.ietf.org/wg/concluded/drums ) > there was a looooong discussion related to whether or not to carry > forward the RFC 822 "x-" header text into what would become RFC 2822. > The conclusion, the DRUMS WG consensus, was to drop it, because it > causes more problems than it solves. =A0It solves the problem of having > a bad idea or a poor implementation grab the good or obvious name, > then requiring the good implementation to use a sub-optimal name. > > But once there's significant deployment of any feature, it's very > disruptive to change it. =A0So what happened with RFC 822 was that > people either ignored the requirement and used a non-X-name from the > start (like "Importance" and "Priority"), or the X-name stuck, and > just didn't get registered. =A0So RFC 2822 (and now 5322) say nothing at > all about names with "X-". > > The same situation could come up here, and it's arguable that it's a > bad idea to start things out with X- as a reserved, non-registerable > prefix. > > Because for this document the "x-" language has been in there since > the -00 WG version, it has WG consensus based purely on having been > there and not being objected to. =A0But without specific discussions > about it, it has no *explicit* WG consensus. > > I'm asking the working group, therefore, to discuss it specifically, > and come to explicit consensus: either agree that the existing text is > what the group wants there, despite the related DRUMS history, or > revise those two paragraphs to remove the "x-" special case. > > Discussion is now open. > > Barry, as chair > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > From msk@cloudmark.com Mon May 3 15:45:52 2010 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 94D0F3A6B20 for ; Mon, 3 May 2010 15:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=-1.796, BAYES_50=0.001] 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 0+6lPxOpxBTh for ; Mon, 3 May 2010 15:45:51 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id E02CB3A6B2C for ; Mon, 3 May 2010 15:45:51 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Mon, 3 May 2010 15:45:37 -0700 From: "Murray S. Kucherawy" To: "barryleiba@computer.org" , Message Abuse Report Format working group Date: Mon, 3 May 2010 15:45:36 -0700 Thread-Topic: [marf] Proposed base-04 changes based on AD feedback Thread-Index: AcrrC8RcJGGooxDzQ1yjT9NOiaGCqgABmOGQ 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 Cc: Alexey Melnikov Subject: Re: [marf] Proposed base-04 changes based on AD feedback 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, 03 May 2010 22:45:52 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Barry Leiba > Sent: Monday, May 03, 2010 2:58 PM > To: Message Abuse Report Format working group > Cc: Alexey Melnikov > Subject: Re: [marf] Proposed base-04 changes based on AD feedback >=20 > [...]=20 > Because for this document the "x-" language has been in there since > the -00 WG version, it has WG consensus based purely on having been > there and not being objected to. But without specific discussions > about it, it has no *explicit* WG consensus. >=20 > I'm asking the working group, therefore, to discuss it specifically, > and come to explicit consensus: either agree that the existing text is > what the group wants there, despite the related DRUMS history, or > revise those two paragraphs to remove the "x-" special case. >=20 > Discussion is now open. I'd be fine with removing it. I think I added it back when I inherited the= document, and it came in as a side effect of the Security Directorate revi= ew of RFC5451 which recommended its addition. That reviewer may not have h= ad the benefit of knowing the DRUMS debate and outcome, so perhaps adding i= t wasn't such a good idea. From shmuel+gen@patriot.net Tue May 4 02:09:22 2010 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 3D6BE3A6A02 for ; Tue, 4 May 2010 02:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.025 X-Spam-Level: * X-Spam-Status: No, score=1.025 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_50=0.001, DATE_IN_PAST_06_12=1.069] 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 2pLSjC9qXIGl for ; Tue, 4 May 2010 02:09:20 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 5A9C93A69C1 for ; Tue, 4 May 2010 02:09:20 -0700 (PDT) Received: from ECS35455305 (core-dc-1-54.dynamic-dialup.coretel.net [69.72.26.54]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 56EF0F580C0 for ; Tue, 4 May 2010 05:07:07 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Mon, 03 May 2010 20:49:36 -0400 To: marf@ietf.org In-Reply-To: <20100430161501.717AA28C111@core3.amsl.com> 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: <20100504090707.56EF0F580C0@smtp.patriot.net> Subject: Re: [marf] I-D Action:draft-ietf-marf-base-04.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: Tue, 04 May 2010 09:09:22 -0000 In <20100430161501.717AA28C111@core3.amsl.com>, on 04/30/2010 at 09:15 AM, Internet-Drafts@ietf.org said: >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. RFC 2046 does not require that a MIME compliant e-mail client automatically retrieve an external body, and, in fact, Section 9 warns of the security ramifications of doing so. -- 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 macfisherman@gmail.com Tue May 4 07:26:29 2010 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 918303A6C82 for ; Tue, 4 May 2010 07:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.192 X-Spam-Level: X-Spam-Status: No, score=-4.192 tagged_above=-999 required=5 tests=[AWL=-1.593, 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 GAtcMmfbP0Un for ; Tue, 4 May 2010 07:26:28 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id D875E28C123 for ; Tue, 4 May 2010 07:23:28 -0700 (PDT) Received: by ewy24 with SMTP id 24so1016794ewy.33 for ; Tue, 04 May 2010 07:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=AvUQ+Ws1dzdHRdEwYcWMYwJAxeZuXQ1fYUrVm3opcgo=; b=mnf0qqvZ4nfzaZVgkcFeum1M0G45Povr3KniF5SMdmVSkFNlygT7AEMOjm3VezjaUd fiC/sgcXfnOxAj55ue+gsYb3wozBSEh34dqfGpOf4iVD/39f9kQdGbS9sMPTwugphKQS 6wbX89GHSC2Upy4XJN9HAbm6O0N1E/nruv8ac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=PXHUFBkXJtEOmW3GeH2Jtl6AbVCKenFyEQ60uZ5TI1G/yu9F71EZEQVMG4U6bGRwqr iFfxEvOxW0ggKdUc18JTvWXUY/ExmaIh7emcAeStw5PEmTBduCs8FG2WFueRpp2OXLJP Uc3C3eVksTGi1EdScew1kXkn+BoGhmhpU4d+A= MIME-Version: 1.0 Received: by 10.213.79.77 with SMTP id o13mr1925478ebk.61.1272982988210; Tue, 04 May 2010 07:23:08 -0700 (PDT) Received: by 10.213.31.208 with HTTP; Tue, 4 May 2010 07:23:08 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 May 2010 10:23:08 -0400 Message-ID: From: Jeff Macdonald To: Message Abuse Report Format working group Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [marf] Proposed base-04 changes based on AD feedback 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, 04 May 2010 14:26:29 -0000 +1 to removing X-*. -- Jeff Macdonald Ayer, MA From johnl@iecc.com Tue May 4 08:41:21 2010 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 59A6A3A682E for ; Tue, 4 May 2010 08:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.992 X-Spam-Level: X-Spam-Status: No, score=-9.992 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3] 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 Q-XP7CrsrzkW for ; Tue, 4 May 2010 08:41:20 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id EB2A23A6C75 for ; Tue, 4 May 2010 08:41:17 -0700 (PDT) Received: (qmail 98830 invoked from network); 4 May 2010 15:41:03 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 4 May 2010 15:41:03 -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; s=k1005; olt=johnl@user.iecc.com; bh=Ux+U5aPWaLOVLUTt7k4wiItsWiq9iI0K37yBDRrJjZo=; b=Laq204tqN4fdOttlUod84EkMtWysk+VIIEpPADzx/BDRGfIW4kSXqixL6AZSaxSzg14GPNFuZjQ3kBwVrfYyiKvzSYLPrBGdK0jE9g8MSuf/hGj1Oa+fnabRi5tgXgHd0ffmxaE7iW6CDZQ93PlCO03usajVuP7B6OJn56NE/OA= 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; s=k1005; bh=Ux+U5aPWaLOVLUTt7k4wiItsWiq9iI0K37yBDRrJjZo=; b=p1Obvup7GfYkHOtXRjUvqlPYUG6yj12Odlw+ty5LltIY1gNZ9wAeBf1foYDWIn5mzg6+tBiOLiSlr742LKq9np6zVQmgYVjDOEcWmnVIMXSChrheSkvpErqwPtHHeyyGtwgVoFupyFvXYMl8rn1HShE/+h2oTQZBc55hOCplnW0= Date: 4 May 2010 15:40:59 -0000 Message-ID: <20100504154059.5103.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=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [marf] x-foo, was Proposed base-04 changes based on AD feedback 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, 04 May 2010 15:41:21 -0000 >I'd be fine with removing it. I think I added it back when I inherited >the document, and it came in as a side effect of the Security >Directorate review of RFC5451 which recommended its addition. That >reviewer may not have had the benefit of knowing the DRUMS debate and >outcome, so perhaps adding it wasn't such a good idea. Agree with both the history and getting rid of x- I suppose it would be more trouble than it's worth to ask them what changed since 5451. R's, John From barryleiba.mailing.lists@gmail.com Tue May 4 19:58:02 2010 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 41DD63A67B2 for ; Tue, 4 May 2010 19:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_50=0.001] 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 qOFsPX0HxkMQ for ; Tue, 4 May 2010 19:58:01 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 45FF63A6781 for ; Tue, 4 May 2010 19:58:01 -0700 (PDT) Received: by fxm4 with SMTP id 4so4197694fxm.31 for ; Tue, 04 May 2010 19:57:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:content-type; bh=CDrDI2vj/ZcDHCKB/KKbOyLYBG8wiP3s7nsA9OVu2xA=; b=xWogTj+dPHscjohfpjGKXJW1sWBlv809W6bcWcih74v887ACOYgFKV/2vLo1uXb62q MAUeGahZdba8rveO0r97mg9+wVE62PnihJnO4Rk+ncWARu+FTeERQzb74o2aD4BPBqJs ySHwSQhysTIBvkEv+VJ8VQ3jwI5luwOnoApco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=ltsr/LVZJ5+EJD3KP7NZeVL/vi8tajXEzeZu0RNa6TnYT81aE+n4WiPi6QrNjDORaJ ShAUJoHQroIgG8puqJOMGQ0OjGZXRJ/jqTJlthDhCYHhWH1Lzr6hYnaO86RVKKqMpoRa /iqesvfUXE7rZOwUiL25l0j5/rNVQlhQ/QVdo= MIME-Version: 1.0 Received: by 10.223.143.67 with SMTP id t3mr4855144fau.16.1273028263967; Tue, 04 May 2010 19:57:43 -0700 (PDT) Received: by 10.223.122.141 with HTTP; Tue, 4 May 2010 19:57:43 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 May 2010 22:57:43 -0400 Message-ID: From: Barry Leiba To: Message Abuse Report Format working group Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [marf] Proposed base-04 changes based on AD feedback X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org 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, 05 May 2010 02:58:02 -0000 [Putting this back in this thread, to get rid of the split. John, please don't keep splitting threads unless there really are two parallel discussions that need to be separated.] On Tue, May 4, 2010 at 11:40 AM, John Levine wrote: >>I'd be fine with removing it. I think I added it back when I inherited >>the document, and it came in as a side effect of the Security >>Directorate review of RFC5451 which recommended its addition. That >>reviewer may not have had the benefit of knowing the DRUMS debate and >>outcome, so perhaps adding it wasn't such a good idea. > > Agree with both the history and getting rid of x- > > I suppose it would be more trouble than it's worth to ask them > what changed since 5451. I suspect it's just a question of nobody's having noticed it when 5451 went through. The secdir reviewer asked for the change, Murray complied, and it didn't get noticed. This time, it did. Barry From yakov@shaftek.org Tue May 4 20:02:36 2010 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 88E043A6969 for ; Tue, 4 May 2010 20:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.008 X-Spam-Level: X-Spam-Status: No, score=-0.008 tagged_above=-999 required=5 tests=[AWL=-0.631, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 jIoT1TXCuTsD for ; Tue, 4 May 2010 20:02:35 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 8E25C3A68E9 for ; Tue, 4 May 2010 20:02:35 -0700 (PDT) Received: by wwi18 with SMTP id 18so1648880wwi.31 for ; Tue, 04 May 2010 20:02:18 -0700 (PDT) Received: by 10.216.186.194 with SMTP id w44mr2366528wem.186.1273028538160; Tue, 04 May 2010 20:02:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.21.143 with HTTP; Tue, 4 May 2010 20:01:58 -0700 (PDT) In-Reply-To: References: From: Yakov Shafranovich Date: Tue, 4 May 2010 23:01:58 -0400 Message-ID: To: barryleiba@computer.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Message Abuse Report Format working group Subject: Re: [marf] Proposed base-04 changes based on AD feedback 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, 05 May 2010 03:02:36 -0000 On Tue, May 4, 2010 at 10:57 PM, Barry Leiba wrote: > [Putting this back in this thread, to get rid of the split. =A0John, > please don't keep splitting threads unless there really are two > parallel discussions that need to be separated.] > > On Tue, May 4, 2010 at 11:40 AM, John Levine wrote: >>>I'd be fine with removing it. =A0I think I added it back when I inherite= d >>>the document, and it came in as a side effect of the Security >>>Directorate review of RFC5451 which recommended its addition. =A0That >>>reviewer may not have had the benefit of knowing the DRUMS debate and >>>outcome, so perhaps adding it wasn't such a good idea. >> >> Agree with both the history and getting rid of x- >> >> I suppose it would be more trouble than it's worth to ask them >> what changed since 5451. > > I suspect it's just a question of nobody's having noticed it when 5451 > went through. =A0The secdir reviewer asked for the change, Murray > complied, and it didn't get noticed. > > This time, it did. > As a separate note, is there going to be some sort of a note on IESG's site or perhaps an RFC so people are aware that "x-" is not a good thing for future standards? Yakov From barryleiba.mailing.lists@gmail.com Tue May 4 20:18:39 2010 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 BC6B93A6A2D for ; Tue, 4 May 2010 20:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 FrWdDfjZ9Ojm for ; Tue, 4 May 2010 20:18:38 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 5E2BE3A6A1E for ; Tue, 4 May 2010 20:18:37 -0700 (PDT) Received: by fxm4 with SMTP id 4so4205393fxm.31 for ; Tue, 04 May 2010 20:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=WtUP4WaJsrd0AFu1dIG9YphJWTQrUTuSvc8Md6Zhb58=; b=OAU/pTNbgaTR6lsaK59DrgtARJCE72Ystfxy/5CuwqxoyioMy6Jq35EKFhLMp8LfMM wTOCKEWEk6O9A66smwje/xlEXXbBIX4gBNqzu1YwTlji2gvJxJ3PL2E+vUQmo90lZteh ztwaOsSGGBp5pfhDVEKETG1LuQvvxhkeN6Arg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=i7jKpxYUd5a6/2IOJBatX9FwzEW8d4zVzTiOoFVxXQOtWleBt2M4TL4LflZqqpuAkA bU+fsCVZ3qz7Qd1rEtDu5wAcnAyt+f7ip4vYh5wS/y/g0BVWzR8WLpWU33CQKGK+Gl7R hZp/OY2Q0BWP1yE4m3kLqKQO0XYMbTGJlrWEg= MIME-Version: 1.0 Received: by 10.223.101.81 with SMTP id b17mr695019fao.17.1273029499622; Tue, 04 May 2010 20:18:19 -0700 (PDT) Received: by 10.223.122.141 with HTTP; Tue, 4 May 2010 20:18:19 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 May 2010 23:18:19 -0400 Message-ID: From: Barry Leiba To: Yakov Shafranovich , Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Cc: Message Abuse Report Format working group Subject: Re: [marf] Proposed base-04 changes based on AD feedback X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org 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, 05 May 2010 03:18:39 -0000 [Adding Alexey to the distribution.] On Tue, May 4, 2010 at 11:01 PM, Yakov Shafranovich wrote: > As a separate note, is there going to be some sort of a note on IESG's > site or perhaps an RFC so people are aware that "x-" is not a good > thing for future standards? Alexey: Would the IESG consider an IESG Statement about this? Or should someone kick off a "X- Prefixes Considered Harmful" RFC ? Barry From jdfalk-lists@cybernothing.org Tue May 11 13:32:32 2010 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 A8B243A69CD for ; Tue, 11 May 2010 13:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.055 X-Spam-Level: X-Spam-Status: No, score=-5.055 tagged_above=-999 required=5 tests=[AWL=-0.956, BAYES_50=0.001, RCVD_IN_BSP_OTHER=-0.1, 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 jlkpD4vZGtb6 for ; Tue, 11 May 2010 13:32:31 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id DBAD63A68FE for ; Tue, 11 May 2010 13:32:14 -0700 (PDT) Received: from rpco-bbakerd630.rpcorp.local (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4BKW1lx018275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 11 May 2010 14:32:03 -0600 From: "J.D. Falk" Content-Type: text/plain; charset=us-ascii Message-Id: Date: Tue, 11 May 2010 14:31:56 -0600 To: Message Abuse Report Format working group Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [marf] draft-jdfalk-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, 11 May 2010 20:32:32 -0000 Fellow MARFarians, I've written a draft titled "Advertising and Discovering Willingness to = Provide or Receive ARF Reports," which uses a DNS TXT record inspired by = (but necessarily separate from) the extensions to the DKIM record = proposed in draft-ietf-marf-dkim-reporting. There are three types of advertisements: ARF generators offering = feedback, ARF consumers requesting feedback, and mailbox providers who = wish to collect complaints from their end users. (I'm not certain if = this latter should stay in this document, or be split into another.) It needs a lot of work, but I wanted to seek your input before = continuing. http://tools.ietf.org/html/draft-jdfalk-marf-reporting-discovery-00 -- J.D. Falk Return Path Inc From jdfalk-lists@cybernothing.org Tue May 11 15:43:57 2010 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 CED8A3A6908 for ; Tue, 11 May 2010 15:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.304 X-Spam-Level: X-Spam-Status: No, score=-6.304 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, RCVD_IN_BSP_OTHER=-0.1, 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 V0FZIGU1L3bg for ; Tue, 11 May 2010 15:43:56 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 0D87C3A6A87 for ; Tue, 11 May 2010 15:43:54 -0700 (PDT) Received: from rpco-bbakerd630.rpcorp.local (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4BMhfa6020317 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 11 May 2010 16:43:43 -0600 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <563800D1-80BD-40EA-88B9-BEFF83C01F1C@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Tue, 11 May 2010 16:43:36 -0600 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1078) Subject: Re: [marf] draft-jdfalk-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, 11 May 2010 22:43:57 -0000 On May 11, 2010, at 2:31 PM, J.D. Falk wrote: > http://tools.ietf.org/html/draft-jdfalk-marf-reporting-discovery-00 I just noticed that xml2rfc lost my hangtags, with the result that = section 5 looks far less complete than it actually is. Oops. You can find the XML (which is relatively human-readable) at = http://disgruntled.net/~jdfalk/draft-jdfalk-marf-reporting-discovery-00.xm= l.txt -- and if anyone can help me figure out how that got lost, it'd be = much appreciated. -- J.D. Falk Return Path Inc From yakov@shaftek.org Tue May 11 16:28:36 2010 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 919DA3A69FC for ; Tue, 11 May 2010 16:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 GgACsPet2kwU for ; Tue, 11 May 2010 16:28:35 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 925B63A69CE for ; Tue, 11 May 2010 16:28:35 -0700 (PDT) Received: by wyb42 with SMTP id 42so595313wyb.31 for ; Tue, 11 May 2010 16:28:21 -0700 (PDT) Received: by 10.216.89.20 with SMTP id b20mr164429wef.58.1273620501162; Tue, 11 May 2010 16:28:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.30.79 with HTTP; Tue, 11 May 2010 16:28:01 -0700 (PDT) In-Reply-To: References: From: Yakov Shafranovich Date: Tue, 11 May 2010 19:28:01 -0400 Message-ID: To: "J.D. Falk" 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-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, 11 May 2010 23:28:36 -0000 Thanks. Is there a current demand for this in the ISP community? My impression was is that ISPs negotiate private arrangements for feedback loops and generally do not advertise such addresses. Yakov On Tue, May 11, 2010 at 4:31 PM, J.D. Falk wrote: > Fellow MARFarians, > > I've written a draft titled "Advertising and Discovering Willingness to P= rovide or Receive ARF Reports," which uses a DNS TXT record inspired by (bu= t necessarily separate from) the extensions to the DKIM record proposed in = draft-ietf-marf-dkim-reporting. > > There are three types of advertisements: ARF generators offering feedback= , ARF consumers requesting feedback, and mailbox providers who wish to coll= ect complaints from their end users. =A0(I'm not certain if this latter sho= uld stay in this document, or be split into another.) > > It needs a lot of work, but I wanted to seek your input before continuing= . > > http://tools.ietf.org/html/draft-jdfalk-marf-reporting-discovery-00 > > -- > J.D. Falk > Return Path Inc > > > > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > From johnl@iecc.com Tue May 11 18:33:47 2010 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 74C3D3A6AB5 for ; Tue, 11 May 2010 18:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.296 X-Spam-Level: X-Spam-Status: No, score=-10.296 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_50=0.001, GB_I_LETTER=-2, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3] 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 JHcmviqvf0lo for ; Tue, 11 May 2010 18:33:46 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 7A6F03A6AB8 for ; Tue, 11 May 2010 18:33:44 -0700 (PDT) Received: (qmail 25939 invoked from network); 12 May 2010 01:33:33 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 12 May 2010 01:33:33 -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; s=k1005; olt=johnl@user.iecc.com; bh=DRAOeyPfdbDO0ibYL0IwWMaCOkJzmcSqxJJwIOUMPgc=; b=f3x/vEvEZuyDGxwklGr2+r9FQ3zUav84TpTNJ+lPWdqE2VfqNfMmyY/bbhU6GgkhXzfU+GbW8F2uKNt368MBPNo4PN7g+fAL/Ku1cz5fKmBDAmLXi4q4GHF/2CZdYhmzV/a+1C7utlt4L4yVdZn1M3aObK1uxJcKJLgCJnK+eg0= 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; s=k1005; bh=DRAOeyPfdbDO0ibYL0IwWMaCOkJzmcSqxJJwIOUMPgc=; b=E1b0WpoLRs27xPsaiTpJsjNasUvP5H5PaP7jBIebCj+tXvYCGfZkem22yo9RubAkhjaVIGz9cwwBpgVfi3+rqSTXKwjeFa7NrUyI+nxaKRqkqJNlmjWDeVgpXHPPZo7LrcBGLY+LGGk205h+mJqcgFCgPhn2DimG7vsl8NOdcu0= Date: 12 May 2010 01:33:32 -0000 Message-ID: <20100512013332.20189.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=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [marf] draft-jdfalk-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, 12 May 2010 01:33:47 -0000 >It needs a lot of work, but I wanted to seek your input before continuing. I would suggest backing up a little bit and clarifying what problem(s) this is supposed to solve. I can see several possibilities: A. Automated discovery of reporting path for a mail service's own users B. Automated discovery of reporting path for a signing (or otherwise responsible) domain, either to send reports or to negotiate an FBL. C. Automated updates to reporting path for negotiated FBLs. D. We'll send reports under some conditions to some people. E. Various hints to humans about how to set stuff up. I think the ASRG argument established that there's some depand for A, although little agreement about much else, including for something like this, what domain a user would use to do the lookup since there is nothing in a normal POP, IMAP, or SMTP For B, there's probably some demand, since people use abuse.net, but there is at least as much demand to publish reporting addresses for IP ranges and ASNs. If I were the IESG (which, lord knows, I'm not), I'd want something that addressed all three, which is a huge can of worms both politically, and just technically identifying a place in the DNS to put the info which is credibly under the control of the right people and doesn't require adding a million new records for a million IP addresses. For C, it seems harmless, but I don't see much demand for it. For D, I don't understand the point, unless it's supposed to lead to a handshake of some sort to establish an FBL which seems fraught with security and abuse issues. For E, there seems little point in publishing anything beyond a single pointer to a web page, since people can read web pages at least as well as they can decode code letters. R's, John From dotis@mail-abuse.org Tue May 11 20:15:10 2010 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 ACE083A696C for ; Tue, 11 May 2010 20:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.828 X-Spam-Level: X-Spam-Status: No, score=-3.828 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_50=0.001, 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 nmhgiXuA+1Ll for ; Tue, 11 May 2010 20:15:07 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 5BF433A695B for ; Tue, 11 May 2010 20:14:52 -0700 (PDT) Received: from sjc-office-nat-223.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 046C3A94442 for ; Wed, 12 May 2010 03:14:35 +0000 (UTC) Message-ID: <4BEA1D1B.7010500@mail-abuse.org> Date: Tue, 11 May 2010 20:14:35 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: marf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] draft-jdfalk-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, 12 May 2010 03:15:11 -0000 On 5/11/10 1:31 PM, J.D. Falk wrote: > Fellow MARFarians, > > I've written a draft titled "Advertising and Discovering Willingness to Provide or Receive ARF Reports," which uses a DNS TXT record inspired by (but necessarily separate from) the extensions to the DKIM record proposed in draft-ietf-marf-dkim-reporting. > > There are three types of advertisements: ARF generators offering feedback, ARF consumers requesting feedback, and mailbox providers who wish to collect complaints from their end users. (I'm not certain if this latter should stay in this document, or be split into another.) > > It needs a lot of work, but I wanted to seek your input before continuing. > > http://tools.ietf.org/html/draft-jdfalk-marf-reporting-discovery-00 > From a security aspect, feedback discovery should depend upon verifiable information confirming a relationship between outbound and inbound servers. Otherwise, an unprotected discovery mechanism seems destine to become a method for abuse. The relationship could be cryptographically based, or use something as simple as having EHLO/HELO confirm IP addresses of outbound servers, with inbound servers being within the same domain. Feedback might represent paths not part of DSN. -Doug From vesely@tana.it Wed May 12 05:29:15 2010 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 8F5A83A6CA2 for ; Wed, 12 May 2010 05:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=-2.401, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MANGLED_SPAM=2.3, 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 D03nlJH0wFUy for ; Wed, 12 May 2010 05:29:14 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 374A03A6B9F for ; Wed, 12 May 2010 05:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1273667130; bh=jbU2voEaL0zbZhTVbUhqX09s4awtB9RTqKctR7qhS9c=; l=1526; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=VMEF+HT3LY5cXGgS3c5N++uq5mIlq1xlejO5uhLMTxmCDvfrlE7lYwOKqJCQC4NRD gtHDDaPqR34SarSvPa33ilr3d94ehqPvjvWCl9QYYCLZC77yu5APLCYV0PkM42kkqK MOWM3gk2ZE4ecMOljrYj6bb18ZMP/023Dw/7IVpY= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 12 May 2010 14:25:30 +0200 id 00000000005DC037.000000004BEA9E3A.0000293E Message-ID: <4BEA9E30.9030106@tana.it> Date: Wed, 12 May 2010 14:25:20 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: John Levine References: <20100512013332.20189.qmail@joyce.lan> In-Reply-To: <20100512013332.20189.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: marf@ietf.org Subject: [marf] A. Automated discovery of reporting path for a mail service's own users 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, 12 May 2010 12:29:15 -0000 On 12/May/10 03:33, John Levine wrote: > I would suggest backing up a little bit and clarifying what problem(s) > this is supposed to solve. I can see several possibilities: > > A. Automated discovery of reporting path for a mail service's own users It has been worked out in the ASRG. I'd suggest splitting the I-D, and stress this by splitting this thread :-) > I think the ASRG argument established that there's some demand for A, > although little agreement about much else, including for something > like this, what domain a user would use to do the lookup since there > is nothing in a normal POP, IMAP, or SMTP Let me invite anyone who hasn't done so already to review http://wiki.asrg.sp.am/wiki/Adding_a_junk_button_to_MUAs for this subject. That page doesn't point out clearly what are the good choices, just the pros and cons of each option discussed. IMHO: Using A-R (the "Per message approach") is the best method; "Via IMAP" is cuter but also more difficult and more restricted. JavaScript programming is not my forté, but I tried and examine A-R fields of my TB inbox. The one thing I've been able to do is to match the authserv-id with the "by" tag of the next "Received" line. If such token also matches the very first "Received" (which is the same one, in case the MX is the final server) I'd automatically trust it, and enable the button. In all other cases, I'd require specific configuration from the user/installer. Is that correct or do I miss something? From vesely@tana.it Wed May 12 05:30:48 2010 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 209AC3A6BFE for ; Wed, 12 May 2010 05:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.278 X-Spam-Level: X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[AWL=-1.159, BAYES_50=0.001, 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 KsrqLxzasmiT for ; Wed, 12 May 2010 05:30:47 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 268A43A6C0B for ; Wed, 12 May 2010 05:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1273667231; bh=lZb69fxTcXR7NDamszC3SpNYZ8zOR4FyRPzStTaQdkQ=; l=1377; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=O8xVWMxjr57T2zD973bSVyziWyhAY2YSw9l3eELBAG+IBWINxWukDvBaORXc7mYR7 vqvL5tRfR027T9mlAILvAhLG35U9zJ57s8z9HgKgYp3/2kTv1cI+CR0baMs67DR1Uq Ijhz35J+9mIh7BpTmjlxRiznDGFXk1roIzWiD0gg= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 12 May 2010 14:27:11 +0200 id 00000000005DC037.000000004BEA9E9F.00003295 Message-ID: <4BEA9E9A.4080308@tana.it> Date: Wed, 12 May 2010 14:27:06 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: John Levine References: <20100512013332.20189.qmail@joyce.lan> In-Reply-To: <20100512013332.20189.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Brian H. Trammell" , "Kathleen M. Moriarty" , marf@ietf.org Subject: [marf] B. Automated discovery of reporting path for a responsible domain, either to send reports or to negotiate an FBL 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, 12 May 2010 12:30:48 -0000 On 12/May/10 03:33, John Levine wrote: > B. Automated discovery of reporting path for a signing (or otherwise > responsible) domain, either to send reports or to negotiate an FBL. This is the next step, after A :-) > For B, there's probably some demand, since people use abuse.net, but there > is at least as much demand to publish reporting addresses for IP ranges > and ASNs. If I were the IESG (which, lord knows, I'm not), I'd want > something that addressed all three, which is a huge can of worms both > politically, and just technically identifying a place in the DNS to put > the info which is credibly under the control of the right people and doesn't > require adding a million new records for a million IP addresses. There is a known overlapping area between MARF and IODEF/RID. I've seen they are active, and their RID transport document is currently in LC; however, I don't know what lists they use, therefore I take the freedom to CC to that doc's authors' addresses. Requirements are probably very different. Can an extensible TXT resource record format be arranged so as to serve most purposes correctly, possibly without requiring a too huge discussion? The issue of whether to negotiate an FBL or just send reports belongs to MARF. But I'd be curious to know how network operators establish trust among one another. From barryleiba.mailing.lists@gmail.com Wed May 12 07:12:08 2010 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 0652E28C35D for ; Wed, 12 May 2010 07:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 aqvBG18hVlBB for ; Wed, 12 May 2010 07:12:07 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id EE75B3A68AA for ; Wed, 12 May 2010 06:59:28 -0700 (PDT) Received: by fxm7 with SMTP id 7so87491fxm.31 for ; Wed, 12 May 2010 06:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=ufhSKZqsXdahzCkBA/iJGsdjD6NJf7cECoWxgP23nUA=; b=fH0+wEv/A57bJAnXF3FvJGWGrslJAjvzK0cbi8t3fgfyNsqgq+DVQAMM5lfirQWalJ fQ64QwZvDW4QpMqD6nRXhGHRCaOhL6n1om+xoH5bYVfrpyqii5OjBHXlOkJUh0/KLHy8 9KUemhrj6Bg+uEYf9+WNnaJoU69hartVHM9F8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=Pvh3zSAGGU19Mtnj29wFA/234qJZy6I2uf6ZU4CXSZXj1cj9Vkgeq4lnHMVn1L2INU PKy5BAbJst7avqdU9XrmB0hOcGol7NwjtST1aa4A6+v8OCRUCzDURuaYiXXzETAxuXLl UmXZU8hZBbb8gTipU5NQDGMvu2qzyIUXw9LJs= MIME-Version: 1.0 Received: by 10.223.144.84 with SMTP id y20mr8220965fau.78.1273672754245; Wed, 12 May 2010 06:59:14 -0700 (PDT) Received: by 10.223.122.141 with HTTP; Wed, 12 May 2010 06:59:14 -0700 (PDT) In-Reply-To: <563800D1-80BD-40EA-88B9-BEFF83C01F1C@cybernothing.org> References: <563800D1-80BD-40EA-88B9-BEFF83C01F1C@cybernothing.org> Date: Wed, 12 May 2010 09:59:14 -0400 Message-ID: From: Barry Leiba To: "J.D. Falk" 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-marf-reporting-discovery X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org 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, 12 May 2010 14:12:08 -0000 > I just noticed that xml2rfc lost my hangtags, with the result that sectio= n > 5 looks far less complete than it actually is. =A0Oops. I've corrected JD's XML, and I'll send him the correction separately. Barry From jdfalk-lists@cybernothing.org Wed May 12 13:58:25 2010 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 4504A3A68FE for ; Wed, 12 May 2010 13:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.035 X-Spam-Level: X-Spam-Status: No, score=-5.035 tagged_above=-999 required=5 tests=[AWL=-0.936, BAYES_50=0.001, RCVD_IN_BSP_OTHER=-0.1, 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 L3h6JE7EoE3C for ; Wed, 12 May 2010 13:58:24 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 3BA733A68AF for ; Wed, 12 May 2010 13:58:23 -0700 (PDT) Received: from rpco-bbakerd630.rpcorp.local (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4CKwATP008320 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 12 May 2010 14:58:12 -0600 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <4CCC2CE0-4742-434C-9CC0-090E056AA810@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Wed, 12 May 2010 14:58:05 -0600 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1078) Subject: Re: [marf] draft-jdfalk-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, 12 May 2010 20:58:25 -0000 On May 11, 2010, at 5:28 PM, Yakov Shafranovich wrote: > Is there a current demand for this in the ISP community? My impression > was is that ISPs negotiate private arrangements for feedback loops and > generally do not advertise such addresses. Most are fairly public that they have feedback loops, and then they use = their own criteria (which varies, but is generally along the lines of = "don't be a spammer") to decide who gets in. That's why I included the = "gp=3Dr" policy, whereby a Feedback Generator can specify that reports = will be provided only after the prospective consumer has completed an = application process found at URI defined by the "gu=3D" tag. I expect that that'll be the most common configuration at first. -- J.D. Falk Return Path Inc From jdfalk-lists@cybernothing.org Wed May 12 13:58:31 2010 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 300193A67FD for ; Wed, 12 May 2010 13:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.268 X-Spam-Level: X-Spam-Status: No, score=-6.268 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, RCVD_IN_BSP_OTHER=-0.1, 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 nwQtmS6L3yi1 for ; Wed, 12 May 2010 13:58:30 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id D3FA63A67D9 for ; Wed, 12 May 2010 13:58:24 -0700 (PDT) Received: from rpco-bbakerd630.rpcorp.local (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4CKwATQ008320 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 12 May 2010 14:58:14 -0600 References: <20100512013332.20189.qmail@joyce.lan> <4BEA9E30.9030106@tana.it> In-Reply-To: <4BEA9E30.9030106@tana.it> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <1CD59A15-72CD-4929-83D3-98D3904140EC@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Wed, 12 May 2010 14:58:12 -0600 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1078) Subject: Re: [marf] A. Automated discovery of reporting path for a mail service's own users 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, 12 May 2010 20:58:31 -0000 On May 12, 2010, at 6:25 AM, Alessandro Vesely wrote: > On 12/May/10 03:33, John Levine wrote: >> I would suggest backing up a little bit and clarifying what = problem(s) >> this is supposed to solve. I can see several possibilities: >>=20 >> A. Automated discovery of reporting path for a mail service's own = users >=20 > It has been worked out in the ASRG. I'd suggest splitting the I-D, and = stress this by splitting this thread :-) And I'm entirely open to this idea -- possibly even in favor -- but was = hoping for more WG discussion about it before splitting off a new draft. -- J.D. Falk Return Path Inc From jdfalk-lists@cybernothing.org Wed May 12 14:35:08 2010 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 C38333A696D for ; Wed, 12 May 2010 14:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.297 X-Spam-Level: X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_BSP_OTHER=-0.1, 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 b35Vd8GxqzAo for ; Wed, 12 May 2010 14:35:08 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 0F9123A6920 for ; Wed, 12 May 2010 14:35:06 -0700 (PDT) Received: from rpco-bbakerd630.rpcorp.local (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4CLYsta008981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 12 May 2010 15:34:56 -0600 References: <20100512213027.4E6533A6953@core3.amsl.com> From: "J.D. Falk" Content-Type: text/plain; charset=us-ascii Message-Id: <249A4E12-305C-4530-816A-033DB2C2F039@cybernothing.org> Date: Wed, 12 May 2010 15:34:48 -0600 To: Message Abuse Report Format working group Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [marf] Fwd: New Version Notification for draft-jdfalk-marf-reporting-discovery-01 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, 12 May 2010 21:35:08 -0000 The xml2rfc issues are fixed, so I submitted an -01 which should be = easier to read -- and incorporates many of the suggestions offered thus = far. (Next, I need to figure out why the submission tool grabs my = organization name instead of my actual name.) Begin forwarded message: > From: IETF I-D Submission Tool > Date: May 12, 2010 3:30:27 PM MDT > To: ietf@cybernothing.org > Subject: New Version Notification for = draft-jdfalk-marf-reporting-discovery-01=20 >=20 >=20 > A new version of I-D, draft-jdfalk-marf-reporting-discovery-01.txt has = been successfully submitted by Return Path and posted to the IETF = repository. >=20 > Filename: draft-jdfalk-marf-reporting-discovery > Revision: 01 > Title: Advertising and Discovering Willingness to = Provide or Receive ARF Reports > Creation_date: 2010-05-12 > WG ID: Independent Submission > Number_of_pages: 11 >=20 > Abstract: > This document defines a method for network operators to advertise > their willingness to send feedback about received email to other > parties, and for those other parties to advertise their willingness > to receive such feedback. >=20 >=20 >=20 > The IETF Secretariat. >=20 -- J.D. Falk Return Path Inc From barryleiba.mailing.lists@gmail.com Wed May 12 17:33:42 2010 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 485143A6947 for ; Wed, 12 May 2010 17:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_20=-0.74] 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 4Rb4BzmLhsWF for ; Wed, 12 May 2010 17:33:41 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 562153A6908 for ; Wed, 12 May 2010 17:33:41 -0700 (PDT) Received: by fxm7 with SMTP id 7so765436fxm.31 for ; Wed, 12 May 2010 17:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=T293Ne6dOdydzcnseoeh2iRNqJK8TQyYOfxpQB2GAdg=; b=q5dTn9t54dMUuBaozOF4o2F01XYp01gN8xojahWk29H6StMlUgQylxvBUZiaFEghfY 4HYRf5xd+czsRDl/AkpLymyZEJH0AZLBDHODFdNEkOSmsfuzBndKfo8Mwu65Jk8dGxnr X4H1scYyAZQfveTAXdblsglqZfawp/BHUP21c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=qxNHOEqpFRzwzPVwwz719m64vUC6VgTmcXX6dfyuI1DLReQbUu2kI0bb2HsNJlgGG+ KnKfvPoo8ud6lUXEUO8Gi/fWlB2W8dwS/B5VVbzBNDbNrpxUZ5aJMy4HlLdYbZqcB4Fz UK1GR/t+G0eONJ84BPXlktnRjCQELFeDMIOEQ= MIME-Version: 1.0 Received: by 10.223.101.4 with SMTP id a4mr9109481fao.71.1273710808217; Wed, 12 May 2010 17:33:28 -0700 (PDT) Received: by 10.223.122.141 with HTTP; Wed, 12 May 2010 17:33:28 -0700 (PDT) In-Reply-To: <249A4E12-305C-4530-816A-033DB2C2F039@cybernothing.org> References: <20100512213027.4E6533A6953@core3.amsl.com> <249A4E12-305C-4530-816A-033DB2C2F039@cybernothing.org> Date: Wed, 12 May 2010 20:33:28 -0400 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] Fwd: New Version Notification for draft-jdfalk-marf-reporting-discovery-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 00:33:42 -0000 > (Next, I need to figure out why the submission tool grabs my organization > name instead of my actual name.) Just for the fork of it, try re-ordering the attributes in the "author" element, to put them in the order "initials", "surname", "fullname". See if that makes any difference. And, by the way, you can remove the "month" attribute from the "date" element, and it will fill in the current month (and day). That way, you don't have to change it every month. Barry From msk@cloudmark.com Wed May 12 20:02:09 2010 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 4B35B3A69BE for ; Wed, 12 May 2010 20:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=-0.721, 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 StMxQ7AvfiaZ for ; Wed, 12 May 2010 20:02:08 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id A642A3A69FF for ; Wed, 12 May 2010 20:02:01 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Wed, 12 May 2010 20:01:52 -0700 From: "Murray S. Kucherawy" To: "barryleiba@computer.org" Date: Wed, 12 May 2010 20:01:30 -0700 Thread-Topic: [marf] Fwd: New Version Notification for draft-jdfalk-marf-reporting-discovery-01 Thread-Index: AcryM++nayWG3AcXR5KYF0o2ub3eGgAFKY1z Message-ID: References: <20100512213027.4E6533A6953@core3.amsl.com> <249A4E12-305C-4530-816A-033DB2C2F039@cybernothing.org>, 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: Message Abuse Report Format working group Subject: Re: [marf] Fwd: New Version Notification for draft-jdfalk-marf-reporting-discovery-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 03:02:09 -0000 I also suggested he open a bug about the submission tool, because really th= at shouldn't be an issue.= From shmuel+gen@patriot.net Thu May 13 03:13:39 2010 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 5C0B73A6C04 for ; Thu, 13 May 2010 03:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_21=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 3RBCO0FebQqz for ; Thu, 13 May 2010 03:13:38 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 3C1183A6B89 for ; Thu, 13 May 2010 03:12:48 -0700 (PDT) Received: from ECS35455305 (unknown [208.103.155.210]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 22E41F5808A for ; Thu, 13 May 2010 06:10:20 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Thu, 13 May 2010 05:50:56 -0400 To: Message Abuse Report Format working group In-Reply-To: <249A4E12-305C-4530-816A-033DB2C2F039@cybernothing.org> 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: <20100513101021.22E41F5808A@smtp.patriot.net> Subject: Re: [marf] Fwd: New Version Notification for draft-jdfalk-marf-reporting-discovery-01 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: Thu, 13 May 2010 10:13:39 -0000 In <249A4E12-305C-4530-816A-033DB2C2F039@cybernothing.org>, on 05/12/2010 at 03:34 PM, "J.D. Falk" said: >The xml2rfc issues are fixed, so I submitted an -01 which should be >easier to read -- and incorporates many of the suggestions offered >thus far. Isn't it desirable to allow a consumer to specify a policy of rp=r? r Open to reports only after the prospective generator has completed a registration process, which may be found by the by the URI defined by the u? tag below. ... u? URI for additional information. This field SHOULD be defined for a policy of "c", "o" or "u", and MUST be defined when the policy is "r". Otherwise, the field is optional; there is no default. As an alternative to a new u?= field, the definition of uu= could be expanded. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From vesely@tana.it Thu May 13 09:35:24 2010 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 98A593A695E for ; Thu, 13 May 2010 09:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=-1.116, BAYES_50=0.001, 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 VpgZfzWcvTaE for ; Thu, 13 May 2010 09:35:23 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 1FAA03A6C58 for ; Thu, 13 May 2010 09:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1273768498; bh=RD4Al0reUTFrubPg1Wscr+ZppJF4EQSgaU7pUpKuTGA=; l=2066; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=bjub3i0sfnu8AzyE0olMvEwRZcYBsToYr88m2w/S0iQ6bWUEoi06KqZQzncNuO+Iv qlZWe6+1fj28xseznDEubj8Fp7WXDQ6v1rH+KN6PrrbA9bBVnJseL+xhJKp+Jdvlm/ n4o/MSPTe4YlSOXUCjM2ff27yDLzC3WMbhidgHRU= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 13 May 2010 18:34:58 +0200 id 00000000005DC03B.000000004BEC2A32.0000575B Message-ID: <4BEC2A31.8070901@tana.it> Date: Thu, 13 May 2010 18:34:57 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: marf@ietf.org References: <20100512213027.4E6533A6953@core3.amsl.com> <249A4E12-305C-4530-816A-033DB2C2F039@cybernothing.org> In-Reply-To: <249A4E12-305C-4530-816A-033DB2C2F039@cybernothing.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] Fwd: New Version Notification for draft-jdfalk-marf-reporting-discovery-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 16:35:24 -0000 On 12/May/10 23:34, J.D. Falk wrote: >> A new version of I-D, draft-jdfalk-marf-reporting-discovery-01.txt has been successfully submitted by Return Path and posted to the IETF repository. >> >> Filename: draft-jdfalk-marf-reporting-discovery >> Revision: 01 >> Title: Advertising and Discovering Willingness to Provide or Receive ARF Reports >> Creation_date: 2010-05-12 Three points: *Consumers vs generators* The new paragraph about generators is rather puzzling, as it considers a generator who wishes to send a report to a consumer. It may be worth to note --in an earlier section-- that a (prospect) consumer is one who sends a message and is worried about its worthiness. That is, if the sending MTA is wary, e.g. because the number of recipients exceeds some limit, it may want to check each recipient's domain. An ADMD would keep a database of the domains with whom they have established an FBL already. For new domains, this I-D describes how to discover whether it is possible to establish a new FBL. But how? Scalability requires that an application process can be started right away, automatically, while the message is being relayed. Please note that we have an alternative to DNS here. The FBL policy can also be advertised in an ehlo-line, e.g. 250-FBL_report gp=r; gu=http://postmaster.example.com/ That would save a query, but is only available for client software that has access to the full ehlo response of each server. *Record format intro* There should be some text introducing the tags, near the beginning of section 5. I'd propose something like Each resource record consists of a list of "tag=value" elements terminated by a semicolon. *Consistency with other mailboxes* An abuse-mailbox is often defined in whois records of registered domains (where it is subject to query limits.) In addition, RFC 2142 mandates abuse@example.com. Should the published "r=" address match any of these? In some cases, shouldn't it default to that abuse@example.com? From jdfalk-lists@cybernothing.org Thu May 13 16:02:52 2010 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 AB4273A682E for ; Thu, 13 May 2010 16:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.344 X-Spam-Level: X-Spam-Status: No, score=-6.344 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, RCVD_IN_BSP_OTHER=-0.1, 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 GP4-TLp4VW1v for ; Thu, 13 May 2010 16:02:51 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id B27FD3A684A for ; Thu, 13 May 2010 16:02:51 -0700 (PDT) Received: from [10.0.2.142] (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4DN1pgX001079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 13 May 2010 17:02:41 -0600 References: <20100512213027.4E6533A6953@core3.amsl.com> <249A4E12-305C-4530-816A-033DB2C2F039@cybernothing.org>, In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <5CC811DF-4D3F-4C36-A2B5-C6E41C42202C@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Thu, 13 May 2010 17:02:41 -0600 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1078) Subject: Re: [marf] Fwd: New Version Notification for draft-jdfalk-marf-reporting-discovery-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 23:02:52 -0000 On May 12, 2010, at 9:01 PM, Murray S. Kucherawy wrote: > I also suggested he open a bug about the submission tool, because = really that shouldn't be an issue. They say they don't know why it's happening, but a new version should be = released soon which won't have that problem. -- J.D. Falk Return Path Inc From shmuel+gen@patriot.net Fri May 14 03:24:24 2010 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 DC8ED3A6B23 for ; Fri, 14 May 2010 03:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001] 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 mXKHGVJXDz89 for ; Fri, 14 May 2010 03:24:23 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 456373A659A for ; Fri, 14 May 2010 03:21:49 -0700 (PDT) Received: from ECS35455305 (unknown [208.103.155.209]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id D4EABF5809C for ; Fri, 14 May 2010 06:19:20 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Fri, 14 May 2010 06:17:39 -0400 To: marf@ietf.org In-Reply-To: <4BEC2A31.8070901@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: <20100514101920.D4EABF5809C@smtp.patriot.net> Subject: Re: [marf] Fwd: New Version Notification for draft-jdfalk-marf-reporting-discovery-01 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: Fri, 14 May 2010 10:24:25 -0000 In <4BEC2A31.8070901@tana.it>, on 05/13/2010 at 06:34 PM, Alessandro Vesely said: >Please note that we have an alternative to DNS here. The FBL policy >can also be advertised in an ehlo-line, e.g. > 250-FBL_report gp=r; gu=http://postmaster.example.com/ IMHO that's the wrong way to do it. There's a well defined mechanism for extending SMTP; why not use it instead of relying on ad hoc parsing of free text fields? C: EHLO example.com S: 250-Welcom to bar.com S: 250-MARF S: 250 8BITMIME C: MARFINFO S: 250 FBL_report gp=r; gu=http://postmaster.example.com/ >*Consistency with other mailboxes* >An abuse-mailbox is often defined in whois records of registered >domains (where it is subject to query limits.) If we're going to suggest relying on whois data then we should specify the syntax of the relevant line in the whois record. >RFC 2142 mandates abuse@example.com. It mandates having a functional abuse mailbox; it doesn't prohibit having other role accounts. It might make sense to have distinct default mailboxes for report and text. -- 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 MAdkins05@aol.com Fri May 14 07:19:58 2010 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 30E973A6B01 for ; Fri, 14 May 2010 07:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 XeIGTYQu9GQu for ; Fri, 14 May 2010 07:19:55 -0700 (PDT) Received: from imr-ma06.mx.aol.com (imr-ma06.mx.aol.com [64.12.78.142]) by core3.amsl.com (Postfix) with ESMTP id BA0AE3A6B3A for ; Fri, 14 May 2010 07:17:29 -0700 (PDT) Received: from imo-ma02.mx.aol.com (imo-ma02.mx.aol.com [64.12.78.137]) by imr-ma06.mx.aol.com (8.14.1/8.14.1) with ESMTP id o4EEH0rx028957 for ; Fri, 14 May 2010 10:17:00 -0400 Received: from MAdkins05@aol.com by imo-ma02.mx.aol.com (mail_out_v42.9.) id l.d0b.6c8caf0c (34992) for ; Fri, 14 May 2010 10:16:55 -0400 (EDT) Received: from smtprly-mc03.mx.aol.com (smtprly-mc03.mx.aol.com [64.12.95.99]) by cia-db01.mx.aol.com (v129.4) with ESMTP id MAILCIADB015-d3d94bed5b4f181; Fri, 14 May 2010 10:16:55 -0400 Received: from webmail-m074 (webmail-m074.sim.aol.com [64.12.141.32]) by smtprly-mc03.mx.aol.com (v129.4) with ESMTP id MAILSMTPRLYMC033-d3d94bed5b4f181; Fri, 14 May 2010 10:16:47 -0400 To: MARF@IETF.ORG Date: Fri, 14 May 2010 10:16:47 -0400 X-AOL-IP: 71.198.26.109 In-Reply-To: <20100514101920.D4EABF5809C@smtp.patriot.net> X-MB-Message-Source: WebUI MIME-Version: 1.0 From: madkins05@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CCC187392CE0FD_75C_16ED8_webmail-m074.sysops.aol.com" X-Mailer: AOL Webmail 31650-STANDARD Received: from 71.198.26.109 by webmail-m074.sysops.aol.com (64.12.141.32) with HTTP (WebMailUI); Fri, 14 May 2010 10:16:47 -0400 Message-Id: <8CCC18739105071-75C-AD96@webmail-m074.sysops.aol.com> X-AOL-SENDER: MAdkins05@aol.com Subject: Re: [marf] Fwd: New Version Notification for draft-jdfalk-marf-reporting-discovery-01 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 May 2010 14:19:58 -0000 ----------MB_8CCC187392CE0FD_75C_16ED8_webmail-m074.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Why do it during the SMTP transaction? That data is not needed at the ti= me the message is delivered. It is needed at the time feedback is generat= ed. =20 =20 =20 -----Original Message----- From: Shmuel (Seymour J.) Metz To: marf@ietf.org Sent: Fri, May 14, 2010 3:17 am Subject: Re: [marf] Fwd: New Version Notification for draft-jdfalk-marf-re= porting-discovery-01 In <4BEC2A31.8070901@tana.it>, on 05/13/2010 at 06:34 PM, Alessandro Vesely said: >Please note that we have an alternative to DNS here. The FBL policy=20 >can also be advertised in an ehlo-line, e.g. > 250-FBL_report gp=3Dr; gu=3Dhttp://postmaster.example.com/ IMHO that's the wrong way to do it. There's a well defined mechanism for extending SMTP; why not use it instead of relying on ad hoc parsing of free text fields? C: EHLO example.com S: 250-Welcom to bar.com S: 250-MARF S: 250 8BITMIME C: MARFINFO S: 250 FBL_report gp=3Dr; gu=3Dhttp://postmaster.example.com/ >*Consistency with other mailboxes* >An abuse-mailbox is often defined in whois records of registered=20 >domains (where it is subject to query limits.)=20 If we're going to suggest relying on whois data then we should specify the syntax of the relevant line in the whois record. >RFC 2142 mandates abuse@example.com. It mandates having a functional abuse mailbox; it doesn't prohibit having other role accounts. It might make sense to have distinct default mailboxes for report and text. --=20 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) _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf =20 ----------MB_8CCC187392CE0FD_75C_16ED8_webmail-m074.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
Why do= it during the SMTP transaction?  That data is not needed at the time= the message is delivered.  It is needed at the time feedback is gene= rated.



In <4BEC2A31.8070901@tana.it>,=
 on 05/13/2010

   at 06:34 PM, Alessandro Vesely <vesely@tana.it> said:



>Please note that we have an alternative to DNS here. The FBL policy 
>can also be advertised in an ehlo-line, e.g.

>  250-FBL_report gp=3Dr; gu=3Dhttp://postmaster.example.=
com/



IMHO that's the wrong way to do it. There's a well defined mechanism

for extending SMTP; why not use it instead of relying on ad hoc

parsing of free text fields?



 C: EHLO example.com

 S: 250-Welcom to bar.com

 S: 250-MARF

 S: 250 8BITMIME

 C: MARFINFO

 S: 250 FBL_report gp=3Dr; gu=3Dhttp://postmaster.example.co=
m/



>*Consistency with other mailboxes*

>An abuse-mailbox is often defined in whois records of registered 

>domains (where it is subject to query limits.) 



If we're going to suggest relying on whois data then we should specify

the syntax of the relevant line in the whois record.



>RFC 2142 mandates abuse@example.com.



It mandates having a functional abuse mailbox; it doesn't prohibit

having other role accounts. It might make sense to have distinct

default mailboxes for report and text.



-- 

     Shmuel (Seymour J.) Metz, SysProg and JOAT

     Atid/2        <http://patriot.net/~shmuel>

We don't care. We don't have to care, we're Congress.

(S877: The Shut up and Eat Your spam act of 2003)



_______________________________________________

marf mailing list

marf@ietf.org<=
/a>

https://www.ietf.org/mailman/listinfo/marf
----------MB_8CCC187392CE0FD_75C_16ED8_webmail-m074.sysops.aol.com-- From dotis@mail-abuse.org Fri May 14 10:52:14 2010 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 AB9093A6C03 for ; Fri, 14 May 2010 10:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.845 X-Spam-Level: X-Spam-Status: No, score=-3.845 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_50=0.001, 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 qfmMDvnwYdzW for ; Fri, 14 May 2010 10:52:13 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 3ABDA3A6C01 for ; Fri, 14 May 2010 10:52:11 -0700 (PDT) Received: from sjc-office-nat-223.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 7DB0FA9447E for ; Fri, 14 May 2010 17:51:56 +0000 (UTC) Message-ID: <4BED8DBC.8040402@mail-abuse.org> Date: Fri, 14 May 2010 10:51:56 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: marf@ietf.org References: <20100514101920.D4EABF5809C@smtp.patriot.net> In-Reply-To: <20100514101920.D4EABF5809C@smtp.patriot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] Fwd: New Version Notification for draft-jdfalk-marf-reporting-discovery-01 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 May 2010 17:52:14 -0000 On 5/14/10 3:17 AM, Shmuel (Seymour J.) Metz wrote: > Please note that we have an alternative to DNS here. The FBL policy > > can also be advertised in an ehlo-line, e.g. 250-FBL_report gp=r; > > gu=http://postmaster.example.com/ > > IMHO that's the wrong way to do it. There's a well defined mechanism > for extending SMTP; why not use it instead of relying on ad hoc > parsing of free text fields? > > C: EHLO example.com S: 250-Welcom to bar.com S: 250-MARF S: 250 > 8BITMIME C: MARFINFO S: 250 FBL_report gp=r; > gu=http://postmaster.example.com/ This suggests contacting an inbound server to ask where to send feedback related to some other outbound server which means this path can be easily abused. Without a method to verify a message is associated with a specific feedback server, the path is likely to be targeted for abuse, as abuse@ has been. > > *Consistency with other mailboxes* An abuse-mailbox is often > > defined in whois records of registered domains (where it is > > subject to query limits.) > If we're going to suggest relying on whois data then we should > specify the syntax of the relevant line in the whois record. > > RFC 2142 mandates abuse@example.com. > It mandates having a functional abuse mailbox; it doesn't prohibit > having other role accounts. It might make sense to have distinct > default mailboxes for report and text. Automation related to feedback needs a defensive strategy. Allow clients to indicate where feedback is to be directed. This path should be within the EHLO domain that permits the outbound servers address to be verified with a forward referenced address or APL. C: EHLO mx-001.example.com S: 250-Welcome mx-001.example.com [192.168.1.1] to bar.com S: 250-MARF S: 250 8BITMIME C: MARFPATH S: 250 Ok The server might also respond with 252 or 554 Unable to verify mx-001.example.com. This approach would exclude typical bot spam engines while also providing a method to defend the feedback path. -Doug From vesely@tana.it Sat May 15 04:54:39 2010 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 058BF3A6A6A for ; Sat, 15 May 2010 04:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.407 X-Spam-Level: X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[AWL=-1.288, BAYES_50=0.001, 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 AuitYDKdvEf5 for ; Sat, 15 May 2010 04:54:37 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 6E3133A6A75 for ; Sat, 15 May 2010 04:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1273924463; bh=J1DExj9SqlO2dagtVvJ9A6EfAW0Aad24qGKPJPs6R9w=; l=2908; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=YNxwtoMeR8kTqeN7wgziIobOmadS9RuO2se0S8KXVp907YSD+Tb7Uu0E4KrkvUi/5 Rls/GTqAs08OuRWIZDlQQTXFCBXvG5STRp8Ggyu7jNvsJbYqx3uSFzEBDR/wRUNiKE A/qJ/DeD4Y1ixd8k3yRfRZgarp0VkfJ8rD3+nC04= Received: from mach-4.local (93-32-136-234.ip33.fastwebnet.it [93.32.136.234]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 15 May 2010 13:54:23 +0200 id 00000000005DC03B.000000004BEE8B6F.000021F7 Message-ID: <4BEE8B76.3030601@tana.it> Date: Sat, 15 May 2010 13:54:30 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: marf@ietf.org References: <20100514101920.D4EABF5809C@smtp.patriot.net> <4BED8DBC.8040402@mail-abuse.org> In-Reply-To: <4BED8DBC.8040402@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] Fwd: New Version Notification for draft-jdfalk-marf-reporting-discovery-01 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, 15 May 2010 11:54:39 -0000 Douglas Otis wrote: > On 5/14/10 3:17 AM, Shmuel (Seymour J.) Metz wrote: >> C: EHLO example.com >> S: 250-Welcom to bar.com >> S: 250-MARF >> S: 250 8BITMIME >> C: MARFINFO >> S: 250 FBL_report gp=r; gu=http://postmaster.example.com/ > > This suggests contacting an inbound server to ask where to send feedback > related to some other outbound server Not really. It is contacting an inbound server to ask where to _apply_ in order to receive feedback in case messages originating by this client will be reported as spam. Such info is not tied to the specific message at hand, except that since the client is sending mail there, it may be interested in the FBL. Currently, clients get the few existing URLs of this type by word of mouth. In addition, those "postmaster" sites are designed for interactivity. A non-scalable setup. > which means this path can be easily abused. Correct, nevertheless. > Without a method to verify a message is associated with a specific > feedback server, the path is likely to be targeted for abuse What is a "feedback server", the generator or the consumer? > as abuse@ has been. Has it? >>> *Consistency with other mailboxes* An abuse-mailbox is often >>> defined in whois records of registered domains (where it is >>> subject to query limits.) >> If we're going to suggest relying on whois data then we should >> specify the syntax of the relevant line in the whois record. Because of the usability limit, it may rather work the other way around: provide hints for verifying whois data consistency. > Automation related to feedback needs a defensive strategy. Allow > clients to indicate where feedback is to be directed. This path should > be within the EHLO domain that permits the outbound servers address to > be verified with a forward referenced address or APL. (APL?) > C: EHLO mx-001.example.com > S: 250-Welcome mx-001.example.com [192.168.1.1] to bar.com > S: 250-MARF > S: 250 8BITMIME > C: MARFPATH > S: 250 Ok I'm not sure what you mean by "within the EHLO domain". What if example.com outsources ARF processing to some 3rd party? > The server might also respond with 252 or 554 Unable to verify > mx-001.example.com. > This approach would exclude typical bot spam engines while also > providing a method to defend the feedback path. Why cannot it be abused just like the MAIL FROM path? The defense implied by relegating that datum in the envelope poses some difficulties in case of multi-hops, and it cannot be DKIM-signed. IMHO, abuse at an abuse-box is pretty unavoidable. Since we are talking about publishing and advertising an address, we cannot require that it remains secret. But then, hey, getting spam in an abuse-box is like discovering bugs during tests, we should just thank our luck. From shmuel+gen@patriot.net Sat May 15 18:19:45 2010 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 BF6333A6837 for ; Sat, 15 May 2010 18:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.151 X-Spam-Level: X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001] 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 4-Eegz97lOgM for ; Sat, 15 May 2010 18:19:43 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 5688D3A67D6 for ; Sat, 15 May 2010 18:19:43 -0700 (PDT) Received: from ECS35455305 (unknown [208.103.155.12]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 67498F580BA for ; Sat, 15 May 2010 21:17:12 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Sat, 15 May 2010 21:24:08 -0400 To: marf@ietf.org In-Reply-To: <8CCC18739105071-75C-AD96@webmail-m074.sysops.aol.com> 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: <20100516011712.67498F580BA@smtp.patriot.net> Subject: Re: [marf] Fwd: New Version Notification for draft-jdfalk-marf-reporting-discovery-01 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: Sun, 16 May 2010 01:19:46 -0000 In <8CCC18739105071-75C-AD96@webmail-m074.sysops.aol.com>, on 05/14/2010 at 10:16 AM, madkins05@aol.com said: > Why do it during the SMTP transaction? I wasn't taking a position on whether to do it during the SMTP transaction. Rather, I was taking a position on using free text fields as a mechanism for carrying machine-readable data. If we do it during SMTP at all then I strongly believe that we should use the defined extension mechanism rather than an ad hoc overloading of an existing response. -- 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 dotis@mail-abuse.org Sun May 16 18:20:38 2010 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 11C843A6C25 for ; Sun, 16 May 2010 18:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001, 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 cWgvn7BC-cga for ; Sun, 16 May 2010 18:20:35 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id F0BC13A6C11 for ; Sun, 16 May 2010 18:19:48 -0700 (PDT) Received: from US-DOUGLASO-MB.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id B0FD7A94648 for ; Mon, 17 May 2010 01:19:35 +0000 (UTC) Message-ID: <4BF099A6.4050303@mail-abuse.org> Date: Sun, 16 May 2010 18:19:34 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: marf@ietf.org References: <20100514101920.D4EABF5809C@smtp.patriot.net> <4BED8DBC.8040402@mail-abuse.org> <4BEE8B76.3030601@tana.it> In-Reply-To: <4BEE8B76.3030601@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] Fwd: New Version Notification for draft-jdfalk-marf-reporting-discovery-01 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, 17 May 2010 01:20:38 -0000 On 5/15/10 4:54 AM, Alessandro Vesely wrote: > Douglas Otis wrote: > > On 5/14/10 3:17 AM, Shmuel (Seymour J.) Metz wrote: > >> C: EHLO example.com >>> S: 250-Welcom to bar.com >>> S: 250-MARF >>> S: 250 8BITMIME >>> C: MARFINFO >>> S: 250 FBL_report gp=r; gu=http://postmaster.example.com/ > > This suggests contacting an inbound server to ask where to send > > feedback related to some other outbound server > Not really. It is contacting an inbound server to ask where to > _apply_ in order to receive feedback in case messages originating by > this client will be reported as spam. Such info is not tied to the > specific message at hand, except that since the client is sending > mail there, it may be interested in the FBL. Some messages are incorrectly identified as spam. As such, a relationship needs to be established between outbound clients and a feedback server, regardless of the discovery process. Confirmation of this relationship is needed to protect confidentiality with false positive detections. > Currently, clients get the few existing URLs of this type by word of > mouth. In addition, those "postmaster" sites are designed for > interactivity. A non-scalable setup. Agreed. > > which means this path can be easily abused. > Correct, nevertheless. > > Without a method to verify a message is associated with a specific > > feedback server, the path is likely to be targeted for abuse > What is a "feedback server", the generator or the consumer? A feedback server accepts problematic messages originally emitted by an associated outbound client, or messages appearing to spoof an associated domain. A third-party authorization scheme for DKIM could be used to safely exclude apparent spoofing as well as to authorize feedback domains. More to follow. > as abuse@ has been. > > Has it? Yes, from my experience. When there is abuse, having a method to change the path can help thwart abusive campaigns, and expose the source. > > Automation related to feedback needs a defensive strategy. Allow > > clients to indicate where feedback is to be directed. This path > > should be within the EHLO domain that permits the outbound servers > > address to be verified with a forward referenced address or APL. > (APL?) Some domains will likely desire strict control of their feedback path. Overloading MARF feedback validation with SPF intended to authorize a client's use of Mail-From parameters or PRA headers would prove problematic. After all, SPF is applied against clients handling messages from thousands of domains. APL stands for Address Prefix List (See RFC 3123). This single transaction alternative could be used in the few cases where address record sets prove inadequate. > > C: EHLO mx-001.example.com >> S: 250-Welcome mx-001.example.com [192.168.1.1] to bar.com >> S: 250-MARF >> S: 250 8BITMIME >> C: MARFPATH >> S: 250 Ok > I'm not sure what you mean by "within the EHLO domain". What if > example.com outsources ARF processing to some 3rd party? An MX record at the mx-001.example.com node could target any desired feedback server. This assumes the EHLO verified the administrative domain of the outbound client. With the domain verified, it can be relied upon to indicate where feedback for the client's messages are to be directed. Source spoofing would be a different issue, where the definition of spoofing would likely be based upon the From header. Hence ADSP. To suppress the noise generated by many exceptions in a From domain criteria, a third-party authorization scheme could help. > The server might also respond with 252 or 554 Unable to verify > mx-001.example.com. > > This approach would exclude typical bot spam engines while also > > providing a method to defend the feedback path. > Why cannot it be abused just like the MAIL FROM path? The MARF extension can raise expectations of being able to verify the EHLO. Ascertaining the domain an abusive source provides simpler defensive strategies. > The defense implied by relegating that datum in the envelope poses > some difficulties in case of multi-hops, and it cannot be > DKIM-signed. The third-party authorization scheme proposed for DKIM offers a single transaction able to associate any number of domains without use of signatures. > IMHO, abuse at an abuse-box is pretty unavoidable. Since we are > talking about publishing and advertising an address, we cannot > require that it remains secret. But then, hey, getting spam in an > abuse-box is like discovering bugs during tests, we should just thank > our luck. By having a scheme that collects information related to abuse sources, and that modulates paths as needed, this would not rely upon luck. A dependable feedback scheme is needed. Many large ISPs have discovered that processing high volumes of submission traffic requires elaborate strategies to defend account identifications and authorizations. :^( A responsible ISP must quickly respond to evidence of abuse by rate limiting sources and disabling accounts. Email accounts represent a weak link in security, since email is often used to recover lost passwords for other highly sensitive services. -Doug From vesely@tana.it Mon May 17 01:32:19 2010 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 D452D3A69F2 for ; Mon, 17 May 2010 01:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.192 X-Spam-Level: X-Spam-Status: No, score=-3.192 tagged_above=-999 required=5 tests=[AWL=-1.073, BAYES_50=0.001, 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 TxGy3eWBcmwn for ; Mon, 17 May 2010 01:32:18 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id B6F7C3A68BA for ; Mon, 17 May 2010 01:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1274085127; bh=eKQfdABed8k20fT3+4LSUWDlMW+6Zgmt37DsAaDQOxo=; l=5043; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=bneM9A5bg8sf27qsLIUUzcb4lp8KGzlm1+jVQ7XgKqKBcFsYISXkJtwf0o7fipScL divfmQT9Mx5XSTYUIiHT5nBqZz3aSI6IyAlXtyaplfyPMCJuLG72IBnmtiqTw69uTm +OYlbOcXBqs78wl8orzd0Q0TE9pZYtBkkBAWE7cY= Received: from mach-4.local (93-32-146-159.ip34.fastwebnet.it [93.32.146.159]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 17 May 2010 10:32:07 +0200 id 00000000005DC03C.000000004BF0FF07.00007E51 Message-ID: <4BF0FF13.5030207@tana.it> Date: Mon, 17 May 2010 10:32:19 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: marf@ietf.org References: <20100514101920.D4EABF5809C@smtp.patriot.net> <4BED8DBC.8040402@mail-abuse.org> <4BEE8B76.3030601@tana.it> <4BF099A6.4050303@mail-abuse.org> In-Reply-To: <4BF099A6.4050303@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] Fwd: New Version Notification for draft-jdfalk-marf-reporting-discovery-01 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, 17 May 2010 08:32:19 -0000 Douglas Otis wrote: > On 5/15/10 4:54 AM, Alessandro Vesely wrote: >> [...gu=...] is [for] contacting an inbound server to ask where to >> _apply_ in order to receive feedback in case messages originating by >> this client will be reported as spam. Such info is not tied to the >> specific message at hand, except that since the client is sending >> mail there, it may be interested in the FBL. > > Some messages are incorrectly identified as spam. As such, a > relationship needs to be established between outbound clients and a > feedback server, regardless of the discovery process. Confirmation of > this relationship is needed to protect confidentiality with false > positive detections. Well, that's not /regardless/ of the discovery process. In this case, the discovery process provides the starting point for establishing that relationship. I tend to consider it a peculiar kind of relationship between two ADMDs, rather than between specific hosts of theirs. It doesn't have to be a symmetric relationship, as it provides for different roles of outbound clients and feedback consumers for one ADMD, STMP servers and feedback generators for the other ADMD. Confidentiality is certainly a concern, but I don't think it is the only reason for requiring that relationship. Validating a feedback generator's input to an abuse-box is another one. Yet, in some cases, reports are transmitted with no prior agreement. >> What is a "feedback server", the generator or the consumer? > > A feedback server accepts problematic messages originally emitted by an > associated outbound client, or messages appearing to spoof an associated > domain. Fine. I'd stick with the term "consumer", as it seems less ambiguous. > A third-party authorization scheme for DKIM could be used to > safely exclude apparent spoofing as well as to authorize feedback > domains. Agreed. Abuse reports DKIM-signed by the generating ADMD, allow third parties. I'd require generated feedback to be _always_ DKIM-signed, irrespective of any signature that may be present or required in the reported message. > APL stands for Address Prefix List (See RFC 3123). Thanks for the explanation. I think APL or SPF may be used, according to local policies, for establishing a relationship between two ADMDs. However, IP addresses or ranges should not be part of the relationship records: When a mailbox provider changes one or more of its network providers, its IP addresses also change. Current FBL subscription procedures that check IP vs domain relationship have to be re-done in such occasions, which is non-scalable. Tracking domain's registrants may be a better strategy. >>> C: EHLO mx-001.example.com >>> S: 250-Welcome mx-001.example.com [192.168.1.1] to bar.com >>> S: 250-MARF >>> S: 250 8BITMIME >>> C: MARFPATH >>> S: 250 Ok >> I'm not sure what you mean by "within the EHLO domain". What if >> example.com outsources ARF processing to some 3rd party? > > An MX record at the mx-001.example.com node could target any desired > feedback server. This assumes the EHLO verified the administrative > domain of the outbound client. With the domain verified, it can be > relied upon to indicate where feedback for the client's messages are to > be directed. Hm... EHLO cannot be used to verify a domain. VHLO --that's the name John Klensin suggested for "Verified HelLO"-- would be needed for it. >> The defense implied by relegating that datum in the envelope poses >> some difficulties in case of multi-hops, and it cannot be >> DKIM-signed. > > The third-party authorization scheme proposed for DKIM offers a single > transaction able to associate any number of domains without use of > signatures. This would imply too much interpretation of DNS names, IMHO. Since it is not possible to reliably learn zone cuts and delegations, I would refrain from specifying the feedback consumer that way. An abuse-box's script should be able to sort out good reports by checking its trusted feedback generators list for the ADMD corresponding to the report's signature "d=" tag. > A dependable feedback scheme is needed. Many large ISPs have discovered > that processing high volumes of submission traffic requires elaborate > strategies to defend account identifications and authorizations. :^( > > A responsible ISP must quickly respond to evidence of abuse by rate > limiting sources and disabling accounts. Email accounts represent a > weak link in security, since email is often used to recover lost > passwords for other highly sensitive services. OK, but let's stick to minimal requirements for generalizing FBLs. If this will fly, it may happen to become a building block for the "mythical global reputation systems". However, if we require anything that may resemble a reputation system for building this, chances are we'll never even reach the runway. From dotis@mail-abuse.org Mon May 17 12:21:02 2010 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 D07C13A6AD8 for ; Mon, 17 May 2010 12:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.853 X-Spam-Level: X-Spam-Status: No, score=-3.853 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_50=0.001, 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 UEjxJpMCUc54 for ; Mon, 17 May 2010 12:20:59 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id C628928C0F3 for ; Mon, 17 May 2010 12:20:48 -0700 (PDT) Received: from sjc-office-nat-210.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 3F709A94532 for ; Mon, 17 May 2010 19:20:33 +0000 (UTC) Message-ID: <4BF196FF.8080602@mail-abuse.org> Date: Mon, 17 May 2010 12:20:31 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: marf@ietf.org References: <20100514101920.D4EABF5809C@smtp.patriot.net> <4BED8DBC.8040402@mail-abuse.org> <4BEE8B76.3030601@tana.it> <4BF099A6.4050303@mail-abuse.org> <4BF0FF13.5030207@tana.it> In-Reply-To: <4BF0FF13.5030207@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] Fwd: New Version Notification for draft-jdfalk-marf-reporting-discovery-01 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, 17 May 2010 19:21:02 -0000 On 5/17/10 1:32 AM, Alessandro Vesely wrote: > Douglas Otis wrote: >> On 5/15/10 4:54 AM, Alessandro Vesely wrote: >> >> Some messages are incorrectly identified as spam. As such, a >> relationship needs to be established between outbound clients and a >> feedback server, regardless of the discovery process. Confirmation >> of this relationship is needed to protect confidentiality with false >> positive detections. > > Well, that's not /regardless/ of the discovery process. In this case, > the discovery process provides the starting point for establishing > that relationship. I tend to consider it a peculiar kind of > relationship between two ADMDs, rather than between specific hosts of > theirs. It doesn't have to be a symmetric relationship, as it provides > for different roles of outbound clients and feedback consumers for one > ADMD, STMP servers and feedback generators for the other ADMD. > > Confidentiality is certainly a concern, but I don't think it is the > only reason for requiring that relationship. Validating a feedback > generator's input to an abuse-box is another one. > > Yet, in some cases, reports are transmitted with no prior agreement. One might assume the reason for having an automated discovery process for feedback servers would be to allow messages lacking prior agreements. There are two possible criteria might be applied when selecting a feedback server. Selection might be based upon: a) messages from clients associated with feedback servers through some mechanism. b) apparent spoofing of a domain associated with feedback servers referenced by that domain. 'a' represents the best criteria for identifying problematic accounts. 'b' represents the best criteria for content filters and vetting sources. >>> What is a "feedback server", the generator or the consumer? >> A feedback server accepts problematic messages originally emitted by >> an associated outbound client, or messages appearing to spoof an >> associated domain. > Fine. I'd stick with the term "consumer", as it seems less ambiguous. Consumer of what? Problematic messages, or reports of problematic messages. Client / server still seems better defined. >> A third-party authorization scheme for DKIM could be used to safely >> exclude apparent spoofing as well as to authorize feedback domains. > Agreed. Abuse reports DKIM-signed by the generating ADMD, allow third > parties. I'd require generated feedback to be _always_ DKIM-signed, > irrespective of any signature that may be present or required in the > reported message. Agreed. >> APL stands for Address Prefix List (See RFC 3123). > Thanks for the explanation. I think APL or SPF may be used, according > to local policies, for establishing a relationship between two ADMDs. > However, IP addresses or ranges should not be part of the relationship > records: When a mailbox provider changes one or more of its network > providers, its IP addresses also change. Current FBL subscription > procedures that check IP vs domain relationship have to be re-done in > such occasions, which is non-scalable. Are you suggesting that feedback servers should only be located using reverse DNS, rather than using any forward reference? > Tracking domain's registrants may be a better strategy. I don't know what that means in regard to ensuring only correct feedback servers receive the selected feedback. >> An MX record at the mx-001.example.com node could target any desired >> feedback server. This assumes the EHLO verified the administrative >> domain of the outbound client. With the domain verified, it can be >> relied upon to indicate where feedback for the client's messages are >> to be directed. > > Hm... EHLO cannot be used to verify a domain. VHLO --that's the name > John Klensin suggested for "Verified HelLO"-- would be needed for it. The MARF extension could be used in conjunction with an assurance that EHLOs be verifiable. >> The third-party authorization scheme proposed for DKIM offers a >> single transaction able to associate any number of domains without >> use of signatures. > > This would imply too much interpretation of DNS names, IMHO. Since it > is not possible to reliably learn zone cuts and delegations, I would > refrain from specifying the feedback consumer that way. You should review how association are made. There is no dependence upon zone boundaries. http://tools.ietf.org/html/draft-otis-dkim-tpa-label-03 > An abuse-box's script should be able to sort out good reports by > checking its trusted feedback generators list for the ADMD > corresponding to the report's signature "d=" tag. Of course, but that is a separate issue from selecting the feedback server. Bad actors should not be able to intercept a portion of an SMTP client's traffic when criteria 'a' is being used. >> A dependable feedback scheme is needed. Many large ISPs have >> discovered that processing high volumes of submission traffic >> requires elaborate strategies to defend account identifications and >> authorizations. :^( >> >> A responsible ISP must quickly respond to evidence of abuse by rate >> limiting sources and disabling accounts. Email accounts represent a >> weak link in security, since email is often used to recover lost >> passwords for other highly sensitive services. > > OK, but let's stick to minimal requirements for generalizing FBLs. If > this will fly, it may happen to become a building block for the > "mythical global reputation systems". However, if we require anything > that may resemble a reputation system for building this, chances are > we'll never even reach the runway. Criteria 'a' represents information most relevant to managing SMTP clients. -Doug From root@core3.amsl.com Tue May 18 15:45:02 2010 Return-Path: X-Original-To: marf@ietf.org Delivered-To: marf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1D1A63A6877; Tue, 18 May 2010 15:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100518224502.1D1A63A6877@core3.amsl.com> Date: Tue, 18 May 2010 15:45:02 -0700 (PDT) Cc: marf@ietf.org Subject: [marf] I-D Action:draft-ietf-marf-base-05.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 22:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Abuse Reporting Format Working Group of the IETF. Title : An Extensible Format for Email Feedback Reports Author(s) : Y. Shafranovich, et al. Filename : draft-ietf-marf-base-05.txt Pages : 36 Date : 2010-05-18 This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-base-05.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-base-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-18153253.I-D@ietf.org> --NextPart-- From dotis@mail-abuse.org Tue May 18 18:15:40 2010 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 10A7F3A68E3 for ; Tue, 18 May 2010 18:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.874 X-Spam-Level: X-Spam-Status: No, score=-3.874 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_50=0.001, 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 CC-0ukObP6jN for ; Tue, 18 May 2010 18:15:38 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id D59E93A6A64 for ; Tue, 18 May 2010 18:15:17 -0700 (PDT) Received: from sjc-office-nat-210.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id AA537A94550 for ; Wed, 19 May 2010 01:14:59 +0000 (UTC) Message-ID: <4BF33B93.2050605@mail-abuse.org> Date: Tue, 18 May 2010 18:14:59 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: marf@ietf.org References: <20100514101920.D4EABF5809C@smtp.patriot.net> <4BED8DBC.8040402@mail-abuse.org> <4BEE8B76.3030601@tana.it> <4BF099A6.4050303@mail-abuse.org> <4BF0FF13.5030207@tana.it> In-Reply-To: <4BF0FF13.5030207@tana.it> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [marf] MARF roles for draft-jdfalk-marf-reporting-discovery-01 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 May 2010 01:15:40 -0000 The MARF discovery draft raises troubling issues. It defines roles strictly in terms of domains, which is wrong of course. The draft describes administrative management domains as feedback consumers who publish in DNS at domains matching DKIM 'd=' values of outgoing signatures, domains matching those present in SMTP MAIL commands for sending mail, and/or domains referenced by reverse DNS PTR records of the IP address used by outbound border MTAs. The draft offers little guidance in respect to who should be expected to act, and whether it is okay issue reports based upon unverified domain information present within SMTP mail messages and commands. MARF Responsible Parties should be defined as follows: _Most_Responsible_Entity_. Administrators of an Autonomous System (IP address owners), see RFC 4271 for BGP details. These owners are managed by AfriNIC, APNIC, ARIN, LACNIC, RIPE-NCC who are Regional Internet Registries that identify owners by offering whois at whois.afrinic.net, whois.apnic.net, whois.arin.net, whois.lacnic.net, whois.ripe.net respectively. Only owners of the IP address space are able to mitigate abuse from _any_ source making them the most responsible for mitigation. These owners are identified by their Autonomous System Number, which is used to advertise IP address space. The related address space is _always_ kept current with BGP advertisements, since this is how Internet traffic is routed. _Next_Responsible_Entity_, Email Service Providers as determined by the IP address used by their system. ESPs acquire access from those managing an AS. Only use of an IP address provides a verifiable relationship between an Email Service Provider and the AS or Domain. Domains do not directly represent a responsible entity. A domain can claim use of any IP address within their DNS zone without any claim being true. Only when the domain resolves the IP address of an interacting host, can responsibility be established, but this is confined to these IP addresses. As an analogy, consider the U.S. Online Copyright Infringement Liability Limitation Act (OCILLA), part of the U.S. Digital Millennium Copyright Act. It uses the term "service provider" to mean an entity offering the transmission, routing, or providing of connections for digital online communications, between or among points specified by a user, of material of the user’s choosing, without modification to the content of the material as sent or received. Routing and an transmission is the AS bailiwick. "Service provider" also means an Online Service Provider (OSP) or Internet Access Provider (IAP), or the operator of facilities for OSPs or IAPs. For the purpose of MARF, this would be within the ESP Bailiwick. Protection under OCILLA requires the service provider to act expeditiously to take down infringements, and to not benefit from infringing activity. This is construed to include attracting more users. While the service provider has no duty to monitor for infringements, they must respond to notifications of infringement which includes within a single message the following: i) A signature of a person authorized to act on behalf of entity making the allegation. ii) identify or list infringements. iii) identify the infringing material to be removed. iv) offer sufficient information to locate the infringement. v) a statement that notification is being made in good faith. vi) a statement that the notification is accurate, and under penalty of perjury, they are authorized to act on behalf of the owner. Does email need a copyright notice on the use of the From Header? There is an easy way for a domain to specially authorize third-parties to include their From headers. One wonders whether there should be boiler-plate language that makes OCILLA like declarations, where infringement includes violation of a From header copyright. Clearly, MARF messages must go to an entity able to take action. Since most spam is emitted by compromised systems, _only_ the AS able to act in these cases. So in general, MARF discovery fails in the most important case. In the cases where a domain is extracted from an SMTP command or message, this should only occur when the sender provides a method to verify that the domain is managed by the outbound system through specific references and demonstration of use. -Doug From msk@cloudmark.com Thu May 20 11:39:59 2010 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 08C243A6844 for ; Thu, 20 May 2010 11:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.163 X-Spam-Level: X-Spam-Status: No, score=-3.163 tagged_above=-999 required=5 tests=[AWL=-0.564, 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 cKK+QrQHjqRi for ; Thu, 20 May 2010 11:39:58 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 16F423A6836 for ; Thu, 20 May 2010 11:39:55 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Thu, 20 May 2010 11:39:48 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Thu, 20 May 2010 11:39:47 -0700 Thread-Topic: ID Tracker State Update Notice: draft-ietf-marf-base Thread-Index: Acr4S7rYQl10baDFQgWkrm44NsmpvwAAAk3g Message-ID: 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: [marf] FW: ID Tracker State Update Notice: draft-ietf-marf-base X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 18:39:59 -0000 Congratulations, all! -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org]=20 Sent: Thursday, May 20, 2010 11:39 AM To: marf-chairs@tools.ietf.org; draft-ietf-marf-base@tools.ietf.org; ietf@c= ybernothing.org Subject: ID Tracker State Update Notice: draft-ietf-marf-base 'State Changes to Approved-announcement to be sent::Point Raised - writeup = needed from IESG Evaluation by Cindy Morgan' ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command= =3Dview_id&dTag=3D19559&rfc_flag=3D0 From bmcdowell@paypal.com Thu May 20 14:22:43 2010 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 8464A3A68B9 for ; Thu, 20 May 2010 14:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.594 X-Spam-Level: X-Spam-Status: No, score=-4.594 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_FORGED_PAYPAL_C=1.3] 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 6dk-AqTfhqj2 for ; Thu, 20 May 2010 14:22:41 -0700 (PDT) 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 0945B3A67DB for ; Thu, 20 May 2010 14:22:40 -0700 (PDT) DomainKey-Signature: s=ppcorp; d=paypal.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=PIwC8YzN1XUxp6if6Tyjz23a/QVSxNzsfqMUjMfvCk+LQWHcoqVNu8vf ZbBVJ2JEDfF4duXnpibwfVkM3G3nECyU167xAYbquz5vN6A8NBYmtfluU 2SMFuyNCaobvLN2; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal.com; i=bmcdowell@paypal.com; q=dns/txt; s=ppcorp; t=1274390555; x=1305926555; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"McDowell,=20Brett"=20 |Subject:=20Re:=20[marf]=20FW:=20ID=20Tracker=20State=20U pdate=20Notice:=20draft-ietf-marf-base|Date:=20Thu,=2020 =20May=202010=2015:22:29=20-0600|Message-ID:=20<2E65F7E2- 4DEE-4F4B-A8F2-94419A1032D4@paypal.com>|To:=20"Murray=20S .=20Kucherawy"=20|CC:=20Message=20Abus e=20Report=20Format=20working=20group=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20|References:=20; bh=g6ge03JXWS5CwgrnUUo6juaOXJg0CxxCT4NlZXa9Bc8=; b=TqDHI7R3DFqhgOgOQtFT2an+tWGz5TjjYk1UXphab30UfmdpIRg6T/V1 nfFKyJvXZqkQWvBangE0/5+Ifyc/t3BDKZS4fBYGsWq7mcUsQ+4lzRVLZ IaQZDEmXktbQnIU; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.53,273,1272870000"; d="scan'208";a="70767429" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-001.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 20 May 2010 14:22:34 -0700 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; Thu, 20 May 2010 15:22:33 -0600 From: "McDowell, Brett" To: "Murray S. Kucherawy" Date: Thu, 20 May 2010 15:22:29 -0600 Thread-Topic: [marf] FW: ID Tracker State Update Notice: draft-ietf-marf-base Thread-Index: Acr4Yo9zPdc2pJYiQvqhklPJgDEchw== Message-ID: <2E65F7E2-4DEE-4F4B-A8F2-94419A1032D4@paypal.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: ogQEZDTYZzvlVDRJKsnpCA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: Message Abuse Report Format working group Subject: Re: [marf] FW: ID Tracker State Update Notice: draft-ietf-marf-base X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 21:22:43 -0000 +1 Tweeted here http://twitter.com/brettmcdowell/status/14385925448 On May 20, 2010, at 2:39 PM, Murray S. Kucherawy wrote: > Congratulations, all! >=20 > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org]=20 > Sent: Thursday, May 20, 2010 11:39 AM > To: marf-chairs@tools.ietf.org; draft-ietf-marf-base@tools.ietf.org; ietf= @cybernothing.org > Subject: ID Tracker State Update Notice: draft-ietf-marf-base >=20 > 'State Changes to Approved-announcement to be sent::Point Raised - writeu= p needed from IESG Evaluation by Cindy Morgan' > ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?comman= d=3Dview_id&dTag=3D19559&rfc_flag=3D0 >=20 > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf From root@core3.amsl.com Fri May 21 06:15:35 2010 Return-Path: X-Original-To: marf@ietf.org Delivered-To: marf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9C8883A9A72; Fri, 21 May 2010 06:15:14 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100521131519.9C8883A9A72@core3.amsl.com> Date: Fri, 21 May 2010 06:15:14 -0700 (PDT) Cc: marf@ietf.org Subject: [marf] I-D Action:draft-ietf-marf-base-06.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, 21 May 2010 13:15:39 -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 : An Extensible Format for Email Feedback Reports Author(s) : Y. Shafranovich, et al. Filename : draft-ietf-marf-base-06.txt Pages : 38 Date : 2010-05-21 This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-base-06.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-base-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-21061247.I-D@ietf.org> --NextPart-- From alexey.melnikov@isode.com Fri May 21 10:24:26 2010 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 EE0BE3A6940 for ; Fri, 21 May 2010 10:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.420, 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 S7iFGabjO11l for ; Fri, 21 May 2010 10:24:26 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id BF83C3A8129 for ; Fri, 21 May 2010 06:53:48 -0700 (PDT) Received: from [172.16.2.151] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 21 May 2010 14:53:41 +0100 Message-ID: <4BF69060.4010205@isode.com> Date: Fri, 21 May 2010 14:53:36 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: barryleiba@computer.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 21 May 2010 12:54:29 -0700 Cc: Peter Saint-Andre , Message Abuse Report Format working group Subject: Re: [marf] Proposed base-04 changes based on AD feedback 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, 21 May 2010 17:24:27 -0000 Barry Leiba wrote: >[Adding Alexey to the distribution.] > >On Tue, May 4, 2010 at 11:01 PM, Yakov Shafranovich wrote: > > >>As a separate note, is there going to be some sort of a note on IESG's >>site or perhaps an RFC so people are aware that "x-" is not a good >>thing for future standards? >> >> >Alexey: Would the IESG consider an IESG Statement about this? Or >should someone kick off a "X- Prefixes Considered Harmful" RFC ? > > Sorry for the late reply. I think publishing a "X- Prefixes Considered Harmful" RFC would be a better way to go. At this point I am not entirely sure if IESG has a united view on this (I haven't asked), so some public discussion of this would be helpful. Peter said that he will help with this. So would I. From msk@cloudmark.com Fri May 21 13:43:17 2010 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 1D0703A68A9 for ; Fri, 21 May 2010 13:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=-1.299, BAYES_05=-1.11] 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 MtJBonSEG-IL for ; Fri, 21 May 2010 13:43:16 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 47B113A6C0E for ; Fri, 21 May 2010 13:10:43 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Fri, 21 May 2010 12:55:10 -0700 From: "Murray S. Kucherawy" To: Alexey Melnikov , "barryleiba@computer.org" Date: Fri, 21 May 2010 12:55:10 -0700 Thread-Topic: [marf] Proposed base-04 changes based on AD feedback Thread-Index: Acr5H2od9DeeJtFzRg6UaTsAoo2y1wAAAwoQ Message-ID: References: <4BF69060.4010205@isode.com> In-Reply-To: <4BF69060.4010205@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Message, Peter Saint-Andre , working group Subject: Re: [marf] Proposed base-04 changes based on AD feedback 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, 21 May 2010 20:43:17 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Alexey Melnikov > Sent: Friday, May 21, 2010 6:54 AM > To: barryleiba@computer.org > Cc: Peter Saint-Andre; Message Abuse Report Format working group > Subject: Re: [marf] Proposed base-04 changes based on AD feedback >=20 >=20 > >Alexey: Would the IESG consider an IESG Statement about this? Or > >should someone kick off a "X- Prefixes Considered Harmful" RFC ? >=20 > Sorry for the late reply. > I think publishing a "X- Prefixes Considered Harmful" RFC would be a > better way to go. At this point I am not entirely sure if IESG has a > united view on this (I haven't asked), so some public discussion of > this > would be helpful. >=20 > Peter said that he will help with this. So would I. I'll help too if needed. From stpeter@stpeter.im Fri May 21 13:43:27 2010 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 E64EA3A6825 for ; Fri, 21 May 2010 13:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=0.272, 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 HFu5HKbGaKEL for ; Fri, 21 May 2010 13:43:26 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E76FF3A6AE8 for ; Fri, 21 May 2010 13:11:58 -0700 (PDT) Received: from squire.local (dsl-251-29.dynamic-dsl.frii.net [216.17.251.29]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B1C76403F3; Fri, 21 May 2010 14:10:09 -0600 (MDT) Message-ID: <4BF6E88F.9060908@stpeter.im> Date: Fri, 21 May 2010 14:09:51 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <4BF69060.4010205@isode.com> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090301000200040700090105" X-Mailman-Approved-At: Fri, 21 May 2010 13:54:32 -0700 Cc: Alexey Melnikov , "barryleiba@computer.org" , Message Abuse Report Format working group Subject: Re: [marf] Proposed base-04 changes based on AD feedback 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, 21 May 2010 20:43:28 -0000 This is a cryptographically signed message in MIME format. --------------ms090301000200040700090105 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/21/10 1:55 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf O= f >> Alexey Melnikov >> Sent: Friday, May 21, 2010 6:54 AM >> To: barryleiba@computer.org >> Cc: Peter Saint-Andre; Message Abuse Report Format working group >> Subject: Re: [marf] Proposed base-04 changes based on AD feedback >> >> >>> Alexey: Would the IESG consider an IESG Statement about this? Or >>> should someone kick off a "X- Prefixes Considered Harmful" RFC ? >> >> Sorry for the late reply. >> I think publishing a "X- Prefixes Considered Harmful" RFC would be a >> better way to go. At this point I am not entirely sure if IESG has a >> united view on this (I haven't asked), so some public discussion of >> this >> would be helpful. >> >> Peter said that he will help with this. So would I. >=20 > I'll help too if needed. I think it will end up being a very short document, perhaps only a few pages, but feedback will be welcome. Alexey and I will sketch out an Internet-Draft at the IESG retreat next week. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090301000200040700090105 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDUyMTIwMDk1MVowIwYJKoZIhvcNAQkEMRYEFA6T0DiNeV+YqrnGAKt4 LIp7kzwdMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAitcAuUPDpQoJEO1IdF84gALuqNZSQbqXySTlCXAV 4qujt7XTQf3H4sDUHv5ECVdl5EX1rHbWH4YSn0qC82hHi6pdAHbCtdoIeLsFclt18XMkCuMl 1S6ULd1Dd5EQ1bi3kyNMkh19AZh6MsdqRVHmovpd9cWz+NE8MOaqyOw38DKqglpJwgrc3ewo cyuydQgb57W9f3JCap8HwAV1wAxZ4FeUOpcJqDSPY1Ffj5pPYVKEqh6ZNfco2ImO+7i2HkeF unhN+jzJSkRtupWLIY2dwtlnd4OovnOO/nX8OwDzxAUyipI0qdoyIvPCGNRG1x2EuldfIxSB yshCXY5HrDehxgAAAAAAAA== --------------ms090301000200040700090105-- From wwwrun@core3.amsl.com Mon May 24 10:02:30 2010 Return-Path: X-Original-To: marf@ietf.org Delivered-To: marf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 435BC3A6EC4; Mon, 24 May 2010 10:02:29 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100524170230.435BC3A6EC4@core3.amsl.com> Date: Mon, 24 May 2010 10:02:30 -0700 (PDT) Cc: Internet Architecture Board , marf chair , marf mailing list , RFC Editor Subject: [marf] Protocol Action: 'An Extensible Format for Email Feedback Reports' to Proposed Standard 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 May 2010 17:02:30 -0000 The IESG has approved the following document: - 'An Extensible Format for Email Feedback Reports ' as a Proposed Standard This document is the product of the Messaging Abuse Reporting Format Working Group. The IESG contact persons are Alexey Melnikov and Peter Saint-Andre. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-base-06.txt Technical Summary This document defines an extensible format and MIME type that may be used by network operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. Working Group Summary The majority of development of this specification took place outside of the IETF between 2005 and 2007, resulting in a de facto standard with many large-scale implementations. The recent work within the MARF Working Group has resulted in a more precise document, and has revealed some items for discussion in future documents. Document Quality The Working Group is aware of more than a dozen generators of reports which follow this specification, and hundreds of consumers of those reports. These include most of the largest mailbox providers and email service providers, and many smaller operators. Many of the WG members are also implementors, and many additional implementers who are not currently WG participants have reviewed this document and/or earlier revisions. Personnel J.D. Falk is the Document Shepherd. Alexey Melnikov is the Responsible Area Director. RFC Editor Note In Appendix B (and subsections), please change the version number in all "Version: 0.1" fields to be "1"