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