Received: from todzilla.mail.rr.com (todzilla.mail.rr.com [24.28.207.21]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8UL923M010435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 30 Sep 2009 14:09:08 -0700 Received: from todzilla.mail.rr.com (todzilla.mail.rr.com [127.0.0.1]) by todzilla.mail.rr.com (8.14.2/8.14.2) with ESMTP id n8UL91jj012837 for ; Wed, 30 Sep 2009 17:09:01 -0400 Received: (from therr@localhost) by todzilla.mail.rr.com (8.14.2/8.14.2/Submit) id n8UL91wk012836 for abuse-feedback-report@mipassoc.org; Wed, 30 Sep 2009 17:09:01 -0400 X-Authentication-Warning: todzilla.mail.rr.com: therr set sender to therr@security.rr.com using -f Date: Wed, 30 Sep 2009 17:09:01 -0400 From: Todd Herr To: abuse-feedback-report@mipassoc.org Message-ID: <20090930210901.GD9910@todzilla.mail.rr.com> References: <4AC366EE.4030502@davearonson.com> <20090930175729.GB8650@todzilla.mail.rr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Scanned: ClamAV 0.92/9856/Wed Sep 30 05:27:30 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 30 Sep 2009 14:09:08 -0700 (PDT) Subject: Re: [feedback-report] "reality" check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 21:09:08 -0000 On Wed, Sep 30, 2009 at 04:43:12PM -0400, John R. Levine wrote: >> The abuse@ option fails in many cases because there are many working >> Abuse desks that reject and/or discard any message containing attachments, >> or at least pre-process their inbound Abuse stream so as to remove any >> attachments from the message; > > That used to happen a lot, but I haven't seen much of it lately other > than at Microsoft itself. In any event, I'm not sure that it's a good > long term plan to design around short term bugs in abuse desk software. I always got the impression that the bugs were in the wetware, not the software. That said, I've had experiences within the past couple of years with Abuse desks telling me that they don't accept attachments. > >> but even if all producers produced reports that were identical in >> format and content, there'd still be value to the FBL/ARF consumer to >> have separate inbound streams for different reporting agencies, simply >> for counting purposes. > > What's wrong with counting the From: addresses? Every FBL I've seen has > a very consistent return address. I don't believe Occam ever existed, and so I always look for the most complex solution to a problem. -- Todd Herr Principal Engineer and Postmaster V: 703.345.2447 Road Runner Email Operations M: 571.287.0366 therr@security.rr.com AIM: RRMailToddHerr Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8UKhDTZ009004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 30 Sep 2009 13:43:19 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 81847 invoked from network); 30 Sep 2009 20:43:12 -0000 Received: (ofmipd 208.31.42.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Sep 2009 20:42:50 -0000 Date: 30 Sep 2009 16:43:12 -0400 Message-ID: From: "John R. Levine" To: "Todd Herr" In-Reply-To: <20090930175729.GB8650@todzilla.mail.rr.com> References: <4AC366EE.4030502@davearonson.com> <20090930175729.GB8650@todzilla.mail.rr.com> 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 X-Virus-Scanned: ClamAV 0.92/9856/Wed Sep 30 05:27:30 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 30 Sep 2009 13:43:19 -0700 (PDT) Cc: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] "reality" check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 20:43:19 -0000 > The abuse@ option fails in many cases because there are many working > Abuse desks that reject and/or discard any message containing attachments, > or at least pre-process their inbound Abuse stream so as to remove any > attachments from the message; That used to happen a lot, but I haven't seen much of it lately other than at Microsoft itself. In any event, I'm not sure that it's a good long term plan to design around short term bugs in abuse desk software. > but even if all producers produced reports that were identical in > format and content, there'd still be value to the FBL/ARF consumer to > have separate inbound streams for different reporting agencies, simply > for counting purposes. What's wrong with counting the From: addresses? Every FBL I've seen has a very consistent return address. R's, John Received: from todzilla.mail.rr.com (todzilla.mail.rr.com [24.28.207.21]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8UJML1Y003723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 30 Sep 2009 12:22:27 -0700 Received: from todzilla.mail.rr.com (todzilla.mail.rr.com [127.0.0.1]) by todzilla.mail.rr.com (8.14.2/8.14.2) with ESMTP id n8UHvThs009364 for ; Wed, 30 Sep 2009 13:57:29 -0400 Received: (from therr@localhost) by todzilla.mail.rr.com (8.14.2/8.14.2/Submit) id n8UHvTXK009362 for abuse-feedback-report@mipassoc.org; Wed, 30 Sep 2009 13:57:29 -0400 X-Authentication-Warning: todzilla.mail.rr.com: therr set sender to therr@security.rr.com using -f Date: Wed, 30 Sep 2009 13:57:29 -0400 From: Todd Herr To: abuse-feedback-report@mipassoc.org Message-ID: <20090930175729.GB8650@todzilla.mail.rr.com> References: <4AC366EE.4030502@davearonson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Scanned: ClamAV 0.92/9856/Wed Sep 30 05:27:30 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Delayed for 01:22:29 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 30 Sep 2009 12:22:27 -0700 (PDT) Subject: Re: [feedback-report] "reality" check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 19:22:28 -0000 On Wed, Sep 30, 2009 at 09:56:06AM -0700, Murray S. Kucherawy wrote: > > John R. Levine wrote: > > > > > It would be technically possible to define something analogous to an > > MX to > > > invite abuse reports, but I have seen nothing to suggest that there > > is any > > > demand for such a thing. > > > > Perhaps an organization might want to publish such records in order to > > claim that they "care"... never mind that, behind the scenes, the > > reports are blackholed upon receipt, possibly with an autoreply. Given > > the past behavior by certain major ISPs/carriers regarding spam > > reports, > > this would not surprise me at all. > > I should point out that this is pretty similar to something mentioned > in the proposed charter for an ARF working group, and that's predicated > on past discussions at MAAWG (at least) where some FBL participant was > interested in advertising specifically this kind of information. One > would think, then, that standardizing such a concept would be a Good > Thing(tm). > > On the other hand, the group could decide through consensus that ARF > could just say "use the current standard abuse address, abuse@example.com, > for sending ARF reports", and that would probably be just fine as well to > tie up that loose end. I'm not sure, based on what I've seen so far in both producing and consuming FBL reports, that either approach will work here. The abuse@ option fails in many cases because there are many working Abuse desks that reject and/or discard any message containing attachments, or at least pre-process their inbound Abuse stream so as to remove any attachments from the message; I gather this is done as a defense mechanism to prevent infections/compromises of Windows-based desktops being used by Abuse desk staff. Since ARF defines a message with several attachments, absent rules in place on the abuse@ mailbox to allow attachments from $KNOWN_FBL_PRODUCER_ADDRESSES, sending ARF to abuse@ will not have the intended result in all cases. As for the MX-analogous solution, that's a better path, I believe, but there are many FBL consumers that seem to like to specify a different inbound FBL address for each FBL producer to which they're subscribing. This can be useful now for rules-based processing of the reports, since each producer has slight variances in the content of their reports (subject lines, actual content in the message/feedback-report content type sections, owing to the "Optional Fields..." sections in the drafts), but even if all producers produced reports that were identical in format and content, there'd still be value to the FBL/ARF consumer to have separate inbound streams for different reporting agencies, simply for counting purposes. Such separation of streams can allow the consumer to know quickly if a change in complaint rates is localized to one domain or is happening across the board. (And I suppose if the MX-analog solution were pursued, then it'd be about five minutes till the address is harvested and spammed, and with properly formatted ARF messages, even, but that's another bridge to cross....) -- Todd Herr Principal Engineer and Postmaster V: 703.345.2447 Road Runner Email Operations M: 571.287.0366 therr@security.rr.com AIM: RRMailToddHerr Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8UIRfgH031926 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 30 Sep 2009 11:27:46 -0700 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Wed, 30 Sep 2009 11:27:41 -0700 From: "Murray S. Kucherawy" To: Douglas Otis , "John R. Levine" Date: Wed, 30 Sep 2009 11:27:40 -0700 Thread-Topic: [feedback-report] "reality" check, was Revised draft charter Thread-Index: AcpB+VsoF9PCmmrpSJ6w0r4tigBnJQAAd/9A Message-ID: References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> <4ABF44A0.8010104@tana.it> <4AC0DD0D.30909@cybernothing.org> <4AC130D0.4050108@mail-abuse.org> <4AC14109.4060107@cybernothing.org> <4AC14E90.4050407@mail-abuse.org> <4AC2426D.4070609@cybernothing.org> <4AC280FF.8070706@mail-abuse.org> <4AC2A6B6.4080100@mail-abuse.org> <4AC39EB7.7010701@mail-abuse.org> In-Reply-To: <4AC39EB7.7010701@mail-abuse.org> 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" MIME-Version: 1.0 X-Virus-Scanned: ClamAV 0.92/9856/Wed Sep 30 05:27:30 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 30 Sep 2009 11:27:46 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n8UIRfgH031926 Cc: ARF mailing list Subject: Re: [feedback-report] "reality" check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 18:27:47 -0000 > -----Original Message----- > From: abuse-feedback-report-bounces@mipassoc.org [mailto:abuse- > feedback-report-bounces@mipassoc.org] On Behalf Of Douglas Otis > Sent: Wednesday, September 30, 2009 11:09 AM > To: John R. Levine > Cc: ARF mailing list > Subject: Re: [feedback-report] "reality" check, was Revised draft > charter > > RFC5321 still states in section 4.1.1.4: > ,--- > In sending a positive "250 OK" completion reply to the end of data > indication, the receiver takes full responsibility for the message (see > Section 6.1). Errors that are diagnosed subsequently MUST be reported > in a mail message,as discussed in Section 4.4. > '--- > > What is being suggested with respect to ARF reporting is that those who > act upon ARF reports take full responsibility for the accuracy of the > information employed when disabling or removing email accounts. Since > ARF reports are often received from third-parties, it is important that > source accuracy be continuously evaluated. This evaluation might > involve the visual examination of statistically significant samplings. > Humans are better than computers at resolving Turing like problems. > > > But, really, it's not our job to tell people how to do that, because > > we don't know. > > As RFC5321 demonstrates, an RFC can clearly define _who_ is responsible > within the protocol. The ARF draft should make it clear that the > entity > acting upon an ARF report takes responsibility for the accuracy of the > information being relied upon. How would one be able to demonstrate a positive assertion of this nature by a receiver? That an ARF went into an SMTP server, with "abuse@..." in the envelope recipient, and a "250" was produced in response is unlikely to be successfully asserted as the ARF processing software accepted responsibility for validation of its content. Is section 6.2 of the current draft not sufficient to cover all of this? Received: from harry.mail-abuse.org ([168.61.5.27]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8UI9jkj029905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 30 Sep 2009 11:09:50 -0700 Received: from sjc-office-nat-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 8AD53A9444E; Wed, 30 Sep 2009 18:08:55 +0000 (UTC) Message-ID: <4AC39EB7.7010701@mail-abuse.org> Date: Wed, 30 Sep 2009 11:08:55 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: "John R. Levine" References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> <4ABF44A0.8010104@tana.it> <4AC0DD0D.30909@cybernothing.org> <4AC130D0.4050108@mail-abuse.org> <4AC14109.4060107@cybernothing.org> <4AC14E90.4050407@mail-abuse.org> <4AC2426D.4070609@cybernothing.org> <4AC280FF.8070706@mail-abuse.org> <4AC2A6B6.4080100@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9856/Wed Sep 30 05:27:30 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 30 Sep 2009 11:09:50 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] "reality" check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 18:09:51 -0000 On 9/29/09 6:52 PM, John R. Levine wrote: >> Not at all. Indeed, the generation of feedback is often fully >> automated. However, use of information obtained from a complex, >> albeit automated process, should include safeguards against >> third-party error. > > Well, of course. But I think you will look in vain for any IETF > standard that includes useful advice about how not to be stupid. Deflecting responsibility for potentially damaging actions remains a concern in third-party reporting schemes. There could be SLAs that ensure those making errors remain responsible as a means to control the number of errors. Nevertheless, counting reports is not enough, especially in a multilingual world where auto-responses in foreign languages are often mistaken for spam. Perhaps there should be a convention something like having all auto-generated responses be contained within a mime type like Multipart/Report that was intended for mail system administrative messages (RFC 5337). > Manual inspection is one possibility, but hardly the only one. It is > my strong impression that large FBL consumers use statistical > techniques to figure out what's plausible, because the volume is far > too great to manage manually. No doubt this is how many want ARF to operate. Nevertheless, safeguards of some form remain important. Use of statistics is fine for deciding what represents an adequate sampling. It would be wrong to expect statistics will determine the exploit being used at the expense of purported source email-address, or whether the related account has been compromised. While many techniques help identify the source of a problem (this could have been made better by ensuring the capture of source IP addresses for IP address based validations), none of these schemes are without error nor never exploited. Antagonists being defended against are human, and not machines. Those depending upon ARF must ensure the accuracy of their approach, where often this requires visual inspection to ascertain whether mistakes are occurring. RFC5321 still states in section 4.1.1.4: ,--- In sending a positive "250 OK" completion reply to the end of data indication, the receiver takes full responsibility for the message (see Section 6.1). Errors that are diagnosed subsequently MUST be reported in a mail message,as discussed in Section 4.4. '--- What is being suggested with respect to ARF reporting is that those who act upon ARF reports take full responsibility for the accuracy of the information employed when disabling or removing email accounts. Since ARF reports are often received from third-parties, it is important that source accuracy be continuously evaluated. This evaluation might involve the visual examination of statistically significant samplings. Humans are better than computers at resolving Turing like problems. > But, really, it's not our job to tell people how to do that, because > we don't know. As RFC5321 demonstrates, an RFC can clearly define _who_ is responsible within the protocol. The ARF draft should make it clear that the entity acting upon an ARF report takes responsibility for the accuracy of the information being relied upon. -Doug Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8UHmdra026093 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 30 Sep 2009 10:48:44 -0700 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Wed, 30 Sep 2009 10:48:39 -0700 From: "Murray S. Kucherawy" To: Douglas Otis Date: Wed, 30 Sep 2009 10:48:38 -0700 Thread-Topic: [feedback-report] Revised draft charter, call for participation -- Please comment Thread-Index: Aco9ZwnSQhBnkANFQZCS/6bRUGnv1gEjihIA Message-ID: References: <501c18e00909211910u20f885cal8226831f6c60af5e@mail.gmail.com> <4ABAC5DC.8000501@mail-abuse.org> <4ABB1568.9000600@mail-abuse.org> <4ABBF3B7.8000807@mail-abuse.org> In-Reply-To: <4ABBF3B7.8000807@mail-abuse.org> 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" MIME-Version: 1.0 X-Virus-Scanned: ClamAV 0.92/9856/Wed Sep 30 05:27:30 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 30 Sep 2009 10:48:44 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n8UHmdra026093 Cc: ARF mailing list Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 17:48:44 -0000 > -----Original Message----- > From: Douglas Otis [mailto:dotis@mail-abuse.org] > Sent: Thursday, September 24, 2009 3:33 PM > To: Murray S. Kucherawy > Cc: Steve Atkins; ARF mailing list > Subject: Re: [feedback-report] Revised draft charter, call for > participation -- Please comment > > The concern was not about how to deal with DSNs where recipients of a > DSN (such as a mailing list) can confirm it was in response to their > message. There are immediate methods to ensure against DSN spoofing, > while there is also little incentive to send spoofed DSNs to some third > party, which could be why this is not a problem. Again, the concern was > about altering accounts based upon ARF reports when the nature of the > message had not been visually verified. How does an MLM definitively confirm that a DSN was sent in response to a message that actually passed through it? If both are automated and neither are cryptographically signed, then both can be spoofed to think a user did something he/she didn't do. In the case of an MLM responding to a fake DSN, this could result in unwarranted suspension or removal from a list; in the case of an abuse desk responding to a faked ARF message, this could result in other unwarranted corrective action taken on a user. Perhaps FBL users can help one way or the other: Are automated responses to ARF severe, or mostly a matter of record-keeping? My impressions are that: a) The volume of ARFs received in an FBL are so large that a reasonable sampling isn't practical; and b) To mitigate the fact that ARFs could be forged, the severity of response to ARFs is constrained to notification and record-keeping, with only large counts drawing human attention. > > So, I have to disagree. > > Are you saying that ARF reports should _not_ be visually reviewed > because mailing list automatically react to DSNs? Do you really think > these two mechanisms are directly comparable? I'm saying making an impractical recommendation detracts from the credibility of the work this group will produce. Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8UHSvQA024559 for ; Wed, 30 Sep 2009 10:29:02 -0700 Received: by pxi13 with SMTP id 13so7219079pxi.6 for ; Wed, 30 Sep 2009 10:28:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.207.16 with SMTP id e16mr5837rvg.86.1254331737066; Wed, 30 Sep 2009 10:28:57 -0700 (PDT) In-Reply-To: References: <4AC14E90.4050407@mail-abuse.org> <4AC2426D.4070609@cybernothing.org> <4AC280FF.8070706@mail-abuse.org> <4AC2A6B6.4080100@mail-abuse.org> <501c18e00909291906s1e3466b3r9e25e4aad6b1cb94@mail.gmail.com> <826A8469-E15D-43FE-B5C1-6CF4739A67BA@word-to-the-wise.com> From: Yakov Shafranovich Date: Wed, 30 Sep 2009 13:28:37 -0400 Message-ID: <501c18e00909301028y3227c06xd8c6b509b0d987fb@mail.gmail.com> To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: ClamAV 0.92/9856/Wed Sep 30 05:27:30 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 30 Sep 2009 10:29:02 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n8UHSvQA024559 Cc: ARF mailing list Subject: Re: [feedback-report] "reality" check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 17:29:02 -0000 On Wed, Sep 30, 2009 at 12:53 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: abuse-feedback-report-bounces@mipassoc.org [mailto:abuse- >> feedback-report-bounces@mipassoc.org] On Behalf Of Steve Atkins >> Sent: Tuesday, September 29, 2009 7:40 PM >> To: ARF mailing list >> Subject: Re: [feedback-report] "reality" check, was Revised draft >> charter >> >> >> Well, of course.  But I think you will look in vain for any IETF >> >> standard >> >> that includes useful advice about how not to be stupid. >> >> >> > >> > But it might be a good idea to have a separate draft with operational >> > experience related to ARF so people are less likely to do stupid >> > things. >> >> The (sole) value of ARF is to provide easy interoperability at the >> transport >> layer, and that's the sort of thing the IETF is good at. >> >> "Not being stupid" at the political layer is something that's likely to >> be defined mostly by agreements between consenting parties who are >> using ARF. It's something that's mostly orthogonal to the protocol >> level work on ARF, and it may be something that's better >> left to those who are actually producing or consuming feedback loops >> - either through their contracts with each other or through an >> organization like MAAWG that's a bit higher up the protocol stack >> than the IETF. > > The IETF has produced BCP RFCs in the past.  For example, several of the documents the DKIM WG produced are information and provide guidance about implementation rather than protocol specification. > > An ARF WG could take that on as a task after its initial deliverables are completed. > The Spam OPS RFC comes to mind. Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8UHRcJd024461 for ; Wed, 30 Sep 2009 10:27:43 -0700 Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 1E68880CFC for ; Wed, 30 Sep 2009 10:27:38 -0700 (PDT) Message-Id: From: Steve Atkins To: ARF mailing list In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 30 Sep 2009 10:27:35 -0700 References: <4AC0DD0D.30909@cybernothing.org> <4AC130D0.4050108@mail-abuse.org> <4AC14109.4060107@cybernothing.org> <4AC14E90.4050407@mail-abuse.org> <4AC2426D.4070609@cybernothing.org> <4AC280FF.8070706@mail-abuse.org> <4AC2A6B6.4080100@mail-abuse.org> <501c18e00909291906s1e3466b3r9e25e4aad6b1cb94@mail.gmail.com> <826A8469-E15D-43FE-B5C1-6CF4739A67BA@word-to-the-wise.com> <4AC30E54.6020906@tana.it> X-Mailer: Apple Mail (2.936) X-Virus-Scanned: ClamAV 0.92/9856/Wed Sep 30 05:27:30 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 30 Sep 2009 10:27:43 -0700 (PDT) Subject: Re: [feedback-report] "reality" check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 17:27:43 -0000 On Sep 30, 2009, at 5:48 AM, John R. Levine wrote: > > > ARF is quite successful as it is, and it's worth standardizing what > people > actually use. That's how normal standards organizations work. +1 Cheers, Steve Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8UHQhQ9024389 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 30 Sep 2009 10:26:49 -0700 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Wed, 30 Sep 2009 09:56:07 -0700 From: "Murray S. Kucherawy" To: Dave Aronson , ARF mailing list Date: Wed, 30 Sep 2009 09:56:06 -0700 Thread-Topic: [feedback-report] "reality" check, was Revised draft charter Thread-Index: AcpB4H2AAWJcbz/rQ5CMFg5ydLenPwADiMdg Message-ID: References: <4AC366EE.4030502@davearonson.com> In-Reply-To: <4AC366EE.4030502@davearonson.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" MIME-Version: 1.0 X-Virus-Scanned: ClamAV 0.92/9856/Wed Sep 30 05:27:30 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Delayed for 00:30:37 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 30 Sep 2009 10:26:49 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n8UHQhQ9024389 Subject: Re: [feedback-report] "reality" check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 17:26:49 -0000 > -----Original Message----- > From: abuse-feedback-report-bounces@mipassoc.org [mailto:abuse- > feedback-report-bounces@mipassoc.org] On Behalf Of Dave Aronson > Sent: Wednesday, September 30, 2009 7:11 AM > To: ARF mailing list > Subject: Re: [feedback-report] "reality" check, was Revised draft > charter > > John R. Levine wrote: > > > It would be technically possible to define something analogous to an > MX to > > invite abuse reports, but I have seen nothing to suggest that there > is any > > demand for such a thing. > > Perhaps an organization might want to publish such records in order to > claim that they "care"... never mind that, behind the scenes, the > reports are blackholed upon receipt, possibly with an autoreply. Given > the past behavior by certain major ISPs/carriers regarding spam > reports, > this would not surprise me at all. I should point out that this is pretty similar to something mentioned in the proposed charter for an ARF working group, and that's predicated on past discussions at MAAWG (at least) where some FBL participant was interested in advertising specifically this kind of information. One would think, then, that standardizing such a concept would be a Good Thing(tm). On the other hand, the group could decide through consensus that ARF could just say "use the current standard abuse address, abuse@example.com, for sending ARF reports", and that would probably be just fine as well to tie up that loose end. Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8UHNw21024115 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 30 Sep 2009 10:24:03 -0700 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Wed, 30 Sep 2009 09:53:23 -0700 From: "Murray S. Kucherawy" To: Steve Atkins , ARF mailing list Date: Wed, 30 Sep 2009 09:53:23 -0700 Thread-Topic: [feedback-report] "reality" check, was Revised draft charter Thread-Index: AcpBd2/ClvVeEjnrTByiarIpGsJz8AAds5LA Message-ID: References: <4AC0DD0D.30909@cybernothing.org> <4AC130D0.4050108@mail-abuse.org> <4AC14109.4060107@cybernothing.org> <4AC14E90.4050407@mail-abuse.org> <4AC2426D.4070609@cybernothing.org> <4AC280FF.8070706@mail-abuse.org> <4AC2A6B6.4080100@mail-abuse.org> <501c18e00909291906s1e3466b3r9e25e4aad6b1cb94@mail.gmail.com> <826A8469-E15D-43FE-B5C1-6CF4739A67BA@word-to-the-wise.com> In-Reply-To: <826A8469-E15D-43FE-B5C1-6CF4739A67BA@word-to-the-wise.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" MIME-Version: 1.0 X-Virus-Scanned: ClamAV 0.92/9856/Wed Sep 30 05:27:30 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Delayed for 00:30:33 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 30 Sep 2009 10:24:03 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n8UHNw21024115 Subject: Re: [feedback-report] "reality" check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 17:24:03 -0000 > -----Original Message----- > From: abuse-feedback-report-bounces@mipassoc.org [mailto:abuse- > feedback-report-bounces@mipassoc.org] On Behalf Of Steve Atkins > Sent: Tuesday, September 29, 2009 7:40 PM > To: ARF mailing list > Subject: Re: [feedback-report] "reality" check, was Revised draft > charter > > >> Well, of course. But I think you will look in vain for any IETF > >> standard > >> that includes useful advice about how not to be stupid. > >> > > > > But it might be a good idea to have a separate draft with operational > > experience related to ARF so people are less likely to do stupid > > things. > > The (sole) value of ARF is to provide easy interoperability at the > transport > layer, and that's the sort of thing the IETF is good at. > > "Not being stupid" at the political layer is something that's likely to > be defined mostly by agreements between consenting parties who are > using ARF. It's something that's mostly orthogonal to the protocol > level work on ARF, and it may be something that's better > left to those who are actually producing or consuming feedback loops > - either through their contracts with each other or through an > organization like MAAWG that's a bit higher up the protocol stack > than the IETF. The IETF has produced BCP RFCs in the past. For example, several of the documents the DKIM WG produced are information and provide guidance about implementation rather than protocol specification. An ARF WG could take that on as a task after its initial deliverables are completed. Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8UHI5nW023592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 30 Sep 2009 10:18:11 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@cybernothing.org Received: from rpco-jdmacbook.rpcorp.local (np54.co.returnpath.net [38.109.196.54]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id n8UHI2Nv023904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 30 Sep 2009 11:18:04 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net n8UHI2Nv023904 Message-ID: <4AC392C0.5030109@cybernothing.org> Date: Wed, 30 Sep 2009 11:17:52 -0600 From: "J.D. Falk" User-Agent: Postbox 1.0b16 (Macintosh/2009090218) MIME-Version: 1.0 To: ARF mailing list References: <4AC0DD0D.30909@cybernothing.org> <4AC130D0.4050108@mail-abuse.org> <4AC14109.4060107@cybernothing.org> <4AC14E90.4050407@mail-abuse.org> <4AC2426D.4070609@cybernothing.org> <4AC280FF.8070706@mail-abuse.org> <4AC2A6B6.4080100@mail-abuse.org> <501c18e00909291906s1e3466b3r9e25e4aad6b1cb94@mail.gmail.com> <826A8469-E15D-43FE-B5C1-6CF4739A67BA@word-to-the-wise.com> <4AC30E54.6020906@tana.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9856/Wed Sep 30 05:27:30 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 30 Sep 2009 10:18:11 -0700 (PDT) Subject: Re: [feedback-report] "reality" check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 17:18:11 -0000 John R. Levine wrote: > ARF is quite successful as it is, and it's worth standardizing what people > actually use. +1 -- J.D. Falk Return Path Inc http://www.returnpath.net/ Received: from vms173011pub.verizon.net (vms173011pub.verizon.net [206.46.173.11]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8UFBaEr014414 for ; Wed, 30 Sep 2009 08:11:42 -0700 Received: from nanki-poo.3612opr ([71.191.163.50]) by vms173011.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KQS000GMFE6XRA9@vms173011.mailsrvcs.net> for abuse-feedback-report@mipassoc.org; Wed, 30 Sep 2009 09:11:04 -0500 (CDT) Message-id: <4AC366EE.4030502@davearonson.com> Date: Wed, 30 Sep 2009 10:10:54 -0400 From: Dave Aronson User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-version: 1.0 To: ARF mailing list Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9856/Wed Sep 30 05:27:30 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Delayed for 01:00:09 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 30 Sep 2009 08:11:42 -0700 (PDT) Subject: Re: [feedback-report] "reality" check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 15:11:42 -0000 John R. Levine wrote: > It would be technically possible to define something analogous to an MX to > invite abuse reports, but I have seen nothing to suggest that there is any > demand for such a thing. Perhaps an organization might want to publish such records in order to claim that they "care"... never mind that, behind the scenes, the reports are blackholed upon receipt, possibly with an autoreply. Given the past behavior by certain major ISPs/carriers regarding spam reports, this would not surprise me at all. -Dave -- Dave Aronson, software engineer or trainer for hire. Looking for job (or contract) in Washington DC area. See http://davearonson.com/ for resume & other info. Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8UCmDsE001680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 30 Sep 2009 05:48:19 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 27803 invoked from network); 30 Sep 2009 12:48:12 -0000 Received: (ofmipd 208.31.42.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Sep 2009 12:47:50 -0000 Date: 30 Sep 2009 08:48:12 -0400 Message-ID: From: "John R. Levine" To: "Alessandro Vesely" In-Reply-To: <4AC30E54.6020906@tana.it> References: <4AC0DD0D.30909@cybernothing.org> <4AC130D0.4050108@mail-abuse.org> <4AC14109.4060107@cybernothing.org> <4AC14E90.4050407@mail-abuse.org> <4AC2426D.4070609@cybernothing.org> <4AC280FF.8070706@mail-abuse.org> <4AC2A6B6.4080100@mail-abuse.org> <501c18e00909291906s1e3466b3r9e25e4aad6b1cb94@mail.gmail.com> <826A8469-E15D-43FE-B5C1-6CF4739A67BA@word-to-the-wise.com> <4AC30E54.6020906@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 X-Virus-Scanned: ClamAV 0.92/9855/Wed Sep 30 03:40:17 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 30 Sep 2009 05:48:19 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] "reality" check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 12:48:20 -0000 > SMTP, for example, is structured as two loosely coordinated > documents, one for the format and the other for the dynamics of > exchanging the relevant data. Obviously, it cannot mandate who and > why would send what message to whom... Hmmn. I gather you are not familiar with RFCs 2821 and 5321, since section 5 of each is about exactly that topic. Domains invite SMTP traffic by publishing MX records. It would be technically possible to define something analogous to an MX to invite abuse reports, but I have seen nothing to suggest that there is any demand for such a thing. It wouldn't be straightforward due to the messiness of publishing data related to IP addresses and to subdomains, and there's no point in spending effort on yet another unused standard. ARF is quite successful as it is, and it's worth standardizing what people actually use. That's how normal standards organizations work. R's, John Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8U7q6CW008527 for ; Wed, 30 Sep 2009 00:52:29 -0700 Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 30 Sep 2009 09:52:28 +0200 id 00000000005DC039.000000004AC30E3C.0000057E Message-ID: <4AC30E54.6020906@tana.it> Date: Wed, 30 Sep 2009 09:52:52 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: ARF mailing list References: <4AC0DD0D.30909@cybernothing.org> <4AC130D0.4050108@mail-abuse.org> <4AC14109.4060107@cybernothing.org> <4AC14E90.4050407@mail-abuse.org> <4AC2426D.4070609@cybernothing.org> <4AC280FF.8070706@mail-abuse.org> <4AC2A6B6.4080100@mail-abuse.org> <501c18e00909291906s1e3466b3r9e25e4aad6b1cb94@mail.gmail.com> <826A8469-E15D-43FE-B5C1-6CF4739A67BA@word-to-the-wise.com> In-Reply-To: <826A8469-E15D-43FE-B5C1-6CF4739A67BA@word-to-the-wise.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9854/Tue Sep 29 21:52:32 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 30 Sep 2009 00:52:29 -0700 (PDT) Subject: Re: [feedback-report] "reality" check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 07:52:29 -0000 Steve Atkins wrote: > On Sep 29, 2009, at 7:06 PM, Yakov Shafranovich wrote: >> But it might be a good idea to have a separate draft with operational >> experience related to ARF so people are less likely to do stupid >> things. > > The (sole) value of ARF is to provide easy interoperability at the > transport layer, and that's the sort of thing the IETF is good at. SMTP, for example, is structured as two loosely coordinated documents, one for the format and the other for the dynamics of exchanging the relevant data. Obviously, it cannot mandate who and why would send what message to whom... For ARF, by parallel reasoning, we would mention how an abuse report is originally submitted and what mechanisms allow it to reach its consumers. It may additional inform about where political settlements may affect sensible concerns. > "Not being stupid" at the political layer is something that's likely to > be defined mostly by agreements between consenting parties who are > using ARF. It's something that's mostly orthogonal to the protocol > level work on ARF, and it may be something that's better > left to those who are actually producing or consuming feedback loops > - either through their contracts with each other or through an > organization like MAAWG that's a bit higher up the protocol stack > than the IETF. The political, orthogonal, part would then include any reaction that an operator may take based on abuse reports. I agree this is at a different level and not quite standardizable. Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8U7q6CU008527 for ; Wed, 30 Sep 2009 00:52:12 -0700 Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 30 Sep 2009 09:52:02 +0200 id 00000000005DC036.000000004AC30E23.0000054E Message-ID: <4AC30E39.5040109@tana.it> Date: Wed, 30 Sep 2009 09:52:25 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "John R. Levine" References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> <4ABF44A0.8010104@tana.it> <4AC0DD0D.30909@cybernothing.org> <4AC105B3.9080600@tana.it> <6D4EF14B-F8D9-4E0B-964A-A4CC8161A650@word-to-the-wise.com> <4AC2329D.2010704@tana.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9854/Tue Sep 29 21:52:32 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 30 Sep 2009 00:52:12 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] reality check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 07:52:12 -0000 John R. Levine wrote: > I think it's safe to say that the vast majority of FBL traffic currently > flows via bilateral agreements. Hm... one possibility is to define FBL in that way. That would neatly distinguish it from, e.g., Abusix's "global reporting", although both may use ARF. > Again, you need to familiarize yourself with what's already going on. Although I've read a fair amount of docs, I never even found a definition of FBL (except the one on wikipedia, that I had to write myself.) >> In addition, unless they share more than the FBL proper, they would >> not offer the compensation of accepting rather than blocking senders >> based on the complaint ratio they rouse. > > Nobody promises to whitelist FBL recipients. Although it could be done, the alternative to block senders whose complaint ratio exceeds a given threshold is still a means for compensation. > Again, you need to familiarize yourself with what's already going on. Any pointer to technical documentation I'm likely missing, please? >> Yet, such standard has to be published before it can be enforced. > > Um, billions of ARF messages are successfully exchanged every day. > Nobody "enforces" IETF standards. That may be the reason why much confusion would result from the introduction of new ways to exchange those messages. And I presume that's the reason for proposing this WG. > Again, you need to familiarize yourself with what's already going on. Thinking thrice, if FBL delivery is destined to remain an obscure mechanism provided as-is for a few large operators only, then maybe I don't need to :-/ Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8U2db9n015417 for ; Tue, 29 Sep 2009 19:39:42 -0700 Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id E15708036B for ; Tue, 29 Sep 2009 19:39:36 -0700 (PDT) Message-Id: <826A8469-E15D-43FE-B5C1-6CF4739A67BA@word-to-the-wise.com> From: Steve Atkins To: ARF mailing list In-Reply-To: <501c18e00909291906s1e3466b3r9e25e4aad6b1cb94@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 29 Sep 2009 19:39:35 -0700 References: <4AC0DD0D.30909@cybernothing.org> <4AC130D0.4050108@mail-abuse.org> <4AC14109.4060107@cybernothing.org> <4AC14E90.4050407@mail-abuse.org> <4AC2426D.4070609@cybernothing.org> <4AC280FF.8070706@mail-abuse.org> <4AC2A6B6.4080100@mail-abuse.org> <501c18e00909291906s1e3466b3r9e25e4aad6b1cb94@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-Virus-Scanned: ClamAV 0.92/9853/Tue Sep 29 12:34:02 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 29 Sep 2009 19:39:42 -0700 (PDT) Subject: Re: [feedback-report] "reality" check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 02:39:43 -0000 On Sep 29, 2009, at 7:06 PM, Yakov Shafranovich wrote: > On Tue, Sep 29, 2009 at 9:52 PM, John R. Levine > wrote: >>> Not at all. Indeed, the generation of feedback is often fully >>> automated. >>> However, use of information obtained from a complex, albeit >>> automated >>> process, should include safeguards against third-party error. >> >> Well, of course. But I think you will look in vain for any IETF >> standard >> that includes useful advice about how not to be stupid. >> > > But it might be a good idea to have a separate draft with operational > experience related to ARF so people are less likely to do stupid > things. The (sole) value of ARF is to provide easy interoperability at the transport layer, and that's the sort of thing the IETF is good at. "Not being stupid" at the political layer is something that's likely to be defined mostly by agreements between consenting parties who are using ARF. It's something that's mostly orthogonal to the protocol level work on ARF, and it may be something that's better left to those who are actually producing or consuming feedback loops - either through their contracts with each other or through an organization like MAAWG that's a bit higher up the protocol stack than the IETF. Cheers, Steve Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8U26kxx012229 for ; Tue, 29 Sep 2009 19:06:52 -0700 Received: by pxi13 with SMTP id 13so6625860pxi.6 for ; Tue, 29 Sep 2009 19:06:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.255.21 with SMTP id c21mr522264rvi.285.1254276406589; Tue, 29 Sep 2009 19:06:46 -0700 (PDT) In-Reply-To: References: <4AC0DD0D.30909@cybernothing.org> <4AC130D0.4050108@mail-abuse.org> <4AC14109.4060107@cybernothing.org> <4AC14E90.4050407@mail-abuse.org> <4AC2426D.4070609@cybernothing.org> <4AC280FF.8070706@mail-abuse.org> <4AC2A6B6.4080100@mail-abuse.org> From: Yakov Shafranovich Date: Tue, 29 Sep 2009 22:06:26 -0400 Message-ID: <501c18e00909291906s1e3466b3r9e25e4aad6b1cb94@mail.gmail.com> To: ARF mailing list Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: ClamAV 0.92/9853/Tue Sep 29 12:34:02 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 29 Sep 2009 19:06:52 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n8U26kxx012229 Subject: Re: [feedback-report] "reality" check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 02:06:52 -0000 On Tue, Sep 29, 2009 at 9:52 PM, John R. Levine wrote: >> Not at all.  Indeed, the generation of feedback is often fully automated. >> However, use of information obtained from a complex, albeit automated >> process, should include safeguards against third-party error. > > Well, of course.  But I think you will look in vain for any IETF standard > that includes useful advice about how not to be stupid. > But it might be a good idea to have a separate draft with operational experience related to ARF so people are less likely to do stupid things. Yakov Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8U1qfhl011103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Sep 2009 18:52:47 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 84316 invoked from network); 30 Sep 2009 01:52:41 -0000 Received: (ofmipd 208.31.42.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Sep 2009 01:52:19 -0000 Date: 29 Sep 2009 21:52:40 -0400 Message-ID: From: "John R. Levine" To: "Douglas Otis" In-Reply-To: <4AC2A6B6.4080100@mail-abuse.org> References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> <4ABF44A0.8010104@tana.it> <4AC0DD0D.30909@cybernothing.org> <4AC130D0.4050108@mail-abuse.org> <4AC14109.4060107@cybernothing.org> <4AC14E90.4050407@mail-abuse.org> <4AC2426D.4070609@cybernothing.org> <4AC280FF.8070706@mail-abuse.org> <4AC2A6B6.4080100@mail-abuse.org> 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 X-Virus-Scanned: ClamAV 0.92/9853/Tue Sep 29 12:34:02 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 29 Sep 2009 18:52:47 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] "reality" check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 01:52:48 -0000 > Not at all. Indeed, the generation of feedback is often fully automated. > However, use of information obtained from a complex, albeit automated > process, should include safeguards against third-party error. Well, of course. But I think you will look in vain for any IETF standard that includes useful advice about how not to be stupid. Manual inspection is one possibility, but hardly the only one. It is my strong impression that large FBL consumers use statistical techniques to figure out what's plausible, because the volume is far too great to manage manually. But, really, it's not our job to tell people how to do that, because we don't know. R's, John Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8U1WeKX009695 for ; Tue, 29 Sep 2009 18:32:45 -0700 Authentication-Results: sbh17.songbird.com; dkim=hardfail (verification failed) header.i=@kitterman.com Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3A62020E413A; Tue, 29 Sep 2009 20:53:18 -0400 (EDT) Received: from [75.192.80.152] (152.sub-75-192-80.myvzw.com [75.192.80.152]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4F24620E40C4; Tue, 29 Sep 2009 20:53:14 -0400 (EDT) Mime-Version: 1.0 X-Mailer: SnapperMail 2.4.2.01 by Snapperfish To: ARF mailing list Message-ID: <17545-SnapperMsgD8DB99B6C6E85C7C@[75.192.80.152]> In-Reply-To: <4AC2A6B6.4080100@mail-abuse.org> References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> <4ABF44A0.8010104@tana.it> <4AC0DD0D.30909@cybernothing.org> <4AC130D0.4050108@mail-abuse.org> <4AC14109.4060107@cybernothing.org> <4AC14E90.40 50407@mail-abuse.org> <4AC2426D.4070609@cybernothing.org> <4AC280FF.8070706@mail-abuse.org> <4AC2A6B6.4080100@mail-abuse.org> From: sklist@kitterman.com Date: Tue, 29 Sep 2009 20:52:28 -0400 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV 0.92/9853/Tue Sep 29 12:34:02 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Delayed for 00:39:22 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 29 Sep 2009 18:32:45 -0700 (PDT) Subject: Re: [feedback-report] "reality" check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 01:32:46 -0000 On Tue, 29 Sep 2009 17:30:46 -0700 Douglas Otis wrote: >On 9/29/09 3:11 PM, John R. Levine wrote: >>> The draft should temper expectations that ARF allows the creation of a >>> fully automated administrative scheme. >> >> Are you claiming that the existing automated FBLs don't exist? > >Not at all. Indeed, the generation of feedback is often fully >automated. However, use of information obtained from a complex, albeit >automated process, should include safeguards against third-party error. > >IMHO, visual inspection, even on a sampling basis, is important. This >is about human communications and not something simple. Visual >inspection provides a way to discover many of the games played by bad >actors, and a way to protect innocent users from loss of their accounts. > What harm is there in saying a provider should take responsibility for >their actions. A responsible provider should visually confirm >information before acting upon an automated categorization of email >messages performed by a third-party? This would not require all >messages be checked in any specific case. What sampling rate would you recommend be required? Scott K Received: from harry.mail-abuse.org ([168.61.5.27]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8U0VaSw006288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Sep 2009 17:31:42 -0700 Received: from sjc-office-nat-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id CC8E5A9443B; Wed, 30 Sep 2009 00:30:46 +0000 (UTC) Message-ID: <4AC2A6B6.4080100@mail-abuse.org> Date: Tue, 29 Sep 2009 17:30:46 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: "John R. Levine" References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> <4ABF44A0.8010104@tana.it> <4AC0DD0D.30909@cybernothing.org> <4AC130D0.4050108@mail-abuse.org> <4AC14109.4060107@cybernothing.org> <4AC14E90.4050407@mail-abuse.org> <4AC2426D.4070609@cybernothing.org> <4AC280FF.8070706@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9853/Tue Sep 29 12:34:02 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 29 Sep 2009 17:31:42 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] "reality" check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 00:31:42 -0000 On 9/29/09 3:11 PM, John R. Levine wrote: >> The draft should temper expectations that ARF allows the creation of a >> fully automated administrative scheme. > > Are you claiming that the existing automated FBLs don't exist? Not at all. Indeed, the generation of feedback is often fully automated. However, use of information obtained from a complex, albeit automated process, should include safeguards against third-party error. IMHO, visual inspection, even on a sampling basis, is important. This is about human communications and not something simple. Visual inspection provides a way to discover many of the games played by bad actors, and a way to protect innocent users from loss of their accounts. What harm is there in saying a provider should take responsibility for their actions. A responsible provider should visually confirm information before acting upon an automated categorization of email messages performed by a third-party? This would not require all messages be checked in any specific case. -Doug Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8TMBIGJ031768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Sep 2009 15:11:23 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 35851 invoked from network); 29 Sep 2009 22:11:17 -0000 Received: (ofmipd 208.31.42.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 29 Sep 2009 22:10:55 -0000 Date: 29 Sep 2009 18:11:16 -0400 Message-ID: From: "John R. Levine" To: "Douglas Otis" In-Reply-To: <4AC280FF.8070706@mail-abuse.org> References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> <4ABF44A0.8010104@tana.it> <4AC0DD0D.30909@cybernothing.org> <4AC130D0.4050108@mail-abuse.org> <4AC14109.4060107@cybernothing.org> <4AC14E90.4050407@mail-abuse.org> <4AC2426D.4070609@cybernothing.org> <4AC280FF.8070706@mail-abuse.org> 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 X-Virus-Scanned: ClamAV 0.92/9853/Tue Sep 29 12:34:02 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 29 Sep 2009 15:11:24 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] "reality" check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 22:11:24 -0000 > The draft should temper expectations that ARF allows the creation of a > fully automated administrative scheme. Are you claiming that the existing automated FBLs don't exist? R's, John Received: from harry.mail-abuse.org ([168.61.5.27]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8TLoglx030844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Sep 2009 14:50:47 -0700 Received: from sjc-office-nat-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 21F4FA94446; Tue, 29 Sep 2009 21:49:52 +0000 (UTC) Message-ID: <4AC280FF.8070706@mail-abuse.org> Date: Tue, 29 Sep 2009 14:49:51 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: "J.D. Falk" References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> <4ABF44A0.8010104@tana.it> <4AC0DD0D.30909@cybernothing.org> <4AC130D0.4050108@mail-abuse.org> <4AC14109.4060107@cybernothing.org> <4AC14E90.4050407@mail-abuse.org> <4AC2426D.4070609@cybernothing.org> In-Reply-To: <4AC2426D.4070609@cybernothing.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9853/Tue Sep 29 12:34:02 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 29 Sep 2009 14:50:47 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] "reality" check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 21:50:47 -0000 On 9/29/09 10:22 AM, J.D. Falk wrote: > Douglas Otis wrote: > >> Limiting category selections would fine. However, the concern regarding >> the proper categorization of a message remains a concern, even when >> limited to messages being categorized as spam/abusive or not. Here >> auto-responses in foreign languages being marked as spam are one example >> of a common mistake. > > That all depends on whether you believe that every complaint will be treated > as Ultimate Truth by report recipients. Thus far, there's no evidence to > support that belief. > > Is it actually necessary to explicitly state that the report recipient is > allowed to decide for themselves whether or not to take action on any single > report, and allowed to decide for themselves what that action will be? The draft should temper expectations that ARF allows the creation of a fully automated administrative scheme. It remains important, especially when little is known about how ARF information might be used or misused, to also mention a need for human overview of the process where messages receive visual examination. When dealing with information from some third-party's automated script, the draft should stress that the onus of determining the validity of information is with the receiver. This point can be strengthened with a statement that the system's integrity can be improved through visual examination of automated results. Scripts and processes often make mistakes, where conclusions should not be based solely upon ARF report counts. Adequate inspection will not require every message be viewed, only that enough are sampled and reviewed for each case. -Doug Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8TLUR0l030029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Sep 2009 14:30:33 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 5276 invoked from network); 29 Sep 2009 21:30:25 -0000 Received: (ofmipd 208.31.42.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 29 Sep 2009 21:30:01 -0000 Date: 29 Sep 2009 17:30:22 -0400 Message-ID: From: "John R. Levine" To: "Alessandro Vesely" In-Reply-To: <4AC2329D.2010704@tana.it> References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> <4ABF44A0.8010104@tana.it> <4AC0DD0D.30909@cybernothing.org> <4AC105B3.9080600@tana.it> <6D4EF14B-F8D9-4E0B-964A-A4CC8161A650@word-to-the-wise.com> <4AC2329D.2010704@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 X-Virus-Scanned: ClamAV 0.92/9853/Tue Sep 29 12:34:02 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 29 Sep 2009 14:30:33 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] reality check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 21:30:34 -0000 >> If you're so small that a recipient may receive just one report from >> you, then there's no mechanical way to distinguish whether that's >> signal or that's noise. > > I thought a single complaint was enough for unsubscribing a user. Usually, although as I'm sure others will tell you, opinions vary, particularly if a list has a history of false positives. I get AOL spam reports all the time for one particular non-technical list and although my system unsubs them all, I suspect the majority are mistakes. >> One obvious thing would be for you and a bunch of other tiny >> mailbox providers to gang together to offer a FBL large enough >> that the data may be relevant. > > A rather difficult task, since mailbox providers, unlike network > providers, don't need prior arrangements among one another in order to > operate. (Such was the goal of SMTP.) I think it's safe to say that the vast majority of FBL traffic currently flows via bilateral agreements. Again, you need to familiarize yourself with what's already going on. > In addition, unless they share more than the FBL proper, they would > not offer the compensation of accepting rather than blocking senders > based on the complaint ratio they rouse. Nobody promises to whitelist FBL recipients. Again, you need to familiarize yourself with what's already going on. > Yet, such standard has to be published before it can be enforced. Um, billions of ARF messages are successfully exchanged every day. Nobody "enforces" IETF standards. Again, you need to familiarize yourself with what's already going on. R's, John Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8THOska007120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 29 Sep 2009 10:25:00 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@cybernothing.org Received: from rpco-jdmacbook.rpcorp.local (np54.co.returnpath.net [38.109.196.54]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id n8THOqvX000417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 29 Sep 2009 11:24:54 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net n8THOqvX000417 Message-ID: <4AC242DF.9030607@cybernothing.org> Date: Tue, 29 Sep 2009 11:24:47 -0600 From: "J.D. Falk" User-Agent: Postbox 1.0b16 (Macintosh/2009090218) MIME-Version: 1.0 To: ARF mailing list References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> <4ABF44A0.8010104@tana.it> <4AC0DD0D.30909@cybernothing.org> <4AC105B3.9080600@tana.it> <6D4EF14B-F8D9-4E0B-964A-A4CC8161A650@word-to-the-wise.com> <4AC2329D.2010704@tana.it> In-Reply-To: <4AC2329D.2010704@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9852/Tue Sep 29 08:06:51 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 29 Sep 2009 10:25:00 -0700 (PDT) Subject: Re: [feedback-report] reality check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 17:25:01 -0000 Alessandro Vesely wrote: > I thought a single complaint was enough for unsubscribing a user. That's an implementation decision, not a requirement imposed by the Abuse Reporting Format that we are discussing here. > In rare cases I send hand written reports. Normally I hit delete, as > that's the only button I have. If report-spam buttons result in a > better effect, it would seem unfair to restrict their usage. Any such restriction would also be an implementation decision, and not a requirement imposed by the format. -- J.D. Falk Return Path Inc http://www.returnpath.net/ Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8THN4Kq006955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 29 Sep 2009 10:23:10 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@cybernothing.org Received: from rpco-jdmacbook.rpcorp.local (np54.co.returnpath.net [38.109.196.54]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id n8THMwrI000371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 29 Sep 2009 11:23:00 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net n8THMwrI000371 Message-ID: <4AC2426D.4070609@cybernothing.org> Date: Tue, 29 Sep 2009 11:22:53 -0600 From: "J.D. Falk" User-Agent: Postbox 1.0b16 (Macintosh/2009090218) MIME-Version: 1.0 To: ARF mailing list References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> <4ABF44A0.8010104@tana.it> <4AC0DD0D.30909@cybernothing.org> <4AC130D0.4050108@mail-abuse.org> <4AC14109.4060107@cybernothing.org> <4AC14E90.4050407@mail-abuse.org> In-Reply-To: <4AC14E90.4050407@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9852/Tue Sep 29 08:06:51 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 29 Sep 2009 10:23:10 -0700 (PDT) Subject: Re: [feedback-report] "reality" check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 17:23:10 -0000 Douglas Otis wrote: > Limiting category selections would fine. However, the concern regarding > the proper categorization of a message remains a concern, even when > limited to messages being categorized as spam/abusive or not. Here > auto-responses in foreign languages being marked as spam are one example > of a common mistake. That all depends on whether you believe that every complaint will be treated as Ultimate Truth by report recipients. Thus far, there's no evidence to support that belief. Is it actually necessary to explicitly state that the report recipient is allowed to decide for themselves whether or not to take action on any single report, and allowed to decide for themselves what that action will be? -- J.D. Falk Return Path Inc http://www.returnpath.net/ Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8TGFSFT032673 for ; Tue, 29 Sep 2009 09:15:34 -0700 Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 29 Sep 2009 18:15:26 +0200 id 00000000005DC033.000000004AC2329E.00004B6E Message-ID: <4AC2329D.2010704@tana.it> Date: Tue, 29 Sep 2009 18:15:25 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ARF mailing list References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> <4ABF44A0.8010104@tana.it> <4AC0DD0D.30909@cybernothing.org> <4AC105B3.9080600@tana.it> <6D4EF14B-F8D9-4E0B-964A-A4CC8161A650@word-to-the-wise.com> In-Reply-To: <6D4EF14B-F8D9-4E0B-964A-A4CC8161A650@word-to-the-wise.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9852/Tue Sep 29 08:06:51 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 29 Sep 2009 09:15:34 -0700 (PDT) Subject: Re: [feedback-report] reality check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 16:15:37 -0000 Steve Atkins wrote: >> The other way around, what is the number of FBLs that a new mail site >> should subscribe to, if every other mail site already has one? > > I think what you're saying is that you don't believe you're a source > of enough data or valuable enough data that anyone else is > going to be interested in it. Exactly! > I think you're right. > > One of the big advantages of FBLs from large ISPs is that they > provide a volume of data that is high enough that you can derive > signal out of the noise. > > If you're so small that a recipient may receive just one report from > you, then there's no mechanical way to distinguish whether that's > signal or that's noise. I thought a single complaint was enough for unsubscribing a user. > One obvious thing would be for you and a bunch of other tiny > mailbox providers to gang together to offer a FBL large enough > that the data may be relevant. A rather difficult task, since mailbox providers, unlike network providers, don't need prior arrangements among one another in order to operate. (Such was the goal of SMTP.) In addition, unless they share more than the FBL proper, they would not offer the compensation of accepting rather than blocking senders based on the complaint ratio they rouse. > That leads to the other problem, though. With existing FBLs it's > usually very, very well-defined what a report means and what > action is expected by the recipient of the report. > > Unless your co-operative of tiny ISPs were to enforce identical > standards across all your members you'd end up with the situation > where it wasn't clear what any particular report meant, meaning > they'll likely not have much attention paid to them, as it'll be > impossible to mechanically pull any signal out of the noise. Yet, such standard has to be published before it can be enforced. > Unless you think you can manage and enforce that sort of a setup > then you're best not providing a FBL and simply sending hand > written reports. In rare cases I send hand written reports. Normally I hit delete, as that's the only button I have. If report-spam buttons result in a better effect, it would seem unfair to restrict their usage. > Note also that any situation where you have ISPs sending unsolicited > reports directly to senders, without any sort of agreement in place, > is going to lead to the same sort of data consistency problems as > a badly run co-op. Lots of noise, hard to identify any signal. I agree that's a problem. Also add the trust and privacy concerns, that can be formally avoided with FBL agreements. Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8T6uiRE020376 for ; Mon, 28 Sep 2009 23:56:49 -0700 Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 29 Sep 2009 08:56:43 +0200 id 00000000005DC030.000000004AC1AFAB.00006807 Message-ID: <4AC1AFC0.2010300@tana.it> Date: Tue, 29 Sep 2009 08:57:04 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: ARF mailing list References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> <4ABF44A0.8010104@tana.it> <4AC0DD0D.30909@cybernothing.org> <4AC130D0.4050108@mail-abuse.org> In-Reply-To: <4AC130D0.4050108@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9848/Mon Sep 28 20:48:16 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 28 Sep 2009 23:56:50 -0700 (PDT) Subject: Re: [feedback-report] reality check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 06:56:52 -0000 Douglas Otis wrote: > It would be careless to expect ARF reports represent a solution allowing > complete automation of abusive account identification. Such an > assumption runs the risk of the ARF process being used as a vehicle to > cause individual's the loss of their email access. Only visual review > can help guard against most egregious automation mistakes. The only case I recall --from discussions-- of unauthenticated abusive messages deserving some sort of treatment is dropboxes, that may deserve being monitored for phishing responses. A very different treatment than counting abuses for the sake of eventual administrative actions. Received: from harry.mail-abuse.org ([168.61.5.27]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8T03ELh024831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Sep 2009 17:03:20 -0700 Received: from sjc-office-nat-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id C3041A9443B; Tue, 29 Sep 2009 00:02:24 +0000 (UTC) Message-ID: <4AC14E90.4050407@mail-abuse.org> Date: Mon, 28 Sep 2009 17:02:24 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: "J.D. Falk" References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> <4ABF44A0.8010104@tana.it> <4AC0DD0D.30909@cybernothing.org> <4AC130D0.4050108@mail-abuse.org> <4AC14109.4060107@cybernothing.org> In-Reply-To: <4AC14109.4060107@cybernothing.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9846/Mon Sep 28 14:18:48 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 28 Sep 2009 17:03:20 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] reality check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 00:03:20 -0000 On 9/28/09 4:04 PM, J.D. Falk wrote: > Douglas Otis wrote: > >> It should be stated as a good practice for providers receiving ARF >> reports, to visually review on a sampling basis, the messages contained >> to confirm an ARF generator's proper message categorizations. > > Except for a few test environments, I'm not aware of any ARF generator using > a Feedback-Type other than "abuse". This is why I proposed removing most of > the other types. > > I'll make that proposal again once we've got a working group. J.D. Limiting category selections would fine. However, the concern regarding the proper categorization of a message remains a concern, even when limited to messages being categorized as spam/abusive or not. Here auto-responses in foreign languages being marked as spam are one example of a common mistake. Spammers often use harvested email addresses in their spam's return address. When this address represents a honey-pot, then determining which messages are auto-responses becomes important. Often mistakes can be visually obvious, even when the language of the message is not understood. Language recognition and translation tools are making this task easier, however support for some languages still remains limited. In languages where support is good, recognition errors still represent several percentage points. Message categorization has not reached a point of certainty that allows an assumption of categorization errors being so few as to be negligent, IMHO. Strides are being made at improving this situation in our own product, with emphasis on several Asian and Middle Eastern languages. Nevertheless, spammers leverage any gray area in an automated process, where often no two messages are identical to thwart statistical analysis. With vast computational resources at their disposal, spammers enjoy an advantage when it comes to automation. -Doug Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8SN4nS3022282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 28 Sep 2009 16:04:55 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@cybernothing.org Received: from rpco-jdmacbook.rpcorp.local (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id n8SN4kHA014304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 28 Sep 2009 17:04:48 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net n8SN4kHA014304 Message-ID: <4AC14109.4060107@cybernothing.org> Date: Mon, 28 Sep 2009 17:04:41 -0600 From: "J.D. Falk" User-Agent: Postbox 1.0b16 (Macintosh/2009090218) MIME-Version: 1.0 To: ARF mailing list References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> <4ABF44A0.8010104@tana.it> <4AC0DD0D.30909@cybernothing.org> <4AC130D0.4050108@mail-abuse.org> In-Reply-To: <4AC130D0.4050108@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9845/Mon Sep 28 10:02:17 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 28 Sep 2009 16:04:55 -0700 (PDT) Subject: Re: [feedback-report] reality check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 23:04:55 -0000 Douglas Otis wrote: > It should be stated as a good practice for providers receiving ARF > reports, to visually review on a sampling basis, the messages contained > to confirm an ARF generator's proper message categorizations. Except for a few test environments, I'm not aware of any ARF generator using a Feedback-Type other than "abuse". This is why I proposed removing most of the other types. I'll make that proposal again once we've got a working group. -- J.D. Falk Return Path Inc http://www.returnpath.net/ Received: from harry.mail-abuse.org ([168.61.5.27]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8SMZss6021118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Sep 2009 15:35:59 -0700 Received: from sjc-office-nat-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 69D11A9443B; Mon, 28 Sep 2009 21:55:29 +0000 (UTC) Message-ID: <4AC130D0.4050108@mail-abuse.org> Date: Mon, 28 Sep 2009 14:55:28 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: "J.D. Falk" References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> <4ABF44A0.8010104@tana.it> <4AC0DD0D.30909@cybernothing.org> In-Reply-To: <4AC0DD0D.30909@cybernothing.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9845/Mon Sep 28 10:02:17 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Delayed for 00:39:33 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 28 Sep 2009 15:35:59 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] reality check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 22:36:00 -0000 On 9/28/09 8:58 AM, J.D. Falk wrote: > I'm not aware of any complaint feedback loop operating today in which a > postmaster manually forwards complaints to all feedback subscribers. > Instead, it's an automated process whereby approved subscribers receive > complaints about messages originating from their own IP ranges, without any > manual interaction. Nearly all of these use ARF. Since information generated by feedback systems represent an automated categorization of messages marked as abuse or spam, fraud or phish, virus or malware, opt-out, apart from non-spam, NDN, or auto-responses. There will be incorrect categorizations made. Auto-responses are often mis-categorized, for example. It should be stated as a good practice for providers receiving ARF reports, to visually review on a sampling basis, the messages contained to confirm an ARF generator's proper message categorizations. Bad actors are continuously finding ways to evade categorizations, where counter measures might lead to a number of categorization errors. Ensuring prevalence of erroneous accusations of bad behavior remains low, would be reliant upon a provider's visual review of received ARF reports. Full dependence upon message categorization filters without visual reviews lowers email's reliability. This practice becomes important whenever accounts are disabled or removed based upon automated feedback. ARF feedback can be wrong in what some might be considered more than a negligible number of cases. After all, a categorization process is constantly evolving. It would be careless to expect ARF reports represent a solution allowing complete automation of abusive account identification. Such an assumption runs the risk of the ARF process being used as a vehicle to cause individual's the loss of their email access. Only visual review can help guard against most egregious automation mistakes. -Doug Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8SLMxk9018172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Sep 2009 14:23:05 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 59717 invoked from network); 28 Sep 2009 21:22:59 -0000 Received: (ofmipd 208.31.42.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 28 Sep 2009 21:22:37 -0000 Date: 28 Sep 2009 17:22:58 -0400 Message-ID: From: "John R. Levine" To: "Alessandro Vesely" In-Reply-To: <4ABE5052.7050307@tana.it> References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@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 X-Virus-Scanned: ClamAV 0.92/9845/Mon Sep 28 10:02:17 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 28 Sep 2009 14:23:06 -0700 (PDT) Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] reality check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 21:23:06 -0000 >> Just for reference, have you ever used any of the existing MUA spam >> buttons? > > Never, as you probably already guessed. It would really save us all a lot of wasted time if you would spend at least a few minutes finding out how things work now before making proposals that have no chance of ever being implemented. >> How many questions did it ask? > > If it asks no questions, how can it compile a "good" report? Who is going to > read the human readable part? Anyone who is familiar with ARF already knows the answers to those questions, so there seems little reason to waste the list's time with them. R's, John Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8SJJYBS012383 for ; Mon, 28 Sep 2009 12:19:39 -0700 Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 0317A80598 for ; Mon, 28 Sep 2009 12:19:33 -0700 (PDT) Message-Id: <6D4EF14B-F8D9-4E0B-964A-A4CC8161A650@word-to-the-wise.com> From: Steve Atkins To: ARF mailing list In-Reply-To: <4AC105B3.9080600@tana.it> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 28 Sep 2009 12:19:32 -0700 References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> <4ABF44A0.8010104@tana.it> <4AC0DD0D.30909@cybernothing.org> <4AC105B3.9080600@tana.it> X-Mailer: Apple Mail (2.936) X-Virus-Scanned: ClamAV 0.92/9845/Mon Sep 28 10:02:17 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 28 Sep 2009 12:19:39 -0700 (PDT) Subject: Re: [feedback-report] reality check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 19:19:39 -0000 On Sep 28, 2009, at 11:51 AM, Alessandro Vesely wrote: > > How can you say there's no size problem? If I set up an FBL > subscription page (either on my own or using a 3rd party as above) and > then encourage my few users to submit abuse reports to me, what are > the probabilities that an ISP responsible for the origin of the > abusive message has happened to subscribe to the FBL of my tiny > server? I'd guess ~0.0%. > > The other way around, what is the number of FBLs that a new mail site > should subscribe to, if every other mail site already has one? I think what you're saying is that you don't believe you're a source of enough data or valuable enough data that anyone else is going to be interested in it. I think you're right. One of the big advantages of FBLs from large ISPs is that they provide a volume of data that is high enough that you can derive signal out of the noise. If you're so small that a recipient may receive just one report from you, then there's no mechanical way to distinguish whether that's signal or that's noise. One obvious thing would be for you and a bunch of other tiny mailbox providers to gang together to offer a FBL large enough that the data may be relevant. That leads to the other problem, though. With existing FBLs it's usually very, very well-defined what a report means and what action is expected by the recipient of the report. Unless your co-operative of tiny ISPs were to enforce identical standards across all your members you'd end up with the situation where it wasn't clear what any particular report meant, meaning they'll likely not have much attention paid to them, as it'll be impossible to mechanically pull any signal out of the noise. Unless you think you can manage and enforce that sort of a setup then you're best not providing a FBL and simply sending hand written reports. Note also that any situation where you have ISPs sending unsolicited reports directly to senders, without any sort of agreement in place, is going to lead to the same sort of data consistency problems as a badly run co-op. Lots of noise, hard to identify any signal. Cheers, Steve Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8SIpWQ6011240 for ; Mon, 28 Sep 2009 11:51:38 -0700 Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Mon, 28 Sep 2009 20:51:31 +0200 id 00000000005DC030.000000004AC105B3.00000CA0 Message-ID: <4AC105B3.9080600@tana.it> Date: Mon, 28 Sep 2009 20:51:31 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ARF mailing list References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> <4ABF44A0.8010104@tana.it> <4AC0DD0D.30909@cybernothing.org> In-Reply-To: <4AC0DD0D.30909@cybernothing.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9845/Mon Sep 28 10:02:17 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 28 Sep 2009 11:51:38 -0700 (PDT) Subject: Re: [feedback-report] reality check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 18:51:38 -0000 IMHO, many of these infos on ARF's usage deserve being collected in some document. I thought they could go together with the address where ARF reports should be sent, as they are similar. J.D. Falk wrote: >> I should send [a manually composed] complaint to >> abuse@(new ISP) but not use ARF in that case, correct? > > The scenario you've described sounds more appropriate for a direct > conversation with the ISP, rather than an automated report via an automated > channel. ARF was never intended to replace human-to-human interaction. I'll take that as 'yes'. Thanks for confirming it. >> Users send abuse reports to their postmasters. Abusive messages >> submitted within the same mail domain feed the bucket for (1). >> Otherwise, a postmaster might just forward the report to any FBL >> subscribers. This solution is apparently non-scalable, as only giant >> ISPs have FBLs. > > I'm not aware of any complaint feedback loop operating today in which a > postmaster manually forwards complaints to all feedback subscribers. Nor I. I didn't mean _manually_ in that paragraph, except for users. > It's true that the larger ISPs were faster to implement complaint feedback > systems, but that's due more to available resources than anything inherent > to size. > > I work on a product which handles this process for many ISPs: > > http://www.returnpath.net/internetserviceprovider/feedback/ How can you say there's no size problem? If I set up an FBL subscription page (either on my own or using a 3rd party as above) and then encourage my few users to submit abuse reports to me, what are the probabilities that an ISP responsible for the origin of the abusive message has happened to subscribe to the FBL of my tiny server? I'd guess ~0.0%. The other way around, what is the number of FBLs that a new mail site should subscribe to, if every other mail site already has one? Am I missing something? > Please, Alessandro, let go of your preconceived notions of how abuse desks > could work and listen to what we're saying about how ARF is implemented. > It's not that complicated. The only preconceived notion I have is that ARF should work for any SMTP server who wants to use it. I'm just trying to understand how. Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8SHIVBg006450 for ; Mon, 28 Sep 2009 10:18:36 -0700 Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id DEFCB4F81C5 for ; Mon, 28 Sep 2009 10:18:26 -0700 (PDT) Message-Id: <05E47A06-8E4E-4891-8B7B-C289BF7C2C79@word-to-the-wise.com> From: Steve Atkins To: ARF mailing list In-Reply-To: <4AC0EBC6.7020702@corp.aol.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 28 Sep 2009 10:18:26 -0700 References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> <4ABF44A0.8010104@tana.it> <4AC0DD0D.30909@cybernothing.org> <4AC0EBC6.7020702@corp.aol.com> X-Mailer: Apple Mail (2.936) X-Virus-Scanned: ClamAV 0.92/9843/Sun Sep 27 19:23:36 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 28 Sep 2009 10:18:36 -0700 (PDT) Subject: Re: [feedback-report] reality check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 17:18:36 -0000 On Sep 28, 2009, at 10:00 AM, Michael Adkins wrote: > "I suggested that same idea years ago, but it didn't catch on. I'm not > aware of any network provider with either huamn staff or automated > systems which forward individual complaints (ARF or otherwise) to > their > customers. Instead, a number of services have cropped up which will > process ARF messages in order to provide aggregate reports on > potential > problem areas." > > The only one I know of is Level 3, who request reports about their > entire ip space and then forward them on the appropriate customer. There are others. I know several Abacus users use it to automatically forward reports (ARF and otherwise) on to some subset of their customers (typically those that have demonstrated that they can handle the abuse issues of their customers well) automatically. And I occasionally get FBL reports about my (tiny) network space forwarded on to me from my provider, apparently mechanically. Works pretty well, as it allows the network provider to maintain stats about issues at their customers with very little overhead, while allowing those customers to handle their abuse issues themselves. It's not something you can do for many ISP FBLs targeting bulk mailers, though, as the contract you need to agree to while signing up for the FBL tends to include terms that you cannot commit to unless you handle all the reports yourself. That's a contractual problem, though, more than an operational one, I suspect. Cheers, Steve Received: from omr-d34.mx.aol.com (omr-d34.mx.aol.com [205.188.249.132]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8SH14lM005286 for ; Mon, 28 Sep 2009 10:01:09 -0700 Received: from AOLDTCMEH01.ad.office.aol.com (aoldtcmeh01.office.aol.com [10.180.121.20]) by omr-d34.mx.aol.com (v117.7) with ESMTP id MAILOMRD345-7e644ac0ebc6271; Mon, 28 Sep 2009 13:00:54 -0400 Received: from AOLMTCMEI04.ad.office.aol.com ([10.178.3.24]) by AOLDTCMEH01.ad.office.aol.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 13:00:55 -0400 Received: from [10.181.80.41] ([10.178.3.11]) by AOLMTCMEI04.ad.office.aol.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 13:00:54 -0400 Message-ID: <4AC0EBC6.7020702@corp.aol.com> Date: Mon, 28 Sep 2009 13:00:54 -0400 From: Michael Adkins User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "J.D. Falk" References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> <4ABF44A0.8010104@tana.it> <4AC0DD0D.30909@cybernothing.org> In-Reply-To: <4AC0DD0D.30909@cybernothing.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Sep 2009 17:00:54.0527 (UTC) FILETIME=[3DBAD0F0:01CA405D] X-AOL-IP: 10.180.121.20 X-Virus-Scanned: ClamAV 0.92/9843/Sun Sep 27 19:23:36 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 28 Sep 2009 10:01:09 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] reality check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 17:01:09 -0000 "I suggested that same idea years ago, but it didn't catch on. I'm not aware of any network provider with either huamn staff or automated systems which forward individual complaints (ARF or otherwise) to their customers. Instead, a number of services have cropped up which will process ARF messages in order to provide aggregate reports on potential problem areas." The only one I know of is Level 3, who request reports about their entire ip space and then forward them on the appropriate customer. J.D. Falk wrote: > Alessandro Vesely wrote: > > >> If I've got it right, I should never use ARF after carrying out any >> investigation. For example, suppose I've found a link to a previous >> conviction against the spam sender, that might convince their new >> ISP to terminate their account: I should send that complaint to >> abuse@(new ISP) but not use ARF in that case, correct? >> > > The scenario you've described sounds more appropriate for a direct > conversation with the ISP, rather than an automated report via an automated > channel. ARF was never intended to replace human-to-human interaction. > > >> Users send abuse reports to their postmasters. Abusive messages >> submitted within the same mail domain feed the bucket for (1). >> Otherwise, a postmaster might just forward the report to any FBL >> subscribers. This solution is apparently non-scalable, as only giant >> ISPs have FBLs. >> > > I'm not aware of any complaint feedback loop operating today in which a > postmaster manually forwards complaints to all feedback subscribers. > Instead, it's an automated process whereby approved subscribers receive > complaints about messages originating from their own IP ranges, without any > manual interaction. Nearly all of these use ARF. > > It's true that the larger ISPs were faster to implement complaint feedback > systems, but that's due more to available resources than anything inherent > to size. > > I work on a product which handles this process for many ISPs: > > http://www.returnpath.net/internetserviceprovider/feedback/ > > (I mention this not to advertise the product, but rather as additional > insight into the current state of the industry.) > > >> Beyond FBLs, postmasters may forward reports to the relevant network >> providers (NP). Abusix, for one, proposes first level RIR's >> assignments as targets. >> > > Abusix's implementation decisions are fairly unique. > > >> That way (2) is possible. In order to make >> (1) possible, we must presume that an NP forwards each report down >> to further level assignments until it reaches the mailbox provider. >> > > I suggested that same idea years ago, but it didn't catch on. I'm not aware > of any network provider with either huamn staff or automated systems which > forward individual complaints (ARF or otherwise) to their customers. > Instead, a number of services have cropped up which will process ARF > messages in order to provide aggregate reports on potential problem areas. > > Please, Alessandro, let go of your preconceived notions of how abuse desks > could work and listen to what we're saying about how ARF is implemented. > It's not that complicated. > > Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8SFwDtl001339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 28 Sep 2009 08:58:19 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@cybernothing.org Received: from rpco-jdmacbook.rpcorp.local (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id n8SFwA5A006810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 28 Sep 2009 09:58:12 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net n8SFwA5A006810 Message-ID: <4AC0DD0D.30909@cybernothing.org> Date: Mon, 28 Sep 2009 09:58:05 -0600 From: "J.D. Falk" User-Agent: Postbox 1.0b16 (Macintosh/2009090218) MIME-Version: 1.0 To: ARF mailing list References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> <4ABF44A0.8010104@tana.it> In-Reply-To: <4ABF44A0.8010104@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9843/Sun Sep 27 19:23:36 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 28 Sep 2009 08:58:19 -0700 (PDT) Subject: Re: [feedback-report] reality check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 15:58:19 -0000 Alessandro Vesely wrote: > If I've got it right, I should never use ARF after carrying out any > investigation. For example, suppose I've found a link to a previous > conviction against the spam sender, that might convince their new > ISP to terminate their account: I should send that complaint to > abuse@(new ISP) but not use ARF in that case, correct? The scenario you've described sounds more appropriate for a direct conversation with the ISP, rather than an automated report via an automated channel. ARF was never intended to replace human-to-human interaction. > Users send abuse reports to their postmasters. Abusive messages > submitted within the same mail domain feed the bucket for (1). > Otherwise, a postmaster might just forward the report to any FBL > subscribers. This solution is apparently non-scalable, as only giant > ISPs have FBLs. I'm not aware of any complaint feedback loop operating today in which a postmaster manually forwards complaints to all feedback subscribers. Instead, it's an automated process whereby approved subscribers receive complaints about messages originating from their own IP ranges, without any manual interaction. Nearly all of these use ARF. It's true that the larger ISPs were faster to implement complaint feedback systems, but that's due more to available resources than anything inherent to size. I work on a product which handles this process for many ISPs: http://www.returnpath.net/internetserviceprovider/feedback/ (I mention this not to advertise the product, but rather as additional insight into the current state of the industry.) > Beyond FBLs, postmasters may forward reports to the relevant network > providers (NP). Abusix, for one, proposes first level RIR's > assignments as targets. Abusix's implementation decisions are fairly unique. > That way (2) is possible. In order to make > (1) possible, we must presume that an NP forwards each report down > to further level assignments until it reaches the mailbox provider. I suggested that same idea years ago, but it didn't catch on. I'm not aware of any network provider with either huamn staff or automated systems which forward individual complaints (ARF or otherwise) to their customers. Instead, a number of services have cropped up which will process ARF messages in order to provide aggregate reports on potential problem areas. Please, Alessandro, let go of your preconceived notions of how abuse desks could work and listen to what we're saying about how ARF is implemented. It's not that complicated. -- J.D. Falk Return Path Inc http://www.returnpath.net/ Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8SFg7YB000395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 28 Sep 2009 08:42:13 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@cybernothing.org Received: from rpco-jdmacbook.rpcorp.local (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id n8SFg4tu006526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 28 Sep 2009 09:42:06 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net n8SFg4tu006526 Message-ID: <4AC0D946.5060203@cybernothing.org> Date: Mon, 28 Sep 2009 09:41:58 -0600 From: "J.D. Falk" User-Agent: Postbox 1.0b16 (Macintosh/2009090218) MIME-Version: 1.0 To: "abuse-feedback-report@mipassoc.org" References: <4ABDEA27.4000105@tana.it> In-Reply-To: <4ABDEA27.4000105@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9843/Sun Sep 27 19:23:36 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 28 Sep 2009 08:42:13 -0700 (PDT) Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 15:42:14 -0000 Alessandro Vesely wrote: > I would replace "ISPs" with the more specific "mailbox providers". ARF is generated by (or on behalf of) mailbox providers, and then consumed by (or on behalf of) a fairly wide variety of email senders, including: - fellow mailbox providers - access providers ranging from dialup to backbones - commercial senders - non-commercial senders - educational institutions - hobbyists - spammers (I'm not saying it's right, just saying it happens) There are many millions of ARF messages transferred every day, and once we've got the WG started I'll propose editing the draft to indicate this. (I'll also get a more accurate estimate.) > The user should be able to write or modify the human readable part > of the report. I envisage the MUA button as popping up a dialog > asking such questions as Vanishingly few (if any) of the ARF messages transferred today include any text supplied by the end user who initiated the complaint. Few ARF messages are processed by humans at any stage. But more importantly, this list of questions doesn't seem appropriate for a standards project. The developer of a particular tool may wish to include them, and that's fine -- every MUA is different -- but it isn't (and shouldn't be) required by an RFC. -- J.D. Falk Return Path Inc http://www.returnpath.net/ Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8RAtI2Z020631 for ; Sun, 27 Sep 2009 03:55:23 -0700 Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Sun, 27 Sep 2009 12:55:10 +0200 id 00000000005DC030.000000004ABF448E.00007B21 Message-ID: <4ABF44A0.8010104@tana.it> Date: Sun, 27 Sep 2009 12:55:28 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: ARF mailing list References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> In-Reply-To: <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9841/Sat Sep 26 19:04:45 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sun, 27 Sep 2009 03:55:24 -0700 (PDT) Subject: Re: [feedback-report] reality check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 10:55:26 -0000 Steve Atkins wrote: >> If [an interactive report-spam process] asks no questions, how can it compile a "good" report? >> Who is going to read the human readable part? > > People who wish to receive FBL reports, yet who don't receive > a high enough volume for them to need to automate handling > them. Does that imply that the human readable part of an ARF report should only consist of boilerplate text, much like MIME preambles? >> Reports sent to abuse desks most often involve further interaction, > > I don't recall seeing such a thing more than a few times in years, > and never in response to a "typical" abuse report and certainly > not in response to the sort of report that's intended to be handled > mechanically, which is the target for ARF. If I've got it right, I should never use ARF after carrying out any investigation. For example, suppose I've found a link to a previous conviction against the spam sender, that might convince their new ISP to terminate their account: I should send that complaint to abuse@(new ISP) but not use ARF in that case, correct? Possibly, auto-responders for abuse mailboxes should only be fired on non-ARF messages. And ARF reports should have an empty MAIL FROM, and/or an "Auto-Submitted: auto-generated" header. The current draft doesn't make any such considerations. > If the report doesn't include all the information needed to triage > and handle it without further interaction with the reporter then > it's not a good candidate for automated report handling, and > not really relevant to ARF. Fine. Even if that implies a one-way flow of information, and thus leaves little room for semi-automated cooperative processing, it seems consistent to me, now that you have explained it in deeper detail. Let me check I've got the picture correctly: Tentatively, abuse reports may eventually result in 0) dispute on whether the reported abusive message is really such, 1) administrative actions by the relevant mailbox provider, ranging from admonition to account termination, 2) similar actions by network providers (or registrars?) against the mailbox providers who failed to take the actions in (1), 3) blacklisting, or removal from whitelists, of the relevant IPs or registered domains, 4) possible legal actions. Users send abuse reports to their postmasters. Abusive messages submitted within the same mail domain feed the bucket for (1). Otherwise, a postmaster might just forward the report to any FBL subscribers. This solution is apparently non-scalable, as only giant ISPs have FBLs. Beyond FBLs, postmasters may forward reports to the relevant network providers (NP). Abusix, for one, proposes first level RIR's assignments as targets. That way (2) is possible. In order to make (1) possible, we must presume that an NP forwards each report down to further level assignments until it reaches the mailbox provider. Eager postmasters may do that themselves directly, but not blindly. In some circumstances, the report might be further forwarded to the original sender, to allow for (0). Each recipient can triage on its own, while forwarding single messages. That way, a reasonable timeliness can be obtained, while each downstream recipient can reckon the count accumulated by its sender, and guess when the next admonition is likely to occur; the current incidents count may also be written inside the report, for checking --that's not what the "Incidents" field is apparently for. To avoid duplicates or failures, it should be clarified whether postmasters should send directly to multiple NPs rather than rely on each NP to forward in turn. IOW, whose behavior is better, Abusix or eager postmasters? Whether to send a report to the mail domain where the abusive message was submitted, or DKIM signed, may be decided using the same heuristics as for accepting FBL subscriptions. That may involve lengthy processes, such as requiring NP's approval by email, whose results deserve being cached. The "eager postmasters" approach resembles an FBL with auto-subscription. Furthermore, if the abusive message had VBR credentials, the report's destinations should include the relevant vouching services, in addition to the network and mailbox providers: A future version of (3) --for a limited scope of (3), postmasters who maintain local black/whitelists may update them after users' reports. (4) is obviously fully manual and hence out of ARF's scope, but ARF reports might be supplied as evidence. Is the above correct? (I note that this one-way functioning is quite different from the cooperative model devised in INCH.) What for errors or disputes? We should subtract 1 from all the involved counters in case of a message erroneously reported as spam. Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8QIV35B003668 for ; Sat, 26 Sep 2009 11:31:08 -0700 Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 9BF834F8133 for ; Sat, 26 Sep 2009 11:31:03 -0700 (PDT) Message-Id: <3EB4B8E5-7F6E-452F-BBDE-F2D4494C78AC@word-to-the-wise.com> From: Steve Atkins To: ARF mailing list In-Reply-To: <4ABE5052.7050307@tana.it> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 26 Sep 2009 11:31:03 -0700 References: <4ABDEA27.4000105@tana.it> <4ABE5052.7050307@tana.it> X-Mailer: Apple Mail (2.936) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sat, 26 Sep 2009 11:31:08 -0700 (PDT) Subject: Re: [feedback-report] reality check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2009 18:31:09 -0000 On Sep 26, 2009, at 10:33 AM, Alessandro Vesely wrote: > John R. Levine wrote: >> On Sat, 26 Sep 2009, Alessandro Vesely wrote: >>> The user should be able to write or modify the human readable part >>> of the >>> report. I envisage the MUA button as popping up a dialog asking such >>> questions as >>> >>> * Did the user manually examine the body of the message? >>> * Does the user understand SMTP? >>> * Does the user believe the From address is true? >>> * Did the user examine the headers of the message? >>> * Does the user believe the Return-Path, if any, is true? >> >> Just for reference, have you ever used any of the existing MUA spam >> buttons? > > Never, as you probably already guessed. Are you a recipient of a feedback loop of any sort? If so, how do you handle and respond to inbound reports right now? > >> How many questions did it ask? > > If it asks no questions, how can it compile a "good" report? Who is > going to read the human readable part? People who wish to receive FBL reports, yet who don't receive a high enough volume for them to need to automate handling them. > > Reports sent to abuse desks most often involve further interaction, I don't recall seeing such a thing more than a few times in years, and never in response to a "typical" abuse report and certainly not in response to the sort of report that's intended to be handled mechanically, which is the target for ARF. If the report doesn't include all the information needed to triage and handle it without further interaction with the reporter then it's not a good candidate for automated report handling, and not really relevant to ARF. > messages tagged with an incident number. Should that be directed to > the user who originated the report? IOW, the user's mailbox provider > forwards the message as a service done _on behalf_ of the user? None of the above, in general. Cheers, Steve Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8QHX7qn000830 for ; Sat, 26 Sep 2009 10:33:13 -0700 Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Sat, 26 Sep 2009 19:33:07 +0200 id 00000000005DC031.000000004ABE5053.000037B0 Message-ID: <4ABE5052.7050307@tana.it> Date: Sat, 26 Sep 2009 19:33:06 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "John R. Levine" References: <4ABDEA27.4000105@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sat, 26 Sep 2009 10:33:13 -0700 (PDT) Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] reality check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2009 17:33:15 -0000 John R. Levine wrote: > On Sat, 26 Sep 2009, Alessandro Vesely wrote: >> The user should be able to write or modify the human readable part of the >> report. I envisage the MUA button as popping up a dialog asking such >> questions as >> >> * Did the user manually examine the body of the message? >> * Does the user understand SMTP? >> * Does the user believe the From address is true? >> * Did the user examine the headers of the message? >> * Does the user believe the Return-Path, if any, is true? > > Just for reference, have you ever used any of the existing MUA spam > buttons? Never, as you probably already guessed. > How many questions did it ask? If it asks no questions, how can it compile a "good" report? Who is going to read the human readable part? Reports sent to abuse desks most often involve further interaction, messages tagged with an incident number. Should that be directed to the user who originated the report? IOW, the user's mailbox provider forwards the message as a service done _on behalf_ of the user? Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8QCVaqR015436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 26 Sep 2009 05:31:42 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 18735 invoked from network); 26 Sep 2009 12:31:34 -0000 Received: (ofmipd 208.31.42.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Sep 2009 12:31:11 -0000 Date: 26 Sep 2009 08:31:32 -0400 Message-ID: From: "John R. Levine" To: "Alessandro Vesely" In-Reply-To: <4ABDEA27.4000105@tana.it> References: <4ABDEA27.4000105@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 X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sat, 26 Sep 2009 05:31:42 -0700 (PDT) Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] reality check, was Revised draft charter X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2009 12:31:43 -0000 On Sat, 26 Sep 2009, Alessandro Vesely wrote: > The user should be able to write or modify the human readable part of the > report. I envisage the MUA button as popping up a dialog asking such > questions as > > * Did the user manually examine the body of the message? > * Does the user understand SMTP? > * Does the user believe the From address is true? > * Did the user examine the headers of the message? > * Does the user believe the Return-Path, if any, is true? Just for reference, have you ever used any of the existing MUA spam buttons? How many questions did it ask? R's, John Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8QAwPDC010362 for ; Sat, 26 Sep 2009 03:58:30 -0700 Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Sat, 26 Sep 2009 12:16:55 +0200 id 00000000005DC031.000000004ABDEA17.00000978 Message-ID: <4ABDEA27.4000105@tana.it> Date: Sat, 26 Sep 2009 12:17:11 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "John R. Levine" , "Murray S. Kucherawy" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Delayed for 00:41:28 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sat, 26 Sep 2009 03:58:30 -0700 (PDT) Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2009 10:58:31 -0000 John R. Levine wrote: >> Attached is the proposed charter, modified as discussed. Do we have consensus that this is the way we want to go? >> >> Feel free to propose other wording if you have some feedback other than a "+1". +1, with two alternative wordings and one mumbling: * In the third paragraph ARF as initially defined is already in widespread use at large ISPs, so interoperability can be demonstrated. I would replace "ISPs" with the more specific "mailbox providers". * In the extension list, non-message extensions (c), (d), (e), and (h) might be merged in a single entry, if we plan to address them in a similar fashion. A possible wording might be x) non-SMTP attacks, including SSH, FTP, and web, and DDoS reports For the mumbling, about point 4, in the "abuse@(domain)" standard it is not plainly obvious to an average postmaster how to determine the target domain so as to avoid sending reports to the black hats. In case the WG will conclude that the industry should continue to use that standard, will the required guidelines be assumed to belong to an eventual rfc2142-bis? In any case, ARF extensions (e.g. DKIM) may define their own means and provide guidelines to specify or suggest the target(s) for the corresponding ARF reports. I'm not sure whether it's worth mentioning this in the charter's description. > I can live with it the way it is, but for point 4 if we're going to help > automate ARF reports, it's at least as important to invent some way for an > MUA junk button to report a message back to the user's ISP. This could be > as simple as a header with an address or as baroque as added options in > DHCP, POP, IMAP, and SUBMIT. +1, and I like the simple option: using abuse@(domain) even the extra header becomes unnecessary. The user should be able to write or modify the human readable part of the report. I envisage the MUA button as popping up a dialog asking such questions as * Did the user manually examine the body of the message? * Does the user understand SMTP? * Does the user believe the From address is true? * Did the user examine the headers of the message? * Does the user believe the Return-Path, if any, is true? Assuming that the report will be sent to the user's mailbox provider, they may be able to forward it without further inspection depending on user's answers to those questions. In general, if the report is going to be forwarded through a trusted chain, wouldn't it be a waste of time to manually examine it multiple times? Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8PHWQqt014214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 25 Sep 2009 10:32:32 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@cybernothing.org Received: from rpco-jdmacbook.rpcorp.local (np45.co.returnpath.net [38.109.196.45]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id n8PGuMus007761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 25 Sep 2009 10:56:24 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net n8PGuMus007761 Message-ID: <4ABCF631.1020207@cybernothing.org> Date: Fri, 25 Sep 2009 10:56:17 -0600 From: "J.D. Falk" User-Agent: Postbox 1.0b16 (Macintosh/2009090218) MIME-Version: 1.0 To: "abuse-feedback-report@mipassoc.org" References: <501c18e00909211910u20f885cal8226831f6c60af5e@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Delayed for 00:36:01 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 25 Sep 2009 10:32:32 -0700 (PDT) Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 17:32:32 -0000 John R. Levine wrote: >> So if I were to rework the deliverables, effectively swapping (1) and (2) from the current draft charter, it sounds like that would make everyone happy. Specifically, we would push to get ARF finalized as minimally as possible (maybe even removing some stuff) and then work on the suggested list of things, including the DKIM stuff, as extensions. >> >> Do I hear any "+1"s? > > +1 +1 > Unlike a lot of IETF standardization efforts, ARF is already in wide use > with rough consensus on the current format. > > Hence it would be a good idea to document what its many users do now > before blowing it up and hoping they like the changes. +1 -- J.D. Falk Return Path Inc http://www.returnpath.net/ Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8OMXUWq006764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Sep 2009 15:33:35 -0700 Received: from sjc-office-nat-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 24D01A9444C; Thu, 24 Sep 2009 22:33:28 +0000 (UTC) Message-ID: <4ABBF3B7.8000807@mail-abuse.org> Date: Thu, 24 Sep 2009 15:33:27 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <501c18e00909211910u20f885cal8226831f6c60af5e@mail.gmail.com> <4ABAC5DC.8000501@mail-abuse.org> <4ABB1568.9000600@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 24 Sep 2009 15:33:35 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 22:33:35 -0000 On 9/24/09 10:51 AM, Murray S. Kucherawy wrote: >> Both automatic filtering OR reports generated by users pressing a >> "junk" or "spam" button should not be considered reliable >> categorization methods. Even email sent to honeypots still need to >> be automatically filtered into categories like "abuse/spam", >> "fraud/phish", "opt-out", "virus/malware" and >> "not-spam/NDN/auto-response". >> >> [...] >> >> The ARF report offers email providers a means to view samplings of >> the problems their customer's systems create. It would be a bad >> practice for providers to react to ARF reports without their visual >> review. It would also be a bad practice to report any and all >> email that can be categorized by an ARF report. Still, providers >> of email should ensure ARF reports are visually reviewed before >> actions are taken. > > By extension, DSNs shouldn't be parsed by software to use when > determining whether or not to remove a bouncing address from a > mailing list, yet this is somewhat common practice. I've not heard > this in widespread use as an attack vector. The concern was not about how to deal with DSNs where recipients of a DSN (such as a mailing list) can confirm it was in response to their message. There are immediate methods to ensure against DSN spoofing, while there is also little incentive to send spoofed DSNs to some third party, which could be why this is not a problem. Again, the concern was about altering accounts based upon ARF reports when the nature of the message had not been visually verified. It is not unusual for those generating ARF reports to lack a means to detect spoofed messages that would be afforded the natural recipient of a DSNs. And, unlike DSNs, there are significant incentives for spammers to spoof messages normally captured in ARF reports. This type of spoofing often creates multiple levels of indirection with respect to messages found in ARF reports. A spammer may have determined the Mail From and Rcpt To using a dictionary attack against different domains. Their spam will often spoof both of these addresses, where the return address might then receive an auto-response in a language not recognized by filter software run in someone's honeypot generating ARF reports, for example. When it comes to reacting to issues noted indirectly (through an ARF third-party generator), visual inspection of the ARF message remains important. It would be wrong and unfair to justify complacency by comparing ARF reports to DSNs. > If automatic processing is a dangerous goal, then we must also > conclude that DSN was a bad idea in the first place. While the process that produces the ARF report is likely automatic, sorry Steve, recipients of these reports should be encouraged to visually examine the report's message before acting. If not all, at least some of the messages should be reviewed. > So, I have to disagree. Are you saying that ARF reports should _not_ be visually reviewed because mailing list automatically react to DSNs? Do you really think these two mechanisms are directly comparable? -Doug Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8OJbkHQ028469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Sep 2009 12:37:52 -0700 Authentication-Results: sbh17.songbird.com; dkim=neutral header.i=@iecc.com Received: (qmail 89119 invoked from network); 24 Sep 2009 19:37:46 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 24 Sep 2009 19:37:46 -0000 Date: Thu, 24 Sep 2009 15:37:45 -0400 (EDT) From: "John R. Levine" To: "Murray S. Kucherawy" In-Reply-To: Message-ID: References: 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 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 24 Sep 2009 12:37:52 -0700 (PDT) Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 19:37:52 -0000 > Attached is the proposed charter, modified as discussed. Do we have consensus that this is the way we want to go? > > Feel free to propose other wording if you have some feedback other than a "+1". I can live with it the way it is, but for point 4 if we're going to help automate ARF reports, it's at least as important to invent some way for an MUA junk button to report a message back to the user's ISP. This could be as simple as a header with an adddress or as baroque as added options in DHCP, POP, IMAP, and SUBMIT. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8OIlCmF025114 for ; Thu, 24 Sep 2009 11:47:18 -0700 Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 65C64802A4 for ; Thu, 24 Sep 2009 11:47:12 -0700 (PDT) Message-Id: From: Steve Atkins To: ARF mailing list In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 24 Sep 2009 11:47:10 -0700 References: X-Mailer: Apple Mail (2.936) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 24 Sep 2009 11:47:18 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n8OIlCmF025114 Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 18:47:18 -0000 On Sep 24, 2009, at 10:55 AM, Murray S. Kucherawy wrote: > Attached is the proposed charter, modified as discussed. Do we have > consensus that this is the way we want to go? > > Feel free to propose other wording if you have some feedback other > than a “+1”. > > (Silence isn’t automatic assent; please speak up!) > > -MSK 1 & 2 look fine to me. 4 is probably OK. But point 3 states that integration of ARF with DKIM records is something that will be done by the group, which I don't think is good. (Not that I think that doing something to report DKIM failures is necessarily a bad idea, it's just not something that should be a fait accompli in the charter. It might be better in the DKIM world than the ARF world too, as that's where the operational experience is.) Cheers, Steve Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8OIQ9Y1023498 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Thu, 24 Sep 2009 11:26:14 -0700 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Thu, 24 Sep 2009 10:55:33 -0700 From: "Murray S. Kucherawy" To: "Murray S. Kucherawy" , "abuse-feedback-report@mipassoc.org" Date: Thu, 24 Sep 2009 10:55:33 -0700 Thread-Topic: [feedback-report] Revised draft charter, call for participation -- Please comment Thread-Index: Aco63efKNIukbSaSRrmQ/hk0dgw0SgCYfe/Q Message-ID: References: In-Reply-To: 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_BB012BD379D7B046ABE1472D8093C61C01AFA273F7EXCHC2corpclo_" MIME-Version: 1.0 X-Greylist: Delayed for 00:30:35 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 24 Sep 2009 11:26:14 -0700 (PDT) Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 18:26:14 -0000 --_004_BB012BD379D7B046ABE1472D8093C61C01AFA273F7EXCHC2corpclo_ Content-Type: multipart/alternative; boundary="_000_BB012BD379D7B046ABE1472D8093C61C01AFA273F7EXCHC2corpclo_" --_000_BB012BD379D7B046ABE1472D8093C61C01AFA273F7EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Attached is the proposed charter, modified as discussed. Do we have consen= sus that this is the way we want to go? Feel free to propose other wording if you have some feedback other than a "= +1". (Silence isn't automatic assent; please speak up!) -MSK --_000_BB012BD379D7B046ABE1472D8093C61C01AFA273F7EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Attached is the proposed charter, modified as discussed.  Do we have consensus that this is the= way we want to go?

 =

Feel free to propose oth= er wording if you have some feedback other than a “+1”.=

 =

(Silence isn’t aut= omatic assent; please speak up!)

 =

-MSK

 =

 

--_000_BB012BD379D7B046ABE1472D8093C61C01AFA273F7EXCHC2corpclo_-- --_004_BB012BD379D7B046ABE1472D8093C61C01AFA273F7EXCHC2corpclo_ Content-Type: text/plain; name="arf-charter v06.txt" Content-Description: arf-charter v06.txt Content-Disposition: attachment; filename="arf-charter v06.txt"; size=6089; creation-date="Thu, 24 Sep 2009 10:46:47 GMT"; modification-date="Thu, 24 Sep 2009 10:48:11 GMT" Content-Transfer-Encoding: base64 ICAgV29ya2luZyBHcm91cCBOYW1lOg0KICAgICAgICBBYnVzZSBSZXBvcnRpbmcgRm9ybWF0IChB UkYpDQoNCiAgIElFVEYgQXJlYToNCiAgICAgICAgQXBwbGljYXRpb25zIEFyZWENCg0KICAgQ2hh aXIocyk6DQogICAgICAgIFRCRA0KDQogICBBcHBsaWNhdGlvbnMgQXJlYSBEaXJlY3RvcihzKToN CiAgICAgICAgTGlzYSBEdXNzZWF1bHQgPExpc2EuRHVzc2VhdWx0QG1lc3NhZ2luZ2FyY2hpdGVj dHMuY29tPg0KICAgICAgICBBbGV4ZXkgTWVsbmlrb3YgPGFsZXhleS5tZWxuaWtvdkBpc29kZS5j b20+DQoNCiAgIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3I6DQogICAgICAgIFRCRA0KDQogICBN YWlsaW5nIExpc3RzOg0KICAgICAgICBHZW5lcmFsIERpc2N1c3Npb246IGFidXNlLWZlZWRiYWNr LXJlcG9ydEBtaXBhc3NvYy5vcmcNCiAgICAgICAgVG8gU3Vic2NyaWJlOiBodHRwOi8vbWlwYXNz b2Mub3JnL21haWxtYW4vbGlzdGluZm8vYWJ1c2UtZmVlZGJhY2stcmVwb3J0DQogICAgICAgIEFy Y2hpdmU6IGh0dHA6Ly9taXBhc3NvYy5vcmcvbWFpbG1hbi9saXN0aW5mby9hYnVzZS1mZWVkYmFj ay1yZXBvcnQNCg0KICAgRGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cDoNCglNZXNzYWdpbmcg YW50aS1hYnVzZSBvcGVyYXRpb25zIGJldHdlZW4gaW5kZXBlbmRlbnQgc2VydmljZXMgb2Z0ZW4g cmVxdWlyZXMNCglzZW5kaW5nIHJlcG9ydHMgb24gb2JzZXJ2ZWQgZnJhdWQsIHNwYW0gdmlydXMg b3Igb3RoZXIgYWJ1c2UgYWN0aXZpdHkuICBBDQoJc3RhbmRhcmRpemVkIHJlcG9ydCBmb3JtYXQg ZW5hYmxlcyBhdXRvbWF0ZWQgcHJvY2Vzc2luZy4gIFRoZSBBYnVzZSBSZXBvcnRpbmcNCglGb3Jt YXQgKEFSRikgc3BlY2lmaWNhdGlvbiBoYXMgZ2FpbmVkIHN1ZmZpY2llbnQgcG9wdWxhcml0eSB0 byB3YXJyYW50IGZvcm1hbA0KCWNvZGlmaWNhdGlvbiwgdG8gZW5zdXJlIGFuZCBlbmNvdXJhZ2Ug ZnV0dXJlIGludGVyb3BlcmFiaWxpdHkgd2l0aCBuZXcNCglpbXBsZW1lbnRhdGlvbnMuICBUaGUg cHJpbWFyeSBmdW5jdGlvbiBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBiZSB0byBzb2xpY2l0 DQoJcmV2aWV3IGFuZCByZWZpbmVtZW50IG9mIHRoZSBleGlzdGluZyBzcGVjaWZpY2F0aW9uLg0K DQoJQVJGIHdhcyBkZXZlbG9wZWQgYnkgYSBtZXNzYWdpbmcgdHJhZGUgb3JnYW5pemF0aW9uIGlu ZGVwZW5kZW50IG9mIHRoZSBJRVRGLA0KCWFuZCB1c2VzIGEgZm9ybWF0IHNpbWlsYXIgdG8gYSBE ZWxpdmVyeSBTdGF0dXMgTm90aWZpY2F0aW9uIChEU04sIFJGQzM0NjQpDQoJdG8gcmVwb3J0IGZy YXVkLCBzcGFtLCB2aXJ1c2VzIG9yIG90aGVyIGFidXNpdmUgYWN0aXZpdHkgaW4gdGhlIGVtYWls IHN5c3RlbS4NCglUaGUgYmFzaWMgZm9ybWF0IGlzIGFtZW5hYmxlIHRvIHByb2Nlc3NpbmcgYnkg aHVtYW5zIG9yIHNvZnR3YXJlLCB3aXRoIHRoZQ0KCWxhdHRlciByZXF1aXJpbmcgdGhlIGZvcm1h dCB0byBiZSBzdGFuZGFyZGl6ZWQsIHRvIHBlcm1pdCBpbnRlcm9wZXJhYmlsaXR5DQoJYmV0d2Vl biBhdXRvbWF0ZWQgc2VydmljZXMsIHBhcnRpY3VsYXJseSB3aXRob3V0IHByaW9yIGFycmFuZ2Vt ZW50Lg0KDQoJQVJGIGFzIGluaXRpYWxseSBkZWZpbmVkIGlzIGFscmVhZHkgaW4gd2lkZXNwcmVh ZCB1c2UgYXQgbGFyZ2UgSVNQcywgc28NCglpbnRlcm9wZXJhYmlsaXR5IGNhbiBiZSBkZW1vbnN0 cmF0ZWQuICBTb21lIHRvb2xzIGFscmVhZHkgZXhpc3QNCglmb3IgcHJvY2Vzc2luZyBBUkYgbWVz c2FnZXMsIGEgZmV3IG9mIHdoaWNoIGFyZSBvcGVuIHNvdXJjZS4gIEluIG9yZGVyIHRvDQoJcHJl c2VydmUgdGhlIGluc3RhbGxlZCBiYXNlLCB0aGUgd29ya2luZyBncm91cCB3aWxsIG1ha2UgdGhl IG1pbmltdW0gY2hhbmdlcw0KCW5lY2Vzc2FyeSB0byB0aGUgZXhpc3Rpbmcgc3BlY2lmaWNhdGlv biBhbmQgd2lsbCBzZWVrIHRvIGhhdmUgYmFja3dhcmQNCgljb21wYXRpYmlsaXR5LiAgRnVydGhl cm1vcmUsIHNvbWUgZXh0ZW5zaW9ucyB0byB0aGUgY3VycmVudCBwcm9wb3NhbCBhcmUNCglvZiBp bnRlcmVzdCB0byB0aGUgY29tbXVuaXR5LCBzdWNoIGFzIHRoZSBtZWFucyBmb3IgYW4gb3BlcmF0 b3IgdG8gYWR2ZXJ0aXNlDQoJYW4gZW1haWwgYWRkcmVzcyB0byB3aGljaCBhYnVzZSByZXBvcnRz IHVzaW5nIEFSRiBzaG91bGQgYmUgc2VudC4gIFRoZQ0KCXdvcmtpbmcgZ3JvdXAgd2lsbCB0YWtl IG9uIHRoZSB0YXNrIG9mIGNvbnNpZGVyaW5nIGFuZCBzcGVjaWZ5aW5nIHN1Y2ggYSBtZWNoYW5p c20uDQoNCglUaGUgaW5pdGlhbCBwcm9wb3NhbCBpcyBwdWJsaXNoZWQgYXMgZHJhZnQtc2hhZnJh bm92aWNoLWZlZWRiYWNrLXJlcG9ydCwNCglhbmQgdGhpcyB3aWxsIHByb3ZpZGUgdGhlIHdvcmtp bmcgZ3JvdXAncyBzdGFydGluZyBwb2ludC4NCg0KCVRoZSB3b3JraW5nIGdyb3VwIHNob3VsZCBj b25zaWRlciBzdWNoIGZhY3RvcnMgYXM6DQoJKiBpbXBsZW1lbnRlciBleHBlcmllbmNlDQoJKiBp bnRlcm5hdGlvbmFsaXphdGlvbg0KCSogZXhpc3RpbmcgdXNlcyBvZiBBUkYNCgkqIGFiaWxpdHkg dG8gYWNoaWV2ZSBicm9hZCBpbXBsZW1lbnRhdGlvbiBhbmQgaW50ZXJvcGVyYWJpbGl0eQ0KCSog YWJpbGl0eSB0byBhZGRyZXNzIGJyb2FkZXIgdXNlIGNhc2VzIHRoYW4gbWF5IGhhdmUgYmUgY29u dGVtcGxhdGVkIGJ5IHRoZSBvcmlnaW5hbA0KCSAgYXV0aG9ycw0KCSogb3ZlcmxhcCB3aXRoIHRo ZSBJTkNIIHdvcmtpbmcgZ3JvdXAncyB3b3JrIChlLmcuIFJGQzUwNzApOyBpdCBpcyB1bmNsZWFy IHdoZXRoZXINCgkgIHN1Y2ggb3ZlcmxhcCBpcyBhcHByb3ByaWF0ZSBvciBzaG91bGQgYmUgYXZv aWRlZA0KDQogICAgICAgIFRodXMsIHRoZSB3b3JraW5nIGdyb3VwJ3Mgc3BlY2lmaWMgdGFza3Mg YXJlIGFzIGZvbGxvd3M6DQoNCgkxKSBUaGUgZ3JvdXAgd2lsbCBmaXJzdCBwcm9kdWNlIGEgUHJv cG9zZWQgU3RhbmRhcmQgdHJhY2sgc3BlY2lmaWNhdGlvbiBvZiBBUkYuDQoJICAgVGhpcyB3aWxs IGRvY3VtZW50IGN1cnJlbnQgdXNlLCByZW1vdmluZyBhbnkgcG9ydGlvbnMgdGhhdCBhcmUgbm90 IGltcGxlbWVudGVkIGFuZC9vcg0KCSAgIG5vdCByZXF1aXJlZCBmb3IgYSBtaW5pbXVtIGltcGxl bWVudGF0aW9uICh0byBiZSBwdWJsaXNoZWQgbGF0ZXIgYXMgZXh0ZW5zaW9ucykuDQoJICAgVGhp cyB3aWxsIGluY2x1ZGUgbm90IG9ubHkgdGhlIGZvcm1hdCBvZiBhbiBBUkYgbWVzc2FnZSwgYnV0 IG11c3QgYWxzbyBpbmNsdWRlDQoJICAgYXBwcm9wcmlhdGUgZG9jdW1lbnRhdGlvbiBvZiBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBhbmQgY3JlYXRpb24gb2YgSUFOQSByZWdpc3RyaWVzDQoJICAg Zm9yIGVsZW1lbnRzIG9mIEFSRiB0byBzdXBwb3J0IGZ1dHVyZSBleHRlbnNpb25zLCBhcyB3ZWxs IGFzIGluZm9ybWF0aW9uYWwgc2VjdGlvbnMNCgkgICBjb252ZXlpbmcgY3VycmVudCBiZXN0IHBy YWN0aXNlcy4NCg0KCTIpIFRoZSBmb2xsb3dpbmcgcG9zc2lsYmxlIHJlcG9ydGluZyBleHRlbnNp b25zIGhhdmUgYmVlbiBwcm9wb3NlZCBhbmQgd2lsbCBiZSBjb25zaWRlcmVkDQoJICAgcG9zc2li bGUgZm9yIHB1YmxpY2F0aW9uIGFzIGV4dGVuc2lvbnMgdG8gdGhlIGJhc2Ugc3BlY2lmaWNhdGlv bjoNCg0KCSAgIGEpIGRyb3AgYm94ZXMgKGRldGVjdGlvbiBvZiBhIG1haWxib3ggdXNlZCB0byBy ZWNlaXZlIHRoaW5ncyBsaWtlIHN0b2xlbg0KCSAgICAgIGNyZWRpdCBjYXJkcykNCgkgICBiKSBi b3RuZXQgZGV0ZWN0aW9uIChpLmUuIHJlcG9ydGluZyBvZiB0cmFmZmljIHRoYXQgYXBwZWFycyB0 byBoYXZlIGNvbWUNCgkgICAgICBmcm9tIGEgYm90LCByZWdhcmRsZXNzIG9mIGNvbnRlbnQpDQoJ ICAgYykgU1NIIGF0dGFja3MNCgkgICBkKSBGVFAgYXR0YWNrcw0KCSAgIGUpIFdlYiBzZXJ2ZXIg YXR0YWNrcw0KCSAgIGYpIG1haWwgc2VudCB0byBhIGhvbmV5cG90IG9yIHNwYW0gdHJhcA0KCSAg IGcpIG1hbHdhcmUgY29ubmVjdGlvbnMgdG8gc2lua2hvbGVzDQoJICAgaCkgRERvUyByZXBvcnRz DQoJICAgaSkgcG9ydGlvbnMgb2YgdGhlIHByZS1JRVRGIHZlcmlzb24gb2YgdGhlIHNwZWNpZmlj YXRpb24gdGhhdCB3ZXJlIHJlbW92ZWQgaW4gKDEpDQoJICAgICAgYWJvdmUgdG8gcHJvZHVjZSBh IG1pbmltYWwgYmFzZSBkb2N1bWVudA0KCSAgIGopIG90aGVycyB0aGF0IG1heSBiZSBwcm9wb3Nl ZCB3aXRoaW4gdGhlIGFsbG90dGVkIHRpbWVmcmFtZQ0KDQoJMykgVGhlIGdyb3VwIHdpbGwgc3Bl Y2lmeSB0aGUgaW50ZWdyYXRpb24gb2YgQVJGIGludG8gREtJTSBETlMga2V5IHJlY29yZHMsIHdp dGgNCgkgICBkcmFmdC1rdWNoZXJhd3ktZGtpbS1yZXBvcnRpbmcgYXMgaXRzIGlucHV0LiAgSXQg Y29udGFpbnMgZXh0ZW5zaW9ucw0KCSAgIHRvIERLSU0gdGhhdCBhcmUgcmVsYXRlZCB0byBBUkYg YXMgYSBtZWFucyBvZiByZXBvcnRpbmcgREtJTS1yZWxhdGVkIGZhaWx1cmVzDQoJICAgd2hpY2gg aW5jbHVkZSBwaGlzaGluZyAoImZyYXVkIikgYW5kIGFzIHN1Y2ggYXJlIHJlbGV2YW50IHRvIHRo ZSBBUkYgZWZmb3J0Lg0KCSAgIFRoZSBncm91cCB3aWxsIHByb2R1Y2UgUHJvcG9zZWQgU3RhbmRh cmQgdHJhY2sgc3BlY2lmaWNhdGlvbiBmb3IgdGhlc2UNCgkgICBBUkYgYW5kIERLSU0gZXh0ZW5z aW9ucy4NCg0KCTQpIFRoZSBncm91cCB3aWxsIGZpbmFsbHkgY29uc2lkZXIgYSBtZWFucyBmb3Ig cHVibGlzaGluZyB0aGUgYWRkcmVzcw0KCSAgIHRvIHdoaWNoIEFSRiByZXBvcnRzIHNob3VsZCBi ZSBzZW50LiAgTm90IGFsbCBBUkYgcGFydGljaXBhbnRzIHdpc2ggdG8gdXNlDQoJICAgYWJ1c2VA KGRvbWFpbiksIHdoaWNoIGlzIHRoZSBjdXJyZW50IHN0YW5kYXJkIChSRkMyMTQyKSAsIGFzIHRo ZSBwbGFjZSB0byBzZW5kDQoJICAgYXV0b21hdGVkIEFSRi1mb3JtYXR0ZWQgcmVwb3J0cy4gIFRo ZSBncm91cCB3aWxsIGVpdGhlciBjb25jbHVkZSB0aGF0IHRoZSBpbmR1c3RyeQ0KCSAgIHNob3Vs ZCBjb250aW51ZSB0byB1c2UgdGhpcyBkZSBmYWN0byBzdGFuZGFyZCAoYW5kIHRodXMgbm8gc3Bl Y2lmaWNhdGlvbiBpcyBhcHByb3ByaWF0ZSksDQoJICAgb3Igd2lsbCBwcm9kdWNlIGEgUHJvcG9z ZWQgU3RhbmRhcmQgdHJhY2sgZG9jdW1lbnQgaWRlbnRpZnlpbmcgdGhlIG1lYW5zIGJ5IHdoaWNo DQoJICAgdGhhdCBhZGRyZXNzIHNob3VsZCBiZSBhZHZlcnRpc2VkLg0KDQoJVGhlIGdyb3VwIG1h eSBjb25zaWRlciByZS1jaGFydGVyaW5nIHRvIGNvdmVyIHJlbGF0ZWQgd29yaywgc3VjaCBhcyBm dXJ0aGVyIGV4dGVuc2lvbnMsDQoJb25jZSB0aGVzZSBkZWxpdmVyYWJsZXMgaGF2ZSBiZWVuIGFj aGlldmVkLg0KDQogICBHb2FscyBhbmQgTWlsZXN0b25lczoNCglKYW4gMTAJSXNzdWUgZmlyc3Qg V0ctYmFzZWQgSW50ZXJuZXQtRHJhZnQgZGVmaW5pbmcgQVJGDQoJTWFyIDEwCUFjaGlldmUgY29u c2Vuc3VzIG9uIGFueSBXRy1iYXNlZCBjaGFuZ2VzIHRvIEFSRg0KCUFwciAxMAlTdWJtaXQgQVJG IElEIHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uDQoJQXVnIDEwCUlzc3VlIFdHLWJhc2VkIElEcyBk ZWZpbmluZyB1c2VmdWwgZXh0ZW5zaW9ucw0KCU5vdiAxMAlBY2hpZXZlIGNvbnNlbnN1cyBvbiBl eHRlbnNpb24gZHJhZnRzDQoJRGVjIDEwCVN1Ym1pdCBleHRlbnNpb24gSURzIHRvIElFU0cgZm9y IHB1YmxpY2F0aW9uDQoJSmFuIDExCUlzc3VlIGZpcnN0IFdHLWJhc2VkIElEIGZvciBES0lNIHJl cG9ydGluZyBleHRlbnNpb25zDQoJTWFyIDExCUFjaGlldmUgY29uc2Vuc3VzIG9uIERLSU0gcmVw b3J0aW5nIGV4dGVuc2lvbnMgZHJhZnQNCglBcHIgMTEJU3VibWl0IERLSU0gcmVwb3J0aW5nIElE IHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uDQoJSnVuIDExCUlzc3VlIGZpcnN0IFdHLWJhc2VkIElE IGZvciBhZHZlcnRpc2luZyB0aGUgQVJGIGFkZHJlc3MNCglTZXAgMTEJQWNoaWV2ZSBjb25zZW5z dXMgb24gQVJGIGFkZHJlc3MgYWR2ZXJ0aXNpbmcgZHJhZnQNCglPY3QgMTEJU3VibWl0IEFSRiBh ZGRyZXNzIGFkdmVydGlzaW5nIElEIHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uDQo= --_004_BB012BD379D7B046ABE1472D8093C61C01AFA273F7EXCHC2corpclo_-- Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8OHq1k2021321 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Thu, 24 Sep 2009 10:52:06 -0700 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Thu, 24 Sep 2009 10:52:00 -0700 From: "Murray S. Kucherawy" To: Douglas Otis , Steve Atkins Date: Thu, 24 Sep 2009 10:51:59 -0700 Thread-Topic: [feedback-report] Revised draft charter, call for participation -- Please comment Thread-Index: Aco84rb9l8S+9lLCRM2wu5f4GppQTwAXJrHQ Message-ID: References: <501c18e00909211910u20f885cal8226831f6c60af5e@mail.gmail.com> <4ABAC5DC.8000501@mail-abuse.org> <4ABB1568.9000600@mail-abuse.org> In-Reply-To: <4ABB1568.9000600@mail-abuse.org> 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" MIME-Version: 1.0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 24 Sep 2009 10:52:06 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n8OHq1k2021321 Cc: ARF mailing list Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 17:52:06 -0000 > -----Original Message----- > From: abuse-feedback-report-bounces@mipassoc.org [mailto:abuse- > feedback-report-bounces@mipassoc.org] On Behalf Of Douglas Otis > Sent: Wednesday, September 23, 2009 11:45 PM > To: Steve Atkins > Cc: ARF mailing list > Subject: Re: [feedback-report] Revised draft charter, call for > participation -- Please comment > > Both automatic filtering OR reports generated by users pressing a > "junk" > or "spam" button should not be considered reliable categorization > methods. Even email sent to honeypots still need to be automatically > filtered into categories like "abuse/spam", "fraud/phish", "opt-out", > "virus/malware" and "not-spam/NDN/auto-response". > > [...] > > The ARF report offers email providers a means to view samplings of the > problems their customer's systems create. It would be a bad practice > for providers to react to ARF reports without their visual review. It > would also be a bad practice to report any and all email that can be > categorized by an ARF report. Still, providers of email should ensure > ARF reports are visually reviewed before actions are taken. By extension, DSNs shouldn't be parsed by software to use when determining whether or not to remove a bouncing address from a mailing list, yet this is somewhat common practice. I've not heard this in widespread use as an attack vector. If automatic processing is a dangerous goal, then we must also conclude that DSN was a bad idea in the first place. So, I have to disagree. Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8O6ilLt009058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 Sep 2009 23:44:53 -0700 Received: from farside-mini.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 93802A9444C; Thu, 24 Sep 2009 06:44:45 +0000 (UTC) Message-ID: <4ABB1568.9000600@mail-abuse.org> Date: Wed, 23 Sep 2009 23:44:56 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Steve Atkins References: <501c18e00909211910u20f885cal8226831f6c60af5e@mail.gmail.com> <4ABAC5DC.8000501@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 23 Sep 2009 23:44:53 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 06:44:53 -0000 On 9/23/09 6:29 PM, Steve Atkins wrote: > > On Sep 23, 2009, at 6:05 PM, Douglas Otis wrote: >> >> The problem this attempts to address will not be resolved through >> automation. Any automation 'foo' will be gamed. Resolving these >> issues requires wet-ware. It should be a safe assumption that >> automated detection of spam will represent the main force causing >> a report to be generated. > > Uhm. > > Automated detection of spam is not a main force in causing a report > to be generated today. It's probably a negligible fraction, actually, > and that's not a bad thing given the quality of that sort of report > I've seen. Steve, Both automatic filtering OR reports generated by users pressing a "junk" or "spam" button should not be considered reliable categorization methods. Even email sent to honeypots still need to be automatically filtered into categories like "abuse/spam", "fraud/phish", "opt-out", "virus/malware" and "not-spam/NDN/auto-response". Those issuing ARF reports should not be expected to have expended much effort checking the veracity of their output, beyond ensuring their process is active and not reporting errors. The onus is on those receiving ARF reports to decide what actions are needed based upon their own inspections. This raises a question about the "miscategorizated" status. Is this intended to benefit rating services? A bad reputation would not be an assertion against _all_ of a domain's email or even all email from a specific email-address. It just means the source is considered abusive and recipients may not wish to accept or to lower their score to improve catch rates. Reporting instances of where a message conflicts with a rating can be easily gamed, and likely to be of no value. The ARF report offers email providers a means to view samplings of the problems their customer's systems create. It would be a bad practice for providers to react to ARF reports without their visual review. It would also be a bad practice to report any and all email that can be categorized by an ARF report. Still, providers of email should ensure ARF reports are visually reviewed before actions are taken. -Doug Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8O1oZk7021223 for ; Wed, 23 Sep 2009 18:50:40 -0700 Received: by pxi13 with SMTP id 13so1081148pxi.6 for ; Wed, 23 Sep 2009 18:50:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.41.11 with SMTP id t11mr181773rvj.259.1253757034069; Wed, 23 Sep 2009 18:50:34 -0700 (PDT) In-Reply-To: <4ABAC5DC.8000501@mail-abuse.org> References: <501c18e00909211910u20f885cal8226831f6c60af5e@mail.gmail.com> <4ABAC5DC.8000501@mail-abuse.org> From: Yakov Shafranovich Date: Wed, 23 Sep 2009 21:50:14 -0400 Message-ID: <501c18e00909231850pb31b874pf19b91ebd2650a53@mail.gmail.com> To: Douglas Otis Content-Type: text/plain; charset=ISO-8859-1 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 23 Sep 2009 18:50:40 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n8O1oZk7021223 Cc: ARF mailing list Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 01:50:40 -0000 On Wed, Sep 23, 2009 at 9:05 PM, Douglas Otis wrote: > The problem this attempts to address will not be resolved through > automation.  Any automation 'foo' will be gamed.  Resolving these issues > requires wet-ware.  It should be a safe assumption that automated > detection of spam will represent the main force causing a report to be > generated. > > These reports should be considered similar to check processing at a bank > where exceptions require visual examination.  Such examination is not > facilitated by XML decorations. > It is possible to make examination by humans more efficient and faster. For example, several US banks now use a system for their ATMs where the checks are scanned and the scanned images are transmitted to some other location instead of being checked by the teller at the bank. They are already in a form that is easily analyzed and linked to the accounts in question. Same goes here - getting the reports in a standard format, will allow make analysis and processing faster. Yakov Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8O1guK2020750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 Sep 2009 18:43:01 -0700 Received: from sjc-office-nat-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 3A581A9443B; Thu, 24 Sep 2009 01:05:32 +0000 (UTC) Message-ID: <4ABAC5DC.8000501@mail-abuse.org> Date: Wed, 23 Sep 2009 18:05:32 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Steve Atkins References: <501c18e00909211910u20f885cal8226831f6c60af5e@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Delayed for 00:37:22 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 23 Sep 2009 18:43:01 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 01:43:01 -0000 On 9/23/09 12:22 PM, Steve Atkins wrote: > > On Sep 23, 2009, at 12:07 PM, Murray S. Kucherawy wrote: >>> >>> I would like to participate but I have an issue with the >>> deliverables. Specifically, I am concerned with the possibility >>> that we may get stuck on discussing all the proposed extensions >>> before codifying the main draft. I would like to suggest that we >>> make standardizing the bare minimum of ARF first, and consider >>> the extensions as a second step. If a larger scope format evolves >>> from it, it may become ARF 2.0, but we need the 1.0 in place >>> first. >> >> I believe this jives with what a few others have said. I'm fine >> with this approach if there's consensus. >> >> So if I were to rework the deliverables, effectively swapping (1) >> and (2) from the current draft charter, it sounds like that would >> make everyone happy. Specifically, we would push to get ARF >> finalized as minimally as possible (maybe even removing some stuff) >> and then work on the suggested list of things, including the DKIM >> stuff, as extensions. >> >> Do I hear any "+1"s? > > Yup, sounds like a good plan to me. Yes. Start with: ,--- The primary target for "generic" abuse reports (fraud, spam, virus, etcetera) would be the abuse desk of the organization accountable for originating the message. A document specifying where the target address can be found should also say how to identify such accountable originator, which is not a marginal task for a document or a WG dedicated to a format specification. '--- The problem this attempts to address will not be resolved through automation. Any automation 'foo' will be gamed. Resolving these issues requires wet-ware. It should be a safe assumption that automated detection of spam will represent the main force causing a report to be generated. These reports should be considered similar to check processing at a bank where exceptions require visual examination. Such examination is not facilitated by XML decorations. -Doug Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8O1U0Eg019891 for ; Wed, 23 Sep 2009 18:30:05 -0700 Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 5EBA880714 for ; Wed, 23 Sep 2009 18:30:00 -0700 (PDT) Message-Id: From: Steve Atkins To: ARF mailing list In-Reply-To: <4ABAC5DC.8000501@mail-abuse.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 23 Sep 2009 18:29:59 -0700 References: <501c18e00909211910u20f885cal8226831f6c60af5e@mail.gmail.com> <4ABAC5DC.8000501@mail-abuse.org> X-Mailer: Apple Mail (2.936) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 23 Sep 2009 18:30:05 -0700 (PDT) Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 01:30:06 -0000 On Sep 23, 2009, at 6:05 PM, Douglas Otis wrote: >> > > Yes. Start with: > > ,--- > The primary target for "generic" abuse reports (fraud, spam, > virus, etcetera) would be the abuse desk of the organization > accountable for originating the message. A document specifying where > the target address can be found should also say how to identify such > accountable originator, which is not a marginal task for a document or > a WG dedicated to a format specification. > '--- > > The problem this attempts to address will not be resolved through > automation. Any automation 'foo' will be gamed. Resolving these > issues > requires wet-ware. It should be a safe assumption that automated > detection of spam will represent the main force causing a report to be > generated. Uhm. Automated detection of spam is not a main force in causing a report to be generated today. It's probably a negligible fraction, actually, and that's not a bad thing given the quality of that sort of report I've seen. > > These reports should be considered similar to check processing at a > bank > where exceptions require visual examination. Such examination is not > facilitated by XML decorations. Cheers, Steve Received: from todzilla.mail.rr.com (todzilla.mail.rr.com [24.28.207.21]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8NLMLAo009133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 Sep 2009 14:22:27 -0700 Received: from todzilla.mail.rr.com (todzilla.mail.rr.com [127.0.0.1]) by todzilla.mail.rr.com (8.14.2/8.14.2) with ESMTP id n8NJtNFq012335 for ; Wed, 23 Sep 2009 15:55:24 -0400 Received: (from therr@localhost) by todzilla.mail.rr.com (8.14.2/8.14.2/Submit) id n8NJtNIF012333 for abuse-feedback-report@mipassoc.org; Wed, 23 Sep 2009 15:55:23 -0400 X-Authentication-Warning: todzilla.mail.rr.com: therr set sender to therr@security.rr.com using -f Date: Wed, 23 Sep 2009 15:55:23 -0400 From: Todd Herr To: abuse-feedback-report@mipassoc.org Message-ID: <20090923195523.GB11860@todzilla.mail.rr.com> References: <501c18e00909211910u20f885cal8226831f6c60af5e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: Delayed for 01:26:57 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 23 Sep 2009 14:22:27 -0700 (PDT) Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 21:22:28 -0000 +1 On Wed, Sep 23, 2009 at 12:07:14PM -0700, Murray S. Kucherawy wrote: > > -----Original Message----- > > From: Yakov Shafranovich [mailto:yakov@shaftek.org] > > Sent: Monday, September 21, 2009 7:11 PM > > To: Murray S. Kucherawy > > Cc: abuse-feedback-report@mipassoc.org > > Subject: Re: [feedback-report] Revised draft charter, call for > > participation -- Please comment > > > > I would like to participate but I have an issue with the deliverables. > > Specifically, I am concerned with the possibility that we may get > > stuck on discussing all the proposed extensions before codifying the > > main draft. I would like to suggest that we make standardizing the > > bare minimum of ARF first, and consider the extensions as a second > > step. If a larger scope format evolves from it, it may become ARF 2.0, > > but we need the 1.0 in place first. > > I believe this jives with what a few others have said. I'm fine with this approach if there's consensus. > > So if I were to rework the deliverables, effectively swapping (1) and (2) from the current draft charter, it sounds like that would make everyone happy. Specifically, we would push to get ARF finalized as minimally as possible (maybe even removing some stuff) and then work on the suggested list of things, including the DKIM stuff, as extensions. > > Do I hear any "+1"s? > > > _______________________________________________ > abuse-feedback-report mailing list > abuse-feedback-report@mipassoc.org > http://mipassoc.org/mailman/listinfo/abuse-feedback-report -- Todd Herr Principal Engineer and Postmaster V: 703.345.2447 Road Runner Email Operations M: 571.287.0366 therr@security.rr.com AIM: RRMailToddHerr Received: from omr-d31.mx.aol.com (omr-d31.mx.aol.com [205.188.249.129]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8NJbRGJ002552 for ; Wed, 23 Sep 2009 12:37:32 -0700 Received: from AOLMTCMEH01.ad.office.aol.com (aolmtcmeh01.office.aol.com [10.178.121.20]) by omr-d31.mx.aol.com (v117.7) with ESMTP id MAILOMRD315-7e4a4aba78f0321; Wed, 23 Sep 2009 15:37:20 -0400 Received: from AOLMTCMEI02.ad.office.aol.com ([10.178.3.19]) by AOLMTCMEH01.ad.office.aol.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 15:37:20 -0400 Received: from [10.181.80.41] ([10.178.3.11]) by AOLMTCMEI02.ad.office.aol.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 15:37:20 -0400 Message-ID: <4ABA78F1.70103@corp.aol.com> Date: Wed, 23 Sep 2009 15:37:21 -0400 From: Michael Adkins User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <501c18e00909211910u20f885cal8226831f6c60af5e@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Sep 2009 19:37:20.0474 (UTC) FILETIME=[441FEBA0:01CA3C85] X-AOL-IP: 10.178.121.20 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 23 Sep 2009 12:37:32 -0700 (PDT) Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 19:37:32 -0000 +1 Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Yakov Shafranovich [mailto:yakov@shaftek.org] >> Sent: Monday, September 21, 2009 7:11 PM >> To: Murray S. Kucherawy >> Cc: abuse-feedback-report@mipassoc.org >> Subject: Re: [feedback-report] Revised draft charter, call for >> participation -- Please comment >> >> I would like to participate but I have an issue with the deliverables. >> Specifically, I am concerned with the possibility that we may get >> stuck on discussing all the proposed extensions before codifying the >> main draft. I would like to suggest that we make standardizing the >> bare minimum of ARF first, and consider the extensions as a second >> step. If a larger scope format evolves from it, it may become ARF 2.0, >> but we need the 1.0 in place first. >> > > I believe this jives with what a few others have said. I'm fine with this approach if there's consensus. > > So if I were to rework the deliverables, effectively swapping (1) and (2) from the current draft charter, it sounds like that would make everyone happy. Specifically, we would push to get ARF finalized as minimally as possible (maybe even removing some stuff) and then work on the suggested list of things, including the DKIM stuff, as extensions. > > Do I hear any "+1"s? > > > _______________________________________________ > abuse-feedback-report mailing list > abuse-feedback-report@mipassoc.org > http://mipassoc.org/mailman/listinfo/abuse-feedback-report > Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8NJMuoC001511 for ; Wed, 23 Sep 2009 12:23:01 -0700 Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id B2A1E80C9B for ; Wed, 23 Sep 2009 12:22:55 -0700 (PDT) Message-Id: From: Steve Atkins To: ARF mailing list In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 23 Sep 2009 12:22:54 -0700 References: <501c18e00909211910u20f885cal8226831f6c60af5e@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 23 Sep 2009 12:23:01 -0700 (PDT) Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 19:23:01 -0000 On Sep 23, 2009, at 12:07 PM, Murray S. Kucherawy wrote: >> >> I would like to participate but I have an issue with the >> deliverables. >> Specifically, I am concerned with the possibility that we may get >> stuck on discussing all the proposed extensions before codifying the >> main draft. I would like to suggest that we make standardizing the >> bare minimum of ARF first, and consider the extensions as a second >> step. If a larger scope format evolves from it, it may become ARF >> 2.0, >> but we need the 1.0 in place first. > > I believe this jives with what a few others have said. I'm fine > with this approach if there's consensus. > > So if I were to rework the deliverables, effectively swapping (1) > and (2) from the current draft charter, it sounds like that would > make everyone happy. Specifically, we would push to get ARF > finalized as minimally as possible (maybe even removing some stuff) > and then work on the suggested list of things, including the DKIM > stuff, as extensions. > > Do I hear any "+1"s? Yup, sounds like a good plan to me. Cheers, Steve Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8NJMFZC001451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 Sep 2009 12:22:22 -0700 Received: (qmail 53741 invoked from network); 23 Sep 2009 19:22:15 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 23 Sep 2009 19:22:15 -0000 Date: 23 Sep 2009 15:22:15 -0400 Message-ID: From: "John R. Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <501c18e00909211910u20f885cal8226831f6c60af5e@mail.gmail.com> 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 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 23 Sep 2009 12:22:22 -0700 (PDT) Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 19:22:22 -0000 > So if I were to rework the deliverables, effectively swapping (1) and (2) from the current draft charter, it sounds like that would make everyone happy. Specifically, we would push to get ARF finalized as minimally as possible (maybe even removing some stuff) and then work on the suggested list of things, including the DKIM stuff, as extensions. > > Do I hear any "+1"s? +1 Unlike a lot of IETF standardization efforts, ARF is already in wide use with rough consensus on the current format. Hence it would be a good idea to document what its many users do now before blowing it up and hoping they like the changes. R's, John Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8NJ7FHJ000352 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 23 Sep 2009 12:07:20 -0700 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Wed, 23 Sep 2009 12:07:15 -0700 From: "Murray S. Kucherawy" To: Yakov Shafranovich Date: Wed, 23 Sep 2009 12:07:14 -0700 Thread-Topic: [feedback-report] Revised draft charter, call for participation -- Please comment Thread-Index: Aco7KekZrJ2Kg/guRfKnpoqEqI8uHABVpZxw Message-ID: References: <501c18e00909211910u20f885cal8226831f6c60af5e@mail.gmail.com> In-Reply-To: <501c18e00909211910u20f885cal8226831f6c60af5e@mail.gmail.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" MIME-Version: 1.0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 23 Sep 2009 12:07:20 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n8NJ7FHJ000352 Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 19:07:20 -0000 > -----Original Message----- > From: Yakov Shafranovich [mailto:yakov@shaftek.org] > Sent: Monday, September 21, 2009 7:11 PM > To: Murray S. Kucherawy > Cc: abuse-feedback-report@mipassoc.org > Subject: Re: [feedback-report] Revised draft charter, call for > participation -- Please comment > > I would like to participate but I have an issue with the deliverables. > Specifically, I am concerned with the possibility that we may get > stuck on discussing all the proposed extensions before codifying the > main draft. I would like to suggest that we make standardizing the > bare minimum of ARF first, and consider the extensions as a second > step. If a larger scope format evolves from it, it may become ARF 2.0, > but we need the 1.0 in place first. I believe this jives with what a few others have said. I'm fine with this approach if there's consensus. So if I were to rework the deliverables, effectively swapping (1) and (2) from the current draft charter, it sounds like that would make everyone happy. Specifically, we would push to get ARF finalized as minimally as possible (maybe even removing some stuff) and then work on the suggested list of things, including the DKIM stuff, as extensions. Do I hear any "+1"s? Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8N7NJOa021080 for ; Wed, 23 Sep 2009 00:23:25 -0700 Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 23 Sep 2009 08:42:59 +0200 id 00000000005DC02F.000000004AB9C373.0000131D Message-ID: <4AB9C37C.5000105@tana.it> Date: Wed, 23 Sep 2009 08:43:08 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "abuse-feedback-report@mipassoc.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Delayed for 00:40:19 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 23 Sep 2009 00:23:25 -0700 (PDT) Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 07:23:25 -0000 Murray S. Kucherawy wrote: > Attached is a revised proposed charter for an IETF working group > regarding the ARF work. Thanks for that addition! It's good to mention INCH, not only because non-message extensions can be addressed that way, but also for complementarity that may manifest, e.g., when a botnet message reported using ARF happens to contribute useful info to a network incident maintained using IODEF. > [...] So after reviewing the draft charter, please reply to the > list with some comments along the lines of the following as you feel > appropriate: I would participate in a working group with this charter. > …and: Formally, I represent just myself. However, I try to consider the needs of several small to medium mailbox providers that serve one or few mail domains within non-IT companies or institutions. That is to say, organizations that currently use neither ARF nor IODEF, but might adopt any of them when a clear proposal of cooperation for a better Internet will be made. Received: from omr-m34.mx.aol.com (omr-m34.mx.aol.com [64.12.143.146]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8MF41x5015531 for ; Tue, 22 Sep 2009 08:04:06 -0700 Received: from AOLDTCMEH01.ad.office.aol.com (aoldtcmeh01.office.aol.com [10.180.121.20]) by omr-m34.mx.aol.com (v117.7) with ESMTP id MAILOMRM341-7f2b4ab8e0131ee; Tue, 22 Sep 2009 10:32:51 -0400 Received: from AOLMTCMEI02.ad.office.aol.com ([10.178.3.19]) by AOLDTCMEH01.ad.office.aol.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 10:32:52 -0400 Received: from [10.181.80.41] ([10.178.3.10]) by AOLMTCMEI02.ad.office.aol.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 10:32:51 -0400 Message-ID: <4AB8E027.901@corp.aol.com> Date: Tue, 22 Sep 2009 10:33:11 -0400 From: Michael Adkins User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "John R. Levine" References: <33D03E77-7B9F-4DB1-B2AD-3F0D641D5C22@word-to-the-wise.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Sep 2009 14:32:51.0629 (UTC) FILETIME=[90A1A5D0:01CA3B91] X-AOL-IP: 10.180.121.20 X-Greylist: Delayed for 00:30:53 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 22 Sep 2009 08:04:06 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 15:04:06 -0000 John R. Levine wrote: >> I'd like to participate if there were fewer deliverables. >> >> ARF is, at core, a way of encapsulating a clean copy of a single email >> along with some metadata. >> >> The extensions you mention as possibilities cannot be added without >> changing ARF entirely, as they are not things that can be expressed as >> a copy of a single email. >> >> Alternatively, I'd also be somewhat interested in participating in >> development of a reporting format for the non-email related issues you >> mention, one that is not ARF, but adopts ARF's philosophy of simplicity. >> > > +1 > _______________________________________________ > abuse-feedback-report mailing list > abuse-feedback-report@mipassoc.org > http://mipassoc.org/mailman/listinfo/abuse-feedback-report > +1 Also - I would participate in a working group if the charter had the sort of changes John and Steve are talking about. ...and: I represent an organization that already uses ARF and would like to see it published as a proposed standard. Received: from mail-px0-f202.google.com (mail-px0-f202.google.com [209.85.216.202]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8M2ApOr031454 for ; Mon, 21 Sep 2009 19:10:56 -0700 Received: by pxi40 with SMTP id 40so2894228pxi.5 for ; Mon, 21 Sep 2009 19:10:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.157.9 with SMTP id f9mr13922rve.165.1253585451139; Mon, 21 Sep 2009 19:10:51 -0700 (PDT) In-Reply-To: References: From: Yakov Shafranovich Date: Mon, 21 Sep 2009 22:10:31 -0400 Message-ID: <501c18e00909211910u20f885cal8226831f6c60af5e@mail.gmail.com> To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 21 Sep 2009 19:10:57 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n8M2ApOr031454 Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 02:10:57 -0000 2009/9/21 Murray S. Kucherawy : > Attached is a revised proposed charter for an IETF working group regarding > the ARF work.  Please take a look. > > Murray - once again - thanks for taking over and shepherding this along. > -          I/we would participate in a working group if the charter had the > following changes (e.g. additional deliverables) > I would like to participate but I have an issue with the deliverables. Specifically, I am concerned with the possibility that we may get stuck on discussing all the proposed extensions before codifying the main draft. I would like to suggest that we make standardizing the bare minimum of ARF first, and consider the extensions as a second step. If a larger scope format evolves from it, it may become ARF 2.0, but we need the 1.0 in place first. Also, two small comments on the actual text: 1. The group referred to in the draft as originally have developed ARF - I believe that is referring to Anti-Spam Technology Alliance. 2. The draft is referencing DSNs as a related standard. It should probably reference RFC 3462 since it is directly based on it. Keep up the good work! Yakov Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8LI5CXW032645 for ; Mon, 21 Sep 2009 11:05:17 -0700 Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 178E280924 for ; Mon, 21 Sep 2009 11:05:12 -0700 (PDT) Message-Id: <09A4C68B-C324-461E-8F3F-D5DD8DBE5559@word-to-the-wise.com> From: Steve Atkins To: ARF mailing list In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 21 Sep 2009 11:05:10 -0700 References: <33D03E77-7B9F-4DB1-B2AD-3F0D641D5C22@word-to-the-wise.com> X-Mailer: Apple Mail (2.936) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 21 Sep 2009 11:05:17 -0700 (PDT) Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 18:05:17 -0000 On Sep 21, 2009, at 10:48 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: abuse-feedback-report-bounces@mipassoc.org [mailto:abuse- >> feedback-report-bounces@mipassoc.org] On Behalf Of Steve Atkins >> Sent: Monday, September 21, 2009 10:44 AM >> To: ARF mailing list >> Subject: Re: [feedback-report] Revised draft charter, call for >> participation -- Please comment >> >> I'd like to participate if there were fewer deliverables. >> >> ARF is, at core, a way of encapsulating a clean copy of a single >> email >> along with some metadata. >> >> The extensions you mention as possibilities cannot be added without >> changing ARF entirely, as they are not things that can be expressed >> as >> a copy of a single email. > > The charter doesn't require adoption of any or all of those proposed > extensions. It just makes a commitment to their due consideration. Yup, and that's perfectly reasonable. However, I've seen in the past that "the phrasing of the charter dictates the end product", and including obviously problematic ideas in a charter that is explicitly about ARF is going to lead to, well, long and pointless discussions at the very least (which is something that makes me less interested in participating). > > A spinoff effort to consider the non-messaging extensions that have > been proposed also seems quite palatable to me, even if it would be > as simple as "here's how to use/extend INCH to do that", since > clearly there's a need for it. If the goal were "How to easily automate abuse reports of these types, including use of ARF, INCH and potentially other approaches", rather than "How to extend ARF to automate abuse reports of these types" I'd lose most of my reservations about the charter. That'd be more likely to tread on INCH toes, though, I'm sure, given it's mostly revisiting their work. Cheers, Steve Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8LI1Zax032382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Sep 2009 11:01:40 -0700 Authentication-Results: sbh17.songbird.com; dkim=neutral header.i=@iecc.com Received: (qmail 89986 invoked from network); 21 Sep 2009 18:01:34 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 21 Sep 2009 18:01:34 -0000 Date: Mon, 21 Sep 2009 14:01:33 -0400 (EDT) From: "John R. Levine" To: Steve Atkins In-Reply-To: <33D03E77-7B9F-4DB1-B2AD-3F0D641D5C22@word-to-the-wise.com> Message-ID: References: <33D03E77-7B9F-4DB1-B2AD-3F0D641D5C22@word-to-the-wise.com> 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 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 21 Sep 2009 11:01:41 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 18:01:41 -0000 > I'd like to participate if there were fewer deliverables. > > ARF is, at core, a way of encapsulating a clean copy of a single email > along with some metadata. > > The extensions you mention as possibilities cannot be added without > changing ARF entirely, as they are not things that can be expressed as > a copy of a single email. > > Alternatively, I'd also be somewhat interested in participating in > development of a reporting format for the non-email related issues you > mention, one that is not ARF, but adopts ARF's philosophy of simplicity. +1 Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8LHp3dR031779 for ; Mon, 21 Sep 2009 10:51:08 -0700 Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id BA64080924 for ; Mon, 21 Sep 2009 10:11:42 -0700 (PDT) Message-Id: <4727E01B-DDD2-4C16-A8FF-2D743453FD17@word-to-the-wise.com> From: Steve Atkins To: ARF mailing list In-Reply-To: <501c18e00909210959h79546462wf5e1620ccdb8efb6@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 21 Sep 2009 10:11:42 -0700 References: <4AB3C1FD.1090203@knutix.de> <4AB5039B.7050401@knutix.de> <501c18e00909210959h79546462wf5e1620ccdb8efb6@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 21 Sep 2009 10:51:08 -0700 (PDT) Subject: Re: [feedback-report] FW: Another ARF expansion request X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 17:51:09 -0000 On Sep 21, 2009, at 9:59 AM, Yakov Shafranovich wrote: > On Mon, Sep 21, 2009 at 12:51 PM, Murray S. Kucherawy > wrote: >>> -----Original Message----- >>> From: abuse-feedback-report-bounces@mipassoc.org [mailto:abuse- >>> feedback-report-bounces@mipassoc.org] On Behalf Of John R. Levine >>> Sent: Saturday, September 19, 2009 9:27 AM >>> To: Tobias Knecht >>> Cc: ARF mailing list >>> Subject: Re: [feedback-report] FW: Another ARF expansion request >>> >>> I'll ask at MAAWG and see how willing ISPs are to add a lot of >>> custom >>> additions to their ARF processing. Designing formats that >>> interoperate >>> reliably is harder than it appears (look at all the little bugs in >>> DKIM.) >> >> We can mitigate some (but not all) of this concern by adopting >> DKIM's "if you don't recognize it, ignore it" posture with respect >> to tag names (or in the ARF case, abuse types, etc.). > > It is already in the current draft in section dealing with > extensibility: > > "In order to encourage extensibility and interoperability of this > format, implementors MUST ignore any fields they do not support. > " This makes ARF significantly less suitable for automated processing, as the bits you're ignoring may change the semantics of the message entirely - leading to automated processing taking the wrong action. Cheers, Steve Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8LHmhjA031595 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Mon, 21 Sep 2009 10:48:48 -0700 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Mon, 21 Sep 2009 10:48:42 -0700 From: "Murray S. Kucherawy" To: Steve Atkins , ARF mailing list Date: Mon, 21 Sep 2009 10:48:42 -0700 Thread-Topic: [feedback-report] Revised draft charter, call for participation -- Please comment Thread-Index: Aco641W6Ql0AyvQlSAKo/idq/yfVLAAABKJw Message-ID: References: <33D03E77-7B9F-4DB1-B2AD-3F0D641D5C22@word-to-the-wise.com> In-Reply-To: <33D03E77-7B9F-4DB1-B2AD-3F0D641D5C22@word-to-the-wise.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" MIME-Version: 1.0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 21 Sep 2009 10:48:48 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n8LHmhjA031595 Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 17:48:48 -0000 > -----Original Message----- > From: abuse-feedback-report-bounces@mipassoc.org [mailto:abuse- > feedback-report-bounces@mipassoc.org] On Behalf Of Steve Atkins > Sent: Monday, September 21, 2009 10:44 AM > To: ARF mailing list > Subject: Re: [feedback-report] Revised draft charter, call for > participation -- Please comment > > I'd like to participate if there were fewer deliverables. > > ARF is, at core, a way of encapsulating a clean copy of a single email > along with some metadata. > > The extensions you mention as possibilities cannot be added without > changing ARF entirely, as they are not things that can be expressed as > a copy of a single email. The charter doesn't require adoption of any or all of those proposed extensions. It just makes a commitment to their due consideration. A spinoff effort to consider the non-messaging extensions that have been proposed also seems quite palatable to me, even if it would be as simple as "here's how to use/extend INCH to do that", since clearly there's a need for it. Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8LHiEoJ031350 for ; Mon, 21 Sep 2009 10:44:19 -0700 Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 7C36080B90 for ; Mon, 21 Sep 2009 10:44:12 -0700 (PDT) Message-Id: <33D03E77-7B9F-4DB1-B2AD-3F0D641D5C22@word-to-the-wise.com> From: Steve Atkins To: ARF mailing list In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 21 Sep 2009 10:44:10 -0700 References: X-Mailer: Apple Mail (2.936) X-Greylist: Delayed for 00:32:31 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 21 Sep 2009 10:44:19 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n8LHiEoJ031350 Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 17:44:19 -0000 On Sep 21, 2009, at 10:06 AM, Murray S. Kucherawy wrote: > Attached is a revised proposed charter for an IETF working group > regarding the ARF work. Please take a look. > > Also, it’s important to have “for the record” the overall response > in terms of potential working group participation. I know I’ve done > something like this before but there appears to be some cause to re- > poll the group. It may be good enough just to have the recent > chatter as evidence of interest but for the sake of the IETF I’d > like to be more explicit. So after reviewing the draft charter, > please reply to the list with some comments along the lines of the > following as you feel appropriate: > > - I/we would participate in a working group with this > charter or one like it > - I/we would participate in a working group if the charter > had the following changes (e.g. additional deliverables) I'd like to participate if there were fewer deliverables. ARF is, at core, a way of encapsulating a clean copy of a single email along with some metadata. The extensions you mention as possibilities cannot be added without changing ARF entirely, as they are not things that can be expressed as a copy of a single email. Alternatively, I'd also be somewhat interested in participating in development of a reporting format for the non-email related issues you mention, one that is not ARF, but adopts ARF's philosophy of simplicity. But shoehorning every possible thing someone may want to communicate into what's currently a simple, single-use format isn't an approach I think will lead to a widely deployable standard. > …and: > > - I represent an organization that already uses ARF and > would like to see it published as a proposed standard I'd like to see a slightly cut-down version of the existing ARF spec published as a proposed standard. I'd be interested in an effort to add additional machine readable abuse reporting approaches that are not ARF. There's a whole spectrum there, from the complexity of INCH to a very simple format that simply includes just the metadata needed for routing and triage[1]. > - I represent an organization that would adopt ARF once it > has been published as a proposed standard > - I represent an organization that may not use ARF but > would like to see it or something like it issued as a proposed > standard > > I can say personally that I’ll participate and I represent one > commercial organization that may or may not use ARF directly but is > interested in seeing it standardized in either case, and one (an > open source team) that already uses it and would like it to move > forward. > > Thanks, > Cheers, Steve [1] A major use of the ARF metadata is to aggregate multiple reports of the same incident into a single issue, mechanically triage that based on (mostly) number of reports and then have those incidents be handled by a human. An extremely simple format that consisted simply of an identifier (an IP address, hostname, URL or email address, say) and free text would cover all the suggested abuse types, and provide a lot of what recipients need. It could also be specced fully on a single page and implemented fairly easily with current tools. Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8LH6nEe028804 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Mon, 21 Sep 2009 10:06:54 -0700 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Mon, 21 Sep 2009 10:06:49 -0700 From: "Murray S. Kucherawy" To: "abuse-feedback-report@mipassoc.org" Date: Mon, 21 Sep 2009 10:06:48 -0700 Thread-Topic: Revised draft charter, call for participation -- Please comment Thread-Index: Aco63efKNIukbSaSRrmQ/hk0dgw0Sg== 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_BB012BD379D7B046ABE1472D8093C61C01AFA26F58EXCHC2corpclo_" MIME-Version: 1.0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 21 Sep 2009 10:06:54 -0700 (PDT) Subject: [feedback-report] Revised draft charter, call for participation -- Please comment X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 17:06:54 -0000 --_004_BB012BD379D7B046ABE1472D8093C61C01AFA26F58EXCHC2corpclo_ Content-Type: multipart/alternative; boundary="_000_BB012BD379D7B046ABE1472D8093C61C01AFA26F58EXCHC2corpclo_" --_000_BB012BD379D7B046ABE1472D8093C61C01AFA26F58EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Attached is a revised proposed charter for an IETF working group regarding = the ARF work. Please take a look. Also, it's important to have "for the record" the overall response in terms= of potential working group participation. I know I've done something like= this before but there appears to be some cause to re-poll the group. It m= ay be good enough just to have the recent chatter as evidence of interest b= ut for the sake of the IETF I'd like to be more explicit. So after reviewi= ng the draft charter, please reply to the list with some comments along the= lines of the following as you feel appropriate: - I/we would participate in a working group with this charter or o= ne like it - I/we would participate in a working group if the charter had the= following changes (e.g. additional deliverables) ...and: - I represent an organization that already uses ARF and would like= to see it published as a proposed standard - I represent an organization that would adopt ARF once it has bee= n published as a proposed standard - I represent an organization that may not use ARF but would like = to see it or something like it issued as a proposed standard I can say personally that I'll participate and I represent one commercial o= rganization that may or may not use ARF directly but is interested in seein= g it standardized in either case, and one (an open source team) that alread= y uses it and would like it to move forward. Thanks, -MSK --_000_BB012BD379D7B046ABE1472D8093C61C01AFA26F58EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Attached is a revised proposed charter for an IETF wor= king group regarding the ARF work.  Please take a look.

 

Also, it’s important to have “for the reco= rd” the overall response in terms of potential working group participation.&nbs= p; I know I’ve done something like this before but there appears to be som= e cause to re-poll the group.  It may be good enough just to have the re= cent chatter as evidence of interest but for the sake of the IETF I’d like= to be more explicit.  So after reviewing the draft charter, please reply = to the list with some comments along the lines of the following as you feel appropriate:

 

-&nb= sp;         I/we would participate in a working group with this charter or one like it

-&nb= sp;         I/we would participate in a working group if the charter had the following changes (e.g. additional deliverables)=

 

…and:

 

-&nb= sp;         I represent an organization that already uses ARF a= nd would like to see it published as a proposed standard

-&nb= sp;         I represent an organization that would adopt ARF on= ce it has been published as a proposed standard

-&nb= sp;         I represent an organization that may not use ARF bu= t would like to see it or something like it issued as a proposed standard

 

I can say personally that I’ll participate and I represent one commercial organization that may or may not use ARF directly = but is interested in seeing it standardized in either case, and one (an open so= urce team) that already uses it and would like it to move forward.

 

Thanks,

 

-MSK

--_000_BB012BD379D7B046ABE1472D8093C61C01AFA26F58EXCHC2corpclo_-- --_004_BB012BD379D7B046ABE1472D8093C61C01AFA26F58EXCHC2corpclo_ Content-Type: text/plain; name="arf-charter v05.txt" Content-Description: arf-charter v05.txt Content-Disposition: attachment; filename="arf-charter v05.txt"; size=5597; creation-date="Fri, 18 Sep 2009 09:50:14 GMT"; modification-date="Fri, 18 Sep 2009 12:17:33 GMT" Content-Transfer-Encoding: base64 ICAgV29ya2luZyBHcm91cCBOYW1lOg0KICAgICAgICBBYnVzZSBSZXBvcnRpbmcgRm9ybWF0IChB UkYpDQoNCiAgIElFVEYgQXJlYToNCiAgICAgICAgQXBwbGljYXRpb25zIEFyZWENCg0KICAgQ2hh aXIocyk6DQogICAgICAgIFRCRA0KDQogICBBcHBsaWNhdGlvbnMgQXJlYSBEaXJlY3RvcihzKToN CiAgICAgICAgTGlzYSBEdXNzZWF1bHQgPExpc2EuRHVzc2VhdWx0QG1lc3NhZ2luZ2FyY2hpdGVj dHMuY29tPg0KICAgICAgICBBbGV4ZXkgTWVsbmlrb3YgPGFsZXhleS5tZWxuaWtvdkBpc29kZS5j b20+DQoNCiAgIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3I6DQogICAgICAgIFRCRA0KDQogICBN YWlsaW5nIExpc3RzOg0KICAgICAgICBHZW5lcmFsIERpc2N1c3Npb246IGFidXNlLWZlZWRiYWNr LXJlcG9ydEBtaXBhc3NvYy5vcmcNCiAgICAgICAgVG8gU3Vic2NyaWJlOiBodHRwOi8vbWlwYXNz b2Mub3JnL21haWxtYW4vbGlzdGluZm8vYWJ1c2UtZmVlZGJhY2stcmVwb3J0DQogICAgICAgIEFy Y2hpdmU6IGh0dHA6Ly9taXBhc3NvYy5vcmcvbWFpbG1hbi9saXN0aW5mby9hYnVzZS1mZWVkYmFj ay1yZXBvcnQNCg0KICAgRGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cDoNCglNZXNzYWdpbmcg YW50aS1hYnVzZSBvcGVyYXRpb25zIGJldHdlZW4gaW5kZXBlbmRlbnQgc2VydmljZXMgb2Z0ZW4g cmVxdWlyZXMNCglzZW5kaW5nIHJlcG9ydHMgb24gb2JzZXJ2ZWQgZnJhdWQsIHNwYW0gdmlydXMg b3Igb3RoZXIgYWJ1c2UgYWN0aXZpdHkuICBBDQoJc3RhbmRhcmRpemVkIHJlcG9ydCBmb3JtYXQg ZW5hYmxlcyBhdXRvbWF0ZWQgcHJvY2Vzc2luZy4gIFRoZSBBYnVzZSBSZXBvcnRpbmcNCglGb3Jt YXQgKEFSRikgc3BlY2lmaWNhdGlvbiBoYXMgZ2FpbmVkIHN1ZmZpY2llbnQgcG9wdWxhcml0eSB0 byB3YXJyYW50IGZvcm1hbA0KCWNvZGlmaWNhdGlvbiwgdG8gZW5zdXJlIGFuZCBlbmNvdXJhZ2Ug ZnV0dXJlIGludGVyb3BlcmFiaWxpdHkgd2l0aCBuZXcNCglpbXBsZW1lbnRhdGlvbnMuICBUaGUg cHJpbWFyeSBmdW5jdGlvbiBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBiZSB0byBzb2xpY2l0 DQoJcmV2aWV3IGFuZCByZWZpbmVtZW50IG9mIHRoZSBleGlzdGluZyBzcGVjaWZpY2F0aW9uLg0K DQoJQVJGIHdhcyBkZXZlbG9wZWQgYnkgYSBtZXNzYWdpbmcgdHJhZGUgb3JnYW5pemF0aW9uIGlu ZGVwZW5kZW50IG9mIHRoZSBJRVRGLA0KCWFuZCB1c2VzIGEgZm9ybWF0IHNpbWlsYXIgdG8gYSBE ZWxpdmVyeSBTdGF0dXMgTm90aWZpY2F0aW9uIChEU04sIFJGQzM0NjQpDQoJdG8gcmVwb3J0IGZy YXVkLCBzcGFtLCB2aXJ1c2VzIG9yIG90aGVyIGFidXNpdmUgYWN0aXZpdHkgaW4gdGhlIGVtYWls IHN5c3RlbS4NCglUaGUgYmFzaWMgZm9ybWF0IGlzIGFtZW5hYmxlIHRvIHByb2Nlc3NpbmcgYnkg aHVtYW5zIG9yIHNvZnR3YXJlLCB3aXRoIHRoZQ0KCWxhdHRlciByZXF1aXJpbmcgdGhlIGZvcm1h dCB0byBiZSBzdGFuZGFyZGl6ZWQsIHRvIHBlcm1pdCBpbnRlcm9wZXJhYmlsaXR5DQoJYmV0d2Vl biBhdXRvbWF0ZWQgc2VydmljZXMsIHBhcnRpY3VsYXJseSB3aXRob3V0IHByaW9yIGFycmFuZ2Vt ZW50Lg0KDQoJQVJGIGFzIGluaXRpYWxseSBkZWZpbmVkIGlzIGFscmVhZHkgaW4gd2lkZXNwcmVh ZCB1c2UgYXQgbGFyZ2UgSVNQcywgc28NCglpbnRlcm9wZXJhYmlsaXR5IGNhbiBiZSBkZW1vbnN0 cmF0ZWQuICBTb21lIHRvb2xzIGFscmVhZHkgZXhpc3QNCglmb3IgcHJvY2Vzc2luZyBBUkYgbWVz c2FnZXMsIGEgZmV3IG9mIHdoaWNoIGFyZSBvcGVuIHNvdXJjZS4gIEluIG9yZGVyIHRvDQoJcHJl c2VydmUgdGhlIGluc3RhbGxlZCBiYXNlLCB0aGUgd29ya2luZyBncm91cCB3aWxsIG1ha2UgdGhl IG1pbmltdW0gY2hhbmdlcw0KCW5lY2Vzc2FyeSB0byB0aGUgZXhpc3Rpbmcgc3BlY2lmaWNhdGlv biBhbmQgd2lsbCBzZWVrIHRvIGhhdmUgYmFja3dhcmQNCgljb21wYXRpYmlsaXR5LiAgRnVydGhl cm1vcmUsIHNvbWUgZXh0ZW5zaW9ucyB0byB0aGUgY3VycmVudCBwcm9wb3NhbCBhcmUNCglvZiBp bnRlcmVzdCB0byB0aGUgY29tbXVuaXR5LCBzdWNoIGFzIHRoZSBtZWFucyBmb3IgYW4gb3BlcmF0 b3IgdG8gYWR2ZXJ0aXNlDQoJYW4gZW1haWwgYWRkcmVzcyB0byB3aGljaCBhYnVzZSByZXBvcnRz IHVzaW5nIEFSRiBzaG91bGQgYmUgc2VudC4gIFRoZQ0KCXdvcmtpbmcgZ3JvdXAgd2lsbCB0YWtl IG9uIHRoZSB0YXNrIG9mIGNvbnNpZGVyaW5nIGFuZCBzcGVjaWZ5aW5nIHN1Y2ggYSBtZWNoYW5p c20uDQoNCglUaGUgaW5pdGlhbCBwcm9wb3NhbCBpcyBwdWJsaXNoZWQgYXMgZHJhZnQtc2hhZnJh bm92aWNoLWZlZWRiYWNrLXJlcG9ydCwNCglhbmQgdGhpcyB3aWxsIHByb3ZpZGUgdGhlIHdvcmtp bmcgZ3JvdXAncyBzdGFydGluZyBwb2ludC4NCg0KCVRoZSB3b3JraW5nIGdyb3VwIHNob3VsZCBj b25zaWRlciBzdWNoIGZhY3RvcnMgYXM6DQoJKiBpbXBsZW1lbnRlciBleHBlcmllbmNlDQoJKiBp bnRlcm5hdGlvbmFsaXphdGlvbg0KCSogZXhpc3RpbmcgdXNlcyBvZiBBUkYNCgkqIGFiaWxpdHkg dG8gYWNoaWV2ZSBicm9hZCBpbXBsZW1lbnRhdGlvbiBhbmQgaW50ZXJvcGVyYWJpbGl0eQ0KCSog YWJpbGl0eSB0byBhZGRyZXNzIGJyb2FkZXIgdXNlIGNhc2VzIHRoYW4gbWF5IGhhdmUgYmUgY29u dGVtcGxhdGVkIGJ5IHRoZSBvcmlnaW5hbA0KCSAgYXV0aG9ycw0KCSogb3ZlcmxhcCB3aXRoIHRo ZSBJTkNIIHdvcmtpbmcgZ3JvdXAncyB3b3JrIChlLmcuIFJGQzUwNzApOyBpdCBpcyB1bmNsZWFy IHdoZXRoZXINCgkgIHN1Y2ggb3ZlcmxhcCBpcyBhcHByb3ByaWF0ZSBvciBzaG91bGQgYmUgYXZv aWRlZA0KDQogICAgICAgIFRodXMsIHRoZSB3b3JraW5nIGdyb3VwJ3Mgc3BlY2lmaWMgdGFza3Mg YXJlIGFzIGZvbGxvd3M6DQoNCgkxKSBUaGUgZm9sbG93aW5nIHBvc3NpbGJsZSByZXBvcnRpbmcg ZXh0ZW5zaW9ucyBoYXZlIGJlZW4gcHJvcG9zZWQgYW5kIHdpbGwgYmUgY29uc2lkZXJlZA0KCSAg IHBvc3NpYmxlIGZvciBhZGRpdGlvbiB0byB0aGUgZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbjoNCg0K CSAgIGEpIGRyb3AgYm94ZXMgKGRldGVjdGlvbiBvZiBhIG1haWxib3ggdXNlZCB0byByZWNlaXZl IHRoaW5ncyBsaWtlIHN0b2xlbg0KCSAgICAgIGNyZWRpdCBjYXJkcykNCgkgICBiKSBib3RuZXQg ZGV0ZWN0aW9uIChpLmUuIHJlcG9ydGluZyBvZiB0cmFmZmljIHRoYXQgYXBwZWFycyB0byBoYXZl IGNvbWUNCgkgICAgICBmcm9tIGEgYm90LCByZWdhcmRsZXNzIG9mIGNvbnRlbnQpDQoJICAgYykg U1NIIGF0dGFja3MNCgkgICBkKSBGVFAgYXR0YWNrcw0KCSAgIGUpIFdlYiBzZXJ2ZXIgYXR0YWNr cw0KCSAgIGYpIG1haWwgc2VudCB0byBhIGhvbmV5cG90IG9yIHNwYW0gdHJhcA0KCSAgIGcpIG1h bHdhcmUgY29ubmVjdGlvbnMgdG8gc2lua2hvbGVzDQoJICAgaCkgRERvUyByZXBvcnRzDQogICAg ICAgICAgIGkpIG90aGVycyB0aGF0IG1heSBiZSBwcm9wb3NlZCB3aXRoaW4gdGhlIGFsbG90dGVk IHRpbWVmcmFtZQ0KDQoJMikgVGhlIGdyb3VwIHdpbGwgdGhlbiBwcm9kdWNlIGEgUHJvcG9zZWQg U3RhbmRhcmQgdHJhY2sgc3BlY2lmaWNhdGlvbiBvZiBBUkYuDQoJICAgVGhpcyB3aWxsIGluY2x1 ZGUgbm90IG9ubHkgdGhlIGZvcm1hdCBvZiBhbiBBUkYgbWVzc2FnZSBhZGFwdGVkIGFzIG5lZWRl ZA0KCSAgIGZvciB0aGUgaXNzdWVzIGVudW1lcmF0ZWQgYWJvdmUsIGJ1dCBtdXN0IGFsc28gaW5j bHVkZSBhcHByb3ByaWF0ZQ0KCSAgIGRvY3VtZW50YXRpb24gb2Ygc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMgYW5kIGNyZWF0aW9uIG9mIElBTkEgcmVnaXN0cmllcw0KCSAgIGZvciBlbGVtZW50cyBv ZiBBUkYgdG8gc3VwcG9ydCBmdXR1cmUgZXh0ZW5zaW9ucy4NCg0KCTMpIFRoZSBncm91cCB3aWxs IHNwZWNpZnkgdGhlIGludGVncmF0aW9uIG9mIEFSRiBpbnRvIERLSU0gRE5TIGtleSByZWNvcmRz LCB3aXRoDQoJICAgZHJhZnQta3VjaGVyYXd5LWRraW0tcmVwb3J0aW5nIGFzIGl0cyBpbnB1dC4g IEl0IGNvbnRhaW5zIGV4dGVuc2lvbnMNCgkgICB0byBES0lNIHRoYXQgYXJlIHJlbGF0ZWQgdG8g QVJGIGFzIGEgbWVhbnMgb2YgcmVwb3J0aW5nIERLSU0tcmVsYXRlZCBmYWlsdXJlcw0KCSAgIHdo aWNoIGluY2x1ZGUgcGhpc2hpbmcgKCJmcmF1ZCIpIGFuZCBhcyBzdWNoIGFyZSByZWxldmFudCB0 byB0aGUgQVJGIGVmZm9ydC4NCgkgICBUaGUgZ3JvdXAgd2lsbCBwcm9kdWNlIFByb3Bvc2VkIFN0 YW5kYXJkIHRyYWNrIHNwZWNpZmljYXRpb24gZm9yIHRoZXNlDQoJICAgQVJGIGFuZCBES0lNIGV4 dGVuc2lvbnMuDQoNCgk0KSBUaGUgZ3JvdXAgd2lsbCBmaW5hbGx5IGNvbnNpZGVyIGEgbWVhbnMg Zm9yIHB1Ymxpc2hpbmcgdGhlIGFkZHJlc3MNCgkgICB0byB3aGljaCBBUkYgcmVwb3J0cyBzaG91 bGQgYmUgc2VudC4gIE5vdCBhbGwgQVJGIHBhcnRpY2lwYW50cyB3aXNoIHRvIHVzZQ0KCSAgIGFi dXNlQChkb21haW4pLCB3aGljaCBpcyB0aGUgY3VycmVudCBzdGFuZGFyZCAoUkZDMjE0MikgLCBh cyB0aGUgcGxhY2UgdG8gc2VuZA0KCSAgIGF1dG9tYXRlZCBBUkYtZm9ybWF0dGVkIHJlcG9ydHMu ICBUaGUgZ3JvdXAgd2lsbCBlaXRoZXIgY29uY2x1ZGUgdGhhdCB0aGUgaW5kdXN0cnkNCgkgICBz aG91bGQgY29udGludWUgdG8gdXNlIHRoaXMgZGUgZmFjdG8gc3RhbmRhcmQgKGFuZCB0aHVzIG5v IHNwZWNpZmljYXRpb24gaXMgYXBwcm9wcmlhdGUpLA0KCSAgIG9yIHdpbGwgcHJvZHVjZSBhIFBy b3Bvc2VkIFN0YW5kYXJkIHRyYWNrIGRvY3VtZW50IGlkZW50aWZ5aW5nIHRoZSBtZWFucyBieSB3 aGljaA0KCSAgIHRoYXQgYWRkcmVzcyBzaG91bGQgYmUgYWR2ZXJ0aXNlZC4NCg0KCVRoZSBncm91 cCBtYXkgY29uc2lkZXIgcmUtY2hhcnRlcmluZyB0byBjb3ZlciByZWxhdGVkIHdvcmssIHN1Y2gg YXMgZnVydGhlciBleHRlbnNpb25zLA0KCW9uY2UgdGhlc2UgZGVsaXZlcmFibGVzIGhhdmUgYmVl biBhY2hpZXZlZC4NCg0KICAgR29hbHMgYW5kIE1pbGVzdG9uZXM6DQoJSmFuIDEwCUlzc3VlIGZp cnN0IFdHLWJhc2VkIEludGVybmV0LURyYWZ0IGRlZmluaW5nIEFSRg0KCU1hciAxMAlBY2hpZXZl IGNvbnNlbnN1cyBvbiBhbnkgV0ctYmFzZWQgY2hhbmdlcyB0byBBUkYNCglBcHIgMTAJU3VibWl0 IEFSRiBJRCB0byBJRVNHIGZvciBwdWJsaWNhdGlvbg0KCUp1bCAxMAlJc3N1ZSBmaXJzdCBXRy1i YXNlZCBJRCBhYm91dCBES0lNIHJlcG9ydGluZyBleHRlbnNpb25zDQoJU2VwIDEwCUFjaGlldmUg Y29uc2Vuc3VzIG9uIERLSU0gcmVwb3J0aW5nIGV4dGVuc2lvbnMgZHJhZnQNCglPY3QgMTAJU3Vi bWl0IERLSU0gcmVwb3J0aW5nIElEIHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uDQoJSmFuIDExCUlz c3VlIGZpcnN0IFdHLWJhc2VkIElEIGZvciBhZHZlcnRpc2luZyB0aGUgQVJGIGFkZHJlc3MNCglB cHIgMTEJQWNoaWV2ZSBjb25zZW5zdXMgb24gQVJGIGFkZHJlc3MgYWR2ZXJ0aXNpbmcgZHJhZnQN CglNYXkgMTEJU3VibWl0IEFSRiBhZGRyZXNzIGFkdmVydGlzaW5nIElEIHRvIElFU0cgZm9yIHB1 YmxpY2F0aW9uDQo= --_004_BB012BD379D7B046ABE1472D8093C61C01AFA26F58EXCHC2corpclo_-- Received: from mail-px0-f174.google.com (mail-px0-f174.google.com [209.85.216.174]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8LGxNRK028196 for ; Mon, 21 Sep 2009 09:59:28 -0700 Received: by pxi4 with SMTP id 4so2531259pxi.23 for ; Mon, 21 Sep 2009 09:59:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.165.21 with SMTP id n21mr113778rve.1.1253552363050; Mon, 21 Sep 2009 09:59:23 -0700 (PDT) In-Reply-To: References: <4AB3C1FD.1090203@knutix.de> <4AB5039B.7050401@knutix.de> From: Yakov Shafranovich Date: Mon, 21 Sep 2009 12:59:03 -0400 Message-ID: <501c18e00909210959h79546462wf5e1620ccdb8efb6@mail.gmail.com> To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 21 Sep 2009 09:59:28 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n8LGxNRK028196 Cc: ARF mailing list Subject: Re: [feedback-report] FW: Another ARF expansion request X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 16:59:29 -0000 On Mon, Sep 21, 2009 at 12:51 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: abuse-feedback-report-bounces@mipassoc.org [mailto:abuse- >> feedback-report-bounces@mipassoc.org] On Behalf Of John R. Levine >> Sent: Saturday, September 19, 2009 9:27 AM >> To: Tobias Knecht >> Cc: ARF mailing list >> Subject: Re: [feedback-report] FW: Another ARF expansion request >> >> I'll ask at MAAWG and see how willing ISPs are to add a lot of custom >> additions to their ARF processing.  Designing formats that interoperate >> reliably is harder than it appears (look at all the little bugs in >> DKIM.) > > We can mitigate some (but not all) of this concern by adopting DKIM's "if you don't recognize it, ignore it" posture with respect to tag names (or in the ARF case, abuse types, etc.). It is already in the current draft in section dealing with extensibility: "In order to encourage extensibility and interoperability of this format, implementors MUST ignore any fields they do not support. " Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8LGpSLj027622 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Mon, 21 Sep 2009 09:51:33 -0700 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Mon, 21 Sep 2009 09:51:27 -0700 From: "Murray S. Kucherawy" To: "John R. Levine" , Tobias Knecht Date: Mon, 21 Sep 2009 09:51:27 -0700 Thread-Topic: [feedback-report] FW: Another ARF expansion request Thread-Index: Aco5RnFEyXfbNp/oQiO5JvPVWJ5LMwBlSdFg Message-ID: References: <4AB3C1FD.1090203@knutix.de> <4AB5039B.7050401@knutix.de> 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" MIME-Version: 1.0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Mon, 21 Sep 2009 09:51:33 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n8LGpSLj027622 Cc: ARF mailing list Subject: Re: [feedback-report] FW: Another ARF expansion request X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 16:51:34 -0000 > -----Original Message----- > From: abuse-feedback-report-bounces@mipassoc.org [mailto:abuse- > feedback-report-bounces@mipassoc.org] On Behalf Of John R. Levine > Sent: Saturday, September 19, 2009 9:27 AM > To: Tobias Knecht > Cc: ARF mailing list > Subject: Re: [feedback-report] FW: Another ARF expansion request > > I'll ask at MAAWG and see how willing ISPs are to add a lot of custom > additions to their ARF processing. Designing formats that interoperate > reliably is harder than it appears (look at all the little bugs in > DKIM.) We can mitigate some (but not all) of this concern by adopting DKIM's "if you don't recognize it, ignore it" posture with respect to tag names (or in the ARF case, abuse types, etc.). Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8JGQWHS017041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 19 Sep 2009 09:26:38 -0700 Authentication-Results: sbh17.songbird.com; dkim=neutral header.i=@iecc.com Received: (qmail 93841 invoked from network); 19 Sep 2009 16:26:32 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 19 Sep 2009 16:26:32 -0000 Date: Sat, 19 Sep 2009 12:26:31 -0400 (EDT) From: "John R. Levine" To: Tobias Knecht In-Reply-To: <4AB5039B.7050401@knutix.de> Message-ID: References: <4AB3C1FD.1090203@knutix.de> <4AB5039B.7050401@knutix.de> 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 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sat, 19 Sep 2009 09:26:38 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] FW: Another ARF expansion request X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 16:26:38 -0000 PS: > It is not commonly used. ARF is used by abuse departments and we wanna > communicated with abuse departments. I'll ask at MAAWG and see how willing ISPs are to add a lot of custom additions to their ARF processing. Designing formats that interoperate reliably is harder than it appears (look at all the little bugs in DKIM.) An important reason to use XML for complex formats is that there are already well debugged libraries to read and write it. R's, John Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8JGMwsu016835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 19 Sep 2009 09:23:04 -0700 Authentication-Results: sbh17.songbird.com; dkim=neutral header.i=@iecc.com Received: (qmail 90325 invoked from network); 19 Sep 2009 16:22:58 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 19 Sep 2009 16:22:58 -0000 Date: Sat, 19 Sep 2009 12:22:57 -0400 (EDT) From: "John R. Levine" To: Tobias Knecht In-Reply-To: <4AB5039B.7050401@knutix.de> Message-ID: References: <4AB3C1FD.1090203@knutix.de> <4AB5039B.7050401@knutix.de> 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 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sat, 19 Sep 2009 09:23:04 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] German abuse reporting work X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 16:23:05 -0000 > "We" means Germany ISP Association (eco), German Ministry of Internet > Securtity (BSI), several ISPs and abusix. The draft will be done by BSI > and published for conversation. We already had the conversation at the > meeting when we worked out the things you have seen in the email by > Dietmar Braun. So the conversation should not last too long. It would be nice if you could send along your results before the MAAWG meeting at the end of October, since it would be unfortunate if German ISPs used one reporting format and everyone else used another. > So if we have to make changes in IODEF and in ARF, I would like to > change the format that is mostly used in abuse departments. Which is ARF. Nothing personal, but I fear that if you both think that IODEF is too complicated and it doesn't have enough options, you're unlikely to come up with anything better. R's, John Received: from vwp0043.webpack.hosteurope.de (vwp0043.webpack.hosteurope.de [87.230.60.50]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8JGFTeo016520 for ; Sat, 19 Sep 2009 09:15:35 -0700 Received: from [88.128.45.200] (helo=[88.128.45.200]); authenticated by vwp0043.webpack.hosteurope.de running ExIM with esmtpa id 1Mp2au-0001SJ-Iq; Sat, 19 Sep 2009 18:15:28 +0200 Message-ID: <4AB5039B.7050401@knutix.de> Date: Sat, 19 Sep 2009 18:15:23 +0200 From: Tobias Knecht User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 CC: "abuse-feedback-report@mipassoc.org" References: <4AB3C1FD.1090203@knutix.de> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5330C60900D0640F2E306561" X-bounce-key: webpack.hosteurope.de;knut@knutix.de;1253376935;f2172dee; X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sat, 19 Sep 2009 09:15:35 -0700 (PDT) Subject: Re: [feedback-report] FW: Another ARF expansion request X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 16:15:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5330C60900D0640F2E306561 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, sorry for the delayed answer. > Sounds great. Who is "we"? This sounds like something that needs > coordination with MAAWG, since that's where you find the large ISPs. "We" means Germany ISP Association (eco), German Ministry of Internet Securtity (BSI), several ISPs and abusix. The draft will be done by BSI and published for conversation. We already had the conversation at the meeting when we worked out the things you have seen in the email by Dietmar Braun. So the conversation should not last too long. >> And yes there is INCH/IODEF and we decided that it's not sufficient fo= r >> the needs we have. >=20 > I don't disagree, but what in particular makes IODEF insufficient, and > why would you rather start over than add report types to IODEF? It is too complicated. It is not able to handle all sorts of abusive behavior, so there is need to change, same as in ARF. It is not commonly used. ARF is used by abuse departments and we wanna communicated with abuse departments. IODEF is used by CERTs or mostly network operation centers which will not be interested in spam issues. So our opinion is, to have IODEF as a format for things that have to be sent to CERTs or network operation centers and ARF will be used by abuse departments. So if we have to make changes in IODEF and in ARF, I would like to change the format that is mostly used in abuse departments. Which is ARF.= Thanks, Tobias --------------enig5330C60900D0640F2E306561 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkq1A58ACgkQvB4M5yQyqDek/wCfZBnzJgtfT5bCfcRL6QaXAKY6 VHEAoOUAYnVb9Yrm+F15fj/vQHC1/lBd =uCvM -----END PGP SIGNATURE----- --------------enig5330C60900D0640F2E306561-- Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8JDLkRc005739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 19 Sep 2009 06:21:52 -0700 Authentication-Results: sbh17.songbird.com; dkim=neutral header.i=@iecc.com Received: (qmail 24999 invoked from network); 19 Sep 2009 13:21:46 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 19 Sep 2009 13:21:46 -0000 Date: Sat, 19 Sep 2009 09:21:44 -0400 (EDT) From: "John R. Levine" To: ARF mailing list In-Reply-To: <4AB4BACF.30906@tana.it> Message-ID: References: <501c18e00909161142n20d30d56gf65a0a4cd1b0b1be@mail.gmail.com> <4AB24F3F.3060908@tana.it> <4AB4BACF.30906@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 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sat, 19 Sep 2009 06:21:52 -0700 (PDT) Subject: [feedback-report] Remember to put SIP and SPIT in the kitchen sink X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 13:21:52 -0000 Our pals over in the RUCKUS group which is considering VoIP spam remind us that if we're trying to invent or preferably adapt an all-purpose report format, it should handle reports of SIP abuse. SIP calls have a header that deliberately looks a lot like a mail header. so that shouldn't be hard to do. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8JB4nOu029096 for ; Sat, 19 Sep 2009 04:04:55 -0700 Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Sat, 19 Sep 2009 13:04:55 +0200 id 00000000005DC035.000000004AB4BAD7.000076DC Message-ID: <4AB4BAD6.3090703@tana.it> Date: Sat, 19 Sep 2009 13:04:54 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Yakov Shafranovich References: <4AB3C1FD.1090203@knutix.de> <501c18e00909181243w5036470fh1b54296af6977f44@mail.gmail.com> In-Reply-To: <501c18e00909181243w5036470fh1b54296af6977f44@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sat, 19 Sep 2009 04:04:55 -0700 (PDT) Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] FW: Another ARF expansion request X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 11:04:56 -0000 Yakov Shafranovich wrote: > Abuse desks that deal with ARF now are the same ones that deal with > all abuse issues and it would make sense to have a single format. I doubt someone who deals with "all abuse issues" really exists. But even then, why should they use a single format? > What I am also guessing is that IO-DEF/INCH and its XML base makes > things too heavy for most ISPs. ARF is much simpler and this is > probably why ISPs are interested in using it for all kinds of abuse > reporting [(implied:) that they do, or plan to]. +1, ^^ ARF is good as it can be read manually by moderately trained postmasters, just like DSN format. Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8JB4nOs029096 for ; Sat, 19 Sep 2009 04:04:54 -0700 Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Sat, 19 Sep 2009 13:04:47 +0200 id 00000000005DC031.000000004AB4BACF.000076B9 Message-ID: <4AB4BACF.30906@tana.it> Date: Sat, 19 Sep 2009 13:04:47 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "John R. Levine" References: <501c18e00909161142n20d30d56gf65a0a4cd1b0b1be@mail.gmail.com> <4AB24F3F.3060908@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sat, 19 Sep 2009 04:04:54 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] IETF draft on dealing with bots X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 11:04:55 -0000 John R. Levine wrote: > [...] it's really time for you to > stop wasting everyone's time trying to turn ARF into an all-purpose > reporting blob. I never meant to promote all-purpose reporting. > If you want INCH, you know where to find it. It's not here. I'm not familiar with INCH, but at a quick glance it looks as if that is just a rather sophisticated data model. Did they say anything about who, when, where, and why? Received: from [10.64.144.40] (ws101.websense.com [204.15.64.200]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8ILwY91010615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 18 Sep 2009 14:58:40 -0700 Message-ID: <4AB40289.7060207@dcrocker.net> Date: Fri, 18 Sep 2009 14:58:33 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "abuse-feedback-report@mipassoc.org" References: <4AB3C1FD.1090203@knutix.de> <501c18e00909181243w5036470fh1b54296af6977f44@mail.gmail.com> In-Reply-To: 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]); Fri, 18 Sep 2009 14:58:40 -0700 (PDT) Subject: [feedback-report] attr/val vs. xml X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 21:58:40 -0000 Murray S. Kucherawy wrote: > I suggested privately to someone else earlier today that email admins and > developers are likely quite used to parsing "name: value" (like header > fields), "tag=value" (like DKIM or MIME), and similar string formats versus > full XML work, and likely by now also have a good repertoire of library > functions ... > On the other hand, inertia is often not a good thing, and XML is generally > regarded as "the way" these days. A simple tag/value format has the advantage of being... simple. But it also is not comfortably extensible, except as a serial list of tag/values. xml has the advantage of permitting more complex structures. And that, I think, is a useful basis for choosing between them: If you are sure that you only need an extensible list, then use a trivial attribute/value format. If you expect to need any more data complexity -- such as nested values -- then xml is the way to go. (xml might be the way to go for additional reasons, but I'm suggesting a simple guideline.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8IKqEZX007178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 18 Sep 2009 13:52:20 -0700 Authentication-Results: sbh17.songbird.com; dkim=neutral header.i=@iecc.com Received: (qmail 40532 invoked from network); 18 Sep 2009 20:52:14 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 18 Sep 2009 20:52:14 -0000 Date: Fri, 18 Sep 2009 16:52:13 -0400 (EDT) From: "John R. Levine" To: "Murray S. Kucherawy" In-Reply-To: Message-ID: References: <4AB3C1FD.1090203@knutix.de> <501c18e00909181243w5036470fh1b54296af6977f44@mail.gmail.com> 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 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 18 Sep 2009 13:52:20 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] FW: Another ARF expansion request X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 20:52:20 -0000 > I suggested privately to someone else earlier today that email admins > and developers are likely quite used to parsing "name: value" (like > header fields), "tag=value" (like DKIM or MIME), and similar string > formats versus full XML work Oh, of course. But if you want an abuse format that can report, say, a list of IP addresses in a /24 that have been attacking your ssh server, with the latest timestamp of each, you're going to need something more than tag=value, and XML for all its faults has the advantage of well debugged libraries to read it and write it. It would definitely be useful to know why you decided that you couldn't use IODEF. R's, John Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8IKe09A006434 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Fri, 18 Sep 2009 13:40:05 -0700 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Fri, 18 Sep 2009 13:40:00 -0700 From: "Murray S. Kucherawy" To: Yakov Shafranovich , Tobias Knecht Date: Fri, 18 Sep 2009 13:39:58 -0700 Thread-Topic: [feedback-report] FW: Another ARF expansion request Thread-Index: Aco4mE+8hXVrzUm0QPa7vMH5Q9B/6QAB4dYA Message-ID: References: <4AB3C1FD.1090203@knutix.de> <501c18e00909181243w5036470fh1b54296af6977f44@mail.gmail.com> In-Reply-To: <501c18e00909181243w5036470fh1b54296af6977f44@mail.gmail.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" MIME-Version: 1.0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 18 Sep 2009 13:40:05 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n8IKe09A006434 Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] FW: Another ARF expansion request X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 20:40:05 -0000 > -----Original Message----- > From: Yakov Shafranovich [mailto:yakov@shaftek.org] > Sent: Friday, September 18, 2009 12:43 PM > To: Tobias Knecht > Cc: Murray S. Kucherawy; abuse-feedback-report@mipassoc.org > Subject: Re: [feedback-report] FW: Another ARF expansion request > > [...] > > What I am also guessing is that IO-DEF/INCH and its XML base makes > things too heavy for most ISPs. ARF is much simpler and this is > probably why ISPs are interested in using it for all kinds of abuse > reporting. I suggested privately to someone else earlier today that email admins and developers are likely quite used to parsing "name: value" (like header fields), "tag=value" (like DKIM or MIME), and similar string formats versus full XML work, and likely by now also have a good repertoire of library functions or other code for doing so. Though INCH might be very appropriate for general abuse reporting, the idea of converting to it may well be daunting for the average email admin these days. On the other hand, inertia is often not a good thing, and XML is generally regarded as "the way" these days. But I do understand the pressures to be timely rather than robust in expanding existing functionality. Received: from mail-vw0-f189.google.com (mail-vw0-f189.google.com [209.85.212.189]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8IJhYEn003504 for ; Fri, 18 Sep 2009 12:43:39 -0700 Received: by vws27 with SMTP id 27so1076735vws.3 for ; Fri, 18 Sep 2009 12:43:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.79.140 with SMTP id p12mr1866811vck.57.1253303014194; Fri, 18 Sep 2009 12:43:34 -0700 (PDT) In-Reply-To: <4AB3C1FD.1090203@knutix.de> References: <4AB3C1FD.1090203@knutix.de> From: Yakov Shafranovich Date: Fri, 18 Sep 2009 15:43:14 -0400 Message-ID: <501c18e00909181243w5036470fh1b54296af6977f44@mail.gmail.com> To: Tobias Knecht Content-Type: text/plain; charset=ISO-8859-1 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 18 Sep 2009 12:43:40 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n8IJhYEn003504 Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] FW: Another ARF expansion request X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 19:43:40 -0000 Tobias, I don't think that this group is not interested, rather it is a question of scope. ARF 1.0 was designed specifically for email abuse reporting and it would take a lot of changes to make it more generic. So a more correct way to put this would be is that this group does not think that this would fit within ARF as it is currently written and used. We might be better off keeping the two separate. HOWEVER, if you want to talk about taking the existing ARF, making a version 2.0 or IRF/INCH-lite, etc, as a generic abuse format, not just for email - that is a totally different animal. What it seems that you have in mind is a three part format - first part for humans, second part for machines and third part for evidence. Instead of having one ARF-1.0 report for each spam email, we are talking about one ARF-2.0 report for each incident. Of course, mapping INCH to ARF-2.0 is possible as well. The second part would have fields with data in them, and the third part would be set to whatever MIME type is used for logs and evidence. Abuse desks that deal with ARF now are the same ones that deal with all abuse issues and it would make sense to have a single format. It is just that the current format of ARF is not suitable for that. It might be prudent to fix the current format in whatever form it is used right now (1.0), publish an RFC, and move on to 2.0 format that is more generic. What I am also guessing is that IO-DEF/INCH and its XML base makes things too heavy for most ISPs. ARF is much simpler and this is probably why ISPs are interested in using it for all kinds of abuse reporting. Yakov 2009/9/18 Tobias Knecht : > Hi, > > this is just a information for people in this WG and has nothing to do > with my personal opinion. > > This is the proposal that was made by BSI (Government Security > Ministry), eco (German ISP Association), us (abusix.org) and a lot other > huge European ISPs. Thanks to Dietmar for putting it in on another way. > > Since we got the feedback from this group, that it is not wanted to add > these things into ARF, we decided on Monday (German Anti Spam Summit) > that there will be an ARF extension or a complete new standard based and > downwardly compatible to ARF for these kinds of abusive behavior. > > The feedback from European ISPs, and even some from the US was, that it > would make sense to them to change to the "new format" as soon as their > abuse departments can see more different kinds of abusive behavior > within one standardized format. > > And yes there is INCH/IODEF and we decided that it's not sufficient for > the needs we have. > > Thanks, > > Tobias > > > Murray S. Kucherawy schrieb: >> After the MAAWG conference in June, I received the following list of suggested extensions to be considered.  I've included them already in the proposed working group draft but so far the submissions were anonymous.  The author gave me permission to forward his mail to the list, and he'll be joining shortly.  Not all of them may be appropriate for ARF but they're probably worth discussing as we consider what extensions should be pursued. >> >> -----Original Message----- >> From: Dietmar Braun [mailto:dietmar.braun@netcologne.de] >> Sent: Thursday, June 25, 2009 4:48 AM >> To: Murray S. Kucherawy >> Subject: Re: FW: Another ARF expansion request >> >> Hi, >> >> Wednesday, June 17, 2009, 6:59:24 PM, you wrote: >>>> We thought about extending ARF (which now is primarily for email abuse >>>> issues) to some other types of complaints like firewall logs, scans, >>>> brute force attacks, phishing etc... >>>> >>>> What do you think about that? >> >>> It already covers phishing ("fraud"), but the other cases are >>> interesting.  Do you have some text written up already to add the new report types, etc.? >> >> We discussed the following issues: >> >> 1) drop boxes >> original mail from (mail address of the sender, required) >> arrival date (date of sending, required) >> description (text description, required) >> incidents (counter, how many times stolen information was sent to this >> adress, required) >> phishing URL (url of phishing site, optional) >> >> 2) spam sending botnet >> source IP (required) >> start date (date, required) >> end date (date, required) >> description (text, required) >> incidents (counter, required) >> >> 3) SSH attacks >> source IP (required) >> start date (date, required) >> end date (date, required) >> description (text, required) >> incidents (counter, required) >> username (username which was tried, optional) >> logdata (text log data, optional) >> >> 4) FTP attacks >> source IP (required) >> start date (date, required) >> end date (date, required) >> description (text, required) >> incidents (counter, required) >> username (username which was tried, optional) >> logdata (text log data, optional) >> >> 5) web server attacks >> source IP (required) >> date (date, required) >> description (text, required) >> malware URL (text, optional) >> malware type (text, optional) >> >> 6) Honeypot target >> source IP (required) >> date (date, required) >> description (text, required) >> malware URL (text, optional) >> malware type (text, optional) >> >> 7) Sinkholes (malware) >> source IP (required) >> date (date, required) >> description (text, required) >> URL (text, required) >> identifier (additional information, optional) >> >> 8) spam trap >> source IP (required) >> date (date, required) >> description (text, required) >> subject (text, required) >> header (text, required) >> >> 9) harvester report >> source IP (required) >> date (date, required) >> description (text, required) >> user agent (text, required) >> Operating system (text, required) >> >> 10) DDOS >> source IP (required) >> start date (date, required) >> end date (date, required) >> description (text, required) >> destination IP (IP address, required) >> >> 11) Phishing Mail >> mail from (mail address, required) >> arrival date (date, required) >> description (text, required) >> phishing URL (required) >> additional description (text, optional) >> >> 12) Others >> mail from (mail address of the complainer, required) >> date (date of the complaint, required) >> description (text, required) >> >> Perhaps this is a bit too much (you could probably merge some of the >> complaint types together to one), but just as ideas... >> >> Regards, >> Dietmar >> > > > _______________________________________________ > abuse-feedback-report mailing list > abuse-feedback-report@mipassoc.org > http://mipassoc.org/mailman/listinfo/abuse-feedback-report > > Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8IJcmGn003258 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Fri, 18 Sep 2009 12:38:54 -0700 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Fri, 18 Sep 2009 12:08:16 -0700 From: "Murray S. Kucherawy" To: Tobias Knecht Date: Fri, 18 Sep 2009 12:08:16 -0700 Thread-Topic: [feedback-report] FW: Another ARF expansion request Thread-Index: Aco4hLPx5UoATGWBReS+9gO/C1n1iQADVXsA Message-ID: References: <4AB3C1FD.1090203@knutix.de> In-Reply-To: <4AB3C1FD.1090203@knutix.de> 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" MIME-Version: 1.0 X-Greylist: Delayed for 00:30:33 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 18 Sep 2009 12:38:54 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n8IJcmGn003258 Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] FW: Another ARF expansion request X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 19:38:54 -0000 > -----Original Message----- > From: Tobias Knecht [mailto:knut@knutix.de] > Sent: Friday, September 18, 2009 10:23 AM > To: Murray S. Kucherawy > Cc: abuse-feedback-report@mipassoc.org > Subject: Re: [feedback-report] FW: Another ARF expansion request > > [...] > > And yes there is INCH/IODEF and we decided that it's not sufficient for > the needs we have. Can you go into detail as to why? If INCH is missing something, maybe they should consider adding it, and I'd like to be sure that ARF isn't missing something important as well. On the other hand, if there's a solid answer as to why INCH won't live up to the needs of this community, that's a good argument for considering some amendments to ARF. I think we would just want to be sure that we're not needlessly overlapping the work produced by other working groups by taking on ideas that appear to be out-of-scope. -MSK Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8IJNrEP002411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 18 Sep 2009 12:23:59 -0700 Authentication-Results: sbh17.songbird.com; dkim=neutral header.i=@iecc.com Received: (qmail 73329 invoked from network); 18 Sep 2009 19:23:53 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 18 Sep 2009 19:23:53 -0000 Date: Fri, 18 Sep 2009 15:23:51 -0400 (EDT) From: "John R. Levine" To: Tobias Knecht In-Reply-To: <4AB3C1FD.1090203@knutix.de> Message-ID: References: <4AB3C1FD.1090203@knutix.de> 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 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 18 Sep 2009 12:23:59 -0700 (PDT) Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] FW: Another ARF expansion request X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 19:24:00 -0000 > Since we got the feedback from this group, that it is not wanted to add > these things into ARF, we decided on Monday (German Anti Spam Summit) > that there will be an ARF extension or a complete new standard based and > downwardly compatible to ARF for these kinds of abusive behavior. Sounds great. Who is "we"? This sounds like something that needs coordination with MAAWG, since that's where you find the large ISPs. > And yes there is INCH/IODEF and we decided that it's not sufficient for > the needs we have. I don't disagree, but what in particular makes IODEF insufficient, and why would you rather start over than add report types to IODEF? R's, John Received: from vwp0043.webpack.hosteurope.de (vwp0043.webpack.hosteurope.de [87.230.60.50]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8II24M5029452 for ; Fri, 18 Sep 2009 11:02:10 -0700 Received: from p5b337e95.dip.t-dialin.net ([91.51.126.149] helo=[192.168.1.111]); authenticated by vwp0043.webpack.hosteurope.de running ExIM with esmtpa id 1MohAs-0002ni-4P; Fri, 18 Sep 2009 19:23:10 +0200 Message-ID: <4AB3C1FD.1090203@knutix.de> Date: Fri, 18 Sep 2009 19:23:09 +0200 From: Tobias Knecht User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEE9FE09675D9E693A281252F" X-bounce-key: webpack.hosteurope.de;knut@knutix.de;1253296930;90618394; X-Greylist: Delayed for 00:38:53 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 18 Sep 2009 11:02:10 -0700 (PDT) Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] FW: Another ARF expansion request X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 18:02:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEE9FE09675D9E693A281252F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, this is just a information for people in this WG and has nothing to do with my personal opinion. This is the proposal that was made by BSI (Government Security Ministry), eco (German ISP Association), us (abusix.org) and a lot other huge European ISPs. Thanks to Dietmar for putting it in on another way. Since we got the feedback from this group, that it is not wanted to add these things into ARF, we decided on Monday (German Anti Spam Summit) that there will be an ARF extension or a complete new standard based and downwardly compatible to ARF for these kinds of abusive behavior. The feedback from European ISPs, and even some from the US was, that it would make sense to them to change to the "new format" as soon as their abuse departments can see more different kinds of abusive behavior within one standardized format. And yes there is INCH/IODEF and we decided that it's not sufficient for the needs we have. Thanks, Tobias Murray S. Kucherawy schrieb: > After the MAAWG conference in June, I received the following list of su= ggested extensions to be considered. I've included them already in the p= roposed working group draft but so far the submissions were anonymous. T= he author gave me permission to forward his mail to the list, and he'll b= e joining shortly. Not all of them may be appropriate for ARF but they'r= e probably worth discussing as we consider what extensions should be purs= ued. >=20 > -----Original Message----- > From: Dietmar Braun [mailto:dietmar.braun@netcologne.de]=20 > Sent: Thursday, June 25, 2009 4:48 AM > To: Murray S. Kucherawy > Subject: Re: FW: Another ARF expansion request >=20 > Hi, >=20 > Wednesday, June 17, 2009, 6:59:24 PM, you wrote: >>> We thought about extending ARF (which now is primarily for email abus= e >>> issues) to some other types of complaints like firewall logs, scans, >>> brute force attacks, phishing etc... >>> >>> What do you think about that? >=20 >> It already covers phishing ("fraud"), but the other cases are >> interesting. Do you have some text written up already to add the new = report types, etc.? >=20 > We discussed the following issues: >=20 > 1) drop boxes > original mail from (mail address of the sender, required) > arrival date (date of sending, required) > description (text description, required) > incidents (counter, how many times stolen information was sent to this > adress, required) > phishing URL (url of phishing site, optional) >=20 > 2) spam sending botnet > source IP (required) > start date (date, required) > end date (date, required) > description (text, required) > incidents (counter, required) >=20 > 3) SSH attacks > source IP (required) > start date (date, required) > end date (date, required) > description (text, required) > incidents (counter, required) > username (username which was tried, optional) > logdata (text log data, optional) >=20 > 4) FTP attacks > source IP (required) > start date (date, required) > end date (date, required) > description (text, required) > incidents (counter, required) > username (username which was tried, optional) > logdata (text log data, optional) >=20 > 5) web server attacks > source IP (required) > date (date, required) > description (text, required) > malware URL (text, optional) > malware type (text, optional) >=20 > 6) Honeypot target > source IP (required) > date (date, required) > description (text, required) > malware URL (text, optional) > malware type (text, optional) >=20 > 7) Sinkholes (malware) > source IP (required) > date (date, required) > description (text, required) > URL (text, required) > identifier (additional information, optional) >=20 > 8) spam trap > source IP (required) > date (date, required) > description (text, required) > subject (text, required) > header (text, required) >=20 > 9) harvester report > source IP (required) > date (date, required) > description (text, required) > user agent (text, required) > Operating system (text, required) >=20 > 10) DDOS > source IP (required) > start date (date, required) > end date (date, required) > description (text, required) > destination IP (IP address, required) >=20 > 11) Phishing Mail > mail from (mail address, required) > arrival date (date, required) > description (text, required) > phishing URL (required) > additional description (text, optional) >=20 > 12) Others > mail from (mail address of the complainer, required) > date (date of the complaint, required) > description (text, required) >=20 > Perhaps this is a bit too much (you could probably merge some of the > complaint types together to one), but just as ideas... >=20 > Regards, > Dietmar >=20 --------------enigEE9FE09675D9E693A281252F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqzwf0ACgkQvB4M5yQyqDehjwCfcOvwFK84EW/JcywAa6LM5IPa gsYAoM55FX+v1lzdZDQSbp4boNxhVrqe =d0Cl -----END PGP SIGNATURE----- --------------enigEE9FE09675D9E693A281252F-- Received: from mail-vw0-f189.google.com (mail-vw0-f189.google.com [209.85.212.189]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8IHZXJO028125 for ; Fri, 18 Sep 2009 10:35:38 -0700 Received: by vws27 with SMTP id 27so1007846vws.3 for ; Fri, 18 Sep 2009 10:35:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.114.12 with SMTP id c12mr1584701vcq.109.1253295331167; Fri, 18 Sep 2009 10:35:31 -0700 (PDT) In-Reply-To: References: From: Yakov Shafranovich Date: Fri, 18 Sep 2009 13:35:11 -0400 Message-ID: <501c18e00909181035t6672a3ebt5c0052c51b2c49ed@mail.gmail.com> To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 18 Sep 2009 10:35:38 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n8IHZXJO028125 Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] FW: Another ARF expansion request X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 17:35:39 -0000 On Fri, Sep 18, 2009 at 1:20 PM, Murray S. Kucherawy wrote: >> These are all entirely reasonable things to report in automated or >> semi-automated ways, but I'd rather not try and shoehorn them all into >> a >> format designed to report single e-mail messages. >> >> I'd suggest that people look at the various INCH documments, since they >> have already addressed a lot of these same issues.  There may turn out >> to >> be some fatal problem with INCH that makes it unsuitable, but since it >> represents quite a few years' work by smart people thinking about very >> similar problems to ours, we should at least make an informed decision >> whether or not to use it. >> >> See http://www.cert.org/ietf/inch/inch.html > > +1 to all of that.  I was simply encouraging discussion. :) > I agree with both of you. I would also like to add that ARF is a "son of" RFC 3462 which is a MIME type for "Reporting of Mail System Administrative Messages". While spam botnets fit within the definition (barely), things like FTP attacks are way out of scope. > Is anyone on this list using INCH?  Or if anyone has made a conscious decision not to pursue INCH, can you share your reasons with the group? > I would also like to add that if anyone feels that INCH is too complex, they can consider making an ARF-like format for INCH (I guess INCH-lite or Incident Reporting Format / IRF?). But that again would be out of scope for this group and is something that INCH WG or the security AD would need to look into. ARF works because it is simple. Making it more complicated would dissuade people from using it. Yakov Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8IHKbeZ027172 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Fri, 18 Sep 2009 10:20:42 -0700 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Fri, 18 Sep 2009 10:20:37 -0700 From: "Murray S. Kucherawy" To: "John R. Levine" Date: Fri, 18 Sep 2009 10:20:36 -0700 Thread-Topic: [feedback-report] FW: Another ARF expansion request Thread-Index: Aco4g8C4V4WtEo4QSv+aZdy64iLP+AAAHFMA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 18 Sep 2009 10:20:42 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n8IHKbeZ027172 Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] FW: Another ARF expansion request X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 17:20:43 -0000 > These are all entirely reasonable things to report in automated or > semi-automated ways, but I'd rather not try and shoehorn them all into > a > format designed to report single e-mail messages. > > I'd suggest that people look at the various INCH documments, since they > have already addressed a lot of these same issues. There may turn out > to > be some fatal problem with INCH that makes it unsuitable, but since it > represents quite a few years' work by smart people thinking about very > similar problems to ours, we should at least make an informed decision > whether or not to use it. > > See http://www.cert.org/ietf/inch/inch.html +1 to all of that. I was simply encouraging discussion. :) Is anyone on this list using INCH? Or if anyone has made a conscious decision not to pursue INCH, can you share your reasons with the group? -MSK Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8IHGP33026857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 18 Sep 2009 10:16:31 -0700 Authentication-Results: sbh17.songbird.com; dkim=neutral header.i=@iecc.com Received: (qmail 69031 invoked from network); 18 Sep 2009 17:16:24 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 18 Sep 2009 17:16:24 -0000 Date: Fri, 18 Sep 2009 13:16:23 -0400 (EDT) From: "John R. Levine" To: "Murray S. Kucherawy" In-Reply-To: Message-ID: References: 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 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 18 Sep 2009 10:16:31 -0700 (PDT) Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] FW: Another ARF expansion request X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 17:16:31 -0000 > We discussed the following issues: > > 1) drop boxes > 2) spam sending botnet > 3) SSH attacks > 4) FTP attacks > 5) web server attacks > 6) Honeypot target > 7) Sinkholes (malware) > 8) spam trap > 9) harvester report > 10) DDOS > 11) Phishing Mail > 12) Others These are all entirely reasonable things to report in automated or semi-automated ways, but I'd rather not try and shoehorn them all into a format designed to report single e-mail messages. I'd suggest that people look at the various INCH documments, since they have already addressed a lot of these same issues. There may turn out to be some fatal problem with INCH that makes it unsuitable, but since it represents quite a few years' work by smart people thinking about very similar problems to ours, we should at least make an informed decision whether or not to use it. See http://www.cert.org/ietf/inch/inch.html R's, John Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8IGxalP025839 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Fri, 18 Sep 2009 09:59:41 -0700 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Fri, 18 Sep 2009 09:29:04 -0700 From: "Murray S. Kucherawy" To: "abuse-feedback-report@mipassoc.org" Date: Fri, 18 Sep 2009 09:29:04 -0700 Thread-Topic: Another ARF expansion request Thread-Index: Acn1issmlx6h2VQ9R5a6lQaLueKzQBC8fAZQ 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" MIME-Version: 1.0 X-Greylist: Delayed for 00:30:32 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 18 Sep 2009 09:59:41 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sbh17.songbird.com id n8IGxalP025839 Subject: [feedback-report] FW: Another ARF expansion request X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 16:59:41 -0000 After the MAAWG conference in June, I received the following list of suggested extensions to be considered. I've included them already in the proposed working group draft but so far the submissions were anonymous. The author gave me permission to forward his mail to the list, and he'll be joining shortly. Not all of them may be appropriate for ARF but they're probably worth discussing as we consider what extensions should be pursued. -----Original Message----- From: Dietmar Braun [mailto:dietmar.braun@netcologne.de] Sent: Thursday, June 25, 2009 4:48 AM To: Murray S. Kucherawy Subject: Re: FW: Another ARF expansion request Hi, Wednesday, June 17, 2009, 6:59:24 PM, you wrote: >> We thought about extending ARF (which now is primarily for email abuse >> issues) to some other types of complaints like firewall logs, scans, >> brute force attacks, phishing etc... >> >> What do you think about that? > It already covers phishing ("fraud"), but the other cases are > interesting. Do you have some text written up already to add the new report types, etc.? We discussed the following issues: 1) drop boxes original mail from (mail address of the sender, required) arrival date (date of sending, required) description (text description, required) incidents (counter, how many times stolen information was sent to this adress, required) phishing URL (url of phishing site, optional) 2) spam sending botnet source IP (required) start date (date, required) end date (date, required) description (text, required) incidents (counter, required) 3) SSH attacks source IP (required) start date (date, required) end date (date, required) description (text, required) incidents (counter, required) username (username which was tried, optional) logdata (text log data, optional) 4) FTP attacks source IP (required) start date (date, required) end date (date, required) description (text, required) incidents (counter, required) username (username which was tried, optional) logdata (text log data, optional) 5) web server attacks source IP (required) date (date, required) description (text, required) malware URL (text, optional) malware type (text, optional) 6) Honeypot target source IP (required) date (date, required) description (text, required) malware URL (text, optional) malware type (text, optional) 7) Sinkholes (malware) source IP (required) date (date, required) description (text, required) URL (text, required) identifier (additional information, optional) 8) spam trap source IP (required) date (date, required) description (text, required) subject (text, required) header (text, required) 9) harvester report source IP (required) date (date, required) description (text, required) user agent (text, required) Operating system (text, required) 10) DDOS source IP (required) start date (date, required) end date (date, required) description (text, required) destination IP (IP address, required) 11) Phishing Mail mail from (mail address, required) arrival date (date, required) description (text, required) phishing URL (required) additional description (text, optional) 12) Others mail from (mail address of the complainer, required) date (date of the complaint, required) description (text, required) Perhaps this is a bit too much (you could probably merge some of the complaint types together to one), but just as ideas... Regards, Dietmar -- NetCologne Gesellschaft fuer Telekommunikation mbH Am Coloneum 9, 50829 Koeln Geschaeftsfuehrer: Werner Hanf, Dipl.-Ing. Karl-Heinz Zankel HRB 25580, AG Koeln Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8IG9Cw9022189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 18 Sep 2009 09:09:18 -0700 Authentication-Results: sbh17.songbird.com; dkim=neutral header.i=@iecc.com Received: (qmail 61846 invoked from network); 18 Sep 2009 15:09:11 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 18 Sep 2009 15:09:11 -0000 Date: Fri, 18 Sep 2009 11:09:10 -0400 (EDT) From: "John R. Levine" To: Alessandro Vesely In-Reply-To: <4AB24F3F.3060908@tana.it> Message-ID: References: <501c18e00909161142n20d30d56gf65a0a4cd1b0b1be@mail.gmail.com> <4AB24F3F.3060908@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 X-Greylist: Delayed for 01:00:01 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 18 Sep 2009 09:09:19 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] IETF draft on dealing with bots X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 16:09:21 -0000 I think Mike's botnet draft is just dandy, but it's really time for you to stop wasting everyone's time trying to turn ARF into an all-purpose reporting blob. The authors of the botnet draft are quite familiar with ARF, and use it for their FBL reports of individual messages. I suppose one could add a flag saying "this looks like bot spam" but any ISP that doesn't already know that spam coming directly from consumer PCs means there's a bot isn't likely to do anything useful with such a flag. If you want INCH, you know where to find it. It's not here. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8HFfdaK000601 for ; Thu, 17 Sep 2009 08:41:44 -0700 Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Thu, 17 Sep 2009 17:01:19 +0200 id 00000000005DC02F.000000004AB24F3F.00007F5C Message-ID: <4AB24F3F.3060908@tana.it> Date: Thu, 17 Sep 2009 17:01:19 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Yakov Shafranovich References: <501c18e00909161142n20d30d56gf65a0a4cd1b0b1be@mail.gmail.com> In-Reply-To: <501c18e00909161142n20d30d56gf65a0a4cd1b0b1be@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Delayed for 00:40:18 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 17 Sep 2009 08:41:44 -0700 (PDT) Cc: nirmal_mody@cable.comcast.com, jason_livingood@cable.comcast.com, michael_oreirdan@cable.comcast.com, abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] IETF draft on dealing with bots X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 15:41:45 -0000 Yakov Shafranovich wrote: > Somewhat relevant to our work: > > http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-03 Yes, "botnet detection" is the #2 reporting extension in Murray's WG draft[1]. When I mentioned this I-D[2], I hypothesized the group interest could be extended to the dynamics of forwarding FBLs. At any rate, since the I-D has been already mentioned twice in this list, I take the liberty to CC to its authors. [1] http://mipassoc.org/pipermail/abuse-feedback-report/attachments/20090901/ffffcfcd/attachment.txt [2] http://mipassoc.org/pipermail/abuse-feedback-report/2009q3/000319.html In the rest of this message I just quote a few passages from the I-D. The term "ISP" is used right from the title, "Recommendations for the Remediation of Bots in ISP Networks". In section 3, "Introduction and Problem Statement", it is made explicit that it means those "providing IP connectivity, among many other services, to Internet users". That is, not specifically "mailbox providers". "Detection of Bots", section 5 of the I-D, contains the two recommendations quoted below; I think that's where the relevance to our work is more evident. b. An ISP may also communicate and share selected data, via feedback loops or other mechanisms, with various third parties. Feedback loops are consistently formatted feeds of real-time (or nearly real-time) abuse reports offered by threat data clearinghouses, security alert organizations, other ISPs, and other organizations. The data may include, but is not limited to, lists of the IP addresses computers which have or are likely to have a bot running, domain names or fully qualified domain names (FQDNs) known to host malware and/or be involved in the command and control of botnets, IP addresses know to host malware and/or be involved in the command and control of botnets, recently tested or discovered techniques or detecting or remediating bot infections, new threat vectors, and other relevant information. Good examples of this include SNDS from Microsoft, XBL and PBL from Spamhaus and the DSHIELD AS tool from the SANS Institue. e. User complaints: Because hosts infected by bots are frequently used to send spam or participate in DDoS attacks, the ISP servicing those hosts will normally receive complaints about the malicious network traffic. Those complaints may be sent to RFC2142-specified [RFC2142] role accounts, such as abuse@ or postmaster@ or to abuse or security addresses specified by the site as part of its WHOIS (or other) contact data. Received: from mail-vw0-f189.google.com (mail-vw0-f189.google.com [209.85.212.189]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8GIgvdg006666 for ; Wed, 16 Sep 2009 11:43:03 -0700 Received: by vws27 with SMTP id 27so3342255vws.3 for ; Wed, 16 Sep 2009 11:42:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.108.39 with SMTP id d39mr12806283vcp.12.1253126573272; Wed, 16 Sep 2009 11:42:53 -0700 (PDT) From: Yakov Shafranovich Date: Wed, 16 Sep 2009 14:42:33 -0400 Message-ID: <501c18e00909161142n20d30d56gf65a0a4cd1b0b1be@mail.gmail.com> To: abuse-feedback-report@mipassoc.org Content-Type: text/plain; charset=ISO-8859-1 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 16 Sep 2009 11:43:03 -0700 (PDT) Subject: [feedback-report] IETF draft on dealing with bots X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 18:43:03 -0000 Somewhat relevant to our work: http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-03 Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n898Movu001953 for ; Wed, 9 Sep 2009 01:22:56 -0700 Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 09 Sep 2009 09:42:31 +0200 id 00000000005DC031.000000004AA75C67.00003DC0 Message-ID: <4AA75C68.4020405@tana.it> Date: Wed, 09 Sep 2009 09:42:32 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "J.D. Falk" References: <4AA6BE96.90501@cybernothing.org> In-Reply-To: <4AA6BE96.90501@cybernothing.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Delayed for 00:40:18 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 09 Sep 2009 01:22:56 -0700 (PDT) Cc: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] ESP (was Re: ARF working group interest?) X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 08:22:58 -0000 J.D. Falk wrote: > I'm partial to the term "mailbox provider," but that's still relatively new. +1, as it is less ambiguous. Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n88L5vOI001226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 8 Sep 2009 14:06:03 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@cybernothing.org Received: from rpco-jdmacbook.local (63-207-218-130.ded.pacbell.net [63.207.218.130]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id n88KTA51012504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 8 Sep 2009 14:29:12 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net n88KTA51012504 Message-ID: <4AA6BE96.90501@cybernothing.org> Date: Tue, 08 Sep 2009 13:29:10 -0700 From: "J.D. Falk" User-Agent: Postbox 1.0b15 (Macintosh/2009081714) MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Delayed for 00:36:44 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 08 Sep 2009 14:06:03 -0700 (PDT) Subject: [feedback-report] ESP (was Re: ARF working group interest?) X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 21:06:04 -0000 Alessandro Vesely wrote: > J.D. Falk wrote: >> I believe your use of the acronym "ESP" may be different from others'. > > I use it for Email Service Provider, what is it being confused with? Many of the folks who use ARF today use "ESP" to describe companies which send bulk email on behalf of other companies. That's an email service, but I don't think it's the email service you're talking about. There are a lot of other email services, too. I'm partial to the term "mailbox provider," but that's still relatively new. -- J.D. Falk Return Path Inc http://www.returnpath.net/ Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n85KfuwI012821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 5 Sep 2009 13:42:02 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 88877 invoked from network); 5 Sep 2009 20:41:55 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 5 Sep 2009 20:41:55 -0000 Date: Sat, 5 Sep 2009 16:41:55 -0400 (EDT) From: "John R. Levine" To: Steve Atkins In-Reply-To: <630751C6-59BA-476C-BB05-BCA522B66EA0@word-to-the-wise.com> Message-ID: References: <4AA023AE.1010209@cybernothing.org> <501c18e00909031958h3addab0hf1e1db692b0eab7b@mail.gmail.com> <4AA12793.6000404@corp.aol.com> <501c18e00909041023v4a172007i6ebdb032149e5a85@mail.gmail.com> <915ED7B8-D623-4A7A-8433-52114FFE8FFB@word-to-the-wise.com> <630751C6-59BA-476C-BB05-BCA522B66EA0@word-to-the-wise.com> 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 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sat, 05 Sep 2009 13:42:02 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] end user submission of feedback (was Re: ARF working group interest?) X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2009 20:42:02 -0000 >> I think that's OK give or take the SMTP AUTH issue. > I was assuming that the magic email address would be different for > each message, and potentially long and full of crypto and message ids > and user identifiers and per-message metadata and secret cookies and > hashes and things. (I may just have been doing too much work with VERP > recently). Oh, duh, of course. That should work fine. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n85K38sL010849 for ; Sat, 5 Sep 2009 13:03:13 -0700 Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 511B98073E for ; Sat, 5 Sep 2009 13:02:48 -0700 (PDT) Message-Id: <630751C6-59BA-476C-BB05-BCA522B66EA0@word-to-the-wise.com> From: Steve Atkins To: ARF mailing list In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 5 Sep 2009 13:03:06 -0700 References: <4AA023AE.1010209@cybernothing.org> <501c18e00909031958h3addab0hf1e1db692b0eab7b@mail.gmail.com> <4AA12793.6000404@corp.aol.com> <501c18e00909041023v4a172007i6ebdb032149e5a85@mail.gmail.com> <915ED7B8-D623-4A7A-8433-52114FFE8FFB@word-to-the-wise.com> X-Mailer: Apple Mail (2.936) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sat, 05 Sep 2009 13:03:13 -0700 (PDT) Subject: Re: [feedback-report] end user submission of feedback (was Re: ARF working group interest?) X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2009 20:03:13 -0000 On Sep 5, 2009, at 10:12 AM, John R. Levine wrote: >> as trivial to implement as a header, added by the mailbox provider >> MDA, >> with "Feedback-Reports-To: " and a TiS button >> that >> sends the associated message as a MIME attachment to that email >> address would work[1]. > > I think that's OK give or take the SMTP AUTH issue. If I were an > ISP, I would think it were nice if I could be reasonably sure that I > knew who the reports were coming from. I suppose we could wave our > hands and say to use whatever outgoing channel matches the incoming > channel, and that would work almost as well as something a lot more > complicated. We could give a hint to the ISP that they might want > to put in some other header that they could use to recognize which > of their customers the mail was delivered to. I was assuming that the magic email address would be different for each message, and potentially long and full of crypto and message ids and user identifiers and per-message metadata and secret cookies and hashes and things. (I may just have been doing too much work with VERP recently). Cheers, Steve Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n85HCC7P004314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 5 Sep 2009 10:12:18 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 25619 invoked from network); 5 Sep 2009 17:12:12 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 5 Sep 2009 17:12:12 -0000 Date: Sat, 5 Sep 2009 13:12:12 -0400 (EDT) From: "John R. Levine" To: Steve Atkins In-Reply-To: <915ED7B8-D623-4A7A-8433-52114FFE8FFB@word-to-the-wise.com> Message-ID: References: <4AA023AE.1010209@cybernothing.org> <501c18e00909031958h3addab0hf1e1db692b0eab7b@mail.gmail.com> <4AA12793.6000404@corp.aol.com> <501c18e00909041023v4a172007i6ebdb032149e5a85@mail.gmail.com> <915ED7B8-D623-4A7A-8433-52114FFE8FFB@word-to-the-wise.com> 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 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sat, 05 Sep 2009 10:12:19 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] end user submission of feedback (was Re: ARF working group interest?) X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2009 17:12:19 -0000 > as trivial to implement as a header, added by the mailbox provider MDA, > with "Feedback-Reports-To: " and a TiS button that > sends the associated message as a MIME attachment to that email > address would work[1]. I think that's OK give or take the SMTP AUTH issue. If I were an ISP, I would think it were nice if I could be reasonably sure that I knew who the reports were coming from. I suppose we could wave our hands and say to use whatever outgoing channel matches the incoming channel, and that would work almost as well as something a lot more complicated. We could give a hint to the ISP that they might want to put in some other header that they could use to recognize which of their customers the mail was delivered to. R's, John Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n85GAYRx000878 for ; Sat, 5 Sep 2009 09:10:39 -0700 Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id CCE374F8007 for ; Sat, 5 Sep 2009 09:10:14 -0700 (PDT) Message-Id: <915ED7B8-D623-4A7A-8433-52114FFE8FFB@word-to-the-wise.com> From: Steve Atkins To: ARF mailing list In-Reply-To: <501c18e00909041023v4a172007i6ebdb032149e5a85@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 5 Sep 2009 09:10:33 -0700 References: <4AA023AE.1010209@cybernothing.org> <501c18e00909031958h3addab0hf1e1db692b0eab7b@mail.gmail.com> <4AA12793.6000404@corp.aol.com> <501c18e00909041023v4a172007i6ebdb032149e5a85@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Sat, 05 Sep 2009 09:10:39 -0700 (PDT) Subject: Re: [feedback-report] end user submission of feedback (was Re: ARF working group interest?) X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2009 16:10:39 -0000 On Sep 4, 2009, at 10:23 AM, Yakov Shafranovich wrote: > On Fri, Sep 4, 2009 at 10:43 AM, Michael > Adkins wrote: >> Yakov Shafranovich wrote: >>> Are we talking about users sending reports to their own ISP, or to >>> any ISP? >>> >> To the mailbox provider for the specific account the spam was sent >> to. >> > > Thanks Michael. > > If so, why not an SMTP SUBMIT extension? It's not unusual for inbound mail and outbound mail to be unrelated, so there may not be any SMTP connection related to the mailbox. That doesn't mean that an SMTP SUBMIT extension (or one of the simpler SMTP level ideas) isn't interesting to look at, but it wouldn't be usable in all cases. I'm not sure that attempting to support IMAP, POP3, deltasync and so on makes any sense either. I'd rather build something that wasn't intimately tied to a particular connection that an MUA happened to have open, rather relying on something that any MUA can implement easily. Depending on how much we cared about the threat model, something as trivial to implement as a header, added by the mailbox provider MDA, with "Feedback-Reports-To: " and a TiS button that sends the associated message as a MIME attachment to that email address would work[1]. Cheers, Steve [1] Yes, this can be spoofed by spammers. But, (A), I'm not necessarily sure that's a terrible thing and (B) it can be protected against that fairly trivially. Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n854I7wI024779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 4 Sep 2009 21:18:13 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 45718 invoked from network); 5 Sep 2009 04:18:04 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 5 Sep 2009 04:18:04 -0000 Date: Sat, 5 Sep 2009 00:18:03 -0400 (EDT) From: "John R. Levine" To: Yakov Shafranovich In-Reply-To: <501c18e00909041023v4a172007i6ebdb032149e5a85@mail.gmail.com> Message-ID: References: <4AA023AE.1010209@cybernothing.org> <501c18e00909031958h3addab0hf1e1db692b0eab7b@mail.gmail.com> <4AA12793.6000404@corp.aol.com> <501c18e00909041023v4a172007i6ebdb032149e5a85@mail.gmail.com> 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 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 04 Sep 2009 21:18:13 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] end user submission of feedback (was Re: ARF working group interest?) X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2009 04:18:13 -0000 >> To the mailbox provider for the specific account the spam was sent to. > If so, why not an SMTP SUBMIT extension? Not a bad thought, although I worry that there are accounts with inbound POP or IMAP servers but no outbound server, because they either don't expect you to send mail from that address, or they expect you to have some other way to send it. Received: from mail-vw0-f189.google.com (mail-vw0-f189.google.com [209.85.212.189]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n84HNZpJ023899 for ; Fri, 4 Sep 2009 10:23:40 -0700 Received: by vws27 with SMTP id 27so813305vws.3 for ; Fri, 04 Sep 2009 10:23:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.79.168 with SMTP id p40mr15878348vck.110.1252085014133; Fri, 04 Sep 2009 10:23:34 -0700 (PDT) In-Reply-To: <4AA12793.6000404@corp.aol.com> References: <4AA023AE.1010209@cybernothing.org> <501c18e00909031958h3addab0hf1e1db692b0eab7b@mail.gmail.com> <4AA12793.6000404@corp.aol.com> From: Yakov Shafranovich Date: Fri, 4 Sep 2009 13:23:14 -0400 Message-ID: <501c18e00909041023v4a172007i6ebdb032149e5a85@mail.gmail.com> To: Michael Adkins Content-Type: text/plain; charset=ISO-8859-1 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 04 Sep 2009 10:23:40 -0700 (PDT) Cc: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] end user submission of feedback (was Re: ARF working group interest?) X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 17:23:40 -0000 On Fri, Sep 4, 2009 at 10:43 AM, Michael Adkins wrote: > Yakov Shafranovich wrote: >> Are we talking about users sending reports to their own ISP, or to any ISP? >> > To the mailbox provider for the specific account the spam was sent to. > Thanks Michael. If so, why not an SMTP SUBMIT extension? Yakov Received: from omr-m35.mx.aol.com (omr-m35.mx.aol.com [64.12.143.147]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n84EdMCg014662 for ; Fri, 4 Sep 2009 07:39:28 -0700 Received: from AOLDTCMEH01.ad.office.aol.com (aoldtcmeh01.office.aol.com [10.180.121.20]) by omr-m35.mx.aol.com (v117.7) with ESMTP id MAILOMRM352-7f394aa1269211f; Fri, 04 Sep 2009 10:39:14 -0400 Received: from AOLMTCMEI01.ad.office.aol.com ([10.178.3.18]) by AOLDTCMEH01.ad.office.aol.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 10:36:42 -0400 Received: from [10.181.80.41] ([10.178.3.10]) by AOLMTCMEI01.ad.office.aol.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 10:36:42 -0400 Message-ID: <4AA12793.6000404@corp.aol.com> Date: Fri, 04 Sep 2009 10:43:31 -0400 From: Michael Adkins User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Yakov Shafranovich References: <4AA023AE.1010209@cybernothing.org> <501c18e00909031958h3addab0hf1e1db692b0eab7b@mail.gmail.com> In-Reply-To: <501c18e00909031958h3addab0hf1e1db692b0eab7b@mail.gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Sep 2009 14:36:42.0756 (UTC) FILETIME=[1EF55440:01CA2D6D] X-AOL-IP: 10.180.121.20 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 04 Sep 2009 07:39:28 -0700 (PDT) Cc: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] end user submission of feedback (was Re: ARF working group interest?) X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 14:39:28 -0000 Yakov Shafranovich wrote: > Are we talking about users sending reports to their own ISP, or to any ISP? > > Yakov > To the mailbox provider for the specific account the spam was sent to. > On Thu, Sep 3, 2009 at 4:14 PM, J.D. Falk wrote: > >> Michael Adkins wrote: >> >> >>> So would there be interest in a standard way for 3rd party mail clients >>> to know where to send a report to their provider, who could then send it >>> on to the originator if they chose to? >>> >> I think that would be a very appropriate thing for this WG to address. >> >> It could be extremely simple >> - authenticated SMTP submission of a raw message to a preconfigured address >> - a way for the MUA to auto-discover the submission address >> >> -- >> J.D. Falk >> Return Path Inc >> http://www.returnpath.net/ >> _______________________________________________ >> abuse-feedback-report mailing list >> abuse-feedback-report@mipassoc.org >> http://mipassoc.org/mailman/listinfo/abuse-feedback-report >> >> > _______________________________________________ > abuse-feedback-report mailing list > abuse-feedback-report@mipassoc.org > http://mipassoc.org/mailman/listinfo/abuse-feedback-report > Received: from todzilla.mail.rr.com (todzilla.mail.rr.com [24.28.207.21]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n84CfVZC007333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 4 Sep 2009 05:41:37 -0700 Received: from todzilla.mail.rr.com (todzilla.mail.rr.com [127.0.0.1]) by todzilla.mail.rr.com (8.14.2/8.14.2) with ESMTP id n84CfVxx022030 for ; Fri, 4 Sep 2009 08:41:31 -0400 Received: (from therr@localhost) by todzilla.mail.rr.com (8.14.2/8.14.2/Submit) id n84CfVGb022029 for abuse-feedback-report@mipassoc.org; Fri, 4 Sep 2009 08:41:31 -0400 X-Authentication-Warning: todzilla.mail.rr.com: therr set sender to therr@security.rr.com using -f Date: Fri, 4 Sep 2009 08:41:31 -0400 From: Todd Herr To: abuse-feedback-report@mipassoc.org Message-ID: <20090904124130.GA21820@todzilla.mail.rr.com> References: <46BDEC4E-BDF4-456C-AF33-04BF81794BEF@word-to-the-wise.com> <4A9FD3D0.1030802@corp.aol.com> <20090903165135.GA26570@todzilla.mail.rr.com> <4AA0090C.4070507@tana.it> <4AA02462.2040605@cybernothing.org> <4AA0F375.4080407@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AA0F375.4080407@tana.it> User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 04 Sep 2009 05:41:37 -0700 (PDT) Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 12:41:38 -0000 On Fri, Sep 04, 2009 at 01:01:09PM +0200, Alessandro Vesely wrote: > J.D. Falk wrote: > > I believe your use of the acronym "ESP" may be different from others'. > > I use it for Email Service Provider, what is it being confused with? > > I use it to differentiate from ISPs, who provide cables, routing, and > global IP ranges. It's consistent with the IP vs domain dichotomy. Here in the US, the term ESP also means Email Service Provider, but it refers to a class of company that's usually engaged by email senders with a need to send a quantity of commercial email and a desire to do the job right. In the context of the whole ARF discussion, ESPs in the US would, on behalf of their clients, be recievers of FBL reports, not producers of them. An ISP here in the US, along with, for instance, Hotmail, Yahoo, and Gmail, would fall into a class of company called "mailbox providers", and their customers would be the ones generating complaints that could be turned into FBL reports and sent along to the proper reporting destination. -- Todd Herr Principal Engineer and Postmaster V: 703.345.2447 Road Runner Email Operations M: 571.287.0366 therr@security.rr.com AIM: RRMailToddHerr Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n84BDjNP003891 for ; Fri, 4 Sep 2009 04:13:50 -0700 Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Fri, 04 Sep 2009 13:13:44 +0200 id 00000000005DC02F.000000004AA0F668.00004D16 Message-ID: <4AA0F668.3020807@tana.it> Date: Fri, 04 Sep 2009 13:13:44 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "John R. Levine" References: <4A9E9D15.5020903@tana.it> <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> <20090902205039.GA1179@todzilla.mail.rr.com> <46BDEC4E-BDF4-456C-AF33-04BF81794BEF@word-to-the-wise.com> <4A9FD3D0.1030802@corp.aol.com> <20090903165135.GA26570@todzilla.mail.rr.com> <4AA00797.5060702@corp.aol.com> <3D348242-BC89-433F-AA87-5071EAD5DFAE@word-to-the-wise.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 04 Sep 2009 04:13:50 -0700 (PDT) Cc: ARF mailing list Subject: [feedback-report] ARF submission and forwarding X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 11:13:53 -0000 John R. Levine wrote: > I can think of two general approaches. One somehow adds the report > address to the per-account config, the other to the messages. I'd prefer > to do the config, except that config is already a painful swamp which > isn't likely to be drained any time soon. It could default to abuse@domain, where "domain" is obtained from the current identity of the user. In the simple cases, that implies submission through an already configured MSA, which is also (near to) the target of the message. Advanced users, with multiple accounts at different ESPs, may have to configure ARF-specific MSAs to avoid unnecessary filtering. Hence, at the ARF target, the first decision about a report being received is to establish whether it is of local concern, which normally is the case for FBL feeds. However, spam being reported by local users may well have originated from the same domain. This justifies the usage of the same abuse@ role account. Reports about non-local spam, may be forwarded directly or submitted to various third parties, as Todd has described. IMHO, this network of FBL exchanges is the most crippled part of the game, as it's difficult to establish and maintain. Postmaster should rather concentrate on clearing local reports. Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n84B1BGt002652 for ; Fri, 4 Sep 2009 04:01:17 -0700 Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Fri, 04 Sep 2009 13:01:10 +0200 id 00000000005DC02F.000000004AA0F376.0000145D Message-ID: <4AA0F375.4080407@tana.it> Date: Fri, 04 Sep 2009 13:01:09 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org References: <4A9E9D15.5020903@tana.it> <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> <20090902205039.GA1179@todzilla.mail.rr.com> <46BDEC4E-BDF4-456C-AF33-04BF81794BEF@word-to-the-wise.com> <4A9FD3D0.1030802@corp.aol.com> <20090903165135.GA26570@todzilla.mail.rr.com> <4AA0090C.4070507@tana.it> <4AA02462.2040605@cybernothing.org> In-Reply-To: <4AA02462.2040605@cybernothing.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Fri, 04 Sep 2009 04:01:17 -0700 (PDT) Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 11:01:17 -0000 J.D. Falk wrote: > I believe your use of the acronym "ESP" may be different from others'. I use it for Email Service Provider, what is it being confused with? I use it to differentiate from ISPs, who provide cables, routing, and global IP ranges. It's consistent with the IP vs domain dichotomy. Received: from mail-vw0-f189.google.com (mail-vw0-f189.google.com [209.85.212.189]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8435lIk013377 for ; Thu, 3 Sep 2009 20:05:53 -0700 Received: by vws27 with SMTP id 27so456021vws.3 for ; Thu, 03 Sep 2009 20:05:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.108.233 with SMTP id g41mr648767vcp.2.1252033547060; Thu, 03 Sep 2009 20:05:47 -0700 (PDT) In-Reply-To: <4AA03BE4.3060802@knutix.de> References: <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> <46BDEC4E-BDF4-456C-AF33-04BF81794BEF@word-to-the-wise.com> <4A9FD3D0.1030802@corp.aol.com> <20090903165135.GA26570@todzilla.mail.rr.com> <4AA0090C.4070507@tana.it> <20090903212241.GA4016@todzilla.mail.rr.com> <4AA03BE4.3060802@knutix.de> From: Yakov Shafranovich Date: Thu, 3 Sep 2009 23:05:27 -0400 Message-ID: <501c18e00909032005k78bb818dl2eb462285bb717ec@mail.gmail.com> To: Tobias Knecht Content-Type: text/plain; charset=ISO-8859-1 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 03 Sep 2009 20:05:53 -0700 (PDT) Cc: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 03:05:53 -0000 2009/9/3 Tobias Knecht : > > I'm not sure if I understand this discussion right. We are talking about > a format. A format that describes the look of data. We are not talking > about processes and business logic. > > If an ISP receives complaints from different sources, the trustlevel is > a subjective estimation. Sending it to a special address or having an > agreement does not predict that they are more trusted. Most of the time > this will be the case, but it's is not exclusively that way. Some > European ISPs rate "trusted" complaints different, because some > "trusted" senders are more trusted than others. > > So the decision on how to handle the incoming complaints is a process > that has to be defined in the business logic of the receiver and nowhere > else. > > IMHO ARF is just the format to exchange data. And I concur - ARF is just a format. As the current draft states: " This document only defines the format and [MIME] content type to be used for these reports. Determination of where these reports should be sent, how trust among report generators and report recipients is established, and reports related to more than one message are outside the scope of this document. It is assumed that best practices will evolve over time, and will be codified in future documents. " It might be a good idea is to write up a parallel informational RFCs on best practices for using ARF or reporting spam, especially if we can draw from the wide variety of experiences provided here and via MAAWG. I believe that Carl Hutzler (AOL postmaster at the time) tried to do something similar for spam operations in general and it was published as RFC 5068: http://tools.ietf.org/html/rfc5068 Yakov Received: from mail-vw0-f189.google.com (mail-vw0-f189.google.com [209.85.212.189]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n8432BwZ013174 for ; Thu, 3 Sep 2009 20:02:17 -0700 Received: by vws27 with SMTP id 27so454718vws.3 for ; Thu, 03 Sep 2009 20:02:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.88.25 with SMTP id y25mr14540696vcl.66.1252033331124; Thu, 03 Sep 2009 20:02:11 -0700 (PDT) From: Yakov Shafranovich Date: Thu, 3 Sep 2009 23:01:51 -0400 Message-ID: <501c18e00909032001k11be0cabkb6b810efc06c2ed0@mail.gmail.com> To: ARF mailing list Content-Type: multipart/mixed; boundary=0016e64714e2f2e2620472b7b950 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 03 Sep 2009 20:02:17 -0700 (PDT) Subject: [feedback-report] Munging ARF reports X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 03:02:17 -0000 --0016e64714e2f2e2620472b7b950 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We has this discussion several years ago, primarily with AOL. The compromise at the time appears in section 2d of the current draft as follows: " While some operators may choose to modify or redact this portion for privacy or legal reasons, it is RECOMMENDED that the entire original email message be included without any modification as such modifications can impede forensic work by the recipient of this report. " I believe that the current language should address all sides. Yakov ---------- Forwarded message ---------- From: Tobias Knecht John R. Levine schrieb: >>> Sorry, but that's just wrong. =A0Several large ISPs send me fully >>> unredacted >>> copies of messages in FBL reports. >> >> Sending unredacted complaints to a third party with personal information >> of end-users is an absolute no-go in Germany. > > Perhaps, but the IETF most definitely does not offer legal advice. I just wanted to mention that it is not wise to put munging rules into the draft, if they will make legal problems in future. --0016e64714e2f2e2620472b7b950 Content-Type: application/pgp-signature; name="signature.asc" Content-Disposition: attachment; filename="signature.asc" Content-Transfer-Encoding: base64 X-Attachment-Id: 0.0.1 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC45IChHTlUv TGludXgpCkNvbW1lbnQ6IFVzaW5nIEdudVBHIHdpdGggTW96aWxsYSAtIGh0dHA6Ly9lbmlnbWFp bC5tb3pkZXYub3JnCgppRVlFQVJFQ0FBWUZBa3FnTnNNQUNna1F2QjRNNXlReXFEZlY4UUNlUFVP ZDJ4WDVaaTdCelhCYnVsZnIrb3FlCkEvTUFvTUJZZHRlQjZxU1Z2YzA2Mm9MOVU3YmUvTVRTCj1m bjBxCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --0016e64714e2f2e2620472b7b950-- Received: from mail-vw0-f189.google.com (mail-vw0-f189.google.com [209.85.212.189]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n842wgM4012877 for ; Thu, 3 Sep 2009 19:58:48 -0700 Received: by vws27 with SMTP id 27so453472vws.3 for ; Thu, 03 Sep 2009 19:58:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.10.133 with SMTP id p5mr14579197vcp.119.1252033122284; Thu, 03 Sep 2009 19:58:42 -0700 (PDT) In-Reply-To: <4AA023AE.1010209@cybernothing.org> References: <4AA023AE.1010209@cybernothing.org> From: Yakov Shafranovich Date: Thu, 3 Sep 2009 22:58:22 -0400 Message-ID: <501c18e00909031958h3addab0hf1e1db692b0eab7b@mail.gmail.com> To: "J.D. Falk" Content-Type: text/plain; charset=ISO-8859-1 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 03 Sep 2009 19:58:48 -0700 (PDT) Cc: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] end user submission of feedback (was Re: ARF working group interest?) X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 02:58:48 -0000 Are we talking about users sending reports to their own ISP, or to any ISP? Yakov On Thu, Sep 3, 2009 at 4:14 PM, J.D. Falk wrote: > Michael Adkins wrote: > >> So would there be interest in a standard way for 3rd party mail clients >> to know where to send a report to their provider, who could then send it >> on to the originator if they chose to? > > I think that would be a very appropriate thing for this WG to address. > > It could be extremely simple > - authenticated SMTP submission of a raw message to a preconfigured address > - a way for the MUA to auto-discover the submission address > > -- > J.D. Falk > Return Path Inc > http://www.returnpath.net/ > _______________________________________________ > abuse-feedback-report mailing list > abuse-feedback-report@mipassoc.org > http://mipassoc.org/mailman/listinfo/abuse-feedback-report > Received: from vwp0043.webpack.hosteurope.de (vwp0043.webpack.hosteurope.de [87.230.60.50]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n83LvvJG032691 for ; Thu, 3 Sep 2009 14:58:02 -0700 Received: from p5b337639.dip.t-dialin.net ([91.51.118.57] helo=[192.168.1.115]); authenticated by vwp0043.webpack.hosteurope.de running ExIM with esmtpa id 1MjKJY-00023s-OX; Thu, 03 Sep 2009 23:57:56 +0200 Message-ID: <4AA03BE4.3060802@knutix.de> Date: Thu, 03 Sep 2009 23:57:56 +0200 From: Tobias Knecht User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org References: <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> <20090902205039.GA1179@todzilla.mail.rr.com> <46BDEC4E-BDF4-456C-AF33-04BF81794BEF@word-to-the-wise.com> <4A9FD3D0.1030802@corp.aol.com> <20090903165135.GA26570@todzilla.mail.rr.com> <4AA0090C.4070507@tana.it> <20090903212241.GA4016@todzilla.mail.rr.com> In-Reply-To: <20090903212241.GA4016@todzilla.mail.rr.com> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4FC9E1F175FFC05CC12808D9" X-bounce-key: webpack.hosteurope.de;knut@knutix.de;1252015082;daf9fe03; X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 03 Sep 2009 14:58:03 -0700 (PDT) Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 21:58:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4FC9E1F175FFC05CC12808D9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > RFCs aren't gonna trump lawyers' interpretations here. However, mailer= s=20 > can (and probably should, where appropriate) use VERPs, X- headers, or = > other header information from the complaint to identify the redacted > information from their own logs. Full Ack. >> Should ESPs verify that the stuff is actually spam or just forward it?= >=20 > Verification is not a scalable solution, IMHO. The staff required to > read every complaint might run to the dozens, if not hundreds, and then= =20 > separating the obvious spam from the might be spam (e.g., it's bulk, bu= t=20 > do you know whether or not your customer signed up for this mailing?)=20 > from the clearly not spam would require resources that most ISPs don't = > and won't have. Besides, who would want a job for which the descriptio= n > is "Read spam complaints all day"? Full Ack. I'm not sure if I understand this discussion right. We are talking about a format. A format that describes the look of data. We are not talking about processes and business logic. If an ISP receives complaints from different sources, the trustlevel is a subjective estimation. Sending it to a special address or having an agreement does not predict that they are more trusted. Most of the time this will be the case, but it's is not exclusively that way. Some European ISPs rate "trusted" complaints different, because some "trusted" senders are more trusted than others. So the decision on how to handle the incoming complaints is a process that has to be defined in the business logic of the receiver and nowhere else. IMHO ARF is just the format to exchange data. Tobias --------------enig4FC9E1F175FFC05CC12808D9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqgO+QACgkQvB4M5yQyqDchIgCdFj6ybtTryQMoPH2p9ZhyD58p qrkAoIWuTVnV/Oz7MDb3jHXVXJ+aVRSl =UkB4 -----END PGP SIGNATURE----- --------------enig4FC9E1F175FFC05CC12808D9-- Received: from vwp0043.webpack.hosteurope.de (vwp0043.webpack.hosteurope.de [87.230.60.50]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n83La48G031795 for ; Thu, 3 Sep 2009 14:36:10 -0700 Received: from p5b337639.dip.t-dialin.net ([91.51.118.57] helo=[192.168.1.115]); authenticated by vwp0043.webpack.hosteurope.de running ExIM with esmtpa id 1MjJyN-0000lc-SP; Thu, 03 Sep 2009 23:36:04 +0200 Message-ID: <4AA036C3.8070607@knutix.de> Date: Thu, 03 Sep 2009 23:36:03 +0200 From: Tobias Knecht User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: ARF mailing list References: <4A9E9D15.5020903@tana.it> <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> <20090902205039.GA1179@todzilla.mail.rr.com> <46BDEC4E-BDF4-456C-AF33-04BF81794BEF@word-to-the-wise.com> <4A9FD3D0.1030802@corp.aol.com> <20090903165135.GA26570@todzilla.mail.rr.com> <4AA0090C.4070507@tana.it> <4AA024BE.7080507@knutix.de> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig03352E751205BD98A60236C2" X-bounce-key: webpack.hosteurope.de;knut@knutix.de;1252013770;65bc2bf1; X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 03 Sep 2009 14:36:10 -0700 (PDT) Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 21:36:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig03352E751205BD98A60236C2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable John R. Levine schrieb: >>> Sorry, but that's just wrong. Several large ISPs send me fully >>> unredacted >>> copies of messages in FBL reports. >> >> Sending unredacted complaints to a third party with personal informati= on >> of end-users is an absolute no-go in Germany. >=20 > Perhaps, but the IETF most definitely does not offer legal advice. I just wanted to mention that it is not wise to put munging rules into the draft, if they will make legal problems in future. Tobias --------------enig03352E751205BD98A60236C2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqgNsMACgkQvB4M5yQyqDfV8QCePUOd2xX5Zi7BzXBbulfr+oqe A/MAoMBYdteB6qSVvc062oL9U7be/MTS =fn0q -----END PGP SIGNATURE----- --------------enig03352E751205BD98A60236C2-- Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n83LTIji031525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 Sep 2009 14:29:24 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 61747 invoked from network); 3 Sep 2009 21:29:18 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 3 Sep 2009 21:29:18 -0000 Date: Thu, 3 Sep 2009 17:29:17 -0400 (EDT) From: "John R. Levine" To: Tobias Knecht In-Reply-To: <4AA024BE.7080507@knutix.de> Message-ID: References: <4A9E9D15.5020903@tana.it> <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> <20090902205039.GA1179@todzilla.mail.rr.com> <46BDEC4E-BDF4-456C-AF33-04BF81794BEF@word-to-the-wise.com> <4A9FD3D0.1030802@corp.aol.com> <20090903165135.GA26570@todzilla.mail.rr.com> <4AA0090C.4070507@tana.it> <4AA024BE.7080507@knutix.de> 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 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 03 Sep 2009 14:29:24 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 21:29:25 -0000 >> Sorry, but that's just wrong. Several large ISPs send me fully unredacted >> copies of messages in FBL reports. > > Sending unredacted complaints to a third party with personal information > of end-users is an absolute no-go in Germany. Perhaps, but the IETF most definitely does not offer legal advice. R's, John Received: from todzilla.mail.rr.com (todzilla.mail.rr.com [24.28.207.21]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n83LMiPh031267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 Sep 2009 14:22:50 -0700 Received: from todzilla.mail.rr.com (todzilla.mail.rr.com [127.0.0.1]) by todzilla.mail.rr.com (8.14.2/8.14.2) with ESMTP id n83LMftg004351 for ; Thu, 3 Sep 2009 17:22:41 -0400 Received: (from therr@localhost) by todzilla.mail.rr.com (8.14.2/8.14.2/Submit) id n83LMfOS004350 for abuse-feedback-report@mipassoc.org; Thu, 3 Sep 2009 17:22:41 -0400 X-Authentication-Warning: todzilla.mail.rr.com: therr set sender to therr@security.rr.com using -f Date: Thu, 3 Sep 2009 17:22:41 -0400 From: Todd Herr To: abuse-feedback-report@mipassoc.org Message-ID: <20090903212241.GA4016@todzilla.mail.rr.com> References: <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> <20090902205039.GA1179@todzilla.mail.rr.com> <46BDEC4E-BDF4-456C-AF33-04BF81794BEF@word-to-the-wise.com> <4A9FD3D0.1030802@corp.aol.com> <20090903165135.GA26570@todzilla.mail.rr.com> <4AA0090C.4070507@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AA0090C.4070507@tana.it> User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 03 Sep 2009 14:22:50 -0700 (PDT) Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 21:22:50 -0000 On Thu, Sep 03, 2009 at 08:21:00PM +0200, Alessandro Vesely wrote: > John R. Levine wrote: >>>> * Where do you send them if you're trusted, or if you're untrusted >>> >>> In my experience, we only send FBL reports to those who've asked >>> for them (and been approved for enrollment in our FBL) > > Would you expand on how do you approve enrollments? (Fully/partially > automated WHOIS lookup, I'd guess.) And how do ESPs find out where to > ask for enrollment? We (Road Runner) have our own criteria that we don't publish, but we do try to provide a reason for rejecting any IPs that we reject in the message sent to the requester regarding their application being processed. Other ISPs have other criteria that may or may not match our own. One place to find out about what FBLs are currently available is here: http://www.spamhaus.org/faq/answers.lasso?section=ISP%20Spam%20Issues#119 > >> This is a good point. FBL data (other than AOL) tends to be unredacted >> because you know who you're sending it to. > > The last thing one would do is to confirm users' addresses, or betray > honeypots. Will guidance for munging be part of the ARF spec? AOL redacts because AOL's lawyers tell them they have to. Road Runner redacts because our lawyers tell us we have to, but for different reasons than AOL's lawyers. Road Runner is Time Warner Cable's High Speed Data service, and our lawyers think the 1984 US Cable Privacy Act requires that we redact email addresses. Other cable companies in the US that offer FBLs may have different interpretations of that same law. RFCs aren't gonna trump lawyers' interpretations here. However, mailers can (and probably should, where appropriate) use VERPs, X- headers, or other header information from the complaint to identify the redacted information from their own logs. > >>> - Mailbox holders who are clued enough to read headers and make a >>> reasonable guess at the right place to which to complain >>> - Mailbox holders who aren't clued enough to read headers >>> >>> For the latter two classes, providing them with a method to generate >>> an ARF report is a large hurdle >> >> I don't think it's a good idea. It makes much more sense to give >> individual users a button they can push to ask their provider to send a >> report on their behalf. > > I see no contradiction here: either users push a button to generate ARF > reports for their own ESPs (updated clients), or move spam messages to > ad-hoc IMAP folders (problematic clients) so that an ARF header can be > generated directly from the file (any added delay may help > anonymization.) Regardless of the outcome of the button pressing, the hurdle's still much larger when the MUA is not controlled by the client. There may be existing plug-ins already for things like Outlook Express, and Thunderbird, and $YOUR_FAVORITE_MUA but getting customers to use them is not as easy as simply sending your customers an email and saying "Go download this cool plug-in". If there's not an existing plug-in, who's gonna build and support them? > > Should ESPs verify that the stuff is actually spam or just forward it? Verification is not a scalable solution, IMHO. The staff required to read every complaint might run to the dozens, if not hundreds, and then separating the obvious spam from the might be spam (e.g., it's bulk, but do you know whether or not your customer signed up for this mailing?) from the clearly not spam would require resources that most ISPs don't and won't have. Besides, who would want a job for which the description is "Read spam complaints all day"? -- Todd Herr Principal Engineer and Postmaster V: 703.345.2447 Road Runner Email Operations M: 571.287.0366 therr@security.rr.com AIM: RRMailToddHerr Received: from vwp0043.webpack.hosteurope.de (vwp0043.webpack.hosteurope.de [87.230.60.50]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n83KtLbM030162 for ; Thu, 3 Sep 2009 13:55:26 -0700 Received: from p5b337639.dip.t-dialin.net ([91.51.118.57] helo=[192.168.1.115]); authenticated by vwp0043.webpack.hosteurope.de running ExIM with esmtpa id 1MjIm2-0004aZ-3G; Thu, 03 Sep 2009 22:19:14 +0200 Message-ID: <4AA024BE.7080507@knutix.de> Date: Thu, 03 Sep 2009 22:19:10 +0200 From: Tobias Knecht User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: ARF mailing list References: <4A9E9D15.5020903@tana.it> <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> <20090902205039.GA1179@todzilla.mail.rr.com> <46BDEC4E-BDF4-456C-AF33-04BF81794BEF@word-to-the-wise.com> <4A9FD3D0.1030802@corp.aol.com> <20090903165135.GA26570@todzilla.mail.rr.com> <4AA0090C.4070507@tana.it> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF32112BB7B8B9FDED644EC79" X-bounce-key: webpack.hosteurope.de;knut@knutix.de;1252011326;e73fcdac; X-Greylist: Delayed for 00:36:04 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 03 Sep 2009 13:55:27 -0700 (PDT) Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 20:55:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF32112BB7B8B9FDED644EC79 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > Sorry, but that's just wrong. Several large ISPs send me fully unredac= ted=20 > copies of messages in FBL reports. Sending unredacted complaints to a third party with personal information of end-users is an absolute no-go in Germany. If there is a legal need to redact information, it should be allowed without getting in problems with the standards. On the other side there are so many discussions about privacy policy in Germany and all over Europe at the moment. The rules change with every court decision nearly weekly at the moment. It would not be helpful to make decisions and create standards now which could be completely nonsense after the next election. Tobias --------------enigF32112BB7B8B9FDED644EC79 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqgJMEACgkQvB4M5yQyqDegdACgnie5uDRrlDw2oiOpXCycKccJ c+8An36ROXs5gblAfWZcT0e7ANM/7Fnv =JZxC -----END PGP SIGNATURE----- --------------enigF32112BB7B8B9FDED644EC79-- Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n83Ki2mr029651 for ; Thu, 3 Sep 2009 13:44:07 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@resistor.net Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Beta0/8.14.4.Beta0) with ESMTP id n83Khoh5013380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Sep 2009 13:43:56 -0700 (PDT) Message-Id: <6.2.5.6.2.20090903132450.02c7c518@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 03 Sep 2009 13:43:39 -0700 To: abuse-feedback-report@mipassoc.org From: SM In-Reply-To: <4A9E9D15.5020903@tana.it> References: <4A9E9D15.5020903@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 03 Sep 2009 13:44:07 -0700 (PDT) Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 20:44:07 -0000 At 09:28 02-09-2009, Alessandro Vesely wrote: >What I would suggest is to modify the name and the description of the >WG so as to provide for further discussion on feedback loops, after >the publication of the first RFC. Please note that this would be a >completion, not an upset. Tentatively, Murray's message was about gauging interest and drawing up a charter for a ARF WG. The cut-off date to request a BoF is September 7, 2009. If there is any interest in changing the name and/or the work to be done by the WG, it is better to do it soon as a BoF requires AD approval. Discussions about the details of ARF will not help in getting the Charter approved in my opinion. Regards, -sm Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n83KOTcB028838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 Sep 2009 13:24:35 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 20650 invoked from network); 3 Sep 2009 20:24:28 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 3 Sep 2009 20:24:28 -0000 Date: Thu, 3 Sep 2009 16:24:28 -0400 (EDT) From: "John R. Levine" To: Steve Atkins In-Reply-To: <3D348242-BC89-433F-AA87-5071EAD5DFAE@word-to-the-wise.com> Message-ID: References: <4A9E9D15.5020903@tana.it> <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> <20090902205039.GA1179@todzilla.mail.rr.com> <46BDEC4E-BDF4-456C-AF33-04BF81794BEF@word-to-the-wise.com> <4A9FD3D0.1030802@corp.aol.com> <20090903165135.GA26570@todzilla.mail.rr.com> <4AA00797.5060702@corp.aol.com> <3D348242-BC89-433F-AA87-5071EAD5DFAE@word-to-the-wise.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 03 Sep 2009 13:24:35 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 20:24:35 -0000 >> So would there be interest in a standard way for 3rd party mail clients >> to know where to send a report to their provider, who could then send >> it on to the originator if they chose to? > > Yes, definitely. It's an interesting challenge to figure out how to do that in a way that will work, will be resistant to misuse (e.g. spammers providing fake info), and won't require major surgery to existing mail software. Since it is quite common for a single MUA to collect mail from multiple accounts, it's important that there be an address per provider, not just one address per MUA. My copy of Thunderbird, for example, collects mail from Yahoo, Hotmail, Gmail, AOL, and my own mail server, which may be a bit extreme but should still work. I can think of two general approaches. One somehow adds the report address to the per-account config, the other to the messages. I'd prefer to do the config, except that config is already a painful swamp which isn't likely to be drained any time soon. The other is to add a trace header to the top of each message along the lines of ARF-Info: to report@corp.bigisp.com auth someuser@bigisp.com via submithost.bigisp.com:587 It's a trace header so the top one wins, deterring fakes. The idea of the auth clause is to give the MUA a hint about which account to use. If the auth doesn't match one that the MUA already knows, there's no button for this message. I realize this is kind of a kludge, but this at least avoids adding more config state to MUA setup. Autodiscovery sounds like a great idea, but I'm having trouble figuring out how it would work unless you want to extend POP and IMAP with commands to fetch extended config info, which I fear would have serious political problems with the keepers of the POP and IMAP specs. R's, John Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n83KHjp1028525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 3 Sep 2009 13:17:51 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@cybernothing.org Received: from rpco-jdmacbook.rpcorp.local (np57.co.returnpath.net [38.109.196.57]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id n83KHhSB001787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 3 Sep 2009 14:17:44 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net n83KHhSB001787 Message-ID: <4AA02462.2040605@cybernothing.org> Date: Thu, 03 Sep 2009 14:17:38 -0600 From: "J.D. Falk" User-Agent: Postbox 1.0b15 (Macintosh/2009081714) MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org References: <4A9E9D15.5020903@tana.it> <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> <20090902205039.GA1179@todzilla.mail.rr.com> <46BDEC4E-BDF4-456C-AF33-04BF81794BEF@word-to-the-wise.com> <4A9FD3D0.1030802@corp.aol.com> <20090903165135.GA26570@todzilla.mail.rr.com> <4AA0090C.4070507@tana.it> In-Reply-To: <4AA0090C.4070507@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 03 Sep 2009 13:17:51 -0700 (PDT) Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 20:17:51 -0000 Alessandro Vesely wrote: > Would you expand on how do you approve enrollments? (Fully/partially > automated WHOIS lookup, I'd guess.) And how do ESPs find out where to > ask for enrollment? That's what the MAAWG document will focus on. Really short version: people talk to each other. >> This is a good point. FBL data (other than AOL) tends to be unredacted >> because you know who you're sending it to. > > The last thing one would do is to confirm users' addresses, or betray > honeypots. Will guidance for munging be part of the ARF spec? See the list archives for the last dozen times we had that discussion. > Should ESPs verify that the stuff is actually spam or just forward it? A complaint is a complaint. Every known implementation today (there's about a dozen) simply forwards it. I believe your use of the acronym "ESP" may be different from others'. -- J.D. Falk Return Path Inc http://www.returnpath.net/ Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n83KEkqD028406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 3 Sep 2009 13:14:52 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@cybernothing.org Received: from rpco-jdmacbook.rpcorp.local (np57.co.returnpath.net [38.109.196.57]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id n83KEh81001750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 3 Sep 2009 14:14:45 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net n83KEh81001750 Message-ID: <4AA023AE.1010209@cybernothing.org> Date: Thu, 03 Sep 2009 14:14:38 -0600 From: "J.D. Falk" User-Agent: Postbox 1.0b15 (Macintosh/2009081714) MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 03 Sep 2009 13:14:52 -0700 (PDT) Subject: [feedback-report] end user submission of feedback (was Re: ARF working group interest?) X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 20:14:52 -0000 Michael Adkins wrote: > So would there be interest in a standard way for 3rd party mail clients > to know where to send a report to their provider, who could then send it > on to the originator if they chose to? I think that would be a very appropriate thing for this WG to address. It could be extremely simple - authenticated SMTP submission of a raw message to a preconfigured address - a way for the MUA to auto-discover the submission address -- J.D. Falk Return Path Inc http://www.returnpath.net/ Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n83ImvPJ023222 for ; Thu, 3 Sep 2009 11:49:02 -0700 Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 3941980668 for ; Thu, 3 Sep 2009 11:48:38 -0700 (PDT) Message-Id: <3D348242-BC89-433F-AA87-5071EAD5DFAE@word-to-the-wise.com> From: Steve Atkins To: ARF mailing list In-Reply-To: <4AA00797.5060702@corp.aol.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 3 Sep 2009 11:48:56 -0700 References: <4A9E9D15.5020903@tana.it> <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> <20090902205039.GA1179@todzilla.mail.rr.com> <46BDEC4E-BDF4-456C-AF33-04BF81794BEF@word-to-the-wise.com> <4A9FD3D0.1030802@corp.aol.com> <20090903165135.GA26570@todzilla.mail.rr.com> <4AA00797.5060702@corp.aol.com> X-Mailer: Apple Mail (2.936) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 03 Sep 2009 11:49:02 -0700 (PDT) Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 18:49:02 -0000 On Sep 3, 2009, at 11:14 AM, Michael Adkins wrote: > >> I don't think it's a good idea. It makes much more sense to give >> individual users a button they can push to ask their provider to >> send a >> report on their behalf. >> >> >> > +1 > > So would there be interest in a standard way for 3rd party mail > clients > to know where to send a report to their provider, who could then > send it > on to the originator if they chose to? Yes, definitely. Cheers, Steve Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n83IhhHI022800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 Sep 2009 11:43:49 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 49725 invoked from network); 3 Sep 2009 18:43:43 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 3 Sep 2009 18:43:43 -0000 Date: Thu, 3 Sep 2009 14:43:42 -0400 (EDT) From: "John R. Levine" To: Alessandro Vesely In-Reply-To: <4AA0090C.4070507@tana.it> Message-ID: References: <4A9E9D15.5020903@tana.it> <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> <20090902205039.GA1179@todzilla.mail.rr.com> <46BDEC4E-BDF4-456C-AF33-04BF81794BEF@word-to-the-wise.com> <4A9FD3D0.1030802@corp.aol.com> <20090903165135.GA26570@todzilla.mail.rr.com> <4AA0090C.4070507@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 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 03 Sep 2009 11:43:49 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 18:43:50 -0000 >> This is a good point. FBL data (other than AOL) tends to be unredacted >> because you know who you're sending it to. > > The last thing one would do is to confirm users' addresses, or betray > honeypots. Will guidance for munging be part of the ARF spec? Sorry, but that's just wrong. Several large ISPs send me fully unredacted copies of messages in FBL reports. > I see no contradiction here: either users push a button to generate ARF > reports for their own ESPs (updated clients), or move spam messages to ad-hoc > IMAP folders (problematic clients) so that an ARF header can be generated > directly from the file (any added delay may help anonymization.) I presume you mean ISP, not ESP. In my experience abuse reports from end users are almost always useless. Senders will often trust a report from the ISP but not from the end user since they'll have an FBL agreement with the ISP. > Should ESPs verify that the stuff is actually spam or just forward it? Wow, talk about a research topic. R's, John Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n83IL1kY020997 for ; Thu, 3 Sep 2009 11:21:07 -0700 Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Thu, 03 Sep 2009 20:21:01 +0200 id 00000000005DC031.000000004AA0090D.00007A6C Message-ID: <4AA0090C.4070507@tana.it> Date: Thu, 03 Sep 2009 20:21:00 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Todd Herr References: <4A9E9D15.5020903@tana.it> <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> <20090902205039.GA1179@todzilla.mail.rr.com> <46BDEC4E-BDF4-456C-AF33-04BF81794BEF@word-to-the-wise.com> <4A9FD3D0.1030802@corp.aol.com> <20090903165135.GA26570@todzilla.mail.rr.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 03 Sep 2009 11:21:07 -0700 (PDT) Cc: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 18:21:11 -0000 John R. Levine wrote: >>> * Where do you send them if you're trusted, or if you're untrusted >> >> In my experience, we only send FBL reports to those who've asked >> for them (and been approved for enrollment in our FBL) Would you expand on how do you approve enrollments? (Fully/partially automated WHOIS lookup, I'd guess.) And how do ESPs find out where to ask for enrollment? > This is a good point. FBL data (other than AOL) tends to be unredacted > because you know who you're sending it to. The last thing one would do is to confirm users' addresses, or betray honeypots. Will guidance for munging be part of the ARF spec? >> - Mailbox holders who are clued enough to read headers and make a >> reasonable guess at the right place to which to complain >> - Mailbox holders who aren't clued enough to read headers >> >> For the latter two classes, providing them with a method to generate >> an ARF report is a large hurdle > > I don't think it's a good idea. It makes much more sense to give > individual users a button they can push to ask their provider to send a > report on their behalf. I see no contradiction here: either users push a button to generate ARF reports for their own ESPs (updated clients), or move spam messages to ad-hoc IMAP folders (problematic clients) so that an ARF header can be generated directly from the file (any added delay may help anonymization.) Should ESPs verify that the stuff is actually spam or just forward it? Received: from omr-d34.mx.aol.com (omr-d34.mx.aol.com [205.188.249.132]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n83I97Mo019910 for ; Thu, 3 Sep 2009 11:09:13 -0700 Received: from AOLDTCMEH01.ad.office.aol.com (aoldtcmeh01.office.aol.com [10.180.121.20]) by omr-d34.mx.aol.com (v117.7) with ESMTP id MAILOMRD345-7e644aa0061f156; Thu, 03 Sep 2009 14:08:31 -0400 Received: from AOLMTCMEI01.ad.office.aol.com ([10.178.3.18]) by AOLDTCMEH01.ad.office.aol.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 14:08:03 -0400 Received: from [10.181.80.41] ([10.178.3.11]) by AOLMTCMEI01.ad.office.aol.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 14:08:03 -0400 Message-ID: <4AA00797.5060702@corp.aol.com> Date: Thu, 03 Sep 2009 14:14:47 -0400 From: Michael Adkins User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "John R. Levine" References: <4A9E9D15.5020903@tana.it> <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> <20090902205039.GA1179@todzilla.mail.rr.com> <46BDEC4E-BDF4-456C-AF33-04BF81794BEF@word-to-the-wise.com> <4A9FD3D0.1030802@corp.aol.com> <20090903165135.GA26570@todzilla.mail.rr.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Sep 2009 18:08:03.0227 (UTC) FILETIME=[7AB1E6B0:01CA2CC1] X-AOL-IP: 10.180.121.20 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 03 Sep 2009 11:09:13 -0700 (PDT) Cc: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 18:09:13 -0000 > I don't think it's a good idea. It makes much more sense to give > individual users a button they can push to ask their provider to send a > report on their behalf. > > > +1 So would there be interest in a standard way for 3rd party mail clients to know where to send a report to their provider, who could then send it on to the originator if they chose to? Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n83GwpXY013600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 Sep 2009 09:58:57 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 52080 invoked from network); 3 Sep 2009 16:58:50 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 3 Sep 2009 16:58:50 -0000 Date: Thu, 3 Sep 2009 12:58:50 -0400 (EDT) From: "John R. Levine" To: Todd Herr In-Reply-To: <20090903165135.GA26570@todzilla.mail.rr.com> Message-ID: References: <4A9E9D15.5020903@tana.it> <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> <20090902205039.GA1179@todzilla.mail.rr.com> <46BDEC4E-BDF4-456C-AF33-04BF81794BEF@word-to-the-wise.com> <4A9FD3D0.1030802@corp.aol.com> <20090903165135.GA26570@todzilla.mail.rr.com> 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 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 03 Sep 2009 09:58:57 -0700 (PDT) Cc: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 16:58:57 -0000 >> * Where do you send them if you're trusted, or if you're untrusted > > In my experience, we only send FBL reports to those who've asked > for them (and been approved for enrollment in our FBL) This is a good point. FBL data (other than AOL) tends to be unredacted because you know who you're sending it to. > I have found that sending untrusted ARF reports to abuse@ results in > responses ranging the gamut of: > > - Reply asking to please stop sending mail with attachments to abuse@ > - Reply asking to change format to something other than ARF > - Reply asking to please send FBL to other address > - Silence I realize I'm a lot smaller than you, but I send about a million a month. Mostly I get silence. I used to get a lot of don't send attachments, but that's dropped off considerably. > - Mail providers (i.e., actual ISP mail operations staff) > - Mailbox holders who are clued enough to read headers and make a > reasonable guess at the right place to which to complain > - Mailbox holders who aren't clued enough to read headers > > For the latter two classes, providing them with a method to generate > an ARF report is a large hurdle I don't think it's a good idea. It makes much more sense to give individual users a button they can push to ask their provider to send a report on their behalf. R's, John Received: from todzilla.mail.rr.com (todzilla.mail.rr.com [24.28.207.21]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n83Gpa40012841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 Sep 2009 09:51:42 -0700 Received: from todzilla.mail.rr.com (todzilla.mail.rr.com [127.0.0.1]) by todzilla.mail.rr.com (8.14.2/8.14.2) with ESMTP id n83GpZA2032340 for ; Thu, 3 Sep 2009 12:51:35 -0400 Received: (from therr@localhost) by todzilla.mail.rr.com (8.14.2/8.14.2/Submit) id n83GpZuU032339 for abuse-feedback-report@mipassoc.org; Thu, 3 Sep 2009 12:51:35 -0400 X-Authentication-Warning: todzilla.mail.rr.com: therr set sender to therr@security.rr.com using -f Date: Thu, 3 Sep 2009 12:51:35 -0400 From: Todd Herr To: abuse-feedback-report@mipassoc.org Message-ID: <20090903165135.GA26570@todzilla.mail.rr.com> References: <4A9E9D15.5020903@tana.it> <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> <20090902205039.GA1179@todzilla.mail.rr.com> <46BDEC4E-BDF4-456C-AF33-04BF81794BEF@word-to-the-wise.com> <4A9FD3D0.1030802@corp.aol.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 03 Sep 2009 09:51:42 -0700 (PDT) Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 16:51:42 -0000 On Thu, Sep 03, 2009 at 12:20:49PM -0400, John R. Levine wrote: > > What, I don't count anymore? ;) > > Hey, this is the IETF where anecdotes about something that happened to > some guy with a Sun3 in 1998 count for more than the experience of global > mail providers. > > > The vast majority of our FBLs also go to addresses other than abuse@. > > Keeping all of those channels straight gets to be a cumbersome task on > > both sides, especially as more and more mailbox providers become fbl > > providers. I would be interested in a standard way to discover where to > > route automated reports that I don't expect a response to, whether they > > trust me as a report sender or not. I should be able to authenticate the > > reports as coming from my system and let the report recipients decide > > whether to process it or not based on that authentication, instead of > > relying on shared secrets established when the channel was created. > > Let's see if we can pick that apart a little. > > For senders of reports: > > * Where do you send them if you're trusted, or if you're untrusted In my experience, we only send FBL reports to those who've asked for them (and been approved for enrollment in our FBL), and then to the address that the requester has specified at the time of signup. I have found that sending untrusted ARF reports to abuse@ results in responses ranging the gamut of: - Reply asking to please stop sending mail with attachments to abuse@ - Reply asking to change format to something other than ARF - Reply asking to please send FBL to other address - Silence I'd also add that when we speak of untrusted senders, we must divide them into at least three categories: - Mail providers (i.e., actual ISP mail operations staff) - Mailbox holders who are clued enough to read headers and make a reasonable guess at the right place to which to complain - Mailbox holders who aren't clued enough to read headers For the latter two classes, providing them with a method to generate an ARF report is a large hurdle, because it's going to have be something done inside the mail client, with one click of the mouse/one keystroke. Mail providers alone cannot shoulder that burden if they don't provide their customers with a uniform client and a uniform method of accessing their mail. I *heart* ARF, but I believe it's only effective at this time when there's a trust relationship involved. -- Todd Herr Principal Engineer and Postmaster V: 703.345.2447 Road Runner Email Operations M: 571.287.0366 therr@security.rr.com AIM: RRMailToddHerr Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n83GUq46010771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 3 Sep 2009 09:30:58 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@cybernothing.org Received: from rpco-jdmacbook.rpcorp.local (np57.co.returnpath.net [38.109.196.57]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id n83GUkhX030027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 3 Sep 2009 10:30:48 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net n83GUkhX030027 Message-ID: <4A9FEF31.9000909@cybernothing.org> Date: Thu, 03 Sep 2009 10:30:41 -0600 From: "J.D. Falk" User-Agent: Postbox 1.0b15 (Macintosh/2009081714) MIME-Version: 1.0 To: "abuse-feedback-report@mipassoc.org" References: <4A9E9D15.5020903@tana.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 03 Sep 2009 09:30:58 -0700 (PDT) Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 16:30:59 -0000 John R. Levine wrote: > ARF is a perfectly good way to send meta-information about messages from > one place to another. Don't try to make it more than that. +1 If it helps, MAAWG's working on a BCP for complaint feedback loops; it recommends ARF as the standard format for messages, and suggests ways to create those 1:1 relationships for automated feedback. -- J.D. Falk Return Path Inc http://www.returnpath.net/ Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n83GKpjl010048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 Sep 2009 09:20:57 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 21414 invoked from network); 3 Sep 2009 16:20:50 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 3 Sep 2009 16:20:50 -0000 Date: Thu, 3 Sep 2009 12:20:49 -0400 (EDT) From: "John R. Levine" To: Michael Adkins In-Reply-To: <4A9FD3D0.1030802@corp.aol.com> Message-ID: References: <4A9E9D15.5020903@tana.it> <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> <20090902205039.GA1179@todzilla.mail.rr.com> <46BDEC4E-BDF4-456C-AF33-04BF81794BEF@word-to-the-wise.com> <4A9FD3D0.1030802@corp.aol.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 03 Sep 2009 09:20:57 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 16:20:57 -0000 > What, I don't count anymore? ;) Hey, this is the IETF where anecdotes about something that happened to some guy with a Sun3 in 1998 count for more than the experience of global mail providers. > The vast majority of our FBLs also go to addresses other than abuse@. > Keeping all of those channels straight gets to be a cumbersome task on > both sides, especially as more and more mailbox providers become fbl > providers. I would be interested in a standard way to discover where to > route automated reports that I don't expect a response to, whether they > trust me as a report sender or not. I should be able to authenticate the > reports as coming from my system and let the report recipients decide > whether to process it or not based on that authentication, instead of > relying on shared secrets established when the channel was created. Let's see if we can pick that apart a little. For senders of reports: * Where do you send them if you're trusted, or if you're untrusted * How do you tell the recipient who you are * How can you tell if the recipient trusts you * How do you tell the recipient you don't want an answer For recipients * How do you publish your reporting address * How do you recognize a reporter My suggestions would be pretty minimalist: * All reports go to abuse@domain, no need to publish yet more contact addresses, since ARF reports are self-identifying * Senders who want to prove who they are can sign reports with DKIM. Perhaps add a "Reporting-domain: example.com" line to tell recipients which of multiple signatures you'd like them to use * Senders who don't want a response can put in "Response-requested: no" Not sure how to tell if they trust your reports, perhaps a "Tell-me-if-you-love-me: yes" field asking for some sort of stylized response. Would this do it? If not, what am I missing? If at all possible I would like to use existing standards rather than invent new stuff. R's, John Received: from omr-m31.mx.aol.com (omr-m31.mx.aol.com [64.12.143.151]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n83Ex0OU004213 for ; Thu, 3 Sep 2009 07:59:05 -0700 Received: from AOLMTCMEH01.ad.office.aol.com (aolmtcmeh01.office.aol.com [10.178.121.20]) by omr-m31.mx.aol.com (v117.7) with ESMTP id MAILOMRM318-7f094a9fd258273; Thu, 03 Sep 2009 10:27:36 -0400 Received: from AOLMTCMEI03.ad.office.aol.com ([10.178.3.20]) by AOLMTCMEH01.ad.office.aol.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 10:27:09 -0400 Received: from [10.181.80.41] ([10.178.3.10]) by AOLMTCMEI03.ad.office.aol.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 10:27:08 -0400 Message-ID: <4A9FD3D0.1030802@corp.aol.com> Date: Thu, 03 Sep 2009 10:33:52 -0400 From: Michael Adkins User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "John R. Levine" References: <4A9E9D15.5020903@tana.it> <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> <20090902205039.GA1179@todzilla.mail.rr.com> <46BDEC4E-BDF4-456C-AF33-04BF81794BEF@word-to-the-wise.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Sep 2009 14:27:08.0764 (UTC) FILETIME=[9E6B59C0:01CA2CA2] X-AOL-IP: 10.178.121.20 X-Greylist: Delayed for 00:30:56 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 03 Sep 2009 07:59:06 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 14:59:08 -0000 > For trusted senders, there's all sorts of possible ways to set up a > channel, special address, passwords in the mail, even channels other than > SMTP. I haven't heard any interest in standardizing that. > > What, I don't count anymore? ;) The vast majority of our FBLs also go to addresses other than abuse@. Keeping all of those channels straight gets to be a cumbersome task on both sides, especially as more and more mailbox providers become fbl providers. I would be interested in a standard way to discover where to route automated reports that I don't expect a response to, whether they trust me as a report sender or not. I should be able to authenticate the reports as coming from my system and let the report recipients decide whether to process it or not based on that authentication, instead of relying on shared secrets established when the channel was created. Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n838F7Ns015079 for ; Thu, 3 Sep 2009 01:15:13 -0700 Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Thu, 03 Sep 2009 10:15:06 +0200 id 00000000005DC031.000000004A9F7B0A.0000785E Message-ID: <4A9F7B1E.8000906@tana.it> Date: Thu, 03 Sep 2009 10:15:26 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "John R. Levine" References: <4A9E9D15.5020903@tana.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Thu, 03 Sep 2009 01:15:13 -0700 (PDT) Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 08:15:13 -0000 John R. Levine wrote: >> Please let me state once more that ARF is not sufficient. What appears >> to be missing are the indications of when and how to use it, i.e. the >> role of a mail domain and its "abuse" mailbox. > > I fear that you misunderstand the nature of a standards process. Granted! I try, however :-) > You > can't force people to accept abuse reports or to do anything else if they > don't want to, and despite a lot of wishful thinking, writing language > into an RFC doesn't change that. Fine. But what about people who want to? I'd imagine any responsible users of an IP subnet would like to be informed about bots seizing their PCs, or users wandering on the dark side. Specifying how exactly that information is to be delivered is not functionally different than, say, spelling the role of an MX RR. (See the forwarding example below.) > We already have abuse@domain as the preferred reporting address for domain > that sends mail, and I see no reason to think that any amount of standards > drafting will improve on the current situation. We might consider saying > something in the ARF document that hosts MAY or SHOULD accept ARF > formatted reports at abuse@domain, but nothing beyond that. IMHO, such a statement doesn't belong to the ARF specification proper. > It would be nice if there were a reliable way to identify the reporting > address for an IP address, but we're not going to standardize that either. Why not? Each organization doing FBLs has to invent their own methods. And when an ESP changes ISP, they have to rebuild the whole reputation-related distributed database: a loosing strategy that only advantages those who change domain names more often than IP addresses. > The closest thing to a de-facto standard is listing it in SWIP data at > your RIR. That has all sorts of lookup problems we all know, but I see no > reason to think that any alternative spec we might invent would be adopted > by anyone. Is it worth mentioning the Shared WHOIS Project and the abuse-mailbox field in an RFC? Abusix's stance of only trusting 1st level (largest) ISPs, for example, seems reasonable. They look for an abuse mailbox in the 1st level RIRs' allocations. If they find none, they use the last tech-c contact listed there. The corresponding fellow is usually able to add an abuse mailbox to the record, thus abusix enforce RFC 2142 compliance somewhat. The 1st level allocation usually corresponds to an ISP, not an ESP. In case the next level allocation had been leased to a spammer, it is reasonable to to have means to let the upper level be also informed. However, there are some routing issues here: normally, abuse reports are to be forwarded to the relevant postmasters. In particular, * we need fields in the ARF format to automate forwarding, but * determination of where to forward is out of the ARF RFC's scope. That raises a chicken and egg problem, unless the two specifications are coordinated. I mention a second specification because it is extremely unlikely that ISPs on their own come out with some satisfactory practice. Although some ISPs might engineer a clever mechanism to route abuse reports, many won't; and even if they will, the likelihood that such mechanisms are portable from an ISP to another is scarce. Isn't that what standards processes are for? Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n831QwBx025575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Sep 2009 18:27:04 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 85934 invoked from network); 3 Sep 2009 01:26:58 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 3 Sep 2009 01:26:58 -0000 Date: Wed, 2 Sep 2009 21:26:57 -0400 (EDT) From: "John R. Levine" To: Steve Atkins In-Reply-To: <46BDEC4E-BDF4-456C-AF33-04BF81794BEF@word-to-the-wise.com> Message-ID: References: <4A9E9D15.5020903@tana.it> <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> <20090902205039.GA1179@todzilla.mail.rr.com> <46BDEC4E-BDF4-456C-AF33-04BF81794BEF@word-to-the-wise.com> 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 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 02 Sep 2009 18:27:04 -0700 (PDT) Cc: ARF mailing list Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 01:27:05 -0000 >> I dunno about you, but it seems a lot more trivial to tell mail hosts >> to make a twiddle to their mail sorting software to directly handle ARF >> than to invent yet another abuse.net type database that people are >> supposed to query to be able to send ARF reports. > I's not a case of "twiddling their mail sorting software" to parse ARF > format, it's a case of only opening up full automation to trusted > senders. I think we're actually in agreement here. I was thinking only in terms of your type B mail when I made that comment. Even for untrusted senders, ARF should make it easier to tell what they're trying to say even if you don't believe it. It is my impression that there's a fair amount of automation there already to look for IP addresses, URLs and email addresses. For trusted senders, there's all sorts of possible ways to set up a channel, special address, passwords in the mail, even channels other than SMTP. I haven't heard any interest in standardizing that. I suppose we could add an optional "Authorization: xxxxx" line to ARF, but I would only do that if there were FBLs that said they wanted it and would use it. R's, John Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n830GInq020851 for ; Wed, 2 Sep 2009 17:16:23 -0700 Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 4420F808F9 for ; Wed, 2 Sep 2009 16:40:36 -0700 (PDT) Message-Id: <46BDEC4E-BDF4-456C-AF33-04BF81794BEF@word-to-the-wise.com> From: Steve Atkins To: ARF mailing list In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 2 Sep 2009 16:40:53 -0700 References: <4A9E9D15.5020903@tana.it> <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> <20090902205039.GA1179@todzilla.mail.rr.com> X-Mailer: Apple Mail (2.936) X-Greylist: Delayed for 00:35:23 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 02 Sep 2009 17:16:23 -0700 (PDT) Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 00:16:23 -0000 On Sep 2, 2009, at 3:18 PM, John R. Levine wrote: >>> mail to the "abuse@" mailbox looking for ARF reports. The issue is >>> not >>> a technical one but rather one of policy - which is up to each ISP >>> to >>> set as they fit. >> >> Indeed, and the most trivial method of such filtering seemingly in >> use >> today (based on what I've seen, anyway) is for the ARF receiver to >> request >> that the ARF sender send ARF reports to >> specialAddressThatIsNotAbuse@. > Lets take ARF out of the equation for a couple of paragraphs. There are two main sorts of email that are of interest to an ESP or ISP abuse desk. There's mail from trusted reporters, where the receiver has an explicit relationship with the sender of the report, and for which the receiver doesn't have to ask any questions or consider the meaning or quality of the report, instead they can just take action based on it in a fairly mechanical manner. Type A email. Then there's mail from untrusted reporters. There it's much harder to judge what the mail means, and whether to take action based on it, and what that action should be. It's not something that's conducive to high levels of automation, typically, and there'll pretty much always need to be a human in the loop (on a per-incident basis, if not a per message basis) to judge what the mail means and whether it should be trusted. Type B email. Type A email is extremely conducive to 100% automation, if the messages can be identified as solicited email from trusted reporters and if the messages are of a format that can be mechanically processed easily. Type B email is not so conducive to 100% automation. If you are a trusted reporter then the receiver will have provided you with a password of some sort to identify yourself to the receiver, typically a special email address but it could equally well be a magic word to put in the message, or DKIM validation or anything the sender and receiver agree to, and they will have asked you to use a specific format for sending reports. That format is probably ARF, but the "ARF format email" is otherwise orthogonal to being a trusted reporter sending type A email. If you don't have that password from the receiver the _you are not a trusted reporter_. You are sending type B email to abuse@ without prior explicit arrangement. Your mail will not be treated as special in any way if you are not a trusted reporter, even if you send it in ARF format. At best, sending email in ARF format as an untrusted reporter will just provide a good, MIME encapsulated message to the receiver - it is unlikely to provoke any special handling. So, let us not confuse "ARF format" vs "Non-ARF format" email with "trusted reporter" vs "untrusted reporter". Trusted reporters get the benefit of implicit belief and full automation, untrusted reporters don't. Trusted reporters may be required to use ARF format email, but that's not the same as senders of ARF format email being trusted. There are people who believe that by sending a steady stream of emails to abuse@ in ARF format without any prior arrangement with the receiving ISP it will cause them to be considered trusted in some way. They're almost always wrong, though if the volume is high enough they will end up getting special treatment of some sort. I say "almost always wrong" as there are a very few reporters who, despite no prior agreement with the ISP, have consistently provided useful data and are treated as trusted reporters by receiver abuse desks and are special cased. That's very, very rare and orthogonal to the ARFness or otherwise of their emails (in fact, in the two cases I'm aware of they do not use ARF). > > I dunno about you, but it seems a lot more trivial to tell mail > hosts to > make a twiddle to their mail sorting software to directly handle ARF > than > to invent yet another abuse.net type database that people are > supposed to > query to be able to send ARF reports. I's not a case of "twiddling their mail sorting software" to parse ARF format, it's a case of only opening up full automation to trusted senders. If they're using some sort of abuse.net type database to work out where to send the report then they are an untrusted sender, and the format they send the report in is irrelevant. Cheers, Steve Received: from [127.0.0.1] (ppp-68-120-198-98.dsl.pltn13.pacbell.net [68.120.198.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n82MOHsG014586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Sep 2009 15:24:23 -0700 Message-ID: <4A9EF090.6080701@dcrocker.net> Date: Wed, 02 Sep 2009 15:24:16 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alessandro Vesely References: <4A9E9D15.5020903@tana.it> In-Reply-To: <4A9E9D15.5020903@tana.it> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 02 Sep 2009 15:24:23 -0700 (PDT) Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 22:24:23 -0000 Alessandro Vesely wrote: > Murray S. Kucherawy wrote: >> One of the main functions of creating the working group will be to take >> on the technical work of considering whether ARF as it is currently >> defined is necessary and sufficient. That is, we should consider >> dropping stuff that’s not actually useful or ambiguous, and adding what >> appears to be missing. > > Please let me state once more that ARF is not sufficient. What appears > to be missing are the indications of when and how to use it, There is a difference between specifying an overall system, versus specifying a component of a system. ARF is component technology. There's nothing wrong with considering the specification of a system in which ARF is used, but it is a fundamentally different task than the one before us right now. To consider whether the current form of ARF is necessary and and sufficient does require considering a larger system in which it can be used. But it does not require specifying it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n82MIarb014199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Sep 2009 15:18:42 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 62654 invoked from network); 2 Sep 2009 22:18:35 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 2 Sep 2009 22:18:35 -0000 Date: Wed, 2 Sep 2009 18:18:35 -0400 (EDT) From: "John R. Levine" To: Todd Herr In-Reply-To: <20090902205039.GA1179@todzilla.mail.rr.com> Message-ID: References: <4A9E9D15.5020903@tana.it> <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> <20090902205039.GA1179@todzilla.mail.rr.com> 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 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 02 Sep 2009 15:18:42 -0700 (PDT) Cc: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 22:18:42 -0000 >> mail to the "abuse@" mailbox looking for ARF reports. The issue is not >> a technical one but rather one of policy - which is up to each ISP to >> set as they fit. > > Indeed, and the most trivial method of such filtering seemingly in use > today (based on what I've seen, anyway) is for the ARF receiver to request > that the ARF sender send ARF reports to specialAddressThatIsNotAbuse@. I dunno about you, but it seems a lot more trivial to tell mail hosts to make a twiddle to their mail sorting software to directly handle ARF than to invent yet another abuse.net type database that people are supposed to query to be able to send ARF reports. R's, John Received: from todzilla.mail.rr.com (todzilla.mail.rr.com [24.28.207.21]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n82LMKo8010793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Sep 2009 14:22:26 -0700 Received: from todzilla.mail.rr.com (todzilla.mail.rr.com [127.0.0.1]) by todzilla.mail.rr.com (8.14.2/8.14.2) with ESMTP id n82KodQF010544 for ; Wed, 2 Sep 2009 16:50:39 -0400 Received: (from therr@localhost) by todzilla.mail.rr.com (8.14.2/8.14.2/Submit) id n82Kod1Y010543 for abuse-feedback-report@mipassoc.org; Wed, 2 Sep 2009 16:50:39 -0400 X-Authentication-Warning: todzilla.mail.rr.com: therr set sender to therr@security.rr.com using -f Date: Wed, 2 Sep 2009 16:50:39 -0400 From: Todd Herr To: abuse-feedback-report@mipassoc.org Message-ID: <20090902205039.GA1179@todzilla.mail.rr.com> References: <4A9E9D15.5020903@tana.it> <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: Delayed for 00:31:38 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 02 Sep 2009 14:22:26 -0700 (PDT) Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 21:22:27 -0000 On Wed, Sep 02, 2009 at 03:59:19PM -0400, Yakov Shafranovich wrote: > > There are sufficient standards and procedures in place that if an ARF > sender and an ARF receiver wanted to communicate, that would easily be > able to do so. For example, it would be trivial to filter incoming > mail to the "abuse@" mailbox looking for ARF reports. The issue is not > a technical one but rather one of policy - which is up to each ISP to > set as they fit. Indeed, and the most trivial method of such filtering seemingly in use today (based on what I've seen, anyway) is for the ARF receiver to request that the ARF sender send ARF reports to specialAddressThatIsNotAbuse@. -- Todd Herr Principal Engineer and Postmaster V: 703.345.2447 Road Runner Email Operations M: 571.287.0366 therr@security.rr.com AIM: RRMailToddHerr Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n82KeR99004345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Sep 2009 13:40:33 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 94904 invoked from network); 2 Sep 2009 20:40:27 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 2 Sep 2009 20:40:27 -0000 Date: Wed, 2 Sep 2009 16:40:26 -0400 (EDT) From: "John R. Levine" To: Yakov Shafranovich In-Reply-To: <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> Message-ID: References: <4A9E9D15.5020903@tana.it> <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> 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 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 02 Sep 2009 13:40:33 -0700 (PDT) Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 20:40:33 -0000 > able to do so. For example, it would be trivial to filter incoming > mail to the "abuse@" mailbox looking for ARF reports. The issue is not > a technical one but rather one of policy - which is up to each ISP to > set as they fit. I have been sending all my abuse reports in ARF format for the past couple of years, and can report that it works pretty well. But I don't see what we as a standards group would do about that other than to say that they MAY or SHOULD accept and handle them. R's, John Received: from mail-vw0-f189.google.com (mail-vw0-f189.google.com [209.85.212.189]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n82Jxdtd014217 for ; Wed, 2 Sep 2009 12:59:45 -0700 Received: by vws27 with SMTP id 27so1052059vws.3 for ; Wed, 02 Sep 2009 12:59:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.16.85 with SMTP id n21mr1966719vca.13.1251921579091; Wed, 02 Sep 2009 12:59:39 -0700 (PDT) In-Reply-To: References: <4A9E9D15.5020903@tana.it> From: Yakov Shafranovich Date: Wed, 2 Sep 2009 15:59:19 -0400 Message-ID: <501c18e00909021259n22868bd8n44dc18e7620e4d39@mail.gmail.com> To: "John R. Levine" Content-Type: text/plain; charset=ISO-8859-1 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 02 Sep 2009 12:59:45 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n82Jxdtd014217 Cc: "abuse-feedback-report@mipassoc.org" , Alessandro Vesely Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 19:59:45 -0000 On Wed, Sep 2, 2009 at 2:43 PM, John R. Levine wrote: >> Please let me state once more that ARF is not sufficient. What appears >> to be missing are the indications of when and how to use it, i.e. the >> role of a mail domain and its "abuse" mailbox. > > I fear that you misunderstand the nature of a standards process.  You > can't force people to accept abuse reports or to do anything else if they > don't want to, and despite a lot of wishful thinking, writing language > into an RFC doesn't change that. > Or as Jon Postel put it "be conservative in what you send, be liberal in what you receive". There are sufficient standards and procedures in place that if an ARF sender and an ARF receiver wanted to communicate, that would easily be able to do so. For example, it would be trivial to filter incoming mail to the "abuse@" mailbox looking for ARF reports. The issue is not a technical one but rather one of policy - which is up to each ISP to set as they fit. Yakov Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n82JhMXh013244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Sep 2009 12:43:28 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@iecc.com Received: (qmail 3822 invoked from network); 2 Sep 2009 18:43:22 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 2 Sep 2009 18:43:22 -0000 Date: Wed, 2 Sep 2009 14:43:22 -0400 (EDT) From: "John R. Levine" To: Alessandro Vesely In-Reply-To: <4A9E9D15.5020903@tana.it> Message-ID: References: <4A9E9D15.5020903@tana.it> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Delayed for 00:59:57 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 02 Sep 2009 12:43:28 -0700 (PDT) Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 19:43:29 -0000 > Please let me state once more that ARF is not sufficient. What appears > to be missing are the indications of when and how to use it, i.e. the > role of a mail domain and its "abuse" mailbox. I fear that you misunderstand the nature of a standards process. You can't force people to accept abuse reports or to do anything else if they don't want to, and despite a lot of wishful thinking, writing language into an RFC doesn't change that. We already have abuse@domain as the preferred reporting address for domain that sends mail, and I see no reason to think that any amount of standards drafting will improve on the current situation. We might consider saying something in the ARF document that hosts MAY or SHOULD accept ARF formatted reports at abuse@domain, but nothing beyond that. It would be nice if there were a reliable way to identify the reporting address for an IP address, but we're not going to standardize that either. The closest thing to a de-facto standard is listing it in SWIP data at your RIR. That has all sorts of lookup problems we all know, but I see no reason to think that any alternative spec we might invent would be adopted by anyone. I also agree that it would be nice to be able to report abuse that isn't tied to an individual mail messge. INCH did that, we're not going to impress anyone by doing it again. ARF is a perfectly good way to send meta-information about messages from one place to another. Don't try to make it more than that. R's, John Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n82H8NsP003604 for ; Wed, 2 Sep 2009 10:08:28 -0700 Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 02 Sep 2009 18:28:05 +0200 id 00000000005DC02F.000000004A9E9D15.000058EB Message-ID: <4A9E9D15.5020903@tana.it> Date: Wed, 02 Sep 2009 18:28:05 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Delayed for 00:40:16 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 02 Sep 2009 10:08:29 -0700 (PDT) Cc: "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 17:08:31 -0000 Murray S. Kucherawy wrote: > One of the main functions of creating the working group will be to take > on the technical work of considering whether ARF as it is currently > defined is necessary and sufficient. That is, we should consider > dropping stuff that’s not actually useful or ambiguous, and adding what > appears to be missing. Please let me state once more that ARF is not sufficient. What appears to be missing are the indications of when and how to use it, i.e. the role of a mail domain and its "abuse" mailbox. In the draft's words: Determination of where these reports should be sent, how trust among report generators and report recipients is established, and reports related to more than one message are outside the scope of this document. I consider that self-imposed limitation useful, as it will likely allow to standardize ARF more quickly, as others have also noted on this list. However, while those out-of-scope issues would hardly fit within a single RFC, a working group might/should take them into account. Existing specifications are not sufficient: RFC 2142 dates back to 1997. It defines abuse@, but does not mention automated processing. That concept is reinforced by RFC 3013 (BCP 46), and RFC 2635 (FYI 35); the latter additionally suggests that users submit complaints to the local abuse desk, or to a global one (it mentions abuse.net). Some drafts exist that consider the concepts of abuse reporting (e.g. [1]) and domain-based reputation (e.g. [2]). While they may look distant from format discussions, the alternatives of either not discussing them, or discussing them in different WGs/lists, are bound to result in rough and inconsistent interoperability. For example, consider anonymization, a.k.a. munging reports; or report forwarding. More coordination may eventually result in a more consistent overall picture that ESPs and MUAs may conform to. [1] http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation [2] http://tools.ietf.org/html/draft-vesely-vhlo > The most recent version of the draft charter is attached. [...] > Of course, everyone is invited to make suggestions and participate in > the discussion for any work to be done by the working group. What I would suggest is to modify the name and the description of the WG so as to provide for further discussion on feedback loops, after the publication of the first RFC. Please note that this would be a completion, not an upset. Tentatively, Name: from Abuse Reporting Format (ARF) to, e.g., Wide-range Abuse Reporting Format And Related Extents (WARFARE) Description (1st paragraph only): from Messaging anti-abuse operations between independent services often requires sending reports on observed fraud, spam virus or other abuse activity. A standardized report format enables automated processing. The Abuse Reporting Format (ARF) specification has gained sufficient popularity to warrant formal codification, to ensure future interoperability with new implementations. The primary function of this working group will be to solicit review and refinement of the existing specification. to Messaging anti-abuse operations between independent services often require sending reports on observed fraud, spam virus or other abuse activity. A standardized report format enables automated processing. The Abuse Reporting Format (ARF) specification has gained sufficient popularity to warrant formal codification, to ensure future interoperability with new implementations. The primary function of this working group will be to solicit review and refinement of the existing format specifications. In addition, this working group may review current practices for forwarding abuse reports and subscribing to such feeds, possibly examining the security issues implied in migrating from IPv4-based subscriptions to domain-based ones. Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n81MfEgk012529 for ; Tue, 1 Sep 2009 15:41:19 -0700 Authentication-Results: sbh17.songbird.com; dkim=neutral (verification failed) header.i=@resistor.net Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Beta0/8.14.4.Beta0) with ESMTP id n81M1Yu2011109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Sep 2009 15:01:41 -0700 (PDT) Message-Id: <6.2.5.6.2.20090901142817.03111df8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 01 Sep 2009 15:01:21 -0700 To: abuse-feedback-report@mipassoc.org From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Delayed for 00:39:23 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 01 Sep 2009 15:41:20 -0700 (PDT) Cc: technical@maawg.org Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 22:41:20 -0000 At 11:40 01-09-2009, Murray S. Kucherawy wrote: >One of the main functions of creating the working group will be to >take on the technical work of considering whether ARF as it is >currently defined is necessary and sufficient. That is, we should >consider dropping stuff that's not actually useful or ambiguous, and >adding what appears to be missing. ARF has seen some real-world >traction so the In other words, the first objective is to define what goes in the base specification using draft-shafranovich-feedback-report as an initial proposal and to set up IANA registries. >Finally, one of the points of the charter is to consider some >proposed extensions. There is only one proposed extension at the moment (draft-kucherawy-dkim-reporting). The charter mentions eight possible reporting extensions. If I recall correctly, there were some comments from John Levine about the list and a mention of the work done in INCH. The output of INCH was RFC 5070. The goals are to deliver a document to "standardize" the reporting format while striving to retain backward compatibility. Once that has been done, the group will work on the extensions. I suggest finding out whether there is any interest to implement each of the eight extensions. At 12:27 01-09-2009, Yakov Shafranovich wrote: >I have some concern about separating the core ARF standard from the >extensions. As I wrote it originally, the standard was meant to be >highly extensible which is why it comes with a whole slew of IANA >registries.Perhaps we should make this distinction more clear in the >charter and work towards including the most widely used extensions in >the core standard Thus, we will be focusing the work of the WG on >getting ARF itself approved first. Work on additional extensions to >the core standard can be done after the main work is done. The core ARF is not being separated from the extensions. There's the work on the core ARF and once that is standardized, the group can proceed to work on the extensions. >I am afraid that getting bogged down in the extensions and what to >include will get us away from approving the ARF format itself. Yes. Regards, -sm Received: from mail.thenose.net (thenose.net [208.94.208.66]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n81LIPUe007856 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 1 Sep 2009 14:18:30 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@thenose.net X-MDAV-Processed: mail.thenose.net, Tue, 01 Sep 2009 15:47:14 -0500 Received: from [192.168.1.103] by thenose.net (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v10.1.1) with ESMTP id md50000339606.msg for ; Tue, 01 Sep 2009 15:47:13 -0500 X-Spam-Processed: mail.thenose.net, Tue, 01 Sep 2009 15:47:13 -0500 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: dennis@thenose.net X-MDRemoteIP: 99.8.63.207 X-Return-Path: dennis@thenose.net X-Envelope-From: dennis@thenose.net X-MDaemon-Deliver-To: abuse-feedback-report@mipassoc.org Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Dennis Dayman In-Reply-To: Date: Tue, 1 Sep 2009 15:47:18 -0500 Content-Transfer-Encoding: 7bit Message-Id: <6F00A1FA-A95F-42B4-B874-937C40E84B65@thenose.net> References: To: J D Falk X-Mailer: Apple Mail (2.1075.2) X-Greylist: Delayed for 00:31:00 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 01 Sep 2009 14:18:30 -0700 (PDT) Cc: MAAWG Technical Committee , "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] [technical] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 21:18:31 -0000 On Sep 1, 2009, at 1:54 PM, J D Falk wrote: > On 01/09/2009 12:40, "Murray S. Kucherawy" wrote: > >> It would also be helpful to know based on list traffic how many >> likely >> participants there will be. Thus, please reply to the list (see >> below) if you >> would be interested in participating both in the BoF and the >> working group >> (once it starts) by being part of list conversations and, better yet, >> attending IETF conferences and/or submitting document >> contributions. The more >> momentum we can demonstrate, the more the IETF will be willing to >> move >> forward. > > I plan to participate (most likely in person in Hiroshima), and > contribute, > and will continue to implement and evangelize ARF both personally > and on > behalf of my employer. I'm supposed to be in Barcelona end of that week, but depending on the date this might be on, perhaps. I am interested. -Dennis Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n81Ks1uA006683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 1 Sep 2009 13:54:06 -0700 Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@cybernothing.org Received: from rpco-jdmacbook.rpcorp.local (np57.co.returnpath.net [38.109.196.57]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id n81KMNP2018693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 1 Sep 2009 14:22:26 -0600 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net n81KMNP2018693 Message-ID: <4A9D8275.4020207@cybernothing.org> Date: Tue, 01 Sep 2009 14:22:13 -0600 From: "J.D. Falk" User-Agent: Postbox 1.0b15 (Macintosh/2009081714) MIME-Version: 1.0 To: ARF mailing list Content-Type: multipart/mixed; boundary="------------020301000605030900000900" X-Greylist: Delayed for 00:31:30 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 01 Sep 2009 13:54:07 -0700 (PDT) Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 20:54:07 -0000 This is a multi-part message in MIME format. --------------020301000605030900000900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm subscribed under a different address here, so this got rejected. --------------020301000605030900000900 Content-Type: message/rfc822; name="Re: [technical] ARF working group interest?.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: [technical] ARF working group interest?.eml" Received: from mail.corp.returnpath.net (mail.corp.returnpath.net [38.109.196.9]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n81JouB8002727 for ; Tue, 1 Sep 2009 12:51:02 -0700 Received: from mail.corp.returnpath.net (localhost.localdomain [127.0.0.1]) by mail.corp.returnpath.net (Postfix) with ESMTP id 47DF42501C4; Tue, 1 Sep 2009 12:54:08 -0600 (MDT) Received: from rpcoex01.rpcorp.local (unknown [10.0.1.142]) by mail.corp.returnpath.net (Postfix) with ESMTP id 3F0A5250078; Tue, 1 Sep 2009 18:54:08 +0000 (UTC) Received: from rpcoex01.rpcorp.local ([10.0.1.142]) by rpcoex01.rpcorp.local ([10.0.1.142]) with mapi; Tue, 1 Sep 2009 12:54:08 -0600 From: J D Falk To: "Murray S. Kucherawy" , "abuse-feedback-report@mipassoc.org" , MAAWG Technical Committee Date: Tue, 1 Sep 2009 12:54:05 -0600 Subject: Re: [technical] ARF working group interest? Thread-Topic: [technical] ARF working group interest? Thread-Index: AcorM59hnEV7ntJ4S1in9EceGNSM4wAAfSh7 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=returnpath.net; h=from:to :date:subject:message-id:in-reply-to:content-type :content-transfer-encoding:mime-version; s=selector1; bh=u05tnpC W01kVqj4gHYUMoJSKqNg=; b=d/nVn99bY/4Nra4HwJtJbxOoNBP8DqVbjM5Iizd rlh8gUSAbfxCfPQ4U1LB+pLpoZRRn6mS0D6upFepdaXxck+YtrhWYl3hJo0BgN6I ZtnM/9m1Isp9kgM9j3z3m9l64H9MopTQwJmuUkYqWZomNsBoonaF+xKYP01t8er2 i8PE= user-agent: Microsoft-Entourage/13.0.0.090609 x-ems-proccessed: Yma8eInq5qTp77FzNR/WDA== x-ems-stamp: /aTap+qpl5SN4wvRmv3Yaw== domainkey-signature: a=rsa-sha1; c=nofws; d=returnpath.net; h=from:to :date:subject:message-id:in-reply-to:content-type :content-transfer-encoding:mime-version; q=dns; s=selector1; b=T nHYWBhiiUfiPozhrFOy6AjUb8YL21l2l/NKIEMa/qZA4R8f5NG+Nhgtqqu3HcSlf rRumMKhpmN5L74rco52Qxbnnq3VwYM3RA8+oOwSplPtXphO/WC/ZSAuQEEzJ22BX W/uT4Mi0N8q85uarFxw+GlIEDD4ohJab/YUs/TptRI= x-mime-autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n81JouB8002727 authentication-results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@returnpath.net x-greylist: Delayed for 00:56:49 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 01 Sep 2009 12:51:02 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 On 01/09/2009 12:40, "Murray S. Kucherawy" wrote: > It would also be helpful to know based on list traffic how many likely > participants there will be. Thus, please reply to the list (see below) if you > would be interested in participating both in the BoF and the working group > (once it starts) by being part of list conversations and, better yet, > attending IETF conferences and/or submitting document contributions. The more > momentum we can demonstrate, the more the IETF will be willing to move > forward. I plan to participate (most likely in person in Hiroshima), and contribute, and will continue to implement and evangelize ARF both personally and on behalf of my employer. --------------020301000605030900000900-- Received: from [127.0.0.1] (ppp-68-120-198-98.dsl.pltn13.pacbell.net [68.120.198.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n81Keg2D005843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Sep 2009 13:40:48 -0700 Message-ID: <4A9D86CA.7090207@dcrocker.net> Date: Tue, 01 Sep 2009 13:40:42 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <501c18e00909011227u420e5ba3p68ede02a86701cdd@mail.gmail.com> In-Reply-To: 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]); Tue, 01 Sep 2009 13:40:48 -0700 (PDT) Cc: "technical@maawg.org" , "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 20:40:48 -0000 Murray S. Kucherawy wrote: > I think it would be fine to propose an adjusted charter that involves > verifying the base spec is up to IETF snuff and is reasonably minimal, moving > some things it has now out to extension specifications as needed, and then > considering the other already-proposed extensions as a third step. That translates into "review existing text and make whatever deletions, changes and removals are deemed appropriate". I don't recall ever seeing a wg charter with this as principal task. spoilingly yours, d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n81KUnZJ005312 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Tue, 1 Sep 2009 13:30:55 -0700 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Tue, 1 Sep 2009 13:30:49 -0700 From: "Murray S. Kucherawy" To: Yakov Shafranovich Date: Tue, 1 Sep 2009 13:30:48 -0700 Thread-Topic: [feedback-report] ARF working group interest? Thread-Index: AcorOldrjybZDVZTSyWKrG3lzPp3VAACGImQ Message-ID: References: <501c18e00909011227u420e5ba3p68ede02a86701cdd@mail.gmail.com> In-Reply-To: <501c18e00909011227u420e5ba3p68ede02a86701cdd@mail.gmail.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" MIME-Version: 1.0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 01 Sep 2009 13:30:55 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n81KUnZJ005312 Cc: "technical@maawg.org" , "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 20:30:55 -0000 > -----Original Message----- > From: Yakov Shafranovich [mailto:yakov@shaftek.org] > Sent: Tuesday, September 01, 2009 12:28 PM > To: Murray S. Kucherawy > Cc: abuse-feedback-report@mipassoc.org; technical@maawg.org > Subject: Re: [feedback-report] ARF working group interest? > > I have some concern about separating the core ARF standard from the > extensions. As I wrote it originally, the standard was meant to be > highly extensible which is why it comes with a whole slew of IANA > registries.Perhaps we should make this distinction more clear in the > charter and work towards including the most widely used extensions in > the core standard Thus, we will be focusing the work of the WG on > getting ARF itself approved first. Work on additional extensions to > the core standard can be done after the main work is done. I think it would be fine to propose an adjusted charter that involves verifying the base spec is up to IETF snuff and is reasonably minimal, moving some things it has now out to extension specifications as needed, and then considering the other already-proposed extensions as a third step. Received: from [127.0.0.1] (ppp-68-120-198-98.dsl.pltn13.pacbell.net [68.120.198.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n81JrmUG002960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Sep 2009 12:53:53 -0700 Message-ID: <4A9D7BCB.6030306@dcrocker.net> Date: Tue, 01 Sep 2009 12:53:47 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <4A9D70A8.7020108@bbiw.net> In-Reply-To: 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]); Tue, 01 Sep 2009 12:53:53 -0700 (PDT) Cc: "technical@maawg.org" , Dave CROCKER , "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] [technical] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 19:53:54 -0000 Murray S. Kucherawy wrote: >> -----Original Message----- From: Dave CROCKER [mailto:dcrocker@bbiw.net] >> Working groups are extremely expensive, in time and effort. The time for >> deciding whether changes are needed is before wg formation, not after. > > Recent chatter on the ARF list suggests that there is some momentum toward > removing stuff from the current specification. That's not to say there's > consensus to do so, but there is interest in discussing it. This suggests an avenue that might note might appear to be arguing against, but which is entirely reasonable within IETF framework: There is a solid consensus to do a particular bit of work. A bunch of folk agree that the spec needs pruning or that it needs to support capability x or that existing capability y isn't efficient enough or... The charter calls for doing this work. The wg is formed. It constructively pursued doing this work. But it discovers that it can't reach agreement on the details. (And, yes, this includes failing to agree on pruning. Cf., recent DKIM discussions about pruning DKIM; solid constituency for doing it, but failure to gain consensus for the details.) WG agrees that the original spec is sufficient on its own. Submits it to standards track. This is an odd version of a "failed" working group, int that it failed to make the changes it committed to, but it still issues an RFC. To repeat, however: this would be predicated on consensus about the need, beforehand. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Received: from omr-m35.mx.aol.com (omr-m35.mx.aol.com [64.12.143.147]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n81JfQhH002228 for ; Tue, 1 Sep 2009 12:41:31 -0700 Received: from AOLDTCMEH01.ad.office.aol.com (aoldtcmeh01.office.aol.com [10.180.121.20]) by omr-m35.mx.aol.com (v117.7) with ESMTP id MAILOMRM355-7f3c4a9d71aa2b7; Tue, 01 Sep 2009 15:10:34 -0400 Received: from AOLMTCMEI01.ad.office.aol.com ([10.178.3.18]) by AOLDTCMEH01.ad.office.aol.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 15:10:35 -0400 Received: from [10.181.80.41] ([10.178.3.11]) by AOLMTCMEI01.ad.office.aol.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 15:10:33 -0400 Message-ID: <4A9D7334.2070005@corp.aol.com> Date: Tue, 01 Sep 2009 15:17:08 -0400 From: Michael Adkins User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Sep 2009 19:10:33.0650 (UTC) FILETIME=[E14B8920:01CA2B37] X-AOL-IP: 10.180.121.20 X-Greylist: Delayed for 00:30:47 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 01 Sep 2009 12:41:31 -0700 (PDT) Cc: MAAWG Technical Committee , "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] [technical] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 19:41:31 -0000 J D Falk wrote: > On 01/09/2009 12:40, "Murray S. Kucherawy" wrote: > > >> It would also be helpful to know based on list traffic how many likely >> participants there will be. Thus, please reply to the list (see below) if you >> would be interested in participating both in the BoF and the working group >> (once it starts) by being part of list conversations and, better yet, >> attending IETF conferences and/or submitting document contributions. The more >> momentum we can demonstrate, the more the IETF will be willing to move >> forward. >> > > I plan to participate (most likely in person in Hiroshima), and contribute, > and will continue to implement and evangelize ARF both personally and on > behalf of my employer. > > There's no chance I could make it to Hiroshima, but I would like to participate. Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n81JfPaj002224 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Tue, 1 Sep 2009 12:41:30 -0700 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Tue, 1 Sep 2009 12:10:48 -0700 From: "Murray S. Kucherawy" To: Dave CROCKER Date: Tue, 1 Sep 2009 12:10:47 -0700 Thread-Topic: [technical] ARF working group interest? Thread-Index: AcorN04p1g1cRpU3QPilTu46xstq0wAAGvIA Message-ID: References: <4A9D70A8.7020108@bbiw.net> In-Reply-To: <4A9D70A8.7020108@bbiw.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" MIME-Version: 1.0 X-Greylist: Delayed for 00:30:37 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 01 Sep 2009 12:41:30 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n81JfPaj002224 Cc: "technical@maawg.org" , "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] [technical] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 19:41:30 -0000 > -----Original Message----- > From: Dave CROCKER [mailto:dcrocker@bbiw.net] > Sent: Tuesday, September 01, 2009 12:06 PM > To: Murray S. Kucherawy > Cc: abuse-feedback-report@mipassoc.org; technical@maawg.org > Subject: Re: [technical] ARF working group interest? > > A concern that I keep expressing about the current approach being taken > to > working group formation is when the decision has to be made that > changes are > necessary. > > Working groups are extremely expensive, in time and effort. The time > for > deciding whether changes are needed is before wg formation, not after. Recent chatter on the ARF list suggests that there is some momentum toward removing stuff from the current specification. That's not to say there's consensus to do so, but there is interest in discussing it. Received: from mail-vw0-f189.google.com (mail-vw0-f189.google.com [209.85.212.189]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n81JS8FH001440 for ; Tue, 1 Sep 2009 12:28:14 -0700 Received: by vws27 with SMTP id 27so312896vws.3 for ; Tue, 01 Sep 2009 12:28:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.108.39 with SMTP id d39mr9210639vcp.12.1251833288084; Tue, 01 Sep 2009 12:28:08 -0700 (PDT) In-Reply-To: References: From: Yakov Shafranovich Date: Tue, 1 Sep 2009 15:27:48 -0400 Message-ID: <501c18e00909011227u420e5ba3p68ede02a86701cdd@mail.gmail.com> To: "Murray S. Kucherawy" Content-Type: text/plain; charset=windows-1252 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 01 Sep 2009 12:28:14 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sbh17.songbird.com id n81JS8FH001440 Cc: "technical@maawg.org" , "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 19:28:14 -0000 2009/9/1 Murray S. Kucherawy : >... > One of the main functions of creating the working group will be to take on > the technical work of considering whether ARF as it is currently defined is > necessary and sufficient.  That is, we should consider dropping stuff that’s > not actually useful or ambiguous, and adding what appears to be missing. > ARF has seen some real-world traction so the experience of those sending > and/or receiving ARF messages will be valuable in that process.  There have > also been some submissions about features that should be added, and these > need to be considered within the rigorous context of a standards working > group.  The output of the working group will be the proposed standard > document(s) that define ARF and any adjunct proposals. > Thanks for your hard work to get us this far. I have some concern about separating the core ARF standard from the extensions. As I wrote it originally, the standard was meant to be highly extensible which is why it comes with a whole slew of IANA registries.Perhaps we should make this distinction more clear in the charter and work towards including the most widely used extensions in the core standard Thus, we will be focusing the work of the WG on getting ARF itself approved first. Work on additional extensions to the core standard can be done after the main work is done. I am afraid that getting bogged down in the extensions and what to include will get us away from approving the ARF format itself. >  .... > > It would also be helpful to know based on list traffic how many likely > participants there will be.  Thus, please reply to the list (see below) if > you would be interested in participating both in the BoF and the working > group (once it starts) by being part of list conversations and, better yet, > attending IETF conferences and/or submitting document contributions.  The > more momentum we can demonstrate, the more the IETF will be willing to move > forward. > I hope to participate remotely. >  ... > > The most recent version of the draft charter is attached.  It includes some > of the suggestions I’ve collected at past MAAWG conferences.  A few of these > have been discussed recently on the ARF list, but all of them are subject to > review by participants. > As per our email, some of the historical stuff needs to be adjusted. Yakov Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n81JAfxd000341 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Tue, 1 Sep 2009 12:10:47 -0700 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Tue, 1 Sep 2009 11:40:06 -0700 From: "Murray S. Kucherawy" To: "abuse-feedback-report@mipassoc.org" , "technical@maawg.org" Date: Tue, 1 Sep 2009 11:40:05 -0700 Thread-Topic: ARF working group interest? Thread-Index: AcorM59hnEV7ntJ4S1in9EceGNSM4w== 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_BB012BD379D7B046ABE1472D8093C61C0116CA29BBEXCHC2corpclo_" MIME-Version: 1.0 X-Greylist: Delayed for 00:30:36 by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 01 Sep 2009 12:10:47 -0700 (PDT) Subject: [feedback-report] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 19:10:47 -0000 --_004_BB012BD379D7B046ABE1472D8093C61C0116CA29BBEXCHC2corpclo_ Content-Type: multipart/alternative; boundary="_000_BB012BD379D7B046ABE1472D8093C61C0116CA29BBEXCHC2corpclo_" --_000_BB012BD379D7B046ABE1472D8093C61C0116CA29BBEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At IETF 75 in Stockholm in July, a presentation was made of a charter for a= potential Abuse Report Format (ARF) working group. Basically, the main go= al of the proposed working group is to move the ARF specification toward st= andardization using the collaboration and review procedures and expertise t= hat the IETF provides, and then extend ARF into relevant areas such as DKIM= reporting. Standardization of ARF is an important goal that will have the benefits of = incremental enhancement over the current specification, increasing the comm= unity it supports and thus the community likely to subscribe to using it. One of the main functions of creating the working group will be to take on = the technical work of considering whether ARF as it is currently defined is= necessary and sufficient. That is, we should consider dropping stuff that= 's not actually useful or ambiguous, and adding what appears to be missing.= ARF has seen some real-world traction so the experience of those sending = and/or receiving ARF messages will be valuable in that process. There have= also been some submissions about features that should be added, and these = need to be considered within the rigorous context of a standards working gr= oup. The output of the working group will be the proposed standard documen= t(s) that define ARF and any adjunct proposals. The next step toward making this a reality is to host a Birds-of-a-Feather = session about the idea of starting a working group. The purpose of this is= to allow the IETF to observe how much interest and support there is behind= the effort, thus warranting the establishment of the working group. I am = planning to submit a BoF request for IETF 76 this coming November in Hirosh= ima. You can show your support for the idea of having a working group by a= ttending the BoF either in person or remotely (they usually have a jabber s= erver set up). In the IETF, the best type of support is participation. It= demonstrates that the industry might add the work to products and use it i= n operations. Due to other commitments I won't be able to attend in person in Hiroshima, = but I will however be participating remotely. It would also be helpful to know based on list traffic how many likely part= icipants there will be. Thus, please reply to the list (see below) if you = would be interested in participating both in the BoF and the working group = (once it starts) by being part of list conversations and, better yet, atten= ding IETF conferences and/or submitting document contributions. The more m= omentum we can demonstrate, the more the IETF will be willing to move forwa= rd. Finally, one of the points of the charter is to consider some proposed exte= nsions. Although I have tried to be representative of those extensions peo= ple have discussed with me privately, there's a lot more credibility lent t= o the effort if those conversations are public. So, if you have proposed e= xtensions to ARF and you have not yet posted to this list, or if you'd like= to express support for the proposed extensions listed in the charter, plea= se do so. It may even get some discussion going right away which of course= will demonstrate interest. The most recent version of the draft charter is attached. It includes some= of the suggestions I've collected at past MAAWG conferences. A few of the= se have been discussed recently on the ARF list, but all of them are subjec= t to review by participants. Of course, everyone is invited to make suggestions and participate in the d= iscussion for any work to be done by the working group. The mailing list i= s at abuse-report-format@mipassoc.org; see http://mipassoc.org/mailman/list= info/abuse-feedback-report for links to subscriptions and archives. Thanks, -MSK --_000_BB012BD379D7B046ABE1472D8093C61C0116CA29BBEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At IETF 75 in Stockholm in July, a presentation was ma= de of a charter for a potential Abuse Report Format (ARF) working group.  Ba= sically, the main goal of the proposed working group is to move the ARF specification to= ward standardization using the collaboration and review procedures and expertise that the IETF provides, and then extend ARF into relevant areas such as DKI= M reporting.

 

Standardization of ARF is an important goal that will = have the benefits of incremental enhancement over the current specification, increasing the community it supports and thus the community likely to subsc= ribe to using it.

 

One of the main functions of creating the working grou= p will be to take on the technical work of considering whether ARF as it is curren= tly defined is necessary and sufficient.  That is, we should consider drop= ping stuff that’s not actually useful or ambiguous, and adding what appear= s to be missing.  ARF has seen some real-world traction so the experience o= f those sending and/or receiving ARF messages will be valuable in that process.&nbs= p; There have also been some submissions about features that should be added, and th= ese need to be considered within the rigorous context of a standards working group.  The output of the working group will be the proposed standard document(s) that define ARF and any adjunct proposals.

 

The next step toward making this a reality is to host = a Birds-of-a-Feather session about the idea of starting a working group. = ; The purpose of this is to allow the IETF to observe how much interest and suppo= rt there is behind the effort, thus warranting the establishment of the workin= g group.  I am planning to submit a BoF request for IETF 76 this coming = November in Hiroshima.  You can show your support for the idea of having a work= ing group by attending the BoF either in person or remotely (they usually have a jabb= er server set up).  In the IETF, the best type of support is participatio= n.  It demonstrates that the industry might add the work to products and use it in operations.

 

Due to other commitments I won’t be able to atte= nd in person in Hiroshima, but I will however be participating remotely.

 

It would also be helpful to know based on list traffic= how many likely participants there will be.  Thus, please reply to the lis= t (see below) if you would be interested in participating both in the BoF and the working group (once it starts) by being part of list conversations and, bet= ter yet, attending IETF conferences and/or submitting document contributions.&n= bsp; The more momentum we can demonstrate, the more the IETF will be willing to move forward.

 

Finally, one of the points of the charter is to consid= er some proposed extensions.  Although I have tried to be representative = of those extensions people have discussed with me privately, there’s a lot mor= e credibility lent to the effort if those conversations are public.  So,= if you have proposed extensions to ARF and you have not yet posted to this list, o= r if you’d like to express support for the proposed extensions listed in t= he charter, please do so.  It may even get some discussion going right aw= ay which of course will demonstrate interest.

 

The most recent version of the draft charter is attach= ed.  It includes some of the suggestions I’ve collected at past MAAWG conferences.  A few of these have been discussed recently on the ARF l= ist, but all of them are subject to review by participants.

 

Of course, everyone is invited to make suggestions and participate in the discussion for any work to be done by the working group.=   The mailing list is at abuse-report-format@mipassoc.org; see http://mipassoc.org/mailman/listinfo/abuse-feedback-report for links to subscriptions and archives.

 

Thanks,

 

-MSK

--_000_BB012BD379D7B046ABE1472D8093C61C0116CA29BBEXCHC2corpclo_-- --_004_BB012BD379D7B046ABE1472D8093C61C0116CA29BBEXCHC2corpclo_ Content-Type: text/plain; name="arf-charter v04.txt" Content-Description: arf-charter v04.txt Content-Disposition: attachment; filename="arf-charter v04.txt"; size=3516; creation-date="Mon, 20 Jul 2009 10:36:14 GMT"; modification-date="Mon, 20 Jul 2009 10:36:14 GMT" Content-Transfer-Encoding: base64 ICAgV29ya2luZyBHcm91cCBOYW1lOg0KICAgICAgICBBYnVzZSBSZXBvcnRpbmcgRm9ybWF0IChB UkYpDQoNCiAgIElFVEYgQXJlYToNCiAgICAgICAgQXBwbGljYXRpb25zIEFyZWENCg0KICAgQ2hh aXIocyk6DQogICAgICAgIFRCRA0KDQogICBBcHBsaWNhdGlvbnMgQXJlYSBEaXJlY3RvcihzKToN CiAgICAgICAgTGlzYSBEdXNzZWF1bHQgPExpc2EuRHVzc2VhdWx0QG1lc3NhZ2luZ2FyY2hpdGVj dHMuY29tPg0KICAgICAgICBBbGV4ZXkgTWVsbmlrb3YgPGFsZXhleS5tZWxuaWtvdkBpc29kZS5j b20+DQoNCiAgIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3I6DQogICAgICAgIFRCRA0KDQogICBN YWlsaW5nIExpc3RzOg0KICAgICAgICBHZW5lcmFsIERpc2N1c3Npb246IGFidXNlLWZlZWRiYWNr LXJlcG9ydEBtaXBhc3NvYy5vcmcNCiAgICAgICAgVG8gU3Vic2NyaWJlOiBodHRwOi8vbWlwYXNz b2Mub3JnL21haWxtYW4vbGlzdGluZm8vYWJ1c2UtZmVlZGJhY2stcmVwb3J0DQogICAgICAgIEFy Y2hpdmU6IGh0dHA6Ly9taXBhc3NvYy5vcmcvbWFpbG1hbi9saXN0aW5mby9hYnVzZS1mZWVkYmFj ay1yZXBvcnQNCg0KICAgRGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cDoNCglNZXNzYWdpbmcg YW50aS1hYnVzZSBvcGVyYXRpb25zIGJldHdlZW4gaW5kZXBlbmRlbnQgc2VydmljZXMgb2Z0ZW4g cmVxdWlyZXMNCglzZW5kaW5nIHJlcG9ydHMgb24gb2JzZXJ2ZWQgZnJhdWQsIHNwYW0gdmlydXMg b3Igb3RoZXIgYWJ1c2UgYWN0aXZpdHkuICBBDQoJc3RhbmRhcmRpemVkIHJlcG9ydCBmb3JtYXQg ZW5hYmxlcyBhdXRvbWF0ZWQgcHJvY2Vzc2luZy4gIFRoZSBBYnVzZSBSZXBvcnRpbmcNCglGb3Jt YXQgKEFSRikgc3BlY2lmaWNhdGlvbiBoYXMgZ2FpbmVkIHN1ZmZpY2llbnQgcG9wdWxhcml0eSB0 byB3YXJyYW50IGZvcm1hbA0KCWNvZGlmaWNhdGlvbiwgdG8gZW5zdXJlIGZ1dHVyZSBpbnRlcm9w ZXJhYmlsaXR5IHdpdGggbmV3IGltcGxlbWVudGF0aW9ucy4NCglUaGUgcHJpbWFyeSBmdW5jdGlv biBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBiZSB0byBzb2xpY2l0IHJldmlldyBhbmQNCgly ZWZpbmVtZW50IG9mIHRoZSBleGlzdGluZyBzcGVjaWZpY2F0aW9uLg0KDQoJQVJGIHdhcyBkZXZl bG9wZWQgYnkgYSBtZXNzYWdpbmcgdHJhZGUgb3JnYW5pemF0aW9uIGluZGVwZW5kZW50IG9mIHRo ZSBJRVRGLA0KCWFuZCB1c2VzIGEgZm9ybWF0IHNpbWlsYXIgdG8gYSBEZWxpdmVyeSBTdGF0dXMg Tm90aWZpY2F0aW9uIChEU04sIFJGQzM0NjQpDQoJdG8gcmVwb3J0IGZyYXVkLCBzcGFtLCB2aXJ1 c2VzIG9yIG90aGVyIGFidXNpdmUgYWN0aXZpdHkgaW4gdGhlIGVtYWlsIHN5c3RlbS4NCglUaGUg YmFzaWMgZm9ybWF0IGlzIGFtZW5hYmxlIHRvIHByb2Nlc3NpbmcgYnkgaHVtYW5zIG9yIHNvZnR3 YXJlLCB3aXRoIHRoZQ0KCWxhdHRlciByZXF1aXJpbmcgdGhlIGZvcm1hdCB0byBiZSBzdGFuZGFy ZGl6ZWQsIHRvIHBlcm1pdCBpbnRlcm9wZXJhYmlsaXR5DQoJYmV0d2VlbiBhdXRvbWF0ZWQgc2Vy dmljZXMsIHBhcnRpY3VsYXJseSB3aXRob3V0IHByaW9yIGFycmFuZ2VtZW50Lg0KDQoJQVJGIGFz IGluaXRpYWxseSBkZWZpbmVkIGlzIGFscmVhZHkgaW4gd2lkZXNwcmVhZCB1c2UgYXQgbGFyZ2Ug SVNQcywgc28NCglpbnRlcm9wZXJhYmlsaXR5IGNhbiBiZSBkZW1vbnN0cmF0ZWQuICBTb21lIHRv b2xzIGFscmVhZHkgZXhpc3QNCglmb3IgcHJvY2Vzc2luZyBBUkYgbWVzc2FnZXMsIGEgZmV3IG9m IHdoaWNoIGFyZSBvcGVuIHNvdXJjZS4gIEluIG9yZGVyIHRvDQoJcHJlc2VydmUgdGhlIGluc3Rh bGxlZCBiYXNlLCB0aGUgd29ya2luZyBncm91cCB3aWxsIG1ha2UgdGhlIG1pbmltdW0gY2hhbmdl cw0KCW5lY2Vzc2FyeSB0byB0aGUgZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbiBhbmQgd2lsbCBzZWVr IHRvIGhhdmUgYmFja3dhcmQNCgljb21wYXRpYmlsaXR5LiAgRnVydGhlcm1vcmUsIHNvbWUgZXh0 ZW5zaW9ucyB0byB0aGUgY3VycmVudCBwcm9wb3NhbCBhcmUNCglvZiBpbnRlcmVzdCB0byB0aGUg Y29tbXVuaXR5LCBzdWNoIGFzIHRoZSBtZWFucyBmb3IgYW4gb3BlcmF0b3IgdG8gYWR2ZXJ0aXNl DQoJYW4gZW1haWwgYWRkcmVzcyB0byB3aGljaCBhYnVzZSByZXBvcnRzIHVzaW5nIEFSRiBzaG91 bGQgYmUgc2VudC4gIFRoZQ0KCXdvcmtpbmcgZ3JvdXAgd2lsbCB0YWtlIG9uIHRoZSB0YXNrIG9m IHNwZWNpZnlpbmcgc3VjaCBhIG1lY2hhbmlzbS4NCg0KCVRoZSBpbml0aWFsIHByb3Bvc2FsIGlz IHB1Ymxpc2hlZCBhcyBkcmFmdC1zaGFmcmFub3ZpY2gtZmVlZGJhY2stcmVwb3J0LA0KCWFuZCB0 aGlzIHdpbGwgcHJvdmlkZSB0aGUgd29ya2luZyBncm91cCdzIHN0YXJ0aW5nIHBvaW50Lg0KDQoJ VGhlIGZvbGxvd2luZyBwb3NzaWxibGUgcmVwb3J0aW5nIGV4dGVuc2lvbnMgd2lsbCBiZSBjb25z aWRlcmVkOg0KDQoJMSkgZHJvcCBib3hlcyAoZGV0ZWN0aW9uIG9mIGEgbWFpbGJveCB1c2VkIHRv IHJlY2VpdmUgdGhpbmdzIGxpa2Ugc3RvbGVuDQoJICAgY3JlZGl0IGNhcmRzKQ0KCTIpIGJvdG5l dCBkZXRlY3Rpb24gKGkuZS4gcmVwb3J0aW5nIG9mIHRyYWZmaWMgdGhhdCBhcHBlYXJzIHRvIGhh dmUgY29tZQ0KCSAgIGZyb20gYSBib3QsIHJlZ2FyZGxlc3Mgb2YgY29udGVudCkNCgkzKSBTU0gg YXR0YWNrcw0KCTQpIEZUUCBhdHRhY2tzDQoJNSkgV2ViIHNlcnZlciBhdHRhY2tzDQoJNikgbWFp bCBzZW50IHRvIGEgaG9uZXlwb3Qgb3Igc3BhbSB0cmFwDQoJNykgbWFsd2FyZSBjb25uZWN0aW9u cyB0byBzaW5raG9sZXMNCgk4KSBERG9TIHJlcG9ydHMNCg0KCUluIGFkZGl0aW9uLCB0aGUgZ3Jv dXAgd2lsbCBzcGVjaWZ5IHRoZSBpbnRlZ3JhdGlvbiBvZiBBUkYgaW50byBES0lNIHVzZQ0KCXVz aW5nIGRyYWZ0LWt1Y2hlcmF3eS1ka2ltLXJlcG9ydGluZyBhcyBpdHMgaW5wdXQuICBJdCBjb250 YWlucyBleHRlbnNpb25zDQoJdG8gREtJTSB0aGF0IGFyZSByZWxhdGVkIHRvIEFSRiBhcyBhIG1l YW5zIG9mIHJlcG9ydGluZyBES0lNLXJlbGF0ZWQgZmFpbHVyZXMNCgl3aGljaCBpbmNsdWRlIHBo aXNoaW5nICgiZnJhdWQiKSBhbmQgYXMgc3VjaCBhcmUgcmVsZXZhbnQgdG8gdGhlIEFSRiBlZmZv cnQuDQoNCiAgIEdvYWxzIGFuZCBNaWxlc3RvbmVzOg0KCU5vdiAwOQlJc3N1ZSBmaXJzdCBXRy1i YXNlZCBJbnRlcm5ldC1EcmFmdCBkZWZpbmluZyBBUkYNCglKYW4gMDkJQWNoaWV2ZSBjb25zZW5z dXMgb24gYW55IFdHLWJhc2VkIGNoYW5nZXMgdG8gQVJGDQoJRmViIDEwCVN1Ym1pdCBBUkYgSUQg dG8gSUVTRyBmb3IgcHVibGljYXRpb24NCglBcHIgMTAJSXNzdWUgZmlyc3QgV0ctYmFzZWQgSUQg YWJvdXQgREtJTSByZXBvcnRpbmcgZXh0ZW5zaW9ucw0KCUp1biAxMAlBY2hpZXZlIGNvbnNlbnN1 cyBvbiBES0lNIHJlcG9ydGluZyBleHRlbnNpb25zIGRyYWZ0DQoJSnVsIDEwCVN1Ym1pdCBES0lN IHJlcG9ydGluZyBJRCB0byBJRVNHIGZvciBwdWJsaWNhdGlvbg0K --_004_BB012BD379D7B046ABE1472D8093C61C0116CA29BBEXCHC2corpclo_-- Received: from [127.0.0.1] (ppp-68-120-198-98.dsl.pltn13.pacbell.net [68.120.198.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n81J6JMt032566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Sep 2009 12:06:25 -0700 Message-ID: <4A9D70A8.7020108@bbiw.net> Date: Tue, 01 Sep 2009 12:06:16 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 01 Sep 2009 12:06:25 -0700 (PDT) Cc: "technical@maawg.org" , "abuse-feedback-report@mipassoc.org" Subject: Re: [feedback-report] [technical] ARF working group interest? X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Public forum for discussion on the feedback-report draft List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 19:06:25 -0000 Murray S. Kucherawy wrote: > One of the main functions of creating the working group will be to take on > the technical work of considering whether ARF as it is currently defined is > necessary and sufficient. That is, we should consider dropping stuff that’s > not actually useful or ambiguous, and adding what appears to be missing. ARF > has seen some real-world traction so the experience of those sending and/or > receiving ARF messages will be valuable in that process. There have also > been some submissions about features that should be added, and these need to > be considered within the rigorous context of a standards working group. The > output of the working group will be the proposed standard document(s) that > define ARF and any adjunct proposals. In spite of being a cat person, I see this bit of work as important. A concern that I keep expressing about the current approach being taken to working group formation is when the decision has to be made that changes are necessary. Working groups are extremely expensive, in time and effort. The time for deciding whether changes are needed is before wg formation, not after. That is, my view of when to have a working group decide on the particular work to be done is before it is chartered, not after. There need to be a clear and solid constituency for making particular types of changes. The 8 items listed in the draft charter all look reasonable. And no, they don't need to be solved before chartering. But there does need to be clear support for --essentially, statements of desire to implement -- particular ones. IMO. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net