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 <abuse-feedback-report@mipassoc.org>; 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 <abuse-feedback-report@mipassoc.org>; 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" <jdfalk@yahoo-inc.com>
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 <abuse-feedback-report.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/abuse-feedback-report>
List-Post: <mailto:abuse-feedback-report@mipassoc.org>
List-Help: <mailto:abuse-feedback-report-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000066">
On 5/26/05 12:48 PM, Yakov Shafranovich wrote:
<blockquote cite="mid42962828.1080407@solidmatrix.com" type="cite">
  <pre wrap="">Take a look at:

<a class="moz-txt-link-freetext" href="http://postmaster.msn.com/snds/FAQ.aspx">http://postmaster.msn.com/snds/FAQ.aspx</a>
<a class="moz-txt-link-freetext" href="http://postmaster.msn.com/snds/">http://postmaster.msn.com/snds/</a>
  </pre>
</blockquote>
MSN's SNDS covers aggregate mail traffic, rather than reports of
individual messages.<br>
<pre class="moz-signature" cols="72">-- 
J.D. Falk, Anti-spam Product Manager, Yahoo! Mail
<a class="moz-txt-link-abbreviated" href="mailto:jdfalk@yahoo-inc.com">jdfalk@yahoo-inc.com</a>
</pre>
</body>
</html>

--------------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 <abuse-feedback-report@mipassoc.org>; 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 <YakovS@solidmatrix.com>
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 <abuse-feedback-report.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/abuse-feedback-report>
List-Post: <mailto:abuse-feedback-report@mipassoc.org>
List-Help: <mailto:abuse-feedback-report-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=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 <abuse-feedback-report@mipassoc.org>; 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 <YakovS@solidmatrix.com>
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 <blilly@erols.com>
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 <ietf-822@imc.org>, 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 <abuse-feedback-report.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/abuse-feedback-report>
List-Post: <mailto:abuse-feedback-report@mipassoc.org>
List-Help: <mailto:abuse-feedback-report-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=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 <abuse-feedback-report@mipassoc.org>; 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 <YakovS@solidmatrix.com>
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 <abuse-feedback-report.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/abuse-feedback-report>
List-Post: <mailto:abuse-feedback-report@mipassoc.org>
List-Help: <mailto:abuse-feedback-report-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=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 <abuse-feedback-report@mipassoc.org>; 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 <YakovS@solidmatrix.com>
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 <abuse-feedback-report.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/abuse-feedback-report>
List-Post: <mailto:abuse-feedback-report@mipassoc.org>
List-Help: <mailto:abuse-feedback-report-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=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 <abuse-feedback-report@mipassoc.org>; 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 <YakovS@solidmatrix.com>
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 <william@completewhois.com>
Subject: Re: [feedback-report] Comments on draft (and spam reporting in general)
References: <Pine.LNX.4.60.0505202219210.27335@cwhois1.completewhois.com>
In-Reply-To: <Pine.LNX.4.60.0505202219210.27335@cwhois1.completewhois.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 <abuse-feedback-report.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/abuse-feedback-report>
List-Post: <mailto:abuse-feedback-report@mipassoc.org>
List-Help: <mailto:abuse-feedback-report-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=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 <abuse-feedback-report@mipassoc.org>; 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 <YakovS@solidmatrix.com>
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 <blilly@erols.com>
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-822@imc.org>, 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 <abuse-feedback-report.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/abuse-feedback-report>
List-Post: <mailto:abuse-feedback-report@mipassoc.org>
List-Help: <mailto:abuse-feedback-report-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=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 <abuse-feedback-report@mipassoc.org>; 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 <YakovS@solidmatrix.com>
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 <abuse-feedback-report.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/abuse-feedback-report>
List-Post: <mailto:abuse-feedback-report@mipassoc.org>
List-Help: <mailto:abuse-feedback-report-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=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 <blilly@erols.com>
Reply-To: ietf-822 <ietf-822@imc.org>
Organization: Bruce Lilly
To: ietf-822 <ietf-822@imc.org>, 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: <abusedesk@example.com>
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: <abuse@example.net>
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: <somespammer@example.net>
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: <Undisclosed Recipients>
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 <abuse-feedback-report@mipassoc.org>; 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 <abuse-feedback-report@mipassoc.org>; 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" <jdfalk@yahoo-inc.com>
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: <Pine.LNX.4.60.0505202219210.27335@cwhois1.completewhois.com>
In-Reply-To: <Pine.LNX.4.60.0505202219210.27335@cwhois1.completewhois.com>
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 <abuse-feedback-report.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/abuse-feedback-report>
List-Post: <mailto:abuse-feedback-report@mipassoc.org>
List-Help: <mailto:abuse-feedback-report-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000066">
On 5/20/05 11:09 PM, William Leibzon wrote:
<blockquote
 cite="midPine.LNX.4.60.0505202219210.27335@cwhois1.completewhois.com"
 type="cite">
  <pre wrap="">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.
  </pre>
</blockquote>
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.<br>
<blockquote
 cite="midPine.LNX.4.60.0505202219210.27335@cwhois1.completewhois.com"
 type="cite">
  <pre wrap="">1. Discussion is needed on combining reporting of more then one email
  </pre>
</blockquote>
Our consensus was to leave that for a future version, and assume one
report for one message to one report recipient for now.<br>
<blockquote
 cite="midPine.LNX.4.60.0505202219210.27335@cwhois1.completewhois.com"
 type="cite">
  <pre wrap="">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.</pre>
</blockquote>
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.&nbsp; Maybe
we should change it back.<br>
<blockquote
 cite="midPine.LNX.4.60.0505202219210.27335@cwhois1.completewhois.com"
 type="cite">
  <pre wrap="">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).
  </pre>
</blockquote>
How would this help report recipients to handle these reports more
effectively?<br>
<br>
You also wrote a bunch about headers -- you do realize that these
fields aren't mail headers, but are actually message content?<br>
<blockquote
 cite="midPine.LNX.4.60.0505202219210.27335@cwhois1.completewhois.com"
 type="cite">
  <pre wrap="">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.
  </pre>
</blockquote>
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.<br>
<pre class="moz-signature" cols="72">-- 
J.D. Falk, Anti-spam Product Manager, Yahoo! Mail
<a class="moz-txt-link-abbreviated" href="mailto:jdfalk@yahoo-inc.com">jdfalk@yahoo-inc.com</a>
</pre>
</body>
</html>

--------------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 <abuse-feedback-report@mipassoc.org>; 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 <abuse-feedback-report@mipassoc.org>; Fri, 20 May 2005 23:09:02 -0700 (PDT)
Date: Fri, 20 May 2005 23:09:02 -0700 (PDT)
From: William Leibzon <william@completewhois.com>
To: abuse-feedback-report@mipassoc.org
Message-ID: <Pine.LNX.4.60.0505202219210.27335@cwhois1.completewhois.com>
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 <abuse-feedback-report.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/abuse-feedback-report>
List-Post: <mailto:abuse-feedback-report@mipassoc.org>
List-Help: <mailto:abuse-feedback-report-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=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 <abuse-feedback-report@mipassoc.org>; 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 <abuse-feedback-report@mipassoc.org>; 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 <matthew@elvey.com>
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 <http://www.habeas.com/report/>.
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 <abuse-feedback-report.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/abuse-feedback-report>
List-Post: <mailto:abuse-feedback-report@mipassoc.org>
List-Help: <mailto:abuse-feedback-report-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=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 <abuse-feedback-report@mipassoc.org>; 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 <YakovS@solidmatrix.com>
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 <abuse-feedback-report.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/abuse-feedback-report>
List-Post: <mailto:abuse-feedback-report@mipassoc.org>
List-Help: <mailto:abuse-feedback-report-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=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 <abuse-feedback-report@mipassoc.org>; 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 <YakovS@solidmatrix.com>
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 <matthew@elvey.com>
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 <abuse-feedback-report.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/abuse-feedback-report>
List-Post: <mailto:abuse-feedback-report@mipassoc.org>
List-Help: <mailto:abuse-feedback-report-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=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 <abuse-feedback-report@mipassoc.org>; 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 <matthew@elvey.com>
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Yakov Shafranovich <YakovS@solidmatrix.com>, 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 <http://www.habeas.com/report/>.
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 <abuse-feedback-report.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/abuse-feedback-report>
List-Post: <mailto:abuse-feedback-report@mipassoc.org>
List-Help: <mailto:abuse-feedback-report-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=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 <abuse-feedback-report@mipassoc.org>; 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 <YakovS@solidmatrix.com>
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 <matthew@elvey.com>
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 <abuse-feedback-report.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/abuse-feedback-report>
List-Post: <mailto:abuse-feedback-report@mipassoc.org>
List-Help: <mailto:abuse-feedback-report-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=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 <abuse-feedback-report@mipassoc.org>; 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 <abuse-feedback-report@mipassoc.org>; 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 <tstock05@aol.com>
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 <abuse-feedback-report.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/abuse-feedback-report>
List-Post: <mailto:abuse-feedback-report@mipassoc.org>
List-Help: <mailto:abuse-feedback-report-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=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 <abuse-feedback-report@mipassoc.org>; 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 <matthew@elvey.com>
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Yakov Shafranovich <YakovS@solidmatrix.com>
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 <http://www.habeas.com/report/>.
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 <abuse-feedback-report.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/abuse-feedback-report>
List-Post: <mailto:abuse-feedback-report@mipassoc.org>
List-Help: <mailto:abuse-feedback-report-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=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 <abuse-feedback-report@mipassoc.org>; 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 <YakovS@solidmatrix.com>
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 <abuse-feedback-report.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/abuse-feedback-report>
List-Post: <mailto:abuse-feedback-report@mipassoc.org>
List-Help: <mailto:abuse-feedback-report-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=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 <abuse-feedback-report@mipassoc.org>; 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 <YakovS@solidmatrix.com>
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 <matthew@elvey.com>
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 <abuse-feedback-report.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/abuse-feedback-report>
List-Post: <mailto:abuse-feedback-report@mipassoc.org>
List-Help: <mailto:abuse-feedback-report-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=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 <abuse-feedback-report@mipassoc.org>; 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 <abuse-feedback-report@mipassoc.org>; 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" <jdfalk@yahoo-inc.com>
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 <abuse-feedback-report.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/abuse-feedback-report>
List-Post: <mailto:abuse-feedback-report@mipassoc.org>
List-Help: <mailto:abuse-feedback-report-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000066">
On 5/3/05 5:14 PM, Matthew Elvey wrote:
<blockquote cite="mid427813DE.2020902@elvey.com" type="cite">
  <pre wrap=""> 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.
  </pre>
</blockquote>
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.<br>
<pre class="moz-signature" cols="72">-- 
J.D. Falk, Anti-spam Product Manager, Yahoo! Mail
<a class="moz-txt-link-abbreviated" href="mailto:jdfalk@yahoo-inc.com">jdfalk@yahoo-inc.com</a>
</pre>
</body>
</html>

--------------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 <abuse-feedback-report@mipassoc.org>; 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 <matthew@elvey.com>
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Yakov Shafranovich <YakovS@solidmatrix.com>
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 <http://www.habeas.com/report/>.
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 <abuse-feedback-report.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/abuse-feedback-report>
List-Post: <mailto:abuse-feedback-report@mipassoc.org>
List-Help: <mailto:abuse-feedback-report-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/abuse-feedback-report>,  <mailto:abuse-feedback-report-request@mipassoc.org?subject=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:
>> <http://groups-beta.google.com/group/news.admin.net-abuse.email/browse_frm/thread/fbb5ea0269b1fada/fdd399a8b869aa77#fdd399a8b869aa77> 
>>
>
>
> 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:

>> <http://www.shaftek.org/publications/drafts/abuse-report/draft-shafranovich-abuse-report-00.html>
>> 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.