From vesely@tana.it Wed Feb 1 02:47:50 2012 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 5795521F861C for ; Wed, 1 Feb 2012 02:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.626 X-Spam-Level: X-Spam-Status: No, score=-4.626 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4V7Ya7llISCN for ; Wed, 1 Feb 2012 02:47:49 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 26D2621F85EF for ; Wed, 1 Feb 2012 02:47:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328093267; bh=HvcASBSegg/hY1jlokevaWh6ZZtyTD1Fe0IlEwU39Os=; l=4543; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=jc1wbzdAfrK+/pgikiozYz6Ohz7v6KF4OjjeCqfsiZ+xjXcIt9CPo4oSkrS6xaPlq vJW1+L4OEJBUYR7uJa3tNDEQjCnt3RDFe8iMyiwSobrs+XWemIcG0L2yd0W7y908yg 7GsTxVK7dGeYcJNe0vDwaNQ8fLZ4bWPc6VmhYFXQ= 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, 01 Feb 2012 11:47:47 +0100 id 00000000005DC039.000000004F291853.00001FEB Message-ID: <4F291852.8020807@tana.it> Date: Wed, 01 Feb 2012 11:47:46 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120130193649.24837.53481.idtracker@ietfa.amsl.com> <4F283C32.7070206@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-dkim-reporting-08, was -07 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, 01 Feb 2012 10:47:50 -0000 On 31/Jan/12 21:00, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely > >> BTW, why isn't the rs= string actionable even in the absence of ra=? > > Good point; fixed. Nice, thanks for this --and for the other fixes as well. Does this change have to be addressed also in the last step of the reporting algorithm? See below... >> 3.3. *DKIM Reporting Algorithm* >> >> The last paragraph of this section is rather convoluted. In order to >> simplify it, I would modify the first step of the algorithm > I think that falls under "semantically equivalent", so I'd prefer > not to change it. Steps 2-9 are quite precisely stated, so I'm not sure how obvious it is what amount of latitude is left to programmers' common sense. An alternative is to use regular text phrases to discuss the SHOULDs and MAYs of generating a report, as well as the relative independence between that and honoring rs=. The algorithm proper would then specify what to do after those decisions are made. (Hey, numbering paragraphs /is/ meaningful in this case.) >> 8.5. *Automatic Generation* >> >> The last paragraph, about out-of-band arrangements, seems to defy this >> I-D's very purpose of automating reporting. Considering what marf-as >> is going to say on unsolicited reports, I'd s/create/persist sending/. > > What this section is trying to say is that people should not > implement systems that do this kind of reporting work by default. Yes. In this sense, that paragraph is rowing in the opposite direction than the rest of the I-D. (I understand "reporting of message authentication failures in an on-demand fashion" as I-set-record=you-send-report.) > It can create a ton of traffic due to simple infrastructure > problems at the signer/sender, for example. The obvious > mitigation, rate limiting the generation of reports, isn't an ideal > solution for various reasons. Agreed. > I don't think this harms what -as is saying about unsolicited > reports. Not at all. However, marf-as says Where an unsolicited report results in the establishment of contact with a responsible and responsive party, this can be saved for future complaint handling and possible establishment of a formal (solicited) feedback arrangement. That is, it provides for transitioning to an out-of-band agreement, if interpreted in this I-D's context. > This document discusses a specific kind of feedback and thus this > is not a statement about ARF in general. It is, since the paragraph talks about "these (or any) ARF reports". And it is good to do so, IMHO. This I-D is not specifying blind-to-witting transitions, and I'm not suggesting it should, but maybe it can still suggest some details of such activity. >> 8.6. *Reporting Multiple Incidents* >> >> To suspend report generation for some time after an RCPT rejection of >> the reporting address might also provide for a safe approach. > > Since it's Security Considerations, none of this is normative. > It's just a suggestion for handling large volumes of reports. Yes, such specification should belong to some other I-D (reporting-discovery? :-) > Your two are equally viable, so it would be fine to add them as > well, especially since the latter one talks about a way to do rate > limiting at the report receiver rather than relying on the report > generator to do it all. So I'll add this: > > Other rate limiting provisions might be considered, > including detection of a temporary failure > response from the report destination and thus > halting report generation to that destination > for some period, or simply imposing or negotiating > a hard limit on the number of reports to be sent > to a particular receiver in a given time > frame. While that may be semantically correct, there is the practical problem that 4xx reply codes are not reported timely. It is necessary to query the mail queue in order to know whether there are outstanding temporary failures. In case the boundary box where the report generator lives does not send mail out directly, it is not practical to determine that condition. On the other hand, 5xx reply codes should cause the current message to be discarded. On resuming reporting, new reports are transmitted, rather than the queued flood initiators. However, in order to ensure immediate notification of rejections in all cases, one would have to use purposely configured variable envelope senders. What do you think? From vesely@tana.it Wed Feb 1 03:15:27 2012 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 C157021F8698 for ; Wed, 1 Feb 2012 03:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.628 X-Spam-Level: X-Spam-Status: No, score=-4.628 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xi-tOwGQ65lf for ; Wed, 1 Feb 2012 03:15:27 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id E32BF21F8693 for ; Wed, 1 Feb 2012 03:15:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328094925; bh=+sdCoBRUFtT1qZ7V9oaEu6DmITdfB7cAN5vGNWnGQP8=; l=1233; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=eCPx/wArUVdQozGNYIin/A3x09RuJ0ek/FfK4Du+pJ672MdjMV8UCvwrgu4SQSLrx AREDQ+s1pbjyjh2pvmrOjA1BWxDe/MgI+wDdp5vL1/ljRJaDC0//JFpSKQ9w/4PP6f DpLlcOirbPPJxOxy0b1l3dkm7AdGlluvJmHzkZmg= 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, 01 Feb 2012 12:15:25 +0100 id 00000000005DC039.000000004F291ECD.0000269E Message-ID: <4F291ECD.9040308@tana.it> Date: Wed, 01 Feb 2012 12:15:25 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 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] Working Group Last Call on draft-ietf-marf-as-05 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, 01 Feb 2012 11:15:27 -0000 On 31/Jan/12 22:23, Barry Leiba wrote: > I am re-posting this without the extra recipients; please reply to > THIS message, and NOT to that other one. We can discuss later who, > exactly, should get the truncheon treatment here....... > --- > > Here begins a last call for the MARF working group on the subject > document, detailed below. Please make any comments you have on this > version no later than 10 Feb 2012. That's a week and a half, which > should be enough for this active and vocal group, wot? Please do not > wait until the last minute, and especially do not wait until the > document goes to the IESG. You will be beaten with a rubber > truncheon. It looks good to me. The only nit I'd note is in 9. Per Section 4.4 of [RFC6449], a network service provider MAY use ARF data for automated forwarding of feedabck messages to the originating customer. This is a very important statement, IMHO, as it involves a number of those "abuse addresses in WHOIS records of the IP" that are mentioned elsewhere in the document. I think "network service provider" is clear enough (rfc6045-bis is changing "network provider" to "service provider", FWIW.) The nit is s/feedabck/feedback/, obviously. From msk@cloudmark.com Wed Feb 1 10:41:13 2012 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 1585B11E8079 for ; Wed, 1 Feb 2012 10:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LF0O1AMs21Lo for ; Wed, 1 Feb 2012 10:41:12 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0355011E8071 for ; Wed, 1 Feb 2012 10:41:12 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 1 Feb 2012 10:41:11 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 1 Feb 2012 10:41:11 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 1 Feb 2012 10:41:10 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was -07 Thread-Index: AczgzvM8oG6j9J7YS92Enkc+4Y2m7AAQHqQA Message-ID: References: <20120130193649.24837.53481.idtracker@ietfa.amsl.com> <4F283C32.7070206@tana.it> <4F291852.8020807@tana.it> In-Reply-To: <4F291852.8020807@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-dkim-reporting-08, was -07 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, 01 Feb 2012 18:41:13 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Wednesday, February 01, 2012 2:48 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was -0= 7 >=20 > >> BTW, why isn't the rs=3D string actionable even in the absence of ra= =3D? > > > > Good point; fixed. >=20 > Nice, thanks for this --and for the other fixes as well. Does this > change have to be addressed also in the last step of the reporting > algorithm? See below... The last step already does talk about including the "rs=3D" string, if ther= e was one. What does need correction though is step 8 which presumes "ra= =3D" is there. I'll tidy that up. > Steps 2-9 are quite precisely stated, so I'm not sure how obvious it is > what amount of latitude is left to programmers' common sense. An > alternative is to use regular text phrases to discuss the SHOULDs and > MAYs of generating a report, as well as the relative independence > between that and honoring rs=3D. The algorithm proper would then specify > what to do after those decisions are made. (Hey, numbering paragraphs > /is/ meaningful in this case.) We've used the "semantically equivalent" language in a few places without c= omplaint, most notably ADSP and I think DKIM as well. I think adding speci= fic implementation detail about possible alternate implementations will jus= t clutter the matter rather than improving it, so I'd prefer to leave it al= one. > >> 8.5. *Automatic Generation* > >> > >> The last paragraph, about out-of-band arrangements, seems to defy > >> this I-D's very purpose of automating reporting. Considering what > >> marf-as is going to say on unsolicited reports, I'd s/create/persist s= ending/. > > > > What this section is trying to say is that people should not implement > > systems that do this kind of reporting work by default. >=20 > Yes. In this sense, that paragraph is rowing in the opposite direction > than the rest of the I-D. (I understand "reporting of message > authentication failures in an on-demand fashion" as > I-set-record=3Dyou-send-report.) I don't agree. The I-D is meant to present the mechanisms for requesting a= nd providing these reports. That is, "If you're going to do this, here's h= ow we think you should go about it." There are some obvious concerns with = doing so across-the-board without any checking or thought to it, though one= certainly could do that. It seems very appropriate to me to call that out= in Security Considerations. > It is, since the paragraph talks about "these (or any) ARF reports". > And it is good to do so, IMHO. This I-D is not specifying blind-to- > witting transitions, and I'm not suggesting it should, but maybe it can > still suggest some details of such activity. I think to do so we would wander into the realm of speculation, not specifi= cation. I don't think that's a good idea for something that's asking for P= roposed Standard status as a protocol document. Perhaps it could as an app= licability statement, but that's not what we're doing here. > >> 8.6. *Reporting Multiple Incidents* > >> > >> To suspend report generation for some time after an RCPT rejection of > >> the reporting address might also provide for a safe approach. > > > > Since it's Security Considerations, none of this is normative. > > It's just a suggestion for handling large volumes of reports. >=20 > Yes, such specification should belong to some other I-D (reporting- > discovery? :-) If we're going to talk about handling of large report volumes, given our cu= rrent document set, the AS is the right place to do it. If you think that'= s important, now's the time to make such a proposal, before WGLC closes. > While that may be semantically correct, there is the practical problem > that 4xx reply codes are not reported timely. It is necessary to query > the mail queue in order to know whether there are outstanding temporary > failures. In case the boundary box where the report generator lives > does not send mail out directly, it is not practical to determine that > condition. >=20 > On the other hand, 5xx reply codes should cause the current message to > be discarded. On resuming reporting, new reports are transmitted, > rather than the queued flood initiators. However, in order to ensure > immediate notification of rejections in all cases, one would have to > use purposely configured variable envelope senders. >=20 > What do you think? I think if the advice that's been added about observing the behavior of the= report recipient as input to a throttling mechanism is actually impractica= l, we should remove it rather than expanding on it and complicating the doc= ument further. We risk confusing the reader. -MSK From internet-drafts@ietf.org Wed Feb 1 11:45:31 2012 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 E71FA11E80DE; Wed, 1 Feb 2012 11:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTVldYyxLjSp; Wed, 1 Feb 2012 11:45:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE0911E8071; Wed, 1 Feb 2012 11:45:16 -0800 (PST) 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.64p1 Message-ID: <20120201194516.19350.96923.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2012 11:45:16 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-spf-reporting-05.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, 01 Feb 2012 19:45:31 -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-05.txt Pages : 15 Date : 2012-02-01 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-05.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-05.txt From sklist@kitterman.com Wed Feb 1 11:47:05 2012 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 5607111E80D0 for ; Wed, 1 Feb 2012 11:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lepcy5Ls7VWA for ; Wed, 1 Feb 2012 11:47:04 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 77ABE11E80BA for ; Wed, 1 Feb 2012 11:47:04 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E94A420E40D0; Wed, 1 Feb 2012 14:47:03 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328125623; bh=l/xMeFyEqpNI1OqL+o82rUEAzF+my/Cf5Kbp9f643yo=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=CF/CGAhT2bfL4HXU+PjdJUPPLlNIFiDcYtU6ZGzQr9RX1aURzmXJDDN6I7qrj8zu5 CgG6paMjbeLewYbqEYSYhnOKX2QOLthwAPaP1CkULNz0T69Rzy7ggjQtm+V8yFUnrc U43jfkmzPMFH5hSp6N2vwLPfOH7dPk97T2sfa3Zw= Received: from scott-latitude-e6320.localnet (unknown [208.255.163.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id BB9AF20E4064; Wed, 1 Feb 2012 14:47:03 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 01 Feb 2012 14:47:02 -0500 Message-ID: <1982726.RCUBYWX0PF@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120201194516.19350.96923.idtracker@ietfa.amsl.com> References: <20120201194516.19350.96923.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-05.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, 01 Feb 2012 19:47:05 -0000 On Wednesday, February 01, 2012 11:45:16 AM internet-drafts@ietf.org wrote: > 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-05.txt > Pages : 15 > Date : 2012-02-01 Here's the changes in this revision: * Change ro= to rr= to match DKIM draft. * Fix stray reference to old r= modifier. * Add SPF result of None to rr=n (now covers neutral and none for completeness and to preserve RFC 4408 required alignment between Neutral and None). * Port changes from DKIM -08 to the SPF draft - Update rp= definition - Reworded section of ignoring other modifiers if ra= is absent - Added not generating failure reports for ARF messages - Added other rate limiting paragraph to automatic generation security consideration Scott K From sklist@kitterman.com Wed Feb 1 12:14:17 2012 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 7D8F511E80BE for ; Wed, 1 Feb 2012 12:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVJyRYkU4K18 for ; Wed, 1 Feb 2012 12:14:16 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CC52111E80BA for ; Wed, 1 Feb 2012 12:14:16 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6575C20E40D0; Wed, 1 Feb 2012 15:14:16 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328127256; bh=wyZN6jiuotx9ebtjVnW29ozjS21F8TttG8abXgegNAA=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=KBfXTnNWjffdqWyAISfL1fo3oBpOqzVjB9F7mA1T0Hzh7diTZQCAlv+MPi3yxB7C+ Njl6+Sx7oIKYHnrA2CrV3oR/TEEmUXJgjM7AxtUNe/Sf4F95Vd1Tl2SFm+qdWCodUX uX9PbaVo7u1KTzU0ln+0TCmY3KJG0OeaFQ/SXIc0= Received: from scott-latitude-e6320.localnet (unknown [208.255.163.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0CAA420E4064; Wed, 1 Feb 2012 15:14:15 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 01 Feb 2012 15:14:13 -0500 Message-ID: <6993547.EjUSn6dgaq@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 01 Feb 2012 20:14:17 -0000 On Tuesday, January 31, 2012 04:23:33 PM Barry Leiba wrote: > I am re-posting this without the extra recipients; please reply to > THIS message, and NOT to that other one. We can discuss later who, > exactly, should get the truncheon treatment here....... > --- > > Here begins a last call for the MARF working group on the subject > document, detailed below. Please make any comments you have on this > version no later than 10 Feb 2012. That's a week and a half, which > should be enough for this active and vocal group, wot? Please do not > wait until the last minute, and especially do not wait until the > document goes to the IESG. You will be beaten with a rubber > truncheon. It looks good to me. Just a couple of comments: 3. The Mailbox Provider SHOULD send reports to relevant parties who have requested to receive such reports. The reports MUST be formatted per [RFC5965], and transmitted as an email message ([RFC5322]), typically using SMTP ([RFC5321]). The process whereby such parties may request the reports is discussed in Section 3.5 of [RFC6449]. Although I understad the MUST here in context, it could be misread out of context by people trying to insist on ARF. Could we have some kind of "To implement the recommendations of this draft, the reports MUST ..." or similar? 12. Although [RFC6449] suggests that replying to feedback is not useful, in the case of receipt of ARF reports where no feedback arrangement has been established, a reply might be desirable to indicate that the complaint will result in action, heading off more severe filtering from the report generator. Thus, a report generator sending unsolicited reports SHOULD ensure that a reply to such a report can be received. Where an unsolicited report results in the establishment of contact with a responsible and responsive party, this can be saved for future complaint handling and possible establishment of a formal (solicited) feedback arrangement. See Section 3.5 of [RFC6449] for a discussion of establishment of feedback arrangements. The SHOULD seems strong here. While I agree it's a nice idea, the odds of this actually happening are vanishingly small in my opinion. Something without a RFC 2119 keyword would be better here. Scott K From steve@wordtothewise.com Wed Feb 1 12:21:41 2012 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 3488411E80CC for ; Wed, 1 Feb 2012 12:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHGl8l3aiHze for ; Wed, 1 Feb 2012 12:21:40 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 4D51D11E80BA for ; Wed, 1 Feb 2012 12:21:39 -0800 (PST) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id 60E7E2DED3 for ; Wed, 1 Feb 2012 12:21:32 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Steve Atkins In-Reply-To: <6993547.EjUSn6dgaq@scott-latitude-e6320> Date: Wed, 1 Feb 2012 12:21:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4DEC4C4E-7F56-44DE-B0D6-6900120D9263@wordtothewise.com> References: <6993547.EjUSn6dgaq@scott-latitude-e6320> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1251.1) Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 01 Feb 2012 20:21:41 -0000 On Feb 1, 2012, at 12:14 PM, Scott Kitterman wrote: > On Tuesday, January 31, 2012 04:23:33 PM Barry Leiba wrote: >> I am re-posting this without the extra recipients; please reply to >> THIS message, and NOT to that other one. We can discuss later who, >> exactly, should get the truncheon treatment here....... >> --- >>=20 >> Here begins a last call for the MARF working group on the subject >> document, detailed below. Please make any comments you have on this >> version no later than 10 Feb 2012. That's a week and a half, which >> should be enough for this active and vocal group, wot? Please do not >> wait until the last minute, and especially do not wait until the >> document goes to the IESG. You will be beaten with a rubber >> truncheon. >=20 > It looks good to me. Just a couple of comments: >=20 > 3. The Mailbox Provider SHOULD send reports to relevant parties = who > have requested to receive such reports. The reports MUST be > formatted per [RFC5965], and transmitted as an email message > ([RFC5322]), typically using SMTP ([RFC5321]). The process > whereby such parties may request the reports is discussed in > Section 3.5 of [RFC6449]. >=20 > Although I understad the MUST here in context, it could be misread out = of=20 > context by people trying to insist on ARF. Could we have some kind of = "To=20 > implement the recommendations of this draft, the reports MUST ..." or = similar? >=20 > 12. Although [RFC6449] suggests that replying to feedback is not > useful, in the case of receipt of ARF reports where no feedback > arrangement has been established, a reply might be desirable to > indicate that the complaint will result in action, heading off > more severe filtering from the report generator. Thus, a = report > generator sending unsolicited reports SHOULD ensure that a = reply > to such a report can be received. Where an unsolicited report > results in the establishment of contact with a responsible and > responsive party, this can be saved for future complaint > handling and possible establishment of a formal (solicited) > feedback arrangement. See Section 3.5 of [RFC6449] for a > discussion of establishment of feedback arrangements. >=20 > The SHOULD seems strong here. While I agree it's a nice idea, the = odds of=20 > this actually happening are vanishingly small in my opinion. = Something=20 > without a RFC 2119 keyword would be better here. Unsolicited reports sent from an undeliverable address aren't terribly useful, as you can't ask the sender for additional context (data that's already there for FBLs). They're also more likely to be discarded or blocked. I think the SHOULD is a reasonable level of strength (though I wouldn't object to MUST). Cheers, Steve From msk@cloudmark.com Wed Feb 1 12:27:31 2012 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 4F7D011E80BA for ; Wed, 1 Feb 2012 12:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtRZnGePSq42 for ; Wed, 1 Feb 2012 12:27:30 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id E1B5711E8094 for ; Wed, 1 Feb 2012 12:27:30 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 1 Feb 2012 12:27:30 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 1 Feb 2012 12:27:29 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 1 Feb 2012 12:27:28 -0800 Thread-Topic: [marf] Working Group Last Call on draft-ietf-marf-as-05 Thread-Index: AczhHixKQRy2Rtp7RTamTtTMORL5rAAAbBVA Message-ID: References: <6993547.EjUSn6dgaq@scott-latitude-e6320> In-Reply-To: <6993547.EjUSn6dgaq@scott-latitude-e6320> 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] Working Group Last Call on draft-ietf-marf-as-05 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, 01 Feb 2012 20:27:31 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Wednesday, February 01, 2012 12:14 PM > To: marf@ietf.org > Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 >=20 > It looks good to me. Just a couple of comments: >=20 > 3. The Mailbox Provider SHOULD send reports to relevant parties wh= o > have requested to receive such reports. The reports MUST be > formatted per [RFC5965], and transmitted as an email message > ([RFC5322]), typically using SMTP ([RFC5321]). The process > whereby such parties may request the reports is discussed in > Section 3.5 of [RFC6449]. >=20 > Although I understad the MUST here in context, it could be misread out > of context by people trying to insist on ARF. Could we have some kind > of "To implement the recommendations of this draft, the reports MUST > ..." or similar? Seems reasonable to me. -MSK From johnl@iecc.com Wed Feb 1 12:29:26 2012 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 61E2B11E8094 for ; Wed, 1 Feb 2012 12:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.306 X-Spam-Level: X-Spam-Status: No, score=-109.306 tagged_above=-999 required=5 tests=[AWL=1.893, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GX-988gp9pji for ; Wed, 1 Feb 2012 12:29:25 -0800 (PST) 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 5456C11E8085 for ; Wed, 1 Feb 2012 12:29:25 -0800 (PST) Received: (qmail 21023 invoked from network); 1 Feb 2012 20:29:23 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 1 Feb 2012 20:29:23 -0000 Date: 1 Feb 2012 20:29:01 -0000 Message-ID: <20120201202901.18986.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <6993547.EjUSn6dgaq@scott-latitude-e6320> 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-as-05 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, 01 Feb 2012 20:29:26 -0000 > 3. The Mailbox Provider SHOULD send reports to relevant parties who > have requested to receive such reports. The reports MUST be > formatted per [RFC5965], and transmitted as an email message > ([RFC5322]), typically using SMTP ([RFC5321]). The process > whereby such parties may request the reports is discussed in > Section 3.5 of [RFC6449]. > >Although I understad the MUST here in context, it could be misread out of >context by people trying to insist on ARF. Could we have some kind of "To >implement the recommendations of this draft, the reports MUST ..." or similar? That's implicit in any standard. The 2119 language is relative to implementing what the document is about. > more severe filtering from the report generator. Thus, a report > generator sending unsolicited reports SHOULD ensure that a reply > to such a report can be received. >The SHOULD seems strong here. While I agree it's a nice idea, the odds of >this actually happening are vanishingly small in my opinion. Something >without a RFC 2119 keyword would be better here. I get dozens of responses to ARF reports every day, many from actual people. R's, John From sklist@kitterman.com Wed Feb 1 12:29:32 2012 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 0F24C11E8085 for ; Wed, 1 Feb 2012 12:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJHrGMudxpTc for ; Wed, 1 Feb 2012 12:29:31 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 1944611E80E0 for ; Wed, 1 Feb 2012 12:29:31 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 51CF1D0408B; Wed, 1 Feb 2012 14:29:30 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328128170; bh=AdQjjB6gh+mTJIAIuy/l9tZtzPgF+r76QXdPDqay0aE=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=Wt8+w4zRf0DOMKqcF5gFGXYwUBNmfzryXCO2IVBh8vmUhfs29ZiM9ClugFlCE0HO7 V4rqP4YZo/5SG0cM8K4acjFXdxsjWutSEZXjnMLrQlF5100H8gO7o56x01kZAN//5v H5urKfhBcJP2ncSgY4tLpG3TwuGb3G5OHTyb4kCc= Received: from 1.sub-97-129-202.myvzw.com (1.sub-97-129-202.myvzw.com [97.129.202.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id AB733D04025; Wed, 1 Feb 2012 14:29:29 -0600 (CST) References: <6993547.EjUSn6dgaq@scott-latitude-e6320> <4DEC4C4E-7F56-44DE-B0D6-6900120D9263@wordtothewise.com> User-Agent: K-9 Mail for Android In-Reply-To: <4DEC4C4E-7F56-44DE-B0D6-6900120D9263@wordtothewise.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 01 Feb 2012 15:29:36 -0500 To: Message Abuse Report Format working group Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 01 Feb 2012 20:29:32 -0000 Steve Atkins wrote: > >On Feb 1, 2012, at 12:14 PM, Scott Kitterman wrote: > >> On Tuesday, January 31, 2012 04:23:33 PM Barry Leiba wrote: >>> I am re-posting this without the extra recipients; please reply to >>> THIS message, and NOT to that other one. We can discuss later who, >>> exactly, should get the truncheon treatment here....... >>> --- >>> >>> Here begins a last call for the MARF working group on the subject >>> document, detailed below. Please make any comments you have on this >>> version no later than 10 Feb 2012. That's a week and a half, which >>> should be enough for this active and vocal group, wot? Please do >not >>> wait until the last minute, and especially do not wait until the >>> document goes to the IESG. You will be beaten with a rubber >>> truncheon. >> >> It looks good to me. Just a couple of comments: >> >> 3. The Mailbox Provider SHOULD send reports to relevant parties >who >> have requested to receive such reports. The reports MUST be >> formatted per [RFC5965], and transmitted as an email message >> ([RFC5322]), typically using SMTP ([RFC5321]). The process >> whereby such parties may request the reports is discussed in >> Section 3.5 of [RFC6449]. >> >> Although I understad the MUST here in context, it could be misread >out of >> context by people trying to insist on ARF. Could we have some kind >of "To >> implement the recommendations of this draft, the reports MUST ..." or >similar? >> >> 12. Although [RFC6449] suggests that replying to feedback is not >> useful, in the case of receipt of ARF reports where no >feedback >> arrangement has been established, a reply might be desirable >to >> indicate that the complaint will result in action, heading off >> more severe filtering from the report generator. Thus, a >report >> generator sending unsolicited reports SHOULD ensure that a >reply >> to such a report can be received. Where an unsolicited report >> results in the establishment of contact with a responsible and >> responsive party, this can be saved for future complaint >> handling and possible establishment of a formal (solicited) >> feedback arrangement. See Section 3.5 of [RFC6449] for a >> discussion of establishment of feedback arrangements. >> >> The SHOULD seems strong here. While I agree it's a nice idea, the >odds of >> this actually happening are vanishingly small in my opinion. >Something >> without a RFC 2119 keyword would be better here. > >Unsolicited reports sent from an undeliverable address aren't terribly >useful, as you can't ask the sender for additional context (data that's >already there for FBLs). They're also more likely to be discarded or >blocked. > >I think the SHOULD is a reasonable level of strength (though I >wouldn't object to MUST). That's a much better rationale. The draft should leave the SHOULD and add that. Scott K From shmuel+gen@patriot.net Wed Feb 1 16:57:59 2012 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 58E4A21F87E2 for ; Wed, 1 Feb 2012 16:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hn5mA7tatZMG for ; Wed, 1 Feb 2012 16:57:58 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 539A921F87E0 for ; Wed, 1 Feb 2012 16:57:58 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.125]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id C7D0BF58083 for ; Wed, 1 Feb 2012 19:43:33 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Wed, 01 Feb 2012 08:30:26 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120202004334.C7D0BF58083@smtp.patriot.net> Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 02 Feb 2012 00:57:59 -0000 In , on 01/31/2012 at 04:23 PM, Barry Leiba said: >Here begins a last call for the MARF working group on the subject >document, detailed below. A minor point: 3. MUAs SHOULD NOT generate abuse reports directly to entities found in the message or by queries to WHOIS or other heuristic means. Rather, the MUA should signal, by some means, the mailbox provider to which it connects to generate such a report. What about an MUA that prepares an abuse report and requests editing and submission from the user? MUA's that generate abuse reports for manual submission by the user SHOULD include guidance on where to submit them and a warning about possible forgeries. -- 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 johnl@iecc.com Wed Feb 1 18:16:41 2012 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 2E03C11E8137 for ; Wed, 1 Feb 2012 18:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.339 X-Spam-Level: X-Spam-Status: No, score=-109.339 tagged_above=-999 required=5 tests=[AWL=1.860, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MPBLtzUQIqZ for ; Wed, 1 Feb 2012 18:16:39 -0800 (PST) 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 B1E1D11E8114 for ; Wed, 1 Feb 2012 18:16:39 -0800 (PST) Received: (qmail 13603 invoked from network); 2 Feb 2012 02:16:38 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Feb 2012 02:16:38 -0000 Date: 2 Feb 2012 02:16:16 -0000 Message-ID: <20120202021616.31482.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <20120202004334.C7D0BF58083@smtp.patriot.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 02 Feb 2012 02:16:41 -0000 > 3. MUAs SHOULD NOT generate abuse reports directly to entities > found in the message or by queries to WHOIS or other heuristic > means. Rather, the MUA should signal, by some means, the > mailbox provider to which it connects to generate such a report. >What about an MUA that prepares an abuse report and requests editing >and submission from the user? Look at RFC 2119. SHOULD NOT more or less means don't do this unless you're sure you understand what you're doing. Given how few mail users understand header parsing and mail routing, SHOULD NOT seems right to me. If you, one of the few users familiar with the details of SMTP mail, want to do it, go ahead. For the bazillion users of some random consumer mail system, let their mail system admins handle it. R's, John From msk@cloudmark.com Wed Feb 1 19:51:16 2012 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 E535F11E8087 for ; Wed, 1 Feb 2012 19:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kVblRJcH4MH for ; Wed, 1 Feb 2012 19:51:16 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6312811E8083 for ; Wed, 1 Feb 2012 19:51:16 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 1 Feb 2012 19:51:15 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 1 Feb 2012 19:51:15 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Wed, 1 Feb 2012 19:51:18 -0800 Thread-Topic: [marf] Working Group Last Call on draft-ietf-marf-as-05 Thread-Index: AczhRboXyW9UJpd3Tweb1qnbLRUqygAGBlrA Message-ID: References: <20120202004334.C7D0BF58083@smtp.patriot.net> In-Reply-To: <20120202004334.C7D0BF58083@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 02 Feb 2012 03:51:17 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Wednesday, February 01, 2012 5:30 AM > To: marf@ietf.org > Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 >=20 > What about an MUA that prepares an abuse report and requests editing > and submission from the user? Does such a thing exist? Would it make sense to build one? I don't want us to go down the road of adding text for every conceivable id= ea. We should present basic advice, and stop. From steve@wordtothewise.com Wed Feb 1 20:05:44 2012 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 B343221F884E for ; Wed, 1 Feb 2012 20:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buEQor-NAJQ2 for ; Wed, 1 Feb 2012 20:05:44 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id D8C8C21F884D for ; Wed, 1 Feb 2012 20:05:36 -0800 (PST) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id 6FB9C2EB3A for ; Wed, 1 Feb 2012 20:05:36 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Steve Atkins In-Reply-To: Date: Wed, 1 Feb 2012 20:05:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7DEB0B04-2161-4FA4-8B86-E004CCB3085B@wordtothewise.com> References: <20120202004334.C7D0BF58083@smtp.patriot.net> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1251.1) Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 02 Feb 2012 04:05:44 -0000 On Feb 1, 2012, at 7:51 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of Shmuel Metz >> Sent: Wednesday, February 01, 2012 5:30 AM >> To: marf@ietf.org >> Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 >>=20 >> What about an MUA that prepares an abuse report and requests editing >> and submission from the user? >=20 > Does such a thing exist? Kinda, yes. It's not been in much use for years, and long predates ARF, = but I still occasionally hear from an abuse desk "Hey! We received a = report! Blast from the past!". > Would it make sense to build one? Probably, yes - while on the modern net it would probably make much more = sense to centralize most the processing and decision making, having the = report be emitted from the MUA wouldn't be a bad decision. >=20 > I don't want us to go down the road of adding text for every = conceivable idea. We should present basic advice, and stop. I think anyone developing an MUA to do that sort of thing would either = deeply understand this document and read it from an appropriate = perspective, or not understand it and need to be restrained from doing = anything along these lines. So I think we're fine as we are. Cheers, Steve From msk@cloudmark.com Wed Feb 1 23:30:46 2012 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 6F3C721F8AB4 for ; Wed, 1 Feb 2012 23:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAozIKD3td+l for ; Wed, 1 Feb 2012 23:30:46 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 011C521F8AB2 for ; Wed, 1 Feb 2012 23:30:45 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 1 Feb 2012 23:30:45 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 1 Feb 2012 23:30:45 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Wed, 1 Feb 2012 23:30:49 -0800 Thread-Topic: [marf] Working Group Last Call on draft-ietf-marf-as-05 Thread-Index: AczhIDWESJpruhq2Sauue5+5X/cjCQAXEc2g Message-ID: References: <6993547.EjUSn6dgaq@scott-latitude-e6320> <4DEC4C4E-7F56-44DE-B0D6-6900120D9263@wordtothewise.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 02 Feb 2012 07:30:46 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Wednesday, February 01, 2012 12:30 PM > To: Message Abuse Report Format working group > Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 >=20 > >Unsolicited reports sent from an undeliverable address aren't terribly > >useful, as you can't ask the sender for additional context (data that's > >already there for FBLs). They're also more likely to be discarded or > >blocked. > > > >I think the SHOULD is a reasonable level of strength (though I wouldn't > >object to MUST). >=20 > That's a much better rationale. The draft should leave the SHOULD and > add that. Done in -06. I take it you are both otherwise happy with the AS draft as-is? -MSK From vesely@tana.it Thu Feb 2 01:10:48 2012 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 AE8E821F8AE9 for ; Thu, 2 Feb 2012 01:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.632 X-Spam-Level: X-Spam-Status: No, score=-4.632 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHOFpweoHwMp for ; Thu, 2 Feb 2012 01:10:47 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6B04021F8AAC for ; Thu, 2 Feb 2012 01:10:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328173824; bh=dMiB2b3ulISnxfqKWv3MoepF3xd+RZy3W3FvnN6KXwo=; l=1302; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=OTTgEntTcMDexZ4OsafEjRUtbtnh9l+AR/JxQ8HJSvAwO82BZukNpXXOdL5fDpZwt KX1T9eOILvXZUtOqCyjQ1x6jhIgahMnjHVypXKtee69yKoJGJSXCFkazl1ekQkPuFl RdWqmq6esq1LMHsDW/XEr/fEIFO3JIGckLv9VhSc= 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, 02 Feb 2012 10:10:24 +0100 id 00000000005DC039.000000004F2A5300.000058D2 Message-ID: <4F2A52F5.80004@tana.it> Date: Thu, 02 Feb 2012 10:10:13 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120201202901.18986.qmail@joyce.lan> In-Reply-To: <20120201202901.18986.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 02 Feb 2012 09:10:49 -0000 On 01/Feb/12 21:29, John Levine wrote: >> 3. The Mailbox Provider SHOULD send reports to relevant parties who >> have requested to receive such reports. The reports MUST be >> formatted per [RFC5965], and transmitted as an email message >> ([RFC5322]), typically using SMTP ([RFC5321]). The process >> whereby such parties may request the reports is discussed in >> Section 3.5 of [RFC6449]. >> >> Although I understad the MUST here in context, it could be >> misread out of context by people trying to insist on ARF. Could >> we have some kind of "To implement the recommendations of this >> draft, the reports MUST ..." or similar? > > That's implicit in any standard. The 2119 language is relative to > implementing what the document is about. In addition, the context where that snippet comes from is about a closed transmission whose details were privately agreed upon by the participating parties. That is, not only requiring ARF makes sense, but also attaching definite semantics to specific fields of it. The generic recommendation of not insisting on ARF is in bullet 10 of Section 8: 10. Published abuse mailbox addresses SHOULD NOT reject messages not in the ARF format, as generation of ARF messages can occasionally be unavailable or not applicable. [...] From sklist@kitterman.com Thu Feb 2 03:47:36 2012 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 873CF21F877F for ; Thu, 2 Feb 2012 03:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNs+e4zTqgAA for ; Thu, 2 Feb 2012 03:47:36 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id E462421F877E for ; Thu, 2 Feb 2012 03:47:35 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 51F41D0408B; Thu, 2 Feb 2012 05:47:35 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328183255; bh=0svIrdB11vnWLMcl73gq+flKttX2tTqbOdlfMzSdsvs=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=GzStK1ESlyPR3vAnrmDRAVj2FnKzy8bMM2qrAIQwdnR4tXZNYBLIWsgI0I+y9dDPI 8Qoii4IiZf2FWuGPFegwAmHvghWLKB8/umTG/DvmZx+libS1qdCuaynFUIvkAcvenp WMbzQIDys28PKJIfzoZNiyMJUc1GVTj1VkoUl9B0= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 0FFFFD0400D; Thu, 2 Feb 2012 05:47:34 -0600 (CST) References: <6993547.EjUSn6dgaq@scott-latitude-e6320> <4DEC4C4E-7F56-44DE-B0D6-6900120D9263@wordtothewise.com> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 02 Feb 2012 06:47:45 -0500 To: Message Abuse Report Format working group Message-ID: <733f9cf0-5358-4315-91ae-c43f521038ba@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 02 Feb 2012 11:47:36 -0000 "Murray S. Kucherawy" wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf >Of Scott Kitterman >> Sent: Wednesday, February 01, 2012 12:30 PM >> To: Message Abuse Report Format working group >> Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 >> >> >Unsolicited reports sent from an undeliverable address aren't >terribly >> >useful, as you can't ask the sender for additional context (data >that's >> >already there for FBLs). They're also more likely to be discarded or >> >blocked. >> > >> >I think the SHOULD is a reasonable level of strength (though I >wouldn't >> >object to MUST). >> >> That's a much better rationale. The draft should leave the SHOULD >and >> add that. > >Done in -06. > >I take it you are both otherwise happy with the AS draft as-is? Yes. Scott K From vesely@tana.it Thu Feb 2 04:16:26 2012 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 D2F9A21F8AB5 for ; Thu, 2 Feb 2012 04:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.633 X-Spam-Level: X-Spam-Status: No, score=-4.633 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuE3sO-O5Sao for ; Thu, 2 Feb 2012 04:16:25 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7675D21F8AB4 for ; Thu, 2 Feb 2012 04:16:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328184984; bh=kB5/oIECBx5PeuKKYpv+t3DpeQl4rGXE6qX0nBIB2JM=; l=6178; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=cWtCbvuB6gzLZyGgBxzbmc9qjxXS5KK87UzQ1apdgXhrTOQJWr4XLraxRGUD0eDA+ faeAUSIdJzmj8oNee1wSIF4KCi72VIdha7o9deobVrrgzjKInJSNo6qHJdkoQj+vHC uedY+8jhFaVM648exMJsyGWx4/AIYYUYqtbEvO1Y= 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, 02 Feb 2012 13:16:24 +0100 id 00000000005DC039.000000004F2A7E98.000004DD Message-ID: <4F2A7E8F.9010901@tana.it> Date: Thu, 02 Feb 2012 13:16:15 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120130193649.24837.53481.idtracker@ietfa.amsl.com> <4F283C32.7070206@tana.it> <4F291852.8020807@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-dkim-reporting-08, was -07 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, 02 Feb 2012 12:16:26 -0000 On 01/Feb/12 19:41, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely > >>>> 8.5. *Automatic Generation* >>> >>> What this section is trying to say is that people should not implement >>> systems that do this kind of reporting work by default. >> >> (I understand "reporting of message authentication failures in an >> on-demand fashion" as I-set-record=you-send-report.) > > I don't agree. The I-D is meant to present the mechanisms for > requesting and providing these reports. That is, "If you're going > to do this, here's how we think you should go about it." There are > some obvious concerns with doing so across-the-board without any > checking or thought to it, though one certainly could do that. What's that "could"?! There's nothing I can conceivably do besides setting the RR properly. If that is not enough for getting reports from whoever will happen to get a broken signature, then this I-D is completely useless --I can well receive occasional failure notices from friends based on authfailure-report only. Differently from abuse reports, authentication failures may affect personal messages and confidential content. Concern over divulging that is due. If I were to report to unknown people, I would probably want to redact most header fields and omit the body. > It seems very appropriate to me to call that out in Security > Considerations. Yes. >> This I-D is not specifying blind-to- witting transitions, and I'm >> not suggesting it should, but maybe it can still suggest some >> details of such activity. > > I think to do so we would wander into the realm of speculation, not > specification. Let me describe a possible case, just to make sure we're talking about the same thing: Alice writes to Bob, DKIM-Signature breaks, ISP-B (Bob's ISP) start reporting to ISP-A. ISP-A receive the first reports, check that they are good and confirm, possibly on http://postmaster.ISP-B.example/acknowledge?key=ISP-A_beenhere, that they would like to continue receiving them. That doesn't lower the amount of redaction applied to reports. Yet, ISP-A can collect reports and form a statistic picture of how their configuration goes. Useful work already, isn't it? After some months, ISP-A write to ISP-B to arrange for a debugging session: Hi ISP-B, I have some statistical evidence that messages from our user Alice to your user Bob tend to break much more often than normal. Would it be possible to check that more closely? Alice says she can resend the messages listed below (see attachment). Bob agrees, but please check his consent for your records. Regards ISP-A --- (attachment omitted) ISP-B answer affirmatively and manually forward unredacted reports of the relevant failures to ISP-A. ISP-A find the bug and they lived happily ever after. > I don't think that's a good idea for something that's asking for > Proposed Standard status as a protocol document. The idea is just to note that there are data items about ISP-A, such as acknowledgment, contacts, responsiveness, and involvement, that is worth being stored on a per-domain database. We don't need to say that such data may turn out to be useful for looking into spam (reporting) issues, as that is indeed speculation. >>>> 8.6. *Reporting Multiple Incidents* >>>> >>>> To suspend report generation for some time after an RCPT rejection of >>>> the reporting address >>> >>> It's just a suggestion for handling large volumes of reports. >> >> Yes, such specification should belong to some other I-D (reporting- >> discovery? :-) > > If we're going to talk about handling of large report volumes, > given our current document set, the AS is the right place to do it. > If you think that's important, now's the time to make such a > proposal, before WGLC closes. Both dkim-reporting and spf-reporting have a section on "Envelope Sender Selection". Reporting-discovery would need one too. The question of flow control (see below) is a related problem, also common to all those specs. I agree it is good to factor them. Are you saying the AS is the right place for both flow control and loop avoidance? What do everybody else think? >> While [temporary failure] may be semantically correct, there is >> the practical problem that 4xx reply codes are not reported >> timely. It is necessary to query the mail queue in order to know >> whether there are outstanding temporary failures. In case the >> boundary box where the report generator lives does not send mail >> out directly, it is not practical to determine that condition. >> >> On the other hand, 5xx reply codes should cause the current >> message to be discarded. On resuming reporting, new reports are >> transmitted, rather than the queued flood initiators. However, >> in order to ensure immediate notification of rejections in all >> cases, one would have to use purposely configured variable >> envelope senders. >> >> What do you think? > > I think if the advice that's been added about observing the > behavior of the report recipient as input to a throttling mechanism > is actually impractical, we should remove it rather than expanding > on it and complicating the document further. We risk confusing the > reader. Hm... I don't think that a non-empty envelope sender may cause reporting loops, as reporting does not actually use it. Hence, we could use it for flow control. For some unsorted details, we may recommend 552 after RCPT for momentarily stop reporting, but had better not rely on it. Rather, I propose we encourage getting acknowledgments and recording them along with per-domain reporting history. Report generators should use VERP, and suspend reporting to rejecting domains for an amount of time inversely proportional to the confidence, e.g.: 0.5T for an acknowledged domain, T for a first-time first-failure, 2T, 4T, ... , one year for dorks. where T is the TTL of the relevant _report's RR if retrieved with the AA flag, or some other time constant either agreed with the domain or set by default. From johnl@iecc.com Thu Feb 2 07:37:33 2012 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 7E4DF21F84D9 for ; Thu, 2 Feb 2012 07:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.371 X-Spam-Level: X-Spam-Status: No, score=-109.371 tagged_above=-999 required=5 tests=[AWL=1.828, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK4FdlFI8Jaq for ; Thu, 2 Feb 2012 07:37:33 -0800 (PST) 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 166A921F84D7 for ; Thu, 2 Feb 2012 07:37:31 -0800 (PST) Received: (qmail 49257 invoked from network); 2 Feb 2012 15:37:27 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Feb 2012 15:37:27 -0000 Date: 2 Feb 2012 15:37:04 -0000 Message-ID: <20120202153704.67577.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-as-05 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, 02 Feb 2012 15:37:33 -0000 >Done in -06. > >I take it you are both otherwise happy with the AS draft as-is? Oh, I'm sure we'll find other nits to complain about. As an editorial suggestion, I'd suggest changing the numbered lists in sections 6-8 back to plain paragraphs since they do not describe sequences of things to do in order. The numbers have been handy during the revision process to identify what we're arguing about, though. R's, John From msk@cloudmark.com Thu Feb 2 10:16:18 2012 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 6DDF221F8628 for ; Thu, 2 Feb 2012 10:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mg7YXxV8cnZr for ; Thu, 2 Feb 2012 10:16:17 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 60B1B21F8627 for ; Thu, 2 Feb 2012 10:16:17 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 2 Feb 2012 10:16:16 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 2 Feb 2012 10:16:16 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 2 Feb 2012 10:16:15 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was -07 Thread-Index: AczhpIEUpejNdMGXSJmCnzBSiMxu1QALxgdg Message-ID: References: <20120130193649.24837.53481.idtracker@ietfa.amsl.com> <4F283C32.7070206@tana.it> <4F291852.8020807@tana.it> <4F2A7E8F.9010901@tana.it> In-Reply-To: <4F2A7E8F.9010901@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-dkim-reporting-08, was -07 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, 02 Feb 2012 18:16:18 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Thursday, February 02, 2012 4:16 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was-07 >=20 > > I don't agree. The I-D is meant to present the mechanisms for > > requesting and providing these reports. That is, "If you're going to > > do this, here's how we think you should go about it." There are some > > obvious concerns with doing so across-the-board without any checking > > or thought to it, though one certainly could do that. >=20 > What's that "could"?! There's nothing I can conceivably do besides > setting the RR properly. If that is not enough for getting reports > from whoever will happen to get a broken signature, then this I-D is > completely useless --I can well receive occasional failure notices from > friends based on authfailure-report only. I think we're talking past each other here. What this draft presents is a = method that amounts to a two-way handshake between someone that wants repor= ts about DKIM failures and someone willing to generate them. You need to c= onsider both sides of that equation. For report generators in particular, = simply turning this on without giving any thought to the potential for crea= ting a mail storm is possibly a bad idea, which means we should provide app= ropriate cautions. For senders/signers, you need to be aware that requesti= ng reports might mean you get (legitimately) mailbombed. That's what Secti= ons 8.5 and 8.6 try to point out. > Differently from abuse reports, authentication failures may affect > personal messages and confidential content. Concern over divulging > that is due. If I were to report to unknown people, I would probably > want to redact most header fields and omit the body. But that's a risk in any ARF context, isn't it? I don't see why it's neces= sary to call it out here (or, presumably, in spf-reporting). It's called o= ut appropriately in the authfailure-report draft (Section 3.1 at least), wh= ich this one normatively references. > >> This I-D is not specifying blind-to- witting transitions, and I'm not > >> suggesting it should, but maybe it can still suggest some details of > >> such activity. > > > > I think to do so we would wander into the realm of speculation, not > > specification. >=20 > Let me describe a possible case, just to make sure we're talking about > the same thing: >=20 > Alice writes to Bob, DKIM-Signature breaks, ISP-B (Bob's ISP) start > reporting to ISP-A. ISP-A receive the first reports, check that they > are good and confirm, possibly on http://postmaster.ISP- > B.example/acknowledge?key=3DISP-A_beenhere, that they would like to > continue receiving them. That doesn't lower the amount of redaction > applied to reports. Yet, ISP-A can collect reports and form a > statistic picture of how their configuration goes. > Useful work already, isn't it? Sure, but I think if you take the DKIM-specific aspect out, you're talking = about a generic feedback loop scenario. And that means it's more appropria= te for the applicability statement draft. > > I don't think that's a good idea for something that's asking for > > Proposed Standard status as a protocol document. >=20 > The idea is just to note that there are data items about ISP-A, such as > acknowledgment, contacts, responsiveness, and involvement, that is > worth being stored on a per-domain database. We don't need to say that > such data may turn out to be useful for looking into spam > (reporting) issues, as that is indeed speculation. But that isn't specific to DKIM reporting, so I don't think that belongs he= re. > Are you saying the AS is the right place for both flow control and loop > avoidance? Yes. That draft is now in WGLC, so if you want to make a pitch to add text= to that document, now's the time. > What do everybody else think? That's a fine question. I suggest summarizing the proposed change in anoth= er thread. > > I think if the advice that's been added about observing the behavior > > of the report recipient as input to a throttling mechanism is actually > > impractical, we should remove it rather than expanding on it and > > complicating the document further. We risk confusing the reader. >=20 > Hm... I don't think that a non-empty envelope sender may cause > reporting loops, as reporting does not actually use it. Hence, we > could use it for flow control. Actually anything that isn't the empty envelope sender could cause a forwar= ding loop, modulo normative guidance to the contrary. Section 6 covers thi= s. > For some unsorted details, we may recommend 552 after RCPT for > momentarily stop reporting, but had better not rely on it. Rather, I > propose we encourage getting acknowledgments and recording them along > with per-domain reporting history. Report generators should use VERP, > and suspend reporting to rejecting domains for an amount of time > inversely proportional to the confidence, e.g.: >=20 > 0.5T for an acknowledged domain, > T for a first-time first-failure, > 2T, > 4T, > ... , > one year for dorks. >=20 > where T is the TTL of the relevant _report's RR if retrieved with the > AA flag, or some other time constant either agreed with the domain or > set by default. And you think this would improve Section 8.6 rather than complicating it? = Personally, I'm satisfied that the last paragraph of what we have in that s= ection is adequate to introduce the idea. Developing and recommending a de= tailed tracking system design seems like overkill here. If someone wants t= o do such a thing, it would certainly be valid, but I think suggesting that= such a thing might be necessary could become a barrier to adoption. -MSK From steve@wordtothewise.com Thu Feb 2 10:32:44 2012 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 B7B7A21F8552 for ; Thu, 2 Feb 2012 10:32:44 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoPJ0xCdFl91 for ; Thu, 2 Feb 2012 10:32:44 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 8F14121F854A for ; Thu, 2 Feb 2012 10:32:38 -0800 (PST) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id 3A0EA2EB3C for ; Thu, 2 Feb 2012 10:32:38 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Steve Atkins In-Reply-To: Date: Thu, 2 Feb 2012 10:32:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6993547.EjUSn6dgaq@scott-latitude-e6320> <4DEC4C4E-7F56-44DE-B0D6-6900120D9263@wordtothewise.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1251.1) Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 02 Feb 2012 18:32:44 -0000 On Feb 1, 2012, at 11:30 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of Scott Kitterman >> Sent: Wednesday, February 01, 2012 12:30 PM >> To: Message Abuse Report Format working group >> Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 >>=20 >>> Unsolicited reports sent from an undeliverable address aren't = terribly >>> useful, as you can't ask the sender for additional context (data = that's >>> already there for FBLs). They're also more likely to be discarded or >>> blocked. >>>=20 >>> I think the SHOULD is a reasonable level of strength (though I = wouldn't >>> object to MUST). >>=20 >> That's a much better rationale. The draft should leave the SHOULD = and >> add that. >=20 > Done in -06. >=20 > I take it you are both otherwise happy with the AS draft as-is? Not entirely. I think that encouraging people to send unsolicited, = non-human-readable email to email addresses harvested from domain or IP registration = addresses, or to role accounts intended to receive human readable email, isn't a = good idea and we might want to spend more space on the problems with that. The discussion we have of that now varies between the rather vague, = glossing over the operational impossibilities of actually doing what we're = suggesting people do, through to the oddly specific. There've been enough minor changes that section 8 is significantly = improved over earlier versions, but it's still rather weak. It seems more a grab = bag of unrelated thoughts than good coverage of why and how and where you should send unsolicited email in ARF format. Most of those are good thoughts, but = they're rather terse and without the context of why someone provided them I'm = not sure they add up to a coherent narrative. My preference would be to focus on use of ARF format for solicited = reports in this document, rip out section 8 altogether and concentrate on that = issue more in a separate document that could provide more depth, more focus on the difficulties with unsolicited reports that this one glosses over, = possibly combined with the work on advertising desire to receive machine-readable reports. Expanding section 8 into a deeper discussion in this document might work too. The rest of it looks fine, though, so if that doesn't = happen I'd consider -06 OK. Cheers, Steve From vesely@tana.it Thu Feb 2 10:44:35 2012 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 6839B21F85AF for ; Thu, 2 Feb 2012 10:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.637 X-Spam-Level: X-Spam-Status: No, score=-4.637 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mU1gKupOmqJG for ; Thu, 2 Feb 2012 10:44:34 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A335921F8539 for ; Thu, 2 Feb 2012 10:44:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328208273; bh=dQe+2Nj8Yy/78iBZlJrB32rfZmIJzPmlEjG4neDOth4=; l=742; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=atgsRiFzz2TABXkrUmKuQiFDUtplh5sLhGcE678MidsEddAkDts8M8rtf56oZSAPi 9nQwx9ulasM0pgasHgCcQBM6SQCKT4oO53gh8bq2EFTnEAmRYNJNWg2QCHuIdk8ACe O9y42eMVBulKAayjSk1+V7QKADgB7dEwm8cGO1so= 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, 02 Feb 2012 19:44:33 +0100 id 00000000005DC035.000000004F2AD991.00005EA2 Message-ID: <4F2AD991.8050508@tana.it> Date: Thu, 02 Feb 2012 19:44:33 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <4F291ECD.9040308@tana.it> In-Reply-To: <4F291ECD.9040308@tana.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [marf] Change request for AS, was Working Group Last Call on draft-ietf-marf-as-05 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, 02 Feb 2012 18:44:35 -0000 On 01/Feb/12 12:15, Alessandro Vesely wrote: > On 31/Jan/12 22:23, Barry Leiba wrote: >> I am re-posting this without the extra recipients; please reply to >> THIS message, and NOT to that other one. We can discuss later who, >> exactly, should get the truncheon treatment here....... > > It looks good to me[...] At the risk of being proposed for a treatment, I retract my post and ask that a new section be added to marf-as, about loop avoidance and control of flow. The new section would cover FBL traffic details such as using VERP and replying 552, which are to be used by all of dkim-reporting, spf-reporting, and reporting-discovery. Read more on, e.g. http://www.ietf.org/mail-archive/web/marf/current/msg01910.html From barryleiba.mailing.lists@gmail.com Thu Feb 2 11:13:47 2012 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 51D0421F858B for ; Thu, 2 Feb 2012 11:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.948 X-Spam-Level: X-Spam-Status: No, score=-102.948 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZR63joE018V2 for ; Thu, 2 Feb 2012 11:13:45 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C2E7F21F862B for ; Thu, 2 Feb 2012 11:13:45 -0800 (PST) Received: by yhkk25 with SMTP id k25so1492913yhk.31 for ; Thu, 02 Feb 2012 11:13:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lF52Ur08lsKGHPOCH9+aCPTtyV+0y3BUFlHS69+chB4=; b=ZLvJ4dsew9hGFMlXe7XJ8LZknO4aQNWHsT88Ez5yt9ZL3rJjv/Kcc9IOHUVOyEjuFv OPmDutdz69nbhbci7wEIKFuR+SIKeBDv/U8Isf5hVKP/X3PISfX1y1FakwLNEH+UYTO9 MyOvZgSk6ec7sA81viFQKqjVkbUn5aJS1KIUM= MIME-Version: 1.0 Received: by 10.236.133.210 with SMTP id q58mr6783217yhi.6.1328210025406; Thu, 02 Feb 2012 11:13:45 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Thu, 2 Feb 2012 11:13:45 -0800 (PST) In-Reply-To: References: <6993547.EjUSn6dgaq@scott-latitude-e6320> <4DEC4C4E-7F56-44DE-B0D6-6900120D9263@wordtothewise.com> Date: Thu, 2 Feb 2012 14:13:45 -0500 X-Google-Sender-Auth: MIoDMI-bO3_cHTmou3Cji3ZZfHE Message-ID: From: Barry Leiba To: Steve Atkins Content-Type: multipart/alternative; boundary=20cf30363723c061b104b7fffe18 Cc: Message Abuse Report Format working group Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 02 Feb 2012 19:13:47 -0000 --20cf30363723c061b104b7fffe18 Content-Type: text/plain; charset=ISO-8859-1 > Not entirely. I think that encouraging people to send unsolicited, non-human-readable > email to email addresses harvested from domain or IP registration addresses, > or to role accounts intended to receive human readable email, isn't a good idea > and we might want to spend more space on the problems with that. ... > My preference would be to focus on use of ARF format for solicited reports > in this document, rip out section 8 altogether and concentrate on that issue > more in a separate document that could provide more depth, more focus on > the difficulties with unsolicited reports that this one glosses over, possibly > combined with the work on advertising desire to receive machine-readable > reports. Expanding section 8 into a deeper discussion in this document > might work too. The rest of it looks fine, though, so if that doesn't happen > I'd consider -06 OK. I'll leave it to Murray to say for sure what input he wants, but I'll note that at this stage in the document's life cycle, giving the editor specific text that you propose to be included/changed is probably the most productive approach. Barry, border collie --20cf30363723c061b104b7fffe18 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> Not entirely. I think that encouraging people to send unsolicited,= non-human-readable
> email to email addresses harvested from domain = or IP registration addresses,
> or to role accounts intended to recei= ve human readable email, isn't a good idea
> and we might want to spend more space on the problems with that.
..= .
> My preference would be to focus on use of ARF format for solicite= d reports
> in this document, rip out section 8 altogether and concen= trate on that issue
> more in a separate document that could provide more depth, more focus = on
> the difficulties with unsolicited reports that this one glosses = over, possibly
> combined with the work on advertising desire to rece= ive machine-readable
> reports. Expanding section 8 into a deeper discussion in this document=
> might work too. The rest of it looks fine, though, so if that does= n't happen
> I'd consider -06 OK.

I'll leave it to= Murray to say for sure what input he wants, but I'll note that at this= stage in the document's life cycle, giving the editor specific text th= at you propose to be included/changed is probably the most productive appro= ach.

Barry, border collie --20cf30363723c061b104b7fffe18-- From msk@cloudmark.com Thu Feb 2 11:21:00 2012 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 930B221F8609 for ; Thu, 2 Feb 2012 11:21:00 -0800 (PST) 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.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05sCrxmiLZ+O for ; Thu, 2 Feb 2012 11:20:59 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 39BC821F85CF for ; Thu, 2 Feb 2012 11:20:59 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 2 Feb 2012 11:20:58 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 2 Feb 2012 11:20:58 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Thu, 2 Feb 2012 11:20:57 -0800 Thread-Topic: [marf] Working Group Last Call on draft-ietf-marf-as-05 Thread-Index: Aczh3s5YgA6rlTpwRkeQ3+wdFD5QxwAANvjw Message-ID: References: <6993547.EjUSn6dgaq@scott-latitude-e6320> <4DEC4C4E-7F56-44DE-B0D6-6900120D9263@wordtothewise.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C9A7DB60EXCHC2corpclo_" MIME-Version: 1.0 Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 02 Feb 2012 19:21:00 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DB60EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, please. I don't need a unified diff for something simple like "Remove Section 8", b= ut if that leaves any connecting tissue dangling, I'd like some specific up= dates to resolve those. -MSK From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Bar= ry Leiba Sent: Thursday, February 02, 2012 11:14 AM To: Steve Atkins Cc: Message Abuse Report Format working group Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 > Not entirely. I think that encouraging people to send unsolicited, non-hu= man-readable > email to email addresses harvested from domain or IP registration address= es, > or to role accounts intended to receive human readable email, isn't a goo= d idea > and we might want to spend more space on the problems with that. ... > My preference would be to focus on use of ARF format for solicited report= s > in this document, rip out section 8 altogether and concentrate on that is= sue > more in a separate document that could provide more depth, more focus on > the difficulties with unsolicited reports that this one glosses over, pos= sibly > combined with the work on advertising desire to receive machine-readable > reports. Expanding section 8 into a deeper discussion in this document > might work too. The rest of it looks fine, though, so if that doesn't hap= pen > I'd consider -06 OK. I'll leave it to Murray to say for sure what input he wants, but I'll note = that at this stage in the document's life cycle, giving the editor specific= text that you propose to be included/changed is probably the most producti= ve approach. Barry, border collie --_000_F5833273385BB34F99288B3648C4F06F19C9A7DB60EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, plea= se.

 

I don’t need a unified diff for som= ething simple like “Remove Section 8”, but if that leaves any c= onnecting tissue dangling, I’d like some specific updates to resolve = those.

 

-MSK

 

From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On= Behalf Of Barry Leiba
Sent: Thursday, February 02, 2012 11:1= 4 AM
To: Steve Atkins
Cc: Message Abuse Report Format w= orking group
Subject: Re: [marf] Working Group Last Call on draft= -ietf-marf-as-05

 


> Not entirely. I think that e= ncouraging people to send unsolicited, non-human-readable
> email to = email addresses harvested from domain or IP registration addresses,
>= or to role accounts intended to receive human readable email, isn't a good= idea
> and we might want to spend more space on the problems with th= at.
...
> My preference would be to focus on use of ARF format for= solicited reports
> in this document, rip out section 8 altogether a= nd concentrate on that issue
> more in a separate document that could= provide more depth, more focus on
> the difficulties with unsolicite= d reports that this one glosses over, possibly
> combined with the wo= rk on advertising desire to receive machine-readable
> reports. Expan= ding section 8 into a deeper discussion in this document
> might work= too. The rest of it looks fine, though, so if that doesn't happen
> = I'd consider -06 OK.

I'll leave it to Murray to say for sure what in= put he wants, but I'll note that at this stage in the document's life cycle= , giving the editor specific text that you propose to be included/changed i= s probably the most productive approach.

Barry, border collie <= /o:p>

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DB60EXCHC2corpclo_-- From johnl@iecc.com Thu Feb 2 12:22:07 2012 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 81A3621F86B5 for ; Thu, 2 Feb 2012 12:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.432 X-Spam-Level: X-Spam-Status: No, score=-109.432 tagged_above=-999 required=5 tests=[AWL=1.767, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Knj+ytR8MK-c for ; Thu, 2 Feb 2012 12:22:07 -0800 (PST) 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 CFB3B21F86B4 for ; Thu, 2 Feb 2012 12:22:06 -0800 (PST) Received: (qmail 30555 invoked from network); 2 Feb 2012 20:22:05 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Feb 2012 20:22:05 -0000 Date: 2 Feb 2012 20:21:43 -0000 Message-ID: <20120202202143.96921.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: barryleiba@computer.org Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 02 Feb 2012 20:22:07 -0000 > Not entirely. I think that encouraging people to send unsolicited, > non-human-readable email to email addresses harvested from domain or > IP registration addresses, or to role accounts intended to receive > human readable email, isn't a good idea and we might want to spend > more space on the problems with that. On the other hand, I've been sending ARF reports to random abuse contacts for years, and have found that it works pretty well. Remember that by design, the first part of an ARF report is free text for the benefit of humans who might be reading it. I'd be OK with either "do this at your own risk", or pull it out and save it for another document. Telling people not to send ARF reports to abuse addresses because it won't work flies in the face of experience. R's, John From msk@cloudmark.com Thu Feb 2 12:30:06 2012 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 AAB6421F8573 for ; Thu, 2 Feb 2012 12:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOe0tM2Q0Iix for ; Thu, 2 Feb 2012 12:30:06 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB7321F85C0 for ; Thu, 2 Feb 2012 12:30:00 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 2 Feb 2012 12:29:59 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 2 Feb 2012 12:29:59 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 2 Feb 2012 12:29:57 -0800 Thread-Topic: [marf] Change request for AS, was Working Group Last Call on draft-ietf-marf-as-05 Thread-Index: Aczh2roECdBgBcHzQjetXXoFpZAmkQADhnHw Message-ID: References: <4F291ECD.9040308@tana.it> <4F2AD991.8050508@tana.it> In-Reply-To: <4F2AD991.8050508@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] Change request for AS, was Working Group Last Call on draft-ietf-marf-as-05 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, 02 Feb 2012 20:30:06 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Thursday, February 02, 2012 10:45 AM > To: marf@ietf.org > Subject: [marf] Change request for AS, was Working Group Last Call on dra= ft-ietf-marf-as-05 >=20 > On 01/Feb/12 12:15, Alessandro Vesely wrote: > > On 31/Jan/12 22:23, Barry Leiba wrote: > >> I am re-posting this without the extra recipients; please reply to > >> THIS message, and NOT to that other one. We can discuss later who, > >> exactly, should get the truncheon treatment here....... > > > > It looks good to me[...] >=20 > At the risk of being proposed for a treatment, I retract my post and > ask that a new section be added to marf-as, about loop avoidance and > control of flow. >=20 > The new section would cover FBL traffic details such as using VERP and > replying 552, which are to be used by all of dkim-reporting, spf- > reporting, and reporting-discovery. Read more on, e.g. > http://www.ietf.org/mail-archive/web/marf/current/msg01910.html I would not be opposed to taking what dkim-reporting says in Section 6 and = Sections 8.4 through 8.6 (with parallel text in spf-reporting) and moving t= hem to the AS, and making the AS an informative reference for the two repor= ting drafts. That seems to be a sensible common-factoring to do. Is there= any support/objection for doing so? However, if we also agree that we want to include the "developed relationsh= ip" example Alessandro has there, I would like to see some text that presen= ts it but is far more concise. A detailed, complex (or even contrived) exa= mple is more confusing than a couple of simply-presented concepts. -MSK From steve@wordtothewise.com Thu Feb 2 12:35:45 2012 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 5752D21F86A6 for ; Thu, 2 Feb 2012 12:35:45 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRTqUqToYPlj for ; Thu, 2 Feb 2012 12:35:44 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id EDB3121F86A0 for ; Thu, 2 Feb 2012 12:35:44 -0800 (PST) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id AE6272EB3C for ; Thu, 2 Feb 2012 12:35:44 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Steve Atkins In-Reply-To: <20120202202143.96921.qmail@joyce.lan> Date: Thu, 2 Feb 2012 12:35:44 -0800 Content-Transfer-Encoding: 7bit Message-Id: <87ADC923-77C1-4BBE-985D-77074026EDAE@wordtothewise.com> References: <20120202202143.96921.qmail@joyce.lan> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1251.1) Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 02 Feb 2012 20:35:45 -0000 On Feb 2, 2012, at 12:21 PM, John Levine wrote: >> Not entirely. I think that encouraging people to send unsolicited, >> non-human-readable email to email addresses harvested from domain or >> IP registration addresses, or to role accounts intended to receive >> human readable email, isn't a good idea and we might want to spend >> more space on the problems with that. > > On the other hand, I've been sending ARF reports to random abuse > contacts for years, and have found that it works pretty well. > Remember that by design, the first part of an ARF report is free text > for the benefit of humans who might be reading it. If the report is fully actionable and makes sense to a recipient who only has access to the text/plain part, that's not a non-human-readable email, and my concern doesn't apply. I'm not against using ARF for unsolicited reports, I'm against sending unsolicited reports that aren't actionable by the recipient. Anyway, see my suggested edits in 3.. 2.. 1... > I'd be OK with either "do this at your own risk", or pull it out and > save it for another document. Telling people not to send ARF reports > to abuse addresses because it won't work flies in the face of > experience. Cheers, Steve From steve@wordtothewise.com Thu Feb 2 12:35:52 2012 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 D1F9E21F86AA for ; Thu, 2 Feb 2012 12:35:52 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcot7cnyiDj0 for ; Thu, 2 Feb 2012 12:35:52 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 038D121F869C for ; Thu, 2 Feb 2012 12:35:52 -0800 (PST) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id B29492EB3C for ; Thu, 2 Feb 2012 12:35:51 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1251.1) From: Steve Atkins In-Reply-To: Date: Thu, 2 Feb 2012 12:35:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2F430701-7B41-4F3B-ACC6-F2A302482304@wordtothewise.com> References: <6993547.EjUSn6dgaq@scott-latitude-e6320> <4DEC4C4E-7F56-44DE-B0D6-6900120D9263@wordtothewise.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1251.1) Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 02 Feb 2012 20:35:52 -0000 On Feb 2, 2012, at 11:20 AM, Murray S. Kucherawy wrote: > Yes, please. > =20 > I don=92t need a unified diff for something simple like =93Remove = Section 8=94, but if that leaves any connecting tissue dangling, I=92d = like some specific updates to resolve those. > =20 Yup. Sorry for leaving it until this late (quite possibly too late) in = the process, but it wasn't until I was rereading section 8 for the n-th time that I spotted the wood through the trees. Removing section 8: --- draft-ietf-marf-as-05.txt 2012-01-31 09:28:20.000000000 -0800 +++ new.txt 2012-02-02 11:35:46.000000000 -0800 @@ -143,22 +143,17 @@ messages as spam. We refer to these as solicited reports. =20 Other uses for ARF involve reports sent between parties that don't - know each other, with the recipient address typically being - abuse@domain (see [RFC2142]), looked up via WHOIS, or using other - heuristics. The reports may be manual, or automated due to hitting - spam traps, or caused by anything else that the sender of the report - considers to merit an abuse report. Abuse addresses in WHOIS = records - of the source IP and of the domain found in the results of a PTR - ("reverse lookup") query on that address are likely reasonable - candidates for receiving feedback about the message, although - automated parsing may be difficult, and such addresses are not - guaranteed to be useful. - - However, it is inadvisable to generate automated reports based on - inline content analysis tools that apply subjective evaluation = rules. - This can cause reports that, because of their subjective nature, are - not actionable by report receivers, which wastes valuable operator - time in processing them. + know each other. These unsolicited reports are sent without prior + agreement and without prior arrangement between the parties as to + the context and meaning of the reports, so the constraints on how + these unsolicited reports need to be generated such that they are + likely to be useful to the recipient, where they can usefully be + sent to, what issues they can be used to report and how they can + be handled by the receiver of the report are very different. + + In this document we discuss only solicited reports. Further = discussion + of unsolicited reports can be found in [reference]. + =20 Less drastic suggestion, moving the discussion of unsolicited reports to it's own section, removing reference to Yahoo, mentioning that ARF reports can be crafted to be more text/plain friendly, adding a MUST allow unsubscribes, a few other minor tweaks and a moral at the end: --- draft-ietf-marf-as-05.txt 2012-01-31 09:28:20.000000000 -0800 +++ new2.txt 2012-02-02 12:30:01.000000000 -0800 @@ -143,22 +143,15 @@ messages as spam. We refer to these as solicited reports. =20 Other uses for ARF involve reports sent between parties that don't - know each other, with the recipient address typically being - abuse@domain (see [RFC2142]), looked up via WHOIS, or using other - heuristics. The reports may be manual, or automated due to hitting - spam traps, or caused by anything else that the sender of the report - considers to merit an abuse report. Abuse addresses in WHOIS = records - of the source IP and of the domain found in the results of a PTR - ("reverse lookup") query on that address are likely reasonable - candidates for receiving feedback about the message, although - automated parsing may be difficult, and such addresses are not - guaranteed to be useful. - - However, it is inadvisable to generate automated reports based on - inline content analysis tools that apply subjective evaluation = rules. - This can cause reports that, because of their subjective nature, are - not actionable by report receivers, which wastes valuable operator - time in processing them. + know each other. These unsolicited reports are sent without prior + agreement and without prior arrangement between the parties as to + the context and meaning of the reports, so the constraints on how + these unsolicited reports need to be generated such that they are + likely to be useful to the recipient, where they can usefully be + sent to, what issues they can be used to report and how they can + be handled by the receiver of the report are very different. + + =20 =20 =20 =20 @@ -246,6 +239,8 @@ =20 8. Generating and Handling Unsolicited Reports =20 + =20 + 1. Systems that generate unsolicited reports SHOULD ensure that = the criteria used to decide what messages to report accurately identify messages that the reporting entity believes in good @@ -255,7 +250,11 @@ failures, and virus reports. (These applications might be described in future IETF documents.) Systems SHOULD NOT report all mail sent from a particular sender merely because some of = it - is determined to be abusive. + is determined to be abusive. Mechanical reports of mail that + "looks like" spam, based solely on the results of inline = content + analysis tools SHOULD NOT be sent as, because of their = subjective + nature, they are unlikely to provide a basis for the recipient + to take action. 2. With respect to authentication failures, these could occur for legitimate reasons outside of the control of the author. A report generator SHOULD be cautious to generate reports only in @@ -272,7 +271,21 @@ SHOULD NOT send reports to the operator of every Autonomous System in the path between the apparent originating system and the operator generating the report. - + X. Deciding where to send an unsolicited report will typically + rely on heuristics. Abuse addresses in WHOIS records + of the source IP and of the domain found in the results of + a PTR ("reverse lookup") query on that address are likely + reasonable candidates, as is the abuse@domain role address + (see [RFC2142]) of related domains. Unsolicited reports + SHOULD NOT be sent to email addresses which are not intended + to handle abuse reports, including any personal or role address + found in WHOIS records or on a web site that isn't either + explicitly described as an abuse contact or is of the form + abuse@domain. + Additionally, a report generator MUST provide a way for + a report recipient to request no further reports be sent + to them and MAY provide a way for recipients to change + the address(es) reports about them are sent to. =20 =20 =20 @@ -311,19 +324,19 @@ originating customer. 10. Published abuse mailbox addresses SHOULD NOT reject messages = not in the ARF format, as generation of ARF messages can - occasionally be unavailable or not applicable. Nevertheless, - some large messaging service providers specifically request = that - abuse reports be sent to them in ARF format. Experience of + occasionally be unavailable or not applicable. Experience of systems that send abuse reports in ARF format suggests that = even automated recipient systems that haven't asked for ARF format reports handle them at least as well as any other format such = as - plain text, with or without a copy of the message attached. + plain text, with or without a copy of the message attached, if + the original report has been generated with use by recipients + not using automated ARF parsing in mind. This suggests use of ARF is advisable in most contexts. 11. This is, however, not universally true. Anyone sending unsolicited reports in ARF format can legitimately presume that recipients will not be able to see the ARF metadata (i.e., = those - elements present in the second part of the report), and instead - MAY include all information needed in the human readable = (first, + elements present in the second part of the report), and MAY=20 + also include all information needed in the human readable = (first, text/plain) section of the report. Further, they MAY ensure that the report is readable when viewed as plain text, to give low-end ticketing systems as much assistance as possible. @@ -354,7 +367,16 @@ reporting addresses belonging to the abusive parties = themselves. Reports SHOULD NOT be sent to such addresses if they can be identified beforehand. - + 14. Handling unsolicited reports has a significant cost to the + receiver. Senders of unsolicited reports, especially those + sending large volumes of them mechanically, need to be aware + of that and do all they reasonably can to avoid sending + reports that cannot be used as a basis for action by the=20 + recipient - whether that is due to the report being sent + about an incident that isn't abuse-related, it being sent to + an email address that can't take action on it, or due to the + content or format of the report being hard for the recipient + to read or use. =20 9. IANA Considerations =20 Cheers, Steve From vesely@tana.it Fri Feb 3 01:43:12 2012 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 0978F21F85EF for ; Fri, 3 Feb 2012 01:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.638 X-Spam-Level: X-Spam-Status: No, score=-4.638 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIkZ5aDnmq+d for ; Fri, 3 Feb 2012 01:43:11 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCF121F85F4 for ; Fri, 3 Feb 2012 01:43:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328262189; bh=iuBnDUpEyGIXfiilyWCefO8kOWMJX4NArdqTSeaJrY0=; l=2422; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=INAxTt0KZnpRAafpa84X6ERAvLhbzMttCbV4KhO0Qkevn/lqyzw+HQqSk5aHhviIV baf+OCZEadWVUjtuK77dB2eN9WE+/3wrbUvL4ESltGIhLzFQG8n060XmM7SQsm0aIT OTM/28uxJAOKQ3pAwbssPzIe0BcioZ3pR60hmL5M= 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, 03 Feb 2012 10:43:09 +0100 id 00000000005DC033.000000004F2BAC2D.00003628 Message-ID: <4F2BAC2C.7000808@tana.it> Date: Fri, 03 Feb 2012 10:43:08 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120130193649.24837.53481.idtracker@ietfa.amsl.com> <4F283C32.7070206@tana.it> <4F291852.8020807@tana.it> <4F2A7E8F.9010901@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-dkim-reporting-08, was -07 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, 03 Feb 2012 09:43:12 -0000 On 02/Feb/12 19:16, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely >> >>> The I-D is meant to present the mechanisms for requesting and >>> providing these reports. That is, "If you're going to do this, >>> here's how we think you should go about it." There are some >>> obvious concerns with doing so across-the-board without any >>> checking or thought to it, though one certainly could do that. >> >> What's that "could"?! There's nothing I can conceivably do besides >> setting the RR properly. If that is not enough for getting reports >> from whoever will happen to get a broken signature, then this I-D is >> completely useless --I can well receive occasional failure notices from >> friends based on authfailure-report only. > > I think we're talking past each other here. What this draft > presents is a method that amounts to a two-way handshake between > someone that wants reports about DKIM failures and someone willing > to generate them. You need to consider both sides of that > equation. For report generators in particular, simply turning this > on without giving any thought to the potential for creating a mail > storm is possibly a bad idea, which means we should provide > appropriate cautions. For senders/signers, you need to be aware > that requesting reports might mean you get (legitimately) > mailbombed. That's what Sections 8.5 and 8.6 try to point out. I don't think we are at cross purposes, as we have more matching than contrasting points. Yet, at times we are unable to understand each other --possibly my English doesn't help much. Define "giving any thought". Auto or manual? Section 8.5 is about out-of-band arrangements. The only sense I'm able to make of it is that the signer has already set up an FBL with the report generating domain. If that's correct, it has to be said more clearly. BTW, the last phrase: data found in the DKIM signatures, which could have been fraudulently inserted. is obsolete now that the data is checked in the DNS. Section 8.6 is about run-time control of traffic. We may solve the problem or just mention it. Let's see if anyone else is interested. In any case, the mailbombing is limited by a max in/out ratio of 3 (if one fails SPF and DKIM and gets a spam report for each message) so it should be fine for sites like mine where that ratio is usually around 10~20. From vesely@tana.it Fri Feb 3 02:06:41 2012 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 662AA21F85D1 for ; Fri, 3 Feb 2012 02:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.64 X-Spam-Level: X-Spam-Status: No, score=-4.64 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GUMNcg+xEZV for ; Fri, 3 Feb 2012 02:06:40 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0460321F85BD for ; Fri, 3 Feb 2012 02:06:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328263598; bh=p7h10M+xUnSjwukLqSmmKTB+FOlvGj0mjXUSGMg2HOY=; l=8000; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=X7tQ9c1e57VGnoNF6kODWawf0xuNMGdLBxLJk0kjrSOGY6v4Lm/jkX4QvRqk0eSZi o/Ost97xs8rlC9sscXwyP8SsewoIJu1PS0HevWP3Ih+l2ZjAss5sMm7zANssIP2xnt Wmsgv89ZaV2dgLIRmXrMeAx/xQELSE4iMO1pJ5V8= 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, 03 Feb 2012 11:06:38 +0100 id 00000000005DC033.000000004F2BB1AE.00003D46 Message-ID: <4F2BB1AE.4020605@tana.it> Date: Fri, 03 Feb 2012 11:06:38 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <6993547.EjUSn6dgaq@scott-latitude-e6320> <4DEC4C4E-7F56-44DE-B0D6-6900120D9263@wordtothewise.com> <2F430701-7B41-4F3B-ACC6-F2A302482304@wordtothewise.com> In-Reply-To: <2F430701-7B41-4F3B-ACC6-F2A302482304@wordtothewise.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 03 Feb 2012 10:06:41 -0000 My comments on Steve's diffs: On 02/Feb/12 21:35, Steve Atkins wrote: > > Sorry for leaving it until this late (quite possibly too late) Still better than never. > Removing section 8: That is a step toward banning mail domains below a critical size. It has very bigbrotherish implications on the resiliency, privacy, and even democracy of the mail system. I'm strongly opposed to that. > Less drastic suggestion, moving the discussion of unsolicited > reports to it's own section, removing reference to Yahoo, mentioning > that ARF reports can be crafted to be more text/plain friendly, adding > a MUST allow unsubscribes, a few other minor tweaks and a moral > at the end: What was the reference to Yahoo? > --- draft-ietf-marf-as-05.txt 2012-01-31 09:28:20.000000000 -0800 > +++ new2.txt 2012-02-02 12:30:01.000000000 -0800 > @@ -143,22 +143,15 @@ > messages as spam. We refer to these as solicited reports. > > Other uses for ARF involve reports sent between parties that don't > - know each other, with the recipient address typically being > - abuse@domain (see [RFC2142]), looked up via WHOIS, or using other > - heuristics. The reports may be manual, or automated due to hitting > - spam traps, or caused by anything else that the sender of the report > - considers to merit an abuse report. Abuse addresses in WHOIS records > - of the source IP and of the domain found in the results of a PTR > - ("reverse lookup") query on that address are likely reasonable > - candidates for receiving feedback about the message, although > - automated parsing may be difficult, and such addresses are not > - guaranteed to be useful. > - > - However, it is inadvisable to generate automated reports based on > - inline content analysis tools that apply subjective evaluation rules. > - This can cause reports that, because of their subjective nature, are > - not actionable by report receivers, which wastes valuable operator > - time in processing them. > + know each other. These unsolicited reports are sent without prior > + agreement and without prior arrangement between the parties as to > + the context and meaning of the reports, so the constraints on how > + these unsolicited reports need to be generated such that they are > + likely to be useful to the recipient, where they can usefully be > + sent to, what issues they can be used to report and how they can > + be handled by the receiver of the report are very different. I'd add that sending unsolicited messages can be a way of initiating an FBL. With respect to RFC 6449, the resulting FBL is more based on domain authentication (including SPF) and less on IP addresses. In particular the IP validation mentioned in Section 3.6.1 of RFC 6449 shall be fully automatic, because changing ISP cannot imply filling out several thousands of web forms. > @@ -246,6 +239,8 @@ > > 8. Generating and Handling Unsolicited Reports > > + > + > 1. Systems that generate unsolicited reports SHOULD ensure that the > criteria used to decide what messages to report accurately > identify messages that the reporting entity believes in good > @@ -255,7 +250,11 @@ > failures, and virus reports. (These applications might be > described in future IETF documents.) Systems SHOULD NOT report > all mail sent from a particular sender merely because some of it > - is determined to be abusive. > + is determined to be abusive. Mechanical reports of mail that > + "looks like" spam, based solely on the results of inline content > + analysis tools SHOULD NOT be sent as, because of their subjective > + nature, they are unlikely to provide a basis for the recipient > + to take action. Advice that a message was delivered to a junk folder might be useful, though. I think we won't get it even if we ask for it, so putting too much emphasis on this point is worthless. However, perhaps it has to be said that rejected messages must not be reported. > @@ -272,7 +271,21 @@ > SHOULD NOT send reports to the operator of every Autonomous > System in the path between the apparent originating system and > the operator generating the report. > - > + X. Deciding where to send an unsolicited report will typically > + rely on heuristics. Abuse addresses in WHOIS records > + of the source IP and of the domain found in the results of > + a PTR ("reverse lookup") query on that address are likely > + reasonable candidates, as is the abuse@domain role address > + (see [RFC2142]) of related domains. Unsolicited reports > + SHOULD NOT be sent to email addresses which are not intended > + to handle abuse reports, including any personal or role address > + found in WHOIS records or on a web site that isn't either > + explicitly described as an abuse contact or is of the form > + abuse@domain. Very much agreed! I suggest X be near 5 (abuse@authenticated-domain.) > + Additionally, a report generator MUST provide a way for > + a report recipient to request no further reports be sent > + to them and MAY provide a way for recipients to change > + the address(es) reports about them are sent to. This latter part should go to a different paragraph. Perhaps near 12 (replying to feedback). Replies may be mail- or web-based. > @@ -311,19 +324,19 @@ > originating customer. > 10. Published abuse mailbox addresses SHOULD NOT reject messages not > in the ARF format, as generation of ARF messages can > - occasionally be unavailable or not applicable. Paragraph 10, for receivers, should terminate here. > Nevertheless, > - some large messaging service providers specifically request that > - abuse reports be sent to them in ARF format. Experience of > + occasionally be unavailable or not applicable. Experience of > systems that send abuse reports in ARF format suggests that even > automated recipient systems that haven't asked for ARF format > reports handle them at least as well as any other format such as > - plain text, with or without a copy of the message attached. > + plain text, with or without a copy of the message attached, if > + the original report has been generated with use by recipients > + not using automated ARF parsing in mind. > This suggests use of ARF is advisable in most contexts. > 11. This is, however, not universally true. Anyone sending > unsolicited reports in ARF format can legitimately presume that > recipients will not be able to see the ARF metadata (i.e., those > - elements present in the second part of the report), and instead > - MAY include all information needed in the human readable (first, > + elements present in the second part of the report), and MAY > + also include all information needed in the human readable (first, > text/plain) section of the report. Further, they MAY ensure > that the report is readable when viewed as plain text, to give > low-end ticketing systems as much assistance as possible. The rest of paragraph 10 and paragraph 11 (for senders) are confusing and need additional rewording, IMHO. > @@ -354,7 +367,16 @@ > [snip] > - > + 14. Handling unsolicited reports has a significant cost to the > + receiver. Senders of unsolicited reports, especially those > + sending large volumes of them mechanically, need to be aware > + of that and do all they reasonably can to avoid sending > + reports that cannot be used as a basis for action by the > + recipient - whether that is due to the report being sent > + about an incident that isn't abuse-related, it being sent to > + an email address that can't take action on it, or due to the > + content or format of the report being hard for the recipient > + to read or use. Non-actionable reports could still be useful for collecting statistics, whose evaluation may eventually result in a better sending. This is especially true for spf- or dkim-reporting. Should we say that the 3rd mime part of non-actionable reports should be "text/rfc822-headers"? From shmuel+gen@patriot.net Fri Feb 3 06:36:42 2012 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 F010021F856A for ; Fri, 3 Feb 2012 06:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[AWL=-1.199, BAYES_20=-0.74, DATE_IN_PAST_24_48=1.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3VN95Fc-Qy7 for ; Fri, 3 Feb 2012 06:36:41 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6737521F855B for ; Fri, 3 Feb 2012 06:36:41 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.97]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 4AE98F58083 for ; Fri, 3 Feb 2012 09:22:13 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Thu, 02 Feb 2012 06:11:58 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120203142214.4AE98F58083@smtp.patriot.net> Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 14:36:42 -0000 In , on 02/01/2012 at 07:51 PM, "Murray S. Kucherawy" said: >Does such a thing exist? Don't know. >Would it make sense to build one? Generating MARF reports from the MUA Is the natural response to a large provider that won't accept abuse reports in plain text. IMHO it would be prudent to provide advice on how such a tool would operate. -- 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 Fri Feb 3 06:36:51 2012 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 D7DDA21F85D7 for ; Fri, 3 Feb 2012 06:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.862 X-Spam-Level: X-Spam-Status: No, score=-0.862 tagged_above=-999 required=5 tests=[AWL=-0.971, BAYES_05=-1.11, DATE_IN_PAST_24_48=1.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xt+B0kY-azOy for ; Fri, 3 Feb 2012 06:36:51 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6F94A21F855B for ; Fri, 3 Feb 2012 06:36:51 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.97]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id CA088F58083 for ; Fri, 3 Feb 2012 09:22:17 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Thu, 02 Feb 2012 06:18:04 -0500 To: marf@ietf.org In-Reply-To: <20120202021616.31482.qmail@joyce.lan> Mail-Copies-To: nobody 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: <20120203142218.CA088F58083@smtp.patriot.net> Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 14:36:52 -0000 In <20120202021616.31482.qmail@joyce.lan>, on 02/02/2012 at 02:16 AM, "John Levine" said: >Look at RFC 2119. SHOULD NOT more or less means don't do this unless >you're sure you understand what you're doing. Given how few mail >users understand header parsing and mail routing, SHOULD NOT seems >right to me. One would hope that the author of such a tool would understand header parsing and mail routing. Of course, correct operation would still require that the user be able to count. >If you, one of the few users familiar with the details of SMTP mail, >want to do it, go ahead. For the bazillion users of some random >consumer mail system, let their mail system admins handle it. Who's going to bell the cat? Currently, a lot of e-mail admins don't provide the function of collecting abuse complaints and forwarding them to the proper recipients. -- 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 Fri Feb 3 06:54:00 2012 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 F1F7121F850D for ; Fri, 3 Feb 2012 06:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.366 X-Spam-Level: X-Spam-Status: No, score=-0.366 tagged_above=-999 required=5 tests=[AWL=-1.400, BAYES_40=-0.185, DATE_IN_PAST_24_48=1.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEVicQb5vnfQ for ; Fri, 3 Feb 2012 06:54:00 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9FA21F8508 for ; Fri, 3 Feb 2012 06:54:00 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.97]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 85582F58083 for ; Fri, 3 Feb 2012 09:22:33 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Thu, 02 Feb 2012 06:25:59 -0500 To: marf@ietf.org In-Reply-To: <7DEB0B04-2161-4FA4-8B86-E004CCB3085B@wordtothewise.com> Mail-Copies-To: nobody 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: <20120203142239.85582F58083@smtp.patriot.net> Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 14:54:01 -0000 In <7DEB0B04-2161-4FA4-8B86-E004CCB3085B@wordtothewise.com>, on 02/01/2012 at 08:05 PM, Steve Atkins said: >Probably, yes - while on the modern net it would probably make much >more sense to centralize most the processing and decision making, I agree, but in the short run there will continue to be providers that don't provide that function. >I think anyone developing an MUA to do that sort of thing would >either deeply understand this document and read it from an >appropriate perspective, or not understand it and need to be >restrained from doing anything along these lines. The refusal of, e.g., yahoo, to accept plain text complaints provides an incentive for MUA authors to write such tools. Given the number of e-mail clients that are broken in one way or another, I'd rather see some guidance in an RFC before the avalanche starts. Restraining the MUA authors is not feasible. -- 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 johnl@iecc.com Fri Feb 3 08:16:56 2012 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 CE07F21F85BB for ; Fri, 3 Feb 2012 08:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.489 X-Spam-Level: X-Spam-Status: No, score=-109.489 tagged_above=-999 required=5 tests=[AWL=1.710, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtzE7RhmZAhz for ; Fri, 3 Feb 2012 08:16:56 -0800 (PST) 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 0B27A21F85CE for ; Fri, 3 Feb 2012 08:16:55 -0800 (PST) Received: (qmail 81217 invoked from network); 3 Feb 2012 16:16:54 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 3 Feb 2012 16:16:54 -0000 Date: 3 Feb 2012 16:16:32 -0000 Message-ID: <20120203161632.69515.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org Cc: MARF@IETF.ORG In-Reply-To: <20120203142218.CA088F58083@smtp.patriot.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 03 Feb 2012 16:16:56 -0000 >>If you, one of the few users familiar with the details of SMTP mail, >>want to do it, go ahead. For the bazillion users of some random >>consumer mail system, let their mail system admins handle it. > >Who's going to bell the cat? Currently, a lot of e-mail admins don't >provide the function of collecting abuse complaints and forwarding >them to the proper recipients. Not the IETF. Despite a lot of wishful thinking, no standard can force anyone to do anything they're not already inclined to do. R's, John From johnl@iecc.com Fri Feb 3 08:16:56 2012 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 CDAD521F8565 for ; Fri, 3 Feb 2012 08:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.461 X-Spam-Level: X-Spam-Status: No, score=-109.461 tagged_above=-999 required=5 tests=[AWL=1.738, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWrdyfqqiR+J for ; Fri, 3 Feb 2012 08:16:56 -0800 (PST) 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 08D2321F85C9 for ; Fri, 3 Feb 2012 08:16:55 -0800 (PST) Received: (qmail 81217 invoked from network); 3 Feb 2012 16:16:54 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 3 Feb 2012 16:16:54 -0000 Date: 3 Feb 2012 16:16:32 -0000 Message-ID: <20120203161632.69515.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org Cc: MARF@IETF.ORG In-Reply-To: <20120203142218.CA088F58083@smtp.patriot.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 03 Feb 2012 16:16:56 -0000 >>If you, one of the few users familiar with the details of SMTP mail, >>want to do it, go ahead. For the bazillion users of some random >>consumer mail system, let their mail system admins handle it. > >Who's going to bell the cat? Currently, a lot of e-mail admins don't >provide the function of collecting abuse complaints and forwarding >them to the proper recipients. Not the IETF. Despite a lot of wishful thinking, no standard can force anyone to do anything they're not already inclined to do. R's, John From shmuel+gen@patriot.net Fri Feb 3 09:57:06 2012 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 0361321F8574 for ; Fri, 3 Feb 2012 09:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxgVqXehPAyB for ; Fri, 3 Feb 2012 09:57:05 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 53EE421F8567 for ; Fri, 3 Feb 2012 09:57:05 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.189]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 310DEF58089 for ; Fri, 3 Feb 2012 12:42:37 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Fri, 03 Feb 2012 11:53:13 -0500 To: marf@ietf.org In-Reply-To: <87ADC923-77C1-4BBE-985D-77074026EDAE@wordtothewise.com> Mail-Copies-To: nobody 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: <20120203174238.310DEF58089@smtp.patriot.net> Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 17:57:06 -0000 In <87ADC923-77C1-4BBE-985D-77074026EDAE@wordtothewise.com>, on 02/02/2012 at 12:35 PM, Steve Atkins said: >I'm not against using ARF for unsolicited reports, I'm against >sending unsolicited reports that aren't actionable by the recipient. I'd suggest changing MAY to SHOULD in item 11 of 8. Generating and Handling Unsolicited Reports. 11. This is, however, not universally true. Anyone sending unsolicited reports in ARF format can legitimately presume that some recipients will not be able to see the ARF metadata (e.g., those elements present in the second part of the report), and instead SHOULD include all information needed in the human readable (first, text/plain) section of the report. Further, they MAY ensure that the report is readable when viewed as plain text, to give low-end ticketing systems as much assistance as possible. Finally, they need to be aware that the report could be discarded or ignored due to failure to take these steps in the most extreme cases. I fixed a couple of nits in the above; adding "some" and changing an inappropriate "i.e." to "e.g.". I'm not sure whether the second MAY should also be SHOULD. -- 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 david.black@emc.com Fri Feb 3 10:57:18 2012 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 2466A21F853D; Fri, 3 Feb 2012 10:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.412 X-Spam-Level: X-Spam-Status: No, score=-109.412 tagged_above=-999 required=5 tests=[AWL=1.187, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIQjTD0d3glL; Fri, 3 Feb 2012 10:57:17 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE0C21F8476; Fri, 3 Feb 2012 10:57:16 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q13Iv3ln014116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Feb 2012 13:57:06 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Fri, 3 Feb 2012 13:56:42 -0500 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q13IufHE016263; Fri, 3 Feb 2012 13:56:41 -0500 Received: from mx14a.corp.emc.com ([169.254.1.94]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Fri, 3 Feb 2012 13:56:40 -0500 From: To: , , , Date: Fri, 3 Feb 2012 13:56:39 -0500 Thread-Topic: Gen-ART review of draft-ietf-marf-redaction-08 Thread-Index: AczQCujbMXhqirD5Sk6EB1sS2KVtOQG/Hm+wAudY0sA= Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05AD13B873@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7CF1028@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7CF1028@MX14A.corp.emc.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: presnick@qualcomm.com, david.black@emc.com, marf@ietf.org Subject: [marf] Gen-ART review of draft-ietf-marf-redaction-08 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, 03 Feb 2012 18:57:18 -0000 The -08 version is a significant improvement that aligns the draft's recommendations on mechanisms for redaction and anonymization with the situation-dependent levels of security that are appropriate for those purposes. idnits 2.12.13 didn't find anything. The -08 version is ready for publication as a Standards Track RFC. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Thursday, January 19, 2012 7:10 PM > To: ietf@cybernothing.org; Murray S. Kucherawy; gen-art@ietf.org; ietf@ie= tf.org > Cc: marf@ietf.org; presnick@qualcomm.com; Black, David > Subject: Gen-ART review of draft-ietf-marf-redaction-05 >=20 > Based on discussion with the authors, the -05 version of this draft resol= ves the > issues raised in the Gen-ART review of the -04 version. An important ele= ment of > the approach taken to issue [1] has been to explain why the security requ= irements > for redaction are significantly weaker than the strength of the secure ha= shes > that are suggested by the draft. >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Black, David > > Sent: Tuesday, January 10, 2012 9:44 PM > > To: ietf@cybernothing.org; Murray S. Kucherawy; gen-art@ietf.org; ietf@= ietf.org > > Cc: Black, David; marf@ietf.org; presnick@qualcomm.com > > Subject: Gen-ART review of draft-ietf-marf-redaction-04 > > > > I am the assigned Gen-ART reviewer for this draft. For background on Ge= n-ART, please > > see the FAQ at . > > > > Please resolve these comments along with any other Last Call comments y= ou may receive. > > > > Document: draft-ietf-marf-redaction-04 > > Reviewer: David L. Black > > Review Date: January 10, 2012 > > IETF LC End Date: January 18, 2011 > > IESG Telechat Date: January 19, 2011 > > > > Summary: This draft is on the right track but has open issues, describe= d in the review. > > > > This draft specifies a method for redacting information from email abus= e reports > > (e.g., hiding the local part [user] of an email address), while still a= llowing > > correlation of the redacted information across related abuse reports fr= om the same > > source. The draft is short, clear, and well written. > > > > There are two open issues: > > > > [1] The first open issue is the absence of security guidance to ensure = that this > > redaction technique effectively hides the redacted information. The re= daction > > technique is to concatenate a secret string (called the "redaction key"= ) to the > > information to be redacted, apply "any hashing/digest algorithm", conve= rt the output > > to base64 and use that base64 string to replace the redacted informatio= n. > > > > There are two important ways in which this technique could fail to effe= ctively hide > > the redacted information: > > - The secret string may inject insufficient entropy. > > - The hashing/digest algorithm may be weak. > > > > To take an extreme example, if the secret string ("redaction key") cons= ists of a > > single ASCII character, and a short email local part is being redacted,= then the > > output is highly vulnerable to dictionary and brute force attacks becau= se only 6 bits > > of entropy are added (the result may look secure, but it's not). Beyon= d this extreme > > example, this is a potentially real concern - e.g., applying the rule o= f thumb that > > ASCII text contains 4-5 bits of entropy per character, the example in A= ppendix A > > uses a "redaction key" of "potatoes" that injects at most 40 bits of en= tropy - > > is that sufficient for email redaction purposes? > > > > To take a silly example, if a CRC is used as the hash with that sort of= short input, > > the result is not particularly difficult to invert. > > > > I suggest a couple of changes: > > 1) Change "any hashing/digest algorithm" to require use of a secure has= h, and > > explain what is meant by "secure hash" in the security considerations = section. > > 2) Require a minimum length of the "redaction key" string, and strongly= suggest > > (SHOULD) that it be randomly generated (e.g., by running sufficient ou= tput > > of an entropy-rich random number generator through a base64 converter)= . > > > > For the latter change, figure out the amount of entropy that should be = used > > for redaction - the recommended string length will be larger because pr= intable > > ASCII is not entropy-dense (at best it's good for 6 bits of entropy in = each > > 8-bit character, and human-written text such as this message has signif= icantly > > less). > > > > From a pure security perspective, use of HMAC with specified secure has= hes > > (SHA2-family) and an approach of hashing the "redaction key" down to a = binary > > key for HMAC would be a stronger approach. I suggest that authors consi= der > > approach, but there may be practical usage concerns that suggest not a= dopting it. > > > > [2] The second open issue is absence of security considerations for the= redaction > > key. The security considerations section needs to caution that the red= action key > > is a secret key that must be managed and protected as a secret key. Di= sclosure > > of a redaction key removes the redaction from all reports that used tha= t key. > > As part of this, guidance should be provided on when and how to change = the > > redaction key in order to limit the effects of loss of secrecy for a si= ngle > > redaction key. > > > > Editorial Nit: I believe that "anonymization" is a better description o= f what > > this draft is doing (as opposed to "redaction"), particularly as the re= sult is > > intended to be correlatable via string match across reports from the sa= me source. > > > > idnits 2.12.13 didn't find any nits. > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer > > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293= -7786 > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- From msk@cloudmark.com Fri Feb 3 13:58:14 2012 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 125E51F0C41 for ; Fri, 3 Feb 2012 13:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5UWmJZZTNVQ for ; Fri, 3 Feb 2012 13:58:13 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECBB1F0C3F for ; Fri, 3 Feb 2012 13:58:13 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 Feb 2012 13:58:12 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 3 Feb 2012 13:58:12 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 3 Feb 2012 13:58:11 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was -07 Thread-Index: AcziWD/YNPJ63JxrQGaXv2BODzU6rgAZOyng Message-ID: References: <20120130193649.24837.53481.idtracker@ietfa.amsl.com> <4F283C32.7070206@tana.it> <4F291852.8020807@tana.it> <4F2A7E8F.9010901@tana.it> <4F2BAC2C.7000808@tana.it> In-Reply-To: <4F2BAC2C.7000808@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-dkim-reporting-08, was -07 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, 03 Feb 2012 21:58:14 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Friday, February 03, 2012 1:43 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was -0= 7 >=20 > > I think we're talking past each other here. What this draft presents > > is a method that amounts to a two-way handshake between someone that > > wants reports about DKIM failures and someone willing to generate > > them. You need to consider both sides of that equation. For report > > generators in particular, simply turning this on without giving any > > thought to the potential for creating a mail storm is possibly a bad > > idea, which means we should provide appropriate cautions. For > > senders/signers, you need to be aware that requesting reports might > > mean you get (legitimately) mailbombed. That's what Sections 8.5 and > > 8.6 try to point out. >=20 > I don't think we are at cross purposes, as we have more matching than > contrasting points. Yet, at times we are unable to understand each > other --possibly my English doesn't help much. >=20 > Define "giving any thought". Auto or manual? I'll define "without giving any thought" as "install, enable, walk away." > Section 8.5 is about out-of-band arrangements. Quite the opposite; Section 8.5 is about generating reports to anyone that = asks for them, rather than sending them to sites that have specifically ask= ed for them. I can improve the language to reflect this. The point is that report generators could be installed to send reports when= ever they are requested. For a large email campaign whose signatures all b= reak, this could cause the sender to become inundated with reports. It cou= ld also cause the report generator to be overwhelmed generating reports. B= oth parties need to be aware of this. > BTW, the last phrase: >=20 > data found in the DKIM signatures, which could have been > fraudulently inserted. >=20 > is obsolete now that the data is checked in the DNS. Removed. So here's the pending 8.5: 8.5. Automatic Generation The mechanisms described in this memo are primarily intended for use in generating reports to aid implementers of [DKIM] and [ADSP] and other related protocols in development and debugging. They are not intended for prolonged forensic use. However, such uses are possible by ADMDs that want to keep a close watch for fraud or infrastructure problems. A sender requesting these reports can cause its mail servers to be overwhelmed if it sends out signed messages whose signatures fail to verify for some reason, provoking a large number of reports from report generators. Similarly, a report generator could be overwhelmed by a large volume of messages requesting reports whose signatures fail to validate, as those now need to send reports back to the signer. Limiting the rate of generation of these messages may be appropriate but threatens to inhibit the distribution of important and possibly time-sensitive information. In general ARF feedback loop terms, it is often suggested that report generators only create these (or any) ARF reports after an out-of- band arrangement has been made between two parties. This mechanism then becomes a way to adjust parameters of an authorized abuse report feedback loop that is configured and activated by private agreement rather than starting to send them automatically based solely on data found in the DKIM signatures, which may have unintended consequences. > Section 8.6 is about run-time control of traffic. We may solve the > problem or just mention it. Let's see if anyone else is interested. I think I like the idea of common-factoring this into the AS, but I'm watch= ing for others to reply. -MSK From sklist@kitterman.com Fri Feb 3 14:05:05 2012 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 086291F0C46 for ; Fri, 3 Feb 2012 14:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVzjYDl35NoV for ; Fri, 3 Feb 2012 14:05:04 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5F61F0C3F for ; Fri, 3 Feb 2012 14:05:04 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 94B4120E40F9; Fri, 3 Feb 2012 17:05:03 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328306703; bh=LhF8fGl/KIpoN4enmJEfWggSM0JAozsWzlAJe9jtqSE=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=abFh3V8sLa4Dapu/ktcfuPQOcyilMyd135CADV1CDqLLW6gtXC/8orYAyFJU4CgjM B/66UPzvMl0LOtHxZ90uK/t9AtIx6CbbaF8j0oYE3wmPH0qCpwmPHthPfxKnlKqF/F bVsNiXKOZgIz20HWFa93s/EoUhDYeDUrkcmm9/o4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 73E3B20E40D0; Fri, 3 Feb 2012 17:05:03 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Fri, 03 Feb 2012 17:05:02 -0500 Message-ID: <3480646.curB61z5rG@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120130193649.24837.53481.idtracker@ietfa.amsl.com> <4F2BAC2C.7000808@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was -07 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, 03 Feb 2012 22:05:05 -0000 On Friday, February 03, 2012 01:58:11 PM Murray S. Kucherawy wrote: > The mechanisms described in this memo are primarily intended for use > in generating reports to aid implementers of [DKIM] and [ADSP] and > other related protocols in development and debugging. They are not > intended for prolonged forensic use. However, such uses are possible > by ADMDs that want to keep a close watch for fraud or infrastructure > problems. I probably missed a discussion about this sometime, but why isn't this intended for prolonged forensic use? The applications of ARF I've seen that's exactly what they are for. Scott K From sklist@kitterman.com Fri Feb 3 22:12:56 2012 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 B95DD21F85B9 for ; Fri, 3 Feb 2012 22:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, HS_INDEX_PARAM=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixbLskEf9p0R for ; Fri, 3 Feb 2012 22:12:55 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF9E21F85BE for ; Fri, 3 Feb 2012 22:12:55 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5EA1120E4083; Sat, 4 Feb 2012 01:12:54 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328335974; bh=7ppr0fFIeGoo2fgspAxwXxTocOwvgtnmKD5VDX+hROA=; h=From:To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=cQiiRQKI8oGWlIIPrS8kKlfkOrt7bS1XOBnC/C73M2F3JStRC1MoMfoOHmXZ5WR+V MrGglLZ+30gqfpjwtgiqq/PKdm8UbKKLe3K6e8fyY5WdTdA3D1r+g1IY0VQEjaPRyZ WMKspNKxXK5eE4F8RENOb7cAKz1YC8GP5prmVJRs= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3DC5C20E406C; Sat, 4 Feb 2012 01:12:54 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Sat, 04 Feb 2012 01:12:53 -0500 Message-ID: <3745195.APs8KS2Hoz@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [marf] Fwd: Re: [spf-discuss] Review of draft-ietf-marf-spf-reporting X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 06:12:56 -0000 I've asked for a number of people external to the working group who have experience with SPF to review this draft, including multiple reviews on the spf-discuss mailing list. Most of the comments have been general, like "looks much easier to implement that the exists: processing you'd have to use now to get feedback". I got this review today. Comments in line. Scott K > Subject: Re: (Private) [spf-discuss] Review of > draft-ietf-marf-spf-reporting Date: Friday, February 03, 2012, 05:52:14 > PM > From: Commerco WebMaster > To: Scott Kitterman > > Scott, > > The draft looks good. > > That said, looking at things from the standpoint of an implementing > user, I typically like to see more in the way of examples in the RFCs. > > While the examples in Appendix B - B.1. and B.2. are great, it would be > nice to include a couple of logical variants that someone trying to > implement SPF might want to set up in the real world. > > In other words starting with an example of no mail authorized - > > v=spf1 -all > > to a simple IP4 case - > > v=spf1 ip4:192.168.10.1 ip4:192.168.20.1 -all > > and some other possible variations might help implementers better > understand their possible choices, given that SPF offers quite a few > ways to acceptably configure a DNS record. I'm always a fan of examples, so I can add some more. > One last thought, since there are two ways to implement the DNS RR (via > TXT and SPF), perhaps that might get a mention somewhere. I think it's probably not necessary since this is within an SPF record and not about how the record as a whole is created or published. Also, since the type SPF RR has almost no deployment, I'm afraid it might confuse things. > Best, > > Alan Maitland > > On 2/3/2012 3:33 PM, Scott Kitterman wrote: > > I think this is getting close to ready, so I would appreciate it if > > people here would review the draft and provide comments: > > > > http://datatracker.ietf.org/doc/draft-ietf-marf-spf-reporting/?include > > _text=1 > > > > Thanks. > > > > Scott K From msk@cloudmark.com Sat Feb 4 20:51:32 2012 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 CA51321F84FA for ; Sat, 4 Feb 2012 20:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7oDDkDFXKgg for ; Sat, 4 Feb 2012 20:51:32 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2893B21F84F8 for ; Sat, 4 Feb 2012 20:51:32 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 4 Feb 2012 20:51:30 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 4 Feb 2012 20:51:31 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sat, 4 Feb 2012 20:51:36 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was -07 Thread-Index: Acziv+dwaFRN9zS2SouhnlHmLwODIQBAEelQ Message-ID: References: <20120130193649.24837.53481.idtracker@ietfa.amsl.com> <4F2BAC2C.7000808@tana.it> <3480646.curB61z5rG@scott-latitude-e6320> In-Reply-To: <3480646.curB61z5rG@scott-latitude-e6320> 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-dkim-reporting-08, was -07 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, 05 Feb 2012 04:51:32 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Friday, February 03, 2012 2:05 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was -0= 7 >=20 > On Friday, February 03, 2012 01:58:11 PM Murray S. Kucherawy wrote: > > The mechanisms described in this memo are primarily intended for use > > in generating reports to aid implementers of [DKIM] and [ADSP] and > > other related protocols in development and debugging. They are not > > intended for prolonged forensic use. However, such uses are possibl= e > > by ADMDs that want to keep a close watch for fraud or infrastructure > > problems. >=20 > I probably missed a discussion about this sometime, but why isn't this > intended for prolonged forensic use? The applications of ARF I've seen > that's exactly what they are for. The difference to me is that conventional ARF (e.g., spam reports) are almo= st always provoked by some human action, like clicking a Report Spam button= in a mail reader. These, by contrast, will almost always be automatically= generated. Perhaps we should say that, rather than what's there now. I think the current language is also drawn from implementation experience. = It's akin, I suppose, to running a binary in production that has full debu= gging symbols included to enable detailed debugging versus a stripped binar= y that is leaner but harder to debug. Indeed, running a report generator w= ith all of this turned on can obviously cause drag on a mail system when la= rge and/or constant volumes of these reports are being sent in addition to = regular mail. So how about this to replace the above paragraph: ARF reports have historically been generated individually as a result of so= me kind of human request, such as someone clicking a "Report Abuse" button = in a mail reader. In contrast, the mechanisms described in this memo are f= ocused around automated reporting. This obviously implies the potential fo= r much larger volumes or frequency of messages, and thus greater mail syste= m load (both for report generators and report receivers). =09 These mechanisms are primarily intended for use in generating reports to ai= d implementers of [DKIM] and [ADSP] and other related protocols in developm= ent and debugging. They are not intended for prolonged forensic use, speci= fically because of these load concerns. However, extended use is possible = by ADMDs that want to keep a close watch for fraud or infrastructure proble= ms. It is important to consider the impact of doing so on both report gene= rators and the requesting ADMDs. From msk@cloudmark.com Sat Feb 4 21:00:58 2012 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 C2F0C21F8507 for ; Sat, 4 Feb 2012 21:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Zzsb8WpbeOY for ; Sat, 4 Feb 2012 21:00:58 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCAE21F8508 for ; Sat, 4 Feb 2012 21:00:58 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 4 Feb 2012 21:00:58 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 4 Feb 2012 21:00:58 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Sat, 4 Feb 2012 21:01:03 -0800 Thread-Topic: [marf] Working Group Last Call on draft-ietf-marf-as-05 Thread-Index: AczinT+L6xS9A5BuQka1cAapM68R6wBJXYkg Message-ID: References: <87ADC923-77C1-4BBE-985D-77074026EDAE@wordtothewise.com> <20120203174238.310DEF58089@smtp.patriot.net> In-Reply-To: <20120203174238.310DEF58089@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 05 Feb 2012 05:00:58 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Friday, February 03, 2012 8:53 AM > To: marf@ietf.org > Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 >=20 > In <87ADC923-77C1-4BBE-985D-77074026EDAE@wordtothewise.com>, on > 02/02/2012 > at 12:35 PM, Steve Atkins said: >=20 > >I'm not against using ARF for unsolicited reports, I'm against sending > >unsolicited reports that aren't actionable by the recipient. >=20 > I'd suggest changing MAY to SHOULD in item 11 of 8. Generating and > Handling Unsolicited Reports. >=20 > 11. This is, however, not universally true. Anyone sending > unsolicited reports in ARF format can legitimately presume > that some recipients will not be able to see the ARF > metadata (e.g., those elements present in the second part of > the report), and instead SHOULD include all information > needed in the human readable (first, text/plain) section of > the report. Further, they MAY ensure that the report is > readable when viewed as plain text, to give low-end > ticketing systems as much assistance as possible. Finally, > they need to be aware that the report could be discarded or > ignored due to failure to take these steps in the > most extreme cases. >=20 > I fixed a couple of nits in the above; adding "some" and changing an > inappropriate "i.e." to "e.g.". I'm not sure whether the second MAY > should also be SHOULD. Agree with the "some". I think if you're going to change the first MAY to SHOULD, changing the sec= ond also makes sense. I agree with it, since interoperability is the goal,= so I've made the change, but of course consensus could disagree. "i.e." is correct rather than "e.g."; "i.e." means "that is", which is more= appropriate here than "e.g." which means "for example". What's in parenth= eses there is precise, not an example. Thanks, -MSK From sklist@kitterman.com Sat Feb 4 21:29:06 2012 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 9F08E21F8507 for ; Sat, 4 Feb 2012 21:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjPwtKRGcdMu for ; Sat, 4 Feb 2012 21:29:05 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A6ED821F84FF for ; Sat, 4 Feb 2012 21:29:05 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id EC39A20E40B7; Sun, 5 Feb 2012 00:29:03 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328419744; bh=ASNGx2dmw4OiMEewv8g56RWW+YZYkodS9k+RWMRWIRY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=o9k3FmWK8MFV80IlDVuecuYwahxJiNDmJgZFj9oZWLTgOdCI1Qf6y5ROY0kTIvptQ nMhDVQ5OfW70dUll2VkA0dj8IvA55TbGDGGZMkm4us7k6nrr5SIxB+7dJ1+0IeogXa CP9U5UHBMktsl2DUcwTCOlRIXUl7tdgdNohs69AE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id CBB7620E409F; Sun, 5 Feb 2012 00:29:03 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Sun, 05 Feb 2012 00:29:03 -0500 Message-ID: <2132281.WbfWs6XqNi@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120130193649.24837.53481.idtracker@ietfa.amsl.com> <3480646.curB61z5rG@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was -07 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, 05 Feb 2012 05:29:06 -0000 On Saturday, February 04, 2012 08:51:36 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Friday, February 03, 2012 2:05 PM > > To: marf@ietf.org > > Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was > > -07> > > On Friday, February 03, 2012 01:58:11 PM Murray S. Kucherawy wrote: > > > The mechanisms described in this memo are primarily intended > > > for use > > > in generating reports to aid implementers of [DKIM] and [ADSP] > > > and > > > other related protocols in development and debugging. They > > > are not > > > intended for prolonged forensic use. However, such uses are > > > possible by ADMDs that want to keep a close watch for fraud > > > or infrastructure problems. > > > > I probably missed a discussion about this sometime, but why isn't this > > intended for prolonged forensic use? The applications of ARF I've seen > > that's exactly what they are for. > > The difference to me is that conventional ARF (e.g., spam reports) are > almost always provoked by some human action, like clicking a Report Spam > button in a mail reader. These, by contrast, will almost always be > automatically generated. Perhaps we should say that, rather than what's > there now. > > I think the current language is also drawn from implementation experience. > It's akin, I suppose, to running a binary in production that has full > debugging symbols included to enable detailed debugging versus a stripped > binary that is leaner but harder to debug. Indeed, running a report > generator with all of this turned on can obviously cause drag on a mail > system when large and/or constant volumes of these reports are being sent > in addition to regular mail. > > So how about this to replace the above paragraph: > > ARF reports have historically been generated individually as a result of > some kind of human request, such as someone clicking a "Report Abuse" > button in a mail reader. In contrast, the mechanisms described in this > memo are focused around automated reporting. This obviously implies the > potential for much larger volumes or frequency of messages, and thus > greater mail system load (both for report generators and report receivers). > > These mechanisms are primarily intended for use in generating reports to aid > implementers of [DKIM] and [ADSP] and other related protocols in > development and debugging. They are not intended for prolonged forensic > use, specifically because of these load concerns. However, extended use is > possible by ADMDs that want to keep a close watch for fraud or > infrastructure problems. It is important to consider the impact of doing > so on both report generators and the requesting ADMDs. "not intended for prolonged"/"not generally intended for prolonged" and I think I'm happy. Scott K From msk@cloudmark.com Sat Feb 4 21:38:59 2012 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 9A66421F84D3 for ; Sat, 4 Feb 2012 21:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAp2l3Lyercn for ; Sat, 4 Feb 2012 21:38:58 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 58E2921F84B6 for ; Sat, 4 Feb 2012 21:38:58 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 4 Feb 2012 21:38:57 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sat, 4 Feb 2012 21:38:57 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sat, 4 Feb 2012 21:39:03 -0800 Thread-Topic: [marf] Working Group Last Call on draft-ietf-marf-as-05 Thread-Index: AcziW5g5IF8+puSnSC61S5lcxYw2NwBavqrw Message-ID: References: <6993547.EjUSn6dgaq@scott-latitude-e6320> <4DEC4C4E-7F56-44DE-B0D6-6900120D9263@wordtothewise.com> <2F430701-7B41-4F3B-ACC6-F2A302482304@wordtothewise.com> <4F2BB1AE.4020605@tana.it> In-Reply-To: <4F2BB1AE.4020605@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] Working Group Last Call on draft-ietf-marf-as-05 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, 05 Feb 2012 05:38:59 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Friday, February 03, 2012 2:07 AM > To: marf@ietf.org > Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 >=20 > > Less drastic suggestion, moving the discussion of unsolicited reports > > to it's own section, removing reference to Yahoo, mentioning that ARF > > reports can be crafted to be more text/plain friendly, adding a MUST > > allow unsubscribes, a few other minor tweaks and a moral at the end: >=20 > What was the reference to Yahoo? The stuff about a large service provider insisting that all abuse reports b= e ARF-formatted is a reference to Yahoo. > I'd add that sending unsolicited messages can be a way of initiating an > FBL. We already do say that later in the same section. > Advice that a message was delivered to a junk folder might be useful, > though. I think we won't get it even if we ask for it, so putting too > much emphasis on this point is worthless. However, perhaps it has to > be said that rejected messages must not be reported. I disagree, because that presumes a lot about what exactly "rejected" means= . I think we're fine with the current text. > > + Additionally, a report generator MUST provide a way for > > + a report recipient to request no further reports be sent > > + to them and MAY provide a way for recipients to change > > + the address(es) reports about them are sent to. >=20 > This latter part should go to a different paragraph. Perhaps near 12 > (replying to feedback). Replies may be mail- or web-based. It's enough to say "a way", I think. The method is unspecified, and that's= fine. > > @@ -311,19 +324,19 @@ > > originating customer. > > 10. Published abuse mailbox addresses SHOULD NOT reject messages n= ot > > in the ARF format, as generation of ARF messages can > > - occasionally be unavailable or not applicable. >=20 > Paragraph 10, for receivers, should terminate here. Do you think the rest of what's there now is incorrect? > The rest of paragraph 10 and paragraph 11 (for senders) are confusing > and need additional rewording, IMHO. Please provide substitute text. > > @@ -354,7 +367,16 @@ > > [snip] > > - > > + 14. Handling unsolicited reports has a significant cost to the > > + receiver. Senders of unsolicited reports, especially those > > + sending large volumes of them mechanically, need to be aware > > + of that and do all they reasonably can to avoid sending > > + reports that cannot be used as a basis for action by the > > + recipient - whether that is due to the report being sent > > + about an incident that isn't abuse-related, it being sent to > > + an email address that can't take action on it, or due to the > > + content or format of the report being hard for the recipient > > + to read or use. >=20 > Non-actionable reports could still be useful for collecting statistics, > whose evaluation may eventually result in a better sending. This is > especially true for spf- or dkim-reporting. I think this fits under "take action on it". > Should we say that the 3rd mime part of non-actionable reports should > be "text/rfc822-headers"? Why? -MSK From msk@cloudmark.com Sat Feb 4 21:40:10 2012 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 ECCFD21F84FA for ; Sat, 4 Feb 2012 21:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbtJU2OEnPLK for ; Sat, 4 Feb 2012 21:40:09 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF9221F84B6 for ; Sat, 4 Feb 2012 21:40:09 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 4 Feb 2012 21:40:07 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 4 Feb 2012 21:40:08 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sat, 4 Feb 2012 21:40:13 -0800 Thread-Topic: [marf] Working Group Last Call on draft-ietf-marf-as-05 Thread-Index: AczhwJQg0vbhmRSRRZ6zbjFSq11GUQCB/85Q Message-ID: References: <20120202153704.67577.qmail@joyce.lan> In-Reply-To: <20120202153704.67577.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 05 Feb 2012 05:40:10 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQHRhdWdoLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDAyLCAyMDEyIDc6 MzcgQU0NCj4gVG86IG1hcmZAaWV0Zi5vcmcNCj4gQ2M6IE11cnJheSBTLiBLdWNoZXJhd3kNCj4g U3ViamVjdDogUmU6IFttYXJmXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRm LW1hcmYtYXMtMDUNCj4gDQo+IEFzIGFuIGVkaXRvcmlhbCBzdWdnZXN0aW9uLCBJJ2Qgc3VnZ2Vz dCBjaGFuZ2luZyB0aGUgbnVtYmVyZWQgbGlzdHMgaW4NCj4gc2VjdGlvbnMgNi04IGJhY2sgdG8g cGxhaW4gcGFyYWdyYXBocyBzaW5jZSB0aGV5IGRvIG5vdCBkZXNjcmliZQ0KPiBzZXF1ZW5jZXMg b2YgdGhpbmdzIHRvIGRvIGluIG9yZGVyLiAgVGhlIG51bWJlcnMgaGF2ZSBiZWVuIGhhbmR5IGR1 cmluZw0KPiB0aGUgcmV2aXNpb24gcHJvY2VzcyB0byBpZGVudGlmeSB3aGF0IHdlJ3JlIGFyZ3Vp bmcgYWJvdXQsIHRob3VnaC4NCg0KU2VlbXMgcmVhc29uYWJsZTsgSSdsbCBsZWF2ZSB0aGVtIGlu IHVudGlsIElFVEYgTEMgZW5kcywgaW4gY2FzZSB3ZSBuZWVkIHRvIHVzZSB0aGVtIGZvciB0aGUg c2FtZSByZWFzb24uDQoNCi1NU0sNCg== From steve@wordtothewise.com Sat Feb 4 21:51:43 2012 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 0E3ED21F850F for ; Sat, 4 Feb 2012 21:51:43 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-Xoe4I9hA-7 for ; Sat, 4 Feb 2012 21:51:42 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 9722121F84DA for ; Sat, 4 Feb 2012 21:51:42 -0800 (PST) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id 28A1C2E192 for ; Sat, 4 Feb 2012 21:51:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Steve Atkins In-Reply-To: Date: Sat, 4 Feb 2012 21:51:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <32C4B3AE-F4AB-4344-AC8C-4B26A53EA04A@wordtothewise.com> References: <6993547.EjUSn6dgaq@scott-latitude-e6320> <4DEC4C4E-7F56-44DE-B0D6-6900120D9263@wordtothewise.com> <2F430701-7B41-4F3B-ACC6-F2A302482304@wordtothewise.com> <4F2BB1AE.4020605@tana.it> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1257) Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 05 Feb 2012 05:51:43 -0000 On Feb 4, 2012, at 9:39 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of Alessandro Vesely >>>=20 >>> + receiver. Senders of unsolicited reports, especially those >>> + sending large volumes of them mechanically, need to be = aware >>> + of that and do all they reasonably can to avoid sending >>> + reports that cannot be used as a basis for action by the >>> + recipient - whether that is due to the report being sent >>> + about an incident that isn't abuse-related, it being sent = to >>> + an email address that can't take action on it, or due to = the >>> + content or format of the report being hard for the = recipient >>> + to read or use. >>=20 >> Non-actionable reports could still be useful for collecting = statistics, >> whose evaluation may eventually result in a better sending. This is >> especially true for spf- or dkim-reporting. >=20 > I think this fits under "take action on it". I don't think so. If the report is not about an abusive behaviour on which the recipient of the report can take action, it's not something that should be sent unsolicited. If the recipient wants that sort of thing, they can ask for it. (And if they've not asked for it then the non-actionable reports you're sending are just ARF-formatted spam). Cheers, Steve= From msk@cloudmark.com Sat Feb 4 21:54:46 2012 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 A4B8B21F8514 for ; Sat, 4 Feb 2012 21:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRHVntE5-8VD for ; Sat, 4 Feb 2012 21:54:45 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 52EFD21F84DA for ; Sat, 4 Feb 2012 21:54:45 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 4 Feb 2012 21:54:44 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sat, 4 Feb 2012 21:54:44 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Sat, 4 Feb 2012 21:54:50 -0800 Thread-Topic: [marf] Working Group Last Call on draft-ietf-marf-as-05 Thread-Index: Aczh6kNXz+xNdyLAS/2TTaeuqV1k9wB3tFhg Message-ID: References: <6993547.EjUSn6dgaq@scott-latitude-e6320> <4DEC4C4E-7F56-44DE-B0D6-6900120D9263@wordtothewise.com> <2F430701-7B41-4F3B-ACC6-F2A302482304@wordtothewise.com> In-Reply-To: <2F430701-7B41-4F3B-ACC6-F2A302482304@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] Working Group Last Call on draft-ietf-marf-as-05 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, 05 Feb 2012 05:54:46 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= teve Atkins > Sent: Thursday, February 02, 2012 12:36 PM > To: Message Abuse Report Format working group > Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 >=20 > Less drastic suggestion, moving the discussion of unsolicited reports > to it's own section, removing reference to Yahoo, mentioning that ARF > reports can be crafted to be more text/plain friendly, adding a MUST > allow unsubscribes, a few other minor tweaks and a moral at the end: Thanks, Steve. I've included much of what you've said in this part with so= me minor copy editing for the new version. I think it largely cleans up th= e presentation and says things a little better than how we had them. -MSK From msk@cloudmark.com Sat Feb 4 22:01:41 2012 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 9DC0F21F851E for ; Sat, 4 Feb 2012 22:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQ3-SslFp3N2 for ; Sat, 4 Feb 2012 22:01:41 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3018621F8514 for ; Sat, 4 Feb 2012 22:01:41 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 4 Feb 2012 22:01:40 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 4 Feb 2012 22:01:41 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Sat, 4 Feb 2012 22:01:46 -0800 Thread-Topic: [marf] Working Group Last Call on draft-ietf-marf-as-05 Thread-Index: AczjykKDr83cUBTUQJi65tS7ucDcLwAAHtuw Message-ID: References: <6993547.EjUSn6dgaq@scott-latitude-e6320> <4DEC4C4E-7F56-44DE-B0D6-6900120D9263@wordtothewise.com> <2F430701-7B41-4F3B-ACC6-F2A302482304@wordtothewise.com> <4F2BB1AE.4020605@tana.it> <32C4B3AE-F4AB-4344-AC8C-4B26A53EA04A@wordtothewise.com> In-Reply-To: <32C4B3AE-F4AB-4344-AC8C-4B26A53EA04A@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] Working Group Last Call on draft-ietf-marf-as-05 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, 05 Feb 2012 06:01:41 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= teve Atkins > Sent: Saturday, February 04, 2012 9:52 PM > To: Message Abuse Report Format working group > Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 >=20 > >> Non-actionable reports could still be useful for collecting > >> statistics, whose evaluation may eventually result in a better > >> sending. This is especially true for spf- or dkim-reporting. > > > > I think this fits under "take action on it". >=20 > I don't think so. If the report is not about an abusive behaviour on > which the recipient of the report can take action, it's not something > that should be sent unsolicited. >=20 > If the recipient wants that sort of thing, they can ask for it. (And if > they've not asked for it then the non-actionable reports you're sending > are just ARF-formatted spam). I think we're agreeing, really. What I'm trying to avoid is having the AS = turn into a cookbook of 101 Things You Could Do With ARF Reports Maybe. I = think we should present the most common use cases based on experience, and = leave it at that, without going into navel-gazing about all sorts of neat w= ays they might be useful someday. From msk@cloudmark.com Sat Feb 4 22:07:14 2012 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 D47BB21F8523 for ; Sat, 4 Feb 2012 22:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWWbd7tW91tN for ; Sat, 4 Feb 2012 22:07:14 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE5E21F8514 for ; Sat, 4 Feb 2012 22:07:14 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 4 Feb 2012 22:07:13 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sat, 4 Feb 2012 22:07:13 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Sat, 4 Feb 2012 22:07:19 -0800 Thread-Topic: [marf] Working Group Last Call on draft-ietf-marf-as-05 Thread-Index: Aczig6u2E5Ng7znFQKqgxfK+q8lhYABSAk4A Message-ID: References: <7DEB0B04-2161-4FA4-8B86-E004CCB3085B@wordtothewise.com> <20120203142239.85582F58083@smtp.patriot.net> In-Reply-To: <20120203142239.85582F58083@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 05 Feb 2012 06:07:15 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Thursday, February 02, 2012 3:26 AM > To: marf@ietf.org > Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 >=20 > >Probably, yes - while on the modern net it would probably make much > >more sense to centralize most the processing and decision making, >=20 > I agree, but in the short run there will continue to be providers that > don't provide that function. >=20 > >I think anyone developing an MUA to do that sort of thing would either > >deeply understand this document and read it from an appropriate > >perspective, or not understand it and need to be restrained from doing > >anything along these lines. >=20 > The refusal of, e.g., yahoo, to accept plain text complaints provides > an incentive for MUA authors to write such tools. Given the number of > e-mail clients that are broken in one way or another, I'd rather see > some guidance in an RFC before the avalanche starts. Restraining the > MUA authors is not feasible. What do others think about this point? Given the number of direct complain= ts John, Yakov and I got from Yahoo members when Yahoo decided to accept on= ly ARF reports, it seems like we might be able to say we have experience th= at this creates a big problem for a lot of people. And it's true that soft= ware to generate ARFs will start appearing, if it hasn't already. That said, I don't think we need to talk specifically about MUAs sending ab= use reports. It seems to me any advice we have for them is the same as the= advice we're already giving to report generators. Why would it be any dif= ferent? -MSK From msk@cloudmark.com Sat Feb 4 22:09:54 2012 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 ACADC21F852D for ; Sat, 4 Feb 2012 22:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmEMqoGmBPqe for ; Sat, 4 Feb 2012 22:09:52 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id A546421F8528 for ; Sat, 4 Feb 2012 22:09:51 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 4 Feb 2012 22:09:49 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 4 Feb 2012 22:09:50 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sat, 4 Feb 2012 22:09:55 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was -07 Thread-Index: AczjxxZdIHw3uyzBSJmOqGuvEaiXdwABaEgw Message-ID: References: <20120130193649.24837.53481.idtracker@ietfa.amsl.com> <3480646.curB61z5rG@scott-latitude-e6320> <2132281.WbfWs6XqNi@scott-latitude-e6320> In-Reply-To: <2132281.WbfWs6XqNi@scott-latitude-e6320> 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-dkim-reporting-08, was -07 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, 05 Feb 2012 06:09:54 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Saturday, February 04, 2012 9:29 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was -0= 7 >=20 > "not intended for prolonged"/"not generally intended for prolonged" and > I think I'm happy. Sold. -MSK From sklist@kitterman.com Sat Feb 4 22:10:56 2012 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 8961E21F8528 for ; Sat, 4 Feb 2012 22:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhI9OFUY843t for ; Sat, 4 Feb 2012 22:10:55 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 497DB21F8526 for ; Sat, 4 Feb 2012 22:10:55 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B960B20E40B7; Sun, 5 Feb 2012 01:10:54 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328422254; bh=u+IzcW3JbplpPjCg5jM6NrsvmekPSvgi47+pi2gBIzQ=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=m8fAv5Iuxt/vk/RxU2MEKTWAYiBlTwSBiVIYLilkZZ5uSg1c8bpqIijHV756eO/mM AIwDOk7liM44k+KK5fNhYK7xdnvlpi+rokTO96dVzanqOCixWl3irNlPIm89hqcr61 K9UdyTTzMV4/XRxnid3X7UUMj4Oxd4lJeUuhcHRY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9E9E120E409F; Sun, 5 Feb 2012 01:10:54 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Sun, 05 Feb 2012 01:10:53 -0500 Message-ID: <18200969.C6yHtmV1Pa@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <7DEB0B04-2161-4FA4-8B86-E004CCB3085B@wordtothewise.com> <20120203142239.85582F58083@smtp.patriot.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 05 Feb 2012 06:10:56 -0000 On Saturday, February 04, 2012 10:07:19 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Shmuel Metz Sent: Thursday, February 02, 2012 3:26 AM > > To: marf@ietf.org > > Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 > > > > >Probably, yes - while on the modern net it would probably make much > > >more sense to centralize most the processing and decision making, > > > > I agree, but in the short run there will continue to be providers that > > don't provide that function. > > > > >I think anyone developing an MUA to do that sort of thing would either > > >deeply understand this document and read it from an appropriate > > >perspective, or not understand it and need to be restrained from doing > > >anything along these lines. > > > > The refusal of, e.g., yahoo, to accept plain text complaints provides > > an incentive for MUA authors to write such tools. Given the number of > > e-mail clients that are broken in one way or another, I'd rather see > > some guidance in an RFC before the avalanche starts. Restraining the > > MUA authors is not feasible. > > What do others think about this point? Given the number of direct > complaints John, Yakov and I got from Yahoo members when Yahoo decided to > accept only ARF reports, it seems like we might be able to say we have > experience that this creates a big problem for a lot of people. And it's > true that software to generate ARFs will start appearing, if it hasn't > already. > > That said, I don't think we need to talk specifically about MUAs sending > abuse reports. It seems to me any advice we have for them is the same as > the advice we're already giving to report generators. Why would it be any > different? I don't think it would be different. Scott K From steve@wordtothewise.com Sat Feb 4 22:13:51 2012 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 29E3F21F8523 for ; Sat, 4 Feb 2012 22:13:51 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQETuzTSRo0l for ; Sat, 4 Feb 2012 22:13:50 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB9421F8507 for ; Sat, 4 Feb 2012 22:13:50 -0800 (PST) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id 0A8B92EADE for ; Sat, 4 Feb 2012 22:13:50 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Steve Atkins In-Reply-To: Date: Sat, 4 Feb 2012 22:13:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4BD8F6FC-FFE6-4D41-9487-26452F61DCED@wordtothewise.com> References: <6993547.EjUSn6dgaq@scott-latitude-e6320> <4DEC4C4E-7F56-44DE-B0D6-6900120D9263@wordtothewise.com> <2F430701-7B41-4F3B-ACC6-F2A302482304@wordtothewise.com> <4F2BB1AE.4020605@tana.it> <32C4B3AE-F4AB-4344-AC8C-4B26A53EA04A@wordtothewise.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1257) Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 05 Feb 2012 06:13:51 -0000 On Feb 4, 2012, at 10:01 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of Steve Atkins >> Sent: Saturday, February 04, 2012 9:52 PM >> To: Message Abuse Report Format working group >> Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 >>=20 >>>> Non-actionable reports could still be useful for collecting >>>> statistics, whose evaluation may eventually result in a better >>>> sending. This is especially true for spf- or dkim-reporting. >>>=20 >>> I think this fits under "take action on it". >>=20 >> I don't think so. If the report is not about an abusive behaviour on >> which the recipient of the report can take action, it's not something >> that should be sent unsolicited. >>=20 >> If the recipient wants that sort of thing, they can ask for it. (And = if >> they've not asked for it then the non-actionable reports you're = sending >> are just ARF-formatted spam). >=20 > I think we're agreeing, really. What I'm trying to avoid is having = the AS turn into a cookbook of 101 Things You Could Do With ARF Reports = Maybe. I think we should present the most common use cases based on = experience, and leave it at that, without going into navel-gazing about = all sorts of neat ways they might be useful someday. +1 for the ARF format in general, sure. For unsolicited reports there's something stronger - If the report is = about something that's not actionable by an abuse desk, it shouldn't be = sent unsolicited. "evaluation may eventually result in a better sending." is a = deliverability issue, not an abuse issue. Interesting to some people, = sure, but something delivery@ should opt-in to not something = abuse@everywhere should have to opt-out of. Cheers, Steve From msk@cloudmark.com Sat Feb 4 22:25:46 2012 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 A0A2821F8526 for ; Sat, 4 Feb 2012 22:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36M8dNymx3Eo for ; Sat, 4 Feb 2012 22:25:46 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 352D321F851D for ; Sat, 4 Feb 2012 22:25:46 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 4 Feb 2012 22:25:45 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sat, 4 Feb 2012 22:25:45 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sat, 4 Feb 2012 22:25:51 -0800 Thread-Topic: [marf] Change request for AS, was Working Group Last Call on draft-ietf-marf-as-05 Thread-Index: Aczh2roECdBgBcHzQjetXXoFpZAmkQB8qbvA Message-ID: References: <4F291ECD.9040308@tana.it> <4F2AD991.8050508@tana.it> In-Reply-To: <4F2AD991.8050508@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] Change request for AS, was Working Group Last Call on draft-ietf-marf-as-05 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, 05 Feb 2012 06:25:46 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Thursday, February 02, 2012 10:45 AM > To: marf@ietf.org > Subject: [marf] Change request for AS, was Working Group Last Call on dra= ft-ietf-marf-as-05 >=20 > At the risk of being proposed for a treatment, I retract my post and > ask that a new section be added to marf-as, about loop avoidance and > control of flow. >=20 > The new section would cover FBL traffic details such as using VERP and > replying 552, which are to be used by all of dkim-reporting, spf- > reporting, and reporting-discovery. Read more on, e.g. > http://www.ietf.org/mail-archive/web/marf/current/msg01910.html I support the idea of common-factoring what's in draft-ietf-marf-dkim-repor= ting-08, Section 6 and Sections 8.4 through 8.6, and parallel text in draft= -ietf-marf-spf-reporting, or very similar text, into the AS. The AS is sup= posed to be a statement of "this is how we suggest you use ARF" and those s= trike me as reasonable things to include in such a document even without th= e reporting drafts. Do others agree? If people don't like that idea, then I would instead suggest at least remov= ing them from one of the two -reporting drafts and having that one referenc= e the other one. I'm not too keen on the exact same text appearing in two = documents if we can avoid it. Again, do others agree? I don't (currently) agree that the rest of the suggestions at that URL part= icularly benefit either of the documents. Others should chime in on this p= oint as well. -MSK From steve@wordtothewise.com Sat Feb 4 22:54:25 2012 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 F113321F853D for ; Sat, 4 Feb 2012 22:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-IwwiUCNMRg for ; Sat, 4 Feb 2012 22:54:25 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 78E3E21F853A for ; Sat, 4 Feb 2012 22:54:25 -0800 (PST) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id 3AAAC2E185 for ; Sat, 4 Feb 2012 22:54:25 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Steve Atkins In-Reply-To: Date: Sat, 4 Feb 2012 22:54:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <48E6B374-95D2-4BC9-8794-50465B6455A2@wordtothewise.com> References: <4F291ECD.9040308@tana.it> <4F2AD991.8050508@tana.it> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1257) Subject: Re: [marf] Change request for AS, was Working Group Last Call on draft-ietf-marf-as-05 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, 05 Feb 2012 06:54:26 -0000 On Feb 4, 2012, at 10:25 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of Alessandro Vesely >> Sent: Thursday, February 02, 2012 10:45 AM >> To: marf@ietf.org >> Subject: [marf] Change request for AS, was Working Group Last Call on = draft-ietf-marf-as-05 >>=20 >> At the risk of being proposed for a treatment, I retract my post and >> ask that a new section be added to marf-as, about loop avoidance and >> control of flow. >>=20 >> The new section would cover FBL traffic details such as using VERP = and >> replying 552, which are to be used by all of dkim-reporting, spf- >> reporting, and reporting-discovery. Read more on, e.g. >> http://www.ietf.org/mail-archive/web/marf/current/msg01910.html >=20 > I support the idea of common-factoring what's in = draft-ietf-marf-dkim-reporting-08, Section 6 and Sections 8.4 through = 8.6, and parallel text in draft-ietf-marf-spf-reporting, or very similar = text, into the AS. The AS is supposed to be a statement of "this is how = we suggest you use ARF" and those strike me as reasonable things to = include in such a document even without the reporting drafts. Do others = agree? Is the thought to add them to the AS document as a section on how to = craft and send an ARF message that's being used for SPF or DKIM failure = feedback? Or as something that's more generally applicable to all ARF = usage? Or something in-between - FBL best practices, say? (Also, if we're going to do that, should we reference 3834 - = Auto-Submitted and all that - as well / instead?) It does seem to make more sense to have them both referencing a base = "reporting auth failures" document that covers the common requirements = rather than referencing each other, whether that base doc is = draft-ietf-marf-as or not. > If people don't like that idea, then I would instead suggest at least = removing them from one of the two -reporting drafts and having that one = reference the other one. I'm not too keen on the exact same text = appearing in two documents if we can avoid it. Again, do others agree? Yes. > I don't (currently) agree that the rest of the suggestions at that URL = particularly benefit either of the documents. Others should chime in on = this point as well. Cheers, Steve From msk@cloudmark.com Sat Feb 4 23:27:22 2012 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 0E46421F8474 for ; Sat, 4 Feb 2012 23:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoFTlhatxR0r for ; Sat, 4 Feb 2012 23:27:21 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 91AFE21F847A for ; Sat, 4 Feb 2012 23:27:21 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 4 Feb 2012 23:27:20 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 4 Feb 2012 23:27:19 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Sat, 4 Feb 2012 23:27:25 -0800 Thread-Topic: [marf] Change request for AS, was Working Group Last Call on draft-ietf-marf-as-05 Thread-Index: Aczj0wF9wb5BE70JQze8Og13gSnr0AABCqyQ Message-ID: References: <4F291ECD.9040308@tana.it> <4F2AD991.8050508@tana.it> <48E6B374-95D2-4BC9-8794-50465B6455A2@wordtothewise.com> In-Reply-To: <48E6B374-95D2-4BC9-8794-50465B6455A2@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] Change request for AS, was Working Group Last Call on draft-ietf-marf-as-05 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, 05 Feb 2012 07:27:22 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= teve Atkins > Sent: Saturday, February 04, 2012 10:54 PM > To: Message Abuse Report Format working group > Subject: Re: [marf] Change request for AS, was Working Group Last Call on= draft-ietf-marf-as-05 >=20 > Is the thought to add them to the AS document as a section on how to > craft and send an ARF message that's being used for SPF or DKIM failure > feedback? Or as something that's more generally applicable to all ARF > usage? Or something in-between - FBL best practices, say? >=20 > (Also, if we're going to do that, should we reference 3834 - Auto- > Submitted and all that - as well / instead?) >=20 > It does seem to make more sense to have them both referencing a base > "reporting auth failures" document that covers the common requirements > rather than referencing each other, whether that base doc is draft- > ietf-marf-as or not. It seems to me what's in Section 6 is good advice for any ARF generation ca= se. What's in DKIM reporting's 8.4-8.6 would go under a section that talks abou= t any kind of automated reporting, with authentication failure reporting as= the prime example. The two reporting drafts would then reference the AS i= nstead of including those sections themselves, and the AS could reference t= hem as use cases. That would turn them into a document cluster, but that's= not a big deal; it just means they are published simultaneously with seque= ntial RFC numbers. -MSK From steve@wordtothewise.com Sun Feb 5 00:06:52 2012 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 4C2A221F854F for ; Sun, 5 Feb 2012 00:06:52 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YV07QKx7GwW for ; Sun, 5 Feb 2012 00:06:51 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id A4BBB21F854E for ; Sun, 5 Feb 2012 00:06:51 -0800 (PST) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id 3925B2E192 for ; Sun, 5 Feb 2012 00:06:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Steve Atkins In-Reply-To: Date: Sun, 5 Feb 2012 00:06:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2A6B561A-FFD5-4B87-A5F2-CC157EFFA08A@wordtothewise.com> References: <4F291ECD.9040308@tana.it> <4F2AD991.8050508@tana.it> <48E6B374-95D2-4BC9-8794-50465B6455A2@wordtothewise.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1257) Subject: Re: [marf] Change request for AS, was Working Group Last Call on draft-ietf-marf-as-05 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, 05 Feb 2012 08:06:52 -0000 On Feb 4, 2012, at 11:27 PM, Murray S. Kucherawy wrote: >> Is the thought to add them to the AS document as a section on how to >> craft and send an ARF message that's being used for SPF or DKIM = failure >> feedback? Or as something that's more generally applicable to all ARF >> usage? Or something in-between - FBL best practices, say? >>=20 >> (Also, if we're going to do that, should we reference 3834 - Auto- >> Submitted and all that - as well / instead?) >>=20 >> It does seem to make more sense to have them both referencing a base >> "reporting auth failures" document that covers the common = requirements >> rather than referencing each other, whether that base doc is draft- >> ietf-marf-as or not. >=20 > It seems to me what's in Section 6 is good advice for any ARF = generation case. 6.3 isn't bad advice, but the justification of some of it is rather = specific to authentication failure reporting. Do we want to mandate that = anyone sending ARF reports of any sort MUST also publish SPF records or = send them with a NULL envelope sender? That requirement isn't = unreasonable in the case where you're talking about reports sent in = response to an authentication failure, where avoiding an authentication = failure in response to a report of authentication failure is a = reasonably belt-and-braces way to help avoid a mail loop - but beyond = that narrow scope it seems a bit of a reach. There are people who = consider SPF irrecoverably broken, yet still offer feedback loops. > What's in DKIM reporting's 8.4-8.6 would go under a section that talks = about any kind of automated reporting, with authentication failure = reporting as the prime example. =20 Some of it is specific to authentication failure reporting. As for the = rest of it, are they security concerns that should be discussed in = marf-as regardless of whether the DKIM/SPF docs want to reference them? = I'm thinking yes. And (I'm going to regret asking this, I'm sure) where does = draft-ietf-marf-authfailure come into this? It has much the same = security statements and is already referenced by the SPF and DKIM = failure drafts, I think. > The two reporting drafts would then reference the AS instead of = including those sections themselves, and the AS could reference them as = use cases. That would turn them into a document cluster, but that's not = a big deal; it just means they are published simultaneously with = sequential RFC numbers. Cheers, Steve= From vesely@tana.it Sun Feb 5 03:43:01 2012 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 3595721F852B for ; Sun, 5 Feb 2012 03:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.645 X-Spam-Level: X-Spam-Status: No, score=-4.645 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMdfBIQLAdrQ for ; Sun, 5 Feb 2012 03:43:00 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5B64A21F8526 for ; Sun, 5 Feb 2012 03:43:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328442178; bh=mVrPoxkJrp0e1mGMX6MIsj/Vo696f3Hf+tBQDF5QJIQ=; l=369; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=icopFSRGgNkhntHhHxYG8bP0h5N0NdCwcZyOXXm9IQNuyvOWkYG6FiznBB4lUV20n UJuQUL3WwFh7lXs4LxRf/X9Fv4aWPqdvbDoyh6tZiyY0HqVDtYLz5ptS/Sw8+CMFUc TVrVsLkIbG2QgKT715KE6+3stF7XiWZJ9mTQaM/0= 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, 05 Feb 2012 12:42:58 +0100 id 00000000005DC039.000000004F2E6B42.000050D6 Message-ID: <4F2E6B42.9050406@tana.it> Date: Sun, 05 Feb 2012 12:42:58 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120130193649.24837.53481.idtracker@ietfa.amsl.com> <3480646.curB61z5rG@scott-latitude-e6320> <2132281.WbfWs6XqNi@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was -07 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, 05 Feb 2012 11:43:01 -0000 On 05/Feb/12 07:09, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Scott Kitterman > >> "not intended for prolonged"/"not generally intended for prolonged" and >> I think I'm happy. > > Sold. Hm... I'm neutral on that. Actually, I'd like a report generator to be useful for both full-detail verbose debugging and lightweight advisory statistics. From vesely@tana.it Sun Feb 5 04:40:13 2012 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 4D94A21F84F1 for ; Sun, 5 Feb 2012 04:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.646 X-Spam-Level: X-Spam-Status: No, score=-4.646 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iRh7lsURBEc for ; Sun, 5 Feb 2012 04:40:12 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6952921F849C for ; Sun, 5 Feb 2012 04:40:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328445609; bh=q9dnsrf1no5Zb/JD76tkabMYewrVrc0bAtq6o6rwcTo=; l=2030; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=G+x37iaDLdN0ROarU/B9mAbTyu3Z7hJfD1XV3TxIFIoqSeiyw2BauaMZDuO16O06/ V3F85V9SFKGm+xLTs+6nSz7pBt3ATWlHYKX4zdS9Haksyq09zc5YpGMHzav69X8YZb gSKcgrJzOWM2f5CwgveLx31secwZ9QMAbIYe/o94= 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, 05 Feb 2012 13:40:09 +0100 id 00000000005DC039.000000004F2E78A9.00005CD2 Message-ID: <4F2E78A9.103@tana.it> Date: Sun, 05 Feb 2012 13:40:09 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <6993547.EjUSn6dgaq@scott-latitude-e6320> <4DEC4C4E-7F56-44DE-B0D6-6900120D9263@wordtothewise.com> <2F430701-7B41-4F3B-ACC6-F2A302482304@wordtothewise.com> <4F2BB1AE.4020605@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 05 Feb 2012 12:40:13 -0000 On 05/Feb/12 06:39, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely > >>> @@ -311,19 +324,19 @@ >>> >>> 10. Published abuse mailbox addresses SHOULD NOT reject messages not >>> in the ARF format, as generation of ARF messages can >>> - occasionally be unavailable or not applicable. >> >> Paragraph 10, for receivers, should terminate here. > > Do you think the rest of what's there now is incorrect? It is not incorrect, it is in the wrong paragraph. Indeed, paragraph 11 starts with "This is" as a want to be a continuation of #10. >> The rest of paragraph 10 and paragraph 11 (for senders) are confusing >> and need additional rewording, IMHO. > > Please provide substitute text. Experience suggests use of ARF is advisable in most contexts. Automated recipient systems can handle abuse reports sent in ARF format at least as well as any other format such as plain text, with or without a copy of the message attached. That holds even for systems that didn't ask for ARF format reports, provided that reports are generated with use by recipients not using automated ARF parsing in mind. Anyone sending unsolicited reports in ARF format can legitimately presume that recipients will only be able to access the human readable (first, text/plain) part of it, and MAY include all information needed also in this part. Further, they MAY ensure that the report is readable when viewed as plain text, to give low-end ticketing systems as much assistance as possible. >> Non-actionable reports could still be useful for collecting >> statistics, whose evaluation may eventually result in a better >> sending. This is especially true for spf- or dkim-reporting. > > I think this fits under "take action on it". Yes, in a slightly indirect sense. BTW, publishing a _report address /is/ opt-in, isn't it? >> Should we say that the 3rd mime part of non-actionable reports should >> be "text/rfc822-headers"? > > Why? To be more lightweight. From sklist@kitterman.com Sun Feb 5 07:21:52 2012 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 3713821F858A for ; Sun, 5 Feb 2012 07:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlWF7kNhiG2p for ; Sun, 5 Feb 2012 07:21:51 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 930B221F8589 for ; Sun, 5 Feb 2012 07:21:51 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 84B6CD0407F; Sun, 5 Feb 2012 09:21:50 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328455310; bh=gD1z9TpD16pZAar6MJFWOFiJVYVN9ngAhhiRlq04AzQ=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=nn71AcpsteDIjGKSE1Ma2ujcU2m5MJgNfSZ1t/vMtICyLwPVGVSCC5P4OccRBIEO5 FqcW8UfPYSibZZBuBQ5oGrbtfruerxfa5m0TaoqdfsQPL3snW47FoLiL6do9Rny5Zq mNyOX0M2KDL0/2tEDiRQNaJY4KdXEetxS4UWHBl0= Received: from 143.sub-97-243-156.myvzw.com (143.sub-97-243-156.myvzw.com [97.243.156.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id EB59CD04042; Sun, 5 Feb 2012 09:21:49 -0600 (CST) References: <20120130193649.24837.53481.idtracker@ietfa.amsl.com> <3480646.curB61z5rG@scott-latitude-e6320> <2132281.WbfWs6XqNi@scott-latitude-e6320> <4F2E6B42.9050406@tana.it> User-Agent: K-9 Mail for Android In-Reply-To: <4F2E6B42.9050406@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sun, 05 Feb 2012 10:21:52 -0500 To: marf@ietf.org Message-ID: <55136ac6-9982-4f0b-884d-313356e0f752@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was -07 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, 05 Feb 2012 15:21:52 -0000 Alessandro Vesely On 05/Feb/12 07:09, Murray S. Kucherawy wrote: >>> From: ietf.org On Behalf Of Scott Kitterman >> >>> "not intended for prolonged"/"not generally intended for prolonged" >and >>> I think I'm happy. >> >> Sold. > >Hm... I'm neutral on that. Actually, I'd like a report generator to >be useful for both full-detail verbose debugging and lightweight >advisory statistics. I think the wording allows for that. Scott K From barryleiba.mailing.lists@gmail.com Sun Feb 5 07:26:36 2012 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 45EE021F8589 for ; Sun, 5 Feb 2012 07:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.938 X-Spam-Level: X-Spam-Status: No, score=-102.938 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFTwB6wtW+nh for ; Sun, 5 Feb 2012 07:26:35 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id BEE0821F8547 for ; Sun, 5 Feb 2012 07:26:35 -0800 (PST) Received: by ghbg16 with SMTP id g16so2603881ghb.31 for ; Sun, 05 Feb 2012 07:26:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Z4iQeWA6kcZuDorE5isqdBh6nGdpKW1rDJFiNYtTgx4=; b=llvcvuRS6k0BHcYNRledVinnkQgQCtuQq1dGW/Y4tdeJ7vzJvI8R1u4J8SIFB1UV5y 5scopjsKiTFmtvYBduEhDUyCoFQSBUbC6KVVcZUWnqPmV2zZDFK9ba+QSIbnr65i0CNc GUIsHyoFOXY33/z3dxoyeELam35L9iUCV0LdA= MIME-Version: 1.0 Received: by 10.236.124.69 with SMTP id w45mr20024668yhh.57.1328455595349; Sun, 05 Feb 2012 07:26:35 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Sun, 5 Feb 2012 07:26:35 -0800 (PST) In-Reply-To: References: <20120202153704.67577.qmail@joyce.lan> Date: Sun, 5 Feb 2012 10:26:35 -0500 X-Google-Sender-Auth: 9CWpAjG310z3BUSe6hxV3ZzvjwM Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=20cf300e5415dc557a04b8392b07 Cc: "marf@ietf.org" Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 05 Feb 2012 15:26:36 -0000 --20cf300e5415dc557a04b8392b07 Content-Type: text/plain; charset=ISO-8859-1 >> As an editorial suggestion, I'd suggest changing the numbered lists in >> sections 6-8 back to plain paragraphs since they do not describe >> sequences of things to do in order. The numbers have been handy during >> the revision process to identify what we're arguing about, though. > > Seems reasonable; I'll leave them in until IETF LC ends, in case we need > to use them for the same reason. If we inten to remove them, I suggest adding a note before each that says something like this: [These numbered items are not intended to be in a paricular sequence. The numbers are here during document development to make it easier to idenify the items for discussion, and will be removed before publication.] Barry --20cf300e5415dc557a04b8392b07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >> As an editorial suggestion, I'd suggest changing the numbered = lists in
>> sections 6-8 back to plain paragraphs since they do no= t describe
>> sequences of things to do in order. =A0The numbers h= ave been handy during
>> the revision process to identify what we're arguing about, tho= ugh.
>
> Seems reasonable; I'll leave them in until IETF LC= ends, in case we need
> to use them for the same reason.

If we inten to remove them, I suggest adding a note before each that says s= omething like this:

[These numbered items are not intended to be in = a paricular sequence. =A0The numbers are here during document development t= o make it easier to idenify the items for discussion, and will be removed b= efore publication.]

Barry
--20cf300e5415dc557a04b8392b07-- From sklist@kitterman.com Sun Feb 5 07:30:30 2012 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 030DE21F8589 for ; Sun, 5 Feb 2012 07:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vj7QrBC4Jf81 for ; Sun, 5 Feb 2012 07:30:29 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id ECF2621F8585 for ; Sun, 5 Feb 2012 07:30:28 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 7CA67D0407F; Sun, 5 Feb 2012 09:30:28 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328455828; bh=MAD78WnOFdQCtSf/AUai7e2vFnOyMso7vEjICMVRdTw=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=eXyEQTWFwCHhXFd3tXugTtMP57vlnzh73XhyhlzVwt5zVP9MX+8NIXsmd56fqmjrk RDdhA7NY6ZZaGiy8j2FyImGZ7dKoLzSHondbf6sFumPcVmgEtohBT8wSIGzm/hnpew Zs7/78MMWvU6FJxFnrMmF3fLKMlfhE77FmmIuU8E= Received: from 143.sub-97-243-156.myvzw.com (143.sub-97-243-156.myvzw.com [97.243.156.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 4C53CD0400D; Sun, 5 Feb 2012 09:30:27 -0600 (CST) References: <4F291ECD.9040308@tana.it> <4F2AD991.8050508@tana.it> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sun, 05 Feb 2012 10:30:33 -0500 To: "marf@ietf.org" Message-ID: <7cda5459-7aca-4296-9ddf-d2337d06883a@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Change request for AS, was Working Group Last Call on draft-ietf-marf-as-05 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, 05 Feb 2012 15:30:30 -0000 "Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf >Of Alessandro Vesely >> Sent: Thursday, February 02, 2012 10:45 AM >> To: marf@ietf.org >> Subject: [marf] Change request for AS, was Working Group Last Call on >draft-ietf-marf-as-05 >> >> At the risk of being proposed for a treatment, I retract my post and >> ask that a new section be added to marf-as, about loop avoidance and >> control of flow. >> >> The new section would cover FBL traffic details such as using VERP >and >> replying 552, which are to be used by all of dkim-reporting, spf- >> reporting, and reporting-discovery. Read more on, e.g. >> http://www.ietf.org/mail-archive/web/marf/current/msg01910.html > >I support the idea of common-factoring what's in >draft-ietf-marf-dkim-reporting-08, Section 6 and Sections 8.4 through >8.6, and parallel text in draft-ietf-marf-spf-reporting, or very >similar text, into the AS. The AS is supposed to be a statement of >"this is how we suggest you use ARF" and those strike me as reasonable >things to include in such a document even without the reporting drafts. > Do others agree? > >If people don't like that idea, then I would instead suggest at least >removing them from one of the two -reporting drafts and having that one >reference the other one. I'm not too keen on the exact same text >appearing in two documents if we can avoid it. Again, do others agree? > >I don't (currently) agree that the rest of the suggestions at that URL >particularly benefit either of the documents. Others should chime in >on this point as well. I think the auth failure draft would have been the one to factor it into. Adding the AS draft into the mix of the various auth failure drafts will confuse things. The auth failure and AS use cases are orthogonal in some respects. They overlap, but are definitely different. Scott K From shmuel+gen@patriot.net Sun Feb 5 07:48:21 2012 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 B323921F8577 for ; Sun, 5 Feb 2012 07:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[AWL=-0.759, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nga6NMgzGzLD for ; Sun, 5 Feb 2012 07:48:21 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1261521F8576 for ; Sun, 5 Feb 2012 07:48:21 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.25]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 3A2CFF58089 for ; Sun, 5 Feb 2012 10:33:51 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Sun, 05 Feb 2012 08:29:23 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120205153352.3A2CFF58089@smtp.patriot.net> Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 05 Feb 2012 15:48:21 -0000 In , on 02/04/2012 at 10:07 PM, "Murray S. Kucherawy" said: >What do others think about this point? Given the number of direct >complaints John, Yakov and I got from Yahoo members when Yahoo >decided to accept only ARF reports, it seems like we might be able to >say we have experience that this creates a big problem for a lot of >people. "The avalanche has already started; it is too late for the pebbles to vote." I agree that the exerience is already here and that we should take note of it. >And it's true that software to generate ARFs will start appearing, >if it hasn't already. It's on my todo list[1], and I'd be astonished if there weren't many others. [1] Currently hung up on some dependency issues and also waiting for discovery to firm up. -- 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 Feb 5 07:49:14 2012 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 C0C2D21F858E for ; Sun, 5 Feb 2012 07:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ENClah7Q36B for ; Sun, 5 Feb 2012 07:49:14 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5552B21F8587 for ; Sun, 5 Feb 2012 07:49:14 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.25]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id E1398F58089 for ; Sun, 5 Feb 2012 10:34:45 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Sun, 05 Feb 2012 08:22:15 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120205153445.E1398F58089@smtp.patriot.net> Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 05 Feb 2012 15:49:14 -0000 In , on 02/04/2012 at 09:01 PM, "Murray S. Kucherawy" said: >What's in parentheses there is precise, not an example. Yes, on re-reading it I see that. -- 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 Feb 5 07:49:38 2012 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 0D42421F8594 for ; Sun, 5 Feb 2012 07:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbJ5ni9Us84J for ; Sun, 5 Feb 2012 07:49:37 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 943C421F8592 for ; Sun, 5 Feb 2012 07:49:37 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.25]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 12472F58089 for ; Sun, 5 Feb 2012 10:35:06 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Sun, 05 Feb 2012 08:33:44 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120205153508.12472F58089@smtp.patriot.net> Subject: Re: [marf] Change request for AS, was Working Group Last Call on draft-ietf-marf-as-05 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, 05 Feb 2012 15:49:38 -0000 In , on 02/04/2012 at 10:25 PM, "Murray S. Kucherawy" said: >I support the idea of common-factoring Yes; I don't see much likelyhood that they will diverge. >If people don't like that idea, then I would instead suggest at >least removing them from one of the two -reporting drafts and having >that one reference the other one. I don't like that. If the text is moved to a single document, it should not be one specific to DKIM or SPF. AS is a better place to park it. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From barryleiba.mailing.lists@gmail.com Sun Feb 5 09:09:06 2012 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 1149A21F847F for ; Sun, 5 Feb 2012 09:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.938 X-Spam-Level: X-Spam-Status: No, score=-102.938 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVURxT94KkZ8 for ; Sun, 5 Feb 2012 09:09:05 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 86AC321F8470 for ; Sun, 5 Feb 2012 09:09:05 -0800 (PST) Received: by ghbg16 with SMTP id g16so2621719ghb.31 for ; Sun, 05 Feb 2012 09:09:05 -0800 (PST) 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; bh=zQBYhFG/0BZw4j0213q2zEPXbl32/5SqFThJ9OLRZS8=; b=K0XocugaPY8+bNXPLZGQqpnTXbtUMDTRyuKTeH+up35qwtaWlDnv4JpczUjpKzUqyX r1maM3Yim4UoIbQ9S6fbTo3QcD6ElslgAKJEgp/57wJn7itogMMYbCgRkiKSLr1L/wT+ By7JZP6wdDfsDXajxhbfnA5L6LMSquj9qXdoY= MIME-Version: 1.0 Received: by 10.236.124.66 with SMTP id w42mr20884836yhh.23.1328461745216; Sun, 05 Feb 2012 09:09:05 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Sun, 5 Feb 2012 09:09:05 -0800 (PST) In-Reply-To: <20120205153508.12472F58089@smtp.patriot.net> References: <20120205153508.12472F58089@smtp.patriot.net> Date: Sun, 5 Feb 2012 12:09:05 -0500 X-Google-Sender-Auth: ohpD6J0AvGagvyjQ7kCQ0-_jN9c Message-ID: From: Barry Leiba To: Message Abuse Report Format working group Content-Type: multipart/alternative; boundary=20cf300e56256bdba404b83a9a5c Subject: Re: [marf] Change request for AS, was Working Group Last Call on draft-ietf-marf-as-05 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, 05 Feb 2012 17:09:06 -0000 --20cf300e56256bdba404b83a9a5c Content-Type: text/plain; charset=ISO-8859-1 >>If people don't like that idea, then I would instead suggest at >>least removing them from one of the two -reporting drafts and having >>that one reference the other one. > > I don't like that. If the text is moved to a single document, it > should not be one specific to DKIM or SPF. AS is a better place to > park it. I agree, as participant and as document shepherd. Barry --20cf300e56256bdba404b83a9a5c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>If people don't like that idea, then I would instead suggest at=
>>least removing them from one of the two -reporting drafts and h= aving
>>that one reference the other one.
>
> I don= 9;t like that. If the text is moved to a single document, it
> should not be one specific to DKIM or SPF. AS is a better place to
= > park it.

I agree, as participant and as document shepherd.
<= br>Barry
--20cf300e56256bdba404b83a9a5c-- From barryleiba.mailing.lists@gmail.com Sun Feb 5 09:13:26 2012 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 ECF2721F8547 for ; Sun, 5 Feb 2012 09:13:26 -0800 (PST) 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.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6E3BUWmtFhS for ; Sun, 5 Feb 2012 09:13:26 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDC821F8557 for ; Sun, 5 Feb 2012 09:13:21 -0800 (PST) Received: by ghbg16 with SMTP id g16so2622492ghb.31 for ; Sun, 05 Feb 2012 09:13:21 -0800 (PST) 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; bh=KcXLiEuJqNQ+Z8edaovu8zEPrVB4fpoMb16xTg48q3o=; b=O3tZ1PHP5EL5UOxrDaeHPF01j8YGY2DLfLEzCdzpe782nlJPTsFeaoVqjMxUgQHM72 mv7+9jxMHWUBM1xj9BxqCeNzlT+jpBIzyaD+RxzeTWE7naedwk5Hmvwtw1+40JyZuwTY tnjTOYJrW3XSxz6Iiy7LIfQjmK8Ofhv/+cAJA= MIME-Version: 1.0 Received: by 10.236.124.66 with SMTP id w42mr20899357yhh.23.1328462001244; Sun, 05 Feb 2012 09:13:21 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Sun, 5 Feb 2012 09:13:21 -0800 (PST) In-Reply-To: <20120205153508.12472F58089@smtp.patriot.net> References: <20120205153508.12472F58089@smtp.patriot.net> Date: Sun, 5 Feb 2012 12:13:21 -0500 X-Google-Sender-Auth: PTlx6tgv2egi-VILwL01g8-TTWU Message-ID: From: Barry Leiba To: Message Abuse Report Format working group Content-Type: multipart/alternative; boundary=20cf300e5625ae8a3204b83aa93b Subject: [marf] Change request for AS, was Working Group Last Call on draft-ietf-marf-as-05 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, 05 Feb 2012 17:13:27 -0000 --20cf300e5625ae8a3204b83aa93b Content-Type: text/plain; charset=ISO-8859-1 >>If people don't like that idea, then I would instead suggest at >>least removing them from one of the two -reporting drafts and having >>that one reference the other one. > > I don't like that. If the text is moved to a single document, it > should not be one specific to DKIM or SPF. AS is a better place to > park it. I agree, as participant and as document shepherd. Barry --20cf300e5625ae8a3204b83aa93b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>If people don't like that idea, then I would instead suggest at=
>>least removing them from one of the two -reporting drafts and h= aving
>>that one reference the other one.
>
> I don= 9;t like that. If the text is moved to a single document, it
> should not be one specific to DKIM or SPF. AS is a better place to
= > park it.

I agree, as participant and as document shepherd.
B= arry
--20cf300e5625ae8a3204b83aa93b-- From sklist@kitterman.com Sun Feb 5 10:19:58 2012 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 E78A321F84A5 for ; Sun, 5 Feb 2012 10:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_ENC_UTF8x2=0.246] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Sp0lS-tpThB for ; Sun, 5 Feb 2012 10:19:58 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 562AD21F8495 for ; Sun, 5 Feb 2012 10:19:58 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 9C2D4D0407F; Sun, 5 Feb 2012 12:19:57 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328465997; bh=obXdCc+Xu740JqaA1F5zft1lweuZ7654M0MIWp3MQu8=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=OchgngeQ0e8GZIYYuLVJr7pypufKvQKBOdxfBZZZ8KgVtXJLUl3Z8m7FAuaZpg35H 94U6PzmEhUZFLMClfWrgE/1GrdrOTHDeJp+shWO3nH6zYzfnP56vb5GIQXgfNhqZGn YlZlKXWTlP7wGlnKIzMdez0f9kmiAdAgi+m/YY2k= Received: from 122.sub-97-21-197.myvzw.com (122.sub-97-21-197.myvzw.com [97.21.197.122]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 12ADAD0400D; Sun, 5 Feb 2012 12:19:56 -0600 (CST) References: <20120205153508.12472F58089@smtp.patriot.net> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sun, 05 Feb 2012 13:20:04 -0500 To: Message Abuse Report Format working group Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] =?utf-8?q?Change_request_for_AS=2C=09was_Working_Group_Las?= =?utf-8?q?t_Call_on_draft-ietf-marf-as-05?= 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, 05 Feb 2012 18:19:59 -0000 Barry Leiba wrote: >>>If people don't like that idea, then I would instead suggest at >>>least removing them from one of the two -reporting drafts and having >>>that one reference the other one. >> >> I don't like that. If the text is moved to a single document, it >> should not be one specific to DKIM or SPF. AS is a better place to >> park it. > >I agree, as participant and as document shepherd. >Barry Why the AS draft? There are tons of non-spam auth failures. These are often the most interesting ones. If this belongs in the AS draft then it's probably misnamed. Scott K From johnl@iecc.com Sun Feb 5 10:36:53 2012 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 54F7521F8562 for ; Sun, 5 Feb 2012 10:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.516 X-Spam-Level: X-Spam-Status: No, score=-109.516 tagged_above=-999 required=5 tests=[AWL=1.683, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRKa2KpWxL9n for ; Sun, 5 Feb 2012 10:36:52 -0800 (PST) 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 955BF21F854D for ; Sun, 5 Feb 2012 10:36:52 -0800 (PST) Received: (qmail 64604 invoked from network); 5 Feb 2012 18:36:49 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 5 Feb 2012 18:36:49 -0000 Date: 5 Feb 2012 18:36:27 -0000 Message-ID: <20120205183627.14893.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-as-05 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, 05 Feb 2012 18:36:53 -0000 >> The refusal of, e.g., yahoo, to accept plain text complaints provides >> an incentive for MUA authors to write such tools. Given the number of >> e-mail clients that are broken in one way or another, I'd rather see >> some guidance in an RFC before the avalanche starts. Restraining the >> MUA authors is not feasible. > >What do others think about this point? Given the number of direct complaints John, Yakov and I got >from Yahoo members when Yahoo decided to accept only ARF reports, it seems like we might be able to >say we have experience that this creates a big problem for a lot of people. And it's true that >software to generate ARFs will start appearing, if it hasn't already. I think I've gotten maybe a dozen complaints from people whose abuse reports were rejected by Yahoo. Considering how much mail Yahoo sends, that rounds to zero. Of those dozen complaints, it's not clear to me how many of them would have been actionable of Yahoo did accept them, since I didn't get the impression that people understood sending the headers, recognizing obvious forgeries, and the like. It may seem rude to say this, but if you can't figure out how to send an ARF report, you probably weren't sending actionable reports in the first place. Most useful reports come from other mail systems, triggered by users pushing the spam button. I also can't have much sympathy for the argument that there is a desperate need for a standard to desribe a way for users of random MUAs to force complaints into Yahoo. How long have they been ARF only, at least a year? How many MUA ARF generators are there? None that I'm aware of. (I can run the script I use to send all my abuse reports from Alpine on my FreeBSD laptop, but I wouldn't wish it on anyone else. And even there, the vast majority of my reports are sent from the server side.) That's not even a descending snowflake, much less an avalanche. If you want to write a plugin or script to send ARF reports from your MUA, go ahead. You don't need our permission. But it's not something that's going to be used by even 0.01% of mail users, so it's not worth addressing in a standards document. R's, John From barryleiba.mailing.lists@gmail.com Sun Feb 5 11:31:15 2012 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 6668921F84DD for ; Sun, 5 Feb 2012 11:31:15 -0800 (PST) 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.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrBEHtFmVGh6 for ; Sun, 5 Feb 2012 11:31:15 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D5DEB21F8470 for ; Sun, 5 Feb 2012 11:31:14 -0800 (PST) Received: by ghbg16 with SMTP id g16so2646939ghb.31 for ; Sun, 05 Feb 2012 11:31:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Lg/uDId07NGzyhchxLXnphhp9OfydafTqF5Pffhl0S0=; b=sI9oBMKtKsEnydgJzlBnDq4pXjaiEa4fUi1y7V2u3w575Je0Eg3u5aBzgJK+gT1das 5sHQgvt7BoqVX/rx6buTnQyla9yULkJUhknRKisrxlK4EOAYOKM73/bRK0qIh575PgDQ 1b4lIEmNhG2Wdh1boULQPSrgkQICDjkZ/x7pE= MIME-Version: 1.0 Received: by 10.236.124.69 with SMTP id w45mr20787611yhh.57.1328470274544; Sun, 05 Feb 2012 11:31:14 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Sun, 5 Feb 2012 11:31:14 -0800 (PST) In-Reply-To: References: <20120205153508.12472F58089@smtp.patriot.net> Date: Sun, 5 Feb 2012 14:31:14 -0500 X-Google-Sender-Auth: QKqw9a8_DzgYYc0AFO5gn9cbawI Message-ID: From: Barry Leiba To: Scott Kitterman Content-Type: multipart/alternative; boundary=20cf300e5415cf14b704b83c9651 Cc: Message Abuse Report Format working group Subject: Re: [marf] Change request for AS, was Working Group Last Call on draft-ietf-marf-as-05 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, 05 Feb 2012 19:31:15 -0000 --20cf300e5415cf14b704b83c9651 Content-Type: text/plain; charset=ISO-8859-1 > Why the AS draft? There are tons of non-spam auth failures. These are often the most interesting ones. > > If this belongs in the AS draft then it's probably misnamed. I'm confused by both of the last two sentences... I don't see the antecedents to "these", "this", and "it's". As to "Why the AS [document]?", It's because that document is an "applicability statement" for the work being done with MARF. An AS is a standards-track document that describes how to use the underlying protocols (as opposed to a TS (technical specification), which defines the protocol(s)). Part of using the protocols involves dealing with feedback loops, reporting, failures, ans so on. We decided to split certain details off into separate documents, for various reasons, but it all fits into the "applicability statement" box, and it makes sense to put the common bits into the AS document. Barry --20cf300e5415cf14b704b83c9651 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > Why the AS draft? There are tons of non-spam auth failures. These are = often the most interesting ones.
>
> If this belongs in the AS = draft then it's probably misnamed.

I'm confused by both of t= he last two sentences... I don't see the antecedents to "these&quo= t;, "this", and "it's".
As to "Why the AS [document]?", It's because that document is= an "applicability statement" for the work being done with MARF. = =A0An AS is a standards-track document that describes how to use the underl= ying protocols (as opposed to a TS (technical specification), which defines= the protocol(s)). =A0Part of using the protocols involves dealing with fee= dback loops, reporting, failures, ans so on.

We decided to split certain details off into separate documents, for va= rious reasons, but it all fits into the "applicability statement"= box, and it makes sense to put the common bits into the AS document.

Barry --20cf300e5415cf14b704b83c9651-- From msk@cloudmark.com Sun Feb 5 20:10:42 2012 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 F3F9321F8593 for ; Sun, 5 Feb 2012 20:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k088JVCKS5pa for ; Sun, 5 Feb 2012 20:10:41 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5A421F8581 for ; Sun, 5 Feb 2012 20:10:41 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 5 Feb 2012 20:10:40 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sun, 5 Feb 2012 20:10:40 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Sun, 5 Feb 2012 20:10:47 -0800 Thread-Topic: [marf] Change request for AS, was Working Group Last Call on draft-ietf-marf-as-05 Thread-Index: Aczj3SAjxrnvXZKAQ7ecGwE9Aa/J/QAp6YsA Message-ID: References: <4F291ECD.9040308@tana.it> <4F2AD991.8050508@tana.it> <48E6B374-95D2-4BC9-8794-50465B6455A2@wordtothewise.com> <2A6B561A-FFD5-4B87-A5F2-CC157EFFA08A@wordtothewise.com> In-Reply-To: <2A6B561A-FFD5-4B87-A5F2-CC157EFFA08A@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] Change request for AS, was Working Group Last Call on draft-ietf-marf-as-05 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, 06 Feb 2012 04:10:42 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= teve Atkins > Sent: Sunday, February 05, 2012 12:07 AM > To: Message Abuse Report Format working group > Subject: Re: [marf] Change request for AS, was Working Group Last Call on= draft-ietf-marf-as-05 >=20 > > It seems to me what's in Section 6 is good advice for any ARF > > generation case. >=20 > 6.3 isn't bad advice, but the justification of some of it is rather > specific to authentication failure reporting. Do we want to mandate > that anyone sending ARF reports of any sort MUST also publish SPF > records or send them with a NULL envelope sender? That requirement > isn't unreasonable in the case where you're talking about reports sent > in response to an authentication failure, where avoiding an > authentication failure in response to a report of authentication > failure is a reasonably belt-and-braces way to help avoid a mail loop - > but beyond that narrow scope it seems a bit of a reach. There are > people who consider SPF irrecoverably broken, yet still offer feedback > loops. Perhaps a compromise then: If we agree to move Section 6 to the AS, mention= that the advice of 6.3 is specific to authentication failure reports. > Some of it is specific to authentication failure reporting. As for the > rest of it, are they security concerns that should be discussed in > marf-as regardless of whether the DKIM/SPF docs want to reference them? > I'm thinking yes. Probably. > And (I'm going to regret asking this, I'm sure) where does draft-ietf- > marf-authfailure come into this? It has much the same security > statements and is already referenced by the SPF and DKIM failure > drafts, I think. That's true, and probably as a result of the fact that authfailure-report w= as the "master" from which these others were created at some point. If we're happy with what authfailure-report says, these sections could actu= ally be dropped since the two reporting documents already normatively refer= ence that one. -MSK From msk@cloudmark.com Sun Feb 5 20:14:21 2012 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 D540921F852E for ; Sun, 5 Feb 2012 20:14:21 -0800 (PST) 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.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktHC08fy8iuf for ; Sun, 5 Feb 2012 20:14:21 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6983321F84EC for ; Sun, 5 Feb 2012 20:14:21 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 5 Feb 2012 20:14:20 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sun, 5 Feb 2012 20:14:21 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sun, 5 Feb 2012 20:14:27 -0800 Thread-Topic: Working Group Last Call on draft-ietf-marf-as-05 Thread-Index: AczkGozNdGmQbA96RIKfKEbJ8PZ8JQAazlvg Message-ID: References: <20120202153704.67577.qmail@joyce.lan> 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_F5833273385BB34F99288B3648C4F06F19C9A7DBD4EXCHC2corpclo_" MIME-Version: 1.0 Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 06 Feb 2012 04:14:21 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DBD4EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good idea, works for me; added in the working copy. From: barryleiba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lists@g= mail.com] On Behalf Of Barry Leiba Sent: Sunday, February 05, 2012 7:27 AM To: Murray S. Kucherawy Cc: marf@ietf.org Subject: Re: Working Group Last Call on draft-ietf-marf-as-05 >> As an editorial suggestion, I'd suggest changing the numbered lists in >> sections 6-8 back to plain paragraphs since they do not describe >> sequences of things to do in order. The numbers have been handy during >> the revision process to identify what we're arguing about, though. > > Seems reasonable; I'll leave them in until IETF LC ends, in case we need > to use them for the same reason. If we inten to remove them, I suggest adding a note before each that says s= omething like this: [These numbered items are not intended to be in a paricular sequence. The = numbers are here during document development to make it easier to idenify t= he items for discussion, and will be removed before publication.] Barry --_000_F5833273385BB34F99288B3648C4F06F19C9A7DBD4EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good idea= , works for me; added in the working copy.

 

From: barryleiba.mailing.lists@gmail.com [mailto:barryleiba.mail= ing.lists@gmail.com] On Behalf Of Barry Leiba
Sent: Sunday= , February 05, 2012 7:27 AM
To: Murray S. Kucherawy
Cc:= marf@ietf.org
Subject: Re: Working Group Last Call on draft-ietf= -marf-as-05

&nbs= p;

>> As an editorial suggestion, I'd s= uggest changing the numbered lists in
>> sections 6-8 back to plai= n paragraphs since they do not describe
>> sequences of things to = do in order.  The numbers have been handy during
>> the revis= ion process to identify what we're arguing about, though.
>
> S= eems reasonable; I'll leave them in until IETF LC ends, in case we need
= > to use them for the same reason.

If we inten to remove them, I = suggest adding a note before each that says something like this:

[Th= ese numbered items are not intended to be in a paricular sequence.  Th= e numbers are here during document development to make it easier to idenify= the items for discussion, and will be removed before publication.]

= Barry

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DBD4EXCHC2corpclo_-- From msk@cloudmark.com Sun Feb 5 20:23:39 2012 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 F309821F852E for ; Sun, 5 Feb 2012 20:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyi0vgtO3AZg for ; Sun, 5 Feb 2012 20:23:38 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7422A21F8512 for ; Sun, 5 Feb 2012 20:23:38 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 5 Feb 2012 20:23:37 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sun, 5 Feb 2012 20:23:37 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sun, 5 Feb 2012 20:23:44 -0800 Thread-Topic: [marf] Working Group Last Call on draft-ietf-marf-as-05 Thread-Index: AczkA1AViHS5eJiBRpq4y7XboqsN3AAgp3rg Message-ID: References: <6993547.EjUSn6dgaq@scott-latitude-e6320> <4DEC4C4E-7F56-44DE-B0D6-6900120D9263@wordtothewise.com> <2F430701-7B41-4F3B-ACC6-F2A302482304@wordtothewise.com> <4F2BB1AE.4020605@tana.it> <4F2E78A9.103@tana.it> In-Reply-To: <4F2E78A9.103@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] Working Group Last Call on draft-ietf-marf-as-05 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, 06 Feb 2012 04:23:39 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Sunday, February 05, 2012 4:40 AM > To: marf@ietf.org > Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 >=20 > On 05/Feb/12 06:39, Murray S. Kucherawy wrote: > >> From: ietf.org On Behalf Of Alessandro Vesely > > > >>> @@ -311,19 +324,19 @@ > >>> > >>> 10. Published abuse mailbox addresses SHOULD NOT reject > messages not > >>> in the ARF format, as generation of ARF messages can > >>> - occasionally be unavailable or not applicable. > >> > >> Paragraph 10, for receivers, should terminate here. > > > > Do you think the rest of what's there now is incorrect? >=20 > It is not incorrect, it is in the wrong paragraph. Indeed, paragraph > 11 starts with "This is" as a want to be a continuation of #10. So you're suggesting that the remainder of 10 be merged into 11? That seem= s to make sense. > >> The rest of paragraph 10 and paragraph 11 (for senders) are > confusing > >> and need additional rewording, IMHO. > > > > Please provide substitute text. >=20 > Experience suggests use of ARF is advisable in most contexts. > Automated recipient systems can handle abuse reports sent in ARF > format at least as well as any other format such as plain text, > with or without a copy of the message attached. That holds even for > systems that didn't ask for ARF format reports, provided that > reports are generated with use by recipients not using automated > ARF parsing in mind. Anyone sending unsolicited reports in ARF > format can legitimately presume that recipients will only be able > to access the human readable (first, text/plain) part of it, and > MAY include all information needed also in this part. Further, they > MAY ensure that the report is readable when viewed as plain text, > to give low-end ticketing systems as much assistance as possible. Thanks, that works (with the warning about what might happen if you don't c= omply included from the previous version). > BTW, publishing a _report address /is/ opt-in, isn't it? That's a "reporting-discovery" thing, which I think we've essentially dropp= ed now. > >> Should we say that the 3rd mime part of non-actionable reports should > >> be "text/rfc822-headers"? > > > > Why? >=20 > To be more lightweight. I think we need to discuss it further if we want to use the word SHOULD. A= s it is, either message/rfc822 and text/rfc822-headers is acceptable and th= e report generator can choose to use either. I don't think we need to say = anything normative about that. -MSK From internet-drafts@ietf.org Sun Feb 5 21:16:57 2012 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 EB17521F859B; Sun, 5 Feb 2012 21:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNEX+shEBXCB; Sun, 5 Feb 2012 21:16:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8039121F84D5; Sun, 5 Feb 2012 21:16:56 -0800 (PST) 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.64p1 Message-ID: <20120206051656.8064.8480.idtracker@ietfa.amsl.com> Date: Sun, 05 Feb 2012 21:16:56 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-as-06.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, 06 Feb 2012 05:16:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Messaging Abuse Reporting Format Work= ing Group of the IETF. Title : Creation and Use of Email Feedback Reports: An Applicabi= lity Statement for the Abuse Reporting Format (ARF) Author(s) : J.D. Falk M. Kucherawy Filename : draft-ietf-marf-as-06.txt Pages : 13 Date : 2012-02-05 RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This document describes common methods for utilizing this format for abuse reporting. Mailbox Providers of any size, mail sending entities, and end users can use these methods as a basis to create procedures that best suit them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-as-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-as-06.txt From internet-drafts@ietf.org Sun Feb 5 21:17:22 2012 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 4190621F8422; Sun, 5 Feb 2012 21:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zbs1tjUP9vuh; Sun, 5 Feb 2012 21:17:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE6D21F85A7; Sun, 5 Feb 2012 21:17:03 -0800 (PST) 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.64p1 Message-ID: <20120206051703.7640.91731.idtracker@ietfa.amsl.com> Date: Sun, 05 Feb 2012 21:17:03 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-dkim-reporting-09.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, 06 Feb 2012 05:17:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Messaging Abuse Reporting Format Work= ing Group of the IETF. Title : Extensions to DKIM for Failure Reporting Author(s) : Murray S. Kucherawy Filename : draft-ietf-marf-dkim-reporting-09.txt Pages : 22 Date : 2012-02-05 This memo presents extensions to the DomainKeys Identified Mail (DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-dkim-reporting-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-dkim-reporting-09.txt From msk@cloudmark.com Sun Feb 5 21:24:08 2012 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 722C721F8456 for ; Sun, 5 Feb 2012 21:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaZ6aZK9RR3A for ; Sun, 5 Feb 2012 21:24:07 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCE921F8453 for ; Sun, 5 Feb 2012 21:24:07 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 5 Feb 2012 21:24:06 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sun, 5 Feb 2012 21:24:07 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sun, 5 Feb 2012 21:24:13 -0800 Thread-Topic: I-D Action: draft-ietf-marf-as-06.txt Thread-Index: Aczkjpv8XNxXRZquTdqzTqJJK5NUGgAACKPg Message-ID: References: <20120206051656.8064.8480.idtracker@ietfa.amsl.com> In-Reply-To: <20120206051656.8064.8480.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-as-06.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, 06 Feb 2012 05:24:08 -0000 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org > Sent: Sunday, February 05, 2012 9:17 PM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: I-D Action: draft-ietf-marf-as-06.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Messaging Abuse Reporting > Format Working Group of the IETF. >=20 > Title : Creation and Use of Email Feedback Reports: An > Applicability Statement for the Abuse Reporting Format (ARF) > Author(s) : J.D. Falk > M. Kucherawy > Filename : draft-ietf-marf-as-06.txt > Pages : 13 > Date : 2012-02-05 >=20 > RFC 5965 defines an extensible, machine-readable format intended for > mail operators to report feedback about received email to other > parties. This document describes common methods for utilizing this > format for abuse reporting. Mailbox Providers of any size, mail > sending entities, and end users can use these methods as a basis to > create procedures that best suit them. This version includes the following based on WGLC feedback so far, which I = believe is either minor editorial stuff or has rough consensus, just so we = all have an updated but common place from which to work: - relocate text about auto-generation based on spam filters from Section 5 = into Section 8, suggested by Steve - add a note that the numbered bullets will become symbol bullets (i.e., an= unordered list) prior to publication, suggested by John and Barry - some clarifying text requested by Scott - reposition the report destination address heuristics discussion, suggeste= d by Steve - add opt-out text, suggested by Steve - some rewording and reorganization in Section 8, suggested by Alessandro - discussion of costs of unsolicited reports, suggested by Steve - move discussion of automated report generation from the DKIM reporting dr= aft to a new Section 9 here - move Security Considerations specific to any kind of automated report gen= eration to Security Considerations here - some editorial stuff suggested by Shmuel - add/update references accordingly We're still in WGLC, so let the bashing continue... -MSK From msk@cloudmark.com Sun Feb 5 21:26:59 2012 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 F0A5721F84C3 for ; Sun, 5 Feb 2012 21:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVgSpnEcT9Li for ; Sun, 5 Feb 2012 21:26:58 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2C921F8456 for ; Sun, 5 Feb 2012 21:26:58 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 5 Feb 2012 21:26:57 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sun, 5 Feb 2012 21:26:57 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sun, 5 Feb 2012 21:27:04 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-dkim-reporting-09.txt Thread-Index: AczkjrCRDZievYlaRNqGHGH2//0OCAAAOvGA Message-ID: References: <20120206051703.7640.91731.idtracker@ietfa.amsl.com> In-Reply-To: <20120206051703.7640.91731.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-09.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, 06 Feb 2012 05:26:59 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org > Sent: Sunday, February 05, 2012 9:17 PM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: [marf] I-D Action: draft-ietf-marf-dkim-reporting-09.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Messaging Abuse Reporting > Format Working Group of the IETF. >=20 > Title : Extensions to DKIM for Failure Reporting > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-marf-dkim-reporting-09.txt > Pages : 22 > Date : 2012-02-05 >=20 > This memo presents extensions to the DomainKeys Identified Mail > (DKIM) specification to allow for detailed reporting of message > authentication failures in an on-demand fashion. Similarly, here's an update based on the recent rearrangement of text: - incorporate Alessandro's point that "rs=3D" is still actionable even if "= ra=3D" is missing - state that the report format is defined in the "authfailure-report" draft= , but common-factor all the other normative stuff about construction/transm= ission of the report (e.g., the envelope) to the AS document - further, common-factor the Security Considerations stuff that's applicabl= e to both SPF reporting and DKIM reporting into the AS - add/update references accordingly How's that look? -MSK From vesely@tana.it Mon Feb 6 02:21:18 2012 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 7ACED21F85B4 for ; Mon, 6 Feb 2012 02:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.647 X-Spam-Level: X-Spam-Status: No, score=-4.647 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5s5cusF12aE for ; Mon, 6 Feb 2012 02:21:17 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 972EB21F8585 for ; Mon, 6 Feb 2012 02:21:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328523675; bh=WQgCvZprkJO+MH1LLPa7Lvmfd+Jshhp5GwItolqa5ag=; l=1645; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=K7R7u4LS8D240I4AmOSZdWT7naasc8j/vFUqjVO0cOgEtR9kWs4sfKfz4GsyZzaaq Cmjt5QkH60lyhY+r5B/AAY8nVYpGyXRFcPaZdq6u1jqOaPFgQcJY1cKCMreprYXhqr 2WdYnbc/MRYHyeLFLe7T4k/Jch+/dzCi4wZd8TA0= 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, 06 Feb 2012 11:21:15 +0100 id 00000000005DC039.000000004F2FA99B.00007FF8 Message-ID: <4F2FA99A.2020107@tana.it> Date: Mon, 06 Feb 2012 11:21:14 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org, John Levine References: <20120130193649.24837.53481.idtracker@ietfa.amsl.com> <4F283C32.7070206@tana.it> <4F291852.8020807@tana.it> <4F2A7E8F.9010901@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [marf] VERP in 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: Mon, 06 Feb 2012 10:21:18 -0000 On 02/Feb/12 19:16, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely > >> I propose we encourage getting acknowledgments and recording them >> along with per-domain reporting history. Report generators >> should use VERP, and suspend reporting to rejecting domains for >> an amount of time inversely proportional to the confidence, >> e.g.: >> >> 0.5T for an acknowledged domain, >> T for a first-time first-failure, >> 2T, >> 4T, >> ... , >> one year for dorks. >> >> where T is the TTL of the relevant _report's RR if retrieved with the >> AA flag, or some other time constant either agreed with the domain or >> set by default. > > And you think this would improve [Section 11.5 of marf-as-06] rather > than complicating it? Personally, I'm satisfied that the last > paragraph of what we have in that section is adequate to introduce > the idea. Developing and recommending a detailed tracking system > design seems like overkill here. If someone wants to do such a > thing, it would certainly be valid, but I think suggesting that > such a thing might be necessary could become a barrier to > adoption. VERP should be quite straightforward to implement, given that it's been around for decades. What to do on delivery failures is part of using VERP, of course. Per-domain DBs may look more like greylisting whitelists than subscriber lists. They are needed anyway to implement paragraph 6 of Section 8 ("MUST provide a way for a report recipient to request no further reports be sent to that address") unless that gets limited to heuristically inferred addresses. Ideas? From sklist@kitterman.com Mon Feb 6 03:57:16 2012 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 B872121F8633 for ; Mon, 6 Feb 2012 03:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7RAPQqCeDrF for ; Mon, 6 Feb 2012 03:57:16 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1030D21F8609 for ; Mon, 6 Feb 2012 03:57:15 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0C96620E4126; Mon, 6 Feb 2012 06:57:15 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328529435; bh=PR6wKXeqNBpOvhpWCKr5E79GZG5twB1tN9oMdolj9tQ=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=a5fVV3HNBMezzRNFZmPV+b3CMIj0oJ6Yc185jlwPljoZ7uQwEqjhpl4cnq1hn5r0v 6En+/pgrfXsSnW14IyQn4wnvsXUrBL7kgSI/ETDGi5xQWQF9a0AfZeTvhY1LHyDYb3 iijAfuOX5Fzj9UwtB8xXey4/ve8fp3GrfWfvFubc= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id E1A6420E408E; Mon, 6 Feb 2012 06:57:14 -0500 (EST) From: Scott Kitterman To: Message Abuse Report Format working group Date: Mon, 06 Feb 2012 06:57:13 -0500 Message-ID: <6781615.bvN8lPaFUn@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Change request for AS, was Working Group Last Call on draft-ietf-marf-as-05 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, 06 Feb 2012 11:57:16 -0000 On Sunday, February 05, 2012 02:31:14 PM Barry Leiba wrote: > > Why the AS draft? There are tons of non-spam auth failures. These are > often the most interesting ones. > > > If this belongs in the AS draft then it's probably misnamed. > > I'm confused by both of the last two sentences... I don't see the > antecedents to "these", "this", and "it's". These are auth failure arfs. This is the text from the DKIM and SPF drafts being proposed be consolidated into the AS draft and it's is the AS draft. > As to "Why the AS [document]?", It's because that document is an > "applicability statement" for the work being done with MARF. An AS is a > standards-track document that describes how to use the underlying protocols > (as opposed to a TS (technical specification), which defines the > protocol(s)). Part of using the protocols involves dealing with feedback > loops, reporting, failures, ans so on. > > We decided to split certain details off into separate documents, for > various reasons, but it all fits into the "applicability statement" box, > and it makes sense to put the common bits into the AS document. For auth failure reports we (tried to anyway) put the common bits needed to extend arf to send messages about authentication failures in draft-ietf-marf- authfailure-report. If there is further factoring to be done from the DKIM and SPF drafts, that's where it seems to be sensible to put it (I know that's procedurally complex at this point). I don't think what's being discussed fits a draft about anti-spam. Anti-spam and auth failure are different concepts. In many cases the most interesting (to the sender) cases are the ones where legitimate messages failed authentication. There are also interesting authentication failure cases where the message is spam, but it's certainly not limited to that. It would seem odd to me to have to go read an RFC about anti-spam in order to implement authentication failure reporting, so if what's in the anti-spam draft is really necessary to authentication failure reporting, then I suspect it is misnamed. That's a longer (and hopefully clearer) version of what I was trying to communicate yesterday. Scott K From sklist@kitterman.com Mon Feb 6 04:03:36 2012 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 1F05B21F8611 for ; Mon, 6 Feb 2012 04:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECicOzGB1MmQ for ; Mon, 6 Feb 2012 04:03:35 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3437021F8617 for ; Mon, 6 Feb 2012 04:03:35 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C334E20E4126; Mon, 6 Feb 2012 07:03:34 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328529814; bh=OaUeoSR02J+wOQoehRacc40uWKsBoIjHLcYU7qX9Trk=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=K2jOw7N/ERbcZrs3vwIs7xQTuuuQ1UEAvNxHIVVhaqJu9ZDK50aTlplFm8MGwlYO3 juWAvCKqMX3FOybDVOMRXAwmk/yGZs5ghm33v/B3qssznPMAY9h3NBqLyPljFMLCqo Ei2SoRVrONdevsbqMdMybUrQOX5PK6cFTwQt3+wY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A3A4720E408E; Mon, 6 Feb 2012 07:03:34 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Mon, 06 Feb 2012 07:03:34 -0500 Message-ID: <2891512.IOemTbiojJ@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120206051703.7640.91731.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-09.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, 06 Feb 2012 12:03:36 -0000 On Sunday, February 05, 2012 09:27:04 PM Murray S. Kucherawy wrote: > - further, common-factor the Security Considerations stuff that's applicable > to both SPF reporting and DKIM reporting into the AS I'm against this. It's the wrong place for it (see my note to Barry). Scott K From vesely@tana.it Mon Feb 6 04:23:39 2012 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 B6C6F21F8613 for ; Mon, 6 Feb 2012 04:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.648 X-Spam-Level: X-Spam-Status: No, score=-4.648 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7CDoorGSZ7y for ; Mon, 6 Feb 2012 04:23:39 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 00CFA21F8603 for ; Mon, 6 Feb 2012 04:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328531018; bh=JTxRG4NAxUg0DPDaUFWm4A0lXI82WlsTvoth0ysDM3M=; l=528; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=XaXGmI9GliALskbEU73ZqdriT481BcyJRKuEgIiMl7ZPuxTTCaxFzfp+qTkZiWCsq J6OtGtRYQyfCNtH/IvKgxzo5b4oK0NMnchIiy7C15kFFNCXDFdgm4RfTbpUjUU0UCQ LE9QDkoHq/tjLC/q0zLprr5s7N7Mv/2uYVAQckJ0= 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, 06 Feb 2012 13:23:38 +0100 id 00000000005DC039.000000004F2FC64A.00002266 Message-ID: <4F2FC649.3040104@tana.it> Date: Mon, 06 Feb 2012 13:23:37 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120206051703.7640.91731.idtracker@ietfa.amsl.com> <2891512.IOemTbiojJ@scott-latitude-e6320> In-Reply-To: <2891512.IOemTbiojJ@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-09.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, 06 Feb 2012 12:23:39 -0000 On 06/Feb/12 13:03, Scott Kitterman wrote: > On Sunday, February 05, 2012 09:27:04 PM Murray S. Kucherawy wrote: >> - further, common-factor the Security Considerations stuff that's applicable >> to both SPF reporting and DKIM reporting into the AS > > I'm against this. It's the wrong place for it (see my note to Barry). Auto-sending of hi-score messages, although not recommended, needs precautions that are quite similar to those of sending auth-failures, so it makes sense to gather them into a common document. From sklist@kitterman.com Mon Feb 6 05:02:11 2012 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 D037221F85FD for ; Mon, 6 Feb 2012 05:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDwgieccJjbU for ; Mon, 6 Feb 2012 05:02:07 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5A421F85E9 for ; Mon, 6 Feb 2012 05:02:07 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 9D26ED0407F; Mon, 6 Feb 2012 07:02:06 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328533326; bh=l1U1XEyM7mhiOTz2QdDWt1g+SNOiih2KmdVcp2jfhVs=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=D3h57QGMdQSjayl7orxHLf6lgyGMMtcB7lah9gCkT8OSK3iztET9lOo0y6t8AU5zu sMtpBiwC/o3NGzMjBs6OxG3NKdlvvppRhCXoVzR5W441SiLlfMdc0dXbL5Nw9zCEoX TWgKDKmvjOtBGN0xIw6tnWm6HerepPPxQN0vly08= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E8639D04042; Mon, 6 Feb 2012 07:02:05 -0600 (CST) References: <20120206051703.7640.91731.idtracker@ietfa.amsl.com> <2891512.IOemTbiojJ@scott-latitude-e6320> User-Agent: K-9 Mail for Android In-Reply-To: <2891512.IOemTbiojJ@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Mon, 06 Feb 2012 08:02:10 -0500 To: marf@ietf.org Message-ID: <83f0989f-aebe-4288-b93e-1805193387ac@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-09.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, 06 Feb 2012 13:02:11 -0000 Scott Kitterman wrote: >On Sunday, February 05, 2012 09:27:04 PM Murray S. Kucherawy wrote: >> - further, common-factor the Security Considerations stuff that's >applicable >> to both SPF reporting and DKIM reporting into the AS > >I'm against this. It's the wrong place for it (see my note to Barry). Now that there's an updated draft for last call, here are three additional last call comments: 1. If the DKIM and SPF drafts are supposed to be supported by this draft, then the discussion on reporting address discovery is inadequate. Those drafts enable domains to explicitly publish reporting addresses, so the heuristics for address discovery in this draft are inappropriate for those types of reports. My preferred solution to this problem would be to separate them again (not providing a recommended diff since it's just reverting some of the changes in the last update). 2. Strongly suggesting use of SPF is, in my opinion, not appropriate in a general document like this. The current text adds up to SHOULD use SPF. The way it was before (IIRC), SPF only came up in the SPF draft. I suspect a general SHOULD SPF is going to be a hard sell in a standards track document that's not limited in scope to domains already interested in SPF. 3. Due to now saying senders SHOULD use SPF in the envelope sender selection paragraph, the reference to RFC 4408 needs to be normative now. My solution for #2 and #3 is the same as #1. Scott K From shmuel+gen@patriot.net Mon Feb 6 05:50:22 2012 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 E46B521F862F for ; Mon, 6 Feb 2012 05:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 555+cQNl3PAJ for ; Mon, 6 Feb 2012 05:50:17 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7595121F8617 for ; Mon, 6 Feb 2012 05:50:17 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.50]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id D6194F5808A for ; Mon, 6 Feb 2012 08:35:46 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 06 Feb 2012 08:37:20 -0500 To: marf@ietf.org In-Reply-To: <20120205183627.14893.qmail@joyce.lan> Mail-Copies-To: nobody 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: <20120206133546.D6194F5808A@smtp.patriot.net> Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 06 Feb 2012 13:50:22 -0000 In <20120205183627.14893.qmail@joyce.lan>, on 02/05/2012 at 06:36 PM, "John Levine" said: >I also can't have much sympathy for the argument that there is a >desperate need for a standard to desribe a way for users of random >MUAs to force complaints into Yahoo. Accepting abuse complaints is part and parcel of, e.g., sending e-mail. I don't see how you can legitimately describe sending such complaints as forcing them on yahoo. -- 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 johnl@taugh.com Mon Feb 6 06:35:59 2012 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 092EA21F8642 for ; Mon, 6 Feb 2012 06:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqxqgcdKiM85 for ; Mon, 6 Feb 2012 06:35:52 -0800 (PST) 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 7D2E521F8645 for ; Mon, 6 Feb 2012 06:35:52 -0800 (PST) Received: (qmail 30136 invoked from network); 6 Feb 2012 14:35:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:vbr-info:user-agent:cleverness; s=75b7.4f2fe546.k1202; bh=oxrfuhEzCAESs+i8YgCPksFb8eFMf4cdcNeLNVnuQ24=; b=Bk4APE6uRD811N8XTw8ChAnakLVCuFeCZf7vkkUvnEZElJA/czABMnLXA6iqJiDgPm63gTJtVbXsZLZBa3NG30bxJrUgvlEgNbxypbBsiWlCKrnBxvrcb/byMGHHxJwcOfSisoNahQyOEICb1fTCiaR8FYvyWR9cbXg0LtY5pjo= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:vbr-info:user-agent:cleverness; s=75b7.4f2fe546.k1202; bh=oxrfuhEzCAESs+i8YgCPksFb8eFMf4cdcNeLNVnuQ24=; b=dd+d/oRcmpo4FmtF49czB5SyRcBe5V3X60ytoNHOTn7u+A3vggIC5c/OU6aM5rhgW9DF/Tndm8RupN0rJhCU+AZqhZdlzPiqLMM4e4N9JOSlENJxUhAadxIGNFRoDePBk5alYQF3fWo21NgKtbfbqWuJdMrGJOzZRXfGxi//Xjg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 Feb 2012 14:35:27 -0000 Date: 6 Feb 2012 09:35:49 -0500 Message-ID: From: "John R Levine" To: "ARF mailing list" User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [marf] VERP in marf-as (fwd) 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, 06 Feb 2012 14:35:59 -0000 > Ideas? VERP is a swell technique, but this is an applicability statement, not a mail programming tutorial. 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 shmuel+gen@patriot.net Mon Feb 6 08:07:16 2012 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 45FC221F852B for ; Mon, 6 Feb 2012 08:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.168 X-Spam-Level: X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b23kpi6wXbvp for ; Mon, 6 Feb 2012 08:07:07 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id C316921F84DD for ; Mon, 6 Feb 2012 08:07:07 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.134]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 63714F5808A for ; Mon, 6 Feb 2012 10:52:37 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 06 Feb 2012 09:39:59 -0500 To: marf@ietf.org In-Reply-To: <20120206051656.8064.8480.idtracker@ietfa.amsl.com> Mail-Copies-To: nobody 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: <20120206155237.63714F5808A@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-06.txt 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, 06 Feb 2012 16:07:16 -0000 In <20120206051656.8064.8480.idtracker@ietfa.amsl.com>, on 02/05/2012 at 09:16 PM, internet-drafts@ietf.org said: >draft-ietf-marf-as-06.txt In 8. Generating and Handling Unsolicited Reports, if a MUST is appropriate in item 6 then surely it is also appropriate in item 12. I suggest 6. A report generator MUST provide a way for a report recipient to request no further reports be sent to that address, unless the provider only accepts abuse complaints in ARF format, and MAY provide a way for recipients to change the address(es) to which reports about them are sent. 12. Published abuse mailbox addresses SHOULD NOT reject messages not in the ARF format, as generation of ARF messages can occasionally be unavailable or not applicable. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From shmuel+gen@patriot.net Mon Feb 6 08:11:15 2012 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 BD10821F8545 for ; Mon, 6 Feb 2012 08:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQ3b6ykNL7+Q for ; Mon, 6 Feb 2012 08:10:42 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id F23E321F847E for ; Mon, 6 Feb 2012 08:10:37 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.157]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id D015CF5808A for ; Mon, 6 Feb 2012 10:56:06 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 06 Feb 2012 09:13:01 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120206155606.D015CF5808A@smtp.patriot.net> Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 06 Feb 2012 16:11:15 -0000 In , on 02/04/2012 at 09:01 PM, "Murray S. Kucherawy" said: >Agree with the "some". I notice "some" that it isn't in draft-ietf-marf-as-06.txt; is that deliberate or inadvertent? 8. Generating and Handling Unsolicited Reports 13. Experience suggests use of ARF is advisable in most contexts. Automated recipient systems can handle abuse reports sent in ARF format at least as well as any other format such as plain text, with or without a copy of the message attached. That holds even for systems that did not request ARF format reports, provided that reports are generated with use by recipients not using automated ARF parsing in mind. Anyone sending unsolicited reports in ARF format can legitimately presume that recipients -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From vesely@tana.it Mon Feb 6 09:24:18 2012 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 977BB21F86A3 for ; Mon, 6 Feb 2012 09:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L716kVayecaf for ; Mon, 6 Feb 2012 09:24:18 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C023921F86A6 for ; Mon, 6 Feb 2012 09:24:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328549055; bh=GiX2QJrdWpzDROVJPfJ4FKJ9i5NH/WzmdvejkztZMzM=; l=975; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=FLuMWQFq824CSzqILL2hSSoyF8bkg25F/xhsDzORv3k+VgFx07SDNYcPWnF/8Ckvd Qm9qBvwwEiBZ9g/8VOzewO/REmh/4jeh02naUlXgtXKNONMbYJvkxe2zRjBlo31QF3 /5dFCWvqzN/MIvv6o34oAGV6novo4cRg4RDNZmHk= 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, 06 Feb 2012 18:24:15 +0100 id 00000000005DC033.000000004F300CBF.00006983 Message-ID: <4F300CBE.9030804@tana.it> Date: Mon, 06 Feb 2012 18:24:14 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org, John Levine References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] VERP in 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: Mon, 06 Feb 2012 17:24:18 -0000 On 06/Feb/12 15:35, John R Levine wrote: >> Ideas? > > VERP is a swell technique, but this is an applicability statement, not > a mail programming tutorial. Yes, we can just describe the purpose. E.g., somewhere in Section 6: In the case of reports transmitted automatically, the envelope sender address MAY/SHOULD/MUST be set so that all error messages generated by the final deliveries will be returned to the transmitting entity. Transmission of further reports to a failed address MAY be regulated taking into account previous experience of sending the same kind of report to the same address. For example, if the address was used successfully in the past and retrieved from the DNS, transmission may be paused so as to give the relevant cached RR a chance to expire. In any case, reports transmitted automatically are an email service in the sense of RFC 3834, and those recommendations apply. Do we want to say something like this? From johnl@iecc.com Mon Feb 6 09:40:47 2012 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 EE32721F86DC for ; Mon, 6 Feb 2012 09:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.543 X-Spam-Level: X-Spam-Status: No, score=-109.543 tagged_above=-999 required=5 tests=[AWL=1.656, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFytoZC4GI4j for ; Mon, 6 Feb 2012 09:40:47 -0800 (PST) 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 E966521F86DA for ; Mon, 6 Feb 2012 09:40:46 -0800 (PST) Received: (qmail 90523 invoked from network); 6 Feb 2012 17:40:46 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Feb 2012 17:40:46 -0000 Date: 6 Feb 2012 17:40:24 -0000 Message-ID: <20120206174024.54825.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-dkim-reporting-09.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, 06 Feb 2012 17:40:48 -0000 >How's that look? Section 10 tells people to use SHA1 as a redaction hash. The crypto weenies who freaked out last time will do so again. Suggest you replace the text in the section with whatever we said last time, just do something that's hard to reverse. I have to say that I'm not thrilled that sections 3, 4, and 5 still include the r= remote mailbombing feature. R's, John From johnl@taugh.com Mon Feb 6 09:43:45 2012 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 CE79B21F86DE for ; Mon, 6 Feb 2012 09:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bl4e5XpMBcl7 for ; Mon, 6 Feb 2012 09:43:45 -0800 (PST) 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 EF91521F86DC for ; Mon, 6 Feb 2012 09:43:44 -0800 (PST) Received: (qmail 92603 invoked from network); 6 Feb 2012 17:43:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=169ba.4f301150.k1202; bh=TqkkKo5+SDFrM7KQ2oAozbM2H31qaxaOPNdrpCTHiHE=; b=THCTUmUWs7K5+mKXLUPdm6Xvu5jRTXTezvg88tjJu9TfRtuY2lbHn77fk1abtXW6ZUGY6AkE/my0zO5b2+htN7HJ1L/qgHlKkUafg1dneW2A6OLFF7KDrAUv1c6URURnzw5xDL6/6vCboihKZOayJIxvsJVldIGTOtxKyRr1UrM= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=169ba.4f301150.k1202; bh=TqkkKo5+SDFrM7KQ2oAozbM2H31qaxaOPNdrpCTHiHE=; b=CvKhY847jvRCJRAaf6EgdoXzPl5zpM6GQcshe188UlVpfRW8TSS6aTd530QxLdKjKnFC+5TlCLlaZtjFTGI9SPFzWJ+IXCQVYshF320sSzmKrulxEC2XSw6tz5ZL29paXx5n1wZPbsAdP+B8zC/mXrlle7Mj7jYCeT7i5FX8yEk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 Feb 2012 17:43:22 -0000 Date: 6 Feb 2012 12:43:42 -0500 Message-ID: From: "John R Levine" To: "Alessandro Vesely" In-Reply-To: <4F300CBE.9030804@tana.it> References: <4F300CBE.9030804@tana.it> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ARF mailing list Subject: Re: [marf] VERP in 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: Mon, 06 Feb 2012 17:43:45 -0000 > Do we want to say something like this? No. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From sklist@kitterman.com Mon Feb 6 09:44:52 2012 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 EF6CE21F86E5 for ; Mon, 6 Feb 2012 09:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4t3hOndr-Tj for ; Mon, 6 Feb 2012 09:44:52 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB8621F86E2 for ; Mon, 6 Feb 2012 09:44:52 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D7B7520E414F; Mon, 6 Feb 2012 12:44:51 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328550291; bh=RWVXFyIb8qDqFXr49wirIW1tqG636le0qSZKg1OsxKE=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=XB8VN9ifEeaOV9heFd9l0pxJjUdxqCykLPSlf6IljmNnn1S3fsQNXy7d568wNaKJG A3PxglQhpktolglxpcrSuaUWshMVhi15K77i56awxPRjyK2+73YyxjFrlVb/mqrQF0 aXv2glhA9tRQSD1vY1QZjG25pPaIiFDDS5cnjLTE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B8CF620E408E; Mon, 6 Feb 2012 12:44:51 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Mon, 06 Feb 2012 12:44:51 -0500 Message-ID: <5254590.qjdYWPBNpp@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120206174024.54825.qmail@joyce.lan> References: <20120206174024.54825.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-09.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, 06 Feb 2012 17:44:53 -0000 On Monday, February 06, 2012 05:40:24 PM John Levine wrote: > I have to say that I'm not thrilled that sections 3, 4, and 5 still > include the r= remote mailbombing feature. I thought we had agreed we didn't want that? I changed the SPF draft to provide local part only and I think they should be the same. Scott K From msk@cloudmark.com Mon Feb 6 09:46:34 2012 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 C9B7321F86E8 for ; Mon, 6 Feb 2012 09:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpPMdFmMe8O6 for ; Mon, 6 Feb 2012 09:46:34 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA8221F86E5 for ; Mon, 6 Feb 2012 09:46:34 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Feb 2012 09:46:34 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 6 Feb 2012 09:46:33 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 6 Feb 2012 09:46:32 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-dkim-reporting-09.txt Thread-Index: Aczk9nbAXlR7hPdhRTS3WFFO+Ec/uwAAJuFw Message-ID: References: <20120206174024.54825.qmail@joyce.lan> In-Reply-To: <20120206174024.54825.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-09.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, 06 Feb 2012 17:46:34 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQHRhdWdoLmNvbV0NCj4gU2VudDogTW9uZGF5LCBGZWJydWFyeSAwNiwgMjAxMiA5OjQw IEFNDQo+IFRvOiBtYXJmQGlldGYub3JnDQo+IENjOiBNdXJyYXkgUy4gS3VjaGVyYXd5DQo+IFN1 YmplY3Q6IFJlOiBbbWFyZl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1tYXJmLWRraW0tcmVwb3J0 aW5nLTA5LnR4dA0KPiANCj4gU2VjdGlvbiAxMCB0ZWxscyBwZW9wbGUgdG8gdXNlIFNIQTEgYXMg YSByZWRhY3Rpb24gaGFzaC4gIFRoZSBjcnlwdG8NCj4gd2VlbmllcyB3aG8gZnJlYWtlZCBvdXQg bGFzdCB0aW1lIHdpbGwgZG8gc28gYWdhaW4uICBTdWdnZXN0IHlvdQ0KPiByZXBsYWNlIHRoZSB0 ZXh0IGluIHRoZSBzZWN0aW9uIHdpdGggd2hhdGV2ZXIgd2Ugc2FpZCBsYXN0IHRpbWUsIGp1c3QN Cj4gZG8gc29tZXRoaW5nIHRoYXQncyBoYXJkIHRvIHJldmVyc2UuDQoNClRoZXJlIGlzIG5vIFNl Y3Rpb24gMTAgaW4gdGhpcyBkb2N1bWVudC4gIFdoaWNoIG9uZSBhcmUgeW91IGxvb2tpbmcgYXQ/ DQoNCj4gSSBoYXZlIHRvIHNheSB0aGF0IEknbSBub3QgdGhyaWxsZWQgdGhhdCBzZWN0aW9ucyAz LCA0LCBhbmQgNSBzdGlsbA0KPiBpbmNsdWRlIHRoZSByPSByZW1vdGUgbWFpbGJvbWJpbmcgZmVh dHVyZS4NCg0KVGhlIGFsZ29yaXRobSBpbiB0aGUgZHJhZnQgaXMgdGhlIG9uZSB5b3UndmUgYmVl biBzdWdnZXN0aW5nLCBmb3IgdGhlIG1vc3QgcGFydC4gICJyPSIgaXMgbm93IHNpbXBseSBhIEJv b2xlYW4gaW5kaWNhdG9yIG9mIGEgcmVxdWVzdCBmb3IgcmVwb3J0cywgYW5kIHRoZSByZXN0IG9m IHRoZSByZXBvcnRpbmcgcGFyYW1ldGVycyBhcmUgZHJhd24gZnJvbSBETlMgcmVjb3Jkcy4NCg0K From msk@cloudmark.com Mon Feb 6 09:52:19 2012 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 B83F821F8622 for ; Mon, 6 Feb 2012 09:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsybczSM1l7K for ; Mon, 6 Feb 2012 09:52:19 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 497E521F8603 for ; Mon, 6 Feb 2012 09:52:11 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Feb 2012 09:52:11 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 6 Feb 2012 09:52:10 -0800 From: "Murray S. Kucherawy" To: ARF mailing list Date: Mon, 6 Feb 2012 09:52:09 -0800 Thread-Topic: [marf] VERP in marf-as Thread-Index: Aczk9uIWjwC9WlABSt+9147olC5utAAARQpQ Message-ID: References: <4F300CBE.9030804@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] VERP in 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: Mon, 06 Feb 2012 17:52:19 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of J= ohn R Levine > Sent: Monday, February 06, 2012 9:44 AM > To: Alessandro Vesely > Cc: ARF mailing list > Subject: Re: [marf] VERP in marf-as >=20 > > Do we want to say something like this? >=20 > No. I agree. See my previous desire to avoid turning this into an ARF cookbook= . -MSK From msk@cloudmark.com Mon Feb 6 10:03:51 2012 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 B49F421F86C5 for ; Mon, 6 Feb 2012 10:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8btVS0lDYUqi for ; Mon, 6 Feb 2012 10:03:51 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3D021F86C2 for ; Mon, 6 Feb 2012 10:03:51 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Feb 2012 10:03:51 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 6 Feb 2012 10:03:51 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 6 Feb 2012 10:03:49 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-dkim-reporting-09.txt Thread-Index: Aczkz4x6ExbrVnieS6+Q3te1DuwJFgAKPQzg Message-ID: References: <20120206051703.7640.91731.idtracker@ietfa.amsl.com> <2891512.IOemTbiojJ@scott-latitude-e6320> <83f0989f-aebe-4288-b93e-1805193387ac@email.android.com> In-Reply-To: <83f0989f-aebe-4288-b93e-1805193387ac@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-09.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, 06 Feb 2012 18:03:51 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Monday, February 06, 2012 5:02 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-09.txt >=20 > 1. If the DKIM and SPF drafts are supposed to be supported by this > draft, then the discussion on reporting address discovery is > inadequate. Those drafts enable domains to explicitly publish reporting > addresses, so the heuristics for address discovery in this draft are > inappropriate for those types of reports. >=20 > My preferred solution to this problem would be to separate them again > (not providing a recommended diff since it's just reverting some of the > changes in the last update). That's one option. Another is to indicate that for automatic reports, a sp= ecific reporting address SHOULD be advertised by the party requesting the r= eports, and then refer to the two reporting drafts as examples. > 2. Strongly suggesting use of SPF is, in my opinion, not appropriate in > a general document like this. The current text adds up to SHOULD use > SPF. The way it was before (IIRC), SPF only came up in the SPF draft. > I suspect a general SHOULD SPF is going to be a hard sell in a > standards track document that's not limited in scope to domains already > interested in SPF. >=20 > 3. Due to now saying senders SHOULD use SPF in the envelope sender > selection paragraph, the reference to RFC 4408 needs to be normative > now. >=20 > My solution for #2 and #3 is the same as #1. The SPF-specific text (i.e., the last paragraph of the AS Section 9.2) coul= d be moved back to the SPF document, with more generic text left behind in = the AS so that it addresses the problem without naming SPF specifically. -MSK From msk@cloudmark.com Mon Feb 6 10:07:09 2012 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 5EDE021F86E3 for ; Mon, 6 Feb 2012 10:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aZgH3FdAikd for ; Mon, 6 Feb 2012 10:07:09 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id F1D4E21F86E2 for ; Mon, 6 Feb 2012 10:07:08 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Feb 2012 10:07:08 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 6 Feb 2012 10:07:07 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Mon, 6 Feb 2012 10:07:06 -0800 Thread-Topic: [marf] Working Group Last Call on draft-ietf-marf-as-05 Thread-Index: Aczk6fUW9noohUpbQ3yZoDUuQkrmigAEATew Message-ID: References: <20120206155606.D015CF5808A@smtp.patriot.net> In-Reply-To: <20120206155606.D015CF5808A@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 06 Feb 2012 18:07:09 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Monday, February 06, 2012 6:13 AM > To: marf@ietf.org > Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 >=20 > >Agree with the "some". >=20 > I notice "some" that it isn't in draft-ietf-marf-as-06.txt; is that > deliberate or inadvertent? The paragraph was overhauled by the submission of some text from Alessandro= . Where would you like to see "some" inserted in this version? -MSK From msk@cloudmark.com Mon Feb 6 10:09:12 2012 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 2C4C721F85EE for ; Mon, 6 Feb 2012 10:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zymqNosu2Lik for ; Mon, 6 Feb 2012 10:09:11 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1EF21F84B6 for ; Mon, 6 Feb 2012 10:09:03 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Feb 2012 10:09:03 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 6 Feb 2012 10:09:03 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Mon, 6 Feb 2012 10:09:01 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-06.txt Thread-Index: Aczk6WbZhlvAUr/mQYaC+HAHyMMyLwAEOYVA Message-ID: References: <20120206051656.8064.8480.idtracker@ietfa.amsl.com> <20120206155237.63714F5808A@smtp.patriot.net> In-Reply-To: <20120206155237.63714F5808A@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-as-06.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, 06 Feb 2012 18:09:12 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Monday, February 06, 2012 6:40 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-06.txt >=20 > In 8. Generating and Handling Unsolicited Reports, if a MUST is > appropriate in item 6 then surely it is also appropriate in item 12. I > suggest >=20 > 6. A report generator MUST provide a way for a report recipient > to request no further reports be sent to that address, > unless the provider only accepts abuse complaints in ARF > format, and MAY provide a way for recipients to change the > address(es) to which reports about them are sent. Why are ARF-only receivers exempt from this MUST? From sklist@kitterman.com Mon Feb 6 10:13:59 2012 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 A9D3121F869C for ; Mon, 6 Feb 2012 10:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLaSTDBBWugP for ; Mon, 6 Feb 2012 10:13:59 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C72E821F856C for ; Mon, 6 Feb 2012 10:13:58 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4EFCB20E4126; Mon, 6 Feb 2012 13:13:58 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328552038; bh=qTBni8v5WBJ9Pmx1n/gUjI397BXkhOiiqoVXQpz55hg=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=CWsyvCj9I1aONSkolyTqCyuZ/WK23vwdLvoiwbIU3jxL3IivO3hMUHbuqr98zLeSf d3V2rYVGSozIWXbRd0SRZ3bXNnYHRSzNwTdlEjyN9el+7tf+KIepUPKAOdTja+y9CW CsPwVm9O013cUMwxsw+jwsdQoxbsRvamMaZrEYIE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2EE1520E408E; Mon, 6 Feb 2012 13:13:57 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Mon, 06 Feb 2012 13:13:57 -0500 Message-ID: <265713811.Oxg5BB6jze@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120206051703.7640.91731.idtracker@ietfa.amsl.com> <83f0989f-aebe-4288-b93e-1805193387ac@email.android.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-09.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, 06 Feb 2012 18:13:59 -0000 On Monday, February 06, 2012 10:03:49 AM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Monday, February 06, 2012 5:02 AM > > To: marf@ietf.org > > Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-09.txt > > > > 1. If the DKIM and SPF drafts are supposed to be supported by this > > draft, then the discussion on reporting address discovery is > > inadequate. Those drafts enable domains to explicitly publish reporting > > addresses, so the heuristics for address discovery in this draft are > > inappropriate for those types of reports. > > > > My preferred solution to this problem would be to separate them again > > (not providing a recommended diff since it's just reverting some of the > > changes in the last update). > > That's one option. Another is to indicate that for automatic reports, a > specific reporting address SHOULD be advertised by the party requesting the > reports, and then refer to the two reporting drafts as examples. I've read the AS draft again and other than the text you just moved into it, I don't find it particularly useful for implementers of auth failure FBRs. I think the minimal efficiency for document producers provided by having one draft to update is more than offset by increased complexity for implementers having to sorth through a lot of irrelevant advice. > > 2. Strongly suggesting use of SPF is, in my opinion, not appropriate in > > a general document like this. The current text adds up to SHOULD use > > SPF. The way it was before (IIRC), SPF only came up in the SPF draft. > > I suspect a general SHOULD SPF is going to be a hard sell in a > > standards track document that's not limited in scope to domains already > > interested in SPF. > > > > 3. Due to now saying senders SHOULD use SPF in the envelope sender > > selection paragraph, the reference to RFC 4408 needs to be normative > > now. > > > > My solution for #2 and #3 is the same as #1. > > The SPF-specific text (i.e., the last paragraph of the AS Section 9.2) could > be moved back to the SPF document, with more generic text left behind in > the AS so that it addresses the problem without naming SPF specifically. Except that as written, 9.2 isn't giving advice for just SPF auth failure results. It's now giving advice for all ARFs (as I understand it), so I don't think it can be pushed off into a document on how to due auth failure ARFs for SPF. Scott K From msk@cloudmark.com Mon Feb 6 10:19:58 2012 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 C5D4321F8726 for ; Mon, 6 Feb 2012 10:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8aCMBoK9znY for ; Mon, 6 Feb 2012 10:19:58 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5644821F8723 for ; Mon, 6 Feb 2012 10:19:58 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 Feb 2012 10:19:58 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 6 Feb 2012 10:19:58 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 6 Feb 2012 10:19:56 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-dkim-reporting-09.txt Thread-Index: Aczk+yYvzAZY3s+0TXeT0eobPzM0dAAAEItw Message-ID: References: <20120206051703.7640.91731.idtracker@ietfa.amsl.com> <83f0989f-aebe-4288-b93e-1805193387ac@email.android.com> <265713811.Oxg5BB6jze@scott-latitude-e6320> In-Reply-To: <265713811.Oxg5BB6jze@scott-latitude-e6320> 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-dkim-reporting-09.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, 06 Feb 2012 18:19:58 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Monday, February 06, 2012 10:14 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-09.txt >=20 > I've read the AS draft again and other than the text you just moved > into it, I don't find it particularly useful for implementers of auth > failure FBRs. I think the minimal efficiency for document producers > provided by having one draft to update is more than offset by increased > complexity for implementers having to sorth through a lot of irrelevant > advice. What I'm trying to avoid is having the same text in two documents (the two = reporting drafts) without having to spin up yet another document to contain= the common factoring. As Barry pointed out, the AS is essentially our ans= wer to the "How do you use ARF?" question in general, so it seems like a re= asonable path to me. That said, this has to have consensus, so I'm open to other opinions. > > The SPF-specific text (i.e., the last paragraph of the AS Section 9.2) > > could be moved back to the SPF document, with more generic text left > > behind in the AS so that it addresses the problem without naming SPF > specifically. >=20 > Except that as written, 9.2 isn't giving advice for just SPF auth > failure results. It's now giving advice for all ARFs (as I understand > it), so I don't think it can be pushed off into a document on how to > due auth failure ARFs for SPF. Right, and my suggestion is to fix that by removing the SPF-specific stuff = back to your document, as you suggested, and leaving something more general= ly applicable in its place. It would not, for example, reappear in the DKI= M reporting draft. Section 9 overall is about automatic report generation such as is defined i= n the two reporting documents we have now, and how doing so differs from th= e rest of the document. I thought the text in Section 9 itself says that, = but I can make it more explicit if needed. -MSK From johnl@iecc.com Mon Feb 6 11:35:33 2012 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 EE27521F8733 for ; Mon, 6 Feb 2012 11:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.568 X-Spam-Level: X-Spam-Status: No, score=-109.568 tagged_above=-999 required=5 tests=[AWL=1.631, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADfETGAkvHFo for ; Mon, 6 Feb 2012 11:35:33 -0800 (PST) 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 A3E7F21F85F9 for ; Mon, 6 Feb 2012 11:35:24 -0800 (PST) Received: (qmail 71490 invoked from network); 6 Feb 2012 19:35:23 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Feb 2012 19:35:23 -0000 Date: 6 Feb 2012 19:35:01 -0000 Message-ID: <20120206193501.90336.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <20120206174024.54825.qmail@joyce.lan> 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-dkim-reporting-09.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, 06 Feb 2012 19:35:34 -0000 In article <20120206174024.54825.qmail@joyce.lan> you write: >>How's that look? Oops, having now read the correct document, you need to say that _report._domainkey.foo can return only one TXT record, no asking for three different reports, but other than that, it's fine. Ship it. R's, John From shmuel+gen@patriot.net Tue Feb 7 02:00:16 2012 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 E0A6221F870B for ; Tue, 7 Feb 2012 02:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.656 X-Spam-Level: X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dg8368T+rp+S for ; Tue, 7 Feb 2012 02:00:16 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 97B4C21F8705 for ; Tue, 7 Feb 2012 02:00:15 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.50]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 711A5F58089 for ; Tue, 7 Feb 2012 04:45:43 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 06 Feb 2012 18:34:46 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120207094543.711A5F58089@smtp.patriot.net> Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 10:00:17 -0000 In , on 02/06/2012 at 10:07 AM, "Murray S. Kucherawy" said: >The paragraph was overhauled by the submission of some text from >Alessandro. Where would you like to see "some" inserted in this >version? 8. Generating and Handling Unsolicited Reports 13. Experience suggests ... can legitimately presume that some recipients ... -- 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 Tue Feb 7 02:00:18 2012 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 B4BDE21F85F9 for ; Tue, 7 Feb 2012 02:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.653 X-Spam-Level: X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+jqszDhb7qO for ; Tue, 7 Feb 2012 02:00:18 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4E26521F873D for ; Tue, 7 Feb 2012 02:00:18 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.50]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 1078CF58089 for ; Tue, 7 Feb 2012 04:45:45 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 06 Feb 2012 18:36:04 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120207094547.1078CF58089@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-06.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 10:00:18 -0000 In , on 02/06/2012 at 10:09 AM, "Murray S. Kucherawy" said: >Why are ARF-only receivers exempt from this MUST? Because they don't support the normal channel for reporting abuse. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From vesely@tana.it Tue Feb 7 02:55:25 2012 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 527F421F8625 for ; Tue, 7 Feb 2012 02:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3mr-PbmAJEH for ; Tue, 7 Feb 2012 02:55:24 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 760F121F8622 for ; Tue, 7 Feb 2012 02:55:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328612122; bh=1X/4BkGsBgj7feaBeodyoQpCpo+bExEt60IZbCcwQu0=; l=472; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=TMBfG3OB79azgWwk2AD6FXM4pcPoso5WW6rOetKLv6JUD/t1FC4AoyJHtq+8Xcm+u ePU6+NFoocdfcqP/z2U8T1JJgJuHfHDk/ldeBmB871Szm5VKygGCjVVNgF2T1Ka6fj Glt0HYc293/AKNNPjt6N/sRaRjUR5gZPAdLWMSAU= 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, 07 Feb 2012 11:55:22 +0100 id 00000000005DC042.000000004F31031A.00005F70 Message-ID: <4F31031B.3040107@tana.it> Date: Tue, 07 Feb 2012 11:55:23 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120207094547.1078CF58089@smtp.patriot.net> In-Reply-To: <20120207094547.1078CF58089@smtp.patriot.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-06.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, 07 Feb 2012 10:55:25 -0000 On 07/Feb/12 00:36, Shmuel (Seymour J.) Metz wrote: > In > , > on 02/06/2012 > at 10:09 AM, "Murray S. Kucherawy" said: > >> Why are ARF-only receivers exempt from this MUST? > > Because they don't support the normal channel for reporting abuse. What is the "normal" channel? Section 8 is limited to sending unsolicited reports, which is deemed "typically heuristic". From vesely@tana.it Tue Feb 7 03:21:26 2012 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 5180021F8705 for ; Tue, 7 Feb 2012 03:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxfGaVYbyyIP for ; Tue, 7 Feb 2012 03:21:25 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8885521F86F8 for ; Tue, 7 Feb 2012 03:21:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328613680; bh=yO9v+1OPMF7c/kGt1hfi2iE6oEFIB6OtxIeKJW97Xek=; l=389; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=LDH3f5eUubxsxRkJ/Tvv77a6VMhZFQYgKXYWq+iDi9KrAgpargfhKpMLh//PbbFrp Xo/vZElZL5lhuzxclArMEYOglKwoj8UKMcd4uJVYMozbaWW2+yXa0k4zwH4PRKk5iJ meHh+pweoLBnbk+sKOl+U9b6wBmYQVMUzeLA5bLk= 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, 07 Feb 2012 12:21:20 +0100 id 00000000005DC042.000000004F310930.00006575 Message-ID: <4F310930.4030003@tana.it> Date: Tue, 07 Feb 2012 12:21:20 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <4F300CBE.9030804@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] VERP in 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, 07 Feb 2012 11:21:26 -0000 On 06/Feb/12 18:52, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of John R Levine >> >>> Do we want to say something like this? >> >> No. > > I agree. See my previous desire to avoid turning this into an ARF > cookbook. Oh well, be that as it may. RFC 3834's role, however, has to be stated, lest opposing interpretations pop out the same question over and over. From msk@cloudmark.com Tue Feb 7 09:25:18 2012 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 8946721F8827 for ; Tue, 7 Feb 2012 09:25:18 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JO8qDX8VOx-w for ; Tue, 7 Feb 2012 09:25:18 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 383BD21F87EB for ; Tue, 7 Feb 2012 09:25:18 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 7 Feb 2012 09:25:17 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 7 Feb 2012 09:25:17 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 7 Feb 2012 09:25:16 -0800 Thread-Topic: [marf] VERP in marf-as Thread-Index: AczliqNKu14SabczSROAQE4s/wOCyQAMrTow Message-ID: References: <4F300CBE.9030804@tana.it> <4F310930.4030003@tana.it> In-Reply-To: <4F310930.4030003@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] VERP in 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, 07 Feb 2012 17:25:18 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Alessandro Vesely > Sent: Tuesday, February 07, 2012 3:21 AM > To: marf@ietf.org > Subject: Re: [marf] VERP in marf-as >=20 > RFC 3834's role, however, has to be stated, lest opposing > interpretations pop out the same question over and over. I don't agree. RFC3834 appears to be about how to write auto-responders li= ke vacation services. In fact Section 3.2.1 suggests that there are cases = where not using it is the right thing to do (DSNs, for example), and I thin= k ARF is one of those cases. -MSK From msk@cloudmark.com Tue Feb 7 09:26:20 2012 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 CC6E521F8894 for ; Tue, 7 Feb 2012 09:26:20 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHUp6c4InEvT for ; Tue, 7 Feb 2012 09:26:20 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1E32D21F889A for ; Tue, 7 Feb 2012 09:26:18 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 7 Feb 2012 09:26:17 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 7 Feb 2012 09:26:17 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Tue, 7 Feb 2012 09:26:16 -0800 Thread-Topic: [marf] Working Group Last Call on draft-ietf-marf-as-05 Thread-Index: Aczlf00vHrkg6YZITKOu3Hmbu7WplAAPkTig Message-ID: References: <20120207094543.711A5F58089@smtp.patriot.net> In-Reply-To: <20120207094543.711A5F58089@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 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, 07 Feb 2012 17:26:20 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Monday, February 06, 2012 3:35 PM > To: marf@ietf.org > Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05 >=20 > 8. Generating and Handling Unsolicited Reports >=20 > 13. Experience suggests ... can legitimately presume that some > recipients ... Done. From shmuel+gen@patriot.net Tue Feb 7 09:42:37 2012 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 5162721F86CF for ; Tue, 7 Feb 2012 09:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdJFUg6OX32S for ; Tue, 7 Feb 2012 09:42:36 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id D67DB21F86CB for ; Tue, 7 Feb 2012 09:42:36 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.160]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 6DCA9F580A3 for ; Tue, 7 Feb 2012 12:28:04 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Tue, 07 Feb 2012 08:14:22 -0500 To: marf@ietf.org In-Reply-To: <4F31031B.3040107@tana.it> Mail-Copies-To: nobody 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: <20120207172804.6DCA9F580A3@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-06.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 17:42:37 -0000 In <4F31031B.3040107@tana.it>, on 02/07/2012 at 11:55 AM, Alessandro Vesely said: >What is the "normal" channel? Plain text messages to the abuse and postmaster mailboxes. >Section 8 is limited to sending unsolicited reports, Understood. The question is whether somebody complaining about UBE from a network has to shut up and eat his spam. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From vesely@tana.it Tue Feb 7 10:35:24 2012 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 B91C921F88BC for ; Tue, 7 Feb 2012 10:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxWyNSU+xJc8 for ; Tue, 7 Feb 2012 10:35:24 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D597E21F888A for ; Tue, 7 Feb 2012 10:35:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328639722; bh=BZ3v2MTZZ6C5hTlxi+nu4GRhR4InOlPTMszAoevAHqo=; l=682; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=l8ejxMLJ9uuVUK43j3Pg/qlAwm+3mUEzDWFDvcO4jT8aLe2O15Fj4YPnf2c/j3ObL DqhPO6CS9ZoaOyPvA69DkC61IuwWvMODvITk2OTx5W5ZDB4uXaPUOlgdC2yrgZM03r gXrk0+eBLVM+1KVFtC1x1QlplrZSZSWoYJBRLTHs= 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, 07 Feb 2012 19:35:22 +0100 id 00000000005DC04A.000000004F316EEA.0000507F Message-ID: <4F316EEA.4010206@tana.it> Date: Tue, 07 Feb 2012 19:35:22 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <4F300CBE.9030804@tana.it> <4F310930.4030003@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [marf] Automatic Responses, was VERP 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, 07 Feb 2012 18:35:24 -0000 On 07/Feb/12 18:25, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely > >> RFC 3834's role, however, has to be stated, lest opposing >> interpretations pop out the same question over and over. > > RFC3834 appears to be about how to write auto-responders like > vacation services. In fact Section 3.2.1 suggests that there are > cases where not using it is the right thing to do (DSNs, for > example), and I think ARF is one of those cases. I think we ought to write that on the spec, otherwise it will be debatable forever. Report generators are not automatic responders in the sense of Section 3.2.1 of [RFC3834] would work for me. From vesely@tana.it Tue Feb 7 10:46:23 2012 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 27EBF11E80AF for ; Tue, 7 Feb 2012 10:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.65 X-Spam-Level: X-Spam-Status: No, score=-4.65 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjnHwMKu+ana for ; Tue, 7 Feb 2012 10:46:22 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD0B11E80B6 for ; Tue, 7 Feb 2012 10:46:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328640381; bh=hbYb2LWYKYfgY5tSzgXQgtg6MJO22Pl+cWskTSRZXzE=; l=600; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=L0/8i77XtxQV9cu9CTVKp0KNAx1zqvNnv7vOlg8JS4aRGBb4nWov2aTk0fEXPKD+R I3HB5T9oAwmJfxHfBxdnOtq2Gd6ihGCQToRzyuWYV+bkL333kByZ7K4G3mshRMSAmV U+SStNVHi4IZIgCdcpgBOwBOCuZ8Ht1a9a0nhdYI= 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, 07 Feb 2012 19:46:21 +0100 id 00000000005DC046.000000004F31717D.00005369 Message-ID: <4F31717D.6080507@tana.it> Date: Tue, 07 Feb 2012 19:46:21 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120207172804.6DCA9F580A3@smtp.patriot.net> In-Reply-To: <20120207172804.6DCA9F580A3@smtp.patriot.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-06.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, 07 Feb 2012 18:46:23 -0000 On 07/Feb/12 14:14, Shmuel (Seymour J.) Metz wrote: > In <4F31031B.3040107@tana.it>, on 02/07/2012 > at 11:55 AM, Alessandro Vesely said: > >> Section 8 is limited to sending unsolicited reports, > > Understood. The question is whether somebody complaining about UBE > from a network has to shut up and eat his spam. Got it. Nevertheless, we don't want to encourage retaliation, do we? IMHO, it is useful to just know that a domain doesn't want to get complaints about any spam it sends. It is up to recipients to decide what to do with messages having such senders. From msk@cloudmark.com Tue Feb 7 11:24:24 2012 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 D0B0C21F87E8 for ; Tue, 7 Feb 2012 11:24:23 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXiAyudAt5pQ for ; Tue, 7 Feb 2012 11:24:23 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5282521F87DA for ; Tue, 7 Feb 2012 11:24:23 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 7 Feb 2012 11:24:22 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 7 Feb 2012 11:24:22 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 7 Feb 2012 11:24:20 -0800 Thread-Topic: [marf] Automatic Responses, was VERP Thread-Index: Aczlx0L+qpNV9r+ARomXS13l6fckdgABpaUQ Message-ID: References: <4F300CBE.9030804@tana.it> <4F310930.4030003@tana.it> <4F316EEA.4010206@tana.it> In-Reply-To: <4F316EEA.4010206@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] Automatic Responses, was VERP 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, 07 Feb 2012 19:24:24 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Tuesday, February 07, 2012 10:35 AM > To: marf@ietf.org > Subject: [marf] Automatic Responses, was VERP >=20 > > RFC3834 appears to be about how to write auto-responders like vacation > > services. In fact Section 3.2.1 suggests that there are cases where > > not using it is the right thing to do (DSNs, for example), and I think > > ARF is one of those cases. >=20 > I think we ought to write that on the spec, otherwise it will be > debatable forever. >=20 > Report generators are not automatic responders in the sense of > Section 3.2.1 of [RFC3834] >=20 > would work for me. Does anyone else think this is necessary? I don't think RFC3834 covers wha= t we're doing here at all, so I don't think we need to be concerned about p= ossible debate on the topic. From shmuel+gen@patriot.net Tue Feb 7 13:55:47 2012 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 9853711E8074 for ; Tue, 7 Feb 2012 13:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScL3pl1rDuNx for ; Tue, 7 Feb 2012 13:55:47 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6098B11E8073 for ; Tue, 7 Feb 2012 13:55:46 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.237]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 38A39F580A9 for ; Tue, 7 Feb 2012 16:41:11 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Tue, 07 Feb 2012 16:19:16 -0500 To: marf@ietf.org In-Reply-To: <4F31717D.6080507@tana.it> Mail-Copies-To: nobody 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: <20120207214113.38A39F580A9@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-06.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 21:55:47 -0000 In <4F31717D.6080507@tana.it>, on 02/07/2012 at 07:46 PM, Alessandro Vesely said: >Nevertheless, we don't want to encourage retaliation, do we? First, I wouldn't call one complaint per spam received retaliation. Second. I would support non-abusive[1[ retaliation where feasible, e.g., * Blocking of ASN * Boycotts * Criminal complaints * Lawsuits [1] And out of scope fot 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 R.E.Sonneveld@sonnection.nl Tue Feb 7 15:27:22 2012 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 2090B21F847B for ; Tue, 7 Feb 2012 15:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzE30YTC2mMl for ; Tue, 7 Feb 2012 15:27:21 -0800 (PST) Received: from mx11.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by ietfa.amsl.com (Postfix) with ESMTP id C3DD911E807F for ; Tue, 7 Feb 2012 15:27:16 -0800 (PST) Received: from process-dkim-sign-daemon.hydrogen.mailtransaction.com by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0LZ100500QHFGZ00@hydrogen.mailtransaction.com>; Wed, 08 Feb 2012 00:27:15 +0100 (CET) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0LZ100E17QHEWV00@hydrogen.mailtransaction.com>; Wed, 08 Feb 2012 00:27:15 +0100 (CET) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_gnu8syDG+8U42AfQR+54mQ)" Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0LZ100A34QHEQZ00@lion.sonnection.nl> for marf@ietf.org; Wed, 08 Feb 2012 00:27:14 +0100 (CET) Message-id: <4F31B4B9.70708@sonnection.nl> Date: Wed, 08 Feb 2012 00:33:13 +0100 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 To: "Murray S. Kucherawy" References: <4F300CBE.9030804@tana.it> <4F310930.4030003@tana.it> <4F316EEA.4010206@tana.it> In-reply-to: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1328657235; bh=I6U7WRxYYliZ/Ex0evaK2V89/hVRu6zPpA26kxAN91Y=; h=MIME-version:Content-type:Message-id:Date:From:To:Cc:Subject: References:In-reply-to; b=VEPSJM8hipkhtRWuKMfBH6uF/qPcxNgm3pv0Z9sBNMmoKzQbnIiGw8PNXAXX4UHuW CFi0gtucxbq6sG6GM+iU1ANoAlxcL1Vz3M4r5l+w/hL0CYgAW5ChfC3xcqwFE9Rj1F YyNKeBSpLyWH4JlW039nBrEhX31b9rq0ItgrjzdI= X-DKIM: OpenDKIM Filter v2.1.3 hydrogen.mailtransaction.com 0LZ100500QHFGZ00 Cc: "marf@ietf.org" Subject: Re: [marf] Automatic Responses, was VERP 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, 07 Feb 2012 23:27:22 -0000 This is a multi-part message in MIME format. --Boundary_(ID_gnu8syDG+8U42AfQR+54mQ) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT On 2/7/12 8:24 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Alessandro Vesely >> Sent: Tuesday, February 07, 2012 10:35 AM >> To: marf@ietf.org >> Subject: [marf] Automatic Responses, was VERP >> >>> RFC3834 appears to be about how to write auto-responders like vacation >>> services. In fact Section 3.2.1 suggests that there are cases where >>> not using it is the right thing to do (DSNs, for example), and I think >>> ARF is one of those cases. >> I think we ought to write that on the spec, otherwise it will be >> debatable forever. >> >> Report generators are not automatic responders in the sense of >> Section 3.2.1 of [RFC3834] >> >> would work for me. > Does anyone else think this is necessary? I don't think RFC3834 covers what we're doing here at all, so I don't think we need to be concerned about possible debate on the topic. Hmm. RFC3834 identifies three classes of responders, among which Group Responders: > - "Group Responders" exist to make automatic responses on behalf of > any of a significant set of recipient addresses (say, every > recipient in a particular DNS domain), in advance of, or in lieu > of, a response from the actual recipient. Group Responders are > similar to Personal Responders except that in the case of a Group > Responder the criteria for responding are not set on a per- > recipient basis. A "virus scanner" program that filtered all mail > sent to any recipient on a particular server, and sent responses > when a message was rejected or delivered in an altered form, might > be an example of a Group Responder. This sounds a bit like the type of feedback we're talking about in the context of ARF (and DMARC for example). And as some of the topics, discussed in RFC3834, might be discussed also for ARF (loop prevention etc.) I'm not sure RFC3834 can completely be ignored. If however we all agree that RFC3834 has no relationship to ARF, then let's explicitly mention this, as Alessandro proposed. /rolf --Boundary_(ID_gnu8syDG+8U42AfQR+54mQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On 2/7/12 8:24 PM, Murray S. Kucherawy wrote: 
-----Original Message-----
From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Alessandro Vesely
Sent: Tuesday, February 07, 2012 10:35 AM
To: marf@ietf.org
Subject: [marf] Automatic Responses, was VERP


RFC3834 appears to be about how to write auto-responders like vacation
services.  In fact Section 3.2.1 suggests that there are cases where
not using it is the right thing to do (DSNs, for example), and I think
ARF is one of those cases.

I think we ought to write that on the spec, otherwise it will be
debatable forever.

  Report generators are not automatic responders in the sense of
  Section 3.2.1 of [RFC3834]

would work for me.

Does anyone else think this is necessary?  I don't think RFC3834 covers what we're doing here at all, so I don't think we need to be concerned about possible debate on the topic.

Hmm. RFC3834 identifies three classes of responders, among which Group Responders:

   -  "Group Responders" exist to make automatic responses on behalf of
      any of a significant set of recipient addresses (say, every
      recipient in a particular DNS domain), in advance of, or in lieu
      of, a response from the actual recipient.  Group Responders are
      similar to Personal Responders except that in the case of a Group
      Responder the criteria for responding are not set on a per-
      recipient basis.  A "virus scanner" program that filtered all mail
      sent to any recipient on a particular server, and sent responses
      when a message was rejected or delivered in an altered form, might
      be an example of a Group Responder.

This sounds a bit like the type of feedback we're talking about in the context of ARF (and DMARC for example). And as some of the topics, discussed in RFC3834, might be discussed also for ARF (loop prevention etc.) I'm not sure RFC3834 can completely be ignored.

If however we all agree that RFC3834 has no relationship to ARF, then let's explicitly mention this, as Alessandro proposed.

/rolf
--Boundary_(ID_gnu8syDG+8U42AfQR+54mQ)-- From msk@cloudmark.com Tue Feb 7 15:31:27 2012 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 3D29121F87C7 for ; Tue, 7 Feb 2012 15:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfBGGfA4cJcm for ; Tue, 7 Feb 2012 15:31:25 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6AF21F87C0 for ; Tue, 7 Feb 2012 15:31:25 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 7 Feb 2012 15:31:24 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 7 Feb 2012 15:31:24 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 7 Feb 2012 15:31:24 -0800 Thread-Topic: [marf] Automatic Responses, was VERP Thread-Index: Aczl8Al5bMpnE2xgTMq0trt2jHWhiQAABe2w Message-ID: References: <4F300CBE.9030804@tana.it> <4F310930.4030003@tana.it> <4F316EEA.4010206@tana.it> <4F31B4B9.70708@sonnection.nl> In-Reply-To: <4F31B4B9.70708@sonnection.nl> 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_F5833273385BB34F99288B3648C4F06F19C9A7DC5AEXCHC2corpclo_" MIME-Version: 1.0 Subject: Re: [marf] Automatic Responses, was VERP 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, 07 Feb 2012 23:31:27 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DC5AEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rolf, ARFs are not typically sent in place of delivery of a message, such as is t= he case when a virus scanner rejects a message. ARF is normally generated = in response to a user action post-delivery. For the case of DKIM and SPF reports, rejection on failure is actually impr= oper most of the time (the exceptions being ADSP and SPF "-all", both of wh= ich are currently discouraged). What I'm trying to avoid is accumulating a list of informative references d= escribing what ARF is not. It seems to me that it's far less confusing for= unfamiliar readers just to say what ARF is, and stop. That said, if there's consensus to include it, we can add it. -MSK From: Rolf E. Sonneveld [mailto:R.E.Sonneveld@sonnection.nl] Sent: Tuesday, February 07, 2012 3:33 PM To: Murray S. Kucherawy Cc: marf@ietf.org Subject: Re: [marf] Automatic Responses, was VERP On 2/7/12 8:24 PM, Murray S. Kucherawy wrote: -----Original Message----- From: marf-bounces@ietf.org [mailto:marf-boun= ces@ietf.org] On Behalf Of Alessandro Vesely Sent: Tuesday, February 07, 2012 10:35 AM To: marf@ietf.org Subject: [marf] Automatic Responses, was VERP RFC3834 appears to be about how to write auto-responders like vacation services. In fact Section 3.2.1 suggests that there are cases where not using it is the right thing to do (DSNs, for example), and I think ARF is one of those cases. I think we ought to write that on the spec, otherwise it will be debatable forever. Report generators are not automatic responders in the sense of Section 3.2.1 of [RFC3834] would work for me. Does anyone else think this is necessary? I don't think RFC3834 covers wha= t we're doing here at all, so I don't think we need to be concerned about p= ossible debate on the topic. Hmm. RFC3834 identifies three classes of responders, among which Group Resp= onders: - "Group Responders" exist to make automatic responses on behalf of any of a significant set of recipient addresses (say, every recipient in a particular DNS domain), in advance of, or in lieu of, a response from the actual recipient. Group Responders are similar to Personal Responders except that in the case of a Group Responder the criteria for responding are not set on a per- recipient basis. A "virus scanner" program that filtered all mail sent to any recipient on a particular server, and sent responses when a message was rejected or delivered in an altered form, might be an example of a Group Responder. This sounds a bit like the type of feedback we're talking about in the cont= ext of ARF (and DMARC for example). And as some of the topics, discussed in= RFC3834, might be discussed also for ARF (loop prevention etc.) I'm not su= re RFC3834 can completely be ignored. If however we all agree that RFC3834 has no relationship to ARF, then let's= explicitly mention this, as Alessandro proposed. /rolf --_000_F5833273385BB34F99288B3648C4F06F19C9A7DC5AEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Rolf,

 = ;

ARFs are not typically sent i= n place of delivery of a message, such as is the case when a virus scanner = rejects a message.  ARF is normally generated in response to a user ac= tion post-delivery.

 

For the case of DKIM an= d SPF reports, rejection on failure is actually improper most of the time (= the exceptions being ADSP and SPF “-all”, both of which are cur= rently discouraged).

 

What I’m trying t= o avoid is accumulating a list of informative references describing what AR= F is not.  It seems to me that it’s far less confusing for unfam= iliar readers just to say what ARF is, and stop.

 

That said, if there’s consensus to include it, we can add it.

 

<= p class=3DMsoNormal>-MSK

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

From: Rolf E. Sonneveld [mailto:R.E.Sonnev= eld@sonnection.nl]
Sent: Tuesday, February 07, 2012 3:33 PM
<= b>To: Murray S. Kucherawy
Cc: marf@ietf.org
Subject: Re: [marf] Automatic Responses, was VERP

 

On 2/7/12 8= :24 PM, Murray S. Kucherawy wrote: 

-----Original Message-----
From: marf-bounces@iet=
f.org [mailto:marf-bounces@iet=
f.org] On Behalf Of Alessandro Vesely
Sent: Tuesda=
y, February 07, 2012 10:35 AM
To: marf@ietf.org
Subject: [marf] Automat=
ic Responses, was VERP
 
RFC3834 appears to =
be about how to write auto-responders like vacation
se=
rvices.  In fact Section 3.2.1 suggests that there are cases where
not using it is the right thing to do (DSNs, for example)=
, and I think
ARF is one of those cases.
 
I think we ought to write =
that on the spec, otherwise it will be
debatable forev=
er.
 
  Report generato=
rs are not automatic responders in the sense of
 =
 Section 3.2.1 of [RFC3834]
 
would work for me.
 
Does anyone else think this is necessary?  I don't think RFC38=
34 covers what we're doing here at all, so I don't think we need to be conc=
erned about possible debate on the topic.

Hmm. RFC3834 identifies three classes of responders, among which Gr=
oup Responders:


   -  "G=
roup Responders" exist to make automatic responses on behalf of
      any of a significant set of r=
ecipient addresses (say, every
    =
;  recipient in a particular DNS domain), in advance of, or in lieu
      of, a response from the a=
ctual recipient.  Group Responders are
 &nbs=
p;    similar to Personal Responders except that in the case=
 of a Group
      Responder t=
he criteria for responding are not set on a per-
 =
;     recipient basis.  A "virus scanner"=
; program that filtered all mail
   &nb=
sp;  sent to any recipient on a particular server, and sent responses<=
o:p>
      when a message was reje=
cted or delivered in an altered form, might
 &nbs=
p;    be an example of a Group Responder.

This sounds a bit like the type of feedback we're ta=
lking about in the context of ARF (and DMARC for example). And as some of t=
he topics, discussed in RFC3834, might be discussed also for ARF (loop prev=
ention etc.) I'm not sure RFC3834 can completely be ignored.

If howe=
ver we all agree that RFC3834 has no relationship to ARF, then let's explic=
itly mention this, as Alessandro proposed.

/rolf
= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DC5AEXCHC2corpclo_-- From johnl@iecc.com Tue Feb 7 17:37:17 2012 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 8600511E8089 for ; Tue, 7 Feb 2012 17:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.617 X-Spam-Level: X-Spam-Status: No, score=-109.617 tagged_above=-999 required=5 tests=[AWL=1.582, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYj1kWfU776L for ; Tue, 7 Feb 2012 17:37:17 -0800 (PST) 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 E302711E8088 for ; Tue, 7 Feb 2012 17:37:16 -0800 (PST) Received: (qmail 3441 invoked from network); 8 Feb 2012 01:37:16 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 8 Feb 2012 01:37:16 -0000 Date: 8 Feb 2012 01:36:54 -0000 Message-ID: <20120208013654.53677.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] Automatic Responses, was VERP 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, 08 Feb 2012 01:37:17 -0000 >Does anyone else think this is necessary? No. From internet-drafts@ietf.org Tue Feb 7 22:39:18 2012 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 13A0D21F8627; Tue, 7 Feb 2012 22:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pkdh06eR-VRc; Tue, 7 Feb 2012 22:39:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E9321F8604; Tue, 7 Feb 2012 22:39:17 -0800 (PST) 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.64p1 Message-ID: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> Date: Tue, 07 Feb 2012 22:39:17 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-as-07.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, 08 Feb 2012 06:39:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Messaging Abuse Reporting Format Work= ing Group of the IETF. Title : Creation and Use of Email Feedback Reports: An Applicabi= lity Statement for the Abuse Reporting Format (ARF) Author(s) : J.D. Falk M. Kucherawy Filename : draft-ietf-marf-as-07.txt Pages : 13 Date : 2012-02-07 RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This document describes common methods for utilizing this format for reporting both abuse and authentication failure events. Mailbox Providers of any size, mail sending entities, and end users can use these methods as a basis to create procedures that best suit them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-as-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-as-07.txt From msk@cloudmark.com Tue Feb 7 22:42:40 2012 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 B78DE21F86A2 for ; Tue, 7 Feb 2012 22:42:40 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbHhik8t+Frq for ; Tue, 7 Feb 2012 22:42:40 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4D41421F8693 for ; Tue, 7 Feb 2012 22:42:40 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 7 Feb 2012 22:42:39 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 7 Feb 2012 22:42:39 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 7 Feb 2012 22:42:46 -0800 Thread-Topic: I-D Action: draft-ietf-marf-as-07.txt Thread-Index: AczmLGujtusy/zrvSo2L8Qp2YoKYNgAAAi3g Message-ID: References: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> In-Reply-To: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 08 Feb 2012 06:42:40 -0000 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org > Sent: Tuesday, February 07, 2012 10:39 PM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: I-D Action: draft-ietf-marf-as-07.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Messaging Abuse Reporting > Format Working Group of the IETF. >=20 > Title : Creation and Use of Email Feedback Reports: An > Applicability Statement for the Abuse Reporting Format (ARF) > Author(s) : J.D. Falk > M. Kucherawy > Filename : draft-ietf-marf-as-07.txt > Pages : 13 > Date : 2012-02-07 >=20 > RFC 5965 defines an extensible, machine-readable format intended for > mail operators to report feedback about received email to other > parties. This document describes common methods for utilizing this > format for reporting both abuse and authentication failure events. > Mailbox Providers of any size, mail sending entities, and end users > can use these methods as a basis to create procedures that best suit > them. Incorporated Shmuel's tweaks, and also reworked the text to make it clear w= hich parts apply to conventional ARF reports and which parts apply to autom= ated reports like authentication failures as Scott pointed out. Still in WGLC until Friday. Have at it. -MSK From R.E.Sonneveld@sonnection.nl Wed Feb 8 01:49:22 2012 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 2D0D521F8605 for ; Wed, 8 Feb 2012 01:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.698 X-Spam-Level: X-Spam-Status: No, score=-3.698 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldnELfaz-mYP for ; Wed, 8 Feb 2012 01:49:21 -0800 (PST) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 82F5521F85FB for ; Wed, 8 Feb 2012 01:49:19 -0800 (PST) Received: from process-dkim-sign-daemon.helium.mailtransaction.com by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0LZ200D00JA5TU00@helium.mailtransaction.com>; Wed, 08 Feb 2012 10:49:18 +0100 (CET) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0LZ20011VJA50500@helium.mailtransaction.com>; Wed, 08 Feb 2012 10:49:17 +0100 (CET) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_3R9vOJaafjmC20MBc82Orw)" Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0LZ200J0IJA54000@lion.sonnection.nl> for marf@ietf.org; Wed, 08 Feb 2012 10:49:17 +0100 (CET) Message-id: <4F324685.9060808@sonnection.nl> Date: Wed, 08 Feb 2012 10:55:17 +0100 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 To: "Murray S. Kucherawy" References: <4F300CBE.9030804@tana.it> <4F310930.4030003@tana.it> <4F316EEA.4010206@tana.it> <4F31B4B9.70708@sonnection.nl> In-reply-to: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1328694558; bh=23ihsdSQZq7wefCaoy8FV5R2cQZUYjx418iny8q1Opc=; h=MIME-version:Content-type:Message-id:Date:From:To:Cc:Subject: References:In-reply-to; b=VgoG94Nuk42ur+m8XnrFGF+hM7aAAJOuL5qCmLgVZFQ//jnqzp7lsRA5hYh1TStEA PqVtrn1rsRAcd1W8WGuQ0qgLfB/Nzo0Fx4RjGogPsGjXHwJy1o9jU0wZi5kI0lp5zv DVFV+nfwfr3A+dZErp61GNfGKcwuaH5fHov9cSz0= X-DKIM: OpenDKIM Filter v2.1.3 helium.mailtransaction.com 0LZ200D00JA5TU00 Cc: "marf@ietf.org" Subject: Re: [marf] Automatic Responses, was VERP 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, 08 Feb 2012 09:49:22 -0000 This is a multi-part message in MIME format. --Boundary_(ID_3R9vOJaafjmC20MBc82Orw) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Hi, Murray, On 2/8/12 12:31 AM, Murray S. Kucherawy wrote: > > Hi Rolf, > > ARFs are not typically sent in place of delivery of a message, such as > is the case when a virus scanner rejects a message. ARF is normally > generated in response to a user action post-delivery. > > For the case of DKIM and SPF reports, rejection on failure is actually > improper most of the time (the exceptions being ADSP and SPF "-all", > both of which are currently discouraged). > I know at least one bank which uses SPF -all for a domain that reflects one of their (old/obsoleted) brand names. Furthermore I can imagine that banks will register SPF -all for lookalide domains, if they own the domainname. Similarly with ADSP and DMARC we can expect organizations that will use the 'reject' option to indicate they never send mail with domain example.com. > What I'm trying to avoid is accumulating a list of informative > references describing what ARF is not. It seems to me that it's far > less confusing for unfamiliar readers just to say what ARF is, and stop. > I understand, just leave it out. /rolf --Boundary_(ID_3R9vOJaafjmC20MBc82Orw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi, Murray,

On 2/8/12 12:31 AM, Murray S. Kucherawy wrote:

Hi Rolf,

 

ARFs are not typically sent in place of delivery of a message, such as is the case when a virus scanner rejects a message.  ARF is normally generated in response to a user action post-delivery.

 

For the case of DKIM and SPF reports, rejection on failure is actually improper most of the time (the exceptions being ADSP and SPF “-all”, both of which are currently discouraged).


I know at least one bank which uses SPF -all for a domain that reflects one of their (old/obsoleted) brand names. Furthermore I can imagine that banks will register SPF -all for lookalide domains, if they own the domainname. Similarly with ADSP and DMARC we can expect organizations that will use the 'reject' option to indicate they never send mail with domain example.com.

 

What I’m trying to avoid is accumulating a list of informative references describing what ARF is not.  It seems to me that it’s far less confusing for unfamiliar readers just to say what ARF is, and stop.


I understand, just leave it out.

/rolf

--Boundary_(ID_3R9vOJaafjmC20MBc82Orw)-- From steve@wordtothewise.com Wed Feb 8 06:26:36 2012 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 8315021F863D for ; Wed, 8 Feb 2012 06:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbK35lBtEaA0 for ; Wed, 8 Feb 2012 06:26:34 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 8198D21F85DD for ; Wed, 8 Feb 2012 06:26:34 -0800 (PST) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id C4B942DDE4 for ; Wed, 8 Feb 2012 06:26:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Steve Atkins In-Reply-To: Date: Wed, 8 Feb 2012 06:26:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <17BC3B48-8118-442C-A51C-8D7A7043C982@wordtothewise.com> References: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1257) Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 08 Feb 2012 14:26:36 -0000 On Feb 7, 2012, at 10:42 PM, Murray S. Kucherawy wrote: >>=20 >=20 > Incorporated Shmuel's tweaks, and also reworked the text to make it = clear which parts apply to conventional ARF reports and which parts = apply to automated reports like authentication failures as Scott pointed = out. >=20 > Still in WGLC until Friday. Have at it. 8.1 talks about sending unsolicited reports of authentication failure = while 9.1 states that unsolicited reports of authentication failure MUST = NOT be sent. One of those likely needs to change (probably 8.1). 8.6 implies that the d=3D domain is always a good place to send an = unsolicited report if it leads to a deliverable email address. Is that = what we mean to say? Cheers, Steve From shmuel+gen@patriot.net Wed Feb 8 07:50:22 2012 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 4840F21F8615 for ; Wed, 8 Feb 2012 07:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[AWL=-0.812, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bPyUBdvr7Zi for ; Wed, 8 Feb 2012 07:50:21 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id C830E21F85FC for ; Wed, 8 Feb 2012 07:50:18 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.79]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id F1BECF58083 for ; Wed, 8 Feb 2012 10:35:44 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Wed, 08 Feb 2012 10:49:25 -0500 To: Message Abuse Report Format working group Mail-Copies-To: nobody 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: <20120208153544.F1BECF58083@smtp.patriot.net> Subject: [marf] RFC 2119 language 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, 08 Feb 2012 15:50:22 -0000 I believe that we need to be careful to adhere to the definitions in RFC 2119, specifically 6. Guidance in the use of these Imperatives. In particular, I don't believe that we should use MUST unless we have documented that "it is actually required for interoperation or to limit behavior which has potential for causing harm". I noticed that some drafts use [RFC2119] as a footnote label and some use [KEYWORDS]. Is that an arbitrary choice, or should we be consistently using only one, and, if so, which one? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From vesely@tana.it Wed Feb 8 08:21:14 2012 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 AB87621F87F3 for ; Wed, 8 Feb 2012 08:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnTrghygLbj9 for ; Wed, 8 Feb 2012 08:21:14 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id B424521F87E8 for ; Wed, 8 Feb 2012 08:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328718071; bh=k6Oi0U9UD2gQMMp3iBBFxgHEUw2m+90koxwCwiYr3Ys=; l=1139; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=WQBaf7ymHBxkICDOiAwjhkMtrRHiWKxwsvM+z/NQyJXIg3jDIf1AU5WSxCgw7zww2 /aoKNhau/fv6HDjRpKWtFibRLjEK+KeT8ekBVL+JXFyIx7q/0wVnYG5WcMXPRo3ktE eKlPZqUPm/agg5XbLcn4HlND7EnVH0sVJFdddMNo= 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, 08 Feb 2012 17:21:11 +0100 id 00000000005DC042.000000004F32A0F7.00001135 Message-ID: <4F32A0F7.4000002@tana.it> Date: Wed, 08 Feb 2012 17:21:11 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 08 Feb 2012 16:21:14 -0000 On 08/Feb/12 07:42, Murray S. Kucherawy wrote: > > Still in WGLC until Friday. Have at it. *Abstract* The abstract says "end users can use these methods", which may be somewhat misleading. How about "and conceivably even end users", or equivalent English text? *Generating and Handling Unsolicited Abuse Reports* I'd suggest the leading paragraph be more similar to that of Section 9, instead of: The following advice is offered for the case of reports that are not solicited: For example: There are cases where no sending parties have requested reports, possibly because they did not know how to apply, or didn't care. *Generating Automatic Authentication Failure Reports* Barry's advice on numbering is missing. Paragraph 2 seems to be overly restrictive. IMHO, it suffices to say that the report "MUST NOT be sent automatically". That way, a generator can still produce its data for local debugging or manual forwarding. I'm unable to understand the first sentence of paragraph 3. Reports have to be new messages irrespectively of whether the original message was accepted or rejected. From vesely@tana.it Wed Feb 8 08:29:27 2012 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 849EE21F8759 for ; Wed, 8 Feb 2012 08:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvCa3IuAMPAt for ; Wed, 8 Feb 2012 08:29:26 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id F2D4321F86EF for ; Wed, 8 Feb 2012 08:29:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328718564; bh=behct8QGrB3TWrV1YssvANq8ReNjekJegc6sGL/NDZ4=; l=606; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=BQP3xfwMwmHnBLs4czA2WqjXTssxMlp5ZpXdyV4/cQk5DjMJQtSPzjAw/1uIlEXXX EWa6IKFQiBo35Wyd8gquMzRplFkdMHIaMS04I+B85SQ6262MUKLziC2KBtzzNneqRq IUGXogLiqMldMGvd3o9t9YFibE/yRgFOD2Nm4FFI= 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, 08 Feb 2012 17:29:24 +0100 id 00000000005DC042.000000004F32A2E4.00001352 Message-ID: <4F32A2E4.5070608@tana.it> Date: Wed, 08 Feb 2012 17:29:24 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> <17BC3B48-8118-442C-A51C-8D7A7043C982@wordtothewise.com> In-Reply-To: <17BC3B48-8118-442C-A51C-8D7A7043C982@wordtothewise.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 08 Feb 2012 16:29:27 -0000 On 08/Feb/12 15:26, Steve Atkins wrote: > > 8.1 talks about sending unsolicited reports of authentication > failure while 9.1 states that unsolicited reports of authentication > failure MUST NOT be sent. No, 8.1 talks about sending unsolicited abuse reports. > 8.6 implies that the d= domain is always a good place to send an > unsolicited report if it leads to a deliverable email address. Is > that what we mean to say? No. A "reasonable candidate" implies a few attempts can be done. We are unable to order the candidate destinations described in 4 and 6 according to some criteria. From steve@wordtothewise.com Wed Feb 8 08:56:56 2012 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 85B4521F8729 for ; Wed, 8 Feb 2012 08:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6s47SSNSluM for ; Wed, 8 Feb 2012 08:56:56 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1B921F8725 for ; Wed, 8 Feb 2012 08:56:56 -0800 (PST) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id 4BBC82DECF for ; Wed, 8 Feb 2012 08:56:53 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Steve Atkins In-Reply-To: <4F32A2E4.5070608@tana.it> Date: Wed, 8 Feb 2012 08:56:48 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> <17BC3B48-8118-442C-A51C-8D7A7043C982@wordtothewise.com> <4F32A2E4.5070608@tana.it> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1257) Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 08 Feb 2012 16:56:56 -0000 On Feb 8, 2012, at 8:29 AM, Alessandro Vesely wrote: > On 08/Feb/12 15:26, Steve Atkins wrote: >> >> 8.1 talks about sending unsolicited reports of authentication >> failure while 9.1 states that unsolicited reports of authentication >> failure MUST NOT be sent. > > No, 8.1 talks about sending unsolicited abuse reports. "Such criteria might include direct complaint submissions from MUAs, reports triggered by mail sent to "spam trap" or "honeypot" addresses, reports of authentication failures, and virus reports." That's talking about "reports of authentication failure". s/reports of authentication failures,// is the obvious fix. > >> 8.6 implies that the d= domain is always a good place to send an >> unsolicited report if it leads to a deliverable email address. Is >> that what we mean to say? > > No. A "reasonable candidate" implies a few attempts can be done. I'm not sure what you mean there. 8.6 fairly strongly implies that the only reason that a DKIM d= might not be an appropriate place to notify is if the d= is being used to distinguish reputation streams. That's only one of several reasons it may not be a reasonable candidate. > > We are unable to order the candidate destinations described in 4 and 6 > according to some criteria. Cheers, Steve From msk@cloudmark.com Wed Feb 8 10:42:12 2012 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 7FB5A21E800F for ; Wed, 8 Feb 2012 10:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I93E5+to1t0K for ; Wed, 8 Feb 2012 10:42:12 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 11F1A21E800E for ; Wed, 8 Feb 2012 10:42:12 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 8 Feb 2012 10:42:11 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 8 Feb 2012 10:42:11 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Wed, 8 Feb 2012 10:42:10 -0800 Thread-Topic: [marf] RFC 2119 language Thread-Index: AczmeV9C+45sITPMS6+fW+mjluGnGwAF+wpA Message-ID: References: <20120208153544.F1BECF58083@smtp.patriot.net> In-Reply-To: <20120208153544.F1BECF58083@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] RFC 2119 language 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, 08 Feb 2012 18:42:12 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Wednesday, February 08, 2012 7:49 AM > To: Message Abuse Report Format working group > Subject: [marf] RFC 2119 language >=20 > I believe that we need to be careful to adhere to the definitions in > RFC 2119, specifically 6. Guidance in the use of these Imperatives. In > particular, I don't believe that we should use MUST unless we have > documented that "it is actually required for interoperation or to limit > behavior which has potential for causing harm". Which document, and which normative uses, are you asking us to review? > I noticed that some drafts use [RFC2119] as a footnote label and some > use [KEYWORDS]. Is that an arbitrary choice, or should we be > consistently using only one, and, if so, which one? It's an arbitrary choice, left to the preferences of the author(s)/editor(s= ). -MSK From msk@cloudmark.com Wed Feb 8 11:14:23 2012 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 6367621F851E for ; Wed, 8 Feb 2012 11:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hHkQF4NfJ+r for ; Wed, 8 Feb 2012 11:14:23 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 01C3A21F8503 for ; Wed, 8 Feb 2012 11:14:23 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 8 Feb 2012 11:14:22 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 8 Feb 2012 11:14:22 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Wed, 8 Feb 2012 11:14:21 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-07.txt Thread-Index: AczmbawS4tsy0/laSAKSH8BXJDKQkgAKABiw Message-ID: References: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> <17BC3B48-8118-442C-A51C-8D7A7043C982@wordtothewise.com> In-Reply-To: <17BC3B48-8118-442C-A51C-8D7A7043C982@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] I-D Action: draft-ietf-marf-as-07.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, 08 Feb 2012 19:14:23 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= teve Atkins > Sent: Wednesday, February 08, 2012 6:27 AM > To: Message Abuse Report Format working group > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >=20 > 8.1 talks about sending unsolicited reports of authentication failure > while 9.1 states that unsolicited reports of authentication failure > MUST NOT be sent. One of those likely needs to change (probably 8.1). Right; fixed. I only found one reference though; let me know if there are = others. > 8.6 implies that the d=3D domain is always a good place to send an > unsolicited report if it leads to a deliverable email address. Is that > what we mean to say? I don't agree that it says "always", since the words are "likely" and "not = universally true". -MSK From msk@cloudmark.com Wed Feb 8 11:18:45 2012 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 72C3321F8542 for ; Wed, 8 Feb 2012 11:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGTx7n82X6kl for ; Wed, 8 Feb 2012 11:18:45 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id F3AFF21F8541 for ; Wed, 8 Feb 2012 11:18:44 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 8 Feb 2012 11:18:44 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 8 Feb 2012 11:18:44 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Wed, 8 Feb 2012 11:18:43 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-07.txt Thread-Index: AczmfbPtwrJsrCtJScCPd+Qxo3ArAgAGDiEQ Message-ID: References: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> <4F32A0F7.4000002@tana.it> In-Reply-To: <4F32A0F7.4000002@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-as-07.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, 08 Feb 2012 19:18:45 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Wednesday, February 08, 2012 8:21 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >=20 > *Abstract* >=20 > The abstract says "end users can use these methods", which may be > somewhat misleading. How about "and conceivably even end users", or > equivalent English text? How is it misleading? > *Generating and Handling Unsolicited Abuse Reports* >=20 > I'd suggest the leading paragraph be more similar to that of Section 9, > instead of: >=20 > The following advice is offered for the case of reports that are not > solicited: >=20 > For example: >=20 > There are cases where no sending parties have requested reports, > possibly because they did not know how to apply, or didn't care. I think that says effectively the same thing. > *Generating Automatic Authentication Failure Reports* >=20 > Barry's advice on numbering is missing. Added. > Paragraph 2 seems to be overly restrictive. IMHO, it suffices to say > that the report "MUST NOT be sent automatically". That way, a > generator can still produce its data for local debugging or manual > forwarding. OK. > I'm unable to understand the first sentence of paragraph 3. Reports > have to be new messages irrespectively of whether the original message > was accepted or rejected. The focus isn't on new messages, it's on SMTP. If the delivery method isn'= t SMTP, then the rest of that paragraph doesn't apply because its loop-avoi= dance technique isn't applicable. -MSK From shmuel+gen@patriot.net Wed Feb 8 12:20:00 2012 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 03F8C21F8564 for ; Wed, 8 Feb 2012 12:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uXJ+kCimssj for ; Wed, 8 Feb 2012 12:19:59 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 64E8B21F855F for ; Wed, 8 Feb 2012 12:19:59 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.202]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 9A14FF5809A for ; Wed, 8 Feb 2012 15:05:23 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Wed, 08 Feb 2012 11:54:39 -0500 To: marf@ietf.org In-Reply-To: <17BC3B48-8118-442C-A51C-8D7A7043C982@wordtothewise.com> Mail-Copies-To: nobody 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: <20120208200524.9A14FF5809A@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt 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, 08 Feb 2012 20:20:00 -0000 In <17BC3B48-8118-442C-A51C-8D7A7043C982@wordtothewise.com>, on 02/08/2012 at 06:26 AM, Steve Atkins said: >8.1 talks about sending unsolicited reports of authentication failure >while 9.1 states that unsolicited reports of authentication failure >MUST NOT be sent. One of those likely needs to change (probably 8.1). I agree. If there's no abuse issue and the sender has not requested feedback on authentication failure then there's not much point in sending the feedback. If the e-mail client is sending legitimate mail that fails validation then the potential volume should be enough to justify the MUST NOT. 8.5 and 9.2 also have MUST. In the case of 8.5, it does not seem to satisfy 6. in RFC 2119. In the case of 9.2, I believe that it is legitimate in order to prevent loops. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From msk@cloudmark.com Wed Feb 8 12:26:39 2012 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 9FFF921F8539 for ; Wed, 8 Feb 2012 12:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC77QtEvH8jI for ; Wed, 8 Feb 2012 12:26:39 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1B58921F8533 for ; Wed, 8 Feb 2012 12:26:39 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 8 Feb 2012 12:26:38 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 8 Feb 2012 12:26:38 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Wed, 8 Feb 2012 12:26:38 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-07.txt Thread-Index: AczmnwoqLI0Z/U4rTkeizDtzPzLUlAAAHuDA Message-ID: References: <17BC3B48-8118-442C-A51C-8D7A7043C982@wordtothewise.com> <20120208200524.9A14FF5809A@smtp.patriot.net> In-Reply-To: <20120208200524.9A14FF5809A@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 08 Feb 2012 20:26:39 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Wednesday, February 08, 2012 8:55 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >=20 > 8.5 and 9.2 also have MUST. In the case of 8.5, it does not seem to > satisfy 6. in RFC 2119. In the case of 9.2, I believe that it is > legitimate in order to prevent loops. As you cited, Section 6 of RFC2119 says normative keywords "MUST only be us= ed where it is actually required for interoperation or to limit behavior wh= ich has potential for causing harm (e.g., limiting retransmisssions)". It seems to me that providing a mechanism to tell a report generator to kno= ck it off certainly does fit within the second part of that admonition. Th= ink of the extreme case where a report generator is mailbombing some addres= s extracted by heuristics. The MUST there seems quite appropriate to me. -MSK From shmuel+gen@patriot.net Wed Feb 8 13:02:44 2012 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 37A5421F8503 for ; Wed, 8 Feb 2012 13:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBk68uxrFG2Y for ; Wed, 8 Feb 2012 13:02:43 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7F78621F84D2 for ; Wed, 8 Feb 2012 13:02:43 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.161]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 418F0F580A1 for ; Wed, 8 Feb 2012 15:48:09 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Wed, 08 Feb 2012 16:02:40 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120208204809.418F0F580A1@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt 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, 08 Feb 2012 21:02:44 -0000 In , on 02/08/2012 at 12:26 PM, "Murray S. Kucherawy" said: >It seems to me that providing a mechanism to tell a report generator >to knock it off certainly does fit within the second part of that >admonition. Think of the extreme case where a report generator is >mailbombing some address extracted by heuristics. If it's sending only one report per abusive message received and sending it to the owner of the source IP then it's not mailbombing. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From shmuel+gen@patriot.net Wed Feb 8 13:04:13 2012 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 41E3911E8097 for ; Wed, 8 Feb 2012 13:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nLSPz3D7fu0 for ; Wed, 8 Feb 2012 13:04:12 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9448E11E8080 for ; Wed, 8 Feb 2012 13:04:12 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.161]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id BA629F580A1 for ; Wed, 8 Feb 2012 15:49:38 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Wed, 08 Feb 2012 16:04:09 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120208204938.BA629F580A1@smtp.patriot.net> Subject: Re: [marf] RFC 2119 language 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, 08 Feb 2012 21:04:13 -0000 In , on 02/08/2012 at 10:42 AM, "Murray S. Kucherawy" said: >Which document, and which normative uses, are you asking us to >review? I was thinking of draft-ietf-marf-as-07.txt, but I was suggesting that we be cautious about specifying MUST in general. In fact, I wonder whether we should include the justification as part of any draft using MUST, or at least in the discussion. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From msk@cloudmark.com Wed Feb 8 13:06:48 2012 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 7F25921F8585 for ; Wed, 8 Feb 2012 13:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zL3QjZ3DHjTq for ; Wed, 8 Feb 2012 13:06:48 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4DC21F8508 for ; Wed, 8 Feb 2012 13:06:48 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 8 Feb 2012 13:06:47 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 8 Feb 2012 13:06:47 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Wed, 8 Feb 2012 13:06:46 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-07.txt Thread-Index: AczmpQLBpcDksxyJRnSmE6Fw1BhgUwAAHHuA Message-ID: References: <20120208204809.418F0F580A1@smtp.patriot.net> In-Reply-To: <20120208204809.418F0F580A1@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 08 Feb 2012 21:06:48 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Wednesday, February 08, 2012 1:03 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >=20 > >It seems to me that providing a mechanism to tell a report generator to > >knock it off certainly does fit within the second part of that > >admonition. Think of the extreme case where a report generator is > >mailbombing some address extracted by heuristics. >=20 > If it's sending only one report per abusive message received and > sending it to the owner of the source IP then it's not mailbombing. If the reports are for some reason inactionable, then we're already saying = elsewhere that they shouldn't be sent in the first place. From msk@cloudmark.com Wed Feb 8 13:09:38 2012 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 5E15121F858F for ; Wed, 8 Feb 2012 13:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieslNu7pc4Vv for ; Wed, 8 Feb 2012 13:09:38 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 016AA21F858D for ; Wed, 8 Feb 2012 13:09:38 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 8 Feb 2012 13:09:37 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 8 Feb 2012 13:09:37 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Wed, 8 Feb 2012 13:09:36 -0800 Thread-Topic: [marf] RFC 2119 language Thread-Index: AczmpTdK9/5z3DyxQIKl19LSfcDuKgAAHQFw Message-ID: References: <20120208204938.BA629F580A1@smtp.patriot.net> In-Reply-To: <20120208204938.BA629F580A1@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] RFC 2119 language 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, 08 Feb 2012 21:09:38 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Shmuel Metz > Sent: Wednesday, February 08, 2012 1:04 PM > To: marf@ietf.org > Subject: Re: [marf] RFC 2119 language >=20 > I was thinking of draft-ietf-marf-as-07.txt, but I was suggesting that > we be cautious about specifying MUST in general. In fact, I wonder > whether we should include the justification as part of any draft using > MUST, or at least in the discussion. It's fair to suggest this, but we're late enough in WGLC that I think we ne= ed to have specific examples called out for consideration, with alternate t= ext suggested. Also, this is an applicability statement, not a protocol document. That ch= anges the context a bit in terms of interoperability requirements; the prot= ocol document establishes those, and this is more of a "best practices" spe= cification. From johnl@iecc.com Wed Feb 8 15:11:57 2012 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 1998C21F8576 for ; Wed, 8 Feb 2012 15:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.64 X-Spam-Level: X-Spam-Status: No, score=-109.64 tagged_above=-999 required=5 tests=[AWL=1.559, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmJJZdt+uerF for ; Wed, 8 Feb 2012 15:11:56 -0800 (PST) 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 98FDF21F8575 for ; Wed, 8 Feb 2012 15:11:55 -0800 (PST) Received: (qmail 18943 invoked from network); 8 Feb 2012 23:11:51 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 8 Feb 2012 23:11:51 -0000 Date: 8 Feb 2012 23:11:29 -0000 Message-ID: <20120208231129.99781.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <20120208204809.418F0F580A1@smtp.patriot.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 08 Feb 2012 23:11:57 -0000 >>It seems to me that providing a mechanism to tell a report generator >>to knock it off certainly does fit within the second part of that >>admonition. Think of the extreme case where a report generator is >>mailbombing some address extracted by heuristics. > >If it's sending only one report per abusive message received and >sending it to the owner of the source IP then it's not mailbombing. If the heuristic guessed wrong and it's some poor schnook getting a mountain of someone else's abuse reports, it most definitely is. No source of contact information is infallible. For the N+1'th time, standards can't make people do anything they're not inclined to do. Forcing abuse reports on people who don't want them will not make the abuse stop, nor accomplish anything else useful. R's, John From shmuel+gen@patriot.net Wed Feb 8 18:45:56 2012 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 76F5611E80B4 for ; Wed, 8 Feb 2012 18:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eZaZh4KQXzT for ; Wed, 8 Feb 2012 18:45:55 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id CD1F711E80BA for ; Wed, 8 Feb 2012 18:45:55 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.110]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id C7E62F580A9 for ; Wed, 8 Feb 2012 21:31:20 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Wed, 08 Feb 2012 21:45:52 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120209023120.C7E62F580A9@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt 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, 09 Feb 2012 02:45:56 -0000 In , on 02/08/2012 at 01:06 PM, "Murray S. Kucherawy" said: >If the reports are for some reason inactionable, then we're already >saying elsewhere that they shouldn't be sent in the first place. Indeed; SHOULD NOT. The question is whether there is a case for MUST NOT. -- 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 Feb 8 20:02:38 2012 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 AEE5421F854D for ; Wed, 8 Feb 2012 20:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drnHEeas9tB4 for ; Wed, 8 Feb 2012 20:02:38 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E491121F8542 for ; Wed, 8 Feb 2012 20:02:37 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 33AAE20E4126; Wed, 8 Feb 2012 23:02:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328760157; bh=CuwGkoOiBegkQpdBbTQssLxddKMLAWhslabordDTu4o=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=WpQQlH1UJRWbhKFWrGvfaykPQQyDJS1LWztjGEacPo54tf1XaKCnzBBiMEGIZQ4J8 sEnOtGCDS2oedO/7+A6cpnK0YziQ7sjtWabjVa+4Lpd5psIm9hZhQMh8TrVFKb0ZkV IuIWf8b1dFOMF8Bgm3XRI4LXiBQVcy2TPPCJULms= Received: from scott-latitude-e6320.localnet (unknown [97.67.196.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id D361520E4064; Wed, 8 Feb 2012 23:02:36 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 08 Feb 2012 23:02:33 -0500 Message-ID: <8745247.6SOmXc3d5b@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120208204809.418F0F580A1@smtp.patriot.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 04:02:38 -0000 On Wednesday, February 08, 2012 01:06:46 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Shmuel Metz Sent: Wednesday, February 08, 2012 1:03 PM > > To: marf@ietf.org > > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt > > > > >It seems to me that providing a mechanism to tell a report generator > > >to > > >knock it off certainly does fit within the second part of that > > >admonition. Think of the extreme case where a report generator is > > >mailbombing some address extracted by heuristics. > > > > If it's sending only one report per abusive message received and > > sending it to the owner of the source IP then it's not mailbombing. > > If the reports are for some reason inactionable, then we're already saying > elsewhere that they shouldn't be sent in the first place. Yes, but it's said in context of content analysis. If you send me reports because someone spoofed my domain and I've not indicated somehow that I want those reports (e.g. what's discussed under auth failure reporting) then it's inactionable and MUST not be sent. I really object to an RFC that's going to legitimize random idiots who don't understand that SMTP and address spoofing filling my postmaster inbox with crap from random spammers that used my Mail From in their last spam run. I would propose adding between 8.6 and 8.7: 6.5. A report generator MUST NOT send abuse reports to the Mail From domain if the message has an SPF result other than Pass, None, or Neutral. This is a special case of an inactionable report that I think is worth calling out. Scott K From steve@wordtothewise.com Wed Feb 8 20:07:52 2012 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 BDD1F21F858E for ; Wed, 8 Feb 2012 20:07:52 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNQj7tITsucm for ; Wed, 8 Feb 2012 20:07:52 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 495F221F8589 for ; Wed, 8 Feb 2012 20:07:52 -0800 (PST) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id 3C0E92DECF for ; Wed, 8 Feb 2012 20:07:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Steve Atkins In-Reply-To: <8745247.6SOmXc3d5b@scott-latitude-e6320> Date: Wed, 8 Feb 2012 20:07:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5057D802-0CFA-4A8C-A5D3-68021A247BAA@wordtothewise.com> References: <20120208204809.418F0F580A1@smtp.patriot.net> <8745247.6SOmXc3d5b@scott-latitude-e6320> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1257) Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 04:07:52 -0000 On Feb 8, 2012, at 8:02 PM, Scott Kitterman wrote: > On Wednesday, February 08, 2012 01:06:46 PM Murray S. Kucherawy wrote: >>> -----Original Message----- >>> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of >>> Shmuel Metz Sent: Wednesday, February 08, 2012 1:03 PM >>> To: marf@ietf.org >>> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >>>=20 >>>> It seems to me that providing a mechanism to tell a report = generator >>>> to >>>> knock it off certainly does fit within the second part of that >>>> admonition. Think of the extreme case where a report generator is >>>> mailbombing some address extracted by heuristics. >>>=20 >>> If it's sending only one report per abusive message received and >>> sending it to the owner of the source IP then it's not mailbombing. >>=20 >> If the reports are for some reason inactionable, then we're already = saying >> elsewhere that they shouldn't be sent in the first place. >=20 > Yes, but it's said in context of content analysis. >=20 > If you send me reports because someone spoofed my domain and I've not=20= > indicated somehow that I want those reports (e.g. what's discussed = under auth=20 > failure reporting) then it's inactionable and MUST not be sent. >=20 > I really object to an RFC that's going to legitimize random idiots who = don't=20 > understand that SMTP and address spoofing filling my postmaster inbox = with crap=20 > from random spammers that used my Mail =46rom in their last spam run. >=20 > I would propose adding between 8.6 and 8.7: >=20 > 6.5. A report generator MUST NOT send abuse reports to the Mail =46rom = domain=20 > if the message has an SPF result other than Pass, None, or Neutral. >=20 > This is a special case of an inactionable report that I think is worth = calling=20 > out. I'm not sure it is. It's no different from a report in any other format = sent to abuse@wherever. Where the problem appears is when someone automates the process. Those are the people who may be aware of this spec, and those are the people who'll generate a noticeable volume. It's only those people developing automation software that most of this is aimed at, and they are not the ones who need to have SPF explained to them[1]. Cheers, Steve [1] Well, OK, some of them are. But they're not going to pay any attention anyway. Filter their mail and move on, just like we all have with certain automated reporters already.= From sklist@kitterman.com Wed Feb 8 20:14:25 2012 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 BFB1821F85C3 for ; Wed, 8 Feb 2012 20:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3U-7PSO9UNfu for ; Wed, 8 Feb 2012 20:14:25 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A089121F84B6 for ; Wed, 8 Feb 2012 20:14:22 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2114F20E4126; Wed, 8 Feb 2012 23:14:22 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328760862; bh=sfzF8BO4LFvyPZ+lQwJMuaoRPefqYcq6urbh+xZPY+I=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=EGQnztRNp7SAaUhI6wUBEeQZcHhitAtdn3E1Se/tMqdaFKdXF1nGzpWuHzavNBzXz whK25U+2lhzriUrGJZLji0gQL7qIprcyo6L3GuPp7Yn6ETCOZapzY++xAQcxJCut6B zKfFvcJiDad6vhVGkvkqHKVykW3von2EKujssarc= Received: from scott-latitude-e6320.localnet (unknown [97.67.196.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id CB8E520E4064; Wed, 8 Feb 2012 23:14:21 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 08 Feb 2012 23:14:19 -0500 Message-ID: <2655621.YKa4m7p0Yk@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <5057D802-0CFA-4A8C-A5D3-68021A247BAA@wordtothewise.com> References: <8745247.6SOmXc3d5b@scott-latitude-e6320> <5057D802-0CFA-4A8C-A5D3-68021A247BAA@wordtothewise.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 04:14:25 -0000 On Wednesday, February 08, 2012 08:07:46 PM Steve Atkins wrote: > On Feb 8, 2012, at 8:02 PM, Scott Kitterman wrote: > > On Wednesday, February 08, 2012 01:06:46 PM Murray S. Kucherawy wrote: > >>> -----Original Message----- > >>> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf > >>> Of > >>> Shmuel Metz Sent: Wednesday, February 08, 2012 1:03 PM > >>> To: marf@ietf.org > >>> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt > >>> > >>>> It seems to me that providing a mechanism to tell a report > >>>> generator > >>>> to > >>>> knock it off certainly does fit within the second part of that > >>>> admonition. Think of the extreme case where a report generator is > >>>> mailbombing some address extracted by heuristics. > >>> > >>> If it's sending only one report per abusive message received and > >>> sending it to the owner of the source IP then it's not mailbombing. > >> > >> If the reports are for some reason inactionable, then we're already > >> saying elsewhere that they shouldn't be sent in the first place. > > > > Yes, but it's said in context of content analysis. > > > > If you send me reports because someone spoofed my domain and I've not > > indicated somehow that I want those reports (e.g. what's discussed under > > auth failure reporting) then it's inactionable and MUST not be sent. > > > > I really object to an RFC that's going to legitimize random idiots who > > don't understand that SMTP and address spoofing filling my postmaster > > inbox with crap from random spammers that used my Mail From in their > > last spam run. > > > > I would propose adding between 8.6 and 8.7: > > > > 6.5. A report generator MUST NOT send abuse reports to the Mail From > > domain if the message has an SPF result other than Pass, None, or > > Neutral. > > > > This is a special case of an inactionable report that I think is worth > > calling out. > > I'm not sure it is. It's no different from a report in any other format sent > to abuse@wherever. > > Where the problem appears is when someone automates the process. > Those are the people who may be aware of this spec, and those are > the people who'll generate a noticeable volume. It's only those people > developing automation software that most of this is aimed at, and they > are not the ones who need to have SPF explained to them[1]. > > Cheers, > Steve > > [1] Well, OK, some of them are. But they're not going to pay any > attention anyway. Filter their mail and move on, just like we all have > with certain automated reporters already. That's all true, but I don't think it's not a reason to put it in here. This is the document we're writing on how to do abuse reporting. If we were writing a more global document, I'd want it in that too, but we aren't. The entire document is rife with advice that is also applicable to non-ARF abuse reports, so this is no different in that regard. One of the reasons SPF was created was to reduce the number of bounces people received due to spoofed messages. I feel very strongly we ought to avoid recreating that problem. Scott K From scott@kitterman.com Wed Feb 8 20:39:02 2012 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 E2C2321E8010 for ; Wed, 8 Feb 2012 20:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y36KbPw2T05M for ; Wed, 8 Feb 2012 20:39:02 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 359C921E8017 for ; Wed, 8 Feb 2012 20:39:02 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3F5FA20E4126; Wed, 8 Feb 2012 23:39:01 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328762341; bh=28XmsqwrdGLrbkpV/J9c6lqoAxQlr+dH5VzO6EO4Xo8=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=cIziLXjCq1usyFvBvhJNRAusmaaw+NrRFYyC/utVA9gq4NCEYw1Fgvg/F5lzh9oq4 JRrULsvECFVbAV8OdCAIICn1e210w3VCzfqzJP2adaS2kyfhkCG5JJLXgY1tNcPskJ 3dGIaGETB1qKvFSrdhiCvWSUfKl5jVzL7bY3iCe0= Received: from scott-latitude-e6320.localnet (unknown [97.67.196.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0B96520E4064; Wed, 8 Feb 2012 23:39:00 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 08 Feb 2012 23:38:58 -0500 Message-ID: <1691793.jRbOJzBfkP@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 04:39:03 -0000 On Tuesday, February 07, 2012 10:42:46 PM Murray S. Kucherawy wrote: ... > Still in WGLC until Friday. Have at it. ... In paragraph 11.2 (forgeries), the last section of it: Perhaps the simplest means of mitigating this threat is to assert that these reports should themselves be signed with something like DKIM. On the other hand, if there is a problem with the DKIM infrastructure at the Verifier, signing DKIM failure reports may produce reports that aren't trusted or even accepted by their intended recipients. I think it would useful to mention both SPF and DKIM here as one may offset failures in the other (along the lines of what DMARC is doing). Proposed text: Perhaps the simplest means of mitigating this threat is to assert that these reports should themselves be signed with something like DKIM or authorized with SPF. On the other hand, if there is a problem with the DKIM infrastructure at the Verifier, signing DKIM failure reports may produce reports that aren't trusted or even accepted by their intended recipients. There may be similar issues with SPF evaluation. Use of both technologies can mitigate this risk to a degree. Scott K From sklist@kitterman.com Wed Feb 8 20:42:10 2012 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 A226121E8013 for ; Wed, 8 Feb 2012 20:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxQ-qmOyUmcb for ; Wed, 8 Feb 2012 20:42:09 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C651321E8010 for ; Wed, 8 Feb 2012 20:42:09 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5DA5020E4126; Wed, 8 Feb 2012 23:42:09 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328762529; bh=t5fTqjNttvWolCyfyWXfGjDhdSuFT1CnOJczUTV5Qwc=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=p0WwXyKF1U8I+ztwDsObyqCrgbKRk79iwfGhjc9DlNsJgBwfFJ4WaTZMqGeVv+5mj kf/y5lf/tqiBl9Sj9jSFU8oVZMBXyWA0xIX835TbtOA0gwU+jniXeupJJuJFTbS7ak 4sgL5t1VoyLz7D4kYgGpflkqiCvY1CpfAaLM8P1Q= Received: from scott-latitude-e6320.localnet (unknown [97.67.196.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0946F20E4064; Wed, 8 Feb 2012 23:42:08 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 08 Feb 2012 23:42:06 -0500 Message-ID: <11659215.dRxuJzBLh7@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <1691793.jRbOJzBfkP@scott-latitude-e6320> References: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> <1691793.jRbOJzBfkP@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 04:42:10 -0000 On Wednesday, February 08, 2012 11:38:58 PM Scott Kitterman wrote: > On Tuesday, February 07, 2012 10:42:46 PM Murray S. Kucherawy wrote: > ... > > > Still in WGLC until Friday. Have at it. > > ... > > In paragraph 11.2 (forgeries), the last section of it: > > Perhaps the simplest means of mitigating this threat is to assert > that these reports should themselves be signed with something like > DKIM. On the other hand, if there is a problem with the DKIM > infrastructure at the Verifier, signing DKIM failure reports may > produce reports that aren't trusted or even accepted by their > intended recipients. > > I think it would useful to mention both SPF and DKIM here as one may offset > failures in the other (along the lines of what DMARC is doing). Proposed > text: > > Perhaps the simplest means of mitigating this threat is to assert > that these reports should themselves be signed with something like > DKIM or authorized with SPF. On the other hand, if there is a problem > with the DKIM infrastructure at the Verifier, signing DKIM failure reports > may produce reports that aren't trusted or even accepted by their > intended recipients. There may be similar issues with SPF evaluation. > Use of both technologies can mitigate this risk to a degree. I should have mentioned that this is consistent with combining the input from both the DKIM and SPF drafts into the AS draft. The SPF draft currently says: Perhaps the simplest means of mitigating this threat is to assert that these reports should themselves pass SPF checks and/or use other email authentication technologies such as DKIM. I'm currently working on an update to the SPF draft and am assuming you'll do something along these lines. If not, I think I need to put the forgeries consideration back into the SPF draft. Scott K From msk@cloudmark.com Wed Feb 8 20:59:32 2012 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 3158521E8017 for ; Wed, 8 Feb 2012 20:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pn+MgGQkf706 for ; Wed, 8 Feb 2012 20:59:31 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id C09BA21E8016 for ; Wed, 8 Feb 2012 20:59:31 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 8 Feb 2012 20:59:31 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 8 Feb 2012 20:59:31 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 8 Feb 2012 20:59:39 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-07.txt Thread-Index: Aczm36sd2Lk07c0sRam4l/jYVEUOFwABpcqw Message-ID: References: <20120208204809.418F0F580A1@smtp.patriot.net> <8745247.6SOmXc3d5b@scott-latitude-e6320> In-Reply-To: <8745247.6SOmXc3d5b@scott-latitude-e6320> 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-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 04:59:32 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Wednesday, February 08, 2012 8:03 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >=20 > 6.5. A report generator MUST NOT send abuse reports to the Mail From > domain if the message has an SPF result other than Pass, None, or > Neutral. That sounds a little like establishing an SPF requirement on use of ARF. H= ow about: If a report generator applies [SPF] to arriving messages, and an arriving m= essage's SPF evaluation produced something other than a Pass, None or Neutr= al result, a report SHOULD NOT be generated. ...and add similar not-on-failure advice to the DKIM text as well. ? -MSK From msk@cloudmark.com Wed Feb 8 21:08:28 2012 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 56B1821F84A0 for ; Wed, 8 Feb 2012 21:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iLNIGoPmovz for ; Wed, 8 Feb 2012 21:08:27 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id D8F0921F849D for ; Wed, 8 Feb 2012 21:08:27 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 8 Feb 2012 21:08:27 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 8 Feb 2012 21:08:27 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 8 Feb 2012 21:08:35 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-07.txt Thread-Index: Aczm5MH6Inx0VVXoRzCOJhQXnMrrQgABAlZQ Message-ID: References: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> <1691793.jRbOJzBfkP@scott-latitude-e6320> In-Reply-To: <1691793.jRbOJzBfkP@scott-latitude-e6320> 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-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 05:08:28 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Wednesday, February 08, 2012 8:39 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >=20 > I think it would useful to mention both SPF and DKIM here as one may > offset failures in the other (along the lines of what DMARC is doing). > Proposed text: >=20 > Perhaps the simplest means of mitigating this threat is to assert > that these reports should themselves be signed with something like > DKIM or authorized with SPF. On the other hand, if there is a problem= with > the DKIM infrastructure at the Verifier, signing DKIM failure reports = may > produce reports that aren't trusted or even accepted by their > intended recipients. There may be similar issues with SPF evaluation.= Use > of both technologies can mitigate this risk to a degree. Quite right, and what everyone's been espousing in that space for quite a w= hile. Updated accordingly. -MSK From sklist@kitterman.com Wed Feb 8 21:22:59 2012 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 CE15111E8096 for ; Wed, 8 Feb 2012 21:22:59 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdEmedudz6Ta for ; Wed, 8 Feb 2012 21:22:59 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id DE52111E8094 for ; Wed, 8 Feb 2012 21:22:58 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 52E8E20E4126; Thu, 9 Feb 2012 00:22:58 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328764978; bh=MVcy+SxcAcXkoDfF8ABdRkfzV/01ZBg18K8i8joj0rk=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=oS1TlQwYWQGoFoqn3TXpOTBQRfOFefmtCESZzvy5BpdbIeaRp+oHEQJs7ri/zNSxK QPp5lDmOngYKo4P+UID1din7h4vZPGPUUTv2VOG2mnDaGqxmisDNR2pp6n/z9uwrtk 4PpQUhc2n4CWKZNbY6wH2jomjNcumb1+ZGnGZWuU= Received: from scott-latitude-e6320.localnet (unknown [97.67.196.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 25EF620E4064; Thu, 9 Feb 2012 00:22:57 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Thu, 09 Feb 2012 00:22:56 -0500 Message-ID: <5681886.BiAaEpefJ0@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <8745247.6SOmXc3d5b@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 05:22:59 -0000 On Wednesday, February 08, 2012 08:59:39 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Wednesday, February 08, 2012 8:03 PM > > To: marf@ietf.org > > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt > > > > 6.5. A report generator MUST NOT send abuse reports to the Mail From > > domain if the message has an SPF result other than Pass, None, or > > Neutral. > > That sounds a little like establishing an SPF requirement on use of ARF. > How about: > > If a report generator applies [SPF] to arriving messages, and an arriving > message's SPF evaluation produced something other than a Pass, None or > Neutral result, a report SHOULD NOT be generated. > > ...and add similar not-on-failure advice to the DKIM text as well. > > ? I'm generally OK with this, but I think it should be MUST NOT vice SHOULD NOT. In this case you know that sending an ARF to the domain that was spoofed is non-actionable. All it's going to get is return complaints, your mail blackholed, or abuse reports against the sending domain. The reports are known pointless and will do only harm. It's different for auth failure reports where the receiver has said they want such reports. Scott K From internet-drafts@ietf.org Wed Feb 8 21:24:50 2012 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 2A5D911E80B4; Wed, 8 Feb 2012 21:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1T6CwOEyZcY; Wed, 8 Feb 2012 21:24:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A918721F84EF; Wed, 8 Feb 2012 21:24:48 -0800 (PST) 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.64p1 Message-ID: <20120209052448.21842.58701.idtracker@ietfa.amsl.com> Date: Wed, 08 Feb 2012 21:24:48 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-spf-reporting-06.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 05:24:50 -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-06.txt Pages : 13 Date : 2012-02-08 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-06.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-06.txt From sklist@kitterman.com Wed Feb 8 21:26:04 2012 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 1863621F84F5 for ; Wed, 8 Feb 2012 21:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYU8+PvSXmKW for ; Wed, 8 Feb 2012 21:26:03 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD2C21F84F3 for ; Wed, 8 Feb 2012 21:26:03 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CCEF820E4126; Thu, 9 Feb 2012 00:26:01 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328765161; bh=Yuw47FFtBMq2n4RNk5NYjI/jFTw7lopJp81P3gOWUA0=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=hW37fI0ua8AJlDUYs0mE2Z4M0hkZbrJ8kvqLc0s8QVVF8oACT+MpBeOtRTq2ZZ6Bj jz3NWXbdzVq9W/kRZcF8wkXdyD7R8AvBegrpVWgCrFVhcyAJmi3aA+Sc5bfsNBHqGM MYhPXe3gqmGsdXGO9A+0TKLFK8+W6RjyG4xetfSU= Received: from scott-latitude-e6320.localnet (unknown [97.67.196.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9C98320E4064; Thu, 9 Feb 2012 00:26:01 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Thu, 09 Feb 2012 00:26 -0500 Message-ID: <34970908.JnMMdW1Op1@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120209052448.21842.58701.idtracker@ietfa.amsl.com> References: <20120209052448.21842.58701.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-06.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 05:26:04 -0000 On Wednesday, February 08, 2012 09:24:48 PM internet-drafts@ietf.org wrote: > 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-06.txt > Pages : 13 > Date : 2012-02-08 * Port changes from DKIM -08 to the SPF draft - Drop DKIM/ADSP/Email arch/SMTP mentions in text and references - Add I-D.IETF-MARF-AS to references and in introduction and security considerations - Distill forgeries/envelope selection security considerations down to residual text not included in I-D.IETF-MARF-AS - Remove the balance of forgeries and envelope sender selection considerations - Remove automatic generation security consideration * Add an additional example based on feedback on spf-discuss Scott K From msk@cloudmark.com Wed Feb 8 21:36:11 2012 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 3196A11E80A3 for ; Wed, 8 Feb 2012 21:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26EvKcgW91Iv for ; Wed, 8 Feb 2012 21:36:08 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id AC5FC11E8096 for ; Wed, 8 Feb 2012 21:36:07 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 8 Feb 2012 21:36:06 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 8 Feb 2012 21:36:06 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 8 Feb 2012 21:36:14 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-07.txt Thread-Index: Aczm6uT9yvpvx0/6RiqqI5Q7YmalWwAAa5pA Message-ID: References: <8745247.6SOmXc3d5b@scott-latitude-e6320> <5681886.BiAaEpefJ0@scott-latitude-e6320> In-Reply-To: <5681886.BiAaEpefJ0@scott-latitude-e6320> 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-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 05:36:11 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Wednesday, February 08, 2012 9:23 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >=20 > I'm generally OK with this, but I think it should be MUST NOT vice > SHOULD NOT. I suggested SHOULD NOT because RFC2119 defines that as basically "MUST NOT,= unless you've given serious thought to why you're ignoring that advice." Does that sound any better? From msk@cloudmark.com Wed Feb 8 21:52:31 2012 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 4A08E21F8448 for ; Wed, 8 Feb 2012 21:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWA4MXhH8mul for ; Wed, 8 Feb 2012 21:52:30 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 408E721F842F for ; Wed, 8 Feb 2012 21:52:30 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 8 Feb 2012 21:52:28 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 8 Feb 2012 21:52:28 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 8 Feb 2012 21:52:36 -0800 Thread-Topic: Working Group Last Call: draft-ietf-marf-spf-reporting and draft-ietf-marf-dkim-reporting Thread-Index: Aczm7wYdz5QZBO0ARlem72gqs75ZJw== 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_F5833273385BB34F99288B3648C4F06F19C9A7DCAFEXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] Working Group Last Call: draft-ietf-marf-spf-reporting and draft-ietf-marf-dkim-reporting X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 05:52:31 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DCAFEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This message begins a Working Group Last Call on the above drafts, ending F= ebruary 24th. Everyone please review these drafts (probably alongside the = AS, which is also in WGLC already) and provide your comments by then. Thanks, -MSK, as co-chair --_000_F5833273385BB34F99288B3648C4F06F19C9A7DCAFEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This message beg= ins a Working Group Last Call on the above drafts, ending February 24t= h.  Everyone please review these drafts (probably alongside the = AS, which is also in WGLC already) and provide your comments by then.<= /o:p>

 

Tha= nks,

-MSK, as co-chair

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DCAFEXCHC2corpclo_-- From sklist@kitterman.com Wed Feb 8 21:54:42 2012 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 0E76221F8585 for ; Wed, 8 Feb 2012 21:54:42 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEQrmWFCl+-G for ; Wed, 8 Feb 2012 21:54:41 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA8121F8589 for ; Wed, 8 Feb 2012 21:54:41 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id BB66A20E4126; Thu, 9 Feb 2012 00:54:40 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328766880; bh=H3eXI3KlCO+NvloFzd6TYZiVO5Y/wBELgTLJvpH0fk4=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=SMMFyV9pCIWrUtzkwmgU/OvFToDMklv1zj6ALFclfezcBATBTdAyXUWb2fh4AjS2a D4n+22XsAVYtgx0i1lfvAQVbSzSkWokq99u3qKREH5b/2tB2Pih1xtmEARlC3m1iSg 8HpOMyBeNppJT0tkY6vDbhSXV+5hhyytS/SQ1KQ8= Received: from scott-latitude-e6320.localnet (unknown [97.67.196.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8F79220E4064; Thu, 9 Feb 2012 00:54:40 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Thu, 09 Feb 2012 00:54:39 -0500 Message-ID: <1449287.lWhNiLsB7Y@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <5681886.BiAaEpefJ0@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 05:54:42 -0000 On Wednesday, February 08, 2012 09:36:14 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Wednesday, February 08, 2012 9:23 PM > > To: marf@ietf.org > > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt > > > > I'm generally OK with this, but I think it should be MUST NOT vice > > SHOULD NOT. > > I suggested SHOULD NOT because RFC2119 defines that as basically "MUST NOT, > unless you've given serious thought to why you're ignoring that advice." > > Does that sound any better? No. I've read RFC 2119. The only case I can think of where I can envision not heeding this advice is if you think the senders authentication is broken. In that case I believe you should be looking at how to send auth failure reports. I think this is a MUST NOT. All it will lead to is pain. I will confess it's possible that I'm overly cynical about the ability of giving serious thought reliably producing the correct result here, but I really think that for whatever corner case that may exist, there's globally more harm associated with given people a free pass to think it over. Scott K From sklist@kitterman.com Wed Feb 8 22:49:24 2012 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 8998821F85B5 for ; Wed, 8 Feb 2012 22:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7u9OobYNKDJ for ; Wed, 8 Feb 2012 22:49:23 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 803DD21F8575 for ; Wed, 8 Feb 2012 22:49:15 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B67E020E4126; Thu, 9 Feb 2012 01:49:14 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328770154; bh=/C0MdJKZrU0tF9MXHwoPWkILs/2/P/ysiDfclNyQF/A=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=d0vKOBFBdls1aq4b08i8i9rSfwy0AMWG5sKVSi0nKptgfR3RXzX40oJ3W51jIRK1h 3SbD3AELyrB4BZOXfez0/t2CM9+jUAZ/5F0Nj7cmVT1LuBYvclEG01wxEdmSqvYUab 5z0nTp9iWvrzF/MFWjbNJ88r2KBni05tEDGqnaq4= Received: from scott-latitude-e6320.localnet (unknown [97.67.196.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 894BF20E4064; Thu, 9 Feb 2012 01:49:14 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Thu, 09 Feb 2012 01:49:12 -0500 Message-ID: <5339830.dVgCMc24YG@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Working Group Last Call: draft-ietf-marf-spf-reporting and draft-ietf-marf-dkim-reporting X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 06:49:24 -0000 On Wednesday, February 08, 2012 09:52:36 PM Murray S. Kucherawy wrote: > This message begins a Working Group Last Call on the above drafts, ending > February 24th. Everyone please review these drafts (probably alongside the > AS, which is also in WGLC already) and provide your comments by then. Comments on the dkim-reporting draft (for the record, I'm happy with the spf- reporting draft): paragraph 3.3, items 3/5: It seems to me to be overkill to specify anything about what should be logged locally. It's not relevant to interoperability and is really an implementation detail. paragraph 3.3, item 8: Since ra= for dkim is required, then it seems to me if ra= is missing, the record has already failed step 5, so step is is redundant. Recommend removing step 8 and rewording step 5 (taking the liberty of resolving my previous comment for this item as well): 5. If the TXT content is syntactically invalid (including missing required tags like ra=), terminate. In the last hunk of paragraph 3, there is the phrase: "It might be useful to some Signers to receive such reports. To enable this, a Verifier could violate the first step above and continue even in the absence of an "r=" tag." I know that the rest of the paragraph gets to "Don't do this", but I'm afraid the current wording is an invitation to mischief. Perhaps something like: "It might be useful to some Signers to receive such reports, but this use case is not supported. To support this, a Verifier would have to violate the first step above and continue even in the absence of an "r=" tag." Looks pretty good. Scott K From shmuel+gen@patriot.net Thu Feb 9 08:32:20 2012 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 F16DE21F872F for ; Thu, 9 Feb 2012 08:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBSgDVNT7a4p for ; Thu, 9 Feb 2012 08:32:16 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id C4A1921F8729 for ; Thu, 9 Feb 2012 08:32:13 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.3]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 4963EF580A9 for ; Thu, 9 Feb 2012 11:17:38 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Thu, 09 Feb 2012 11:24:50 -0500 To: marf@ietf.org In-Reply-To: <8745247.6SOmXc3d5b@scott-latitude-e6320> Mail-Copies-To: nobody 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: <20120209161738.4963EF580A9@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt 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, 09 Feb 2012 16:32:20 -0000 In <8745247.6SOmXc3d5b@scott-latitude-e6320>, on 02/08/2012 at 11:02 PM, Scott Kitterman said: >I would propose adding between 8.6 and 8.7: >6.5. A report generator MUST NOT send abuse reports to the Mail From >domain if the message has an SPF result other than Pass, None, or >Neutral. I'd suggest 6.5. A report generator SHOULD NOT send abuse reports to the Mail >From domain unless the domain has been authenticated, e.g., if the message has an SPF result of Pass, None, or Neutral. Similarly, a report generator SHOULD NOT send abuse reports to the header From domain unless the domain has been authenticated. I'd support MUST NOT for both if we make a case that "it is actually required for interoperation or to limit behavior which has potential for causing harm", as specificed in RFC 2119. -- 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 Thu Feb 9 08:32:20 2012 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 0ABDB21F8729 for ; Thu, 9 Feb 2012 08:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QhogIKObBAM for ; Thu, 9 Feb 2012 08:32:16 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id A7D0D21F872B for ; Thu, 9 Feb 2012 08:32:16 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.3]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 74A73F580AB for ; Thu, 9 Feb 2012 11:17:40 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Thu, 09 Feb 2012 11:29:10 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120209161741.74A73F580AB@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt 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, 09 Feb 2012 16:32:20 -0000 In , on 02/08/2012 at 08:59 PM, "Murray S. Kucherawy" said: >If a report generator applies [SPF] to arriving messages, and an >arriving message's SPF evaluation produced something other than a >Pass, None or Neutral result, a report SHOULD NOT be generated. I'd rather make it more general and also require authentication for anything not based on the source IP or a domain resolving to the source id. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From vesely@tana.it Thu Feb 9 09:03:20 2012 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 9372521E8039 for ; Thu, 9 Feb 2012 09:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.653 X-Spam-Level: X-Spam-Status: No, score=-4.653 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqz4fezWsBmD for ; Thu, 9 Feb 2012 09:03:19 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4310921E8035 for ; Thu, 9 Feb 2012 09:03:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328806996; bh=LxTmL3H02N1MG57JcrsCoz+NuXxUzi18zgVbgiTayt0=; l=1574; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=DjuBgp3+8CsnsddjY/YRlmBwiI5REwlozUR7jTaVvBi6MVB/0NCfYTLBa4d0sYP8t 0fDYCFEfLsxbb/6zPXaQAeT3xpqcc+SynWmoAVOn/m0ujdCBG0qvCB4rBaq22Acrp6 r3g+Z86HGCAG43gCeCFzgoz/q7WUcL7BmzF3NR5w= 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, 09 Feb 2012 18:03:16 +0100 id 00000000005DC035.000000004F33FC54.00000658 Message-ID: <4F33FC54.1010003@tana.it> Date: Thu, 09 Feb 2012 18:03:16 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> <17BC3B48-8118-442C-A51C-8D7A7043C982@wordtothewise.com> <4F32A2E4.5070608@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-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 17:03:20 -0000 On 08/Feb/12 17:56, Steve Atkins wrote: > On Feb 8, 2012, at 8:29 AM, Alessandro Vesely wrote: > >> 8.1 talks about sending unsolicited abuse reports. > > "Such criteria might include direct complaint > submissions from MUAs, reports triggered by mail sent to "spam > trap" or "honeypot" addresses, reports of authentication > failures, and virus reports." > > That's talking about "reports of authentication failure". Mistake? > s/reports of authentication failures,// is the obvious fix. The whole snippet quoted above seems to be somewhat misplaced, as those are all cases of "mechanical reports" that the concluding sentence of that paragraph discourages. >>> 8.6 implies that the d= domain is always a good place to send an >>> unsolicited report if it leads to a deliverable email address. Is >>> that what we mean to say? >> >> No. A "reasonable candidate" implies a few attempts can be done. > > I'm not sure what you mean there. Even if the d= domain is a reasonable candidate, one should stop sending reports if any of the following is determined to be true: * abuse@domain is undeliverable, * nobody acknowledges the reports (paragraph 13), or * the recipients opt-out (paragraph 5). > 8.6 fairly strongly implies that the only reason that a DKIM d= might > not be an appropriate place to notify is if the d= is being used to > distinguish reputation streams. That's only one of several reasons > it may not be a reasonable candidate. Abusive parties (paragraph 14) make another class of unreasonable candidates. From msk@cloudmark.com Thu Feb 9 09:50:16 2012 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 3F48121E8032 for ; Thu, 9 Feb 2012 09:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iX+5uU0kU7Mp for ; Thu, 9 Feb 2012 09:50:15 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id A78FC21E802F for ; Thu, 9 Feb 2012 09:50:15 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 9 Feb 2012 09:50:15 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 9 Feb 2012 09:50:15 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 9 Feb 2012 09:50:14 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-07.txt Thread-Index: Aczm71MZ5wi5IRZ/T3mzOqkXYanrZAAY34pg Message-ID: References: <5681886.BiAaEpefJ0@scott-latitude-e6320> <1449287.lWhNiLsB7Y@scott-latitude-e6320> In-Reply-To: <1449287.lWhNiLsB7Y@scott-latitude-e6320> 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-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 17:50:16 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Scott Kitterman > Sent: Wednesday, February 08, 2012 9:55 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >=20 > The only case I can think of where I can envision not heeding this > advice is if you think the senders authentication is broken. In that > case I believe you should be looking at how to send auth failure > reports. >=20 > I think this is a MUST NOT. All it will lead to is pain. >=20 > I will confess it's possible that I'm overly cynical about the ability > of giving serious thought reliably producing the correct result here, > but I really think that for whatever corner case that may exist, > there's globally more harm associated with given people a free pass to > think it over. If I may paraphrase John Levine, no amount of MUST NOTting will prevent a p= inhead from being a pinhead. In those cases, I prefer to pick RFC2119 word= s geared toward the competent reader. That's why I went with SHOULD NOT he= re. But I'll go with consensus, also accepting that the IESG might correct us i= n either direction. Thus, what do others think? From vesely@tana.it Thu Feb 9 09:54:55 2012 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 BCA1921E8021 for ; Thu, 9 Feb 2012 09:54:55 -0800 (PST) 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.065, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVWqHiZAXnsZ for ; Thu, 9 Feb 2012 09:54:55 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D428621F8570 for ; Thu, 9 Feb 2012 09:54:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328810093; bh=5FzN3KKdh4LkNRNKoM9EDI92TkDfzxWlg1VnwJss8OI=; l=1526; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=aWthMltizBoGZGewS3Lh5+rjDLYuEoR/gV2nf5FXwpzxGakyfkm6T37tT9VHQBQLT u46x6J58LDCeIvf2LE1nlIiP+UwRXb5N/vkg1Z0t/Sf8mruzbLljMJWwx5P7AoE9DY azErgRZP7MgnRQJuzKsHrYTYmr9UVJmKYKFNIWq0= 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, 09 Feb 2012 18:54:53 +0100 id 00000000005DC04B.000000004F34086D.000013A4 Message-ID: <4F34086D.8060609@tana.it> Date: Thu, 09 Feb 2012 18:54:53 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <5681886.BiAaEpefJ0@scott-latitude-e6320> <1449287.lWhNiLsB7Y@scott-latitude-e6320> In-Reply-To: <1449287.lWhNiLsB7Y@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 17:54:55 -0000 On 09/Feb/12 06:54, Scott Kitterman wrote: > > I think this is a MUST NOT. All it will lead to is pain. > > I will confess it's possible that I'm overly cynical about the > ability of giving serious thought reliably producing the correct > result here, but I really think that for whatever corner case that > may exist, there's globally more harm associated with given people > a free pass to think it over. A corner case: an ISP configure SPF according to their own mail traffic, e.g. "v=spf1 mx:ISP.example ~all". The ISP don't trust their customers enough to point WHOIS records directly to their abuse-mailboxes, but does count-and-forward according to 8.10. Now, an ISP's customer sends spam with MAIL FROM:. The abuse-mailbox resulting from WHOIS lookup of the source address is abuse@ISP.example. That domain failed SPF authentication and thus, you say, it cannot be the target of unsolicited complaints. Why? As for the whole idea, may I ask why softfail is considered less bad than neutral? AFAIK people use them interchangeably when they don't dare -all. We are already saying that the domain in MAIL FROM is likely a reasonable candidate if SPF gave "pass". Doesn't that already mean you should not use it if SPF gave any other result? Why do we need to add that fail, softfail, temperror, and permerror, in particular, are not good? Rather, I'd s/the domain that has been verified/the domain that has been verified ("pass")/, in case that isn't clear enough. From msk@cloudmark.com Thu Feb 9 10:06:09 2012 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 7DF5121F85D6 for ; Thu, 9 Feb 2012 10:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7mU+bEvNF+E for ; Thu, 9 Feb 2012 10:06:08 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id DA63121F85D1 for ; Thu, 9 Feb 2012 10:06:08 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 9 Feb 2012 10:06:08 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 9 Feb 2012 10:06:08 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Thu, 9 Feb 2012 10:06:07 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-07.txt Thread-Index: AcznSGakpQoKK4z+TKyfE44uTWMzswADP7ug Message-ID: References: <8745247.6SOmXc3d5b@scott-latitude-e6320> <20120209161738.4963EF580A9@smtp.patriot.net> In-Reply-To: <20120209161738.4963EF580A9@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 18:06:09 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Thursday, February 09, 2012 8:25 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >=20 > 6.5. A report generator SHOULD NOT send abuse reports to the Mail From > domain unless the domain has been authenticated, e.g., if the message > has an SPF result of Pass, None, or Neutral. Similarly, a report > generator SHOULD NOT send abuse reports to the header From domain > unless the domain has been authenticated. Neither DKIM nor SPF do anything to authenticate the header From domain. W= hat other mechanism are you proposing we introduce? -MSK From msk@cloudmark.com Thu Feb 9 10:08:24 2012 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 7CE3221F86AD for ; Thu, 9 Feb 2012 10:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rpv+KLq0Cx9L for ; Thu, 9 Feb 2012 10:08:23 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id DACB521F862F for ; Thu, 9 Feb 2012 10:08:23 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 9 Feb 2012 10:08:23 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 9 Feb 2012 10:08:23 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 9 Feb 2012 10:08:21 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-07.txt Thread-Index: Aczm71MZ5wi5IRZ/T3mzOqkXYanrZAAY34pgAAC1XgA= Message-ID: References: <5681886.BiAaEpefJ0@scott-latitude-e6320> <1449287.lWhNiLsB7Y@scott-latitude-e6320> 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] I-D Action: draft-ietf-marf-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 18:08:24 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of M= urray S. Kucherawy > Sent: Thursday, February 09, 2012 9:50 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >=20 > If I may paraphrase John Levine, no amount of MUST NOTting will prevent > a pinhead from being a pinhead. In those cases, I prefer to pick > RFC2119 words geared toward the competent reader. That's why I went > with SHOULD NOT here. >=20 > But I'll go with consensus, also accepting that the IESG might correct > us in either direction. Thus, what do others think? Now that I think of it, another compromise would be language like "SHOULD N= OT ... unless ..." followed by an explicit example of when we would think i= t's safe to violate the SHOULD NOT. That strengthens it without going all = the way to a MUST NOT. Any suggestions? From msk@cloudmark.com Thu Feb 9 10:14:55 2012 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 79AFB21E8014 for ; Thu, 9 Feb 2012 10:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAjBDaPhLG+x for ; Thu, 9 Feb 2012 10:14:54 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id B620521E8012 for ; Thu, 9 Feb 2012 10:14:54 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 9 Feb 2012 10:14:54 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 9 Feb 2012 10:14:54 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 9 Feb 2012 10:14:53 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-07.txt Thread-Index: AcznTMMcLetjn3BjTMups15yBEljjAACSHEw Message-ID: References: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> <17BC3B48-8118-442C-A51C-8D7A7043C982@wordtothewise.com> <4F32A2E4.5070608@tana.it> <4F33FC54.1010003@tana.it> In-Reply-To: <4F33FC54.1010003@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-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 18:14:55 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Thursday, February 09, 2012 9:03 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >=20 > The whole snippet quoted above seems to be somewhat misplaced, as those > are all cases of "mechanical reports" that the concluding sentence of > that paragraph discourages. The methods listed in 8.1 all name things that warrant corrective action. = User submission are active demands for corrective action; mail arriving at = spam traps and honeypots are always either from spammers or poorly managed = mailing lists, and virus false positives are (as far as I know) few and far= between. What we took out was spam filtering and authentication failures,= both of which are far more FP-prone. > >>> 8.6 implies that the d=3D domain is always a good place to send an > >>> unsolicited report if it leads to a deliverable email address. Is > >>> that what we mean to say? > >> > >> No. A "reasonable candidate" implies a few attempts can be done. > > > > I'm not sure what you mean there. >=20 > Even if the d=3D domain is a reasonable candidate, one should stop > sending reports if any of the following is determined to be true: >=20 > * abuse@domain is undeliverable, > * nobody acknowledges the reports (paragraph 13), or > * the recipients opt-out (paragraph 5). Don't we already cover those cases, then? > > 8.6 fairly strongly implies that the only reason that a DKIM d=3D might > > not be an appropriate place to notify is if the d=3D is being used to > > distinguish reputation streams. That's only one of several reasons it > > may not be a reasonable candidate. >=20 > Abusive parties (paragraph 14) make another class of unreasonable > candidates. Added to the end of 8.6: "..., or the verified domain is a fake and discar= dable domain created by a bad actor for the purpose of sending abusive mail= ." Anything else? -MSK From msk@cloudmark.com Thu Feb 9 10:23:18 2012 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 D72AA21F8757 for ; Thu, 9 Feb 2012 10:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.593 X-Spam-Level: X-Spam-Status: No, score=-103.593 tagged_above=-999 required=5 tests=[AWL=1.006, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzNoqua1KRzE for ; Thu, 9 Feb 2012 10:23:15 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id D6A3621F875A for ; Thu, 9 Feb 2012 10:23:09 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 9 Feb 2012 10:23:09 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 9 Feb 2012 10:23:09 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 9 Feb 2012 10:23:08 -0800 Thread-Topic: [marf] Working Group Last Call: draft-ietf-marf-spf-reporting and draft-ietf-marf-dkim-reporting Thread-Index: Aczm9vrAoHOkbfmaSGGoJvXamPX8jQAYGsqQ Message-ID: References: <5339830.dVgCMc24YG@scott-latitude-e6320> In-Reply-To: <5339830.dVgCMc24YG@scott-latitude-e6320> 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] Working Group Last Call: draft-ietf-marf-spf-reporting and draft-ietf-marf-dkim-reporting X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 18:23:18 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Wednesday, February 08, 2012 10:49 PM > To: marf@ietf.org > Subject: Re: [marf] Working Group Last Call: draft-ietf-marf-spf-reportin= g and draft-ietf-marf-dkim-reporting >=20 > Comments on the dkim-reporting draft (for the record, I'm happy with > the spf- reporting draft): I think we assume that about authors... :-) > paragraph 3.3, items 3/5: It seems to me to be overkill to specify > anything about what should be logged locally. It's not relevant to > interoperability and is really an implementation detail. Fixed. > paragraph 3.3, item 8: Since ra=3D for dkim is required, then it seems to > me if ra=3D is missing, the record has already failed step 5, so step is > is redundant. Oversight; "ra=3D" is no longer required. Changed it to OPTIONAL. This wa= s done a couple of versions ago to allow for the case where someone wants f= ailures to be reported via SMTP errors only and not ARF reports. > In the last hunk of paragraph 3, there is the phrase: >=20 > "It might be useful to some Signers to receive such reports. To enable > this, a Verifier could violate the first step above and continue even > in the absence of an "r=3D" tag." >=20 > I know that the rest of the paragraph gets to "Don't do this", but I'm > afraid the current wording is an invitation to mischief. Perhaps > something like: >=20 > "It might be useful to some Signers to receive such reports, but this > use case is not supported. To support this, a Verifier would have to > violate the first step above and continue even in the absence of an > "r=3D" tag." Applied. Thanks for the review! -MSK From steve@wordtothewise.com Thu Feb 9 10:29:16 2012 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 81FEB21E8021 for ; Thu, 9 Feb 2012 10:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TD4x02xT8S8F for ; Thu, 9 Feb 2012 10:29:16 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 06A9121F8535 for ; Thu, 9 Feb 2012 10:29:16 -0800 (PST) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id C18032EB25 for ; Thu, 9 Feb 2012 10:29:15 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Steve Atkins In-Reply-To: Date: Thu, 9 Feb 2012 10:29:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <730797D9-E7D6-4286-A7F7-E200EFB9D656@wordtothewise.com> References: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> <17BC3B48-8118-442C-A51C-8D7A7043C982@wordtothewise.com> <4F32A2E4.5070608@tana.it> <4F33FC54.1010003@tana.it> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1257) Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 18:29:16 -0000 On Feb 9, 2012, at 10:14 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of Alessandro Vesely >> Sent: Thursday, February 09, 2012 9:03 AM >> To: marf@ietf.org >> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >>=20 >> The whole snippet quoted above seems to be somewhat misplaced, as = those >> are all cases of "mechanical reports" that the concluding sentence of >> that paragraph discourages. >=20 > The methods listed in 8.1 all name things that warrant corrective = action. User submission are active demands for corrective action; mail = arriving at spam traps and honeypots are always either from spammers or = poorly managed mailing lists, and virus false positives are (as far as I = know) few and far between. What we took out was spam filtering and = authentication failures, both of which are far more FP-prone. >=20 >>>>> 8.6 implies that the d=3D domain is always a good place to send an >>>>> unsolicited report if it leads to a deliverable email address. Is >>>>> that what we mean to say? >>>>=20 >>>> No. A "reasonable candidate" implies a few attempts can be done. >>>=20 >>> I'm not sure what you mean there. >>=20 >> Even if the d=3D domain is a reasonable candidate, one should stop >> sending reports if any of the following is determined to be true: >>=20 >> * abuse@domain is undeliverable, >> * nobody acknowledges the reports (paragraph 13), or >> * the recipients opt-out (paragraph 5). >=20 > Don't we already cover those cases, then? >=20 >>> 8.6 fairly strongly implies that the only reason that a DKIM d=3D = might >>> not be an appropriate place to notify is if the d=3D is being used = to >>> distinguish reputation streams. That's only one of several reasons = it >>> may not be a reasonable candidate. >>=20 >> Abusive parties (paragraph 14) make another class of unreasonable >> candidates. >=20 > Added to the end of 8.6: "..., or the verified domain is a fake and = discardable domain created by a bad actor for the purpose of sending = abusive mail." >=20 > Anything else? One common case is where the d=3D domain is that of the entity owning the mailing list and generating the content, while outsourcing the delivery of the mail to an ESP. In those cases (and it's a very common case) notifying anyone other than the ESP is probably a waste of time, while notifying the ESP will be extremely effective. I'm not sure whether we want to try and teach people what some decent heuristics are, or just put in enough suggestions to mitigate the harm done to others if they get it wrong, though. Cheers, Steve From vesely@tana.it Thu Feb 9 10:31:52 2012 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 AF6FD21F8535 for ; Thu, 9 Feb 2012 10:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.655 X-Spam-Level: X-Spam-Status: No, score=-4.655 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLQtALbryTLm for ; Thu, 9 Feb 2012 10:31:52 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C6C5921F8559 for ; Thu, 9 Feb 2012 10:31:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328812310; bh=keQKa9ZAVUSJCO821n7hEXcv9tBa3qlBepuPYumH/x0=; l=1437; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=aL6ra3ENai+TWBGPQN+we7yPdrO6BdgScYDZV4xfQQR+B7SU130coAp5xfFbgTbYB +GaAHfx4td7T39IrLp4BdUkPFC2vxovA0n10KlbMdr8HSKloeV/I0m9Fc+IccBcYTp fFC2RwoYJAYmBN8MU6rUxaQ1qqsgQCgZxWqlX8FY= 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, 09 Feb 2012 19:31:50 +0100 id 00000000005DC042.000000004F341116.00001FAF Message-ID: <4F341116.1030206@tana.it> Date: Thu, 09 Feb 2012 19:31:50 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> <4F32A0F7.4000002@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-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 18:31:52 -0000 On 08/Feb/12 20:18, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely > >> *Abstract* >> >> The abstract says "end users can use these methods", which may be >> somewhat misleading. How about "and conceivably even end users", or >> equivalent English text? > > How is it misleading? Sorry, Murray, forget it. I thought (as said in 8.2) that reporting is no MUA's business. Thinking twice, however, it is not bad if MUA developers have a look at this I-D, even if most methods are not suitable for them. >> I'm unable to understand the first sentence of paragraph 3. Reports >> have to be new messages irrespectively of whether the original message >> was accepted or rejected. > > The focus isn't on new messages, it's on SMTP. If the delivery > method isn't SMTP, then the rest of that paragraph doesn't apply > because its loop-avoidance technique isn't applicable. Well, that focus adds to the confusion, since the preceding sections only do SMTP. You are not talking about failed authentication of non-SMTP messages (doseta), are you? It is the parenthesized "versus" that drives me astray. I tend to understand the beginning of that paragraph as if it were just: 3. The envelope sender address of the report needs to be chosen so that these reports will not generate mail loops, so as to avoid amplification attacks, deliberate or otherwise. What am I missing? From msk@cloudmark.com Thu Feb 9 10:33:50 2012 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 8305921F85A4 for ; Thu, 9 Feb 2012 10:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UpU9lnUcKbW for ; Thu, 9 Feb 2012 10:33:50 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0852E21F85A2 for ; Thu, 9 Feb 2012 10:33:49 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 9 Feb 2012 10:33:49 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 9 Feb 2012 10:33:49 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Thu, 9 Feb 2012 10:33:48 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-07.txt Thread-Index: AcznWLyaGnAA/W4bRPyC4x+WBNHJyAAAE25A Message-ID: References: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> <17BC3B48-8118-442C-A51C-8D7A7043C982@wordtothewise.com> <4F32A2E4.5070608@tana.it> <4F33FC54.1010003@tana.it> <730797D9-E7D6-4286-A7F7-E200EFB9D656@wordtothewise.com> In-Reply-To: <730797D9-E7D6-4286-A7F7-E200EFB9D656@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] I-D Action: draft-ietf-marf-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 18:33:50 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= teve Atkins > Sent: Thursday, February 09, 2012 10:29 AM > To: Message Abuse Report Format working group > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >=20 > One common case is where the d=3D domain is that of the entity owning the > mailing list and generating the content, while outsourcing the delivery > of the mail to an ESP. >=20 > In those cases (and it's a very common case) notifying anyone other > than the ESP is probably a waste of time, while notifying the ESP will > be extremely effective. >=20 > I'm not sure whether we want to try and teach people what some decent > heuristics are, or just put in enough suggestions to mitigate the harm > done to others if they get it wrong, though. It seems to me we're starting down the road of cluttering the document with= counter-examples if we add this. Can someone suggest some more generic text here about cases where reporting= to the "d=3D" is a bad idea, hopefully in ways that the report generator c= an detect? If not, the two examples we have set the stage nicely, I think. -MSK From msk@cloudmark.com Thu Feb 9 10:36:41 2012 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 42FB521E8027 for ; Thu, 9 Feb 2012 10:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2F8lmpQfq-pu for ; Thu, 9 Feb 2012 10:36:40 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id D2EED21E8021 for ; Thu, 9 Feb 2012 10:36:40 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 9 Feb 2012 10:36:40 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 9 Feb 2012 10:36:40 -0800 From: "Murray S. Kucherawy" To: Alessandro Vesely , "marf@ietf.org" Date: Thu, 9 Feb 2012 10:36:39 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-07.txt Thread-Index: AcznWRoeIfASySQJRKucfOimyemTOgAAGw2g Message-ID: References: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> <4F32A0F7.4000002@tana.it> <4F341116.1030206@tana.it> In-Reply-To: <4F341116.1030206@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-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 18:36:41 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Thursday, February 09, 2012 10:32 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >=20 > Well, that focus adds to the confusion, since the preceding sections > only do SMTP. You are not talking about failed authentication of non- > SMTP messages (doseta), are you? >=20 > It is the parenthesized "versus" that drives me astray. I tend to > understand the beginning of that paragraph as if it were just: >=20 > 3. The envelope sender address of the report needs to be chosen so > that these reports will not generate mail loops, so as to avoid > amplification attacks, deliberate or otherwise. >=20 > What am I missing? It is a little convoluted, I agree. How about: "When sending a new report via SMTP, it is necessary to construct the messa= ge so as to avoid amplification attacks, deliberate or otherwise." From vesely@tana.it Thu Feb 9 10:56:00 2012 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 8BAB021F871D for ; Thu, 9 Feb 2012 10:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.656 X-Spam-Level: X-Spam-Status: No, score=-4.656 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpvCg1-t2LnN for ; Thu, 9 Feb 2012 10:55:59 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id B1E3621F871E for ; Thu, 9 Feb 2012 10:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328813758; bh=0tqf7AgrbqvgEmjlgsRS7PepY7xa7W+XvU8XQnM322Q=; l=244; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=kbesGWmFe88b7EfpyoMvdIQ2RNT7UAoDn9OVouoLkPUb0kDc2JJGNz2Yd1z96OOPM 1v2Mq0e9vwQQahtSbfrmY3MvPmQkUB09AjMjyXYjPa/J+GOVVnQnR+Cb3eIkAwn4Bm FcOE++wD4Uhp9lRjmYPoxEG9YYttmXsJA1yWDquE= 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, 09 Feb 2012 19:55:58 +0100 id 00000000005DC042.000000004F3416BE.00002785 Message-ID: <4F3416BE.6010804@tana.it> Date: Thu, 09 Feb 2012 19:55:58 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> <4F32A0F7.4000002@tana.it> <4F341116.1030206@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-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 18:56:00 -0000 On 09/Feb/12 19:36, Murray S. Kucherawy wrote: > > How about: > > "When sending a new report via SMTP, it is necessary to construct > the message so as to avoid amplification attacks, deliberate or > otherwise." Much clearer, thanks. From steve@wordtothewise.com Thu Feb 9 11:11:49 2012 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 2BB3521F85A2 for ; Thu, 9 Feb 2012 11:11:49 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKuVpXqVW+yC for ; Thu, 9 Feb 2012 11:11:47 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id B7B6621F85AA for ; Thu, 9 Feb 2012 11:11:46 -0800 (PST) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id 12C2B2DDE4 for ; Thu, 9 Feb 2012 11:11:45 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Steve Atkins In-Reply-To: Date: Thu, 9 Feb 2012 11:11:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0914944E-1491-422F-9BBD-460AF322F680@wordtothewise.com> References: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> <17BC3B48-8118-442C-A51C-8D7A7043C982@wordtothewise.com> <4F32A2E4.5070608@tana.it> <4F33FC54.1010003@tana.it> <730797D9-E7D6-4286-A7F7-E200EFB9D656@wordtothewise.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1257) Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 19:11:49 -0000 On Feb 9, 2012, at 10:33 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of Steve Atkins >> Sent: Thursday, February 09, 2012 10:29 AM >> To: Message Abuse Report Format working group >> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >>=20 >> One common case is where the d=3D domain is that of the entity owning = the >> mailing list and generating the content, while outsourcing the = delivery >> of the mail to an ESP. >>=20 >> In those cases (and it's a very common case) notifying anyone other >> than the ESP is probably a waste of time, while notifying the ESP = will >> be extremely effective. >>=20 >> I'm not sure whether we want to try and teach people what some decent >> heuristics are, or just put in enough suggestions to mitigate the = harm >> done to others if they get it wrong, though. >=20 > It seems to me we're starting down the road of cluttering the document = with counter-examples if we add this. >=20 > Can someone suggest some more generic text here about cases where = reporting to the "d=3D" is a bad idea, hopefully in ways that the report = generator can detect? >=20 > If not, the two examples we have set the stage nicely, I think. I think the examples are the problem. The implication they give is that if the d=3D domain is a "real" domain, it's a good place to send reports to. It's a really minor issue, but I guess I should come up with some alternate wording. *** draft-ietf-marf-as-07.txt 2012-02-07 22:38:33.000000000 -0800 --- new.txt 2012-02-09 11:11:01.000000000 -0800 *************** *** 307,317 **** 6. Where an abusive message is signed using a domain-level authentication technology such as DKIM ([RFC6376]) or SPF ([RFC4408]), the domain that has been verified by the ! authentication mechanism is likely a reasonable candidate for ! receiving feedback about the message. However, this is not ! universally true, since sometimes the domain thus verified ! exists only to distinguish one stream of mail from another = (see ! Section 2.5 of [RFC6377]), and cannot actually receive email. 7. Recipients of unsolicited ARF reports SHOULD, in general, = handle them the same way as any other abuse reports. However, they = MAY take advantage of the standardized parts of the ARF format to --- 307,318 ---- 6. Where an abusive message is signed using a domain-level authentication technology such as DKIM ([RFC6376]) or SPF ([RFC4408]), the domain that has been verified by the ! authentication mechanism is oftenlikely a reasonable candidate = for ! receiving feedback about the message. For DKIM, though, while ! the authenticated domain has some responsibility for the mail ! sent it often will not be a good contact point for abuse = issues ! (for example, it may be the author of the message rather than ! the sender or it may be a domain that doesn't accept email at = all). 7. Recipients of unsolicited ARF reports SHOULD, in general, = handle them the same way as any other abuse reports. However, they = MAY take advantage of the standardized parts of the ARF format to Cheers, Steve From msk@cloudmark.com Thu Feb 9 11:25:58 2012 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 534C021E804F for ; Thu, 9 Feb 2012 11:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTM7k142CdUg for ; Thu, 9 Feb 2012 11:25:50 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 287E621E8046 for ; Thu, 9 Feb 2012 11:25:21 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 9 Feb 2012 11:24:55 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 9 Feb 2012 11:24:56 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Thu, 9 Feb 2012 11:24:54 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-07.txt Thread-Index: AcznXr8CqngL85NOQLyTdKySOZpUtgAAaY9Q Message-ID: References: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> <17BC3B48-8118-442C-A51C-8D7A7043C982@wordtothewise.com> <4F32A2E4.5070608@tana.it> <4F33FC54.1010003@tana.it> <730797D9-E7D6-4286-A7F7-E200EFB9D656@wordtothewise.com> <0914944E-1491-422F-9BBD-460AF322F680@wordtothewise.com> In-Reply-To: <0914944E-1491-422F-9BBD-460AF322F680@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] I-D Action: draft-ietf-marf-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 19:25:58 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= teve Atkins > Sent: Thursday, February 09, 2012 11:12 AM > To: Message Abuse Report Format working group > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >=20 > It's a really minor issue, but I guess I should come up with some > alternate wording. > [...] Fine with me, except that I'd also mention the d=3D could identify the bad = actor, in which case reporting the abuse is unlikely to be effective. Good enough? -MSK From steve@wordtothewise.com Thu Feb 9 11:56:00 2012 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 7005321E8061 for ; Thu, 9 Feb 2012 11:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0ETNdTP8PDT for ; Thu, 9 Feb 2012 11:55:59 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 115A121E8056 for ; Thu, 9 Feb 2012 11:55:59 -0800 (PST) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id B041C2DDE4 for ; Thu, 9 Feb 2012 11:55:55 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Steve Atkins In-Reply-To: Date: Thu, 9 Feb 2012 11:55:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> <17BC3B48-8118-442C-A51C-8D7A7043C982@wordtothewise.com> <4F32A2E4.5070608@tana.it> <4F33FC54.1010003@tana.it> <730797D9-E7D6-4286-A7F7-E200EFB9D656@wordtothewise.com> <0914944E-1491-422F-9BBD-460AF322F680@wordtothewise.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1257) Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 19:56:00 -0000 On Feb 9, 2012, at 11:24 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of Steve Atkins >> Sent: Thursday, February 09, 2012 11:12 AM >> To: Message Abuse Report Format working group >> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >>=20 >> It's a really minor issue, but I guess I should come up with some >> alternate wording. >> [...] >=20 > Fine with me, except that I'd also mention the d=3D could identify the = bad actor, in which case reporting the abuse is unlikely to be = effective. >=20 > Good enough? Sure. Cheers, Steve From sklist@kitterman.com Thu Feb 9 13:08:53 2012 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 EA2A521F8604 for ; Thu, 9 Feb 2012 13:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imiLr9JwjDdv for ; Thu, 9 Feb 2012 13:08:51 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 77BB021F8602 for ; Thu, 9 Feb 2012 13:08:51 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 9C2D3D0407F; Thu, 9 Feb 2012 15:08:50 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328821730; bh=tsPspMKVnJcL0Qcuek490ju8Z98QB4MhyR7WHFPmVCY=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=Qvm0skCTNdIAGG1QBy3Kw3mEFW3JgCSpnGnbi7SXQIESt3PfnRDqfCAWpI/+WiWmp iUId6fZ7nyFMPTYq3KGf48DLAIK2kRjmM/1JyEsroJ7/sM+mAThqh7/Qy1EttDmQaW ViXvSJIFfnasaNVDY8ssUGHMTBez/JpEoU/ln84U= Received: from 67.sub-70-210-197.myvzw.com (67.sub-70-210-197.myvzw.com [70.210.197.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 45281D0400D; Thu, 9 Feb 2012 15:08:49 -0600 (CST) References: <5681886.BiAaEpefJ0@scott-latitude-e6320> <1449287.lWhNiLsB7Y@scott-latitude-e6320> <4F34086D.8060609@tana.it> User-Agent: K-9 Mail for Android In-Reply-To: <4F34086D.8060609@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 09 Feb 2012 15:08:56 -0600 To: Alessandro Vesely ,marf@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 21:08:53 -0000 Alessandro Vesely wrote: >On 09/Feb/12 06:54, Scott Kitterman wrote: >> >> I think this is a MUST NOT. All it will lead to is pain. >> >> I will confess it's possible that I'm overly cynical about the >> ability of giving serious thought reliably producing the correct >> result here, but I really think that for whatever corner case that >> may exist, there's globally more harm associated with given people >> a free pass to think it over. > >A corner case: an ISP configure SPF according to their own mail >traffic, e.g. "v=spf1 mx:ISP.example ~all". The ISP don't trust their >customers enough to point WHOIS records directly to their >abuse-mailboxes, but does count-and-forward according to 8.10. Now, >an ISP's customer sends spam with MAIL FROM:. The >abuse-mailbox resulting from WHOIS lookup of the source address is >abuse@ISP.example. That domain failed SPF authentication and thus, >you say, it cannot be the target of unsolicited complaints. Why? There's no reliable way to distinguish that scenario from regular spoofing, so it's pointless to use to drive design. ISP can police his own network without external help, so it's not a useful distinction in any case. >As for the whole idea, may I ask why softfail is considered less bad >than neutral? AFAIK people use them interchangeably when they don't >dare -all. SPF is opt-in, so I can't punish none results. The one receiver policy MUST in RFC 4408 is neutral MUST be treated the same as none. My proposed text is consistent with this. >We are already saying that the domain in MAIL FROM is likely a >reasonable candidate if SPF gave "pass". Doesn't that already mean >you should not use it if SPF gave any other result? Why do we need to >add that fail, softfail, temperror, and permerror, in particular, are >not good? > >Rather, I'd s/the domain that has been verified/the domain that has >been verified ("pass")/, in case that isn't clear enough. It's a little more complicated than that and I think the suggested text navigates the complexity correctly. Scott K From sklist@kitterman.com Thu Feb 9 13:12:16 2012 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 79C0721F860F for ; Thu, 9 Feb 2012 13:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpRLes0BlFSb for ; Thu, 9 Feb 2012 13:12:15 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4253B21F8604 for ; Thu, 9 Feb 2012 13:12:14 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id B4581D0407F; Thu, 9 Feb 2012 15:11:48 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328821908; bh=2rQsyOrxpmR/cRGzCDOXcq3cTl7imd5TSfu/eiGMGFo=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=am2Oh6PsLx9gAp02qCtSW7v7eGjsaj4lkwiI9i5xDGZI8HS52eshRB2Cm4eL14QUB 5Z1M0JnoIMfYc2q5X6UCmzDZXgPvXhtcb6gI5t5logTszlQw0SuVjCX7yA4aUH4jT/ A0ZavlDt0/fxET4JH+4YserEPAbWyNXmvHaQauHU= Received: from 67.sub-70-210-197.myvzw.com (67.sub-70-210-197.myvzw.com [70.210.197.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 2A3D4D0400D; Thu, 9 Feb 2012 15:11:47 -0600 (CST) References: <5681886.BiAaEpefJ0@scott-latitude-e6320> <1449287.lWhNiLsB7Y@scott-latitude-e6320> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 09 Feb 2012 15:11:57 -0600 To: "marf@ietf.org" Message-ID: <7a340d22-de07-4308-a864-767a3936838e@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 21:12:16 -0000 "Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf >Of Murray S. Kucherawy >> Sent: Thursday, February 09, 2012 9:50 AM >> To: marf@ietf.org >> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >> >> If I may paraphrase John Levine, no amount of MUST NOTting will >prevent >> a pinhead from being a pinhead. In those cases, I prefer to pick >> RFC2119 words geared toward the competent reader. That's why I went >> with SHOULD NOT here. >> >> But I'll go with consensus, also accepting that the IESG might >correct >> us in either direction. Thus, what do others think? > >Now that I think of it, another compromise would be language like >"SHOULD NOT ... unless ..." followed by an explicit example of when we >would think it's safe to violate the SHOULD NOT. That strengthens it >without going all the way to a MUST NOT. > >Any suggestions? If I could come up with a useful case for after the unless, I'd be happy with this. Scott K From sklist@kitterman.com Thu Feb 9 13:18:14 2012 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 A4F1221E805B for ; Thu, 9 Feb 2012 13:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lt9oFXV3XNwQ for ; Thu, 9 Feb 2012 13:18:13 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 85C3721E805A for ; Thu, 9 Feb 2012 13:18:13 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 24C48D0407F; Thu, 9 Feb 2012 15:18:13 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328822293; bh=3Fnb1PuVfUWirsxl6QPUnb67gwbsVVf8rbFNZ2dzpMI=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=VhVb4dm7HvsJcb9tSA5lmQQqy2PyEi7jPS6NST470vGz4ujxFeVOdC7vjFCoOkRP9 teKTcv8t3iV1iNcXOhWseDTZy3759IhbKMyY5qnJYVLt8fYJMzGxn3wlspFBLBs0W7 xu4OADhV6PXkqD+720ZoXzxTE5I8rNwQoSEdAfo4= Received: from 67.sub-70-210-197.myvzw.com (67.sub-70-210-197.myvzw.com [70.210.197.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 9182BD0400D; Thu, 9 Feb 2012 15:18:12 -0600 (CST) References: <20120208063917.26412.88138.idtracker@ietfa.amsl.com> <17BC3B48-8118-442C-A51C-8D7A7043C982@wordtothewise.com> <4F32A2E4.5070608@tana.it> <4F33FC54.1010003@tana.it> <730797D9-E7D6-4286-A7F7-E200EFB9D656@wordtothewise.com> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 09 Feb 2012 15:18:16 -0600 To: Message Abuse Report Format working group Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 21:18:14 -0000 "Murray S. Kucherawy" wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf >Of Steve Atkins >> Sent: Thursday, February 09, 2012 10:29 AM >> To: Message Abuse Report Format working group >> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >> >> One common case is where the d= domain is that of the entity owning >the >> mailing list and generating the content, while outsourcing the >delivery >> of the mail to an ESP. >> >> In those cases (and it's a very common case) notifying anyone other >> than the ESP is probably a waste of time, while notifying the ESP >will >> be extremely effective. >> >> I'm not sure whether we want to try and teach people what some decent >> heuristics are, or just put in enough suggestions to mitigate the >harm >> done to others if they get it wrong, though. > >It seems to me we're starting down the road of cluttering the document >with counter-examples if we add this. > >Can someone suggest some more generic text here about cases where >reporting to the "d=" is a bad idea, hopefully in ways that the report >generator can detect? > >If not, the two examples we have set the stage nicely, I think. > >-MSK In Steve's example if i= is explicitly set, it may be a better choice. I'm not sure though. Scott K From msk@cloudmark.com Thu Feb 9 21:31:23 2012 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 E681621F857D for ; Thu, 9 Feb 2012 21:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JLqTsF3-u2g for ; Thu, 9 Feb 2012 21:31:22 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1726721F8581 for ; Thu, 9 Feb 2012 21:31:21 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 9 Feb 2012 21:31:20 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 9 Feb 2012 21:31:20 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 9 Feb 2012 21:31:29 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-07.txt Thread-Index: Acznb4Jt0pDc/V3sS2yAu1D7FjAi2wARR6Ug Message-ID: References: <5681886.BiAaEpefJ0@scott-latitude-e6320> <1449287.lWhNiLsB7Y@scott-latitude-e6320> <7a340d22-de07-4308-a864-767a3936838e@email.android.com> In-Reply-To: <7a340d22-de07-4308-a864-767a3936838e@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 10 Feb 2012 05:31:23 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Thursday, February 09, 2012 1:12 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >=20 > >Now that I think of it, another compromise would be language like > >"SHOULD NOT ... unless ..." followed by an explicit example of when we > >would think it's safe to violate the SHOULD NOT. That strengthens it > >without going all the way to a MUST NOT. > > > >Any suggestions? >=20 > If I could come up with a useful case for after the unless, I'd be > happy with this. How about: Similarly, if a report generator applies SPF to arriving messages, and that= evaluation produced something other than a "Pass", "None" or "Neutral" res= ult, a report addressed to the RFC5321.MailFrom domain SHOULD NOT be genera= ted as it might be a forgery and thus not actionable. A valid exception wo= uld be specific knowledge that the SPF check is expected to fail for that d= omain under those circumstances. From msk@cloudmark.com Thu Feb 9 22:36:45 2012 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 9E44E21E801B for ; Thu, 9 Feb 2012 22:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pb6nIeu3AQwQ for ; Thu, 9 Feb 2012 22:36:45 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1C48121E8010 for ; Thu, 9 Feb 2012 22:36:45 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 9 Feb 2012 22:36:44 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 9 Feb 2012 22:36:44 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 9 Feb 2012 22:36:42 -0800 Thread-Topic: Reminder: WGLC for draft-ietf-marf-as ends 2/10 Thread-Index: Acznvln/vcLipHtBTQypb2qwzJXbPw== 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_F5833273385BB34F99288B3648C4F06F19C9A7DCE5EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] Reminder: WGLC for draft-ietf-marf-as ends 2/10 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, 10 Feb 2012 06:36:45 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DCE5EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a reminder that WGLC for draft-ietf-marf-as ends tomorrow 2/10. Barry= will be writing up the shepherding document and sending it to the IESG for= review and evaluation after that. I will post the version with the latest revisions late tomorrow afternoon P= acific time, and that should be it for this document until after IETF LC. -MSK --_000_F5833273385BB34F99288B3648C4F06F19C9A7DCE5EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a reminder = that WGLC for draft-ietf-marf-as ends tomorrow 2/10.  Barry will be wr= iting up the shepherding document and sending it to the IESG for review and= evaluation after that.

 

I will post the version with the latest revisions= late tomorrow afternoon Pacific time, and that should be it for this docum= ent until after IETF LC.

 

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DCE5EXCHC2corpclo_-- From vesely@tana.it Fri Feb 10 01:56:49 2012 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 5E36D21F876D for ; Fri, 10 Feb 2012 01:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmjnYzzeoZLt for ; Fri, 10 Feb 2012 01:56:48 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 80FFE21F8757 for ; Fri, 10 Feb 2012 01:56:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328867807; bh=wt23jjKyzsIXpHFZyH7H72LcdCkvTlrfqctjNUnm9wQ=; l=2405; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=XU4y1Omk9o7UXr+nejjZxAGht0HIgUsqtyqTaVLEff1Fqd1mmoDBbmA98MhBfoTpE FmsTimjc1bQjDxfP0sS1dhBFYX0B/6+AqDzkT9dvwljL0ZftOEV/FYQEwoOA7st9QC MFkOtAhLfO06pwdTJc904G13HKrOTS7Xtz+RBh2c= 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, 10 Feb 2012 10:56:47 +0100 id 00000000005DC035.000000004F34E9DF.0000058F Message-ID: <4F34E9DE.4090007@tana.it> Date: Fri, 10 Feb 2012 10:56:46 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <5681886.BiAaEpefJ0@scott-latitude-e6320> <1449287.lWhNiLsB7Y@scott-latitude-e6320> <4F34086D.8060609@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-as-07.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, 10 Feb 2012 09:56:49 -0000 On 09/Feb/12 22:08, Scott Kitterman wrote: > Alessandro Vesely wrote: >>On 09/Feb/12 06:54, Scott Kitterman wrote: >>> >>> I think this is a MUST NOT. All it will lead to is pain. >> >> A corner case: an ISP configure SPF according to their own mail >> traffic, e.g. "v=spf1 mx:ISP.example ~all". The ISP don't trust >> their customers enough to point WHOIS records directly to their >> abuse-mailboxes, but does count-and-forward according to 8.10. An >> ISP's customer sends spam with MAIL FROM:. > > There's no reliable way to distinguish that scenario from regular > spoofing, so it's pointless to use to drive design. Except that we'd be providing a recipe for building non-reportable forgeries. > ISP can police his own network without external help, so it's not a > useful distinction in any case. The amount of support that ISPs may want to give to abuse reporting is unknown at this time. Requiring them to proactively policing abusive use of domain names in outgoing mail is probably not an option, also because that might interfere with contractual habits (more than explicit complaints from third parties.) Advice that abuse-mailboxes shouldn't be spam-filtered is spread throughout several papers. That the domain part of abuse-mailboxes should not be SPF-protected would be a new, somewhat obscure requirement, that is not going to improve SPF adoption. >> We are already saying that the domain in MAIL FROM is likely a >> reasonable candidate if SPF gave "pass". Doesn't that already >> mean you should not use it if SPF gave any other result? > > It's a little more complicated than that and I think the suggested > text navigates the complexity correctly. We mention how to derive a destination address from * WHOIS, * rDNS, and * "pass" for SPF/DKIM domain. Any other destination is dicey, and SHOULD NOT be used. IOW, an address derived from WHOIS, rDNS, or DKIM does not need to be doubly checked against SPF none/neutral. And let me stress this once more: we are talking _only_ of addresses derived in one of those three ways. Yes, it is more complicated. For example, if I get DKIM pass and SPF fail for the same domain, I should hypothesize a replay attack which might be better reported as an authentication failure. But that's well beyond what this I-D is going to specify/state. From vesely@tana.it Fri Feb 10 02:03:07 2012 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 C833A21F8548 for ; Fri, 10 Feb 2012 02:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.642 X-Spam-Level: X-Spam-Status: No, score=-4.642 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+tcB442VKZU for ; Fri, 10 Feb 2012 02:03:07 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2677721F853E for ; Fri, 10 Feb 2012 02:03:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328868186; bh=x4G18EB5i400IUg1o/VXFA+AlWdWSRp582PxlWwRDDA=; l=525; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=DdN1WSqB0n4Bsc1D5o67ARGQtr/GixAOadS+d+jnbN846CS+LSD/2lD3FvtJBtE19 HB3C3gcUI5jz5s6bFE/5Po8E2iVlZi4KoTKop7sjBySBsPslODafZXpJnnPe8KtEUd Y4C5J+zRGV/Hvq9/TgauRmsT7bB67eQFGuZiUl1k= 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, 10 Feb 2012 11:03:06 +0100 id 00000000005DC035.000000004F34EB5A.00000740 Message-ID: <4F34EB5A.6090103@tana.it> Date: Fri, 10 Feb 2012 11:03:06 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 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] Reminder: WGLC for draft-ietf-marf-as ends 2/10 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, 10 Feb 2012 10:03:07 -0000 On 10/Feb/12 07:36, Murray S. Kucherawy wrote: > Just a reminder that WGLC for draft-ietf-marf-as ends tomorrow 2/10. > Barry will be writing up the shepherding document and sending it to > the IESG for review and evaluation after that. > > I will post the version with the latest revisions late tomorrow > afternoon Pacific time, and that should be it for this document until > after IETF LC. One last nit: both 8.4 and 8.6 talk about where to send reports, moving 8.5 after 8.6 might improve continuity. TIA From sklist@kitterman.com Fri Feb 10 04:06:46 2012 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 C976921F8639 for ; Fri, 10 Feb 2012 04:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[AWL=-1.152, BAYES_00=-2.599, MANGLED_LOAN=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiJT5LmaoEJF for ; Fri, 10 Feb 2012 04:06:46 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6175021F861E for ; Fri, 10 Feb 2012 04:06:45 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 90744D0407F; Fri, 10 Feb 2012 06:06:44 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328875604; bh=MPQlI/MpAOJD5Nfb4pQk9uARFSe6mfTW8FmTTTaiZok=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=ErIMrp3GCuOfE1zn9fAegz0P3BtV/dFiFAQ5MgRGAcHd13XX86cWYZpeYX1pINDA0 nLtX50cVA4FqpytoGsArmbFzH5xouxOQDylWipq5Vb0xJZbxnuIwtoKGZmdcf40L6M /Y08DPZ2y7UGDgmhpUVH5vPcisQN4LTbmV4JNJtg= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 58214D04056; Fri, 10 Feb 2012 06:06:44 -0600 (CST) References: <5681886.BiAaEpefJ0@scott-latitude-e6320> <1449287.lWhNiLsB7Y@scott-latitude-e6320> <4F34086D.8060609@tana.it> <4F34E9DE.4090007@tana.it> User-Agent: K-9 Mail for Android In-Reply-To: <4F34E9DE.4090007@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 10 Feb 2012 07:06:45 -0500 To: marf@ietf.org Message-ID: <68d9b554-45bc-4f26-9f52-f06b0a992dcb@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 10 Feb 2012 12:06:46 -0000 Alessandro Vesely wrote: >On 09/Feb/12 22:08, Scott Kitterman wrote: >> Alessandro Vesely wrote: >>>On 09/Feb/12 06:54, Scott Kitterman wrote: >>>> >>>> I think this is a MUST NOT. All it will lead to is pain. >>> >>> A corner case: an ISP configure SPF according to their own mail >>> traffic, e.g. "v=spf1 mx:ISP.example ~all". The ISP don't trust >>> their customers enough to point WHOIS records directly to their >>> abuse-mailboxes, but does count-and-forward according to 8.10. An >>> ISP's customer sends spam with MAIL FROM:. >> >> There's no reliable way to distinguish that scenario from regular >> spoofing, so it's pointless to use to drive design. > >Except that we'd be providing a recipe for building non-reportable >forgeries. > >> ISP can police his own network without external help, so it's not a >> useful distinction in any case. > >The amount of support that ISPs may want to give to abuse reporting is >unknown at this time. Requiring them to proactively policing abusive >use of domain names in outgoing mail is probably not an option, also >because that might interfere with contractual habits (more than >explicit complaints from third parties.) This would only be relevant for their own domain, some other domain would be a different case. What I suggest isn't nearly so broad as you infer. >Advice that abuse-mailboxes shouldn't be spam-filtered is spread >throughout several papers. That the domain part of abuse-mailboxes >should not be SPF-protected would be a new, somewhat obscure >requirement, that is not going to improve SPF adoption. I don't agree. I don't see such a requirement. >>> We are already saying that the domain in MAIL FROM is likely a >>> reasonable candidate if SPF gave "pass". Doesn't that already >>> mean you should not use it if SPF gave any other result? >> >> It's a little more complicated than that and I think the suggested >> text navigates the complexity correctly. > >We mention how to derive a destination address from > >* WHOIS, >* rDNS, and >* "pass" for SPF/DKIM domain. > >Any other destination is dicey, and SHOULD NOT be used. IOW, an >address derived from WHOIS, rDNS, or DKIM does not need to be doubly >checked against SPF none/neutral. And let me stress this once more: >we are talking _only_ of addresses derived in one of those three ways. > >Yes, it is more complicated. For example, if I get DKIM pass and SPF >fail for the same domain, I should hypothesize a replay attack which >might be better reported as an authentication failure. But that's >well beyond what this I-D is going to specify/state. I think the DKIM pass with the same domain is a reasonable case. I can imagine a rouge ESP scenario where notifying the domain owner is a good idea. Thanks. I'll go back and modify my answer to Murray. Scott K From sklist@kitterman.com Fri Feb 10 04:15:32 2012 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 6F93221F863E for ; Fri, 10 Feb 2012 04:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EYXrJ250ukx for ; Fri, 10 Feb 2012 04:15:31 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id B95AE21F863D for ; Fri, 10 Feb 2012 04:15:31 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 1F078D0407F; Fri, 10 Feb 2012 06:15:31 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328876131; bh=Fn35cv3vzefCj7indWyLk0m8Ql2De7Z3g4Q7PYeYcqw=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=m6tJKzOoDqjau6/RL8Ffb6+ZjAoyM2NYLecpLA1/iyCRHyQEkwCH+f5a81mqsCHjW Q4ermIbsDBHg9cQZ/iVQ3XK4Zp2OMxvDqXFMzcjSrlGxbfeVgbNFYo4chSjQT0Zhxu IzcIhOIJcINAC0aIekiGD3uRKDaQwSLTZ6qFRE8Q= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id DA5B0D04056; Fri, 10 Feb 2012 06:15:30 -0600 (CST) References: <5681886.BiAaEpefJ0@scott-latitude-e6320> <1449287.lWhNiLsB7Y@scott-latitude-e6320> <7a340d22-de07-4308-a864-767a3936838e@email.android.com> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 10 Feb 2012 07:15:41 -0500 To: "marf@ietf.org" Message-ID: <1183a5b4-b51a-4056-abff-0b5e73cffe87@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 10 Feb 2012 12:15:32 -0000 "Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf >Of Scott Kitterman >> Sent: Thursday, February 09, 2012 1:12 PM >> To: marf@ietf.org >> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >> >> >Now that I think of it, another compromise would be language like >> >"SHOULD NOT ... unless ..." followed by an explicit example of when >we >> >would think it's safe to violate the SHOULD NOT. That strengthens >it >> >without going all the way to a MUST NOT. >> > >> >Any suggestions? >> >> If I could come up with a useful case for after the unless, I'd be >> happy with this. > >How about: > >Similarly, if a report generator applies SPF to arriving messages, and >that evaluation produced something other than a "Pass", "None" or >"Neutral" result, a report addressed to the RFC5321.MailFrom domain >SHOULD NOT be generated as it might be a forgery and thus not >actionable. A valid exception would be specific knowledge that the SPF >check is expected to fail for that domain under those circumstances. Allesandro provided a scenario that I think is reasonable. If you add: (i.e. a message with DKIM pass for the same domain) at the end and change "expected to fail" to "not definitive" I think I'm good. Scott K From shmuel+gen@patriot.net Fri Feb 10 06:58:56 2012 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 5055921F8610 for ; Fri, 10 Feb 2012 06:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rAzaMvMI9ko for ; Fri, 10 Feb 2012 06:58:55 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id B9EA221F84FC for ; Fri, 10 Feb 2012 06:58:55 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.180]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 96DE3F580A9 for ; Fri, 10 Feb 2012 09:44:18 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Thu, 09 Feb 2012 16:25:40 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120210144418.96DE3F580A9@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 14:58:56 -0000 In , on 02/09/2012 at 10:06 AM, "Murray S. Kucherawy" said: >Neither DKIM nor SPF do anything to authenticate the header From >domain. What other mechanism are you proposing we introduce? I'm not; I'm proposing that we be neutral on any potential future authenticatiobn standards. Or is there reason to believe that there will never be an RFC for signing domain names in the header? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From vesely@tana.it Fri Feb 10 07:34:00 2012 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 DC33921F8764 for ; Fri, 10 Feb 2012 07:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.344 X-Spam-Level: X-Spam-Status: No, score=-4.344 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75VDF3iSGn0B for ; Fri, 10 Feb 2012 07:34:00 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D908A21F8757 for ; Fri, 10 Feb 2012 07:33:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328888038; bh=fwTcMVY6cT7YzXxXmn6fRwWpZU3w0cPyI77MilPEpmc=; l=2668; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ONqQ6fi76xPFSrUGs/QDQ2T5AgzvOovigz8lagV4jYVilobKDV+74miKKESmV5ueH ZvlQgQpgPvEDl2w3sh5G+7bb6ppLBdpr+pHhPOOOcZ0v1FtpLHk1GOyznPrFijIBDT e2MAc7IyYsh7d+1VVN9HPw7diaSj6K2dxQHI4QD0= 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, 10 Feb 2012 16:33:58 +0100 id 00000000005DC035.000000004F3538E6.0000593D Message-ID: <4F3538E5.8080001@tana.it> Date: Fri, 10 Feb 2012 16:33:57 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <5681886.BiAaEpefJ0@scott-latitude-e6320> <1449287.lWhNiLsB7Y@scott-latitude-e6320> <4F34086D.8060609@tana.it> <4F34E9DE.4090007@tana.it> <68d9b554-45bc-4f26-9f52-f06b0a992dcb@email.android.com> In-Reply-To: <68d9b554-45bc-4f26-9f52-f06b0a992dcb@email.android.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 10 Feb 2012 15:34:01 -0000 On 10/Feb/12 13:06, Scott Kitterman wrote: > Alessandro Vesely wrote: >> >> The amount of support that ISPs may want to give to abuse reporting is >> unknown at this time. Requiring them to proactively policing abusive >> use of domain names in outgoing mail is probably not an option, also >> because that might interfere with contractual habits (more than >> explicit complaints from third parties.) > > This would only be relevant for their own domain, some other domain > would be a different case. What I suggest isn't nearly so broad as > you infer. > >> That the domain part of abuse-mailboxes should not be >> SPF-protected would be a new, somewhat obscure requirement, that >> is not going to improve SPF adoption. > > I don't agree. I don't see such a requirement. If some leased addresses can get (soft)fail for ISP.example, the ISP needs to scan outgoing SMTP transactions --if they are not cyphered-- in order to avoid non-reportable cases. Otherwise a bot-master could MAIL FROM: from those addresses and get away with it. (And that assuming that ISPs don't publish abuse-mailboxes for the sole purpose of keeping admin and technical contacts clear of spam complaints.) >> We mention how to derive a destination address from >> >> * WHOIS, >> * rDNS, and >> * "pass" for SPF/DKIM domain. >> >> Any other destination is dicey, and SHOULD NOT be used. IOW, an >> address derived from WHOIS, rDNS, or DKIM does not need to be doubly >> checked against SPF none/neutral. And let me stress this once more: >> we are talking _only_ of addresses derived in one of those three ways. >> >> Yes, it is more complicated. For example, if I get DKIM pass and SPF >> fail for the same domain, I should hypothesize a replay attack which >> might be better reported as an authentication failure. But that's >> well beyond what this I-D is going to specify/state. > > I think the DKIM pass with the same domain is a reasonable case. I > can imagine a rouge ESP scenario where notifying the domain owner > is a good idea. Author's domain should be the preferred reporting path, for example for newcomers or naive spammers, in order to have them admonished by their own postmasters. However, DKIM signatures can break for other reasons. In that case, a broken signature gives no hints about deriving the same reporting target from some other heuristics. > I'll go back and modify my answer to Murray. I hope he won't get down to convoluted scenarios. Examples belong to appendixes, and one or few actual cases would be clearer than lengthy discussions, IMHO. From sklist@kitterman.com Fri Feb 10 07:43:28 2012 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 D024821F8710 for ; Fri, 10 Feb 2012 07:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLl7Ooop8n4D for ; Fri, 10 Feb 2012 07:43:27 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C05B621F8596 for ; Fri, 10 Feb 2012 07:43:26 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E469020E40D0; Fri, 10 Feb 2012 10:43:25 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328888605; bh=PsR9AWL5TIdnUCCj42viJMn8VuR8V8xWKaYTakPVZ9k=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=DCfmz51gb+k18CBDAcsr3f/9sV7JbyoDdVncSd2U0z5YN2uS9H0rAYMrbpp5tRBoZ 5bb2MZw4LtG/k0ewB/4AAyJe/Ru+6QbG/g7tg5slbXtvT6SvImlXNGITPMnefsM1Ly O8TPwpaDz48mSAMGe3mgVO0gYdLkU5HI6QDobjm8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C516220E4083; Fri, 10 Feb 2012 10:43:25 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Fri, 10 Feb 2012 10:43:25 -0500 Message-ID: <11077475.E2zCB0Jdsz@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F3538E5.8080001@tana.it> References: <68d9b554-45bc-4f26-9f52-f06b0a992dcb@email.android.com> <4F3538E5.8080001@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 10 Feb 2012 15:43:28 -0000 On Friday, February 10, 2012 04:33:57 PM Alessandro Vesely wrote: ... > >> That the domain part of abuse-mailboxes should not be > >> SPF-protected would be a new, somewhat obscure requirement, that > >> is not going to improve SPF adoption. > > > > > > > > I don't agree. I don't see such a requirement. > > If some leased addresses can get (soft)fail for ISP.example, the ISP > needs to scan outgoing SMTP transactions --if they are not cyphered-- > in order to avoid non-reportable cases. Otherwise a bot-master could > MAIL FROM: from those addresses and get > away with it. > > (And that assuming that ISPs don't publish abuse-mailboxes for the > sole purpose of keeping admin and technical contacts clear of spam > complaints.) ... I think you are mixing things together that are separate. I do think it's up to a network owner (such as an ISP) to police their IP space. If they don't want mail using their domain name to be sent out of their network except through their official MTAs, they can prevent that easily enough. The problem though is it's difficult to reliable separate this case from generic SPF non-pass conditions, so I don't think we should create a space for an unreliable solution to a problem that network operators can solve on their own if they care to. None of this has any impact on the SPF status of the postmaster inbox. The message we are discussing here that didn't pass SPF was the original one believed to be abusive. That's got no bearing on the SPF status of any report to postmaster@. That's completely separate. I can see having an discussion about should postmaster addresses filter/reject based on SPF, but I don't think anything we are doing in the MARF group has any impact on the answer to that question. Scott K From msk@cloudmark.com Fri Feb 10 09:21:54 2012 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 34E4621F865E for ; Fri, 10 Feb 2012 09:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QejrQt4cHd8P for ; Fri, 10 Feb 2012 09:21:53 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id B945821F861A for ; Fri, 10 Feb 2012 09:21:53 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 10 Feb 2012 09:21:53 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 10 Feb 2012 09:21:53 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Fri, 10 Feb 2012 09:21:51 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-07.txt Thread-Index: AczoBITyu62stFs+Qs2+er4EtqGo0gAE4iZA Message-ID: References: <20120210144418.96DE3F580A9@smtp.patriot.net> In-Reply-To: <20120210144418.96DE3F580A9@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 10 Feb 2012 17:21:54 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Thursday, February 09, 2012 1:26 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >=20 > >Neither DKIM nor SPF do anything to authenticate the header From > >domain. What other mechanism are you proposing we introduce? >=20 > I'm not; I'm proposing that we be neutral on any potential future > authenticatiobn standards. Or is there reason to believe that there > will never be an RFC for signing domain names in the header? S/MIME and PGP also allow you to sign the From: field of a message, but the= y make no statement about whether what got signed is true or not. DKIM and SPF confirm that the use of the domain was effectively authorized.= DKIM, S/MIME and PGP confirm that the domain wasn't changed post-signing.= None of them make any statement about whether or not the domain itself is= valid in context, true, or anything else. I can't conceive of an Internet-based technology that can confirm intent or= legitimacy of the signer/author/whatever. From msk@cloudmark.com Fri Feb 10 09:30:53 2012 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 15D1A21F86B6 for ; Fri, 10 Feb 2012 09:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrwI+xO4J93y for ; Fri, 10 Feb 2012 09:30:51 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id C895121F86B5 for ; Fri, 10 Feb 2012 09:30:51 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 10 Feb 2012 09:30:41 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 10 Feb 2012 09:30:41 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 10 Feb 2012 09:30:39 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-07.txt Thread-Index: Aczn2l0Lipsli/O0R36H9xSTFitQiwAPqz3w Message-ID: References: <5681886.BiAaEpefJ0@scott-latitude-e6320> <1449287.lWhNiLsB7Y@scott-latitude-e6320> <4F34086D.8060609@tana.it> <4F34E9DE.4090007@tana.it> In-Reply-To: <4F34E9DE.4090007@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-as-07.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, 10 Feb 2012 17:30:53 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Friday, February 10, 2012 1:57 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >=20 > > ISP can police his own network without external help, so it's not a > > useful distinction in any case. >=20 > The amount of support that ISPs may want to give to abuse reporting is > unknown at this time. Requiring them to proactively policing abusive > use of domain names in outgoing mail is probably not an option, also > because that might interfere with contractual habits (more than > explicit complaints from third parties.) That's true, but I don't think it's something MARF needs to consider. Thes= e are really operational choices that have nothing to do (directly) with AR= F generation or acceptance. Or am I missing something? > Advice that abuse-mailboxes shouldn't be spam-filtered is spread > throughout several papers. That the domain part of abuse-mailboxes > should not be SPF-protected would be a new, somewhat obscure > requirement, that is not going to improve SPF adoption. If you're proposing a text change about whether or not email addresses that= lead to abuse inboxes SHOULD NOT be spam-filtered, I've lost track of it. = Can you point me to it? -MSK From msk@cloudmark.com Fri Feb 10 09:33:55 2012 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 9C21F21F86C2 for ; Fri, 10 Feb 2012 09:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kq4rKadaHaHl for ; Fri, 10 Feb 2012 09:33:54 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 951A121F8667 for ; Fri, 10 Feb 2012 09:33:54 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 10 Feb 2012 09:33:54 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 10 Feb 2012 09:33:54 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 10 Feb 2012 09:33:53 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-07.txt Thread-Index: Aczn7bD8CQBqksI8SfeyWW5nKsaJjQALEmig Message-ID: References: <5681886.BiAaEpefJ0@scott-latitude-e6320> <1449287.lWhNiLsB7Y@scott-latitude-e6320> <7a340d22-de07-4308-a864-767a3936838e@email.android.com> <1183a5b4-b51a-4056-abff-0b5e73cffe87@email.android.com> In-Reply-To: <1183a5b4-b51a-4056-abff-0b5e73cffe87@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 10 Feb 2012 17:33:55 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Friday, February 10, 2012 4:16 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >=20 > Allesandro provided a scenario that I think is reasonable. If you add: >=20 > (i.e. a message with DKIM pass for the same domain) >=20 > at the end and change "expected to fail" to "not definitive" I think > I'm good. Slightly different, and assuming I got your proposal right: Similarly, if a report generator applies SPF to arriving messages, and that= evaluation produced something other than a "Pass", "None" or "Neutral" res= ult, a report addressed to the RFC5321.MailFrom domain SHOULD NOT be genera= ted as it might be a forgery and thus not actionable. A valid exception wo= uld be specific knowledge that the SPF result is not definitive for that do= main under those circumstances (e.g., a message that is also DKIM-signed by= the same domain, and that signature validates). That work? -MSK From msk@cloudmark.com Fri Feb 10 09:37:08 2012 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 16A7821F8725 for ; Fri, 10 Feb 2012 09:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFOtGBSsWkQb for ; Fri, 10 Feb 2012 09:37:07 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC0721F8721 for ; Fri, 10 Feb 2012 09:37:07 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 10 Feb 2012 09:37:07 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 10 Feb 2012 09:37:07 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 10 Feb 2012 09:37:06 -0800 Thread-Topic: [marf] Reminder: WGLC for draft-ietf-marf-as ends 2/10 Thread-Index: Aczn2zHE2fKN3tyTTz6+5p5ZfI4W5gAP0vjw Message-ID: References: <4F34EB5A.6090103@tana.it> In-Reply-To: <4F34EB5A.6090103@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] Reminder: WGLC for draft-ietf-marf-as ends 2/10 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, 10 Feb 2012 17:37:08 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Friday, February 10, 2012 2:03 AM > To: marf@ietf.org > Subject: Re: [marf] Reminder: WGLC for draft-ietf-marf-as ends 2/10 >=20 > One last nit: both 8.4 and 8.6 talk about where to send reports, moving > 8.5 after 8.6 might improve continuity. Yep, done. Thanks. -MSK From steve@wordtothewise.com Fri Feb 10 09:42:49 2012 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 7D55221F8594 for ; Fri, 10 Feb 2012 09:42:49 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id el5DZ4Hq-YpM for ; Fri, 10 Feb 2012 09:42:48 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 4002421F8567 for ; Fri, 10 Feb 2012 09:42:47 -0800 (PST) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id C3EFE2EB0B for ; Fri, 10 Feb 2012 09:42:46 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Steve Atkins In-Reply-To: Date: Fri, 10 Feb 2012 09:42:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <138CE012-1E87-47F7-B013-1E3E35305E4A@wordtothewise.com> References: <5681886.BiAaEpefJ0@scott-latitude-e6320> <1449287.lWhNiLsB7Y@scott-latitude-e6320> <7a340d22-de07-4308-a864-767a3936838e@email.android.com> <1183a5b4-b51a-4056-abff-0b5e73cffe87@email.android.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1257) Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 10 Feb 2012 17:42:49 -0000 On Feb 10, 2012, at 9:33 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of Scott Kitterman >> Sent: Friday, February 10, 2012 4:16 AM >> To: marf@ietf.org >> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >>=20 >> Allesandro provided a scenario that I think is reasonable. If you = add: >>=20 >> (i.e. a message with DKIM pass for the same domain) >>=20 >> at the end and change "expected to fail" to "not definitive" I think >> I'm good. >=20 > Slightly different, and assuming I got your proposal right: >=20 > Similarly, if a report generator applies SPF to arriving messages, and = that evaluation produced something other than a "Pass", "None" or = "Neutral" result, a report addressed to the RFC5321.Mail=46rom domain = SHOULD NOT be generated as it might be a forgery and thus not = actionable. A valid exception would be specific knowledge that the SPF = result is not definitive for that domain under those circumstances = (e.g., a message that is also DKIM-signed by the same domain, and that = signature validates). >=20 > That work? We're imposing an awful lot of detailed micromanagement on an = application developer that's probably making assumptions about the = heuristics they chose for their app that aren't generally applicable, = and generally discussing detailed implementation decisions about = something we're not developing (and, mostly, have little experience = developing). Can we just say what we'd like the end result to be, and leave it to the = developer to make the choices needed to get there? Cheers, Steve From sklist@kitterman.com Fri Feb 10 10:09:34 2012 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 50F0821F8721 for ; Fri, 10 Feb 2012 10:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pvD8lPaWxRW for ; Fri, 10 Feb 2012 10:09:33 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 932B821F871E for ; Fri, 10 Feb 2012 10:09:33 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1F25720E40D0; Fri, 10 Feb 2012 13:09:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328897373; bh=0ZIm2GK1y8+E1ScV7qV56/W6hrau0fR6a2qNTo52nh4=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=a4rqq5LL9eOvMFs7w0VX1UkXGKO3cNKddz89wQwXHQkjEu8F7eN0JJeetCKzK7G3s wuU8xdeS1P4frKlA/EX5VQeuE1XIAcEkgEmslCPdPpxqkxHZ6GYcIMGSyFy/ovI9C6 TG4XG/u2KW92T2m8XZ2Ztnb+Lw74cN+mefNpQq54= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id F376020E4083; Fri, 10 Feb 2012 13:09:32 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Fri, 10 Feb 2012 13:09:32 -0500 Message-ID: <4961976.nBIT92DZ3y@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <1183a5b4-b51a-4056-abff-0b5e73cffe87@email.android.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 10 Feb 2012 18:09:34 -0000 On Friday, February 10, 2012 09:33:53 AM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Friday, February 10, 2012 4:16 AM > > To: marf@ietf.org > > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt > > > > Allesandro provided a scenario that I think is reasonable. If you add: > > > > (i.e. a message with DKIM pass for the same domain) > > > > at the end and change "expected to fail" to "not definitive" I think > > I'm good. > > Slightly different, and assuming I got your proposal right: > > Similarly, if a report generator applies SPF to arriving messages, and that > evaluation produced something other than a "Pass", "None" or "Neutral" > result, a report addressed to the RFC5321.MailFrom domain SHOULD NOT be > generated as it might be a forgery and thus not actionable. A valid > exception would be specific knowledge that the SPF result is not definitive > for that domain under those circumstances (e.g., a message that is also > DKIM-signed by the same domain, and that signature validates). > > That work? might be a forgery/probably is a forgery e.g./i.e. and I'm happy. Scott K From msk@cloudmark.com Fri Feb 10 10:13:45 2012 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 4072121F879C for ; Fri, 10 Feb 2012 10:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7-7P-U7n-pa for ; Fri, 10 Feb 2012 10:13:44 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8059421F8748 for ; Fri, 10 Feb 2012 10:13:44 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 10 Feb 2012 10:13:44 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 10 Feb 2012 10:13:44 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Fri, 10 Feb 2012 10:13:43 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-07.txt Thread-Index: AczoG2oi33dOVGWqSMiQZituzMTsuwABCXww Message-ID: References: <5681886.BiAaEpefJ0@scott-latitude-e6320> <1449287.lWhNiLsB7Y@scott-latitude-e6320> <7a340d22-de07-4308-a864-767a3936838e@email.android.com> <1183a5b4-b51a-4056-abff-0b5e73cffe87@email.android.com> <138CE012-1E87-47F7-B013-1E3E35305E4A@wordtothewise.com> In-Reply-To: <138CE012-1E87-47F7-B013-1E3E35305E4A@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] I-D Action: draft-ietf-marf-as-07.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, 10 Feb 2012 18:13:45 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= teve Atkins > Sent: Friday, February 10, 2012 9:43 AM > To: Message Abuse Report Format working group > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >=20 > We're imposing an awful lot of detailed micromanagement on an > application developer that's probably making assumptions about the > heuristics they chose for their app that aren't generally applicable, > and generally discussing detailed implementation decisions about > something we're not developing (and, mostly, have little experience > developing). >=20 > Can we just say what we'd like the end result to be, and leave it to > the developer to make the choices needed to get there? You must've expected this: Can you suggest specific changes? I can handle "Strike 8.x", but I'd like some actual text for the "say what = we'd like the end result to be" part. I'll post what we have now in a moment and you can use that to hack away. -MSK From steve@wordtothewise.com Fri Feb 10 10:15:56 2012 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 91D9E21F8748 for ; Fri, 10 Feb 2012 10:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNq6NJtRsPRF for ; Fri, 10 Feb 2012 10:15:55 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id D0FD921F86D6 for ; Fri, 10 Feb 2012 10:15:55 -0800 (PST) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id A68862DDE4 for ; Fri, 10 Feb 2012 10:15:55 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Steve Atkins In-Reply-To: Date: Fri, 10 Feb 2012 10:15:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5681886.BiAaEpefJ0@scott-latitude-e6320> <1449287.lWhNiLsB7Y@scott-latitude-e6320> <7a340d22-de07-4308-a864-767a3936838e@email.android.com> <1183a5b4-b51a-4056-abff-0b5e73cffe87@email.android.com> <138CE012-1E87-47F7-B013-1E3E35305E4A@wordtothewise.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1257) Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 10 Feb 2012 18:15:56 -0000 On Feb 10, 2012, at 10:13 AM, Murray S. Kucherawy wrote: >>=20 >> We're imposing an awful lot of detailed micromanagement on an >> application developer that's probably making assumptions about the >> heuristics they chose for their app that aren't generally applicable, >> and generally discussing detailed implementation decisions about >> something we're not developing (and, mostly, have little experience >> developing). >>=20 >> Can we just say what we'd like the end result to be, and leave it to >> the developer to make the choices needed to get there? >=20 > You must've expected this: >=20 > Can you suggest specific changes? Sure did. I'm already working on them, but I thought I'd give the = general idea a chance to be shot down as well. >=20 > I can handle "Strike 8.x", but I'd like some actual text for the "say = what we'd like the end result to be" part. >=20 > I'll post what we have now in a moment and you can use that to hack = away. Cheers, Steve From internet-drafts@ietf.org Fri Feb 10 10:16:36 2012 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 E15D021F87EA; Fri, 10 Feb 2012 10:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kz1P7lZHFgQC; Fri, 10 Feb 2012 10:16:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0F921F87E5; Fri, 10 Feb 2012 10:16:35 -0800 (PST) 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.64p1 Message-ID: <20120210181635.26298.26668.idtracker@ietfa.amsl.com> Date: Fri, 10 Feb 2012 10:16:35 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-as-08.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, 10 Feb 2012 18:16:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Messaging Abuse Reporting Format Work= ing Group of the IETF. Title : Creation and Use of Email Feedback Reports: An Applicabi= lity Statement for the Abuse Reporting Format (ARF) Author(s) : J.D. Falk M. Kucherawy Filename : draft-ietf-marf-as-08.txt Pages : 14 Date : 2012-02-10 RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This document describes common methods for utilizing this format for reporting both abuse and authentication failure events. Mailbox Providers of any size, mail sending entities, and end users can use these methods as a basis to create procedures that best suit them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-as-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-as-08.txt From msk@cloudmark.com Fri Feb 10 10:22:40 2012 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 3520721F87B8 for ; Fri, 10 Feb 2012 10:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpOpgEsuDVPs for ; Fri, 10 Feb 2012 10:22:39 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id EFD0C21F879F for ; Fri, 10 Feb 2012 10:22:38 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 10 Feb 2012 10:22:38 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 10 Feb 2012 10:22:38 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 10 Feb 2012 10:22:36 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-08.txt Thread-Index: AczoICn8m4aTH47xQqShvUDovmYrzwAACZGw Message-ID: References: <20120210181635.26298.26668.idtracker@ietfa.amsl.com> In-Reply-To: <20120210181635.26298.26668.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-as-08.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, 10 Feb 2012 18:22:40 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org > Sent: Friday, February 10, 2012 10:17 AM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: [marf] I-D Action: draft-ietf-marf-as-08.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Messaging Abuse Reporting > Format Working Group of the IETF. >=20 > Title : Creation and Use of Email Feedback Reports: An > Applicability Statement for the Abuse Reporting Format (ARF) > Author(s) : J.D. Falk > M. Kucherawy > Filename : draft-ietf-marf-as-08.txt > Pages : 14 > Date : 2012-02-10 >=20 > RFC 5965 defines an extensible, machine-readable format intended for > mail operators to report feedback about received email to other > parties. This document describes common methods for utilizing this > format for reporting both abuse and authentication failure events. > Mailbox Providers of any size, mail sending entities, and end users > can use these methods as a basis to create procedures that best suit > them. Numerous changes from various people in the last two days are included in t= his version. I also just now noticed that the table of contents wasn't bei= ng generated, so that's now fixed as well. WGLC closes today, so please do your final reviews and provide comments. -MSK From sklist@kitterman.com Fri Feb 10 10:26:25 2012 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 1781721F880B for ; Fri, 10 Feb 2012 10:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DM+FYMvw58ES for ; Fri, 10 Feb 2012 10:26:24 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E88D521F87FF for ; Fri, 10 Feb 2012 10:26:23 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9C14820E40D0; Fri, 10 Feb 2012 13:26:17 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328898377; bh=qhTOsqDrl3Gby6s8GpjdTglik4fs+VOVXnx+D+/kIgY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=VrcbKVL3PLfCuIzC5RoUsfKbxYAmw5JG9KdIVffm6HQJduFkMOXg1/US+HTOYyTZn PGIsM9O9V8fMsMbScBPTyCmGOK0IqkG7Sf2PGhep5WcJfF3XONn4EnNmHFRETffiYt rfV/CLkiZSckQGAIcQchO+CrS8zUeREtJ2wPFd3o= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 80E6020E4083; Fri, 10 Feb 2012 13:26:17 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Fri, 10 Feb 2012 13:26:16 -0500 Message-ID: <1650118.gzCBRNi4GK@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120210181635.26298.26668.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-as-08.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, 10 Feb 2012 18:26:25 -0000 On Friday, February 10, 2012 10:22:36 AM Murray S. Kucherawy wrote: ... > WGLC closes today, so please do your final reviews and provide comments. For completeness ... My comment against your proposed fix (probably is/i.e.) is still applicable to this version. Scott K From msk@cloudmark.com Fri Feb 10 10:38:14 2012 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 15BD421F87D2 for ; Fri, 10 Feb 2012 10:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxVi-7zLsCO1 for ; Fri, 10 Feb 2012 10:38:13 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF9821F8487 for ; Fri, 10 Feb 2012 10:38:13 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 10 Feb 2012 10:38:13 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 10 Feb 2012 10:38:13 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 10 Feb 2012 10:38:12 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-08.txt Thread-Index: AczoIYDMjOmoFiqoSJuSk3ZdI0pmHwAAWFiw Message-ID: References: <20120210181635.26298.26668.idtracker@ietfa.amsl.com> <1650118.gzCBRNi4GK@scott-latitude-e6320> In-Reply-To: <1650118.gzCBRNi4GK@scott-latitude-e6320> 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-as-08.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, 10 Feb 2012 18:38:14 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Friday, February 10, 2012 10:26 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-08.txt >=20 > My comment against your proposed fix (probably is/i.e.) is still > applicable to this version. 8.6 says "is probably a forgery" and includes at the end "(e.g., a message = that is also DKIM-signed by the same domain, and that signature validates)"= . Was that not it? (e.g. is more correct than i.e., I believe, since there could be other case= s.) -MSK From vesely@tana.it Fri Feb 10 11:26:52 2012 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 3D88021F881B for ; Fri, 10 Feb 2012 11:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.342 X-Spam-Level: X-Spam-Status: No, score=-4.342 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCkpI971DYez for ; Fri, 10 Feb 2012 11:26:51 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2276421F881A for ; Fri, 10 Feb 2012 11:26:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328902009; bh=9d3EnOSow2zMmQu10019gsS9va6aNrTff7D+/qpeTc8=; l=2422; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=aRgxx8SDht8KgimjRl6ZBJ72kC0L+g6rcm/8AJzaQclWXgnusKGfBkRX9MsZ35+x6 UkGigO6bw1YvZ8kw9E8d3DOgVFeF0OIfzx1a00O1gwT8+qaap82/IbAN4PYnvArK4a +LRpBXCN6hNiSR6hPZUbw2wSyc69v57JFqEJ+uTU= 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, 10 Feb 2012 20:26:49 +0100 id 00000000005DC035.000000004F356F79.000011FE Message-ID: <4F356F79.4010104@tana.it> Date: Fri, 10 Feb 2012 20:26:49 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <68d9b554-45bc-4f26-9f52-f06b0a992dcb@email.android.com> <4F3538E5.8080001@tana.it> <11077475.E2zCB0Jdsz@scott-latitude-e6320> In-Reply-To: <11077475.E2zCB0Jdsz@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 10 Feb 2012 19:26:52 -0000 On 10/Feb/12 16:43, Scott Kitterman wrote: > On Friday, February 10, 2012 04:33:57 PM Alessandro Vesely wrote: > ... >>>> That the domain part of abuse-mailboxes should not be >>>> SPF-protected would be a new, somewhat obscure requirement, that >>>> is not going to improve SPF adoption. >>> >>> I don't agree. I don't see such a requirement. >> >> If some leased addresses can get (soft)fail for ISP.example, the ISP >> needs to scan outgoing SMTP transactions --if they are not cyphered-- >> in order to avoid non-reportable cases. Otherwise a bot-master could >> MAIL FROM: from those addresses and get >> away with it. >> >> (And that assuming that ISPs don't publish abuse-mailboxes for the >> sole purpose of keeping admin and technical contacts clear of spam >> complaints.) > ... > > I think you are mixing things together that are separate. Sorry, I thought I depicted the case clearly... > I do think it's up to a network owner (such as an ISP) to police their IP > space. If they don't want mail using their domain name to be sent out of > their network except through their official MTAs, they can prevent that easily > enough. No. ISP.example is a network provider, like softlayer.com leasing 208.43.65.50 to controlledmail.com. MAIL FROM: sent from 208.43.65.50 (mailout03.controlledmail.com) would get a softfail, if I'm not mistaken. Where should it be reported, if abusive? ABUSE1025-ARIN tells abuse@softlayer.com, but one cannot use it as target because of the softfail. > The problem though is it's difficult to reliable separate this case from generic > SPF non-pass conditions, so I don't think we should create a space for an > unreliable solution to a problem that network operators can solve on their own > if they care to. Agreed, but the more difficult the solution, the less likely they'll be to take care. We could say that, given their SPF record, their abuse POC should have been abuse@non-spf-protected.softlayer.com, but... > None of this has any impact on the SPF status of the postmaster inbox. The > message we are discussing here that didn't pass SPF was the original one > believed to be abusive. Yes > That's got no bearing on the SPF status of any report to > postmaster@. That's completely separate. It /was/ completely separated. Since -08 it triggers a SHOULD NOT. From sklist@kitterman.com Fri Feb 10 11:54:26 2012 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 7A0F321F8613 for ; Fri, 10 Feb 2012 11:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTJ1UShS3WWG for ; Fri, 10 Feb 2012 11:54:24 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2159421F8608 for ; Fri, 10 Feb 2012 11:54:23 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 58C0820E40D0; Fri, 10 Feb 2012 14:54:23 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328903663; bh=8My42WZalrY1LCDKD8PeeZS2JYr6hjuIm0bTe/O2IGE=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=DlX5mIF4AJ8PLosrvD9MPQxI0WtPiZrlEXGcknMtG+5TBQ8cgR078z6y3KAq02w3k x9auDNRQ3PZsPNUjENUNrSNAV4o7Dm9d6Q5lvw4ZEt9CzoxWXjn3XjhGWy9wjZ4m5I bIbVwQM/7gP7fO4ciT6DK+SCnKQe0b7hSTnuYjRY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 386A720E4083; Fri, 10 Feb 2012 14:54:23 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Fri, 10 Feb 2012 14:54:22 -0500 Message-ID: <15455772.Z1P6imbDzz@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120210181635.26298.26668.idtracker@ietfa.amsl.com> <1650118.gzCBRNi4GK@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-as-08.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, 10 Feb 2012 19:54:26 -0000 On Friday, February 10, 2012 10:38:12 AM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Friday, February 10, 2012 10:26 AM > > To: marf@ietf.org > > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-08.txt > > > > My comment against your proposed fix (probably is/i.e.) is still > > applicable to this version. > > 8.6 says "is probably a forgery" and includes at the end "(e.g., a message > that is also DKIM-signed by the same domain, and that signature > validates)". Was that not it? Yes. That was it. Sorry for the noise. > (e.g. is more correct than i.e., I believe, since there could be other > cases.) At this point I think it's a fully enumerated list, so I think i.e. is correct. BTW, I think some people have been over-reading what this says. I don't think it says you can't through some heuristic pick a certain email address to report abuse to. I hope it says you can't pick that address to report abuse to in this case because it's the mail from address. In that context, I'm really lacking ideas on what might go in this list. Scott K From sklist@kitterman.com Fri Feb 10 11:59:57 2012 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 A18D621F8857 for ; Fri, 10 Feb 2012 11:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oWGApUaj6vM for ; Fri, 10 Feb 2012 11:59:56 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C6D9021F8818 for ; Fri, 10 Feb 2012 11:59:55 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5E9AA20E40D0; Fri, 10 Feb 2012 14:59:55 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1328903995; bh=43fAnFPDNU7rRjdD6RhlUrPB8jHJx+TUVHCmKhxPx+I=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=lZ5f2wQi2LfeOH9pwl5RpkAH/ppLdpu/Pc/54p/zr12DO1+p2AGr3R3tbqZjR8FMc RSkS+qT2zv/LUEMewCyn5HeiFc27ObaTK4IFcwPdl9q5aGgGBCS1OkuVz8o5jJLv5t SQ970K0Q+CiPCP/Y21Nzkp5D6f2bewyOB6dsYXl0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3F18620E4083; Fri, 10 Feb 2012 14:59:55 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Fri, 10 Feb 2012 14:59:54 -0500 Message-ID: <4523485.9DVovjFMqb@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F356F79.4010104@tana.it> References: <11077475.E2zCB0Jdsz@scott-latitude-e6320> <4F356F79.4010104@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 10 Feb 2012 19:59:57 -0000 On Friday, February 10, 2012 08:26:49 PM Alessandro Vesely wrote: > On 10/Feb/12 16:43, Scott Kitterman wrote: > > On Friday, February 10, 2012 04:33:57 PM Alessandro Vesely wrote: > > ... > > > >>>> That the domain part of abuse-mailboxes should not be > >>>> SPF-protected would be a new, somewhat obscure requirement, that > >>>> is not going to improve SPF adoption. > >>> > >>> I don't agree. I don't see such a requirement. > >> > >> If some leased addresses can get (soft)fail for ISP.example, the ISP > >> needs to scan outgoing SMTP transactions --if they are not cyphered-- > >> in order to avoid non-reportable cases. Otherwise a bot-master could > >> MAIL FROM: from those addresses and get > >> away with it. > >> > >> (And that assuming that ISPs don't publish abuse-mailboxes for the > >> sole purpose of keeping admin and technical contacts clear of spam > >> complaints.) > > > > ... > > > > I think you are mixing things together that are separate. > > Sorry, I thought I depicted the case clearly... > > > I do think it's up to a network owner (such as an ISP) to police their > > IP > > space. If they don't want mail using their domain name to be sent out > > of > > their network except through their official MTAs, they can prevent that > > easily enough. > > No. ISP.example is a network provider, like softlayer.com leasing > 208.43.65.50 to controlledmail.com. MAIL FROM: > sent from 208.43.65.50 (mailout03.controlledmail.com) would get a > softfail, if I'm not mistaken. Where should it be reported, if > abusive? ABUSE1025-ARIN tells abuse@softlayer.com, but one cannot use > it as target because of the softfail. I think I haven't been clear (and maybe the text needs more work), but this is reasonable. Where I would object is if you wanted to send the report to abuse@softlayer.com because they were used in mail from. > > The problem though is it's difficult to reliable separate this case from > > generic SPF non-pass conditions, so I don't think we should create a > > space for an unreliable solution to a problem that network operators > > can solve on their own if they care to. > > Agreed, but the more difficult the solution, the less likely they'll > be to take care. We could say that, given their SPF record, their > abuse POC should have been abuse@non-spf-protected.softlayer.com, but... This is where I think you've confused things. The relevant SPF check here would be on the domain you are sending the report from. It's got nothing to do with their SPF record or status of messages sent mail from their domain. > > None of this has any impact on the SPF status of the postmaster inbox. > > The message we are discussing here that didn't pass SPF was the > > original one believed to be abusive. > > Yes > > > That's got no bearing on the SPF status of any report to > > postmaster@. That's completely separate. > > It /was/ completely separated. Since -08 it triggers a SHOULD NOT. No it doesn't. Even if it does, it's got nothing to do with if SPF not-pass messages are accepted by their postmaster. Scott K From vesely@tana.it Sat Feb 11 01:30:55 2012 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 3A05A21F8532 for ; Sat, 11 Feb 2012 01:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.04 X-Spam-Level: X-Spam-Status: No, score=-4.04 tagged_above=-999 required=5 tests=[AWL=-0.521, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKQ8ayf74f7e for ; Sat, 11 Feb 2012 01:30:54 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id F32A621F8540 for ; Sat, 11 Feb 2012 01:30:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1328952651; bh=TbVCBHZOzpxTl8UFwbjoe3nTgVgz1Mg43MTyts+HEzA=; l=1562; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=liKxahTmoqOj5iii33pztAkZMiUELwMp16PbE1aMCVtGAHPogwZreK8vI22f4Jgix Jj4+x5OmagLylCk9UPfJRws26lvXCb4JLDt6RIkiJs2ipUhXaSxg3wjT5r5MAnD48L C5RCHNZFgpYgaNQMQWbu6hdOLQLoY3tQrLzTKQLg= 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, 11 Feb 2012 10:30:51 +0100 id 00000000005DC039.000000004F36354B.0000512A Message-ID: <4F36354B.1050109@tana.it> Date: Sat, 11 Feb 2012 10:30:51 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <11077475.E2zCB0Jdsz@scott-latitude-e6320> <4F356F79.4010104@tana.it> <4523485.9DVovjFMqb@scott-latitude-e6320> In-Reply-To: <4523485.9DVovjFMqb@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 09:30:55 -0000 On 10/Feb/12 20:59, Scott Kitterman wrote: > On Friday, February 10, 2012 08:26:49 PM Alessandro Vesely wrote: > >> ISP.example is a network provider, like softlayer.com leasing >> 208.43.65.50 to controlledmail.com. MAIL FROM: >> sent from 208.43.65.50 (mailout03.controlledmail.com) would get a >> softfail, if I'm not mistaken. Where should it be reported, if >> abusive? ABUSE1025-ARIN tells abuse@softlayer.com, but one cannot use >> it as target because of the softfail. > > I think I haven't been clear (and maybe the text needs more work), > but this is reasonable. Where I would object is if you wanted to > send the report to abuse@softlayer.com because they were used in > mail from. Yes, the current wording can be interpreted badly. 8.5 says report generators can derive an address from RFC5321.MailFrom if they have spf=pass. 8.6 says they can do so even with none or neutral. >> We could say that, given their SPF record, their abuse POC should >> have been abuse@non-spf-protected.softlayer.com, but... > > This is where I think you've confused things. The relevant SPF > check here would be on the domain you are sending the report from. > It's got nothing to do with their SPF record or status of messages > sent mail from their domain. The subdomain would be needed to allow report generators to use that address even if its domain-part is the same of the RFC5321.MailFrom. Non-spf-protected.softlayer.com must result in spf=none, in the original message, hence can be used to report it. From barryleiba.mailing.lists@gmail.com Sat Feb 11 14:06:09 2012 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 0099721F852B for ; Sat, 11 Feb 2012 14:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.955 X-Spam-Level: X-Spam-Status: No, score=-102.955 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9gIPTe735Vz for ; Sat, 11 Feb 2012 14:06:08 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD9821F852C for ; Sat, 11 Feb 2012 14:06:08 -0800 (PST) Received: by yenm3 with SMTP id m3so2264458yen.31 for ; Sat, 11 Feb 2012 14:06:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=pH1/ZE+lZNoSun757V5/7tGdKGveY0ndaBjSb8irZd0=; b=ggg8zyXf43oTn214T3nFEmwcvRKZG+3WJSXp1Oxx3k1T5iXW9fLuD2ZBpHb8B70JUa qW8gYU0/plB3ZSoiIRnAsCTQXrvjVdCWKBvLR+hlcSugH7DYWCsWLDnBxPJNeOos0xPu +KfK6mZQ3B6TwS7zj6NUU0fRRUKWC2pVNVpmI= MIME-Version: 1.0 Received: by 10.236.133.210 with SMTP id q58mr14855481yhi.6.1328997967897; Sat, 11 Feb 2012 14:06:07 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Sat, 11 Feb 2012 14:06:07 -0800 (PST) Date: Sat, 11 Feb 2012 17:06:07 -0500 X-Google-Sender-Auth: B-c9RG8hMgDBheycnOpDvVZSeoI Message-ID: From: Barry Leiba To: Message Abuse Report Format working group Content-Type: multipart/alternative; boundary=20cf30363723c8a3db04b8b77368 Subject: [marf] Important verification on IPR status 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, 11 Feb 2012 22:06:09 -0000 --20cf30363723c8a3db04b8b77368 Content-Type: text/plain; charset=ISO-8859-1 While we're finishing up working-group last call on the three documents, I will make a request that comes from some discussion within the IESG and with the working group chairs: If any participant, including the document editors, is aware of any intellectual property claims that apply to any of the MARF documents that are in final processing[1], please notify the mailing list by 24 Feb, and arrange for a formal IPR statement as soon as practicable. This applies to any patents or patent applications that you know about, including those that may not yet be published. Remember that your participation in the IETF is contingent upon your making such disclosures; see http://www.ietf.org/about/note-well.html or ask the chairs for more information. Barry, as chair [1] draft-ietf-marf-as, draft-ietf-marf-dkim-reporting, draft-ietf-marf-spf-reporting, draft-ietf-marf-redaction --20cf30363723c8a3db04b8b77368 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable While we're finishing up working-group last call on the three documents= , I will make a request that comes from some discussion within the IESG and= with the working group chairs:

If any participant, including the do= cument editors, is aware of any intellectual property claims that apply to = any of the MARF documents that are in final processing[1], please notify th= e mailing list by 24 Feb, and arrange for a formal IPR statement as soon as= practicable. =A0This applies to any patents or patent applications that yo= u know about, including those that may not yet be published. =A0Remember th= at your participation in the IETF is contingent upon your making such discl= osures; see http://www= .ietf.org/about/note-well.html or ask the chairs for more information.<= br>
Barry, as chair

[1] draft-ietf-marf-as, draft-ietf-marf-dkim-rep= orting, draft-ietf-marf-spf-reporting, draft-ietf-marf-redaction
--20cf30363723c8a3db04b8b77368-- From shmuel+gen@patriot.net Sat Feb 11 16:39:59 2012 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 E884621F857D for ; Sat, 11 Feb 2012 16:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNIrmakE1219 for ; Sat, 11 Feb 2012 16:39:58 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4AC21F8565 for ; Sat, 11 Feb 2012 16:39:57 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.38]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 12805F580B2 for ; Sat, 11 Feb 2012 19:25:16 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Sat, 11 Feb 2012 19:38:56 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120212002517.12805F580B2@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt 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, 12 Feb 2012 00:40:00 -0000 In , on 02/10/2012 at 09:21 AM, "Murray S. Kucherawy" said: >S/MIME and PGP also allow you to sign the From: field of a message, >but they make no statement about whether what got signed is true or >not. By "authenticate" and "sign" I was refering to authentication of permission, not to authenticating that the message had not been altered. >I can't conceive of an Internet-based technology that can confirm >intent or legitimacy of the signer/author/whatever. How about a public key in a TXT RR? -- 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 Sat Feb 11 16:56:36 2012 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 1FD6C21F85A2 for ; Sat, 11 Feb 2012 16:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAOtpF7f+lKF for ; Sat, 11 Feb 2012 16:56:34 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 74D2121F85A1 for ; Sat, 11 Feb 2012 16:56:34 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.38]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 6274EF580B2 for ; Sat, 11 Feb 2012 19:41:55 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Sat, 11 Feb 2012 19:54:29 -0500 To: marf@ietf.org In-Reply-To: <4961976.nBIT92DZ3y@scott-latitude-e6320> Mail-Copies-To: nobody 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: <20120212004155.6274EF580B2@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt 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, 12 Feb 2012 00:56:36 -0000 In <4961976.nBIT92DZ3y@scott-latitude-e6320>, on 02/10/2012 at 01:09 PM, Scott Kitterman said: >e.g./i.e. e.g. is correct; it's an example, not an explanation. -- 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 johnl@iecc.com Sat Feb 11 17:28:46 2012 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 3FEB021F8555 for ; Sat, 11 Feb 2012 17:28:46 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CauYPK4pxGW for ; Sat, 11 Feb 2012 17:28:45 -0800 (PST) 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 9FE3221F84FB for ; Sat, 11 Feb 2012 17:28:45 -0800 (PST) Received: (qmail 83321 invoked from network); 12 Feb 2012 01:28:41 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Feb 2012 01:28:41 -0000 Date: 12 Feb 2012 01:28:19 -0000 Message-ID: <20120212012819.27950.qmail@joyce.lan> From: "Bank Security" To: marf@ietf.org In-Reply-To: <20120212002517.12805F580B2@smtp.patriot.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] meaning of signatures, was I-D Action: draft-ietf-marf-as-07.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, 12 Feb 2012 01:28:46 -0000 >>I can't conceive of an Internet-based technology that can confirm >>intent or legitimacy of the signer/author/whatever. > >How about a public key in a TXT RR? OK, what's the intent and legitimacy of this message? The DKIM signature should be 100% valid. R's, John From sklist@kitterman.com Sat Feb 11 19:03:57 2012 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 A2E9421F84BD for ; Sat, 11 Feb 2012 19:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Wd8z4j1pRrv for ; Sat, 11 Feb 2012 19:03:56 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id BC15621F84C9 for ; Sat, 11 Feb 2012 19:03:56 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id A4F71D0407F; Sat, 11 Feb 2012 21:03:55 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329015835; bh=TSbyweNaMhGO2yVrXeX3+bZ3nFsrJmW9Rk4biw/ZRDc=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=ASg7P9oKYivm+Mxp6Y1K5GB1z5pQ4aib5BO9+d/LbClGqjW0byJnadc89oB6go1su ZJ6Wk7dvpgPyAtBljRAsHswl3SCbJU3l6K4JyBoH6VCX7AOzioE5QFQbt40+ZRz5qK JTiIi8EmF6uidyVMiZZ4hWAIAZhgGzbstR0LTPhs= Received: from 75.sub-97-1-91.myvzw.com (75.sub-97-1-91.myvzw.com [97.1.91.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 5F51DD04056; Sat, 11 Feb 2012 21:03:53 -0600 (CST) References: <20120212004155.6274EF580B2@smtp.patriot.net> User-Agent: K-9 Mail for Android In-Reply-To: <20120212004155.6274EF580B2@smtp.patriot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sat, 11 Feb 2012 22:03:58 -0500 To: Message Abuse Report Format working group Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 12 Feb 2012 03:03:57 -0000 Shmuel Metz wrote: >In <4961976.nBIT92DZ3y@scott-latitude-e6320>, on 02/10/2012 > at 01:09 PM, Scott Kitterman said: > >>e.g./i.e. > >e.g. is correct; it's an example, not an explanation. I think it's a complete list. What would you add to make it complete? Scott K From shmuel+gen@patriot.net Sun Feb 12 08:11:19 2012 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 8F5D921F878A for ; Sun, 12 Feb 2012 08:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHAl8oYbwbK6 for ; Sun, 12 Feb 2012 08:11:18 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id C2C8121F8789 for ; Sun, 12 Feb 2012 08:11:18 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.47]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 0C179F58095 for ; Sun, 12 Feb 2012 10:56:37 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Sun, 12 Feb 2012 11:11:29 -0500 To: Message Abuse Report Format working group In-Reply-To: <20120212012819.27950.qmail@joyce.lan> Mail-Copies-To: nobody 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: <20120212155638.0C179F58095@smtp.patriot.net> Subject: Re: [marf] meaning of signatures, was I-D Action: draft-ietf-marf-as-07.txt 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, 12 Feb 2012 16:11:19 -0000 In <20120212012819.27950.qmail@joyce.lan>, on 02/12/2012 at 01:28 AM, "Bank Security" said: >To: marf@ietf.org >Cc: shmuel+mail-abuse-feedback-report@patriot.net Please don't do that; one copy is sufficient. >>>I can't conceive of an Internet-based technology that can confirm >>>intent or legitimacy of the signer/author/whatever. >> >>How about a public key in a TXT RR? >OK, what's the intent and legitimacy of this message? How is that relevant? The only TXT RR for banqofamerika.com is the SPF RR. What I was saying was that a technolgy was feasible whereby, e.g., the Return-Path, the From address, was encrypted with a private key and the public key was available in a TXT[1] RR. [1] A different type of RR would work as well. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From barryleiba.mailing.lists@gmail.com Sun Feb 12 08:16:08 2012 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 46D7921F8740 for ; Sun, 12 Feb 2012 08:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBPg+8aQKcZQ for ; Sun, 12 Feb 2012 08:16:07 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A5EFB21F8749 for ; Sun, 12 Feb 2012 08:16:07 -0800 (PST) Received: by yenm3 with SMTP id m3so2394261yen.31 for ; Sun, 12 Feb 2012 08:16:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=dEZJ7DIKBXSuSjOse0AIBkaU9RMqyiBgTS2Gu/Jut9U=; b=nobrH+8lsGBZOm1cu2PX5NRacdmajTYDt0a23Nm0WN70fGT/sGalkjccL+F3yoptAx 54G5CIukNQzEIquLUkyz1D06BaYMMXhglK8iBALjuIO+ZRkafZGInIstimRFu/lkUfEr UnapNbePTfOAd3vnJn5SVzZTlrJKT1dTEmTAo= MIME-Version: 1.0 Received: by 10.236.124.66 with SMTP id w42mr16566675yhh.23.1329063367280; Sun, 12 Feb 2012 08:16:07 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Sun, 12 Feb 2012 08:16:07 -0800 (PST) In-Reply-To: References: <20120212004155.6274EF580B2@smtp.patriot.net> Date: Sun, 12 Feb 2012 11:16:07 -0500 X-Google-Sender-Auth: Ccou0HV6fFDFIgslkV3nmSc_JIk Message-ID: From: Barry Leiba To: Scott Kitterman Content-Type: multipart/alternative; boundary=20cf300e5625e406d204b8c6ad4b Cc: Message Abuse Report Format working group Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 12 Feb 2012 16:16:08 -0000 --20cf300e5625e406d204b8c6ad4b Content-Type: text/plain; charset=ISO-8859-1 > I think it's a complete list. What would you add to make it complete? 1. Opinion: We can't predict the future, or what situations others may find themselves in, so it's a bad idea to make an absolute pronouncement here. 2. Chair evaluation: You are in the rough on this one; you are the only one who wants this to be written as an exhaustive list. Let's move on. 3. Because many people don't properly use or understand the distinction between "i.e." and "e.g.", I think it's better (and easy enough) to avoid them. Murray, please consider changing to "for example", "such as", or some similar English replacement. Barry, chair-ish --20cf300e5625e406d204b8c6ad4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > I think it's a complete list. What would you add to make it comple= te?

1. Opinion: We can't predict the future, or what situations = others may find themselves in, so it's a bad idea to make an absolute p= ronouncement here.

2. Chair evaluation: You are in the rough on this one; you are the only= one who wants this to be written as an exhaustive list. =A0Let's move = on.

3. Because many people don't properly use or understand the = distinction between "i.e." and "e.g.", I think it's= better (and easy enough) to avoid them. =A0Murray, please consider changin= g to "for example", "such as", or some similar English = replacement.

Barry, chair-ish --20cf300e5625e406d204b8c6ad4b-- From sklist@kitterman.com Sun Feb 12 08:39:39 2012 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 3109321F879B for ; Sun, 12 Feb 2012 08:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3hsn8UIdex9 for ; Sun, 12 Feb 2012 08:39:38 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 80E2B21F8796 for ; Sun, 12 Feb 2012 08:39:38 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 889C320E40BB; Sun, 12 Feb 2012 11:39:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329064777; bh=C/XJekCYvBGUDFAR2J1NYkE9b0+bDKdCubZLd/MNX3Q=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=iXRWdb/bCWWM3BhPe7FJEALgMZCQAKglzflOgFJLhY6vfmAHyy/S0OMMS10D0WPiJ BTd075GBVhQFCLRGH0zdpDt/+ZVwom6RIITbUc3E2bJ3I6dBuqjOqpyI/NCE5TC/Wl vT2VN1UPEOs2i0v/niTmoEAIopz5B7O5v7RFYztQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 687B220E4093; Sun, 12 Feb 2012 11:39:37 -0500 (EST) From: Scott Kitterman To: Message Abuse Report Format working group Date: Sun, 12 Feb 2012 11:39:36 -0500 Message-ID: <1631294.6ZISkRYib7@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120212004155.6274EF580B2@smtp.patriot.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 12 Feb 2012 16:39:39 -0000 On Sunday, February 12, 2012 11:16:07 AM Barry Leiba wrote: > 2. Chair evaluation: You are in the rough on this one; you are the only one > who wants this to be written as an exhaustive list. Let's move on. Fair enough. Moving on ... Scott K From msk@cloudmark.com Sun Feb 12 08:45:49 2012 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 CE31221F87A8 for ; Sun, 12 Feb 2012 08:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0JTUBvHbbY7 for ; Sun, 12 Feb 2012 08:45:49 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id B0C1821F87A4 for ; Sun, 12 Feb 2012 08:45:42 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 12 Feb 2012 08:45:42 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sun, 12 Feb 2012 08:45:42 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Sun, 12 Feb 2012 08:45:40 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-07.txt Thread-Index: AczpoaKEteNvupksTW6FXjfnjqU/yAABBBdw Message-ID: References: <20120212004155.6274EF580B2@smtp.patriot.net> 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_F5833273385BB34F99288B3648C4F06F19C9A7DD0BEXCHC2corpclo_" MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.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, 12 Feb 2012 16:45:50 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DD0BEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Done. (If I could figure out how to make Outlook not top-post, I would; ap= ologies.) From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Bar= ry Leiba Sent: Sunday, February 12, 2012 8:16 AM To: Scott Kitterman Cc: Message Abuse Report Format working group Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt > I think it's a complete list. What would you add to make it complete? 1. Opinion: We can't predict the future, or what situations others may find= themselves in, so it's a bad idea to make an absolute pronouncement here. 2. Chair evaluation: You are in the rough on this one; you are the only one= who wants this to be written as an exhaustive list. Let's move on. 3. Because many people don't properly use or understand the distinction bet= ween "i.e." and "e.g.", I think it's better (and easy enough) to avoid them= . Murray, please consider changing to "for example", "such as", or some si= milar English replacement. Barry, chair-ish --_000_F5833273385BB34F99288B3648C4F06F19C9A7DD0BEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Done.&nbs= p; (If I could figure out how to make Outlook not top-post, I would; apolog= ies.)

 

From: marf-bounces@ietf.org= [mailto:marf-bounces@ietf.org] On Behalf Of Barry Leiba
Sent:= Sunday, February 12, 2012 8:16 AM
To: Scott Kitterman
= Cc: Message Abuse Report Format working group
Subject: Re: [m= arf] I-D Action: draft-ietf-marf-as-07.txt

 

> I thin= k it's a complete list. What would you add to make it complete?

1. O= pinion: We can't predict the future, or what situations others may find the= mselves in, so it's a bad idea to make an absolute pronouncement here.
<= br>2. Chair evaluation: You are in the rough on this one; you are the only = one who wants this to be written as an exhaustive list.  Let's move on= .

3. Because many people don't properly use or understand the distin= ction between "i.e." and "e.g.", I think it's better (a= nd easy enough) to avoid them.  Murray, please consider changing to &q= uot;for example", "such as", or some similar English replace= ment.

Barry, chair-ish

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DD0BEXCHC2corpclo_-- From msk@cloudmark.com Sun Feb 12 08:53:30 2012 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 AD5B621F8753 for ; Sun, 12 Feb 2012 08:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-Y5SnT8adMd for ; Sun, 12 Feb 2012 08:53:30 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1916F21F8750 for ; Sun, 12 Feb 2012 08:53:30 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 12 Feb 2012 08:53:25 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sun, 12 Feb 2012 08:53:25 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Sun, 12 Feb 2012 08:53:24 -0800 Thread-Topic: [marf] meaning of signatures, was I-D Action: draft-ietf-marf-as-07.txt Thread-Index: AczpoPdBtzKQVJBeRnSuiFBp1ETkJgABZOhg Message-ID: References: <20120212012819.27950.qmail@joyce.lan> <20120212155638.0C179F58095@smtp.patriot.net> In-Reply-To: <20120212155638.0C179F58095@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] meaning of signatures, was I-D Action: draft-ietf-marf-as-07.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, 12 Feb 2012 16:53:30 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Sunday, February 12, 2012 8:11 AM > To: Message Abuse Report Format working group > Subject: Re: [marf] meaning of signatures, was I-D Action: draft-ietf- > marf-as-07.txt >=20 > >>>I can't conceive of an Internet-based technology that can confirm > >>>intent or legitimacy of the signer/author/whatever. > >> > >>How about a public key in a TXT RR? > >OK, what's the intent and legitimacy of this message? >=20 > How is that relevant? Despite DKIM passing on a message for any given domain, you don't know whet= her or not that domain name represents the entity claimed in the message he= ader or body. The legitimacy, therefore, cannot be established even by cry= ptographic means. > The only TXT RR for banqofamerika.com is the SPF > RR. What I was saying was that a technolgy was feasible whereby, e.g., > the Return-Path, the From address, was encrypted with a private key and > the public key was available in a TXT[1] RR. Doing so would also tell you nothing about the legitimacy of the content. In any case, if we were to speculate on any possible future authentication = technology, this document will suffer more bloat than it already has. -MSK From johnl@iecc.com Sun Feb 12 10:03:32 2012 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 A891721F871C for ; Sun, 12 Feb 2012 10:03:32 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLPCywpdC6NG for ; Sun, 12 Feb 2012 10:03:32 -0800 (PST) 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 C4F8621F8636 for ; Sun, 12 Feb 2012 10:03:31 -0800 (PST) Received: (qmail 48675 invoked from network); 12 Feb 2012 18:03:21 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Feb 2012 18:03:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f37fee9.xn--3zv.k1202; i=johnl@user.iecc.com; bh=GR2vvzo1bqSraXtMlRdOjlspeigHln64BEwBM/MbYhc=; b=lD6WPTefXRbyJmgqVh1DzrAi0+yttD6ZOeKJ3UAM0HL9kV2uSAHD4ft/UA0EunWBP4MRkPD6NgAMYow7LF6IMJk4VLy0x/ZdZcqS51Rmmv1mV8SYwFMk/0YMGunjrdTAd/GanMNPzSCZnN591YpW58qIR4GNV8Puwz/BTmB8NOs= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=banqofamerika.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f37fee9.xn--3zv.k1202; olt=johnl@user.iecc.com; bh=GR2vvzo1bqSraXtMlRdOjlspeigHln64BEwBM/MbYhc=; b=hIVTjUqJsXgacefmXRJHSagSNnCMMxXKQkSuWS/Wk5WnAAgHmjRq4o6OK0D7+Ppqg5+3f451CvjfPxmJMi3Sa7wOwK99rhgJEAJ/zZze7vKW6Nh2qOnqqBG7QnKiJODgCOJg/qRZfL7jD41SFhoxF8dTyBgdxQItzmQhnK6RFUo= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 12 Feb 2012 18:02:58 -0000 Message-ID: <20120212180258.22242.qmail@joyce.lan> From: "Bank Security" To: marf@ietf.org In-Reply-To: <20120212155638.0C179F58095@smtp.patriot.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] meaning of signatures, was I-D Action: draft-ietf-marf-as-07.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, 12 Feb 2012 18:03:32 -0000 >>To: marf@ietf.org >>Cc: shmuel+mail-abuse-feedback-report@patriot.net > >Please don't do that; one copy is sufficient. Sigh. >>OK, what's the intent and legitimacy of this message? > >How is that relevant? The only TXT RR for banqofamerika.com is the SPF >RR. Sigh++. If you'd looked at the message you were complaining about, you'd have seen a valid DKIM signature with d=banqofamerika.com. You can't tell whether that's a phish or a joke without external knowledge about the domain. As Murray says, speculation about the design of reputation systems or of other kinds of authentication are utterly out of scope here. R's, John PS: Any replies to this message MUST be sent to both the list and me. If you do anything else, that's so wrong as to be unworthy even of discussion. From shmuel+gen@patriot.net Sun Feb 12 11:55:28 2012 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 5CC1521F8616 for ; Sun, 12 Feb 2012 11:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZyTUEOMAlih for ; Sun, 12 Feb 2012 11:55:27 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id BAF3621F8615 for ; Sun, 12 Feb 2012 11:55:27 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.150]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 03FB9F58093 for ; Sun, 12 Feb 2012 14:40:46 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Sun, 12 Feb 2012 11:51:32 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120212194047.03FB9F58093@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt 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, 12 Feb 2012 19:55:28 -0000 In , on 02/11/2012 at 10:03 PM, Scott Kitterman said: >I think it's a complete list. At the moment. Will it remain a complete list for the life of the RFC? If not, then it should be "e.g.,". -- 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 Feb 12 12:16:55 2012 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 C58A121F8659 for ; Sun, 12 Feb 2012 12:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1FMev2EeVEX for ; Sun, 12 Feb 2012 12:16:54 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1775C21F85E6 for ; Sun, 12 Feb 2012 12:16:54 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.150]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 9FA67F58093 for ; Sun, 12 Feb 2012 15:01:40 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Sun, 12 Feb 2012 15:15:41 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120212200148.9FA67F58093@smtp.patriot.net> Subject: Re: [marf] meaning of signatures, was I-D Action: draft-ietf-marf-as-07.txt 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, 12 Feb 2012 20:16:55 -0000 In , on 02/12/2012 at 08:53 AM, "Murray S. Kucherawy" said: >Despite DKIM passing on a message for any given domain, you don't >know whether or not that domain name represents the entity claimed in >the message header or body. How is DKIM relevant to potential future standards? The statement was "I can't conceive of an Internet-based technology that can confirm intent or legitimacy of the signer/author/whatever.", not "I can't conceive of a DKIM-based technology that can confirm intent or legitimacy of the signer/author/whatever." >In any case, if we were to speculate on any possible future >authentication technology, this document will suffer more bloat than >it already has. I was suggesting that we shorten it rather than lengthen it, by making a general statement rather than listing specific technologies. -- 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 Feb 12 12:25:33 2012 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 9646221F864E for ; Sun, 12 Feb 2012 12:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDghBCsL5Svf for ; Sun, 12 Feb 2012 12:25:32 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id D483E21F8533 for ; Sun, 12 Feb 2012 12:25:32 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.105]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id DE60AF58093; Sun, 12 Feb 2012 15:10:50 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Sun, 12 Feb 2012 15:24:30 -0500 To: marf@ietf.org In-Reply-To: <20120212180258.22242.qmail@joyce.lan> Mail-Copies-To: nobody 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: <20120212201050.DE60AF58093@smtp.patriot.net> Cc: Bank Security Subject: Re: [marf] meaning of signatures, was I-D Action: draft-ietf-marf-as-07.txt 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, 12 Feb 2012 20:25:33 -0000 In <20120212180258.22242.qmail@joyce.lan>, on 02/12/2012 at 06:02 PM, "Bank Security" said: >Sigh++. If you'd looked at the message you were complaining about, >you'd have seen a valid DKIM signature with d=banqofamerika.com. Indeed, but neither DKIM nor SPF is relevant. >You can't tell whether that's a phish or a joke That's because DKIM doesn't provide for the functionality, not because it can't be done. >without external knowledge about the domain. A TXT RR containing a public key would be external knowledge of the domain. >As Murray says, speculation about the design of reputation systems >or of other kinds of authentication are utterly out of scope here. Then we should be neutral with regard to future technology, not preclude it. >PS: Any replies to this message MUST be sent to both the list and >me. Then why isn't there a ReplyTo header field? -- 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 security@banqofamerika.com Sun Feb 12 12:54:06 2012 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 1E31E21F867E for ; Sun, 12 Feb 2012 12:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piytwdE-RvFb for ; Sun, 12 Feb 2012 12:54:05 -0800 (PST) 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 E865A21F8642 for ; Sun, 12 Feb 2012 12:54:04 -0800 (PST) Received: (qmail 12148 invoked from network); 12 Feb 2012 20:54:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=2f73.4f3826ea.k1202; bh=uvbBsQcK0l3wVOR4SHuTHeQF1GKaRDgyTKHsuNhAKaA=; b=T/tgyCTWQPmUPtvTHS2kdU24ttbLfjYq3qjf3DATCXCzta081Tmq7Yx0Lqv2VFmpapyJoYwG05c1y4tpwC65PvL3n0XQkhiTUg3v8MtOs6owT2vp3kw8/okgPXCCliFjGKAL8Q2bV2isvE1J3bdoapcJXw4XVXqd4fGHn4WVF6s= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=banqofamerika.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=2f73.4f3826ea.k1202; bh=uvbBsQcK0l3wVOR4SHuTHeQF1GKaRDgyTKHsuNhAKaA=; b=bZ8q4HCY2Z5boQM4OibnWyH9XZ5a/XsVOKtYM//ZOpHOtcveE72ETzK+Ch3PE3v/yTB1hJChb1Q3/4bLXLSuBJGL/fnKz+yWN6Ol20OQKlhWWtSTdB8rpF0S8da5CLfBRMVIANmQ3vnlwsO8Qc7r34IYiGPoOei6xIZWQ9tiMK8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Feb 2012 20:53:40 -0000 Date: 12 Feb 2012 15:54:01 -0500 Message-ID: From: "BANK SECURITY" To: "ARF mailing list" In-Reply-To: <20120212201050.DE60AF58093@smtp.patriot.net> References: <20120212201050.DE60AF58093@smtp.patriot.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [marf] meaning of signatures, was I-D Action: draft-ietf-marf-as-07.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, 12 Feb 2012 20:54:06 -0000 > A TXT RR containing a public key would be external knowledge of the > domain. Sorry, that makes no sense at all. Every DKIM verification record is a TXT record containing a public key. The basic fact is that there is nothing I can say to improve my reputation unless it's confirmed by someone that the reputation user finds credible. So I can publish text records to prove that something is from me, but not to prove that I'm nice. R's, John From msk@cloudmark.com Sun Feb 12 19:42:07 2012 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 78B9621F8725 for ; Sun, 12 Feb 2012 19:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yU5jF+B8XAa for ; Sun, 12 Feb 2012 19:42:06 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 81FA921F871C for ; Sun, 12 Feb 2012 19:42:06 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 12 Feb 2012 19:42:05 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sun, 12 Feb 2012 19:42:06 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Sun, 12 Feb 2012 19:42:05 -0800 Thread-Topic: Simplifying draft-ietf-marf-as Thread-Index: AczqAXRw74XZMyZPQ6+xgUy0N46qgg== 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_F5833273385BB34F99288B3648C4F06F19C9A7DD1AEXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] Simplifying draft-ietf-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: Mon, 13 Feb 2012 03:42:07 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DD1AEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, A last-minute rewrite of a couple of sections of draft-ietf-marf-as was sub= mitted. The feeling is that Sections 7 and 8 (especially the latter) had b= ecome too verbose and confusing, and had the feel of micromanagement. The = proposed text is rather more general while still attempting to put the work= ing group's main message into the hands of feedback operators. The diff is here: http://www.blackops.org/~msk/marf-as.html Please review it and comment as soon as possible. This is our last batch o= f work before Barry can write up his shepherding document and move it along= to the IESG. Thanks, -MSK --_000_F5833273385BB34F99288B3648C4F06F19C9A7DD1AEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

A last= -minute rewrite of a couple of sections of draft-ietf-marf-as was submitted= .  The feeling is that Sections 7 and 8 (especially the latter) had be= come too verbose and confusing, and had the feel of micromanagement.  = The proposed text is rather more general while still attempting to put the = working group’s main message into the hands of feedback operators.


The diff is here: http://www.blackops.org/~msk/marf-as.html=

 

Please review it and comment as soon as possible.  This is our = last batch of work before Barry can write up his shepherding document and m= ove it along to the IESG.

 

Thanks,

-MSK=

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DD1AEXCHC2corpclo_-- From sklist@kitterman.com Sun Feb 12 20:24:38 2012 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 EE6C621F8645 for ; Sun, 12 Feb 2012 20:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fZ22Ml2Jhas for ; Sun, 12 Feb 2012 20:24:38 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 050FD21F862D for ; Sun, 12 Feb 2012 20:24:38 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4056820E40BB; Sun, 12 Feb 2012 23:24:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329107077; bh=cl44dHIUt2WCuguVcAJDKag/DdFQLlZXTKRMj5AVB6U=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=KM1JarMr9mK/MrnyqMXgtVXZ0Q7B/GYpfYZhw2dN25IxQlRpZuWH/Dcl7MXKyftTe LVYeHiRTpJ5jX2ZHOaiRvuc4aQLrTnZNMAxSQKqMS4PwPB0BDXSAkb5qZH5IcBeiBN 60wkNL05X4WzjY7DLDSdJtADDxHsWYqANKZomBOE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 1DDAD20E4093; Sun, 12 Feb 2012 23:24:36 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Sun, 12 Feb 2012 23:24:36 -0500 Message-ID: <2693039.0voWxnHqOg@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Simplifying draft-ietf-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: Mon, 13 Feb 2012 04:24:39 -0000 On Sunday, February 12, 2012 07:42:05 PM Murray S. Kucherawy wrote: > Hi all, > > A last-minute rewrite of a couple of sections of draft-ietf-marf-as was > submitted. The feeling is that Sections 7 and 8 (especially the latter) > had become too verbose and confusing, and had the feel of micromanagement. > The proposed text is rather more general while still attempting to put the > working group's main message into the hands of feedback operators. > > The diff is here: http://www.blackops.org/~msk/marf-as.html > > Please review it and comment as soon as possible. This is our last batch of > work before Barry can write up his shepherding document and move it along > to the IESG. This is a substantial change and I don't think it is reasonable to assume that any working group consensus established during the recently completed last call would apply to it. I like the consolidation of 7.4, 7.5, and 7.7 with 7.3, but I think it goes a little too far. I think the MUST/SHOULD NOTs in the original 7.4 are significant. I'm less fond of the changes to paragraph 8. I think the advice that was removed in 8.1 was useful. I don't think that what makes a report actionable is broadly understood, so including that discussion is useful. Removal of the previous 8.3 is concerning as I think people are encouraged enough to send reports to reports and about resources that are at most peripherally involved in abuse. I think discouraging this sort of behavior for high volume automatic abuse reports that are unsolicited is important. It would be good to understand the rationale for removing the reference to WHOIS abuse addresses? Other heuristics are retained to some degree, but that one was dropped completely. I think the revised discussion about DKIM and SPF is unintelligible. I think the old 8.5 and 8.6 gave explanations that are useful for developers that are not DKIM or SPF experts. The revised text will only provide value for people who already know about DKIM or SPF (i.e. the people that don't need the text because they know already) or people that are triggered to go become protocal experts for DKIM and SPF to figure out how to apply them to this problem. If this is retained the relevant DKIM and SPF RFCs should be normative as there's no way to properly implement this without a detailed study of them now. I particularly object to ditching 8.6. We had a lot of discussion and iterated through a lot of options before settling on the current wording as the rough consensus of the group. One of the primary reasons for the creation of SPF was to reduce the amount of unwanted blowback due to bounce messages when domains where forged. Without clear guidance about this, this draft could cause high volume unsolicited ARFs that cause very similar problems to the bounces from forged messages the protocol was created to combat. Please don't. I think the simplification relative to the old 8.8 (on receiver processing) is fine. I think the removal of 8.11 and 8.12 is fine too. I think the simplification of 8.13 into 8.8 and 8.14 into 8.9 are fine. I'm OK with ditching 8.15 as I don't think it's particularly actionable. For 8.16, I don't think the simplification is an improvement, but I don't think it's awful. WHOIS is mentioned in 8.2 (new and old) so the reference should probably stay. Scott K From internet-drafts@ietf.org Sun Feb 12 20:35:58 2012 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 3A1E921F872A; Sun, 12 Feb 2012 20:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id havaFhjovWj0; Sun, 12 Feb 2012 20:35:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B7D21F86DB; Sun, 12 Feb 2012 20:35:57 -0800 (PST) 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.64p1 Message-ID: <20120213043557.18160.80647.idtracker@ietfa.amsl.com> Date: Sun, 12 Feb 2012 20:35:57 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-dkim-reporting-10.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, 13 Feb 2012 04:35:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Messaging Abuse Reporting Format Work= ing Group of the IETF. Title : Extensions to DKIM for Failure Reporting Author(s) : Murray S. Kucherawy Filename : draft-ietf-marf-dkim-reporting-10.txt Pages : 22 Date : 2012-02-12 This memo presents extensions to the DomainKeys Identified Mail (DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-dkim-reporting-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-dkim-reporting-10.txt From msk@cloudmark.com Sun Feb 12 20:38:08 2012 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 159F521F871B for ; Sun, 12 Feb 2012 20:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7ktVYGsjjnt for ; Sun, 12 Feb 2012 20:38:07 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6997221F86E0 for ; Sun, 12 Feb 2012 20:38:07 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 12 Feb 2012 20:38:07 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sun, 12 Feb 2012 20:38:07 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sun, 12 Feb 2012 20:38:06 -0800 Thread-Topic: I-D Action: draft-ietf-marf-dkim-reporting-10.txt Thread-Index: AczqCQEe2xxZRBmEQba6tK9joCzRPwAADe2A Message-ID: References: <20120213043557.18160.80647.idtracker@ietfa.amsl.com> In-Reply-To: <20120213043557.18160.80647.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-10.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, 13 Feb 2012 04:38:08 -0000 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org > Sent: Sunday, February 12, 2012 8:36 PM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: I-D Action: draft-ietf-marf-dkim-reporting-10.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Messaging Abuse Reporting > Format Working Group of the IETF. >=20 > Title : Extensions to DKIM for Failure Reporting > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-marf-dkim-reporting-10.txt > Pages : 22 > Date : 2012-02-12 >=20 > This memo presents extensions to the DomainKeys Identified Mail > (DKIM) specification to allow for detailed reporting of message > authentication failures in an on-demand fashion. Minor editorial fixes as suggested since start of WGLC. -MSK From sklist@kitterman.com Sun Feb 12 20:59:23 2012 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 3571721F8688 for ; Sun, 12 Feb 2012 20:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzZmwBWVk6yZ for ; Sun, 12 Feb 2012 20:59:22 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE0621F865C for ; Sun, 12 Feb 2012 20:59:22 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E275320E40BB; Sun, 12 Feb 2012 23:59:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329109161; bh=P5MsgCBDfpeFjdQYaqLPQq/c6pUx6889iPhj3ZWOcs4=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=dQLTKQpnkopsuN+kpQMWw+ESzQFMsvVmXQK0rehsu35M01udXAK0zgnoKZOCKQgRx HhxryRbMgkaOMI0xHHlb8HPUPQklMcMxjbx9ILgdAKNG5iv4j25/SLhEfWKjlSyHQx hyLEiHc/bVQQ4siDYbevLgrRHvuVGwfi89UIVlQ8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C28F820E4093; Sun, 12 Feb 2012 23:59:21 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Sun, 12 Feb 2012 23:59:21 -0500 Message-ID: <5658322.PDoDe8X1Pl@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120213043557.18160.80647.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-10.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, 13 Feb 2012 04:59:23 -0000 On Sunday, February 12, 2012 08:38:06 PM Murray S. Kucherawy wrote: ... > Minor editorial fixes as suggested since start of WGLC. ... It still mentions logging, although in a kinder, gentler way. I'm not sure why since it's completely unrelated to interoperability. Scott K From msk@cloudmark.com Sun Feb 12 21:57:38 2012 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 3C20521F84E4 for ; Sun, 12 Feb 2012 21:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AliyRsWDpxMQ for ; Sun, 12 Feb 2012 21:57:37 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6389521F8468 for ; Sun, 12 Feb 2012 21:57:37 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 12 Feb 2012 21:57:37 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sun, 12 Feb 2012 21:57:36 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sun, 12 Feb 2012 21:57:35 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-dkim-reporting-10.txt Thread-Index: AczqDEKlmRu2bbRBS4mpRi+IAB5ABgAB/lcQ Message-ID: References: <20120213043557.18160.80647.idtracker@ietfa.amsl.com> <5658322.PDoDe8X1Pl@scott-latitude-e6320> In-Reply-To: <5658322.PDoDe8X1Pl@scott-latitude-e6320> 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-dkim-reporting-10.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, 13 Feb 2012 05:57:38 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Sunday, February 12, 2012 8:59 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-10.txt >=20 > On Sunday, February 12, 2012 08:38:06 PM Murray S. Kucherawy wrote: > ... > > Minor editorial fixes as suggested since start of WGLC. > ... >=20 > It still mentions logging, although in a kinder, gentler way. I'm not > sure why since it's completely unrelated to interoperability. Where? I don't see any use of "log" anywhere in the document now, except a= s a substring of "technologies". From sklist@kitterman.com Sun Feb 12 22:05:15 2012 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 6290421F8655 for ; Sun, 12 Feb 2012 22:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zh91SZFM2mgh for ; Sun, 12 Feb 2012 22:05:14 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D2F1221F8468 for ; Sun, 12 Feb 2012 22:05:13 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3587020E40BB; Mon, 13 Feb 2012 01:05:13 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329113113; bh=CAZnKxeM7Og3YuR0HO2S5iyP/OE3d/0KI50ltkL224U=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=h9nGfo5q5Ih3ItNQX8e5uLmLnsNISzRXd+Qy1yBTpkIRITJ43ZTB6Z/D214ZGoOhb P2r9A5/aM+zW7scnAWW3QIXH98n55/0uQIxbtefG3hL135AIud+5c/2babZYhGMZM7 ZJxJ3H+iJNf97XKMZOD5mQg8gRt+GxaUwfW50FUk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 1A46120E4093; Mon, 13 Feb 2012 01:05:12 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Mon, 13 Feb 2012 01:05:12 -0500 Message-ID: <1680712.d2TxJAG4Ma@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120213043557.18160.80647.idtracker@ietfa.amsl.com> <5658322.PDoDe8X1Pl@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-10.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, 13 Feb 2012 06:05:15 -0000 On Sunday, February 12, 2012 09:57:35 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Sunday, February 12, 2012 8:59 PM > > To: marf@ietf.org > > Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-10.txt > > > > On Sunday, February 12, 2012 08:38:06 PM Murray S. Kucherawy wrote: > > ... > > > > > Minor editorial fixes as suggested since start of WGLC. > > > > ... > > > > It still mentions logging, although in a kinder, gentler way. I'm not > > sure why since it's completely unrelated to interoperability. > > Where? I don't see any use of "log" anywhere in the document now, except as > a substring of "technologies". Sorry for the noise. Apparently I can't always keep track of which is the before and which is the after in a diff when I'm really tire. Nevermind. Scott K From sklist@kitterman.com Sun Feb 12 22:20:49 2012 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 6A6CA21F8691 for ; Sun, 12 Feb 2012 22:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sywj7O-Ou4b9 for ; Sun, 12 Feb 2012 22:20:48 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 460C121F86B5 for ; Sun, 12 Feb 2012 22:20:48 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D2C4720E40BB; Mon, 13 Feb 2012 01:20:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329114047; bh=wBGdO4n7Ei7Y+6/zPiT/PbtVl8zOlusWerGITfqSaI0=; h=From:To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=UnWdMgAq/B5OusNKgGpiXO+4hh6gQPHNn5539ev8zOQkX1x75Kb0I/+9z1G6py//P gLwp3aPPqVIc5mDsi3ivYkzV4HnIAp7ELEgGBs9kcGLDtrvBlwiha/UkAAJZlpdyVJ oG6mEWzC0b51XnMajfnKdy/Lk7bCD/X3rl+8UnxY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B813220E4093; Mon, 13 Feb 2012 01:20:47 -0500 (EST) From: Scott Kitterman To: "marf@ietf.org" Date: Mon, 13 Feb 2012 01:20:47 -0500 Message-ID: <2687617.GuVsQiVKMe@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [marf] Message bodies in ARF reports 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, 13 Feb 2012 06:20:49 -0000 I think I've seen mention a few times on this list about doing certain things with ARFs depending on if they have the message bodies attached. Now that I'm working on my implementation of draft-ietf-marf-spf-reporting, I'm questioning where the requirement for message bodies or headers in ARFs is. As I read RFC 5965 2.d, either the message body or rfc822-headers must be included as the third part of the message. For SPF auth-failure reports, I'm not sure what, if anything, it makes to include in this third MIME part of the message. Since it's during the SMTP transaction, there are SMTP exchanges of identities, but no headers. Since Mail From is already included as an explicit field in the second MIME part, I'm not sure what, if anything should be required for the last part. In the case of the work I'm doing, I'm using the Postfix policy delegation interface (see http://www.postfix.org/SMTPD_POLICY_README.html if you're interested) and I don't have access to anything in the body of the message (nor is there a reason for me to have it). Is this MUST in 5965 being ignored or am mis-interpreting something? Scott K From vesely@tana.it Mon Feb 13 07:15:39 2012 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 2A1CA21F8633 for ; Mon, 13 Feb 2012 07:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.634 X-Spam-Level: X-Spam-Status: No, score=-4.634 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AK-K+FTRw4cg for ; Mon, 13 Feb 2012 07:15:38 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A743D21F862B for ; Mon, 13 Feb 2012 07:15:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1329146128; bh=sUiuRRcSbFXoTznshTTqYmG83GvSPTUpGtMwaID694c=; l=1577; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ChFJ8XykItXz5/AAcULMKvzvVhu0fL9g2frw/zMC7qpKvPSkeDd3v2GC6A/Yzq8Fs dAAOayT7RAsMlWzlOhJr123U9WVEpgAt0eWoZHbrG+9QkILZeSBbzx0TZaOKWsBP0C NqtGfUBDpZ4fNIpiBAqDooY3aErMkyJVtoF4s3xU= 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, 13 Feb 2012 16:15:28 +0100 id 00000000005DC033.000000004F392910.00001A22 Message-ID: <4F39290F.5090405@tana.it> Date: Mon, 13 Feb 2012 16:15:27 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 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] Simplifying draft-ietf-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: Mon, 13 Feb 2012 15:15:39 -0000 On 13/Feb/12 04:42, Murray S. Kucherawy wrote: > > The diff is here: http://www.blackops.org/~msk/marf-as.html > > Please review it and comment as soon as possible. This is our last > batch of work before Barry can write up his shepherding document and > move it along to the IESG. That oversimplifies the I-D. Except for a few excisions, version -08 looks sounder and clearer. In the rest of this message, I paste all the snippets of text that, IMHO, can be removed from Section 8 of version -08 with no substantial loss: The following advice is offered for the case of reports that are not solicited: (These applications might be described in future IETF documents.) Systems SHOULD NOT report all mail sent from a particular sender merely because some of it is determined to be abusive. since, because of their subjective nature, they are unlikely to provide a basis for the recipient to take action 6. Similarly, if a report generator applies SPF to arriving messages, and that evaluation produced something other than a "Pass", "None" or "Neutral" result, a report addressed to the RFC5321.MailFrom domain SHOULD NOT be generated as it is probably a forgery and thus not actionable. A valid exception would be specific knowledge that the SPF result is not definitive for that domain under those circumstances (e.g., a message that is also DKIM-signed by the same domain, and that signature validates). However, they MAY take advantage of the standardized parts of the ARF format to automate processing. From johnl@iecc.com Mon Feb 13 07:42:02 2012 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 A5BA421F863C for ; Mon, 13 Feb 2012 07:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.685 X-Spam-Level: X-Spam-Status: No, score=-109.685 tagged_above=-999 required=5 tests=[AWL=1.514, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEqwLCUVH6Lr for ; Mon, 13 Feb 2012 07:42:01 -0800 (PST) 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 33B1321F8639 for ; Mon, 13 Feb 2012 07:42:00 -0800 (PST) Received: (qmail 59652 invoked from network); 13 Feb 2012 15:41:55 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Feb 2012 15:41:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f392f42.xn--btvx9d.k1202; i=johnl@user.iecc.com; bh=+YdXSC/OmiJs9eoT9VnbhBDv7mrTOflCxfmVpzycIGQ=; b=RBlUMJDW/hk8QyO9sP44+qyJKHQJAl+NsAp1qxKYhxYldU9ZG+zGsHn34nP9MlgeL+cMuD3S60mHVvisHMoCF46N8EjI790eqVlLYIXJ1WlzAkFZUxN68jRtEkok6X2QeYqrbixqugnBw0HexOlFCOnb+D9K3lC22S7UqnVN/Ks= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f392f42.xn--btvx9d.k1202; olt=johnl@user.iecc.com; bh=+YdXSC/OmiJs9eoT9VnbhBDv7mrTOflCxfmVpzycIGQ=; b=dIWXfZPx8UOYw/gawHZdUsAgiZGmjdwfI+dlSmlbux76/eD/MwtH9a8eiYgJ6RSllw4vyRhVrkSqlc+yvwusPLWyaMeaYSbhjeqdJ7OeT0ePs5tWobfA1h8MFeNW/+Qtd+ESL0QTDnJ1qJSSIJNN9CGjjjE62TZNcnWJBlv3DRM= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 13 Feb 2012 15:41:32 -0000 Message-ID: <20120213154132.68179.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <2687617.GuVsQiVKMe@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] Message bodies in ARF reports 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, 13 Feb 2012 15:42:02 -0000 >Now that I'm working on my implementation of draft-ietf-marf-spf-reporting, >I'm questioning where the requirement for message bodies or headers in ARFs >is. Interesting question. ARF is a version of multipart/report as defined in RFC 3462. In that document, the message/rfc822 or message/headers is optional. In RFC 5965, we made it mandatory in section 2.d. We did that because the usage scenario we were thinking of was spam button reports where you always have a message in hand, not for any deeper reason. You are of course correct that SPF failures sometimes don't accept the message. I'd be willing to file an erratum that 2.d. should have said that the report MUST include the message if the reporting entity has received it. R's, John From johnl@iecc.com Mon Feb 13 07:43:37 2012 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 2E04421F865D for ; Mon, 13 Feb 2012 07:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.706 X-Spam-Level: X-Spam-Status: No, score=-109.706 tagged_above=-999 required=5 tests=[AWL=1.493, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3q74lFVpE73 for ; Mon, 13 Feb 2012 07:43:36 -0800 (PST) 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 8C15521F849C for ; Mon, 13 Feb 2012 07:43:35 -0800 (PST) Received: (qmail 60495 invoked from network); 13 Feb 2012 15:43:34 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Feb 2012 15:43:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f392fa5.xn--30v786c.k1202; i=johnl@user.iecc.com; bh=tjrcKYCbKGulqWtCF+A90pL5b0Kgg56LtkVceYPhw+I=; b=Li86uWWtswT9HWd1Yz8Lr/hLMshBfvn8BIS45Bvz79A7K9/LjuXKmaU/1jTbVIMeAgxX7qpuDwLaogM/eEyJAru4CB0YN3Sph41Ij0KkpnreS2ioJdkIY8Ax/7GTzf2HI6VKOmd6BYZHJVtnbY4gXGK3MQxqiklmYL4MfqDJhOQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f392fa5.xn--30v786c.k1202; olt=johnl@user.iecc.com; bh=tjrcKYCbKGulqWtCF+A90pL5b0Kgg56LtkVceYPhw+I=; b=o5duRvWAtfotw+frJAOMXO+Xm+9CbnQukjic2bz5xKvTBvn/WsImcbIrDCRFjxPztk57mBmemt96Ka/WFjs4QcSeiykaweLopfwL0qBTK0c3iWYd4tLjKmoVxfkntMLx2JtFnnexDj4Bxio4SaBTIIKpeOL7C5fSu9iALyBL4PE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 13 Feb 2012 15:43:11 -0000 Message-ID: <20120213154311.68251.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] Simplifying draft-ietf-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: Mon, 13 Feb 2012 15:43:37 -0000 >The diff is here: http://www.blackops.org/~msk/marf-as.html Steve and I went through and took out stuff that looks too much like an implementor's guide rather than an applicability statement. In particular, we tried to stick to what to accomplish, not how to do it. There's nothing wrong with writing a DKIM or SPF reporting cookbook, but this isn't it. R's, John From barryleiba.mailing.lists@gmail.com Mon Feb 13 08:02:52 2012 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 0DBE621F8657 for ; Mon, 13 Feb 2012 08:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.957 X-Spam-Level: X-Spam-Status: No, score=-102.957 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiU8KcIJwNKa for ; Mon, 13 Feb 2012 08:02:51 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3139D21F8648 for ; Mon, 13 Feb 2012 08:02:51 -0800 (PST) Received: by ggnq2 with SMTP id q2so2788562ggn.31 for ; Mon, 13 Feb 2012 08:02:50 -0800 (PST) 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=WcT93/a9EoGKPnJ8X2pffnRrfu5RirewN1yyQrWWel8=; b=vjfu2JskUXbeLyCWZnO6JLSgbwgDQFTtRPByf+wXznW1x8iNO+y5LiMKcLGG1X7aaA 3M5LzXdEEjoT6/7z1kZOEhO9okMIlLma6gdJrf0oPO8Sm+7Wa0mUVmhfbdnzNcmXLOLG UefrvpXcKUNQXMqWBvCK7fVmmmUkIimwAcw/o= MIME-Version: 1.0 Received: by 10.236.124.66 with SMTP id w42mr20968513yhh.23.1329148970789; Mon, 13 Feb 2012 08:02:50 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Mon, 13 Feb 2012 08:02:50 -0800 (PST) In-Reply-To: <2693039.0voWxnHqOg@scott-latitude-e6320> References: <2693039.0voWxnHqOg@scott-latitude-e6320> Date: Mon, 13 Feb 2012 11:02:50 -0500 X-Google-Sender-Auth: VztaqW4VePPc0aH65bhV6Lc_zG8 Message-ID: From: Barry Leiba To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: marf@ietf.org Subject: Re: [marf] Simplifying draft-ietf-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: Mon, 13 Feb 2012 16:02:52 -0000 >> A last-minute rewrite of a couple of sections of draft-ietf-marf-as was >> submitted. =A0The feeling is that Sections 7 and 8 (especially the latte= r) >> had become too verbose and confusing, and had the feel of micromanagemen= t. >> The proposed text is rather more general while still attempting to put t= he >> working group's main message into the hands of feedback operators. > > This is a substantial change and I don't think it is reasonable to assume= that > any working group consensus established during the recently completed las= t > call would apply to it. I agree, and I will want to hear from at least all the participants who made WGLC comments, before accepting this version. So far, we've heard from Scott and Alessandro, who aren't happy with the changes. That's likely to mean that the document isn't ready to go yet, and that we need more work to re-achieve consensus on a last-call version. Barry, document shepherd From vesely@tana.it Mon Feb 13 08:28:40 2012 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 61D1A21F8681 for ; Mon, 13 Feb 2012 08:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.635 X-Spam-Level: X-Spam-Status: No, score=-4.635 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd5d7pmQxHDz for ; Mon, 13 Feb 2012 08:28:39 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9D23121F8679 for ; Mon, 13 Feb 2012 08:28:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1329150513; bh=sncIDt/efXWITZ8AXTQ2eZpHcKE3sxsCMBjKrSXQMJg=; l=2001; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=cdGsj1mDGkLJGKdI3XMT/SYNvIhg+aROZ935SLWOrWgeH0JSFcC0zWsMpUWanmE4t hg7nYzVubOXCw1Q2yeuF36heY6sLwE6020EeMHXzxKqVVHc7QlZpJuYMdSxi4wMFba NWYUxokdVNBxP2nNQ9kP1D82LrWnga6urOcxoJk4= 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, 13 Feb 2012 17:28:33 +0100 id 00000000005DC050.000000004F393A31.00002CF9 Message-ID: <4F393A31.6020303@tana.it> Date: Mon, 13 Feb 2012 17:28:33 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <2687617.GuVsQiVKMe@scott-latitude-e6320> In-Reply-To: <2687617.GuVsQiVKMe@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Message bodies in ARF reports 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, 13 Feb 2012 16:28:40 -0000 On 13/Feb/12 07:20, Scott Kitterman wrote: > > As I read RFC 5965 2.d, either the message body or rfc822-headers must be > included as the third part of the message. Yup. > For SPF auth-failure reports, I'm not sure what, if anything, it makes to > include in this third MIME part of the message. Since it's during the SMTP > transaction, there are SMTP exchanges of identities, but no headers. AFAICS, the third part is needed to let the sender understand what message failed to authenticate. For example, if a user of theirs sent a message via an unauthorized server, the envelope is possibly not enough to take action (e.g. tell the user to not do that.) > Since Mail From is already included as an explicit field in the second MIME > part, I'm not sure what, if anything should be required for the last part. In > the case of the work I'm doing, I'm using the Postfix policy delegation > interface (see http://www.postfix.org/SMTPD_POLICY_README.html if you're > interested) and I don't have access to anything in the body of the message > (nor is there a reason for me to have it). Could it be worked around designing a two-tier process? That is, 1) generate non-ARF data (essentially, ARF w/o 3rd part), and then 2) finalize, possibly redact, and send. The outcome of the first tier can still be useful for debugging or internal auditing. If the message gets accepted, the second tier has to be able to retrieve the file. > Is this MUST in 5965 being ignored or am mis-interpreting something? 2.d implies that only accepted or rejected-after-data messages can actually be reported, while SPF rejections occur before data. That point could be overridden in spf-reporting or, if it's not too late, in authailure-report. A use case is for domains that need to collect as many SPF *fail* reports as possible, e.g. to gather evidence on which third parties habitually infringe on their registered name. I'd be favorable to adding such possibility. From msk@cloudmark.com Mon Feb 13 08:58:35 2012 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 BDEF821F8656 for ; Mon, 13 Feb 2012 08:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TokvGWTWotS4 for ; Mon, 13 Feb 2012 08:58:35 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3762521F864F for ; Mon, 13 Feb 2012 08:58:35 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 13 Feb 2012 08:58:33 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 13 Feb 2012 08:58:33 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 13 Feb 2012 08:58:32 -0800 Thread-Topic: [marf] Message bodies in ARF reports Thread-Index: AczqZgyTe/Q1+maKQOudVYfSpdaAcwACfsHQ Message-ID: References: <2687617.GuVsQiVKMe@scott-latitude-e6320> <20120213154132.68179.qmail@joyce.lan> In-Reply-To: <20120213154132.68179.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Message bodies in ARF reports 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, 13 Feb 2012 16:58:35 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of J= ohn Levine > Sent: Monday, February 13, 2012 7:42 AM > To: marf@ietf.org > Subject: Re: [marf] Message bodies in ARF reports >=20 > Interesting question. >=20 > ARF is a version of multipart/report as defined in RFC 3462. In that > document, the message/rfc822 or message/headers is optional. In RFC > 5965, we made it mandatory in section 2.d. We did that because the > usage scenario we were thinking of was spam button reports where you > always have a message in hand, not for any deeper reason. >=20 > You are of course correct that SPF failures sometimes don't accept the > message. I'd be willing to file an erratum that 2.d. should have said > that the report MUST include the message if the reporting entity has > received it. I'd support that. I'd also support the idea that an SPF report can synthesize the text/rfc822= -headers for a message whose content has not actually arrived. All you leg= ally need is a From: field as I recall, and that can be generated based on = the rejected RFC5321.MailFrom. From shmuel+gen@patriot.net Mon Feb 13 10:56:48 2012 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 F28D121F869E for ; Mon, 13 Feb 2012 10:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfLWIn3D6Apz for ; Mon, 13 Feb 2012 10:56:47 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9D821F865E for ; Mon, 13 Feb 2012 10:56:46 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.150]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 3EC32F58093 for ; Mon, 13 Feb 2012 13:42:03 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 13 Feb 2012 13:04:57 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120213184204.3EC32F58093@smtp.patriot.net> Subject: Re: [marf] meaning of signatures, was I-D Action: draft-ietf-marf-as-07.txt 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, 13 Feb 2012 18:56:48 -0000 In , on 02/12/2012 at 03:54 PM, "BANK SECURITY" said: >Sorry, that makes no sense at all. Every DKIM verification record is >a TXT record containing a public key. We seem to be talking at cross purposes. I'm not saying that DKIM or SPF infrastructure can be used for the purpose, I'm saying that it is possible to define and deploy a means of authenticating addresses in the header. >The basic fact is that there is nothing I can say to improve my >reputation I'm not addressing reputation. Verifying that the sender is authorized to use a domain name in no way implies that he is legitimate. In fact, spammers were early adopters of SPF, as you know. >So I can publish text records to prove that something is from me, >but not to prove that I'm nice. I was addressing authentication, not reputation. -- 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 Mon Feb 13 11:16:42 2012 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 2F9CA21F86E2 for ; Mon, 13 Feb 2012 11:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2HYxqCpy9fE for ; Mon, 13 Feb 2012 11:16:41 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6F80B21F86D5 for ; Mon, 13 Feb 2012 11:16:41 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A5DF020E40BB; Mon, 13 Feb 2012 14:16:40 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329160600; bh=IXYA739VYB+4qvuf+dAwCyFcfYrQlSKU7AaA6eCpVxk=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=qUFtHIthYTSPQ87BG5KNtTlsxkuAJXEW92hF2UPxq/jm1FFPd4IPFvWWpoqoZ2GWL rdoroHkFUVBYiJp+Wo97mkvjMAxXSXXKMvw3/rcsjEptmS0mzo2vk4qDoNI8x59uYr 9x4nuORKFWqyTdletauWmwJerCYMhfW39evqhrwc= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8AFF320E408E; Mon, 13 Feb 2012 14:16:40 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Mon, 13 Feb 2012 14:16:39 -0500 Message-ID: <4262669.j8FVnr9uh5@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <2693039.0voWxnHqOg@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Simplifying draft-ietf-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: Mon, 13 Feb 2012 19:16:42 -0000 On Monday, February 13, 2012 11:02:50 AM Barry Leiba wrote: > >> A last-minute rewrite of a couple of sections of draft-ietf-marf-as > >> was > >> submitted. The feeling is that Sections 7 and 8 (especially the > >> latter) > >> had become too verbose and confusing, and had the feel of > >> micromanagement. The proposed text is rather more general while still > >> attempting to put the working group's main message into the hands of > >> feedback operators.> > > This is a substantial change and I don't think it is reasonable to > > assume that any working group consensus established during the recently > > completed last call would apply to it. > > I agree, and I will want to hear from at least all the participants > who made WGLC comments, before accepting this version. So far, we've > heard from Scott and Alessandro, who aren't happy with the changes. > That's likely to mean that the document isn't ready to go yet, and > that we need more work to re-achieve consensus on a last-call version. > > Barry, document shepherd That or decide there's rough consensus on the previous draft. Scott K From sklist@kitterman.com Mon Feb 13 11:26:49 2012 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 88A4421F8747 for ; Mon, 13 Feb 2012 11:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4Rb3jj24EMs for ; Mon, 13 Feb 2012 11:26:48 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C4E0821F873E for ; Mon, 13 Feb 2012 11:26:48 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5DA1520E40BB; Mon, 13 Feb 2012 14:26:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329161208; bh=B726jyZUfQduhaL7QyI0bIzzo4KliIWI/c0MgZY/kpg=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=eAE5JFx1r2uZ6WdiB2XyR8fPVlD1+h96ixeekge9j72gQv9yh5GoH6/zE/Vnart4A Bm2D0N1EedVjxGR/BoepIcuRKm2Uzh+KzF6ePQbpwpCVJNc/nYXvLhe6Mk1K6W+yUR Ij30reWi3tgsgUZMeOwgJaXxd94H9NUHf+0/IMgg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3ED6320E408E; Mon, 13 Feb 2012 14:26:48 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Mon, 13 Feb 2012 14:26:47 -0500 Message-ID: <8577772.BrpObzDUBN@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <2687617.GuVsQiVKMe@scott-latitude-e6320> <20120213154132.68179.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Message bodies in ARF reports 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, 13 Feb 2012 19:26:49 -0000 On Monday, February 13, 2012 08:58:32 AM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > John Levine Sent: Monday, February 13, 2012 7:42 AM > > To: marf@ietf.org > > Subject: Re: [marf] Message bodies in ARF reports > > > > Interesting question. > > > > ARF is a version of multipart/report as defined in RFC 3462. In that > > document, the message/rfc822 or message/headers is optional. In RFC > > 5965, we made it mandatory in section 2.d. We did that because the > > usage scenario we were thinking of was spam button reports where you > > always have a message in hand, not for any deeper reason. > > > > You are of course correct that SPF failures sometimes don't accept the > > message. I'd be willing to file an erratum that 2.d. should have said > > that the report MUST include the message if the reporting entity has > > received it. > > I'd support that. That's great. Is MUST include if you have ... or SHOULD include (unless you do not have ...) a better construction? I thought the trend in IETF documents was away from MUSTs if they weren't essential. > I'd also support the idea that an SPF report can synthesize the > text/rfc822-headers for a message whose content has not actually arrived. > All you legally need is a From: field as I recall, and that can be > generated based on the rejected RFC5321.MailFrom. If by 'synthesize' you mean 'assume the RFC5321.MailFrom and the FRC5322.From are the same', then yes, it could do that. That's not the same as saying I think it's a good idea. In cases where this heuristic is wrong (I've seen numbers between 5% and 20% of mail), it will probably be deeply confusing to receivers of such reports. I don't think we should. Scott K From johnl@iecc.com Mon Feb 13 13:37:23 2012 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 4455821E804B for ; Mon, 13 Feb 2012 13:37:23 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjwja9j6bbnN for ; Mon, 13 Feb 2012 13:37:22 -0800 (PST) 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 128E521E802A for ; Mon, 13 Feb 2012 13:37:19 -0800 (PST) Received: (qmail 2863 invoked from network); 13 Feb 2012 21:37:18 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Feb 2012 21:37:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f39828e.xn--30v786c.k1202; i=johnl@user.iecc.com; bh=LBRaa1Orw7kgBjqjS4jYHTZxahjxDROM527pokZiDsA=; b=H161J+SuQAtDSWUN0rMLuj5JhQsmWrA+PXXbjEsr91tcr78OYnbl6NCxRVJQ/8q/du+3ZCbWPHCkeHZEGq7I6e/hznLQgC8v63IJugKRzX0XYN7jpQMz3WkT/rt3PPfdXYyf1vTrCr3CgEnDGeq5X/iyvsBrg+EVoJEbxQwv0Bg= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=banqofamerika.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f39828e.xn--30v786c.k1202; olt=johnl@user.iecc.com; bh=LBRaa1Orw7kgBjqjS4jYHTZxahjxDROM527pokZiDsA=; b=X8LF6tbB2ZaVEXUyfWg0fyNRl7O9kJrET+KLWQqKioRwandpi+x/KxqZTj4BQmY8qIBqMQ2QCY9TPrY0wdDjyVZ0f91A9j2w1AurwRAT+G4hea35KmcG7riLWcaPjmVMHc7yeCkwCPI5Hjs2ReH9AasAzXHfixNYRXm+G9rBWBg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 13 Feb 2012 21:36:56 -0000 Message-ID: <20120213213656.80676.qmail@joyce.lan> From: "Bank Security" To: marf@ietf.org In-Reply-To: <20120213184204.3EC32F58093@smtp.patriot.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] meaning of signatures, was I-D Action: draft-ietf-marf-as-07.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, 13 Feb 2012 21:37:23 -0000 >I was addressing authentication, not reputation. This makes no sense at all. DKIM and SPF do authentication right now. If for some reason you want authentication of the From: line, you know where to find Sender-ID or DMARC. Your message a few rounds ago said: >>I can't conceive of an Internet-based technology that can confirm >>intent or legitimacy of the signer/author/whatever. > >How about a public key in a TXT RR? You can tell that the From: line is tied to a DNS entry, but you can't tell from that DNS entry whether the sender is the person who he claims to be, or whether his intent is to phish you or tell you that your bank account really is overdrawn. This argument has been beaten to death N times, no need for another round. R's, John From dhc@dcrocker.net Mon Feb 13 13:50:38 2012 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 A638821F863E for ; Mon, 13 Feb 2012 13:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.636 X-Spam-Level: X-Spam-Status: No, score=-6.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZGzMAI09jUS for ; Mon, 13 Feb 2012 13:50:37 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id CC31B21F8639 for ; Mon, 13 Feb 2012 13:50:37 -0800 (PST) Received: from [192.168.1.9] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1DLoSbS021032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Feb 2012 13:50:34 -0800 Message-ID: <4F39859B.7020106@dcrocker.net> Date: Mon, 13 Feb 2012 13:50:19 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Bank Security References: <20120213213656.80676.qmail@joyce.lan> In-Reply-To: <20120213213656.80676.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 13 Feb 2012 13:50:34 -0800 (PST) Cc: marf@ietf.org Subject: Re: [marf] meaning of signatures, was I-D Action: draft-ietf-marf-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net 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, 13 Feb 2012 21:50:38 -0000 I just scanned this sub-thread. It appears to be one that started badly and got worse. From what I can see, there's little change that trend will change. I guess I should also note that I don't see it's relevance to marf. d/ On 2/13/2012 1:36 PM, Bank Security wrote: >> I was addressing authentication, not reputation. > > This makes no sense at all. DKIM and SPF do authentication right now. > If for some reason you want authentication of the From: line, you know > where to find Sender-ID or DMARC. > > Your message a few rounds ago said: >>> I can't conceive of an Internet-based technology that can confirm >>> intent or legitimacy of the signer/author/whatever. >> >> How about a public key in a TXT RR? > > You can tell that the From: line is tied to a DNS entry, but you can't > tell from that DNS entry whether the sender is the person who he > claims to be, or whether his intent is to phish you or tell you that > your bank account really is overdrawn. > > This argument has been beaten to death N times, no need for another round. > > R's, > John > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > -- Dave Crocker Brandenburg InternetWorking bbiw.net From barryleiba.mailing.lists@gmail.com Mon Feb 13 15:05:27 2012 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 2C6A321E802C for ; Mon, 13 Feb 2012 15:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.957 X-Spam-Level: X-Spam-Status: No, score=-102.957 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uLXoOflkm4w for ; Mon, 13 Feb 2012 15:05:26 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB1B21E8010 for ; Mon, 13 Feb 2012 15:05:26 -0800 (PST) Received: by ghbg16 with SMTP id g16so3111216ghb.31 for ; Mon, 13 Feb 2012 15:05:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=JBSGazL+w4FfMs2YLuNhxSoU9O9gDc0fSeFaq3uh1tQ=; b=Hor1baYHiNRSuJhs9xo1zS76QV/VUGaXpMQ+BOOseu8J/pVB2yoYpAzJVriwrUC4CB E7xqObiWKIW97Eri7OHOqCdbohzjCTfcPMwvKh0zdpa95hgtukpjxrH/1GN8mwcKwAW+ mHAo0tx/UP82NIRffnBNoNvRxvXDb6tBhlBkg= MIME-Version: 1.0 Received: by 10.101.141.9 with SMTP id t9mr7293471ann.42.1329174325673; Mon, 13 Feb 2012 15:05:25 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Mon, 13 Feb 2012 15:05:25 -0800 (PST) Date: Mon, 13 Feb 2012 18:05:25 -0500 X-Google-Sender-Auth: YsLts7WXAEpjhWPbaJlOGUWnvWc Message-ID: From: Barry Leiba To: Message Abuse Report Format working group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [marf] Working Group Last Call on draft-ietf-marf-as... expired, and coming back 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, 13 Feb 2012 23:05:27 -0000 A couple of weeks ago-ish, I started working-group last call on the subject document, and said this: > Please do not > wait until the last minute, and especially do not wait until the > document goes to the IESG. =A0You will be beaten with a rubber > truncheon. It seems that I do need to get out my truncheon. John Levine and Steve Atkins did, indeed, wait until the last minute. Despite participation in the last-call conversation, they provided *major* edits to the editor (1) off list, and (2) after WGLC ended. Now, I'm not one to hold a line, at least not at this point, and say that we won't consider useful input because an arbitrary deadline wasn't met. At the same time, this sort of behaviour is abusive to the working group. It abuses process, it abuses the chair's desire to accommodate all reasonable input, and, most significantly, it shows a complete lack of respect for the time and effort of the other participants. We spent ten days hashing out what some thought were the final details of an almost-done document, only to find that a couple of participants thought it proper to do significant rewrites at the last minute and without discussing them with the group. Everyone: My interest in accommodating everyone's input and allowing for busy schedules that include things other than MARF participation is getting a bit frayed. I consider that the AS document is back to "active document" state. We will continue discussing it. We will come to rough consensus on all, some, or none of the recent changes. WHen we've decided where the working group as a collective roughitude stands on it, we will re-do working-group last call. And we will expect that discussion will quickly converge so that we can send this to the IESG before the Paris IETF meeting. And we will NOT do this sort of thing again. Barry, as increasingly annoyed chair From sklist@kitterman.com Mon Feb 13 16:09:30 2012 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 6473621F8681 for ; Mon, 13 Feb 2012 16:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7duDa17eIqBs for ; Mon, 13 Feb 2012 16:09:29 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id EE3F521F8675 for ; Mon, 13 Feb 2012 16:09:28 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CBFA920E40BB; Mon, 13 Feb 2012 19:09:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329178168; bh=5SYhRjPjr4Rg9JLbL448trRsbNQxA2xUO9xbqX0duCk=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=m/hfdNsT21iXLGppQ1ESFyK/k7HD6qHOL/Xok5i5bjXAHVp5eBf8QFTrVeFFVci5N Z2i8GFzhlN5jkJ0DR63On+h+Oj0+Pewi2HmyXImOAzE+XjjR/qPXVB6AhSEN3Cw/Ba JJ8Ytb5jnvZKh6tspqsvylKejj1I2k2o1/vWT0G0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id ABBF620E408E; Mon, 13 Feb 2012 19:09:21 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Mon, 13 Feb 2012 19:09:20 -0500 Message-ID: <4538983.3ALPO6EjPM@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as... expired, and coming back 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, 14 Feb 2012 00:09:30 -0000 On Monday, February 13, 2012 06:05:25 PM Barry Leiba wrote: > A couple of weeks ago-ish, I started working-group last call on the > > subject document, and said this: > > Please do not > > wait until the last minute, and especially do not wait until the > > document goes to the IESG. You will be beaten with a rubber > > truncheon. > > It seems that I do need to get out my truncheon. > > John Levine and Steve Atkins did, indeed, wait until the last minute. > Despite participation in the last-call conversation, they provided > *major* edits to the editor (1) off list, and (2) after WGLC ended. > > Now, I'm not one to hold a line, at least not at this point, and say > that we won't consider useful input because an arbitrary deadline > wasn't met. At the same time, this sort of behaviour is abusive to > the working group. It abuses process, it abuses the chair's desire to > accommodate all reasonable input, and, most significantly, it shows a > complete lack of respect for the time and effort of the other > participants. We spent ten days hashing out what some thought were > the final details of an almost-done document, only to find that a > couple of participants thought it proper to do significant rewrites at > the last minute and without discussing them with the group. > > Everyone: My interest in accommodating everyone's input and allowing > for busy schedules that include things other than MARF participation > is getting a bit frayed. > > I consider that the AS document is back to "active document" state. > We will continue discussing it. We will come to rough consensus on > all, some, or none of the recent changes. WHen we've decided where > the working group as a collective roughitude stands on it, we will > re-do working-group last call. And we will expect that discussion > will quickly converge so that we can send this to the IESG before the > Paris IETF meeting. > > And we will NOT do this sort of thing again. > > Barry, as increasingly annoyed chair OK. I've invested all the time I intend to invest in this draft within the working group. I'll read it again when it hits IETF last call then. I don't have time for this. Scott K From sklist@kitterman.com Mon Feb 13 17:14:47 2012 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 6304721F858A for ; Mon, 13 Feb 2012 17:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaCkl8zGp3Yz for ; Mon, 13 Feb 2012 17:14:46 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6373D21F8594 for ; Mon, 13 Feb 2012 17:14:46 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 722C920E40BB; Mon, 13 Feb 2012 20:14:45 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329182085; bh=ADVExEZrglkjGkbILo48lKlVo/bcSkMa49xHTP8jByA=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=jExa1Szret9t/lCsXrsEj5RWbHWMD+k4mFmusJBrU1qg4gbphHIbeeu+0rsF/TCn6 aLSGf1zKVU1anwtbp1vRKgFdoQ1jxfkOg2DNJpqQf2C7gC7TkiguvmP6EM5rjAiHcG dSi+ePj21F7lmdHRCWeyKYdD/5GwObSx3BJ1YNc0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 53AD220E408E; Mon, 13 Feb 2012 20:14:45 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Mon, 13 Feb 2012 20:14:44 -0500 Message-ID: <5174453.Dzk5rAalN3@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4538983.3ALPO6EjPM@scott-latitude-e6320> References: <4538983.3ALPO6EjPM@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as... expired, and coming back 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, 14 Feb 2012 01:14:47 -0000 On Monday, February 13, 2012 07:09:20 PM Scott Kitterman wrote: > On Monday, February 13, 2012 06:05:25 PM Barry Leiba wrote: > > A couple of weeks ago-ish, I started working-group last call on the > > > > subject document, and said this: > > > Please do not > > > wait until the last minute, and especially do not wait until the > > > document goes to the IESG. You will be beaten with a rubber > > > truncheon. > > > > It seems that I do need to get out my truncheon. > > > > John Levine and Steve Atkins did, indeed, wait until the last minute. > > Despite participation in the last-call conversation, they provided > > *major* edits to the editor (1) off list, and (2) after WGLC ended. > > > > Now, I'm not one to hold a line, at least not at this point, and say > > that we won't consider useful input because an arbitrary deadline > > wasn't met. At the same time, this sort of behaviour is abusive to > > the working group. It abuses process, it abuses the chair's desire to > > accommodate all reasonable input, and, most significantly, it shows a > > complete lack of respect for the time and effort of the other > > participants. We spent ten days hashing out what some thought were > > the final details of an almost-done document, only to find that a > > couple of participants thought it proper to do significant rewrites at > > the last minute and without discussing them with the group. > > > > Everyone: My interest in accommodating everyone's input and allowing > > for busy schedules that include things other than MARF participation > > is getting a bit frayed. > > > > I consider that the AS document is back to "active document" state. > > We will continue discussing it. We will come to rough consensus on > > all, some, or none of the recent changes. WHen we've decided where > > the working group as a collective roughitude stands on it, we will > > re-do working-group last call. And we will expect that discussion > > will quickly converge so that we can send this to the IESG before the > > Paris IETF meeting. > > > > And we will NOT do this sort of thing again. > > > > Barry, as increasingly annoyed chair > > OK. I've invested all the time I intend to invest in this draft within the > working group. I'll read it again when it hits IETF last call then. I > don't have time for this. I've gone back and re-read Barry's mail and while I'm frustrated, I'm backing off from my last statement. You've got my review of the proposed changeset. It's got a few things worth using, but on the whole, I think it worsens the document. Scott K From sklist@kitterman.com Mon Feb 13 18:38:45 2012 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 E122621E8043 for ; Mon, 13 Feb 2012 18:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blHKRTQ5B7hP for ; Mon, 13 Feb 2012 18:38:45 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 31B7621E802B for ; Mon, 13 Feb 2012 18:38:44 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 472CB20E40BB; Mon, 13 Feb 2012 21:38:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329187124; bh=bqwzBJ3TKAlZdQO6F1uEKIxi0NgYc0TtzJ3YsHCtvAg=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=F1lJLkWxk48OLUgUFqgcHN+ijwkxEIXE9Ya6T1Fo9yZcebMAhzpdDMty9PJgniWe+ 5CG407YGVDx5rcO3Sv36Klrxxzwlhs/c6kvFEEIASOqxWipiIMCJQiQoNYb+OZ1Q2y 1pSxSSw8YFqjsu9shEyj+5IQfMf9f0gMCTh8fezY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2706420E408E; Mon, 13 Feb 2012 21:38:43 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Mon, 13 Feb 2012 21:38:43 -0500 Message-ID: <51125120.U0YxYHyHTE@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120213154311.68251.qmail@joyce.lan> References: <20120213154311.68251.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Simplifying draft-ietf-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, 14 Feb 2012 02:38:46 -0000 On Monday, February 13, 2012 03:43:11 PM John Levine wrote: > >The diff is here: http://www.blackops.org/~msk/marf-as.html > > Steve and I went through and took out stuff that looks too much like > an implementor's guide rather than an applicability statement. In > particular, we tried to stick to what to accomplish, not how to do it. > > There's nothing wrong with writing a DKIM or SPF reporting cookbook, > but this isn't it. Where are applicability statements defined? Scott K From msk@cloudmark.com Mon Feb 13 19:54:30 2012 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 9CF0C21E804A for ; Mon, 13 Feb 2012 19:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2J7QZNqDfK3 for ; Mon, 13 Feb 2012 19:54:30 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 222C921E8043 for ; Mon, 13 Feb 2012 19:54:30 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 13 Feb 2012 19:54:29 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 13 Feb 2012 19:54:29 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 13 Feb 2012 19:54:28 -0800 Thread-Topic: [marf] Simplifying draft-ietf-marf-as Thread-Index: AczqwchMByphNbuUQ1m5JCfV5H5KGgACmikg Message-ID: References: <20120213154311.68251.qmail@joyce.lan> <51125120.U0YxYHyHTE@scott-latitude-e6320> In-Reply-To: <51125120.U0YxYHyHTE@scott-latitude-e6320> 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] Simplifying draft-ietf-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, 14 Feb 2012 03:54:30 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Monday, February 13, 2012 6:39 PM > To: marf@ietf.org > Subject: Re: [marf] Simplifying draft-ietf-marf-as >=20 > > There's nothing wrong with writing a DKIM or SPF reporting cookbook, > > but this isn't it. >=20 > Where are applicability statements defined? Section 3.2 of RFC2026. From johnl@iecc.com Mon Feb 13 20:02:35 2012 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 6256621F86CA for ; Mon, 13 Feb 2012 20:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.727 X-Spam-Level: X-Spam-Status: No, score=-109.727 tagged_above=-999 required=5 tests=[AWL=1.472, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ytgBxHbTgfk for ; Mon, 13 Feb 2012 20:02:34 -0800 (PST) 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 8283F21F861E for ; Mon, 13 Feb 2012 20:02:34 -0800 (PST) Received: (qmail 40687 invoked from network); 14 Feb 2012 04:02:33 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Feb 2012 04:02:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f39dcd9.xn--9vv.k1202; i=johnl@user.iecc.com; bh=Alxq11YYpESdfjz2D8CmZCQ9o3DdoBoZNk8zrfF6rgg=; b=hleqO3tg0+ZbvBU7WLm251EM0cNHvIqa8FjZdpMyejLpAehcYLdSurYG3k5/WSz9NvHr0vgAAPHV/1FY0W6AxBHoYmZPiqxTBycjbQ4LMsP+Jyy2Ec+qBL4WX5CngBJ5Jydcr+vNybD80ANXZOkALr2P+Sta8qrsmzKSauOpQxM= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f39dcd9.xn--9vv.k1202; olt=johnl@user.iecc.com; bh=Alxq11YYpESdfjz2D8CmZCQ9o3DdoBoZNk8zrfF6rgg=; b=xOGUXVW6+dp1lFrsrA9vfgfeCWcDPfzLLRoLbDNl5d52yqDsOYX2ekJLtTJ6mvUyVvpgKZgAYcfEAQ23QDqmhb4ZAyUlK68JjZxRfR2+//yKF1qDH1wh7UyNcyccJKutKgch6oPeI1yNaQaUEY4aNmT3GF04BzVOGKEC2kSbb6I= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 14 Feb 2012 04:02:11 -0000 Message-ID: <20120214040211.95564.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <51125120.U0YxYHyHTE@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] Simplifying draft-ietf-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, 14 Feb 2012 04:02:35 -0000 >Where are applicability statements defined? RFC 2026, sections 3.2 and 3.3. From sklist@kitterman.com Mon Feb 13 20:57:09 2012 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 F1FCA21E8043 for ; Mon, 13 Feb 2012 20:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDs+scUAJRGo for ; Mon, 13 Feb 2012 20:57:08 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8E021E802E for ; Mon, 13 Feb 2012 20:57:08 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5DA5920E40BB; Mon, 13 Feb 2012 23:57:07 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329195427; bh=8vx9XaVilTbmDlOMtEO+0qA/iOv7miQavtQ0hc2mAxE=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=cnxc59FXIxci/p+TiRakoAbSbvWdzucqBf4ULFKupTzK2bdBvm1y0IPol8tJtPvOd /LZAsiy1fxDBQJrjcAgv86MIXOmWETF2ueCSP60yC1Cwsfu5MzyolBdpIse+avodUK /yDRrv2zSh26YrV9O1Nq0d6/0ABNwnmIJ1u2tzgg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3EE5F20E408E; Mon, 13 Feb 2012 23:57:07 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Mon, 13 Feb 2012 23:57:06 -0500 Message-ID: <14142915.kamOqp1Um9@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120213154311.68251.qmail@joyce.lan> References: <20120213154311.68251.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Simplifying draft-ietf-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, 14 Feb 2012 04:57:09 -0000 On Monday, February 13, 2012 03:43:11 PM John Levine wrote: > >The diff is here: http://www.blackops.org/~msk/marf-as.html > > Steve and I went through and took out stuff that looks too much like > an implementor's guide rather than an applicability statement. In > particular, we tried to stick to what to accomplish, not how to do it. > > There's nothing wrong with writing a DKIM or SPF reporting cookbook, > but this isn't it. OK. Now that I've read the relevant standard, I'm more convinced than ever this proposed change is a step in the wrong direction. The first section of RFC 2026, paragraph 3.2 says: An Applicability Statement specifies how, and under what circumstances, one or more TSs may be applied to support a particular Internet capability. An AS may specify uses for TSs that are not Internet Standards, as discussed in Section 7. If you look at the old paragraph 8.6 of the AS draft, it says: 6. Similarly, if a report generator applies SPF to arriving messages, and that evaluation produced something other than a "Pass", "None" or "Neutral" result, a report addressed to the RFC5321.MailFrom domain SHOULD NOT be generated as it is probably a forgery and thus not actionable. A valid exception would be specific knowledge that the SPF result is not definitive for that domain under those circumstances (e.g., a message that is also DKIM-signed by the same domain, and that signature validates). To me that reads exactly like a statement about how and under what circumstances one or more technical standards (ARF, DKIM, SPF) may be applied to support a particular internet capability (unsolicitited automatic abuse reports). A DKIM or SPF "cookbook" would describe how to determine the SPF result. This just says what to do with them. It seems exactly right to me. Scott K From johnl@iecc.com Mon Feb 13 21:07:39 2012 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 2477221E804C for ; Mon, 13 Feb 2012 21:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.747 X-Spam-Level: X-Spam-Status: No, score=-109.747 tagged_above=-999 required=5 tests=[AWL=1.452, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k60O3cnXcXl6 for ; Mon, 13 Feb 2012 21:07:33 -0800 (PST) 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 F15BB21E801B for ; Mon, 13 Feb 2012 21:07:32 -0800 (PST) Received: (qmail 75942 invoked from network); 14 Feb 2012 05:07:31 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Feb 2012 05:07:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f39ec13.xn--i8sz2z.k1202; i=johnl@user.iecc.com; bh=sCM4jLqzMB0QcKG7AZQKUxG/RbEghyjvFaFLHKYyh5g=; b=VH82FUSYDTw0O3F8n++EDOof5+S6XUHWdOd7EGIHo2hupWGiEEPQTtdqaUK5DTdC5I51jF8BATdG9y0r/8v+/FGpQtyptcein1vERt3Db8zgn/Z8R2Ur9hysghkF0MqF0zrp9JQmm0Rm94JxqBx8luDG8JCwmcz0Sow4r4kwVUk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f39ec13.xn--i8sz2z.k1202; olt=johnl@user.iecc.com; bh=sCM4jLqzMB0QcKG7AZQKUxG/RbEghyjvFaFLHKYyh5g=; b=X1M6BRUbnlacciqUg5ICDeuJ9eb8VzkGOX+6w7xFP+nfnIukllR9A0BQhVO7VOKZtGiRXc3f4P22U83RIZ63vIIGY7Hk353wshpdpzngvplQfsWUhYbOWhyEovTsHmJrmL3HSqQTdNsot65B/6EqZzf7J++JFTMubya+Yie7MyA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 14 Feb 2012 05:07:09 -0000 Message-ID: <20120214050709.97851.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <14142915.kamOqp1Um9@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] Simplifying draft-ietf-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, 14 Feb 2012 05:07:39 -0000 I completely disagree, but for this document, it's not worth fighting about it. R's, John From vesely@tana.it Tue Feb 14 03:59:50 2012 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 0593321F87D1 for ; Tue, 14 Feb 2012 03:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.636 X-Spam-Level: X-Spam-Status: No, score=-4.636 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhxCkTTuvAmJ for ; Tue, 14 Feb 2012 03:59:49 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id CA7B521F87CF for ; Tue, 14 Feb 2012 03:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1329220787; bh=NFDZpY2RfK/xUoy3gNd6Z58kZOf2NGI4bDDHnjmmPRg=; l=3000; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=GKRIDtjyQjLewlvzgyJSUeoIK+/sdNVYQ4LlcfFwtVlOxh4qoLQucl81N984zCIQL D9RdCVs89/XxNRiHGpgfm0XXkywDu8af3WhzFH+1/qE+fvmI78RLrSVDONHvynt6t+ RfTTcnkl8AnpDs+v4L67J9daIG35RPTdWWX2T1TQ= 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, 14 Feb 2012 12:59:47 +0100 id 00000000005DC042.000000004F3A4CB3.00003C1C Message-ID: <4F3A4CB2.1090807@tana.it> Date: Tue, 14 Feb 2012 12:59:46 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120213154311.68251.qmail@joyce.lan> <14142915.kamOqp1Um9@scott-latitude-e6320> In-Reply-To: <14142915.kamOqp1Um9@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Simplifying draft-ietf-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, 14 Feb 2012 11:59:50 -0000 On 14/Feb/12 05:57, Scott Kitterman wrote: > On Monday, February 13, 2012 03:43:11 PM John Levine wrote: > >> Steve and I went through and took out stuff that looks too much like >> an implementor's guide rather than an applicability statement. In >> particular, we tried to stick to what to accomplish, not how to do it. >> >> There's nothing wrong with writing a DKIM or SPF reporting cookbook, >> but this isn't it. > > OK. Now that I've read the relevant standard, I'm more convinced than ever > this proposed change is a step in the wrong direction. The first section of > RFC 2026, paragraph 3.2 says: > > An Applicability Statement specifies how, and under what > circumstances, one or more TSs may be applied to support a particular > Internet capability. An AS may specify uses for TSs that are not > Internet Standards, as discussed in Section 7. The AS capability aims at RFC 6449, which is formally Informational although it has the appearance and the substance of a BCP. In facts, it was a MAAWG's BCP, and it was decided to keep the document as-is rather than re-discuss it anew. Section 8 is not covered by RFC 6449, it's new stuff. Since RFC 2026 allows an AS to also contain technical specifications, the WG thought it's better to come out with a single RFC rather than split the discourse into multiple documents. > If you look at the old paragraph 8.6 of the AS draft, it says: > > 6. Similarly, if a report generator applies SPF to arriving > messages, and that evaluation produced something other than a > "Pass", "None" or "Neutral" result, a report addressed to the > RFC5321.MailFrom domain SHOULD NOT be generated as it is > probably a forgery and thus not actionable. A valid exception > would be specific knowledge that the SPF result is not > definitive for that domain under those circumstances (e.g., a > message that is also DKIM-signed by the same domain, and that > signature validates). > > To me that reads exactly like a statement about how and under what > circumstances one or more technical standards (ARF, DKIM, SPF) may be applied > to support a particular internet capability (unsolicited automatic abuse > reports). The I-D gives four possible ways to derive a target address. It is probably that that John refers to as "reporting cookbook". I admit it is rather vague and requires some wit to get right. The style of Section 8 is to tell what to accomplish by describing possibilities and restraints, so as to sketch the way. For a justification, the way is large enough to allow some degrees of freedom, yet not so well paved as to grant running through any path on it. Is that style (or level of detail) acceptable? I propose we review the bluish-background passages in the diff, one component at a time, starting with Section 8, making use of that cool professionalism that we are famous for. Given that we all share the same goal, we can well do it within the time frame that Barry said. From vesely@tana.it Tue Feb 14 04:49:58 2012 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 B2F9821F87C3 for ; Tue, 14 Feb 2012 04:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.637 X-Spam-Level: X-Spam-Status: No, score=-4.637 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsi44-TmE+GA for ; Tue, 14 Feb 2012 04:49:58 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D3CD621F87A7 for ; Tue, 14 Feb 2012 04:49:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1329223796; bh=HxLvPyf4FY/tOK/jit7eywTxcBB5hPvy6XI/W402Mew=; l=1942; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=SZpfc3NLc49ZHjnSJjlfhMUuQQmRPHT0jW4AvC9BdwGvoZS42w0+7aPIpZC+keFWh qki6qt3PetMJvdqoYXKQ4VCH4poeli7v9l2llHdSYeZT2e6bnj9Bd9mla2vJg0a9w6 kcTHxr5MgjwmnWKq+iUGKAELu9ujkLtkTVkte8jk= 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, 14 Feb 2012 13:49:56 +0100 id 00000000005DC042.000000004F3A5874.00004821 Message-ID: <4F3A5874.4090604@tana.it> Date: Tue, 14 Feb 2012 13:49:56 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [marf] "Such criteria might include...", was coming back 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, 14 Feb 2012 12:49:58 -0000 This is the first of nine (connected, blu background) diff components of Section 8. Section 8 starts saying that Systems that generate unsolicited reports SHOULD ensure that the criteria used to decide what messages to report accurately identify messages that the reporting entity believes in good faith are abusive. The mutilated version just adds "and are sent only to parties that are able to act on them". This recommendation looks similar to the concept in the last paragraph. Its role here could express the concern that messages to be reported were actually received by the reporting entity, not forwarded from some other account. The published version, instead, exemplifies some criteria, thereby adding automatic triggers to the original TiS-button criterion: Such criteria might include direct complaint submissions from MUAs, reports triggered by mail sent to "spam trap" or "honeypot" addresses, and virus reports. (These applications might be described in future IETF documents.) At a minimum, we should keep TiS buttons, in order to match paragraph 1 of Section 6. IMHO, the next sentence can be safely eliminated: Systems SHOULD NOT report all mail sent from a particular sender merely because some of it is determined to be abusive. Finally, version-08 says to avoid sending Bayesian scores: Mechanical reports of mail that "looks like" spam, based solely on the results of inline content analysis tools, SHOULD NOT be sent since, because of their subjective nature, they are unlikely to provide a basis for the recipient to take action. IMHO, that "SHOULD NOT" is good for unsolicited reports, because attempts to establish a reporting channel deserve solid reasons. I don't agree on the given explanation, but can live with it. Comments? On 14/Feb/12 00:05, Barry Leiba wrote: > > I consider that the AS document is back to "active document" state. From shmuel+gen@patriot.net Tue Feb 14 06:21:06 2012 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 C687D21F879D for ; Tue, 14 Feb 2012 06:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.745 X-Spam-Level: X-Spam-Status: No, score=-1.745 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wkOtI+dhknQ for ; Tue, 14 Feb 2012 06:21:02 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id A057521F87B4 for ; Tue, 14 Feb 2012 06:21:01 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.188]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id B1057F5808F for ; Tue, 14 Feb 2012 09:06:17 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 13 Feb 2012 22:18:10 -0500 To: marf@ietf.org In-Reply-To: <20120213213656.80676.qmail@joyce.lan> Mail-Copies-To: nobody 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: <20120214140617.B1057F5808F@smtp.patriot.net> Subject: Re: [marf] meaning of signatures, was I-D Action: draft-ietf-marf-as-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 14:21:06 -0000 In <20120213213656.80676.qmail@joyce.lan>, on 02/13/2012 at 09:36 PM, "Bank Security" said: >This makes no sense at all. DKIM and SPF do authentication right >now. If for some reason you want authentication of the From: line, >you know where to find Sender-ID or DMARC. That's tied to the IP address. >You can tell that the From: line is tied to a DNS entry, but you >can't tell from that DNS entry whether the sender is the person who >he claims to be, or whether his intent is to phish you or tell you >that your bank account really is overdrawn. We're still talking at cross purposes. I'm talking about the posibility of the sender providing a field that contains text encrypted with a private key and the receiver attempting to decrypt it using a public key. I'm not addressing the issue of associating the sender with an organization, just with his right to use the domain in the header. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From barryleiba.mailing.lists@gmail.com Tue Feb 14 08:26:19 2012 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 B1F5A21F86EF for ; Tue, 14 Feb 2012 08:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.958 X-Spam-Level: X-Spam-Status: No, score=-102.958 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xk0gf6EZwdwI for ; Tue, 14 Feb 2012 08:26:18 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id BEDC221F86E2 for ; Tue, 14 Feb 2012 08:26:18 -0800 (PST) Received: by ggnq2 with SMTP id q2so114471ggn.31 for ; Tue, 14 Feb 2012 08:26:18 -0800 (PST) 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=1/dBd6yrl0pSMNE/hzfu86Z87pTdH7xb0lFhvoIjWL4=; b=PkPX8zU0EOpzinG6b7TYm0ARzhRZYxU4y25PYorNL4GdR8kMbxIFUHF9Cn5AezBHfA qlJw2m2xny58rDlHY8pFZpYaptKVy09NznqrCMmexOy8yoTEGMcpkUlIht9SQNMA94ul B9ZMz+yF6lMPrrXqMUP+8fMdjoifC0OHYW6U4= MIME-Version: 1.0 Received: by 10.236.124.66 with SMTP id w42mr27745522yhh.23.1329236778426; Tue, 14 Feb 2012 08:26:18 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Tue, 14 Feb 2012 08:26:18 -0800 (PST) In-Reply-To: <14142915.kamOqp1Um9@scott-latitude-e6320> References: <20120213154311.68251.qmail@joyce.lan> <14142915.kamOqp1Um9@scott-latitude-e6320> Date: Tue, 14 Feb 2012 11:26:18 -0500 X-Google-Sender-Auth: ASDqajExKhK--xhqKVfPFQ5gaQw Message-ID: From: Barry Leiba To: Message Abuse Report Format working group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [marf] Simplifying draft-ietf-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, 14 Feb 2012 16:26:19 -0000 >> Steve and I went through and took out stuff that looks too much like >> an implementor's guide rather than an applicability statement. =A0In >> particular, we tried to stick to what to accomplish, not how to do it. >> >> There's nothing wrong with writing a DKIM or SPF reporting cookbook, >> but this isn't it. > > OK. =A0Now that I've read the relevant standard, I'm more convinced than = ever > this proposed change is a step in the wrong direction. =A0The first secti= on of > RFC 2026, paragraph 3.2 says: I can give the WG my opinion, as a contributor, a chair, and now an AD, on what an Applicability Statement should be. We have little recent experience with the AS idea -- its function has mostly been either included in Technical Specifications (TS), pushed into a non-standards-track Informational document (as in the DKIM operational guide), or published as a BCP. A TS, such as RFC 5965 (MARF base), is meant to describe the details of the protocol, while an AS is for explaining how to use the protocol in practice. It's often difficult to decide where to draw the line between what should go in the TS and what qualifies as AS material. But I think there's a lot of flexibility in deciding what qualifies for an AS. As chair (and, soon, as AD), my opinion goes toward inclusion. The working group has to decide what it has rough consensus to include, of course. That said, I recommend that it include what advice would be useful to use these protocols to best effect and greatest level of interoperability in the real world... considering that this advice can advance along the standards track along with the protocol documents themselves, getting revisions as appropriate along the way (which is one thing that distinguishes an AS from a BCP). Because the AS is a Standards Track document, it theoretically carries more weight than an Informational document, and the WG should consider what should be specified as advice on the Standards Track, and what really *is* just information. That said, purely informational content can be included in the AS and be so labelled. But stuff that's important to getting your abuse reports done right and accepted by report consumers should be in here. Stuff that's important to report consumers for correctly handling abuse reports should be in here. I'm not sure why there's such a strong desire among some to eliminate text, so perhaps you can explain that. My preference (as a participant), and my advice (as a chair) is to include more information, as long, of course, as we think that information is correct. If we're cutting content because we don't agree with it, we should do that. If we're cutting content just to make the document shorter, I question the need for that. If we're cutting content because we think an "AS" shouldn't have that sort of stuff in it, let's think about that carefully, and explain why. If it helps implementors get things right and interoperate better, or helps implementors better understand how multiple standards work together, I think it's exactly what belongs in an AS. Barry From msk@cloudmark.com Tue Feb 14 09:26:55 2012 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 16AB521F8763 for ; Tue, 14 Feb 2012 09:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLujcmKW64Ei for ; Tue, 14 Feb 2012 09:26:54 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id A739E21F8789 for ; Tue, 14 Feb 2012 09:26:54 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 14 Feb 2012 09:26:54 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 14 Feb 2012 09:26:54 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Tue, 14 Feb 2012 09:26:52 -0800 Thread-Topic: [marf] meaning of signatures, was I-D Action: draft-ietf-marf-as-07.txt Thread-Index: AczrI+ZJgs1+G9UTR0mGWTh586+/twAGdFsw Message-ID: References: <20120213213656.80676.qmail@joyce.lan> <20120214140617.B1057F5808F@smtp.patriot.net> In-Reply-To: <20120214140617.B1057F5808F@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] meaning of signatures, was I-D Action: draft-ietf-marf-as-07.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, 14 Feb 2012 17:26:55 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Monday, February 13, 2012 7:18 PM > To: marf@ietf.org > Subject: Re: [marf] meaning of signatures, was I-D Action: draft-ietf-mar= f-as-07.txt >=20 > We're still talking at cross purposes. I'm talking about the posibility > of the sender providing a field that contains text encrypted with a > private key and the receiver attempting to decrypt it using a public > key. I'm not addressing the issue of associating the sender with an > organization, just with his right to use the domain in the header. I believe this is off-topic for MARF. Please don't reply to this thread un= less you have an argument to make that it's germane to one of the documents= under development. -MSK, as co-chair From msk@cloudmark.com Tue Feb 14 09:34:11 2012 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 86E4521F87A3 for ; Tue, 14 Feb 2012 09:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVJEAj6SHbTm for ; Tue, 14 Feb 2012 09:34:10 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8AADF21F879D for ; Tue, 14 Feb 2012 09:34:10 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 14 Feb 2012 09:34:10 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 14 Feb 2012 09:34:10 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 14 Feb 2012 09:34:09 -0800 Thread-Topic: [marf] Message bodies in ARF reports Thread-Index: AczqhXDOSC6cDwIBRH+h0R7tvM6FAgAuNwSQ Message-ID: References: <2687617.GuVsQiVKMe@scott-latitude-e6320> <20120213154132.68179.qmail@joyce.lan> <8577772.BrpObzDUBN@scott-latitude-e6320> In-Reply-To: <8577772.BrpObzDUBN@scott-latitude-e6320> 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] Message bodies in ARF reports 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, 14 Feb 2012 17:34:11 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Monday, February 13, 2012 11:27 AM > To: marf@ietf.org > Subject: Re: [marf] Message bodies in ARF reports >=20 > > > ARF is a version of multipart/report as defined in RFC 3462. In > > > that document, the message/rfc822 or message/headers is optional. > > > In RFC 5965, we made it mandatory in section 2.d. We did that > > > because the usage scenario we were thinking of was spam button > > > reports where you always have a message in hand, not for any deeper r= eason. > > > > > > You are of course correct that SPF failures sometimes don't accept > > > the message. I'd be willing to file an erratum that 2.d. should > > > have said that the report MUST include the message if the reporting > > > entity has received it. > > > > I'd support that. >=20 > That's great. Is MUST include if you have ... or SHOULD include > (unless you do not have ...) a better construction? I thought the > trend in IETF documents was away from MUSTs if they weren't essential. I'd prefer "MUST ... unless" for this one. I'm not sure I can explain why = though. This one's for Barry: Can a Standards Track document contradict another one= on the basis of an accepted erratum? Or should we do a quick update to RF= C5965 (not a "bis", just a standards-track correction)? > > I'd also support the idea that an SPF report can synthesize the > > text/rfc822-headers for a message whose content has not actually arrive= d. > > All you legally need is a From: field as I recall, and that can be > > generated based on the rejected RFC5321.MailFrom. >=20 > If by 'synthesize' you mean 'assume the RFC5321.MailFrom and the > FRC5322.From are the same', then yes, it could do that. That's not the > same as saying I think it's a good idea. In cases where this heuristic > is wrong (I've seen numbers between 5% and 20% of mail), it will > probably be deeply confusing to receivers of such reports. I don't > think we should. Yeah, I realize it's not guaranteed to be right. It's a question of what f= its within the rules. We could certainly say in the SPF reporting document= that the synthesized third part is based on the envelope only and thus cou= ld be a misrepresentation of what was really in the (rejected) message. Of= course if the message failed SPF but was still delivered, the content is a= vailable anyway. -MSK From barryleiba.mailing.lists@gmail.com Tue Feb 14 09:46:45 2012 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 32B5921E80A4 for ; Tue, 14 Feb 2012 09:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.958 X-Spam-Level: X-Spam-Status: No, score=-102.958 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bstvTVlJawP7 for ; Tue, 14 Feb 2012 09:46:44 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5233F21E8051 for ; Tue, 14 Feb 2012 09:46:44 -0800 (PST) Received: by ggnq2 with SMTP id q2so192782ggn.31 for ; Tue, 14 Feb 2012 09:46:41 -0800 (PST) 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=ebFFaqnjyeWDWpef1aKjpxPCWDk1fc16zCZxj2DDMdY=; b=FiRxKHZrBWU9CccESAv8NBIo+HdW6sJsFbRjOqaUKBAtdtCF3TTkhIE0I7Txys35cK E8aynOviWfoQxFGQOc+Xf0idcIQoUACVFzp/suVE/u5TLMH3eijUKuMZaRenRPzh+gLp SAaN9Zc5HqotQRvTZgZV9JKp0IeDaCOeLUuX4= MIME-Version: 1.0 Received: by 10.236.191.100 with SMTP id f64mr2634187yhn.57.1329241601749; Tue, 14 Feb 2012 09:46:41 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Tue, 14 Feb 2012 09:46:41 -0800 (PST) In-Reply-To: References: <2687617.GuVsQiVKMe@scott-latitude-e6320> <20120213154132.68179.qmail@joyce.lan> <8577772.BrpObzDUBN@scott-latitude-e6320> Date: Tue, 14 Feb 2012 12:46:41 -0500 X-Google-Sender-Auth: aR4tFoQv_RJIN38k3h4O-v29bDA 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] Message bodies in ARF reports 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, 14 Feb 2012 17:46:45 -0000 > This one's for Barry: Can a Standards Track document contradict another > one on the basis of an accepted erratum? =A0Or should we do a quick updat= e > to RFC5965 (not a "bis", just a standards-track correction)? The second (contradicting) S-T document can be the one to do the "quick update" (you don't need a separate document to do it). Just make it "Updates 5965", include text in the introduction that says it updates 5965 to change XYZ, and then in the normative text where you make the contradiction, add a sentence that says "This updates the requirement [or whatever] in RFC 5965." b From vesely@tana.it Tue Feb 14 09:59:34 2012 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 3452221F863B for ; Tue, 14 Feb 2012 09:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.64 X-Spam-Level: X-Spam-Status: No, score=-4.64 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onB751T2QURR for ; Tue, 14 Feb 2012 09:59:33 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC2521F8629 for ; Tue, 14 Feb 2012 09:59:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1329242372; bh=TKzKCg9BnqYmfiytHL71zCJrPF1xpsw0z8gPwudu9hY=; l=1365; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=HSDk5J+CfCW2jxvJPnL4Ha/hOa6qzk1MD/v9JG30mmRrFflku0c2n6lOGyjpy676g C79tvZFtYFNAIYmJKMBDJ2A0Qfrd5rhEjVoYx3zg+XtwFTAtUh8ZSQoF8k2hoJRR/s ZEFT5qCDvcrnCgzfL/UaKHk5EgVuvJ9kSHvK/m1E= 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, 14 Feb 2012 18:59:32 +0100 id 00000000005DC03F.000000004F3AA104.00001550 Message-ID: <4F3AA104.3040502@tana.it> Date: Tue, 14 Feb 2012 18:59:32 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <2687617.GuVsQiVKMe@scott-latitude-e6320> <20120213154132.68179.qmail@joyce.lan> <8577772.BrpObzDUBN@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Message bodies in ARF reports 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, 14 Feb 2012 17:59:34 -0000 On 14/Feb/12 18:34, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Scott Kitterman >> >>>> You are of course correct that SPF failures sometimes don't accept >>>> the message. I'd be willing to file an erratum that 2.d. should >>>> have said that the report MUST include the message if the reporting >>>> entity has received it. >>> >>> I'd support that. >> >> That's great. Is MUST include if you have ... or SHOULD include >> (unless you do not have ...) a better construction? I thought the >> trend in IETF documents was away from MUSTs if they weren't essential. > > I'd prefer "MUST ... unless" for this one. I'm not sure I can > explain why though. We could get away with "... unless an extension specifies otherwise". > This one's for Barry: Can a Standards Track document contradict > another one on the basis of an accepted erratum? Or should we do a > quick update to RFC5965 (not a "bis", just a standards-track > correction)? IMHO we have to change authfailure-report anyway. Section 3.1 says: The third MIME part of the message is either of type "message/rfc822" (as defined in [MIME-TYPES]) or "text/rfc822-headers" (as defined in [REPORT]) and contains a copy of the entire header block from the original message. This part MUST be included (contrary to [REPORT], which makes it optional). jm2c From msk@cloudmark.com Tue Feb 14 10:10:23 2012 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 48DDE21F8742 for ; Tue, 14 Feb 2012 10:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7x6E4VLZAbsp for ; Tue, 14 Feb 2012 10:10:22 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id B190221F873A for ; Tue, 14 Feb 2012 10:10:22 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 14 Feb 2012 10:10:22 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 14 Feb 2012 10:10:21 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 14 Feb 2012 10:10:20 -0800 Thread-Topic: [marf] Message bodies in ARF reports Thread-Index: AczrQm0P0oj6cZO4QcSCl9tzoZbo1QAAWm+Q Message-ID: References: <2687617.GuVsQiVKMe@scott-latitude-e6320> <20120213154132.68179.qmail@joyce.lan> <8577772.BrpObzDUBN@scott-latitude-e6320> <4F3AA104.3040502@tana.it> In-Reply-To: <4F3AA104.3040502@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] Message bodies in ARF reports 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, 14 Feb 2012 18:10:23 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Tuesday, February 14, 2012 10:00 AM > To: marf@ietf.org > Subject: Re: [marf] Message bodies in ARF reports >=20 > IMHO we have to change authfailure-report anyway. Section 3.1 says: >=20 > The third MIME part of the message is either of type "message/rfc822" > (as defined in [MIME-TYPES]) or "text/rfc822-headers" (as defined in > [REPORT]) and contains a copy of the entire header block from the > original message. This part MUST be included (contrary to [REPORT], > which makes it optional). The synthesis option handles this, if we want to go that way. From wwwrun@rfc-editor.org Tue Feb 14 10:31:00 2012 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 99E6621F86E1 for ; Tue, 14 Feb 2012 10:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NhbWTQGDlLi for ; Tue, 14 Feb 2012 10:31:00 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id B753921F86F2 for ; Tue, 14 Feb 2012 10:30:58 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6571072F1F1; Tue, 14 Feb 2012 10:26:16 -0800 (PST) To: ietf@shaftek.org, standards@taugh.com, msk@cloudmark.com, presnick@qualcomm.com, barryleiba@computer.org, stpeter@stpeter.im, barryleiba@computer.org, msk@cloudmark.com From: RFC Errata System Message-Id: <20120214182616.6571072F1F1@rfc-editor.org> Date: Tue, 14 Feb 2012 10:26:16 -0800 (PST) X-Mailman-Approved-At: Tue, 14 Feb 2012 10:31:43 -0800 Cc: rfc-editor@rfc-editor.org, standards@taugh.com, marf@ietf.org Subject: [marf] [Technical Errata Reported] RFC5965 (3120) 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, 14 Feb 2012 18:31:00 -0000 The following errata report has been submitted for RFC5965, "An Extensible Format for Email Feedback Reports". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5965&eid=3120 -------------------------------------- Type: Technical Reported by: John Levine Section: 2.d. Original Text ------------- This part MUST be included (contrary to [REPORT]) Corrected Text -------------- This part MUST be included if the entity creating the report has received the message. Notes ----- Reports can be created from info collected in SMTP transactions that don't accept a message, a scenario we didn't consider when we wrote this section. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5965 (draft-ietf-marf-base-06) -------------------------------------- Title : An Extensible Format for Email Feedback Reports Publication Date : August 2010 Author(s) : Y. Shafranovich, J. Levine, M. Kucherawy Category : PROPOSED STANDARD Source : Messaging Abuse Reporting Format Area : Applications Stream : IETF Verifying Party : IESG From johnl@iecc.com Tue Feb 14 10:33:12 2012 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 E348321E80A2 for ; Tue, 14 Feb 2012 10:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.767 X-Spam-Level: X-Spam-Status: No, score=-109.767 tagged_above=-999 required=5 tests=[AWL=1.432, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEvZJdHX0Q3H for ; Tue, 14 Feb 2012 10:33:11 -0800 (PST) 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 012AC21E809B for ; Tue, 14 Feb 2012 10:33:09 -0800 (PST) Received: (qmail 63477 invoked from network); 14 Feb 2012 18:33:08 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Feb 2012 18:33:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f3aa8e4.xn--3zv.k1202; i=johnl@user.iecc.com; bh=qTU1cGfD4nc8fO9nJuIkirFGl7v8Wh4QxG0DnjcinBw=; b=SQbzOZNn23mfsvkU7JmkxI7sR3cunw62thvkzQj6ZyDdVOsiFTmWezdJ6cpKm//jfVzrVSKHz/a5cuZH3SrCTtIRu5n4jgWAcok6tTuUPPINU77MSxQX9+q8mylNWhX7VWxPuNRgryt/X+KxEECEQDArchb+aXH9+3M5Dz+tfwE= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f3aa8e4.xn--3zv.k1202; olt=johnl@user.iecc.com; bh=qTU1cGfD4nc8fO9nJuIkirFGl7v8Wh4QxG0DnjcinBw=; b=rtmjxvEu6xIU6ObKrL8ewGuyqfhmgUmJLtP6lDtfyuBeeFChSYyFvkfFkM90+kYmbiV9eaM6mVVzeTfPzw+rzYghsFsV6YkttcSFZld43kR48Qx14cgWrvuclAaGyZK5qshmbMN84AB7l5LnIo1mv/J6mB2bCNN7DPW9MwF2UeA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 14 Feb 2012 18:32:46 -0000 Message-ID: <20120214183246.27478.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] Message bodies in ARF reports 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, 14 Feb 2012 18:33:12 -0000 > I'd also support the idea that an SPF report can synthesize the > text/rfc822-headers for a message whose content has not actually arrived. > All you legally need is a From: field as I recall, and that can be > generated based on the rejected RFC5321.MailFrom. I think that would cause far more confusion than enlightenment. The kind of analysis I do on ARFs looks for specific quirks of the headers that my software adds. If it doesn't find them, it'll discard the whole report as bogus. Better to send no headers than fake ones. Since it's fine for any other multipart/report to omit the copy of the message, seems to me a lot tidier just to fix 5965 to be consistent. Based on my prior experience with errata, it's OK to use the corrected version of the doc as a base for future work without recycling. In RFC 5518 we made a fairly bad mistake, saying that you use the i= rather than d= in a DKIM result. We fixed that with an erratum, seems to be OK. R's, John From sklist@kitterman.com Tue Feb 14 10:33:39 2012 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 9F11F21E8080 for ; Tue, 14 Feb 2012 10:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rl4530bo2f2u for ; Tue, 14 Feb 2012 10:33:39 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E5CE621E8058 for ; Tue, 14 Feb 2012 10:33:38 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7FC3A20E40BB; Tue, 14 Feb 2012 13:33:38 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329244418; bh=JPRxm4fxvq958j8062BLbrHZOWNbycTZzm+7/0HdtbY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=PDAS+RKId6oKEwkB7d0YM4C7MMdykuitO/GnfPw6/UisrFmjNY3F+1Pj04bWw8tj5 jkfl4VpNdLNmxp3BAr/Lyo9wdM44yVCsOX/ljhFz8YfmBS/exqHizxZ0yLU8H5G+bC E//fu+BsMQ884P5V05ge/CF95bvaa+foR0euvOdU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7198520E4099; Tue, 14 Feb 2012 13:33:38 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Tue, 14 Feb 2012 13:33:38 -0500 Message-ID: <1808577.DjigAfslBR@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120214182616.6571072F1F1@rfc-editor.org> References: <20120214182616.6571072F1F1@rfc-editor.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] [Technical Errata Reported] RFC5965 (3120) 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, 14 Feb 2012 18:33:39 -0000 On Tuesday, February 14, 2012 10:26:16 AM RFC Errata System wrote: > The following errata report has been submitted for RFC5965, > "An Extensible Format for Email Feedback Reports". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5965&eid=3120 > > -------------------------------------- > Type: Technical > Reported by: John Levine > ... John, Thanks for taking care of reporting it. Scott K From vesely@tana.it Tue Feb 14 10:55:30 2012 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 21A4F21E8087 for ; Tue, 14 Feb 2012 10:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.641 X-Spam-Level: X-Spam-Status: No, score=-4.641 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgMsQN8CH4c9 for ; Tue, 14 Feb 2012 10:55:29 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 52D4321F877B for ; Tue, 14 Feb 2012 10:55:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1329245728; bh=6lolkOlNOGlxW+Tiju8rPwGGqdcc68oxaCR3upWX1Sw=; l=593; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=hWwuRcmTUBfCNYOeEdSBhsZ3c50COHe6ffItanLuAbpm0yZr04kRUwPIulAgfTPts yd1MCRdSh+eQQe/HCGxRTR+AtCqiZSuKPSX/AXhNro6WxWjiKi+0bgPtCypxNLHc4a 5tZi7Kss+Lrj3rhHgg1T2wJFOhwe1yXmBEZj+8n4= 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, 14 Feb 2012 19:55:28 +0100 id 00000000005DC03F.000000004F3AAE20.0000241C Message-ID: <4F3AAE1F.7040503@tana.it> Date: Tue, 14 Feb 2012 19:55:27 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <2687617.GuVsQiVKMe@scott-latitude-e6320> <20120213154132.68179.qmail@joyce.lan> <8577772.BrpObzDUBN@scott-latitude-e6320> <4F3AA104.3040502@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Message bodies in ARF reports 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, 14 Feb 2012 18:55:30 -0000 On 14/Feb/12 19:10, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely > >> IMHO we have to change authfailure-report anyway. Section 3.1 says: >> >> The third MIME part of the message is either of type "message/rfc822" >> (as defined in [MIME-TYPES]) or "text/rfc822-headers" (as defined in >> [REPORT]) and contains a copy of the entire header block from the >> original message. This part MUST be included (contrary to [REPORT], >> which makes it optional). > > The synthesis option handles this, if we want to go that way. Which "synthesis option"? From msk@cloudmark.com Tue Feb 14 11:12:45 2012 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 D1B3E21F855F for ; Tue, 14 Feb 2012 11:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZ6b38JWQrs1 for ; Tue, 14 Feb 2012 11:12:45 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id E6C7021F855B for ; Tue, 14 Feb 2012 11:12:44 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 14 Feb 2012 11:12:44 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 14 Feb 2012 11:12:44 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 14 Feb 2012 11:12:42 -0800 Thread-Topic: [marf] Message bodies in ARF reports Thread-Index: AczrSj1tVtgJgiNVQVy2MfzLf3FjLAAAllgg Message-ID: References: <2687617.GuVsQiVKMe@scott-latitude-e6320> <20120213154132.68179.qmail@joyce.lan> <8577772.BrpObzDUBN@scott-latitude-e6320> <4F3AA104.3040502@tana.it> <4F3AAE1F.7040503@tana.it> In-Reply-To: <4F3AAE1F.7040503@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] Message bodies in ARF reports 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, 14 Feb 2012 19:12:46 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Tuesday, February 14, 2012 10:55 AM > To: marf@ietf.org > Subject: Re: [marf] Message bodies in ARF reports >=20 > >> The third MIME part of the message is either of type "message/rfc822" > >> (as defined in [MIME-TYPES]) or "text/rfc822-headers" (as defined in > >> [REPORT]) and contains a copy of the entire header block from the > >> original message. This part MUST be included (contrary to [REPORT], > >> which makes it optional). > > > > The synthesis option handles this, if we want to go that way. >=20 > Which "synthesis option"? http://www.ietf.org/mail-archive/web/marf/current/msg02109.html From msk@cloudmark.com Tue Feb 14 11:14:11 2012 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 6F3B721E801B for ; Tue, 14 Feb 2012 11:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzQLwLGy0AAH for ; Tue, 14 Feb 2012 11:14:10 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id AA2F621F8710 for ; Tue, 14 Feb 2012 11:14:10 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 14 Feb 2012 11:14:10 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 14 Feb 2012 11:14:09 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 14 Feb 2012 11:14:09 -0800 Thread-Topic: [marf] Message bodies in ARF reports Thread-Index: AczrRx97F5ArSB+aQvClkzVibuNXsAABZiDw Message-ID: References: <20120214183246.27478.qmail@joyce.lan> In-Reply-To: <20120214183246.27478.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [marf] Message bodies in ARF reports 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, 14 Feb 2012 19:14:11 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQHRhdWdoLmNvbV0NCj4gU2VudDogVHVlc2RheSwgRmVicnVhcnkgMTQsIDIwMTIgMTA6 MzMgQU0NCj4gVG86IG1hcmZAaWV0Zi5vcmcNCj4gQ2M6IE11cnJheSBTLiBLdWNoZXJhd3kNCj4g U3ViamVjdDogUmU6IFttYXJmXSBNZXNzYWdlIGJvZGllcyBpbiBBUkYgcmVwb3J0cw0KPiANCj4g U2luY2UgaXQncyBmaW5lIGZvciBhbnkgb3RoZXIgbXVsdGlwYXJ0L3JlcG9ydCB0byBvbWl0IHRo ZSBjb3B5IG9mIHRoZQ0KPiBtZXNzYWdlLCBzZWVtcyB0byBtZSBhIGxvdCB0aWRpZXIganVzdCB0 byBmaXggNTk2NSB0byBiZSBjb25zaXN0ZW50Lg0KPiANCj4gQmFzZWQgb24gbXkgcHJpb3IgZXhw ZXJpZW5jZSB3aXRoIGVycmF0YSwgaXQncyBPSyB0byB1c2UgdGhlIGNvcnJlY3RlZA0KPiB2ZXJz aW9uIG9mIHRoZSBkb2MgYXMgYSBiYXNlIGZvciBmdXR1cmUgd29yayB3aXRob3V0IHJlY3ljbGlu Zy4gIEluIFJGQw0KPiA1NTE4IHdlIG1hZGUgYSBmYWlybHkgYmFkIG1pc3Rha2UsIHNheWluZyB0 aGF0IHlvdSB1c2UgdGhlIGk9IHJhdGhlcg0KPiB0aGFuIGQ9IGluIGEgREtJTSByZXN1bHQuICBX ZSBmaXhlZCB0aGF0IHdpdGggYW4gZXJyYXR1bSwgc2VlbXMgdG8gYmUNCj4gT0suDQoNClNvIGRv IHdlIG5lZWQgdG8gc2F5ICJVcGRhdGVzIFJGQzU5NjUiIGluIFNjb3R0J3MgZHJhZnQsIHBlcmhh cHMgcG9pbnRpbmcgYXQgdGhlIGVycmF0dW0gaW4gYW4gYXBwZW5kaXggb3Igc29tZXRoaW5nLCBq dXN0IHRvIHRpZSBpdCBhbGwgdG9nZXRoZXI/DQoNCg== From sm@resistor.net Tue Feb 14 12:32:40 2012 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 7CAE321F84D1 for ; Tue, 14 Feb 2012 12:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.623 X-Spam-Level: X-Spam-Status: No, score=-102.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IAlKT4Nmpk0 for ; Tue, 14 Feb 2012 12:32:39 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9149721F847F for ; Tue, 14 Feb 2012 12:32:39 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1EKWYmC003988 for ; Tue, 14 Feb 2012 12:32:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329251559; i=@resistor.net; bh=NdQZpcDKqrF+u2BO2LY3zbP+NIztL1Nt7wusLz4zLQc=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=0JfOrq5hMvt4r6+4HF8IyF+1byCA7qMY95L2zuaE8tW7g6VYDSv5bcYHt2Iae4Y9L FDW8nMaQf0nqRxqQFiPwIlWAtMt2dPNHC1lNjblwGBed/a6fLvEAV5/A9jR20+vAI4 faWXkb1+nExvO+LuHd1Vetscrv5XYA1LOF9kRYRE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1329251559; i=@resistor.net; bh=NdQZpcDKqrF+u2BO2LY3zbP+NIztL1Nt7wusLz4zLQc=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=u1AJ4TFI2Ich4ppm329AytTfUZo7V5nH+jvVYRinUxG5WqgMXFZUCL6dUm+pDD7x1 BxgILcTrmVM8O5xu7+33JPN3LOLHWVAUSY6VRJhfyIzP9QEormTwkROCSsQ1ly40hf 3C2m0AuRFqUJc7vPt3kz6zmtNeerFtmK3kOu3d6U= Message-Id: <6.2.5.6.2.20120214112826.09ec1d48@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 14 Feb 2012 12:32:32 -0800 To: Message Abuse Report Format working group From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as... expired, and coming back 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, 14 Feb 2012 20:32:40 -0000 Hello, As this is late feedback, please consider all the comments are optional. The comments are based on the diff posted by Murray. The title mentions "An Applicability Statement for the Abuse Reporting Format". I don't see that mentioned in the Abstract Section. From RFC 2606, "An Applicability Statement specifies how, and under what circumstances, one or more TSs may be applied to support a particular Internet capability". This draft updates RFC 5965, a Proposed Standard. Why is this draft an Applicability Statement? In Section 2, I suggest "POP3" instead of "POP". In the first paragraph of Section 6, "identify". "The Mailbox Provider SHOULD process the reports to improve its spam filtering systems." This is not required for interoperability. "3. The Mailbox Provider SHOULD send reports to relevant parties who have requested to receive such reports. To implement the recommendations of this memo, the reports MUST be formatted per [RFC5965], and transmitted as an email message ([RFC5322]), typically using SMTP ([RFC5321]). The process whereby such parties may request the reports is discussed in Section 3.5 of [RFC6449]." Picking the above as an example, Section 3.5 of RFC 6449 discusses about "Handling Requests to Receive Feedback". I would reference the technology, e.g. RFC 5321, and document requirements about how the technology should be used. The text quoted above comes out as a BCP. "The reports SHOULD include the following optional fields whenever practical: Original-Mail-From, Arrival-Date, Source-IP, Original- Rcpt-To. Other optional fields MAY be included, as the implementer feels is appropriate." The above qualifies as applicability as it specifies a recommendation for fields which are optional in a Technical Specification. In Section 7, first paragraph, "identify". Same for Section 8. In Section 9: "command SHOULD use the NULL return address" That should be Reverse-Path. I am confused after reading the draft. It comes out as a mix of recipes. IETF practice is to send text. I don't know where to start. Regards, -sm From msk@cloudmark.com Tue Feb 14 12:41:21 2012 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 C494E21E80C9 for ; Tue, 14 Feb 2012 12:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nI0gw9WHECRj for ; Tue, 14 Feb 2012 12:41:21 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 04E4E21E80E2 for ; Tue, 14 Feb 2012 12:41:21 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 14 Feb 2012 12:41:20 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 14 Feb 2012 12:41:20 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Tue, 14 Feb 2012 12:41:19 -0800 Thread-Topic: [marf] Working Group Last Call on draft-ietf-marf-as... expired, and coming back Thread-Index: AczrV84Ta5lBGFryQ+G3bJVKhJWRcAAAGgyQ Message-ID: References: <6.2.5.6.2.20120214112826.09ec1d48@resistor.net> In-Reply-To: <6.2.5.6.2.20120214112826.09ec1d48@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as... expired, and coming back 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, 14 Feb 2012 20:41:21 -0000 As Barry said, this document is back to being in plain old "WG Document" as= we take another round of developing it. > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= M > Sent: Tuesday, February 14, 2012 12:33 PM > To: Message Abuse Report Format working group > Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as... expi= red, and coming back >=20 > The title mentions "An Applicability Statement for the Abuse Reporting > Format". I don't see that mentioned in the Abstract Section. Easily fixed. > From RFC 2606, "An Applicability Statement specifies how, and under > what circumstances, one or more TSs may be applied to support a > particular Internet capability". This draft updates RFC 5965, a > Proposed Standard. Why is this draft an Applicability Statement? I think it fits that definition. The "Updates" is appropriate in that if o= ne is implementing RFC5965, one should also read this draft. > In Section 2, I suggest "POP3" instead of "POP". OK. > In the first paragraph of Section 6, "identify". >=20 > "The Mailbox Provider SHOULD process the reports to improve its > spam filtering systems." >=20 > This is not required for interoperability. Sounds like a job for the non-normative SHOULD-like words draft! > "3. The Mailbox Provider SHOULD send reports to relevant parties who > have requested to receive such reports. To implement the > recommendations of this memo, the reports MUST be formatted per > [RFC5965], and transmitted as an email message ([RFC5322]), > typically using SMTP ([RFC5321]). The process whereby such > parties may request the reports is discussed in Section 3.5 of > [RFC6449]." >=20 > Picking the above as an example, Section 3.5 of RFC 6449 discusses > about "Handling Requests to Receive Feedback". I would reference the > technology, e.g. RFC 5321, and document requirements about how the > technology should be used. The text quoted above comes out as a BCP. I'm not sure what you're getting at here. Do we need to be specific about = how SMTP is used in the feedback report context? I don't think we have any= specific advice there. > In Section 7, first paragraph, "identify". Same for Section 8. OK. > In Section 9: >=20 > "command SHOULD use the NULL return address" >=20 > That should be Reverse-Path. OK. > I am confused after reading the draft. It comes out as a mix of > recipes. IETF practice is to send text. I don't know where to start. So this isn't the first time I've heard that about the current WG version. = The contention appears to be around how much detail is appropriate for thi= s document. Since we're back to "WG Document" state for this one, I wonder if taking th= e current WG version and doing a better job of organizing the information w= ithout actually removing anything would make it more palatable rather than = drastically reducing the detail directly. -MSK From msk@cloudmark.com Tue Feb 14 13:13:47 2012 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 7183521F85E7 for ; Tue, 14 Feb 2012 13:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3JLwzTOEPUa for ; Tue, 14 Feb 2012 13:13:47 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 192E021F85B7 for ; Tue, 14 Feb 2012 13:13:47 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 14 Feb 2012 13:13:46 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 14 Feb 2012 13:13:46 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Tue, 14 Feb 2012 13:13:45 -0800 Thread-Topic: [marf] Working Group Last Call on draft-ietf-marf-as... expired, and coming back Thread-Index: AczrV84Ta5lBGFryQ+G3bJVKhJWRcAAAGgyQAAFKmFA= Message-ID: References: <6.2.5.6.2.20120214112826.09ec1d48@resistor.net> 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] Working Group Last Call on draft-ietf-marf-as... expired, and coming back 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, 14 Feb 2012 21:13:47 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of M= urray S. Kucherawy > Sent: Tuesday, February 14, 2012 12:41 PM > To: Message Abuse Report Format working group > Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as... expi= red, and coming back >=20 > As Barry said, this document is back to being in plain old "WG > Document" as we take another round of developing it. > [...] >=20 > Since we're back to "WG Document" state for this one, I wonder if > taking the current WG version and doing a better job of organizing the > information without actually removing anything would make it more > palatable rather than drastically reducing the detail directly. Just to be clear, I am going to take a run at re-organizing the current WG = version without removing any detail. A better presentation might make it m= ore palatable. I'll post something new to the list soon. From sm@resistor.net Tue Feb 14 13:36:05 2012 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 BA0EA21E8016 for ; Tue, 14 Feb 2012 13:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.622 X-Spam-Level: X-Spam-Status: No, score=-102.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCfxkCNavASd for ; Tue, 14 Feb 2012 13:36:04 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 454E921F858D for ; Tue, 14 Feb 2012 13:35:52 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1ELZk65012490 for ; Tue, 14 Feb 2012 13:35:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329255351; i=@resistor.net; bh=TqOPJY2xQAcy+l4g5VnR+KOWfq05do0mJ6NVte7IMEY=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=HQLRHQaESrcVLcho0uX93SoL77IPTxuVWt8Xk0QrAn2rPsK33rOk40Z6WnitDHSAJ nrIs1ofJd5q2ZO5jF6JxGSsWTDFF545JafDyhy5u2MpTrWRPBVYNqVjhkcNSsUJeO1 DRFzt1sntOjk/OWejnboCOP1N2DGkvKDpCcwNuCI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1329255351; i=@resistor.net; bh=TqOPJY2xQAcy+l4g5VnR+KOWfq05do0mJ6NVte7IMEY=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=oZhIEUzrGOt7IXiJ7C/xZB95FdCBco77wZl3cR/yEn+MB7eUi0iRW6Lc1a30ENj9+ SOMgAizWJWaICLcM8VlWel3rPfGLbF2RpzCeS61o7aWwVYdYDv6RZjld88VeC3Htpl c/uJ3hBZAKgDWHAVPWED3IhM5Y3Kg+DwDSleJzeI= Message-Id: <6.2.5.6.2.20120214131258.0934af50@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 14 Feb 2012 13:33:15 -0800 To: Message Abuse Report Format working group From: SM In-Reply-To: References: <6.2.5.6.2.20120214112826.09ec1d48@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as... expired, and coming back 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, 14 Feb 2012 21:36:05 -0000 Hi Murray, At 12:41 14-02-2012, Murray S. Kucherawy wrote: >I think it fits that definition. The "Updates" is appropriate in >that if one is implementing RFC5965, one should also read this draft. No, the question is why is it an AS? >Sounds like a job for the non-normative SHOULD-like words draft! :-) >I'm not sure what you're getting at here. Do we need to be specific >about how SMTP is used in the feedback report context? I don't >think we have any specific advice there. No. My point was about how to draw up an Applicability Statement from a Technical Specification. Let's say that we are using RFC 5965 for a specific purpose. Section 3.2 of that RFC mentions optional fields. An AS can make them a requirement. >Since we're back to "WG Document" state for this one, I wonder if >taking the current WG version and doing a better job of organizing >the information without actually removing anything would make it >more palatable rather than drastically reducing the detail directly. If I understood correctly, the draft is about using ARF for unsolicited reports. The two documents do not really map as this draft covers a wide topic. As you mentioned above, it is a matter of organizing the information. How that is done is more of an editorial choice. Regards, -sm From msk@cloudmark.com Tue Feb 14 16:05:42 2012 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 8332021E8070 for ; Tue, 14 Feb 2012 16:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28sys4pBMHq6 for ; Tue, 14 Feb 2012 16:05:38 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id B843021E802A for ; Tue, 14 Feb 2012 16:05:38 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 14 Feb 2012 16:05:37 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 14 Feb 2012 16:05:09 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Tue, 14 Feb 2012 16:01:35 -0800 Thread-Topic: Reorganizing the AS Thread-Index: AczrdPtKVXaKkZYrTg+507BiBChJJQ== 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_F5833273385BB34F99288B3648C4F06F19C9A7DD7CEXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] Reorganizing the 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: Wed, 15 Feb 2012 00:05:42 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DD7CEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As I mentioned earlier, I've done some reorganizing of the content in the A= S. The curret result of my work is here: http://www.blackops.org/~msk/draft-ietf-marf-as.txt Note: None of the content of the -08 version has been removed here, but a l= ot of it has been rearranged. A test-drive of this on a couple of people h= ere before I brought it to the list was quite successful, so now I'm showin= g it to the group. Is this a more reasonable starting place for moving forward, or do we want = to stick with the -08 version? If we like it, I'll post it as -09, and the= n we can talk about another pass of work on it and perhaps a second WGLC. = If not, we'll do that on -08. -MSK --_000_F5833273385BB34F99288B3648C4F06F19C9A7DD7CEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As I mentioned e= arlier, I’ve done some reorganizing of the content in the AS.  T= he curret result of my work is here:

 

http://www.blackops.org/~msk/draft-ietf-marf-as= .txt

 

Note: None of the content of the -08 version has been removed = here, but a lot of it has been rearranged.  A test-drive of this on a = couple of people here before I brought it to the list was quite successful,= so now I’m showing it to the group.

 

Is this a more reasonable star= ting place for moving forward, or do we want to stick with the -08 version?=   If we like it, I’ll post it as -09, and then we can talk about= another pass of work on it and perhaps a second WGLC.  If not, weR= 17;ll do that on -08.

 <= /p>

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DD7CEXCHC2corpclo_-- From sklist@kitterman.com Tue Feb 14 21:11:15 2012 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 580FB21F862D for ; Tue, 14 Feb 2012 21:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXXRbXryGjpd for ; Tue, 14 Feb 2012 21:11:14 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0472121F862A for ; Tue, 14 Feb 2012 21:11:14 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id AEA3F20E40BB; Wed, 15 Feb 2012 00:11:11 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329282671; bh=BhYa8BObFvlTYoAZMciDc2uyte1vWkxAwIHNOQwBuUA=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Yd2rFZl4iw+2pAJBYNdgKCKA7TjfGBXwWE8q+oRH7yf1dxXwfgM0PI57SidUJy/Gj MVifHgH+8pFALNeQ/tuy9a5sew94Nw9SMmmL/Y5MurxBKC2gj91A6+EjSV9dGyWna+ KWMhig1FgQ6J+V8ONGtQSvSqx2S5iwZMayu8HZT8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 915FE20E4099; Wed, 15 Feb 2012 00:11:11 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 15 Feb 2012 00:11:10 -0500 Message-ID: <1995466.1FV58W8Wkm@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Reorganizing the 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: Wed, 15 Feb 2012 05:11:15 -0000 On Tuesday, February 14, 2012 04:01:35 PM Murray S. Kucherawy wrote: > As I mentioned earlier, I've done some reorganizing of the content in the > AS. The curret result of my work is here: > > http://www.blackops.org/~msk/draft-ietf-marf-as.txt > > Note: None of the content of the -08 version has been removed here, but a > lot of it has been rearranged. A test-drive of this on a couple of people > here before I brought it to the list was quite successful, so now I'm > showing it to the group. > > Is this a more reasonable starting place for moving forward, or do we want > to stick with the -08 version? If we like it, I'll post it as -09, and > then we can talk about another pass of work on it and perhaps a second > WGLC. If not, we'll do that on -08. It doesn't seem to me to be significantly better or worse, so I'll take either one. I did notice (this is common to both versions) in the authentication failure report section: 1. Selection of the recipient(s) for reports that are automatically generated MUST be done based on data provided by the report recipient, and MUST NOT be done heuristically. Therefore these reports are always solicited, though the means for doing so are not specified in this memo. Is there a reason not to just reference the DKIM and SPF drafts that define how to select the reporting address? It seems to me that would be a lot clearer. Scott K From msk@cloudmark.com Tue Feb 14 21:25:23 2012 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 CF3A711E808A for ; Tue, 14 Feb 2012 21:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmZHsLi3uQMl for ; Tue, 14 Feb 2012 21:25:23 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0E66311E8073 for ; Tue, 14 Feb 2012 21:25:23 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 14 Feb 2012 21:25:22 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 14 Feb 2012 21:25:18 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 14 Feb 2012 21:19:00 -0800 Thread-Topic: [marf] Reorganizing the AS Thread-Index: AczroOJK+Lf9k0gySTySVghacI6e4wAAD0Wg Message-ID: References: <1995466.1FV58W8Wkm@scott-latitude-e6320> In-Reply-To: <1995466.1FV58W8Wkm@scott-latitude-e6320> 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] Reorganizing the 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: Wed, 15 Feb 2012 05:25:24 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Tuesday, February 14, 2012 9:11 PM > To: marf@ietf.org > Subject: Re: [marf] Reorganizing the AS >=20 > I did notice (this is common to both versions) in the authentication > failure report section: >=20 > 1. Selection of the recipient(s) for reports that are automatically > generated MUST be done based on data provided by the report > recipient, and MUST NOT be done heuristically. Therefore these > reports are always solicited, though the means for doing so are > not specified in this memo. >=20 > Is there a reason not to just reference the DKIM and SPF drafts that > define how to select the reporting address? It seems to me that would > be a lot clearer. This appears two paragraphs earlier (in the reorganized version at least): There are some cases where report generation is caused by automation rather than user request. A specific example of this is reporting, using the ARF format (or extensions to it), of messages that fail particular message authentication checks. Examples of this include [I-D.IETF-MARF-DKIM-REPORTING] and [I-D.IETF-MARF-SPF-REPORTING]. The considerations presented below apply in those cases. So the selection mechanism is specific to the reporting scheme, and we poin= t off to the two we're developing right now. That ties it together for me.= What do you think? -MSK From sklist@kitterman.com Wed Feb 15 03:42:06 2012 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 F2DE721F87E1 for ; Wed, 15 Feb 2012 03:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dw+mrQPi5My for ; Wed, 15 Feb 2012 03:42:01 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id EFF9221F879D for ; Wed, 15 Feb 2012 03:41:54 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 07B4520E40BB; Wed, 15 Feb 2012 06:41:54 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329306114; bh=CKLxQ+3WYkgnP7/cnuCcGoaNZg2J7pUDI0bJPTjw1c4=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=B+dKTDopGhudNYN0z4cyvjBwLT9542YsoFBRTi83aLhfvyn06YTemE8RaAVUPu/ZE KQdnhnlLqad05sEqLlk7PWwrlaeuAT/Ypf96GpXpCqqc0WGBkMSlFIBUl/MMEnqwWO yEz2QkqgJ3XL6deM5U6D8Ol2loVCc39MIx51l+lo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DD1D120E4064; Wed, 15 Feb 2012 06:41:53 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 15 Feb 2012 06:41:53 -0500 Message-ID: <14938562.xOdz318ZKP@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <1995466.1FV58W8Wkm@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Reorganizing the 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: Wed, 15 Feb 2012 11:42:06 -0000 On Tuesday, February 14, 2012 09:19:00 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Tuesday, February 14, 2012 9:11 PM > > To: marf@ietf.org > > Subject: Re: [marf] Reorganizing the AS > > > > I did notice (this is common to both versions) in the authentication > > > > failure report section: > > 1. Selection of the recipient(s) for reports that are > > automatically > > > > generated MUST be done based on data provided by the > > report > > recipient, and MUST NOT be done heuristically. Therefore > > these > > reports are always solicited, though the means for doing > > so are > > not specified in this memo. > > > > Is there a reason not to just reference the DKIM and SPF drafts that > > define how to select the reporting address? It seems to me that would > > be a lot clearer. > > This appears two paragraphs earlier (in the reorganized version at least): > > There are some cases where report generation is caused by automation > rather than user request. A specific example of this is reporting, > using the ARF format (or extensions to it), of messages that fail > particular message authentication checks. Examples of this include > [I-D.IETF-MARF-DKIM-REPORTING] and [I-D.IETF-MARF-SPF-REPORTING]. > The considerations presented below apply in those cases. > > So the selection mechanism is specific to the reporting scheme, and we point > off to the two we're developing right now. That ties it together for me. > What do you think? If you change "..., though the means for doing so are not specified in this memo." to "as described above." I think that ties it together. The same text is just above in both, so it works either way. Scott K From vesely@tana.it Wed Feb 15 04:40:24 2012 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 32DBF21F879B for ; Wed, 15 Feb 2012 04:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.642 X-Spam-Level: X-Spam-Status: No, score=-4.642 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZcjhAA0gguK for ; Wed, 15 Feb 2012 04:40:19 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3A321F8800 for ; Wed, 15 Feb 2012 04:39:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1329309579; bh=lwIVMMPystqd+0DJ43fuwhIEAs7kU1pkjEg9jw2FbsM=; l=1004; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Ge6Bixn1njVvd2sJGrrljGBtzStoUcbeQV4O73KLi7gorD1eG+wbU1XPrpLR0+fCX R74iFyfjfUQus4jyxjT/oUu31cB9doIsmZ6VnhX3epQpw7P8d8YgIq8zyqRSw3g3qi 7KhOIzwUmEkFYji6T7cgPGC4dcrpv8WOsB21gJr4= 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, 15 Feb 2012 13:39:39 +0100 id 00000000005DC033.000000004F3BA78B.00001B2C Message-ID: <4F3BA78A.5030405@tana.it> Date: Wed, 15 Feb 2012 13:39:38 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <2687617.GuVsQiVKMe@scott-latitude-e6320> <20120213154132.68179.qmail@joyce.lan> <8577772.BrpObzDUBN@scott-latitude-e6320> <4F3AA104.3040502@tana.it> <4F3AAE1F.7040503@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Message bodies in ARF reports 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, 15 Feb 2012 12:40:24 -0000 On 14/Feb/12 20:12, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely >> >>>> The third MIME part of the message is either of type "message/rfc822" >>>> (as defined in [MIME-TYPES]) or "text/rfc822-headers" (as defined in >>>> [REPORT]) and contains a copy of the entire header block from the >>>> original message. This part MUST be included (contrary to [REPORT], >>>> which makes it optional). >>> >>> The synthesis option handles this, if we want to go that way. >> >> Which "synthesis option"? > > http://www.ietf.org/mail-archive/web/marf/current/msg02109.html Ah, that. I'd prefer to avoid it... I foolishly though there was a possibility to apply an update (or errata) recursively to all RFCs derived from an updated (corrected) format. Probably, it is an error of authfailure-report to have the paragraph quoted above --almost equal to the 5965's text that John corrected yesterday. Is it necessary to have it published before correcting it? From vesely@tana.it Wed Feb 15 04:41:10 2012 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 1E06D21F87C0 for ; Wed, 15 Feb 2012 04:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.643 X-Spam-Level: X-Spam-Status: No, score=-4.643 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frrPmnmEat1C for ; Wed, 15 Feb 2012 04:41:05 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 19A5E21F8790 for ; Wed, 15 Feb 2012 04:40:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1329309656; bh=TUbjgAPXBx3n1OvAdiHbhKHt3gm0cyO2B783CcocC4g=; l=622; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Lt2d8kWjtqowvHDG1AC9kqMulDuV+rqjYymOhHDF7rhN0SLRsR2fj7RYAwrk4ICgB r5cCvpPZARK4pflgBZPeiEGr9dyU4rRukMNp5+A07fguyBS+wbzLtF97iRBLjQF8wH hX20huIo2gJPmC3s+5bUG8IkVfcb8kItPmpVnvKA= 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, 15 Feb 2012 13:40:56 +0100 id 00000000005DC033.000000004F3BA7D8.00001B89 Message-ID: <4F3BA7D7.4060604@tana.it> Date: Wed, 15 Feb 2012 13:40:55 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <6.2.5.6.2.20120214112826.09ec1d48@resistor.net> <6.2.5.6.2.20120214131258.0934af50@resistor.net> In-Reply-To: <6.2.5.6.2.20120214131258.0934af50@resistor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as... expired, and coming back 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, 15 Feb 2012 12:41:10 -0000 On 14/Feb/12 22:33, SM wrote: > Hi Murray, > At 12:41 14-02-2012, Murray S. Kucherawy wrote: >> I think it fits that definition. The "Updates" is appropriate in >> that if one is implementing RFC5965, one should also read this draft. > > No, the question is why is it an AS? My understanding is^H^H was that an AS allows to "import" a TS from external sources. Something like saying "Hey, that stuff is to be considered Standard-Track, even if it's formally Informational and/or produced outside of the IETF." Recall the bottom paragraph of http://www.ietf.org/mail-archive/web/marf/current/msg01257.html From vesely@tana.it Wed Feb 15 04:41:14 2012 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 1A4DF21F878B for ; Wed, 15 Feb 2012 04:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.643 X-Spam-Level: X-Spam-Status: No, score=-4.643 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTmcsp2-3JOu for ; Wed, 15 Feb 2012 04:41:10 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D3B8121F87FA for ; Wed, 15 Feb 2012 04:40:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1329309659; bh=0+AEdQpWStGiEW9Aze6Ps/cgkQ+hg5pwSaQO92nKXNY=; l=408; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ectPREABoR/vxneSYUHB2e66uOvORYPl6xfWu1SujoPFm/RvXHQEkXncmmNuUxaJD IpP65El5PDvDPz6Ws3Ub+tVJCfAc0H0CyM0Hlp4I61BMkgLbevlsnpDoV3+zFuOnzi eOP46KvPLOCmBtyyPoTcPNq/2K+46ZYsyukY40qE= 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, 15 Feb 2012 13:40:59 +0100 id 00000000005DC033.000000004F3BA7DB.00001BAF Message-ID: <4F3BA7DA.2020506@tana.it> Date: Wed, 15 Feb 2012 13:40:58 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [marf] Reorganizing the 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: Wed, 15 Feb 2012 12:41:14 -0000 On 15/Feb/12 01:01, Murray S. Kucherawy wrote: > As I mentioned earlier, I’ve done some reorganizing of the content in > the AS. The curret result of my work is here: > > http://www.blackops.org/~msk/draft-ietf-marf-as.txt I particularly appreciate that "Where To Send Reports" has its own subsection. However, this version is not substantially better or worse than -08, so I'll take either one. From shmuel+gen@patriot.net Wed Feb 15 09:25:22 2012 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 5239821F8743 for ; Wed, 15 Feb 2012 09:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZQQxCwJyeTa for ; Wed, 15 Feb 2012 09:25:18 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 46B7D21F8731 for ; Wed, 15 Feb 2012 09:25:11 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.190]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 71604F58093 for ; Wed, 15 Feb 2012 12:10:25 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Wed, 15 Feb 2012 12:10:10 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120215171025.71604F58093@smtp.patriot.net> Subject: Re: [marf] meaning of signatures, was I-D Action: draft-ietf-marf-as-07.txt 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, 15 Feb 2012 17:25:22 -0000 In , on 02/14/2012 at 09:26 AM, "Murray S. Kucherawy" said: >I believe this is off-topic for MARF. Please don't reply to this >thread unless you have an argument to make that it's germane to one >of the documents under development. The context for this is that I wanted the language to be general rather than limited to specific protocols. From Message-Id: <20120209161741.74A73F580AB@smtp.patriot.net> "I'd rather make it more general and also require authentication for anything not based on the source IP or a domain resolving to the source id." The intent is that the AS not automatically become obsolete should the IETF ever publish a new authentication protocol. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From shmuel+gen@patriot.net Wed Feb 15 09:25:22 2012 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 8588C21F8731 for ; Wed, 15 Feb 2012 09:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.351 X-Spam-Level: X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[AWL=-0.611, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lyo5NL5iTeJB for ; Wed, 15 Feb 2012 09:25:18 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5494021F873E for ; Wed, 15 Feb 2012 09:25:18 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.190]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 0B1C5F5808F for ; Wed, 15 Feb 2012 12:10:27 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Wed, 15 Feb 2012 12:15:59 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120215171029.0B1C5F5808F@smtp.patriot.net> Subject: Re: [marf] Message bodies in ARF reports 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, 15 Feb 2012 17:25:22 -0000 In , on 02/14/2012 at 11:14 AM, "Murray S. Kucherawy" said: >So do we need to say "Updates RFC5965" in Scott's draft, perhaps >pointing at the erratum in an appendix or something, just to tie it >all together? That's my take. Also, is failure to respond to an erratum taken as concurrence or non-concurrence? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From shmuel+gen@patriot.net Wed Feb 15 09:44:30 2012 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 59E2621E8067 for ; Wed, 15 Feb 2012 09:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U47Firtm2gYk for ; Wed, 15 Feb 2012 09:44:25 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8004D21E8054 for ; Wed, 15 Feb 2012 09:44:25 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.190]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 9BB72F58095 for ; Wed, 15 Feb 2012 12:10:41 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Wed, 15 Feb 2012 12:24:32 -0500 To: marf@ietf.org In-Reply-To: <6.2.5.6.2.20120214131258.0934af50@resistor.net> Mail-Copies-To: nobody 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: <20120215171042.9BB72F58095@smtp.patriot.net> Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as... expired, and coming back 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, 15 Feb 2012 17:44:30 -0000 In <6.2.5.6.2.20120214131258.0934af50@resistor.net>, on 02/14/2012 at 01:33 PM, SM said: >If I understood correctly, the draft is about using ARF for >unsolicited reports. It's primarily about solicited reports. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From shmuel+gen@patriot.net Wed Feb 15 09:44:30 2012 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 8A47121F8576 for ; Wed, 15 Feb 2012 09:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlQ8OuUMn2yv for ; Wed, 15 Feb 2012 09:44:25 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD3721E804F for ; Wed, 15 Feb 2012 09:44:20 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.190]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 3BE91F5808F for ; Wed, 15 Feb 2012 12:10:38 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Wed, 15 Feb 2012 12:21:31 -0500 To: marf@ietf.org In-Reply-To: <6.2.5.6.2.20120214112826.09ec1d48@resistor.net> Mail-Copies-To: nobody 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: <20120215171039.3BE91F5808F@smtp.patriot.net> Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as... expired, and coming back 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, 15 Feb 2012 17:44:30 -0000 In <6.2.5.6.2.20120214112826.09ec1d48@resistor.net>, on 02/14/2012 at 12:32 PM, SM said: >In Section 2, I suggest "POP3" instead of "POP". Then "IMAP" should be "IMAP4". -- 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 Wed Feb 15 09:58:05 2012 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 949CA21F8638 for ; Wed, 15 Feb 2012 09:58:05 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4ta42dL-9lt for ; Wed, 15 Feb 2012 09:58:05 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDD321F8631 for ; Wed, 15 Feb 2012 09:58:05 -0800 (PST) Received: from platter.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id 7AE242DDE4 for ; Wed, 15 Feb 2012 09:58:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Steve Atkins In-Reply-To: <20120215171042.9BB72F58095@smtp.patriot.net> Date: Wed, 15 Feb 2012 09:58:01 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <20120215171042.9BB72F58095@smtp.patriot.net> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1257) Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as... expired, and coming back 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, 15 Feb 2012 17:58:05 -0000 On Feb 15, 2012, at 9:24 AM, Shmuel (Seymour J.) Metz wrote: > In <6.2.5.6.2.20120214131258.0934af50@resistor.net>, on 02/14/2012 > at 01:33 PM, SM said: > >> If I understood correctly, the draft is about using ARF for >> unsolicited reports. > > It's primarily about solicited reports. It's about both, about equally. They're quite different things, and the only connection between them is that they both are using ARF as the envelope format. Cheers, Steve From msk@cloudmark.com Wed Feb 15 10:47:59 2012 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 9FCEE21F8532 for ; Wed, 15 Feb 2012 10:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1F8ViqLp-yf for ; Wed, 15 Feb 2012 10:47:59 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id C1E2021F852F for ; Wed, 15 Feb 2012 10:47:58 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 15 Feb 2012 10:47:58 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 15 Feb 2012 10:47:49 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Wed, 15 Feb 2012 10:44:57 -0800 Thread-Topic: [marf] Message bodies in ARF reports Thread-Index: AczsB1k2AMnfmMJZQzeKdJgZ/bgM6gACnGAg Message-ID: References: <20120215171029.0B1C5F5808F@smtp.patriot.net> In-Reply-To: <20120215171029.0B1C5F5808F@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Message bodies in ARF reports 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, 15 Feb 2012 18:47:59 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Wednesday, February 15, 2012 9:16 AM > To: marf@ietf.org > Subject: Re: [marf] Message bodies in ARF reports >=20 > That's my take. Also, is failure to respond to an erratum taken as > concurrence or non-concurrence? I think only a verified erratum has any effect, although the effect only ma= tters if one knows to go looking for it. The real way to get the erratum implemented is a -bis effort, but I'm not s= ure that would be wise for RFC5965 just now. -MSK From vesely@tana.it Wed Feb 15 10:55:35 2012 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 7885021E806A for ; Wed, 15 Feb 2012 10:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.645 X-Spam-Level: X-Spam-Status: No, score=-4.645 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA27vQ7HSTbI for ; Wed, 15 Feb 2012 10:55:31 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id F371221E8027 for ; Wed, 15 Feb 2012 10:55:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1329332129; bh=4Tcihy+LMS65vJppHBeklm6QmVhQ5voNn196SN8+TJA=; l=718; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=SxsYZplrkMmpMj8Cf3HWL0MhiYKYZR2mh83Rj4BRd40o1iT/7NuAfUigahAittf4+ wVFoxopGKG9AJbvvspB6frfX/RSbVzp+D1DXAJGVhfylDtR/+GZz77913UyHwHctei 9gLyNYwYelwz25LHOnRRafcYL/k6hG7XAF98Ru7k= 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, 15 Feb 2012 19:55:29 +0100 id 00000000005DC039.000000004F3BFFA1.0000757C Message-ID: <4F3BFFA1.9060102@tana.it> Date: Wed, 15 Feb 2012 19:55:29 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120215171042.9BB72F58095@smtp.patriot.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as... expired, and coming back 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, 15 Feb 2012 18:55:35 -0000 On 15/Feb/12 18:58, Steve Atkins wrote: > On Feb 15, 2012, at 9:24 AM, Shmuel (Seymour J.) Metz wrote: >> In <6.2.5.6.2.20120214131258.0934af50@resistor.net>, on 02/14/2012 >> at 01:33 PM, SM said: >> >>> If I understood correctly, the draft is about using ARF for >>> unsolicited reports. >> >> It's primarily about solicited reports. > > It's about both, about equally. They're quite different things, and the > only connection between them is that they both are using ARF as > the envelope format. Another connection is that one can transition from receiver of unsolicited reports to FBL subscriber by clicking on a link in the human readable part of (one of) the first reports. From internet-drafts@ietf.org Wed Feb 15 12:12:25 2012 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 E8BD821E80A0; Wed, 15 Feb 2012 12:12:24 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SajDQQq4QL+G; Wed, 15 Feb 2012 12:12:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153CA21F8638; Wed, 15 Feb 2012 12:12:20 -0800 (PST) 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.64p2 Message-ID: <20120215201220.9725.32329.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2012 12:12:20 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-as-09.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, 15 Feb 2012 20:12:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Messaging Abuse Reporting Format Work= ing Group of the IETF. Title : Creation and Use of Email Feedback Reports: An Applicabi= lity Statement for the Abuse Reporting Format (ARF) Author(s) : J.D. Falk M. Kucherawy Filename : draft-ietf-marf-as-09.txt Pages : 16 Date : 2012-02-15 RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This Applicability Statement describes common methods for utilizing this format for reporting both abuse and authentication failure events. Mailbox Providers of any size, mail sending entities, and end users can use these methods as a basis to create procedures that best suit them. Some related optional mechanisms are also discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-as-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-as-09.txt From shmuel+gen@patriot.net Wed Feb 15 12:42:41 2012 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 0575221E80AD for ; Wed, 15 Feb 2012 12:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6CisvyW9CTv for ; Wed, 15 Feb 2012 12:42:36 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id B305E21E80AA for ; Wed, 15 Feb 2012 12:42:36 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.53]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 4E85AF5808F for ; Wed, 15 Feb 2012 15:27:51 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Wed, 15 Feb 2012 12:31:01 -0500 To: marf@ietf.org In-Reply-To: <1995466.1FV58W8Wkm@scott-latitude-e6320> Mail-Copies-To: nobody 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: <20120215202751.4E85AF5808F@smtp.patriot.net> Subject: Re: [marf] Reorganizing the AS 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, 15 Feb 2012 20:42:41 -0000 In <1995466.1FV58W8Wkm@scott-latitude-e6320>, on 02/15/2012 at 12:11 AM, Scott Kitterman said: >Is there a reason not to just reference the DKIM and SPF drafts that >define how to select the reporting address? It seems to me that >would be a lot clearer. I'd endorse adding such language for messages that are authenticated by DKIM or SPF, but I believe that the general statement is still needed for other messages. -- 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 Feb 15 12:57:14 2012 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 322EE21E8086 for ; Wed, 15 Feb 2012 12:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBO+odm6ok4s for ; Wed, 15 Feb 2012 12:57:09 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B997A21E808D for ; Wed, 15 Feb 2012 12:57:09 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D5C4120E40BD; Wed, 15 Feb 2012 15:57:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329339428; bh=r37Y6O7hgM2TnEOxgzEzZAlVT3d2RLPA2zK14uN912A=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=i4H6CKyNK6GCRrqAFLGnmlR4GscZiZ8zL8Rsvx/jNtSvXMeoxzCVpHINIG9rmR70e uiecL6iCfciV1fS31Q8XGFvZvyqWCru32urvR8CK2uBaxIcyvinP030ss8XfoKmQwH 1zn84n0GySu8K2FidkpTzml38yUBxM+OKYeRjVG4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B714520E4064; Wed, 15 Feb 2012 15:57:08 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 15 Feb 2012 15:57:08 -0500 Message-ID: <2086143.VlEbLfYXfO@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120215202751.4E85AF5808F@smtp.patriot.net> References: <20120215202751.4E85AF5808F@smtp.patriot.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Reorganizing the 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: Wed, 15 Feb 2012 20:57:14 -0000 On Wednesday, February 15, 2012 12:31:01 PM Shmuel Metz wrote: > In <1995466.1FV58W8Wkm@scott-latitude-e6320>, on 02/15/2012 > > at 12:11 AM, Scott Kitterman said: > >Is there a reason not to just reference the DKIM and SPF drafts that > >define how to select the reporting address? It seems to me that > >would be a lot clearer. > > I'd endorse adding such language for messages that are authenticated > by DKIM or SPF, but I believe that the general statement is still > needed for other messages. I don't think it's possible for this applicability statement to cover arbitrary authentication technologies. I think it can only address the ones we have. I don't mind if we make the references to the DKIM and SPF drafts exemplary, but that doesn't mean arbitrary things will work. Scott K From msk@cloudmark.com Wed Feb 15 13:01:55 2012 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 E744421E8086 for ; Wed, 15 Feb 2012 13:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwc57YDz7Kt8 for ; Wed, 15 Feb 2012 13:01:55 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 05F8221F864D for ; Wed, 15 Feb 2012 13:01:55 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 15 Feb 2012 13:01:54 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 15 Feb 2012 13:01:50 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 15 Feb 2012 12:57:02 -0800 Thread-Topic: I-D Action: draft-ietf-marf-as-09.txt Thread-Index: AczsHi8W1zL61YHmRfCBBhkV9hsJfQABh8yw Message-ID: References: <20120215201220.9725.32329.idtracker@ietfa.amsl.com> In-Reply-To: <20120215201220.9725.32329.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-as-09.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, 15 Feb 2012 21:01:56 -0000 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org > Sent: Wednesday, February 15, 2012 12:12 PM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: I-D Action: draft-ietf-marf-as-09.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Messaging Abuse Reporting > Format Working Group of the IETF. >=20 > Title : Creation and Use of Email Feedback Reports: An > Applicability Statement for the Abuse Reporting Format (ARF) > Author(s) : J.D. Falk > M. Kucherawy > Filename : draft-ietf-marf-as-09.txt > Pages : 16 > Date : 2012-02-15 >=20 > RFC 5965 defines an extensible, machine-readable format intended for > mail operators to report feedback about received email to other > parties. This Applicability Statement describes common methods for > utilizing this format for reporting both abuse and authentication > failure events. Mailbox Providers of any size, mail sending > entities, and end users can use these methods as a basis to create > procedures that best suit them. Some related optional mechanisms are > also discussed. This is the reorganized version with no content changes. Now we can start = debating those. :-) From msk@cloudmark.com Wed Feb 15 13:10:59 2012 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 1849D21E8098 for ; Wed, 15 Feb 2012 13:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1Q8fMe2LPcx for ; Wed, 15 Feb 2012 13:10:58 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE7921E8086 for ; Wed, 15 Feb 2012 13:10:58 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 15 Feb 2012 13:10:56 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 15 Feb 2012 13:10:56 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 15 Feb 2012 13:03:43 -0800 Thread-Topic: [marf] Reorganizing the AS Thread-Index: AczsJMP683UPGCFiTVaCFLTbLNH/CQAAHGiA Message-ID: References: <20120215202751.4E85AF5808F@smtp.patriot.net> <2086143.VlEbLfYXfO@scott-latitude-e6320> In-Reply-To: <2086143.VlEbLfYXfO@scott-latitude-e6320> 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] Reorganizing the 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: Wed, 15 Feb 2012 21:10:59 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Wednesday, February 15, 2012 12:57 PM > To: marf@ietf.org > Subject: Re: [marf] Reorganizing the AS >=20 > > I'd endorse adding such language for messages that are authenticated > > by DKIM or SPF, but I believe that the general statement is still > > needed for other messages. >=20 > I don't think it's possible for this applicability statement to cover > arbitrary authentication technologies. I think it can only address the > ones we have. I don't mind if we make the references to the DKIM and > SPF drafts exemplary, but that doesn't mean arbitrary things will work. I prefer this approach as well. Do you have specific text to suggest (or p= oint me to earlier in this thread)? -MSK From sklist@kitterman.com Wed Feb 15 13:13:08 2012 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 61E0421F8668 for ; Wed, 15 Feb 2012 13:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPt-+0j0b3f3 for ; Wed, 15 Feb 2012 13:13:03 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE2221F845E for ; Wed, 15 Feb 2012 13:13:00 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D9B1520E40BB; Wed, 15 Feb 2012 16:12:59 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329340379; bh=xuyyY3uKhw8tHUc16t5HafmMdqHCZ4I2oOYT/M/uYKM=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=hfjwn77cr3lm6BuwQV6jKDzxPcy+DUwdfUiqL+zltEBMJlizG01tuU8ucMGPuW/Fe Nr9/hD+V92Jqi42YAuG0gGvRBoF4XZLfKfLCFCAa/bzM1pXaKcRCk+lvkys/kdz4NR C97Jh9qmf6v5GjS63EEQva4VF5krn81r86YVy3pI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id BAA5F20E4064; Wed, 15 Feb 2012 16:12:59 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 15 Feb 2012 16:12:59 -0500 Message-ID: <9705753.ZyYUyGt1MO@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120215202751.4E85AF5808F@smtp.patriot.net> <2086143.VlEbLfYXfO@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Reorganizing the 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: Wed, 15 Feb 2012 21:13:08 -0000 On Wednesday, February 15, 2012 01:03:43 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Wednesday, February 15, 2012 12:57 PM > > To: marf@ietf.org > > Subject: Re: [marf] Reorganizing the AS > > > > > I'd endorse adding such language for messages that are authenticated > > > by DKIM or SPF, but I believe that the general statement is still > > > needed for other messages. > > > > I don't think it's possible for this applicability statement to cover > > arbitrary authentication technologies. I think it can only address the > > ones we have. I don't mind if we make the references to the DKIM and > > SPF drafts exemplary, but that doesn't mean arbitrary things will work. > > I prefer this approach as well. Do you have specific text to suggest (or > point me to earlier in this thread)? >From earlier in the thread: > If you change "..., though the means for doing so are not specified in > this memo." to "as described above." I think that ties it together. The > same text is just above in both, so it works either way. Scott K From msk@cloudmark.com Wed Feb 15 13:53:30 2012 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 16A6021E809B for ; Wed, 15 Feb 2012 13:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dusYbk-q5Lm for ; Wed, 15 Feb 2012 13:53:23 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDCB21E803D for ; Wed, 15 Feb 2012 13:53:20 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 15 Feb 2012 13:53:20 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 15 Feb 2012 13:53:15 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 15 Feb 2012 13:47:06 -0800 Thread-Topic: [marf] Reorganizing the AS Thread-Index: AczsJqCaPHFzyojkQTidMtmU5rzOUwABHupg Message-ID: References: <20120215202751.4E85AF5808F@smtp.patriot.net> <2086143.VlEbLfYXfO@scott-latitude-e6320> <9705753.ZyYUyGt1MO@scott-latitude-e6320> In-Reply-To: <9705753.ZyYUyGt1MO@scott-latitude-e6320> 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] Reorganizing the 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: Wed, 15 Feb 2012 21:53:30 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Wednesday, February 15, 2012 1:13 PM > To: marf@ietf.org > Subject: Re: [marf] Reorganizing the AS >=20 > From earlier in the thread: >=20 > > If you change "..., though the means for doing so are not specified in > > this memo." to "as described above." I think that ties it together. > > The same text is just above in both, so it works either way. How about: ", such as the mechanisms described in the examples listed above." That way it references the mechanisms (which we've already called "examples= " in earlier in that section) while leaving open the idea that others might= come in the future. I think that satisfies both perspectives. OK with both of you? -MSK From sklist@kitterman.com Wed Feb 15 15:48:49 2012 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 A8E0421E8084 for ; Wed, 15 Feb 2012 15:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uF3h6W4JcC6h for ; Wed, 15 Feb 2012 15:48:39 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0B24021E801D for ; Wed, 15 Feb 2012 15:48:38 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 608F120E40BB; Wed, 15 Feb 2012 18:48:38 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329349718; bh=s2EFGy29laL9X8g2PpSBbebIO7/A7VCGEHWblbqc+G8=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=F+mZfgIWIMGJCipdgtv3ill759EdxbGmMLiXtagCfFohY0esnVdSOa3t7zxBLAjno 86osKMHbfDW9lT7r8vvNawS2jC3J+vfFducDtvzLmPGzUsK+a7o8gCutpl3aNTmMKN mTosTOyiGqsNOBaAFszkerm+AKHYzAbFUAOzy2tg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 42B0A20E4064; Wed, 15 Feb 2012 18:48:38 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 15 Feb 2012 18:48:37 -0500 Message-ID: <3359482.btBcAMmgCE@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-15-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120215202751.4E85AF5808F@smtp.patriot.net> <9705753.ZyYUyGt1MO@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Reorganizing the 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: Wed, 15 Feb 2012 23:48:49 -0000 On Wednesday, February 15, 2012 01:47:06 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > Scott Kitterman Sent: Wednesday, February 15, 2012 1:13 PM > > To: marf@ietf.org > > Subject: Re: [marf] Reorganizing the AS > > > > From earlier in the thread: > > > If you change "..., though the means for doing so are not specified > > > in > > > this memo." to "as described above." I think that ties it together. > > > The same text is just above in both, so it works either way. > > How about: > > ", such as the mechanisms described in the examples listed above." > > That way it references the mechanisms (which we've already called "examples" > in earlier in that section) while leaving open the idea that others might > come in the future. I think that satisfies both perspectives. > > OK with both of you? They are already described as examples above, so I don't think it adds anything, but if you prefer it, I'm fine with it. Scott K From msk@cloudmark.com Wed Feb 15 20:59:40 2012 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 A802221E801F for ; Wed, 15 Feb 2012 20:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAgL5O4QuoHy for ; Wed, 15 Feb 2012 20:59:39 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id DB6F521E8011 for ; Wed, 15 Feb 2012 20:59:30 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 15 Feb 2012 20:59:30 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 15 Feb 2012 20:59:23 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 15 Feb 2012 20:57:38 -0800 Thread-Topic: draft-ietf-marf-spf-reporting review comments Thread-Index: AczsZ4HBtsrdp94IQne6OrI9+2ls1Q== 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_F5833273385BB34F99288B3648C4F06F19C9A7DDB8EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] draft-ietf-marf-spf-reporting review comments X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 04:59:40 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DDB8EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just took a pass through the document and found the following things: - I think because it creates a registry that SPF implementations s= hould know about, that this one should advertise that it updates RFC4408. = (Barry, please check my math on this one.) I think that means we need a se= cond paragraph in the Abstract saying "This memo updates RFC4408", and also= add updates=3D"4408" in the tag. - The "ra=3D" definition talks about "r=3D", which should probably= also be "ra=3D" now. - The "rp=3D" definition talks about signature authentication fail= ures. Should be path authorization failures. - The DKIM reporting draft includes "rs=3D" to ask rejecting sites= to use a particular string in the SMTP reply. Is that omitted here for a = reason? (I have some vague recollection that SPF itself can do this, so ma= ybe that's why.) - The ABNF for "spf-rr-tag" includes a reference to "spf-ro-tag" w= hich is undefined. - Section 4 also refers to the "ro" token, which should probably a= lso become "rr". - Section 4 also refers to "these lists", but there's only one. - A note for later: If the SPFbis effort renames the result codes = to all lowercase, it'll have to "Updates" this one. That's it. -MSK --_000_F5833273385BB34F99288B3648C4F06F19C9A7DDB8EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just took a pass= through the document and found the following things:

 

- &n= bsp;        I th= ink because it creates a registry that SPF implementations should know abou= t, that this one should advertise that it updates RFC4408.  (Barry, pl= ease check my math on this one.)  I think that means we need a second = paragraph in the Abstract saying “This memo updates RFC4408”, a= nd also add updates=3D”4408” in the <rfc> tag.=

-       = ;   The “ra=3D” definition ta= lks about “r=3D”, which should probably also be “ra=3D= 221; now.

-   &nb= sp;      The “rp=3D&= #8221; definition talks about signature authentication failures.  Shou= ld be path authorization failures.

-          The DKIM reporting draft includes “rs=3D” to ask reject= ing sites to use a particular string in the SMTP reply.  Is that omitt= ed here for a reason?  (I have some vague recollection that SPF itself= can do this, so maybe that’s why.)

-          The ABNF for “spf-rr-tag” includes a reference t= o “spf-ro-tag” which is undefined.

-          Section 4 also refers to the “ro” token, wh= ich should probably also become “rr”.

-          <= /span>Section 4 also refers to “these lists”, = but there’s only one.

-&nb= sp;         A note for later: If the SPFbis effort renames the result codes to all low= ercase, it’ll have to “Updates” this one.

<= p class=3DMsoNormal>
That’s it.

 

-MSK

= = --_000_F5833273385BB34F99288B3648C4F06F19C9A7DDB8EXCHC2corpclo_-- From shmuel+gen@patriot.net Thu Feb 16 01:07:03 2012 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 EAE5A21F870A for ; Thu, 16 Feb 2012 01:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2Wtfage2kLc for ; Thu, 16 Feb 2012 01:06:58 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4A41021F86E2 for ; Thu, 16 Feb 2012 01:06:58 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.217]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 21120F5808C for ; Thu, 16 Feb 2012 03:52:10 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Thu, 16 Feb 2012 03:52:52 -0500 To: marf@ietf.org In-Reply-To: <2086143.VlEbLfYXfO@scott-latitude-e6320> Mail-Copies-To: nobody 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: <20120216085211.21120F5808C@smtp.patriot.net> Subject: Re: [marf] Reorganizing the AS 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, 16 Feb 2012 09:07:03 -0000 In <2086143.VlEbLfYXfO@scott-latitude-e6320>, on 02/15/2012 at 03:57 PM, Scott Kitterman said: >I don't think it's possible for this applicability statement to >cover arbitrary authentication technologies. Certainly not in detail, but it is possible to specify general constraints. The existing text is reasonable for any likely future techology, it just needs a reference to the specific cases that the draft discusses in detail. 1. Selection of the recipient(s) for reports that are automatically generated MUST be done based on data provided by the report recipient, and MUST NOT be done heuristically. Therefore these reports are always solicited, though the means for doing so, other than the cases discussed above, are not specified in this memo. -- 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 Thu Feb 16 01:07:08 2012 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 C185121F86AF for ; Thu, 16 Feb 2012 01:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWVasjqC6ddO for ; Thu, 16 Feb 2012 01:07:04 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5483921F870F for ; Thu, 16 Feb 2012 01:07:04 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.217]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id AABE1F5808C for ; Thu, 16 Feb 2012 03:52:13 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Thu, 16 Feb 2012 03:55:44 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody 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: <20120216085214.AABE1F5808C@smtp.patriot.net> Subject: Re: [marf] Reorganizing the AS 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, 16 Feb 2012 09:07:08 -0000 In , on 02/15/2012 at 01:47 PM, "Murray S. Kucherawy" said: >", such as the mechanisms described in the examples listed above." I sent alternative text, but the above is fine with me if you believe that it is clearer. -- 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 Thu Feb 16 10:44:41 2012 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 0233411E808E for ; Thu, 16 Feb 2012 10:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNJQyIfQ8ubd for ; Thu, 16 Feb 2012 10:44:36 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD1711E8074 for ; Thu, 16 Feb 2012 10:44:13 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5DA5720E40BB; Thu, 16 Feb 2012 13:44:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329417848; bh=0z0ff3hjsoTlvJyTEYQ9ni7ONkajlKnou52xgdHDTyE=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=RGryk1mewPp++8pRH7S6c5m0c8+TeiTH9h6SUeF2KxrfrvSUM1/huyjbxX2V3hkK4 fnC5XW7V8Iyps7Umh6wRsEJNMlYoB1tyUW4lbrD7Fp12/Qfu7N83HVb0ouiVkPTHdL CbDuEuOzqv08aYw9d5PwC3SHZLKE/zZspu0evPqk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3E14020E406C; Thu, 16 Feb 2012 13:44:08 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Thu, 16 Feb 2012 13:44:07 -0500 Message-ID: <132944365.AW8sBqTBL3@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120214182616.6571072F1F1@rfc-editor.org> References: <20120214182616.6571072F1F1@rfc-editor.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] [Technical Errata Reported] RFC5965 (3120) 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, 16 Feb 2012 18:44:41 -0000 On Tuesday, February 14, 2012 10:26:16 AM RFC Errata System wrote: > The following errata report has been submitted for RFC5965, > "An Extensible Format for Email Feedback Reports". ... > Reports can be created from info collected in SMTP transactions that don't > accept a message, a scenario we didn't consider when we wrote this section. ... Based on the discussions on the list, I looked at including the 'fix' for this in the SPF draft and having it update 5965. When I get into the text though, I don't think this works. The current draft (correctly) says: This document extends [SPF] to add an optional reporting address and other parameters. Extension of [ARF] to add features required for the reporting of these incidents is covered in [I-D.IETF-MARF-AUTHFAILURE-REPORT] and [I-D.IETF-MARF-AS]. So it seems more than a little awkward to shove an ARF fix in here. Ideally, if we were going to fix it in one of the current drafts it should be I-D.IETF- MARF-AUTHFAILURE-REPORT, but I guess it's too late for that. I'm going to proceed on the assumption that the errata will eventually be confirmed and that's sufficient or some was will be found to stuff it into I- D.IETF-MARF-AUTHFAILURE-REPORT/AS and that I don't need to directly address it in the SPF draft. I don't see an non-contrived way to do it. Scott K From msk@cloudmark.com Thu Feb 16 10:49:07 2012 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 B526721F87EB for ; Thu, 16 Feb 2012 10:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kn4OM7tKFd5J for ; Thu, 16 Feb 2012 10:49:07 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 47EB821F87E9 for ; Thu, 16 Feb 2012 10:49:07 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 16 Feb 2012 10:49:06 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 16 Feb 2012 10:49:06 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 16 Feb 2012 10:49:05 -0800 Thread-Topic: [marf] [Technical Errata Reported] RFC5965 (3120) Thread-Index: Aczs2wzH/2OOBq4JTZaA4ScSj5lgdAAAGi+g Message-ID: References: <20120214182616.6571072F1F1@rfc-editor.org> <132944365.AW8sBqTBL3@scott-latitude-e6320> In-Reply-To: <132944365.AW8sBqTBL3@scott-latitude-e6320> 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] [Technical Errata Reported] RFC5965 (3120) 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, 16 Feb 2012 18:49:07 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Thursday, February 16, 2012 10:44 AM > To: marf@ietf.org > Subject: Re: [marf] [Technical Errata Reported] RFC5965 (3120) >=20 > So it seems more than a little awkward to shove an ARF fix in here. > Ideally, if we were going to fix it in one of the current drafts it > should be I-D.IETF- MARF-AUTHFAILURE-REPORT, but I guess it's too late > for that. >=20 > I'm going to proceed on the assumption that the errata will eventually > be confirmed and that's sufficient or some was will be found to stuff > it into I- D.IETF-MARF-AUTHFAILURE-REPORT/AS and that I don't need to > directly address it in the SPF draft. I don't see an non-contrived way > to do it. We can post an erratum for authfailure-report when it publishes to tie it a= ll together. For now I would proceed, and if you feel like adding more explanation would= be useful, include it in an appendix. The IESG can make the choice about = whether or not that's really needed and ask the RFC Editor to strike the se= ction if not. And in the interim, I'll ask our intrepid AD for guidance. -MSK From sklist@kitterman.com Thu Feb 16 10:57:57 2012 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 7D9F321F8455 for ; Thu, 16 Feb 2012 10:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPjQoYqrVaSD for ; Thu, 16 Feb 2012 10:57:53 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 453B621F85A0 for ; Thu, 16 Feb 2012 10:57:41 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CCFB320E40BB; Thu, 16 Feb 2012 13:57:40 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329418660; bh=MV7nvabM/iDu+nBspZic+eCUVsN9qPkhzeB1LnGDKrU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=M2p20YyX1KukCWHhDEao6xTswwZrogwCMd7kRFQv/n68rLC3SABTTPJaPTNkYjmTP XyQESkt4Xc23HwGnmBfyRnsRlS+0Duxej14vmrPiFgDHOJMxIaV/Yhb9XFBeavBFV9 4NPHtR29bsN7rdsH/2oDTJ7jUGFKabswIiXvx+T4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id ADEFE20E406C; Thu, 16 Feb 2012 13:57:40 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Thu, 16 Feb 2012 13:57:40 -0500 Message-ID: <2956844.uFX6CjHGR4@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] draft-ietf-marf-spf-reporting review comments X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:57:57 -0000 On Wednesday, February 15, 2012 08:57:38 PM Murray S. Kucherawy wrote: > Just took a pass through the document and found the following things: Thanks for the review. > > - I think because it creates a registry that SPF implementations > should know about, that this one should advertise that it updates RFC4408. > (Barry, please check my math on this one.) I think that means we need a > second paragraph in the Abstract saying "This memo updates RFC4408", and > also add updates="4408" in the tag. Agreed. Done. > - The "ra=" definition talks about "r=", which should probably also > be "ra=" now. Fixed > - The "rp=" definition talks about signature authentication > failures. Should be path authorization failures. I made it SPF failures since that's what we're talking about. > - The DKIM reporting draft includes "rs=" to ask rejecting sites to > use a particular string in the SMTP reply. Is that omitted here for a > reason? (I have some vague recollection that SPF itself can do this, so > maybe that's why.) Yes. This is done with the exp= modifier. > - The ABNF for "spf-rr-tag" includes a reference to "spf-ro-tag" > which is undefined. Changed to 'spf-rr-type'. > - Section 4 also refers to the "ro" token, which should probably > also become "rr". Fixed. > - Section 4 also refers to "these lists", but there's only one. Fixed > - A note for later: If the SPFbis effort renames the result codes > to all lowercase, it'll have to "Updates" this one. Or not since they're technically case insensitive, either way we can address it later. I think it's an editorial preference, not a technical characteristic. > That's it. Great. Scott K From internet-drafts@ietf.org Thu Feb 16 11:47:44 2012 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 C74E621E809A; Thu, 16 Feb 2012 11:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYcQ2LFc4+kO; Thu, 16 Feb 2012 11:47:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6339A21F87CA; Thu, 16 Feb 2012 11:47:21 -0800 (PST) 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.64p2 Message-ID: <20120216194721.10256.17304.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2012 11:47:21 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-spf-reporting-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 19:47:44 -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-07.txt Pages : 13 Date : 2012-02-16 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. This memo updates RFC4408 by providing an IANA registry for SPF modifiers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-spf-reporting-07.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-07.txt From sklist@kitterman.com Thu Feb 16 11:49:05 2012 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 9CEE321E808C for ; Thu, 16 Feb 2012 11:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+X9WLtFbdQE for ; Thu, 16 Feb 2012 11:49:01 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B58A221E807B for ; Thu, 16 Feb 2012 11:48:55 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1756A20E40BB; Thu, 16 Feb 2012 14:48:55 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1329421735; bh=lB7LQXBAFfHkMyabO8ZfNb2iPT98u4K87Wn8zGA5y9M=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=oXghH+aoDLpllT3h9Yk1bfghf6FlH1zXCLfy/GYjQZ+Y/nQHzfXffCnn5JfHyBWlE AC+tFd/meAp1noenOv2IQHy440bAFujwAPOcZxTPW/1D9L835eC9yS/OGqfVzYJ6pz 17fIICLjANZsZeyvT6yzaB4f4CQWXvRg04CMLbpo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id EC52F20E406C; Thu, 16 Feb 2012 14:48:54 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Thu, 16 Feb 2012 14:48:54 -0500 Message-ID: <1359133.UlS9IDQpDZ@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120216194721.10256.17304.idtracker@ietfa.amsl.com> References: <20120216194721.10256.17304.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 19:49:05 -0000 On Thursday, February 16, 2012 11:47:21 AM internet-drafts@ietf.org wrote: > 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-07.txt ... This revision adds that it updates RFC 4408 and has other corrections based on Murrays' comments. Scott K From johnl@iecc.com Thu Feb 16 12:11:42 2012 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 8D6F321F87B4 for ; Thu, 16 Feb 2012 12:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.786 X-Spam-Level: X-Spam-Status: No, score=-109.786 tagged_above=-999 required=5 tests=[AWL=1.413, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1vH4WGBT-de for ; Thu, 16 Feb 2012 12:11:37 -0800 (PST) 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 F058321F8772 for ; Thu, 16 Feb 2012 12:11:36 -0800 (PST) Received: (qmail 34415 invoked from network); 16 Feb 2012 20:11:19 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 16 Feb 2012 20:11:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f3d62e7.xn--btvx9d.k1202; i=johnl@user.iecc.com; bh=GkKr99XKRgpqa/YLHawCnvlone2rf+Ja/XylYH35VEo=; b=exXBqxlyJLXKLOfhtUc7Swm2wjoj9jVnOU0smV2q3SKmKXU2eW1aDxCiqYhW8ShYpEMXxzFmEOaHj5r4Eg7Rc5nA2tYWMPsSF8yR50B2BBCq37wB0bGPQLwlEWGVV6nW/yHfBXsB4z4Dn06L7zHC+ulzxxOsY/WUTDtOfVNAUdw= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f3d62e7.xn--btvx9d.k1202; olt=johnl@user.iecc.com; bh=GkKr99XKRgpqa/YLHawCnvlone2rf+Ja/XylYH35VEo=; b=iDs1tjk8MvVR4ILmAMyfYwFVUefAOtma46N2U0qPPVaVwAKhw3zbkvfy91AHbZcw0jitrTBl6MpAE1zwq9iWlZoygwPGdAWQAEPUfO3nEhaOLk7pRntL7CD0fS6uuXhc0tmu40J/eNuwDtj4yGSP6fHlx68zPQqYtGH5xfNF1mw= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 16 Feb 2012 20:10:57 -0000 Message-ID: <20120216201057.21706.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <132944365.AW8sBqTBL3@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] [Technical Errata Reported] RFC5965 (3120) 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, 16 Feb 2012 20:11:42 -0000 >I'm going to proceed on the assumption that the errata will eventually be >confirmed and that's sufficient or some was will be found to stuff it into I- >D.IETF-MARF-AUTHFAILURE-REPORT/AS and that I don't need to directly address it >in the SPF draft. I don't see an non-contrived way to do it. Since I'm the one who gets to confirm it, that seems like a safe assumption. R's, John From msk@cloudmark.com Fri Feb 17 10:00:11 2012 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 E939221F8789 for ; Fri, 17 Feb 2012 10:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lmVu8QQdsTK for ; Fri, 17 Feb 2012 10:00:11 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7D48921F877A for ; Fri, 17 Feb 2012 10:00:11 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 17 Feb 2012 10:00:11 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 17 Feb 2012 10:00:11 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 17 Feb 2012 10:00:09 -0800 Thread-Topic: ID Tracker State Update Notice: Thread-Index: AcztmMtPw7QoqBB6SuqaLZtXP//FhwABSSDg 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [marf] FW: ID Tracker State Update Notice: 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, 17 Feb 2012 18:00:12 -0000 VGhlIHJlZGFjdGlvbiBkcmFmdCBoYXMgY29tcGxldGVkIGl0cyAodGhpcmQhKSBJRVRGIExhc3Qg Q2FsbCBhbmQgaXMgbm93IGFwcHJvdmVkIGZvciBwdWJsaWNhdGlvbi4NCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IElFVEYgU2VjcmV0YXJpYXQgW21haWx0bzppZXRmLXNlY3Jl dGFyaWF0LXJlcGx5QGlldGYub3JnXSANClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMTcsIDIwMTIg OToyMyBBTQ0KVG86IG1hcmYtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLW1hcmYt cmVkYWN0aW9uQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBJRCBUcmFja2VyIFN0YXRlIFVwZGF0 ZSBOb3RpY2U6IDxkcmFmdC1pZXRmLW1hcmYtcmVkYWN0aW9uLTA4LnR4dD4NCg0KU3RhdGUgY2hh bmdlZCB0byBBcHByb3ZlZC1hbm5vdW5jZW1lbnQgdG8gYmUgc2VudCBmcm9tIFdhaXRpbmcgZm9y IEFEIEdvLUFoZWFkLg0KSUQgVHJhY2tlciBVUkw6IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1tYXJmLXJlZGFjdGlvbi8NCg0K From msk@cloudmark.com Fri Feb 17 12:04:38 2012 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 4E76E21F866A for ; Fri, 17 Feb 2012 12:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBMj5EUj2got for ; Fri, 17 Feb 2012 12:04:37 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 620CE21F866C for ; Fri, 17 Feb 2012 12:04:21 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 17 Feb 2012 12:04:21 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 17 Feb 2012 12:04:21 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 17 Feb 2012 12:04:20 -0800 Thread-Topic: REMINDER: WGLC for draft-ietf-marf-{spf,dkim}-reporting ends in one week Thread-Index: Acztr1XCyT9dQ4TqRjm1Rinf0gtB+g== 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_F5833273385BB34F99288B3648C4F06F19C9A7DDFEEXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-reporting ends in one week 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, 17 Feb 2012 20:04:38 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DDFEEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please provide your review comments ASAP for these two drafts, and definite= ly before the end of WGLC so they can be discussed if needed. Thanks! -MSK --_000_F5833273385BB34F99288B3648C4F06F19C9A7DDFEEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please provide y= our review comments ASAP for these two drafts, and definitely before the en= d of WGLC so they can be discussed if needed.


Thanks!

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DDFEEXCHC2corpclo_-- From iesg-secretary@ietf.org Tue Feb 21 11:04:17 2012 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 A000221F8543; Tue, 21 Feb 2012 11:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.753 X-Spam-Level: X-Spam-Status: No, score=-102.753 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jV2USdZfIyR; Tue, 21 Feb 2012 11:04:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0FC21F8657; Tue, 21 Feb 2012 11:04:11 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120221190411.16769.44081.idtracker@ietfa.amsl.com> Date: Tue, 21 Feb 2012 11:04:11 -0800 Cc: marf mailing list , marf chair , RFC Editor Subject: [marf] Protocol Action: 'Redaction of Potentially Sensitive Data from Mail Abuse Reports' to Proposed Standard (draft-ietf-marf-redaction-08.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, 21 Feb 2012 19:04:17 -0000 The IESG has approved the following document: - 'Redaction of Potentially Sensitive Data from Mail Abuse Reports' (draft-ietf-marf-redaction-08.txt) as a Proposed Standard This document is the product of the Messaging Abuse Reporting Format Working Group. The IESG contact persons are Pete Resnick and Peter Saint-Andre. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/ Technical Summary Email messages often contain information which might be considered private or sensitive, per either regulation or social norms. When such a message becomes the subject of a report intended to be shared with other entities, the report generator may wish to redact or elide the sensitive portions of the message. This memo suggests one method for doing so effectively. Working Group Summary There was little controversy. This is obviously something needed and is in current use within production feedback loops. Document Quality There are some existing implementations of feedback loops that follow this process, and others that vary a little because they are earlier implementations which informed this specification. There is certainly consensus within industry that this is an appopropriate specification upon which to converge. Personnel Murray Kucherawy is the Document Shepherd. Pete Resnick is the cognizant AD. From msk@cloudmark.com Tue Feb 21 13:40:24 2012 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 3AEDB21E809F for ; Tue, 21 Feb 2012 13:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NavrZSBDZ78c for ; Tue, 21 Feb 2012 13:40:23 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8D05B21E807D for ; Tue, 21 Feb 2012 13:40:23 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Feb 2012 13:40:23 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 21 Feb 2012 13:40:22 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 21 Feb 2012 13:40:22 -0800 Thread-Topic: [marf] REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-reporting ends in one week Thread-Index: Acztr1XCyT9dQ4TqRjm1Rinf0gtB+gDMfNgg Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_F5833273385BB34F99288B3648C4F06F19C9A7DE54EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] FW: REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-reporting ends in one week 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, 21 Feb 2012 21:40:24 -0000 --_004_F5833273385BB34F99288B3648C4F06F19C9A7DE54EXCHC2corpclo_ Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C9A7DE54EXCHC2corpclo_" --_000_F5833273385BB34F99288B3648C4F06F19C9A7DE54EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are a few days left in this WGLC. Can we see some review comments, p= lease, even if it's just a sentence or two in support? -MSK --_000_F5833273385BB34F99288B3648C4F06F19C9A7DE54EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There are a few = days left in this WGLC.  Can we see some review comments, please, even= if it’s just a sentence or two in support?

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DE54EXCHC2corpclo_-- --_004_F5833273385BB34F99288B3648C4F06F19C9A7DE54EXCHC2corpclo_ Content-Type: message/rfc822 Received: from EXCH-HTCAS902.corp.cloudmark.com (172.22.10.74) by spite.corp.cloudmark.com (172.22.10.72) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 17 Feb 2012 12:04:46 -0800 Received: from mail.cloudmark.com (208.83.136.59) by ht2.cloudmark.com (172.22.10.81) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 17 Feb 2012 12:04:45 -0800 Received: from mail.ietf.org ?(mail.ietf.org [12.22.58.30]) by mail.cloudmark.com (8.14.3/8.14.3) with ESMTP id q1HK4ehq024187; Fri, 17 Feb 2012 12:04:40 -0800 (envelope-from marf-bounces@ietf.org) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677BB21F8673; Fri, 17 Feb 2012 12:04:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E76E21F866A for ; Fri, 17 Feb 2012 12:04:38 -0800 (PST) Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBMj5EUj2got for ; Fri, 17 Feb 2012 12:04:37 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 620CE21F866C for ; Fri, 17 Feb 2012 12:04:21 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 17 Feb 2012 12:04:21 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 17 Feb 2012 12:04:21 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Sender: "marf-bounces@ietf.org" Date: Fri, 17 Feb 2012 12:04:20 -0800 Subject: [marf] REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-reporting ends in one week Thread-Topic: [marf] REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-reporting ends in one week Thread-Index: Acztr1XCyT9dQ4TqRjm1Rinf0gtB+g== Message-ID: List-Help: List-Subscribe: , List-Unsubscribe: , Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: exch-htcas902.corp.cloudmark.com X-MS-Has-Attach: yes X-Auto-Response-Suppress: All X-MS-Exchange-Organization-SenderIdResult: Pass X-MS-Exchange-Organization-SCL: -1 X-MS-Exchange-Organization-PRD: ietf.org X-MS-TNEF-Correlator: acceptlanguage: en-US received-spf: Pass (exch-htcas902.corp.cloudmark.com: domain of marf-bounces@ietf.org designates 12.22.58.30 as permitted sender) receiver=exch-htcas902.corp.cloudmark.com; client-ip=12.22.58.30; helo=mail.cloudmark.com; dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1329509080; bh=g/0A1TmF0LUa9xkSgnPQbr886/CaCbDEKk7g87y3WbE=; h=From:To:Date:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=jAgy6KlG8HPS1KsoMBHZym4g3OE/4J21mQ5cQsQIrbg7VsLk/C7UfZ3dYt7G6TDhO JGWUKgNiznRyMvevQFBcnc9QnL3KN0RZbhyW1RlTymtfX4IDdajVycJYKahxKMb/3v 0h+qYRXoKGun53WmdSl3t/0tT8kv6s5UyXShjSx4= errors-to: marf-bounces@ietf.org delivered-to: marf@ietfa.amsl.com x-spam-flag: NO x-virus-scanned: amavisd-new at amsl.com x-spam-score: -102.594 x-spam-level: x-spam-status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] x-original-to: marf@ietfa.amsl.com x-beenthere: marf@ietf.org x-mailman-version: 2.1.12 list-id: Message Abuse Report Format working group discussion list list-archive: list-post: Content-Type: multipart/mixed; boundary="_004_F5833273385BB34F99288B3648C4F06F19C9A7DDFEEXCHC2corpclo_" MIME-Version: 1.0 --_004_F5833273385BB34F99288B3648C4F06F19C9A7DDFEEXCHC2corpclo_ Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C9A7DDFEEXCHC2corpclo_" --_000_F5833273385BB34F99288B3648C4F06F19C9A7DDFEEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please provide your review comments ASAP for these two drafts, and definite= ly before the end of WGLC so they can be discussed if needed. Thanks! -MSK --_000_F5833273385BB34F99288B3648C4F06F19C9A7DDFEEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please provide y= our review comments ASAP for these two drafts, and definitely before the en= d of WGLC so they can be discussed if needed.


Thanks!

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DDFEEXCHC2corpclo_-- --_004_F5833273385BB34F99288B3648C4F06F19C9A7DDFEEXCHC2corpclo_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Fri, 17 Feb 2012 20:04:47 GMT"; modification-date="Fri, 17 Feb 2012 20:04:47 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hcmYgbWFp bGluZyBsaXN0DQptYXJmQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21hcmYNCg== --_004_F5833273385BB34F99288B3648C4F06F19C9A7DDFEEXCHC2corpclo_-- --_004_F5833273385BB34F99288B3648C4F06F19C9A7DE54EXCHC2corpclo_-- From internet-drafts@ietf.org Thu Feb 23 10:03:59 2012 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 7A39221F853A; Thu, 23 Feb 2012 10:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zl+kwDMchv3D; Thu, 23 Feb 2012 10:03:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F2821F87EF; Thu, 23 Feb 2012 10:03:58 -0800 (PST) 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.64p2 Message-ID: <20120223180358.29946.61435.idtracker@ietfa.amsl.com> Date: Thu, 23 Feb 2012 10:03:58 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-as-10.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 18:03:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Messaging Abuse Reporting Format Work= ing Group of the IETF. Title : Creation and Use of Email Feedback Reports: An Applicabi= lity Statement for the Abuse Reporting Format (ARF) Author(s) : J.D. Falk M. Kucherawy Filename : draft-ietf-marf-as-10.txt Pages : 15 Date : 2012-02-23 RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This Applicability Statement describes common methods for utilizing this format for reporting both abuse and authentication failure events. Mailbox Providers of any size, mail sending entities, and end users can use these methods as a basis to create procedures that best suit them. Some related optional mechanisms are also discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-as-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-as-10.txt From msk@cloudmark.com Thu Feb 23 10:12:53 2012 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 937DA21F87E5 for ; Thu, 23 Feb 2012 10:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TA5VM0iKW8Xx for ; Thu, 23 Feb 2012 10:12:52 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2727221F879A for ; Thu, 23 Feb 2012 10:12:51 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Thu, 23 Feb 2012 10:12:51 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Thread-Topic: I-D Action: draft-ietf-marf-as-10.txt Thread-Index: AQHM8lWLsMmqbRNTokGcZeQaAgi37ZZKx9yQ Date: Thu, 23 Feb 2012 18:12:50 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928042F0F@exch-mbx901.corp.cloudmark.com> References: <20120223180358.29946.61435.idtracker@ietfa.amsl.com> In-Reply-To: <20120223180358.29946.61435.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.1.211.245] 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-as-10.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 18:12:53 -0000 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org > Sent: Thursday, February 23, 2012 10:04 AM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: I-D Action: draft-ietf-marf-as-10.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Messaging Abuse Reporting > Format Working Group of the IETF. >=20 > Title : Creation and Use of Email Feedback Reports: An > Applicability Statement for the Abuse Reporting Format (ARF) > Author(s) : J.D. Falk > M. Kucherawy > Filename : draft-ietf-marf-as-10.txt > Pages : 15 > Date : 2012-02-23 >=20 > RFC 5965 defines an extensible, machine-readable format intended for > mail operators to report feedback about received email to other > parties. This Applicability Statement describes common methods for > utilizing this format for reporting both abuse and authentication > failure events. Mailbox Providers of any size, mail sending > entities, and end users can use these methods as a basis to create > procedures that best suit them. Some related optional mechanisms are > also discussed. This version comes to you from the MAAWG meeting in San Francisco, where Jo= hn, Barry and I happen to have found some time to sit down and discuss the = changes John wants to see. He's happy with this version and I think it's r= easonable to initiate a second Working Group Last Call on this one. As Bar= ry will be shepherding, I'll let him make that announcement formally. Early reviews and comments are welcome, of course. If you'd like to see th= e changes it contains, see the datatracker and look at the History tab: http://datatracker.ietf.org/doc/draft-ietf-marf-as/ I think the plan is to have this WGLC complete in time to get it on a telec= hat before the Paris IETF meeting, so please review and comment sooner rath= er than later. -MSK From sklist@kitterman.com Thu Feb 23 10:34:01 2012 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 7175521F8849 for ; Thu, 23 Feb 2012 10:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmAkFIP4E2UI for ; Thu, 23 Feb 2012 10:34:00 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4030D21F8848 for ; Thu, 23 Feb 2012 10:34:00 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2FC1620E40CC; Thu, 23 Feb 2012 13:33:59 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330022039; bh=WcFDQVSmJVq0Hs4MosQrWkLoR2uMShrxWZxlmVZkX8U=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=pTd+c0vTSgvBO5dxVcIZIuBkqNJ5UT9Zn3GwF15C7a0rk8wtKkT6l1iFGr5jjpwq0 CDif0O+fFFpXEV7kdz5qyp3zmIAgW38F64Asz9QBezBRCweVKfnFX1NdONl+c1H5RW zFaTM7AEN6oZ/MpxI/tdUBlwjI3XbmCVlLay9/xA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 103B220E406C; Thu, 23 Feb 2012 13:33:58 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Thu, 23 Feb 2012 13:33:58 -0500 Message-ID: <1601116.TuoDItKi5V@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <9452079D1A51524AA5749AD23E003928042F0F@exch-mbx901.corp.cloudmark.com> References: <20120223180358.29946.61435.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E003928042F0F@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-as-10.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 18:34:01 -0000 On Thursday, February 23, 2012 06:12:50 PM Murray S. Kucherawy wrote: ... > Early reviews and comments are welcome, of course. ... Looks good to me. Scott K From barryleiba.mailing.lists@gmail.com Thu Feb 23 13:31:50 2012 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 2DBD021F87FC for ; Thu, 23 Feb 2012 13:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.988 X-Spam-Level: X-Spam-Status: No, score=-102.988 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id or-EXKrWf5X6 for ; Thu, 23 Feb 2012 13:31:49 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8B321F878E for ; Thu, 23 Feb 2012 13:31:49 -0800 (PST) Received: by yhkk25 with SMTP id k25so975008yhk.31 for ; Thu, 23 Feb 2012 13:31:46 -0800 (PST) Received-SPF: pass (google.com: domain of barryleiba.mailing.lists@gmail.com designates 10.236.37.132 as permitted sender) client-ip=10.236.37.132; Authentication-Results: mr.google.com; spf=pass (google.com: domain of barryleiba.mailing.lists@gmail.com designates 10.236.37.132 as permitted sender) smtp.mail=barryleiba.mailing.lists@gmail.com; dkim=pass header.i=barryleiba.mailing.lists@gmail.com Received: from mr.google.com ([10.236.37.132]) by 10.236.37.132 with SMTP id y4mr6484932yha.10.1330032706302 (num_hops = 1); Thu, 23 Feb 2012 13:31:46 -0800 (PST) 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; bh=aN9zFXuhxsv9oSNUxuqEYYXmZ5oeFaY3bVSklaRWPIA=; b=MCsrxjoYyTOToAP/sEw5aBdGKiYFJ8VTSitelao3BNceLOC99QPNQKhf3ezmdgAsd/ Jx/Uk4lUz9tfd0zzn2A45+nUmig3s41yGSptv8G8LCR+cwIZcUchQmDrVqhbYsgksjZs E3eozxY+JE5IQBZgxaUZt16PC24fLvUf3BbXw= MIME-Version: 1.0 Received: by 10.236.37.132 with SMTP id y4mr5240945yha.10.1330032706246; Thu, 23 Feb 2012 13:31:46 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.58.20 with HTTP; Thu, 23 Feb 2012 13:31:46 -0800 (PST) In-Reply-To: <9452079D1A51524AA5749AD23E003928042F0F@exch-mbx901.corp.cloudmark.com> References: <20120223180358.29946.61435.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E003928042F0F@exch-mbx901.corp.cloudmark.com> Date: Thu, 23 Feb 2012 16:31:46 -0500 X-Google-Sender-Auth: 8vk9_ZzDubg9hguOgeV9T2KhnVg Message-ID: From: Barry Leiba To: Message Abuse Report Format working group Content-Type: multipart/alternative; boundary=20cf302d4882fed9c904b9a85e63 Subject: Re: [marf] I-D Action: draft-ietf-marf-as-10.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 21:31:50 -0000 --20cf302d4882fed9c904b9a85e63 Content-Type: text/plain; charset=ISO-8859-1 > I think it's reasonable to initiate a second Working Group Last Call on this one. > As Barry will be shepherding, I'll let him make that announcement formally. And here it is: please comment on this version ASAP, and in any case no later than 2 March. We will consider this version ready to go to the IESG on that day, unless we hear specific objecions, with specific suggestions of what should change. > I think the plan is to have this WGLC complete in time to get it on a telechat > before the Paris IETF meeting, so please review and comment sooner rather > than later. There's no real chance of it being on a telechat before Paris: the last telechat is 15 March, so there isn't time to do an IETF last call before then. But we can have IETF last call end before Paris, and get on the first telechat after the meeting. That's the goal. Barry, as chair --20cf302d4882fed9c904b9a85e63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> I think it's reasonable to initiate a second Working Group La= st Call on this one.
> As Barry will be shepherding, I'll = let him make that announcement formally.

And here it is: please comm= ent on this version ASAP, and in any case no later than 2 March. =A0We will= consider this version ready to go to the IESG on that day, unless we hear = specific objecions, with specific suggestions of what should change.

> I think the plan is to have this WGLC complete in time to get it o= n a telechat
> before the Paris IETF meeting, so please review= and comment sooner rather
> than later.

There's no real chance of it being on a telechat before Paris: the= last telechat is 15 March, so there isn't time to do an IETF last call= before then. =A0But we can have IETF last call end before Paris, and get o= n the first telechat after the meeting. =A0That's the goal.

Barry, as chair
--20cf302d4882fed9c904b9a85e63-- From msk@cloudmark.com Thu Feb 23 13:47:32 2012 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 5281B11E807F for ; Thu, 23 Feb 2012 13:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L00ZekQF1c6b for ; Thu, 23 Feb 2012 13:47:31 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9A35311E8074 for ; Thu, 23 Feb 2012 13:47:31 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Thu, 23 Feb 2012 13:47:31 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Thread-Topic: [marf] FW: REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-reporting ends in one week Thread-Index: Acztr1XCyT9dQ4TqRjm1Rinf0gtB+gDMfNggAGTaG/A= Date: Thu, 23 Feb 2012 21:47:30 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392804384C@exch-mbx901.corp.cloudmark.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.1.211.245] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E00392804384Cexchmbx901corpclo_" MIME-Version: 1.0 Subject: Re: [marf] FW: REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-reporting ends in one week 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, 23 Feb 2012 21:47:32 -0000 --_000_9452079D1A51524AA5749AD23E00392804384Cexchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One more day. No new review comments? We're ready to go? From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Mur= ray S. Kucherawy Sent: Tuesday, February 21, 2012 1:40 PM To: marf@ietf.org Subject: [marf] FW: REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-reportin= g ends in one week There are a few days left in this WGLC. Can we see some review comments, p= lease, even if it's just a sentence or two in support? -MSK --_000_9452079D1A51524AA5749AD23E00392804384Cexchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One more day.  No= new review comments?  We’re ready to go?

 

From: marf-bou= nces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, February 21, 2012 1:40 PM
To: marf@ietf.org
Subject: [marf] FW: REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-r= eporting ends in one week

 

There are a few days left in this WGLC.  Can we= see some review comments, please, even if it’s just a sentence or tw= o in support?

-MSK

--_000_9452079D1A51524AA5749AD23E00392804384Cexchmbx901corpclo_-- From steve@wordtothewise.com Thu Feb 23 13:59:51 2012 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 A4E3721E8018 for ; Thu, 23 Feb 2012 13:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmN4TZLgoEuS for ; Thu, 23 Feb 2012 13:59:51 -0800 (PST) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id C91B721E8012 for ; Thu, 23 Feb 2012 13:59:50 -0800 (PST) Received: from [10.101.1.42] (64.1.211.245.ptr.us.xo.net [64.1.211.245]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id 65AE22EB25 for ; Thu, 23 Feb 2012 13:59:50 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Steve Atkins In-Reply-To: <9452079D1A51524AA5749AD23E003928042F0F@exch-mbx901.corp.cloudmark.com> Date: Thu, 23 Feb 2012 13:59:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4CFE9B1F-9C79-4C4A-9ABA-E0FAE319B920@wordtothewise.com> References: <20120223180358.29946.61435.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E003928042F0F@exch-mbx901.corp.cloudmark.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1257) Subject: Re: [marf] I-D Action: draft-ietf-marf-as-10.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 21:59:52 -0000 On Feb 23, 2012, at 10:12 AM, Murray S. Kucherawy wrote: >>=20 >=20 > This version comes to you from the MAAWG meeting in San Francisco, = where John, Barry and I happen to have found some time to sit down and = discuss the changes John wants to see. He's happy with this version and = I think it's reasonable to initiate a second Working Group Last Call on = this one. As Barry will be shepherding, I'll let him make that = announcement formally. >=20 > Early reviews and comments are welcome, of course. If you'd like to = see the changes it contains, see the datatracker and look at the History = tab: >=20 > http://datatracker.ietf.org/doc/draft-ietf-marf-as/ >=20 > I think the plan is to have this WGLC complete in time to get it on a = telechat before the Paris IETF meeting, so please review and comment = sooner rather than later. Looks fine to me. Cheers, Steve= From barryleiba.mailing.lists@gmail.com Thu Feb 23 14:24:03 2012 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 D0CD621F882B for ; Thu, 23 Feb 2012 14:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.988 X-Spam-Level: X-Spam-Status: No, score=-102.988 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ra9+Q0QHZFyf for ; Thu, 23 Feb 2012 14:23:57 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE6121F8826 for ; Thu, 23 Feb 2012 14:23:53 -0800 (PST) Received: by yenm3 with SMTP id m3so999660yen.31 for ; Thu, 23 Feb 2012 14:23:52 -0800 (PST) Received-SPF: pass (google.com: domain of barryleiba.mailing.lists@gmail.com designates 10.236.145.230 as permitted sender) client-ip=10.236.145.230; Authentication-Results: mr.google.com; spf=pass (google.com: domain of barryleiba.mailing.lists@gmail.com designates 10.236.145.230 as permitted sender) smtp.mail=barryleiba.mailing.lists@gmail.com; dkim=pass header.i=barryleiba.mailing.lists@gmail.com Received: from mr.google.com ([10.236.145.230]) by 10.236.145.230 with SMTP id p66mr6602079yhj.27.1330035832315 (num_hops = 1); Thu, 23 Feb 2012 14:23:52 -0800 (PST) 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; bh=Zs/QyuIc+Z5C9UztyNjtrEZ7cGZUuhaSKXNehdS0ZeM=; b=r/hx/v0/4m6nu9bl7LawHB5f4QmeNsrhGsUYe4k1/3ZCpZAqw0qxv6ivjVAAMZnqbV F/crSvI152EFQ8Uk132D6IEVSuAAWPq/y9XgIZqR56CpzgS2rbe2OIYQ0FQi5PeKPe8u 6Cich4dj7V+56RuFsQq1Ru6G5LTwLd2ycYGiw= MIME-Version: 1.0 Received: by 10.236.145.230 with SMTP id p66mr5333222yhj.27.1330035832244; Thu, 23 Feb 2012 14:23:52 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.58.20 with HTTP; Thu, 23 Feb 2012 14:23:52 -0800 (PST) In-Reply-To: <9452079D1A51524AA5749AD23E003928042F0F@exch-mbx901.corp.cloudmark.com> References: <20120223180358.29946.61435.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E003928042F0F@exch-mbx901.corp.cloudmark.com> Date: Thu, 23 Feb 2012 17:23:52 -0500 X-Google-Sender-Auth: 65DZRyozUWld32cRjAh4xzn7yvI Message-ID: From: Barry Leiba To: Message Abuse Report Format working group Content-Type: multipart/alternative; boundary=20cf3040eb3251cb4104b9a9196a Subject: Re: [marf] I-D Action: draft-ietf-marf-as-10.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 22:24:04 -0000 --20cf3040eb3251cb4104b9a9196a Content-Type: text/plain; charset=ISO-8859-1 > I think it's reasonable to initiate a second Working Group Last Call on this one. > As Barry will be shepherding, I'll let him make that announcement formally. And here it is: please comment on this version ASAP, and in any case no later than 2 March. We will consider this version ready to go to the IESG on that day, unless we hear specific objecions, with specific suggestions of what should change. > I think the plan is to have this WGLC complete in time to get it on a telechat > before the Paris IETF meeting, so please review and comment sooner rather > than later. There's no real chance of it being on a telechat before Paris: the last telechat is 15 March, so there isn't time to do an IETF last call before then. But we can have IETF last call end before Paris, and get on the first telechat after the meeting. That's the goal. Barry, as chair --20cf3040eb3251cb4104b9a9196a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> I think it's reasonable to initiate a second Working Group La= st Call on this one.
> As Barry will be shepherding, I'll = let him make that announcement formally.

And here it is: please comm= ent on this version ASAP, and in any case no later than 2 March. =A0We will= consider this version ready to go to the IESG on that day, unless we hear = specific objecions, with specific suggestions of what should change.

> I think the plan is to have this WGLC complete in time to get it o= n a telechat
> before the Paris IETF meeting, so please review= and comment sooner rather
> than later.

There's no real chance of it being on a telechat before Paris: the= last telechat is 15 March, so there isn't time to do an IETF last call= before then. =A0But we can have IETF last call end before Paris, and get o= n the first telechat after the meeting. =A0That's the goal.

Barry, as chair
--20cf3040eb3251cb4104b9a9196a-- From shmuel+gen@patriot.net Thu Feb 23 19:34:15 2012 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 8891E11E80AA for ; Thu, 23 Feb 2012 19:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXlKTfhPPD-Z for ; Thu, 23 Feb 2012 19:34:14 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 666EA11E80A3 for ; Thu, 23 Feb 2012 19:34:14 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.19]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 774C0F580CA for ; Thu, 23 Feb 2012 22:19:14 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Thu, 23 Feb 2012 22:34:16 -0500 To: marf@ietf.org In-Reply-To: <20120223180358.29946.61435.idtracker@ietfa.amsl.com> Mail-Copies-To: nobody 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: <20120224031914.774C0F580CA@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-10.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 03:34:15 -0000 In <20120223180358.29946.61435.idtracker@ietfa.amsl.com>, on 02/23/2012 at 10:03 AM, internet-drafts@ietf.org said: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-as-10.txt IMAP -< IMAP4 rpeorts -> reports -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From vesely@tana.it Fri Feb 24 10:43:37 2012 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 ED02621F8828 for ; Fri, 24 Feb 2012 10:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unHyR7Ta6ZEs for ; Fri, 24 Feb 2012 10:43:37 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id EC9C821F8817 for ; Fri, 24 Feb 2012 10:43:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1330109015; bh=0dPBmMgKRmttzcm5ORvaV5I2oKRvcPrIQwSTTBXnh/k=; l=2308; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Skd/9ObyVqIRhRA3spnystDUlWYJBA0MYQEvf3YBE/TLxfIoLLu4qizXT+r6OHlyg G52ChEm4Ye+NeVS7jqSzCIkZ31aUJ6zbRe701IS6GDaeIT6SA79QPDD4tUo2KKy0eq Kbs4zRWlmO6cxgnUxe8b/DZ3KGfd5sh0118YzygA= 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, 24 Feb 2012 19:43:35 +0100 id 00000000005DC033.000000004F47DA57.00003016 Message-ID: <4F47DA56.8090105@tana.it> Date: Fri, 24 Feb 2012 19:43:34 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120223180358.29946.61435.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E003928042F0F@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E003928042F0F@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-10.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, 24 Feb 2012 18:43:38 -0000 On 23/Feb/12 19:12, Murray S. Kucherawy wrote: > I think the plan is to have this WGLC complete in time to get it on > a telechat before the Paris IETF meeting, so please review and > comment sooner rather than later. I have four points only: *Solicited and Unsolicited Reports* Section 3 may sound misleading, as it may seem to exclude that unsolicited reports may also be "due to recipients manually reporting messages as spam." (The introduction can be understood both ways.) I propose to replace the first snippet of the second paragraph (Other uses... how these unsolicited reports) with: In case no prior arrangement was made with the origin of a message that deserves being reported, it is some times fit to send the report just the same. We refer to these as unsolicited reports. Since the context and meaning of the reports cannot be established beforehand, the constraints on how these unsolicited reports [...] (Really, solicited/unsolicited sending is transparent to the user or any other stream-wise similar input mechanisms. Is it too late to try and treat #1 of Section 4.1 and #2 of Section 6.2 in a unified common section?) *When To Generate Reports* The title of Section 6.2 should more appropriately be "When /Not/ To Generate Reports", except for the last paragraph that matches neither title. How about moving #5 to the previous (General Considerations) subsection? *Where To Send Reports* SPF doesn't sign. In paragraph #4 of Section 6.3, I'd replace: Where an abusive message is signed using a domain-level authentication technology such as DKIM ([RFC6376]) or SPF ([RFC4408]), the domain that has been verified by the with: Where an abusive message is authenticated using a domain-level authentication technology such as DKIM ([RFC6376]) or SPF ([RFC4408]), the domain that got a "pass" ([RFC5451]) by the (Is it possible to cite IANA's "Email Authentication Result Names" rather than, or in addition to, [RFC5451]?) *What To Do With Reports* No vacation replies. In paragraph #4 of Section 6.5, I'd replace: a reply might be desirable to indicate that the complaint will result in action with: a non-automated reply might be desirable to indicate what action resulted from the complaint From msk@cloudmark.com Fri Feb 24 13:12:30 2012 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 98D2F21F86FF for ; Fri, 24 Feb 2012 13:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGyWQiHbTquZ for ; Fri, 24 Feb 2012 13:12:24 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB1121F86F9 for ; Fri, 24 Feb 2012 13:12:23 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Fri, 24 Feb 2012 13:12:22 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-10.txt Thread-Index: AQHM8lWLsMmqbRNTokGcZeQaAgi37ZZKx9yQgAIiAQD//597wA== Date: Fri, 24 Feb 2012 21:12:21 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280454F2@exch-mbx901.corp.cloudmark.com> References: <20120223180358.29946.61435.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E003928042F0F@exch-mbx901.corp.cloudmark.com> <4F47DA56.8090105@tana.it> In-Reply-To: <4F47DA56.8090105@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] 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-as-10.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, 24 Feb 2012 21:12:30 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Friday, February 24, 2012 10:44 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-as-10.txt A co-chair's note: At this point I think it's prudent to say we won't make = any more changes unless they achieve rough consensus or they are merely min= or editorial corrections. > I have four points only: >=20 > *Solicited and Unsolicited Reports* >=20 > Section 3 may sound misleading, as it may seem to exclude that > unsolicited reports may also be "due to recipients manually reporting > messages as spam." (The introduction can be understood both ways.) Making a backward reference about the cause of the reports from the second = paragraph to the first is possibly a simpler change than what you propose, = i.e.: "Other uses for ARF involve such reports sent between parties that don't kn= ow each other." Is that sufficient? > (Really, solicited/unsolicited sending is transparent to the user or > any other stream-wise similar input mechanisms. Is it too late to try > and treat #1 of Section 4.1 and #2 of Section 6.2 in a unified common > section?) I'm somewhat partial against having a "common" section. What do others thi= nk? Also, what do others think of the idea of talking about spam traps in Secti= on 4.1? It doesn't seem to me as though it's advice specific to unsolicite= d reports, unless that would be something covered in the agreement implicat= ed in a solicited feedback arrangement. > *When To Generate Reports* >=20 > The title of Section 6.2 should more appropriately be "When /Not/ To > Generate Reports", except for the last paragraph that matches neither > title. How about moving #5 to the previous (General Considerations) > subsection? I don't agree with the renaming, but I agree with the proposed rearrangemen= t. Others? > *Where To Send Reports* >=20 > SPF doesn't sign. In paragraph #4 of Section 6.3, I'd replace: >=20 > Where an abusive message is signed using a domain-level > authentication technology such as DKIM ([RFC6376]) or SPF > ([RFC4408]), the domain that has been verified by the >=20 > with: >=20 > Where an abusive message is authenticated using a domain-level > authentication technology such as DKIM ([RFC6376]) or SPF > ([RFC4408]), the domain that got a "pass" ([RFC5451]) by the >=20 > (Is it possible to cite IANA's "Email Authentication Result Names" > rather than, or in addition to, [RFC5451]?) I agree with changing "signed" to "authenticated", but I think the rest goe= s too far without making the point any more clearly. > *What To Do With Reports* >=20 > No vacation replies. In paragraph #4 of Section 6.5, I'd replace: >=20 > a reply might be desirable to indicate that the complaint will > result in action >=20 > with: >=20 > a non-automated reply might be desirable to indicate what action > resulted from the complaint I agree with that one. -MSK From vesely@tana.it Sat Feb 25 01:33:38 2012 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 5D96521F86B5 for ; Sat, 25 Feb 2012 01:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvmfWnKx94wa for ; Sat, 25 Feb 2012 01:33:37 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 70EE521F86B3 for ; Sat, 25 Feb 2012 01:33:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1330162414; bh=z36lfS0gCij1NM+s3gB8Wd8NpGFQ03mfn4cjGTNFl+U=; l=3667; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ehPgeHS7AP2mcqzacjz9rhGN9jyG7aaatO/tTKcoNNtRUytDYBmtLPiENf3tbjEsx WIsIZbE14grjO1q6Q+8Zuj72JfZoe5Rry4694UZslY68CnMd9ktRFsKtKPOm1uTqne 9mYwEQjgPIC0Qs8EWPFxDPZQkCnPXBY1QzhVfHl0= 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, 25 Feb 2012 10:33:34 +0100 id 00000000005DC039.000000004F48AAEE.00007878 Message-ID: <4F48AAEE.9040409@tana.it> Date: Sat, 25 Feb 2012 10:33:34 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20120223180358.29946.61435.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E003928042F0F@exch-mbx901.corp.cloudmark.com> <4F47DA56.8090105@tana.it> <9452079D1A51524AA5749AD23E0039280454F2@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280454F2@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-10.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 09:33:38 -0000 On 24/Feb/12 22:12, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely > > A co-chair's note: At this point I think it's prudent to say we > won't make any more changes unless they achieve rough consensus or > they are merely minor editorial corrections. > >> *Solicited and Unsolicited Reports* >> >> Section 3 may sound misleading, as it may seem to exclude that >> unsolicited reports may also be "due to recipients manually reporting >> messages as spam." (The introduction can be understood both ways.) > > Making a backward reference about the cause of the reports from the > second paragraph to the first is possibly a simpler change than > what you propose, i.e.: > > "Other uses for ARF involve such reports sent between parties that > don't know each other." > > Is that sufficient? Ehm, possibly; my English doesn't support me quite enough. If "such" unambiguously refers to the same reports that the first paragraph alludes to, then it is sufficient. >> (Really, solicited/unsolicited sending is transparent to the user or >> any other stream-wise similar input mechanisms. Is it too late to try >> and treat #1 of Section 4.1 and #2 of Section 6.2 in a unified common >> section?) > > I'm somewhat partial against having a "common" section. What do > others think? This subject is peculiar in that the I-D does not specify it at all. This consideration can justify a different editorial arrangement. > Also, what do others think of the idea of talking about spam traps > in Section 4.1? It doesn't seem to me as though it's advice > specific to unsolicited reports, unless that would be something > covered in the agreement implicated in a solicited feedback > arrangement. Viruses is a similar idea, left as a hint. But hinting twice would become pushing. >> *When To Generate Reports* >> >> The title of Section 6.2 should more appropriately be "When /Not/ To >> Generate Reports", except for the last paragraph that matches neither >> title. How about moving #5 to the previous (General Considerations) >> subsection? > > I don't agree with the renaming, but I agree with the proposed > rearrangement. Fine. > Others? ... >> *Where To Send Reports* >> >> SPF doesn't sign. In paragraph #4 of Section 6.3, I'd replace: >> >> Where an abusive message is signed using a domain-level >> authentication technology such as DKIM ([RFC6376]) or SPF >> ([RFC4408]), the domain that has been verified by the >> >> with: >> >> Where an abusive message is authenticated using a domain-level >> authentication technology such as DKIM ([RFC6376]) or SPF >> ([RFC4408]), the domain that got a "pass" ([RFC5451]) by the >> >> (Is it possible to cite IANA's "Email Authentication Result Names" >> rather than, or in addition to, [RFC5451]?) > > I agree with changing "signed" to "authenticated", but I think the > rest goes too far without making the point any more clearly. IMHO, it'd be very pertinent to include RFC 5451 among normative references, because of the pivotal role that it plays in reports generation of both types. As for leaving "pass" implied rather than explicit, it is consistent with presenting targets selection as an heuristic process, so I can live with it. >> *What To Do With Reports* >> >> No vacation replies. In paragraph #4 of Section 6.5, I'd replace: >> >> a reply might be desirable to indicate that the complaint will >> result in action >> >> with: >> >> a non-automated reply might be desirable to indicate what action >> resulted from the complaint > > I agree with that one. Thank you. From msk@cloudmark.com Sat Feb 25 20:39:15 2012 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 116C021F8621 for ; Sat, 25 Feb 2012 20:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68eJvL71cLxW for ; Sat, 25 Feb 2012 20:39:14 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACDB21F8628 for ; Sat, 25 Feb 2012 20:39:14 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Sat, 25 Feb 2012 20:39:13 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Thread-Topic: Meeting scheduled Thread-Index: Acz0QJbrNkpFbyCSTHqznQQthS7W/w== Date: Sun, 26 Feb 2012 04:39:12 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928047067@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E003928047067exchmbx901corpclo_" MIME-Version: 1.0 Subject: [marf] Meeting scheduled 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, 26 Feb 2012 04:39:15 -0000 --_000_9452079D1A51524AA5749AD23E003928047067exchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For those of you planning to attend: We have been given a 5:10pm slot for one hour on Tuesday at the Paris IETF = Meeting. This should be the last time this WG meets as by then all of our = deliverables should have completed their IETF Last Calls and be on their wa= y to the IESG. See you there! -MSK --_000_9452079D1A51524AA5749AD23E003928047067exchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For those of you planning to attend:

 

We have been given a 5:10pm slot for one hour on Tue= sday at the Paris IETF Meeting.  This should be the last time this WG = meets as by then all of our deliverables should have completed their IETF L= ast Calls and be on their way to the IESG.

 

See you there!

 

-MSK

--_000_9452079D1A51524AA5749AD23E003928047067exchmbx901corpclo_-- From vesely@tana.it Mon Feb 27 01:19:47 2012 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 D085A21F85A5 for ; Mon, 27 Feb 2012 01:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.724 X-Spam-Level: X-Spam-Status: No, score=-3.724 tagged_above=-999 required=5 tests=[AWL=-0.864, BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miVQSWpnsD+S for ; Mon, 27 Feb 2012 01:19:45 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAA321F85CC for ; Mon, 27 Feb 2012 01:19:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1330334382; bh=rtEHr5Kf4dmD7hdkxDlpZviykNujhMJZ/4ShA9JusWM=; l=1160; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=hGL2f1lMN31DF6CtT1g4yEnpa1oal19w3GqgcLKbFhikUMO53BwSkdxrv4LCbZCoK kqNjRqlGSpJVQNBkZ4SM82BdKuvcnNXGzgfzv5uoQdgeRYM8ngO+v1HPTR0ZK3iA1O XImijM46vNo2y94CepuUS0gPukic468WYHJD324U= 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, 27 Feb 2012 10:19:42 +0100 id 00000000005DC039.000000004F4B4AAE.000077FE Message-ID: <4F4B4AAD.8010804@tana.it> Date: Mon, 27 Feb 2012 10:19:41 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <9452079D1A51524AA5749AD23E003928047067@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E003928047067@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Meeting scheduled 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, 27 Feb 2012 09:19:47 -0000 On 26/Feb/12 05:39, Murray S. Kucherawy wrote: > > We have been given a 5:10pm slot for one hour on Tuesday at the Paris > IETF Meeting. That's the same session as the MILE slot. In Taipei, Kathleen asked whether any MARF participant was present... I don't know whether she's going to repeat that in Paris. The issue is about a format to marshal ARF reports inside IODEF incidents, as John mentioned in http://mipassoc.org/pipermail/abuse-feedback-report/2009q3/000264.html See http://tools.ietf.org/html/draft-vesely-mile-mail-abuse for a proposed naked format. If LIRs are serious about mandatory abuse-mailboxes, they may actually need something like that. Do we have hints about how applications can handle xmllized ARF messages? > This should be the last time this WG meets as by then all of our > deliverables should have completed their IETF Last Calls and be on > their way to the IESG. No rechartering? Indeed, it seems we've even done some of the tasks --but not all-- that we thought we'd have to recharter for, see http://mipassoc.org/pipermail/abuse-feedback-report/2009q4/000463.html Le MARF est mort, vive le MARF! From msk@cloudmark.com Mon Feb 27 09:26:07 2012 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 925D221F87FF for ; Mon, 27 Feb 2012 09:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Y6gpunq3o-5 for ; Mon, 27 Feb 2012 09:26:06 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id A514221F87FC for ; Mon, 27 Feb 2012 09:26:06 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Mon, 27 Feb 2012 09:26:05 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Thread-Topic: [marf] Meeting scheduled Thread-Index: Acz0QJbrNkpFbyCSTHqznQQthS7W/wBM2aWAAAAZq1A= Date: Mon, 27 Feb 2012 17:26:05 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928048CA2@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E003928047067@exch-mbx901.corp.cloudmark.com> <4F4B4AAD.8010804@tana.it> In-Reply-To: <4F4B4AAD.8010804@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Meeting scheduled 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, 27 Feb 2012 17:26:07 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Monday, February 27, 2012 1:20 AM > To: marf@ietf.org > Subject: Re: [marf] Meeting scheduled >=20 > That's the same session as the MILE slot. In Taipei, Kathleen asked > whether any MARF participant was present... I don't know whether she's > going to repeat that in Paris. The issue is about a format to marshal > ARF reports inside IODEF incidents, as John mentioned in > http://mipassoc.org/pipermail/abuse-feedback-report/2009q3/000264.html We're not chartered to do any of this work, and we're not aware of any acti= ve cross-participation, so we didn't list MILE as a scheduling conflict. > See http://tools.ietf.org/html/draft-vesely-mile-mail-abuse for a > proposed naked format. If LIRs are serious about mandatory abuse- > mailboxes, they may actually need something like that. Do we have > hints about how applications can handle xmllized ARF messages? I haven't heard of any work in this area. Others? > > This should be the last time this WG meets as by then all of our > > deliverables should have completed their IETF Last Calls and be on > > their way to the IESG. >=20 > No rechartering? Indeed, it seems we've even done some of the tasks -- > but not all-- that we thought we'd have to recharter for, see > http://mipassoc.org/pipermail/abuse-feedback-report/2009q4/000463.html I asked more than once if the group wanted to pick up the reporting-discove= ry draft, but no champion came forward. I also asked JD's employer if they= wanted to appoint someone to pick up where he left off, but they weren't a= ble to commit the resources. There was also no consensus to support the idea of reporting general securi= ty incidents through ARF. If there are indeed people that want to do those things, the work can be re= sumed as individual submissions or perhaps through APPSAWG after MARF winds= down. -MSK From shmuel+gen@patriot.net Tue Feb 28 06:03:33 2012 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 5DED921F8613 for ; Tue, 28 Feb 2012 06:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[AWL=-1.127, BAYES_20=-0.74, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKemMoQfXwO7 for ; Tue, 28 Feb 2012 06:03:32 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4BB21F85B5 for ; Tue, 28 Feb 2012 06:03:32 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.149]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 1FD65F580C5 for ; Tue, 28 Feb 2012 08:48:24 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 27 Feb 2012 14:47:28 -0500 To: marf@ietf.org In-Reply-To: <9452079D1A51524AA5749AD23E003928048CA2@exch-mbx901.corp.cloudmark.com> Mail-Copies-To: nobody 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: <20120228134825.1FD65F580C5@smtp.patriot.net> Subject: Re: [marf] Meeting scheduled X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 14:03:33 -0000 In <9452079D1A51524AA5749AD23E003928048CA2@exch-mbx901.corp.cloudmark.com>, on 02/27/2012 at 05:26 PM, "Murray S. Kucherawy" said: >If there are indeed people that want to do those things, the work can >be resumed as individual submissions or perhaps through APPSAWG after >MARF winds down. Both discovery and security reporting seem worth doing, but absent a champion a consensus would be irrelevant. If discovering does go forward I'm willing to impliment it and provide the code, although not nicely packaged. -- 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 ajs@anvilwalrusden.com Tue Feb 28 08:56:33 2012 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 1BE4021F86A4 for ; Tue, 28 Feb 2012 08:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=-0.781, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAisSS8eO9jZ for ; Tue, 28 Feb 2012 08:56:32 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8C29121F86B9 for ; Tue, 28 Feb 2012 08:56:32 -0800 (PST) Received: from mail.yitter.info (nat-02-mht.dyndns.com [216.146.45.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 362F41ECB41C for ; Tue, 28 Feb 2012 16:56:31 +0000 (UTC) Date: Tue, 28 Feb 2012 11:56:22 -0500 From: Andrew Sullivan To: marf@ietf.org Message-ID: <20120228165614.GA51122@mail.yitter.info> References: <9452079D1A51524AA5749AD23E00392804384C@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9452079D1A51524AA5749AD23E00392804384C@exch-mbx901.corp.cloudmark.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [marf] FW: REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-reporting ends in one week 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, 28 Feb 2012 16:56:33 -0000 Dear colleagues, On Thu, Feb 23, 2012 at 09:47:30PM +0000, Murray S. Kucherawy wrote: > One more day. No new review comments? We're ready to go? This is a late review of draft-ietf-marf-spf-reporting-07. Apologies for it coming late (although I did warn the chairs I'd do it today). I have read the draft. Overall, I believe it is in good shape. I have a couple questions. First, a process issue. The header says that this is aimed for the standards track, and that it updates RFC 4408. The chairs are more experienced than I in the arcana of IETF process rules, but I think this is going to be tricky, isn't it? Second, in section 3, discussing rp=, the document says that a report SHOULD NOT be generated for percentages higher than that. Under what circumstances is it ok to generate outside of this guidance? Is this a resource issue? I don't understand when it would be ok. Those are all my comments. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From sklist@kitterman.com Tue Feb 28 09:11:10 2012 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 F362321F86EE for ; Tue, 28 Feb 2012 09:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9i0i4zaLyvX for ; Tue, 28 Feb 2012 09:11:09 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id DF42721F86F5 for ; Tue, 28 Feb 2012 09:11:07 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 06AD720E40E0; Tue, 28 Feb 2012 12:11:07 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330449067; bh=LLRV0aidRCuDbe3Ia4/kCKyAIKrdjklvBLUv1TEwRLo=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=IBesPJcTT9sGI/h45RcOXsZNVjXdy1ZSrC25Uk8JoQNIIwd6Vm1FocmipKoyphWcb CSxyPkjkrXaCyTFY1NcLgvuW3vp+I0ew2tH/x3azoCMNHZqdDS0ckvMPshkmgBJbwj OyVXiPJ1YlbMLCdqDB43b3e9HoFvvst3EeDibZ7s= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DF96720E4099; Tue, 28 Feb 2012 12:11:06 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Tue, 28 Feb 2012 12:11:02 -0500 Message-ID: <2104373.7GZjb5v8DT@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120228165614.GA51122@mail.yitter.info> References: <9452079D1A51524AA5749AD23E00392804384C@exch-mbx901.corp.cloudmark.com> <20120228165614.GA51122@mail.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] FW: REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-reporting ends in one week 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, 28 Feb 2012 17:11:10 -0000 On Tuesday, February 28, 2012 11:56:22 AM Andrew Sullivan wrote: > Dear colleagues, > > On Thu, Feb 23, 2012 at 09:47:30PM +0000, Murray S. Kucherawy wrote: > > One more day. No new review comments? We're ready to go? > > This is a late review of draft-ietf-marf-spf-reporting-07. Apologies > for it coming late (although I did warn the chairs I'd do it today). > > I have read the draft. Overall, I believe it is in good shape. I > have a couple questions. > > First, a process issue. The header says that this is aimed for the > standards track, and that it updates RFC 4408. The chairs are more > experienced than I in the arcana of IETF process rules, but I think > this is going to be tricky, isn't it? There's a process for dealing with downrefs. I think it's appropriate in this case. AIUI whoever does the post last call writeup on the draft has to document for the IESG why the downreft is appropriate. There's roughly no chance SPFbis will cause an impact on this specification, so it'd be wasteful to publish this as experimental and then come back once 4408bis is updated and republish the same document with a different label. > Second, in section 3, discussing rp=, the document says that a report > SHOULD NOT be generated for percentages higher than that. Under what > circumstances is it ok to generate outside of this guidance? Is this > a resource issue? I don't understand when it would be ok. It wouldn't be OK, but it wouldn't fundamentally cause an interoperability problem, so we didn't use MUST. The worst that's likely to happen is some of all of your reports get routed to /dev/null. > Those are all my comments. Thanks, Scott K From msk@cloudmark.com Tue Feb 28 09:22:21 2012 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 EFABF21F86E8 for ; Tue, 28 Feb 2012 09:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTwu8L5kOKov for ; Tue, 28 Feb 2012 09:22:20 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id E773B21F8562 for ; Tue, 28 Feb 2012 09:22:19 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Tue, 28 Feb 2012 09:22:19 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Thread-Topic: [marf] FW: REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-reporting ends in one week Thread-Index: AQHM9jv57T/RyH0Ey0qNfYK2XEmDcJZSjRkg Date: Tue, 28 Feb 2012 17:22:18 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392804B1CD@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E00392804384C@exch-mbx901.corp.cloudmark.com> <20120228165614.GA51122@mail.yitter.info> <2104373.7GZjb5v8DT@scott-latitude-e6320> In-Reply-To: <2104373.7GZjb5v8DT@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] FW: REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-reporting ends in one week 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, 28 Feb 2012 17:22:21 -0000 Thanks, Andrew, for your reviews. (To the WG: He did let me know ahead of = time that he'd be sending a late one.) > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= cott Kitterman > Sent: Tuesday, February 28, 2012 9:11 AM > To: marf@ietf.org > Subject: Re: [marf] FW: REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-re= porting ends in one week >=20 > > First, a process issue. The header says that this is aimed for the > > standards track, and that it updates RFC 4408. The chairs are more > > experienced than I in the arcana of IETF process rules, but I think > > this is going to be tricky, isn't it? >=20 > There's a process for dealing with downrefs. I think it's appropriate > in this case. AIUI whoever does the post last call writeup on the > draft has to document for the IESG why the downreft is appropriate. > There's roughly no chance SPFbis will cause an impact on this > specification, so it'd be wasteful to publish this as experimental and > then come back once 4408bis is updated and republish the same document > with a different label. Actually the reason I recommended including "Updates" is that this is suppo= sed to mean "If you implement the older spec, you really need to also read = the newer one." It creates that forward pointer in the RFC index and on so= me HTML renderings of the older documents. The specific reason for doing it in this case is the creation of the IANA r= egistry of modifiers, which RFC4408 didn't do. Someone that wants to make = a new one but only reads RFC4408 won't know the registry exists, so it seem= ed the forward pointer created by an "Updates" was appropriate. This is really a minor procedural point, however. If the IESG doesn't like= it, we can simply remove it. > > Second, in section 3, discussing rp=3D, the document says that a report > > SHOULD NOT be generated for percentages higher than that. Under what > > circumstances is it ok to generate outside of this guidance? Is this > > a resource issue? I don't understand when it would be ok. >=20 > It wouldn't be OK, but it wouldn't fundamentally cause an > interoperability problem, so we didn't use MUST. The worst that's > likely to happen is some of all of your reports get routed to > /dev/null. This is text copied from the other reporting document, as I recall. I used= SHOULD in that instance because there might be cases where one party conta= cts another and says, basically, "Although I advertise that I want x% repor= ted, from you I want everything." Thus, a private arrangement overriding w= hat the protocol says would be a valid reason to disregard the "rp=3D" valu= e. We might want to say that, since there are people on the IESG that have= specifically said they like to see examples of when one might contradict a= SHOULD. We'll save that minor thing for after the IETF-wide LC. Thanks again, -MSK From johnl@iecc.com Tue Feb 28 09:22:46 2012 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 4362921F8705 for ; Tue, 28 Feb 2012 09:22:46 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gT-9q6snka-W for ; Tue, 28 Feb 2012 09:22:42 -0800 (PST) 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 5AF8821F86E2 for ; Tue, 28 Feb 2012 09:22:42 -0800 (PST) Received: (qmail 32079 invoked from network); 28 Feb 2012 17:22:40 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 28 Feb 2012 17:22:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f4d0d5f.xn--9vv.k1202; i=johnl@user.iecc.com; bh=1HY61MCrYiHjWxQfF3n3MuGUR+JERmgNZfwXsbMEpY8=; b=KYmRQeLU3zyaBI5Y/4+lVOkxB43bKx29bBlFk3EPf4Ofhi5BMiWkJQ1KgpOE66NYYzyEoP0CvP5kguym07CVBJD1maybtCBPEb7wDqjUTVHcwOdkqsdqzToaRZ6C+MuH+XJAzqrTbDz4OAY3R/1QdZxM1Rg5jxNW8cHdbHe/jhI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f4d0d5f.xn--9vv.k1202; olt=johnl@user.iecc.com; bh=1HY61MCrYiHjWxQfF3n3MuGUR+JERmgNZfwXsbMEpY8=; b=RX71IV5EaH1DE4r2QlOjiUt3HNcKxjMI70s3m8SyCQ7BRzzE+/nbYLznvW0upx6+F0Q3XoU+yqStFNHN3d7bjxs3YR4j9LRJ2NukGnZIX384KfxIyyS8nf7M/wx+dLSxbrnSEcvpyAMf1BK2Ov4H4encvvvD6avaeA1zemupx5o= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 28 Feb 2012 17:22:17 -0000 Message-ID: <20120228172217.7777.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <20120228165614.GA51122@mail.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] FW: REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-reporting ends in one week 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, 28 Feb 2012 17:22:46 -0000 >First, a process issue. The header says that this is aimed for the >standards track, and that it updates RFC 4408. The chairs are more >experienced than I in the arcana of IETF process rules, but I think >this is going to be tricky, isn't it? EAI moved from experimental to standards track without any trouble. So long as there's a reasonable motivation, which there clearly is in this case, I wouldn't expect any more pushback than we usually have with mail security RFCs. R's, John From ajs@anvilwalrusden.com Tue Feb 28 09:49:04 2012 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 B7F1821F86E2 for ; Tue, 28 Feb 2012 09:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRnjAzSCbCIE for ; Tue, 28 Feb 2012 09:49:04 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id DB13421F86E8 for ; Tue, 28 Feb 2012 09:49:03 -0800 (PST) Received: from mail.yitter.info (nat-02-mht.dyndns.com [216.146.45.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 51CAF1ECB41C for ; Tue, 28 Feb 2012 17:49:03 +0000 (UTC) Date: Tue, 28 Feb 2012 12:49:01 -0500 From: Andrew Sullivan To: marf@ietf.org Message-ID: <20120228174901.GB51122@mail.yitter.info> References: <9452079D1A51524AA5749AD23E00392804384C@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9452079D1A51524AA5749AD23E00392804384C@exch-mbx901.corp.cloudmark.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [marf] FW: REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-reporting ends in one week 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, 28 Feb 2012 17:49:04 -0000 On Thu, Feb 23, 2012 at 09:47:30PM +0000, Murray S. Kucherawy wrote: > One more day. No new review comments? We're ready to go? Dear colleagues, This is my (late) review of draft-ietf-marf-dkim-reporting-10. Apologies for being late, but I was unable to turn to this before today. I think this document is in fairly good shape, but I have some questions and some suggestions. First, the document says it is an extension of RFC 6376 and RFC 5617, but it doesn't update those documents. Should it? Next, I find Section 3.2 to start oddly: When a Signer wishes to advertise that it wants to receive failed verification reports, it also places in the DNS a TXT resource record (RR) whose content follows the same general syntax as DKIM key records, as defined in Section 3.6.1 of [DKIM], in that it is made up of a sequence of tag-value objects. It left me with the impression that it was modifying DKIM, but then I understood this TXT record is independent of the usual DKIM publication. That was even more confusing, because it would cause DKIM processing to abort. Maybe this helps: When a Signer wishes to advertise that it wants to receive failed verification reports, it also places in the DNS a TXT resource record (RR). The RR is made up of a sequence of tag-value objects (much like DKIM key records as defined in section 3.6.1 of [DKIM]), but it is entirely independent of those key records and is found at a different owner name. In the case of advertising the desire to receive failed verification reports, the tags and values. . . The same section refers to section 3.6.2.2 of RFC 6376, but nowhere does the target text talk about "reassembly", so someone following the reference from section 3.2 of this draft might have a hard time understanding what is meant. (I did.) This is also an issue in section 3.3, step 4. The discussion of "rp" says SHOULD NOT. Under what circumstances would it be ok to generate reports over the percentage indicated? In section 3.3, I'd restate this 3. If the DNS query returns anything other than a success status code (0), also known as NOERROR, or if multiple TXT records are returned, terminate. as 3. If the DNS query returns anything other than RCODE 0 (NOERROR), or if multiple TXT records are returned, terminate. Step 5 is missing something: 5. If the TXT content is syntactically invalid, the implementation, terminate. I'm notoriously dumb at these things, but I don't get this in step 7: 7. If a report percentage ("rp=") tag was present, select a random number between 0 and 99, inclusive; if the selected number is higher than the tag's value, terminate. 100 is a possible value for rp; but 99<100. What am I missing? What does the SHOULD in step 10 mean? That is, you have all these conditions already; if all those happen, you SHOULD send the string except when? If this is just "it's up to you", then I think the text should say MAY. Immediately after that, "advantages over previous implementations". Of this reporting system? I don't understand; this I-D doesn't seem to be obsoleting anything. Item (b) of that section relies on negative caches to reduce the deleterious effects of an attack using this mechanism. Negative caches are not typically that long-lived, however, so I'm not sure quite how much mitigation you get. This likely ought to be mentioned in the security considerations, because it's yet another query. (I don't think this is a fatal issue, but I think it needs mentioning.) If this is what the reference in 8.2 is supposed to be, then I think it needs to be clarified there. Nit: the paragraph following item (c) has way too many "this"es. Suggested alternative: The above procedure does not permit the detection and reporting of messages including a fraudulent DKIM-Signature header field, where such signature did not include an "r=" tag. It might be useful to some Signers to receive such reports, but the mechanism does not support it. To offer such support, a Verifier would have to violate the first step above and continue even in the absence of an "r=" tag. Although that would enable the desired report, it would also create a possible denial-of-service attack: such Verifiers would always look for the reporting TXT record, so a generator of fraudulent messages could simply send a large volume of messages without an "r=" tag to a number of destinations. To avoid that outcome, reports of frauduleny DKIM-Signature header fields are not possible using this mechanism. Those were all my comments. I hope this is helpful. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From msk@cloudmark.com Tue Feb 28 13:05:01 2012 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 A855A21E8051 for ; Tue, 28 Feb 2012 13:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwR2hwFufCql for ; Tue, 28 Feb 2012 13:05:00 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id DF5EF21F85C5 for ; Tue, 28 Feb 2012 13:05:00 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Tue, 28 Feb 2012 13:05:00 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Thread-Topic: [marf] FW: REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-reporting ends in one week Thread-Index: Acztr1XCyT9dQ4TqRjm1Rinf0gtB+gDMfNggAGTaG/ABA+digAAMBHbQ Date: Tue, 28 Feb 2012 21:04:59 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392804C452@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E00392804384C@exch-mbx901.corp.cloudmark.com> <20120228174901.GB51122@mail.yitter.info> In-Reply-To: <20120228174901.GB51122@mail.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] FW: REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-reporting ends in one week 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, 28 Feb 2012 21:05:01 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= ndrew Sullivan > Sent: Tuesday, February 28, 2012 9:49 AM > To: marf@ietf.org > Subject: Re: [marf] FW: REMINDER: WGLC for draft-ietf-marf-{spf, dkim}- r= eporting ends in one week >=20 > First, the document says it is an extension of RFC 6376 and RFC 5617, > but it doesn't update those documents. Should it? Those two documents created registries as the method of creating extensions= of them. I don't believe it's common practice both to update such a regis= try and to say "Updates" in such cases. Thus, it's omitted here. > Next, I find Section 3.2 to start oddly: >=20 > When a Signer wishes to advertise that it wants to receive failed > verification reports, it also places in the DNS a TXT resource record > (RR) whose content follows the same general syntax as DKIM key > records, as defined in Section 3.6.1 of [DKIM], in that it is made up > of a sequence of tag-value objects. >=20 > It left me with the impression that it was modifying DKIM, but then I > understood this TXT record is independent of the usual DKIM > publication. That was even more confusing, because it would cause DKIM > processing to abort. Maybe this helps: >=20 > When a Signer wishes to advertise that it wants to receive failed > verification reports, it also places in the DNS a TXT resource > record (RR). The RR is made up of a sequence of tag-value objects > (much like DKIM key records as defined in section 3.6.1 of [DKIM]), > but it is entirely independent of those key records and is found at > a different owner name. In the case of advertising the desire to > receive failed verification reports, the tags and values. . . Seems reasonable. > The same section refers to section 3.6.2.2 of RFC 6376, but nowhere > does the target text talk about "reassembly", so someone following the > reference from section 3.2 of this draft might have a hard time > understanding what is meant. (I did.) This is also an issue in > section 3.3, step 4. Both these sections and the target text refer to the case of a TXT that com= es back separated into multiple "character-strings" (in the parlance of RFC= 1035), and what to do in that case. I'll clarify. > The discussion of "rp" says SHOULD NOT. Under what circumstances would > it be ok to generate reports over the percentage indicated? Same answer as I gave to your spf-reporting review; I'll clarify this as we= ll. > In section 3.3, I'd restate this >=20 > 3. If the DNS query returns anything other than a success status > code (0), also known as NOERROR, or if multiple TXT records are > returned, terminate. >=20 > as >=20 > 3. If the DNS query returns anything other than RCODE 0 (NOERROR), > or if multiple TXT records are returned, terminate. OK. > Step 5 is missing something: >=20 > 5. If the TXT content is syntactically invalid, the implementation, > terminate. Yep, this is already fixed by another report. > I'm notoriously dumb at these things, but I don't get this in step 7: >=20 > 7. If a report percentage ("rp=3D") tag was present, select a random > number between 0 and 99, inclusive; if the selected number is > higher than the tag's value, terminate. >=20 > 100 is a possible value for rp; but 99<100. What am I missing? I think that should be "higher than or equal to", or perhaps just "not lowe= r than". (Scott: Same for spf-reporting, no?) > What does the SHOULD in step 10 mean? That is, you have all these > conditions already; if all those happen, you SHOULD send the string > except when? If this is just "it's up to you", then I think the text > should say MAY. If the participating receiver is already using the text portion of the SMTP= reply in some way, making it MUST means the receiver has to stop doing so = and start doing what we're saying here. On the other hand, failing to do s= o interferes with interoperability of what this document is trying to estab= lish. It seems then like SHOULD is the right way to go. > Immediately after that, "advantages over previous implementations". > Of this reporting system? I don't understand; this I-D doesn't seem to > be obsoleting anything. It is in part documenting work that's already been done in this area for se= veral years. But you're right, it's not modifying any previous standardize= d work. I can just add "pre-standardization" to that sentence and perhaps = clarify that point. > Item (b) of that section relies on negative caches to reduce the > deleterious effects of an attack using this mechanism. Negative caches > are not typically that long-lived, however, so I'm not sure quite how > much mitigation you get. This likely ought to be mentioned in the > security considerations, because it's yet another query. (I don't > think this is a fatal issue, but I think it needs mentioning.) If this > is what the reference in 8.2 is supposed to be, then I think it needs > to be clarified there. I think 8.2 is the right place to expand on it, so I'll fold this text (and= the other information you gave me) into some new text there. How about si= mply adding this: "Negative caching offers some protection against this pattern of abuse, alt= hough it will work only as long as the negative time-to-live on the relevan= t SOA record in the DNS." > Nit: the paragraph following item (c) has way too many "this"es. > Suggested alternative: >=20 > The above procedure does not permit the detection and reporting of > messages including a fraudulent DKIM-Signature header field, where > such signature did not include an "r=3D" tag. It might be useful to > some Signers to receive such reports, but the mechanism does not > support it. To offer such support, a Verifier would have to > violate the first step above and continue even in the absence of an > "r=3D" tag. Although that would enable the desired report, it would > also create a possible denial-of-service attack: such Verifiers > would always look for the reporting TXT record, so a generator of > fraudulent messages could simply send a large volume of messages > without an "r=3D" tag to a number of destinations. To avoid that > outcome, reports of frauduleny DKIM-Signature header fields are not > possible using this mechanism. Nice; I'll use that. > Those were all my comments. I hope this is helpful. Very much so, thanks! -MSK From internet-drafts@ietf.org Tue Feb 28 13:24:15 2012 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 9A36921E806A; Tue, 28 Feb 2012 13:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2odU0TFBGxM; Tue, 28 Feb 2012 13:24:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A9A21E805D; Tue, 28 Feb 2012 13:24:15 -0800 (PST) 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: 4.00 Message-ID: <20120228212414.20001.8848.idtracker@ietfa.amsl.com> Date: Tue, 28 Feb 2012 13:24:15 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-dkim-reporting-11.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, 28 Feb 2012 21:24:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Messaging Abuse Reporting Format Work= ing Group of the IETF. Title : Extensions to DKIM for Failure Reporting Author(s) : Murray S. Kucherawy Filename : draft-ietf-marf-dkim-reporting-11.txt Pages : 22 Date : 2012-02-28 This memo presents extensions to the DomainKeys Identified Mail (DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-dkim-reporting-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-dkim-reporting-11.txt From msk@cloudmark.com Tue Feb 28 13:33:44 2012 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 30C7921E805B for ; Tue, 28 Feb 2012 13:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBCBw16QP-nf for ; Tue, 28 Feb 2012 13:33:39 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1B121E802C for ; Tue, 28 Feb 2012 13:33:39 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Tue, 28 Feb 2012 13:33:38 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Thread-Topic: [marf] I-D Action: draft-ietf-marf-dkim-reporting-11.txt Thread-Index: AQHM9l9jCosa0+TM1ESDzJum3hgw3pZS09vQ Date: Tue, 28 Feb 2012 21:33:37 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392804C56C@exch-mbx901.corp.cloudmark.com> References: <20120228212414.20001.8848.idtracker@ietfa.amsl.com> In-Reply-To: <20120228212414.20001.8848.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] 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-dkim-reporting-11.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, 28 Feb 2012 21:33:44 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org > Sent: Tuesday, February 28, 2012 1:24 PM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: [marf] I-D Action: draft-ietf-marf-dkim-reporting-11.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Messaging Abuse Reporting > Format Working Group of the IETF. >=20 > Title : Extensions to DKIM for Failure Reporting > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-marf-dkim-reporting-11.txt > Pages : 22 > Date : 2012-02-28 >=20 > This memo presents extensions to the DomainKeys Identified Mail > (DKIM) specification to allow for detailed reporting of message > authentication failures in an on-demand fashion. Incorporates the last of the review comments. This document and the spf-re= porting one have now been sent to the IESG for evaluation. The next thing = that should happen is the IETF Last Call, for two weeks, which should start= today or tomorrow. A reminder: draft-ietf-marf-as is still in Working Group Last Call, ending = this Friday. Over the weekend I'll post the revisions that have been accep= ted, either because they have consensus or they were purely editorial in na= ture, and we'll send it to the IESG on Monday. -MSK From internet-drafts@ietf.org Tue Feb 28 13:56:18 2012 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 E5FD921E8051; Tue, 28 Feb 2012 13:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPy47B4ePphi; Tue, 28 Feb 2012 13:56:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACFE21E803F; Tue, 28 Feb 2012 13:56:18 -0800 (PST) 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: 4.00 Message-ID: <20120228215618.28498.21800.idtracker@ietfa.amsl.com> Date: Tue, 28 Feb 2012 13:56:18 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-spf-reporting-08.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, 28 Feb 2012 21:56:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Messaging Abuse Reporting Format Work= ing Group of the IETF. Title : SPF Authentication Failure Reporting using the Abuse Rep= ort Format Author(s) : Scott Kitterman Filename : draft-ietf-marf-spf-reporting-08.txt Pages : 13 Date : 2012-02-28 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. This memo updates RFC4408 by providing an IANA registry for SPF modifiers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-spf-reporting-08.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-08.txt From sklist@kitterman.com Tue Feb 28 13:57:51 2012 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 AF66D21E803F for ; Tue, 28 Feb 2012 13:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPDvrfDDMkDH for ; Tue, 28 Feb 2012 13:57:50 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADD321E8018 for ; Tue, 28 Feb 2012 13:57:50 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C431020E40E0; Tue, 28 Feb 2012 16:57:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330466269; bh=F6tPe8V1RNkGesz8tfu+B06goWBuM77TS7z3V8ZiYFo=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=CSOkhAofV3o1TOTk5Gq7X8k233oOWOOFK0bi1maImlNmaRhwhJHaQT50RE3kxnDUV 9aaXE36arWOerVFQFhbOkwRlqPPhJARhuKFiTgF6Qz3ae/+LUngxxkO7k85w8fB9Yj rMV+p2QsU8pztxKgMgohuoypi9dPHQztu170891E= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A4E8C20E4099; Tue, 28 Feb 2012 16:57:49 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Tue, 28 Feb 2012 16:57:49 -0500 Message-ID: <7477087.WWde4lnFmZ@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120228215618.28498.21800.idtracker@ietfa.amsl.com> References: <20120228215618.28498.21800.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-08.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, 28 Feb 2012 21:57:51 -0000 On Tuesday, February 28, 2012 01:56:18 PM internet-drafts@ietf.org wrote: > 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-08.txt > Pages : 13 > Date : 2012-02-28 This update has only the change for Alexander's comment on the rp= definition (handily borrowed from Murray's DKIM draft). I believe that was the only last call comment not previously addressed. Scott K From barryleiba.mailing.lists@gmail.com Tue Feb 28 15:53:29 2012 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 84CC521E806F for ; Tue, 28 Feb 2012 15:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.987 X-Spam-Level: X-Spam-Status: No, score=-102.987 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wZsYeE5iYak for ; Tue, 28 Feb 2012 15:53:24 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBCF21E8061 for ; Tue, 28 Feb 2012 15:53:24 -0800 (PST) Received: by ghbg16 with SMTP id g16so3223867ghb.31 for ; Tue, 28 Feb 2012 15:53:23 -0800 (PST) Received-SPF: pass (google.com: domain of barryleiba.mailing.lists@gmail.com designates 10.236.79.202 as permitted sender) client-ip=10.236.79.202; Authentication-Results: mr.google.com; spf=pass (google.com: domain of barryleiba.mailing.lists@gmail.com designates 10.236.79.202 as permitted sender) smtp.mail=barryleiba.mailing.lists@gmail.com; dkim=pass header.i=barryleiba.mailing.lists@gmail.com Received: from mr.google.com ([10.236.79.202]) by 10.236.79.202 with SMTP id i50mr32163281yhe.61.1330473203843 (num_hops = 1); Tue, 28 Feb 2012 15:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pAvAhpJFdqR1mdyFN8GVs5mBe+9AdgoJbMJOkFpj3mg=; b=aNcrm0O5MVcd0plsCKECG+V3jnK2rRhWqsA3b9DL0X1lFk9V/Smbd5Pg//kRL+FCeQ 36ssqld2+uaQatEG467pndecE8kZ9MPMwDGCOjT+FBjndhQi3tM9DJdQ5ntfUl9aoMEL skWbbpZwbbHZH9BjPKZQhxb1sRtXhMt5mm5Jk= MIME-Version: 1.0 Received: by 10.236.79.202 with SMTP id i50mr24340947yhe.61.1330473203797; Tue, 28 Feb 2012 15:53:23 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.106.16 with HTTP; Tue, 28 Feb 2012 15:53:23 -0800 (PST) In-Reply-To: <7477087.WWde4lnFmZ@scott-latitude-e6320> References: <20120228215618.28498.21800.idtracker@ietfa.amsl.com> <7477087.WWde4lnFmZ@scott-latitude-e6320> Date: Tue, 28 Feb 2012 18:53:23 -0500 X-Google-Sender-Auth: UE_9AAeGKAhpX0NdBrXd3E1hpvc Message-ID: From: Barry Leiba To: Scott Kitterman Content-Type: multipart/alternative; boundary=20cf30051430b20e9204ba0eeed1 Cc: "marf@ietf.org" Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-08.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, 28 Feb 2012 23:53:29 -0000 --20cf30051430b20e9204ba0eeed1 Content-Type: text/plain; charset=ISO-8859-1 > > This update has only the change for Alexander's comment on the rp= > definition > (handily borrowed from Murray's DKIM draft). I believe that was the only > last > call comment not previously addressed. By "Alexander", I assume you mean Andrew. Careful: that Canuck can get cranky. Barry --20cf30051430b20e9204ba0eeed1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This update has only the change for Alexande= r's comment on the rp=3D definition
(handily borrowed from Murray's DKIM draft). =A0I believe that was the = only last
call comment not previously addressed.

By &= quot;Alexander", I assume you mean Andrew. =A0Careful: that Canuck can= get cranky.

Barry=A0
--20cf30051430b20e9204ba0eeed1-- From sklist@kitterman.com Tue Feb 28 16:02:29 2012 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 038ED21E8061 for ; Tue, 28 Feb 2012 16:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGTyiYm8MlWa for ; Tue, 28 Feb 2012 16:02:28 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4E82421E8051 for ; Tue, 28 Feb 2012 16:02:28 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D5C3420E40E0; Tue, 28 Feb 2012 19:02:27 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1330473747; bh=TWXQmCIXXqp/XpiqqQoRgBFLzQytA9f9pW1CwNvkJY0=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=SBPZ5Lr44iMG9IBbY0PoqgVtt8nZmF+O3nDHPwumkFQiL9YF2mglPos8EeabTJ2QC IlzK4XtAl7rKuFRqG011WbsBgzh2PapUOI2IME/gNEvAtmLSCYSZH3qJISlvUqMnd7 j6LScTNsQf33k/kVgKD7IUKNbmJLEu6scSDjcXoM= Received: from scott-latitude-e6320.localnet (140.239.105.162.ptr.us.xo.net [140.239.105.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B281D20E4099; Tue, 28 Feb 2012 19:02:27 -0500 (EST) From: Scott Kitterman To: "marf@ietf.org" Date: Tue, 28 Feb 2012 19:02:26 -0500 Message-ID: <11776661.QD8aOxDNx9@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <20120228215618.28498.21800.idtracker@ietfa.amsl.com> <7477087.WWde4lnFmZ@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-08.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, 29 Feb 2012 00:02:29 -0000 On Tuesday, February 28, 2012 06:53:23 PM Barry Leiba wrote: > > This update has only the change for Alexander's comment on the rp= > > definition > > (handily borrowed from Murray's DKIM draft). I believe that was the > > only > > last > > call comment not previously addressed. > > By "Alexander", I assume you mean Andrew. Careful: that Canuck can get > cranky. Yes. Sorry. Scott K From iesg-secretary@ietf.org Wed Feb 29 06:57:57 2012 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 8C6DF21F8691; Wed, 29 Feb 2012 06:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EssQxnr0Bx5L; Wed, 29 Feb 2012 06:57:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07CBF21F8600; Wed, 29 Feb 2012 06:57:57 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120229145757.2209.25272.idtracker@ietfa.amsl.com> Date: Wed, 29 Feb 2012 06:57:57 -0800 Cc: marf@ietf.org Subject: [marf] Last Call: (Extensions to DKIM for Failure Reporting) to Proposed Standard X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 14:57:57 -0000 The IESG has received a request from the Messaging Abuse Reporting Format WG (marf) to consider the following document: - 'Extensions to DKIM for Failure Reporting' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo presents extensions to the DomainKeys Identified Mail (DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-marf-dkim-reporting/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-marf-dkim-reporting/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Wed Feb 29 06:58:33 2012 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 0273821F8705; Wed, 29 Feb 2012 06:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9V9IoynQCyFN; Wed, 29 Feb 2012 06:58:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7C021F8615; Wed, 29 Feb 2012 06:58:32 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120229145832.2209.28900.idtracker@ietfa.amsl.com> Date: Wed, 29 Feb 2012 06:58:32 -0800 Cc: marf@ietf.org Subject: [marf] Last Call: (SPF Authentication Failure Reporting using the Abuse Report Format) to Proposed Standard X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 14:58:33 -0000 The IESG has received a request from the Messaging Abuse Reporting Format WG (marf) to consider the following document: - 'SPF Authentication Failure Reporting using the Abuse Report Format' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This 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. This memo updates RFC4408 by providing an IANA registry for SPF modifiers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-marf-spf-reporting/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-marf-spf-reporting/ballot/ No IPR declarations have been submitted directly on this I-D. From msk@cloudmark.com Wed Feb 29 11:17:36 2012 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 D8C8321F8787 for ; Wed, 29 Feb 2012 11:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJHbcPkrdBqb for ; Wed, 29 Feb 2012 11:17:35 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4121C21F8729 for ; Wed, 29 Feb 2012 11:17:35 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Wed, 29 Feb 2012 11:17:34 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Thread-Topic: WGLC Reminder: draft-ietf-marf-as closes Friday, 3/2 Thread-Index: Acz3FsndesF7a9nOSHSKsf/Ucu02+g== Date: Wed, 29 Feb 2012 19:17:33 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392806CEC6@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E00392806CEC6exchmbx901corpclo_" MIME-Version: 1.0 Subject: [marf] WGLC Reminder: draft-ietf-marf-as closes Friday, 3/2 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, 29 Feb 2012 19:17:36 -0000 --_000_9452079D1A51524AA5749AD23E00392806CEC6exchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a friendly reminder that draft-ietf-marf-as is in Working Group Last C= all, closing this Friday. We will be sending it to the IESG over the weeke= nd unless there's a showstopper. Please provide any outstanding review com= ments sooner rather than later. Thank you, -MSK, your friendly neighbourhood co-chair --_000_9452079D1A51524AA5749AD23E00392806CEC6exchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a friendly reminder that draft-ietf-marf-as is = in Working Group Last Call, closing this Friday.  We will be sending i= t to the IESG over the weekend unless there’s a showstopper.  Pl= ease provide any outstanding review comments sooner rather than later.

 

Thank you,

-MSK, your friendly neighbourhood co-chair

 

--_000_9452079D1A51524AA5749AD23E00392806CEC6exchmbx901corpclo_-- From iesg-secretary@ietf.org Wed Feb 29 16:45:38 2012 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 148DD21E8052; Wed, 29 Feb 2012 16:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.171 X-Spam-Level: X-Spam-Status: No, score=-102.171 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXWhYWoQFntB; Wed, 29 Feb 2012 16:45:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FE021E801F; Wed, 29 Feb 2012 16:45:37 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120301004537.16773.40279.idtracker@ietfa.amsl.com> Date: Wed, 29 Feb 2012 16:45:37 -0800 Cc: marf@ietf.org Subject: [marf] Last Call: (Extensions to DKIM for Failure Reporting) to Proposed Standard X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 00:45:38 -0000 The IESG has received a request from the Messaging Abuse Reporting Format WG (marf) to consider the following document: - 'Extensions to DKIM for Failure Reporting' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo presents extensions to the DomainKeys Identified Mail (DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. Note that this document has downward normative references: This document refers normatively to RFC 5598, "Internet Mail Architecture", which is Informational. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-marf-dkim-reporting/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-marf-dkim-reporting/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Wed Feb 29 16:46:52 2012 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 BD77621E8063; Wed, 29 Feb 2012 16:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.257 X-Spam-Level: X-Spam-Status: No, score=-102.257 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vt+03j00v5jO; Wed, 29 Feb 2012 16:46:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50EB821E801C; Wed, 29 Feb 2012 16:46:43 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120301004643.17274.83943.idtracker@ietfa.amsl.com> Date: Wed, 29 Feb 2012 16:46:43 -0800 Cc: marf@ietf.org Subject: [marf] Last Call: (SPF Authentication Failure Reporting using the Abuse Report Format) to Proposed Standard X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 00:46:53 -0000 The IESG has received a request from the Messaging Abuse Reporting Format WG (marf) to consider the following document: - 'SPF Authentication Failure Reporting using the Abuse Report Format' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This 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. This memo updates RFC4408 by providing an IANA registry for SPF modifiers. Note that this document has a downward normative reference: This document makes a normative reference to SPF (RFC4408), which is Experimental. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-marf-spf-reporting/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-marf-spf-reporting/ballot/ No IPR declarations have been submitted directly on this I-D.