From vesely@tana.it Fri Jul 1 02:05:29 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E8521F88C2 for ; Fri, 1 Jul 2011 02:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.032 X-Spam-Level: X-Spam-Status: No, score=-5.032 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wYT6Wc6Nqqt for ; Fri, 1 Jul 2011 02:05:28 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 023E221F88C3 for ; Fri, 1 Jul 2011 02:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1309511126; bh=gI5FY+StetDs/8mI250ZH+ZkxeeuyVkLstiqwnH4Q9I=; l=2268; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Qusz4lKWiQeQYX9ck4X2BoD2hnFNa5zzEp9gEq7eeNtlhnskgjFrM6+QDJix2VZC4 dOEJNzZ2pYPoJZmSYVk4fwQgnWoy86y3WMzg6byQjZSDaToih8xaLXigt4H4ePAmMB ohZju3sLc2LFeVgmItBsEPTEilYSo93FzPdQv2qs= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 01 Jul 2011 11:05:26 +0200 id 00000000005DC039.000000004E0D8DD6.00002CF1 Message-ID: <4E0D8DD6.3030501@tana.it> Date: Fri, 01 Jul 2011 11:05:26 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: marf@ietf.org References: <20110623192929.13813.qmail@joyce.lan> <4E04B896.5010604@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Abuse reporting, was draft-jdfalk-marf-as 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, 01 Jul 2011 09:05:29 -0000 On 29/Jun/11 19:42, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: ietf.org On Behalf Of Alessandro Vesely >> >> I think a document is needed in order to state the "obvious" facts >> that RIRs don't have the scope for discussing. Since JD said it >> cannot be part of the FBL AS, we'd probably better write a new one. >> >> Is it possible to do so? > > We'd have to recharter to do it. For now if you want to get > started, post it as an individual submission, and later we can > consider rechartering to take it on. Hm, the charter provides for an "ARF guidelines document". Couldn't this non-FBL guidelines be considered a part of a multi-part document, together with the FBL AS, the cfblbcp, and the redaction docs? Anyway, I'll try and post an individual submission if you think that's the right thing to do. > Also, John pointed you at the WEIRDS pre-working-group list. ICANN > people approached me about starting that effort up, and right now > they're exploring requirements. There will probably be a bar BoF > at the Quebec City conference next month followed by a lobby to > create a working group later on once they get some momentum going. Hmm, the concluded Web Elucidation of Internet-Related Developments has nothing to do with this, has it? IETF's "concluded" page also mentions a Whois and Network Information Lookup Service concerned with a historical son-of-WHOIS protocol... > It's true that any standard we produce won't compel a WHOIS > provider to give out information it doesn't want to make available, > but ICANN does have a little more stomping power on registrars than > the IETF does. It seems ARIN, APNIC, LACNIC, and RIPE already have abuse team contacts, and are possibly adjusting related procedures, such as removing query rate limits. AfriNIC is apparently discussing that. It is still unclear who should do what in this evolving scenario. There are lots of web pages entitled something like How To Complain To The Spammer's Provider, most of which are reminiscent of a time when there were no means to automate abuse reporting. Updating such documentation is clearly out of WHOIS providers' scope. What is this WG's opinion about such an additional document? From vesely@tana.it Fri Jul 1 02:05: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 50A9E21F8745 for ; Fri, 1 Jul 2011 02:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.654 X-Spam-Level: X-Spam-Status: No, score=-4.654 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reWA5e8W8VEg for ; Fri, 1 Jul 2011 02:05:54 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5213921F8743 for ; Fri, 1 Jul 2011 02:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1309511153; bh=5jW3mgX9a4rJEXrfepLOTuSP7dtnNjyVIRYbspzsBoU=; l=961; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=VamDAYC4ILtUuIdht4F7byQvOugIosEL2cGnczoWHNWkx0BDCyNXUEzcFfcpyZVlt hE1/QmzbMR0ub/sdGmsirWKrp6oYHNQ5elsI21Rc2JFIegZyxfhnVS/0rt7Hsxbo9B E0H9IOIzhKQ9TzylbibEgJMsjpbk4IF4MsA/r1As= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 01 Jul 2011 11:05:53 +0200 id 00000000005DC039.000000004E0D8DF1.00002F55 Message-ID: <4E0D8DF1.2090908@tana.it> Date: Fri, 01 Jul 2011 11:05:53 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: marf@ietf.org References: <20110628220409.17100.29803.idtracker@ietfa.amsl.com> <4E0B35DB.10402@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-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, 01 Jul 2011 09:05:55 -0000 On 30/Jun/11 19:35, Hilda Fontana wrote: > On Wed, Jun 29, 2011 at 7:25 AM, Alessandro Vesely > wrote: > > [...]For example, "dkim=none" means the message had no signature. > > IMHO, the simplest specification is that the feedback-report part > contains just the triggering A-Rs, whether or not they are also > present in the message/rfc822 part of the report. > > for automation it would be useful for the headers to be standard - so > if dkim was not checked perhaps dkim="" would be preferable to > dkim=none - to your point above but I think its worth including to try > to standardize the format I don't see how having dkim="" benefits automation. Its meaning could be inferred from the absence of any dkim methodspec. Using empty result values yields Authentication-Results header fields different from those that verifiers SHOULD produce, see http://tools.ietf.org/html/rfc5451#section-2.4 From johnl@iecc.com Fri Jul 1 07:04: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 E102311E812C for ; Fri, 1 Jul 2011 07:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.712 X-Spam-Level: X-Spam-Status: No, score=-109.712 tagged_above=-999 required=5 tests=[AWL=1.487, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3cFIAwUM4Yp for ; Fri, 1 Jul 2011 07:04:09 -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 EA9711F0C85 for ; Fri, 1 Jul 2011 07:03:35 -0700 (PDT) Received: (qmail 35549 invoked from network); 1 Jul 2011 14:03:32 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 1 Jul 2011 14:03:32 -0000 Received: (qmail 56727 invoked from network); 1 Jul 2011 14:03:32 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 1 Jul 2011 14:03:32 -0000 Date: 1 Jul 2011 14:03:10 -0000 Message-ID: <20110701140310.81713.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] I-D Action: draft-ietf-marf-authfailure-report-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, 01 Jul 2011 14:04:10 -0000 Having taken another look at the document, I would restructure it so that it reports all of the authentication results for the message. A single message can easily have an SPF result and two or three DKIM results, and possibly an ADSP result which is separate from any DKIM results. In a typical FBL keyed by IP address, the sender would be interested in all of these. As far as the delivery status, you can ask, but no sensible person will tell you since the primary utility for asking whether a message was delivered is to tune mail to avoid spam filters. R's, John From internet-drafts@ietf.org Sat Jul 2 19:24:26 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 920B211E80BC; Sat, 2 Jul 2011 19:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9co0YhFvIbQt; Sat, 2 Jul 2011 19:24:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353971F0C51; Sat, 2 Jul 2011 19:24: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.55 Message-ID: <20110703022426.13341.7846.idtracker@ietfa.amsl.com> Date: Sat, 02 Jul 2011 19:24:26 -0700 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-not-spam-feedback-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, 03 Jul 2011 02:24:26 -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-00.txt Pages : 7 Date : 2011-07-02 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-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-not-spam-feedback-00.txt From barryleiba.mailing.lists@gmail.com Sat Jul 2 19:30:16 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA5A11E80BC for ; Sat, 2 Jul 2011 19:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.144 X-Spam-Level: X-Spam-Status: No, score=-103.144 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C09UVJXlOE6z for ; Sat, 2 Jul 2011 19:30:16 -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 D23B411E80B1 for ; Sat, 2 Jul 2011 19:30:15 -0700 (PDT) Received: by gyd5 with SMTP id 5so339868gyd.31 for ; Sat, 02 Jul 2011 19:30:15 -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=YBDkW7uezt1N5egTSGivQrJhF8ydaZr5hRLU1DLHaOg=; b=aYcpvqoTYPcrIbZiuv5PemYMTn02ZpDl3FYpqWzlfKXUa7FAETzGQ7H4JzX7Oa45dz wP87Q3vuhyFJnzLuSyvlvCxcMSg7jchHzs44HsWgvMnUSGP0IsjHZvNUOPxhaLGdu/Gh 0GctisKpEQb12xR3g4yRm6KB84zbRa0U+fCnM= MIME-Version: 1.0 Received: by 10.236.157.197 with SMTP id o45mr1318630yhk.44.1309660214411; Sat, 02 Jul 2011 19:30:14 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.32.4 with HTTP; Sat, 2 Jul 2011 19:30:14 -0700 (PDT) In-Reply-To: <20110703022426.13341.7846.idtracker@ietfa.amsl.com> References: <20110703022426.13341.7846.idtracker@ietfa.amsl.com> Date: Sat, 2 Jul 2011 22:30:14 -0400 X-Google-Sender-Auth: LjH7XZxeJl_pASlT-eb0ybowynM Message-ID: From: Barry Leiba To: marf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [marf] I-D Action: draft-ietf-marf-not-spam-feedback-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, 03 Jul 2011 02:30:16 -0000 We've added the subject draft as a working-group item, and I've incorporated all the feedback so far. > =A0 This document defines a new Abuse Reporting Format (ARF) feedback > =A0 report type value: "not-spam". =A0It can be used to report = a message > =A0 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-00.= txt J.D., does this satisfy your concerns about the tone? And Brett, I've added a DKIM signature to the example (thanks, Murray), and included a note about that and a pointer to the security considerations. Are there any other comments on this? Or are we already set to go now? Reviews, please. Barry From vesely@tana.it Sun Jul 3 03:13: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 D806121F8762 for ; Sun, 3 Jul 2011 03:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.847 X-Spam-Level: X-Spam-Status: No, score=-4.847 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cYUklBckkfY for ; Sun, 3 Jul 2011 03:13:25 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3E621F875C for ; Sun, 3 Jul 2011 03:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1309688003; bh=FAo8DbAhGMnYOLPLAl+DEGIeWh0w+0T+hi2608QvWBg=; l=2157; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=M03aEzeUtVuW29PCtP5EtYPmhMqo/WN+Oqxo0S3zvaH7hZCiVk22guxH8a2u2bTuL 7dc7PJaaHt1Nfu5P9L4j0KAjPDvZ6eluEgfa7nOa6Gf2RzzO2fIdhdoZM296c8CoGd fCxR1u0VkoUWBGl3CKSzDWWjdPeAB3njVTDyBAPo= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 03 Jul 2011 12:13:23 +0200 id 00000000005DC033.000000004E1040C3.00001A89 Message-ID: <4E1040C2.2080508@tana.it> Date: Sun, 03 Jul 2011 12:13:22 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: marf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 03 Jul 2011 10:13:26 -0000 On 31/Mar/11 09:09, Murray S. Kucherawy wrote: > On 31/Mar/11 09:03, Hilda Fontana wrote: >> On Wed, Mar 30, 2011 at 3:52 AM, Murray S. Kucherawy wrote: >> >>> The consensus at our IETF 80 meeting was to divide the DKIM >>> reporting draft into smaller documents. I believe the split >>> should go as follows: >>> >>> - Defining the auth-failure report type (someone besides me >>> should take up authorship of this, but I’ll do it if nobody >>> steps up) >> >> what does it mean "Defining the auth-failure report type" with >> DKIM, SPF and Redaction not included? > > One document would register the changes to DKIM and ADSP (i.e. the > updates to the registered lists of tags and values) and one would > register the new ARF report type. The two documents can be published > simultaneously and refer to each other. I should have raised this issue some months ago, but I hadn't clearly understood the details of the splitting at the time. One the one hand, the SPF and DKIM method-extensions include similar text, thereby making it harder to change any of those parts. On the other hand, the ARF extension mentions DKIM and SPF details again and again, resulting in tight coupling with each method-extension. Alternatively, the ARF extension could list what a method extension must do in order to define and register the details of failure-reporting for the specific authentication method it addresses. I mentioned this possibility in a recent message of mines, but nobody apparently cares. I'm confused, or perhaps it's just July... Which of the following, if any, is correct? A The ARF extension will gain in comprehensibility by removing any method-specific detail. Since that's where admins may eventually look for deciding whether to enable such feature in their software, it is better to have it uncluttered. BTW, why don't we also split dkim-adsp from dkim? B The splitting is fine as it is, although not in a "normal form". It is extremely unlikely that "iprev" or any other method will ever need a failure reporting mechanism. The sooner we go to testing and deploying, the better. From bmcdowell@paypal-inc.com Tue Jul 5 06:36: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 04DFB21F85EC for ; Tue, 5 Jul 2011 06:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8Lxwn4gOc9j for ; Tue, 5 Jul 2011 06:36:38 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by ietfa.amsl.com (Postfix) with ESMTP id 91ED321F8510 for ; Tue, 5 Jul 2011 06:36:14 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:Date: Subject:Thread-Topic:Thread-Index:Message-ID:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:user-agent:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=faA3b8cGR6RDDbmEluJ43zXpkobmeC0RjoNMWqjCQqO1Q4ox24lLfdLY TPXTgi3ypRdrU6gxNhRZD4IgP4VLzomvcCh0Qk28DxVEvc9tsAVZkGsMq B1B7tcQ1Wbfdcuo; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bmcdowell@paypal-inc.com; q=dns/txt; s=ppinc; t=1309872975; x=1341408975; h=from:to:date:subject:message-id:in-reply-to: content-transfer-encoding:mime-version; bh=n1ost/C3OEWofncdZn6vatmDGVNJDE2TNWDv6uObYVY=; b=sASB8KbmBMCqCKkgXJShutxixNaOLl0H5mnCirhhc/xzu86z/IzUZ2lg 4cPgs80r61l6H8Kp7J68anLJB+J4fN7IdkzHoaLalpjwlIF3aQmiO6owZ MmINwCT8RSGSEAZ; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.65,479,1304319600"; d="scan'208";a="3085422" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-003.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 05 Jul 2011 06:36:14 -0700 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-003.corp.ebay.com ([10.241.17.54]) with mapi; Tue, 5 Jul 2011 07:36:13 -0600 From: "McDowell, Brett" To: Barry Leiba , "marf@ietf.org working group" Date: Tue, 5 Jul 2011 07:36:11 -0600 Thread-Topic: [marf] I-D Action: draft-ietf-marf-not-spam-feedback-00.txt Thread-Index: Acw7GIHAhQ4e8/VoRpqcY3puCUSbCg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: RH2ArrZIHXM+0W0Rc6V8gQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [marf] I-D Action: draft-ietf-marf-not-spam-feedback-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, 05 Jul 2011 13:36:39 -0000 On 7/2/11 10:30 PM, "Barry Leiba" wrote: >We've added the subject draft as a working-group item, and I've >incorporated all the feedback so far. > >> 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. >> >> A URL for this Internet-Draft is: >>=20 >>http://www.ietf.org/internet-drafts/draft-ietf-marf-not-spam-feedback-00. >>txt > >J.D., does this satisfy your concerns about the tone? And Brett, I've >added a DKIM signature to the example (thanks, Murray), and included a >note about that and a pointer to the security considerations. Thanks Barry (and Murray). > >Are there any other comments on this? Not from me. > Or are we already set to go >now? Reviews, please. From hfontana@ecertsystems.com Tue Jul 5 09:12:23 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 1D21511E80F3 for ; Tue, 5 Jul 2011 09:12:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLPOeCLt5kAh for ; Tue, 5 Jul 2011 09:12:22 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9C07222800F for ; Tue, 5 Jul 2011 09:12:03 -0700 (PDT) Received: by pzk5 with SMTP id 5so2321868pzk.31 for ; Tue, 05 Jul 2011 09:12:03 -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=6ujA1acsJwCinDBX0hU70RIBb8Iuf2/vX1mLEj/fgjY=; b=cjzZv2ntIcpvGDC1jx3CLALq6an3R2Z16103YrEuwMraq0CRQnvStLOGKbB2Ef8tua FzJbEHg1G27BkrYa0QQv5uX52pEccCGrqzA+LHhkNSExRF+goTfHVZkfB8bPOn21J+6J ZaHq45EtPvFRgRndfCFlH/l4FwecLOAxjhuDg= Received: by 10.68.27.69 with SMTP id r5mr8173143pbg.382.1309882322801; Tue, 05 Jul 2011 09:12:02 -0700 (PDT) Received: from OwnerPC (99-116-250-186.lightspeed.irvnca.sbcglobal.net [99.116.250.186]) by mx.google.com with ESMTPS id n8sm4511969pbh.89.2011.07.05.09.12.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Jul 2011 09:12:02 -0700 (PDT) From: "Hilda Fontana" To: "'Alessandro Vesely'" , References: <4E1040C2.2080508@tana.it> In-Reply-To: <4E1040C2.2080508@tana.it> Date: Tue, 5 Jul 2011 09:11:58 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJGQn+A9NdwEHuaVI1/hpfQVw1GLAFdsbapAMa50X0BuRv9kZPK6v8w Content-Language: en-us Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 05 Jul 2011 16:12:23 -0000 Not sure I follow what your asking? =20 -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of = Alessandro Vesely Sent: Sunday, July 03, 2011 3:13 AM To: marf@ietf.org Subject: [marf] Cohesion of authfailure-report, was Split of = dkim-reporting draft On 31/Mar/11 09:09, Murray S. Kucherawy wrote: > On 31/Mar/11 09:03, Hilda Fontana wrote: >> On Wed, Mar 30, 2011 at 3:52 AM, Murray S. Kucherawy wrote: >>=20 >>> The consensus at our IETF 80 meeting was to divide the DKIM=20 >>> reporting draft into smaller documents. I believe the split should=20 >>> go as follows: >>>=20 >>> - Defining the auth-failure report type (someone besides me >>> should take up authorship of this, but I=E2=80=99ll do it if = nobody=20 >>> steps up) >>=20 >> what does it mean "Defining the auth-failure report type" with DKIM,=20 >> SPF and Redaction not included? > > One document would register the changes to DKIM and ADSP (i.e. the=20 > updates to the registered lists of tags and values) and one would=20 > register the new ARF report type. The two documents can be published=20 > simultaneously and refer to each other. I should have raised this issue some months ago, but I hadn't clearly = understood the details of the splitting at the time. One the one hand, the SPF and DKIM method-extensions include similar = text, thereby making it harder to change any of those parts. On the = other hand, the ARF extension mentions DKIM and SPF details again and = again, resulting in tight coupling with each method-extension. Alternatively, the ARF extension could list what a method extension must = do in order to define and register the details of failure-reporting for = the specific authentication method it addresses. I mentioned this possibility in a recent message of mines, but nobody = apparently cares. I'm confused, or perhaps it's just July... ?? in what way are you suggesting? Which of the following, if any, is correct? A The ARF extension will gain in comprehensibility by removing any method-specific detail. Since that's where admins may eventually look for deciding whether to enable such feature in their software, it is better to have it uncluttered. BTW, why don't we also split dkim-adsp from dkim? B The splitting is fine as it is, although not in a "normal form". It is extremely unlikely that "iprev" or any other method will ever need a failure reporting mechanism. The sooner we go to testing and deploying, the better. ?not in a normal form? _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From hfontana@ecertsystems.com Tue Jul 5 09:13: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 8056421F870F for ; Tue, 5 Jul 2011 09:13:24 -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, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P40s7o3i3-5m for ; Tue, 5 Jul 2011 09:13:24 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id B786721F8672 for ; Tue, 5 Jul 2011 09:13:23 -0700 (PDT) Received: by pvh18 with SMTP id 18so8116216pvh.31 for ; Tue, 05 Jul 2011 09:13:23 -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=3QAS9iZ01cf/fK9vyg5lyzVmXCrXvgPQYZ1Zv1K4E2k=; b=Rygv9ouJWD2qDfh0Qoq5QDZQUxlv+ZbgXZ/3psabhMlmWCqBcFd6m8MjL97Lyoug1y VLj8V2m+IoIRyOHEayYyd2l584JuGW8EPXf1Y7BHmjrJS/x77f8D+L54m0Qk9HCVi0wq 70H7cNoLFyZzn9gVD/TC28QQVl18jpXB/S+HI= Received: by 10.68.25.74 with SMTP id a10mr9228396pbg.78.1309882403280; Tue, 05 Jul 2011 09:13:23 -0700 (PDT) Received: from OwnerPC (99-116-250-186.lightspeed.irvnca.sbcglobal.net [99.116.250.186]) by mx.google.com with ESMTPS id v9sm2545250pbm.47.2011.07.05.09.13.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Jul 2011 09:13:22 -0700 (PDT) From: "Hilda Fontana" To: "'Alessandro Vesely'" , References: <20110628220409.17100.29803.idtracker@ietfa.amsl.com> <4E0B35DB.10402@tana.it> <4E0D8DF1.2090908@tana.it> In-Reply-To: <4E0D8DF1.2090908@tana.it> Date: Tue, 5 Jul 2011 09:13:18 -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: AQJ31Znbl3Gm1gIgzL3hXU8cBJNX9wIFPhd+AQKygH0CxDDHNAIYo59fk0eLUKA= Content-Language: en-us Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-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, 05 Jul 2011 16:13:24 -0000 It helps automation in that you know to always expect it - rather than the way the headers come now where the headers that may appear are not standard -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Alessandro Vesely Sent: Friday, July 01, 2011 2:06 AM To: marf@ietf.org Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-00.txt On 30/Jun/11 19:35, Hilda Fontana wrote: > On Wed, Jun 29, 2011 at 7:25 AM, Alessandro Vesely > wrote: > > [...]For example, "dkim=none" means the message had no signature. > > IMHO, the simplest specification is that the feedback-report part > contains just the triggering A-Rs, whether or not they are also > present in the message/rfc822 part of the report. > > for automation it would be useful for the headers to be standard - so > if dkim was not checked perhaps dkim="" would be preferable to > dkim=none - to your point above but I think its worth including to try > to standardize the format I don't see how having dkim="" benefits automation. Its meaning could be inferred from the absence of any dkim methodspec. Using empty result values yields Authentication-Results header fields different from those that verifiers SHOULD produce, see http://tools.ietf.org/html/rfc5451#section-2.4 _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From hfontana@ecertsystems.com Tue Jul 5 09:14:49 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D554C11E80B8 for ; Tue, 5 Jul 2011 09:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hwUnbEQv-nP for ; Tue, 5 Jul 2011 09:14:49 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7F06722801D for ; Tue, 5 Jul 2011 09:14:47 -0700 (PDT) Received: by pzk5 with SMTP id 5so2324724pzk.31 for ; Tue, 05 Jul 2011 09:14: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=l0aiMuOGh1v1WzS88oh504TjdRf3vtNXPLHBkyniC0w=; b=AWpVvjPNe1GocC6JppSciKTXGmHzTpRQ8VpuEZ/MMFXuj4OIy+f4nWPO9gihCKBANp BMdLxw73A7mH3+rBElBX3ol4oveGEOppEoztYcfLOFHfB6tNdqbuxYmbZux8CL1uuss1 a06SpRUUQ5Io0hZ9WNtIC66i6wW/3jSWnOwi4= Received: by 10.68.23.100 with SMTP id l4mr8179935pbf.358.1309882487166; Tue, 05 Jul 2011 09:14: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 n8sm4520269pbh.25.2011.07.05.09.14.45 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Jul 2011 09:14:46 -0700 (PDT) From: "Hilda Fontana" To: "'John Levine'" , References: <20110701024813.95769.qmail@joyce.lan> In-Reply-To: <20110701024813.95769.qmail@joyce.lan> Date: Tue, 5 Jul 2011 09:14:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKJe8kS5BmMlyvcY+sRpNuzjmybjZNjZZPA Content-Language: en-us Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-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, 05 Jul 2011 16:14:50 -0000 Apologies for the footers - will not include on the mailing lists=20 Thanks H -----Original Message----- From: John Levine [mailto:johnl@taugh.com]=20 Sent: Thursday, June 30, 2011 7:48 PM To: marf@ietf.org Cc: hfontana@ecertsystems.com Subject: Re: [marf] I-D Action: = draft-ietf-marf-authfailure-report-00.txt >This is the first draft of the split out document for the ARF = reporting. >Please review and let me know how best to improve it. Well, OK. >CONFIDENTIALITY NOTICE > >The information contained in this e-mail and any attachments is=20 >CONFIDENTIAL and is intended only for the use of the addressee. Any=20 >unauthorized use, disclosure, distribution, dissemination, or copying=20 >is strictly prohibited and may be unlawful. If you are not the intended = >recipient, you are prohibited from any further viewing of the e-mail or = >any attachments or from making any use of the e-mail or attachments. If = >you believe you have received this e-mail in error, please notify us=20 >immediately and permanently delete the e-mail, any attachments, and all = >copies from any drives or storage media and destroy any printouts of=20 >the e-mail or attachments and any copies of such printouts. Thank you = for your cooperation. Sorry, never mind. R's, John From jdfalk-lists@cybernothing.org Tue Jul 5 10:57: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 253A321F891F for ; Tue, 5 Jul 2011 10:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GW4yMg9EIi5Z for ; Tue, 5 Jul 2011 10:57:43 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1005521F8921 for ; Tue, 5 Jul 2011 10:57:42 -0700 (PDT) Received: from [192.168.11.32] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p65HvZWr010422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 5 Jul 2011 10:57:40 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p65HvZWr010422 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1309888661; bh=S8n0o59LATXIAphxlBgFJHtOJitHKXa59sI5dXoCD og=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=ZfM0ZOsa4lUS uYSPQyGE4AUFatqeqY9WxTF8TKX4hJDn3HH5r8267xkoEi7JayQe8txnQksVz5+FXTV QW4vljaUoNmoclZcC5ViKr5z3JjBtqLzU9qTHCWV0ok96iRlUUQwmy2tppNNLMdMIl+ NhjkxXBVFAVXO2v3g7c9r8AIM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: <4E0D8DD6.3030501@tana.it> Date: Tue, 5 Jul 2011 10:57:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110623192929.13813.qmail@joyce.lan> <4E04B896.5010604@tana.it> <4E0D8DD6.3030501@tana.it> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] Abuse reporting, was draft-jdfalk-marf-as 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, 05 Jul 2011 17:57:44 -0000 On Jul 1, 2011, at 2:05 AM, Alessandro Vesely wrote: > It is still unclear who should do what in this evolving scenario. > There are lots of web pages entitled something like How To Complain To > The Spammer's Provider, most of which are reminiscent of a time when > there were no means to automate abuse reporting. Updating such > documentation is clearly out of WHOIS providers' scope. >=20 > What is this WG's opinion about such an additional document? The problem is, it's already cross-functional /and/ it will refer to = things like WEIRDS which are currently in the early stages of = development. So it's a moving target on many axes. Maybe ASRG? -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From msk@cloudmark.com Tue Jul 5 10:59:59 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8268921F8934 for ; Tue, 5 Jul 2011 10:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.228 X-Spam-Level: X-Spam-Status: No, score=-103.228 tagged_above=-999 required=5 tests=[AWL=-0.628, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLGr45FUTAzj for ; Tue, 5 Jul 2011 10:59:58 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEC721F8933 for ; Tue, 5 Jul 2011 10:59:58 -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, 5 Jul 2011 10:59:58 -0700 From: "Murray S. Kucherawy" To: Alessandro Vesely , "marf@ietf.org" Date: Tue, 5 Jul 2011 10:59:57 -0700 Thread-Topic: [marf] I-D Action: draft-ietf-marf-authfailure-report-00.txt Thread-Index: Acw3zhtsIWwWR2hTTCepyKVZA7IxngDby2rw Message-ID: References: <20110628220409.17100.29803.idtracker@ietfa.amsl.com> <4E0B35DB.10402@tana.it> <4E0D8DF1.2090908@tana.it> In-Reply-To: <4E0D8DF1.2090908@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-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, 05 Jul 2011 17:59:59 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Friday, July 01, 2011 2:06 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-00.txt >=20 > I don't see how having dkim=3D"" benefits automation. Its meaning could > be inferred from the absence of any dkim methodspec. +1. From jdfalk-lists@cybernothing.org Tue Jul 5 11:00:18 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6C921F8938 for ; Tue, 5 Jul 2011 11:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bWAdPuerPQg for ; Tue, 5 Jul 2011 11:00:17 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id E522F21F891B for ; Tue, 5 Jul 2011 11:00:11 -0700 (PDT) Received: from [192.168.11.32] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p65I05VL010662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 5 Jul 2011 11:00:10 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p65I05VL010662 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1309888811; bh=SboxAkST7I4K/fDo3lB7+YkMdnKIfbApp6FASJqQj XI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=V46oHYwZ2PkS aRf0A1nS5lX1ngYjZnzfRSqtfe/Tt7ivYmJAJ1Qd2uZZU2W0fbuubY3AUX4Zx5bkU2H RL+iIX65gXix+3/TMQvE0V62RUpjBekASJJn0XDXunIhCncMT8Oku8Dan4EQEltH21k FLuhZ89tZUSyFsNeXPGNruxVE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: Date: Tue, 5 Jul 2011 11:00:04 -0700 Content-Transfer-Encoding: 7bit Message-Id: <7AE81DC2-D192-4040-9D42-411993A9D7CC@cybernothing.org> References: <20110703022426.13341.7846.idtracker@ietfa.amsl.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] I-D Action: draft-ietf-marf-not-spam-feedback-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, 05 Jul 2011 18:00:18 -0000 On Jul 2, 2011, at 7:30 PM, Barry Leiba wrote: > J.D., does this satisfy your concerns about the tone? And Brett, I've > added a DKIM signature to the example (thanks, Murray), and included a > note about that and a pointer to the security considerations. > > Are there any other comments on this? Or are we already set to go > now? Reviews, please. Looks good to me. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From vesely@tana.it Tue Jul 5 11:00: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 42C6721F8939 for ; Tue, 5 Jul 2011 11:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.826 X-Spam-Level: X-Spam-Status: No, score=-4.826 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSPz998hZakn for ; Tue, 5 Jul 2011 11:00:18 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 26A7621F8937 for ; Tue, 5 Jul 2011 11:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1309888815; bh=AV2hDKr4XFbWQMSJLZa35nn1V62FahOsIUU5RGWXeLk=; l=2299; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=KJUP7N3GeFSVWm6xm5WN0zz1FpdZTIPbnRhZ0EegJjeoXVrkeYuOKMduaOeb1fCmX 3rmiGJuf+wGXcfZ2SBoDDwM7ZdjomiVev3BESGbU9fJCL2qhUlLTr69QGXntv7/o5D pmscjqSz2aBK0BbmGXOcLY+sR2hYNVlmqtecC1BU= 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, 05 Jul 2011 20:00:15 +0200 id 00000000005DC035.000000004E13512F.00003A2F Message-ID: <4E13512E.2050204@tana.it> Date: Tue, 05 Jul 2011 20:00:14 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Hilda Fontana References: <4E1040C2.2080508@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: marf@ietf.org Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 05 Jul 2011 18:00:20 -0000 Hi Hilda, On 05/Jul/11 18:11, Hilda Fontana wrote: > Not sure I follow what your asking? Hm... my English is what it is, please be patient :-) >> Alternatively, the ARF extension could list what a method >> extension must do in order to define and register the details of >> failure-reporting for the specific authentication method it >> addresses. > > ?? in what way are you suggesting? Roughly, a section more or less like X.Y.Z. Definition and Registration of Method-Specific Extensions The IANA maintains a registry of Email Authentication Methods along with their possible results. A "method-specific extension" extends an authentication method by providing for the possibility to report its result using the ARF format specified in this document. Any such extension must specify: * which method(s) it addresses; * which result(s) of the addressed method(s) deserve being reported; * a list of one or more keywords to be used in the Auth-Failure field when reporting such results; and * the location and the syntax of the report parameters whose semantic content is described in Section U.V.W. In addition, a method-specific extension may define further ARF header fields. In case it does so, it shall also define the corresponding updates to ARF header field names in its IANA Considerations section. Section U.V.W would discuss r, rf, and ri, and possibly mention ro and rs too. Not how they are syntactically encoded, just what they mean. Does the above make sense? >> B The splitting is fine as it is, although not in a "normal >> form". It is extremely unlikely that "iprev" or any other >> method will ever need a failure reporting mechanism. The >> sooner we go to testing and deploying, the better. > > ?not in a normal form? "Normal" in the sense of orthogonal or perpendicular; that is, having independent semantics along the "axes". Basically, I mean loosely coupled with the method extensions. Indeed, I think authfailure-report can be written without mentioning neither "dkim" nor "spf", except for possible examples. I guess that would enhance comprehensibility. However, the WG should decide whether to go this way _before_ delving into any finer tuning, if it's not too late already. From sklist@kitterman.com Tue Jul 5 11:19: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 F313D21F8999 for ; Tue, 5 Jul 2011 11:19:20 -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] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZTqBsW5nSjB for ; Tue, 5 Jul 2011 11:19:20 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3331A21F8998 for ; Tue, 5 Jul 2011 11:19:20 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id CEE7C38C12D; Tue, 5 Jul 2011 14:19:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1309889958; bh=266UO6BuvhgUB5fECgiylsi91jExPFcKngnJa8Kzf3Q=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=SbR6kreHyHB7I1iLXCRN6rtOd6mr16weUKzwUoU53dJsFbKeFtx20Av0lK+tna001 jON0jOoYCRFaGgXZA0uvZ3Y8Jqe+gWmUP0yI+yeCVXgfkcJyePbYzRnUeW2XFv2vvU 6ZuebJymHeLMKiJWGojSOMATMwDcvYRVe/V9vo0A= From: Scott Kitterman To: marf@ietf.org Date: Tue, 5 Jul 2011 14:18:59 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic-pae; KDE/4.6.2; i686; ; ) References: <20110628220409.17100.29803.idtracker@ietfa.amsl.com> <4E0D8DF1.2090908@tana.it> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107051418.59473.sklist@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-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, 05 Jul 2011 18:19:21 -0000 On Tuesday, July 05, 2011 01:59:57 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Alessandro Vesely Sent: Friday, July 01, 2011 2:06 AM > > To: marf@ietf.org > > Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-00.txt > > > > I don't see how having dkim="" benefits automation. Its meaning could > > be inferred from the absence of any dkim methodspec. > > +1. +1 from me too. Scott K From hfontana@ecertsystems.com Tue Jul 5 11:25: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 1D74E21F88CF for ; Tue, 5 Jul 2011 11:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJLiwZTYSD8m for ; Tue, 5 Jul 2011 11:25:53 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C83C21F88CD for ; Tue, 5 Jul 2011 11:25:53 -0700 (PDT) Received: by pvh18 with SMTP id 18so8270055pvh.31 for ; Tue, 05 Jul 2011 11:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecertsystems.com; s=google; h=from:to:cc: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=CdD3iQ0d89aNYRETPyFi/xBVXw3hcdArt1JZFLwm3KQ=; b=gQlBAVi6AJo5M91w2eaQHAAMBoiy3PlzDyWgqq/C26f1/j1xRPVOeYMMDe1PAjh8Yl 6xwcb4grSW0/fzL0omkuVaXk8aWtPf33AxtRyGzOeYBNxAv/Ip+ecH/9QNVzvAxE4VRZ m6Zp13LKVhxRKOBVtlJ8wyGnnYiEmKlkKfAxQ= Received: by 10.68.29.229 with SMTP id n5mr10331702pbh.176.1309890352827; Tue, 05 Jul 2011 11:25:52 -0700 (PDT) Received: from OwnerPC (99-116-250-186.lightspeed.irvnca.sbcglobal.net [99.116.250.186]) by mx.google.com with ESMTPS id z7sm4562060pbk.19.2011.07.05.11.25.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Jul 2011 11:25:51 -0700 (PDT) From: "Hilda Fontana" To: "'Alessandro Vesely'" References: <4E1040C2.2080508@tana.it> <4E13512E.2050204@tana.it> In-Reply-To: <4E13512E.2050204@tana.it> Date: Tue, 5 Jul 2011 11:25:48 -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: AQJGQn+A9NdwEHuaVI1/hpfQVw1GLAFdsbapAMa50X0BuRv9kQHmFiZ9AZBFXu2Tr1ysUA== Content-Language: en-us Cc: marf@ietf.org Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 05 Jul 2011 18:25:54 -0000 > X.Y.Z. Definition and Registration of Method-Specific Extensions > > The IANA maintains a registry of Email Authentication Methods > along with their possible results. A "method-specific extension" > extends an authentication method by providing for the possibility > to report its result using the ARF format specified in this > document. Any such extension must specify: > > * which method(s) it addresses; > > * which result(s) of the addressed method(s) deserve being > reported; > > * a list of one or more keywords to be used in the Auth-Failure > field when reporting such results; and > > * the location and the syntax of the report parameters whose > semantic content is described in Section U.V.W. > > In addition, a method-specific extension may define further ARF > header fields. In case it does so, it shall also define the > corresponding updates to ARF header field names in its IANA > Considerations section. > > Section U.V.W would discuss r, rf, and ri, and possibly mention ro and rs too. > Not how they are syntactically encoded, just what they mean. > > Does the above make sense? > So your saying it needs a rewrite - it was really meant to be a fairly simple straightforward way to report auth failures in a useable way i.e. extending what arf/marf already do - does it not to that in your opinion? Or are you looking for it to do something else. The current report format defined in [ARF] lacks some specific features required to do effective sender authentication reporting. This section defines extensions to ARF to accommodate this requirement. > >> B The splitting is fine as it is, although not in a "normal > >> form". It is extremely unlikely that "iprev" or any other > >> method will ever need a failure reporting mechanism. The > >> sooner we go to testing and deploying, the better. > > > > ?not in a normal form? > > "Normal" in the sense of orthogonal or perpendicular; that is, having > independent semantics along the "axes". Basically, I mean loosely coupled > with the method extensions. It is meant to be specific - I don't think "loosely" is a good track From hfontana@ecertsystems.com Tue Jul 5 11:32:18 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F04121F88EE for ; Tue, 5 Jul 2011 11:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUiZkXh3tfjQ for ; Tue, 5 Jul 2011 11:32:18 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 128D921F88ED for ; Tue, 5 Jul 2011 11:32:18 -0700 (PDT) Received: by pzk5 with SMTP id 5so2483348pzk.31 for ; Tue, 05 Jul 2011 11:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecertsystems.com; s=google; h=from:to:cc: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=HVPBmCo6U+Yi5bbMcMsImZepNRVN3QkVp73DjYyA8uI=; b=E3DgpepP2608lKOCHrE1dPCOJ3mbJAQOXiti1NNyhkeLDLZ0loyH2FSc1Y8CXSP/jL GttLJj68fyJ9hzm89CVVE9jx+M430tnhgR8HgU+QmNoxcHrrFRgl+Tii5+WuTnaN0/kb Yicl+DSkK9qPRqYpbXFB9mSSCluAnuwtkfYKE= Received: by 10.68.57.66 with SMTP id g2mr9987027pbq.124.1309890100244; Tue, 05 Jul 2011 11:21:40 -0700 (PDT) Received: from OwnerPC (99-116-250-186.lightspeed.irvnca.sbcglobal.net [99.116.250.186]) by mx.google.com with ESMTPS id z7sm4555488pbk.67.2011.07.05.11.21.39 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Jul 2011 11:21:39 -0700 (PDT) From: "Hilda Fontana" To: "'Alessandro Vesely'" References: <4E1040C2.2080508@tana.it> <4E13512E.2050204@tana.it> In-Reply-To: <4E13512E.2050204@tana.it> Date: Tue, 5 Jul 2011 11:21:35 -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: AQJGQn+A9NdwEHuaVI1/hpfQVw1GLAFdsbapAMa50X0BuRv9kQHmFiZ9AZBFXu2Tr1wAQA== Content-Language: en-us Cc: marf@ietf.org Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 05 Jul 2011 18:32:18 -0000 > "Normal" in the sense of orthogonal or perpendicular; that is, having > independent semantics along the "axes". Basically, I mean loosely coupled > with the method extensions. > > Indeed, I think authfailure-report can be written without mentioning neither > "dkim" nor "spf", except for possible examples. I guess that would enhance > comprehensibility. However, the WG should decide whether to go this way > _before_ delving into any finer tuning, if it's not too late already. The problem right now is that each arf message generated due to auth failures are formatted differently and it makes automation very difficult - if we don't tie the authfailure messages minimally to dkim and spf - I don't think we have accomplished anything - at the very least I think they should be the minimum with the option to extend for future. From msk@cloudmark.com Tue Jul 5 11:48: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 199EA21F88FF for ; Tue, 5 Jul 2011 11:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.204 X-Spam-Level: X-Spam-Status: No, score=-103.204 tagged_above=-999 required=5 tests=[AWL=-0.605, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWerQuygMnEC for ; Tue, 5 Jul 2011 11:48:20 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 8F48021F88FD for ; Tue, 5 Jul 2011 11:48:20 -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, 5 Jul 2011 11:48:20 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 5 Jul 2011 11:48:18 -0700 Thread-Topic: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft Thread-Index: Acw7PYl0FxRwfk6vQXqHVUmyOUlU+QABBDtQ Message-ID: References: <4E1040C2.2080508@tana.it> <4E13512E.2050204@tana.it> In-Reply-To: <4E13512E.2050204@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] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 05 Jul 2011 18:48:21 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Tuesday, July 05, 2011 11:00 AM > To: Hilda Fontana > Cc: marf@ietf.org > Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim-rep= orting draft >=20 > Roughly, a section more or less like >=20 > X.Y.Z. Definition and Registration of Method-Specific Extensions >=20 > The IANA maintains a registry of Email Authentication Methods > along with their possible results. A "method-specific extension" > extends an authentication method by providing for the possibility > to report its result using the ARF format specified in this > document. Any such extension must specify: >=20 > * which method(s) it addresses; >=20 > * which result(s) of the addressed method(s) deserve being > reported; >=20 > * a list of one or more keywords to be used in the Auth-Failure > field when reporting such results; and >=20 > * the location and the syntax of the report parameters whose > semantic content is described in Section U.V.W. >=20 > In addition, a method-specific extension may define further ARF > header fields. In case it does so, it shall also define the > corresponding updates to ARF header field names in its IANA > Considerations section. >=20 > Section U.V.W would discuss r, rf, and ri, and possibly mention ro and > rs too. Not how they are syntactically encoded, just what they mean. >=20 > Does the above make sense? We're adding DKIM and SPF reporting to ARF in this way because they both pr= e-date ARF in the official sense. I think the current approach makes sense= ; this document extends ARF and the spf-reporting and dkim-reporting docume= nts extend SPF and DKIM respectively, and they're all compatible with each = other. I think if the working group feels this is a good idea to write down for fu= ture extensions, we can produce another Informational document that explain= s the things one should consider in terms of creating a new email authentic= ation method, including registering and defining reporting extensions both = in terms of ARF and RFC5451. Or, as a lesser approach, that could become a= n appendix of this one. > Indeed, I think authfailure-report can be written without mentioning > neither "dkim" nor "spf", except for possible examples. I guess that > would enhance comprehensibility. However, the WG should decide > whether to go this way _before_ delving into any finer tuning, if it's > not too late already. Ignoring redaction for the moment, what we have now is: - authfailure-report modifies ARF - dkim-reporting modifies DKIM and ADSP - spf-reporting modifies SPF That seems nice and clean. Your proposal changes it to: - authfailure-report modifies ARF - dkim-reporting modifies DKIM and ADSP, and also modifies authfailure-repo= rt - spf-reporting modifies SPF, and also modifies authfailure-report At a glance the first method seems cleaner to me. On the other hand, the l= atter is a more clear demonstration of how future email authentication meth= ods will need to create reporting hooks. What do others think? And let's try to make this the last revisit of the a= rrangement of this work so that we can make some progress. Thanks, -MSK From hfontana@ecertsystems.com Tue Jul 5 13:25: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 3561A21F881F for ; Tue, 5 Jul 2011 13:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+PmG0hqr4Mf for ; Tue, 5 Jul 2011 13:25:27 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id D766F21F8822 for ; Tue, 5 Jul 2011 13:25:26 -0700 (PDT) Received: by pvh18 with SMTP id 18so8386230pvh.31 for ; Tue, 05 Jul 2011 13:25:26 -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=NjEsJ/bIylwtMNYG58PDrI/Kr4UD/vJrnvs3fY80Vek=; b=frn/SYxEZRJSheAgagAlcVf4CA+xCshwl8zWW8PPXgdxdZeMfpkfrnZ8XXqM0tRtP4 S1T1WvrAiWVjxI/sekaaurPScocw742ayi2xrfLkWsLTLXUTjp+ZKnT9deuTfk6jCPLN 9m0/NUYC2AF7XpUBXnTheehHTRroJqoXifeek= Received: by 10.68.52.38 with SMTP id q6mr8935370pbo.97.1309897526334; Tue, 05 Jul 2011 13:25:26 -0700 (PDT) Received: from OwnerPC (99-116-250-186.lightspeed.irvnca.sbcglobal.net [99.116.250.186]) by mx.google.com with ESMTPS id q5sm4602924pbk.58.2011.07.05.13.25.24 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Jul 2011 13:25:25 -0700 (PDT) From: "Hilda Fontana" To: "'Murray S. Kucherawy'" , References: <4E1040C2.2080508@tana.it> <4E13512E.2050204@tana.it> In-Reply-To: Date: Tue, 5 Jul 2011 13:25:21 -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: AQJGQn+A9NdwEHuaVI1/hpfQVw1GLAFdsbapAMa50X0BuRv9kQHmFiZ9AZBFXu0B7zvir5OgBUcw Content-Language: en-us Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 05 Jul 2011 20:25:33 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Murray S. Kucherawy > Sent: Tuesday, July 05, 2011 11:48 AM > To: marf@ietf.org > Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim- > reporting draft > > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf > > Of Alessandro Vesely > > Sent: Tuesday, July 05, 2011 11:00 AM > > To: Hilda Fontana > > Cc: marf@ietf.org > > Subject: Re: [marf] Cohesion of authfailure-report, was Split of > > dkim-reporting draft > > > > Roughly, a section more or less like > > > > X.Y.Z. Definition and Registration of Method-Specific Extensions > > > > The IANA maintains a registry of Email Authentication Methods > > along with their possible results. A "method-specific extension" > > extends an authentication method by providing for the possibility > > to report its result using the ARF format specified in this > > document. Any such extension must specify: > > > > * which method(s) it addresses; > > > > * which result(s) of the addressed method(s) deserve being > > reported; > > > > * a list of one or more keywords to be used in the Auth-Failure > > field when reporting such results; and > > > > * the location and the syntax of the report parameters whose > > semantic content is described in Section U.V.W. > > > > In addition, a method-specific extension may define further ARF > > header fields. In case it does so, it shall also define the > > corresponding updates to ARF header field names in its IANA > > Considerations section. > > > > Section U.V.W would discuss r, rf, and ri, and possibly mention ro and > > rs too. Not how they are syntactically encoded, just what they mean. > > > > Does the above make sense? > > We're adding DKIM and SPF reporting to ARF in this way because they both > pre-date ARF in the official sense. I think the current approach makes sense; > this document extends ARF and the spf-reporting and dkim-reporting > documents extend SPF and DKIM respectively, and they're all compatible > with each other. > > I think if the working group feels this is a good idea to write down for future > extensions, we can produce another Informational document that explains > the things one should consider in terms of creating a new email > authentication method, including registering and defining reporting > extensions both in terms of ARF and RFC5451. Or, as a lesser approach, that > could become an appendix of this one. > > > Indeed, I think authfailure-report can be written without mentioning > > neither "dkim" nor "spf", except for possible examples. I guess that > > would enhance comprehensibility. However, the WG should decide > > whether to go this way _before_ delving into any finer tuning, if it's > > not too late already. > > Ignoring redaction for the moment, what we have now is: > > - authfailure-report modifies ARF > - dkim-reporting modifies DKIM and ADSP > - spf-reporting modifies SPF > > That seems nice and clean. Your proposal changes it to: > > - authfailure-report modifies ARF > - dkim-reporting modifies DKIM and ADSP, and also modifies authfailure- > report > - spf-reporting modifies SPF, and also modifies authfailure-report > > At a glance the first method seems cleaner to me. On the other hand, the > latter is a more clear demonstration of how future email authentication > methods will need to create reporting hooks. > > What do others think? And let's try to make this the last revisit of the > arrangement of this work so that we can make some progress. > > Thanks, > > -MSK +1 From vesely@tana.it Wed Jul 6 03:12:47 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBBB21F85EB for ; Wed, 6 Jul 2011 03:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.81 X-Spam-Level: X-Spam-Status: No, score=-4.81 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUFstENcNSLW for ; Wed, 6 Jul 2011 03:12:46 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAD521F8514 for ; Wed, 6 Jul 2011 03:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1309947163; bh=fRq7nB9s4R1RgteCVZxpaNI2BCjYi4r5nclLI57oIpM=; l=1017; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=VT42obHFTb1CNI0uPKnLjiXdGWEJuQm8vFsVxFbIrrZvjXt4wSnFD3tDjMU4PmsTD AwvyQBHYt5S4giM+Mk3iJFAAqcisMWFcdtjqB/Z8WthrpHiWUwggn8vXNVkdfZPEIZ XPxhT70ewn8ttwV1fnjZY/tsaH3c/TodtDcflHM8= 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, 06 Jul 2011 12:12:43 +0200 id 00000000005DC039.000000004E14351B.000061F7 Message-ID: <4E14351B.806@tana.it> Date: Wed, 06 Jul 2011 12:12:43 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: marf@ietf.org References: <4E1040C2.2080508@tana.it> <4E13512E.2050204@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 06 Jul 2011 10:12:47 -0000 On 05/Jul/11 20:48, Murray S. Kucherawy wrote: > Ignoring redaction for the moment, what we have now is: > > - authfailure-report modifies ARF > - dkim-reporting modifies DKIM and ADSP > - spf-reporting modifies SPF > > That seems nice and clean. Your proposal changes it to: > > - authfailure-report modifies ARF > - dkim-reporting modifies DKIM and ADSP, and also modifies authfailure-report > - spf-reporting modifies SPF, and also modifies authfailure-report > > At a glance the first method seems cleaner to me. On the other > hand, the latter is a more clear demonstration of how future email > authentication methods will need to create reporting hooks. A more realistic advantage of the second method is to allow editing, say, dkim-reporting without having to negotiate dkim-related modifications with a given version of authfailure-report. > What do others think? And let's try to make this the last revisit > of the arrangement of this work so that we can make some progress. +1 From shmuel+gen@patriot.net Wed Jul 6 09:54: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 2CC6521F85D2 for ; Wed, 6 Jul 2011 09:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmMKsEZWl0yP for ; Wed, 6 Jul 2011 09:54:40 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8852921F85C7 for ; Wed, 6 Jul 2011 09:54:40 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.113]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id D60AAF5808A for ; Wed, 6 Jul 2011 12:46:10 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Wed, 06 Jul 2011 12:51:21 -0400 To: marf@ietf.org In-Reply-To: <4E1040C2.2080508@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: <20110706164610.D60AAF5808A@smtp.patriot.net> Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 06 Jul 2011 16:54:41 -0000 In <4E1040C2.2080508@tana.it>, on 07/03/2011 at 12:13 PM, Alessandro Vesely said: >Which of the following, if any, is correct? >A The ARF extension will gain in comprehensibility by removing > any method-specific detail. That would be my preference. -- 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 sklist@kitterman.com Wed Jul 6 12:54: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 343A721F8B4D for ; Wed, 6 Jul 2011 12:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUIhDNyNo6Ff for ; Wed, 6 Jul 2011 12:54:02 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7020021F8AA2 for ; Wed, 6 Jul 2011 12:54:02 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id AACDE38C101; Wed, 6 Jul 2011 15:54:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1309982040; bh=3TNIUfJxVsWNnjeyMXsPxNhd62Qc6gCeUVe9PS5XjEc=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=Gw2GXcX2x1tfAfNtE3LDXLTWPjnYN8sf0yzmAHe+Igtn3dO1eXehhoeDeDvn1L/jc sBcnWMqmenLMtVgX4MtNRcU/PF2xqwVRr8jivWNJE70LuWcMMriXPyX33OwBST5+th r8LoBbJyTATeHRT4jDg89bwRVQGA3J3PYnJRBijw= From: Scott Kitterman To: marf@ietf.org Date: Wed, 6 Jul 2011 15:53:59 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic-pae; KDE/4.6.2; i686; ; ) References: <4E14351B.806@tana.it> In-Reply-To: <4E14351B.806@tana.it> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107061553.59302.sklist@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 06 Jul 2011 19:54:03 -0000 On Wednesday, July 06, 2011 06:12:43 AM Alessandro Vesely wrote: > On 05/Jul/11 20:48, Murray S. Kucherawy wrote: > > Ignoring redaction for the moment, what we have now is: > > > > - authfailure-report modifies ARF > > - dkim-reporting modifies DKIM and ADSP > > - spf-reporting modifies SPF > > > > That seems nice and clean. Your proposal changes it to: > > > > - authfailure-report modifies ARF > > - dkim-reporting modifies DKIM and ADSP, and also modifies > > authfailure-report - spf-reporting modifies SPF, and also modifies > > authfailure-report > > > > At a glance the first method seems cleaner to me. On the other > > hand, the latter is a more clear demonstration of how future email > > authentication methods will need to create reporting hooks. > > A more realistic advantage of the second method is to allow editing, > say, dkim-reporting without having to negotiate dkim-related > modifications with a given version of authfailure-report. > > > What do others think? And let's try to make this the last revisit > > of the arrangement of this work so that we can make some progress. > > +1 I'm happy either way. I would like a decision to be made soon so we can get updated drafts in prior to the July 11 cutoff. Scott K From barryleiba.mailing.lists@gmail.com Wed Jul 6 15:16: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 48DA421F889B for ; Wed, 6 Jul 2011 15:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.227 X-Spam-Level: X-Spam-Status: No, score=-103.227 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayefQfPUKT-B for ; Wed, 6 Jul 2011 15:16:12 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 781E421F8890 for ; Wed, 6 Jul 2011 15:16:12 -0700 (PDT) Received: by ywp31 with SMTP id 31so178935ywp.31 for ; Wed, 06 Jul 2011 15:16:11 -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=auWGNhz3REe2bP0gU9voALb6XQ5xpux22ogUFRoLIcM=; b=UFgAyYw108AesR2CUj9OXGsSXd8dSDu0g9Hpr4cWpRuTmrgXgCgO2CE9gJreG8SQql ozpzNEOKqU3x92x5gRlcs5zn4PirJGPmB+Rz53tSJ5h0keM1LqEfSFKZHmnCB1Df2sdG Vl/uL82NqGpJmfMSK5cGJgvLu7+kkBFrp1BEQ= MIME-Version: 1.0 Received: by 10.150.50.8 with SMTP id x8mr342092ybx.184.1309990571830; Wed, 06 Jul 2011 15:16:11 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.41.12 with HTTP; Wed, 6 Jul 2011 15:16:11 -0700 (PDT) In-Reply-To: References: <4E1040C2.2080508@tana.it> <4E13512E.2050204@tana.it> Date: Wed, 6 Jul 2011 18:16:11 -0400 X-Google-Sender-Auth: UJz0Kf83zxsq3hy55SSHtidf0OY Message-ID: From: Barry Leiba To: Hilda Fontana Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Message Abuse Report Format working group Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 06 Jul 2011 22:16:13 -0000 Hilda, when you put a "+1" at the end of a message like this, I can't tell what you're agreeing with. Murray didn't make a single statement in his message -- in the end, he gave alternatives and asked what people think. Can you be specific about what you agree with? Barry On Tue, Jul 5, 2011 at 4:25 PM, Hilda Fontana w= rote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of >> Murray S. Kucherawy >> Sent: Tuesday, July 05, 2011 11:48 AM >> To: marf@ietf.org >> Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim- >> reporting draft >> >> > -----Original Message----- >> > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf >> > Of Alessandro Vesely >> > Sent: Tuesday, July 05, 2011 11:00 AM >> > To: Hilda Fontana >> > Cc: marf@ietf.org >> > Subject: Re: [marf] Cohesion of authfailure-report, was Split of >> > dkim-reporting draft >> > >> > Roughly, a section more or less like >> > >> > =A0 =A0X.Y.Z. =A0Definition and Registration of Method-Specific Extens= ions >> > >> > =A0 =A0The IANA maintains a registry of Email Authentication Methods >> > =A0 =A0along with their possible results. =A0A "method-specific extens= ion" >> > =A0 =A0extends an authentication method by providing for the possibili= ty >> > =A0 =A0to report its result using the ARF format specified in this >> > =A0 =A0document. =A0Any such extension must specify: >> > >> > =A0 =A0* =A0which method(s) it addresses; >> > >> > =A0 =A0* =A0which result(s) of the addressed method(s) deserve being >> > =A0 =A0 =A0 reported; >> > >> > =A0 =A0* =A0a list of one or more keywords to be used in the Auth-Fail= ure >> > =A0 =A0 =A0 field when reporting such results; and >> > >> > =A0 =A0* =A0the location and the syntax of the report parameters whose >> > =A0 =A0 =A0 semantic content is described in Section U.V.W. >> > >> > =A0 =A0In addition, a method-specific extension may define further ARF >> > =A0 =A0header fields. =A0In case it does so, it shall also define the >> > =A0 =A0corresponding updates to ARF header field names in its IANA >> > =A0 =A0Considerations section. >> > >> > Section U.V.W would discuss r, rf, and ri, and possibly mention ro and >> > rs too. =A0Not how they are syntactically encoded, just what they mean= . >> > >> > Does the above make sense? >> >> We're adding DKIM and SPF reporting to ARF in this way because they both >> pre-date ARF in the official sense. =A0I think the current approach make= s > sense; >> this document extends ARF and the spf-reporting and dkim-reporting >> documents extend SPF and DKIM respectively, and they're all compatible >> with each other. >> >> I think if the working group feels this is a good idea to write down for > future >> extensions, we can produce another Informational document that explains >> the things one should consider in terms of creating a new email >> authentication method, including registering and defining reporting >> extensions both in terms of ARF and RFC5451. =A0Or, as a lesser approach= , > that >> could become an appendix of this one. >> >> > Indeed, I think authfailure-report can be written without mentioning >> > neither "dkim" nor "spf", except for possible examples. =A0I guess tha= t >> > would enhance comprehensibility. =A0However, the WG should decide >> > whether to go this way _before_ delving into any finer tuning, if it's >> > not too late already. >> >> Ignoring redaction for the moment, what we have now is: >> >> - authfailure-report modifies ARF >> - dkim-reporting modifies DKIM and ADSP >> - spf-reporting modifies SPF >> >> That seems nice and clean. =A0Your proposal changes it to: >> >> - authfailure-report modifies ARF >> - dkim-reporting modifies DKIM and ADSP, and also modifies authfailure- >> report >> - spf-reporting modifies SPF, and also modifies authfailure-report >> >> At a glance the first method seems cleaner to me. =A0On the other hand, = the >> latter is a more clear demonstration of how future email authentication >> methods will need to create reporting hooks. >> >> What do others think? =A0And let's try to make this the last revisit of = the >> arrangement of this work so that we can make some progress. >> >> Thanks, >> >> -MSK > +1 > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > From hfontana@ecertsystems.com Wed Jul 6 15:18:57 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 BC47521F889E for ; Wed, 6 Jul 2011 15:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EolYFn1Kj+Jt for ; Wed, 6 Jul 2011 15:18:57 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id BBDB521F889D for ; Wed, 6 Jul 2011 15:18:55 -0700 (PDT) Received: by pzk5 with SMTP id 5so460532pzk.31 for ; Wed, 06 Jul 2011 15:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecertsystems.com; s=google; h=from:to:cc: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=d3sOyP8e3oeqpqXQoGiJ1nPFGNZn4IsMicqAbNFRJqk=; b=hPFxQHrsbzy4YiYH7DVKmr1ZgL+MXNm5ew/8Ysvnt8ArHDvRiKiMmqkClyjJarhT3b XPvkpdmpj6qwBIbUxEZ4b3XgTFF82Un2p0YDItXqvHY/hME4rDPfDplLQl1HIYbPxpBf owTRwdJEKK9pQnH/wJwT/6x4aoMQTzSSoE8eA= Received: by 10.142.49.7 with SMTP id w7mr47070wfw.88.1309990734802; Wed, 06 Jul 2011 15:18:54 -0700 (PDT) Received: from OwnerPC (99-116-250-186.lightspeed.irvnca.sbcglobal.net [99.116.250.186]) by mx.google.com with ESMTPS id d1sm5136732pbj.56.2011.07.06.15.18.53 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jul 2011 15:18:54 -0700 (PDT) From: "Hilda Fontana" To: "'Barry Leiba'" References: <4E1040C2.2080508@tana.it> <4E13512E.2050204@tana.it> In-Reply-To: Date: Wed, 6 Jul 2011 15:18:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJGQn+A9NdwEHuaVI1/hpfQVw1GLAFdsbapAMa50X0BuRv9kQHmFiZ9AZBFXu0B7zvirwMNolEuAdCdfD6TesUywA== Content-Language: en-us Cc: 'Message Abuse Report Format working group' Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 06 Jul 2011 22:18:57 -0000 I understand Barry - and I did re-respond specifying what I agreed with = - I'm just getting used to the process=20 > -----Original Message----- > From: barryleiba.mailing.lists@gmail.com > [mailto:barryleiba.mailing.lists@gmail.com] On Behalf Of Barry Leiba > Sent: Wednesday, July 06, 2011 3:16 PM > To: Hilda Fontana > Cc: Message Abuse Report Format working group > Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim- > reporting draft >=20 > Hilda, when you put a "+1" at the end of a message like this, I can't = tell what > you're agreeing with. Murray didn't make a single statement in his message - > - in the end, he gave alternatives and asked what people think. >=20 > Can you be specific about what you agree with? >=20 > Barry >=20 > On Tue, Jul 5, 2011 at 4:25 PM, Hilda Fontana = > wrote: > >> -----Original Message----- > >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On = Behalf > >> Of Murray S. Kucherawy > >> Sent: Tuesday, July 05, 2011 11:48 AM > >> To: marf@ietf.org > >> Subject: Re: [marf] Cohesion of authfailure-report, was Split of > >> dkim- reporting draft > >> > >> > -----Original Message----- > >> > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On > >> > Behalf Of Alessandro Vesely > >> > Sent: Tuesday, July 05, 2011 11:00 AM > >> > To: Hilda Fontana > >> > Cc: marf@ietf.org > >> > Subject: Re: [marf] Cohesion of authfailure-report, was Split of > >> > dkim-reporting draft > >> > > >> > Roughly, a section more or less like > >> > > >> > =A0 =A0X.Y.Z. =A0Definition and Registration of Method-Specific > >> > Extensions > >> > > >> > =A0 =A0The IANA maintains a registry of Email Authentication = Methods > >> > =A0 =A0along with their possible results. =A0A "method-specific = extension" > >> > =A0 =A0extends an authentication method by providing for the > >> > possibility > >> > =A0 =A0to report its result using the ARF format specified in = this > >> > =A0 =A0document. =A0Any such extension must specify: > >> > > >> > =A0 =A0* =A0which method(s) it addresses; > >> > > >> > =A0 =A0* =A0which result(s) of the addressed method(s) deserve = being > >> > =A0 =A0 =A0 reported; > >> > > >> > =A0 =A0* =A0a list of one or more keywords to be used in the = Auth-Failure > >> > =A0 =A0 =A0 field when reporting such results; and > >> > > >> > =A0 =A0* =A0the location and the syntax of the report parameters = whose > >> > =A0 =A0 =A0 semantic content is described in Section U.V.W. > >> > > >> > =A0 =A0In addition, a method-specific extension may define = further ARF > >> > =A0 =A0header fields. =A0In case it does so, it shall also define = the > >> > =A0 =A0corresponding updates to ARF header field names in its = IANA > >> > =A0 =A0Considerations section. > >> > > >> > Section U.V.W would discuss r, rf, and ri, and possibly mention = ro > >> > and rs too. =A0Not how they are syntactically encoded, just what = they > mean. > >> > > >> > Does the above make sense? > >> > >> We're adding DKIM and SPF reporting to ARF in this way because they > >> both pre-date ARF in the official sense. =A0I think the current > >> approach makes > > sense; > >> this document extends ARF and the spf-reporting and dkim-reporting > >> documents extend SPF and DKIM respectively, and they're all > >> compatible with each other. > >> > >> I think if the working group feels this is a good idea to write = down > >> for > > future > >> extensions, we can produce another Informational document that > >> explains the things one should consider in terms of creating a new > >> email authentication method, including registering and defining > >> reporting extensions both in terms of ARF and RFC5451. =A0Or, as a > >> lesser approach, > > that > >> could become an appendix of this one. > >> > >> > Indeed, I think authfailure-report can be written without > >> > mentioning neither "dkim" nor "spf", except for possible = examples. > >> > I guess that would enhance comprehensibility. =A0However, the WG > >> > should decide whether to go this way _before_ delving into any > >> > finer tuning, if it's not too late already. > >> > >> Ignoring redaction for the moment, what we have now is: > >> > >> - authfailure-report modifies ARF > >> - dkim-reporting modifies DKIM and ADSP > >> - spf-reporting modifies SPF > >> > >> That seems nice and clean. =A0Your proposal changes it to: > >> > >> - authfailure-report modifies ARF > >> - dkim-reporting modifies DKIM and ADSP, and also modifies > >> authfailure- report > >> - spf-reporting modifies SPF, and also modifies authfailure-report > >> > >> At a glance the first method seems cleaner to me. =A0On the other = hand, > >> the latter is a more clear demonstration of how future email > >> authentication methods will need to create reporting hooks. > >> > >> What do others think? =A0And let's try to make this the last = revisit of > >> the arrangement of this work so that we can make some progress. > >> > >> Thanks, > >> > >> -MSK > > +1 > > > > _______________________________________________ > > marf mailing list > > marf@ietf.org > > https://www.ietf.org/mailman/listinfo/marf > > From barryleiba.mailing.lists@gmail.com Wed Jul 6 15:19: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 7FCA021F8AD6 for ; Wed, 6 Jul 2011 15:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.212 X-Spam-Level: X-Spam-Status: No, score=-103.212 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqMNtT9KwJr8 for ; Wed, 6 Jul 2011 15:19:04 -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 CA2FC21F889D for ; Wed, 6 Jul 2011 15:19:00 -0700 (PDT) Received: by gyd5 with SMTP id 5so194684gyd.31 for ; Wed, 06 Jul 2011 15:19:00 -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=X6O93A9LBD0den6x2c0E2VV4geRSGUpYuGZ7APBSx8s=; b=QLgXYbdCKeakra/DZUUM3BjrwDUbxR1ZCuIdQR1/3iEYxxrTXw7zHjjI6oQygkSet5 uO6Iq1lxsG0y7f1pGKnHNF8mDufDOZQvIJQcHgC+FCjlrdWibkRLCEuRlxMFl5lybdAx heiUKpDqClmwWJDivw1p9OFjnu9g8uDbApmv0= MIME-Version: 1.0 Received: by 10.236.180.98 with SMTP id i62mr42882yhm.403.1309990740296; Wed, 06 Jul 2011 15:19:00 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.41.12 with HTTP; Wed, 6 Jul 2011 15:19:00 -0700 (PDT) In-Reply-To: <20110706164610.D60AAF5808A@smtp.patriot.net> References: <4E1040C2.2080508@tana.it> <20110706164610.D60AAF5808A@smtp.patriot.net> Date: Wed, 6 Jul 2011 18:19:00 -0400 X-Google-Sender-Auth: L5VDJAFi-H-ytlNO56IPBwFaBMk Message-ID: From: Barry Leiba To: shmuel+mail-abuse-feedback-report@patriot.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Message Abuse Report Format working group Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 06 Jul 2011 22:19:04 -0000 >>Which of the following, if any, is correct? > >>A =A0 =A0 =A0 The ARF extension will gain in comprehensibility by removin= g >> =A0 =A0 =A0 =A0any method-specific detail. > > That would be my preference. So, in terms of Murray's message (see below), which arrangement are you agreeing with? Barry Murray said... > Ignoring redaction for the moment, what we have now is: > > - authfailure-report modifies ARF > - dkim-reporting modifies DKIM and ADSP > - spf-reporting modifies SPF > > That seems nice and clean. Your proposal changes it to: > > - authfailure-report modifies ARF > - dkim-reporting modifies DKIM and ADSP, and also modifies authfailure- > report > - spf-reporting modifies SPF, and also modifies authfailure-report > > At a glance the first method seems cleaner to me. On the other hand, the > latter is a more clear demonstration of how future email authentication > methods will need to create reporting hooks. > > What do others think? From barryleiba.mailing.lists@gmail.com Wed Jul 6 15: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 04E6221F8AE1 for ; Wed, 6 Jul 2011 15:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.199 X-Spam-Level: X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q20oiq08U2Lz for ; Wed, 6 Jul 2011 15:23:57 -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 5F84821F8AC6 for ; Wed, 6 Jul 2011 15:23:57 -0700 (PDT) Received: by gyd5 with SMTP id 5so196278gyd.31 for ; Wed, 06 Jul 2011 15:23:57 -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=2lCkzCoHOV/zhLS+gbbFj0sgun82BR3PpiypsLGrE/k=; b=heSlnHL0Ej8QgdRffCJfJ4Xiiv0PO0iKIg/EQth8NfmvVrHbc1x6lNesXaag9pQVsU 3NnljXYW6gbiHPT7vIDXZ0+4mgVM6HPK6yHdeyLKpUYstaXk0D032H9xcaIRkf/V9QxD ZSLgJEkCcvuZ5R2y5H9P97ZRg/fJxKIWy9/ec= MIME-Version: 1.0 Received: by 10.236.76.167 with SMTP id b27mr111916yhe.336.1309991036943; Wed, 06 Jul 2011 15:23:56 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.41.12 with HTTP; Wed, 6 Jul 2011 15:23:56 -0700 (PDT) In-Reply-To: References: <4E1040C2.2080508@tana.it> <4E13512E.2050204@tana.it> Date: Wed, 6 Jul 2011 18:23:56 -0400 X-Google-Sender-Auth: E2rnkSnicToBUjoUP2h57bIJeGo 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] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 06 Jul 2011 22:23:58 -0000 > Ignoring redaction for the moment, what we have now is: > > - authfailure-report modifies ARF > - dkim-reporting modifies DKIM and ADSP > - spf-reporting modifies SPF > > That seems nice and clean. =A0Your proposal changes it to: > > - authfailure-report modifies ARF > - dkim-reporting modifies DKIM and ADSP, and also modifies authfailure-re= port > - spf-reporting modifies SPF, and also modifies authfailure-report > > At a glance the first method seems cleaner to me. =A0On the other hand, t= he > latter is a more clear demonstration of how future email authentication > methods will need to create reporting hooks. > > What do others think? I think I marginally prefer Alessandro's proposal. But it's a very marginal preference -- I think either arrangement will work fine. Barry, as participant From msk@cloudmark.com Wed Jul 6 15:44: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 A75BC21F8BE6 for ; Wed, 6 Jul 2011 15:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.655 X-Spam-Level: X-Spam-Status: No, score=-103.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wV+XcW5D85Ra for ; Wed, 6 Jul 2011 15:44:35 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3B09E21F8BE3 for ; Wed, 6 Jul 2011 15:44:35 -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, 6 Jul 2011 15:44:34 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 6 Jul 2011 15:44:33 -0700 Thread-Topic: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft Thread-Index: Acw8K2jd/CuVbylJSd2Vezc73QCfJgAAsbPA Message-ID: References: <4E1040C2.2080508@tana.it> <4E13512E.2050204@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] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 06 Jul 2011 22:44:35 -0000 > -----Original Message----- > From: barryleiba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lists= @gmail.com] On Behalf Of Barry Leiba > Sent: Wednesday, July 06, 2011 3:24 PM > To: Murray S. Kucherawy > Cc: marf@ietf.org > Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim- re= porting draft >=20 > I think I marginally prefer Alessandro's proposal. But it's a very > marginal preference -- I think either arrangement will work fine. I'll follow up shortly with a summary of who has to change what. It would = be great if we could all do so before the deadline on the 11th. From hfontana@ecertsystems.com Wed Jul 6 16:22: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 A2BA621F8A66 for ; Wed, 6 Jul 2011 16:22:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9yKZA1xgk-N for ; Wed, 6 Jul 2011 16:22:54 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E150021F8A56 for ; Wed, 6 Jul 2011 16:22:53 -0700 (PDT) Received: by pwj5 with SMTP id 5so386069pwj.31 for ; Wed, 06 Jul 2011 16:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecertsystems.com; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; bh=6R/eBPGiLSTO8mHB+p96raqES+IGfAXa5FuV8zprDD0=; b=QOqLU3clO9cxKwjVoZtD80r6wv30wlGqb+/XqgkqGwiAfwUmztu34wYndC1NqewpVp Dht38mXGdCciwDrhsrAFOMbvvW5XlQYUHGbtiaAXSsfqI+SzMTFmBedulwRt+Ce59MgL XA75IlOArYysZjZucUzVvtrMd7MPJi/33u9zg= Received: by 10.142.249.41 with SMTP id w41mr64795wfh.255.1309994573225; Wed, 06 Jul 2011 16:22:53 -0700 (PDT) Received: from [10.11.248.9] ([166.205.136.205]) by mx.google.com with ESMTPS id v9sm3195952pbm.15.2011.07.06.16.22.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jul 2011 16:22:52 -0700 (PDT) References: <4E1040C2.2080508@tana.it> <20110706164610.D60AAF5808A@smtp.patriot.net> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8G4) Content-Type: text/plain; charset=us-ascii Message-Id: <6609C0F1-BB93-4796-827C-7A69B1C27856@ecertsystems.com> Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (8G4) From: Hfontana Date: Wed, 6 Jul 2011 16:22:43 -0700 To: Barry Leiba Cc: Message Abuse Report Format working group Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 06 Jul 2011 23:22:54 -0000 My preference would be the first one seems clearer to me >> authfailure-report modifies ARF >> - dkim-reporting modifies DKIM and ADSP >> - spf-reporting modifies SPF > On Jul 6, 2011, at 3:19 PM, Barry Leiba wrote: >>> Which of the following, if any, is correct? >> >>> A The ARF extension will gain in comprehensibility by removing >>> any method-specific detail. >> >> That would be my preference. > > So, in terms of Murray's message (see below), which arrangement are > you agreeing with? > > Barry > > Murray said... >> Ignoring redaction for the moment, what we have now is: >> >> - authfailure-report modifies ARF >> - dkim-reporting modifies DKIM and ADSP >> - spf-reporting modifies SPF >> >> That seems nice and clean. Your proposal changes it to: >> >> - authfailure-report modifies ARF >> - dkim-reporting modifies DKIM and ADSP, and also modifies authfailure- >> report >> - spf-reporting modifies SPF, and also modifies authfailure-report >> >> At a glance the first method seems cleaner to me. On the other hand, the >> latter is a more clear demonstration of how future email authentication >> methods will need to create reporting hooks. >> >> What do others think? > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf From jdfalk-lists@cybernothing.org Wed Jul 6 21:20: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 7B49121F89A0 for ; Wed, 6 Jul 2011 21:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6b4JUskuXBaX for ; Wed, 6 Jul 2011 21:20:43 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id C181C21F898C for ; Wed, 6 Jul 2011 21:20:42 -0700 (PDT) Received: from [192.168.11.36] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p674JX3T003698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 6 Jul 2011 21:19:35 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: <6609C0F1-BB93-4796-827C-7A69B1C27856@ecertsystems.com> Date: Wed, 6 Jul 2011 21:19:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1040C2.2080508@tana.it> <20110706164610.D60AAF5808A@smtp.patriot.net> <6609C0F1-BB93-4796-827C-7A69B1C27856@ecertsystems.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 07 Jul 2011 04:20:43 -0000 On Jul 6, 2011, at 4:22 PM, Hfontana wrote: > My preference would be the first one seems clearer to me >=20 >>> authfailure-report modifies ARF >>> - dkim-reporting modifies DKIM and ADSP >>> - spf-reporting modifies SPF +1 We can already see that the modifications to DKIM and ADSP are different = from the modifications to SPF, so a draft which makes all modifications = generic is unlikely to ever modify anything sufficiently by itself. In = other words, we'll have to do just as much work for each future = authentication method (if indeed there ever are any) either way, so I = think we should take the path of less work now. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From barryleiba.mailing.lists@gmail.com Thu Jul 7 07:15:18 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2358D21F8758 for ; Thu, 7 Jul 2011 07:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.177 X-Spam-Level: X-Spam-Status: No, score=-103.177 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nBIkMFOtXKZ for ; Thu, 7 Jul 2011 07:15:16 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id CE9F421F8757 for ; Thu, 7 Jul 2011 07:15:13 -0700 (PDT) Received: by yie30 with SMTP id 30so468017yie.31 for ; Thu, 07 Jul 2011 07:15:13 -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=wRxt0rV3ScbBRgQ0cyLov0GRCSLXFEd7tjG37hYLl1Y=; b=CElPCa8sRJJH8HyqVTXaGOd5OCRYCFcUqRFC+sk/BXWktYElCJHsQzrhwMNNoX4bF8 BLP116URMhS3g5pONHFBxVNCOVQO6CZ7Zy3kn1S691sMZOnGR+U8OaRJOxck88dJaI/y 7TWajPQYsXyiRmYvmu6xEqqTUqRiPg85jzE3c= MIME-Version: 1.0 Received: by 10.147.163.16 with SMTP id q16mr714689yao.19.1310048113150; Thu, 07 Jul 2011 07:15:13 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.41.12 with HTTP; Thu, 7 Jul 2011 07:15:13 -0700 (PDT) In-Reply-To: References: <4E1040C2.2080508@tana.it> <20110706164610.D60AAF5808A@smtp.patriot.net> <6609C0F1-BB93-4796-827C-7A69B1C27856@ecertsystems.com> Date: Thu, 7 Jul 2011 10:15:13 -0400 X-Google-Sender-Auth: WoOY7FdhbTt70B1uvcGvW2g0Ngc Message-ID: From: Barry Leiba To: "J.D. Falk" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Message Abuse Report Format working group Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 07 Jul 2011 14:15:18 -0000 > We can already see that the modifications to DKIM and ADSP are > different from the modifications to SPF, so a draft which makes all > modifications generic is unlikely to ever modify anything sufficiently > by itself. =A0In other words, we'll have to do just as much work for each > future authentication method (if indeed there ever are any) either way, > so I think we should take the path of less work now. J.D. has convinced me to shift my preference (I said it was close...). I agree with J.D. Barry, as participant From barryleiba.mailing.lists@gmail.com Thu Jul 7 07:17: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 4C20621F8778 for ; Thu, 7 Jul 2011 07:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.939 X-Spam-Level: X-Spam-Status: No, score=-102.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKkxfeVL2a4W for ; Thu, 7 Jul 2011 07:17:16 -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 B3AE021F8776 for ; Thu, 7 Jul 2011 07:17:16 -0700 (PDT) Received: by gwb20 with SMTP id 20so467094gwb.31 for ; Thu, 07 Jul 2011 07:17:14 -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=CSexqWo86iJWZn9HPgZvHN5TBsn8/Nb3Kw8iIN6AjJc=; b=jLDRgMHy0iUdSNoiS3VSF/X+C2e7ONQhOzTjb5eaTdTPXEuAagdLVsgt50tCYkLSTA YAmQ2AeYqZPszlPSHG5kngQM/PU0eMDhqEj+R+U3Ck/O3+B1+uLnStIWLjmsMXpVHjlh ARef/ToYIBFTa6daAVJIiVne2bc/MCt2dp0nI= MIME-Version: 1.0 Received: by 10.150.14.15 with SMTP id 15mr983664ybn.70.1310048234418; Thu, 07 Jul 2011 07:17:14 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.41.12 with HTTP; Thu, 7 Jul 2011 07:17:14 -0700 (PDT) In-Reply-To: References: <4E1040C2.2080508@tana.it> <4E13512E.2050204@tana.it> Date: Thu, 7 Jul 2011 10:17:14 -0400 X-Google-Sender-Auth: u2SPt7iMX7J6UJEfi9Oeknsjduw 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] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 07 Jul 2011 14:17:17 -0000 > I'll follow up shortly with a summary of who has to change what. > =A0It would be great if we could all do so before the deadline on > the 11th. To be clear: As chair, I see the consensus on leaving the split as originally planned. Alessandro has a good point, but I think WG consensus is against going that way. Barry, as chair From sklist@kitterman.com Thu Jul 7 07:45: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 157C71F0C3C for ; Thu, 7 Jul 2011 07:45:33 -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] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrzwHVmlQZh4 for ; Thu, 7 Jul 2011 07:45:32 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8101F0C37 for ; Thu, 7 Jul 2011 07:45:32 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id C5B5838C187; Thu, 7 Jul 2011 10:45:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1310049931; bh=K0jbV7taKdI4qDRiVa6P3oCAZlNFLgeEZl3ego3/5qw=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=cmMfOA+RNd1NTRXp18k09uNbaLX1VWbre4ufJkUZzVTy2HNoqkwLrgP7qMfRr3IHZ n/J5I03SbNlLb44hNB84l09HetvYfXtfdlqIo463QH+vjKcVdYyohLCjMbZn54DHkt qZCPR9OOqBIQU4TGzjDEK4gb6e+B0P8xqYbzGbg8= From: Scott Kitterman To: marf@ietf.org Date: Thu, 7 Jul 2011 10:45:27 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic-pae; KDE/4.6.2; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107071045.28444.sklist@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 07 Jul 2011 14:45:33 -0000 On Thursday, July 07, 2011 10:17:14 AM Barry Leiba wrote: > > I'll follow up shortly with a summary of who has to change what. > > It would be great if we could all do so before the deadline on > > the 11th. > > To be clear: > As chair, I see the consensus on leaving the split as originally > planned. Alessandro has a good point, but I think WG consensus is > against going that way. > > Barry, as chair Thanks. I have had a few comments against my draft, so I'll post a -01 before the July 11 deadline. If people have been waiting to review draft-ietf-marf- spf-reporting-00, don't wait any longer. Scott K From vesely@tana.it Thu Jul 7 09:35: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 3A49921F85E7 for ; Thu, 7 Jul 2011 09:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.895 X-Spam-Level: X-Spam-Status: No, score=-4.895 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrG8sE00DniM for ; Thu, 7 Jul 2011 09:35:02 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 619C821F8706 for ; Thu, 7 Jul 2011 09:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1310056500; bh=t3r6A2SqPV/Frypv3Y19icdbo7V4fiEzEM4yAJbmDi0=; l=848; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=O66niIgrPnnVoaLkQeOe8BUbNKMscS5MRXOoe+n4DvUQe44VOSCJfkeVXtjuU0vZJ 5x9N39LR5njVBLi07+nwa0MAnh1V9FmnQB/EWUbSF+SxO5AnDP4idkJ2eX8uiu2TkI KSzp5B+avM6KnhYE2h5TA7wkoxXrevbVWlzRNaSk= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 07 Jul 2011 18:35:00 +0200 id 00000000005DC039.000000004E15E034.00007915 Message-ID: <4E15E033.9010800@tana.it> Date: Thu, 07 Jul 2011 18:34:59 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: marf@ietf.org References: <4E1040C2.2080508@tana.it> <4E13512E.2050204@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 07 Jul 2011 16:35:03 -0000 On 07/Jul/11 16:17, Barry Leiba wrote: >> I'll follow up shortly with a summary of who has to change what. >> It would be great if we could all do so before the deadline on >> the 11th. > > To be clear: > As chair, I see the consensus on leaving the split as originally > planned. Alessandro has a good point, but I think WG consensus is > against going that way. I respect the WG decision. However, I'd recommend that the discussion of the meaning of r, rf, and ri be factored in the authfailure-report anyway, as it's not yet final and updating it separately in four occurrences would be a nuisance. Currently, authfailure-report proposes an exponential growth of the interval, while the other two drafts account for three slightly different definitions of ri. In no case it is specified how a stateless verifier should behave. From msk@cloudmark.com Thu Jul 7 09:44: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 A727411E807B for ; Thu, 7 Jul 2011 09:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.245 X-Spam-Level: X-Spam-Status: No, score=-103.245 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3C52AwzXh+O for ; Thu, 7 Jul 2011 09:44:44 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8281F0C3E for ; Thu, 7 Jul 2011 09:44:44 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 7 Jul 2011 09:44:43 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 7 Jul 2011 09:44:42 -0700 Thread-Topic: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft Thread-Index: Acw8w9O59+nGPFkiR/KaMJuUCGb2owAAF5TQ Message-ID: References: <4E1040C2.2080508@tana.it> <4E13512E.2050204@tana.it> <4E15E033.9010800@tana.it> In-Reply-To: <4E15E033.9010800@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] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 07 Jul 2011 16:44:44 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Thursday, July 07, 2011 9:35 AM > To: marf@ietf.org > Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim-rep= orting draft >=20 > I respect the WG decision. However, I'd recommend that the discussion > of the meaning of r, rf, and ri be factored in the authfailure-report > anyway, as it's not yet final and updating it separately in four > occurrences would be a nuisance. It seems to me there could be an authentication method declared later that = doesn't want to support a reporting format other than "arf", or for which a= reporting interval doesn't make any sense, so I don't think it's useful to= make them universally-defined properties. However, I suspect a section in the authfailure-report draft suggesting tha= t future extensions will probably need , as advisory text only, would not be harm= ful. > Currently, authfailure-report > proposes an exponential growth of the interval, while the other two > drafts account for three slightly different definitions of ri. I don't see the text you're referencing here about exponential growth in au= thfailure-report. Can you point me to it? I suppose it would be nice if all of the "ri" definitions had identical beh= avior (and I think they currently do), but I don't see a reason to require = it. > In no > case it is specified how a stateless verifier should behave. Since participation in these extensions is not mandatory, I imagine one ele= cting to honor what "ri" says can't be stateless, by definition. -MSK [participant] From sklist@kitterman.com Thu Jul 7 09:57: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 6C9261F0C5B for ; Thu, 7 Jul 2011 09:57:19 -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] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHWhN1f+N2Fb for ; Thu, 7 Jul 2011 09:57:18 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id AA92D1F0C57 for ; Thu, 7 Jul 2011 09:57:18 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 8C80638C140; Thu, 7 Jul 2011 12:57:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1310057837; bh=M1ik7w+qJNkZLHGOT8RW3kqbvlQksjPj9Ptd63Cdaw4=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=eiiL9q7PA70DOocBZQj50NfDG4AnhYQJ238XzcrAqZdQ1LFTdGwG2PL4rEUFYD9/u bsQX94n3ByEchjBA+voKqZHa6GiITcegi2PSHWt+vFN6281nPrugsIjvrsW7+wKfV7 14UmQpttYecld/loH/d/eTD9z7HDJMusS9kB8/Qk= From: Scott Kitterman To: marf@ietf.org Date: Thu, 7 Jul 2011 12:57:16 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic-pae; KDE/4.6.2; i686; ; ) References: <4E15E033.9010800@tana.it> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107071257.16523.sklist@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft 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, 07 Jul 2011 16:57:19 -0000 On Thursday, July 07, 2011 12:44:42 PM Murray S. Kucherawy wrote: ... > Since participation in these extensions is not mandatory, I imagine one > electing to honor what "ri" says can't be stateless, by definition. ... True. I guess the question that ought to be defined is if it's appropriate to participate in only a subset of the extension? I think it would be reasonable to say that if you are going to send auth failure FBRs, then you MUST honor "ri" if specified. That leaves you two choices: 1. Don't be stateless. 2. Don't submit FBRs for any domain that specifices "ri". I think participating in the extension, but ignoring the volume knob is not OK. Scott K From vesely@tana.it Thu Jul 7 10:45:47 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2C01F0C63 for ; Thu, 7 Jul 2011 10:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.863 X-Spam-Level: X-Spam-Status: No, score=-4.863 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2VgF4e5E7Tl for ; Thu, 7 Jul 2011 10:45:46 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 310511F0C62 for ; Thu, 7 Jul 2011 10:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1310060745; bh=vxW5jHem4KbCWi4Br3tALm9mUuVnm5eCcvqHceSJCQM=; l=3099; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=IBzEGWPd7F4xH55cgldN612B2aegCH/lt3lqZSMBBFd99KCdjSpEzmzu3WSgKvC5D qlpgVCTrCV1hIiC8VL92UI+SWDydo+Lt3DcAYNQsBqFW5luXq/3fqGcX4bqreFSGHS h0H56lHs8zbo41wsl2TmmpZVNNdOH0CPlNCRQX5k= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 07 Jul 2011 19:45:45 +0200 id 00000000005DC03F.000000004E15F0C9.00004343 Message-ID: <4E15F0C6.3070400@tana.it> Date: Thu, 07 Jul 2011 19:45:42 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: marf@ietf.org References: <4E1040C2.2080508@tana.it> <4E13512E.2050204@tana.it> <4E15E033.9010800@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [marf] Requested Report Interval, was Cohesion 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, 07 Jul 2011 17:45:47 -0000 [Subject edited] On 07/Jul/11 18:44, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: ietf.org On Behalf Of Alessandro Vesely >> >> I'd recommend that the discussion of the meaning of r, rf, and ri >> be factored in the authfailure-report anyway, as it's not yet >> final and updating it separately in four occurrences would be a >> nuisance. > > It seems to me there could be an authentication method declared > later that doesn't want to support a reporting format other than > "arf", or for which a reporting interval doesn't make any sense, so > I don't think it's useful to make them universally-defined > properties. >From a very general point of view, yes, even if I'm unable to imagine why it would. Those definitions are only relevant to the somewhat restricted "universe" of email authentication failures, which is exactly what the draft addresses. Thus, it will make sense to update it whenever unforeseen requirements arise. > I don't see the text you're referencing here about exponential > growth in authfailure-report. Can you point me to it? Section 7.5: One might even do something inverse-exponentially, sending reports for each of the first ten incidents, then every tenth incident up to 100, then every 100th incident up to 1000, etc. until some period of relative quiet after which the limitation resets. Interesting, isn't it? > I suppose it would be nice if all of the "ri" definitions had > identical behavior (and I think they currently do), but I don't see > a reason to require it. I makes it easier to write and to read them. To wit, expressing identical behavior with different wording would be even worse. On 07/Jul/11 18:57, Scott Kitterman wrote: > On Thursday, July 07, 2011 12:44:42 PM Murray S. Kucherawy wrote: > ... >> Since participation in these extensions is not mandatory, I imagine one >> electing to honor what "ri" says can't be stateless, by definition. > ... > True. I guess the question that ought to be defined is if it's appropriate to > participate in only a subset of the extension? I think it would be reasonable > to say that if you are going to send auth failure FBRs, then you MUST honor > "ri" if specified. That leaves you two choices: > > 1. Don't be stateless. > 2. Don't submit FBRs for any domain that specifices "ri". > > I think participating in the extension, but ignoring the volume knob is not > OK. I agree with Scott. However, in some cases ri might be just a preference (in a previous message I proposed "ri=10e+".) Otherwise, a stateless reporter could generate a random number and calculate a given probability. The incident count won't be exact in such cases. An interval is not exactly the same as a volume knob, as different domains do different volumes. If one is less interested in an exact count, it would make more sense to get the first report and then nothing for the next 99, than completely missing failures that account for less than 100 occurrences per domain. The exponential approach solves this issue nicely. From shmuel+gen@patriot.net Thu Jul 7 11:06: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 9B1A221F84B7 for ; Thu, 7 Jul 2011 11:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQL5Ok5icIJw for ; Thu, 7 Jul 2011 11:06:06 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id DA6491F0C81 for ; Thu, 7 Jul 2011 11:06:00 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.108]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id AF2E1F580B2 for ; Thu, 7 Jul 2011 13:57:29 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Thu, 07 Jul 2011 14:06:04 -0400 To: Message Abuse Report Format working group 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: <20110707175729.AF2E1F580B2@smtp.patriot.net> Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 18:06:07 -0000 In , on 07/06/2011 at 06:19 PM, Barry Leiba said: >To: shmuel+mail-abuse-feedback-report@patriot.net >Cc: Message Abuse Report Format working group Please don't do that. One copy is sufficient. >So, in terms of Murray's message (see below), which arrangement are >you agreeing with? Neither. I'm agreeing with moving details specific to particular authentication messages into drafts other than the main draft or into a registry[1] maintained by IETF or IANA. That imples that - authfailure-report modifies ARF - dkim-reporting refers to but does not modify authfailure-report - spf-reporting refers to but does not modify authfailure-report [1] In particular, the two IANA registries mentioned in section 6 of RFC 5965 -- 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 Thu Jul 7 14:51:59 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7641A21F8901 for ; Thu, 7 Jul 2011 14:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.788 X-Spam-Level: X-Spam-Status: No, score=-103.788 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGNcqOwFzC2y for ; Thu, 7 Jul 2011 14:51: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 CF37A21F88FE for ; Thu, 7 Jul 2011 14:51: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; Thu, 7 Jul 2011 14:51:55 -0700 From: "Murray S. Kucherawy" To: "MARF@ietf.org" Date: Thu, 7 Jul 2011 14:51:54 -0700 Thread-Topic: Working Group Last Call on draft-ietf-marf-not-spam-feedback Thread-Index: Acw88BYIbETXNv8xQPKkAFiAWLrXoQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F134EBC4BC9EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] Working Group Last Call on draft-ietf-marf-not-spam-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: Thu, 07 Jul 2011 21:51:59 -0000 --_000_F5833273385BB34F99288B3648C4F06F134EBC4BC9EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There has been little feedback about the above draft since its submission, = and given its fairly trivial nature and fit within our charter of SpamRep c= onvergence, I believe we're ready to move forward. Therefore... This note declares the beginning of a Working Group Last Call on draft-ietf= -marf-not-spam-feedback, ending on July 21st. Please submit any comments y= ou have about this draft prior to that time, after which we will begin the = process of submitting it to the IESG for review and approval. -MSK, as co-chair --_000_F5833273385BB34F99288B3648C4F06F134EBC4BC9EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There has been l= ittle feedback about the above draft since its submission, and given its fa= irly trivial nature and fit within our charter of SpamRep convergence, I be= lieve we’re ready to move forward.  Therefore…<= /p>

 

This note= declares the beginning of a Working Group Last Call on draft-ietf-marf-not= -spam-feedback, ending on July 21st.  Please submit any com= ments you have about this draft prior to that time, after which we will beg= in the process of submitting it to the IESG for review and approval.

 

-MSK= , as co-chair

 

= --_000_F5833273385BB34F99288B3648C4F06F134EBC4BC9EXCHC2corpclo_-- From johnl@iecc.com Thu Jul 7 15:11: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 BE09D21F87AC for ; Thu, 7 Jul 2011 15:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.066 X-Spam-Level: X-Spam-Status: No, score=-110.066 tagged_above=-999 required=5 tests=[AWL=1.133, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCBXUhnD96Jc for ; Thu, 7 Jul 2011 15:11:01 -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 160CF21F8795 for ; Thu, 7 Jul 2011 15:11:00 -0700 (PDT) Received: (qmail 63119 invoked from network); 7 Jul 2011 22:10:59 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 7 Jul 2011 22:10:59 -0000 Received: (qmail 20057 invoked from network); 7 Jul 2011 22:10:59 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 7 Jul 2011 22:10:59 -0000 Date: 7 Jul 2011 22:10:37 -0000 Message-ID: <20110707221037.47852.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] Working Group Last Call on draft-ietf-marf-not-spam-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: Thu, 07 Jul 2011 22:11:01 -0000 >This note declares the beginning of a Working Group Last Call on >draft-ietf-marf-not-spam-feedback, ending on July 21st. Please >submit any comments you have about this draft prior to that time, >after which we will begin the process of submitting it to the IESG >for review and approval. I have my doubts about its utility, but it seems at worst harmless, so it's OK with me. R's, John From jdfalk-lists@cybernothing.org Thu Jul 7 16:53:02 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0416F11E8077 for ; Thu, 7 Jul 2011 16:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pnkf9LJ2BZLS for ; Thu, 7 Jul 2011 16:53:01 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id 18EF49E800B for ; Thu, 7 Jul 2011 16:53:00 -0700 (PDT) Received: from [192.168.11.36] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p67Nqvth019238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 7 Jul 2011 16:52:59 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: <20110707221037.47852.qmail@joyce.lan> Date: Thu, 7 Jul 2011 16:52:57 -0700 Content-Transfer-Encoding: 7bit Message-Id: <47AD4EAC-5F98-4BBB-AB96-D9C9C6605D37@cybernothing.org> References: <20110707221037.47852.qmail@joyce.lan> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-not-spam-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: Thu, 07 Jul 2011 23:53:02 -0000 On Jul 7, 2011, at 3:10 PM, John Levine wrote: >> This note declares the beginning of a Working Group Last Call on >> draft-ietf-marf-not-spam-feedback, ending on July 21st. Please >> submit any comments you have about this draft prior to that time, >> after which we will begin the process of submitting it to the IESG >> for review and approval. > > I have my doubts about its utility, but it seems at worst harmless, > so it's OK with me. +1 to all three of John's points. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From julian@mehnle.net Sat Jul 9 20:24: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 39CDC21F8A1B for ; Sat, 9 Jul 2011 20:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXy-1qmA60rB for ; Sat, 9 Jul 2011 20:24:39 -0700 (PDT) Received: from io.link-m.de (io.link-m.de [89.250.128.34]) by ietfa.amsl.com (Postfix) with ESMTP id E583F21F8804 for ; Sat, 9 Jul 2011 20:24:38 -0700 (PDT) Received: from [10.0.2.15] (70-36-140-2.dsl.dynamic.sonic.net [::ffff:70.36.140.2]) (AUTH: CRAM-MD5 julian@mehnle.net, TLS: TLSv1/SSLv3, 256bits, AES256-SHA) by io.link-m.de with esmtp; Sun, 10 Jul 2011 03:24:36 +0000 id 00000000002793BB.000000004E191B74.00000EC2 From: Julian Mehnle To: marf@ietf.org Date: Sun, 10 Jul 2011 03:24:09 +0000 User-Agent: KMail/1.9.9 References: <20110628133507.5389.21089.idtracker@ietfa.amsl.com> <201106280942.04119.sklist@kitterman.com> In-Reply-To: <201106280942.04119.sklist@kitterman.com> MIME-Version: 1.0 Content-Disposition: inline X-Length: 1270 X-UID: 810 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201107100324.18724.julian@mehnle.net> Cc: SPF Discussion Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-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, 10 Jul 2011 03:24:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Scott Kitterman wrote: > On Tuesday, June 28, 2011 09:35:07 AM internet-drafts@ietf.org wrote: > ... > > > Title : SPF Authentication Failure Reporting using the > > Abuse Report Format > > Author(s) : Scott Kitterman > > ... > > This is the first draft of the split out document. Please review and > let me know how it can be improved. Interesting. As you personally asked me to do, here's a thorough review. Shouldn't it say "Updates: 4408, 5965" at the top? Can a Standards Track document refer *normatively* to an Experimental document (RFC 4408)? (Nota bene, I'm all for this document, I'm merely posing the formal question.) In section 3, "Optional Reporting Address for SPF", in the "r=" definition, why is it a "SHOULD" in "an e-mail address to which a report SHOULD be sent"? Anyone following this document should be told they MUST send a report to that e-mail address (subject to the ri=/ro= specifications); anyone *not* following this document will do what they want anyway (with regard to this document). Perhaps it's better to word this as follows: "A local-part or addr-spec (...) specifying an e-mail address to which the domain owner expects reports to be sent when ..." In the same paragraph it says: "The format of this reply" — s/reply/report/. It says: "the domain whose policy was queried" — this might be ambiguous in the context of a possible future overarching policy standard, so s/policy/SPF record/ (the remainder of the sentence can then probably be removed). In the same paragraph the ABNF grammar is incorrect: the SPF grammar does *not* allow WSP around the "=" character. The same problem exists in the later grammar rules in this document. Generally, SPF modifiers may not contain any WSP at all, not even in the modifier value. In the "rf=" definition, I think it is questionable to REQUIRE ("MUST") report generators to generate reports in the first format from the list of preferred formats they are capable of generating. Report generators may have preferences of their own (for whatever reason), and there is no point in this document declaring a generator incompliant if it chooses to generate reports in a format *less* preferred by a domain owner even though it could theoretically generate a more preferred format. IOW, make this a "SHOULD". On the other hand, the last sentence specifying the case when no supported formats are requested should end in "then any reports MUST NOT be sent"; there *is* a point in declaring generators sending reports in unrequested formats incompliant. The same paragraph refers to a description of a reporting format registry in section 5, but section 5 does not establish such a registry. In the "ri=" definition, the semantics of the interval mechanism are weird. E.g., an "ri" value of 0 meaning anything other than "send no reports" is counterintuitive. Also the meaning of a value of 1 is unclear — does it mean "report on every failure" (like a value of 0) or "report on 1/2 of failures"? I assume this is because the mechanism was designed foremost to be easy to implement. However, I think it is more important that the mechanism be easy to understand by domain owners. A relative downsampling factor (a fractional number from 0 to 1) would be functionally equivalent but easier to understand by domain owners, while being similarly easy to implement. I see there is also talk about the possibility of an exponential backoff. Whatever satisfies the real world needs and is easy to understand. Consider making this extensible by syntax (e.g., by using a mode indicator as the "ri=" value's last character, so new modes can be defined in the future). Also, the meaning of "type of incident" is completely unclear. Does this refer to all SPF failures for the domain, or are SoftFail results to be tracked separately from Fail results? What about PermError results? Does this refer to the "ro=" types listed in section 4? If so, this is not clear. And are there perhaps even more elements to a certain "type of incident"? Does this interact with other authentication methods? Does a report on a message that failed SPF also count against the *DKIM* reporting interval if the message happened to also have failed DKIM? In the "ro=" definition, the ABNF grammar should be changed to make the "all" token mutually exclusive with a colon-separated list of tokens. Would it perhaps be more obvious to use the full SPF result code names instead of one-letter tokens? The "rs=" definition is suboptimal because the SPF grammar disallows WSP or quoted-atoms. While the current grammar specified by the "rs=" definition provides for this by requiring the value to be quoted-printable encoded (which turns whitespace into "=20"), this is still not very useful because any meaningful message would eat up a lot of space in the SPF record, which is already limited in size due to DNS limitations. I think it would be more useful to have "rs=" refer to a DNS name, under which a TXT record with the desired message will be found, similar to SPF's existing "exp=" modifier. That message should also be subject to macro expansion just like "exp=" messages. Finally, it would be more consistent (with "exp=") to then call this new modifier "rexp=" or "re=" or "rx=". In section 6.2, "Reports From Unrelated Domains", the scenario described is a problem only for domains referenced via "redirect=" modifiers, not for ones referenced via "include:" mechanisms, since section 3 explicitly specifies that r= modifiers in records found by following an "include:" mechanism must be ignored. However, perhaps section 3 should also say the same thing about records found by following a "redirect=" modifier, even though that makes specifying reporting parameters an inconvenience for domain owners who legitimately use "redirect=" a lot. Section 6.3, "Forgeries", commingles forgeries/fabrications and denial-of-service attacks, which are generally (as well as specifically in this context, as far I as can see) separate issues. What's the DoS issue in this context? The concern about forgeries remains unresolved. The section merely presents a few options, but then goes nowhere. I understand that the options presented (yet not mandated) are problematic. Does this perhaps *require* further discussion before this document is advanced? If no acceptable solutions are developed, then the section should be rephrased to merely warn about the possibility of fabricated reports and perhaps briefly explain why the apparent solutions were discarded. Section 6.4, "Automatic Generation", seems to appeal to verifying agents' sense of responsibility. This seems pointless. Perhaps this section would be better converted into a warning to domain owners publishing "r=" that large volumes of reports (legitimate or fabricated) should be expected. Similar things could be said about the volume related concerns in section 6.6, "Reporting Multiple Incidents". Section B constitutes a good opportunity for explaining the semantics of the "ri=" modifier as well as demonstrating the multiple-tokens support in the "ro=" modifier. Also, the positioning of the r*= modifiers within the SPF record insinuates that there might be a relevance to it. Per RFC 4408 there is not. Either state this clearly or move the r*= modifiers after the "-all" mechanisms. This will help avoid misunderstandings. So long, - -Julian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk4ZG2IACgkQwL7PKlBZWjtmIQCg18sZ9iDhNYMYcddK0AKnHxHS mz4AoPJPkqS0FCXaigl5ja1644Cv25FN =TZrF -----END PGP SIGNATURE----- From vesely@tana.it Sun Jul 10 06:33:26 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 297E721F86EF for ; Sun, 10 Jul 2011 06:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.913 X-Spam-Level: X-Spam-Status: No, score=-4.913 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKX3Ln-rI5G3 for ; Sun, 10 Jul 2011 06:33:25 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCAA21F86EE for ; Sun, 10 Jul 2011 06:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1310304803; bh=07r1vI+GyBF17PBiLDjkeoo+JFBCQcSxNDuL9A11GiU=; l=1971; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Y/tdwdaketQOiTIJcbbZhcq5o7j01PCfvYMdoUu33JZXrXoHsrv7wwF1gEQsoPYC9 jkF+Bz1kwFx47WbCMDsJ4o35bbYr42grVm1vYAK34Rmb+/OH9fY9BoOyy7Km88z0NX WAV7J20tolYPpXaI/5XGwY1DWVgQbm0MVvfQXyjQ= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 10 Jul 2011 15:33:23 +0200 id 00000000005DC039.000000004E19AA23.0000616B Message-ID: <4E19AA22.8060009@tana.it> Date: Sun, 10 Jul 2011 15:33:22 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: marf@ietf.org References: <4E1040C2.2080508@tana.it> <4E13512E.2050204@tana.it> <4E15E033.9010800@tana.it> <4E15F0C6.3070400@tana.it> In-Reply-To: <4E15F0C6.3070400@tana.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Requested Report Interval: stateless cache-driven exponential decrease 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, 10 Jul 2011 13:33:26 -0000 > Section 7.5: > > One might even do something > inverse-exponentially, sending reports for each of the first ten > incidents, then every tenth incident up to 100, then every 100th > incident up to 1000, etc. until some period of relative quiet after > which the limitation resets. I've been wandering about such period. If we use the record's Time-To-Live (TTL) we can specify stateless reporting like so: On diagnosing a failure, the agent generates a random number R in the interval [0, 1] (or sets R=0.5). It then computes a value P using numeric values from the retrieved RR and a formula to be specified in authfailure-report. If P >= R, then the agent generates and sends the report, otherwise does nothing. P may be computed so as to be near to 1 for newly retrieved records and then decreasing more or less rapidly, according to the value of ri. The following gnuplot snippet displays suitably scaled Gaussian curves (aka bump functions) for a few values of ri -----8<----------8<-------cut-here-------8<----------8<----- #! /usr/bin/gnuplot -p reset set title 'P = p(ri*(1 - TTL/TTLMAX)) for TTLMAX=86400' set xrange [0:86400] set key left e=exp(1) p(x) = abs(x)<1? e*exp(-1/(1-x**2)): 0 plot p(1*(1 - x/86400)), \ p(2*(1 - x/86400)), \ p(3*(1 - x/86400)), \ p(4*(1 - x/86400)), \ p(5*(1 - x/86400)) -----8<----------8<-------cut-here-------8<----------8<----- pros: * supports stateless agents, * probability decreases exponentially, * automatic period reset, * leverages DNS cache, thus favoring reporting to "new" (not cached) domains, i.e. from infrequently targeted agents whose A-Rs are more likely to be yet unknown. cons: * Issuers might need a different TTL for reasons independent of failure reporting, * agents using a resolver that may deliver second hand RRs would seldom get a TTL near to TTLMAX, and * TTLMAX (or similar value) has to be explicitly written in the RR. Thoughts? From barryleiba.mailing.lists@gmail.com Sun Jul 10 06:34:23 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 5567A21F86F0 for ; Sun, 10 Jul 2011 06:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.13 X-Spam-Level: X-Spam-Status: No, score=-103.13 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5m6S6j8Sfql for ; Sun, 10 Jul 2011 06:34:22 -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 C6E9D21F86EE for ; Sun, 10 Jul 2011 06:34:22 -0700 (PDT) Received: by gxk19 with SMTP id 19so851730gxk.31 for ; Sun, 10 Jul 2011 06:34:22 -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=Wlrthy4WOj1qcsP+P33b+bPKqJUiqD4EP9w+yad19xo=; b=xoHANngNTK1nY5xpY+MjjxViG0XUwizKzplW/eu1iOlJyuLYU4Z72anQf8LMsBhvVO Lx6jWLNmyjUJXzb0mWBJ8oM6EmiciYZAptiGaDhd2LjGeKxJ5X2fXH/+mXu4RSFuUojn 4c+okTrdjQ52+btmFMNfyyV9lyL0RkG1J3XBs= MIME-Version: 1.0 Received: by 10.236.76.167 with SMTP id b27mr4154328yhe.336.1310304862248; Sun, 10 Jul 2011 06:34:22 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.41.12 with HTTP; Sun, 10 Jul 2011 06:34:22 -0700 (PDT) In-Reply-To: <201107100324.18724.julian@mehnle.net> References: <20110628133507.5389.21089.idtracker@ietfa.amsl.com> <201106280942.04119.sklist@kitterman.com> <201107100324.18724.julian@mehnle.net> Date: Sun, 10 Jul 2011 09:34:22 -0400 X-Google-Sender-Auth: L3RolSz-Z6YzYP4fh77bx-8J864 Message-ID: From: Barry Leiba To: Julian Mehnle Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SPF Discussion , marf@ietf.org Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-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, 10 Jul 2011 13:34:23 -0000 > Can a Standards Track document refer *normatively* to an Experimental > document (RFC 4408)? =A0(Nota bene, I'm all for this document, I'm merely > posing the formal question.) Indeed; this is a question we'll have to discuss with our AD, to figure out what the right way to go is. There are some people wanting to clean up the SPF spec and put it on Standards Track. Perhaps this document can wait for that. Perhaps this document can be made Experimental, and then both docs can move to Standards Track at the same time. Perhaps we can get the IESG to allow the down-ref. We'll have to see. Barry, as MARF chair From bmcdowell@paypal-inc.com Sun Jul 10 08:12:23 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 DC4EE21F85BB for ; Sun, 10 Jul 2011 08:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.11 X-Spam-Level: X-Spam-Status: No, score=-8.11 tagged_above=-999 required=5 tests=[AWL=1.007, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JeW2OvVqxz8 for ; Sun, 10 Jul 2011 08:12:23 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by ietfa.amsl.com (Postfix) with ESMTP id E91AA21F85DB for ; Sun, 10 Jul 2011 08:12:22 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=Ezph9hW2/47N6wxyYlpp6+ZfRd57f0Ocs4FKFeBYPxWlB3qt7QvAmhJ0 OTRihoPVSr1PB41vsZdeFCPRJAgXMfBxuEdXqQeGtfEeh3fpl8PeuZyKt +FDDhDb40CdbyW2; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bmcdowell@paypal-inc.com; q=dns/txt; s=ppinc; t=1310310743; x=1341846743; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/G8lvrpgQ1e2dFlJX0dXPLjobDNzWQhNK8ajAMjsT4o=; b=ZD+OrGbmMwOziv0ceCSaHWGW1f+26Ro5idKG/lPm/blA0pUCGnY2ZxWI bYcC4+CPj4cAY0OXI9rwbegQxitgpfc2urpiBALxwv/JGZi7TH2gEt7Mv xO+IIiLsQH1LYjt; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.65,508,1304319600"; d="scan'208";a="3146886" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-003.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 10 Jul 2011 08:12:18 -0700 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-003.corp.ebay.com ([10.241.17.54]) with mapi; Sun, 10 Jul 2011 09:12:18 -0600 From: "McDowell, Brett" To: Barry Leiba Date: Sun, 10 Jul 2011 09:11:47 -0600 Thread-Topic: [marf] I-D Action: draft-ietf-marf-spf-reporting-00.txt Thread-Index: Acw/E8H+ZLzzfy6bQGGykCu5E9kYpQ== Message-ID: <1AC335A1-5C7C-4347-9175-B2098428D499@paypal-inc.com> References: <20110628133507.5389.21089.idtracker@ietfa.amsl.com> <201106280942.04119.sklist@kitterman.com> <201107100324.18724.julian@mehnle.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: j8jYMxllI2mBtyMTMfAVMA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: SPF Discussion , "marf@ietf.org" Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-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, 10 Jul 2011 15:12:24 -0000 This is an important topic for sure. --- Sent from my mobile phone On Jul 10, 2011, at 9:36 AM, "Barry Leiba" wrote: >> Can a Standards Track document refer *normatively* to an Experimental >> document (RFC 4408)? (Nota bene, I'm all for this document, I'm merely >> posing the formal question.) >=20 > Indeed; this is a question we'll have to discuss with our AD, to > figure out what the right way to go is. There are some people wanting > to clean up the SPF spec and put it on Standards Track. Perhaps this > document can wait for that. Perhaps this document can be made > Experimental, and then both docs can move to Standards Track at the > same time. Perhaps we can get the IESG to allow the down-ref. We'll > have to see. >=20 > Barry, as MARF chair > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf From hmurray@megapathdsl.net Sun Jul 10 23:29: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 8D8F121F89C8 for ; Sun, 10 Jul 2011 23:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.288 X-Spam-Level: **** X-Spam-Status: No, score=4.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65inSzTRICph for ; Sun, 10 Jul 2011 23:29:27 -0700 (PDT) Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by ietfa.amsl.com (Postfix) with ESMTP id 151D321F89C2 for ; Sun, 10 Jul 2011 23:29:27 -0700 (PDT) Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 1D1C2800037; Sun, 10 Jul 2011 23:29:26 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: marf@ietf.org From: Hal Murray Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Jul 2011 23:29:26 -0700 Message-Id: <20110711062926.1D1C2800037@ip-64-139-1-69.sjc.megapath.net> Cc: Hal Murray Subject: Re: [marf] Requested Report Interval: stateless cache-driven exponential decrease 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, 11 Jul 2011 06:29:27 -0000 > I've been wandering about such period. If we use the record's Time-To-Live > (TTL) we can specify stateless reporting like so: Piggybacking on the TTL field seems like a bad idea. A big system might be loafing at X reports per second while the same load could kill a small system or saturate a smaller link. So you have to distribute something like a scale factor. I'm assuming that would be done over DNS. At that point you might as well distribute the real data. -------- > On diagnosing a failure, the agent generates a random number R in the > interval [0, 1] (or sets R=0.5). It then computes a value P using numeric > values from the retrieved RR and a formula to be specified in > authfailure-report. If P >= R, then the agent generates and sends the > report, otherwise does nothing. > P may be computed so as to be near to 1 for newly retrieved records and then > decreasing more or less rapidly, according to the value of ri. The > following gnuplot snippet displays suitably scaled Gaussian curves (aka bump > functions) for a few values of ri What are the goals of this section? I assume the main idea is to avoid overloading (DoS) the receiving system. There are two parts to that. How many reports are coming from each system, and how many systems are contributing to the overall load. I like the idea of an exponential backoff. What are the appropriate parameters? What data would the sending system need in order to do the right thing? Should this type of reporting be moved to a separate socket or separate IP Address? (so a TCP level reject/timeout can be used to trigger the backoff) --------- Would it help to batch the data (at the report stage)? If you are the receiving system, what fraction of your CPU/whatever resources are spent processing the connection vs processing the data for a "report" transmitted over that connection? If I have 100 reports per hour, would you like to get them batched in one message rather than 100 separate messages? -- These are my opinions, not necessarily my employer's. I hate spam. From vesely@tana.it Mon Jul 11 08:42: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 24D6221F86D8 for ; Mon, 11 Jul 2011 08:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.899 X-Spam-Level: X-Spam-Status: No, score=-4.899 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yThVOctSPUpx for ; Mon, 11 Jul 2011 08:42:31 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6DC21F86A0 for ; Mon, 11 Jul 2011 08:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1310398907; bh=DY0bNw7JTSXcgLlvVoaeaPK3jDAjDdi0uDxBufqbtMw=; l=3970; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=j3dslB7uhNzizsqWU/yf8yHaVs0JE2R6MVt/gvw8tXjENyED+IKyy6HLDyt3lrm3o S5tHFcvSOKjS3smnCoBgvUdvjRxugKBCTWEUzsA4vWD/mQSdw/ylLNnZmjJnDzWiqp H1gFmK64kr52T+GWb+njgYrpzoyb0tAa0Kr6t7w8= 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, 11 Jul 2011 17:41:47 +0200 id 00000000005DC045.000000004E1B19BB.00004AE0 Message-ID: <4E1B19B9.2080508@tana.it> Date: Mon, 11 Jul 2011 17:41:45 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: marf@ietf.org References: <20110711062926.1D1C2800037@ip-64-139-1-69.sjc.megapath.net> In-Reply-To: <20110711062926.1D1C2800037@ip-64-139-1-69.sjc.megapath.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Requested Report Interval: stateless cache-driven exponential decrease 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, 11 Jul 2011 15:42:32 -0000 On 11/Jul/11 08:29, Hal Murray wrote: > >> I've been wandering about such period. If we use the record's Time-To-Live >> (TTL) we can specify stateless reporting like so: > > Piggybacking on the TTL field seems like a bad idea. A big system might be > loafing at X reports per second while the same load could kill a small system > or saturate a smaller link. So you have to distribute something like a scale > factor. I'm assuming that would be done over DNS. At that point you might > as well distribute the real data. I assume you mean "/receiving/ X reports per second". I reckon X is proportional to the size of the domain anyway: a large domain sends much mail, part of which may cause authentication failures, and is more heavily phished than a small domain. The current ri parameter provides for setting a /linear/ scale factor, whereby a domain can say it is only interested in getting, say, 25% of failure reports. Such linear behavior can be achieved in a stateless manner by tossing R and sending if R <= 0.25. Linear and exponential cutoffs don't have to be mutually exclusive. > -------- > >> On diagnosing a failure, the agent generates a random number R in >> the interval [0, 1] (or sets R=0.5). It then computes a value P >> [...] If P >= R, then the agent generates and sends the report, >> otherwise does nothing. > >> P may be computed so as to be near to 1 for newly retrieved >> records and then decreasing more or less rapidly, according to >> the value of ri. > > What are the goals of this section? Since the reporter does not know what failures might be important for a domain, varying the criteria on which reports are discarded may better the chances to report something useful. > I assume the main idea is to avoid overloading (DoS) the receiving system. > There are two parts to that. How many reports are coming from each system, > and how many systems are contributing to the overall load. Yes. Each contributing system looks up the DNS record when a message arrives. Larger systems will use the cached version of that record repeatedly until it expires, if they receive a nearly continuous stream of messages. A small system possibly uses it just once. A sharp Gaussian probability centered on TTL can thus increase the relative visibility of the latter. > I like the idea of an exponential backoff. What are the appropriate > parameters? What data would the sending system need in order to do the right > thing? We should do some simulations to ascertain that. > Should this type of reporting be moved to a separate socket or separate IP > Address? (so a TCP level reject/timeout can be used to trigger the backoff) I don't think so, it'd be a rather blind trigger. > --------- > > Would it help to batch the data (at the report stage)? If you are the > receiving system, what fraction of your CPU/whatever resources are spent > processing the connection vs processing the data for a "report" transmitted > over that connection? If I have 100 reports per hour, would you like to get > them batched in one message rather than 100 separate messages? Yes, I certainly would. Indeed, this is what is currently being specified. However, exactly one message has to be attached to the report. For the other failures the reporter can only supply a count, implying they are "similar" in some sense. Does that mean they all had the same Auth-Failure type? Local-part? Did each failure occur today? How are multiple recipients being counted? I'd never know. Computing a probability, however complicate it may seem, can be done in a few lines of code and yields coherent results across most modern systems. Batching requires more implementation effort and more CPU cycles for the reporter, as it implies maintaining tables indexed on domain names. I think that mandating such behavior would exclude more contributing sites than the stateless approach. From sklist@kitterman.com Mon Jul 11 12:25:23 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 97BA711E8114 for ; Mon, 11 Jul 2011 12:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFraICfQXd-N for ; Mon, 11 Jul 2011 12:25:19 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2557611E80EA for ; Mon, 11 Jul 2011 12:25:19 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 6B6D738C168; Mon, 11 Jul 2011 15:25:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1310412317; bh=1NqWa7Yxz7145dXTwmbcg98HO52f4CJZqRVUO3Jw80c=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=jPKQfXMmSE9vVSIiYv2uBVyyGhivIEfG2mxyirkS/uIuHJZ5TnU+XAHTlGW5GQNs2 Vo69eBqqsXDFE97PtaQ8IN72lttbzxt5019tEv+r01vKvzhnH7YxA/WmGbZBDILkTi Dk2Jw0OOgqhfQJLzOY12GMdLwOaS5QrxnrPtpjgk= From: Scott Kitterman To: marf@ietf.org Date: Mon, 11 Jul 2011 15:25:14 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic-pae; KDE/4.6.2; i686; ; ) References: <20110628133507.5389.21089.idtracker@ietfa.amsl.com> <201107100324.18724.julian@mehnle.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107111525.14724.sklist@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-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: Mon, 11 Jul 2011 19:25:23 -0000 On Sunday, July 10, 2011 09:34:22 AM Barry Leiba wrote: > > Can a Standards Track document refer *normatively* to an Experimental > > document (RFC 4408)? (Nota bene, I'm all for this document, I'm merely > > posing the formal question.) > > Indeed; this is a question we'll have to discuss with our AD, to > figure out what the right way to go is. There are some people wanting > to clean up the SPF spec and put it on Standards Track. Perhaps this > document can wait for that. Perhaps this document can be made > Experimental, and then both docs can move to Standards Track at the > same time. Perhaps we can get the IESG to allow the down-ref. We'll > have to see. > > Barry, as MARF chair I've started working on such an update in conjunction with one of the original RFC 4408 authors. Obviously I didn't make the cut off for this IETF, but I don't expect this to be a particularly long or difficult process (the clarifications needed for a 4408bis are reasonably well documented and minor). There is a roughly zero percent chance of there being technical changes in 4408bis that would affect draft-ietf-marf-spf-reporting. The one thing that might affect it would be, depending on the relative timing, if we moved the SPF modifier registry from draft-ietf-marf-spf-reporting to 4408bis. My intent is to proceed (for now) as if the downref will be allowed. Doing this as experimental and then revising it shortly thereafter seems like pointless paperwork to me. If, down the road, it needs to be adjusted, I'll adjust. Scott K From johnl@iecc.com Mon Jul 11 13:12: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 F130E21F8F2C for ; Mon, 11 Jul 2011 13:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.117 X-Spam-Level: X-Spam-Status: No, score=-110.117 tagged_above=-999 required=5 tests=[AWL=1.082, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORobxTIrU7pr for ; Mon, 11 Jul 2011 13:12:03 -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 CE71121F8695 for ; Mon, 11 Jul 2011 13:11:51 -0700 (PDT) Received: (qmail 27488 invoked from network); 11 Jul 2011 20:11:48 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 11 Jul 2011 20:11:48 -0000 Received: (qmail 28813 invoked from network); 11 Jul 2011 20:11:48 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 11 Jul 2011 20:11:48 -0000 Date: 11 Jul 2011 20:11:26 -0000 Message-ID: <20110711201126.2404.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <20110711062926.1D1C2800037@ip-64-139-1-69.sjc.megapath.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] Requested Report Interval: stateless cache-driven exponential decrease 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, 11 Jul 2011 20:12:04 -0000 >> On diagnosing a failure, the agent generates a random number R in the >> interval [0, 1] (or sets R=0.5). It then computes a value P using numeric >> values from the retrieved RR and a formula to be specified in >> authfailure-report. If P >= R, then the agent generates and sends the >> report, otherwise does nothing. Standards only work when it is mutually beneficial to both parties to implement them. What is the benefit to the reporting party of implementing this complex mess? If there's any rate limiting at all, keep it to something easy to implement, like a maximum number of reports per hour. R's, John From sklist@kitterman.com Mon Jul 11 15:31: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 7905E11E833B for ; Mon, 11 Jul 2011 15:31:38 -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=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCTIfbDoHb+i for ; Mon, 11 Jul 2011 15:31:37 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFB511E8332 for ; Mon, 11 Jul 2011 15:31:37 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 6F2F938C107; Mon, 11 Jul 2011 18:31:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1310423496; bh=0IBg0fR40CTPImDLD5h7deirw7/49cXujE9m71XExHo=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=P2R4JIptgcqfqEu0pkfB3Px034SBe130DCbIoTrNv+nTQu922XxMHyEq4MOcj8XpQ SNz2jIURVo6q0aNaRPX6xVsFDOVdbRTXjvKIdGhmCkCo7+tN8nTKOy4gw/GRUYnugp K1LvCfMXpHUhjZdGcZsVyLJZVpTkP4D0r/ISa/+8= From: Scott Kitterman To: marf@ietf.org Date: Mon, 11 Jul 2011 18:31:35 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic-pae; KDE/4.6.2; i686; ; ) References: <20110628133507.5389.21089.idtracker@ietfa.amsl.com> <201106280942.04119.sklist@kitterman.com> <201107100324.18724.julian@mehnle.net> In-Reply-To: <201107100324.18724.julian@mehnle.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201107111831.35685.sklist@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-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: Mon, 11 Jul 2011 22:31:38 -0000 On Saturday, July 09, 2011 11:24:09 PM Julian Mehnle wrote: > Scott Kitterman wrote: > > On Tuesday, June 28, 2011 09:35:07 AM internet-drafts@ietf.org wrote: > > ... > >=20 > > > Title : SPF Authentication Failure Reporting using the > > > =09 > > > Abuse Report Format > > > =20 > > > Author(s) : Scott Kitterman > >=20 > > ... > >=20 > > This is the first draft of the split out document. Please review and > > let me know how it can be improved. >=20 > Interesting. As you personally asked me to do, here's a thorough review. >=20 > Shouldn't it say "Updates: 4408, 5965" at the top? No, because it doesn't actually change those RFCs, it provides extensions. = =20 Due to the IANA modifier registry, that might be appropriate for 4408, I'm = not=20 sure. > Can a Standards Track document refer *normatively* to an Experimental > document (RFC 4408)? (Nota bene, I'm all for this document, I'm merely > posing the formal question.) Addresses already in a different sub-thread. > In section 3, "Optional Reporting Address for SPF", in the "r=3D" > definition, why is it a "SHOULD" in "an e-mail address to which a report > SHOULD be sent"? Anyone following this document should be told they MUST > send a report to that e-mail address (subject to the ri=3D/ro=3D > specifications); anyone *not* following this document will do what they > want anyway (with regard to this document). Perhaps it's better to word > this as follows: >=20 > "A local-part or addr-spec (...) specifying an e-mail address to which > the domain owner expects reports to be sent when ..." I think SHOULD is reasonable here. In general terms SHOULD =3D MUST unless= you=20 have a good reason why not. I think that's OK in this context (an example= =20 might be not sending reports if the sending system were under heavy load). > In the same paragraph it says: "The format of this reply" =E2=80=94 > s/reply/report/. It says: "the domain whose policy was queried" =E2=80= =94 this > might be ambiguous in the context of a possible future overarching policy > standard, so s/policy/SPF record/ (the remainder of the sentence can then > probably be removed). What I'm going for here is to make sure that it's clear that the following= =20 should occur: 1. Don't send an FBR due to mechanisms specified in a record that is=20 'included' in another domain's record. If an ISP uses these mechanisms in= =20 their SPF record and that SPF record is included in other records by their= =20 customers, that shouldn't be a trigger for a report. 2. If only the localpart of the email address is specified, the domain par= t=20 that should be appended should be the original domain, not the on that's=20 'current'. This would give a logical behavior with redirect=3D The distinction between these two (and I know you know this) is that includ= e:=20 is meant to traverse administrative boundaries (so the FBR policy should no= t=20 cross that boundary) and redirect=3D is meant to be used with an administra= tive=20 boundary, so FBR policy should follow. With this construct, using the loca= l=20 part produces a per-domain reporting address for each domain within the=20 administrative group and using the full address produces one common address= =20 for all domains. I took another shot at it. Let me know if it's not clear yet. > In the same paragraph the ABNF grammar is incorrect: the SPF grammar does > *not* allow WSP around the "=3D" character. The same problem exists in t= he > later grammar rules in this document. Generally, SPF modifiers may not > contain any WSP at all, not even in the modifier value. =46ixed. > In the "rf=3D" definition, I think it is questionable to REQUIRE ("MUST") > report generators to generate reports in the first format from the list > of preferred formats they are capable of generating. Report generators > may have preferences of their own (for whatever reason), and there is no > point in this document declaring a generator incompliant if it chooses to > generate reports in a format *less* preferred by a domain owner even > though it could theoretically generate a more preferred format. IOW, > make this a "SHOULD". On the other hand, the last sentence specifying > the case when no supported formats are requested should end in "then any > reports MUST NOT be sent"; there *is* a point in declaring generators > sending reports in unrequested formats incompliant. I agree. Changed. If you don't want reports in a certain format, don't pu= t=20 them on the list. > The same paragraph refers to a description of a reporting format > registry in section 5, but section 5 does not establish such a registry. Agreed. I think that goes in draft-ietf-marf-authfailure-report and so I'v= e=20 changed the reference, although it doesn't look to me like it's covered the= re. > In the "ri=3D" definition, the semantics of the interval mechanism are > weird. E.g., an "ri" value of 0 meaning anything other than "send no > reports" is counterintuitive. Also the meaning of a value of 1 is > unclear =E2=80=94 does it mean "report on every failure" (like a value of= 0) or > "report on 1/2 of failures"? I assume this is because the mechanism was > designed foremost to be easy to implement. However, I think it is more > important that the mechanism be easy to understand by domain owners. > A relative downsampling factor (a fractional number from 0 to 1) would be > functionally equivalent but easier to understand by domain owners, while > being similarly easy to implement. I see there is also talk about the > possibility of an exponential backoff. Whatever satisfies the real world > needs and is easy to understand. Consider making this extensible by > syntax (e.g., by using a mode indicator as the "ri=3D" value's last > character, so new modes can be defined in the future). There's some ongoing discussion about this. I think it should be common=20 between SPF and DKIM, so I'm leaving it for now. I expect the right answer= is=20 to define the semantics in draft-ietf-marf-authfailure-report so it's commo= n=20 the the expression to the method specific drafts. > Also, the meaning of "type of incident" is completely unclear. Does this > refer to all SPF failures for the domain, or are SoftFail results to be > tracked separately from Fail results? What about PermError results? > Does this refer to the "ro=3D" types listed in section 4? If so, this is > not clear. And are there perhaps even more elements to a certain "type > of incident"? Does this interact with other authentication methods? > Does a report on a message that failed SPF also count against the *DKIM* > reporting interval if the message happened to also have failed DKIM? There is currently no interaction between SPF and DKIM (by design - maybe=20 later). Type in this context means SPF/DKIM (if people think it should be= =20 different, let's discuss). I've clarified and will fix it more later if pe= ople=20 think that's wrong. > In the "ro=3D" definition, the ABNF grammar should be changed to make the > "all" token mutually exclusive with a colon-separated list of tokens. > Would it perhaps be more obvious to use the full SPF result code names > instead of one-letter tokens? The results aren't exactly SPF results (we combine TempError and PermError= =20 into e and since these go in SPF records in DNS, I think compatctness count= s,=20 so I think it would be more obvious in some respects, but not better to use= =20 the full name. > The "rs=3D" definition is suboptimal because the SPF grammar disallows WSP > or quoted-atoms. While the current grammar specified by the "rs=3D" > definition provides for this by requiring the value to be > quoted-printable encoded (which turns whitespace into "=3D20"), this is > still not very useful because any meaningful message would eat up a lot > of space in the SPF record, which is already limited in size due to DNS > limitations. I think it would be more useful to have "rs=3D" refer to a > DNS name, under which a TXT record with the desired message will be > found, similar to SPF's existing "exp=3D" modifier. That message should > also be subject to macro expansion just like "exp=3D" messages. Finally, > it would be more consistent (with "exp=3D") to then call this new modifier > "rexp=3D" or "re=3D" or "rx=3D". Looking it over again, I think it's redundant with exp=3D and domains shoul= d=20 just use that. I'll remove it. > In section 6.2, "Reports From Unrelated Domains", the scenario described > is a problem only for domains referenced via "redirect=3D" modifiers, not > for ones referenced via "include:" mechanisms, since section 3 explicitly > specifies that r=3D modifiers in records found by following an "include:" > mechanism must be ignored. However, perhaps section 3 should also say > the same thing about records found by following a "redirect=3D" modifier, > even though that makes specifying reporting parameters an inconvenience > for domain owners who legitimately use "redirect=3D" a lot. Given that redirect is intended to be used within an administrative domain,= I=20 think it's appropriate to not have a similar rule for redirect=3D. I think= the=20 modified text in the record construction paragraph makes it clearer. Let m= e=20 know what you think. > Section 6.3, "Forgeries", commingles forgeries/fabrications and > denial-of-service attacks, which are generally (as well as specifically > in this context, as far I as can see) separate issues. What's the DoS > issue in this context? >=20 > The concern about forgeries remains unresolved. The section merely > presents a few options, but then goes nowhere. I understand that the > options presented (yet not mandated) are problematic. Does this perhaps > *require* further discussion before this document is advanced? If no > acceptable solutions are developed, then the section should be rephrased > to merely warn about the possibility of fabricated reports and perhaps > briefly explain why the apparent solutions were discarded. I think this is no more/no less a reminder that these emails suffer the sam= e=20 problems as email in general. I think that it's ~OK as is, but I'm open to= =20 suggestions for improvement. > Section 6.4, "Automatic Generation", seems to appeal to verifying agents' > sense of responsibility. This seems pointless. Perhaps this section > would be better converted into a warning to domain owners publishing "r= =3D" > that large volumes of reports (legitimate or fabricated) should be > expected. Similar things could be said about the volume related concerns > in section 6.6, "Reporting Multiple Incidents". Adjusted. > Section B constitutes a good opportunity for explaining the semantics of > the "ri=3D" modifier as well as demonstrating the multiple-tokens support > in the "ro=3D" modifier. Also, the positioning of the r*=3D modifiers wi= thin > the SPF record insinuates that there might be a relevance to it. Per RFC > 4408 there is not. Either state this clearly or move the r*=3D modifiers > after the "-all" mechanisms. This will help avoid misunderstandings. I moved one of them to make this clear. Since one is now before and one=20 after, I think that makes it even more obvious it can go anywhere. Scott K From internet-drafts@ietf.org Mon Jul 11 15:45:20 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7767711E8369; Mon, 11 Jul 2011 15:45:20 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edTX3y+KJ1ZR; Mon, 11 Jul 2011 15:45:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF6F11E8355; Mon, 11 Jul 2011 15:45:20 -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.55 Message-ID: <20110711224520.4289.48001.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 15:45:20 -0700 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-spf-reporting-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: Mon, 11 Jul 2011 22:45:20 -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 : SPF Authentication Failure Reporting using the Abuse Rep= ort Format Author(s) : Scott Kitterman Filename : draft-ietf-marf-spf-reporting-01.txt Pages : 15 Date : 2011-07-11 This memo presents extensions to the Abuse Reporting Format (ARF), and Sender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-spf-reporting-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-spf-reporting-01.txt From sklist@kitterman.com Mon Jul 11 15:50: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 7D73D11E82B7 for ; Mon, 11 Jul 2011 15:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-TaJZ-7je0m for ; Mon, 11 Jul 2011 15:50:42 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id DAE5F11E80F4 for ; Mon, 11 Jul 2011 15:50:41 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 617CC38C107; Mon, 11 Jul 2011 18:50:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1310424641; bh=q7haVnZo/V8xDUAGl75hgCCtN4woAR4HsWeUSKOKq8A=; h=From:To:Subject:Date:MIME-Version:Content-Type: Content-Transfer-Encoding:Message-Id; b=jfSrVYOiZXVFhlpX0qXfspV60H2x/tujYGzyEzzPz0cMQ097SYpXNWYHNsPfnoV8j g/dm/6Sx+CgO7F+rRCMp2EvAnzeQTgV/5Df3DPwhPijb6bx/PEaeoue6Kj1qXpmQ3Z pFLQA2+n0eKOinRMjC0eRBNCadgSXz+ywMQcxghk= From: Scott Kitterman To: marf@ietf.org Date: Mon, 11 Jul 2011 18:50:40 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic-pae; KDE/4.6.2; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107111850.40470.sklist@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: [marf] Fwd: I-D Action: draft-ietf-marf-spf-reporting-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: Mon, 11 Jul 2011 22:50:42 -0000 I believe that I've at least taken a stab at resolving all the comments I got on -00 in this draft. I did accidentally introduce a typo in Murray's name in -01, I've already fixed that locally for the next version. Please let me know if you have additional suggestions. Scott K ---------- Forwarded Message ---------- Subject: [marf] I-D Action: draft-ietf-marf-spf-reporting-01.txt Date: Monday, July 11, 2011, 06:45:20 PM From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: marf@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Abuse Reporting Format Working Group of the IETF. Title : SPF Authentication Failure Reporting using the Abuse Report Format Author(s) : Scott Kitterman Filename : draft-ietf-marf-spf-reporting-01.txt Pages : 15 Date : 2011-07-11 This memo presents extensions to the Abuse Reporting Format (ARF), and Sender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-spf-reporting-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-spf-reporting-01.txt _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf ----------------------------------------- From vesely@tana.it Tue Jul 12 03:57:23 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 1282C21F90F4 for ; Tue, 12 Jul 2011 03:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.587 X-Spam-Level: X-Spam-Status: No, score=-4.587 tagged_above=-999 required=5 tests=[AWL=-0.468, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEH0sqaRi0xu for ; Tue, 12 Jul 2011 03:57:22 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 48ACE21F90F2 for ; Tue, 12 Jul 2011 03:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1310468236; bh=xrzqiUqRQxym9ZWR36mufvReFB/yCgl4Bnyto73F3Yw=; l=3246; h=Message-ID:Date:From:Mime-Version:To:References:In-Reply-To; b=U8YDoYkH40lhBFXcpUP4BHcgATmfDCL1Tdiz8Rn7Xlc6zvK+8oQAIihYBOz3MU2Ix yL4bJhUOkSg9J17VG5dsCDcbwjm3szGY3zClsQS37PORa1S97ZfkdTHN7pYT3eNGiH Dn6lTQOc2azhLIsF0siHUI4cE9WKQ9ny4aNBxEso= 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, 12 Jul 2011 12:57:16 +0200 id 00000000005DC033.000000004E1C288C.00003A8C Message-ID: <4E1C288C.70207@tana.it> Date: Tue, 12 Jul 2011 12:57:16 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_north-14988-1310468236-0001-2" To: marf@ietf.org References: <20110711201126.2404.qmail@joyce.lan> In-Reply-To: <20110711201126.2404.qmail@joyce.lan> Subject: Re: [marf] Requested Report Interval: stateless cache-driven exponential decrease 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, 12 Jul 2011 10:57:23 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_north-14988-1310468236-0001-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On 11/Jul/11 22:11, John Levine wrote: >>> On diagnosing a failure, the agent generates a random number R in the >>> interval [0, 1] (or sets R=0.5). It then computes a value P using numeric >>> values from the retrieved RR and a formula to be specified in >>> authfailure-report. If P >= R, then the agent generates and sends the >>> report, otherwise does nothing. > > Standards only work when it is mutually beneficial to both parties to > implement them. What is the benefit to the reporting party of > implementing this complex mess? Complex mess?!? It can be done by a 40-line C function that I attach untested. The benefit is the simplicity of being stateless while still not requiring to report each and every failure. The alternative needs a semaphore to synchronize access to global store. Then, what kind of global store? Plain files like /tmp/reports-example.com? MySQL? BerkeleyDB? Note that a similarly structured storage may already exist, e.g. maintained by the local identity assessor, but sharing it with the verifier would add even more complexity. > If there's any rate limiting at all, keep it to something easy to > implement, like a maximum number of reports per hour. Yes, such limit makes much sense, either as a global maximum or as a per-domain one. Shouldn't it be set by the reporter, though? In such case it could be enforced /after/ any self-imposed "complex mess" limit, e.g. on sending, where access to locally maintained databases might be easier. --=_north-14988-1310468236-0001-2 Content-Type: text/plain; name="self-limit.c"; charset=iso-8859-1 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="self-limit.c" I2luY2x1ZGUgPHN0ZGxpYi5oPg0KI2luY2x1ZGUgPG1hdGguaD4NCg0KaW50IHNlbGZfbGlt aXQoY2hhciAqcmksIHVuc2lnbmVkIGxvbmcgdHRsKQ0KLyoNCmFzc3VtZSByaSBwb2ludHMg dG8gdGhlIHZhbHVlIG9mIHRoZSByaT0gcGFyYW1ldGVyLCBpZiBhbnksIGFuZA0KdGhhdCB0 aGUgcGFyYW1ldGVyIHNob3VsZCBiZSBmb3JtYXR0ZWQgbGlrZSAiODY0MDBwMnMxMDBkIiBp biBhbnkNCm9yZGVyIChwLCBzLCBkIHN0YW5kIGZvciBmb3IgUGVyaW9kLCBTbG9wZSBvciBT aGFycG5lc3MsIERpdmlzb3IpDQoqLw0Kew0KCXVuc2lnbmVkIGxvbmcgcCA9IDAsIHMgPSAw LCBkID0gMDsNCglkb3VibGUgZiA9IDEuMDsNCg0KCXdoaWxlIChyaSAmJiAqcmkpDQoJew0K CQljaGFyICp0Ow0KCQl1bnNpZ25lZCBsb25nIGwgPSBzdHJ0b3VsKHJpLCAmdCwgMTApOw0K CQlzd2l0Y2ggKCp0KQ0KCQl7DQoJCQljYXNlICdkJzogZCA9IGw7IGJyZWFrOw0KCQkJY2Fz ZSAncCc6IHAgPSBsOyBicmVhazsNCgkJCWNhc2UgJ3MnOiBzID0gbDsgYnJlYWs7DQoJCQlk ZWZhdWx0Og0KCQkJCXJldHVybiAwOyAvLyBpbnZhbGlkIHJpLCBkb24ndCBzZW5kDQoJCX0N CgkJcmkgPSB0ICsgMTsNCgl9DQoNCglpZiAocyAmJiBwICYmIHR0bCkgIC8vIEdhdXNzaWFu IGN1dG9mZg0KCXsNCgkJZG91YmxlIHggPSAoZG91YmxlKXMgKiAoMS4wIC0gKGRvdWJsZSl0 dGwvKGRvdWJsZSlwKTsNCgkJaWYgKGZhYnMoeCkgPj0gMS4wKQ0KCQkJcmV0dXJuIDA7IC8v IGRvbid0IHNlbmQNCg0KCQlmID0gTV9FICogZXhwKC0xLjAvKDEuMCAtIHgqeCkpOw0KCX0N Cg0KCWlmIChkKSAvLyBsaW5lYXIgY3V0b2ZmDQoJCWYgLz0gKGRvdWJsZSlkOw0KDQoJcmV0 dXJuIGYgKiAoZG91YmxlKVJBTkRfTUFYIDw9IHJhbmQoKTsNCn0NCg== --=_north-14988-1310468236-0001-2-- From johnl@iecc.com Tue Jul 12 06:50: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 9995121F9126 for ; Tue, 12 Jul 2011 06:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.164 X-Spam-Level: X-Spam-Status: No, score=-110.164 tagged_above=-999 required=5 tests=[AWL=1.035, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWMaE7rDxoMq for ; Tue, 12 Jul 2011 06:50:27 -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 D22C121F8514 for ; Tue, 12 Jul 2011 06:50:26 -0700 (PDT) Received: (qmail 35229 invoked from network); 12 Jul 2011 13:50:24 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 12 Jul 2011 13:50:24 -0000 Received: (qmail 33811 invoked from network); 12 Jul 2011 13:50:24 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 12 Jul 2011 13:50:24 -0000 Date: 12 Jul 2011 13:50:02 -0000 Message-ID: <20110712135002.60532.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <4E1C288C.70207@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] Requested Report Interval: stateless cache-driven exponential decrease 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, 12 Jul 2011 13:50:28 -0000 >Complex mess?!? It can be done by a 40-line C function that I attach >untested. The benefit is the simplicity of being stateless while >still not requiring to report each and every failure. > >The alternative needs a semaphore to synchronize access to global >store. Then, what kind of global store? Plain files like >/tmp/reports-example.com? MySQL? ... Assuming you remember what reports you've sent, which I can assure you is a good idea, rate limiting requires one line of SQL. >Yes, such limit makes much sense, either as a global maximum or as a >per-domain one. Shouldn't it be set by the reporter, though? Well, I rate limit my reports, but I thought the topic under discussion was a way for report recipients to say how many reports they want. R's, John From vesely@tana.it Tue Jul 12 08:32: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 6C61121F8E52 for ; Tue, 12 Jul 2011 08:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.858 X-Spam-Level: X-Spam-Status: No, score=-4.858 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWDRnB0sF4Fq for ; Tue, 12 Jul 2011 08:32:04 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id DA0D721F8E3A for ; Tue, 12 Jul 2011 08:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1310484722; bh=VNZdpqrvkLgOx4tKLlMAYUxqM232yMH41vqcD8s94fo=; l=968; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ROhupfpEBeK+qE2Ls8r6BHJr9YX2im1uqgPnxWm/S9poEvcrtYX/kSOo/2f/Lw/ev DK1nIa7BvR1O06KbUgZBlAqsN9+sgQNSPLPEaXiKaUEGg19gkacDHUXZLWbP+KONe9 W3ZvvWSEL9dp81h2sT7inqGZPyAfAXDGbUXrwwpU= 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, 12 Jul 2011 17:32:02 +0200 id 00000000005DC04A.000000004E1C68F2.00003B52 Message-ID: <4E1C68F2.3000204@tana.it> Date: Tue, 12 Jul 2011 17:32:02 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: marf@ietf.org References: <20110712135002.60532.qmail@joyce.lan> In-Reply-To: <20110712135002.60532.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Requested Report Interval: stateless cache-driven exponential decrease 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, 12 Jul 2011 15:32:05 -0000 On 12/Jul/11 15:50, John Levine wrote: > Assuming you remember what reports you've sent, which I can assure you > is a good idea, rate limiting requires one line of SQL. I agree smart logging is a good idea, but having, say, OpenDBX and a supported database as extra-requirements for a compliant reporter possibly is not so good. >> Yes, such limit makes much sense, either as a global maximum or as a >> per-domain one. Shouldn't it be set by the reporter, though? > > Well, I rate limit my reports, but I thought the topic under discussion > was a way for report recipients to say how many reports they want. Correct. The drafts don't even say whether reporters MAY or SHOULD send reports. IMHO, suggesting best ways to limit them could be covered, in particular for reporters wishing to limit globally rather than per domain. BTW, I like that Scott removed the need for an out-of-band agreement before starting to send spf-failure reports. From msk@cloudmark.com Sun Jul 24 15:53: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 B57BD21F86E6 for ; Sun, 24 Jul 2011 15:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.805 X-Spam-Level: X-Spam-Status: No, score=-103.805 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yAFrzgFOZ2S for ; Sun, 24 Jul 2011 15:53:25 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0F19A21F86DD for ; Sun, 24 Jul 2011 15:53:25 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sun, 24 Jul 2011 15:53:24 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Sun, 24 Jul 2011 15:53:21 -0700 Thread-Topic: Feedback on: ARF feedback type Virus/_report subdomain Thread-Index: AcxKAGaSp5eMiea2SrCRR5cwc+xCOQAUoTww Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 22:53:25 -0000 Barry and I received the following feedback about the ARF base document fro= m someone who does not wish to join the mailing list and does not wish to p= articipate in the working group directly. We've agreed to forward these co= mments to the working group for its consideration, but also agree that one = person's concerns (especially when that person doesn't want to do the work = of advancing them through the working group) are not sufficient to spin up = an update effort. So, if the working group wants to do something with some or all of this mat= erial, great, we can talk about starting that effort. If not, then that's = fine too. Some of this stuff also applies to a couple of our open documents, so the v= arious authors (JD mostly, I think) could consider them there. As far as the base stuff goes, some of this stuff looks reasonable, but non= e of it looks critical to me. Thus, if there's no critical mass to create= an RFC5965bis effort, they could just be logged as errata or something lik= e that so they fall in the "deal with this someday" bucket. I am just working through the most recent version to update our filters to= =20 use the latest proposal, and am in the process of also converting our virus= =20 reporting to the ARF. In that process I found a number of concerns with ARF= =20 and aborted that conversion: 1) I consider it extremely rude and dangerous to transmit malware across th= e=20 Internet even in the form of an ARF, apart from the fact that virus filters= =20 at the ISP level and/or the recipient's level may well catch the malware,=20 create a report of that malware (thus creating a loop), and at the same tim= e=20 firewall the offending IP (our mail server). Hence the proposal to return t= he=20 complete message in case of reporting a virus is a very bad idea. Instead,= =20 only the header of the offending message should be returned. The proposal should therefore prohibit the return of the full message in ca= se=20 of feedback type virus and instead require the return of the mail header=20 only. This also requires to change the content type of the last ARF section from= =20 message/RFC822 to text/RFC822-Headers (or whatever else is deemed suitable)= . 2) Because with just returning the header the recipient is no longer able t= o=20 determine which malware was being sent, an according reporting field is=20 needed in the ARF. I'd propose to use: Reported-Description:=20 or Reported-Malware:=20 the first of which can be used not only for virus reporting, but should be= =20 required for feedback type virus and should contain the full name of the=20 virus as reported by the virus scanner. 3) Because the virus names vary from each virus scanner tool, we also need = to=20 identify the virus scanner reporting the malware. The name of the virus=20 scanner should therefore be included as: Reporting-Utility:=20 Required for feedback type virus, optional for other feedback types. 4) The Source IP address should be mandatory for feedback type virus. 5) I'd phase out the feedback type virus in favour of feedback type malware= =20 (which is the same, just broadening the use to include worms, downloaders,= =20 .. which are not virus type), alternatively introduce malware as equivalent= =20 to virus (keeping both feedback types permanently alive). I feed virus woul= d=20 be too limiting for that type of reporting (virus by definition is self re- producing, while worms, downloaders etc. are not self re-producing and=20 therefore by definition are not virusses). That concludes my virus/malware-related comment to your excellent tool. A suggestion may be whether the keyword virus should not be phased out in=20 favour of the word malware to open the abuse report for more generic purpos= e=20 (although virus generally is now being understood like malware anyway). Another comment regarding the _report.domain DNS TXT entry ... In principle that seems to be a reasonable idea, however, there's a duplica= te=20 created that way. Right now abuse addresses are mandatory for the IP addres= s=20 entries in ARIN, RIPE, ... The problem there, the databases are not really= =20 consistent, but consistent enough that parsing of the entries for abuse=20 addresses is possible indeed. =20 I'd rather leave the (legally binding, because that is part of the contract= =20 between ARIN/RIPE/... for IP address assignment) abuse reporting facility=20 with the IP assigning entities and create a standard there in either their = =20 databases (whois) or via a global abuse address server under control of one= =20 entity (ARIN or whoever, supplied and updated only by ARIN and IP assigning= =20 authorities delegated by ARIN) with the entry of the source IP address and= =20 return of the abuse mail address (could be name server, http, whois, ...) There is actually a huge problem with the _report.domain ... The name serve= r=20 may not be under control of the ISP, subdomains may well be added by the=20 client. Hence a malicious client could redirect the abuse reporting to his= =20 own mail address that way and as such completely disable abuse reporting. Hence I consider the proposal for _report.domain TXT field to publish the=20 abuse mail address as serious risk and detrimental to the purpose of ARF. I'd therefore recommend to drop that proposal in favour of what I lined out= =20 above, most likely and easiest by creating consistency across the whois=20 databases (introduce a specific abuse report field there, which is currentl= y=20 missing and abuse e-mail addresses are only published in the comment=20 fields!). To give you an idea: our spam- and virus reporting utilities fetch the abus= e=20 address of the ISP via whois indeed and do all the necessary parsing of the= =20 whois entries via the source IP address. From tony@att.com Sun Jul 24 20:20: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 308B95E8002 for ; Sun, 24 Jul 2011 20:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.28 X-Spam-Level: X-Spam-Status: No, score=-105.28 tagged_above=-999 required=5 tests=[AWL=1.319, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8EJMl44pfGJ for ; Sun, 24 Jul 2011 20:20:37 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 15ED95E8001 for ; Sun, 24 Jul 2011 20:20:36 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-12.tower-119.messagelabs.com!1311564036!30650069!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 12384 invoked from network); 25 Jul 2011 03:20:36 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-12.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 25 Jul 2011 03:20:36 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p6P3L1XW023922 for ; Sun, 24 Jul 2011 23:21:01 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p6P3Kt5P023880 for ; Sun, 24 Jul 2011 23:20:55 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p6P3KS9S001109 for ; Sun, 24 Jul 2011 23:20:29 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p6P3KN8j001018 for ; Sun, 24 Jul 2011 23:20:24 -0400 Received: from [135.70.163.115] (vpn-135-70-163-115.vpn.mwst.att.com[135.70.163.115]) by maillennium.att.com (mailgw1) with ESMTP id <20110725032022gw100e4l36e> (Authid: tony); Mon, 25 Jul 2011 03:20:23 +0000 X-Originating-IP: [135.70.163.115] Message-ID: <4E2CE0F4.5000204@att.com> Date: Sun, 24 Jul 2011 23:20:20 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Message Abuse Report Format working group References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 03:20:38 -0000 I definitely understand the concerns of passing around the malware via email. If we feel that they *must* be sent, we *could* encrypt the attachment (pick your poison, such as AES), and include the password in another header. Just thinking out loud, Tony Hansen On 7/24/2011 6:53 PM, Murray S. Kucherawy wrote: > > Barry and I received the following feedback about the ARF base document from someone who does not wish to join the mailing list and does not wish to participate in the working group directly. We've agreed to forward these comments to the working group for its consideration, but also agree that one person's concerns (especially when that person doesn't want to do the work of advancing them through the working group) are not sufficient to spin up an update effort. > > So, if the working group wants to do something with some or all of this material, great, we can talk about starting that effort. If not, then that's fine too. > > Some of this stuff also applies to a couple of our open documents, so the various authors (JD mostly, I think) could consider them there. > > > > As far as the base stuff goes, some of this stuff looks reasonable, but none of it looks critical to me. Thus, if there's no critical mass to create an RFC5965bis effort, they could just be logged as errata or something like that so they fall in the "deal with this someday" bucket. > > > > I am just working through the most recent version to update our filters to > use the latest proposal, and am in the process of also converting our virus > reporting to the ARF. In that process I found a number of concerns with ARF > and aborted that conversion: > > 1) I consider it extremely rude and dangerous to transmit malware across the > Internet even in the form of an ARF, apart from the fact that virus filters > at the ISP level and/or the recipient's level may well catch the malware, > create a report of that malware (thus creating a loop), and at the same time > firewall the offending IP (our mail server). Hence the proposal to return the > complete message in case of reporting a virus is a very bad idea. Instead, > only the header of the offending message should be returned. > > The proposal should therefore prohibit the return of the full message in case > of feedback type virus and instead require the return of the mail header > only. > > This also requires to change the content type of the last ARF section from > message/RFC822 to text/RFC822-Headers (or whatever else is deemed suitable). > > 2) Because with just returning the header the recipient is no longer able to > determine which malware was being sent, an according reporting field is > needed in the ARF. I'd propose to use: > > Reported-Description: > > or > > Reported-Malware: > > the first of which can be used not only for virus reporting, but should be > required for feedback type virus and should contain the full name of the > virus as reported by the virus scanner. > > 3) Because the virus names vary from each virus scanner tool, we also need to > identify the virus scanner reporting the malware. The name of the virus > scanner should therefore be included as: > > Reporting-Utility: > > Required for feedback type virus, optional for other feedback types. > > 4) The Source IP address should be mandatory for feedback type virus. > > 5) I'd phase out the feedback type virus in favour of feedback type malware > (which is the same, just broadening the use to include worms, downloaders, > .. which are not virus type), alternatively introduce malware as equivalent > to virus (keeping both feedback types permanently alive). I feed virus would > be too limiting for that type of reporting (virus by definition is self re- > producing, while worms, downloaders etc. are not self re-producing and > therefore by definition are not virusses). > > That concludes my virus/malware-related comment to your excellent tool. > > A suggestion may be whether the keyword virus should not be phased out in > favour of the word malware to open the abuse report for more generic purpose > (although virus generally is now being understood like malware anyway). > > Another comment regarding the _report.domain DNS TXT entry ... > > In principle that seems to be a reasonable idea, however, there's a duplicate > created that way. Right now abuse addresses are mandatory for the IP address > entries in ARIN, RIPE, ... The problem there, the databases are not really > consistent, but consistent enough that parsing of the entries for abuse > addresses is possible indeed. > > I'd rather leave the (legally binding, because that is part of the contract > between ARIN/RIPE/... for IP address assignment) abuse reporting facility > with the IP assigning entities and create a standard there in either their > databases (whois) or via a global abuse address server under control of one > entity (ARIN or whoever, supplied and updated only by ARIN and IP assigning > authorities delegated by ARIN) with the entry of the source IP address and > return of the abuse mail address (could be name server, http, whois, ...) > > There is actually a huge problem with the _report.domain ... The name server > may not be under control of the ISP, subdomains may well be added by the > client. Hence a malicious client could redirect the abuse reporting to his > own mail address that way and as such completely disable abuse reporting. > > Hence I consider the proposal for _report.domain TXT field to publish the > abuse mail address as serious risk and detrimental to the purpose of ARF. > > I'd therefore recommend to drop that proposal in favour of what I lined out > above, most likely and easiest by creating consistency across the whois > databases (introduce a specific abuse report field there, which is currently > missing and abuse e-mail addresses are only published in the comment > fields!). > > To give you an idea: our spam- and virus reporting utilities fetch the abuse > address of the ISP via whois indeed and do all the necessary parsing of the > whois entries via the source IP address. > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf From msk@cloudmark.com Sun Jul 24 20:28:12 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 B190421F8559 for ; Sun, 24 Jul 2011 20:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.803 X-Spam-Level: X-Spam-Status: No, score=-103.803 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZLLtZCQH3qH for ; Sun, 24 Jul 2011 20:28:12 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 51AB721F8557 for ; Sun, 24 Jul 2011 20:28:12 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sun, 24 Jul 2011 20:28:11 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Sun, 24 Jul 2011 20:28:10 -0700 Thread-Topic: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain Thread-Index: AcxKededszmn3DtvRIydtLgWdlTnpgAAMynw Message-ID: References: <4E2CE0F4.5000204@att.com> In-Reply-To: <4E2CE0F4.5000204@att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 03:28:12 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of T= ony Hansen > Sent: Sunday, July 24, 2011 8:20 PM > To: Message Abuse Report Format working group > Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report > subdomain >=20 > I definitely understand the concerns of passing around the malware via > email. If we feel that they *must* be sent, we *could* encrypt the > attachment (pick your poison, such as AES), and include the password in > another header. I'm less concerned about it. An FBL is typically addressed to a person or = a piece of software specifically equipped to handle abusive email, usually = by prior arrangement. It's not like the FBL mail containing a piece of mal= ware is being sent scattershot at people that aren't prepared to receive it= . From johnl@iecc.com Sun Jul 24 21:11: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 383C121F853A for ; Sun, 24 Jul 2011 21:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.9 X-Spam-Level: X-Spam-Status: No, score=-106.9 tagged_above=-999 required=5 tests=[AWL=4.300, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISYdapu+rTGo for ; Sun, 24 Jul 2011 21:11: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 953F321F852C for ; Sun, 24 Jul 2011 21:11:22 -0700 (PDT) Received: (qmail 72963 invoked from network); 25 Jul 2011 04:11:21 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 25 Jul 2011 04:11:21 -0000 Received: (qmail 1573 invoked from network); 25 Jul 2011 04:11:21 -0000 Received: from pedro.iecc.com (66.152.118.17) by mail1.iecc.com with QMQP; 25 Jul 2011 04:11:21 -0000 Date: 25 Jul 2011 04:10:32 -0000 Message-ID: <20110725041032.26076.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] FW: Feedback on: ARF feedback type Virus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 04:11:34 -0000 >I'm less concerned about it. An FBL is typically addressed to a >person or a piece of software specifically equipped to handle abusive >email, usually by prior arrangement. That's pretty much what I was going to say. If you're not prepared for people to send back whatever crud you send out, you have a pretty poor excuse for a feedback loop. Also, I can tell you from experience that I've been sending lightly denatured virus reports (the first few bytes of the base64 changed to xxx so it's not executable), and I've never gotten into a loop or anything else particularly bad. The worst that happened was that a rather dim BL operator insisted that I was sending viruses because their virus detectors said so. R's, John From steve@wordtothewise.com Sun Jul 24 21:28:02 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0178311E8080 for ; Sun, 24 Jul 2011 21:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htx4KRB0mj5f for ; Sun, 24 Jul 2011 21:28:01 -0700 (PDT) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 8D60111E807C for ; Sun, 24 Jul 2011 21:28:01 -0700 (PDT) Received: from [192.168.80.43] (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 2771D2DEC3 for ; Sun, 24 Jul 2011 21:28:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Steve Atkins In-Reply-To: Date: Sun, 24 Jul 2011 21:28:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <619379F2-E7FC-4D17-9624-B571CE234A4A@wordtothewise.com> References: <4E2CE0F4.5000204@att.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 04:28:02 -0000 On Jul 24, 2011, at 8:28 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of Tony Hansen >> Sent: Sunday, July 24, 2011 8:20 PM >> To: Message Abuse Report Format working group >> Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report >> subdomain >>=20 >> I definitely understand the concerns of passing around the malware = via >> email. If we feel that they *must* be sent, we *could* encrypt the >> attachment (pick your poison, such as AES), and include the password = in >> another header. >=20 > > I'm less concerned about it. An FBL is typically addressed to a = person or a piece of software specifically equipped to handle abusive = email, usually by prior arrangement. It's not like the FBL mail = containing a piece of malware is being sent scattershot at people that = aren't prepared to receive it. > =46rom experience, many FBL handlers are behind the primary corporate = MX. Often configured to avoid filters. Sometimes not. Sometimes = configured to do so until the MX (which is not under control of the = people operating the FBL eater) is upgraded or outsourced. If FBL messages contain hostile content they're fairly likely to be = silently dropped or quarantined at a small fraction of recipients today. = That fraction would probably increase if more organizations than the = current selection (ESPs and some ISPs) start to take advantage of them - = which is something I'd really like to happen in the case of FBLs based = on detection of malware emission. Cheers, Steve From alex@bobotek.net Sun Jul 24 23:13: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 C90B421F8AE1 for ; Sun, 24 Jul 2011 23:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rp0nwaPqkNZw for ; Sun, 24 Jul 2011 23:13:36 -0700 (PDT) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by ietfa.amsl.com (Postfix) with ESMTP id 3362B21F8A64 for ; Sun, 24 Jul 2011 23:13:35 -0700 (PDT) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta09.emeryville.ca.mail.comcast.net with comcast id C68b1h0011bwxycA96DYgV; Mon, 25 Jul 2011 06:13:32 +0000 Received: from bobo1.bobotek.net ([71.231.189.124]) by omta18.emeryville.ca.mail.comcast.net with comcast id C6D71h00F2hUyyF8e6D8UU; Mon, 25 Jul 2011 06:13:10 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Jul 2011 23:13:47 -0700 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <619379F2-E7FC-4D17-9624-B571CE234A4A@wordtothewise.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [marf] FW: Feedback on: ARF feedback typeVirus/_report subdomain Thread-Index: AcxKgz4aRnikDkZxSnaYTdRiedVzHgACjG7w References: <4E2CE0F4.5000204@att.com> <619379F2-E7FC-4D17-9624-B571CE234A4A@wordtothewise.com> From: "Alex Bobotek" To: "Steve Atkins" , "Message Abuse Report Format working group" Subject: Re: [marf] FW: Feedback on: ARF feedback typeVirus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 06:13:36 -0000 The use of in-band reporting mechanisms (e.g., message/rfc822 atop an SMTP relay chain), for all their benefits, have some complications. The complexity may increase with gateways and longer SMTP relay chains. =20 MTAs (and gateways) might need to allow uninhibited passage of malign embedded spam or virus reports (e.g., based on MIME type, destination address, or some other mechanism). =20 MUAs might need to recognize that a message/rfc822 embedded inside a feedback report may be unsafe for execution/storage. =20 Tony's suggested method, encryption with a declared key, strikes me as a better mechanism than simply requiring special handling of designated MIME types. An ignorant MUA would be unable to execute malware, and an ignorant MTA would pass reported messages freely. =20 IMHO we should shoot for a more extensible/future-proof reporting mechanism; one that would be more likely to work beyond an ISP1-->ISP2 over SMTP reporting scenario. The trend is towards more gateways and increasing delivery path complexity in general. Regards, Alex =20 -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Steve Atkins Sent: Sunday, July 24, 2011 9:28 PM To: Message Abuse Report Format working group Subject: Re: [marf] FW: Feedback on: ARF feedback typeVirus/_report subdomain On Jul 24, 2011, at 8:28 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Tony Hansen >> Sent: Sunday, July 24, 2011 8:20 PM >> To: Message Abuse Report Format working group >> Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report >> subdomain >>=20 >> I definitely understand the concerns of passing around the malware via >> email. If we feel that they *must* be sent, we *could* encrypt the >> attachment (pick your poison, such as AES), and include the password in >> another header. >=20 > > I'm less concerned about it. An FBL is typically addressed to a person or a piece of software specifically equipped to handle abusive email, usually by prior arrangement. It's not like the FBL mail containing a piece of malware is being sent scattershot at people that aren't prepared to receive it. > >From experience, many FBL handlers are behind the primary corporate MX. Often configured to avoid filters. Sometimes not. Sometimes configured to do so until the MX (which is not under control of the people operating the FBL eater) is upgraded or outsourced. If FBL messages contain hostile content they're fairly likely to be silently dropped or quarantined at a small fraction of recipients today. That fraction would probably increase if more organizations than the current selection (ESPs and some ISPs) start to take advantage of them - which is something I'd really like to happen in the case of FBLs based on detection of malware emission. Cheers, Steve _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From jacqui.caren@ntlworld.com Sun Jul 24 23:23: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 40D6621F8AF4 for ; Sun, 24 Jul 2011 23:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jwyhup6iluFK for ; Sun, 24 Jul 2011 23:23:47 -0700 (PDT) Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by ietfa.amsl.com (Postfix) with ESMTP id C4A6421F8AEA for ; Sun, 24 Jul 2011 23:23:38 -0700 (PDT) Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110725062332.INCZ5301.mtaout03-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com> for ; Mon, 25 Jul 2011 07:23:32 +0100 Received: from [10.0.0.253] (really [86.19.61.126]) by aamtaout03-winn.ispmail.ntl.com (InterMail vG.3.00.04.00 201-2196-133-20080908) with ESMTP id <20110725062332.LEDY24017.aamtaout03-winn.ispmail.ntl.com@[10.0.0.253]> for ; Mon, 25 Jul 2011 07:23:32 +0100 Message-ID: <4E2D0C51.2000309@ntlworld.com> Date: Mon, 25 Jul 2011 07:25:21 +0100 From: Jacqui Caren-home Organization: Home User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: marf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=JvdXmxIgLJv2/GthKqHpGJEEHukvLcvELVXUanXFreg= c=1 sm=0 a=kO1UQE3gKUQA:10 a=qtFFXmhsIkwA:10 a=uObrxnre4hsA:10 a=9YlaCzn6_68A:10 a=8nJEP1OIZ-IA:10 a=sMBj6sIwAAAA:8 a=ST45-1Dj3Skgsa5lrfkA:9 a=p89E26Kzd8qYU8gQ3mwA:7 a=wPNLvfGTeEIA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jacqui.caren@ntlworld.com List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 06:23:48 -0000 On 24/07/2011 23:53, Murray S. Kucherawy wrote: > > Barry and I received the following feedback about the ARF base document from someone who does not wish to join the mailing list and does not wish to participate in the working group directly. We've agreed to forward these comments to the working group for its consideration, but also agree that one person's concerns (especially when that person doesn't want to do the work of advancing them through the working group) are not sufficient to spin up an update effort. > > So, if the working group wants to do something with some or all of this material, great, we can talk about starting that effort. If not, then that's fine too. > > Some of this stuff also applies to a couple of our open documents, so the various authors (JD mostly, I think) could consider them there. > > > > As far as the base stuff goes, some of this stuff looks reasonable, but none of it looks critical to me. Thus, if there's no critical mass to create an RFC5965bis effort, they could just be logged as errata or something like that so they fall in the "deal with this someday" bucket. > > > > I am just working through the most recent version to update our filters to > use the latest proposal, and am in the process of also converting our virus > reporting to the ARF. In that process I found a number of concerns with ARF > and aborted that conversion: > > 1) I consider it extremely rude and dangerous to transmit malware across the > Internet even in the form of an ARF, apart from the fact that virus filters > at the ISP level and/or the recipient's level may well catch the malware, > create a report of that malware (thus creating a loop), and at the same time > firewall the offending IP (our mail server). Hence the proposal to return the > complete message in case of reporting a virus is a very bad idea. Instead, > only the header of the offending message should be returned. > > The proposal should therefore prohibit the return of the full message in case > of feedback type virus and instead require the return of the mail header > only. > > This also requires to change the content type of the last ARF section from > message/RFC822 to text/RFC822-Headers (or whatever else is deemed suitable). > > 2) Because with just returning the header the recipient is no longer able to > determine which malware was being sent, an according reporting field is > needed in the ARF. I'd propose to use: > > Reported-Description: > > or > > Reported-Malware: > the first of which can be used not only for virus reporting, but should be > required for feedback type virus and should contain the full name of the > virus as reported by the virus scanner. IMHO This is too simplistic... The above makes sense for vendor names such as Foobarv1.2 but I would add an optional Reported-CVE-Id: 2010 0042 with the CVE numbers for any known infections seperated by comma's. This should be in format as used by http://cve.mitre.org/ Jacqui From msk@cloudmark.com Mon Jul 25 03:01: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 3604D21F8562 for ; Mon, 25 Jul 2011 03:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.8 X-Spam-Level: X-Spam-Status: No, score=-103.8 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvSTkFypeVnG for ; Mon, 25 Jul 2011 03:01:41 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2CF21F84F7 for ; Mon, 25 Jul 2011 03:01:41 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 25 Jul 2011 03:01:41 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Mon, 25 Jul 2011 03:01:39 -0700 Thread-Topic: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain Thread-Index: AcxKgz8he4m3Ew1+QyW1zMG8nRsx9wALlB4Q Message-ID: References: <4E2CE0F4.5000204@att.com> <619379F2-E7FC-4D17-9624-B571CE234A4A@wordtothewise.com> In-Reply-To: <619379F2-E7FC-4D17-9624-B571CE234A4A@wordtothewise.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 10:01:42 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= teve Atkins > Sent: Sunday, July 24, 2011 9:28 PM > To: Message Abuse Report Format working group > Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subd= omain >=20 > From experience, many FBL handlers are behind the primary corporate MX. > Often configured to avoid filters. Sometimes not. Sometimes configured > to do so until the MX (which is not under control of the people > operating the FBL eater) is upgraded or outsourced. >=20 > If FBL messages contain hostile content they're fairly likely to be > silently dropped or quarantined at a small fraction of recipients > today. That fraction would probably increase if more organizations than > the current selection (ESPs and some ISPs) start to take advantage of > them - which is something I'd really like to happen in the case of FBLs > based on detection of malware emission. Does that mean you feel this justifies a change to the base draft? From steve@wordtothewise.com Mon Jul 25 09:14: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 B784F11E827C for ; Mon, 25 Jul 2011 09:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9Jnwlkklo4i for ; Mon, 25 Jul 2011 09:14:16 -0700 (PDT) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 71E3F21F8DF2 for ; Mon, 25 Jul 2011 08:18:25 -0700 (PDT) Received: from [192.168.80.43] (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 A363D2DEC9 for ; Mon, 25 Jul 2011 08:18:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Steve Atkins In-Reply-To: Date: Mon, 25 Jul 2011 08:18:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5394F540-D9D5-4DA7-AFFE-7F69F264643A@wordtothewise.com> References: <4E2CE0F4.5000204@att.com> <619379F2-E7FC-4D17-9624-B571CE234A4A@wordtothewise.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:14:17 -0000 On Jul 25, 2011, at 3:01 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of Steve Atkins >> Sent: Sunday, July 24, 2011 9:28 PM >> To: Message Abuse Report Format working group >> Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report = subdomain >>=20 >> =46rom experience, many FBL handlers are behind the primary corporate = MX. >> Often configured to avoid filters. Sometimes not. Sometimes = configured >> to do so until the MX (which is not under control of the people >> operating the FBL eater) is upgraded or outsourced. >>=20 >> If FBL messages contain hostile content they're fairly likely to be >> silently dropped or quarantined at a small fraction of recipients >> today. That fraction would probably increase if more organizations = than >> the current selection (ESPs and some ISPs) start to take advantage of >> them - which is something I'd really like to happen in the case of = FBLs >> based on detection of malware emission. >=20 > Does that mean you feel this justifies a change to the base draft? I don't think so, no, definitely not if doing so would increase = implementation complexity further.=20 But it's something to be aware of if ARF is pushed beyond it's original scope of reporting "My user thinks this is spam" to things it's less well suited for (where the obvious payload of the = report is not really a message/rfc822 attachment). Cheers, Steve From shmuel+gen@patriot.net Mon Jul 25 16:12: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 CA32621F86DE for ; Mon, 25 Jul 2011 16:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.415 X-Spam-Level: X-Spam-Status: No, score=-1.415 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuqM0BQ5VTul for ; Mon, 25 Jul 2011 16:12:41 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3B88721F85A1 for ; Mon, 25 Jul 2011 16:12:38 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.2]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id BF401F5808A for ; Mon, 25 Jul 2011 19:03:34 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Mon, 25 Jul 2011 08:43:43 -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: <20110725230334.BF401F5808A@smtp.patriot.net> Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 23:12:41 -0000 In , on 07/24/2011 at 03:53 PM, "Murray S. Kucherawy" said: >1) I consider it extremely rude and dangerous to transmit malware >across the Internet even in the form of an ARF, I consider it extremely rude to send an abuse report without supporting documentation. I wouldn't expect an ISP to act on a virus complaint that didn't document the alleged virus. -- 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 steve@wordtothewise.com Mon Jul 25 16:26:26 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 E99FA11E80E5 for ; Mon, 25 Jul 2011 16:26:26 -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=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vkYgCGhWG7a for ; Mon, 25 Jul 2011 16:26:26 -0700 (PDT) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 328F511E80E9 for ; Mon, 25 Jul 2011 16:26:26 -0700 (PDT) Received: from [192.168.80.43] (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 249642DEC9 for ; Mon, 25 Jul 2011 16:26:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Steve Atkins In-Reply-To: Date: Mon, 25 Jul 2011 16:26:22 -0700 Content-Transfer-Encoding: 7bit Message-Id: <86839040-9773-45D2-8BD2-2063B2C44447@wordtothewise.com> References: <4E2CE0F4.5000204@att.com> <619379F2-E7FC-4D17-9624-B571CE234A4A@wordtothewise.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] FW: Feedback on: ARF feedback typeVirus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 23:26:27 -0000 On Jul 24, 2011, at 11:13 PM, Alex Bobotek wrote: > The use of in-band reporting mechanisms (e.g., message/rfc822 atop an > SMTP relay chain), for all their benefits, have some complications. The > complexity may increase with gateways and longer SMTP relay chains. > > MTAs (and gateways) might need to allow uninhibited passage of malign > embedded spam or virus reports (e.g., based on MIME type, destination > address, or some other mechanism). > > MUAs might need to recognize that a message/rfc822 embedded inside a > feedback report may be unsafe for execution/storage. > > Tony's suggested method, encryption with a declared key, strikes me as a > better mechanism than simply requiring special handling of designated > MIME types. An ignorant MUA would be unable to execute malware, and an > ignorant MTA would pass reported messages freely. Yup. Something with the power and flexibility of ROT13 might suit that well. > IMHO we should shoot for a more extensible/future-proof reporting > mechanism; one that would be more likely to work beyond an ISP1-->ISP2 > over SMTP reporting scenario. The trend is towards more gateways and > increasing delivery path complexity in general. That's not really what ARF is, though. ARF has had significant uptake mostly because it's very simple, and very well suited to it's original role. I'm not sure whether it'll maintain a useful level of uptake if it's made more complex to use, and aimed at roles it's not well suited to. So I'm not sure whether it's the right place to start when crafting something intended to report all sorts of unrelated things via a variety of channels. ( http://xkcd.com/927/ is probably relevant here). Cheers, Steve From jdfalk-lists@cybernothing.org Tue Jul 26 08:03: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 B546121F8BB1 for ; Tue, 26 Jul 2011 08:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tj2373mR9myw for ; Tue, 26 Jul 2011 08:03:57 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id A80F721F874E for ; Tue, 26 Jul 2011 08:03:57 -0700 (PDT) Received: from [192.168.11.36] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p6QF3peU018777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 26 Jul 2011 08:03:53 -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, 26 Jul 2011 08:03:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5FA835A4-9902-4EB8-A872-32BF7DE0C989@cybernothing.org> References: To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 15:03:58 -0000 On Jul 24, 2011, at 3:53 PM, Murray S. Kucherawy forwarded an anonymous = non-participant's feedback: > 1) I consider it extremely rude and dangerous to transmit malware = across the=20 > Internet even in the form of an ARF, apart from the fact that virus = filters=20 > at the ISP level and/or the recipient's level may well catch the = malware,=20 > create a report of that malware (thus creating a loop), and at the = same time=20 > firewall the offending IP (our mail server). Hence the proposal to = return the=20 > complete message in case of reporting a virus is a very bad idea. = Instead,=20 > only the header of the offending message should be returned. There's some validity to these arguments, but what they're convincing me = of is that the "virus" type should be removed entirely. It's never = really been tested at scale, and we didn't have much input from the = malware reporting/research community. Is anyone aware of any implementations that do anything special with = Feedback-Type: virus? Is anyone aware of serious malware reporting/research institutions using = ARF? > Another comment regarding the _report.domain DNS TXT entry ... >=20 > In principle that seems to be a reasonable idea, however, there's a = duplicate=20 > created that way. Right now abuse addresses are mandatory for the IP = address=20 > entries in ARIN, RIPE, ... The problem there, the databases are not = really=20 > consistent, but consistent enough that parsing of the entries for = abuse=20 > addresses is possible indeed. We talked about this earlier. The published abuse@ address is intended = for communication from humans; it would be rude to assume abuse@ is set = up for ARF. By publishing a separate record, the domain owner is saying = "I know about ARF, and I process ARF at this address." It's a shame that this person is not willing to participate in the = conversation. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From vesely@tana.it Tue Jul 26 11:48:30 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1EC11E807A for ; Tue, 26 Jul 2011 11:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.808 X-Spam-Level: X-Spam-Status: No, score=-4.808 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8zz7bKM3PHW for ; Tue, 26 Jul 2011 11:48:30 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6067B21F8BEA for ; Tue, 26 Jul 2011 11:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1311706106; bh=8KfbqaP+F7CJfwv62fjS7z9K8pMdlTSdu7Two8EYpDM=; l=5042; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=WlGrF1bxjtqaNPOyDVexjRJLImA3dP+Vi8PsZWhRQEqnUdkISWxFhAYJFeYSuMxOy ZMRZr1Z8MC3QnYqrVktZFTLxcMzI0mvoE40i3q4fZqOh/1wv5DTupkdAjvvo/M1v9d MNl/E98gjzhhi/zfb1pfN2ozcdSiUuvOzRPvU4HQ= 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, 26 Jul 2011 20:48:26 +0200 id 00000000005DC039.000000004E2F0BFA.00000486 Message-ID: <4E2F0BFA.1020708@tana.it> Date: Tue, 26 Jul 2011 20:48:26 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: marf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 18:48:30 -0000 On 25/Jul/11 00:53, Murray S. Kucherawy wrote: > 1) I consider it extremely rude and dangerous to transmit malware across the > Internet even in the form of an ARF, apart from the fact that virus filters > at the ISP level and/or the recipient's level may well catch the malware, > create a report of that malware (thus creating a loop), and at the same time > firewall the offending IP (our mail server). Hence the proposal to return the > complete message in case of reporting a virus is a very bad idea. Instead, > only the header of the offending message should be returned. This is already provided for, albeit not recommended. > The proposal should therefore prohibit the return of the full message in case > of feedback type virus and instead require the return of the mail header > only. Err... wouldn't it be safer to prohibit people from sending viruses in the first place? > 2) Because with just returning the header the recipient is no longer able to > determine which malware was being sent, an according reporting field is > needed in the ARF. I'd propose to use: > > Reported-Description: > > or > > Reported-Malware: > > the first of which can be used not only for virus reporting, but should be > required for feedback type virus and should contain the full name of the > virus as reported by the virus scanner. Sounds good. "Reported-Malware" better conveys that the "virus" Feedback-Type is somewhat of a misnomer (see below). > 3) Because the virus names vary from each virus scanner tool, we also need to > identify the virus scanner reporting the malware. The name of the virus > scanner should therefore be included as: > > Reporting-Utility: > > Required for feedback type virus, optional for other feedback types. "Scanner" may better distinguish it from "User-Agent". Is it useful? (It can often be inferred from the virus names it reports.) I'd recommend it be fully optional, anyway, especially its update version :-/ > 5) I'd phase out the feedback type virus in favour of feedback type malware > (which is the same, just broadening the use to include worms, downloaders, > .. which are not virus type), alternatively introduce malware as equivalent > to virus (keeping both feedback types permanently alive). I feed virus would > be too limiting for that type of reporting (virus by definition is self re- > producing, while worms, downloaders etc. are not self re-producing and > therefore by definition are not virusses). Sticking to established albeit wrong names seems to be more orthodox than correcting them (remember the "Referer".) For a partial justification, let me note that worms and other malware are often detected by products commonly called "anti-virus". > Another comment regarding the _report.domain DNS TXT entry ... > > In principle that seems to be a reasonable idea, however, there's a duplicate > created that way. Right now abuse addresses are mandatory for the IP address > entries in ARIN, RIPE, ... The problem there, the databases are not really > consistent, but consistent enough that parsing of the entries for abuse > addresses is possible indeed. ARIN's announcement was posted on Mon, 18 July 2011 https://www.arin.net/announcements/2011/20110718.html RIPE hasn't yet said so, AFAIK. I don't know whether they will recommend ARF, but the fact that they strive to avoid rate-limit for that data suggests that they intend it to be for automated use, the same as _report.domain. So, yes, there seems to be some overlapping here. > I'd rather leave the (legally binding, because that is part of the contract > between ARIN/RIPE/... for IP address assignment) abuse reporting facility > with the IP assigning entities and create a standard there in either their > databases (whois) or via a global abuse address server under control of one > entity (ARIN or whoever, supplied and updated only by ARIN and IP assigning > authorities delegated by ARIN) with the entry of the source IP address and > return of the abuse mail address (could be name server, http, whois, ...) > > There is actually a huge problem with the _report.domain ... The name server > may not be under control of the ISP, subdomains may well be added by the > client. Hence a malicious client could redirect the abuse reporting to his > own mail address that way and as such completely disable abuse reporting. Good point. Ideally, ISPs could set abuse@ISP in the RIR's DB, and then count and redirect complaints to the relevant postmasters. It would be great if they also checked that complaints are actually acted upon. More likely, ISPs will just set POCs as clients tell them to, including /dev/null. Reporters can also compare WHOIS data with _report.domain, and send to whomever they like. IMHO, our docs should * mention RIRs and registrars WHOIS databases, * cover comparison considerations, and * insist that end users should report to their postmasters if at all possible. jm2c From msk@cloudmark.com Wed Jul 27 13:54:47 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FB211E80A9 for ; Wed, 27 Jul 2011 13:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.78 X-Spam-Level: X-Spam-Status: No, score=-103.78 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8EFwt8quKDN for ; Wed, 27 Jul 2011 13:54:46 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 862C711E8082 for ; Wed, 27 Jul 2011 13:54:43 -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, 27 Jul 2011 13:54:43 -0700 From: "Murray S. Kucherawy" To: "MARF@ietf.org" Date: Wed, 27 Jul 2011 13:54:41 -0700 Thread-Topic: Working Group Last Call on draft-ietf-marf-not-spam-feedback Thread-Index: Acw88BYIbETXNv8xQPKkAFiAWLrXoQPrt9hQ 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_F5833273385BB34F99288B3648C4F06F13512DF479EXCHC2corpclo_" MIME-Version: 1.0 Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-not-spam-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: Wed, 27 Jul 2011 20:54:47 -0000 --_000_F5833273385BB34F99288B3648C4F06F13512DF479EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This WGLC ended last week. We got two pieces of feedback only. It would b= e a lot more comfortable to send this to the IESG with more feedback than t= hat, even though it's a pretty simple draft. Can we please have a few more reviewers? I assure you it's pretty short. http://datatracker.ietf.org/doc/draft-ietf-marf-not-spam-feedback/ Thanks, -MSK From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Mur= ray S. Kucherawy Sent: Thursday, July 07, 2011 2:52 PM To: MARF@ietf.org Subject: [marf] Working Group Last Call on draft-ietf-marf-not-spam-feedbac= k There has been little feedback about the above draft since its submission, = and given its fairly trivial nature and fit within our charter of SpamRep c= onvergence, I believe we're ready to move forward. Therefore... This note declares the beginning of a Working Group Last Call on draft-ietf= -marf-not-spam-feedback, ending on July 21st. Please submit any comments y= ou have about this draft prior to that time, after which we will begin the = process of submitting it to the IESG for review and approval. -MSK, as co-chair --_000_F5833273385BB34F99288B3648C4F06F13512DF479EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This WGLC ended last week.  We got two pieces of feedbac= k only.  It would be a lot more comfortable to send this to the IESG w= ith more feedback than that, even though it’s a pretty simple draft.<= o:p>

 

Can we please have a few more reviewers?   I assure you it’= ;s pretty short.

 

http://datatracker.ietf.org/doc/draft-ietf-marf-not-= spam-feedback/

 

Thanks,

-MSK

 

From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.o= rg] On Behalf Of Murray S. Kucherawy
Sent: Thursday, July = 07, 2011 2:52 PM
To: MARF@ietf.org
Subject: [marf] Work= ing Group Last Call on draft-ietf-marf-not-spam-feedback<= /p>

 

There has been little feedback about the above draft since its submissio= n, and given its fairly trivial nature and fit within our charter of SpamRe= p convergence, I believe we’re ready to move forward.  Therefore= …

 

This note declares the beginning of a Working Group Last Call on = draft-ietf-marf-not-spam-feedback, ending on July 21st.  Pl= ease submit any comments you have about this draft prior to that time, afte= r which we will begin the process of submitting it to the IESG for review a= nd approval.

 

-MSK, as co-chair

&n= bsp;

= --_000_F5833273385BB34F99288B3648C4F06F13512DF479EXCHC2corpclo_-- From steve@wordtothewise.com Wed Jul 27 14:14: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 3108921F8ADE for ; Wed, 27 Jul 2011 14:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2mgjjqkWK6o for ; Wed, 27 Jul 2011 14:14:40 -0700 (PDT) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id AD19A21F8AE4 for ; Wed, 27 Jul 2011 14:14:40 -0700 (PDT) Received: from [192.168.80.43] (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 3B1032DDE8 for ; Wed, 27 Jul 2011 14:14:40 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1084) From: Steve Atkins In-Reply-To: Date: Wed, 27 Jul 2011 14:14:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <99558CB4-4726-4500-BE48-608ED44AFE5E@wordtothewise.com> References: To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-not-spam-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: Wed, 27 Jul 2011 21:14:41 -0000 On Jul 27, 2011, at 1:54 PM, Murray S. Kucherawy wrote: > This WGLC ended last week. We got two pieces of feedback only. It = would be a lot more comfortable to send this to the IESG with more = feedback than that, even though it=92s a pretty simple draft. > =20 > Can we please have a few more reviewers? I assure you it=92s pretty = short. The use case is sufficiently far outside a "normal" ARF use case that I = didn't feel I had enough context to usefully comment on it. At the protocol level, it's adding a new ARF tag and making no other = changes to the protocol, so there's really nothing to say (other than = that maybe "not-abuse" would be a more logical name, given we don't have = a "spam" type). Whether it makes any operational sense to have it depends on a whole lot = of missing details (authentication, typical use case, whether it's = likely to be attacked by people claiming that spam is not-spam, who the = recipients are, who the senders are, whether it's used MUA->recipients = ISP or recipients ISP -> outsourced spam filter provider, MUA to = original sender, etc, etc.). Without those details, there's not really = much to say about that end of it. That doesn't mean it's a bad idea at all, I think it's probably a good = one, just that I'm not sure what there is to say about it. Cheers, Steve > =20 > http://datatracker.ietf.org/doc/draft-ietf-marf-not-spam-feedback/ > =20 > Thanks, > -MSK > =20 > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of Murray S. Kucherawy > Sent: Thursday, July 07, 2011 2:52 PM > To: MARF@ietf.org > Subject: [marf] Working Group Last Call on = draft-ietf-marf-not-spam-feedback > =20 > There has been little feedback about the above draft since its = submission, and given its fairly trivial nature and fit within our = charter of SpamRep convergence, I believe we=92re ready to move forward. = Therefore=85 > =20 > This note declares the beginning of a Working Group Last Call on = draft-ietf-marf-not-spam-feedback, ending on July 21st. Please submit = any comments you have about this draft prior to that time, after which = we will begin the process of submitting it to the IESG for review and = approval. > =20 > -MSK, as co-chair > =20 > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf From internet-drafts@ietf.org Wed Jul 27 15:03: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 EA7CD11E809A; Wed, 27 Jul 2011 15:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDuICCImO5qs; Wed, 27 Jul 2011 15:03:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7778411E80C8; Wed, 27 Jul 2011 15:03:00 -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.56 Message-ID: <20110727220300.18426.75655.idtracker@ietfa.amsl.com> Date: Wed, 27 Jul 2011 15:03:00 -0700 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-reporting-discovery-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: Wed, 27 Jul 2011 22:03:01 -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 : A DNS TXT Record for Advertising and Discovering Willing= ness to Provide or Receive ARF Reports Author(s) : J.D. Falk Filename : draft-ietf-marf-reporting-discovery-01.txt Pages : 14 Date : 2011-07-27 This document defines a method for network operators to advertise their willingness to send feedback about received email to other parties, and for those other parties to advertise their willingness to receive such feedback. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-reporting-discovery-01.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-reporting-discovery-01.t= xt From jdfalk-lists@cybernothing.org Wed Jul 27 16:16:26 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 C931A11E80A2 for ; Wed, 27 Jul 2011 16:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCC2O1XhG3GI for ; Wed, 27 Jul 2011 16:16:26 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0949211E8084 for ; Wed, 27 Jul 2011 16:16:25 -0700 (PDT) Received: from [192.168.11.36] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p6RNGLOs013989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 27 Jul 2011 16:16:23 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p6RNGLOs013989 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=fudge; t=1311808583; bh=sCjPlWh/m8/vu0YdrC/LafAUxJ8gHm/kghIrSs5l5 Rs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=lwBIxU60Wfq+ fdN9mhVTUopXy5665yA1RLY0f247F9Mm0QEBnC1WqyDcG9iWDzYy9sNvVPuns4462U5 AhGciiRndgdmYN9SAUIhSix8Zv+VFZbt+r49skvRelk8F4xJq2v+MFBPfd7ZYpQqOq9 tLG8JPNu2Q4iDfSmbWe0yyaOg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: <20110727220300.18426.75655.idtracker@ietfa.amsl.com> Date: Wed, 27 Jul 2011 16:16:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6CCF933D-813E-4CD8-8008-1714F4A05302@cybernothing.org> References: <20110727220300.18426.75655.idtracker@ietfa.amsl.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] I-D Action: draft-ietf-marf-reporting-discovery-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: Wed, 27 Jul 2011 23:16:26 -0000 On Jul 27, 2011, at 3:03 PM, Internet-Drafts@ietf.org wrote: > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-marf-reporting-discovery-01= .txt This version incorporates a few changes that have been discussed on-list = over the past year, but primarily it's a refresh to avoid expiration. The diffs are here: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-marf-reporting-discovery-0= 1 Any other Report Generators planning to implement & test this thing? My = employer's timeline is still unclear. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From zav961@yahoo.com Thu Jul 28 11:18:28 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C253E11E80F0 for ; Thu, 28 Jul 2011 11:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaJ8yAk8cixz for ; Thu, 28 Jul 2011 11:18:28 -0700 (PDT) Received: from nm6-vm1.bullet.mail.sp2.yahoo.com (nm6-vm1.bullet.mail.sp2.yahoo.com [98.139.91.207]) by ietfa.amsl.com (Postfix) with SMTP id 1692211E80D7 for ; Thu, 28 Jul 2011 11:18:28 -0700 (PDT) Received: from [98.139.91.68] by nm6.bullet.mail.sp2.yahoo.com with NNFMP; 28 Jul 2011 18:18:25 -0000 Received: from [98.139.91.44] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 28 Jul 2011 18:18:25 -0000 Received: from [127.0.0.1] by omp1044.mail.sp2.yahoo.com with NNFMP; 28 Jul 2011 18:18:25 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 337060.22606.bm@omp1044.mail.sp2.yahoo.com Received: (qmail 14030 invoked by uid 60001); 28 Jul 2011 18:18:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311877105; bh=Gcz5zY62BqU9n4Fe5qMcFG90SwBIxQroz0l37G+ug1E=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=ietl9+GMRTOiAixTQHyNxP6vRT3FPQzSORd7xXpckl8o6nnnL/bG8qh4lWtufBtObDRhlyejTwHNYmyM1knqF/xh5chGUkr5crLxj89s/O2yVghfTr2zQk5ws5XEMpGWUqHkpDrhIOECFoqrp/mpiqmjuIBbPBnmUw3v6asfLmY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=H2XlYCAhCHLGa+mbgQ1hJ4z/k6c/xDiR3/C41ov6RKVIKRyxm4VzdxTjoDanbi8I8lU3wW/l+RwgJAz9g7mQILf1IOhvn9UiWMyWw27VyjYq3ALtxJ2zOb47MWZBhS6brheJ0DHZ6z0rYjJWCirubJENi2kdXc/ebJGy00vYhdc=; X-YMail-OSG: sJ0UX08VM1l7eTVEOkzc7AsAlq3cfzBH.nAV7nD29QqN6A9 kHWY_i.MiiEpseiQ38Nxkhbkh7KiEjbgb.NjknTfoOJfyRQTshbgex.HoZWC qm4meQwlSTSMiGH9zEeKOqxWGQi5mFf_Q9pn_f2U8jU87LnI0wvh8eMlL4C6 cGanMLKyGbVWxkUHG6HzZVGvexUZ5Z_TM_PwJn89cE1WCzIBoAy8kg2sujZc FH7bOckRqdW_L1x24Z8UIJ9FSyKib8w38XwMR0DuYGvhl0WlaeLt6Zoy5PEG rCHGA3leezo.R3K6vjU.dVIGOY.a0x3GLuzC53xAchUvgbAZSp9hMwuPyJpA znieTrQjMfM4sV.iUKxXZOzPYU9c- Received: from [62.99.163.157] by web45309.mail.sp1.yahoo.com via HTTP; Thu, 28 Jul 2011 11:18:25 PDT X-Mailer: YahooMailClassic/14.0.3 YahooMailWebService/0.8.112.310352 Message-ID: <1311877105.86828.YahooMailClassic@web45309.mail.sp1.yahoo.com> Date: Thu, 28 Jul 2011 11:18:25 -0700 (PDT) From: Simon Hradecky To: marf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:20:13 -0000 I am the author of the message forwarded regarding the virus feedback type and the _report subdomain. I decided to now join the mailing list and comment on a couple of points raised. This mail may not get properly threaded though for the lack of in-reply-to and reference fields that I can't insert into the mailer. ad Point evidence ----------------- I see the name of the virus together with the name of the virus scanner producing the identification as equivalent to the actual byte stream, I actually compare it to a compression utility in that sense, just that there's a lot better compression factor. If we start to discuss, whether that combination of virus name and virus scanner is really sufficient as evidence, then we will also need to raise the question, whether the full message is any evidence at all. The message could be tampered with (could be modified), the message could never ever have been sent, ... The MARF could actually be sent by a bad guy trying to lure the ISP's abuse department into taking action against an innocent customer! With that in mind, it does make perfect sense to publish the IP address of permitted MARF senders for a particular domain, similiar to SPF. ad point prevent sending malware in first place ----------------------------------------------- Of course, that would be the ideal case. However, as always with regulations and law, there are always people not adhering and sending such stuff nonetheless. Now, in order to enforce a regulation is it possible to violate the regulation? Certainly not. So, as we agree that malware should not be transmitted over the Internet (and Netiquette as well as RFCs actually require to not send such abuse), why would we then ENFORCE sending such malware in abuse reports? We agree, malware should not be sent, hence the abuse reporting mechanism should provide for that. That's the generic idea behind my proposal. ad ARIN database: ----------------- thanks, Alessandro, I am delighted about that announcement. ad input from malware folks, drop malware reporting altogether: --------------------------------------------------------------- I suspect that just like me those good folks didn't see a lot of need so far, more or less free format mails were generated so far. However, a number of ISPs have started to require ARF format for all mail arriving at their abuse department, so malware reporting has started to become an issue and feedback will probably start to flow in. MARF represents mail abuse reporting format, not just spam reporting format, hence it should be able to cater for proper malware reporting, too. By dropping, or not supporting a proper malware reporting, MARF could actually contribute to malware authors escaping any form of control/abuse handling. ad "Reported-CVE-Id": --------------------- Full support on my side, I actually forgot about that. I'd treat this as an optional field for those virus scanners, the database of which permit to identify attached CVE IDs. The scanners I am aware of currently do not cater for that facility. ad encryption of malware: ------------------------- Bandwidth is an issue despite encryption, as I said above, identifying the virus can be seen as a very effective compression, and at the same time removes the requirement of sending malware across the internet (to a possibly unexpecting receiver). The malware may well be in the order of several 100K, maybe even MBs of attachment, while the virusname is a matter of possibly 128, maybe 512 bytes. Is that line as well as mailbox congestion really worth sending an attachment, that is fully identified by the virusname anyway so that the recipient could go in his database, fetch a sample of that thing and knows the identified malware exactly byte by byte? Who does need and can take use of the actual malware body? Those who write virus scanners, obviously, they however had according (expecting) reporting channels already via their websites. What would the ISP do with the binary file he gets sent? The human eye wouldn't see anything, he might run his own virus scanner over it to get the same result the sender already had, and all we achieve is using up bandwidth on Internet and CPU power. And I'd need to again raise the question whether that attachment has any value as evidence whatsoever. If we don't trust that the MARF report contains accurate data, why would we assume the contained message is accurate? It could as well be just produced from any place without any actual mail having been received. If the receiver of the MARF report doubts the identification, he'd certainly inquire with the sender and they both will agree how to produce something that both accept as reliable evidence. ad FBL: ------- The MARF contains a clear free text section, feedback section and evidence section for good reason. The MARF can that way be processed by either any human monitoring an abuse mailbox, an automatic handling tool and/or both. So, why then restrict the use of MARF to only those who actually expect a MARF? Would the abuse department not requiring nor being prepared for MARF not be interested in seeing the spam mail, or know about what malware was sent from where? So, whether or not it is MARF, the abuse report does need to contain such stuff. So, why not send MARF (and "promote" it that way) on ANY abuse report if the complainer's reporting utility is capable of MARF? However, then MARF must not assume that the recipient is expecting and capable of handling such unsafe content, which again is another argument of shaping the evidence section according to need. Sorry again for the long sermon, and sorry for most likely breaking the threading of this discussion. From msk@cloudmark.com Thu Jul 28 12:06: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 6B24C5E8029 for ; Thu, 28 Jul 2011 12:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.763 X-Spam-Level: X-Spam-Status: No, score=-103.763 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7r889zEAGl4L for ; Thu, 28 Jul 2011 12:06: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 B1FD05E8024 for ; Thu, 28 Jul 2011 12:06: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; Thu, 28 Jul 2011 12:06:37 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 28 Jul 2011 12:06:35 -0700 Thread-Topic: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain Thread-Index: AcxNUwPJk02jOl4WS0aKHKwbtH4XrQAAkaBw Message-ID: References: <1311877105.86828.YahooMailClassic@web45309.mail.sp1.yahoo.com> In-Reply-To: <1311877105.86828.YahooMailClassic@web45309.mail.sp1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 19:06:38 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= imon Hradecky > Sent: Thursday, July 28, 2011 11:18 AM > To: marf@ietf.org > Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subd= omain >=20 > If we start to discuss, whether that combination of virus name and > virus scanner is really sufficient as evidence, then we will also need > to raise the question, whether the full message is any evidence at all. > The message could be tampered with (could be modified), the message > could never ever have been sent, ... The MARF could actually be sent by > a bad guy trying to lure the ISP's abuse department into taking action > against an innocent customer! With that in mind, it does make perfect > sense to publish the IP address of permitted MARF senders for a > particular domain, similiar to SPF. My understanding is that the general practice of an FBL is that they are no= t typically established in an automated fashion. That may change a little = as we do the reporting discovery work, but at the moment I don't think ther= e are any parties that just start sending or accepting FBLs and assuming th= ey're all valid. Thus, there's already an out-of-band component to establi= shing an FBL, and it makes sense to prearrange a list of authorized IP addr= esses in that process rather than in the base protocol. That said, we could entertain the idea of supporting this in the reporting = discovery work. I suggest you write actual text you'd like to see added to= that document to support this idea, and then we can debate it. > Now, in order to enforce a regulation is it possible to violate the > regulation? Certainly not. So, as we agree that malware should not be > transmitted over the Internet (and Netiquette as well as RFCs actually > require to not send such abuse), why would we then ENFORCE sending such > malware in abuse reports? We agree, malware should not be sent, hence > the abuse reporting mechanism should provide for that. That's the > generic idea behind my proposal. You cited RFC3834 in previous email as your basis for the "RFCs" claim abov= e. I disagree that it applies to FBLs, which are typically activated by hu= mans and not by software to report spam, and thus aren't automated messages= . I believe someone (you or someone else) claimed that nobody has implemented= an FBL that reports viruses so far. If that's the case, we could consider= updating the registry to mark it as historic. Those are the places where = RFC3834 might apply. But later you say virus FBLs are likely, so then the above text doesn't app= ly. > ad input from malware folks, drop malware reporting altogether: > --------------------------------------------------------------- >=20 > I suspect that just like me those good folks didn't see a lot of need > so far, more or less free format mails were generated so far. However, > a number of ISPs have started to require ARF format for all mail > arriving at their abuse department, so malware reporting has started to > become an issue and feedback will probably start to flow in. >=20 > MARF represents mail abuse reporting format, not just spam reporting > format, hence it should be able to cater for proper malware reporting, > too. By dropping, or not supporting a proper malware reporting, MARF > could actually contribute to malware authors escaping any form of > control/abuse handling. If people concur that this is an issue, I would suggest updating the base d= ocument to provide a requirement that a virus report include the name of th= e reporting software and the virus name it used, and restrict the third MIM= E part to be text/rfc822-headers. > ad "Reported-CVE-Id": > --------------------- >=20 > Full support on my side, I actually forgot about that. I'd treat this > as an optional field for those virus scanners, the database of which > permit to identify attached CVE IDs. The scanners I am aware of > currently do not cater for that facility. Can you (or someone) propose specific new text to the base document we shou= ld be considering? > ad encryption of malware: > ------------------------- >=20 > Bandwidth is an issue despite encryption, as I said above, identifying > the virus can be seen as a very effective compression, and at the same > time removes the requirement of sending malware across the internet (to > a possibly unexpecting receiver). There may be FBLs (such as one run by a malware analysis company) that want= to get every variant of a virus. Reporting only the virus name and detect= ion software would mean the details of a variant are lost. I don't know if= this is an issue or not. > Who does need and can take use of the actual malware body? Those who > write virus scanners, obviously, they however had according (expecting) > reporting channels already via their websites. They might wish to switch to FBLs as a standard way of doing this. Perhaps= we should ask them. > If we don't trust that the MARF report contains accurate data, why > would we assume the contained message is accurate? It could as well be > just produced from any place without any actual mail having been > received. This, I believe, is a restatement of the out-of-band issue; we know (or at = least assume) that reports from random sources can't be trusted. > ad FBL: > ------- >=20 > The MARF contains a clear free text section, feedback section and > evidence section for good reason. The MARF can that way be processed by > either any human monitoring an abuse mailbox, an automatic handling > tool and/or both. So, why then restrict the use of MARF to only those > who actually expect a MARF? Would the abuse department not requiring > nor being prepared for MARF not be interested in seeing the spam mail, > or know about what malware was sent from where? So, whether or not it > is MARF, the abuse report does need to contain such stuff. So, why not > send MARF (and "promote" it that way) on ANY abuse report if the > complainer's reporting utility is capable of MARF? >=20 > However, then MARF must not assume that the recipient is expecting and > capable of handling such unsafe content, which again is another > argument of shaping the evidence section according to need. It's not clear to me what change you're proposing here. -MSK From zav961@yahoo.com Thu Jul 28 17:14: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 7B4D121F8AFD for ; Thu, 28 Jul 2011 17:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.327 X-Spam-Level: X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=1.272, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWINMeUSoI5G for ; Thu, 28 Jul 2011 17:14:40 -0700 (PDT) Received: from nm19-vm0.bullet.mail.sp2.yahoo.com (nm19-vm0.bullet.mail.sp2.yahoo.com [98.139.91.216]) by ietfa.amsl.com (Postfix) with SMTP id D8F4521F8AFC for ; Thu, 28 Jul 2011 17:14:40 -0700 (PDT) Received: from [98.139.91.70] by nm19.bullet.mail.sp2.yahoo.com with NNFMP; 29 Jul 2011 00:14:37 -0000 Received: from [98.139.91.49] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 29 Jul 2011 00:14:37 -0000 Received: from [127.0.0.1] by omp1049.mail.sp2.yahoo.com with NNFMP; 29 Jul 2011 00:14:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 58345.11338.bm@omp1049.mail.sp2.yahoo.com Received: (qmail 11627 invoked by uid 60001); 29 Jul 2011 00:14:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311898476; bh=uFPeG92zqeOKb0zKRRCFjcti5lD3+6J/IaynsDGhirA=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=jn31gQaK97PY4OtULGB0U4Bf2I9v2NPrBUUJvP+ZkJheyGG/LOHLC3Xt56IhAYRJPu1oWLRIpPF1x5rDlDzqdenq90wshEQCM7p+EmGLHHPAYGfAWj9AT7gT3MEpCBx3bTlhFOAzZwFr2x9pW5rp6NAzywEM8JlgADpLnNrJo2k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=xDGS7OJ8n8FVNyyGJj//4yx7bHRWpbC/qCqKXlS6OydRkqYHt2rzxrO/5FLhO3vxxTwx8KlxrLhR28jT7w8FGIizTYbCvDSs5GaYl0tZgeNx9o7IJT0+3d1Yg+rhRuy0rWxM/7WXLR4PcL3/3YLrg1N05ulvA/Di0PcaB11cBzQ=; X-YMail-OSG: l2bRD_EVM1ll343mbGuV10G2fHLP89lE04dNkQt22FgxzGM tffFEDbTMDSx.1dXbfmr1_gHCzNCzr3iXFYy4p9gkIq5hjMN2zyJkStl9M5O _sNYvEU2FTLofdKaVjC1b3TNpEigJou7vKNWWiy0zov7q8kcPHIOgqn.ss3w 6d8OiezPXxskxTVVRwUgjsn_s9sUzbxC_yVL2HcWiM1IcoT2dlyG1MobjOXP Qrq_C6ht_WGJAsA2.je1sA9JDXTY.E.e.TGTrsM7v5xKZqGHFNThLNy00EvU fWcuZci10.no4GFSkVAqBA8U_vJ6yBMm2xV2N3jkft6tlxBdodFKMYMJupoy xsUhK0NYChzE76x81hqIMdksLkUE0IibquC0A9o8AXei43y.g5aftCs5X6d2 DwZ4G0M1xNa7Qe0FMLbOIq2x4.LXWylLlzs.BrLkc3YxMfgleiRhU6WG17v4 .zaUZYVKThfzx7MQ6AgJefbSioq7s6RIeNNMpaTd6SZieZQyTLh4R_FwjkNa vCAjT.RHwpQoRyOsLUxNbU_BelwGc_Vs4hNwDcHkM147HO1hKtq0ETxmOdcf tiwcqEfq_1y2czQ2TVbZRZkvGPyE9L7ZWtBiawQP2isf6Jg-- Received: from [62.99.163.157] by web45310.mail.sp1.yahoo.com via HTTP; Thu, 28 Jul 2011 17:14:36 PDT X-Mailer: YahooMailClassic/14.0.3 YahooMailWebService/0.8.112.310352 Message-ID: <1311898476.94112.YahooMailClassic@web45310.mail.sp1.yahoo.com> Date: Thu, 28 Jul 2011 17:14:36 -0700 (PDT) From: zav961 To: marf@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 00:14:42 -0000 Hello, Murray, > My understanding is that the general practice of an FBL is > that they are not typically established in an automated > fashion. That may change a little as we do the > reporting discovery work, but at the moment I don't think > there are any parties that just start sending or accepting > FBLs and assuming they're all valid. Thus, there's > already an out-of-band component to establishing an FBL, and > it makes sense to prearrange a list of authorized IP > addresses in that process rather than in the base protocol. > ... > You cited RFC3834 in previous email as your basis for the > "RFCs" claim above. I disagree that it applies to > FBLs, which are typically activated by humans and not by > software to report spam, and thus aren't automated > messages. I see the autoresponders fully involved here - MARF is actually an ideal tool to be used by spam filters, virus scanners and the like, long term they'll certainly take advantage of the possibilities of MARF. Of course, MARF also has its use in Outlook or similiar Mail Software where a user can push a button to mark a mail spam, or not spam, and the sending ISP (and/or filter provider) automatically gets informed upon that user intervention. A fully manual MARF report would seem over the top however. We certainly do spam and malware reporting fully automated. A brief look into history: In 2002, at the height of the first large virus outbreaks, we decided our mailservers would all get virus scanners (long before any of the large ISPs even began to think about it), and we wrote our first own spamfilter, which would also decode the mails (the virusscanners then couldn't cope with the mail format) and send the decoded parts through the virusscanner. As a result, only for virusses then (we didn't trust our own spamfiltering), we parsed the whois entries for the originating IP addresses of infected mails and sent fully automated malware reports to the relevant abuse mail address. This was quite effective, as quite a lot of malware infected machines got cleaned as result and the load on our mailservers reduced noticeable. We have kept that concept, in the meantime the spam filtering has gotten sufficiently reliable too, and hence our tools now do automated reporting on both issues. With a very few exceptions amongst the ISPs spam bots amongst their customers get identified and cleaned very quickly as a result. When Yakov presented his I think second draft on the abuse feedback format, I touched base with him and we discussed one or two details. As result I changed our spam reporting to ARF (but left the malware reporting in our original free text reporting). In the meantime all large ISPs started to introduce their virus filtering, spam filtering became the norm, and the load overall reduced, especially malware seemed to be a thing of the past. After the shut down of the Russian Business Network our filter software did not catch a single malware for about 2, maybe 3 years. However, we are again seeing malware mails increasing in numbers and our filter probably catches a dozen or two every day again. So, malware reporting is still necessary. In the last few weeks a few of our free text malware reports bounced, one with a large ISP, who said in its bounce message, that MARF is expected for abuse reports. That's basically the trigger of why I checked the current definitions and started implementation of MARF feedback-type virus into our utility until I realized the issues (which resulted in the initial mail to you). Hence, to word a request to the MARF group: design the MARF drafts not only with manual, but also with automated responders in mind. I am convinced, that automated responders will create most of the feedback messages in not too distant future. In my opinion, the currently released documents do not create any problem with the spam reporting side. In the malware reporting side however, there is a serious issue I already pointed out. > I believe someone (you or someone else) claimed that nobody > has implemented an FBL that reports viruses so far. If > that's the case, we could consider updating the registry to > mark it as historic. Those are the places where > RFC3834 might apply. Well, if that claim of no-one ever reporting malware automatically ever existed, our implementation is the living example to the contrary. > If people concur that this is an issue, I would suggest > updating the base document to provide a requirement that a > virus report include the name of the reporting software and > the virus name it used, and restrict the third MIME part to > be text/rfc822-headers. I obviously support that motion! > There may be FBLs (such as one run by a malware analysis > company) that want to get every variant of a virus. > Reporting only the virus name and detection software would > mean the details of a variant are lost. I don't know > if this is an issue or not. Malware analysis companies have established their own channels of how to receive malware samples. That's not a consideration for reporting mail abuse, in my opinion. Mail abuse reports, as I see it, should trigger an action at the offender's end to stop identified abuse. Therefore it is irrelevant to see what variants exist - if the virusscanner at the complainer's side has detected a malware, there'll be a report that unambiguously identifies the malware. If the virus scanner did not recognize the threat, there will obviously be no report anyway and the malware go through - and may cause damage at the recipient's end, which then will trigger the malware being submitted to malware analysers. You see therefore, these are two very distinct steps, where malware analysers or abuse reports come into play. So we should remain focussed on the reporting side of identified abuse, which as far as I understand it is the purpose of MARF (mail abuse reporting format). To hammer the point in: It doesn't matter whether an abuse has been identified by the human pushing a button in his mailer, or whether the abuse has been identified by a spamfilter on established criteria or the abuse has been identified by a virus scanner based on its database and detection criteria. In every case, the abuse has been identified somehow and may lead to a MARF report. > They might wish to switch to FBLs as a standard way of > doing this. Perhaps we should ask them. No need to, that's a waste of resources as I lined out above, malware analysers mainly get involved on unidentified threats that already caused damage. They have their own ways of getting those samples. > This, I believe, is a restatement of the out-of-band issue; > we know (or at least assume) that reports from random > sources can't be trusted. Roger, so we are clear on this point. When I mentioned advertising the IP address of the potential MARF report transmitter similiar to SPF, I overlooked an important security question (that's always the danger of a single brain thinking). SPF and MARF have a decisive difference in the use for the bad boys. SPF is hardly exploitable even if it gets under full control of a malicious user. However, MARF could become a dangerous tool in the hands of a malicious user misleading ISPs/regulating bodies or launching DoS attacks against abuse departments. Which leads me to think on a second thought that the MARF senders should be identified through ARIN and their delegated authorities, too, just like the abuse mail addresses. That approach immediately puts the out of band topic to rest, too. Now, I guess, this would hamper introduction of MARF, especially before it gets widely accepted, hence there should be a compromise which allows MARF senders without such identification. I'd propose to look at the implementation of SPF, and instead of the service selector SPF use MARF, otherwise just import the SPF RFC. Implementations of MARF receiving processors checking the name servers thus could easily use the SPF library with some minor modifications to the source code. The syntax and format, apart from the service, could and should remain identical as the purpose is the same: SPF identifies IP addresses to transmit mails with the specific sender domain, MARF DNS identifies IP addresses permitted to transmit mail abuse reports for a particular entity. The imported SPF draft will need two additions: S.1: for reverse DNS resolving (IP address translated into domain name) the relevant MARF entry should be looked up at the full URL, if no entry is found there, drop the most inner part of the URL (e.g. in ip-x-y-z.xyzdomain.co.uk drop the ip-x-y-z) and retry (now on xyzdomain.co.uk) until all parts of the URL are used up (the root domains like com, co.uk, ... might want to publish a MARF entry too, who knows?). Stop at the first discovery of a MARF entry and check originating IP address against those results. (Reason: reverse resolving usually remains under control of the ISP due to name server granularity issues). S.2: for DNS name resolving (URL as input) resolve the IP address, then determine the MARF entry using S.1 (via reverse resolving). (Reason: malicious domain registrations still need some ISP to host their stuff, and we reach the ISP, not the malicious user that way). The draft should still nail down that the name server(s) being checked may be under control of a not trustworthy source, and any such identified MARF sender may still be needed to be treated with caution. If an ARIN entry exists identifying the permitted MARF sender, that entry overrules whatever is stated in the name server's MARF entry. So, in order to summarize the current standing of the discussion and proposals: A) feedback-type: virus I propose to change the keyword virus to malware. To facilitate the malware feedback type, the evidence section (section 3) of MARF should be changed from message/RFC822 to text/RFC822-Headers and contain only and only the complete header of the offending message. In the report section following fields become mandatory: Source-IP: reports the IP address the reporting server received the offending mail directly from Reported-Malware: the name of the malware as identified by the reporting malware scanner Reporting-Utitlity: the name of the reporting malware scanner, ideally also identifying the database in use An optional field: Reported-CVE-ID: the CVE ID numbers, separated by commas, identifying the threats, along http://cve.mitre.org B) MARF Discovery (_report subdomain) B.1 Rethink the whole draft in view of automated responders, malicious abuse and ongoing ARIN database extensions, I'd think the current proposal could be dropped B.2 Require ARIN/delegated authorities published abuse addresses to unconditionally accept MARF reports (they automatically do as it stands due to the humanly readable first part and third part containing the relevant evidence) B.3 Introduce a MARF sender identification (via IP address(es)) with ARIN/IP assignment authorities similiar to abuse address registration B.4. As long as ARIN/IP assignment authorities are not featuring such MARF database entries import the SPF RFC replacing selector SPF with MARF for identifying authorised MARF transmitters. A sample MARF report: ===================== From: "Complainer" To: Subject: MARF report Date: Thu, 28 Jul 2011 21:08:47 +0200 MIME-Version: 1.0 Content-Type: multipart/report; report-type=feedback-report; boundary="----=_NextPart_000_004A_01CC4D6A.8AA038D0" This is a multi-part message in MIME format. This is a MIME-formatted message. Portions of this message may be unreadable without a MIME-capable mail program. ------=_NextPart_000_004A_01CC4D6A.8AA038D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is an example MARF compliant complaint: we received malware "W32/Mytob.AT@mm" from your IP address 192.168.0.45 at 21:08:45 +0200 Find the full header of the message below. We ask to have this machine checked and cleaned or temporarily disconnected until it has been cleaned. ------=_NextPart_000_004A_01CC4D6A.8AA038D0 Content-Type: message/feedback-report Feedback-Type: malware User-Agent: sample MARF generator Version: 1 Source-IP: 192.168.0.45 Reported-Malware: W32/Mytob.AT@mm Reporting-Utility: Sample Virus Scanner, database 2011-07-28-5142 Reported-CVE-ID: CVE-1999-0067, CVE-1999-0068 ------=_NextPart_000_004A_01CC4D6A.8AA038D0 Content-Type: text/RFC822-Headers Return-Path: Received: from ([192.168.0.45]) by mail.complainer.com with ESMTP id p6SJ82qN000353 for ; Thu, 28 Jul 2011 19:08:45 GMT Date: Thu, 28 Jul 2011 19:08:45 GMT To: victim@complainer.com From: user@offender.com Subject: Your documents attached ------=_NextPart_000_004A_01CC4D6A.8AA038D0-- A sample DNS entry: =================== marf.sample.com. 1D IN TXT "v=marf1 ip4:192.168.0.48 -all" @ 1D IN TXT "v=marf1 redirect=marf.sample.com" From johnl@iecc.com Fri Jul 29 06:39: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 3DA2921F8A30 for ; Fri, 29 Jul 2011 06:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n39xrmY8WnTN for ; Fri, 29 Jul 2011 06:39: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 22EC821F8A69 for ; Fri, 29 Jul 2011 06:39:04 -0700 (PDT) Received: (qmail 41054 invoked from network); 29 Jul 2011 13:39:02 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 29 Jul 2011 13:39:02 -0000 Received: (qmail 21524 invoked from network); 29 Jul 2011 13:39:02 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 29 Jul 2011 13:39:02 -0000 Date: 29 Jul 2011 13:38:38 -0000 Message-ID: <20110729133838.62036.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <1311877105.86828.YahooMailClassic@web45309.mail.sp1.yahoo.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 13:39:06 -0000 >I see the name of the virus together with the name of the virus scanner producing the identification as equivalent to the actual byte stream Please do not assume that everyone else's system works the same way that yours does. For the virus reports I send, I have no idea what virus it is. My system makes the fairly safe assumption that any message with an attached EXE sent to a spam trap is a virus. I lightly denature the report by changing the first few bytes of the bas64 attachment to xxxx so it's not executable any more, just in case some misconfigured piece of mail software tries to do something unwise with it. > why would we then ENFORCE sending such malware in abuse reports? Because decades of experience have taught us that a full, unredacted copy of the message being reported is the most useful thing you can send to a feedback consumer. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From vesely@tana.it Fri Jul 29 10:34:26 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 AC9B221F8B85 for ; Fri, 29 Jul 2011 10:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.441 X-Spam-Level: X-Spam-Status: No, score=-4.441 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpqbcnuUdOXZ for ; Fri, 29 Jul 2011 10:34:25 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3DA21F8B7B for ; Fri, 29 Jul 2011 10:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1311960859; bh=/zg1Ol8VaRz6vY+q0HJoDYdRg2IJaCf22hAj3r0OS+Q=; l=2002; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=HOx3nfXiAAWt+VTprqsPAowdYxZXWLKfZyI8DFb8MbBxwAkU88jLmLHM7rOG4s7ei 0JwaQ3Ta9tCsYZdk34Bcdo9pGIZOGfZtGDBLhzBBu8aoDsByvkWwCaar0WETZYVlQO B38l4Tx2bGqk3IpKOW/nmLPPNduGS3zRDkFN5Mgo= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 29 Jul 2011 19:34:19 +0200 id 00000000005DC039.000000004E32EF1B.00002419 Message-ID: <4E32EF1B.7050000@tana.it> Date: Fri, 29 Jul 2011 19:34:19 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: marf@ietf.org References: <1311898476.94112.YahooMailClassic@web45310.mail.sp1.yahoo.com> In-Reply-To: <1311898476.94112.YahooMailClassic@web45310.mail.sp1.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [marf] Automated vs. manual reporting, was feedback type Virus X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 17:34:26 -0000 On 29/Jul/11 02:14, zav961 wrote: > I see the autoresponders fully involved here - MARF is actually an > ideal tool to be used by spam filters, virus scanners and the like, > long term they'll certainly take advantage of the possibilities of > MARF. > > [...] > > Hence, to word a request to the MARF group: design the MARF drafts > not only with manual, but also with automated responders in mind. I > am convinced, that automated responders will create most of the > feedback messages in not too distant future. +1, possibly we should add a field such as Report-Trigger: human/auto. Automatically triggered reports to discovered (not FBL) consumers may actually correspond to the etymological DSN origin or ARF. An MTA decides to quarantine a message, either UBE or virus, and issues a report. The report should be sent with an empty smtp.mailfrom in this case, so it may be an alternative to "Report-Trigger". I concur that text/rfc822-headers is enough for automatically discovered viruses, if Reported-Malware is set. How about UBE? Such reports probably also need to be handled differently, according to their human/auto origin. > Malware analysis companies have established their own channels of > how to receive malware samples. That's not a consideration for > reporting mail abuse, in my opinion. I disagree on this. Many companies have, or used to have, email addresses specific for (suspected) virus submission by humans, e.g. virus@ca.com, virus_research@avertlabs.com, samples@sophos.com, ... Most of them recommend to use zip files, possibly password-protected so that sender-side mail scanners won't block them. > If the virus scanner did not recognize the threat, there will > obviously be no report anyway and the malware go through - and may > cause damage at the recipient's end, which then will trigger the > malware being submitted to malware analysers. That is to say, there will be a report, but to a different consumer. jm2c From jdfalk-lists@cybernothing.org Fri Jul 29 13:23: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 8D49F21F8A58 for ; Fri, 29 Jul 2011 13:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrF4opK5u+JL for ; Fri, 29 Jul 2011 13:23:41 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id 630E811E808D for ; Fri, 29 Jul 2011 13:23:35 -0700 (PDT) Received: from [192.168.11.36] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p6TKNTAA019549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 29 Jul 2011 13:23:31 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p6TKNTAA019549 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=fudge; t=1311971011; bh=xwyhSfArhl1QvJSw2nR6caemCdyJCCa/IQZwZq7dZ cE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=UKdwFM5UCiU1 /QEh25v6AKlOhPW7vatW+d22JAZYHa/jrPYm1enalD9EZfqnyEGW4MD6oAatyM+D9mb w7dG6eQT08FiDQLZqr+sGT55TjkOIh8PWcxZ+NS5NnsHKnnpSF9zywqtrCUzZRyQ7Th eKgg80KKtMysS6oasHdlRA1aw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: <1311898476.94112.YahooMailClassic@web45310.mail.sp1.yahoo.com> Date: Fri, 29 Jul 2011 13:23:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1311898476.94112.YahooMailClassic@web45310.mail.sp1.yahoo.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 20:23:42 -0000 On Jul 28, 2011, at 5:14 PM, zav961 wrote: > Of course, MARF also has its use in Outlook or similiar Mail Software = where a user can push a button to mark a mail spam, or not spam, and the = sending ISP (and/or filter provider) automatically gets informed upon = that user intervention. A fully manual MARF report would seem over the = top however. Using ARF for reports from MUAs has been discussed many times, but = hasn't really ever been implemented (except for a Thunderbird plugin, = years ago, now lost to history.) I'd love to see somebody try it, but = until they do I don't think we can call it a common practice. > In the meantime all large ISPs started to introduce their virus = filtering, spam filtering became the norm, and the load overall reduced, = especially malware seemed to be a thing of the past. After the shut down = of the Russian Business Network our filter software did not catch a = single malware for about 2, maybe 3 years. However, we are again seeing = malware mails increasing in numbers and our filter probably catches a = dozen or two every day again. So, malware reporting is still necessary. = In the last few weeks a few of our free text malware reports bounced, = one with a large ISP, who said in its bounce message, that MARF is = expected for abuse reports. That's basically the trigger of why I = checked the current definitions and started implementation of MARF = feedback-type virus into our utility until I realized the issues (which = resulted in the initial mail to you). Perhaps if you were to contact Yahoo!, they'd set up a trusted channel = for your ARF reports where they'll be given a higher priority than = random mail to abuse@. > Now, I guess, this would hamper introduction of MARF, especially = before it gets widely accepted, hence there should be a compromise which = allows MARF senders without such identification. MARF is already widely accepted. There are dozens of report generators = and literally thousands of report consumers, nearly all following the = use case described in draft-jdfalk-marf-as. That's part of why there's = disagreement -- we don't want to change MARF in ways which would be = incompatible with the established userbase. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From vesely@tana.it Sat Jul 30 01:08: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 9F00821F8834 for ; Sat, 30 Jul 2011 01:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=-1.162, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MANGLED_SPAM=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ue09TOvK14sZ for ; Sat, 30 Jul 2011 01:08:38 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A014B21F87FA for ; Sat, 30 Jul 2011 01:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1312013307; bh=Ibw6RQmzpl+qL6zLUyvIzAV8UITqvlxRP08rcBqmwUI=; l=911; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=kq70JGM5Q/mCzgcg1w3bCAMTxRtwGCG0NyLHHsquBH+52+F6TTP7kIpw+gXalhrd3 YBryqBhR1cV7BbOvJW07jbCf1i0lYq9KdHww/hxivZesqBScnAkwHqVR5LsyAixksU 9xbUcIitGRHjatpR9Q5wUXIq29BTEpVIghCwJm6Y= 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, 30 Jul 2011 10:08:27 +0200 id 00000000005DC039.000000004E33BBFB.00006B09 Message-ID: <4E33BBFB.4020209@tana.it> Date: Sat, 30 Jul 2011 10:08:27 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Message Abuse Report Format working group References: <1311898476.94112.YahooMailClassic@web45310.mail.sp1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [marf] MUA plugins, was feedback type Virus X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 08:08:39 -0000 On 29/Jul/11 22:23, J.D. Falk wrote: > Using ARF for reports from MUAs has been discussed many times, but > hasn't really ever been implemented (except for a Thunderbird > plugin, years ago, now lost to history.) I'd love to see somebody > try it, but until they do I don't think we can call it a common > practice. Where is it? I've been looking for one since we discussed this question in ASRG[*], and eventually started to roll my own stuff. However, I never completed, nor released, my plugin. Previous experience may probably help me... any pointer? The larger part of feedback comes from webmail systems. They /are/ MUAs, although somewhat more loosely constrained by mail protocols. -- [*] 9 Dec 2009 00:35:03 -0500 http://www.ietf.org/mail-archive/web/asrg/current/msg15780.html http://wiki.asrg.sp.am/wiki/Adding_a_junk_button_to_MUAs http://wiki.asrg.sp.am/wiki/Abuse_Reporting From steve@wordtothewise.com Sat Jul 30 09:56:23 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 7181421F8ACA for ; Sat, 30 Jul 2011 09:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id km3anSjIG7Ss for ; Sat, 30 Jul 2011 09:56:22 -0700 (PDT) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id A47C021F8AC9 for ; Sat, 30 Jul 2011 09:56:22 -0700 (PDT) Received: from [192.168.80.43] (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 AA6A22DDE5 for ; Sat, 30 Jul 2011 09:56:21 -0700 (PDT) From: Steve Atkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 30 Jul 2011 09:56:20 -0700 Message-Id: <35734E6B-4579-4EF4-A139-7BFB4FA4573F@wordtothewise.com> To: Message Abuse Report Format working group Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [marf] Misuse of ARF by spam-friendly ISPs X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 16:56:23 -0000 A major US ISP has started using the existence of ARF as an excuse to = reject all spam complaints to their abuse@ alias, instead saying that = they refuse to accept any reports of abuse in any format other than ARF = - meaning that typical users have no way to report the (large amounts = of) abusive mail they emit. It strikes me that using ARF as a scapegoat for antisocial behaviour of = this sort is not going to do ARF's reputation much good, especially if = other abuse-friendly ISPs pick up on the idea. Is there anything "we" can do about it, such as putting a policy = statement somewhere? Should we? Cheers, Steve From alex@bobotek.net Sat Jul 30 10:18:12 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 446C721F885C for ; Sat, 30 Jul 2011 10:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+bbGN69jVjK for ; Sat, 30 Jul 2011 10:18:11 -0700 (PDT) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by ietfa.amsl.com (Postfix) with ESMTP id BA15E21F8839 for ; Sat, 30 Jul 2011 10:18:11 -0700 (PDT) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta13.emeryville.ca.mail.comcast.net with comcast id EHH41h0030vp7WLADHJ9zq; Sat, 30 Jul 2011 17:18:09 +0000 Received: from bobo1.bobotek.net ([71.231.189.124]) by omta05.emeryville.ca.mail.comcast.net with comcast id EHJJ1h00L2hUyyF8RHJLKh; Sat, 30 Jul 2011 17:18:23 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 30 Jul 2011 10:18:28 -0700 Message-ID: In-Reply-To: <35734E6B-4579-4EF4-A139-7BFB4FA4573F@wordtothewise.com> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-TNEF-Correlator: Thread-Topic: [marf] Misuse of ARF by spam-friendly ISPs Thread-Index: AcxO2aS3yZ8dB3XhRpCXS5fZZe/9SgAAYaGw References: <35734E6B-4579-4EF4-A139-7BFB4FA4573F@wordtothewise.com> From: "Alex Bobotek" To: "Steve Atkins" , "Message Abuse Report Format working group" Subject: Re: [marf] Misuse of ARF by spam-friendly ISPs X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 17:18:12 -0000 Steve, Is a more detailed statement of this ISP's policy and rationale available? This might have some bearing on the question of whether MARF or other action is appropriate. Some formal or informal chat or action on best MARF practices in MAAWG is also be a possibility. Regards, Alex -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Steve Atkins Sent: Saturday, July 30, 2011 9:56 AM To: Message Abuse Report Format working group Subject: [marf] Misuse of ARF by spam-friendly ISPs A major US ISP has started using the existence of ARF as an excuse to reject all spam complaints to their abuse@ alias, instead saying that they refuse to accept any reports of abuse in any format other than ARF - meaning that typical users have no way to report the (large amounts of) abusive mail they emit. It strikes me that using ARF as a scapegoat for antisocial behaviour of this sort is not going to do ARF's reputation much good, especially if other abuse-friendly ISPs pick up on the idea. Is there anything "we" can do about it, such as putting a policy statement somewhere? Should we? Cheers, Steve _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf From steve@wordtothewise.com Sat Jul 30 10:26: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 A2C8B21F8A7B for ; Sat, 30 Jul 2011 10:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiNqNjELs6bL for ; Sat, 30 Jul 2011 10:26:44 -0700 (PDT) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 3968521F8A35 for ; Sat, 30 Jul 2011 10:26:44 -0700 (PDT) Received: from [192.168.80.43] (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 34D512DDE4 for ; Sat, 30 Jul 2011 10:26:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Steve Atkins In-Reply-To: Date: Sat, 30 Jul 2011 10:26:44 -0700 Content-Transfer-Encoding: 7bit Message-Id: <953887BF-E8AB-4246-8075-7EB50A7BF916@wordtothewise.com> References: <35734E6B-4579-4EF4-A139-7BFB4FA4573F@wordtothewise.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] Misuse of ARF by spam-friendly ISPs X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 17:26:44 -0000 On Jul 30, 2011, at 10:18 AM, Alex Bobotek wrote: > Steve, > > Is a more detailed statement of this ISP's policy and rationale > available? This might have some bearing on the question of whether MARF > or other action is appropriate. The ISP has made no statement of what their policy or rationale is. I could speculate, but that probably wouldn't be helpful. Sending email to their abuse@ alias leads to a response that starts with "Thank you for your email, but this address now only accepts messages in Abuse Reporting Format." - that's the only information I have about them right now. > Some formal or informal chat or action > on best MARF practices in MAAWG is also be a possibility. That too, yes. I was more thinking along the lines of "us" being clear that ARF is not intended as a replacement for manual reports, rather a useful additional format primarily for machine-to-machine communication. Cheers, Steve > > Regards, > > Alex > > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Steve Atkins > Sent: Saturday, July 30, 2011 9:56 AM > To: Message Abuse Report Format working group > Subject: [marf] Misuse of ARF by spam-friendly ISPs > > A major US ISP has started using the existence of ARF as an excuse to > reject all spam complaints to their abuse@ alias, instead saying that > they refuse to accept any reports of abuse in any format other than ARF > - meaning that typical users have no way to report the (large amounts > of) abusive mail they emit. > > It strikes me that using ARF as a scapegoat for antisocial behaviour of > this sort is not going to do ARF's reputation much good, especially if > other abuse-friendly ISPs pick up on the idea. > > Is there anything "we" can do about it, such as putting a policy > statement somewhere? Should we? > > Cheers, > Steve > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf From msk@cloudmark.com Sat Jul 30 21:30: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 E942A21F86EE for ; Sat, 30 Jul 2011 21:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.243 X-Spam-Level: X-Spam-Status: No, score=-103.243 tagged_above=-999 required=5 tests=[AWL=-0.644, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLmmIuD2uP-h for ; Sat, 30 Jul 2011 21:30:32 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 8435321F86EC for ; Sat, 30 Jul 2011 21:30:29 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sat, 30 Jul 2011 21:30:31 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Sat, 30 Jul 2011 21:30:30 -0700 Thread-Topic: [marf] Misuse of ARF by spam-friendly ISPs Thread-Index: AcxO3d8Xi/l2OtRCSwKk+m2qSPoCSgAXHyXw Message-ID: References: <35734E6B-4579-4EF4-A139-7BFB4FA4573F@wordtothewise.com> <953887BF-E8AB-4246-8075-7EB50A7BF916@wordtothewise.com> In-Reply-To: <953887BF-E8AB-4246-8075-7EB50A7BF916@wordtothewise.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] Misuse of ARF by spam-friendly ISPs X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 04:30:33 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Steve Atkins > Sent: Saturday, July 30, 2011 10:27 AM > To: Message Abuse Report Format working group > Subject: Re: [marf] Misuse of ARF by spam-friendly ISPs >=20 > > Some formal or informal chat or action > > on best MARF practices in MAAWG is also be a possibility. >=20 > That too, yes. I was more thinking along the lines of "us" being > clear that ARF is not intended as a replacement for manual reports, > rather a useful additional format primarily for machine-to-machine > communication. I wonder if this could be mentioned in the BCP effort we're doing (JD?). Failing that, if we decide to update the base document given the recent flu= rry of input, this could certainly go in there. But it's too early to make= that call, I think. -MSK From shmuel+gen@patriot.net Sun Jul 31 16:01: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 80ED821F88DD for ; Sun, 31 Jul 2011 16:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.153 X-Spam-Level: X-Spam-Status: No, score=-0.153 tagged_above=-999 required=5 tests=[AWL=-1.223, BAYES_50=0.001, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWEoKlb+DOqD for ; Sun, 31 Jul 2011 16:01:51 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id F3F9F21F8879 for ; Sun, 31 Jul 2011 16:01:50 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.207]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 3B3F1F5808C for ; Sun, 31 Jul 2011 18:52:41 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Sun, 31 Jul 2011 09:57:24 -0400 To: marf@ietf.org In-Reply-To: <1311898476.94112.YahooMailClassic@web45310.mail.sp1.yahoo.com> Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20110731225242.3B3F1F5808C@smtp.patriot.net> Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 23:01:51 -0000 In <1311898476.94112.YahooMailClassic@web45310.mail.sp1.yahoo.com>, on 07/28/2011 at 05:14 PM, zav961 said: >Of course, MARF also has its use in Outlook or similiar Mail Software >where a user can push a button to mark a mail spam, or not spam, and >the sending ISP (and/or filter provider) automatically gets informed >upon that user intervention. That would seem to be a case where it is desirable to include the full message; the typical end user cannot be trusted to make an accurate determination. >B.2 Require ARIN/delegated authorities published abuse addresses to >unconditionally accept MARF reports Even if they have registered a separate address for MARF? -- 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 Sun Jul 31 16:01: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 6303121F899F for ; Sun, 31 Jul 2011 16:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.153 X-Spam-Level: X-Spam-Status: No, score=0.153 tagged_above=-999 required=5 tests=[AWL=-0.917, BAYES_50=0.001, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZYJDFLt4t4e for ; Sun, 31 Jul 2011 16:01:54 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0025D21F898E for ; Sun, 31 Jul 2011 16:01:53 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.207]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id DAAD3F5808C for ; Sun, 31 Jul 2011 18:52:44 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Sun, 31 Jul 2011 10:03:21 -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: <20110731225245.DAAD3F5808C@smtp.patriot.net> Subject: Re: [marf] FW: Feedback on: ARF feedback type Virus/_report subdomain X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 23:01:54 -0000 In , on 07/29/2011 at 01:23 PM, "J.D. Falk" said: >Using ARF for reports from MUAs has been discussed many times, but >hasn't really ever been implemented (except for a Thunderbird plugin, >years ago, now lost to history.) I'd love to see somebody try it, >but until they do I don't think we can call it a common practice. Keep in mind that once a large corporation is requiring that abuse reports be in ARF, the case for the MUA sending reports in MARF is much stronger. While I consider it inexcusable to ignore text complaints sent to abuse, I don't see the offenders backing off. -- 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)