[feedback-report] New Draft "01-pre1"

[Matthew Elvey]

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.