ietf-asrg
[Top] [All Lists]

Re: [Asrg] Two ways to look at spam

2003-07-02 12:13:12
"Jon Kyme" <jrk(_at_)merseymail(_dot_)com> writes:



You might say something more like
positive_test(name_of_engine_1, engineargs, message) => noconsent 
positive_test(name_of_engine_2, engineargs, message) => consent 
etc...

I guess someone could standardise this (using whatever language they
wanted), and there are some kinds of content filter (probably quite
simple things---the sort of thing that SIEVE can do, say) that we
could standardise on.  That might be useful.

Well no, this isn't really the kind of thing that sieve
( http://www.cyrusoft.com/sieve/ ) is for - as I understand it.

No, but I can imagine standardising things like "the email contains
the string 'mortgage'".



It's clarly possible to *implement* a particular engine as a sieve
"filter". I'm really thinking of a higher level (general) description.
While any component might be implemented in any way you care to imagine,
what we're actually short of is a framework in which various components
might interoperate and complement each other.
 
[...]

No - it isn't THE "Solution to Spam". However, you can plug A "solution
to
spam" right into it.

positive_test(foolproof_spam_detector, engineargs, message) 
        => noconsent

Well, perhaps.  I think such a perfect spam detector is impossible,
for useful definitions of spam.  


So I think the best way to attack spam is to make sending email
expensive (in some way---this may involve computational cost rather
than some kind of financial framework) such that anybody sending me
email thinks a bit first (and so it won't be worthwhile sending to
large numbers of people).  So this would be attacking the volume part
of usual definitions of spam.


Various kind of "proof-of-work" schemes have been discussed by this group
(check the archive) and in other places.

That could fit into a consent framework, of course: I could say how
expensive I want it to be for strangers to contact me (specified in
whatever terms are appropriate), and that would be automatically
enforceable.


The point of a general framework is that *anything* will fit into it.

This should really be on the consent thread...




--

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