From jdfalk-lists@cybernothing.org Mon Aug 1 19:42:37 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F03B11E8112 for ; Mon, 1 Aug 2011 19:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zG4hbpi9UR+y for ; Mon, 1 Aug 2011 19:42:36 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id 98ED611E809E for ; Mon, 1 Aug 2011 19:42:36 -0700 (PDT) Received: from [192.168.11.36] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p722ggKf009576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 1 Aug 2011 19:42:44 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p722ggKf009576 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=fudge; t=1312252964; bh=3RGsXlecmzQZwlSo/5jh4MiB6YCv+YF6TviPu3TUM yE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=FI3xScK+ckO7 rMNyY1LdQ5aGKwGZfmnyfG+7ehJVTUKw6zckVNbM11qKOjE3NdWJHJHSZbldBzYdKGF pgLyPrVHjRFPXFDMNcqsvj7BYipk/uMniIX9pND/BM4dvDTYhujPIzlElYNi/modpGC LuyfJoVb2BN0JyV25bITNuCdI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: <4E33BBFB.4020209@tana.it> Date: Mon, 1 Aug 2011 19:42:41 -0700 Content-Transfer-Encoding: 7bit Message-Id: <48286D03-4F08-4602-A958-71105A740E00@cybernothing.org> References: <1311898476.94112.YahooMailClassic@web45310.mail.sp1.yahoo.com> <4E33BBFB.4020209@tana.it> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] MUA plugins, was feedback type Virus X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 02 Aug 2011 02:42:37 -0000 On Jul 30, 2011, at 1:08 AM, Alessandro Vesely wrote: > On 29/Jul/11 22:23, J.D. Falk wrote: >> Using ARF for reports from MUAs has been discussed many times, but >> hasn't really ever been implemented (except for a Thunderbird >> plugin, years ago, now lost to history.) I'd love to see somebody >> try it, but until they do I don't think we can call it a common >> practice. > > Where is it? I've been looking for one since we discussed this > question in ASRG[*], and eventually started to roll my own stuff. > However, I never completed, nor released, my plugin. Previous > experience may probably help me... any pointer? Lost to history, as far as I know. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From jdfalk-lists@cybernothing.org Tue Aug 2 17:42:28 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719FA11E80F0 for ; Tue, 2 Aug 2011 17:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjhedepDL9db for ; Tue, 2 Aug 2011 17:42:27 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id B628E11E80A1 for ; Tue, 2 Aug 2011 17:42:27 -0700 (PDT) Received: from [192.168.11.41] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p730gZvK028696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 2 Aug 2011 17:42:37 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p730gZvK028696 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=fudge; t=1312332157; bh=iI9OEZ2gr9nwVlCHXd7ocDybBhVk7npXh0ZSrs0SG sY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=A/mMirQ5gvcc XL5EMa8ubJl1ZYJ+9VOsLgoNbQ3/1NPO5dGGU9l5eGcrUSvblD435zCk8KFPDRd3nC7 AqV0XI10QT2QwF66EkLdKasRyhV4f0pfyV8jSzfIGT1mlIwL9ucCJTDNjSvrZP5HnBd wSi9HpTsQqwtjuymYLcnL1jU0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: Date: Tue, 2 Aug 2011 17:42:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <35734E6B-4579-4EF4-A139-7BFB4FA4573F@wordtothewise.com> <953887BF-E8AB-4246-8075-7EB50A7BF916@wordtothewise.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] Misuse of ARF by spam-friendly ISPs X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 00:42:28 -0000 On Jul 30, 2011, at 9:30 PM, Murray S. Kucherawy wrote: > I wonder if this could be mentioned in the BCP effort we're doing = (JD?). I suppose it could be added to the growing list of use cases that = draft-jdfalk-marf-as specifically does not address, along with = individual user submissions, virus/malware reports, churning monkey = butter, et cetera. > Failing that, if we decide to update the base document given the = recent flurry of input, this could certainly go in there. But it's too = early to make that call, I think. Sounds to me like what's actually needed is a BCP on accepting abuse = reports from the general public -- maybe a task for the ASRG? -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From vesely@tana.it Wed Aug 3 03:02:04 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DCD21F8B3D for ; Wed, 3 Aug 2011 03:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=-1.132, BAYES_00=-2.599, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6Net8iXDcLp for ; Wed, 3 Aug 2011 03:02:03 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 51F0021F8B40 for ; Wed, 3 Aug 2011 03:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1312365733; bh=1WPKX5MMwqkeZ8xMcMOVWQ+PoGy5hgCge+dcbm6zL2U=; l=1324; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=X2hEh/cler5mJVQWqbIcUQeCJzU6zsZhIfYiiLS6rLm+R3+ZA4U47KSMZk84MPj7I 5rR5l9mZK2Be+5q9vxSJD5LNtXDBLMZ/NVybkgvcGFec8EJxYldYY2IP1K0wLHxT00 DZi3L+TOTbk/QRxRKJQxpo9mczqDAGKojKnGke20= 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, 03 Aug 2011 12:02:13 +0200 id 00000000005DC039.000000004E391CA5.00005D7A Message-ID: <4E391CA5.6010803@tana.it> Date: Wed, 03 Aug 2011 12:02:13 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: marf@ietf.org References: <35734E6B-4579-4EF4-A139-7BFB4FA4573F@wordtothewise.com> <953887BF-E8AB-4246-8075-7EB50A7BF916@wordtothewise.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Misuse of ARF by spam-friendly ISPs X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 10:02:04 -0000 On 03/Aug/11 02:42, J.D. Falk wrote: > On Jul 30, 2011, at 9:30 PM, Murray S. Kucherawy wrote: > >> I wonder if this could be mentioned in the BCP effort we're doing (JD?). > > I suppose it could be added to the growing list of use cases that > draft-jdfalk-marf-as specifically does not address, along with > individual user submissions, virus/malware reports, churning monkey > butter, et cetera. What is the meaning of a list of non-addressed use cases? Possibly suggest that they are not worth being addressed in general? Hmm... that's quite strange, especially considering that everyone likes the monkey butter. > Sounds to me like what's actually needed is a BCP on accepting > abuse reports from the general public -- maybe a task for the > ASRG? I agree such a BCP is needed, and I take this chance to propose it again. The ASRG has already done research on this topic, and John summarized it in http://wiki.asrg.sp.am/wiki/Adding_a_junk_button_to_MUAs That still looks current. It allows MUAs to report in a variety of ways. For SMTP, it is obviously better to wrap the offending mail in an ARF message, but not mandatory. For homogeneity, I'd put this extra BCP in MARF rather than ASRG. There are related issues, like manual vs. auto submission, and privacy considerations. From msk@cloudmark.com Wed Aug 3 06:33:18 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23FA21F8B2E for ; Wed, 3 Aug 2011 06:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=-1.219, BAYES_00=-2.599, MANGLED_SPAM=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8y3ug-dO6Mb for ; Wed, 3 Aug 2011 06:33:18 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1B021F8512 for ; Wed, 3 Aug 2011 06:33:18 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 3 Aug 2011 06:33:30 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 3 Aug 2011 06:33:28 -0700 Thread-Topic: [marf] Misuse of ARF by spam-friendly ISPs Thread-Index: AcxRxHBSTvlisT89Sh+sWOUDAnEoywAHEXAw Message-ID: References: <35734E6B-4579-4EF4-A139-7BFB4FA4573F@wordtothewise.com> <953887BF-E8AB-4246-8075-7EB50A7BF916@wordtothewise.com> <4E391CA5.6010803@tana.it> In-Reply-To: <4E391CA5.6010803@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Misuse of ARF by spam-friendly ISPs X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 13:33:19 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Wednesday, August 03, 2011 3:02 AM > To: marf@ietf.org > Subject: Re: [marf] Misuse of ARF by spam-friendly ISPs >=20 > On 03/Aug/11 02:42, J.D. Falk wrote: > > On Jul 30, 2011, at 9:30 PM, Murray S. Kucherawy wrote: > > > >> I wonder if this could be mentioned in the BCP effort we're doing (JD?= ). > > > > I suppose it could be added to the growing list of use cases that > > draft-jdfalk-marf-as specifically does not address, along with > > individual user submissions, virus/malware reports, churning monkey > > butter, et cetera. >=20 > What is the meaning of a list of non-addressed use cases? Possibly > suggest that they are not worth being addressed in general? It's referring to a list of use cases that the ARF was not designed to hand= le. There's no intent that I can see to state that those use cases aren't = interesting to handle. The issue is whether it's reasonable for an "abuse@" address to accept only= reports that are ARFs. I would suggest that such is a violation of RFC214= 2, but it doesn't explicitly state that all formats have to be accepted so = I'd probably ultimately lose that argument. > Hmm... > that's quite strange, especially considering that everyone likes the > monkey butter. That's a new one on me. What does it mean? > > Sounds to me like what's actually needed is a BCP on accepting > > abuse reports from the general public -- maybe a task for the > > ASRG? >=20 > I agree such a BCP is needed, and I take this chance to propose it > again. The ASRG has already done research on this topic, and John > summarized it in >=20 > http://wiki.asrg.sp.am/wiki/Adding_a_junk_button_to_MUAs >=20 > That still looks current. It allows MUAs to report in a variety of > ways. For SMTP, it is obviously better to wrap the offending mail in > an ARF message, but not mandatory. Just to be precise, I think JD is suggesting a BCP about how one handles re= ceived abuse reports, not how they are generated. The point at issue is th= at one large service provider has decided only to accept abuse mail if it's= an ARF; free-form complaints are no longer accepted. It's caused quite a = bit of trouble, not the least of which being the three co-authors of ARF ge= tting a lot of "I hope you're happy" hate-mail. > For homogeneity, I'd put this extra BCP in MARF rather than ASRG. > There are related issues, like manual vs. auto submission, and privacy > considerations. I'd be fine with that, but I'd invite the ASRG to comment. -MSK (as participant) From msk@cloudmark.com Wed Aug 3 06:34:50 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6541421F854D for ; Wed, 3 Aug 2011 06:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.658 X-Spam-Level: X-Spam-Status: No, score=-103.658 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 211NIMc2tgaW for ; Wed, 3 Aug 2011 06:34:50 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1224D21F8512 for ; Wed, 3 Aug 2011 06:34:50 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 3 Aug 2011 06:35:02 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 3 Aug 2011 06:35:01 -0700 Thread-Topic: [marf] Automated vs. manual reporting, was feedback type Virus Thread-Index: AcxOFcTTT/rphjzHQXqsllIwJiiwjwDzDQfw Message-ID: References: <1311898476.94112.YahooMailClassic@web45310.mail.sp1.yahoo.com> <4E32EF1B.7050000@tana.it> In-Reply-To: <4E32EF1B.7050000@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Automated vs. manual reporting, was feedback type Virus X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 13:34:50 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Friday, July 29, 2011 10:34 AM > To: marf@ietf.org > Subject: [marf] Automated vs. manual reporting, was feedback type Virus >=20 > > Hence, to word a request to the MARF group: design the MARF drafts > > not only with manual, but also with automated responders in mind. I > > am convinced, that automated responders will create most of the > > feedback messages in not too distant future. >=20 > +1, possibly we should add a field such as Report-Trigger: human/auto. How would that alter one's handling of such a report on receipt? From johnl@iecc.com Wed Aug 3 11:18:30 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C476D21F8A70 for ; Wed, 3 Aug 2011 11:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJIG655WXo7V for ; Wed, 3 Aug 2011 11:18:30 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3B621F842D for ; Wed, 3 Aug 2011 11:18:29 -0700 (PDT) Received: (qmail 32758 invoked from network); 3 Aug 2011 18:18:41 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 3 Aug 2011 18:18:41 -0000 Received: (qmail 25611 invoked from network); 3 Aug 2011 18:18:41 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 3 Aug 2011 18:18:41 -0000 Date: 3 Aug 2011 18:18:19 -0000 Message-ID: <20110803181819.94562.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] Misuse of ARF by spam-friendly ISPs X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 18:18:30 -0000 >The issue is whether it's reasonable for an "abuse@" address to >accept only reports that are ARFs. I would suggest that such is a >violation of RFC2142, ... Before there was ARF, I got plenty of responses saying that they ONLY take reports with the message pasted into the body of the message, or that they ONLY take reports with the message as an attachment, and so forth, so that bridge burned long ago and the ashes are cold. I agree that it's pretty lame to demand ARF, but it does sort of select for people who have some idea what they're doing. R's, John From laura@wordtothewise.com Wed Aug 3 11:27:37 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF3421F84DF for ; Wed, 3 Aug 2011 11:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paNvf1mhHxPd for ; Wed, 3 Aug 2011 11:27:36 -0700 (PDT) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 7916121F86D8 for ; Wed, 3 Aug 2011 11:27:35 -0700 (PDT) Received: from valeria.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: wttwlaura) by m.wordtothewise.com (Postfix) with ESMTPSA id A79042DEC3 for ; Wed, 3 Aug 2011 11:27:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Laura Atkins In-Reply-To: <20110803181819.94562.qmail@joyce.lan> Date: Wed, 3 Aug 2011 11:27:46 -0700 Cc: marf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <991DFC35-3354-4403-B225-EE4E895E18C7@wordtothewise.com> References: <20110803181819.94562.qmail@joyce.lan> X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 03 Aug 2011 11:53:05 -0700 Subject: Re: [marf] Misuse of ARF by spam-friendly ISPs X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 18:27:39 -0000 On Aug 3, 2011, at 11:18 AM, John Levine wrote: >> The issue is whether it's reasonable for an "abuse@" address to >> accept only reports that are ARFs. I would suggest that such is a >> violation of RFC2142, ... >=20 > Before there was ARF, I got plenty of responses saying that they ONLY > take reports with the message pasted into the body of the message, or > that they ONLY take reports with the message as an attachment, and so > forth, so that bridge burned long ago and the ashes are cold. > I agree that it's pretty lame to demand ARF, but it does sort of = select > for people who have some idea what they're doing. Not really, it's selecting for people who can write code that works with = their mail client and conforms to a standard. It doesn't select for = people who can send intelligent, useful reports. I can send a perfectly = competent abuse report, but I don't have the skills to code a ARF report = generator.=20 laura=20 --=20 Laura Atkins Word to the Wise "The Deliverability Experts!" Direct: 650 678-3454 Fax: 650 249-1909 AIM: wttwlaura YIM: wttw_laura Delivery blog: From jdfalk-lists@cybernothing.org Wed Aug 3 12:24:27 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686E921F8B37 for ; Wed, 3 Aug 2011 12:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBvE8OAudA4q for ; Wed, 3 Aug 2011 12:24:26 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id ADF3E21F8B3B for ; Wed, 3 Aug 2011 12:24:26 -0700 (PDT) Received: from [192.168.11.41] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p73JOa3e013181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 3 Aug 2011 12:24:38 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p73JOa3e013181 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=fudge; t=1312399478; bh=s0n6UKLttgEVQpJBCYTgC6zJ0GQz2CzN/GgQQWjbm YM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=WYllXVJjx1K4 Viv9CYfQ/D1AOw5mW8/L1dvTq+PWrgyQNZrWG15lQLZEpHTIvugWjv9tIOyn+nI0j8+ D9TuAlNf6t+XjR/fO9D/78JxkKNb+Q7ylw4eci/hRovGaWL86FhtKDOdUl6sTbjYMFX wZWsyw1s1U5hT5joIsa3JExUY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: <4E391CA5.6010803@tana.it> Date: Wed, 3 Aug 2011 12:24:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3FE12543-6A3F-4AE6-903C-3671F9141D61@cybernothing.org> References: <35734E6B-4579-4EF4-A139-7BFB4FA4573F@wordtothewise.com> <953887BF-E8AB-4246-8075-7EB50A7BF916@wordtothewise.com> <4E391CA5.6010803@tana.it> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] Misuse of ARF by spam-friendly ISPs X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 19:24:27 -0000 On Aug 3, 2011, at 3:02 AM, Alessandro Vesely wrote: > On 03/Aug/11 02:42, J.D. Falk wrote: >> On Jul 30, 2011, at 9:30 PM, Murray S. Kucherawy wrote: >>=20 >>> I wonder if this could be mentioned in the BCP effort we're doing = (JD?). >>=20 >> I suppose it could be added to the growing list of use cases that >> draft-jdfalk-marf-as specifically does not address, along with >> individual user submissions, virus/malware reports, churning monkey >> butter, et cetera. >=20 > What is the meaning of a list of non-addressed use cases? Possibly > suggest that they are not worth being addressed in general? Hmm... > that's quite strange, especially considering that everyone likes the > monkey butter. It was somewhat of a joke, but there does seem to be mounting pressure = to address other use cases in a BCP or AS. My advice to those who want = other use cases addressed is to write a draft addressing them. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From jdfalk-lists@cybernothing.org Wed Aug 3 12:36:16 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B682721F8B9F for ; Wed, 3 Aug 2011 12:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJbw54oSqe3T for ; Wed, 3 Aug 2011 12:36:15 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1914D21F8B9B for ; Wed, 3 Aug 2011 12:36:07 -0700 (PDT) Received: from [192.168.11.41] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p73JaHMb013413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 3 Aug 2011 12:36:19 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p73JaHMb013413 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=fudge; t=1312400179; bh=yRfGAqgueCxSaqWhfQCobFTOuBSD5nRi1FsAS1vd/ rM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=Alr/b5RGAhgR 8Ai6gT5sznkgYb0BZtJ1vO1j96Flj7XvlFkuwZ0nem/9KjKrT/rNi1NKWoDFL1NAEWk BBl0XFtl6YZjNmrL2LnhGwU4/1zQeix00fW8AJHiWIMSGlpQyslbP/BGAmfHhWchhEn 2FhWkSKpE7/6FomU7jVrYQKog= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: Date: Wed, 3 Aug 2011 12:36:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <35734E6B-4579-4EF4-A139-7BFB4FA4573F@wordtothewise.com> <953887BF-E8AB-4246-8075-7EB50A7BF916@wordtothewise.com> <4E391CA5.6010803@tana.it> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] Misuse of ARF by spam-friendly ISPs X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 19:36:16 -0000 On Aug 3, 2011, at 6:33 AM, Murray S. Kucherawy wrote: >> What is the meaning of a list of non-addressed use cases? Possibly >> suggest that they are not worth being addressed in general? >=20 > It's referring to a list of use cases that the ARF was not designed to = handle. There's no intent that I can see to state that those use cases = aren't interesting to handle. Actually, what I meant was that draft-jdfalk-marf-as and = draft-jdfalk-maawg-cfblbcp only fully address the complaint feedback = loop use case. There are other cases that ARF can handle, such as spam = traps or (maybe) virus/malware reports, which I'd think we should = discuss in a separate AS or BCP. Either way, though, I think that bitching at a single ISP about their = abuse@ policy is out of scope for any IETF document. If that practice = becomes common, maybe a "considered harmful" draft could be appropriate. = So far, though, there is one (1) example, which just happens to be a = big ISP that some people love to hate. It would be inappropriate, = unprofessional, and somewhat silly to try to use the IETF as a weapon = against them. >> Hmm... >> that's quite strange, especially considering that everyone likes the >> monkey butter. >=20 > That's a new one on me. What does it mean? http://www.jwz.org/gruntle/monkeybutter.html -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From vesely@tana.it Thu Aug 4 04:45:24 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33AC921F8B65 for ; Thu, 4 Aug 2011 04:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.525 X-Spam-Level: X-Spam-Status: No, score=-3.525 tagged_above=-999 required=5 tests=[AWL=-1.106, BAYES_00=-2.599, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yy5FXWMgjHUy for ; Thu, 4 Aug 2011 04:45:23 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA0421F8B5A for ; Thu, 4 Aug 2011 04:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1312458335; bh=nEaURUdBr+7cnYYTOOvaU82c94TB2nF5IM0VHb19viw=; l=1603; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=DpsfESrpmRbCD6dgmOv2Wm6t7Uo76DImLl5xNuh4wzNwGCVA8Zsip0JF+9M0BT48b 29YBaRgvy4h0J+b51jeI2lshOkrpjMZBl+7CupB04OVO4n9O1AdXtg2d2rqjQCB7mS viAzigf2CNnlnu1QWIzT0EAPuMKgv/aFv0ijM0Ag= 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, 04 Aug 2011 13:45:35 +0200 id 00000000005DC033.000000004E3A865F.00004EE1 Message-ID: <4E3A865F.1070904@tana.it> Date: Thu, 04 Aug 2011 13:45:35 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: marf@ietf.org References: <35734E6B-4579-4EF4-A139-7BFB4FA4573F@wordtothewise.com> <953887BF-E8AB-4246-8075-7EB50A7BF916@wordtothewise.com> <4E391CA5.6010803@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Misuse of ARF by spam-friendly ISPs X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 04 Aug 2011 11:45:24 -0000 On 03/Aug/11 15:33, Murray S. Kucherawy wrote: >> http://wiki.asrg.sp.am/wiki/Adding_a_junk_button_to_MUAs >> >> That still looks current. It allows MUAs to report in a variety of >> ways. For SMTP, it is obviously better to wrap the offending mail in >> an ARF message, but not mandatory. > > Just to be precise, I think JD is suggesting a BCP about how one > handles received abuse reports, not how they are generated. Yes, a MUA that downloaded a message from pop3.example.com would send it back to some address of example.com. In the same way, some other mailbox provider receiving abuse reports from its customers, finds out that a reported message belongs to example.com (DKIM or SPF auth, or IP assigned to example.com), and sends the report to some other address of example.com. There are a number of ways to discover which addresses of example.com should be used in each case. This, IMHO, should be the main topic of the new BCP. > The point at issue is that one large service provider has decided > only to accept abuse mail if it's an ARF; free-form complaints are > no longer accepted. While RFC 2142 is the last option for a tool, it is the easiest one for sending an abuse report manually. Because ARF is most probably managed automatically, hand written reports that include meaningful free-text should never be ARF-wrapped, nor sent to ARF-addresses. Reporting-discovery has a re= for the relevant role account. It defaults to abuse@. I'd take JD's advice and write a draft addressing both topics above, but I cannot start that before September. From shmuel+gen@patriot.net Thu Aug 4 15:04:51 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E253B21F8A7A for ; Thu, 4 Aug 2011 15:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=1.101, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biTG2Vi8BXvO for ; Thu, 4 Aug 2011 15:04:51 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6A51721F8A71 for ; Thu, 4 Aug 2011 15:04:51 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.179]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 35ACBF580A3 for ; Thu, 4 Aug 2011 17:55:41 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Thu, 04 Aug 2011 17:59:25 -0400 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20110804215542.35ACBF580A3@smtp.patriot.net> Subject: Re: [marf] Misuse of ARF by spam-friendly ISPs X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 04 Aug 2011 22:04:52 -0000 In , on 08/03/2011 at 06:33 AM, "Murray S. Kucherawy" said: >It's referring to a list of use cases that the ARF was not designed >to handle. What about reports[1] to LE? Is that worth considering in the future? >The issue is whether it's reasonable for an "abuse@" address to >accept only reports that are ARFs. IMHO that's a form of spam support. OTOH, if someone publishes a separate address for reports in ARF format, then IMHO it's reasonable to reject anything in *that* mailbox that's not ARF. >It's caused quite a bit of trouble, not the least of which being the >three co-authors of ARF getting a lot of "I hope you're happy" >hate-mail. I'd regard such complaints as misdirected and the authors as wingnuts. Yahoo never needed ARF to ignore legitimate complaints. [1] Especially for spam associated with crimes against persons rather than just the intrinsic crimes against property. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From jdfalk-lists@cybernothing.org Fri Aug 5 10:15:28 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5876A21F8C11 for ; Fri, 5 Aug 2011 10:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cc4WeqOceTfQ for ; Fri, 5 Aug 2011 10:15:27 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id AB41921F8C04 for ; Fri, 5 Aug 2011 10:15:24 -0700 (PDT) Received: from [192.168.11.32] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p75HFcl0020075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 5 Aug 2011 10:15:41 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p75HFcl0020075 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=fudge; t=1312564541; bh=wfSACJ+det9lWuO+gI7J7SieBlZkrxNR0jEVDI2es RE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=BEo85RUA+8/J tIUI531+gtMNzn1Gfqw4SGamacf4NyJlZTzphLS8mNpGoqKuVUlTAbSMIV28e9xE92B jl0ldUwZ/4E4Mn9RnwzzsA02g7go9kwuGC1eOT+6sySkX47OWil3oKI6aVcNAhMK+nx 32WjV3Dw1Rv2K8w5TMj8djxck= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: <20110804215542.35ACBF580A3@smtp.patriot.net> Date: Fri, 5 Aug 2011 10:15:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <33365635-0DF4-45C4-A80D-3B79996CD0F8@cybernothing.org> References: <20110804215542.35ACBF580A3@smtp.patriot.net> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] Misuse of ARF by spam-friendly ISPs X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 05 Aug 2011 17:15:28 -0000 On Aug 4, 2011, at 2:59 PM, Shmuel (Seymour J.) Metz wrote: > In > = , > on 08/03/2011 > at 06:33 AM, "Murray S. Kucherawy" said: >=20 >> It's referring to a list of use cases that the ARF was not designed >> to handle.=20 >=20 > What about reports[1] to LE? Is that worth considering in the future? If we can get some law enforcement folks involved and find out what they = want/need, sure. They probably want all sorts of metadata that most = reporters can't offer, though. On the other hand, there are already government agencies consuming ARF = as it is. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From shmuel+gen@patriot.net Sat Aug 6 23:18:01 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A2021F8593 for ; Sat, 6 Aug 2011 23:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.193 X-Spam-Level: X-Spam-Status: No, score=0.193 tagged_above=-999 required=5 tests=[AWL=-0.958, BAYES_50=0.001, SARE_CHILDPRN1=1.15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39n22N0c0YPl for ; Sat, 6 Aug 2011 23:18:01 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5D10721F84E9 for ; Sat, 6 Aug 2011 23:17:58 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.43]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 11A41F580A7 for ; Sun, 7 Aug 2011 02:08:43 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Sun, 07 Aug 2011 01:03:22 -0400 To: marf@ietf.org In-Reply-To: <33365635-0DF4-45C4-A80D-3B79996CD0F8@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: <20110807060847.11A41F580A7@smtp.patriot.net> Subject: Re: [marf] Misuse of ARF by spam-friendly ISPs X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 07 Aug 2011 06:18:02 -0000 In <33365635-0DF4-45C4-A80D-3B79996CD0F8@cybernothing.org>, on 08/05/2011 at 10:15 AM, "J.D. Falk" said: >On the other hand, there are already government agencies consuming >ARF as it is. For generic spam, sure, but not for, e.g., child pornography, counterfeit drugs. -- 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 internet-drafts@ietf.org Tue Aug 9 13:43:30 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3AD21F8C94; Tue, 9 Aug 2011 13:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suwXRNe8zG+J; Tue, 9 Aug 2011 13:43:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F82821F8C8B; Tue, 9 Aug 2011 13:43:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> Date: Tue, 09 Aug 2011 13:43:30 -0700 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 09 Aug 2011 20:43:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Messaging Abuse Reporting Format Work= ing Group of the IETF. Title : Authentication Failure Reporting using the Abuse Report = Format Author(s) : Hilda L. Fontana Filename : draft-ietf-marf-authfailure-report-01.txt Pages : 19 Date : 2011-08-09 This memo registers an extension report type to ARF to be used for reporting forensic information about messages that fail one or more message authentication schemes in use by the purported sender of the message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-authfailure-report-01.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-authfailure-report-01.txt From internet-drafts@ietf.org Fri Aug 12 08:33:32 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA71221F8A7D; Fri, 12 Aug 2011 08:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U49ip2LyaNr6; Fri, 12 Aug 2011 08:33:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7F721F84FC; Fri, 12 Aug 2011 08:33:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110812153332.29852.34750.idtracker@ietfa.amsl.com> Date: Fri, 12 Aug 2011 08:33:32 -0700 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-not-spam-feedback-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 12 Aug 2011 15:33:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Messaging Abuse Reporting Format Work= ing Group of the IETF. Title : Email Feedback Report Type Value : not-spam Author(s) : Kepeng Li Barry Leiba Filename : draft-ietf-marf-not-spam-feedback-01.txt Pages : 7 Date : 2011-08-12 This document defines a new Abuse Reporting Format (ARF) feedback report type value: "not-spam". It can be used to report a mes= sage that was mistakenly marked as spam. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-not-spam-feedback-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-not-spam-feedback-01.txt From msk@cloudmark.com Fri Aug 12 15:02:15 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEAA21F86EE for ; Fri, 12 Aug 2011 15:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.069 X-Spam-Level: X-Spam-Status: No, score=-103.069 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6FmILOE8kgf for ; Fri, 12 Aug 2011 15:02:14 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id DEFB221F8639 for ; Fri, 12 Aug 2011 15:02:14 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 12 Aug 2011 15:02:47 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 12 Aug 2011 15:02:45 -0700 Thread-Topic: [marf] I-D Action: draft-ietf-marf-not-spam-feedback-01.txt Thread-Index: AcxZBUj4Zf0LcV1GRK2q/KbDlPAKCwANjV3w Message-ID: References: <20110812153332.29852.34750.idtracker@ietfa.amsl.com> In-Reply-To: <20110812153332.29852.34750.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-not-spam-feedback-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 12 Aug 2011 22:02:15 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org > Sent: Friday, August 12, 2011 8:34 AM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: [marf] I-D Action: draft-ietf-marf-not-spam-feedback-01.txt >=20 > 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. >=20 > Title : Email Feedback Report Type Value : not-spam > Author(s) : Kepeng Li > Barry Leiba > Filename : draft-ietf-marf-not-spam-feedback-01.txt > Pages : 7 > Date : 2011-08-12 >=20 > This document defines a new Abuse Reporting Format (ARF) feedback > report type value: "not-spam". It can be used to report a m= essage > that was mistakenly marked as spam. I have submitted this to the IESG for publication. An IETF-wide last call = should begin soon. -MSK From msk@cloudmark.com Thu Aug 18 14:01:13 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5291021F8B7C for ; Thu, 18 Aug 2011 14:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.057 X-Spam-Level: X-Spam-Status: No, score=-103.057 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThBKWgdkgFZ6 for ; Thu, 18 Aug 2011 14:01:12 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 6431821F86EA for ; Thu, 18 Aug 2011 14:01:12 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 18 Aug 2011 14:02:07 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 18 Aug 2011 14:02:05 -0700 Thread-Topic: Comments on draft-ietf-marf-authfailure-report-01.txt Thread-Index: AcxW1RMNbfLFK61xTXWXIrjX8GzuxAHEtDBw Message-ID: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> In-Reply-To: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 21:01:13 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org > Sent: Tuesday, August 09, 2011 1:44 PM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: [marf] I-D Action: draft-ietf-marf-authfailure-report-01.txt >=20 > 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. >=20 > Title : Authentication Failure Reporting using the Abuse Repor= t Format > Author(s) : Hilda L. Fontana > Filename : draft-ietf-marf-authfailure-report-01.txt > Pages : 19 > Date : 2011-08-09 >=20 > This memo registers an extension report type to ARF to be used for > reporting forensic information about messages that fail one or more > message authentication schemes in use by the purported sender of the > message. Hi Hilda, It looks like in Section 3.2.2, the definition of "DKIM-Canonicalized-Body"= has gone missing. I believe it should go back in. The definition is the = same as for DKIM-Canonicalized-Header, except (obviously) change "haeder" t= o "body" in the definition text. In the first sentence of Section 3.3, we should change "header" to "header = field". Also in Section 3.3, for "granularity", we might want to mention that this = is supported in [OLD-DKIM] but not in [DKIM] since it's undergoing update n= ow and the whole concept of key granularity has been removed. We would the= n change the existing [DKIM] reference to [OLD-DKIM], and add one called [D= KIM] that points to the one that's currently in the RFC editor queue. (Bar= ry, check my math on this one, please.) Also in Section 3.3, the list of SPF result codes should have spaces after = the commas. Apart from that, I don't have any pending feedback. This specification is = implemented in OpenDKIM v2.4.2 (with one omission that will be present in t= he next release). I do have one question for the WG though: Do people think the current list = of Auth-Failure types is complete enough? Are there other specific cases w= e want to call out? Right now OpenDKIM puts signature failure details in p= arentheses after the "signature" keyword, but I wonder if there are some sp= ecific failure modes that deserve special treatment so a parser can be sure= to distinguish them. Off the top of my head, I can't think of any, but I'= d like to poll the group. If there's no other feedback, do people think we're ready to start a WGLC o= n this one? -MSK From msk@cloudmark.com Thu Aug 18 14:14:09 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A98F21F8B0F for ; Thu, 18 Aug 2011 14:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.054 X-Spam-Level: X-Spam-Status: No, score=-103.054 tagged_above=-999 required=5 tests=[AWL=-0.456, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoQUfjP8N86T for ; Thu, 18 Aug 2011 14:13:57 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB6B21F8B1D for ; Thu, 18 Aug 2011 14:13:57 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 18 Aug 2011 14:14:52 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 18 Aug 2011 14:14:51 -0700 Thread-Topic: Revisiting reporting addresses Thread-Index: Acxd695gO2r+Maw3RUWO/eryys1YlQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F13512DF7E4EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] Revisiting reporting addresses X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 21:14:09 -0000 --_000_F5833273385BB34F99288B3648C4F06F13512DF7E4EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Referring to draft-ietf-marf-dkim-reporting... The current document says the reporting address is either a local-part (a u= serid) or a full address. If it's a local-part, then "@" followed by the r= elevant domain is used to compose the full reporting address; for an ADSP r= eport, that's the From: domain, and for a DKIM failure report that's the "d= =3D" domain. So there are reasonable defaults, but it does allow one to st= ick any address at all there. I seem to recall it started out that way, th= en switch to local-part-only, then back to where it is now. Does everyone = concur that we want to allow that? If we do, I think this warrants text in Security Considerations acknowledgi= ng the attacks this enables, and talking about why we think that's okay. C= ould someone that remembers this discussion better than me propose some tex= t along those lines? This too has been implemented in OpenDKIM and its antecedent for a long tim= e. Thanks, -MSK --_000_F5833273385BB34F99288B3648C4F06F13512DF7E4EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Referring to dra= ft-ietf-marf-dkim-reporting…

=  

The current document says the reportin= g address is either a local-part (a userid) or a full address.  If it&= #8217;s a local-part, then “@” followed by the relevant domain = is used to compose the full reporting address; for an ADSP report, thatR= 17;s the From: domain, and for a DKIM failure report that’s the ̶= 0;d=3D” domain.  So there are reasonable defaults, but it does a= llow one to stick any address at all there.  I seem to recall it start= ed out that way, then switch to local-part-only, then back to where it is n= ow.  Does everyone concur that we want to allow that?

 

If we do, I th= ink this warrants text in Security Considerations acknowledging the attacks= this enables, and talking about why we think that’s okay.  Coul= d someone that remembers this discussion better than me propose some text a= long those lines?

 

<= p class=3DMsoNormal>This too has been implemented in OpenDKIM and its antec= edent for a long time.

 =

Thanks,

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F13512DF7E4EXCHC2corpclo_-- From msk@cloudmark.com Thu Aug 18 14:17:47 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF90F21F8586 for ; Thu, 18 Aug 2011 14:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.051 X-Spam-Level: X-Spam-Status: No, score=-103.051 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkwifTmJ4dcb for ; Thu, 18 Aug 2011 14:17:47 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 3018821F8574 for ; Thu, 18 Aug 2011 14:17:47 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 18 Aug 2011 14:18:42 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 18 Aug 2011 14:18:40 -0700 Thread-Topic: draft-ietf-marf-redaction Thread-Index: Acxd7GbQuG+3QuV/Q76ItvefTQtKIQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F13512DF7E5EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] draft-ietf-marf-redaction X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 21:17:47 -0000 --_000_F5833273385BB34F99288B3648C4F06F13512DF7E5EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Other than a few grammatical nits, I'm happy with this document. I think t= his reflects the recommended practice that's derived from the original ARF = work. Are there any FBLs doing this now? This would be helpful to note as the do= cument prepares to advance. -MSK --_000_F5833273385BB34F99288B3648C4F06F13512DF7E5EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Other than a few= grammatical nits, I’m happy with this document.  I think this r= eflects the recommended practice that’s derived from the original ARF= work.

 

Are there any FBLs doing this now?  This would be helpful to = note as the document prepares to advance.

 

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F13512DF7E5EXCHC2corpclo_-- From msk@cloudmark.com Thu Aug 18 14:33:54 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BEE11E80A2 for ; Thu, 18 Aug 2011 14:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.048 X-Spam-Level: X-Spam-Status: No, score=-103.048 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCl-ALBr-LV0 for ; Thu, 18 Aug 2011 14:33:53 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 4F33B11E80A1 for ; Thu, 18 Aug 2011 14:33:53 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 18 Aug 2011 14:34:48 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 18 Aug 2011 14:34:47 -0700 Thread-Topic: Comments on draft-ietf-marf-spf-reporting Thread-Index: Acxd7qc6hVF8Mb+lRDe+L4EMuzTF4Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F13512DF7E7EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] Comments on draft-ietf-marf-spf-reporting X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 21:33:55 -0000 --_000_F5833273385BB34F99288B3648C4F06F13512DF7E7EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A few comments on this draft: Section 3 should probably include a sentence at the end that says "In the a= bsence of an 'r=3D' tag in the SPF record, all other fields defined above M= UST be ignored." Some of the stuff in Section 6 looks like it might have been copied verbati= m from [ARF] or [DSN] (though I've not confirmed this). If that's the case= , I'd prefer to see them incorporated by reference rather than by value. I= also wonder if any copied from draft-ietf-marf-authfailure-report and/or d= raft-ietf-marf-dkim-reporting should also be incorporated by reference, and= normative references added accordingly. I think there's still an open question about whether Section 5.1 belongs he= re or in the fledgling SPFbis effort. I think we have a few choices there: 1) Do it this way, since the future and path of SPFbis is uncertain. 2) Do it as its own memo and see if APPSAWG will pick it up right away. It= would only contain the "exp" and "redirect" entries just for the sake of c= reating the registry, and would be marked as "updates 4408". Then, this me= mo simply updates that registry, and SPFbis can update it as well if needed= . This might be the cleanest solution. (Barry, thoughts?) 3) Replace Section 5 with text that basically says we know SPF doesn't allo= w unknown modifiers, but proceed anyway because people that want this will = be able to make the distinction somehow. That might warrant demoting this = to Experimental and upgrading it later. Then SPFbis or a separate action c= an create the registry and make it all formal when its future is more clear= . I'm quite in favour of 1 and/or 2. In Section 4.1, PermError needs an end-quote. I think [DKIM] is an informative reference here, not a normative one. In Appendix A, my last name is spelled incorrectly. :) Finally, does anyone know of any SPF implementations under current maintena= nce that are entertaining the idea of implementing these extensions? -MSK --_000_F5833273385BB34F99288B3648C4F06F13512DF7E7EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A few comments o= n this draft:

 

Section 3 should probably include a sentence at the end tha= t says “In the absence of an ‘r=3D’ tag in the SPF record= , all other fields defined above MUST be ignored.”

 

Some of the stuf= f in Section 6 looks like it might have been copied verbatim from [ARF] or = [DSN] (though I’ve not confirmed this).  If that’s the cas= e, I’d prefer to see them incorporated by reference rather than by va= lue.  I also wonder if any copied from draft-ietf-marf-authfailure-rep= ort and/or draft-ietf-marf-dkim-reporting should also be incorporated by re= ference, and normative references added accordingly.

 

I think there’= s still an open question about whether Section 5.1 belongs here or in the f= ledgling SPFbis effort.  I think we have a few choices there:

 

1) Do = it this way, since the future and path of SPFbis is uncertain.

 

2) Do it a= s its own memo and see if APPSAWG will pick it up right away.  It woul= d only contain the “exp” and “redirect” entries jus= t for the sake of creating the registry, and would be marked as “upda= tes 4408”.  Then, this memo simply updates that registry, and SP= Fbis can update it as well if needed.  This might be the cleanest solu= tion.  (Barry, thoughts?)

&nbs= p;

3) Replace Section 5 with text that basica= lly says we know SPF doesn’t allow unknown modifiers, but proceed any= way because people that want this will be able to make the distinction some= how.  That might warrant demoting this to Experimental and upgrading i= t later.  Then SPFbis or a separate action can create the registry and= make it all formal when its future is more clear.

 

I’m quite in f= avour of 1 and/or 2.

 

In Section 4.1, PermError needs an end-quote.

 

I th= ink [DKIM] is an informative reference here, not a normative one.

 

In Appe= ndix A, my last name is spelled incorrectly.  J

 =

Finally, does anyone know of any SPF implementatio= ns under current maintenance that are entertaining the idea of implementing= these extensions?

 

=

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F13512DF7E7EXCHC2corpclo_-- From msk@cloudmark.com Thu Aug 18 14:44:02 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABA121F884C for ; Thu, 18 Aug 2011 14:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.546 X-Spam-Level: X-Spam-Status: No, score=-103.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mPdmT3EGUGw for ; Thu, 18 Aug 2011 14:44:02 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6328E21F85B9 for ; Thu, 18 Aug 2011 14:44:02 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 18 Aug 2011 14:44:57 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Thu, 18 Aug 2011 14:44:55 -0700 Thread-Topic: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain Thread-Index: AcxOLWzC3U7D65imQoWp08ef0JxcJQPwjQ7w Message-ID: References: <1311898476.94112.YahooMailClassic@web45310.mail.sp1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 21:44:02 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of J= .D. Falk > Sent: Friday, July 29, 2011 1:23 PM > To: Message Abuse Report Format working group > Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report > subdomain >=20 > Using ARF for reports from MUAs has been discussed many times, but > hasn't really ever been implemented (except for a Thunderbird plugin, > years ago, now lost to history.) I'd love to see somebody try it, but > until they do I don't think we can call it a common practice. However, "Report Spam" buttons, including ours, do send proprietary feedbac= k of some kind in a lot of instances. Having an ARF implementation would b= e great. Maybe we should chase down that Thunderbird plugin... :-) > MARF is already widely accepted. There are dozens of report generators > and literally thousands of report consumers, nearly all following the > use case described in draft-jdfalk-marf-as. That's part of why there's > disagreement -- we don't want to change MARF in ways which would be > incompatible with the established userbase. There are some people in MAAWG from the AV vendors. I wonder if they'd be = interested in FBLs that use ARF for the purpose of reporting suspected viru= s payloads. From sklist@kitterman.com Thu Aug 18 14:45:48 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3783711E80BA for ; Thu, 18 Aug 2011 14:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAuGSNWdubgG for ; Thu, 18 Aug 2011 14:45:47 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6D24F11E80B9 for ; Thu, 18 Aug 2011 14:45:47 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id A74F338C094; Thu, 18 Aug 2011 17:46:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1313704001; bh=JqDV4LphMVz9dkADjDG11jq7K7gbSCRNNjqUXxpiFGI=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=TavQXGKynBtnK3AHD0TO045+Eu3cpUDxMWSszrKVIr9n5kyRyIaV6y9EP97QhUZPx zLo7osjgJ9KgdQc2lg6W9Zk4StjHjbQLTr70GylIzmNnfqNJQA3fvUxNPtsy06VrQ9 m73CaFKbDVyDCubsPQla85jM2dykYg1OPOwZJ8yI= From: Scott Kitterman To: marf@ietf.org Date: Thu, 18 Aug 2011 17:46:39 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic-pae; KDE/4.6.2; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201108181746.40288.sklist@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Comments on draft-ietf-marf-spf-reporting X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 21:45:48 -0000 On Thursday, August 18, 2011 05:34:47 PM Murray S. Kucherawy wrote: > Finally, does anyone know of any SPF implementations under current > maintenance that are entertaining the idea of implementing these > extensions? I'm planning on doing it, but there is some other work I have to do first. Scott K From sklist@kitterman.com Thu Aug 18 14:53:49 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADC611E80B9 for ; Thu, 18 Aug 2011 14:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pL597uRRI6HG for ; Thu, 18 Aug 2011 14:53:48 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6AA11E80A9 for ; Thu, 18 Aug 2011 14:53:48 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 15ED838C094; Thu, 18 Aug 2011 17:54:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1313704483; bh=UhjJ4nj4MYbYBtkrtu2G5mAWbxYVEAq5veZwzWC1w0k=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=Vi43FAj4JSzjJwOjjNfg4iJ2p2GEWDcwGqFGePyVuOpVEtIKrGlvOPNJvrt/leD0+ aX+tsn5NYbFh7u1L0bn7H0gtrbPgzq8NYb/dwH0YrUfWoCoO0slwZpKkZ8czIe1UHC ssc+SXe2yMmeF8oliGF9imIuTFdDitwc3Zw8WVfM= From: Scott Kitterman To: marf@ietf.org Date: Thu, 18 Aug 2011 17:54:40 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic-pae; KDE/4.6.2; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201108181754.40422.sklist@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Comments on draft-ietf-marf-spf-reporting X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 21:53:49 -0000 On Thursday, August 18, 2011 05:34:47 PM Murray S. Kucherawy wrote: > I think there's still an open question about whether Section 5.1 belongs > here or in the fledgling SPFbis effort. I think we have a few choices > there: > > 1) Do it this way, since the future and path of SPFbis is uncertain. > > 2) Do it as its own memo and see if APPSAWG will pick it up right away. It > would only contain the "exp" and "redirect" entries just for the sake of > creating the registry, and would be marked as "updates 4408". Then, this > memo simply updates that registry, and SPFbis can update it as well if > needed. This might be the cleanest solution. (Barry, thoughts?) > > 3) Replace Section 5 with text that basically says we know SPF doesn't > allow unknown modifiers, but proceed anyway because people that want this > will be able to make the distinction somehow. That might warrant demoting > this to Experimental and upgrading it later. Then SPFbis or a separate > action can create the registry and make it all formal when its future is > more clear. > > I'm quite in favour of 1 and/or 2. My preference would be to leave it here until 4408bis has some traction, but I'm OK with either 1 or 2. 4408 does allow unknown modifiers (unknown mechanisms aren't allowed), the registry just ensures the namespace is managed to avoid collisions. Scott K From msk@cloudmark.com Thu Aug 18 15:24:59 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADF91F0C42 for ; Thu, 18 Aug 2011 15:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.046 X-Spam-Level: X-Spam-Status: No, score=-103.046 tagged_above=-999 required=5 tests=[AWL=-0.447, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDNFn+Day0wr for ; Thu, 18 Aug 2011 15:24:59 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 273BF1F0C3C for ; Thu, 18 Aug 2011 15:24:59 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 18 Aug 2011 15:25:54 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 18 Aug 2011 15:25:52 -0700 Thread-Topic: [marf] Comments on draft-ietf-marf-spf-reporting Thread-Index: Acxd8XHZ5jCqodjbSsK7wBMZClMOnAABDhNg Message-ID: References: <201108181754.40422.sklist@kitterman.com> In-Reply-To: <201108181754.40422.sklist@kitterman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Comments on draft-ietf-marf-spf-reporting X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 22:24:59 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Scott Kitterman > Sent: Thursday, August 18, 2011 2:55 PM > To: marf@ietf.org > Subject: Re: [marf] Comments on draft-ietf-marf-spf-reporting >=20 > My preference would be to leave it here until 4408bis has some traction, = but > I'm OK with either 1 or 2. 4408 does allow unknown modifiers (unknown > mechanisms aren't allowed), the registry just ensures the namespace is ma= naged > to avoid collisions. Ah, OK. That makes life easier. Then it's really just a matter of whether or not it's acceptable to do some= thing in MARF that really APPSAWG or SPFBIS should be handling. From msk@cloudmark.com Thu Aug 18 15:46:42 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DCC11E80B9 for ; Thu, 18 Aug 2011 15:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.543 X-Spam-Level: X-Spam-Status: No, score=-103.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxBQAcY296tN for ; Thu, 18 Aug 2011 15:46:42 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3F011E809C for ; Thu, 18 Aug 2011 15:46:42 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 18 Aug 2011 15:47:36 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 18 Aug 2011 15:47:35 -0700 Thread-Topic: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain Thread-Index: AcxNhITx/bCDDp4BQFKhE7F46j+l4gQcZQLQ Message-ID: References: <1311898476.94112.YahooMailClassic@web45310.mail.sp1.yahoo.com> In-Reply-To: <1311898476.94112.YahooMailClassic@web45310.mail.sp1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 22:46:42 -0000 Apologies for not replying to this sooner. The Quebec City IETF conference= was quite busy, and I'm only now de-queuing various pending MARF work. > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of z= av961 > Sent: Thursday, July 28, 2011 5:15 PM > To: marf@ietf.org > Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subd= omain >=20 > Of course, MARF also has its use in Outlook or similiar Mail Software > where a user can push a button to mark a mail spam, or not spam, and > the sending ISP (and/or filter provider) automatically gets informed > upon that user intervention. A fully manual MARF report would seem over > the top however. I don't think anyone envisioned construction of ARFs by hand, the same as o= ne would never imagine generating an MDN or DSN by hand. But getting suppo= rt for it in more MUAs would be very desirable. I imagine it's a lot like = any new mail protocol though: Producers are waiting for consumers, and vice= -versa. To the general question of sending malware payloads in ARF reports, perhaps= this is something JD could add to the reporting discovery draft, i.e., whe= ther or not an FBL consumer expresses willingness to accept malware payload= s. > Well, if that claim of no-one ever reporting malware automatically ever > existed, our implementation is the living example to the contrary. Naturally any such claim is based on one's own knowledge. It just means we= 've never heard of one, which in turn means we have no experience with them= . > > If people concur that this is an issue, I would suggest > > updating the base document to provide a requirement that a > > virus report include the name of the reporting software and > > the virus name it used, and restrict the third MIME part to > > be text/rfc822-headers. >=20 > I obviously support that motion! I would suggest then that you or someone interested in seeing that change m= ade take some time to produce an individual submission draft and then submi= t it to the working group for consideration. I'm happy to provide guidance= on how to do that if needed. > When I mentioned advertising the IP address of the potential MARF > report transmitter similiar to SPF, I overlooked an important security > question (that's always the danger of a single brain thinking). SPF and > MARF have a decisive difference in the use for the bad boys. SPF is > hardly exploitable even if it gets under full control of a malicious > user. However, MARF could become a dangerous tool in the hands of a > malicious user misleading ISPs/regulating bodies or launching DoS > attacks against abuse departments. Which leads me to think on a second > thought that the MARF senders should be identified through ARIN and > their delegated authorities, too, just like the abuse mail addresses. > That approach immediately puts the out of band topic to rest, too. There's a separate document in the working group (which I think you've seen= ) discussing a method to advertise the preferred destination for feedback r= eports. I think, for both political and technical reasons, that venue is a= lot more likely to be successful than an attempt to change what's availabl= e through WHOIS. We already do say (or at least, I'm pretty sure we do) that ARF reports sho= uldn't be accepted or trusted other than by prior arrangement, specifically= to reduce the threat of injection of false reports. Some of that includes= suggestions like ensuring reports are signed somehow so that their authent= icity can be verified. I'm sure some implementations also check SPF. > A) feedback-type: virus >=20 > I propose to change the keyword virus to malware. A straight rename is probably a problem in case it's already in widespread = use. You might get away with defining "malware" and deprecating "virus", a= lthough I have some doubts about that too. > In the report section following fields become mandatory: > [...] I suggest putting this stuff in a draft and bringing it to the working grou= p. > B) MARF Discovery (_report subdomain) >=20 > B.1 Rethink the whole draft in view of automated responders, malicious > abuse and ongoing ARIN database extensions, I'd think the current > proposal could be dropped >=20 > B.2 Require ARIN/delegated authorities published abuse addresses to > unconditionally accept MARF reports (they automatically do as it stands > due to the humanly readable first part and third part containing the > relevant evidence) >=20 > B.3 Introduce a MARF sender identification (via IP address(es)) with > ARIN/IP assignment authorities similiar to abuse address registration >=20 > B.4. As long as ARIN/IP assignment authorities are not featuring such > MARF database entries import the SPF RFC replacing selector SPF with > MARF for identifying authorised MARF transmitters. As I'm learning now with the fledgling WEIRDS effort, the IETF has no purvi= ew to cause ARIN or any RIR to do anything in terms of what data they requi= re from registrants or make available via WHOIS. That's something you'd ha= ve to pursue with ICANN, as it's entirely a matter of policy and not one of= technology. (I'm not sure how that logic jives with RFC2142, however.) If this is important to your vision, I suspect dropping the reporting-disco= very document is in fact the wrong thing to do, and instead we should work = at updating it to match your needs in a way that achieves consensus. -MSK From sm@resistor.net Thu Aug 18 20:24:30 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A30311E808C for ; Thu, 18 Aug 2011 20:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNfJM9ojqFoF for ; Thu, 18 Aug 2011 20:24:29 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C14211E8082 for ; Thu, 18 Aug 2011 20:24:29 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p7J3PJ7X021128 for ; Thu, 18 Aug 2011 20:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1313724324; bh=Wzu0ra6+pt9H7jIwFl1SyC2NCf1mGsEle1n2TisG3qE=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=Xi97t/99vie/BBB3nF8iIGuCW230gEWtKlVRQigLgDFozn+cVLXLMdtH9+SFZohMk uBy9pLP5FjlBnHl6E5yWrJygqWknVNPKHAfAAr6/tF02FQAjiIFOVySjr3sdenkVj7 fIix177uMKOstO8d/Y8PQ+jFsN6wJlhtG214vRdU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1313724324; bh=Wzu0ra6+pt9H7jIwFl1SyC2NCf1mGsEle1n2TisG3qE=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=FVrnV4wOvwUiGtD2CWatgxx3TKQCsdyqaF7+KbSTdp+RE1Z5NpJkLuoKDKdjtupsV pB+C1ALM3RuMVBGoRDYNUMlC5WfVfGUSDH54/nEE5LFoLF5CwBnCYf18Fxpe9ZXQyc jQh81oiKBIDnBJkdzppDIEf+s7uT1oysgskXHNLM= Message-Id: <6.2.5.6.2.20110818195528.0b274a28@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 18 Aug 2011 20:08:48 -0700 To: marf@ietf.org From: SM In-Reply-To: References: <1311898476.94112.YahooMailClassic@web45310.mail.sp1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 19 Aug 2011 03:24:30 -0000 At 15:47 18-08-2011, Murray S. Kucherawy wrote: > > B.2 Require ARIN/delegated authorities published abuse addresses to > > unconditionally accept MARF reports (they automatically do as it stands > > due to the humanly readable first part and third part containing the > > relevant evidence) If a sender fills your queue with a misdirected ARF report every second, would you unconditionally accept it or take other action? >As I'm learning now with the fledgling WEIRDS effort, the IETF has >no purview to cause ARIN or any RIR to do anything in terms of what >data they require from registrants or make available via >WHOIS. That's something you'd have to pursue with ICANN, as it's >entirely a matter of policy and not one of technology. (I'm not >sure how that logic jives with RFC2142, however.) For the IP address angle, use existing RIR processes to get what you want. I doubt that ICANN can do much in that area. It's better to avoid the RFC 2142 logic as it leads to unproductive discussions. Regards, -sm From shmuel+gen@patriot.net Fri Aug 19 04:55:58 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A3021F8AE6 for ; Fri, 19 Aug 2011 04:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.545 X-Spam-Level: X-Spam-Status: No, score=-1.545 tagged_above=-999 required=5 tests=[AWL=1.054, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jn4dPQX2ez8H for ; Fri, 19 Aug 2011 04:55:58 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 21BE721F8AE1 for ; Fri, 19 Aug 2011 04:55:57 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.23]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 59501F580AB for ; Fri, 19 Aug 2011 07:47:07 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Fri, 19 Aug 2011 07:57:50 -0400 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20110819114707.59501F580AB@smtp.patriot.net> Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 19 Aug 2011 11:55:58 -0000 In , on 08/18/2011 at 03:47 PM, "Murray S. Kucherawy" said: >To the general question of sending malware payloads in ARF reports, >perhaps this is something JD could add to the reporting discovery >draft, i.e., whether or not an FBL consumer expresses willingness to >accept malware payloads. How about a separate flag as to whether the consumer wants full text, only header or full text except for malware? -- 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 barryleiba.mailing.lists@gmail.com Wed Aug 24 06:19:34 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9443721F8AD6 for ; Wed, 24 Aug 2011 06:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.031 X-Spam-Level: X-Spam-Status: No, score=-103.031 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ypXTrYiNCJp for ; Wed, 24 Aug 2011 06:19:34 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 117ED21F8AB0 for ; Wed, 24 Aug 2011 06:19:34 -0700 (PDT) Received: by gyf3 with SMTP id 3so1024659gyf.31 for ; Wed, 24 Aug 2011 06:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=idRt+2dHYWLLFNd6kFn8UDIHVU81dooopG/0AtcWaos=; b=eMzT9pMeWPdWS7PDdj2I9qaZqwmtDcdzRw2nnHhCU7VVSgCnMsHC2o+slOSVbJOmS/ Zgkq4lAlepCIxsveVZKS9WAV3fMOIT1p9wKfNaakpj8FokxQc7J2j9OpezEE3yj0g9G9 1Ufn+aAohUx+dOHJCGokV5EAV2E2u9C3Dm8Uk= MIME-Version: 1.0 Received: by 10.236.187.74 with SMTP id x50mr30102742yhm.76.1314192044540; Wed, 24 Aug 2011 06:20:44 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.181.13 with HTTP; Wed, 24 Aug 2011 06:20:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Aug 2011 09:20:44 -0400 X-Google-Sender-Auth: _91A1BHMLmef5pZFRWNWAOv6XrQ Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "marf@ietf.org" Subject: Re: [marf] Comments on draft-ietf-marf-spf-reporting X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 13:19:34 -0000 > I think there=92s still an open question about whether Section 5.1 belong= s > here or in the fledgling SPFbis effort.=A0 I think we have a few choices > there: > > 1) Do it this way, since the future and path of SPFbis is uncertain. > > 2) Do it as its own memo and see if APPSAWG will pick it up right away.= =A0 It > would only contain the =93exp=94 and =93redirect=94 entries just for the = sake of > creating the registry, and would be marked as =93updates 4408=94.=A0 Then= , this > memo simply updates that registry, and SPFbis can update it as well if > needed.=A0 This might be the cleanest solution.=A0 (Barry, thoughts?) > > 3) Replace Section 5 with text that basically says we know SPF doesn=92t = allow > unknown modifiers, but proceed anyway because people that want this will = be > able to make the distinction somehow.=A0 That might warrant demoting this= to > Experimental and upgrading it later.=A0 Then SPFbis or a separate action = can > create the registry and make it all formal when its future is more clear. I think the best path for now is (1) -- assume that SPF is as it is, and don't predict the future. It's likely that this document will go out before anything changes with SPF, and any SPF working group can pick this up later and incorporate it, and flag itself as "updates [this]". Barry From barryleiba.mailing.lists@gmail.com Wed Aug 24 06:32:25 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5963221F8B59 for ; Wed, 24 Aug 2011 06:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.03 X-Spam-Level: X-Spam-Status: No, score=-103.03 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rC89OfO71hVg for ; Wed, 24 Aug 2011 06:32:24 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB6B021F8B4E for ; Wed, 24 Aug 2011 06:32:24 -0700 (PDT) Received: by gyf3 with SMTP id 3so1035302gyf.31 for ; Wed, 24 Aug 2011 06:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=C+d++dNPyoJ+Ydim0xW13BYSybJpMVAcQZMo6+D65A0=; b=WmZtcUTcBnoQba5FVYaTfBDJUV4EBqAEOWABXHV7cErO3J0asj4Whdcjb6UHzOSYeb fV1XNU/vXEl1l8FXPn49tVNODjjfR7TrmV2jYK0iSVL6QdKTdLmDxmToeOWY8Wl2tnrd hFFtFTZ7MIcghGedgZzWjf2Uk2zFxzDwQo4vI= MIME-Version: 1.0 Received: by 10.146.140.9 with SMTP id n9mr5149316yad.39.1314192815193; Wed, 24 Aug 2011 06:33:35 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.181.13 with HTTP; Wed, 24 Aug 2011 06:33:35 -0700 (PDT) Date: Wed, 24 Aug 2011 09:33:35 -0400 X-Google-Sender-Auth: jVinM8hw18JhIP0njcynWwQL-YE Message-ID: From: Barry Leiba To: Message Abuse Report Format working group Content-Type: text/plain; charset=ISO-8859-1 Subject: [marf] Working group status, and progress on the active documents X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 13:32:25 -0000 The chairs would like to see some progress on the documents the group is working on. The group is still in the middle of a lot of work -- let's look at getting it done, please. ** draft-ietf-marf-reporting-discovery-01 JD posted this version on 27 July, and there have been no comments. JD, what do you consider the status of this version to be? Do you think it needs more work, or is it ready to go? Everyone else, please review this version and post comments, or let us know that you've reviewed it and you think it's ready. Then there's the four-way split: ** draft-ietf-marf-authfailure-report-01 This has had the most recent action. Hilda posted this version on 9 August, and Murray posted his comments on 18 August, here: http://www.ietf.org/mail-archive/web/marf/current/msg01245.html Resolving Murray's comments will require another draft version. But in his message, he also asked some chair questions; we need feedback on this, so Hilda can do an -02 version that can go into working group last call. ** draft-ietf-marf-spf-reporting-01 Scott posted this version on 11 July. Murray commented here: http://www.ietf.org/mail-archive/web/marf/current/msg01248.html Again, there are some questions in Murray's comments; please give your input. Scott, what do you consider the status of this version to be? ** draft-ietf-marf-dkim-reporting-02 Murray posted this version on 15 May. There've been no comments at all. Has anyone looked at it? Do we think we have the split right, and have the right bits been split out of it? ** draft-ietf-marf-redaction-00 JD posted the first working-group version on 6 April. The only comment so far is from Murray, who thinks it's ready. We need more reviews. JD, do you think this version is ready, or do you intend to post a revision? Others, please review and comment, or let us know that you think it's done. Finally, we have this one pending: ** draft-jdfalk-marf-as-00 JD posted this on 13 May, and there's been little substantive said about it. It's how we plan to address the charter item that coincides with MAAWG's feedback loop document (draft-jdfalk-maawg-cfblbcp). Is this the path the WG wants to take? Shall we adopt this as a WG document, and proceed with it? Reviews and comments, please. Barry, as chair From shmuel+gen@patriot.net Wed Aug 24 10:00:29 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31EF21F8C9F for ; Wed, 24 Aug 2011 10:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pi1BtDPBeE4f for ; Wed, 24 Aug 2011 10:00:29 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id E57BF21F8C4B for ; Wed, 24 Aug 2011 10:00:25 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.142]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id C2ADDF5808C for ; Wed, 24 Aug 2011 12:51:34 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Wed, 24 Aug 2011 12:42:59 -0400 To: Message Abuse Report Format working group Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20110824165134.C2ADDF5808C@smtp.patriot.net> Subject: [marf] Comments on draft-ietf-marf-reporting-discovery-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 17:00:29 -0000 The first paragraph of 9.3. Privacy considerations is overly restrictive. If the recipient provided an e-mail for a specific purpose and the sender uses it for unauthorized purposes, then it is spam and should be reported as such. Example: an e-mail address provided to a car dealer strictly for service updates that is used for marketing. In such cases there is an involvement but there is not permission for the specific messages. Of course, if you request announcements of all new printers then an announcement of a printer you're not interested would not be spam; the issue is consent. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From shmuel+gen@patriot.net Wed Aug 24 10:16:54 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B4421F858D for ; Wed, 24 Aug 2011 10:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.635 X-Spam-Level: X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[AWL=0.964, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUTqpBk9tgYP for ; Wed, 24 Aug 2011 10:16:54 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC8421F856B for ; Wed, 24 Aug 2011 10:16:54 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.67]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id D3E9BF5808C for ; Wed, 24 Aug 2011 13:08:10 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Wed, 24 Aug 2011 11:34:59 -0400 To: Message Abuse Report Format working group Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20110824170810.D3E9BF5808C@smtp.patriot.net> Subject: [marf] draft-ietf-marf-not-spam-feedback-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 17:16:55 -0000 The only comment I have is with regard to 1.1. Discussion. There should be mention that the relevant questions are whether the message is solicited or one-to-one, not whether it is desired or useful. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From shmuel+gen@patriot.net Wed Aug 24 10:17:08 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905EC21F8A64 for ; Wed, 24 Aug 2011 10:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.731 X-Spam-Level: X-Spam-Status: No, score=-1.731 tagged_above=-999 required=5 tests=[AWL=0.868, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utgt4LIC8M4L for ; Wed, 24 Aug 2011 10:17:08 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2008821F8751 for ; Wed, 24 Aug 2011 10:17:08 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.67]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id DDF68F5808C for ; Wed, 24 Aug 2011 13:08:23 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Wed, 24 Aug 2011 13:19:34 -0400 To: Message Abuse Report Format working group Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20110824170824.DDF68F5808C@smtp.patriot.net> Subject: [marf] Comments on draft-jdfalk-marf-as-00 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 17:17:08 -0000 There should be some discussion of MARF reports initiated from generic MUA's rather than MUA's provided by the MSA operator. There should be a statement that MARF is not meant to replace plain text reports to abuse and postmaster, but rather is an additional option. -- 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 hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Aug 24 15:06:58 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB3521F8B75 for ; Wed, 24 Aug 2011 15:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.236 X-Spam-Level: X-Spam-Status: No, score=-102.236 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_21=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viZjPqlpp71z for ; Wed, 24 Aug 2011 15:06:57 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8C11A21F8B4F for ; Wed, 24 Aug 2011 15:06:57 -0700 (PDT) Received: by pzk33 with SMTP id 33so3322556pzk.18 for ; Wed, 24 Aug 2011 15:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=hu5IaU/1Jwkm76z6YlKuloRMhsCm9k3G5oiS9Pzvnx4=; b=Yq2PdsKJ7WJpD4lU/CFzWauakQHG0tEqC4yySoklZyXP7PUByPkjhU1DBRHAeqsOtL VYMb2Poy1NjXufkT1aDwR+8gIHXrl3vd8GbQoQvDtz9JJQ1JpJRJPB1oWAPmsCHehPEC rfW1+HYUIXPMx35dr8fTG+n+zdcLrTtdw8jeo= Received: by 10.143.60.19 with SMTP id n19mr2913612wfk.241.1314223688282; Wed, 24 Aug 2011 15:08:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.98.5 with HTTP; Wed, 24 Aug 2011 15:07:28 -0700 (PDT) In-Reply-To: References: From: Frank Ellermann Date: Thu, 25 Aug 2011 00:07:28 +0200 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "marf@ietf.org" Subject: Re: [marf] Comments on draft-ietf-marf-spf-reporting X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 22:06:58 -0000 On 18 August 2011 23:34, Murray S. Kucherawy wrote: > Section 3 should probably include a sentence at the end that says =93In t= he > absence of an =91r=3D=92 tag in the SPF record, all other fields defined = above > MUST be ignored.=94 +1 I don't see the difference between exp=3D and rs=3D, if it is in fact almos= t the same an explanation of exp=3D in the context of MARF would be better than a new modifier. IMO result SOFTFAIL implies "want report", there should be no opt-out in ro=3D. Any PERMERROR or SOFTFAIL must be interesting for somebody wishing to get reports at all (limited by ri=3D if desired). A FAIL report is slightly dubious, if it's a bug in the policy senders got an ordinary bounce (or a "go away" for their FAILing EHLO), and need no extra report blowing up their logfile. They certainly need no report if some spammer forges their EHLO or MAIL FROM in thousands of FAILing mails, eliminating backscatter is one of the main points of SPF. It makes no sense to replace backscatter by opt-in FAIL reports. If the receiver does not reject FAIL curious senders might be interested in the fact, but then ro=3Df could be limited to "unrejected" mail, or let's just say ro=3Df is bogus. OTOH ro=3Dn could be very interesting, if it is something that should be PASS or FAIL instead of NEUTRAL. Suggestion: ro=3Ddebug or ro=3Ddefault, where "debug" asks for any NEUTRAL reports in addition to the default PERMERROR and SOFTFAIL. Obviously there can't be SOFTFAIL reports for a policy without SOFTFAIL outcome, and that is as it should be, but explaining it in the draft helps. All bytes in an SPF policy are precious, ro=3Dd for "debug" and no ro=3D at all for "default" might be good enough. > Some of the stuff in Section 6 looks like it might have been copied > verbatim from [ARF] or [DSN] (though I=92ve not confirmed this).=A0 If > that=92s the case, I=92d prefer to see them incorporated by reference > rather than by value. Okay, but for very important security points explaining what the given reference is about helps. The author can demonstrate to know what it says, readers have no excuse to say that it was hidden in a reference. > I also wonder if any copied from draft-ietf-marf-authfailure-report > and/or draft-ietf-marf-dkim-reporting should also be incorporated > by reference SPF and DKIM tend to be orthogonal (as designed in the case Of DKIM), what do you have in mind? I have not yet understood the difference between the r=3D address in I-D.ietf-marf-spf-reporting and section 7.2 in I-D.ietf-marf-reporting-discovery-01. > there=92s still an open question about whether Section 5.1 belongs > here or in the fledgling SPFbis effort. Quite a lot of folks volunteered to help with 4408bis, I hope that can be done (=3D ready and published) in a few months. If that's the case it is not really necessary to create an SPF modifier registry now: IOW, there won't be any conflicts with the MARF SPF modifiers. IIRC and if I did not miss something in 2009 or 2010 these are the first *new* suggestions for modifiers since RFC 4408 got its number. The simplified ro=3D proposed above could be queezed into op=3D options to save bytes, or better, some remarks about "new modifiers in SPF" in the old op=3D draft can be adopted in I-D.ietf-marf-spf-reporting. > Replace Section 5 with text that basically says we know SPF doesn=92t > allow unknown modifiers That is not exactly the case, see RFC 4408 section 6 intro. The main problem are new yes/no SPF modifiers claiming to have a default, and "opting in" SPF policies published years before the modifier existed. This would be strictly against the SPF design, working policies are supposed to work without "upgrades" as long as they describe the IPs permitted to send MAIL FROM, etc. No need to "opt-out" from any new tricks, the main topic of the old op=3D SPF draft. Where precisely is the ball or token wrt a 4408bis WG at the moment? -Frank From vesely@tana.it Thu Aug 25 11:33:29 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419B721F8BD8 for ; Thu, 25 Aug 2011 11:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.65 X-Spam-Level: X-Spam-Status: No, score=-4.65 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zEBHCNcFRj6 for ; Thu, 25 Aug 2011 11:33:28 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6F88B21F8BC5 for ; Thu, 25 Aug 2011 11:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1314297281; bh=yJUeUnS6bl9Vb49CiVaCYn/alXFZ8jTHZp+ufggkrxQ=; l=936; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=b0kdThM4QbukbowoVf63SLbivnG6zSfs6HCG6FTA1x85oM6pcRUsYjAfvzw9KhnQT IOQLK1gBwxLbCh8aED1dshq/ebzD8jkuJH3Yi/Cdl/Vqc9eJjAN0Jgmg4MijecpMAh xzgHAnhbBvDDE0fO5BVASt8xtx8k4ue1Uud9UDoI= 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, 25 Aug 2011 20:34:40 +0200 id 00000000005DC033.000000004E5695C0.000065D5 Message-ID: <4E5695C0.2010508@tana.it> Date: Thu, 25 Aug 2011 20:34:40 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.20) Gecko/20110804 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: marf@ietf.org References: <20110824170824.DDF68F5808C@smtp.patriot.net> In-Reply-To: <20110824170824.DDF68F5808C@smtp.patriot.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Comments on draft-jdfalk-marf-as-00 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 25 Aug 2011 18:33:29 -0000 On 24/Aug/11 19:19, Shmuel (Seymour J.) Metz wrote: > There should be some discussion of MARF reports initiated from generic > MUA's rather than MUA's provided by the MSA operator. I think you mean "MUA's provided by the _Mailbox Provider_ operator", that is to say, the ones sporting its TiS button. If not, please clarify. > There should be a statement that MARF is not meant to replace plain > text reports to abuse and postmaster, but rather is an additional > option. This topic was touched in "Misuse of ARF by spam-friendly ISPs" http://www.ietf.org/mail-archive/web/marf/current/msg01223.html JD suggested a separate BCP to discuss spam reporting from general public. Murray said he'd be fine with that. It is still not clear whether that BCP would be in this WG; and whether in such case the marf-as would mention it, or vice-versa it should also mention FBLs, so as to provide an overview of ARF usage. From shmuel+gen@patriot.net Fri Aug 26 05:56:07 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D283C21F8772 for ; Fri, 26 Aug 2011 05:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.385 X-Spam-Level: X-Spam-Status: No, score=-0.385 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_20=-0.74, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-g6kIucJLcM for ; Fri, 26 Aug 2011 05:56:07 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB4521F8742 for ; Fri, 26 Aug 2011 05:56:07 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.96]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 75ECAF580A7 for ; Fri, 26 Aug 2011 08:29:40 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Thu, 25 Aug 2011 17:07:49 -0400 To: marf@ietf.org In-Reply-To: <4E5695C0.2010508@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: <20110826122941.75ECAF580A7@smtp.patriot.net> Subject: Re: [marf] Comments on draft-jdfalk-marf-as-00 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 26 Aug 2011 12:56:07 -0000 In <4E5695C0.2010508@tana.it>, on 08/25/2011 at 08:34 PM, Alessandro Vesely said: >I think you mean "MUA's provided by the _Mailbox Provider_ operator", Well, I suppose that in theory you could have split servers operated by different organization, but normally the MSA and MX are under common control, along with any POP3 or IMAP4 servers involved. IAC, I would expect the report to go via the MSA rather than the MX. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From msk@cloudmark.com Fri Aug 26 11:18:08 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9735A21F8AED for ; Fri, 26 Aug 2011 11:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.538 X-Spam-Level: X-Spam-Status: No, score=-103.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2c+V75Wh5yuK for ; Fri, 26 Aug 2011 11:18:08 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 15EEB21F8A35 for ; Fri, 26 Aug 2011 11:18:08 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 26 Aug 2011 11:19:24 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 26 Aug 2011 11:19:23 -0700 Thread-Topic: I-D Action: draft-ordogh-spam-reporting-using-imap-00.txt Thread-Index: AcxkGfb2eNlctnnzTT20P6HRh77GkQAAqo2A 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: I-D Action: draft-ordogh-spam-reporting-using-imap-00.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 26 Aug 2011 18:18:08 -0000 For those of us tracking the SpamRep convergence issue (which should be mos= t of us!), this might be of interest: -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Friday, August 26, 2011 10:58 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-ordogh-spam-reporting-using-imap-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Spam reporting using IMAP: SREP Author(s) : Zoltan Ordogh Filename : draft-ordogh-spam-reporting-using-imap-00.txt Pages : 16 Date : 2011-08-26 The Internet Message Access Protocol [IMAP4] does not support reporting spam on its own. There are a number of solutions available based on the multipart/report content type defined in [REPORT]. However, these solutions require including the message contents and hence, consume bandwidth to transmit the entire message. In bandwidth-constrained environments - such as mobile networks - it is highly desirable to send only a minimum set of information - a reference - instead of the entire message. Furthermore, it is desirable to permit individual server implementations to handle spam in any way these systems choose to: do nothing, flag, recommend deletion or relocation, perform deletion or relocation, and, involve any choice of spam aggregator services in the decision process, such as [OMA-SPAMREP]. Solutions that exist today employ manipulating proprietary flags in the IMAP storage to achieve the bare minimum, however more advanced solutions cannot be developed by using flags only; the IMAP server needs to be involved actively in the spam reporting process. This document specifies the syntax of the SREP command, which allows a client to inform the server that the user considered a message (or parts thereof) spam, or, that the user no longer considers a message (or parts thereof) spam. Since all information about the message is readily available on the server, the command also allows the server to implement a more intelligent and accurate decision logic, which may be invoked when the spam is reported and the server can respond with its decision to the client. Additionally, this document contains example flows, illustrating various decisions that the server may choose to evaluate, including invoking a service based on [OMA-SPAMREP]. This document focuses only on the client-server interactions and the scope is limited to messages that either exist on the IMAP server, or, exist elsewhere and the IMAP server is configured to access them. Consequently, deposit-time filtering, messages that have been deleted, or, exist in an external storage but are accessible via an access protocol unknown to the IMAP server are out of scope. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ordogh-spam-reporting-using-imap-= 00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ordogh-spam-reporting-using-imap-0= 0.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From alex@bobotek.net Fri Aug 26 11:19:28 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F49521F8C00 for ; Fri, 26 Aug 2011 11:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bw01NAJRB+jT for ; Fri, 26 Aug 2011 11:19:28 -0700 (PDT) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by ietfa.amsl.com (Postfix) with ESMTP id ECF4E21F8A35 for ; Fri, 26 Aug 2011 11:19:27 -0700 (PDT) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta02.emeryville.ca.mail.comcast.net with comcast id R6LX1h0020vp7WLA26LgRw; Fri, 26 Aug 2011 18:20:40 +0000 Received: from bobo1.bobotek.net ([71.231.189.124]) by omta05.emeryville.ca.mail.comcast.net with comcast id R6Kw1h0052hUyyF8R6KwCx; Fri, 26 Aug 2011 18:19:56 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Aug 2011 11:21:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [marf] FW: I-D Action: draft-ordogh-spam-reporting-using-imap-00.txt Thread-Index: AcxkGfb2eNlctnnzTT20P6HRh77GkQAAqo2AAAASzmA= References: From: "Alex Bobotek" To: "Murray S. Kucherawy" , Subject: Re: [marf] FW: I-D Action: draft-ordogh-spam-reporting-using-imap-00.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 26 Aug 2011 18:19:28 -0000 Thanks. Reading the link with interest ... Alex -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Friday, August 26, 2011 11:19 AM To: marf@ietf.org Subject: [marf] FW: I-D Action: draft-ordogh-spam-reporting-using-imap-00.txt For those of us tracking the SpamRep convergence issue (which should be most of us!), this might be of interest: -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Friday, August 26, 2011 10:58 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-ordogh-spam-reporting-using-imap-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Spam reporting using IMAP: SREP Author(s) : Zoltan Ordogh Filename : draft-ordogh-spam-reporting-using-imap-00.txt Pages : 16 Date : 2011-08-26 The Internet Message Access Protocol [IMAP4] does not support reporting spam on its own. There are a number of solutions available based on the multipart/report content type defined in [REPORT]. However, these solutions require including the message contents and hence, consume bandwidth to transmit the entire message. In bandwidth-constrained environments - such as mobile networks - it is highly desirable to send only a minimum set of information - a reference - instead of the entire message. Furthermore, it is desirable to permit individual server implementations to handle spam in any way these systems choose to: do nothing, flag, recommend deletion or relocation, perform deletion or relocation, and, involve any choice of spam aggregator services in the decision process, such as [OMA-SPAMREP]. Solutions that exist today employ manipulating proprietary flags in the IMAP storage to achieve the bare minimum, however more advanced solutions cannot be developed by using flags only; the IMAP server needs to be involved actively in the spam reporting process. This document specifies the syntax of the SREP command, which allows a client to inform the server that the user considered a message (or parts thereof) spam, or, that the user no longer considers a message (or parts thereof) spam. Since all information about the message is readily available on the server, the command also allows the server to implement a more intelligent and accurate decision logic, which may be invoked when the spam is reported and the server can respond with its decision to the client. Additionally, this document contains example flows, illustrating various decisions that the server may choose to evaluate, including invoking a service based on [OMA-SPAMREP]. This document focuses only on the client-server interactions and the scope is limited to messages that either exist on the IMAP server, or, exist elsewhere and the IMAP server is configured to access them. Consequently, deposit-time filtering, messages that have been deleted, or, exist in an external storage but are accessible via an access protocol unknown to the IMAP server are out of scope. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ordogh-spam-reporting-using-im ap-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ordogh-spam-reporting-using-ima p-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From vesely@tana.it Fri Aug 26 11:45:14 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D32921F8C53 for ; Fri, 26 Aug 2011 11:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.653 X-Spam-Level: X-Spam-Status: No, score=-4.653 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBENeFM7dXL2 for ; Fri, 26 Aug 2011 11:45:13 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB9221F8C4F for ; Fri, 26 Aug 2011 11:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1314384388; bh=3qHhOYlu7YaUtpu72RFio/sNB3Oy882epWRRAuGM5v0=; l=3065; h=Message-ID:Date:From:MIME-Version:To:Content-Transfer-Encoding; b=SasL6LK+iazADU3nN/+B+GW3f3wo8u3U1GD5GrGqhXBhUKoLXrGWuWOiWzNngf0Xg PH0hNfqrt82rca4yK8H4w2pGO+IkMwG5bnvkoit3FLxIwLRTHNj1k6jIb4V6kf7sJw QjYYtdOHX6nIVDSi9ttun2XvZ16R+V4grSVGEo6s= 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; Fri, 26 Aug 2011 20:46:28 +0200 id 00000000005DC044.000000004E57EA04.00004B25 Message-ID: <4E57EA04.9070405@tana.it> Date: Fri, 26 Aug 2011 20:46:28 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.20) Gecko/20110804 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: Message Abuse Report Format working group Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [marf] Comments on draft-ietf-marf-redaction-00 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 26 Aug 2011 18:45:14 -0000 The doc only describes a technique, whereas it could mention some use cases and give more info to developers. Thus it doesn't seem to me to be ready. I propose some thoughts that may lead to additional info for marf-redaction, if the WG deems worth to expand on them: *Redacting the header* Section 2 bullet 2 mentions "local-parts of email addresses", which is fine. However, the spec puts it within parentheses and prefixed by "such that", thereby allowing unwanted mangling. Some email addresses probably should never be redacted, e.g. From: and Return-Path:, except for VERP. Recipients addresses may appear in To:, Cc:, the "for" clause of Received:, Delivered-To:, Envelope-To:, X-Envelope-To:, X-Rcpt-To:, X-Original-To:, and the like. Would it make sense to attempt a possibly comprehensive list, as a guide to developers? In addition, any of these fields that was added locally could as well be removed altogether. By redacting To: or Cc: a reporter most likely breaks any DKIM signature. That might prevent the report from being accepted, so it should be mentioned. Workarounds are probably different for FBLs than for reports submitted by general public. *Redacting the body* I've seen some mailing list software obscuring email addresses in the body, but found no guidance about this. People send passwords and credit card numbers via email, and there is no standard to annotate that these are sensible strings --a lost cause. At any rate, when the body is covered by a signature, the same concern as above arises. *What to redact* The reporting-discovery draft has a "Privacy considerations" section saying that messages containing sensible data must not be reported as spam. Messages reported as spam are considered public. (That section might be moved to a BCP) This concept may be a means to convey that the already-abused recipient addresses are the only piece of data that deserve redaction. Jacqui Caren recommends "redaction of all identifying marks when dealing with a spamtrap of obvious spam", in a scenario where redaction is "based upon the anti-spam score the orginal message gets and what level of trust you place in the MSP". http://www.ietf.org/mail-archive/web/marf/current/msg01048.html Probably two or more honeypots are required to identify by difference what parts of the messages contain varying information that can potentially betray the destination address. OTOH, users can inadvertently report as spam legitimate messages that contain other kinds of sensible data. Asking "Are you sure?" in the GUI won't probably help much. *Where is the pristine message*? It has been mentioned that reports may need to be transmitted to LEAs. In some cases, a judge may order the disclosure of redacted data. Can we use Message-Id: or similar field to locate it? If we can, we'd better suggest to never redact that field. If transmission to LEAs crosses jurisdictional boundaries, it may be useful to tell which country/state is the pristine data located in. -- From zordogh@rim.com Fri Aug 26 12:38:39 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34FA21F8C97 for ; Fri, 26 Aug 2011 12:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-5xgL1AZ0R7 for ; Fri, 26 Aug 2011 12:38:39 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 01C7321F8C92 for ; Fri, 26 Aug 2011 12:38:38 -0700 (PDT) X-AuditID: 0a412830-b7b62ae000006be9-6e-4e57f6827691 Received: from XHT107CNC.rim.net (xht107cnc.rim.net [10.65.12.217]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 92.AE.27625.286F75E4; Fri, 26 Aug 2011 19:39:46 +0000 (GMT) Received: from XCH115CNC.rim.net ([fe80::80ac:da43:d0fd:dcae]) by XHT107CNC.rim.net ([fe80::5db:5632:3d0b:13ed%11]) with mapi; Fri, 26 Aug 2011 15:39:55 -0400 From: Zoltan Ordogh To: "marf@ietf.org" Date: Fri, 26 Aug 2011 15:39:53 -0400 Thread-Topic: I-D Action: draft-ordogh-spam-reporting-using-imap-00.txt Thread-Index: AcxkGfb2eNlctnnzTT20P6HRh77GkQAAqo2AAAHl26A= Message-ID: <6AAA768C4EF38B458F619FA367ACAB8352B6643A65@XCH115CNC.rim.net> 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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsXC5chzU7fpW7ifwYWzRhbX1z1lt1j9cQeb A5NHx8RdTB5LlvxkCmCKamC0SczLyy9JLElVSEktTrZV8klNT8xRCCjKLEtMrlRwySxOzknM zE0tUlLITLFVMlFSKMhJTE7NTc0rsVVKLChIzUtRsuNSwAA2QGWZeQqpecn5KZl56bZKnsH+ uhYWppa6hkp2ukgg4R93xuJFi1gK/vJWnNm1m6mBcTZ3FyMnh4SAiUTf7J1sELaYxIV764Fs Lg4hgV4miRunrrJDOIsYJWa0gjgcHGwCqhJzrsaCNIgIKEusuLWZHcRmFtCVmNc4gxnEZgEq eb1iHVhcWMBNYsa2W0wQ9e4SzWsOsEPYVhLz3/9jBLF5BbwkOldMA6sREgiW6DgxC6yGUyBE 4sGM92AzGYGO+35qDRPELnGJW0/mM0EcLSCxZM95ZghbVOLl43+sEPWiEnfa1zNC1OtILNj9 iQ3C1pZYtvA1M8ReQYmTM5+wTGAUm4Vk7CwkLbOQtMxC0rKAkWUVo2BuRrGBmWFyXrJeUWau Xl5qySZGcJrQMNjBOGGv1iFGAQ5GJR7el8/C/YRYE8uKK3MPMUpwMCuJ8F7fDBTiTUmsrEot yo8vKs1JLT7EaAEMuYnMUtzJ+cAUllcSb2xggMJREucNkzbwExJIByak7NTUgtQimFYmDk6p BsaOWd3Pf92w+Gq91Vc/2uzBtopNYeJSv6Rbc57Vvqz1eF38Z92Ov6ocFU9Xx/Yxn31Rd7T7 h+mKc/Fz1ddyiDmm7ngjqCq0spN19UOtDraYFzzVbzU1CpxyiiuK5shNN7y33O3o0mWrf38Q iHiu9PzBxjVyMeL/Luty7Nnz/OyvYymlCdLbSlyUWIozEg21mIuKEwG2zLjTLAMAAA== Subject: Re: [marf] I-D Action: draft-ordogh-spam-reporting-using-imap-00.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 26 Aug 2011 19:38:39 -0000 Hi all, I was going to forward it myself, but it appears you are much faster. I did not identify any working group in IETF in the draft on purpose. I was thinking that YAM might be a good candidate, but YAM is closing. MARF is a good candidate, but I was not sure about the attendance of IMAP ex= perts. So, I left it as an individual draft for now. Some history. The motivation for this document originates from the OMA EVVM working group. "OMA" stands for Open Mobile Alliance, it is an SDO, see www.openmobileallia= nce.org "EVVM" stands for Enhanced Visual Voice Mail. In general, the group have requirements to report spam and to report that a= message is longer spam. "Message" here refers to voicemails, which include audio and video attachmen= ts. Being a mobile-focused group, the group needs a mechanism to report spam whi= le keeping the bandwidth usage at the minimal level, and possibly reuse a pr= otocol stack which is already in the scope. The choice for IMAP was very convenient because it is already in the scope (= it is the base protocol), it is easily extensible, and, the entire message i= s already available on the server (no need to upload anything but a referenc= e). The rest is pretty straightforward: a new, extensible command with the argum= ents to go, facilitating all kinds use cases. While it is an individual contribution, it has been reviewed and endorsed by= members of the OMA EVVM working group. Hopefully there will be a liaison statement following up soon to back these= statements up - once we identify the recipient of such liaison statement. In the meantime, it would appreciate if you reviewed the draft. Should you have questions or comments, please do not hesitate to contact me. Thank you. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From zordogh@rim.com Fri Aug 26 13:01:32 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F232921F8AFB for ; Fri, 26 Aug 2011 13:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFbW4D6zeQnf for ; Fri, 26 Aug 2011 13:01:31 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2F04B21F87F0 for ; Fri, 26 Aug 2011 13:01:31 -0700 (PDT) X-AuditID: 0a41282f-b7c26ae000000631-c8-4e57fbd3cfa9 Received: from XHT104CNC.rim.net (xht104cnc.rim.net [10.65.22.52]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id 68.60.01585.3DBF75E4; Fri, 26 Aug 2011 20:02:28 +0000 (GMT) Received: from XCH115CNC.rim.net ([fe80::80ac:da43:d0fd:dcae]) by XHT104CNC.rim.net ([fe80::9520:36d8:1c40:a506%11]) with mapi; Fri, 26 Aug 2011 16:02:47 -0400 From: Zoltan Ordogh To: Zoltan Ordogh , "marf@ietf.org" Date: Fri, 26 Aug 2011 16:02:46 -0400 Thread-Topic: I-D Action: draft-ordogh-spam-reporting-using-imap-00.txt Thread-Index: AcxkGfb2eNlctnnzTT20P6HRh77GkQAAqo2AAAHl26AAAasNEA== Message-ID: <6AAA768C4EF38B458F619FA367ACAB8352B6643AA6@XCH115CNC.rim.net> References: <6AAA768C4EF38B458F619FA367ACAB8352B6643A65@XCH115CNC.rim.net> In-Reply-To: <6AAA768C4EF38B458F619FA367ACAB8352B6643A65@XCH115CNC.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42LhchQz0b3yO9zP4PREFovr656yOzB6LFny kymAMaqB0SYxLy+/JLEkVSEltTjZVsknNT0xRyGgKLMsMblSwSWzODknMTM3tUhJITPFVslE SaEgJzE5NTc1r8RWKbGgIDUvRcmOSwED2ACVZeYppOYl56dk5qXbKnkG++taWJha6hoq2eki gYR/3BkTJr1gL9gqUfH5zC32BsZOkS5GTg4JAROJhwuWMUHYYhIX7q1nA7GFBHqYJN6fze5i 5AKyFzNKvLpxgrGLkYODTUBVYs7VWJAaEQEXiWcztzKD2CxA4WeNfWC2sICbxIxtt5ggatwl mtccYIewnSTe7z3FCGLzCnhJvFk/kxFi/hRGiZ0XO8EWcwp4S7y+uQ2sgRHooO+n1oANYhYQ l7j1ZD7UoQISS/acZ4awRSVePv7HClEvKnGnfT0jRL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJ ywRG0VlIxs5C0jILScssJC0LGFlWMQrmZhQbmBkk5yXrFWXm6uWllmxiBMe+hv4Oxr69WocY BTgYlXh4vX6F+wmxJpYVV+YeYpTgYFYS4b2+GSjEm5JYWZValB9fVJqTWnyI0QIYdBOZpbiT 84FpKa8k3tjAAIWjJM4bLG3gJySQDkw82ampBalFMK1MHJxSDYw5kvsYn18xS1qbLGH3g/dD 6Io7m6vZbfNcPC9fuy/Jevi/0IeHQh+UVs/h/HdGVMaQ3cRHbMbnJ/fEHyYe7Z9j/p5bk73M 721zr7ba7VWrMgXCpNneHj2iMEddMkRLLqj1/b6l4ap6RwzfM39oXLKrVzH1nsyr/4w8MYs/ xkokHdeNKnOYEaTEUpyRaKjFXFScCAB+E3ldFgMAAA== Subject: Re: [marf] I-D Action: draft-ordogh-spam-reporting-using-imap-00.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 26 Aug 2011 20:01:32 -0000 Hi all, There is an error in my message below. The word 'no' is missing. Here's the corrected sentence: In general, the group have requirements to report spam and to report that a= message is no longer spam. Sorry about that, and thank you Moh, for pointing it out. -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Zolt= an Ordogh Sent: August 26, 2011 3:40 PM To: marf@ietf.org Subject: Re: [marf] I-D Action: draft-ordogh-spam-reporting-using-imap-00.tx= t Hi all, I was going to forward it myself, but it appears you are much faster. I did not identify any working group in IETF in the draft on purpose. I was thinking that YAM might be a good candidate, but YAM is closing. MARF is a good candidate, but I was not sure about the attendance of IMAP ex= perts. So, I left it as an individual draft for now. Some history. The motivation for this document originates from the OMA EVVM working group. "OMA" stands for Open Mobile Alliance, it is an SDO, see www.openmobileallia= nce.org "EVVM" stands for Enhanced Visual Voice Mail. In general, the group have requirements to report spam and to report that a= message is longer spam. "Message" here refers to voicemails, which include audio and video attachmen= ts. Being a mobile-focused group, the group needs a mechanism to report spam whi= le keeping the bandwidth usage at the minimal level, and possibly reuse a pr= otocol stack which is already in the scope. The choice for IMAP was very convenient because it is already in the scope (= it is the base protocol), it is easily extensible, and, the entire message i= s already available on the server (no need to upload anything but a referenc= e). The rest is pretty straightforward: a new, extensible command with the argum= ents to go, facilitating all kinds use cases. While it is an individual contribution, it has been reviewed and endorsed by= members of the OMA EVVM working group. Hopefully there will be a liaison statement following up soon to back these= statements up - once we identify the recipient of such liaison statement. In the meantime, it would appreciate if you reviewed the draft. Should you have questions or comments, please do not hesitate to contact me. Thank you. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From msk@cloudmark.com Fri Aug 26 13:14:15 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F4521F8BD8 for ; Fri, 26 Aug 2011 13:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.539 X-Spam-Level: X-Spam-Status: No, score=-103.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkYkeb4-wTl2 for ; Fri, 26 Aug 2011 13:14:14 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id E6ECE21F8AFB for ; Fri, 26 Aug 2011 13:14:14 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 26 Aug 2011 13:15:31 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 26 Aug 2011 13:15:31 -0700 Thread-Topic: I-D Action: draft-ordogh-spam-reporting-using-imap-00.txt Thread-Index: AcxkGfb2eNlctnnzTT20P6HRh77GkQAAqo2AAAHl26AAAbRR0A== Message-ID: References: <6AAA768C4EF38B458F619FA367ACAB8352B6643A65@XCH115CNC.rim.net> In-Reply-To: <6AAA768C4EF38B458F619FA367ACAB8352B6643A65@XCH115CNC.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ordogh-spam-reporting-using-imap-00.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 26 Aug 2011 20:14:15 -0000 Hi Zoltan, In fact, we have in the MARF charter the requirement that we track the work= going on in the OMA's SpamRep working group with an ideal solution being t= he convergence of the two mechanisms. That's why your draft caught my eye. I'm also the IETF liaison to the OMA. So yes, we know who they are. :-) Thanks for contacting us. I'm sure feedback will be coming soon. -MSK From johnl@iecc.com Fri Aug 26 20:25:25 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030FC21F8862 for ; Fri, 26 Aug 2011 20:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.827 X-Spam-Level: X-Spam-Status: No, score=-110.827 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_21=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jCwapMfKSuE for ; Fri, 26 Aug 2011 20:25:24 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF5021F8841 for ; Fri, 26 Aug 2011 20:25:23 -0700 (PDT) Received: (qmail 61945 invoked from network); 27 Aug 2011 03:26:40 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 27 Aug 2011 03:26:40 -0000 Received: (qmail 3180 invoked from network); 27 Aug 2011 03:26:39 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 27 Aug 2011 03:26:39 -0000 Date: 27 Aug 2011 03:26:17 -0000 Message-ID: <20110827032617.7123.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: [marf] draft-ietf-marf-reporting-discovery-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 27 Aug 2011 03:25:25 -0000 I have my doubts about how useful these things would be, but here's a bunch of comments: In sec 5, it says you can identify the consumer domain by DKIM d=, SMTP bounce address domain, or MTA rDNS. I'm wondering whether it is a problem that they all funnel into _report. without any way to tell the difference. If it mattered, I'd suggest adding a tag in the record saying which sort of name the record applies to, with multiple records if need be. For feedback generators, I have no idea how I'm supposed to pick a domain name to look up. If, say, I wanted feedback from Gmail, would that be google.com? gmail.com? googlemail.com? The name of one of their MX hosts? Any or all of the bazillion mail domains they host? Something else? In 5.1, I'd delete the rt= and ri= tags since I don't see how they improves interoperability. If someone is inviting me to send them abuse reports, I'm going to send them abuse reports, and the number of reports will be limited by the amount of mail they send. They can always ignore the ones they don't understand. For the r= tag, I don't understand why it's supposed to be able both to accept ARF abuse reports and to respond to a subscription verification request. Presumably the response is automated, since no human is going to be looking through the stream of ARF for subscriptions. Is there some yet to be defined protocol here? Also it might be better to make r= a URI rather than an email address, so it can be a mailto: or an http: allowing POST. Why is there a gp=r policy but no rp=r policy? I accept random mail to my abuse address, but for feedback senders I know, I treat their ARFs differently (basically, I believe all of the latter and treat them as unconditional unsubscribes.) In 5.4, I would suggest specifically limiting the kind of URIs that the fields can include, unless someone is prepared to explain what to do if you see ru=nntp:news.example.com. Sec 9, security, the obvious problem is that a malicious sender can publish "rp=o r=myenemy@somewhere.com" and indirectly mailbomb people. The mention of subscription verification suggests there's supposed to be some sort of handshake before turning on the cannon, but if it's there, I've missed it. R's, John From vesely@tana.it Sat Aug 27 02:31:59 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5B421F8A1A for ; Sat, 27 Aug 2011 02:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.505 X-Spam-Level: X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=-1.086, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MANGLED_SPAM=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vF7idCj09bAe for ; Sat, 27 Aug 2011 02:31:59 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C6E7821F89CC for ; Sat, 27 Aug 2011 02:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1314437596; bh=CL4ILyAmj+yWv9rRmetZDdyNfk/bVG2yRBndMddh0Kw=; l=3875; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=NTEAiUILCqnyCKvhYTuaHAkuG0FnesI7PTnbqFozLUlz45TrgChrthuxyh4r11gFq ZhpOHnII2wlwFGO70V0QFzZpX4IJsw3OtQEXH1Mx0zOEeRecYLwEE0YJ5+VMwbaukB 8lGRr2RtBoUOutr7VXaL+uF2j3SqWceKeZ5wkfxY= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 27 Aug 2011 11:33:16 +0200 id 00000000005DC033.000000004E58B9DC.000018FF Message-ID: <4E58B9DC.5020907@tana.it> Date: Sat, 27 Aug 2011 11:33:16 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.20) Gecko/20110804 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: Zoltan Ordogh References: <6AAA768C4EF38B458F619FA367ACAB8352B6643A65@XCH115CNC.rim.net> In-Reply-To: <6AAA768C4EF38B458F619FA367ACAB8352B6643A65@XCH115CNC.rim.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "marf@ietf.org" Subject: Re: [marf] I-D Action: draft-ordogh-spam-reporting-using-imap-00.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 27 Aug 2011 09:32:00 -0000 Hi Zoltan, thank you so much for a long awaited IMAP extension!! On 26/Aug/11 21:39, Zoltan Ordogh wrote: > MARF is a good candidate, but I was not sure about the attendance > of IMAP experts. So, I left it as an individual draft for now. I think reporting mechanisms are the meat and potatoes of MARF. I wish this draft be adopted by this WG. > In general, the group have requirements to report spam and to > report that a message is no longer spam. These match the "abuse" type defined by RFC 5965 and the "non-spam" type that draft-ietf-marf-not-spam-feedback is going to define. In http://www.iana.org/assignments/marf-parameters/marf-parameters.xml there is a registry of these types. While spam-reporting-using-imap can define any new types it needs, I think it may reference that registry and use existing types when possible. http://www.iana.org/assignments/imap-keywords/imap-keywords.xml is a similar registry for IMAP flags. $Junk and $NotJunk are there, but $WHATEVER-spam-user-identified is not. Obviously, it is relevant for the IMAP server to know whether spam-classification is a user's or an automated decision, so I'd suggest to register this flag. Currently, it is not possible to transmit such user-vs-auto info using ARF. The one use case that I can think of for an identified-body.X is client-side detected viral attachments, but I'm sure there are more. Header fields identification looks more tricky. Anyway, those values seem to be rather orthogonal to one another. Would there be any advantage if they were defined independently of one another? > "Message" here refers to voicemails, which include audio and video > attachments. Being a mobile-focused group, the group needs a > mechanism to report spam while keeping the bandwidth usage at the > minimal level, and possibly reuse a protocol stack which is already > in the scope. The choice for IMAP was very convenient because it is > already in the scope (it is the base protocol), it is easily > extensible, and, the entire message is already available on the > server (no need to upload anything but a reference). The rest is > pretty straightforward: a new, extensible command with the > arguments to go, facilitating all kinds use cases. I see. I welcome examples with voicemail, but would encourage you to also add examples of plain text messages. I'd remove the OMAENVVM10 prefix from flags, though, especially if they're going to be registered at IANA. The example in section 1.10.1 is not going to be very useful for people who ignore what an aggregator service is. While I'd hope that standardizing aggregation services is the topic of this or some other WG, it is obviously not going to be defined within this document, hence I'd confine this term to informative examples --that is, remove it from Abstract and Security Considerations-- in order to avoid giving the impression that this protocol is somehow proprietary. In facts, it is very general, and hacks for similar functionality common. See http://wiki.asrg.sp.am/wiki/Adding_a_junk_button_to_MUAs#Via_IMAP A more generic discussion of server-side features is probably useful. In particular, I would mention that a server MAY report spammy messages to external, possibly public or foreign audiences, and/or make local copies of them. Of course, users have to know and agree to site policy, especially where law mandates that. The Security Considerations section should mention the possibility that users trigger server's actions accidentally. > --------------------------------------------------------------------- > This transmission (including any attachments) may contain > confidential information, [...] Please read this (and possibly more) on confidentiality notices: http://www.ietf.org/mail-archive/web/ietf/current/msg67516.html -- From vesely@tana.it Sat Aug 27 04:26:47 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F9121F85E3 for ; Sat, 27 Aug 2011 04:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.332 X-Spam-Level: X-Spam-Status: No, score=-4.332 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8N6pNSGoHg8I for ; Sat, 27 Aug 2011 04:26:46 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id BCC4D21F85C0 for ; Sat, 27 Aug 2011 04:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1314444483; bh=5irNefVlcrpAFj57Z2/RXeM2plx8yZkRceNOUjzAUPI=; l=4196; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=kOq/oTh/Q5R5OVVuGxJvY5+MBQCSSZZePmafb2BB2EvH1i6ZV1u82hscqmn6tvjD9 O3kpLGpfIblsyruJuHv0b3nCaBR7oMGMDxmVYatMR7VwPUY/jMIOqWtrdgr51a1fA+ PgZrSJgAUBastLbZ5axH3yF4hB4iob5REXnYQTic= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 27 Aug 2011 13:28:03 +0200 id 00000000005DC045.000000004E58D4C3.00003611 Message-ID: <4E58D4C2.6060209@tana.it> Date: Sat, 27 Aug 2011 13:28:02 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.20) Gecko/20110804 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: marf@ietf.org References: <20110827032617.7123.qmail@joyce.lan> In-Reply-To: <20110827032617.7123.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] draft-ietf-marf-reporting-discovery-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 27 Aug 2011 11:26:47 -0000 On 27/Aug/11 05:26, John Levine wrote: > In sec 5, it says you can identify the consumer domain by DKIM d=, > SMTP bounce address domain, or MTA rDNS. I'm wondering whether it > is a problem that they all funnel into _report. without > any way to tell the difference. If it mattered, I'd suggest adding > a tag in the record saying which sort of name the record applies > to, with multiple records if need be. +1, how about Discovery-Origin? However, I'm skeptical about MTA rDNS. It is not the same level of domain that one would expect in DKIM d= and the domain-part of an address. If we include host-X.example.com as a possible discovery domain, we should also allow helo-names. IME, admins won't bother defining _report.host-X.example.com for each host, so I'd drop them. > For feedback generators, I have no idea how I'm supposed to pick a > domain name to look up. If, say, I wanted feedback from Gmail, would > that be google.com? gmail.com? googlemail.com? The name of one of > their MX hosts? Any or all of the bazillion mail domains they host? > Something else? Good question. Where did you get "Gmail" from? :-) Perhaps, the following could be added, e.g. as a fourth paragraph, in section 5: A feedback consumer who wishes to receive feedback from a generator, may also query the domains it targets. For example, an MTA sending mail to user@example.com may want to query _report.example.org in order to ascertain under what conditions it can have generated feedback sent back to it. > In 5.1, I'd delete the rt= and ri= tags since I don't see how they > improve interoperability. If someone is inviting me to send them > abuse reports, I'm going to send them abuse reports, and the number of > reports will be limited by the amount of mail they send. They can > always ignore the ones they don't understand. Yeah, this conundrum transverses various reporting docs. I don't think we can afford to specify a different behavior for each report type. > For the r= tag, I don't understand why it's supposed to be able both > to accept ARF abuse reports and to respond to a subscription > verification request. Presumably the response is automated, since no > human is going to be looking through the stream of ARF for > subscriptions. Is there some yet to be defined protocol here? > > Also it might be better to make r= a URI rather than an email address, > so it can be a mailto: or an http: allowing POST. > > Why is there a gp=r policy but no rp=r policy? I accept random mail > to my abuse address, but for feedback senders I know, I treat their > ARFs differently (basically, I believe all of the latter and treat > them as unconditional unsubscribes.) I concur on the former point, but would prefer that r=, if given, be an email address, for ease of use. Perhaps, we could allow rp=r and specify that r= is /Optional, but MUST be defined unless rp=r/. The URI in ru= could provide for communicating a generator-specific email target address. If r is not given, only acknowledged generators can send feedback. > In 5.4, I would suggest specifically limiting the kind of URIs that > the fields can include, unless someone is prepared to explain what > to do if you see ru=nntp:news.example.com. How about fax:+12024562461? Currently, URIs are meant to be used interactively, so users can decide on their own. Perhaps, we might reserve some kind of URIs, e.g. http queries, for automated to-be-defined purposes. > Sec 9, security, the obvious problem is that a malicious sender can > publish "rp=o r=myenemy@somewhere.com" and indirectly mailbomb people. Should that be equivalent to a redirection? I mean, should _report.example.org. IN TXT "rp=o r=myenemy@somewhere.com" be considered equivalent to, say, _report.example.org. IN CNAME _report.somewhere.com? > The mention of subscription verification suggests there's supposed to > be some sort of handshake before turning on the cannon, but if it's > there, I've missed it. Verifying that somewhere.com wants feedback for example.org's spam looks like one of those automated to-be-defined purposes... jm2c From johnl@iecc.com Sat Aug 27 07:54:14 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD4821F8AAA for ; Sat, 27 Aug 2011 07:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.112 X-Spam-Level: X-Spam-Status: No, score=-111.112 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwVKCEVvFaZQ for ; Sat, 27 Aug 2011 07:54:13 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 5D64F21F8A7A for ; Sat, 27 Aug 2011 07:54:13 -0700 (PDT) Received: (qmail 67419 invoked from network); 27 Aug 2011 14:55:32 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 27 Aug 2011 14:55:32 -0000 Received: (qmail 13610 invoked from network); 27 Aug 2011 14:55:32 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 27 Aug 2011 14:55:32 -0000 Date: 27 Aug 2011 14:55:09 -0000 Message-ID: <20110827145509.96385.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <4E58D4C2.6060209@tana.it> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: vesely@tana.it Subject: Re: [marf] draft-ietf-marf-reporting-discovery-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 27 Aug 2011 14:54:14 -0000 >> any way to tell the difference. If it mattered, I'd suggest adding >> a tag in the record saying which sort of name the record applies >> to, with multiple records if need be. > >+1, how about Discovery-Origin? Seems a bit prolix when the other tags are r= and ru= but whatever >However, I'm skeptical about MTA rDNS. It is not the same level of >domain that one would expect in DKIM d= and the domain-part of an >address. If we include host-X.example.com as a possible discovery >domain, we should also allow helo-names. I can tell you from extensive experience that I find host rDNS useful for identifying the guilty party, and HELO useless since there is no way to tell whether the HELO has any connection to the actual sender. >Good question. Where did you get "Gmail" from? :-) Perhaps, the >following could be added, e.g. as a fourth paragraph, in section 5: > > A feedback consumer who wishes to receive feedback from a > generator, may also query the domains it targets. For example, an > MTA sending mail to user@example.com may want to query > _report.example.org in order to ascertain under what conditions it > can have generated feedback sent back to it. This scales very poorly. Having set up a variety of people on various shared commercial mail hosts, I can report that the host tells the customer what MX records to use, and the customer more or less painfully configures them into his DNS. The customers are not going to add _report records. I think that the MX is the best of a bad lot for identifying a report generator. The MX hosts are under the control of the actual mail system, and the number of MXes per system is reasonably small, at least compared to the number of mail domains they might host. >> In 5.4, I would suggest specifically limiting the kind of URIs that >> the fields can include, unless someone is prepared to explain what >> to do if you see ru=nntp:news.example.com. > >How about fax:+12024562461? Currently, URIs are meant to be used >interactively, so users can decide on their own. Some URIs are used interactively, some aren't. I know I would have very little interest in a feedback system that asked me to fax in the reports, or do anything other than mail or POST them. >> Sec 9, security, the obvious problem is that a malicious sender can >> publish "rp=o r=myenemy@somewhere.com" and indirectly mailbomb people. > >Should that be equivalent to a redirection? No, it might be real and it might not be. The point is that for this not to be a DDoS vector, there needs to be some way to validate the address before sending it reports. R's, John From vesely@tana.it Sun Aug 28 02:08:20 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F3A21F8A7B for ; Sun, 28 Aug 2011 02:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.628 X-Spam-Level: X-Spam-Status: No, score=-4.628 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtaoJdJCpie6 for ; Sun, 28 Aug 2011 02:08:19 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 22BD421F884C for ; Sun, 28 Aug 2011 02:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1314522577; bh=QPCLNyC3pR29UulL9TP+3+lMh1Ah2r2QOVvjyAynMEA=; l=1663; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=aKm6l74zuuX/fPsx5zFHSegscV4cXF2zMDzzou8YL6RwvtZV/HD5lzp1JjYs6i1z9 KTKREZ0ufcVPiWk6Ceq5r/ZVV8ZXtrt+w3yf525Jk60Ncwo9XEr0a1ZynlaFwcdt/o igJ44VjtM3MDScrAW55gXXRGDHYtmDmwKIp0MPIQ= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 28 Aug 2011 11:09:37 +0200 id 00000000005DC045.000000004E5A05D1.00006554 Message-ID: <4E5A05D2.1090305@tana.it> Date: Sun, 28 Aug 2011 11:09:38 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.20) Gecko/20110804 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: marf@ietf.org References: <20110827145509.96385.qmail@joyce.lan> In-Reply-To: <20110827145509.96385.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] draft-ietf-marf-reporting-discovery-01 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2011 09:08:20 -0000 On 27/Aug/11 16:55, John Levine wrote: >>> any way to tell the difference. If it mattered, I'd suggest adding >>> a tag in the record saying which sort of name the record applies >>> to, with multiple records if need be. >> >> +1, how about Discovery-Origin? > > Seems a bit prolix when the other tags are r= and ru= but whatever Oops, sorry John, I don't know why I was thinking of feedback fields. >>> Sec 9, security, the obvious problem is that a malicious sender can >>> publish "rp=o r=myenemy@somewhere.com" and indirectly mailbomb people. >> >> Should that be equivalent to a redirection? > > No, it might be real and it might not be. The point is that for this > not to be a DDoS vector, there needs to be some way to validate the > address before sending it reports. Perhaps, storing that in the DNS provides for easier verification than, say, an HTTP query. If example.org outsources report handling to example.com, the latter could publish a confirmation as example.org._report.example.com. CNAME _report.example.com. _report.example.com. TXT "rp=o r=service@example.com" or example.org._report.example.com. TXT "r=service+example.org@example.com" ; rp= retained from original record, or default. or example.org._report.example.com. CNAME _report.example.org. This way, a generator can confirm the external domain and fetch any relevant detail using a single extra query. In the latter example, the service accepts whatever settings its customer may define, but it can always revert to one of the former cases; that is, the real handler is in control of the target email address. Just an idea From msk@cloudmark.com Mon Aug 29 12:08:48 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A633121F8C88 for ; Mon, 29 Aug 2011 12:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.54 X-Spam-Level: X-Spam-Status: No, score=-104.54 tagged_above=-999 required=5 tests=[AWL=1.059, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLBlQ4qagmkg for ; Mon, 29 Aug 2011 12:08:47 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 535BA21F8B59 for ; Mon, 29 Aug 2011 12:08:47 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 29 Aug 2011 12:10:12 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 29 Aug 2011 12:10:11 -0700 Thread-Topic: [marf] I-D Action: draft-ordogh-spam-reporting-using-imap-00.txt Thread-Index: AcxknGIIBW4HH8MTQ/6k+MRpqVB/FAB4ZyYQ Message-ID: References: <6AAA768C4EF38B458F619FA367ACAB8352B6643A65@XCH115CNC.rim.net> <4E58B9DC.5020907@tana.it> In-Reply-To: <4E58B9DC.5020907@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ordogh-spam-reporting-using-imap-00.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2011 19:08:48 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Saturday, August 27, 2011 2:33 AM > To: Zoltan Ordogh > Cc: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ordogh-spam-reporting-using-imap-00= .txt >=20 > Hi Zoltan, > thank you so much for a long awaited IMAP extension!! >=20 > On 26/Aug/11 21:39, Zoltan Ordogh wrote: > > MARF is a good candidate, but I was not sure about the attendance > > of IMAP experts. So, I left it as an individual draft for now. >=20 > I think reporting mechanisms are the meat and potatoes of MARF. I > wish this draft be adopted by this WG. A co-chair moment, brought to you by the letters R, F and C: Handling an IMAP extension to enable browsers to do abuse reporting is outs= ide of our current charter. We would have to re-charter to include this wo= rk in order to adopt it as a working group item. We do have in our charter= the work of tracking SpamRep, but this didn't come out of the SpamRep WG a= t OMA. That's not impossible, of course, but it means discussion of adopting this = now is premature. If there are others in this group that feel this is worth the exercise of r= e-chartering and (most importantly) are willing to put time into editing th= e document and creating and testing implementations, please say so. -MSK, as co-chair