Subject: RE: [Asrg] requirements for a proposed solution + notion of conse nt

From: "Sauer, Damon" <[email-masked]>
Date: Fri, 7 Mar 2003 12:23:17 -0600

I would like to add:

- should do no harm (mundged email due to error)
- should have minimal cost of implementation (monetarily and/or
administratively)
- should require no more horsepower (Don't want to have to buy more servers)
- should not significantly increase time to delivery

I will think of more I am sure.

Regards,
Damon

-----Original Message-----
From: Balachander Krishnamurthy [mailto:[email-masked]]
Sent: Friday, March 07, 2003 10:38 AM
To: [email-masked]
Subject: [Asrg] requirements for a proposed solution + notion of consent

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

*****
"The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material.  Any review, retransmission, dissemination or other use
of, or taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.  If you received
this in error, please contact the sender and delete the material from all
computers."
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Gary Feldman" <[email-masked]>
Date: Fri, 7 Mar 2003 13:56:33 -0500

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Sauer, Damon

> - should require no more horsepower (Don't want to have to 

This should be modified to say "not significantly more 
horsepower than required by ordinary growth in traffic."

If sites are going to be buying more horsepower to support
increased downloading of movies, for example, then an
increase in processing requirements due to anti-spam measures
would be ok, if that increase is small compared to the 
increase needed to support the movie traffic.

Gary

---

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

Damon Sauer proposed some more requirements, let's add 3 of those as
k,l,m:

k) should have minimal cost of implementation
l) should require no more horsepower
m) should not significantly increase time to delivery

and look at RMX plus fixed DNS:

	l,m

does not have k (depending on what your ideas of minimal cost are)

and Bayesian filters + hashcash + whitelists:

	m

does not have k (depending on what your ideas of minimal cost are)

horsepower depends on how you deploy it: if only clients create
hashcash shouldn't be a problem; if deployed on servers say in
corporate networks at the gateway, that might cost them some
horsepower (though white lists help that).  But I guess that would be
a trade-off -- the cost of deploying hashcash creation on clients vs
the cost of just doing it at the gateway.

Adam