Subject: [Asrg] requirements for a proposed solution + notion of consent

From: Balachander Krishnamurthy <[email-masked]>
Date: Fri, 07 Mar 2003 10:37:56 -0500

keith moore suggests the following criteria for potential solutions in
   https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00726.html

- should minimize spam to some acceptable level (say, 0.1% of received messages)
- should not prevent delivery of legitimate mail
- should not adversely impact valuable functionality
- should be easy to use (even for grandma)
- should be easy to deploy, incrementally
- should not depend on universal deployment to be effective
- should provide incentives to deploy for those doing the deployment

all of the above are laudable goals. i would like to add a few more

- senders and receivers of wanted (i prefer the term wanted over "legitimate")
  mail should not have to pay additional monetary costs 
   ("sender pays" scheme causes additional pain for people who send/receive
    wanted mail - it would penalize "good folks" because "bad folks" send spam)

- no new protocol should be required to implement such solutions (maybe this is
   covered in 'easy to deploy')

- there should be no additional impact on privacy of participants as a result 
  of such solutions

also, the notion of consent in the original writeup seems to take for granted
that participants have to consent a priori. it would be interesting to consider
a scheme where the sender takes a very modest risk ('liability') which is lifted
when the receiver deems the mail as wanted. the consent is given by the receiver
after the mail is received. the receiver gets to decide if mail is "spam".

cheers,
bala

balachander krishnamurthy
http://www.research.att.com/~bala/papers
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Keith Moore <[email-masked]>
Date: Fri, 7 Mar 2003 12:25:37 -0500

On Fri, 07 Mar 2003 10:37:56 -0500
Balachander Krishnamurthy <[email-masked]> wrote:

> - should minimize spam to some acceptable level (say, 0.1% of received
> messages)- should not prevent delivery of legitimate mail
> - senders and receivers of wanted (i prefer the term wanted over
> "legitimate") mail should not have to pay additional monetary costs 

I agree, but I'd say this differently - I'd say we don't want to raise the
burden of sending email (for the purpose of deterring spam) so high that it
deters  people from sending mail we want to receive.  this applies to monetary
costs, having to reply to confirmation messages, having to get prior
authorization, whatever.

> - no new protocol should be required to implement such solutions (maybe this
> is covered in 'easy to deploy')

I think it's premature to say that.  Replacing the existing mail system would
probably be too onerous.  But some new protocol, somewhere, might be required.
This would not bother me if it could be incrementally deployed, if there were
natural incentives to deploy it, etc.

> - there should be no additional impact on privacy of participants as a
> result of such solutions

a laudable goal, I think.

Keith

---

From: Adam Back <[email-masked]>
Date: Fri, 7 Mar 2003 19:25:48 +0000

Those requirements sound good to me, it may not be possible to satisfy
them all simultaneously but at least they express the problem so
people can measure solutions against them.  I've numbered them, let's
measure a few of the current proposals against these:

a) should minimize spam to some acceptable level
b) should not prevent delivery of legitimate mail
c) should not adversely impact valuable functionality
d) should be easy to use (even for grandma)
e) should be easy to deploy, incrementally
f) should not depend on universal deployment to be effective
g) should provide incentives to deploy for those doing the deployment
h) senders and receivers should not have to pay additional monetary costs 
i) should not require new protocols
j) there should be no additional impact on privacy

(this presumes the solution is universally deployed for the sake of
argument; deployability and chances of getting there are covered by 6,
7 and 9).

1) RMX plus fixed DNS

b,d,h,j

I think the rest it does not do.  To explain a) I suspect there will
still be lots of spam from AUP violations, and spammers who run their
own RMX servers; c) complicates sending while travelling; e) if you
deploy it incrementally you lose mail; f) can't reasonably be turned
on until fully deployed; g) provides no incentive to deploy until
critical mass is reached as you can't turn it on; i) it requires
depoyment of new protocols.

2) Bayesian filters + hashcash + token white lists.

a,b,c,d,e,f,g,h,j

About things it does not do: i) it requires deployment of extensions
to existing protocols

Some of the things it claims to do are not as effective as other
solutions: a) it will reduce spam, but it won't stop it because it
just increases the cost from 0.0001c to say 1c -- this may help
because it may become more targetted; b) bayesian filters have a small
but not zero false positive rate; f) before universal deployment you
are relying on bayesian filters, and hashcash is just to avoid false
positives; g) your incentive to deploy is to avoid mail you send being
caught in false positives; h) individuals would have only CPU costs,
which they probably already have sufficient spare resources for, some
large organizations if they add tokens at the outgoing mail hub may
have to upgrade hardware; 

Also about this approach: it's not clear how long Bayesian filters
will hold-out -- they are effective now because of limited deployment,
I suspect if deployment got to a high enough spammers might go the
next level and win that arms race.

I welcome any criticism of the ratings of either of these, and
suggested ratings for other proposals.

Adam

---

From: Troy Rollo <[email-masked]>
Date: Sat, 08 Mar 2003 08:11:07 +1100

>    covered in 'easy to deploy')

I would qualify - no substitute protocol should be required. A new protocol 
that acts as an auxiliary mechanism can be as easy to deploy as anything else.

--
Troy Rollo				Chairman, CAUBE.AU
[email-masked]			Executive Director, iCAUCE

---

From: Nate W <[email-masked]>
Date: Fri, 7 Mar 2003 13:41:03 -0800 (PST)

> a) should minimize spam to some acceptable level

May I suggest splitting that into two criteria?

1) should reduce the network bandwidth consumed by spam (including related
transmissions such as bounce messages)

2) should reduce the number of unwanted messages presented to the end user

-- 

Nate Waddoups
Redmond WA USA
http://www.natew.com

---

From: Keith Moore <[email-masked]>
Date: Fri, 7 Mar 2003 18:32:07 -0500

> 2) should reduce the number of unwanted messages presented to the end user

yes, I think it's useful to make that distinction.

Keith

---

From: wayne <[email-masked]>
Date: 09 Mar 2003 11:49:34 -0600

> a) should minimize spam to some acceptable level

I think it is a mistake to only consider proposals that reduce spam to
"some acceptable level".

For example, the proposal to have MTAs give a temporary delivery
failure status the first time it recently has seen a sender-recipient
pair may only reduce spam by 20%, but I think that is still useful.

If you find 5 independent tests that each reduce the spam by 20%, when
combined you will have reduced spam by 99.968%.  Granted that most
spam tests will not be independent, so in practice you will have to
find a lot more than 5 such testes to get that level of spam
filtering, but the point is that every little bit *DOES* help.

I like the spamassassin approach that uses many different techniques
to check for spam.  Each test may only filter a small amount of spam,
and some things like their checking for forged email from
AOL/Hotmail/etc and DNS blacklists can give false positives on that
particular test, but over all, it does an excellent job of filtering
spam.  SpamAssassin is far from a perfect filter, there are lots of
things it still does wrong, or could do a lot better, but SpamAssassin
is the most effective tool I've found.

Bayesian filters work in a similar manor.  Each word may not be a
reliable test of spam/ham, but when combined with the results from
many other words, the overall is effect is quite good.

For what it is worth, I would say that SpamAssassin would rate as
follows:

a, b, c, e, f, g, i, j

It currently fails 'd) should be easy to use' if the ISP doesn't do
the installation and also provide a nice front end to do
blacklisting/whitelisting.  (SpamAssassin's automatic
blacklists/whitelists are good, but sometimes you need explicit
control.)

SpamAssassin also requires more CPU power and disk space to hold the
per user autowhitelists and bayesian analysis.  I personally think
this cost is far below the cost of peoples' time, but YMMV.

-wayne

---

From: Hadmut Danisch <[email-masked]>
Date: Sun, 9 Mar 2003 19:12:19 +0100

On Sun, Mar 09, 2003 at 11:49:34AM -0600, wayne wrote:
> combined you will have reduced spam by 99.968%. 

If a test blocks 20% of spam, it will let 80% get through. 
So a pipe of 5 such tests will let 0.8 ^ 5 = 0.32768 = 33%
through. That pipe will block only 66%. 

Hadmut

---

From: wayne <[email-masked]>
Date: 09 Mar 2003 12:17:34 -0600

> through. That pipe will block only 66%. 

Urgh.

You are right.  I used 0.2 ^ 5, which is wrong.

Still, my point remains that the combined effect of many "low grade"
techniques can yield a "high grade" result.  Fortunately, the two
examples I gave of SpamAssassin and bayesian filters do a lot more
than just 5 tests.  ;->

-wayne

---

From: Keith Moore <[email-masked]>
Date: Sun, 9 Mar 2003 13:46:02 -0500

> I think it is a mistake to only consider proposals that reduce spam to

Agreed.  And I also agree that what really matters is not the 
effectiveness of any particular scheme, but the effectiveness of 
whatever ensemble of schemes is used.

However, it wasn't my intention to suggest that we "only consider" 
proposals meeting these criteria - only that we try to establish 
criteria that help us understand how to evaluate schemes relative to 
one another.  Actually since this is a research group I don't view it 
as our job to make any firm selections between the proposals.

Keith

---

From: Matt Sergeant <[email-masked]>
Date: Sun, 9 Mar 2003 19:01:04 +0000 (GMT)

> through. That pipe will block only 66%. 

Lies, damn lies and statistics ;-)

If the 5 rules map to a different part of the address space of all spam
then the filter is 100% effective. That was the point.

---

From: wayne <[email-masked]>
Date: 09 Mar 2003 14:43:44 -0600

> then the filter is 100% effective. That was the point.

Right.  And that brings up a related point.  If a spam test can be
worked around by doing <foo>, that is still ok if that moves the
spammer into part of the address space that other tests work on.  As
Damon Sauer says, we need to pen, trap and kill the spammers.
(Skinning is preferable to me also.)

For example, if you use domain specific DNSBLs or RMX records check
the From: header to see if the sending MTA is "authorized" for that
domain, you won't have an iron clad detector of spam.  You may,
however, have a good indicator that will contribute to an overall spam
score.  Spammers that are trying to fly under these filters may well
decided that "forging" the from header isn't worth the cost.  This
would lead to less confusion by non-geek users and would be a big
help.

Content filters that check for just the word "Viagra" have caused
spammers to munge the word in various ways.  More sophisticated
filters will detect many of these munged versions also.  If we can get
spammers to have to talk in 133t 5p34k, we have won.

-wayne

---

From: Justin Mason <[email-masked]>
Date: Sun, 9 Mar 2003 22:37:03 +0000

> (Skinning is preferable to me also.)

Well, that is the whole idea behind SA's use of lots of different test types,
after all ;)

--j.