Subject: Re: [feedback-report] So...
From: Douglas Otis <[email-masked]>
To: Yakov Shafranovich <[email-masked]>
Cc: [email-masked]
Date: Wed, 20 Jul 2005 17:17:44 -0700
List-Id: Public forum for discussion on the feedback-report draft <abuse-feedback-report.mipassoc.org>

On Jul 20, 2005, at 4:30 PM, Yakov Shafranovich wrote:

> J.D. Falk wrote:
>
>> ...either the list is entirely broken except for me, or nobody  
>> cares about the additional use cases that have been proposed.  Right?
>>
>
> I am aware of the email traffic, just haven't had a chance to reply as
> of yet. Give me a few days or so to finish up stuff from my wedding.
>
>
>> How's the testing going?
>>
>
> I am wondering the same.

I was hoping to find out more about the Thunderbird plug-in for  
creating the reports.

-Doug

Date: Wed, 20 Jul 2005 19:30:07 -0400
From: Yakov Shafranovich <[email-masked]>
Organization: SolidMatrix Technologies, Inc.
To: "J.D. Falk" <[email-masked]>, [email-masked]
Subject: Re: [feedback-report] So...
Cc: 

J.D. Falk wrote:
> ...either the list is entirely broken except for me, or nobody cares 
> about the additional use cases that have been proposed.  Right?
> 

I am aware of the email traffic, just haven't had a chance to reply as
of yet. Give me a few days or so to finish up stuff from my wedding.

> How's the testing going?
> 

I am wondering the same.

Yakov

Date: Wed, 20 Jul 2005 15:45:15 -0700
From: "J.D. Falk" <[email-masked]>
Organization: Yahoo!
To: [email-masked]
Subject: [feedback-report] So...

This is a multi-part message in MIME format.
--------------040701080406040103070500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

...either the list is entirely broken except for me, or nobody cares 
about the additional use cases that have been proposed.  Right?

How's the testing going?

-- 
J.D. Falk, Anti-spam Product Manager, Yahoo! Mail
[email-masked]

--------------040701080406040103070500
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">
<font face="Garamond">...either the list is entirely broken except for
me, or nobody cares about the additional use cases that have been
proposed.&nbsp; Right?<br>
<br>
How's the testing going?<br>
</font>
<pre class="moz-signature" cols="72">-- 
J.D. Falk, Anti-spam Product Manager, Yahoo! Mail
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
</pre>
</body>
</html>

--------------040701080406040103070500--

Date: Fri, 15 Jul 2005 11:41:02 -0700
From: "J.D. Falk" <[email-masked]>
Organization: Yahoo!
To: [email-masked]
Subject: [feedback-report] [Fwd: FW: Evidence Use Case]

This is a multi-part message in MIME format.
--------------030005080102070501070803
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Can someone please figure out why the list isn't accepting posts from 
new subscribers?

-------- Original Message --------
Subject: 	FW: Evidence Use Case
Date: 	Fri, 15 Jul 2005 16:25:06 +1000
From: 	David Jones <[email-masked]>
To: 	<[email-masked]>

JD,

I am in a similar situation to Vipul in that I could not submit to the
abuse-feedback-report. I initially sent the note below on Jun 23 -
retried a few times without joy.

For a previous submission I sent to Yakov but I think he is currently
away in newly-wed bliss. Could you please do the delivery.

Thanks and regards
David

> 
> ----- Forwarded message from "[email-masked]" 
> <[email-masked]> -----
>     Date: Thu, 23 Jun 2005 23:56:38 +1000
>     From: "[email-masked]" <[email-masked]>
> Reply-To: "[email-masked]" <[email-masked]>
>  Subject: Evidence Use Case
>       To: "[email-masked]" 
> <[email-masked]>
> 
> 
> At the risk of triggering grumpiness, I'd like to confirm my 
> comments/questions at MAAWG :)
> 
> 1. A use case exists for using reports in 
> evidentiary/enforcement processes.
> 
> 2. To support this, no material change is required but the 
> following is requested:
> a) I'd actively support the open issue of adding an optional 
> 'munged' indicator.
> Its understood that header and body munging is common for 
> privacy. From my experience, enforcement processes will 
> accept both munged and unmunged data as long as they: (i) get 
> enough unmunged evidence (ii) know which submission are 
> unmunged and of appropriate evidentiary grade.
> b) An optional indicator for human entered content (either 
> structured or free-text). 
> Arrgh you say! We know that any free-form text is usually of 
> zero value in feedback but anecdotal additions may add value 
> later in investigative stages of enforcement.
> 
> 3. Implementers should accept signed feedback reports. 
> (probably outside the scope but just mentioning for implementors).
> 
> I think/hope this Use Case does not undermine the "Simplicity 
> Encourages Adoption" but could add some real value outside 
> normal ISP feedback processes.
> 
> thanks
> David
> 
> 
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
> 
> ----- End forwarded message -----
> 
> 
> 
> 
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
> 
> 
> 
> 

-- 
J.D. Falk, Anti-spam Product Manager, Yahoo! Mail
[email-masked]

--------------030005080102070501070803
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000066">
Can someone please figure out why the list isn't accepting posts from
new subscribers?<br>
<br>
-------- Original Message --------
<table border="0" cellpadding="0" cellspacing="0">
  <tbody>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Subject: </th>
      <td>FW: Evidence Use Case</td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Date: </th>
      <td>Fri, 15 Jul 2005 16:25:06 +1000</td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">From: </th>
      <td>David Jones <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a></td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">To: </th>
      <td><a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a></td>
    </tr>
  </tbody>
</table>
<br>
<br>
<pre>JD,

I am in a similar situation to Vipul in that I could not submit to the
abuse-feedback-report. I initially sent the note below on Jun 23 -
retried a few times without joy.

For a previous submission I sent to Yakov but I think he is currently
away in newly-wed bliss. Could you please do the delivery.

Thanks and regards
David

&gt; 
&gt; ----- Forwarded message from <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">"[email-masked]"</a> 
&gt; <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> -----
&gt;     Date: Thu, 23 Jun 2005 23:56:38 +1000
&gt;     From: <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">"[email-masked]"</a> <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
&gt; Reply-To: <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">"[email-masked]"</a> <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
&gt;  Subject: Evidence Use Case
&gt;       To: <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">"[email-masked]"</a> 
&gt; <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
&gt; 
&gt; 
&gt; At the risk of triggering grumpiness, I'd like to confirm my 
&gt; comments/questions at MAAWG :)
&gt; 
&gt; 1. A use case exists for using reports in 
&gt; evidentiary/enforcement processes.
&gt; 
&gt; 2. To support this, no material change is required but the 
&gt; following is requested:
&gt; a) I'd actively support the open issue of adding an optional 
&gt; 'munged' indicator.
&gt; Its understood that header and body munging is common for 
&gt; privacy. From my experience, enforcement processes will 
&gt; accept both munged and unmunged data as long as they: (i) get 
&gt; enough unmunged evidence (ii) know which submission are 
&gt; unmunged and of appropriate evidentiary grade.
&gt; b) An optional indicator for human entered content (either 
&gt; structured or free-text). 
&gt; Arrgh you say! We know that any free-form text is usually of 
&gt; zero value in feedback but anecdotal additions may add value 
&gt; later in investigative stages of enforcement.
&gt; 
&gt; 3. Implementers should accept signed feedback reports. 
&gt; (probably outside the scope but just mentioning for implementors).
&gt; 
&gt; I think/hope this Use Case does not undermine the "Simplicity 
&gt; Encourages Adoption" but could add some real value outside 
&gt; normal ISP feedback processes.
&gt; 
&gt; thanks
&gt; David
&gt; 
&gt; 
&gt; -------------------------------------------------
&gt; This mail sent through IMP: <a class="moz-txt-link-freetext" href="http://horde.org/imp/">http://horde.org/imp/</a>
&gt; 
&gt; ----- End forwarded message -----
&gt; 
&gt; 
&gt; 
&gt; 
&gt; -------------------------------------------------
&gt; This mail sent through IMP: <a class="moz-txt-link-freetext" href="http://horde.org/imp/">http://horde.org/imp/</a>
&gt; 
&gt; 
&gt; 
&gt; 

</pre>
<br>
<pre class="moz-signature" cols="72">-- 
J.D. Falk, Anti-spam Product Manager, Yahoo! Mail
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
</pre>
</body>
</html>

--------------030005080102070501070803--

Date: Thu, 14 Jul 2005 20:19:21 +0200
From: David <[email-masked]>
Organization: On-Line Services 2000, S.L.
To: [email-masked]
Subject: [feedback-report] expanding the specification

Hi !!

I just read this draft, it looks great but it's too focused on email.
It will be very nice to also use this format for other abuse types
(port scans, virus attacks, email dictionary attacs, DoS attacks, etc
...). Altough the proposal talks about other kinds of abuse it's too
binded to email abuse, i.e. section 3 'Requirements' requires a copy of
the original email but there are other kind of abuse (i.e. port scans) 
that have no email to send. There are many other sections that make this
draft incompatible to be used on other kind of abuses, and it will
be really nice that it could accomodate other kind of incident reports
from the begining.

I know it's difficult to make very general standards, they often do not
produce anything useful, but it's also bad to restrict standars from the
begining. Rfc's take a long time to publish and having a RFC that
extends/obsoletes this one will take many years.

The difference between "obsoletes" and "extends" is important. 
"Extends" can be done with incremental changes, using additional
specifications.  Therefore the base specification does not need to be
changed, but that specification would need to be changed to accomodate
other no email related incidents.

Minor changes like replacing

'A copy of the original email message (body and headers) or the message
headers must be enclosed'

by

'A copy of the original email message (body and headers) or the message
headers MUST be enclosed if the incident to report was originated by the
recepction on an email message'

would allow easy extension in the future.

It would also be useful to add an optional field for the datetime (in
a normalized format) when the message/incident was received so used in
conjuntion with Source-IP could allow ISP's to identify dinamic ip
user's without having to examine the message headers or when no message
has been attached.

-- 
Thanx & best regards ...

----------------------------------------------------------------
    David Saez Padros                http://www.ols.es
    On-Line Services 2000 S.L.       e-mail  [email-masked]
    Pintor Vayreda 1                 telf    +34 902 50 29 75
    08184 Palau-Solita i Plegamans   movil   +34 670 35 27 53
----------------------------------------------------------------

Date: Tue, 05 Jul 2005 12:24:11 -0700
From: "J.D. Falk" <[email-masked]>
Organization: Yahoo!
To: [email-masked]
Subject: [feedback-report] [Fwd: ARF feedback.]

This is a multi-part message in MIME format.
--------------070107010107050303080309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Forwarding by request.

-------- Original Message --------
Subject: 	ARF feedback.
Date: 	Sat, 2 Jul 2005 14:41:08 -0700
From: 	Vipul Ved Prakash <[email-masked]>
To: 	<[email-masked]>

JD,

Somehow still can't get to ARF list, so I am sending feedback directly
to you. These points are based my experience with Razor/SpamNet that
supports submission of messages to us: 

"Message-Truncated" header

    There will be instance when the message to be reported is
    too big and the client is not willing to report the entire
    message. It could be argued that the recipient does not want
    to get multiple 5Mb reports for large spam/worm emails. A
    new header could be used to indicate that the message was
    truncated at a particular length. For instance, a reporting
    agent could be programmed with a max limit, say 64Kb and for
    messages that exceed 64Kb, it would add a header:

            Message-Truncated: 65535

    and truncate the message at 65535 bytes. This could be an
    optional header.

Formats other than RFC822

    I pointed this out in the BOF at INBOX, and I don't want to
    belabor this point, but I think it is important to support
    formats other than RFC822. Outlook, for instance, provides
    the message through MAPI in form of multiple "buckets". In
    many cases, a single MIME part is presented as multiple
    buckets (HTML version, text version, etc), and re-creation
    of original RFC822 is mostly impossible. I understand that
    Outlook support is not the primary focus at this stage, but
    there should be a provision in the spec to include outliers
    like Outlook. For Outlook this could be done through a MIME
    header like message/outlook, that comprises of multiple
    message/outlookbuckets.

    Other clients like Eudora and mail.app also modify the
    original message, but they retain the RFC822 format. For
    these the UserAgent hint is sufficient to indicate that the
    reported message is different from the original one.

Supressing Headers

    Razor and Cloudmark clients support an option to supress
    headers and only report the message. I think this is an
    important privacy option, since headers can contain internal
    routing information that might be considered private by some
    organizations. Header suppression could also be support by a
    MIME header like message/rfc822-noheaders.

Cheers,
Vipul

-- 
J.D. Falk, Anti-spam Product Manager, Yahoo! Mail
[email-masked]

--------------070107010107050303080309
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000066">
<font face="Garamond">Forwarding by request.</font><br>
<br>
-------- Original Message --------
<table border="0" cellpadding="0" cellspacing="0">
  <tbody>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Subject: </th>
      <td>ARF feedback.</td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Date: </th>
      <td>Sat, 2 Jul 2005 14:41:08 -0700</td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">From: </th>
      <td>Vipul Ved Prakash <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a></td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">To: </th>
      <td><a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a></td>
    </tr>
  </tbody>
</table>
<br>
<br>
<pre>JD,

Somehow still can't get to ARF list, so I am sending feedback directly
to you. These points are based my experience with Razor/SpamNet that
supports submission of messages to us: 

"Message-Truncated" header

    There will be instance when the message to be reported is
    too big and the client is not willing to report the entire
    message. It could be argued that the recipient does not want
    to get multiple 5Mb reports for large spam/worm emails. A
    new header could be used to indicate that the message was
    truncated at a particular length. For instance, a reporting
    agent could be programmed with a max limit, say 64Kb and for
    messages that exceed 64Kb, it would add a header:

            Message-Truncated: 65535

    and truncate the message at 65535 bytes. This could be an
    optional header.

Formats other than RFC822

    I pointed this out in the BOF at INBOX, and I don't want to
    belabor this point, but I think it is important to support
    formats other than RFC822. Outlook, for instance, provides
    the message through MAPI in form of multiple "buckets". In
    many cases, a single MIME part is presented as multiple
    buckets (HTML version, text version, etc), and re-creation
    of original RFC822 is mostly impossible. I understand that
    Outlook support is not the primary focus at this stage, but
    there should be a provision in the spec to include outliers
    like Outlook. For Outlook this could be done through a MIME
    header like message/outlook, that comprises of multiple
    message/outlookbuckets.

    Other clients like Eudora and mail.app also modify the
    original message, but they retain the RFC822 format. For
    these the UserAgent hint is sufficient to indicate that the
    reported message is different from the original one.

Supressing Headers

    Razor and Cloudmark clients support an option to supress
    headers and only report the message. I think this is an
    important privacy option, since headers can contain internal
    routing information that might be considered private by some
    organizations. Header suppression could also be support by a
    MIME header like message/rfc822-noheaders.

Cheers,
Vipul

</pre>
<br>
<pre class="moz-signature" cols="72">-- 
J.D. Falk, Anti-spam Product Manager, Yahoo! Mail
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
</pre>
</body>
</html>

--------------070107010107050303080309--