Received: from mrout2-b.corp.dcn.yahoo.com (mrout2-b.corp.dcn.yahoo.com [216.109.112.28]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j4VM5aWu003638 for ; Tue, 31 May 2005 15:05:36 -0700 Received: from [192.168.1.113] (snvvpn-10-72-66-c68.corp.yahoo.com [10.72.66.68]) by mrout2-b.corp.dcn.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id j4VM4XmO001184 for ; Tue, 31 May 2005 15:04:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:organization:user-agent: x-accept-language:mime-version:to:subject:references:in-reply-to:content-type; b=CPI2ddBK7BFYfsEVZDn6Yxh7uhwX3aw1VntRKQ2uDBft8qUoJZY8lGEw4PNcDVIH Message-ID: <429CDF71.5020409@yahoo-inc.com> Date: Tue, 31 May 2005 15:04:33 -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.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.6.0.104 X-Accept-Language: en-us, en MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] Aggregate spam reporting from Microsoft References: <42962828.1080407@solidmatrix.com> In-Reply-To: <42962828.1080407@solidmatrix.com> Content-Type: multipart/alternative; boundary="------------010605030900040901070003" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be 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: Tue, 31 May 2005 22:05:53 -0000 This is a multi-part message in MIME format. --------------010605030900040901070003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/26/05 12:48 PM, Yakov Shafranovich wrote: >Take a look at: > >http://postmaster.msn.com/snds/FAQ.aspx >http://postmaster.msn.com/snds/ > > MSN's SNDS covers aggregate mail traffic, rather than reports of individual messages. -- J.D. Falk, Anti-spam Product Manager, Yahoo! Mail jdfalk@yahoo-inc.com --------------010605030900040901070003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/26/05 12:48 PM, Yakov Shafranovich wrote: 
Take a look at:

http://postmaster.msn.com/snds/FAQ.aspx
http://postmaster.msn.com/snds/
MSN's SNDS covers aggregate mail traffic, rather than reports of individual messages.
-- 
J.D. Falk, Anti-spam Product Manager, Yahoo! Mail
jdfalk@yahoo-inc.com
--------------010605030900040901070003-- Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j4QJnvhr029278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 May 2005 12:49:58 -0700 Received: from 170.sub-70-216-164.myvzw.com ([70.216.164.170] helo=[192.168.0.66]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1DbOLs-0007rk-V9 for abuse-feedback-report@mipassoc.org; Thu, 26 May 2005 15:49:09 -0400 Message-ID: <42962828.1080407@solidmatrix.com> Date: Thu, 26 May 2005 15:48:56 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en 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-HMDNSGroup-MailScanner-Information: Please contact the ISP for more information X-HMDNSGroup-MailScanner: Found to be clean X-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: Found to be clean X-Songbird-From: yakovs@solidmatrix.com Subject: [feedback-report] Aggregate spam reporting from Microsoft 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, 26 May 2005 19:50:07 -0000 Take a look at: http://postmaster.msn.com/snds/FAQ.aspx http://postmaster.msn.com/snds/ Yakov Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j4Q2Yr1m005084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 May 2005 19:34:54 -0700 Received: from 228.sub-70-216-140.myvzw.com ([70.216.140.228] helo=[192.168.0.66]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1Db8C7-0007vh-JF; Wed, 25 May 2005 22:34:00 -0400 Message-ID: <42953571.9040601@solidmatrix.com> Date: Wed, 25 May 2005 22:33:21 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce Lilly References: <200505161938.PAA29488@ietf.org> <4294D164.9040108@solidmatrix.com> <01LOOKFC8HQQ00004T@mauve.mrochek.com> <200505252157.21542.blilly@erols.com> In-Reply-To: <200505252157.21542.blilly@erols.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-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: Found to be clean X-Songbird-From: yakovs@solidmatrix.com Cc: ietf-822 , abuse-feedback-report@mipassoc.org, ned+ietf-822@mrochek.com Subject: [feedback-report] Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt 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, 26 May 2005 02:35:12 -0000 Bruce Lilly wrote: > On Wed May 25 2005 18:32, ned+ietf-822@mrochek.com wrote: > >>In any case, I agree that these are not >>header fields and hence do not belong in the regular header field >>registry. > > > Discussion with Graham back when the registry documents were still > in draft form seemed to indicate that it would be reasonable. The > use could be indicated via the registration form "applicable protocol" > field. The benefits would be as listed in RFC 3864: > ... In this specific case, additional registered fields need to specify the type of feedback they are used for. By using BCP 90, there isn't sufficient space to do that. Same goes for the DSN/MDN/MTSN fields which need more than simple registration. > > With three related types already (DSN, MDN, MTSN), and some already > existing common use (e.g. Original-Recipient, Final-Recipient), the > benefits enumerated in 3864 seem clear. > ... Any particular reason why these fields were not included in the initial header registry? Sounds rather strange to me. Yakov Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j4PM9DKo020571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 May 2005 15:09:13 -0700 Received: from 228.sub-70-216-140.myvzw.com ([70.216.140.228] helo=[192.168.0.66]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1Db437-00009k-8t for abuse-feedback-report@mipassoc.org; Wed, 25 May 2005 18:08:26 -0400 Message-ID: <4294F74D.8090402@solidmatrix.com> Date: Wed, 25 May 2005 18:08:13 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en 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-HMDNSGroup-MailScanner-Information: Please contact the ISP for more information X-HMDNSGroup-MailScanner: Found to be clean X-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: Found to be clean X-Songbird-From: yakovs@solidmatrix.com Subject: [feedback-report] Usage Scenarios 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, 25 May 2005 22:09:25 -0000 Prompted by a suggestion from Dave Crocker, I wanted to see if we can come up with a list of possible usage scenarios for this format. Here are some of my thoughts: 1. Feedback loops - ISPs providing reports back to email senders about spam reports from their users (like SCOMP at AOL). This would imply that the ISPs and email senders establish a relationship in some way (which is out of scope for this spec). 2. ISP-to-ISP reporting - ISPs exchanging reports among themselves - i.e. spam originating from ISP A's network going to ISP B, and ISP B reporting it back to ISP A. This also implies some form of an established relationship among ISPs. 3. Users reporting spam to their ISP - this would be like the "Report Spam" function in AOL's and Yahoo's interfaces but on the MUA. In this case, an ISP user (lets say Earthlink) would be able to report a spam message arriving in his MUA (Outlook, pine, Thunderbird, etc.) to his own ISP which would then aggregate and process them further before taking some sort of action on them. This implies that the ISP has a way of checking whether this user is actually theirs and would help in cases where ISPs provide a "report spam" button in the webmail interface but nothing for POP or IMAP users. 4. Users reporting spam to aggregate services - this would be intended for services like SpamCop where users can report their spam via MUAs and the service will process them further before sending them off. This implies that the service has a way of checking if the user is actually part of that service. 5. Users to ISP reporting - this would allow regular users to report spam directly to ISPs. However, given that most ISPs and users will probably not be able to do this properly, this scenario might not work very well (but scenario #3 instead might). Yakov Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j4PLkETO019480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 May 2005 14:46:15 -0700 Received: from 228.sub-70-216-140.myvzw.com ([70.216.140.228] helo=[192.168.0.66]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1Db3gt-0006Ss-I1 for abuse-feedback-report@mipassoc.org; Wed, 25 May 2005 17:45:28 -0400 Message-ID: <4294F1EC.4000907@solidmatrix.com> Date: Wed, 25 May 2005 17:45:16 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en 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-HMDNSGroup-MailScanner-Information: Please contact the ISP for more information X-HMDNSGroup-MailScanner: Found to be clean X-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: Found to be clean X-Songbird-From: yakovs@solidmatrix.com Subject: [feedback-report] Feedback Types 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, 25 May 2005 21:46:17 -0000 This email was prompted by similar comments from a number of people including Mathew Elvey, Bruce Lilly, and all of the folks on the relevant mailing lists. The current draft defines the following feedback types: 1. abuse - spam or some other kind of email abuse 2. fraud - indicates some kind of fraud or phishing activity. 3a. opt-out - a request to opt out from ALL mailing lists from this provider. 3b. opt-out-list - a request to opt out from THIS mailing list ONLY. 4. other - any other feedback that doesn't fit into other types. 5. virus - report of a virus found in the originating message Based on the discussion with different people, there seems to be confusion as to whether this are the appropriate names, and how they are used. I wanted to elaborate a bit more on these names. 1. "abuse" - The "abuse" type is intended to indicate either regular spam being sent from a network, zombie computers and hosting of spam-related sites. However, at least one email service provider wanted to have this more narrowly specified as "unsolicited" indicating regular spam. In that case, I am not sure how to cover the other cases of hosting spam related sites and operating zombie computers. 2. "fraud" - this is intended specifically for phishing or similar fraudulent activities. However, as pointed out by Bruce Lilly there is no definition of phishing in the document. RFC 2828 which defined a security glossary for Internet standards, does not have that either since it was written in 2000. What I have been thinking is referencing an encyclopedia definition here (something like http://en.wikipedia.org/wiki/Phishing). 3. "opt-out" and "opt-out-list" - these two types are used for opting out from mailing lists. As I am going to mention below, the purpose of feedback types is to specify something to the report receiver that the report generator wants them to know. In this case, this would probably be used in feedback loops where the bulk emailers can be somewhat reliant on to honor them. Once again, since *how* these reports are sent among providers is out of scope, it is upto individual providers to decide whether to use this type. 4. "other" - all of these types are to be used whenever the report generator wants to indicate something to the report receiver. In cases that no such indication is desired, the "other" feedback type is used. However, since this is confusion people, perhaps changing "other" to something else like "unspecified" would be better? 5. "virus" - I intended that the "virus" feedback type should also include all kinds of malware. However, as pointed out by Bruce Lilly, this is kind of ambigious since for most people virus means only normal computer viruses. After looking up RFC 2828, that seems to be the case as well. A better suggestion seems to be the word "malware" as per RFC 2828 (except that it is a bit confusing for non-English readers). Yakov Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j4PLOCSJ017980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 May 2005 14:24:13 -0700 Received: from 228.sub-70-216-140.myvzw.com ([70.216.140.228] helo=[192.168.0.66]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1Db3LY-0004Vi-0D; Wed, 25 May 2005 17:23:25 -0400 Message-ID: <4294ECC1.7030701@solidmatrix.com> Date: Wed, 25 May 2005 17:23:13 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: William Leibzon Subject: Re: [feedback-report] Comments on draft (and spam reporting in general) References: In-Reply-To: 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-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: Found to be 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: Wed, 25 May 2005 21:24:30 -0000 William Leibzon wrote: > > First I'd like to note that I think standard spam reporting format is a > good idea (in fact there was supposed ASRG group working on that - > whatever happened to it and why discussions are being done on separate > mail list and not there), We wanted to start from scratch without any preconceived notions about ASRG/IRTF/IETF/etc. Eventually, we might move this over to the ASRG or perhaps directly into an IETF WG. Alternatively, this may be submitted as an independent submission to the IETF. but I'd have thought it be better if it format > was XML as it gives more options on what and how to report and > extendability for the future then simple mime text fields. > The providers wanted something simple and XML was too complicated. I think that one of the concurent problems with this effort is that anything proposed was way to complicated. In this case, the absolute minimum to comply requires wrapping the offending spam message or its headers in a MIME type and adding two fields: "Version" and "User-Agent" , none of which require any complicated processing. I think that is why this has attracted more attention from providers than other methods. In the future, I forsee other formats for this as well: XML, aggregate, etc. so this is something just to start with. > In any case I'm going to comment on current draft first: > > 1. Discussion is needed on combining reporting of more then one email > In particular what needs to be decided is: ... This document specifically does not address aggregate reporting. The providers I have discussed this with felt that a single spam/report solution might be something that can jump start this effort, with aggregate formats developed later on. > > 2. The report includes Reported-Domain and Reported-URI but its possible > (in fact likely) that reporting maybe for particular email address > rather then domain or URI. I actually think that having separate > fields (and adding yet another one) is not the best idea and its > better to have something like "Reported-Field:" which would have > a tag "type" that can be "URI", "email" or "domain" and then data, i.e. > Reported-Field: type="email"; abuser@hulligans.org > (apologies if hulligans real domain, I've not checked) > Reported-Field: type=URI ; http://www.bankofamerica-phisher.com > > Note: I don't particular like "-Field" as part of above, but I could > not find anything else general enough except "subject" and using that > would be even more confusing. Another possibility is just use > Reported-URI > and use "dns" for reporting dns and "mailto" for reporting email > addresses > I was thinking along the lines of the second solution - just use mailto and dns. Perhaps a bit more explanation is needed in the draft. > 3. On above, it is probably a good idea to indicate in report if what is > being reported is data field from email transmission, email header > or email body (and if email body not a bad idea to make possible > to report cid URI reference to particular mime body part). Perhaps > also indicating particular "location" (byte number) where what is > being reported is at is good idea as well (this brings question on > syntax to report if field appears in more then one place, probably > mutliple Reported-Field). > For now the providers feel that anything more complicated than either the entire message or its headers might be too much. Yakov Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j4PJRcQ8009664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 May 2005 12:27:39 -0700 Received: from 228.sub-70-216-140.myvzw.com ([70.216.140.228] helo=[192.168.0.66]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1Db1WY-00017L-Cz; Wed, 25 May 2005 15:26:41 -0400 Message-ID: <4294D164.9040108@solidmatrix.com> Date: Wed, 25 May 2005 15:26:28 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce Lilly References: <200505161938.PAA29488@ietf.org> <200505231029.32949.blilly@erols.com> In-Reply-To: <200505231029.32949.blilly@erols.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-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: Found to be clean X-Songbird-From: yakovs@solidmatrix.com Cc: ietf-822 , ietf@shaftek.org, abuse-feedback-report@mipassoc.org Subject: [feedback-report] Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt 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, 25 May 2005 19:27:53 -0000 Bruce Lilly wrote: > > Review of draft-shafranovich-feedback-report-01 by B. Lilly > ... > > [X] The document should probably be split: registration of media > types in the standards tree requires an RFC of any type. > Registration procedures (which should be specified for > registration of extension items) are typically specified in a BCP > RFC. Specifications with conformance criteria (which should be > explicit) are typically Standards Track RFCs. > Can you elaborate as to why the document must be split? For example, RFC 3464 includes the MIME registration in the same document. Why should this document, which is also a child-of-RFC3462 be any different? > The document suffers from the following serious defects: > ... > > [X] missing or inadequate internationalization considerations > I am not sure what this is refering to. This is a message intended for machines, not humans, and follows the same conventions as RFC 3462 from which it descends. What internationalization issues have to be discussed? > [X] incompatible with one or more Internet Standards > Can you be more specific? What Internet standards is this document not compatible with, what specific issues are there, etc.? > > Specific issues with the draft: > ... > o The draft implies that "opt-out" is viable. It is not, and the > draft will meet some considerable resistance if it does not > distance itself from that spammer-supported concept. (opt-out is > not viable because there are more than 10 billion potential senders > of unsolicited material (nearly that many individuals, plus a large > number of corporate entites). Responding to a single message from > each, at 5 seconds per response, working continuously, would take > more than 1,500 years of uninterrupted effort. How long do you > plan to live, and do you wish to do something other than "opt-out" > of unsolicited messages?) > This is a technical standard, not an editorial page. The "opt-out" option is included to be used in feedback loops from ISPs to legit bulk mailers such as SkyList, etc., not a general opt-out mechanism. It is perfectly viable according to the ISPs and the bulk mailers I have spoken to. > o The draft states "this format is intended specifically for > communications among providers", implying that a mere individual > (not a provider) cannot use it to report abuse to a government > agency (also not a provider), for example. > I will change it to read "this format is intended primarly for communications among providers, but can also be used in other situations". Would that be more clear? > o The draft states "The first MIME part of the message contains a > human readable description of the report" but does not state > whether or not that part can be a MIME composite type (e.g. > multipart/alternative). Nor does it provide for (e.g.) an audio > type, which might be appropriate if the recipient is known to be > visually impaired. > This is a child-of-RFC3462. Whatever is specified there, applies here. Last time I checked, I did not see any of those options there or in any standards that descend from it such as DSNs and MSG-TRACK. > o The draft states "it is RECOMMENDED that the entire original email > message be included without any modification" but does not indicate > how such a message containing a virus or other malware can be > successfully conveyed in the presence of filtering (at the sender's > site, in transit, or at the intended recipient's site) without > encryption and/or encoding. > This issue was brought up by someone already. One option would be to relay just the headers of the message (an option included in this document). However, the consensus in the discussions that I had with ISPs is that this is something out of scope for this document. Rather, this is an issue for the abuse desks (sender and receiver) to deal with. I do not see any other plausible solution short of mucking around with the RFC3462 format and making this even more complicated. Both ISPs and abuse desks have expressed their desire to keep this simple. > o The draft states "The subject line of the feedback report SHOULD be > the same as the included email message", which conflicts with the > defined semantics of the Subject field as stated in RFC 2822, viz. > a description of the topic of the message containing it, not a > purported description of a different message. > This was included due to the fact that smaller ISPs tend to use the Subject line for manual processing. This is currently the accepted convention and I don't know if mandating anything else will actually accomplish something. However, what about prefixing the subject as follows: "[FEEDBACK REPORT:] subject" ? > > o The draft refers to RFC 2616, which is an HTTP specification that > uses a different field syntax from the Internet Message Format. > I did not find any other standard that defines the user agent field. The "User-Agent" and "Mailer" fields used by email programs are not defined in any standard that I was able to locate. Perhaps a new registration or document for the user agent field should be written, OR the syntax copied from RFC 2616 and included in this document in long hand. > > o In several proposed fields, e.g. "Original-Mail-From:", the draft > makes statements such as "The format of this field is defined in > section 4.1.1.2 of RFC 2821", whereas there is no such definition > of any such fields in the referenced RFCs. It is refering to the following: "MAIL FROM:" ("<>" / Reverse-Path) [SP Mail-parameters] CRLF Specifically to everything that appears after MAIL FROM. The format is probably the same as Return-Path header, but I wanted to reference the original SMTP transaction directly. > > o The draft seeks to define a media type with multiple fields (but > N.B. not *header* fields in this case), but does not provide enough > detail: > > o Where's the syntax specification for the format? > > o What order should the fields appear in? > > o Is the order significant? > > o May empty lines appear between fields? > This is a child-of-RFC3462. > o What about the promised extensibility? > There is an extensibility section. > o Where are the syntax specifications for the fields? > Are you refering to ABNF? > o Where are the BCP 90 registration templates for the fields? > DNS and message tracking standards do not register their fields with BCP 90 IANA registry. Since this is a similar child-of-RFC3462, I do not see why it should be any different. > o The media type registration form doesn't say anything about a > charset parameter, or about required charsets. Can I send such a > report in EBCDIC? > This is a child-of-RFC3462, everything that applies there applies here as well (only 7bit ASCII). > > o The draft proposes establishing an IANA registry for header fields > (actually fields which do not appear in a header). There is > already such a registry and corresponding registration procedure as > established by BCP 90. That mechanism could be used by extending > BCP 90 in small ways to accommodate specifying applicability of > fields to the defined media type proposed in the draft. > See above comment re BCP 90 (and take a look at the DSN and MSGTRACK stuff as well). > > o There is no mention of architectural or internationalization > considerations w.r.t. keywords. Are keywords case-independent > protocol elements or text? Is it OK to use "Feedback-Type: > Betrug"? > Are you refering to the feedback-type keywords? > > o The draft provides a catch-all "other - any other feedback that > doesn't fit into other types". How does one distinguish a > subsequent extension from "other" (hint: only register types that > have a specific definition)? > Other specifically refers to a case where the abuse reporter DOES NOT want to specific a specific feedback type and leave that task for the receiver. > o There is provision for one specific type of malware -- "virus", but > not other types (worms, dialers, keystroke loggers, logic bombs, > etc.). The Security Glossary FYI may be a useful reference. > I assumed that it includes all malware. > o The Security considerations section is completely unacceptable. > Obviously, this is only a draft at this point and has not been sent to the IESG or anyone else for approval just yet. Rather, it is still something that needs work, and specific suggestions would be highly welcome. Blanket statements like the one above are not much helpful - of course I am aware that this section is not finished yet. If you would like to help writing it, I would be very happy. > o References are normally unnumbered sections. > Can you provide a reasoning for this or is this simply something the community is used to? > o Examples are badly broken. > Aside from the various 2822 problems highlited above, how so? > o Discussion venue should be an IETF list for documents intended as > IETF documents. > There is no current IETF list for this type of stuff. The ietf-822 list is not official at this point. When this spec becomes more mature, I will discuss with the appropriate ADs the best avenue for moving this forward. But for now, there is already a dedicated list for this. Yakov Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j4PIlwWw006524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 May 2005 11:47:59 -0700 Received: from 228.sub-70-216-140.myvzw.com ([70.216.140.228] helo=[192.168.0.66]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1Db0uG-0004Vz-Mf for abuse-feedback-report@mipassoc.org; Wed, 25 May 2005 14:47:09 -0400 Message-ID: <4294C81F.7070502@solidmatrix.com> Date: Wed, 25 May 2005 14:46:55 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org Content-Type: multipart/mixed; boundary="------------020309030203090403070502" X-HMDNSGroup-MailScanner-Information: Please contact the ISP for more information X-HMDNSGroup-MailScanner: Found to be clean X-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: Found to be clean X-Songbird-From: yakovs@solidmatrix.com Subject: [feedback-report] [Fwd: Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt] 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, 25 May 2005 18:48:23 -0000 This is a multi-part message in MIME format. --------------020309030203090403070502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI, This was publically posted to the ietf-822 list. I will be posting my reply to both lists. Yakov -------- Original Message -------- Subject: Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt Date: Mon, 23 May 2005 10:29:31 -0400 From: Bruce Lilly Reply-To: ietf-822 Organization: Bruce Lilly To: ietf-822 , ietf@shaftek.org References: <200505161938.PAA29488@ietf.org> On Mon May 16 2005 15:38, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : An Extensible Format for Email Feedback Reports > Author(s) : Y. Shafranovich > Filename : draft-shafranovich-feedback-report-01.txt > Pages : 19 > Date : 2005-5-16 > > This document defines an extensible format and MIME type that may be > used by network operators to report feedback about received email to > other parties. This format is intended as a machine readable > replacement for various existing report formats currently used in > Internet email. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-shafranovich-feedback-report-01.txt This draft probably warrants some discussion on the ietf-822 list. --------------020309030203090403070502 Content-Type: text/plain; name="draft-shafranovich-feedback-report-01-review.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-shafranovich-feedback-report-01-review.txt" Review of draft-shafranovich-feedback-report-01 by B. Lilly Internet-Drafts and RFCs are required to meet certain criteria: [R1.Checklist] (see also references in that document), [R2.ID], [R3.Instruct]. These can be checked by using the "idnits" tool: [R4.idnits]. That tool noted the following regarding the document: idnits 1.71 (02 May 2005) draft-shafranovich-feedback-report-01.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html : Checking conformance with RFC 3978/3979 boilerplate... the boilerplate looks good. * There are 15 instances of too long lines in the document, the longest one being 44 characters in excess of 72. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt : Nothing found here (but these checks does not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. Run idnits with the --verbose option for more detailed information. The document contains: [ ] ABNF [R5.RFC2234] [X] Internet message (or fragment) Verification tools are available at [R6.verify] and/or [R7.mparse]. Verification tools yielded the following results (for brevity, only one example is shown): From: Date: Thu, 8 Mar 2005 17:40:36 EDT X-NG: Thu<- RFC 822 [5.2] prohibits date inconsistency (day-of-week) (Tue) X-NG: Thu<- RFC 2822 [3.3] prohibits date inconsistency (day-of-week) (Tue) X-Warning: ->EDT RFC 2822 [3.3] prohibits (when generating messages) obsolete zone Subject: FW: Earn money To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=feedback-report; boundary="part1_13d.2e68ed54_boundary" X-Warning: RFC 2822 [2.1.1, 2.3, 3.5] strongly recommends against line length > 78 octets (99) X-Err: RFC 2821 [4.4] requires exactly one field (0 Return-Path) --part1_13d.2e68ed54_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit This is an email abuse report for an email message received from IP 10.67.41.167 on Thu, 8 Mar 2005 14:00:00 EDT. For more information about this format please see http://www.mipassoc.org/arf/. --part1_13d.2e68ed54_boundary X-Warning: RFC 2822 [2.1.1, 2.3, 3.5] strongly recommends against line length > 78 octets (113) Content-Type: message/feedback-report Feedback-Type: abuse User-Agent: SomeGenerator/1.0 Version: 0.1 --part1_13d.2e68ed54_boundary Content-Type: message/rfc822 Content-Disposition: inline From: Received: from mailserver.example.net (mailserver.example.net [10.67.41.167]) by example.com with ESMTP id M63d4137594e46; Thu, 08 Mar 2005 14:00:00 -0400 X-NG: ->(mailserver.example.net [10.67.41.167]) RFC 821 [4.1.2] requires one space character X-NG: RFC 821 [4.1.2] requires one space character ->=0D=0A X-NG: <- RFC 821 [4.1.2] requires one space character X-NG: ->M63d4137594e46 RFC 822 [4.1] requires message-id X-NG: ->; RFC 821 [4.1.2] requires one space character X-NG: RFC 2821 [4.4] requires CFWS ->; X-NG: RFC 821 [4.1.2] prohibits day-of-week ->Thu X-NG: ->Thu RFC 822 [5.2] prohibits date inconsistency (day-of-week) (Tue) X-NG: ->Thu RFC 2821 [4.4] prohibits date inconsistency (day-of-week) (Tue) X-NG: ->Thu RFC 2822 [3.3] prohibits date inconsistency (day-of-week) (Tue) X-Warning: RFC 2822 [2.1.1, 2.3, 3.5] strongly recommends against line length > 78 octets (81) To: X-NG: Undisclosed Recipients<- RFC 822 [6.1] requires domain requires domain X-NG: Undisclosed Recipients<- RFC 2822 [3.4, 3.4.1] requires domain X-Warning: -> RFC 2822 [3.4.1, 4.4] prohibits (when generating messages) CFWS in local-part X-NG: ->Recipients RFC 822 [6.1] requires one '@' (0) one '@' (0) X-NG: ->Recipients RFC 2822 [3.2.4, 3.4.1, 4.4] prohibits atom not followed by dot X-NG: ->Recipients RFC 2822 [3.4, 3.4.1] requires one '@' (0) Subject: Earn money MIME-Version: 1.0 Content-type: text/plain Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net X-NG: ->@ syntax error, unexpected '@', expecting EOH Date: Thu, 02 Sep 2004 12:31:03 -0500 Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam --part1_13d.2e68ed54_boundary-- The formatting of the document needs work. See [R8.formatting] and [R9.formatting] and http://www.rfc-editor.org/pipermail/rfc-interest/2005-January/000235.html . The (intended) status of the document is: [X] Not indicated [ ] Experimental [ ] Informational [ ] Proposed Standard [ ] Draft Standard [ ] Internet Standard [ ] Best Current Practice However, the status as defined in [R10.BCP9] should be: [ ] Experimental (typically denotes a specification that is part of some research or development effort, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process) [ ] Informational (published for the general information of the Internet community, does not represent an Internet community consensus or recommendation, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process) [ ] Proposed Standard (generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, appears to enjoy enough community interest to be considered valuable, has no known technical omissions) [ ] Draft Standard (at least two independent and fully interoperable implementations from different code bases have been developed, sufficient successful operational experience has been obtained, unused options and features have been removed, well-understood, known to be quite stable both in its semantics and as a basis for developing an implementation, must have been Proposed Standard for at least six months) [ ] Internet Standard (significant implementation and successful operational experience has been obtained, characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community, must have been Draft Standard for at least four months) [ ] Historic (A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete, must have been Standards Track) [ ] Best Current Practice (a way to standardize practices and the results of community deliberations, subject to the same basic set of procedures as standards track documents, the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function, common guidelines for policies and operations which are generally different in scope and style from protocol standards, not well suited to the phased roll-in nature of the three stage standards track and instead generally only make sense for full and immediate instantiation) [X] The document should probably be split: registration of media types in the standards tree requires an RFC of any type. Registration procedures (which should be specified for registration of extension items) are typically specified in a BCP RFC. Specifications with conformance criteria (which should be explicit) are typically Standards Track RFCs. The document suffers from the following serious defects: [X] missing or inadequate security considerations [X] missing or inadequate internationalization considerations [X] incompatible with one or more Internet Standards [X] uses non-standard terminology which may lead to confusion, misinterpretation, and loss of interoperability. Specifically, "header" is used where the term "header field" should be used, "header field" is used in places where fields in a specific media type are being referenced but where that type has no header, "content type" is used where the standard term "media type" should be used, and the term "address" is used in at least one place where the standard term "mailbox" should instead be used. Several non-standard terms used are nowhere defined. [X] [R11.BCP14] is referenced, but keywords are used inappropriately, and/or words which appear to be keywords are nowhere defined The document could benefit from spell checking and careful proofreading. A quick check reveals that the following are suspect: sucessful intented encourages is it allow overtime setup can only registered Specific issues with the draft: o The term "feedback" is undefined. As the stated intent of the media type is primarily for reporting email abuse, perhaps "email- abuse" should be substituted for "feedback". o The draft implies that "opt-out" is viable. It is not, and the draft will meet some considerable resistance if it does not distance itself from that spammer-supported concept. (opt-out is not viable because there are more than 10 billion potential senders of unsolicited material (nearly that many individuals, plus a large number of corporate entites). Responding to a single message from each, at 5 seconds per response, working continuously, would take more than 1,500 years of uninterrupted effort. How long do you plan to live, and do you wish to do something other than "opt-out" of unsolicited messages?) o The draft states "this format is intended specifically for communications among providers", implying that a mere individual (not a provider) cannot use it to report abuse to a government agency (also not a provider), for example. o The draft says "seeks to define a standard" and "the actual standard is defined in the next sections". The term standard should be avoided when referring to an Internet-Draft [R2.ID]. o The draft states "The first MIME part of the message contains a human readable description of the report" but does not state whether or not that part can be a MIME composite type (e.g. multipart/alternative). Nor does it provide for (e.g.) an audio type, which might be appropriate if the recipient is known to be visually impaired. o The term "munge" is used, but is nowhere defined. o The draft states "it is RECOMMENDED that the entire original email message be included without any modification" but does not indicate how such a message containing a virus or other malware can be successfully conveyed in the presence of filtering (at the sender's site, in transit, or at the intended recipient's site) without encryption and/or encoding. o The draft states "The subject line of the feedback report SHOULD be the same as the included email message", which conflicts with the defined semantics of the Subject field as stated in RFC 2822, viz. a description of the topic of the message containing it, not a purported description of a different message. o The draft refers to "formatted according to the ABNF of RFC 822 [14]"; RFC 822 uses EBNF, not ABNF. A more appropriate reference would be RFCs 2234 (ABNF) and 2822 (Internet Message Format). Note that RFC 822 is listed as being obsoleted by 2822. o The draft does not provide any ABNF or suitable formal syntax format for defining the fields that it claims to define. There is insufficient information for an implementation. Indeed, it is not possible to thoroughly review the draft proposal in the absence of some concrete definitions. o The draft refers to RFC 2616, which is an HTTP specification that uses a different field syntax from the Internet Message Format. o The draft refers to a version number, and specifies "0.1", but: o what does it mean? o Is it a floating point number, a serial number, etc.? o Is it decimal, hexadecimal, octal, or binary? o How are versions compared? o What is supposed to happen when a generated version is not recognized by a receiving implementation? o May comments, whitespace, and/or line folding appear within the version designation (as with RFC 2045 MIME-Version) or not? See also RFC 2234 section 3.1. o In several proposed fields, e.g. "Original-Mail-From:", the draft makes statements such as "The format of this field is defined in section 4.1.1.2 of RFC 2821", whereas there is no such definition of any such fields in the referenced RFCs. o Optional fields are proposed for reporting domain names and for reporting URIs. Many URIs contain domain names, but the draft does not specify whether or not domain names appearing in URIs should also be reported *as* domain names. o The draft seeks to define a media type with multiple fields (but N.B. not *header* fields in this case), but does not provide enough detail: o Where's the syntax specification for the format? o What order should the fields appear in? o Is the order significant? o May empty lines appear between fields? o What about the promised extensibility? o Where are the syntax specifications for the fields? o Where are the BCP 90 registration templates for the fields? o The media type registration form doesn't say anything about a charset parameter, or about required charsets. Can I send such a report in EBCDIC? o The media type registration form says: "Macintosh File Type Code(s): none". MacOS file type codes are 4 characters. Do you mean that the MacOS file type code is the four character sequence "none"? o The draft proposes establishing an IANA registry for header fields (actually fields which do not appear in a header). There is already such a registry and corresponding registration procedure as established by BCP 90. That mechanism could be used by extending BCP 90 in small ways to accommodate specifying applicability of fields to the defined media type proposed in the draft. o The draft uses the capitalized term "REQUIRE", which is not a BCP 14 keyword and the meaning of which is not defined in the draft. o The draft needs to be reviewed for inconsistencies. For example, the media type registration states "implementors MUST ignore any fields they do not support", whereas a subsequent section states "implementors SHOULD ignore any fields they do not support". Is it a requirement per keyword usage guidelines in BCP 14, or a mere recommendation? o There is no mention of architectural or internationalization considerations w.r.t. keywords. Are keywords case-independent protocol elements or text? Is it OK to use "Feedback-Type: Betrug"? o Security considerations are supposed to appear before IANA considerations [R3.Instruct]. o Please don't break a line in the middle of a media type designation. o "Feedback-Type: any" appears several times, and there does not appear to be any registration of "any", which is otherwise syntactically valid as a keyword. The design needs to be carefully rethought (hint: define an alternative which is clearly not an single keyword, such as "*"). Likewise for "N/A". o The term "phishing" appears, but is nowhere defined. o The draft provides a catch-all "other - any other feedback that doesn't fit into other types". How does one distinguish a subsequent extension from "other" (hint: only register types that have a specific definition)? o There is provision for one specific type of malware -- "virus", but not other types (worms, dialers, keystroke loggers, logic bombs, etc.). The Security Glossary FYI may be a useful reference. o The Security considerations section is completely unacceptable. o References are normally unnumbered sections. o Examples are badly broken. o Discussion venue should be an IETF list for documents intended as IETF documents. o Regarding "outstanding issues" and encoding, beware of the restrictions specified in RFC 2045 section 6.4. Please carefully review the references and resources indicated: [X] [R1.Checklist] [X] [R2.ID] [X] [R3.Instruct] [X] [R4.idnits] [X] [R5.RFC2234] [X] [R6.verify] [X] [R7.mparse] [X] [R8.formatting] [X] [R9.formatting] [X] [R10.BCP9] [X] [R11.BCP14] [X] [R12.FYI18] [X] [R13.FYI36] [X] [R14.STD11] [X] [R15.BCP18] [X] [R16.BCP22] [X] [R17.BCP26] [X] [R18.BCP61] [X] [R19.BCP72] [X] [R20.BCP82] [X] [R21.BCP90] [X] [R22.RFC1796] [X] [R23.RFC1925] [X] [R24.RFC1958] [X] [R25.RFC1982] [X] [R26.RFC2223] [X] [R27.RFC2822] [X] [R28.RFC3426] [X] [R29.RFC3439] [X] [R30.RFC3444] [X] [R31.RFC3536] [X] [R32.RFC3724] [X] [R33.RFC3930] [X] [R34.Errata] [X] [R35.Fields] The following applies to the document being reviewed: [X] The document seems promising, but needs work. References: [R1.Checklist] Wijnen, B., "Checklist for Internet-Drafts (IDs) submitted for RFC publication", February 2005, http://www.ietf.org/ID-Checklist.html [R2.ID] Fenner, B., "Guidelines to Authors of Internet-Drafts", March 2005, ftp://ftp.ietf.org/ietf/1id-guidelines.txt [R3.Instruct] Reynolds, J. and R. Braden, "Instructions to Request for Comments (RFC) Authors" (draft-rfc-editor-rfc2223bis-08.txt), July 2004. [R4.idnits] http://ietf.levkowetz.com/tools/idnits/ [R5.RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [R6.verify] TOOLS, "Available Verification Tools", http://tools.ietf.org/verif-tools [R7.mparse] Internet Message Format validating parser, http://users.erols.com/blilly/mparse/index.html [R8.formatting] RFC Editor, "Formatting RFCs and Internet Drafts", http://www.rfc-editor.org/formatting.html [R9.formatting] Lilly, B., "Writing Internet-Drafts and Requests For Comments using troff and nroff" (draft-lilly-using-troff-04.txt), (draft-lilly-using-troff-04.ps), (draft-lilly-using-troff-04.pdf), May 2005. [R10.BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [R11.BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [R12.FYI18] Malkin, G., "Internet Users' Glossary", RFC 1983, August 1996. [R13.FYI36] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000. [R14.STD11] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [R15.BCP18] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [R16.BCP22] Scott, G., "Guide for Internet Standards Writers", BCP 22, RFC 2360, June 1998. [R17.BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [R18.BCP61] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, August 2002. [R19.BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [R20.BCP82] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. [R21.BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. [R22.RFC1796] Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are Standards", RFC 1796, April 1995. [R23.RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, April 1996. [R24.RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996. [R25.RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996. [R26.RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997. [R27.RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [R28.RFC3426] Floyd, S., "General Architectural and Policy Considerations", RFC 3426, November 2002. [R29.RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3439, December 2002. [R30.RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, January 2003. [R31.RFC3536] Hoffman, P., "Terminology Used in Internationalization in the IETF", RFC 3536, May 2003. [R32.RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, March 2004. [R33.RFC3930] Eastlake 3rd, D., "The Protocol versus Document Points of View in Computer Protocols", RFC 3930, October 2004. [R34.Errata] RFC-Editor errata page, http://www.rfc-editor.org/errata.html [R35.Fields] Lilly, B., "Implementer-friendly Specification of Message and MIME-Part Header Fields and Field Components" (draft-lilly-field-specification-03.txt), May 2005. Reviewer's Address Bruce Lilly Email: blilly@erols.com --------------020309030203090403070502-- Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j4NMS9NQ017833 for ; Mon, 23 May 2005 15:28:09 -0700 Received: from [66.228.167.95] (jdfalk-mac.corp.yahoo.com [66.228.167.95]) by mrout1.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id j4NMQHUI097033 for ; Mon, 23 May 2005 15:26:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:organization:user-agent: x-accept-language:mime-version:to:subject:references:in-reply-to:content-type; b=EhjTAfesZ+rWxfbyaJ2+oIpncNyylPrun1TVPdhtmJo8sAOxdNm7XZmKOjuRhdLV Message-ID: <42925889.1090100@yahoo-inc.com> Date: Mon, 23 May 2005 15:26:17 -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.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.6.0.104 X-Accept-Language: en-us, en MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] Comments on draft (and spam reporting in general) References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070402060902090307000703" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be 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: Mon, 23 May 2005 22:28:21 -0000 This is a multi-part message in MIME format. --------------070402060902090307000703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/20/05 11:09 PM, William Leibzon wrote: >I'd have thought it be better if it format >was XML as it gives more options on what and how to report and >extendability for the future then simple mime text fields. > > In practice, this will be parsed by both machines and humans -- and even though XML is mostly text, it doesn't lend itself to readability. >1. Discussion is needed on combining reporting of more then one email > > Our consensus was to leave that for a future version, and assume one report for one message to one report recipient for now. >2. The report includes Reported-Domain and Reported-URI but its possible > (in fact likely) that reporting maybe for particular email address > rather then domain or URI. > The idea was that mailto: is a valid URI, and the e-mail address would be put in there -- but this seems to cause a lot of confusion. Maybe we should change it back. >3. On above, it is probably a good idea to indicate in report if what is > being reported is data field from email transmission, email header > or email body (and if email body not a bad idea to make possible > to report cid URI reference to particular mime body part). Perhaps > also indicating particular "location" (byte number) where what is > being reported is at is good idea as well (this brings question on > syntax to report if field appears in more then one place, probably > mutliple Reported-Field). > > How would this help report recipients to handle these reports more effectively? You also wrote a bunch about headers -- you do realize that these fields aren't mail headers, but are actually message content? >Overall I think the draft and "spam reporting" in general still needs a >lot of work and this work should be both deciding in general as to what >goes into report and deciding on report format (xml or header fields) and >particular syntax as last part. > > More general questions about spam reporting are outside of the (intentionally limited) purview of this document, and the report format has already been decided for the first round of real-world testing. -- J.D. Falk, Anti-spam Product Manager, Yahoo! Mail jdfalk@yahoo-inc.com --------------070402060902090307000703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/20/05 11:09 PM, William Leibzon wrote: 
I'd have thought it be better if it format 
was XML as it gives more options on what and how to report and 
extendability for the future then simple mime text fields.
In practice, this will be parsed by both machines and humans -- and even though XML is mostly text, it doesn't lend itself to readability.
1. Discussion is needed on combining reporting of more then one email
Our consensus was to leave that for a future version, and assume one report for one message to one report recipient for now.
2. The report includes Reported-Domain and Reported-URI but its possible
    (in fact likely) that reporting maybe for particular email address
    rather then domain or URI.
The idea was that mailto: is a valid URI, and the e-mail address would be put in there -- but this seems to cause a lot of confusion.  Maybe we should change it back.
3. On above, it is probably a good idea to indicate in report if what is
    being reported is data field from email transmission, email header
    or email body (and if email body not a bad idea to make possible
    to report cid URI reference to particular mime body part). Perhaps
    also indicating particular "location" (byte number) where what is
    being reported is at is good idea as well (this brings question on
    syntax to report if field appears in more then one place, probably
    mutliple Reported-Field).
How would this help report recipients to handle these reports more effectively?

You also wrote a bunch about headers -- you do realize that these fields aren't mail headers, but are actually message content?
Overall I think the draft and "spam reporting" in general still needs a 
lot of work and this work should be both deciding in general as to what
goes into report and deciding on report format (xml or header fields) and
particular syntax as last part.
More general questions about spam reporting are outside of the (intentionally limited) purview of this document, and the report format has already been decided for the first round of real-world testing.
-- 
J.D. Falk, Anti-spam Product Manager, Yahoo! Mail
jdfalk@yahoo-inc.com
--------------070402060902090307000703-- Received: from mail.completewhois.com (cwhois1.completewhois.com [216.151.192.222]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j4L5hTo4017422 for ; Fri, 20 May 2005 22:43:30 -0700 Received: by mail.completewhois.com (Postfix, from userid 500) id 9DE2E18A05; Fri, 20 May 2005 23:09:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.completewhois.com (Postfix) with ESMTP id 998D34C096 for ; Fri, 20 May 2005 23:09:02 -0700 (PDT) Date: Fri, 20 May 2005 23:09:02 -0700 (PDT) From: William Leibzon To: abuse-feedback-report@mipassoc.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/signed; BOUNDARY="-1747394880-1785408299-1116655742=:27335"; protocol="application/x-pkcs7-signature"; micalg=sha1 X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: william@completewhois.com Subject: [feedback-report] Comments on draft (and spam reporting in general) 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, 21 May 2005 05:43:38 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1747394880-1785408299-1116655742=:27335 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed First I'd like to note that I think standard spam reporting format is a good idea (in fact there was supposed ASRG group working on that - whatever happened to it and why discussions are being done on separate mail list and not there), but I'd have thought it be better if it format was XML as it gives more options on what and how to report and extendability for the future then simple mime text fields. In any case I'm going to comment on current draft first: 1. Discussion is needed on combining reporting of more then one email In particular what needs to be decided is: a. If multiple instances are regarding the same message to multiple users, should it be done as separate reports or not? (probably yes) b. What if those multiple instances are to the same user - multiple reports or some way of mentioning that more then one was received? c. Reporting agent may also want to combine multiple reports for separate independent instances together, should it be allowed, encouraged, prohibited? 2. The report includes Reported-Domain and Reported-URI but its possible (in fact likely) that reporting maybe for particular email address rather then domain or URI. I actually think that having separate fields (and adding yet another one) is not the best idea and its better to have something like "Reported-Field:" which would have a tag "type" that can be "URI", "email" or "domain" and then data, i.e. Reported-Field: type="email"; abuser@hulligans.org (apologies if hulligans real domain, I've not checked) Reported-Field: type=URI ; http://www.bankofamerica-phisher.com Note: I don't particular like "-Field" as part of above, but I could not find anything else general enough except "subject" and using that would be even more confusing. Another possibility is just use Reported-URI and use "dns" for reporting dns and "mailto" for reporting email addresses 3. On above, it is probably a good idea to indicate in report if what is being reported is data field from email transmission, email header or email body (and if email body not a bad idea to make possible to report cid URI reference to particular mime body part). Perhaps also indicating particular "location" (byte number) where what is being reported is at is good idea as well (this brings question on syntax to report if field appears in more then one place, probably mutliple Reported-Field). 4. I don't like "Received-Date" - I think its better if "Received-"* are left for use for trace header fields. Maybe better if you pick another name, possibly "Reported-ReceivedDate" to be consistent. 5. This has yet another use of Original-* which is yet again different then what it was before.... In any case, my comment is that I think its better to not name it directly "Original-Mail-From" and "Original-Rcpt-To" but indicate that its envelope parameters, maybe "Original-Envelope-Mail-From" and "Original-Envelope-Rcpt-To" and also leave possibility for parameters of the MAIL and RCPT commands, i.e. "Original-Envelope-Mail-Submitter". 6. "X-Source-IP" is used in some places to indicate source of actual message. Lets not confuse people, change to "Reported-SourceIP". 7. "Version" as separate header field is way too ambitious and unnecessary, lets leave that along and include version tag as part of MIME type, i.e. Content-Type: message/feedback-report ; format-version=0.1 Overall I think the draft and "spam reporting" in general still needs a lot of work and this work should be both deciding in general as to what goes into report and deciding on report format (xml or header fields) and particular syntax as last part. --- William Leibzon mailto: william@completewhois.com Anti-Spam and Email Security Research Worksite: http://www.elan.net/~william/emailsecurity/ Whois & DNS Network Investigation Tools: http://www.completewhois.com ---1747394880-1785408299-1116655742=:27335 Content-Type: APPLICATION/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename="smime.p7s" MIIEWgYJKoZIhvcNAQcCoIIESzCCBEcCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCAl8wggJbMIIBxKADAgECAgMMcrUwDQYJKoZIhvcNAQEEBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBMB4XDTA0MDYwNTA5NDI0MVoXDTA1MDYwNTA5NDI0MVowSzEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEoMCYGCSqGSIb3DQEJ ARYZd2lsbGlhbUBjb21wbGV0ZXdob2lzLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxU1TG0vg2fYJeZ2TZ7cFst7hHB/83aN00wQS1cmKBpDA q3UgvHfcnltbJqmM0+Wfr35P7RDKGjCvqZTS6sDhXeEUDE1OgdwHsYv62TUr y94CQMVu6cctH3T+ajzQ9m1NmR0AT+uYQK7hwwcz70PB6T2troUUlcxFon+H 1jB1t1ECAwEAAaM2MDQwJAYDVR0RBB0wG4EZd2lsbGlhbUBjb21wbGV0ZXdo b2lzLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBACxJJGcY lC9YU8SQWQBr/lzwwk9coMdLKs7YsqcroT12o0UT+AKO+5Ec4VPE7OfBvz66 5w1sz41oAlZM2JggwDSJ8NeYCpLxUxk/1wx1BclPGuedYsRm7NO5CCQP4IO7 qlwgTwBkfkrLeadbUf9MMuOjURVwTKfVkT6qfX8bvbqzMYIBwzCCAb8CAQEw aTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0ECAwxytTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDUyMTA2MDkwMlowIwYJ KoZIhvcNAQkEMRYEFP7WEvO8RUBHK8QEeTWz7qIEMuCXMFIGCSqGSIb3DQEJ DzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGA QE48l4aAmWx74K5aw/1NWKv3atwt0Rz9B4sbd9lwE+IlqlNijbI3oGRmxpWQ JvYM6JJmpNgQby92DpvzeQfrtrQpGijjbkrEqLOC27MtpzEJlwd6QY53HFuG Y2Jt0HpIVNlW0c9BVvddS+DtFXfHpmjoVp1yWQVU8/qGq19NCnE= ---1747394880-1785408299-1116655742=:27335-- Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j4F9f4il017810 for ; Sun, 15 May 2005 02:41:05 -0700 Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id C5D70C8EED8 for ; Sun, 15 May 2005 05:40:13 -0400 (EDT) X-Sasl-enc: cavrKgheLkOTA69Lf5eVqgrxH+T2zl8qI4EoOwNyTlbS 1116150013 Received: from [192.168.2.98] (adsl-67-122-215-175.dsl.snfc21.pacbell.net [67.122.215.175]) by frontend3.messagingengine.com (Postfix) with ESMTP id 724925F; Sun, 15 May 2005 05:40:13 -0400 (EDT) Message-ID: <428718FC.6090408@elvey.com> Date: Sun, 15 May 2005 02:40:12 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] New Draft "01-pre1" References: <427BDD47.1050806@solidmatrix.com> <427C046D.9060700@elvey.com> <42803DFA.5040008@solidmatrix.com> <4283A10B.3060309@elvey.com> In-Reply-To: <4283A10B.3060309@elvey.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: matthew@elvey.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: Sun, 15 May 2005 09:41:20 -0000 Great. Still one small issue I want to review. (err... two) On 5/12/05 11:31 AM, Matthew Elvey sent forth electrons to convey: > On 5/9/05 9:52 PM, Yakov Shafranovich sent forth electrons to convey: > >> Matthew Elvey wrote: >> >>> >>> In 8.2: >>> Re. names: >>> s/abuse/email/ ? (or s/abuse/email-abuse/ ?) there are other >>> kinds of abuse that may adopt this format (IM,wiki,blog...).. >> >> > ? 1)? Current category is: > abuse - spam or some other kind of email abuse. I think this should be called something other than "abuse" and described differently, especially as there are now these other categories: OTHER, fraud, and opt-out[-list], virus. Or do you WANT this category to be all-encompassing - e.g. for reports that the reporter doesn't wish to subcategorize? (I assume not.) Suggestion: change to: > spam - Unsolicited Bulk Email (spam). or > ube - Unsolicited Bulk Email (spam). (The spamhaus and MAPS definitions** are good.) **http://www.spamhaus.org/definition.html I look at the list, and I'd assume that it would be appropriate to use just the first category that matches in the following list: (perhaps something like this should be made explicit) {malware(currently called virus), fraud,spam(currently called abuse), other(currently meaningless, as the previous category, as currently defined, will always match)} 2) Perhaps make this category more broad: < o virus - report of a virus found in the originating message e.g. replace with: > o malware - report of a virus/worm/trojan/downloader/keylogger/spyware found in the originating message 3) A3 needs work. (more headers, body?) Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j4DKfgvc017583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 May 2005 13:41:43 -0700 Received: from 196.sub-70-212-176.myvzw.com ([70.212.176.196] helo=[192.168.0.66]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1DWgxi-0006t1-Dn for abuse-feedback-report@mipassoc.org; Fri, 13 May 2005 16:40:47 -0400 Message-ID: <428510C4.4030409@solidmatrix.com> Date: Fri, 13 May 2005 16:40:36 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en 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-HMDNSGroup-MailScanner-Information: Please contact the ISP for more information X-HMDNSGroup-MailScanner: Found to be clean X-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 - [47 12] / [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: Found to be clean X-Songbird-From: yakovs@solidmatrix.com Subject: [feedback-report] New Draft ("-01" final) 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, 13 May 2005 20:41:54 -0000 Here is the new draft: http://www.shaftek.org/publications/drafts/abuse-report/draft-shafranovich-feedback-report-01.html http://www.shaftek.org/publications/drafts/abuse-report/draft-shafranovich-feedback-report-01.txt Diffs are here: http://www.shaftek.org/publications/drafts/abuse-report/rfcdiff-feedback-report-01-pre1-to-feedback-report-01.html http://www.shaftek.org/publications/drafts/abuse-report/diff-feedback-report-01-pre1-to-feedback-report-01.txt As always, full document repository with all old versions is here: http://www.shaftek.org/publications/drafts/abuse-report/ Formal ARF page related to this effort here: http://mipassoc.org/arf/index.html ----------------------------------------------------- List of changes: o Added an "Outstanding Issues" section. o Minor spelling mistakes and clarifications. o Added links to previous work and more examples. o Added three new types: "fraud" for phishing, "opt-out-list" for a single list opt out, and "other" as a catch-all List of outstanding issues: o Whether encoding of the machine readable part should be limited to 7-bit o Whether there is a need for both "opt-out" and "opt-out-list", and whether this format should be used for opt-outs at all. o Whether the "from" address should be required to be a human just like other RFCs in the "message/report" family. o Whether there is a need for a new header to indicate munging of the included email message. o Whether different type of convention should be allowed for subject lines. o Whether there should be different types defined for "Reported-Uri" to better indicate to the report receiver how they are related to the email message in question. ------------------------------------------------------ Sincerely, Yakov Shafranovich Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j4DJxRR3014551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 May 2005 12:59:28 -0700 Received: from 196.sub-70-212-176.myvzw.com ([70.212.176.196] helo=[192.168.0.66]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1DWgIt-0003Je-Ba; Fri, 13 May 2005 15:58:36 -0400 Message-ID: <428506DE.80300@solidmatrix.com> Date: Fri, 13 May 2005 15:58:22 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Elvey Subject: Re: [feedback-report] New Draft "01-pre1" References: <427BDD47.1050806@solidmatrix.com> <427C046D.9060700@elvey.com> <42803DFA.5040008@solidmatrix.com> <4283A10B.3060309@elvey.com> In-Reply-To: <4283A10B.3060309@elvey.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-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 - [47 12] / [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: Found to be 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, 13 May 2005 19:59:40 -0000 Matthew Elvey wrote: > On 5/9/05 9:52 PM, Yakov Shafranovich sent forth electrons to convey: >>> >>> Re adding "and viruses" in 2.: >>> Aren't viruses (and worms and phishing) all just forms of email >>> abuse? Let's not mention viruses here. >>> >> >> The ISPs and others I have spoken to wanted an ability to >> differentiate between spam abuse and viruses because the response is >> different. For example, an infected machine needs to be cleaned while >> a spammer needs to be kicked off the network. Of course, given the >> zombie armies prevalent now this might mattr less and less. > > > Sure! I'm OK with this being addressed in section 8 ; here in section 2 > is not the place to do it. It's a minor nit. > Done. >> >>> What IETF 'area' does the draft fall into? Applications? It's never >>> been clear what 'area' abuse stuff falls into/why asrg is in the apps >>> area - other abuse stuff has been seen in other 'area's.... >>> >> >> The ASRG is in the IRTF not the IETF. The MARID stuff is in the APPS >> area. >> >> I think that based on the conversation with two ADs this is either for >> the APPS or the security areas. However, at this time this is not yet >> ripe for a working group. > > > I asked because the expert who approves additions to the IANA namespace > is appointed by the AD, so the draft should specify which area it falls > under. > I would rather leave this upto the IESG to decide but I guess for now I am going to specify APPS since this were the other email stuff ends up. >> >>> and this change: >>> Field Name: Reported-URI Description: URI >>> intended to be used to contact the abuser >>> Multiple Appearances: Yes Related >>> "Feedback-Type": any >>> >> >> Many times this is not necessarily the abuser but someone related. For >> example, in phishing schemes this might be a corporate site that is >> used to pull off images. > > > Hmm. seems like the difference between a UCE and an email virus. A > difference is that this difference isn't readily automatically > detectable. Have a type for each? > For now I would rather leave it undefined and see what people will come up in testing. > (I wonder if the folks who get/got a copy of every spamcop report (by > default,) to e.g. notify trademark owners of abuse, have (m)any customers.) > Spamcop does notify trademark owners and some bigger companies do as well. > On 5/9/05 11:14 AM, Tiago sent forth electrons to convey: > >> ME: >> >>> I don't love the changes to 4.f. >> >> >> >> The current 4.f is useful to the one-abuse-mailbox operation, for >> basic subject sorts. I'm happy for those operations that receive so >> few abuse reports. >> >> It seems to me that few are very happy with most proposed subject >> formats. The current 4.f doesn't preserve the subject line, or give an >> indication that this is an ARF message, or why it was sent to you, the >> recipient of the ARF. I preferred the previous 4.f format, but in the >> end, our apps will probably only use the subject and most of the >> machine readable part as sanity checks against what is really parsed >> from the original. > > > I grep through report subjects, and having the "responsible entity" in > the subject is helpful. ( I poorly named "responsible entity"; "subject > entity" may be better name for the handle/identifier of the thing > regarding which we want the report recipient to take action.) > Lets leave this intact for now since I don't think that mandating anything is going to go change anything at first. Then we can see depending on the feedback whether people are satisfied with it. Once again this is only a draft and I would like to see how people in the field use it. >> It would be nice to allow for spamcop messages and all the other >> suggested subject formats to be allowed by the standard, including the >> old and new 4.f format, but that's wishfully thinking on my part :) > > > I got the feeling that spamcop would be adopting this format, based on > the second-hand feedback from Julian Haight. > If we're calling it ARF, let's put that acronym in the draft. > K. Yakov Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j4CIWYQn022843 for ; Thu, 12 May 2005 11:32:34 -0700 Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id B6433C8E7B6; Thu, 12 May 2005 14:31:42 -0400 (EDT) X-Sasl-enc: i2LIilsv7SPYloit3gXEyfqtEk7/7h589uz/PcqVnT6M 1115922702 Received: from [192.168.19.155] (gateway.swissnex.org [216.38.156.54]) by frontend3.messagingengine.com (Postfix) with ESMTP id 079E184; Thu, 12 May 2005 14:31:40 -0400 (EDT) Message-ID: <4283A10B.3060309@elvey.com> Date: Thu, 12 May 2005 11:31:39 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yakov Shafranovich , abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] New Draft "01-pre1" References: <427BDD47.1050806@solidmatrix.com> <427C046D.9060700@elvey.com> <42803DFA.5040008@solidmatrix.com> In-Reply-To: <42803DFA.5040008@solidmatrix.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: matthew@elvey.com Cc: 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, 12 May 2005 18:32:41 -0000 On 5/9/05 9:52 PM, Yakov Shafranovich sent forth electrons to convey: > Matthew Elvey wrote: > >> Much improved. >> > > Thank you and sorry for the delayed reply. Things have been hectic > lately. > >> >> Re adding "and viruses" in 2.: >> Aren't viruses (and worms and phishing) all just forms of email >> abuse? Let's not mention viruses here. >> > > The ISPs and others I have spoken to wanted an ability to > differentiate between spam abuse and viruses because the response is > different. For example, an infected machine needs to be cleaned while > a spammer needs to be kicked off the network. Of course, given the > zombie armies prevalent now this might mattr less and less. Sure! I'm OK with this being addressed in section 8 ; here in section 2 is not the place to do it. It's a minor nit. > >> "The machine readable section must provide ability for report" >> needs a "the". >> > > Will correct. > >> I don't love the changes to 4.f. >> I'd include something like this: >> "The subject line of the feedback report MUST?SHOULD? include the >> that of the original abusive email" >> and perhaps something like this: >> "and SHOULD include the responsible entity (source IP and/or domain >> and/or email address and/or DNS server and/or web server...)" >> > > Quite a few people pointed out to me that many smaller operations sort > their abuse stuff on the subject line. The responsible entity, IP, etc > will get in their way. See comment after Tiago's, below. > >> What IETF 'area' does the draft fall into? Applications? It's never >> been clear what 'area' abuse stuff falls into/why asrg is in the apps >> area - other abuse stuff has been seen in other 'area's.... >> > > The ASRG is in the IRTF not the IETF. The MARID stuff is in the APPS > area. > > I think that based on the conversation with two ADs this is either for > the APPS or the security areas. However, at this time this is not yet > ripe for a working group. I asked because the expert who approves additions to the IANA namespace is appointed by the AD, so the draft should specify which area it falls under. > >> >> I propose this addition: >> Field Name: Reported-email Description: >> email address intended to be used to contact the abuser >> Multiple Appearances: Yes Related >> "Feedback-Type": any >> > > The Reported-URI field already includes ability to have email > addresses (via "mailto:" scheme). True. > >> and this change: >> Field Name: Reported-URI Description: URI >> intended to be used to contact the abuser >> Multiple Appearances: Yes Related >> "Feedback-Type": any >> > > Many times this is not necessarily the abuser but someone related. For > example, in phishing schemes this might be a corporate site that is > used to pull off images. Hmm. seems like the difference between a UCE and an email virus. A difference is that this difference isn't readily automatically detectable. Have a type for each? (I wonder if the folks who get/got a copy of every spamcop report (by default,) to e.g. notify trademark owners of abuse, have (m)any customers.) > >> (I was going to suggest these be of type abuse only, but they would >> be useful for reporting other abuse (IM,wiki,blog...) >> > > As of now I want to limit it to email spam. However, it can be used to > report other types as well in theory. Both good ideas. > However, that might cross over with the work already being done in the > INCH and other IETF WGs. > >> >> In 8.2: >> Re. names: >> s/abuse/email/ ? (or s/abuse/email-abuse/ ?) there are other >> kinds of abuse that may adopt this format (IM,wiki,blog...).. > ? >> >> Did you forget to reference the work I mentioned or change your mind >> about adding it? : >> > > Slipped my mind. Will be corrected. > >>> >1)Are you aware of the significant prior work done as noted here: >>> >http://www.tmisnet.com/~strads/spam/bcp.html ? IIRC, I mentioned >>> it on ASRG or MARID. >>> >>> I am aware of it and will include a reference in the next draft. >> >> >> >> >> Hope this helps. > > > Thanks for your comments, keep them coming! Ditto. :) I think this work will make a difference, though abuse desks that are wilfully ignorant, but try to appear helpful will remain so. On 5/9/05 11:14 AM, Tiago sent forth electrons to convey: > ME: > >> I don't love the changes to 4.f. > > > The current 4.f is useful to the one-abuse-mailbox operation, for > basic subject sorts. I'm happy for those operations that receive so > few abuse reports. > > It seems to me that few are very happy with most proposed subject > formats. The current 4.f doesn't preserve the subject line, or give an > indication that this is an ARF message, or why it was sent to you, the > recipient of the ARF. I preferred the previous 4.f format, but in the > end, our apps will probably only use the subject and most of the > machine readable part as sanity checks against what is really parsed > from the original. I grep through report subjects, and having the "responsible entity" in the subject is helpful. ( I poorly named "responsible entity"; "subject entity" may be better name for the handle/identifier of the thing regarding which we want the report recipient to take action.) > It would be nice to allow for spamcop messages and all the other > suggested subject formats to be allowed by the standard, including the > old and new 4.f format, but that's wishfully thinking on my part :) I got the feeling that spamcop would be adopting this format, based on the second-hand feedback from Julian Haight. If we're calling it ARF, let's put that acronym in the draft. Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j4A4rDiH032076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 May 2005 21:53:14 -0700 Received: from 64.sub-166-180-38.myvzw.com ([166.180.38.64] helo=[192.168.0.66]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1DVMjC-0006r0-TK; Tue, 10 May 2005 00:52:19 -0400 Message-ID: <42803DFA.5040008@solidmatrix.com> Date: Tue, 10 May 2005 00:52:10 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Elvey Subject: Re: [feedback-report] New Draft "01-pre1" References: <427BDD47.1050806@solidmatrix.com> <427C046D.9060700@elvey.com> In-Reply-To: <427C046D.9060700@elvey.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-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 - [47 12] / [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: Found to be 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: Tue, 10 May 2005 04:53:36 -0000 Matthew Elvey wrote: > Much improved. > Thank you and sorry for the delayed reply. Things have been hectic lately. > > Re adding "and viruses" in 2.: > Aren't viruses (and worms and phishing) all just forms of email abuse? > Let's not mention viruses here. > The ISPs and others I have spoken to wanted an ability to differentiate between spam abuse and viruses because the response is different. For example, an infected machine needs to be cleaned while a spammer needs to be kicked off the network. Of course, given the zombie armies prevalent now this might mattr less and less. > "The machine readable section must provide ability for report" > needs a "the". > Will correct. > I don't love the changes to 4.f. > I'd include something like this: > "The subject line of the feedback report MUST?SHOULD? include the that > of the original abusive email" > and perhaps something like this: > "and SHOULD include the responsible entity (source IP and/or domain > and/or email address and/or DNS server and/or web server...)" > Quite a few people pointed out to me that many smaller operations sort their abuse stuff on the subject line. The responsible entity, IP, etc will get in their way. > What IETF 'area' does the draft fall into? Applications? It's never > been clear what 'area' abuse stuff falls into/why asrg is in the apps > area - other abuse stuff has been seen in other 'area's.... > The ASRG is in the IRTF not the IETF. The MARID stuff is in the APPS area. I think that based on the conversation with two ADs this is either for the APPS or the security areas. However, at this time this is not yet ripe for a working group. > > I propose this addition: > Field Name: Reported-email Description: email > address intended to be used to contact the abuser > Multiple Appearances: Yes Related > "Feedback-Type": any > The Reported-URI field already includes ability to have email addresses (via "mailto:" scheme). > and this change: > Field Name: Reported-URI Description: URI > intended to be used to contact the abuser > Multiple Appearances: Yes Related > "Feedback-Type": any > Many times this is not necessarily the abuser but someone related. For example, in phishing schemes this might be a corporate site that is used to pull off images. > (I was going to suggest these be of type abuse only, but they would be > useful for reporting other abuse (IM,wiki,blog...) > As of now I want to limit it to email spam. However, it can be used to report other types as well in theory. However, that might cross over with the work already being done in the INCH and other IETF WGs. > > In 8.2: > Re. names: > s/abuse/email/ ? (or s/abuse/email-abuse/ ?) there are other kinds > of abuse that may adopt this format (IM,wiki,blog...).. > > Did you forget to reference the work I mentioned or change your mind > about adding it? : > Slipped my mind. Will be corrected. >> >1)Are you aware of the significant prior work done as noted here: >> >http://www.tmisnet.com/~strads/spam/bcp.html ? IIRC, I mentioned it >> on ASRG or MARID. >> >> I am aware of it and will include a reference in the next draft. > > > > Hope this helps. Thanks for your comments, keep them coming! Received: from imo-m17.mx.aol.com (imo-m17.mx.aol.com [64.12.138.207]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j49IGVSf027782 for ; Mon, 9 May 2005 11:16:31 -0700 Received: from TStock05@aol.com by imo-m17.mx.aol.com (mail_out_v38_r1.7.) id k.cd.27d58c73 (16086) for ; Mon, 9 May 2005 14:15:27 -0400 (EDT) Received: from [10.0.25.130] (lisbon.office.aol.com [10.0.25.130]) by air-id10.mx.aol.com (vx) with ESMTP id MAILINID103-3ed6427fa8b164; Mon, 09 May 2005 14:15:26 -0400 Message-ID: <427FA890.3050703@aol.com> Date: Mon, 09 May 2005 14:14:40 -0400 From: Tiago User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org References: <200505071900.j47J01Or004718@sb7.songbird.com> In-Reply-To: <200505071900.j47J01Or004718@sb7.songbird.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 10.0.25.130 X-Mailer: Unknown (No Version) X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: tstock05@aol.com Subject: [feedback-report] [abuse-report] New Draft "01-pre1" 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: Mon, 09 May 2005 18:16:35 -0000 > I don't love the changes to 4.f. The current 4.f is useful to the one-abuse-mailbox operation, for basic subject sorts. I'm happy for those operations that receive so few abuse reports. It seems to me that few are very happy with most proposed subject formats. The current 4.f doesn't preserve the subject line, or give an indication that this is an ARF message, or why it was sent to you, the recipient of the ARF. I preferred the previous 4.f format, but in the end, our apps will probably only use the subject and most of the machine readable part as sanity checks against what is really parsed from the original. It would be nice to allow for spamcop messages and all the other suggested subject formats to be allowed by the standard, including the old and new 4.f format, but that's wishfully thinking on my part :) Tiago AOL AntiSpam Operations Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j46NwWnL021743 for ; Fri, 6 May 2005 16:58:32 -0700 Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 37F4FC8B3FC; Fri, 6 May 2005 19:57:39 -0400 (EDT) X-Sasl-enc: HHZtvNMnvR18/KWMcYSZXlCtI6hvUribmGh80iuOyoNy 1115423859 Received: from [192.168.1.208] (banana.groupd.com [64.139.6.95]) by frontend3.messagingengine.com (Postfix) with ESMTP id B16FB5F; Fri, 6 May 2005 19:57:38 -0400 (EDT) Message-ID: <427C046D.9060700@elvey.com> Date: Fri, 06 May 2005 16:57:33 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yakov Shafranovich Subject: Re: [feedback-report] New Draft "01-pre1" References: <427BDD47.1050806@solidmatrix.com> In-Reply-To: <427BDD47.1050806@solidmatrix.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: matthew@elvey.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, 06 May 2005 23:58:34 -0000 Much improved. Re adding "and viruses" in 2.: Aren't viruses (and worms and phishing) all just forms of email abuse? Let's not mention viruses here. "The machine readable section must provide ability for report" needs a "the". I don't love the changes to 4.f. I'd include something like this: "The subject line of the feedback report MUST?SHOULD? include the that of the original abusive email" and perhaps something like this: "and SHOULD include the responsible entity (source IP and/or domain and/or email address and/or DNS server and/or web server...)" What IETF 'area' does the draft fall into? Applications? It's never been clear what 'area' abuse stuff falls into/why asrg is in the apps area - other abuse stuff has been seen in other 'area's.... I propose this addition: Field Name: Reported-email Description: email address intended to be used to contact the abuser Multiple Appearances: Yes Related "Feedback-Type": any and this change: Field Name: Reported-URI Description: URI intended to be used to contact the abuser Multiple Appearances: Yes Related "Feedback-Type": any (I was going to suggest these be of type abuse only, but they would be useful for reporting other abuse (IM,wiki,blog...) In 8.2: Re. names: s/abuse/email/ ? (or s/abuse/email-abuse/ ?) there are other kinds of abuse that may adopt this format (IM,wiki,blog...).. Did you forget to reference the work I mentioned or change your mind about adding it? : > >1)Are you aware of the significant prior work done as noted here: > >http://www.tmisnet.com/~strads/spam/bcp.html ? IIRC, I mentioned it > on ASRG or MARID. > > I am aware of it and will include a reference in the next draft. Hope this helps. Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j46LBXlA013913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 May 2005 14:11:34 -0700 Received: from 134.sub-70-216-129.myvzw.com ([70.216.129.134]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1DUA5q-0006jE-S2 for abuse-feedback-report@mipassoc.org; Fri, 06 May 2005 17:10:43 -0400 Message-ID: <427BDD47.1050806@solidmatrix.com> Date: Fri, 06 May 2005 17:10:31 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en 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-HMDNSGroup-MailScanner-Information: Please contact the ISP for more information X-HMDNSGroup-MailScanner: Found to be clean X-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: Found to be clean X-Songbird-From: yakovs@solidmatrix.com Subject: [feedback-report] New Draft "01-pre1" 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, 06 May 2005 21:11:39 -0000 I just put up a new draft (-01), revision 1 (pre1). I did not send it into the IETF repository because I wanted to make sure that all of us are on the same page. The draft is available here: http://www.shaftek.org/publications/drafts/abuse-report/draft-shafranovich-feedback-report-01-pre1.html http://www.shaftek.org/publications/drafts/abuse-report/draft-shafranovich-feedback-report-01-pre1.txt Diffs are here: http://www.shaftek.org/publications/drafts/abuse-report/rfcdiff-feedback-report-00-to-feedback-report-01-pre1.html http://www.shaftek.org/publications/drafts/abuse-report/diff-feedback-report-00-to-feedback-report-01-pre1.txt I also put up a better looking web page for the document repository (instead of a simple file listing) here: http://www.shaftek.org/publications/drafts/abuse-report/ There is a link to the main ARF page at MIPA which Dave Crocker put up here: http://mipassoc.org/arf/index.html Yakov Received: from manet.hmdnsgroup.com (manet.hmdnsgroup.com [63.247.133.3]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j46FEdV0011931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 May 2005 08:14:40 -0700 Received: from 60.sub-166-180-37.myvzw.com ([166.180.37.60]) by manet.hmdnsgroup.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1DU4WQ-0001Au-Ue; Fri, 06 May 2005 11:13:47 -0400 Message-ID: <427B899F.7020406@solidmatrix.com> Date: Fri, 06 May 2005 11:13:35 -0400 From: Yakov Shafranovich Organization: SolidMatrix Technologies, Inc. User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Elvey Subject: Re: [feedback-report] misc comments (on draft-shafranovich-feedback-report-00(pre I-D)) References: <427134DC.8010208@elvey.com> <4272ADF5.7020506@elvey.com> <4272B82C.8070500@solidmatrix.com> <427813DE.2020902@elvey.com> In-Reply-To: <427813DE.2020902@elvey.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-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: Found to be 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, 06 May 2005 15:14:47 -0000 (Sorry for the delay, I had a lot on my plate this week) Matthew Elvey wrote: > On 4/29/05 3:41 PM, Yakov Shafranovich sent forth electrons to convey: >> Matthew Elvey wrote: >>> =-=-= >>> Big picture issues: >>> One issue I see with this draft is that it's impossible to send such >>> reports without specialized tools; normal MUAs can't send this mime >>> type. >>> Is that a feature or a bug? Another issue is that it implies that a >>> reporter must craft a separate email for each reportee. >>> >> >> Both are features: >> 1st issue - its intended for ISP to ISP communications primarly (i.e. >> their abuse systems and things like AOL's scomp). >> 2nd issue - this format is intended to cover the use case of one >> report/message. Summaries and aggregate formats will follow as a >> separate standard. ISP feedback affected both of these points. >> >> Regarding the first point once more, I would really really really like >> to write a Thunderbird/Mozilla Mail extension to generate these >> reports but don't have the time to do so. > (someone is actually working on this) > > If it's for ISP-ISP communications, why an extension? And if a major > user will be end-users, changes to address the above two issues seem > doable. The second part will contain a set of metadata headers which would need to be defined. That's is why I choose to extend RFC 3462. > There used to be many abuse@ addresses that don't accept, or discard all > attachments. That may have changed; I haven't sent anything other than > plain text in to abuse-handling addresses in years. Actually, I do have > one recent data point. I did send email to spamhaus, and because I > wanted to show a chart, I sent a mail in dual text/html format; the > recipient slogged through the plain text version.) I guess if you've > spoken to a bunch of ISPs (both reputable and not-so-reputable ones), > and they're all ok receiving attachments, then I've no objection. > The ISPs I have spoken to were fine with this. > > > > Yakov, let me know if my assumption that that > draft-shafranovich-abuse-report-00 has been replaced by > draft-shafranovich-feedback-report-00 is wrong. > This assumption is correct. Yakov Received: from mrout1-b.corp.dcn.yahoo.com (mrout1-b.corp.dcn.yahoo.com [216.109.112.27]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j440iKGf003821 for ; Tue, 3 May 2005 17:44:21 -0700 Received: from [66.228.167.95] (jdfalk-mac.corp.yahoo.com [66.228.167.95]) by mrout1-b.corp.dcn.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id j440hOsM059108 for ; Tue, 3 May 2005 17:43:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:organization:user-agent: x-accept-language:mime-version:to:subject:references:in-reply-to:content-type; b=bKOwdyQmjx0O0QntodwKeMefLBx+w5aiIzXQKl86eBOTZFLgWM0w+f0i1nccV37Y Message-ID: <42781AAE.7030200@yahoo-inc.com> Date: Tue, 03 May 2005 17:43:26 -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.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.6.0.104 X-Accept-Language: en-us, en MIME-Version: 1.0 To: abuse-feedback-report@mipassoc.org Subject: Re: [feedback-report] misc comments (on draft-shafranovich-feedback-report-00(pre I-D)) References: <427134DC.8010208@elvey.com> <4272ADF5.7020506@elvey.com> <4272B82C.8070500@solidmatrix.com> <427813DE.2020902@elvey.com> In-Reply-To: <427813DE.2020902@elvey.com> Content-Type: multipart/alternative; boundary="------------040205020602010805090505" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be 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, 04 May 2005 00:44:43 -0000 This is a multi-part message in MIME format. --------------040205020602010805090505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/3/05 5:14 PM, Matthew Elvey wrote: > There used to be many abuse@ addresses that don't accept, or discard >all attachments. That may have changed; I haven't sent anything other >than plain text in to abuse-handling addresses in years. Actually, I do >have one recent data point. I did send email to spamhaus, and because I >wanted to show a chart, I sent a mail in dual text/html format; the >recipient slogged through the plain text version.) I guess if you've >spoken to a bunch of ISPs (both reputable and not-so-reputable ones), >and they're all ok receiving attachments, then I've no objection. > > In most cases these won't go to the standard abuse@isp address, so they won't be handled by the same attachment-phobic customer support software. -- J.D. Falk, Anti-spam Product Manager, Yahoo! Mail jdfalk@yahoo-inc.com --------------040205020602010805090505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/3/05 5:14 PM, Matthew Elvey wrote: 
 There used to be many abuse@ addresses that don't accept, or discard 
all attachments.  That may have changed; I haven't sent anything other 
than plain text in to abuse-handling addresses in years.  Actually, I do 
have one recent data point.  I did send email to spamhaus, and because I 
wanted to show a chart, I sent a mail in dual text/html format;  the 
recipient slogged through the plain text version.)  I guess if you've 
spoken to a bunch of ISPs (both reputable and not-so-reputable ones), 
and they're all ok receiving attachments, then I've no objection.
In most cases these won't go to the standard abuse@isp address, so they won't be handled by the same attachment-phobic customer support software.
-- 
J.D. Falk, Anti-spam Product Manager, Yahoo! Mail
jdfalk@yahoo-inc.com
--------------040205020602010805090505-- Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j440FE4E002519 for ; Tue, 3 May 2005 17:15:14 -0700 Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 9A19DC88945; Tue, 3 May 2005 20:14:21 -0400 (EDT) X-Sasl-enc: MqF0NWd0KhYJ1CPOjjYIYm7mWskMLll+F3AO7GOVKUYe 1115165658 Received: from [192.168.1.246] (pix.nextbus.com [64.142.39.201]) by frontend3.messagingengine.com (Postfix) with ESMTP id 9113984; Tue, 3 May 2005 20:14:17 -0400 (EDT) Message-ID: <427813DE.2020902@elvey.com> Date: Tue, 03 May 2005 17:14:22 -0700 From: Matthew Elvey User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yakov Shafranovich Subject: Re: [feedback-report] misc comments (on draft-shafranovich-feedback-report-00(pre I-D)) References: <427134DC.8010208@elvey.com> <4272ADF5.7020506@elvey.com> <4272B82C.8070500@solidmatrix.com> In-Reply-To: <4272B82C.8070500@solidmatrix.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: matthew@elvey.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: Wed, 04 May 2005 00:15:34 -0000 On 4/29/05 3:41 PM, Yakov Shafranovich sent forth electrons to convey: > Matthew Elvey wrote: > >> Is this intended to obsolete RFCs 1982 or 3462? >> > > Nope. I guess I should clarify the intent better in the next draft but > this format intended as a child of 3462 just like DSNs and return > receipts are. The intent of this specific format is a format for > providing feedback between network operators and organizations > regarding abuse issues primarly and related matters like opt-outs, > "virus detected" messages, etc. > >> Should we add to 2 Intent: >> d To inform reputation service providers about email abuse by >> entities* they vouch for. >> Also, what about ISPs providing hosting or dns for spamvertized email >> or website addresses? >> *(by this I mean IPs or (HELO or 282[1|2].FrOM or Sender: or even >> PRA) domains or perhaps something else) >> > > I intended to cover all of these and will clarify so in the next draft. > >> =-=-= >> Change 3 b and 4 g to be more explicit about whether the headers and >> body must always be included (folks reading 3 b might (wrongly) >> assume that headers are not part of the message). Why not say that >> they MUST be included? > > > Will do. > >> =-=-= >> Re. 4 f: s/x.x.x.x/[IP]/ and s/YYYY.ZZZZ/example.com/? IPs could >> be IPv6 IPs, and example.com is clearer, IMO. > > > K. > >> =-=-= >> Big picture issues: >> One issue I see with this draft is that it's impossible to send such >> reports without specialized tools; normal MUAs can't send this mime >> type. >> Is that a feature or a bug? Another issue is that it implies that a >> reporter must craft a separate email for each reportee. >> > > Both are features: > 1st issue - its intended for ISP to ISP communications primarly (i.e. > their abuse systems and things like AOL's scomp). > 2nd issue - this format is intended to cover the use case of one > report/message. Summaries and aggregate formats will follow as a > separate standard. ISP feedback affected both of these points. > > Regarding the first point once more, I would really really really like > to write a Thunderbird/Mozilla Mail extension to generate these > reports but don't have the time to do so. If it's for ISP-ISP communications, why an extension? And if a major user will be end-users, changes to address the above two issues seem doable. There used to be many abuse@ addresses that don't accept, or discard all attachments. That may have changed; I haven't sent anything other than plain text in to abuse-handling addresses in years. Actually, I do have one recent data point. I did send email to spamhaus, and because I wanted to show a chart, I sent a mail in dual text/html format; the recipient slogged through the plain text version.) I guess if you've spoken to a bunch of ISPs (both reputable and not-so-reputable ones), and they're all ok receiving attachments, then I've no objection. > >> This thread outlines the task before us well, IMO: >> >> > > > I don't have the time to read through it right now but I will do so > either Sunday night or early next week. However, a quick look through > it seems to talk about parsing issues. I will get back on this as soon > as I read the whole thing in detail. I just noticed that the first few posts were pretty useful; I don't recall the rest. >> ..Yakov, [may I] post anything from our private email on this topic... > > Please go ahead. Here goes. Edited. Yakov wrote: > Matthew Elvey wrote: >> >> 1)Are you aware of the significant prior work done as noted here: >> http://www.tmisnet.com/~strads/spam/bcp.html ? IIRC, I mentioned it >> on ASRG or MARID. >> > I am aware of it and will include a reference in the next draft. > ... > This draft has been developed based on a lot of private feedback from > ISPs and MAAWG members. > >> 3)Consider CSV (csv) for the initial "Authentication-Domain-Method" >> registry. >> > > No problem, I am sure there are more as well. >> >> 4)Any feedback from spamcop.net/Julian Haight? I'd like to know if >> SpamCop would adopt this format; they probably have as good an idea >> as anyone what works, having transmitted more reports than anyone >> else. Also, they've developed a de facto standard. > > Julian is very enthuiastic about the draft. Yakov, let me know if my assumption that that draft-shafranovich-abuse-report-00 has been replaced by draft-shafranovich-feedback-report-00 is wrong.