Subject: Re: [Asrg] 3. Requirements Document

From: Kee Hinckley <[email-masked]>
Date: Tue, 23 Sep 2003 16:04:47 -0400

http://www.irtf.org/asrg/draft-irtf-asrg-requirements-xx-01.txt

Looking over the (as-yet-undefined) definitions I see that there is a 
1.3.31 for "Sender" but I don't see anything that would distinguish 
between the originator of the message and the organization handling 
the delivery.  This is important because the two roles may be 
separate, in which case the best practices for each will be somewhat 
different.

>2.7  Highly Effective
>
>  The proposal MUST provide an effective solution as determined
>  by the [TBD] algorithm.  That blocks all appropriate messaging.
>
>2.7.1     Rationale:
>
>  Although proposals may differ in approach all proposals will be
>  evaluated using an appropriate application of the [TBD]
>  algorithm or one of its derivatives.  The [TBD] algorithm
>  provides a standard and objective measure for evaluation of the
>  approach.

I don't think I agree with this.  In particular, a set of orthogonal 
small changes might as a whole be more likely to be implemented, and 
more effective, than any single change.  Are we saying that small 
incremental changes are ruled out simply because they are only 
partially effective?  What happened to the idea of driving spammers 
into a corner?

2.8 (Persistently Effective) might also want to be clarified.  I 
agree that the solution needs to be persistent, but in the sense that 
although spammers may find ways to avoid the measure, the measure 
itself cannot be be trivially defeated.  Again, the idea is to paint 
spammers into a corner.  If a particular technique can be avoided, 
but only by exposing spammers in some other useful way, then I would 
deem it to be persistently effective.

>2.10 Single Solution
>
>  The proposal SHOULD provide a comprehensive solution that
>  impacts the greatest number of problems caused by [spam], and
>  usable or accessible by the greatest number of MTS users.
>
>2.10.1    Rationale:
>
>  A single solution that will work for all people is the optimum
>  solution, designers should strongly consider methodologies or
>  approaches that impact the largest number of MTS users.  A
>  solution that is optimal will also impact all of the problems
>  associated with [spam], such as [list of problem terms].

Again, this seems wrong to me.  This isn't a technical problem that 
you solve, it is a battle in which you need to contain the adversary. 
I think a search for a single overriding solution runs the serious 
risk of missing smaller steps which are far more likely to be adopted 
and, in aggregate, more effective.

-- 
Kee Hinckley
http://www.messagefire.com/         Next Generation Spam Defense
http://commons.somewhere.com/buzz/  Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 24 Sep 2003 15:58:19 -0400

Kee Hinckley wrote:

> between the originator of the message and the organization handling the 
> delivery.  This is important because the two roles may be separate, in 
> which case the best practices for each will be somewhat different.
> 

Hmm, that's a good point. I think we should make it clear that the 
"Sender" and "Receiver" of the email refer to the human beings or 
software agents which originally sent the email, not the MUA or MTA that 
was used. If that is true then what does "Message Originator" refer to?

In general, we need to look over the definitions and decide which are 
relevant and which are not, and make clear the distinctions between 
different aspects. We might also need another section in this document 
which outlines the mail delivery model and plugs in all of the 
definitions, so the reader of the document can readily see the 
definitions "in action".

> incremental changes are ruled out simply because they are only partially 
> effective?  What happened to the idea of driving spammers into a corner?
> 

This has been mentioned before on the list (gmane.org is down so I can't 
find the article). We need to change or take out this requirement. 
HOWEVER, it would be very useful to provide another requirement on how a 
proposal fits within the consent framework (or any other framework) so 
we can see how it works in combination with other systems. We need 
proposal authors to outline how their solutions would work in 
combination with other systems.

> 2.8 (Persistently Effective) might also want to be clarified.  I agree 
> that the solution needs to be persistent, but in the sense that although 
> spammers may find ways to avoid the measure, the measure itself cannot 
> be be trivially defeated.  Again, the idea is to paint spammers into a 
> corner.  If a particular technique can be avoided, but only by exposing 
> spammers in some other useful way, then I would deem it to be 
> persistently effective.
> 

Agreed.

> Again, this seems wrong to me.  This isn't a technical problem that you 
> solve, it is a battle in which you need to contain the adversary. I 
> think a search for a single overriding solution runs the serious risk of 
> missing smaller steps which are far more likely to be adopted and, in 
> aggregate, more effective.
> 
> 

This has been mentioned before on the list, and needs to be removed. See 
this list message from Paul:

https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg06657.html

BTW, more people are needed to work on this, can the volunteers step 
forward?

Yakov