J.D. Falk wrote:
Danny Angus wrote:
I tried some time ago to articulate some tests which any proposal ought
to at least acknowledge, which you can find here..
http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html
That paper thickens the ranks of anti-anti-spam trenches. It is good
as it avoids an excess of proposal that would possibly result in a
waste of time for evaluating proposed techniques that don't come quite
close to the point. However, I think an it could, and should, go
beyond that. For example, why is it not in the scope of that document
"to attempt to distinguish or justify any more detailed definition of
[the term spam]"? [1.1.1]
The given definition is subjective and should be amended. Recipients'
fickle wishes won't lead to a reliable transport. The second
definition is better, although it leaves the _necessity of transport_
undefined. You don't have to query recipients to know that a sender is
going to abuse the mail system. The definition of spam can be worded
in terms of the senders: where do they get recipients' addresses from,
and how well they comply with existing privacy laws, including
opt-in/out issues.
Nicely done; I think this could be the start of a very useful document.
Any interest in starting up work on it again?
Hey, that implies interest in finding new anti-spam techniques! Good,
but I think the assumption "that there will be early adopters" [2.3.9]
might be misunderstood as an overpromising statement.
First steps could be:
- update terminology to match draft-crocker-email-arch
As it is transport-centric, just updating 2821->5321 might suffice...
- include some examples taken from other RFCs, both successful and non-
Absolutely agreed.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg