Received: from smtp105.plus.mail.mud.yahoo.com (smtp105.plus.mail.mud.yahoo.com [68.142.206.238]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with SMTP id k4RIx9no004943 for ; Sat, 27 May 2006 11:59:09 -0700 Received: (qmail 93139 invoked from network); 27 May 2006 18:58:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=snake; d=yahoo-inc.com; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=FReT/oJdp5p9azczHSWjVwYK0kZuvpypcZxFcrChDlEl1/NSkKBvqI/HOera3vDm ; Received: from unknown (HELO ?192.168.1.113?) (jdfalk@64.142.85.192 with plain) by smtp105.plus.mail.mud.yahoo.com with SMTP; 27 May 2006 18:58:37 -0000 Message-ID: <4478A15C.7030309@yahoo-inc.com> Date: Sat, 27 May 2006 11:58:36 -0700 From: "J.D. Falk" Organization: Yahoo! User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.6.0.104 MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org Subject: Knowing who pressed the button (was Re: [feedback-report] ARF spec oversights) References: <1976958202.20060525145950@pobox.com> <173804e10605260532wb6a4270p6c3001b54498b5d3@mail.gmail.com> In-Reply-To: <173804e10605260532wb6a4270p6c3001b54498b5d3@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: jdfalk@yahoo-inc.com X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 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, 27 May 2006 18:59:16 -0000 On 2006-05-26 05:32, Mark Bainter wrote: > We cannot stop sending that user email if we don't know who s/he is. Nobody disagrees -- but writing that requirement into ARF won't make AOL's lawyers change their minds. Better to keep it optional in the technical spec, and use social pressure to encourage best practices. (Speaking of best practices: you get the full headers in the report, and you can put a token in an x-header which matches up with the subscriber in your database. That'll survive forwarding, too, so it's a lot more accurate than just knowing who pressed the button. But a sender worthy of their job doesn't need /me/ to tell them this stuff, right?) -- J.D. Falk, Anti-Spam Product Manager Yahoo! Communications Platform Team Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k4QJbeck000705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 26 May 2006 12:37:40 -0700 Received: from pool-70-17-215-42.balt.east.verizon.net ([70.17.215.42]:3043 helo=[192.168.1.2]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52) id 1Fji7Q-0003Ck-0e; Fri, 26 May 2006 15:37:08 -0400 Message-ID: <447758DD.5070809@solidmatrix.com> Date: Fri, 26 May 2006 15:37:01 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Mark Bainter Subject: Re: [feedback-report] ARF spec oversights References: <1976958202.20060525145950@pobox.com> <173804e10605260532wb6a4270p6c3001b54498b5d3@mail.gmail.com> In-Reply-To: <173804e10605260532wb6a4270p6c3001b54498b5d3@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-HMDNSGroup-MailScanner-Information: Please contact the ISP for more information X-HMDNSGroup-MailScanner: Found to be clean X-HMDNSGroup-MailScanner-SpamCheck: X-HMDNSGroup-MailScanner-From: yakovs@solidmatrix.com X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - manet.hmdnsgroup.com X-AntiAbuse: Original Domain - mipassoc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - solidmatrix.com X-Source: X-Source-Args: X-Source-Dir: X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: yakovs@solidmatrix.com Cc: abuse-feedback-report@mipassoc.org X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 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, 26 May 2006 19:37:46 -0000 Mark Bainter wrote: > > Incidentally, I DO agree with your request to require the name of the > offended party. I can understand some of the hesitance here, but most > people who are going to be using this to try and be 'good' senders, > like us, are generally sending the mail to customers at other ISPs. > Trying to tag the fields we know for sure we'll get back historically > only increases the chance of users filing a complaint about it. > > We cannot stop sending that user email if we don't know who s/he is. > We already have this feature, there is an optional header "Removal-Recipient" defined in section 5.3 as follows: " o "Removal-Recipient:" - indicates the email address to be removed from the mailing list (MUST only be used with "opt-out" and "opt- out-list" types). The format of this field is defined in section 3.4.1 of RFC 2822 [6]. " Yakov Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k4QCXaSJ001415 for ; Fri, 26 May 2006 05:33:36 -0700 Received: by nf-out-0910.google.com with SMTP id k26so50960nfc for ; Fri, 26 May 2006 05:33:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oAxtVBxm34WeGKXeNZNu6r09Zvkb5WxhzmexwgnT6/e6XgSqinkn/Yk2MskB4Wu2EM1oeUUU/p6APuhkAwLlp6SmYbBSG1Mm35CXlbWc4ocHPNcB9JBx/jNhWITMyoQxYIj7wGK9yQ/nDLGVERKGQboSj77p6U23xJi+mlKQtDs= Received: by 10.48.43.16 with SMTP id q16mr170141nfq; Fri, 26 May 2006 05:32:31 -0700 (PDT) Received: by 10.48.216.16 with HTTP; Fri, 26 May 2006 05:32:31 -0700 (PDT) Message-ID: <173804e10605260532wb6a4270p6c3001b54498b5d3@mail.gmail.com> Date: Fri, 26 May 2006 07:32:31 -0500 From: "Mark Bainter" To: abuse-feedback-report@mipassoc.org Subject: Re: Re[2]: [feedback-report] ARF spec oversights In-Reply-To: <1976958202.20060525145950@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <1976958202.20060525145950@pobox.com> X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: mbainter@gmail.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sb7.songbird.com id k4QCXaSJ001415 X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 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, 26 May 2006 12:33:44 -0000 On 5/24/06, Chris Drake wrote: > As it stands - what's in your standard is no use to me. I cannot > authorize action against my customers without confirmed, verified, > substantiated, authenticated reports with evidence. It is NOT my > problem how some other ISP designs their GUI to facility abuse > reporting - but if they want me to take action based on their reports, > I refuse to do so if they don't bother to put the effort in to prevent > mistaken reports, and give me what I need to protect my customers > against malicious ones. I know exactly what you're talking about. We even have messages sent by our users that are replied to by users, and then they still generate a spam complaint about it. Trying to comply with feedback requirements is a nightmare when the users treat it like it's a delete button. Particularly when they then call and complain and get irate when they stop receiving emails. I read through your message and tried to understand how it would improve things but I'm not sure it will. As these others have said, your suggestions are simply not controllable through the format being suggested here. This is just a format for reporting, not a means of enforcing good design methods. It would be nice if we could force users to have to click to confirm...to make reporting spam more difficult than deleting the email is. (Not make it a hurdle, just don't make it easier and more convenient than deleting emails) However I think any attempt to enforce a standard like that is simply not going to be accepted, leaving us witih nothing. And even without that, the ARF format is a big step forward. I hate to lose it because we tried for too much out of the gate. Incidentally, I DO agree with your request to require the name of the offended party. I can understand some of the hesitance here, but most people who are going to be using this to try and be 'good' senders, like us, are generally sending the mail to customers at other ISPs. Trying to tag the fields we know for sure we'll get back historically only increases the chance of users filing a complaint about it. We cannot stop sending that user email if we don't know who s/he is. Mark Bainter Email Operations Manager Match.com Received: from smtp103.plus.mail.mud.yahoo.com (smtp103.plus.mail.mud.yahoo.com [68.142.206.236]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with SMTP id k4PL8L6F014249 for ; Thu, 25 May 2006 14:08:21 -0700 Received: (qmail 60603 invoked from network); 25 May 2006 21:07:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=snake; d=yahoo-inc.com; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Dy8gi8lCigcq5luk8YD7LbEM+MqkK65wLhsyJj6snUIcZ6WTGLqgArDLTj5WxZeO ; Received: from unknown (HELO ?66.228.167.95?) (jdfalk@66.228.167.95 with plain) by smtp103.plus.mail.mud.yahoo.com with SMTP; 25 May 2006 21:07:49 -0000 Message-ID: <44761CA3.4020308@yahoo-inc.com> Date: Thu, 25 May 2006 14:07:47 -0700 From: "J.D. Falk" Organization: Yahoo! User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.6.0.104 MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] ARF spec oversights References: <1976958202.20060525145950@pobox.com> In-Reply-To: <1976958202.20060525145950@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: jdfalk@yahoo-inc.com X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 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, 25 May 2006 21:08:25 -0000 On 2006-05-24 21:59, Chris Drake wrote: > I guess I didn't make my point clear enough. Unless your "standard" > produces something that me, as an ISP abuse-desk manager, can actually > *use* and RELY upon, there's no point having any standard at all. No need to get upset. All of us who've been involved with the development of this standard have many years of experience with abuse desks, and with trying to get abuse folks to agree on anything. It sounds like you've made the common mistake of assuming that a single report MUST result in a single action, or that ARF is intended to somehow replace standard reports send to abuse desks. Neither of those are necessarily true. Instead, automated reports are sent to automated report processing systems. Depending on the policies of the report recipient, the automated report processing system MAY act on a single report -- or, you might want to wait until there've been multiple reports about the same user, or the same IP, or the same URL, or whatever. In other words, the policy is in the processing -- not in the data format. -- J.D. Falk, Anti-Spam Product Manager Yahoo! Communications Platform Team Received: from srve.com (copa.geek.net.au [203.217.18.13]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k4P50BIg009177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 24 May 2006 22:00:14 -0700 Received: from BLANK (203-217-18-9.perm.iinet.net.au [203.217.18.9]) by srve.com (8.13.6/8.12.11) with ESMTP id k4P4xZq8023403 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 25 May 2006 04:59:36 GMT Date: Thu, 25 May 2006 14:59:50 +1000 From: Chris Drake X-Priority: 3 (Normal) Message-ID: <1976958202.20060525145950@pobox.com> To: abuse-feedback-report@mipassoc.org Subject: Re[2]: [feedback-report] ARF spec oversights In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: christopher@pobox.com X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 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, 25 May 2006 05:00:30 -0000 Hi Mike & J.D., I guess I didn't make my point clear enough. Unless your "standard" produces something that me, as an ISP abuse-desk manager, can actually *use* and RELY upon, there's no point having any standard at all. As it stands - what's in your standard is no use to me. I cannot authorize action against my customers without confirmed, verified, substantiated, authenticated reports with evidence. It is NOT my problem how some other ISP designs their GUI to facility abuse reporting - but if they want me to take action based on their reports, I refuse to do so if they don't bother to put the effort in to prevent mistaken reports, and give me what I need to protect my customers against malicious ones. Don't take my word for it - phone up your own ISP and ask their abuse desk what they do with AOL "TOS" complaints. You will find that we all ignore them, even ARF compliant ones, because 90%+ are mistaken reports, and we either do not have the time to read mounds of AOL users personal emails looking for individual ones that might be spam, or, we take an ethical position that it's not right that we *should* be reading AOL users personal emails. If you improve your standard by incorporating my suggestions, that's the pressure that ISPs need to improve their GUIs to comply with your standard, which is all I need an an abuse-desk manager to properly and immediately act on genuine abuse complaints. Win. Win. Win. Kind Regards, Chris Drake Received: from pkc-exch1.adknowledge.com (pkc-exch1.adknowledge.com [67.53.160.50]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k4OJAjU8025958 for ; Wed, 24 May 2006 12:10:45 -0700 X-Mimeole: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [feedback-report] ARF spec oversights Date: Wed, 24 May 2006 14:10:13 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [feedback-report] ARF spec oversights Thread-Index: AcZ/XHTwnTSl3smKSfqZ773f3fJXVwABPeug From: "Mike Fitzgerald" To: X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: mfitzgerald@adknowledge.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sb7.songbird.com id k4OJAjU8025958 X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 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, 24 May 2006 19:10:52 -0000 My 2 cents... > On 2006-05-24 00:23, Chris Drake wrote: > > > 1. Mandatory - Generator identity > > > > There needs to be a way to distinguish between human-generated > > reports, machine generated reports, vindictive malicious (eg: DoS) > > reports, and 3rd-party (eg: not the original recipient) reports. > > What's the use case you're thinking of? I would hope that we could rely on an existing standard to authenticate the identity of the generator and prevent spoofing / DoS. DomainKeys and/or SPF should work well. > > 3. Recommended - "Feedback type selected by" header > > > > Lots of people hit the "spam" button when they get emails from > > their friends or enemies, and that they merely dislike the > > contents. We need to know how the "Feedback type" was determined: > > is it an accurate description of the reason for the report which > > was something the reporting original recipient selected, or is it > > some kind of generic guess or hard-coded constant inserted by the > > reporting ISPs abuse system ? > > Do any current implementations care about feedback type? Feedback type (e.g. abuse or opt-out) can be determined by the existing "Feedback-Type:" header. How the feedback type was determined is an implementation detail of the ISP that I'm not sure should be exposed to report recipients. There are so many different implementation possibilities that it would be difficult to enumerate them in a standard and unclear how a receiver should treat them differently. In any case, there exists a "User-Agent:" header, which "indicates the name and version of the software program that generated the report." Best Regards, Mike Fitzgerald Team Lead - Email Operations AdKnowledge, Inc. Received: from smtp104.plus.mail.mud.yahoo.com (smtp104.plus.mail.mud.yahoo.com [68.142.206.237]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with SMTP id k4OI42oP015895 for ; Wed, 24 May 2006 11:04:02 -0700 Received: (qmail 12223 invoked from network); 24 May 2006 18:03:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=snake; d=yahoo-inc.com; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=fq9iI3Ln+6LQXk82boykKc4FQ1JdmWgCiMRYclDRBrYJjp4QFgVgSiLLTwwV1e5u ; Received: from unknown (HELO ?66.228.167.95?) (jdfalk@66.228.167.95 with plain) by smtp104.plus.mail.mud.yahoo.com with SMTP; 24 May 2006 18:03:29 -0000 Message-ID: <44749FF0.5060601@yahoo-inc.com> Date: Wed, 24 May 2006 11:03:28 -0700 From: "J.D. Falk" Organization: Yahoo! User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.6.0.104 MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] ARF spec oversights References: <181849176.20060524172322@pobox.com> In-Reply-To: <181849176.20060524172322@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: jdfalk@yahoo-inc.com X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 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, 24 May 2006 18:04:05 -0000 On 2006-05-24 00:23, Chris Drake wrote: > 1. Mandatory - Generator identity > > There needs to be a way to distinguish between human-generated > reports, machine generated reports, vindictive malicious (eg: DoS) > reports, and 3rd-party (eg: not the original recipient) reports. What's the use case you're thinking of? > 2. Recommended - confirmation status > > As 90%+ of the people on this list should know by now - the effect > of AOL, Gmail, Hotmail, etc folks putting their "Spam" button right > next to their "Trash" button means that a large number of users are > hitting the wrong button by mistake. Sounds like a user interface decision, rather than a problem with the standard. > Having a recommended (or perhaps even mandatory - to highlight how > important this is!) header to indicate whether or not the user > "just hit the spam button", or whether they were given an > opportunity to preview what they were about to report, and actually > confirmed that it was "spam" - is important. That still sounds like a user interface decision, rather than a problem with the standard. > Consider also that some emails are highly confidential, and are not > suitable for sending to abuse desks immediately upon clicking a > single button: rg: We also recently received a user-error > spam-report containing some extremely confidential, personal > banking information. And that's a policy issue, not a technical issue. If you think your users can't be trusted with a spam button, that's between you and your users. > 3. Recommended - "Feedback type selected by" header > > Lots of people hit the "spam" button when they get emails from > their friends or enemies, and that they merely dislike the > contents. We need to know how the "Feedback type" was determined: > is it an accurate description of the reason for the report which > was something the reporting original recipient selected, or is it > some kind of generic guess or hard-coded constant inserted by the > reporting ISPs abuse system ? Do any current implementations care about feedback type? > 4. Reporting individual Authentication > > There also needs to be a way to communicate to ARF report > recipients the results of an authenticity check performed against > the reporting individual - for example - a third-party might > maliciously choose "select-all" then "report as spam" with the > "remove" option selected to cause everyone that a victim > communicates with to be barred from sending email to the victim in > future. I'm not sure I understand the scenario you're describing. Are you talking about random third parties somehow gaining access to a Report Generator's reporting system? > 5. Confirmation requests > > Finally - we need a way to communicate back with the original > reporting entity - if they selected "remove" from a mailling list > that they're paying $1000 per year to be listed on, we need to let > them know that we honored their request, or if they submitted a > non-authenticated request - we need to get them to confirm this, > and we probably also need to get them their instructions for how to > cancel their account and get a refund. If you can't figure out who you sent the mail to, that's not the Report Generator's problem. -- J.D. Falk, Anti-Spam Product Manager Yahoo! Communications Platform Team Received: from srve.com (copa.geek.net.au [203.217.18.13]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k4O7Ni2h027800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 24 May 2006 00:23:46 -0700 Received: from BLANK (203-217-18-9.perm.iinet.net.au [203.217.18.9]) by srve.com (8.13.6/8.12.11) with ESMTP id k4O7N9fH026664 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 24 May 2006 07:23:10 GMT Date: Wed, 24 May 2006 17:23:22 +1000 From: Chris Drake X-Priority: 3 (Normal) Message-ID: <181849176.20060524172322@pobox.com> To: abuse-feedback-report@mipassoc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: christopher@pobox.com Subject: [feedback-report] ARF spec oversights X-BeenThere: abuse-feedback-report@mipassoc.org X-Mailman-Version: 2.1.5 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, 24 May 2006 07:23:49 -0000 Hi, There's a few important omissions in the ARF standard that I think need addressing. 1. Mandatory - Generator identity There needs to be a way to distinguish between human-generated reports, machine generated reports, vindictive malicious (eg: DoS) reports, and 3rd-party (eg: not the original recipient) reports. We need some extra mandatory fields to specify this 2. Recommended - confirmation status As 90%+ of the people on this list should know by now - the effect of AOL, Gmail, Hotmail, etc folks putting their "Spam" button right next to their "Trash" button means that a large number of users are hitting the wrong button by mistake. For mail operations who send zero spam and zero unsolicited and zero marketing emails, this results in an almost 100% false-positive complaint rate - that is - every single "spam" that gets reported is a result of a user hitting "Spam" by mistake. There needs to be a way for ISP staff to find actual spam complaints in amongst this sea of user errors, without having to read the personal emails of hundreds of "lame users". Having a recommended (or perhaps even mandatory - to highlight how important this is!) header to indicate whether or not the user "just hit the spam button", or whether they were given an opportunity to preview what they were about to report, and actually confirmed that it was "spam" - is important. Consider also that some emails are highly confidential, and are not suitable for sending to abuse desks immediately upon clicking a single button: rg: We also recently received a user-error spam-report containing some extremely confidential, personal banking information. 3. Recommended - "Feedback type selected by" header Lots of people hit the "spam" button when they get emails from their friends or enemies, and that they merely dislike the contents. We need to know how the "Feedback type" was determined: is it an accurate description of the reason for the report which was something the reporting original recipient selected, or is it some kind of generic guess or hard-coded constant inserted by the reporting ISPs abuse system ? 4. Reporting individual Authentication There also needs to be a way to communicate to ARF report recipients the results of an authenticity check performed against the reporting individual - for example - a third-party might maliciously choose "select-all" then "report as spam" with the "remove" option selected to cause everyone that a victim communicates with to be barred from sending email to the victim in future. As on ISP administering this bar - I need to know by who's *legitimate*, authenticated, authority this bar has been selected. 5. Confirmation requests Finally - we need a way to communicate back with the original reporting entity - if they selected "remove" from a mailling list that they're paying $1000 per year to be listed on, we need to let them know that we honored their request, or if they submitted a non-authenticated request - we need to get them to confirm this, and we probably also need to get them their instructions for how to cancel their account and get a refund. Kind Regards, Chris Drake