Subject: Re: [Asrg] Two ways to look at spam

From: "Jon Kyme" <[email-masked]>
Date: Wed, 02 Jul 2003 13:22:02 +0100

> >From the point of view of effectiveness on spam control, it's probably
> worth distinguishing two classes of features that might appear in such
> consent declarations.  
> 
> There are the relatively easy things: whether I accept HTML
> attachements, size of email, etc.  In general, those things which can
> be checked (and therefore enforced) automatically.  
> 
> Then there are the things that (alas) don't seem to be automatically
> enforceable: for example that I won't accept any commercial email,
> that I won't accept any commercial email except about getting larger,
> firmer mortgages for septic tanks.
> 
> The former would be useful, but I'm doubtful that it would have much
> of an impact on spam.  The latter seems to me to rely on the sender
> accurately tagging their messages according to content---possibly that
> would happen often enough that it would be worthwhile, but I'm not
> sure that it would.

I'm not sure about this, there seems to me (at the most general) to be
only one class of things that need be asserted in a consent expression: How
this message is classified by some engine. Your second class seems to me to
be the sort of thing that's routinely handled by content-filters
(imperfectly, I grant you).

So rather than saying:
1. message has html => noconsent
2. message mentions 'septic tank enhancement' => consent
3. message is from grandma => consent
4. message has valid consent token => consent
5. message has blacklisted source IP => noconsent
etc ...

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

So your consent expression is a bunch of assertions which can be
evaluated at a policy-enforcement-agent if it has access to the
classification engines you specify.
Might be something like:

positive_test("spamassassin-like-engine",
              "version>2.50"
              "com.connectisl.myusername.ruleset", 
              "level>5.0",
              message)  => noconsent

positive_test("recipient_whitelist",
              "[email-masked]", 
              message)  => consent

Are consent expressions only a means of carrying information from a
recipient-entity to a policy-enforcement-entity? Or are they for publishing
a statement to the world at large?

Are sending systems (paid for by the sender) likely to do
policy-enforcement for a remote recipient? Intermediate systems? Would a
global expression still have utility even if not acted on globally (as a
record of the recipients policy)?

Also, does a consent expression creator need means of determining
capabilities of the enforcement-agent that's the target of the
consent-expression?

--

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Dave Aronson <[email-masked]>
Date: Wed, 2 Jul 2003 09:01:07 -0400

"Jon Kyme" <[email-masked]> wrote:

 > recipient-entity to a policy-enforcement-entity? Or are they for
 > publishing a statement to the world at large?

IMHO primarily the former, and almost certainly that will be developed 
before the latter.

The latter need very careful consideration, as it could tip your hand to 
a spammer re how to spoof his way onto your whitelist.  Maybe if only 
NO-consent rules are published?

 > policy-enforcement for a remote recipient?

Methinks not.  Too much complexity added for too little benefit.  Heck, 
we have a hard enough time getting people not to post in HTML, even on 
some lists of intelligent and clueful people.

 > Would a global expression still have utility even if not acted on
 > globally (as a record of the recipients policy)?

It could deflate claims of "we send this only to people we really think 
will be interested in it".  Other than that, I see no use.

 > capabilities of the enforcement-agent that's the target of the

Absolutely.  He needs to know what's possible, lest he waste his time 
writing rules that won't be enforced (not that that stops legislators).  
Furthermore, he may need to know details of just how to state it, such 
as the syntax for a boolean match.

-- 
David J. Aronson, Unemployed Software Engineer in the Washington DC area
See http://destined.to/program/ for online resume and other information.

---

From: Bruce Stephens <[email-masked]>
Date: Wed, 02 Jul 2003 15:53:12 +0100

"Jon Kyme" <[email-masked]> writes:

[...]

> positive_test(name_of_engine_2, engineargs, message) => consent 

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.

It's not a solution to spam, though, because some things really are
things that can't be checked automatically, so the content filtering
will be imperfect.  And (if it were to be standardised) we can expect
it to become more and more imperfect.

[...]

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 02 Jul 2003 16:26:11 +0100

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

Indeed, somebody could standardise this - if somebody wanted to make it
simple for MUA to talk to policy enforcement agents. 

> it to become more and more imperfect.

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

It's one way of looking at part of a consent framework.

--

---

From: Bruce Stephens <[email-masked]>
Date: Wed, 02 Jul 2003 17:33:52 +0100

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

[...]

> positive_test(foolproof_spam_detector, engineargs, message) 

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

If a person unknown to me can send me an email that I want to receive
(and I want them to be able to), then that person can send me unwanted
email (and I don't want them to be able to do that, but I see no way
to stop it without also preventing the possibility of wanted email).

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.

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.

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 02 Jul 2003 20:11:00 +0100

> No, but I can imagine standardising things like "the email contains

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

> whatever terms are appropriate), and that would be automatically

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

This should really be on the consent thread...

--

---

From: Walter Dnes <[email-masked]>
Date: Fri, 4 Jul 2003 18:49:54 -0400

On Wed, Jul 02, 2003 at 05:33:52PM +0100, Bruce Stephens wrote

> to stop it without also preventing the possibility of wanted email).

  You've hit the nail on the head there.  This has given me an
inspiration that'll appear as a long message in a day or so.

> of usual definitions of spam.

  A few problems...

  1) I don't throw away a pefectly good computer and buy the
latest/greatest every year.  This email is coming from a 433 mhz machine
with 128 megs of RAM.  How do I compare with someone who's just bought a
512 meg machine that runs at 3 gigahertz ?

  2) A beowolf cluster of cast-off 1 gigahertz machines will blow the
"computational cost" to smithereens.

-- 
Walter Dnes <[email-masked]>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did

---

From: Bruce Stephens <[email-masked]>
Date: Sat, 05 Jul 2003 01:25:02 +0100

[...]

>> large numbers of people).  So this would be attacking the volume
>> part of usual definitions of spam.
>
>   A few problems...
>
> latest/greatest every year.  This email is coming from a 433 mhz
> machine with 128 megs of RAM.  How do I compare with someone who's
> just bought a 512 meg machine that runs at 3 gigahertz ?

Well, the 3GHz one is presumably about 1 order of magnitude faster
(give or take).  So if the usual cost of sending an email is 1 second
on a 3GHz CPU, then it might take 10 seconds on your slower one (or,
the 3GHz machine can send 10 times as many emails in the same time).

For *really* slow machines (such as mobile phones), I imagine the ISP
could charge per email, and provide the CPU power.  Something like that.

> "computational cost" to smithereens.

Yes, that's a real possibility.  It's still adding to the cost,
however: running clusters of cheap PCs is only relatively cheap, it'll
still take some running.

A more likely attack would be to include hashcash calculating code in
screensavers, Javascript on web pages, worms, etc., so you use the
zillions of PCs that other people are maintaining.

[...]