Subject: Re: [feedback-report] misc comments (on draft-shafranovich-feedback-report-00(pre I-D))
From: Yakov Shafranovich <[email-masked]>
To: Matthew Elvey <[email-masked]>, [email-masked]
Date: Fri, 29 Apr 2005 18:41:48 -0400
List-Id: Public forum for discussion on the feedback-report draft <abuse-feedback-report.mipassoc.org>

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.

> 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.

> 
> =-=-=
> 
> Oh, and Yakov, you may post anything from our private email on this 
> topic. (Please post what you will or may I?) Thrilled to hear that J is 
> on board.
> 

Please go ahead.

Yakov

P.S. I am currently working on the -01 draft, I will post a list of 
planned changes over the weekend or early next week for feedback.

Date: Fri, 29 Apr 2005 14:58:13 -0700
From: Matthew Elvey <[email-masked]>
To: [email-masked]
Subject: [feedback-report] misc comments (on draft-shafranovich-feedback-report-00(pre I-D))

Is this intended to obsolete RFCs 1982 or 3462?

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)

=-=-=
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?
=-=-=
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.
=-=-=
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.

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> 

=-=-=

Oh, and Yakov, you may post anything from our private email on this 
topic. (Please post what you will or may I?) Thrilled to hear that J is 
on board.