Kee, Yakov and List participants:
The latest draft of the Requirements may be accessed at:
http://www.infobro.com/anon-FTP/infoSource/IRTF/ASRG/draft-irtf-asrg-require
ments-xx-05.txt
more below...
Original Message:
-----------------
From: Yakov Shafranovich research(_at_)solidmatrix(_dot_)com
Date: Wed, 24 Sep 2003 15:58:19 -0400
To: nazgul(_at_)somewhere(_dot_)com, asrg(_at_)ietf(_dot_)org,
eric(_at_)infobro(_dot_)com
Subject: Re: [Asrg] 3. Requirements Document
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".
EW> There is a model presented and the points Kee raises are valid. I feel
that the distinctions that are raised may be relevant to a discussion of
delivery methods (these types of disctions were revised in a later draft,
which I will forward now) and origination agent (MUA) and "Sender" are
presented as distinct definitions.
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.
EDW> Again the later (-05) draft attempts to address these concerns. I
will forward that to you, Kee and the list so you can mull it over.
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.
EDW> Agreed. See -05 draft.
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
EDW> This as well was changed in a later draft. Unfortunately, these
subsequent drafts were being discussed off-list. The document which I
forward may be a closer fit to the ideals of the list at present.
BTW, more people are needed to work on this, can the volunteers step
forward?
EDW> Indeed.
-e
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .
draft-irtf-asrg-requirements-xx-05.txt
Description: draft-irtf-asrg-requirements-xx-05.txt