ietf-asrg
[Top] [All Lists]

Re: [Asrg] 3. Requirements Document

2003-09-24 13:00:45
Kee Hinckley wrote:

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.


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

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?


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.

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.



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



_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg