From internet-drafts@ietf.org Thu Sep 1 12:02: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 4480F21F98C1; Thu, 1 Sep 2011 12:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 wox1uqQ9tWAc; Thu, 1 Sep 2011 12:02:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A0421F98A7; Thu, 1 Sep 2011 12:02:26 -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.60 Message-ID: <20110901190226.29237.69126.idtracker@ietfa.amsl.com> Date: Thu, 01 Sep 2011 12:02:26 -0700 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-as-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: Thu, 01 Sep 2011 19:02:27 -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 : Creation and Use of Email Feedback Reports: An Applicabi= lity Statement for the Abuse Reporting Format (ARF) Author(s) : J.D. Falk Filename : draft-ietf-marf-as-00.txt Pages : 6 Date : 2011-09-01 RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This document describes one common method for utilizing this format for reporting at scale between large mailbox providers, and from large mailbox providers to other mail sending entities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-as-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-ietf-marf-as-00.txt From jdfalk-lists@cybernothing.org Thu Sep 1 12:17: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 DD60A21F999D for ; Thu, 1 Sep 2011 12:17:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAeVf5+YBt37 for ; Thu, 1 Sep 2011 12:17:48 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id E5B8721F9997 for ; Thu, 1 Sep 2011 12:17:47 -0700 (PDT) Received: from [192.168.11.44] (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 p81JJIAB002412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 1 Sep 2011 12:19:20 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p81JJIAB002412 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=fudge; t=1314904761; bh=2uzNijC1hF4I+/6bzMm/9NKV9/QJ6w/cL8Ty8IvLG G4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=CdgKN24PDXCp xCMk7JYkAqPD7uniCZmJ56i7Jb/YS+yV+1H8kxScw7ekR0ruhFBFbOqBIDT/9crm+Rq 9xgr4zvkpRkrLNWvkVZKsUyIo7Sba2zNztZ6SSkr0Sp6wvjK/ZSBHn+Qzp7LFl9Wpog ly6R7qskytJ4EnV9SD/4UOytk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: Date: Thu, 1 Sep 2011 12:19:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <37FD6B61-8C86-4E5E-83B2-892F2AF0AAE8@cybernothing.org> References: To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [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: Thu, 01 Sep 2011 19:17:49 -0000 On Aug 24, 2011, at 6:33 AM, Barry Leiba wrote: > ** 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. I could use some help with the ABNF, at which point I think the initial = protocol definition work will be complete -- but there still aren't any = known implementations, so I wouldn't feel comfortable calling the entire = effort finished at that point. My employer has some implementation plans, but we don't have a timeline = I can share at present -- and as the largest ARF generator = implementation, any changes to the existing system are kind of a big = deal. I'd love to see some smaller, more experimentally-minded = operators give it a try in the meantime. > ** 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. I think it's ready. > Finally, we have this one pending: >=20 > ** 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. I reposted it as draft-ietf-marf-as-00 (with a few minor changes) = earlier today. Looks like there's still some interest in discussing = whether to add additional use cases; my opinion is known, but it's a WG = document now so I'll bow to consensus. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions= From jdfalk-lists@cybernothing.org Thu Sep 1 12:21:21 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 6944821F925C for ; Thu, 1 Sep 2011 12:21:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZfCHpWl6y9a for ; Thu, 1 Sep 2011 12:21:20 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id C455B21F9259 for ; Thu, 1 Sep 2011 12:21:17 -0700 (PDT) Received: from [192.168.11.44] (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 p81JMmgi002473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 1 Sep 2011 12:22:50 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p81JMmgi002473 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=fudge; t=1314904970; bh=8I9phgp/ssOIW0TNYtjEhGdqxlEQM0yDj51d9X73k UQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=di0p00tIWmVG AgJroXEYOqZ41WCg/htIVZuPiQq0CqaUgTIZY7Jt/brTJtTUqHM6+6epsBDTk7sYMPo w+QW/2O+r4jcayBBwmSdWtsfbPwieHeG13zdW5Vj00dANJrwSh6EFvtAmU6rlSj4r8v Fi2t7rYIIZ1GtJRRqANlu2thI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: <20110824170824.DDF68F5808C@smtp.patriot.net> Date: Thu, 1 Sep 2011 12:22:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110824170824.DDF68F5808C@smtp.patriot.net> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) 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, 01 Sep 2011 19:21:21 -0000 On Aug 24, 2011, at 10:19 AM, 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. Do you have any examples of this type of functionality in MUAs available = today? > 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. I believe we covered that in marf-base, but I wouldn't be opposed to = saying it again. Can you suggest some appropriate language? -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From jdfalk-lists@cybernothing.org Thu Sep 1 12:31: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 DFC3621F9976 for ; Thu, 1 Sep 2011 12:31:09 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRHF6uGpLzqm for ; Thu, 1 Sep 2011 12:31:09 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id C6F4A21F9977 for ; Thu, 1 Sep 2011 12:31:08 -0700 (PDT) Received: from [192.168.11.44] (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 p81JWb2i002628 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 1 Sep 2011 12:32:41 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p81JWb2i002628 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=fudge; t=1314905561; bh=WeuSPkpN5v4N0XfDAnCQQgXMVfORzriZlzxD8FCB/ /Y=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=fjDSTQtQCqYv DaLYbV2OpxOTzjVxygEnejLA5BPEUSUWSIVQxe5qZX0iFCihmIig63RDf5yoLQW6Dch SFmxUPPc29cOlLbSArjz11jnPb+Kg2eD9wsNVL2BnalC8LHiMudRco7wJ8h/n7UWMoy ZRHZGUOpMV3VmXCQYNz+eM6cU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: Date: Thu, 1 Sep 2011 12:32:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <32B6C1DA-9863-4D97-90FE-8CB7750A24C1@cybernothing.org> References: <6AAA768C4EF38B458F619FA367ACAB8352B6643A65@XCH115CNC.rim.net> <4E58B9DC.5020907@tana.it> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) 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: Thu, 01 Sep 2011 19:31:10 -0000 On Aug 29, 2011, at 12:10 PM, Murray S. Kucherawy wrote: > If there are others in this group that feel this is worth the exercise = of re-chartering and (most importantly) are willing to put time into = editing the document and creating and testing implementations, please = say so. I think it's extremely relevant and plan to keep an eye on the work, but = it sounds to me as if most of the eventual software development effort = will involve IMAP rather than MARF, so I'd think the IMAP WG (if it = still exists) would be a more appropriate location. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From hfontana@ecertsystems.com Thu Sep 1 12:43: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 C8BC221F968E for ; Thu, 1 Sep 2011 12:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 RqYg54n3Dz3g for ; Thu, 1 Sep 2011 12:43:14 -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 0B26D21F963E for ; Thu, 1 Sep 2011 12:43:13 -0700 (PDT) Received: by pzk33 with SMTP id 33so6109963pzk.18 for ; Thu, 01 Sep 2011 12:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecertsystems.com; s=google; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:disposition-notification-to; bh=CFCHLzJVZPdVCWG/0vHd4nYOZxjSsNjXjU6vsrJ5efA=; b=mKg66x7j6KSxa7afdOuA5796VfLx6xrARv5KypTxss6dLnuEDdMQhK1lv98sofvbnz dJ3oZHA0W4b5rHLSuei7aJMyHHWcth+BLH6PlQMEZHLb4cmxjdnKuWjlucHdCKJuOBr8 X6Ci2ZjnjTBAHCXr0iZMRfU+xU8T861LZ6Rps= Received: by 10.68.14.68 with SMTP id n4mr587665pbc.254.1314906287672; Thu, 01 Sep 2011 12:44:47 -0700 (PDT) Received: from OwnerPC (99-116-250-186.lightspeed.irvnca.sbcglobal.net. [99.116.250.186]) by mx.google.com with ESMTPS id t6sm5090238pbg.4.2011.09.01.12.44.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Sep 2011 12:44:45 -0700 (PDT) From: "Hilda Fontana" To: "'Barry Leiba'" , "'Message Abuse Report Format working group'" References: In-Reply-To: Date: Thu, 1 Sep 2011 12:44:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJM9h4ps4AvYlPssqktuy9Frt+coZQ30pwg Content-Language: en-us Subject: Re: [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: Thu, 01 Sep 2011 19:43:14 -0000 As soon as the chair feedback is complete I'll post the -02 for the draft-ietf-marf-authfailure-report-01 Thanks H > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Barry Leiba > Sent: Wednesday, August 24, 2011 6:34 AM > To: Message Abuse Report Format working group > Subject: [marf] Working group status, and progress on the active documents > > 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 > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf From shmuel+gen@patriot.net Thu Sep 1 17:39:44 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 0594621F94B3 for ; Thu, 1 Sep 2011 17:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.757 X-Spam-Level: X-Spam-Status: No, score=-1.757 tagged_above=-999 required=5 tests=[AWL=0.842, 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 9mf3JKAC1SyG for ; Thu, 1 Sep 2011 17:39:43 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6D80821F949C for ; Thu, 1 Sep 2011 17:39:43 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.60]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id D8D59F58096 for ; Thu, 1 Sep 2011 20:31:08 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Thu, 01 Sep 2011 20:36:56 -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: <20110902003108.D8D59F58096@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, 02 Sep 2011 00:39:44 -0000 In , on 09/01/2011 at 12:22 PM, "J.D. Falk" said: >Do you have any examples of this type of functionality in MUAs >available today? I'm afraid not, but I believe that we should discuss the issue. I've got a tool that I use to analyze individual messages and collect whois data on hosts either in the headers or in URL's; it would be a SMOP to modify it to generate a MARF report. The user would have to know hown many leading Received header fields to skip. I'm willing to contribute the code[1] if it would help. >I believe we covered that in marf-base, but I wouldn't be opposed to >saying it again. Can you suggest some appropriate language? He's my first crack at it. In 2. Creating and Sending Reports, at end of paragraph 1: A Mailbox Provider that does not offer another mechanism should accept MARF reports from authenticated MSA users and may offer tools for generating those reports. As new paragraph: 5. MUA authors that provide for generating MARF reports SHOULD provide a "this is spam" option and MAY provide a "this is not spam" option. The number of Received header fields to skip and the target mailbox addresses should be configuration data tather than solicited at each use. Such reports should be sent only using SMTPAUTH. [1] Be warned, it's rapid protyping at its worst and really needs a redesign. -- 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 Thu Sep 1 18:41:44 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 278B021F9040 for ; Thu, 1 Sep 2011 18:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.025 X-Spam-Level: X-Spam-Status: No, score=-103.025 tagged_above=-999 required=5 tests=[AWL=-0.048, 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 VG+b2Pf7OFnB for ; Thu, 1 Sep 2011 18:41:43 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 965D121F9039 for ; Thu, 1 Sep 2011 18:41:43 -0700 (PDT) Received: by gxk19 with SMTP id 19so2278913gxk.31 for ; Thu, 01 Sep 2011 18:43:18 -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; bh=86jwh+zFKf4g2BiNsLhM0mXUwQUiUDBmv28wBrz61BQ=; b=jjf5Og66ZkQ8hcPnoJSNkaMOhPsWNMSfOkC67kuEN2ILUZw0MVOSmLef9vjWJstyma SrqhjiSZPmpzyD+9gyPuspD9BESzvdVNXUOp4slXCetpDkrUbCc2rU0gPtn/p8sk2d9a vjG7A63880vLY+V9h9PvUlJuteVXXX5GmuJyA= MIME-Version: 1.0 Received: by 10.236.183.164 with SMTP id q24mr2611603yhm.117.1314927798005; Thu, 01 Sep 2011 18:43:18 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.40.6 with HTTP; Thu, 1 Sep 2011 18:43:17 -0700 (PDT) In-Reply-To: <32B6C1DA-9863-4D97-90FE-8CB7750A24C1@cybernothing.org> References: <6AAA768C4EF38B458F619FA367ACAB8352B6643A65@XCH115CNC.rim.net> <4E58B9DC.5020907@tana.it> <32B6C1DA-9863-4D97-90FE-8CB7750A24C1@cybernothing.org> Date: Thu, 1 Sep 2011 21:43:17 -0400 X-Google-Sender-Auth: Sz6CqqdAWjVajr6wCxzkRQq1cVM Message-ID: From: Barry Leiba To: "J.D. Falk" Content-Type: text/plain; charset=ISO-8859-1 Cc: Message Abuse Report Format working group Subject: Re: [marf] 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, 02 Sep 2011 01:41:44 -0000 > it sounds to me as if most of the eventual software development effort will > involve IMAP rather than MARF, so I'd think the IMAP WG (if it still exists) > would be a more appropriate location. There's not currently an IMAP-related working group around, and there isn't likely to be one soon. Barry From shmuel+gen@patriot.net Thu Sep 1 20:43: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 6E80E21F94C0 for ; Thu, 1 Sep 2011 20:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.777, 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 YecVYM073TnR for ; Thu, 1 Sep 2011 20:43:41 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 95CC221F94BA for ; Thu, 1 Sep 2011 20:43:41 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.251]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 2298CF58095 for ; Thu, 1 Sep 2011 23:35:04 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Thu, 01 Sep 2011 21:07:10 -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: <20110902033505.2298CF58095@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, 02 Sep 2011 03:43:42 -0000 In , on 09/01/2011 at 12:22 PM, "J.D. Falk" said: >I believe we covered that in marf-base, but I wouldn't be opposed to >saying it again. Can you suggest some appropriate language? Whoops! I sent suggested language for an unrelated item. The test I suggest for this item is a new paragraph in 1. Introduction While it is desirable for network operators to accept complaints at abuse and Postmaster mailboxes in MARF format, they MUST continue to accept and process plain text abuse reports those mailboxes. -- 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 Fri Sep 2 12:01:55 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 72F4821F8CAF for ; Fri, 2 Sep 2011 12:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.025 X-Spam-Level: X-Spam-Status: No, score=-103.025 tagged_above=-999 required=5 tests=[AWL=-0.048, 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 UTCNS3qro8UQ for ; Fri, 2 Sep 2011 12:01:53 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEAC21F8C7B for ; Fri, 2 Sep 2011 12:01:53 -0700 (PDT) Received: by yxj17 with SMTP id 17so1684289yxj.31 for ; Fri, 02 Sep 2011 12:03:29 -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:content-type :content-transfer-encoding; bh=pD8LhtH+KunnfjRPss0jXqAg8knTqXlxI5LmphZfQEI=; b=YKASiVSH7Nn0oeqzKFsctii64vs2mC1eLdo1Z3qetPSs8vwx6hSefSLNz4VOIjRs7S 7EkPAylNaG3WI5iNoXyVp2LYlK0K8dG0Turtn7V/AGrCbgcydQ8owd+ux3Lsd3cIsqH2 Bcgq9jjAS9UG7vmLGcD7H/caKtFn5Sd7l35vI= MIME-Version: 1.0 Received: by 10.236.75.165 with SMTP id z25mr7540705yhd.68.1314990208919; Fri, 02 Sep 2011 12:03:28 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.40.6 with HTTP; Fri, 2 Sep 2011 12:03:28 -0700 (PDT) In-Reply-To: <20110824165134.C2ADDF5808C@smtp.patriot.net> References: <20110824165134.C2ADDF5808C@smtp.patriot.net> Date: Fri, 2 Sep 2011 15:03:28 -0400 X-Google-Sender-Auth: lbF-yGsWgWEVDtrhTwEQnPfxj0A Message-ID: From: Barry Leiba To: Message Abuse Report Format working group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [marf] Comments on 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: Fri, 02 Sep 2011 19:01:55 -0000 > The first paragraph of 9.3. =A0Privacy 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. Shmuel is absolutely right, and I think that first paragraph should be re-thought and re-formulated. A few thoughts on that: 1. Replacing the recipient's email address with an opaque token is reasonable advice. 2. But if the token is the same every time, so that the side processing the abuse reports can correlate different spam messages reported by the same user, that's a privacy leak. We've seen how "anonymized" search information can be used to identify the individual, and there are other effects here as well. 3. It's not valid to assume that the recipient has no relationship to the spam sender, and there might very well be privacy issues involved with associating the sender to the recipient. There are many ways in which one can have an established relationship with someone without having given them permission to send marketing (or other) email. Let's do some re-thinking here. Barry, as participant (but my chair hat is very near) From vesely@tana.it Sat Sep 3 05:38:00 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 2341821F8C61 for ; Sat, 3 Sep 2011 05:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.631 X-Spam-Level: X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[AWL=0.088, 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 MSOHaonLDn75 for ; Sat, 3 Sep 2011 05:37:58 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id ADEFF21F8C79 for ; Sat, 3 Sep 2011 05:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1315053571; bh=QGt/Xqa++dQ/dc2ovauNUvYBD4AJzPcS+DOnl6A280Y=; l=1519; h=Message-ID:Date:From:MIME-Version:To:Content-Transfer-Encoding; b=Au9jdD/uiueZnuVQ5GjcAEXv0mVBS1/UWyOhqeGG6IGI+HTlP9WUxJBu1Ki2gSLFb 3YYRYj7B2Fl3SsiSIBxF2ngxDwEOkXWnpaMsUXByQ6UbKe3ItRZpEq4c5a20pOp4wg IMglLP9NhGz4nWGOuGIYjJw5YnaYFMV1kpaARCRM= 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, 03 Sep 2011 14:39:30 +0200 id 00000000005DC039.000000004E622002.00001E86 Message-ID: <4E622001.8010904@tana.it> Date: Sat, 03 Sep 2011 14:39:29 +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] Fwd: I-D Action: draft-vesely-marf-abuse-reporting-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, 03 Sep 2011 12:38:00 -0000 I posted this, about issues that current WG drafts cannot address. Does the WG want to adopt it as a WG draft, and discuss it? TIA for your time. -------- Original Message -------- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-vesely-marf-abuse-reporting-00.txt Date: Sat, 03 Sep 2011 05:22:43 -0700 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Abuse Reporting Author(s) : Alessandro Vesely Filename : draft-vesely-marf-abuse-reporting-00.txt Pages : 8 Date : 2011-09-03 This documents covers issues of spam reporting by the general public. The Abuse Reporting Format (ARF) was originally developed for use by large operators. However, abuse reporting is also useful for medium and small operators. The need to automate abuse reporting originates from the volume of spam, not the size of the operators. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vesely-marf-abuse-reporting-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-vesely-marf-abuse-reporting-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 From vesely@tana.it Sat Sep 3 10:37:35 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 449B921F8B2F for ; Sat, 3 Sep 2011 10:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.633 X-Spam-Level: X-Spam-Status: No, score=-4.633 tagged_above=-999 required=5 tests=[AWL=0.086, 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 Qba7gIljk4Sy for ; Sat, 3 Sep 2011 10:37:34 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4C521F8B2E for ; Sat, 3 Sep 2011 10:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1315071550; bh=GJ67/9JQe7681R7R0eop9t4N9B8VHrjDssLXqS3OzSk=; l=2782; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=jO30xMc3wt5UnlM3hKPE5stKtpbC918yU7Dh9FvO7n+0e7jzcNhCk+hUn1YzPj0VJ LhlXzRHDqqrq6+J3CjGCwRGGSWIwVkXWMqojjgrJM+CJDuQd1GKgR3RGIj3X1Lovv8 PfIBSBIOQPF5wJezpWecCQrtzAyBpLODrg+JFBrA= 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, 03 Sep 2011 19:39:10 +0200 id 00000000005DC039.000000004E62663E.00007DBC Message-ID: <4E62663D.4000002@tana.it> Date: Sat, 03 Sep 2011 19:39:09 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.21) Gecko/20110830 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: marf@ietf.org References: <20110824165134.C2ADDF5808C@smtp.patriot.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [marf] Comments on 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, 03 Sep 2011 17:37:35 -0000 On 02/Sep/11 21:03, Barry Leiba wrote: >> 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. > > Shmuel is absolutely right, and I think that first paragraph should be > re-thought and re-formulated. A few thoughts on that: > > 1. Replacing the recipient's email address with an opaque token is > reasonable advice. Yes, but it's not always required, otherwise we'd have recommended it in marf-base. > 2. But if the token is the same every time, so that the side > processing the abuse reports can correlate different spam messages > reported by the same user, that's a privacy leak. We've seen how > "anonymized" search information can be used to identify the > individual, and there are other effects here as well. I agree this is an issue, but keeping the same token is recommended by the marf-redaction draft. Perhaps, automatic reporting from spam traps needs some randomization. > 3. It's not valid to assume that the recipient has no relationship to > the spam sender, and there might very well be privacy issues involved > with associating the sender to the recipient. There are many ways in > which one can have an established relationship with someone without > having given them permission to send marketing (or other) email. I see two ways out of this. One is that recipients should first try to solve the issue themselves by contacting the sender directly (e.g. opting out), and only resort to abuse reporting after breaking any relationship with the sender. This is compatible with reporting abuse to collaborative pools à la Vipul's Razor. The other is to report spam only in case there is a certain confidentiality, so that there is no need to redact, except for formally obeying some over-restrictive law in some cases. This is only compatible with feedback loops where subscriptions are only granted subject to suitable conditions. > Let's do some re-thinking here. Let me point to the bracketed sentence in 9.3 [Should these be moved to a BCP?] and match that with section 7 of my recently posted draft: TBD, possibly repeat privacy considerations from other marf drafts. > Barry, as participant (but my chair hat is very near) Gosh, expressing a role as a distance from the relevant hat makes a boolean isomorphic to real numbers... I like that, I'd also apply for a fuzzy charter :-) From shmuel+gen@patriot.net Sat Sep 3 19:36:06 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 A41A221F84EB for ; Sat, 3 Sep 2011 19:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.722, 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 j202c-FJoIO1 for ; Sat, 3 Sep 2011 19:36:06 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0203621F883A for ; Sat, 3 Sep 2011 19:36:05 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.218]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 2FA43F58095 for ; Sat, 3 Sep 2011 22:27:30 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Sat, 03 Sep 2011 22:38:32 -0400 To: Message Abuse Report Format working group In-Reply-To: <4E62663D.4000002@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: <20110904022731.2FA43F58095@smtp.patriot.net> Subject: Re: [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: Sun, 04 Sep 2011 02:36:06 -0000 In <4E62663D.4000002@tana.it>, on 09/03/2011 at 07:39 PM, Alessandro Vesely said: >I see two ways out of this. One is that recipients should first try >to solve the issue themselves by contacting the sender directly (e.g. >opting out), I disagree; IMHO the recipient of spam should always report it to the sender's provider or upstreams. >and only resort to abuse reporting after breaking any >relationship with the sender. Throwing out products that you've already payed for? Not asking for repairs when it's still under warranty? Why should the recipient be penalized? OTOH, you can bet your sweet bippy that they don't get any new business from me ;-) -- 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 Sat Sep 3 22:43:36 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 A096221F8AAA for ; Sat, 3 Sep 2011 22:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.511 X-Spam-Level: X-Spam-Status: No, score=-103.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 l22uoa12-j+L for ; Sat, 3 Sep 2011 22:43:36 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 27FFA21F8A57 for ; Sat, 3 Sep 2011 22:43:36 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 3 Sep 2011 22:45:16 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Sat, 3 Sep 2011 22:45:15 -0700 Thread-Topic: [marf] Fwd: I-D Action: draft-vesely-marf-abuse-reporting-00.txt Thread-Index: AcxqNo1wZ6G+RflbTleO7kVAHmUvwAAjvoiQ Message-ID: References: <4E622001.8010904@tana.it> In-Reply-To: <4E622001.8010904@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] Fwd: I-D Action: draft-vesely-marf-abuse-reporting-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: Sun, 04 Sep 2011 05:43:36 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Saturday, September 03, 2011 5:39 AM > To: Message Abuse Report Format working group > Subject: [marf] Fwd: I-D Action: draft-vesely-marf-abuse-reporting-00.txt >=20 > I posted this, about issues that current WG drafts cannot address. >=20 > Does the WG want to adopt it as a WG draft, and discuss it? >=20 > TIA for your time. Hi Alessandro, Thanks for the draft. It's a long weekend here so I suspect a lot of folks= in North America won't get to this until the middle of next week. That in= cludes me; I haven't read all of it yet and won't for a few more days. Based on your Abstract alone, I'm wondering: Does this introduce material n= ot covered by http://datatracker.ietf.org/doc/draft-jdfalk-maawg-cfblbcp/ ? -MSK (as participant for the moment) From shmuel+gen@patriot.net Sun Sep 4 08:59:40 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 6217321F8663 for ; Sun, 4 Sep 2011 08:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=0.674, 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 Czhg0gjOohIg for ; Sun, 4 Sep 2011 08:59:39 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 793B421F85F2 for ; Sun, 4 Sep 2011 08:59:39 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.245]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id AF00AF5808A for ; Sun, 4 Sep 2011 11:51:07 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Sun, 04 Sep 2011 11:55:12 -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: <20110904155107.AF00AF5808A@smtp.patriot.net> Subject: [marf] draft-vesely-marf-abuse-reporting-00 comments 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, 04 Sep 2011 15:59:40 -0000 4. Forwarding Abuse Reports From Local Users Shouldn't the forwarding be to the abuse team of the source IP address in addition to the abuse team of an authenticated sending domain? Also, shouldn't the fallback be to use the abuse team of the source IP address rather than the abuse team of an unauthenticated sending domain? 5. Receiving Abuse Reports From Other Mailbox Providers I strongly disagree with "The obvious correction for an acknowledged policy contravention is to remove the email address of the original recipient from whatever storage it was retrieved from for sending the reported message, including mailing lists." The obvious correction is to remove *all* addresses for which consent was not given, not just to listwash. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From vesely@tana.it Mon Sep 5 01:01:45 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 1A6DF21F8561 for ; Mon, 5 Sep 2011 01:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.634 X-Spam-Level: X-Spam-Status: No, score=-4.634 tagged_above=-999 required=5 tests=[AWL=0.085, 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 GEy9yEqPfMKq for ; Mon, 5 Sep 2011 01:01:44 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC8C21F85A3 for ; Mon, 5 Sep 2011 01:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1315209805; bh=3wvduSBB7WWCkvizpaIzuTXWV4usaX0ulqgMT51MPnE=; l=1844; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=aRGHKXyeSXlKt8zB4IYH6d8wPqdUsNofPfpSKAhvxNo6sbR9gyaY9Z+KU+AiX+NRI S4yVIPXhaZ6ATDvv97gDjdAdMATYV/w0lRyrWLDOWYPI91W5169Curne6hGqccFKJr +L69KKKqyhw+pSqkxCimnu9MnBh0zqH68bQyu2wM= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 05 Sep 2011 10:03:25 +0200 id 00000000005DC033.000000004E64824D.000046AF Message-ID: <4E64824E.3020003@tana.it> Date: Mon, 05 Sep 2011 10:03:26 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.21) Gecko/20110830 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: marf@ietf.org References: <20110904155107.AF00AF5808A@smtp.patriot.net> In-Reply-To: <20110904155107.AF00AF5808A@smtp.patriot.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] draft-vesely-marf-abuse-reporting-00 comments 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, 05 Sep 2011 08:01:45 -0000 On 04/Sep/11 17:55, Shmuel (Seymour J.) Metz wrote: > 4. Forwarding Abuse Reports From Local Users > > Shouldn't the forwarding be to the abuse team of the source IP address > in addition to the abuse team of an authenticated sending domain? A very interesting question. I didn't dare recommend that, as it would amount to two messages (or more, if targeting also higher level allocations) for each abuse report. It would be a bit better to send a report to the IP team and have them forward it to the domain, but not all ISPs would be willing to cooperate. Perhaps, MPs can realize whether reporting abuse to a given domain sorts any effect, and switch to reporting to the IP team as soon as it is clear that the domain does not react. > Also, shouldn't the fallback be to use the abuse team of the source IP > address rather than the abuse team of an unauthenticated sending > domain? Absolutely, if there is an abuse team for the IP. > 5. Receiving Abuse Reports From Other Mailbox Providers > > I strongly disagree with "The obvious correction for an acknowledged > policy contravention is to remove the email address of the original > recipient from whatever storage it was retrieved from for sending the > reported message, including mailing lists." The obvious correction is > to remove *all* addresses for which consent was not given, not just to > listwash. Yeah, but since we don't know whether consent was actually given, we cannot assume they do. Even in countries where consent is mandatory, mailbox providers are not entitled to collect list subscriptions on behalf of their users. That way, users are confined to annotate on paper whom the gave consent for what, with the sole computer support of possible monthly reminders: a quite ineffective "time-distributed" database... From johnl@iecc.com Mon Sep 5 09:31:33 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 8DA3321F8532 for ; Mon, 5 Sep 2011 09:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.382 X-Spam-Level: X-Spam-Status: No, score=-110.382 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_05=-1.11, 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 eM7jtZw-4Ikp for ; Mon, 5 Sep 2011 09:31:33 -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 CE72C21F8515 for ; Mon, 5 Sep 2011 09:31:32 -0700 (PDT) Received: (qmail 7146 invoked from network); 5 Sep 2011 16:33:16 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 5 Sep 2011 16:33:16 -0000 Received: (qmail 37054 invoked from network); 5 Sep 2011 16:33:16 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 5 Sep 2011 16:33:16 -0000 Date: 5 Sep 2011 16:32:54 -0000 Message-ID: <20110905163254.68202.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <20110904155107.AF00AF5808A@smtp.patriot.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] draft-vesely-marf-abuse-reporting-00 comments 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, 05 Sep 2011 16:31:33 -0000 In article <20110904155107.AF00AF5808A@smtp.patriot.net> you write: >4. Forwarding Abuse Reports From Local Users > >Shouldn't the forwarding be to the abuse team of the source IP address >in addition to the abuse team of an authenticated sending domain? ... Since we're writing a standard for interoperability, not a BCP for abuse desks, I don't think we should tell people what to do with their reports beyond general advice to pass them along to responsible parties insofar as they can. Having run abuse.net for over a decade, I can assure you that identifying the best place to send reports, whether keyed on domains on or IP addresses, is a black art and not something you can put in a standard. There are plenty of heuristics and guesses, but no algorithm. R's, John From shmuel+gen@patriot.net Mon Sep 5 18:39:58 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1A3D21B60AF7 for ; Mon, 5 Sep 2011 18:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.251 X-Spam-Level: X-Spam-Status: No, score=-0.251 tagged_above=-999 required=5 tests=[AWL=-1.321, BAYES_50=0.001, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFOCc-0FNZBc for ; Mon, 5 Sep 2011 18:39:57 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfc.amsl.com (Postfix) with ESMTP id A40D11B60AED for ; Mon, 5 Sep 2011 18:39:53 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.159]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 92798F58093 for ; Mon, 5 Sep 2011 21:29:35 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Mon, 05 Sep 2011 10:13:10 -0400 To: marf@ietf.org In-Reply-To: <4E64824E.3020003@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: <20110906012935.92798F58093@smtp.patriot.net> Subject: Re: [marf] draft-vesely-marf-abuse-reporting-00 comments 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: Tue, 06 Sep 2011 01:39:58 -0000 In <4E64824E.3020003@tana.it>, on 09/05/2011 at 10:03 AM, Alessandro Vesely said: >Yeah, but since we don't know whether consent was actually given, we >cannot assume they do. Understood, but we cam certainly suggest that they investigate instead of listwashing. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From shmuel+gen@patriot.net Mon Sep 5 18:49:55 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2822A1B60B0C for ; Mon, 5 Sep 2011 18:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.455 X-Spam-Level: X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[AWL=-0.456, BAYES_50=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMV6RGChIkOU for ; Mon, 5 Sep 2011 18:49:54 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfc.amsl.com (Postfix) with ESMTP id 8FB201B60AF3 for ; Mon, 5 Sep 2011 18:49:54 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.159]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 8545BF58083 for ; Mon, 5 Sep 2011 21:39:30 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Mon, 05 Sep 2011 21:51:29 -0400 To: marf@ietf.org In-Reply-To: <20110905163254.68202.qmail@joyce.lan> 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: <20110906013934.8545BF58083@smtp.patriot.net> Subject: Re: [marf] draft-vesely-marf-abuse-reporting-00 comments 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: Tue, 06 Sep 2011 01:49:55 -0000 In <20110905163254.68202.qmail@joyce.lan>, on 09/05/2011 at 04:32 PM, "John Levine" said: >Having run abuse.net for over a decade, I can assure you that >identifying the best place to send reports, whether keyed on domains >on or IP addresses, is a black art and not something you can put in a >standard. It's already there. I'm questioning the current wording. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From vesely@tana.it Tue Sep 6 01:54: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 0485321F8538 for ; Tue, 6 Sep 2011 01:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.636 X-Spam-Level: X-Spam-Status: No, score=-4.636 tagged_above=-999 required=5 tests=[AWL=0.083, 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 0SEoACzPth4q for ; Tue, 6 Sep 2011 01:54:06 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 476BE21F8532 for ; Tue, 6 Sep 2011 01:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1315299344; bh=+/8Wy9jhF5OcqTxbfEYqyHv8c1E1lypseSC0avOsnE0=; l=552; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=B4hD7l+aG1rC9d4u78C07RsGDRnSJC8yBfzmwttN9zOmKPsEEQv9bcIi7oyl1mIAk XNABemJ3asPO0X0gTU2S50Ze5FSOxAKuamoW+AvPzxLPqrNSTSvD5QB2j8sWC+Hrcl 6vAs2KNz4YkQl+JaOlAAPXS/Kn65V3cYb7EAnitI= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 06 Sep 2011 10:55:44 +0200 id 00000000005DC039.000000004E65E010.000050CD Message-ID: <4E65E011.9000101@tana.it> Date: Tue, 06 Sep 2011 10:55:45 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.21) Gecko/20110830 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: marf@ietf.org References: <20110906012935.92798F58093@smtp.patriot.net> In-Reply-To: <20110906012935.92798F58093@smtp.patriot.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] draft-vesely-marf-abuse-reporting-00 comments 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, 06 Sep 2011 08:54:07 -0000 On 05/Sep/11 16:13, Shmuel (Seymour J.) Metz wrote: > In <4E64824E.3020003@tana.it>, on 09/05/2011 > at 10:03 AM, Alessandro Vesely said: > >>Yeah, but since we don't know whether consent was actually given, we >>cannot assume they do. > > Understood, but we can certainly suggest that they investigate instead > of listwashing. You mean adding something like An abuse team may need to investigate whether email addresses are stored legitimately on their customer's systems, or if any malware is running there ? From zordogh@rim.com Tue Sep 6 08:55: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 1911F21F8C48 for ; Tue, 6 Sep 2011 08:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.286 X-Spam-Level: X-Spam-Status: No, score=-4.286 tagged_above=-999 required=5 tests=[AWL=-1.383, BAYES_00=-2.599, MANGLED_SPAM=2.3, 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 TMJaHCEHuXFD for ; Tue, 6 Sep 2011 08:55:12 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 02EB721F8C30 for ; Tue, 6 Sep 2011 08:55:11 -0700 (PDT) X-AuditID: 0a412830-b7badae000002c2d-75-4e6642c15195 Received: from XHT106CNC.rim.net (xht106cnc.rim.net [10.65.22.53]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 8C.1D.11309.1C2466E4; Tue, 6 Sep 2011 15:56:49 +0000 (GMT) Received: from XCH115CNC.rim.net ([fe80::80ac:da43:d0fd:dcae]) by XHT106CNC.rim.net ([fe80::218f:6cb:a58:2a01%11]) with mapi; Tue, 6 Sep 2011 11:56:57 -0400 From: Zoltan Ordogh To: Alessandro Vesely Date: Tue, 6 Sep 2011 11:56:56 -0400 Thread-Topic: [marf] I-D Action: draft-ordogh-spam-reporting-using-imap-00.txt Thread-Index: AcxknGFkc31cUpEDTlWyZvpcoElRlwICxm2g Message-ID: <6AAA768C4EF38B458F619FA367ACAB8352B6829792@XCH115CNC.rim.net> 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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRmVeSWpSXmKPExsXC5ShmqnvQKc3P4Mg6A4vr656yW0y8+5PF gcljyZKfTB4ndvEGMEU1MNok5uXllySWpCqkpBYn2yr5pKYn5igEFGWWJSZXKrhkFifnJGbm phYpKWSm2CqZKCkU5CQmp+am5pXYKiUWFKTmpSjZcSlgABugssw8hdS85PyUzLx0WyXPYH9d CwtTS11DJTtdJJDwjztjwtv4gh96FRfXXGVvYHys2sXIySEhYCKx5M9fRghbTOLCvfVsXYxc HEICPUwS65+tYoZwFjBKfDj2FKiKg4NNQFViztVYkAYRATWJs2vnMoHYzALKEltOvwUrYRFQ kXg/JxIkLCzgK3F0/12wsIhAgMSN8yIQnUYSy69uYAGxeQW8JN6dn88KsWkjo8T2H4/YQRKc AuoSDftbwWxGoNu+n1oDtUpc4taT+UwQNwtILNlznhnCFpV4+fgfK0S9qMSd9vWMEPU6Egt2 f2KDsLUlli18zQyxWFDi5MwnLBMYxWYhGTsLScssJC2zkLQsYGRZxSiYm1FsYGaYnJesV5SZ q5eXWrKJEZwgNAx2ME7Yq3WIUYCDUYmH96pFmp8Qa2JZcWXuIUYJDmYlEV4tfqAQb0piZVVq UX58UWlOavEhRgtgwE1kluJOzgcmr7ySeGMDAxSOkjhvmLSBn5BAOjAZZaemFqQWwbQycXBK NTBa8R7snShbdFm/kmcb57Jfiz/F/jHTdT7wX2/BoTkyW7lOX82Iu5XvFXXYYMdcjo/Xdi43 2Pr4kodnw7pHl5QOR3z21mRdn681e+4bjzbWO5P0zzo95TrZxpJrWhwnuyTs0XMZ901dsT0u d32aoxJ2BrNl7fhxIubwhBVPt89acn7nEreJRTdfKbEUZyQaajEXFScCAFABBtopAwAA 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: Tue, 06 Sep 2011 15:55:13 -0000 Hi Alessandro, Thank you for your feedback. > I think reporting mechanisms are the meat and potatoes of MARF. I > wish this draft be adopted by this WG. I certainly hope so, especially because there is no active IMAP-related work= ing group at the moment to progress this draft. There should be a liaison st= atement coming from OMA EVVM soon, seeking 'home' for the draft. I - and may= be I can speak for the rest of the OMA EVVM group here - would be glad if th= e MARF group would take it. More about this later once the liaison statement= came through. > 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. Well, yes and no. We do not define 'abuse' and 'other' in our draft: - 'Abuse' is more or less "default" for all spam. Every single message one= reports is a spam, so we decided to support including only additional infor= mation that would detail the nature of the spam. - 'Other' does not make much sense for a spam-only reporting mechanism (whi= ch our command is). I've considered reusing them, but I decided not to because I would have to e= xplain in the draft that 'abuse' and 'other' are not used, while fraud maps= to phishing and virus maps to malware. By the way, how come you are not naming these phishing and malware? I mean, fraud is only one specific type of phishing while virus is only one= specific type of malware. Do you intend to expand the list with all possible sub-types? I kept it simple in our draft because most users don't even understand the h= igh-level types. > 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. We are trying to come up with a keyword format that would allow us storing t= he reason and the location of the spam. This is a work-in-progress in OMA EV= VM, we might come back with keyword proposals/registrations once we came to= agreement in OMA EVVM. I decided not to include any keywords in the draft on purpose. > 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? Well, yes, the client can identify a virus, an ill-willed script, etc and re= port it. But, in my opinion the user will be the primary source for spam reports; ult= imately is the user that decides what he considers a spam. One man's treasur= e is another man's rubbish. The user should be able to indicate which messag= e he considers a spam and why. Naturally, header fields will be more or less= limited to what the user can normally see: sender, subject field. In additi= on, the user should be able to indicated which part of the message is a spam= (which body). While this does not carry much meaning to the user, it would= greatly improve the accuracy of heuristic spam filters. > 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. I was not sure whether I should keep these or drop these. You see, this specification was going to be part of the OMA EVVM specs, but= the group decided to go with IETF because this is the "natural home" for IM= AP extensions. Consider the OMAEVVM10s a leftover for now, we will follow up= on this once the keywords in OMA has been sorted out. > 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 The reason it was included is that OMA EVVM would like to use the SpamRep En= abler to deal with spam, specifically. I agree that making it informational is not going to change that, so I took= a note here to move it to the informational section. Expect it in the next= revision of the draft. > 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. Yes, this is the intent. The more generic, the better. We've been working with SpamRep only thus far in OMA EVVM. Could you put this into words that I could include in the draft? What is the security issue with triggering the server's action accidentally? Thank you for your comments, Alessandro! --------------------------------------------------------------------- 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 shmuel+gen@patriot.net Tue Sep 6 09:53:33 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 208FD21F8C31 for ; Tue, 6 Sep 2011 09:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=0.632, 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 uIFjshfB7XTS for ; Tue, 6 Sep 2011 09:53:32 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 81AE321F8C30 for ; Tue, 6 Sep 2011 09:53:32 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.204]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 8BF26F5808A for ; Tue, 6 Sep 2011 12:45:01 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Tue, 06 Sep 2011 12:15:15 -0400 To: marf@ietf.org In-Reply-To: <4E65E011.9000101@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: <20110906164502.8BF26F5808A@smtp.patriot.net> Subject: Re: [marf] draft-vesely-marf-abuse-reporting-00 comments 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: Tue, 06 Sep 2011 16:53:33 -0000 In <4E65E011.9000101@tana.it>, on 09/06/2011 at 10:55 AM, Alessandro Vesely said: >You mean adding something like > An abuse team may need to investigate whether email addresses are > stored legitimately on their customer's systems, or if any malware > is running there Yes. -- 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 iesg-secretary@ietf.org Thu Sep 8 06:51: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 C691E21F8BA0; Thu, 8 Sep 2011 06:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 dkyQAh6Pfutm; Thu, 8 Sep 2011 06:51:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1FD21F8997; Thu, 8 Sep 2011 06:51:03 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110908135103.3226.98306.idtracker@ietfa.amsl.com> Date: Thu, 08 Sep 2011 06:51:03 -0700 Cc: marf@ietf.org Subject: [marf] Last Call: (Email Feedback Report Type Value : not-spam) to Proposed Standard X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 13:51:05 -0000 The IESG has received a request from the Messaging Abuse Reporting Format WG (marf) to consider the following document: - 'Email Feedback Report Type Value : not-spam' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-09-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a new Abuse Reporting Format (ARF) feedback report type value: "not-spam". It can be used to report a message that was mistakenly marked as spam. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-marf-not-spam-feedback/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-marf-not-spam-feedback/ No IPR declarations have been submitted directly on this I-D. From sm@resistor.net Thu Sep 8 07:41: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 C8E4C21F8498; Thu, 8 Sep 2011 07:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 XUBvpp0itXCx; Thu, 8 Sep 2011 07:41:47 -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 5F99621F84D1; Thu, 8 Sep 2011 07:41:47 -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 p88EhVAQ000515; Thu, 8 Sep 2011 07:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1315493019; bh=dD/nhTOiDkHuFUqXO9nkxQeE3IEx38u59gkWsupDwhQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=jbKZUD+eeERNqEM2rtzX3bijEBi/TZ2Whi3iMSzehrhVsuMr2Dmsd2PZpj5tSyN7D aOH2pTqL8IIK2Qt9bGHnm+jkrPGyygB1PRMHVZkDuxJ0/QqPSj36CJ+Xhz1ULxSzDj pq4ZD+rXx68rOQrlvkAHGIwCqEoU4KtPvZNemHdA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1315493019; bh=dD/nhTOiDkHuFUqXO9nkxQeE3IEx38u59gkWsupDwhQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=hB9Gb1bV9HX36NhuyO3lJKEgXHPE0xa7Ng9lBaUQVjn3FMig588j40yS/ZnhxvDko ABEnLACGA87e3ESWVvnuMEhGgmzvwNgLp1JqFuxAXA2gvWGZgp6NG0nqUEWEyNcqGy G4TXAELsldttH8nvQglOG9j5bPcQz/lWibx2EMwo= Message-Id: <6.2.5.6.2.20110908073526.0a173a08@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 08 Sep 2011 07:42:12 -0700 To: ietf@ietf.org From: SM In-Reply-To: <20110908135103.3226.98306.idtracker@ietfa.amsl.com> References: <20110908135103.3226.98306.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] Last Call: (Email Feedback Report Type Value : not-spam) to Proposed Standard 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, 08 Sep 2011 14:41:51 -0000 At 06:51 08-09-2011, The IESG wrote: >The IESG has received a request from the Messaging Abuse Reporting Format >WG (marf) to consider the following document: >- 'Email Feedback Report Type Value : not-spam' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2011-09-22. Exceptionally, comments may be I read the document. As an editorial nit, Section 1.2 (terminology) seems superfluous given that there is only one optional requirement. In the example in Section 3, I suggest referencing RFC 5965 or pointing to the authoritative source. Regards, -sm From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Thu Sep 8 08:19: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 ED37821F8696 for ; Thu, 8 Sep 2011 08:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.955 X-Spam-Level: X-Spam-Status: No, score=-102.955 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 3VfAaU8h4vYU for ; Thu, 8 Sep 2011 08:19:37 -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 625C721F85EF for ; Thu, 8 Sep 2011 08:19:37 -0700 (PDT) Received: by gyd12 with SMTP id 12so830716gyd.31 for ; Thu, 08 Sep 2011 08:21:29 -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 :content-type; bh=8Tc85AwpzoPEVu66HUN2rYMOdsVapNx8INt4+BUP2uM=; b=XxF3P79DqKrnJpYmwJBrG+KNKBPU6M4LBAhHzCh8H78Y4wg6uctqNVVwYbtNQn5sUM l9dpNyx+GDn+GhnYNNZPrRPV7jq42F7Eu4+CQEq1cQ0aASAINp3m6UlLtfGkgnsxnvtY CgDiQM1/4OO4XN/R9CdAD1gnCZ3BY8wNIfSh8= Received: by 10.68.0.104 with SMTP id 8mr1259699pbd.381.1315495289323; Thu, 08 Sep 2011 08:21:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.101.15 with HTTP; Thu, 8 Sep 2011 08:20:49 -0700 (PDT) In-Reply-To: <20110908135103.3226.98306.idtracker@ietfa.amsl.com> References: <20110908135103.3226.98306.idtracker@ietfa.amsl.com> From: Frank Ellermann Date: Thu, 8 Sep 2011 17:20:49 +0200 Message-ID: To: marf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [marf] Last Call: (Email Feedback Report Type Value : not-spam) to Proposed Standard 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, 08 Sep 2011 15:19:38 -0000 On 8 September 2011 15:51, The IESG wrote: > http://datatracker.ietf.org/doc/draft-ietf-marf-not-spam-feedback/ Hi, 2.5 nits not important enough for the general list: * The example uses in the first part. This page still points to an ARF draft published in 2008. The example should use , folks reading the first part need to know that this is an RFC before they press DEL. Once that's clear another link to MIPA is fine. * The DKIM signature won't help if the Return-Path is empty (as discussed in RFC 5965) and the SPF HELO result is FAIL; maybe add a note that an SPF PASS result would be ideal. * The third part in the example is obviously truncated. RFC 5965 says that it SHOULD be the complete mail, RFC 3462 and 3462bis say that reporting only a portion of the original mail is okay. Please add an explanation why your example ignored the SHOULD. -Frank From internet-drafts@ietf.org Thu Sep 8 19:16:19 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 D93C821F86EA; Thu, 8 Sep 2011 19:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 4FDSIriaXmDI; Thu, 8 Sep 2011 19:16:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8AF21F84BB; Thu, 8 Sep 2011 19:16:18 -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.60 Message-ID: <20110909021618.27975.41945.idtracker@ietfa.amsl.com> Date: Thu, 08 Sep 2011 19:16:18 -0700 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-authfailure-report-02.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, 09 Sep 2011 02:16:19 -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-02.txt Pages : 19 Date : 2011-09-08 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-02.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-02.txt From msk@cloudmark.com Fri Sep 9 10:31: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 C73FB21F85C0 for ; Fri, 9 Sep 2011 10:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.511 X-Spam-Level: X-Spam-Status: No, score=-103.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 ImFEbEfXlOk7 for ; Fri, 9 Sep 2011 10:31: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 59CCE21F857D for ; Fri, 9 Sep 2011 10:31: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, 9 Sep 2011 10:33:09 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Fri, 9 Sep 2011 10:33:08 -0700 Thread-Topic: [marf] Fwd: I-D Action: draft-vesely-marf-abuse-reporting-00.txt Thread-Index: AcxqNo1wZ6G+RflbTleO7kVAHmUvwAAjvoiQARQNEYA= Message-ID: References: <4E622001.8010904@tana.it> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Fwd: I-D Action: draft-vesely-marf-abuse-reporting-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, 09 Sep 2011 17:31:14 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of M= urray S. Kucherawy > Sent: Saturday, September 03, 2011 10:45 PM > To: Message Abuse Report Format working group > Subject: Re: [marf] Fwd: I-D Action: draft-vesely-marf-abuse-reporting-00= .txt >=20 > Based on your Abstract alone, I'm wondering: Does this introduce > material not covered by http://datatracker.ietf.org/doc/draft-jdfalk- > maawg-cfblbcp/ ? I'm assuming the answer to that is "yes" given other list traffic since. The draft-jdfalk-maawg-cfblbcp document is moving forward as an independent= submission. If the working group thinks there are points in Alessandro's = document that would be good addenda to what the independent submission says= , we can put those in the applicability statement (draft-ietf-marf-as). So= instead of Alessandro going ahead with his document (and it would be weird= for this group to produce two BCPs on the same topic), we should review wh= at he says and then propose text that JD should add to the AS and then see = if any of it gets consensus. Sound good? -MSK From msk@cloudmark.com Fri Sep 9 10:47: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 6EBB721F8562 for ; Fri, 9 Sep 2011 10:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.012 X-Spam-Level: X-Spam-Status: No, score=-103.012 tagged_above=-999 required=5 tests=[AWL=-0.413, 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 EmGXU-KIC6iU for ; Fri, 9 Sep 2011 10:47:25 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id F212321F8480 for ; Fri, 9 Sep 2011 10:47:24 -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, 9 Sep 2011 10:49:15 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 9 Sep 2011 10:49:14 -0700 Thread-Topic: [marf] I-D Action: draft-ietf-marf-authfailure-report-02.txt Thread-Index: AcxulsbXiVejVgnRTDSqNL807lFSrAAgbK/A Message-ID: References: <20110909021618.27975.41945.idtracker@ietfa.amsl.com> In-Reply-To: <20110909021618.27975.41945.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-authfailure-report-02.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, 09 Sep 2011 17:47:25 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org > Sent: Thursday, September 08, 2011 7:16 PM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: [marf] I-D Action: draft-ietf-marf-authfailure-report-02.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-02.txt > Pages : 19 > Date : 2011-09-08 >=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. I've read this, and I think it's ready to go. I know of one open source im= plementation (mine) that sends mail using this format, but my implementatio= n is not also a consumer, so I'd love to hear from anyone that receives and= parses these and does something with them. For bonus points, we could try= some interoperability testing. Also, more reviewers, please. I'd like to see more feedback before we star= t its process up the chain. -MSK From msk@cloudmark.com Fri Sep 9 10:52:33 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 AC0FB21F85EF for ; Fri, 9 Sep 2011 10:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.009 X-Spam-Level: X-Spam-Status: No, score=-103.009 tagged_above=-999 required=5 tests=[AWL=-0.411, 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 L1eM4Mssx95j for ; Fri, 9 Sep 2011 10:52:31 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 9E97E21F8512 for ; Fri, 9 Sep 2011 10:52:31 -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, 9 Sep 2011 10:54:27 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 9 Sep 2011 10:54:26 -0700 Thread-Topic: Revisiting reporting addresses Thread-Index: Acxd695gO2r+Maw3RUWO/eryys1YlQRLaCCg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F13512DFB81EXCHC2corpclo_" MIME-Version: 1.0 Subject: Re: [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: Fri, 09 Sep 2011 17:52:34 -0000 --_000_F5833273385BB34F99288B3648C4F06F13512DFB81EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello? Anyone out there? From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Mur= ray S. Kucherawy Sent: Thursday, August 18, 2011 2:15 PM To: marf@ietf.org Subject: [marf] Revisiting reporting addresses 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_F5833273385BB34F99288B3648C4F06F13512DFB81EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello?  Anyone out there?

 

From: marf-bounces@ietf.org [mailto:mar= f-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent:= Thursday, August 18, 2011 2:15 PM
To: marf@ietf.org
Subjec= t: [marf] Revisiting reporting addresses

 

Referring= to draft-ietf-marf-dkim-reporting…

 

The current document says the r= eporting address is either a local-part (a userid) or a full address. = If it’s a local-part, then “@” followed by the relevant = domain is used to compose the full reporting address; for an ADSP report, t= hat’s the From: domain, and for a DKIM failure report that’s th= e “d=3D” domain.  So there are reasonable defaults, but it= does allow one to stick any address at all there.  I seem to recall i= t started out that way, then switch to local-part-only, then back to where = it is now.  Does everyone concur that we want to allow that?

 

If we d= o, I think this warrants text in Security Considerations acknowledging the = attacks this enables, and talking about why we think that’s okay.&nbs= p; Could someone that remembers this discussion better than me propose some= text along those lines?

 

This too has been implemented in OpenDKIM and it= s antecedent for a long time.

 = ;

Thanks,

= -MSK

= --_000_F5833273385BB34F99288B3648C4F06F13512DFB81EXCHC2corpclo_-- From msk@cloudmark.com Fri Sep 9 10:53:46 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 1A1BA21F85F2 for ; Fri, 9 Sep 2011 10:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.508 X-Spam-Level: X-Spam-Status: No, score=-103.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 b2Ww3WZ1oHgE for ; Fri, 9 Sep 2011 10:53:45 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id A905021F8512 for ; Fri, 9 Sep 2011 10:53:45 -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, 9 Sep 2011 10:55:41 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 9 Sep 2011 10:55:40 -0700 Thread-Topic: Comments on draft-ietf-marf-authfailure-report-01.txt Thread-Index: AcxW1RMNbfLFK61xTXWXIrjX8GzuxAHEtDBwBExrLeA= Message-ID: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.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] 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: Fri, 09 Sep 2011 17:53:46 -0000 Actually, in going back through the list, I found this: > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Murray S. Kucherawy > Sent: Thursday, August 18, 2011 2:02 PM > To: marf@ietf.org > Subject: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt >=20 > 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 now and the whole concept of key granularity has been removed. > We would then change the existing [DKIM] reference to [OLD-DKIM], and > add one called [DKIM] that points to the one that's currently in the > RFC editor queue. (Barry, check my math on this one, please.) It looks like this one got missed. Anyone have any particular comments, es= pecially Barry? > If there's no other feedback, do people think we're ready to start a > WGLC on this one? Re-asking this. From vesely@tana.it Sat Sep 10 08:54:44 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 8622521F899F for ; Sat, 10 Sep 2011 08:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.638 X-Spam-Level: X-Spam-Status: No, score=-4.638 tagged_above=-999 required=5 tests=[AWL=0.081, 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 wa1IiLwAlBYx for ; Sat, 10 Sep 2011 08:54:43 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 955F821F886D for ; Sat, 10 Sep 2011 08:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1315670068; bh=LN+j8tlRxGy5vUD9g9fpYZUDdrynZHMqI4EQsvjsm38=; l=1302; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=RRljzvds1WWXhyDDsXCU2lnaYQNzRNhNfouv2S9so5cSJefJP7exGD8X4atCB0yqt SH+UK3Hr8czkZrYQPDuZg3GAbSBq1gGuT2RSmzxjsR/5NS/saGGjn4Mh9bSAbYQef+ 4YUMid3xkorCFWTQe3hjzXgpCII0p6n0n5p3zGho= 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, 10 Sep 2011 17:54:28 +0200 id 00000000005DC03F.000000004E6B8834.00000B6A Message-ID: <4E6B8833.1000900@tana.it> Date: Sat, 10 Sep 2011 17:54:27 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: marf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [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: Sat, 10 Sep 2011 15:54:44 -0000 On 09/Sep/11 19:54, Murray S. Kucherawy wrote: > Hello? Anyone out there? This was discussed in a different thread... > The current document says the reporting address is either a local-part > (a userid) or a full address. If it’s a local-part, then “@” followed > by the relevant domain is used to compose the full reporting address; > for an ADSP report, that’s the From: domain, and for a DKIM failure > report that’s the “d=” domain. So there are reasonable defaults, but > it does allow one to stick any address at all there. I seem to recall > it started out that way, then switch to local-part-only, then back to > where it is now. Does everyone concur that we want to allow that? I agree with what John said, 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. http://www.ietf.org/mail-archive/web/marf/current/msg01273.html I proposed a DNS-based validation, replying to his message. > If we do, I think this warrants text in Security Considerations > acknowledging the attacks this enables, and talking about why we think > that’s okay. I don't think it's okay. Without validation one cannot lightheartedly use discovered addresses in different domains, IMHO. From johnl@iecc.com Sat Sep 10 10:10: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 F2E1621F86FF for ; Sat, 10 Sep 2011 10:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.101 X-Spam-Level: X-Spam-Status: No, score=-111.101 tagged_above=-999 required=5 tests=[AWL=0.098, 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 naHQZRE9WKqS for ; Sat, 10 Sep 2011 10:10:53 -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 F23ED21F86C7 for ; Sat, 10 Sep 2011 10:10:46 -0700 (PDT) Received: (qmail 2110 invoked from network); 10 Sep 2011 17:12:43 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 10 Sep 2011 17:12:43 -0000 Received: (qmail 79810 invoked from network); 10 Sep 2011 17:12:37 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 10 Sep 2011 17:12:37 -0000 Date: 10 Sep 2011 17:12:15 -0000 Message-ID: <20110910171215.20549.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <4E6B8833.1000900@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] 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: Sat, 10 Sep 2011 17:10:54 -0000 >> If we do, I think this warrants text in Security Considerations >> acknowledging the attacks this enables, and talking about why we >> think that’s okay. I have to say I don't think it's OK either. This sort of thing is only worth standardizing if we think people are likely to use it, and if they're likely to use it, the reverse DDoS attack is an obvious one. The simplest fix would be to require that the reporting address is in the same domain. If someone has so little control over their domain that they can't set up an abuse address, I have limited sympathy. R's, John From sm@resistor.net Sat Sep 10 15:31: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 168F821F855F for ; Sat, 10 Sep 2011 15:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 2xb4bftZ5Kuj for ; Sat, 10 Sep 2011 15:30:59 -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 56FD821F8551 for ; Sat, 10 Sep 2011 15:30:58 -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 p8AMWSCj005880 for ; Sat, 10 Sep 2011 15:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1315693970; bh=dTd3p7G4wmSoMtyMDqivPYqsusmpm587GcfZJ/e0jAw=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=l9dcaQlAdT6Jq1vHijjVRjNKb4cW54BWnbOdGIoEtEE6XjUdnpWyDe4YsMQkn9Ltg bmSq4clTTIjYUGmPaQOZcqG7q3bkqOP2u/ATkTid4UXdjmznAE9uc+48EPlL17LnxH Jt9y+YPzBB3sSa+OQiwPz4vzJzV5rHLPIbnwZBfo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1315693970; bh=dTd3p7G4wmSoMtyMDqivPYqsusmpm587GcfZJ/e0jAw=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=A08y9FRFYG/zRnlqlsk7YmnxzIuEKB2PGg0S/Vuj0VGqI8vrUEAsOwgLeW88loft5 2Bmq2IW8Ctpgue5Dej0I3f1twoSUfoMHQpJL0R2x+3jZvbGNrOW8QBPCKujZqCx93x KxiYK62qwgJLjw+tIFsjf/QXd1Yhz8IcRzuuDMok= Message-Id: <6.2.5.6.2.20110910152545.0b0ad5d0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 10 Sep 2011 15:30:40 -0700 To: marf@ietf.org From: SM In-Reply-To: <20110910171215.20549.qmail@joyce.lan> References: <4E6B8833.1000900@tana.it> <20110910171215.20549.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [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: Sat, 10 Sep 2011 22:31:01 -0000 At 10:12 10-09-2011, John Levine wrote: >The simplest fix would be to require that the reporting address is in >the same domain. If someone has so little control over their domain A similar problem was discussed a few years back and that was the conclusion. Regards, -sm From internet-drafts@ietf.org Sat Sep 10 22:19:17 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 92EC121F8505; Sat, 10 Sep 2011 22:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 fSnYqL3-Z9XI; Sat, 10 Sep 2011 22:19:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DA621F84D3; Sat, 10 Sep 2011 22:19:17 -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.60 Message-ID: <20110911051917.20593.18797.idtracker@ietfa.amsl.com> Date: Sat, 10 Sep 2011 22:19:17 -0700 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-dkim-reporting-03.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: Sun, 11 Sep 2011 05:19:17 -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 : Extensions to DKIM for Failure Reporting Author(s) : Murray S. Kucherawy Filename : draft-ietf-marf-dkim-reporting-03.txt Pages : 18 Date : 2011-09-10 This memo presents extensions to the DomainKeys Identified Mail (DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-dkim-reporting-03.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-dkim-reporting-03.txt From msk@cloudmark.com Sat Sep 10 22:23: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 9E8C521F851F for ; Sat, 10 Sep 2011 22:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.508 X-Spam-Level: X-Spam-Status: No, score=-103.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 5LpIpkgNd-J3 for ; Sat, 10 Sep 2011 22:23:58 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3E16A21F84DF for ; Sat, 10 Sep 2011 22:23:58 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 10 Sep 2011 22:25:56 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sat, 10 Sep 2011 22:25:55 -0700 Thread-Topic: [marf] Revisiting reporting addresses Thread-Index: AcxwCZ150CULCX2xQ/2NQikRBdeHMAAOYxRQ Message-ID: References: <4E6B8833.1000900@tana.it> <20110910171215.20549.qmail@joyce.lan> <6.2.5.6.2.20110910152545.0b0ad5d0@resistor.net> In-Reply-To: <6.2.5.6.2.20110910152545.0b0ad5d0@resistor.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] 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: Sun, 11 Sep 2011 05:23:58 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= M > Sent: Saturday, September 10, 2011 3:31 PM > To: marf@ietf.org > Subject: Re: [marf] Revisiting reporting addresses >=20 > At 10:12 10-09-2011, John Levine wrote: > >The simplest fix would be to require that the reporting address is in > >the same domain. If someone has so little control over their domain >=20 > A similar problem was discussed a few years back and that was the > conclusion. The DKIM reporting document has been updated accordingly. (Fortunately, I = didn't have to change my implementation at all, since it already truncated = at the "@" if any was found.) From vesely@tana.it Mon Sep 12 03:34: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 81FB221F8AAC for ; Mon, 12 Sep 2011 03:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.639 X-Spam-Level: X-Spam-Status: No, score=-4.639 tagged_above=-999 required=5 tests=[AWL=0.080, 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 S-vxC0o1pOoI for ; Mon, 12 Sep 2011 03:34:33 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A629C21F8AAA for ; Mon, 12 Sep 2011 03:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1315823795; bh=Ba8wM4NtJ8kmhHDTQU59zOxEUGH+Xz2Vyh5N/qHrl6A=; l=1673; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=VBYrh29Aq9afPS/FEWo3IFryLxvn+lbLgwHtDD11FkeofaREK03KmSSJMoEDgnptm TkuS4pguGncvCG/yjuLd8Unu8/GaLZvxrkPNySAXQILrpn9aSAaBfaEuV7CKTebj/X xTe1BQLoVoZqpss/tvxdHmeUFQfA3vqPS/YNJjY4= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 12 Sep 2011 12:36:35 +0200 id 00000000005DC039.000000004E6DE0B3.00005CBD Message-ID: <4E6DE0B2.8060104@tana.it> Date: Mon, 12 Sep 2011 12:36:34 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: marf@ietf.org References: <4E6B8833.1000900@tana.it> <20110910171215.20549.qmail@joyce.lan> <6.2.5.6.2.20110910152545.0b0ad5d0@resistor.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [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: Mon, 12 Sep 2011 10:34:34 -0000 On 11/Sep/11 07:25, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: ietf.org On Behalf Of SM >> Sent: Saturday, September 10, 2011 3:31 PM >> To: marf@ietf.org >> Subject: Re: [marf] Revisiting reporting addresses >> >> At 10:12 10-09-2011, John Levine wrote: >>> The simplest fix would be to require that the reporting address is in >>> the same domain. If someone has so little control over their domain >> >> A similar problem was discussed a few years back and that was the >> conclusion. > > The DKIM reporting document has been updated accordingly. > (Fortunately, I didn't have to change my implementation at all, > since it already truncated at the "@" if any was found.) IMHO, that -03 change makes perfectly sense for dkim-reporting, since we can assume the feedback generator is willing to report a technical shortcoming to whoever is applying those signatures. For /abuse/ reporting, however, the domain-part of the discovered address could make a difference when a feedback generator is about to choose among this and, say, abuse POCs found in whois databases. If the discovered domain is well known, feedback generators may trust it. Hence, allowing for a different domain makes sense in this case, and could open up new avenues of abuse reporting practices. Consider _report.myunknowndomain.name. TXT "r=bofh@abuse.net" Confirming that the original domain has indeed outsourced abuse reporting to a renown organization is similar to vouching for that domain, but limited to abuse reporting. Also the syntax can be similar to VBR's: myunknowndomain.name._report.abuse.net. TXT "r=bofh@abuse.net" From johnl@iecc.com Mon Sep 12 07:26:41 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 3FA6A21F8514 for ; Mon, 12 Sep 2011 07:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.106 X-Spam-Level: X-Spam-Status: No, score=-111.106 tagged_above=-999 required=5 tests=[AWL=0.093, 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 rYclAtFwwpfe for ; Mon, 12 Sep 2011 07:26:40 -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 8AE8421F8508 for ; Mon, 12 Sep 2011 07:26:40 -0700 (PDT) Received: (qmail 1539 invoked from network); 12 Sep 2011 14:28:42 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 12 Sep 2011 14:28:42 -0000 Received: (qmail 17102 invoked from network); 12 Sep 2011 14:28:42 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Sep 2011 14:28:42 -0000 Date: 12 Sep 2011 14:28:20 -0000 Message-ID: <20110912142820.57911.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <4E6DE0B2.8060104@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] 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: Mon, 12 Sep 2011 14:26:41 -0000 You seem to be confusing two things. >For /abuse/ reporting, however, the domain-part of the discovered >address could make a difference when a feedback generator is about to >choose among this and, say, abuse POCs found in whois databases. Well, sure. If you find an address you trust some other way, send reports to it. > Consider > _report.myunknowndomain.name. TXT "r=bofh@abuse.net" Speaking both in general, and specifically as Mr. abuse.net, this is precisely what I want to forbid. I cannot tell you how many lazy or incompetent ISPs have foisted off some problem by telling their users to report it to abuse.net, which is of course completely useless and a waste of both the user's time and mine. I realize that we could invent some DNS thing with extra text records that are supposed to cross reference in some way, but I see no reason to invent yet more mechanism. If you've outsourced your abuse handling to someone else, we already know how to add a single line in your mail config to forward your abuse address to them. At last that way when some bozo forwards his complaints to me without asking, I only have one address to blacklist. R's, John From vesely@tana.it Mon Sep 12 11:49:36 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 9716121F8CB3 for ; Mon, 12 Sep 2011 11:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.64 X-Spam-Level: X-Spam-Status: No, score=-4.64 tagged_above=-999 required=5 tests=[AWL=0.079, 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 kAH8hPEZa37M for ; Mon, 12 Sep 2011 11:49:35 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A216D21F8CB2 for ; Mon, 12 Sep 2011 11:49:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1315853498; bh=Hcp2260L2qvvX2ZEm7wOoPYOSLSjAPq0Yk89BE9Uj+Q=; l=2261; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=TxzWUVIDlKWHb/gzieNiZA26MTyG/4xnKrAkU4nrQgpSrYuiRa3ZUkA7PI8SgC/X8 8mrC6/BgW4IY+65kJtrJ3cr/m8GcPEhRdXVAhqGQewMqsPOOZrTXjSKHiBQ8KEXMGH 6ViwDPsGWUwPRMYVApoBcfrPY+NFdGhvYb+zA4uA= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 12 Sep 2011 20:51:38 +0200 id 00000000005DC044.000000004E6E54BA.00002947 Message-ID: <4E6E54BA.3060600@tana.it> Date: Mon, 12 Sep 2011 20:51:38 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: marf@ietf.org References: <20110912142820.57911.qmail@joyce.lan> In-Reply-To: <20110912142820.57911.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [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: Mon, 12 Sep 2011 18:49:36 -0000 On 12/Sep/11 16:28, John Levine wrote: >> Consider >> _report.myunknowndomain.name. TXT "r=bofh@abuse.net" > > Speaking both in general, and specifically as Mr. abuse.net, this is > precisely what I want to forbid. I cannot tell you how many lazy or > incompetent ISPs have foisted off some problem by telling their users > to report it to abuse.net, which is of course completely useless and > a waste of both the user's time and mine. OTOH, such attitude proves that there is a market for that. According to plan "A", users should send complaints to their Mailbox Providers. It is the MP's abuse team who may opt for forwarding to abuse.net: they should be smart enough to understand a clause such as "do so only for domains that (a) are authenticated by dkim or spf, and (b) explicitly authorized by abuse.net". Possibly, abuse.net has a contract with such domains, e.g. providing for higher prices according to the number of complaints. NB: I'm not implying Mr. abuse.net has to be happy of doing such business. It is just a possibility that you and/or someone else might put to work. > I realize that we could invent some DNS thing with extra text records > that are supposed to cross reference in some way, but I see no reason > to invent yet more mechanism. If you've outsourced your abuse > handling to someone else, we already know how to add a single line in > your mail config to forward your abuse address to them. At last that > way when some bozo forwards his complaints to me without asking, I > only have one address to blacklist. The point is that the feedback generator has to be aware of that forwarding, in order to trust sending reports there. As an alternative to inventing more mechanisms, we could tweak VBR. Assume myunknowndomain is vouched for by abuse.net. Then one'd expect abuse.net to accept complaints for abuse originating there, but to what local part should they be addressed to? The reporting-discovery could say that an external domain is acceptable if and only if the latter vouches for myunknowndomain. Or it could modify VBR so as to allow, e.g., "all r=bofh". These two are more or less equivalent variations, even if they may seem to avoid inventing one more mechanism. From johnl@iecc.com Mon Sep 12 12:33:06 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 0759A21F8CC6 for ; Mon, 12 Sep 2011 12:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.097 X-Spam-Level: X-Spam-Status: No, score=-111.097 tagged_above=-999 required=5 tests=[AWL=0.102, 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 XqOYD9jRPADx for ; Mon, 12 Sep 2011 12:33:05 -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 4162021F8CC4 for ; Mon, 12 Sep 2011 12:33:05 -0700 (PDT) Received: (qmail 8653 invoked from network); 12 Sep 2011 19:35:08 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 12 Sep 2011 19:35:08 -0000 Received: (qmail 7570 invoked from network); 12 Sep 2011 19:35:07 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Sep 2011 19:35:07 -0000 Date: 12 Sep 2011 19:34:45 -0000 Message-ID: <20110912193445.41784.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <4E6E54BA.3060600@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] 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: Mon, 12 Sep 2011 19:33:06 -0000 >NB: I'm not implying Mr. abuse.net has to be happy of doing such >business. It is just a possibility that you and/or someone else >might put to work. Sigh. I understand this to mean that you're volunteering to deal with all of the random support requests to abuse.net. >The point is that the feedback generator has to be aware of that >forwarding, in order to trust sending reports there. Sorry, that's 100% totally wrong. The feedback generator sends reports related to example.com to abuse@example.com or feedback@example.com or some other example.com address. Then example.com forwards the reports somewhere, perhaps to an internal ticketing system or to an outsourced abuse desk, or whatever. That's invisible to the people sending the reports. There's a whole separate issue of how much you trust a domain in various ways, perhaps including how much you trust them to handle abuse reports, but we have a separate WG down the virtual hall for that. >As an alternative to inventing more mechanisms, we could tweak VBR. tweak VBR == inventing more mechanisms. Please, no. R's, John From vesely@tana.it Tue Sep 13 00:57:52 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 2A5A221F884C for ; Tue, 13 Sep 2011 00:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.642 X-Spam-Level: X-Spam-Status: No, score=-4.642 tagged_above=-999 required=5 tests=[AWL=0.077, 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 wCeoWB2O33Fq for ; Tue, 13 Sep 2011 00:57:50 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8286121F8634 for ; Tue, 13 Sep 2011 00:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1315900793; bh=u4B2T4IV+3o+73iubcjGWvtDrNZPMPUz3xgjRzevhDw=; l=2317; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=lwKkZdcuhLztu3cF0tk4BxTfqDSZ/tHsr/rcA66KkVSgPxAzj9xbKQKwIDu2i/GIP n2tH0+Nq8ZWDU7+ryT1MYke0AZHSOJCmiiTAtLefGnT7ae+xQ+Q2OjU6NWRCMFTxRt n3AkoH5UCsmmTmFl6HgLDV1MkeIy1lqC/+srSHPQ= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 13 Sep 2011 09:59:53 +0200 id 00000000005DC03F.000000004E6F0D79.00006780 Message-ID: <4E6F0D78.70803@tana.it> Date: Tue, 13 Sep 2011 09:59:52 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: marf@ietf.org References: <20110912193445.41784.qmail@joyce.lan> In-Reply-To: <20110912193445.41784.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [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: Tue, 13 Sep 2011 07:57:52 -0000 On 12/Sep/11 21:34, John Levine wrote: >> NB: I'm not implying Mr. abuse.net has to be happy of doing such >> business. It is just a possibility that you and/or someone else >> might put to work. > > Sigh. I understand this to mean that you're volunteering to deal with > all of the random support requests to abuse.net. Hm... not in my current situation. But I think I could have liked to run a business of that kind, in some life. >> The point is that the feedback generator has to be aware of that >> forwarding, in order to trust sending reports there. > > Sorry, that's 100% totally wrong. The feedback generator sends > reports related to example.com to abuse@example.com or > feedback@example.com or some other example.com address. I mostly agree. However, there are exceptions. In the words of abuse.net: Some particularly unpleasant domains ignore all their mail; when we're aware of that we use the address for their next-level-up provider. There are two questions about such position. First, how do you get aware of that? Second, is that provider willing to cooperate? It goes without saying that taking care of abuse reports involves some costs, so the second question entails how network providers should charge such costs if they want to offer competitive rates also to sites that do no email at all. It can be run as a different business. I'm not holding that ISPs never want to do such job, but since some of them are reluctant, cooperating ISPs need some means to confirm they /do/ take care of complaints. Can reporting-discovery solve this issue? > Then example.com forwards the reports somewhere, perhaps to an > internal ticketing system or to an outsourced abuse desk, or > whatever. That's invisible to the people sending the reports. Right. Within the domain, they may check users are not 0wned, or illegally sending bulk email. This seems to be yet another activity. > There's a whole separate issue of how much you trust a domain in > various ways, perhaps including how much you trust them to handle > abuse reports, but we have a separate WG down the virtual hall for > that. Possibly, that will eventually answer the first question above. For the reporting address, we need a working alternative to next-level-up providers. From dotzero@gmail.com Tue Sep 13 06:16: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 6BF4B21F8481 for ; Tue, 13 Sep 2011 06:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 l5fg3MfNX0me for ; Tue, 13 Sep 2011 06:16:47 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 51AF521F84A0 for ; Tue, 13 Sep 2011 06:16:46 -0700 (PDT) Received: by qyk32 with SMTP id 32so2642143qyk.10 for ; Tue, 13 Sep 2011 06:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8BEdb0CNZfQfGRsUJDIXkkE0bdu4o3BWliZQg6IKWio=; b=JQZOMdw4qQI3riBtbg5sg5wE/ugjf88snzknafotj341u60OV9CmVhZVf0FkDALRHi A/S4w75Ul8H132TWyoOyv7xOgziXi4Vf2OjB+GyPTKG5kJcfBCyl72yRWMjDfJNcJbXj TK2SH7N5rR6oGdyvIfRGeoqiGOKSmT476klH8= MIME-Version: 1.0 Received: by 10.229.67.148 with SMTP id r20mr4554221qci.64.1315919930708; Tue, 13 Sep 2011 06:18:50 -0700 (PDT) Received: by 10.229.191.78 with HTTP; Tue, 13 Sep 2011 06:18:50 -0700 (PDT) In-Reply-To: <4E6F0D78.70803@tana.it> References: <20110912193445.41784.qmail@joyce.lan> <4E6F0D78.70803@tana.it> Date: Tue, 13 Sep 2011 09:18:50 -0400 Message-ID: From: Dotzero To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: marf@ietf.org Subject: Re: [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: Tue, 13 Sep 2011 13:16:48 -0000 On Tue, Sep 13, 2011 at 3:59 AM, Alessandro Vesely wrote: > > Possibly, that will eventually answer the first question above. =A0For > the reporting address, we need a working alternative to next-level-up > providers. > Why? If reporting abuse directly to the domain admin or the abuse contact for the ASN indicated by whois doesn't work, I've found that contacting the upstream works in most cases. From johnl@iecc.com Tue Sep 13 08:05: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 A9E2C21F8B2C for ; Tue, 13 Sep 2011 08:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.101 X-Spam-Level: X-Spam-Status: No, score=-111.101 tagged_above=-999 required=5 tests=[AWL=0.098, 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 f1JVnJ3q5se7 for ; Tue, 13 Sep 2011 08:05:35 -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 5B96221F8500 for ; Tue, 13 Sep 2011 08:05:35 -0700 (PDT) Received: (qmail 35788 invoked from network); 13 Sep 2011 15:07:40 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 13 Sep 2011 15:07:40 -0000 Received: (qmail 40198 invoked from network); 13 Sep 2011 15:07:30 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Sep 2011 15:07:30 -0000 Date: 13 Sep 2011 15:07:08 -0000 Message-ID: <20110913150708.63580.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <4E6F0D78.70803@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] 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: Tue, 13 Sep 2011 15:05:39 -0000 >> Sigh. I understand this to mean that you're volunteering to deal with >> all of the random support requests to abuse.net. > >Hm... not in my current situation. But I think I could have liked to >run a business of that kind, in some life. You're missing the point -- you don't get to charge, they just send you the complaints without asking. I'll forward them as they come in. > Some particularly unpleasant domains ignore all their mail; > when we're aware of that we use the address for their > next-level-up provider. > >There are two questions about such position. First, how do you get >aware of that? Second, is that provider willing to cooperate? At abuse.net, that's handled completely manually, both the evaluation and the selection of addresses. This is policy stuff that is utterly outside the scope of a fricking reporting format. R's, John From vesely@tana.it Tue Sep 13 09:55:41 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 4156021F8C48 for ; Tue, 13 Sep 2011 09:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.643 X-Spam-Level: X-Spam-Status: No, score=-4.643 tagged_above=-999 required=5 tests=[AWL=0.076, 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 mfcnUgc6ec1o for ; Tue, 13 Sep 2011 09:55:40 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 467F421F8C39 for ; Tue, 13 Sep 2011 09:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1315933057; bh=Z3xOSrOXqBjEUPIzkmexS4qAWNnzRwYjYwup+lIhGqk=; l=1238; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=l+JRUN7WLKuORNA9FkSY23DuGs5VKjuI2vZ4g5fLiT0kXH/tOR4yRa7r45mOidDts xttWj/UEvtbtPDUZFPvOYOt/uSTeah0QijgFqF3e8lh25chnS51T/UVxbckQbuXwH7 7kdorOVdYfeX+IXaZNnMoMuBgqaoNqT1eMj8dhi8= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 13 Sep 2011 18:57:37 +0200 id 00000000005DC042.000000004E6F8B81.00003BCA Message-ID: <4E6F8B81.4000100@tana.it> Date: Tue, 13 Sep 2011 18:57:37 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: marf@ietf.org References: <20110913150708.63580.qmail@joyce.lan> In-Reply-To: <20110913150708.63580.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [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: Tue, 13 Sep 2011 16:55:41 -0000 On 13/Sep/11 17:07, John Levine wrote: > You're missing the point -- you don't get to charge, they just send > you the complaints without asking. I'll forward them as they come in. I see, they probably think abuse.net is an abuse reporting hub like SpamCop. > At abuse.net, that's handled completely manually, both the evaluation > and the selection of addresses. This is policy stuff that is utterly > outside the scope of a fricking reporting format. I only send abuse reports for a minimal part of the spam I get. This is not a policy, it is because I haven't yet managed to automate spam reporting. By "automate" I mean that clicking the spam button should result in having a report sent out, with minimal manual intervention on the server side. Then, I'll be able to offer the same service to my few users, and possibly contribute to an RFC about that. I don't think I'd be able to manually send reports (and monitor their effect) for a significant part of the spammy messages in my own inbox, let alone doing so for my users, however few. If we conclude that it is not worth/feasible to automate complaining, how would we characterize that minuscule part of abusive messages that deserve being reported? From msk@cloudmark.com Tue Sep 13 10:01:31 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 CD8D921F84FC for ; Tue, 13 Sep 2011 10:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.005 X-Spam-Level: X-Spam-Status: No, score=-103.005 tagged_above=-999 required=5 tests=[AWL=-0.406, 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 unjvX-EM5tAu for ; Tue, 13 Sep 2011 10:01:31 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 63DD421F84F9 for ; Tue, 13 Sep 2011 10:01:31 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 13 Sep 2011 10:03:37 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 13 Sep 2011 10:03:37 -0700 Thread-Topic: [marf] Revisiting reporting addresses Thread-Index: AcxyJvTCVVHQgGjASA6E8r94cTh1BwADOsIw Message-ID: References: <4E6F0D78.70803@tana.it> <20110913150708.63580.qmail@joyce.lan> In-Reply-To: <20110913150708.63580.qmail@joyce.lan> 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] 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: Tue, 13 Sep 2011 17:01:31 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of J= ohn Levine > Sent: Tuesday, September 13, 2011 8:07 AM > To: marf@ietf.org > Cc: vesely@tana.it > Subject: Re: [marf] Revisiting reporting addresses >=20 > At abuse.net, that's handled completely manually, both the evaluation > and the selection of addresses. This is policy stuff that is utterly > outside the scope of a fricking reporting format. I agree that what's being discussed isn't a protocol matter, but it's not i= mpossible for material like this to be in a BCP or other advisory document.= The question is really whether or not this is stuff we want or need to sa= y beyond the BCP we're already producing. I don't think we could codify, in protocol at least, anything at all about = WHOIS. In its current form it isn't a reliable source of any kind of infor= mation. Sometimes what you need is there, sometimes it's not; sometimes it= 's there but not in a form an automated system can extract. This might be = helpful to include in advice someplace though if we can find text on which = we can agree. All of that might change if the WEIRDS effort is successful,= but for now WHOIS is a wild west. I think it's clear we want not to include domain names in any reporting add= resses for the reasons John stated. The dkim-reporting document has alread= y been updated to say so, and in my opinion the spf-reporting and reporting= -discovery documents should follow. This all leads into the issue of whether or not we want to do some advisory= text about FBLs outside of the context of private agreements. I'll commen= t about that on a separate thread. -MSK, as participant From msk@cloudmark.com Tue Sep 13 10:38:56 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 93A9921F8CBD for ; Tue, 13 Sep 2011 10:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.003 X-Spam-Level: X-Spam-Status: No, score=-103.003 tagged_above=-999 required=5 tests=[AWL=-0.404, 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 ybU396RETXhx for ; Tue, 13 Sep 2011 10:38:56 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 2A31F21F8CB5 for ; Tue, 13 Sep 2011 10:38:56 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 13 Sep 2011 10:41:02 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Tue, 13 Sep 2011 10:41:02 -0700 Thread-Topic: Private vs. "public" FBLs Thread-Index: AcxqNo1wZ6G+RflbTleO7kVAHmUvwAAjvoiQARQNEYAAyFtvIA== Message-ID: References: <4E622001.8010904@tana.it> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [marf] Private vs. "public" FBLs 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, 13 Sep 2011 17:38:56 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Murray S. Kucherawy > Sent: Friday, September 09, 2011 10:33 AM > To: Message Abuse Report Format working group > Subject: Re: [marf] Fwd: I-D Action: draft-vesely-marf-abuse-reporting-00= .txt >=20 > The draft-jdfalk-maawg-cfblbcp document is moving forward as an > independent submission. If the working group thinks there are points > in Alessandro's document that would be good addenda to what the > independent submission says, we can put those in the applicability > statement (draft-ietf-marf-as). So instead of Alessandro going ahead > with his document (and it would be weird for this group to produce two > BCPs on the same topic), we should review what he says and then propose > text that JD should add to the AS and then see if any of it gets > consensus. Given the conversation in the other thread, there's interest (at least from= Alessandro) about discussing the handling of feedback reports that are gen= erated without a private arrangement between the producer and the consumer.= The MAAWG BCP and our Applicability Statement discuss FBLs with private a= rrangements, but not reports from the general public. Barry and I agree that this is something we should consider because such th= ings will happen, either because report generators just start using "abuse@= " as the destination without prior arrangement, or because the reporting-di= scovery draft gets traction. The right place to do this would be in additional sections added to draft-i= etf-marf-as. It's fine for that document to point to the MAAWG BCP for the= pre-arranged FBL case (as it already does), and then also discuss things a= bout sending or receiving feedback outside of the context of a formalized F= BL. So far John and Alessandro have some experience they're bringing to bear on= the topic. If that could be coalesced into additional sections for the AS= , that would probably be ideal. There are other FBL experts on this list (= obviously) and I'd like it if they could weigh in as well. -MSK, as co-chair (and proxying Barry via IM) From johnl@iecc.com Tue Sep 13 12:00:03 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 33E2E21F8B64 for ; Tue, 13 Sep 2011 12:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.105 X-Spam-Level: X-Spam-Status: No, score=-111.105 tagged_above=-999 required=5 tests=[AWL=0.094, 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 eSm+tGC1ai9M for ; Tue, 13 Sep 2011 12:00:02 -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 CE84F11E8095 for ; Tue, 13 Sep 2011 12:00:01 -0700 (PDT) Received: (qmail 41142 invoked from network); 13 Sep 2011 19:02:07 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 13 Sep 2011 19:02:07 -0000 Received: (qmail 69663 invoked from network); 13 Sep 2011 19:02:07 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Sep 2011 19:02:07 -0000 Date: 13 Sep 2011 19:01:45 -0000 Message-ID: <20110913190145.28043.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <4E6F8B81.4000100@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] 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: Tue, 13 Sep 2011 19:00:03 -0000 >I only send abuse reports for a minimal part of the spam I get. This >is not a policy, it is because I haven't yet managed to automate spam >reporting. I do send out reports automatically, for stuff that hits some of my spamtraps, and stuff that lands in my spam folder. It currently uses very conservative rules about where to report; abuse.net if the sending IP has valid rDNS, and a manually maintained list of IP range contacts. If something like MARF reporting becomes popular, I would retrieve the addresses, but only if I were confident that I wasn't going to annoy a lot of unrelated people by doing so. I think we have rough consensus here, so I'll stop now. R's, John From barryleiba.mailing.lists@gmail.com Tue Sep 13 12:56:35 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 4A84511E80F7 for ; Tue, 13 Sep 2011 12:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.848 X-Spam-Level: X-Spam-Status: No, score=-102.848 tagged_above=-999 required=5 tests=[AWL=0.129, 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 W1JleLAXZE9N for ; Tue, 13 Sep 2011 12:56:34 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id BBC9E11E80E2 for ; Tue, 13 Sep 2011 12:56:34 -0700 (PDT) Received: by gwb20 with SMTP id 20so909698gwb.31 for ; Tue, 13 Sep 2011 12:58:41 -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=FR7UApR/ly8/vUe8msh5alTxcarkNjZyLUDLODaMvHo=; b=MrVhrvYnwIBRVHKo1/kFWlsc6I3CgVH0V4TRltdyRmVDEWZ/8BBU28MFZzvaK0tYi+ ke1VmkUS3bi99TVBPZpiv79xgHYN1LKhl1n5BPZCi2UKx6+ev6D+kgIF/PfheHdG1XYc YydPjRMxNscvaYlCjulIYpjYC8WMwUsvekqmE= MIME-Version: 1.0 Received: by 10.146.192.28 with SMTP id p28mr1403654yaf.35.1315943921367; Tue, 13 Sep 2011 12:58:41 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.83.8 with HTTP; Tue, 13 Sep 2011 12:58:41 -0700 (PDT) In-Reply-To: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2011 15:58:41 -0400 X-Google-Sender-Auth: _2RioMO0KIgO6AY2wHS2k3hSEn8 Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "marf@ietf.org" Subject: Re: [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: Tue, 13 Sep 2011 19:56:35 -0000 >> 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 now and the whole concept of key granularity has been removed. >> We would then change the existing [DKIM] reference to [OLD-DKIM], and >> add one called [DKIM] that points to the one that's currently in the >> RFC editor queue. =A0(Barry, check my math on this one, please.) > > It looks like this one got missed. =A0Anyone have any particular comments= , especially Barry? I thought I'd replied to this before, but I guess not. Do we really want to talk about "old-dkim" at this point? Shouldn't we have a failure reason of "other" anyway, and just eliminate "granularity" and say that any other failure reason is reported as "other"? >> If there's no other feedback, do people think we're ready to start a >> WGLC on this one? > > Re-asking this. I think we're ready. The above issue can be resolved during WGLC. Let's say that this now officially starts working-group last call on draft-ietf-marf-authfailure-report-02 ( http://tools.ietf.org/html/draft-ietf-marf-authfailure-report ), said last call to end on 30 September. Everyone, please review this version and give it a yay or nay. Please post issues, and also post notes that you've reviewed this version and it's ready to go. Barry From msk@cloudmark.com Tue Sep 13 13:04:38 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 07BF411E808E for ; Tue, 13 Sep 2011 13:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.5 X-Spam-Level: X-Spam-Status: No, score=-103.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 gAibZqlSp7hm for ; Tue, 13 Sep 2011 13:04:37 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8578B11E8107 for ; Tue, 13 Sep 2011 13:04:37 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 13 Sep 2011 13:06:44 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 13 Sep 2011 13:06:43 -0700 Thread-Topic: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt Thread-Index: AcxyT4nd02lc0y+qQnqXqV0AnC/1sQAAFknQ Message-ID: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.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] 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: Tue, 13 Sep 2011 20:04:38 -0000 > -----Original Message----- > From: barryleiba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lists= @gmail.com] On Behalf Of Barry Leiba > Sent: Tuesday, September 13, 2011 12:59 PM > To: Murray S. Kucherawy > Cc: marf@ietf.org > Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt >=20 > I thought I'd replied to this before, but I guess not. > Do we really want to talk about "old-dkim" at this point? Shouldn't > we have a failure reason of "other" anyway, and just eliminate > "granularity" and say that any other failure reason is reported as > "other"? I'd be fine with removing it as "overtaken by events". > Let's say that this now officially starts working-group last call on > draft-ietf-marf-authfailure-report-02 ( > http://tools.ietf.org/html/draft-ietf-marf-authfailure-report ), said > last call to end on 30 September. Everyone, please review this > version and give it a yay or nay. Please post issues, and also post > notes that you've reviewed this version and it's ready to go. Reviewed, ready to go. The datatracker will show this WGLC closing 9/27, but we'll let it = roll the extra three days. I'll also take this one up as document shepherd= . -MSK, as participant, except as noted From vesely@tana.it Wed Sep 14 01:23:36 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 9A44F21F8C0D for ; Wed, 14 Sep 2011 01:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.644 X-Spam-Level: X-Spam-Status: No, score=-4.644 tagged_above=-999 required=5 tests=[AWL=0.075, 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 VA2x9kfhWfGV for ; Wed, 14 Sep 2011 01:23:35 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D0C5F21F8B58 for ; Wed, 14 Sep 2011 01:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1315988741; bh=tLL9zmupQcv8OiWBWWpmDPdYdcyIL1WPQW9Vn5hkQ2c=; l=1653; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=CiOcEDYPITzPRb7VFJR4n+dVl8CriKHOOz1BEWBRp0gNP85p99KffPpKhnoYxGPqj O8zmyCBLpr8SbLhO2agudKoybMTlR0oCjHm8jIDG/HbB6WB1FDvc6ReeUfC86puVA6 XnHoFD0lRau1+WGFqxueRwctV1xHHRwTu+RbSVx8= 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, 14 Sep 2011 10:25:41 +0200 id 00000000005DC033.000000004E706505.000004C6 Message-ID: <4E706505.901@tana.it> Date: Wed, 14 Sep 2011 10:25:41 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: marf@ietf.org References: <4E622001.8010904@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Private vs. "public" FBLs 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, 14 Sep 2011 08:23:36 -0000 On 13/Sep/11 19:41, Murray S. Kucherawy wrote: > > The right place to do [the handling of feedback reports that are > generated without a private arrangement between the producer and > the consumer] would be in additional sections added to > draft-ietf-marf-as. It's fine for that document to point to the > MAAWG BCP for the pre-arranged FBL case (as it already does), and > then also discuss things about sending or receiving feedback > outside of the context of a formalized FBL. I agree on that. I only wrote a separate document after JD said that non-solicited feedback need to be a different Applicability Statement. http://www.ietf.org/mail-archive/web/marf/current/msg01117.html Yet, it may be convenient to rough-hew that stuff as a separate document, at least until we hear from JD. I dunno whether WG-doc vs. individual submission makes any difference in such respect. Please advise. On 13/Sep/11 19:03, Murray S. Kucherawy also wrote: > I don't think we could codify, in protocol at least, anything at > all about WHOIS. In its current form it isn't a reliable source of > any kind of information. It seems to be getting more and more reliable, even including advice about reliability, in some cases. I'd consider it more reliable than rDNS + domain-name lookup, but would like to hear from John on this point. > All of that might change if the WEIRDS effort is successful, but > for now WHOIS is a wild west. IMHO, the larger part of the difficulty is the need to interface five different RIRs. It would be great if WEIRD could come out with an homogeneous rDNS-like interface --obviously OT here. From vesely@tana.it Wed Sep 14 01:29:05 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 3DC4B21F8C4D for ; Wed, 14 Sep 2011 01:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.646 X-Spam-Level: X-Spam-Status: No, score=-4.646 tagged_above=-999 required=5 tests=[AWL=0.073, 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 4oWL6RPRHavK for ; Wed, 14 Sep 2011 01:29:03 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id B786621F8C36 for ; Wed, 14 Sep 2011 01:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1315989071; bh=ffp8meLSdFp2/GdDGrf4Hb/HAyfDtbB4qKL4mx2Ahss=; l=208; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=OZY8EsJUsr7tdJyl2uSPUEP6TwrL9W0hsrWOL1JfSLyuTvWkcfkC5543ynIT3Jmh/ 3g2e/KK0VQHYcJnYGfaO3y0Dz5wG5LoYrDkwM54knLVtSL9vo3B1j9j97RT5EZ2O3R a78hjlT3b9i9zSgzESStuBX/r/GBkZ7rbwvZZCiQ= 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, 14 Sep 2011 10:31:11 +0200 id 00000000005DC033.000000004E70664F.00001F65 Message-ID: <4E706650.2020108@tana.it> Date: Wed, 14 Sep 2011 10:31:12 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b2 Thunderbird/3.1.14 MIME-Version: 1.0 To: marf@ietf.org References: <20110913190145.28043.qmail@joyce.lan> In-Reply-To: <20110913190145.28043.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [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: Wed, 14 Sep 2011 08:29:05 -0000 On 13/Sep/11 21:01, John Levine wrote: > > I think we have rough consensus here, so I'll stop now. Yup, you an Murray in for domain-less r= is the double of me for the domain-part. Easy arithmetic :-/ From shmuel+gen@patriot.net Wed Sep 14 04:21: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 F1BDA21F891D for ; Wed, 14 Sep 2011 04:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_40=-0.185] 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 7RIKKpl-kdeq for ; Wed, 14 Sep 2011 04:21:30 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 31F5B21F8876 for ; Wed, 14 Sep 2011 04:21:20 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.124]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id C9CA0F580BA for ; Wed, 14 Sep 2011 07:12:55 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Wed, 14 Sep 2011 07:26:14 -0400 To: Message Abuse Report Format working group In-Reply-To: <4E706505.901@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: <20110914111255.C9CA0F580BA@smtp.patriot.net> Subject: Re: [marf] Private vs. "public" FBLs 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, 14 Sep 2011 11:21:33 -0000 In <4E706505.901@tana.it>, on 09/14/2011 at 10:25 AM, Alessandro Vesely said: >It seems to be getting more and more reliable, I parse whois data with Perl regexen, and IMHO the data are still far too unstandardized, e.g., some addresses are present only in comments, some data are available only by following links whose existence depends on the particular RIR. -- 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 Wed Sep 14 09:44: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 7B08821F8BA2 for ; Wed, 14 Sep 2011 09:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.498 X-Spam-Level: X-Spam-Status: No, score=-103.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 0WCzOqgOUGhj for ; Wed, 14 Sep 2011 09:44:39 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 14AA221F8BA4 for ; Wed, 14 Sep 2011 09:44:36 -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, 14 Sep 2011 09:46:45 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Wed, 14 Sep 2011 09:46:43 -0700 Thread-Topic: [marf] Private vs. "public" FBLs Thread-Index: Acxy0M7LJgZ+iMlgSX6dbdoaIkCY8gALOHDg Message-ID: References: <4E706505.901@tana.it> <20110914111255.C9CA0F580BA@smtp.patriot.net> In-Reply-To: <20110914111255.C9CA0F580BA@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Private vs. "public" FBLs 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, 14 Sep 2011 16:44:39 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Wednesday, September 14, 2011 4:26 AM > To: Message Abuse Report Format working group > Subject: Re: [marf] Private vs. "public" FBLs >=20 > I parse whois data with Perl regexen, and IMHO the data are still far > too unstandardized, e.g., some addresses are present only in comments, > some data are available only by following links whose existence > depends on the particular RIR. That's my observation as well. I believe it's the case that any reliabilit= y people see from WHOIS is coincidental, and not the result of any standard= s effort from IETF or a policy effort from ICANN. From msk@cloudmark.com Wed Sep 14 09:47:19 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 5481521F8B46 for ; Wed, 14 Sep 2011 09:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 PfjZOrxUgj0X for ; Wed, 14 Sep 2011 09:47:18 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id E7E1621F8B45 for ; Wed, 14 Sep 2011 09:47:18 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 14 Sep 2011 09:49:28 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 14 Sep 2011 09:49:27 -0700 Thread-Topic: [marf] Private vs. "public" FBLs Thread-Index: Acxyt+iQ/GC5RF28RhyzrEHm9LuRmQARgTkQ Message-ID: References: <4E622001.8010904@tana.it> <4E706505.901@tana.it> In-Reply-To: <4E706505.901@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] Private vs. "public" FBLs 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, 14 Sep 2011 16:47:19 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Wednesday, September 14, 2011 1:26 AM > To: marf@ietf.org > Subject: Re: [marf] Private vs. "public" FBLs >=20 > I agree on that. I only wrote a separate document after JD said that > non-solicited feedback need to be a different Applicability Statement. > http://www.ietf.org/mail-archive/web/marf/current/msg01117.html >=20 > Yet, it may be convenient to rough-hew that stuff as a separate > document, at least until we hear from JD. I dunno whether WG-doc vs. > individual submission makes any difference in such respect. Please > advise. There's certainly nothing stopping you from developing your individual subm= ission, but the chairs feel that material should really be rolled into the = AS once the WG has consensus on what text to add to it to cover this other = specific use case. From johnl@iecc.com Wed Sep 14 12:20:21 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 A8ADA21F8D9A for ; Wed, 14 Sep 2011 12:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.108 X-Spam-Level: X-Spam-Status: No, score=-111.108 tagged_above=-999 required=5 tests=[AWL=0.091, 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 5NJX9IB9BoaC for ; Wed, 14 Sep 2011 12:20:21 -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 C3BB321F8D86 for ; Wed, 14 Sep 2011 12:20:20 -0700 (PDT) Received: (qmail 74666 invoked from network); 14 Sep 2011 19:22:29 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 14 Sep 2011 19:22:29 -0000 Received: (qmail 76088 invoked from network); 14 Sep 2011 19:22:28 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Sep 2011 19:22:28 -0000 Date: 14 Sep 2011 19:22:06 -0000 Message-ID: <20110914192206.12015.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] Private vs. "public" FBLs 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, 14 Sep 2011 19:20:21 -0000 >That's my observation as well. I believe it's the case that any >reliability people see from WHOIS is coincidental, and not the result of >any standards effort from IETF or a policy effort from ICANN. Domain WHOIS for ICANN gTLDs is actually well standardized, except for .com and .net. (I realize this is like saying all water is fresh, except for the ocean.) I believe that the plan is to migrate .com and .net to the standard format at some point, but I don't know what the schedule is. The RIRs are indeed all different, and even when the format is reasonably well defined, the data are often missing or contradictory. In any event, I think we agree that scraping data from WHOIS is not suitable for any IETF standardization any time soon. R's, John From internet-drafts@ietf.org Mon Sep 19 11:46:40 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 4D4D621F8C52; Mon, 19 Sep 2011 11:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 iWAMfMUtRHkT; Mon, 19 Sep 2011 11:46:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CA621F84DD; Mon, 19 Sep 2011 11:46:39 -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.60 Message-ID: <20110919184639.4250.99057.idtracker@ietfa.amsl.com> Date: Mon, 19 Sep 2011 11:46:39 -0700 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-not-spam-feedback-02.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, 19 Sep 2011 18:46:40 -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-02.txt Pages : 7 Date : 2011-09-19 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-02.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-02.txt From jdfalk-lists@cybernothing.org Tue Sep 20 15:34: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 4949C1F0C62 for ; Tue, 20 Sep 2011 15:34:13 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYKgqPdDACNl for ; Tue, 20 Sep 2011 15:34:12 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id ADDED1F0C43 for ; Tue, 20 Sep 2011 15:34:12 -0700 (PDT) Received: from [192.168.11.39] (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 p8KMaakd019785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 20 Sep 2011 15:36:38 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: Date: Tue, 20 Sep 2011 15:36:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1676FED9-9AB3-45A4-AA5C-4EFD77CC0130@cybernothing.org> References: <4E622001.8010904@tana.it> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] Private vs. "public" FBLs 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, 20 Sep 2011 22:34:13 -0000 On Sep 13, 2011, at 10:41 AM, Murray S. Kucherawy wrote: > The right place to do this would be in additional sections added to = draft-ietf-marf-as. It's fine for that document to point to the MAAWG = BCP for the pre-arranged FBL case (as it already does), and then also = discuss things about sending or receiving feedback outside of the = context of a formalized FBL. An alternative could be to have a separate Applicability Statement = discussing open/ad-hoc/non-pre-arranged feedback streams, so that = readers aren't confused. That also leaves room for future ASes on virus = reporting, et cetera -- a whole series. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From internet-drafts@ietf.org Thu Sep 22 10:49: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 315971F0C63; Thu, 22 Sep 2011 10:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 O13i8iZUVwWY; Thu, 22 Sep 2011 10:49:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E241F0C3C; Thu, 22 Sep 2011 10:49:12 -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.60 Message-ID: <20110922174912.10336.18014.idtracker@ietfa.amsl.com> Date: Thu, 22 Sep 2011 10:49:12 -0700 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-not-spam-feedback-03.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, 22 Sep 2011 17:49:13 -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-03.txt Pages : 7 Date : 2011-09-22 This document defines a new Abuse Reporting Format (ARF) feedback report type value: "not-spam". It can be used to report an em= ail message 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-03.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-03.txt From msk@cloudmark.com Fri Sep 30 11:14:40 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 94B5521F8BBB for ; Fri, 30 Sep 2011 11:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.474 X-Spam-Level: X-Spam-Status: No, score=-103.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 475XeAV7+exS for ; Fri, 30 Sep 2011 11:14:40 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0B71321F8AE9 for ; Fri, 30 Sep 2011 11:14:40 -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, 30 Sep 2011 11:17:32 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 30 Sep 2011 11:17:31 -0700 Thread-Topic: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt Thread-Index: AcxyT4nd02lc0y+qQnqXqV0AnC/1sQAAFknQA1NQXJA= Message-ID: References: <20110809204330.28607.64594.idtracker@ietfa.amsl.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] 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: Fri, 30 Sep 2011 18:14:40 -0000 Reminder: WGLC closes today on this document. > > -----Original Message----- > > From: barryleiba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lis= ts@gmail.com] On Behalf Of Barry Leiba > > Sent: Tuesday, September 13, 2011 12:59 PM > > To: Murray S. Kucherawy > > Cc: marf@ietf.org > > Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.t= xt > > > > I thought I'd replied to this before, but I guess not. > > Do we really want to talk about "old-dkim" at this point? Shouldn't > > we have a failure reason of "other" anyway, and just eliminate > > "granularity" and say that any other failure reason is reported as > > "other"? >=20 > I'd be fine with removing it as "overtaken by events". From johnl@iecc.com Fri Sep 30 11:55: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 75C2721F8A7A for ; Fri, 30 Sep 2011 11:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.114 X-Spam-Level: X-Spam-Status: No, score=-111.114 tagged_above=-999 required=5 tests=[AWL=0.085, 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 8BYKKx4tSgWG for ; Fri, 30 Sep 2011 11:55:04 -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 DE42B21F8A4E for ; Fri, 30 Sep 2011 11:55:03 -0700 (PDT) Received: (qmail 90694 invoked from network); 30 Sep 2011 18:57:56 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 30 Sep 2011 18:57:56 -0000 Received: (qmail 17921 invoked from network); 30 Sep 2011 18:57:56 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 30 Sep 2011 18:57:56 -0000 Date: 30 Sep 2011 18:57:34 -0000 Message-ID: <20110930185734.33110.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] 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: Fri, 30 Sep 2011 18:55:04 -0000 Sorry not to get to this sooner. This draft has problems. It's not ready to ship. Sec 3.1 says a report MUST include explicit auth results for both DKIM and SPF. Well, no. I don't check SPF, so if people are only going to accept DKIM failure reports if they also say something about SPF, they're not going to get any reports from me. I expect people who check SPF but not DKIM feel the same way, particularly for the large fraction of mail that has no DKIM signatures to check. Suggest just removing this clause, and let people report what they're reporting. Original-Envelope-ID and Original-Mail-From: same issue, they're not relevant to DKIM, and by the time I check DKIM, it's often after SMTP is over and the envelope isn't directly available. Suggest it say they SHOULD be included if they are available. Source-IP: same problem. If you don't have the source IP, just leave it out, don't lie. (And 0.0.0.0 is totally oldthink. The value I'm not going to include is ::.) Message-ID: this is just wrong, RFC 5965 does not report it. 3.2.1: Delivery-result: what I do with my mail is none of your business. This field has to be optional. 3.3: Why just spf rather than spf-fail, spf-softfail, spf-temperror, or spf-permerror? If you're reporting an SPF problem, you presumably know what your SPF checker returned. 4: SPF-DNS. If you're going to return a snapshot of the SPF record, shouldn't you also return all the records it included? R's, John From steve@wordtothewise.com Fri Sep 30 12:16:43 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 7228721F8CCE for ; Fri, 30 Sep 2011 12:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.595 X-Spam-Level: * X-Spam-Status: No, score=1.595 tagged_above=-999 required=5 tests=[AWL=-5.194, BAYES_00=-2.599, SARE_SPOOF_COM2COM=2.536, SARE_SPOOF_COM2OTH=2.536, SPOOF_COM2COM=2.272, SPOOF_COM2OTH=2.044] 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 3FcjHpdHhILL for ; Fri, 30 Sep 2011 12:16:39 -0700 (PDT) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id E3B3121F8CB9 for ; Fri, 30 Sep 2011 12:16:39 -0700 (PDT) Received: from platter.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: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id 7791B2E199 for ; Fri, 30 Sep 2011 12:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wordtothewise.com; s=1.wttw; t=1317410374; bh=ixSSnbWNjcM5+9++2X9OD525SYLaTmL+fp2ZCqSqPnc=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-Id:To:Mime-Version; b=IaABSYbbOiZDE3SqrxzZPNk3sfNBz5u2G+8HxaLTFoT6/O6sP91UrmT4pyzpv8VN9 0nz71ZroZtLpsrMrAkfHlyDkKsOLRpLAGEjYZ7+AMNyJpT6G19CICsKQ8BE926cfAe iURnk4A+c0mqm7Pgf41DYFzYzj+tBStXE2EDFC4g= From: Steve Atkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Sep 2011 12:19:33 -0700 Message-Id: <8BF70BBB-4AC7-4E8F-A22B-3B2DEBDB1893@wordtothewise.com> To: Message Abuse Report Format working group Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [marf] draft-ietf-marf-dkim-reporting feedback 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, 30 Sep 2011 19:16:43 -0000 I have a few comments - I've already chatted with Murray directly about = some of these, and he encouraged me to share them on-list. 1. Who would want it and their existing alternatives. This seems to be a feature that will primarily be of interest to bulk = emailers. Those senders are interested in many facets of email delivery, = and have existing networks of probe addresses at many ISPs which they = use to monitor email delivery. Those probe networks can already give = them most of the same information that this would provide, without any = requirement for support by the receiving ISP. 2. Where in the delivery path does it detect errors, and whether = organizations causing errors are likely to deploy this sort of code It seems to be intended to detect DKIM-invalidating modifications "at = the receiver", as it's fairly easy for a sender to identify problems = that are near to them. Receivers who have a "non-DKIM-clean" delivery = path seem like the least likely receivers to add additional = DKIM/ADSP-specific baggage to their delivery path - so I'm not sure that = something like this would be likely to be deployed at the receiving ISPs = where the feedback would likely need to be generated. Unless it's = intended for MUA deployment, maybe? 3. Implementation nits 3a. Inconsistent flags for in-band reporting There are some nits too. You can ask for a magic cookie in the rejection = string using rs=3D - which is good, as that can be handled well by = existing delivery log monitoring tracking. But rs=3D is not valid unless = there's an r=3D field that's asking for reports to be sent to a specific = address. r=3D is being overloaded as both a boolean ("do some sort of = reporting") and as a parameter to one particular sort of reporting (via = sending an email). Unless that's there for backwards compatibility I'd = be tempted to split the two. 3b. Does this define an email address for reports, or just a local part? r=3D "MUST be a dkim-quoted-printable string containing an e-mail = address", yet it "MUST be interpreted as a local part only". The = examples tell me that it's just a local part, and doesn't have an "@" = sign in it, but the spec should probably be clarified. 4. Sampling may be useful, but probably not if it can only be applied = identically to all receivers I don't see ri=3D as being particularly useful given the way I expect = this would be used, as that value is shared across all receivers. I'm = either going to want a report about every failure, or I'm going to want = summary reports. If Gmail are having very rare DKIM failures on my mail = - one in a million, say - I'm going to want to see every one. If = Earthlink are breaking everything I send, I'm going to want summary = reports. I can't get both, so I'm going to end up leaving it set to "0" = and summarizing at my end. If it were in the format of "no more than X = reports every Y seconds" it might make more immediate sense than simply = reporting every n-th message, maybe. That would also avoid the problems = in 8.3 and would allow the sender more control over the issues in 8.5. 5. In-band advertising vs out-of-band vs overloading DKIM For many use cases this functionality could be handled by in-band = advertising (e.g. a "DKIM-Errors-To: foo@bar.com" header).=20 It could also be handled via a separate DNS lookup, rather than = overloading the existing DKIM key record. Does the increase in size of the DKIM key record cause significant cost = (especially in the case where it causes the already large key record to = expand so that it's over the size that can be efficiently / reliably = handled over UDP)? 6. Would something broader be more useful? This is very specific to DKIM or ADSP failures. If it is useful for the = sender to be notified of one sort of authentication failure, they'll = probably be interested in notification of other failures (SPF?). 7. Would something narrower be as useful? The rs=3D magic cookie in the rejection string seems like the most = useful part of this. At large ISPs almost all rejections are handled = during the SMTP session, and DKIM checking is happening at the external = MX, not at an internal handoff. Rather than specifying an out-of-band asynchronous notification via = email at all, would this concept be just as useful if it only included = the magic cookie in the rejection string? If so, then rather than adding flags to the DKIM record, could we just = ask receivers to put a magic cookie in their rejection string anyway = ("[AUTHFAIL=3DDKIM-bodyhash]"). If the answer to that involves ADSP, can we split this out to have DKIM = and ADSP handles separately? (If I were starting from scratch rather than doing something specific = for DKIM, I probably wouldn't add all this to the DKIM key record or the = ADSP record at all - I'd use a separate name space to stash the data in, = so that if you were to see a DKIM auth failure from me, you'd do a query = for "mta3.cloudmark.com.dkim._authenticationfailure.wordtothewise.com" = and do what that TXT record asked. Creative use of wildcarding would let = me set a general "I'd like to know about it" policy, while setting much = more verbose reporting while I was diagnosing delivery to a particular = recipient ISP. And I'd also be able to have = "*.spf._authenticationfailure.wordtothewise.com", = "*.adsp._authenticationfailure.wordtothewise.com" and so on. But that's = a whole other discussion.) Cheers, Steve From hfontana@ecertsystems.com Fri Sep 30 14:17: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 902B521F84F5 for ; Fri, 30 Sep 2011 14:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48KCoVE-sJNO for ; Fri, 30 Sep 2011 14:17:12 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A7AE521F84CE for ; Fri, 30 Sep 2011 14:17:12 -0700 (PDT) Received: by yxt33 with SMTP id 33so2390909yxt.31 for ; Fri, 30 Sep 2011 14:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecertsystems.com; s=google; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:disposition-notification-to; bh=xiQcmFoyGugSGzElosxrf3M465NMkY1gQsboMn6dYE0=; b=YdaEau8PIxSflzeql6ulmAy+Am/giWj5jgFYnH3v3nDGtX+LIyS7wP/anZDHp+KfHb Zuy7hmTjThwsriGJOoGuDpl1sYgO5EElfRBZ+klnSLH8Lccxwb23d6ExLKK50S9J/z/v SUxCQ/4JFw5GjqYv8exb7jidJu5xXatqvU8MM= Received: by 10.236.145.74 with SMTP id o50mr75054355yhj.36.1317417607355; Fri, 30 Sep 2011 14:20:07 -0700 (PDT) Received: from OwnerPC (vpn.ord.deteque.com. [204.93.238.72]) by mx.google.com with ESMTPS id r30sm7895277yhj.20.2011.09.30.14.20.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Sep 2011 14:20:06 -0700 (PDT) From: "Hilda Fontana" To: "'John Levine'" , References: <20110930185734.33110.qmail@joyce.lan> In-Reply-To: <20110930185734.33110.qmail@joyce.lan> Date: Fri, 30 Sep 2011 14:19:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH6y1LSW698N1BYJ6coZv7OGyB2qJUJ1LPw Content-Language: en-us Subject: Re: [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: Fri, 30 Sep 2011 21:17:13 -0000 John, Thanks for your comments. I disagree on a couple of points. First - the overall point of this is to be able to better report on authentication headers. If you are only doing dkim then the dkim reporting is probably a better bet than this one. This is meant to be the next step for marf for reporting authentication failures in a uniformed way. For 3.2.1 delivery result - you can default to other but the preference would be to keep it as a MUST Thanks H > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > John Levine > Sent: Friday, September 30, 2011 11:58 AM > To: marf@ietf.org > Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt > > Sorry not to get to this sooner. This draft has problems. It's not ready to > ship. > > Sec 3.1 says a report MUST include explicit auth results for both DKIM and > SPF. Well, no. I don't check SPF, so if people are only going to accept DKIM > failure reports if they also say something about SPF, they're not going to get > any reports from me. I expect people who check SPF but not DKIM feel the > same way, particularly for the large fraction of mail that has no DKIM > signatures to check. Suggest just removing this clause, and let people report > what they're reporting. > > Original-Envelope-ID and Original-Mail-From: same issue, they're not > relevant to DKIM, and by the time I check DKIM, it's often after SMTP is over > and the envelope isn't directly available. Suggest it say they SHOULD be > included if they are available. > > Source-IP: same problem. If you don't have the source IP, just leave it out, > don't lie. (And 0.0.0.0 is totally oldthink. The value I'm not going to include is > ::.) > > Message-ID: this is just wrong, RFC 5965 does not report it. > > 3.2.1: Delivery-result: what I do with my mail is none of your business. > This field has to be optional. > > 3.3: Why just spf rather than spf-fail, spf-softfail, spf-temperror, or spf- > permerror? If you're reporting an SPF problem, you presumably know what > your SPF checker returned. > > 4: SPF-DNS. If you're going to return a snapshot of the SPF record, shouldn't > you also return all the records it included? > > R's, > John > > > > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf From sklist@kitterman.com Fri Sep 30 15:10:41 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 4708121F8472 for ; Fri, 30 Sep 2011 15:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.841 X-Spam-Level: X-Spam-Status: No, score=-3.841 tagged_above=-999 required=5 tests=[AWL=-1.242, 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 7LUf+UouwarK for ; Fri, 30 Sep 2011 15:10:41 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id F396F21F846C for ; Fri, 30 Sep 2011 15:10:40 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id BA16638C101; Fri, 30 Sep 2011 18:13:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1317420815; bh=JgYUxzBHDkdq/t1GiaGJp9Fu6ZVp2husUarCUHvUp+0=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=pxRIMh2pwGAEpP8bWYB5kbFdM5VSp8agHL77bnj17fL6/bVhLv1p7a7Ik/YDJeCpi pjowC/QveumcYyn6zgWfsBIpT/GDDSDOYrz2UYlN8AMZRg3zsFdLHKBP8b+PFtya9d ngnSq/ODZvrXV05QQw6S+Z3NrxRfcSVU792Kctyc= From: Scott Kitterman To: marf@ietf.org Date: Fri, 30 Sep 2011 18:13:35 -0400 Message-ID: <23551164.Qt3FNA7XI6@scott-latitude-e6320> User-Agent: KMail/4.7.1 (Linux/3.0.0-12-generic-pae; KDE/4.7.1; i686; ; ) In-Reply-To: References: <20110930185734.33110.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [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: Fri, 30 Sep 2011 22:10:41 -0000 "If you are only doing dkim then the dkim reporting is probably a better bet than this one.": Currently the SPF draft covers only publishing informaton in DNS about requesting SPF based reports. All the informaiton about how to report the authentication failure is in this draft. The same is true for the DKIM draft, so I have no idea what that statement means. Making providing information about both technlogies when only one might be in use seems exactly backwards. Including information about SPF (or DKIM) when only DKIM (or SPF) are being used is going to be confusing at best. BTW, this confusion is not theoretical for me. I'm involved in one project where we get dummy data from one source that we know doesn't have it and so we have to use our out of band knowledge to hard code around this for that data source. It's a serious issue. Original-Envelope-Id, Original-Mail-From, Arrival-Date, Source-IP. Message-ID, and Reported-Domain are all optional in ARF. They should only be required here if they are relevant to the support understanding the information in the authentication results header. For example, Mail From is completely unrelated to DKIM an so there's no reason to include it in a DKIM related ARF. I think this draft needs a step back to allow reporting of only the authentication results one actually has and only the information relevant to that result. I've always found inclusion of delivery results in a message about auth failure a bit odd (seem somewhat orthogonal). If you're going to keep it required, you should probably add myob as an option (mind your own business) (not a serious proposal, but my guess is virtually all of these will be returned as "other"). Since most senders won't provide this type of information, I think it's senseless bloat to require the field. Does requiring the canonicalized header/body be included in the report obviate the ability to remove data as described in paragraph 5? I think the fact that these include data that one might want to redact is worth a mention in security considerations. Also, if one is going to redact and then re- canonicalize then providing the data is pointless. So if a sender wants to fully redact information there's no benefit to including them. They should only be included if they can be sent unmodified without violating the receiver's privacy requirements. Paragraph 5 could be reduced to a pointer to an appropriate security consideration in paragraph 7 and to the redaction draft. As long as it's clear the receiver needs to make sure the data they include complies with their privacy requirements (which I think belongs in security considerations) the rest it really off topic for this draft. Scott K On Friday, September 30, 2011 02:19:47 PM Hilda Fontana wrote: > John, > > Thanks for your comments. I disagree on a couple of points. > > First - the overall point of this is to be able to better report on > authentication headers. If you are only doing dkim then the dkim reporting > is probably a better bet than this one. This is meant to be the next step > for marf for reporting authentication failures in a uniformed way. > > For 3.2.1 delivery result - you can default to other but the preference > would be to keep it as a MUST > > Thanks > H > > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > John Levine > > Sent: Friday, September 30, 2011 11:58 AM > > To: marf@ietf.org > > Subject: Re: [marf] Comments on > > draft-ietf-marf-authfailure-report-01.txt > > > > Sorry not to get to this sooner. This draft has problems. It's not > > ready > to > > > ship. > > > > Sec 3.1 says a report MUST include explicit auth results for both DKIM > > and SPF. Well, no. I don't check SPF, so if people are only going to > > accept > DKIM > > > failure reports if they also say something about SPF, they're not going > > to > get > > > any reports from me. I expect people who check SPF but not DKIM feel > > the > > same way, particularly for the large fraction of mail that has no DKIM > > signatures to check. Suggest just removing this clause, and let people > > report > > > what they're reporting. > > > > Original-Envelope-ID and Original-Mail-From: same issue, they're not > > relevant to DKIM, and by the time I check DKIM, it's often after SMTP is > > over > > > and the envelope isn't directly available. Suggest it say they SHOULD > > be > > included if they are available. > > > > Source-IP: same problem. If you don't have the source IP, just leave it > > out, > > > don't lie. (And 0.0.0.0 is totally oldthink. The value I'm not going > > to > > include is > > > ::.) > > > > Message-ID: this is just wrong, RFC 5965 does not report it. > > > > 3.2.1: Delivery-result: what I do with my mail is none of your business. > > This field has to be optional. > > > > 3.3: Why just spf rather than spf-fail, spf-softfail, spf-temperror, or > > spf- > > > permerror? If you're reporting an SPF problem, you presumably know what > > your SPF checker returned. > > > > 4: SPF-DNS. If you're going to return a snapshot of the SPF record, > > shouldn't > > > you also return all the records it included? > > > > R's, > > John > > > > > > > > > > _______________________________________________ > > marf mailing list > > marf@ietf.org > > https://www.ietf.org/mailman/listinfo/marf > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf From johnl@taugh.com Fri Sep 30 18:39: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 49DEB21F8AE9 for ; Fri, 30 Sep 2011 18:39:24 -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=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-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 xNJf5b30cjSl for ; Fri, 30 Sep 2011 18:39:23 -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 7B93821F8AE6 for ; Fri, 30 Sep 2011 18:39:23 -0700 (PDT) Received: (qmail 5880 invoked from network); 1 Oct 2011 01:42:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=16f7.4e866ffa.k1109; bh=TQlDV7bqz1G4O2X3/JP6pgn57YwjgAjW4CyIE/bxuZU=; b=dBI2/qW9Wnk1DNqVwRAz54jVwRm/AmYAkhclxaUpnd5R81JOT0tW/vYzPYGcv+QdtBJE1bp+ZpuDJAorHnOwIcbvZAemr54f/viQJ3a+bOa/plE1P1RIoC3e2OicyKKn37E5u12VBQ0HvuFv8X7v2jcMiP4zaGO2bjlAqYXpgFo= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=16f7.4e866ffa.k1109; bh=TQlDV7bqz1G4O2X3/JP6pgn57YwjgAjW4CyIE/bxuZU=; b=B0K3p1MXpR++pErFpwGSTkHwb2QB15GHMjyMcUr9ha91Nl297qx6OQD9A/feie23fuoasZt2/R45fsK7JHW+gXmFxRTf0ugb9qDakXGIxheiZl0mfa01nm58gsVBvnMK9gyK4RpA/R10YykrePX605vL1Jq728ILbEkwZuUw3YI= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 1 Oct 2011 01:41:55 -0000 Date: 30 Sep 2011 21:42:17 -0400 Message-ID: From: "John R Levine" To: "Hilda Fontana" In-Reply-To: References: <20110930185734.33110.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: ARF mailing list Subject: Re: [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: Sat, 01 Oct 2011 01:39:24 -0000 > First - the overall point of this is to be able to better report on > authentication headers. If you are only doing dkim then the dkim reporting > is probably a better bet than this one. This is meant to be the next step > for marf for reporting authentication failures in a uniformed way. > > For 3.2.1 delivery result - you can default to other but the preference > would be to keep it as a MUST I think you're misunderstanding what a standard is. It says, if you want to interoperate with other people, here's how you do it. No IETF standard can ever force people to do anything they don't want to. So if it says you MUST return a delivery result, what you're actually saying is that if you're not going to send a delivery result, don't bother to send anything. You would probably prefer to get some reports than no reports, so MUST is utterly counterproductive. I also note it is fairly common for people simply to ignore parts of standards they think are silly, so no matter what you say, people will send reports with only DKIM info for DKIM failures, only SPF info for SPF failures, and no delivery results. Experience suggests that successful standards are written to maximize the likelihood that people will implement them as written, so you don't write requirements that are likely to be ignored. It appears we all agree that some things in the draft are just wrong, like the Message-ID, so this draft needs to recycle at least once more. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly.