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

[Yakov Shafranovich]

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