Subject: [Asrg] Tragedy of the Commons

From: [email-masked]
Date: Thu, 20 Mar 2003 09:13:47 +1200

Thanks to those contributors who mentioned this issue. I found the following
1-page summary useful in understanding the background of the concept:
http://members.aol.com/trajcom/private/commons.htm

An important concept though, is that the scarce resource is not [bandwidth],
but [our attention] i.e. technology can give extra Mbs, but not extra
minutes. This concept is discussed in depth by Harry Rheingold in his 1994
article:
http://www.well.com/user/hlr/tomorrow/tomorrowcommons.html

	"Attention is the currency of cyberspace. If spammers learn 
	that the Net will turn off its attention in an organized manner, 
	maybe they'll go away before they damage the cybernetic commons. 
	If too many opportunists ignore the social agreements that make 
	the net useful as an online thinktank, the marvelous 
	knowledge-sharing culture that had scaled up so well from 
	the one thousand person ARPAnet in 1970 to the twenty million 
	person Internet of 1994 will be extinct by the time hundreds of 
	millions come online by 1999."

It seems to suggest that the only power we have, is to collectively ignore
the people who abuse our time, or those service providers who allow abusers
to flourish.

Regards, Mike Pearson

Personal: The views expressed are not necessarily those of my employer.

ph  +64 (4) 495-6769   mobile +64 (21) 631-731
fax +64 (4) 495-6669 
mailto:[email-masked] 
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Frank de Lange <[email-masked]>
Date: Wed, 19 Mar 2003 22:53:37 +0100

>http://members.aol.com/trajcom/private/commons.htm

Hm, just deleted a concept-mail in which I put forward the tragic of the 
commons, and the question if economic models can help model the spam 
problem. I deleted it because I think many operators will frown upon 
their mail servers being dubbed part of the commons. Yes, eyetime is a 
scarce resource, but the spam problems are larger. Bandwidth, storage 
and CPU-cycles are also scarce resources, and have to be dealt with. 
Just ignoring the spammers is not enough when the sheer volume is enough 
to overwhelm many links and servers.

Frank

---

From: <[email-masked]>
Date: Wed, 19 Mar 2003 18:17:15 -0500

Be careful about confusing physical models of limited resources with
situations wherein there may be synergy of the commons.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Frank de Lange
Sent: Wednesday, March 19, 2003 16:54
To: [email-masked]
Subject: Re: [Asrg] Tragedy of the Commons

Frank

---

From: Frank de Lange <[email-masked]>
Date: Thu, 20 Mar 2003 00:55:58 +0100

>situations wherein there may be synergy of the commons.
Nice terminology. What does it translate to? What synergy are you 
referring to? Some examples?

The resources are limited, however way you put it. Your time is limited. 
Your bandwidth is limited. Your storage space is limited. Even the 
screen space is limited. You have limited resources to expand your 
limits (money). And, also very important, your patience is limited. 
Several people have already given up on email because of spam.

Frank

---

From: <[email-masked]>
Date: Wed, 19 Mar 2003 20:05:12 -0500

I'll have to excuse myself and leave it cryptic for now because my time
is finite. I'll simply point out that it's not at all clear what the
limits are and we overly focus on doling out scarcity. Even my time,
which I see as very limited, can be effectively increased with tools and
better metaphors for the information.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Frank de Lange
Sent: Wednesday, March 19, 2003 18:56
To: [email-masked]
Subject: Re: [Asrg] Tragedy of the Commons

Frank

---

From: Scott A Crosby <[email-masked]>
Date: 20 Mar 2003 05:31:59 -0600

On Thu, 20 Mar 2003 09:13:47 +1200, [email-masked] writes:

> minutes.

Exactly!

At computer prices of $10,000 for 1ghz. [1]
At bandwidth of $100/gb. [2]
At storage of $50/gig. [3]

In an exaggerated situation, I'd rather burn 60ghz*seconds, 60kb of
bandwidth, and 120kb*100 weeks of storage than to deal with a *single*
message. In the first case, I'm out $.02 in resources, in the second,
I'm out 5 seconds. I value 5 seconds of my time as much more valuable
than $.02.

For an unexagerated situation, with bandwidth prices of $5/gig, and
assuming you actually nuke unwanted email weekly, instead of save it
for 2 years, the numbers come to that I'd rather burn 60ghz seconds,
2400kb of bandwidth, 12MB*weeks of storage, for one spam.

Thus, I've still thought that the mantra of 'stealing my bandwidth' is
an argument I cannot understand, because of how weak it is. I have no
idea who made it, or why they focussed on the absolute cheapest
resource that spam consumes. (Could someone illuminate this with some
history?) Had the mantra been 'they steal my time' or 'they steal my
client's time', I'd agree 100%.

The real irony is that that argument seems to be getting even more
weak, as CPU, storage, and bandwith prices continue to decrease, and
human time becomes more valuable.

Ergo, my pet-idea of, at some level, essentially forgetting about
those ever-cheapening resources; bandwidth, CPU, and space and instead
focus on the only resource that is expensive, and getting more
expensive: human attention&time.

Thus, without *really* good arguments, I can't see the point of ideas
that embed complicated policy langauges into SMTP. Nor others that
force a sender to burn an infitestimal amount of CPU; I'd rather burn
an ghz*hour of CPU than waste a minute of my time.

Now, my pet theory of either reducing the cost, in human time to the
recipients of unwanted communication, or increase the cost, in human
time, to the sender. (And do it in a way that avoids breaking mailing
lists.) I throw out CAPTCHA as a starting point.

Scott

[1] Assume 1ghz for $10,000 over a lifetime of 3 years or 100M
seconds, this comes out to $.0001 per second of 1ghz CPU.

[2] Colo seems to be about 300 gigs monthly at $3500, taken from
www.anchor.net.au; australian dollars.

[3] HD is now $1/gig at commodity prices. 50 is conservative. Assume
they last 100 weeks.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: halloran parry <[email-masked]>
Date: Thu, 20 Mar 2003 10:17:37 -0500

--On Thursday, March 20, 2003 5:31 AM -0600 Scott A Crosby 
<[email-masked]> wrote:

>> Thanks to those contributors who mentioned this issue. I found the
>> following 1-page summary useful in understanding the background of the
>> concept: http://members.aol.com/trajcom/private/commons.htm
>>
>> An important concept though, is that the scarce resource is not
>> [bandwidth], but [our attention] i.e. technology can give extra Mbs, but
>> not extra minutes.
>
> Exactly!
>

On 3/18/03, Matthew Richards posted an interesting idea of developing a new 
email protocol that used a website based login system for every message 
sent ([Asrg]try this on for size).  The thread was never picked up, and I 
had criticisms due to its potentially cumbersome nature as far as sending 
legitimate mass emails was concerned.  However, if you're looking to make 
spamming extremely tedious, time consuming, and difficult for the sender, I 
think it's worth revisiting that thread.

Halloran Parry

---

From: Scott A Crosby <[email-masked]>
Date: 20 Mar 2003 10:35:18 -0600

On Thu, 20 Mar 2003 10:17:37 -0500, halloran parry <[email-masked]> writes:

> On 3/18/03, Matthew Richards posted an interesting idea of developing
> a new email protocol that used a website based login system for every
> message sent ([Asrg]try this on for size).  The thread was never
> picked up, and I had criticisms due to its potentially cumbersome
> nature as far as sending legitimate mass emails was concerned.

> However, if you're looking to make spamming extremely tedious, time
> consuming, and difficult for the sender, I think it's worth revisiting
> that thread.

That consumes the only resource that is gaining in cost each year.

I don't like that, but how about some notion of stamping? Each message
recieved must include a valid stamp. Stamps are only usable once.

Stamps are 96 bits, and thus may be represented as 17 ASCII base64
characters each. The two types are:

   1. Stamps that encode a partial hash collision, of a sufficient
   number of bits so that the MD5 hash of the stamp agrees with a
   sufficient number of bits in the MD5 hash of the recipients email
   address. The input to MD5 is 64 bits and forms 2/3 of the
   stamp. The remaining 32 bits is a random nonce supplied by the
   recipient.

   2. Stamps may be random nonces created by the recipient. This
   document does not discuss additional means to disburse stamps (such
   as CAPTCHA's).

In both cases, the recipient is responsible for tracking the use of a
stamp to prevent double-spending.

All messages SHOULD include a stamp in order to be recieved.

   1. Each sent message MUST include at least two fresh stamps for
   each To, Cc, or Bcc recipient. The stamps must be valid for the
   Reply-To address.

   2. Stamps may also be generated through partial hash collision
   requiring 10 Ghz*min of work.

There is a stamp-control protocol supporting the following messages:

   1. QueryValidStamp: Given a set of stamps, report which stamps are
   and are not valid for a recipient.

   2. RequestStamp: A request of a sender for a roll of stamps. This
   request must be forwarded to the user-agent who will decide whether
   to allow or deny the user's request.

   3. StampMissingBounce: A message was sent but not delivered because
   no valid stamp attached. In this case, the user-agent is required
   to create a hash-partial-collision stamp, then resend the
   message. This bounce also includes a random nonce that must be used
   for partial hash collisions.

   4. RescindStamps: A request by the user agent to rescind a prior
   set of granted stamps granted by RequestStamp.

**

I don't think it would seem to signifigantly hurt many current email
parties:

   1. Resources per stamp are small; the amount of stamp text required
   in an email would be little more than the amount currently required
   for email addresses.

   2. When sending an email, if the sender has a valid stamp for each
   recipient, they use it and send the email. If not, they attempt to
   send the message with no stamp. If they recieve a
   StampMissingBounce for a messsage without a stamp, create a partial
   hash collision stamp. If they recieve a StampMissingBounce for an
   address with a stamp, then their understanding of valid and invalid
   stamps is in error. They send a QueryValidStamp request to that
   recipient to see which other stamps they hold for the recipient are
   also invalid. They then repeat this step.

   3. Robotic replies would not be harmed. Each email sent MUST
   include two valid stamps suitable for automatic replies.

   4. Mailing lists would also not be harmed, because the mailing list
   manager could request stamps from the user in blocks of 1000, then
   use them on the outgoing messages. When they run low, they send a
   RequestStamp request to the user to give more stamps.
   
   5. First-time senders would be impacted with a 3-30 minute CPU
   bill, but not too badly.

   6. I use nonces in the construction of stamps that may be timed out
   by recipients.

---Flaws---  

I've not discussed the seperation of interests between ISP's and
end-users, nor what protocol would be used to represent this
seperation.

I've not discussed when parties such as mailing lists strip stamps off
of messages. As stamps are not tied per-sender, they are
transferrable, so, for instance, stamps should not be put online.

One can still be spammed by RequestStamp messages, and ignorant users
may allow them. Fortunatly this can be half-solved; one attaches a
'report spam' button to an email client, which then sends a
RescindStamps to rescind all of the stamps in the given group. 

Webmail and similar email-to-X gateways may be socked with the CPU bill.

-------

So, go ahead and shred it.

Scott

---

From: [email-masked]
Date: Thu, 20 Mar 2003 11:51:03 -0500

> idea who made it, or why they focussed on the absolute cheapest

There's two corner cases that you need to consider here:

1) Your note arrived at my laptop over a last-hop link over a 44K modem link
(poor copper out to my place).  If your note had been a 200K spam-gram,
it would have delayed the arrival of something legitimate that I was *waiting*
for by some number of seconds.  Also note that bandwidth used by inbound
mail is bandwidth I can't use to check www.weather.com (which is a bit
important, due to heavy rain this part of Virginia has a flash flood watch
in place).

If I have to upgrade mu last-hop link to ADLS or cablemodem, that will be
a hit of some $50/month.  It's one thing to decide spending $50/mo because
you'd like to websurf faster.  It's another thing to find out that you no
longer have that $50/mo to spend on other things because you can't cope with
spam anymore.

2) Dark fiber is cheap.  Bandwidth is cheap.  However, we recently kicked
our campus backbone to gig-E and our main off-campus pipe to OC12.  If we
need to upgrade the off-campus to 2xOC12 or OC48, that is going to *COST*
a pretty chunk of change, as we'd need to upgrade routers, and NetworkVirginia
would have to upgrade routers, etc etc....

---

From: Kee Hinckley <[email-masked]>
Date: Thu, 20 Mar 2003 10:50:06 -0500

>an argument I cannot understand, because of how weak it is. I have no

The problem isn't an end-user problem.  It's a mail-server problem. 
Matt just posted a stat showing that spam accounted for 5% of all 
email traffic.  (And it's mail traffic I'm concerned about--since 
it's the bandwidth to my mail server that's a problem.)  I'll give 
good odds that that was percentage of *delivered* mail.  (Matt?) 
What it doesn't count are the millions and millions of messages that 
couldn't be delivered, had to be rejected, and then had the 
destination machine "temporarily" unavailable, and sat in the queue 
retrying for three days before they were discarded.  That can consume 
a serious amount of bandwidth and disk space.

-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Matt Sergeant <[email-masked]>
Date: Thu, 20 Mar 2003 18:19:24 +0000

On Thursday, Mar 20, 2003, at 15:50 Europe/London, Kee Hinckley wrote:

> email traffic.  (And it's mail traffic I'm concerned about--since it's 
> the bandwidth to my mail server that's a problem.)  I'll give good 
> odds that that was percentage of *delivered* mail.  (Matt?)

No, that's the percentage of mail we do. We have no idea at that point 
if it can be delivered or not (we don't keep individual username 
details on our servers).

Spam is 50% of all email. But the average email size is 60k (this gets 
bloated to the high end by word documents and other large things that 
get emailed around, but it's still an accurate average). The average 
spam size is 6k at the moment.

So at 1/10th of the size of regular email, spam accounts for 5% 
bandwidth wise.

However, on the flip side, we still have to apply aggressive filters to 
every email we see. Our virus filters are extremely aggressive (but we 
don't have any false positive problems there - about 2 FPs every 10 
million mails), and so it takes us about 1 second to process a mail, 
*regardless* of the size.

So while spam is only 5% of the bandwidth, it's 50% of the processor 
time. That's 100% more servers we have to buy just because of spam.

Hope that helps ;-)

Matt.

---

From: David Finnie <[email-masked]>
Date: Fri, 21 Mar 2003 23:21:32 +1100

Scott,

> That consumes the only resource that is gaining in cost each year.

I agree that technical solutions that use more CPU, bandwidth and
storage than mail transport currently does are fine if they reduce
spam, and (therefore) also reduce human time resource
consumption. Ultimately if spam volumes are reduced, then there will
be some saving in CPU, bandwidth and storage resource which will
offset any increases due to new protocols. Besides that, as you've
pointed out, those resource keep getting cheaper, whereas human
resources are the opposite.

> recieved must include a valid stamp. Stamps are only usable once.

This is an interesting idea. I have some questions for you about your
proposal:

Can you please describe more fully your concept of a "partial hash
collision", and "sufficient number of bits". I think I understand that
the first 64 bits of the stamp is input to MD5, and also that the
recipient's email address is input to MD5. If we let "x" be the number
of bits in "sufficient number of bits", are you saying that:

 MD5(stamp[0:63])[0:x-1] = MD5(recipient email)[0:x-1]

(i.e. the left-hand most part of each MD5 hash match)

or perhaps:

 MD5(stamp[0:63])[128-x:127] = MD5(recipient email)[128-x:127]

(i.e. the right-hand most part of each MD5 hash match)

or perhaps that it is up to the receiver to determine which bits match
? And presumably "x" is worked out by the recipient when it does it's
calculation to produce some stamps ? Or are you suggesting that "x" be
a fixed quantity for this protocol ?

Forgive my ignorance, but I'm not familiar with working with partial
hashes, and I don't know of any gotchas. My main concerns would be:
say for a particular recipient email address, could the MD5 hash it
produces severely limit the maximum value of "x" that can be used for
a partial match against hashes of 64 bit quantities ? Given the good
randomness of MD5, I would guess probably not, but it is worth
investigating (if you haven't already). My reasoning is that if that
were the case, then some unfortunate recipients may be easy targets
for spamming because it would be easier to "guess" the first 64 bits
of their stamp.

Are you proposing that the stamp-control protocol piggy-back within
SMTP ? My main reason for asking is that for a sender to acquire a
stamp from a receiver, the request really needs to somehow end up at
the mail server for the receiver (so that the database of valid stamps
can be checked when a mail message containing a stamp is received). I
think it would make sense for it to piggy back within SMTP.

I am also assuming that a stamp cannot be verified as belonging to, or
not belonging to, a particular recipient, except by the recipient
itself. (I say this because one of the options is for the recipient to
create totally random stamps.) Is this correct ?

As an aside from these questions, I haven't found any holes,
yet... :-)

David Finnie

---

From: Scott A Crosby <[email-masked]>
Date: 21 Mar 2003 07:38:27 -0600

> of bits in "sufficient number of bits", are you saying that:

The sender gets 32 bits, called HashNonce from the recipient through a
stamp-missing bounce. Then then wish to compute the 64 bit quantity
XXX, such that:

N=(HashNonce || XXX)

and 

MD5(N)[0:x-1] = MD5(recipient email)[0:x-1]

N is now a valid stamp. The reason I use HashNonce there is to allow a
recipient to eventually time out old used stamps to reduce storage
needs for already used stamps. I would expect it to change yearly. 

>  MD5(stamp[0:63])[128-y:127] = MD5(recipient email)[128-y:127]

This does not matter, what matters is the number of bits that are
forced to be matched. IE, x=20 in your first example is as equally
hard problem as y=20 in the second.

> a fixed quantity for this protocol ?

$x$ is a fixed quantity, say 32, such that computing such an XXX
requires a signifigant amount of work. Benchmarking, it looks like
1ghz machine can do 5 million/second MD5's, so for $x$=32, this means
about 15 minutes/stamp, but will go down with increasing computing
power. I want it to be this long, because nominally, this cost is only
payed once between a pair of participants. Generally, anyone you've
sent email to won't have to burn this CPU time to reply.

MD5 may not be the best function however; anyone have any idea how
greatly can be greatly sped up using hardware? (And for what cost?)

> for spamming because it would be easier to "guess" the first 64 bits

Assuming that MD5 is a random function of its inputs, $x=32$ means
that the probability of successfully forging a stamp is one in 4
billion.

> SMTP ? My main reason for asking is that for a sender to acquire a

Undecided. There are four sets of data that need to be kept:

  1. Canceled/Used stamps.
  2. Outstanding stamps (that were sent in response to a request)
  3. HashNonce
  4. Unused stamps

IMHO, #1, #2 may be kept by the user or the ISP. #3 should be kept by
the ISP, so that first-time senders can learn the currently valid
HashNonce with paying a user-agent to ISP trip instead of = paying a
full user-agent user-agent round trip. So, if #3 is not kept by the
ISP, email latency could require two round trips.

#4 is who keeps track of which stamps are unused for a particular
recipient. If this is kept by the ISP, how does the ISP avoid paying
the time for a partial hash collision.

> think it would make sense for it to piggy back within SMTP.

I'm not entirely certain, and leave this to others.

> create totally random stamps.) Is this correct ?

There are two notions of stamp: Random nonces created by a recipient,
and partial hash collisions. In the first case, identification can
come from the fact that all nonces are fresh. In the second case,
identification may come from the HashNonce.

There is no identification attached to a stamp, except for the
knowledge that the probability of someone successfully forging one is
extremely small. If I create stamp *EMovyZQWSXggt1uV*, I can be
assured that nobody will guess it, I can also keep track of who I
origionally sent it to. I also keep track when its been used.

So, when a stamp is recieved, it is 

  1. If a nonce, looked up in the hash table of all unused stamps. If
  yes, accept, if no, bounce.

  2. If a partial-hash stamp, the HashNonce is looked up in the hash
  table of all currently accepted HashNonce's. If its not there,
  bounce. Then the the partial hash collision is checked. If invalid,
  bounce. Finally, the stamp is checked in the used-stamps
  hashtable. If there, bounce, if not accept.

Scott

---

From: "Damien Morton" <[email-masked]>
Date: Fri, 21 Mar 2003 09:29:34 -0500

Could a daily, globally published, random number somehow come into this
computation. Incorporating this number into the hash computation somehow
would then validate a stamp for 24 hours (or some other period).

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Scott A Crosby
> Sent: Friday, 21 March 2003 08:38
> To: David Finnie
> Cc: [email-masked]; [email-masked]
> Subject: [Asrg] Re: Stamping
> 
> 
> On Fri, 21 Mar 2003 23:21:32 +1100, David Finnie 
> <[email-masked]> writes:
> 
> > Scott,
> > 
> > > I don't like that, but how about some notion of stamping? Each 
> > > message recieved must include a valid stamp. Stamps are 
> only usable 
> > > once.
> > 
> The sender gets 32 bits, called HashNonce from the recipient 
> through a stamp-missing bounce. Then then wish to compute the 
> 64 bit quantity XXX, such that:
> 
> N=(HashNonce || XXX)
> 
> and 
> 
> N is now a valid stamp. The reason I use HashNonce there is 
> to allow a recipient to eventually time out old used stamps 
> to reduce storage needs for already used stamps. I would 
> expect it to change yearly. 
> 
> This does not matter, what matters is the number of bits that 
> are forced to be matched. IE, x=20 in your first example is 
> as equally hard problem as y=20 in the second.
> 
> $x$ is a fixed quantity, say 32, such that computing such an 
> XXX requires a signifigant amount of work. Benchmarking, it 
> looks like 1ghz machine can do 5 million/second MD5's, so for 
> $x$=32, this means about 15 minutes/stamp, but will go down 
> with increasing computing power. I want it to be this long, 
> because nominally, this cost is only payed once between a 
> pair of participants. Generally, anyone you've sent email to 
> won't have to burn this CPU time to reply.
> 
> MD5 may not be the best function however; anyone have any 
> idea how greatly can be greatly sped up using hardware? (And 
> for what cost?)
> 
> Assuming that MD5 is a random function of its inputs, $x=32$ 
> means that the probability of successfully forging a stamp is 
> one in 4 billion.
> 
> IMHO, #1, #2 may be kept by the user or the ISP. #3 should be 
> kept by the ISP, so that first-time senders can learn the 
> currently valid HashNonce with paying a user-agent to ISP 
> trip instead of = paying a full user-agent user-agent round 
> trip. So, if #3 is not kept by the ISP, email latency could 
> require two round trips.
> 
> #4 is who keeps track of which stamps are unused for a 
> particular recipient. If this is kept by the ISP, how does 
> the ISP avoid paying the time for a partial hash collision.
> 
> There are two notions of stamp: Random nonces created by a 
> recipient, and partial hash collisions. In the first case, 
> identification can come from the fact that all nonces are 
> fresh. In the second case, identification may come from the HashNonce.
> 
> There is no identification attached to a stamp, except for 
> the knowledge that the probability of someone successfully 
> forging one is extremely small. If I create stamp 
> *EMovyZQWSXggt1uV*, I can be assured that nobody will guess 
> it, I can also keep track of who I origionally sent it to. I 
> also keep track when its been used.
>

---

From: Scott A Crosby <[email-masked]>
Date: 21 Mar 2003 09:10:45 -0600

> would then validate a stamp for 24 hours (or some other period).

No. Stamps are intended to be good for months/years. The reason for
that design decision is to reduce resouce use, to avoid having to
remember *every* past used stamp to detect double-spending.

Unused random nonces (the first type of stamp) may be flushed after a
year or two and no longer accepted.

On the other hand, how does one avoid having to remember every past
hash-stamp, forever? Thus, the only reason I include a HashNonce in
the protocol is to allow me to invalidate past (say, 2 years old)
hash-stamps. If I could, I'd take them out of the protocol, they
require additional semantics, and they're one main reason that
prevents this protocol from being implemented soley by user-agents.

On reflection, the correct design decision may be to remove the
HashNonce and remember all hash-collision stamps forever. At 20 bytes
each. (hash table implementation), the cost to store used Hash-Stamps
is pennies/million. Accidently losing that table allows stamps to be
double-spent, but if that occurs only rarely, its not an issue.

Scott

---

From: C Wegrzyn <[email-masked]>
Date: Fri, 21 Mar 2003 11:36:38 -0500

I have to ask this one question: why e-stamps?  It seems a solution 
looking for a problem to solve.

It seems to me the whole idea behind stopping spam would be for ISPs to 
levy a "use tax" on email being sent. Right now the reason spam is so 
prevalent is that there is no difference in cost between sending one 
email or ten million. While I don't want to get into a war about single 
price, unlimited usage vs. pay for services model, it would be very 
appropriate.

For what it is worth...
Chuck Wegrzyn

---

From: Chuq Von Rospach <[email-masked]>
Date: Fri, 21 Mar 2003 08:44:50 -0800

On Friday, March 21, 2003, at 08:36  AM, C Wegrzyn wrote:

> It seems to me the whole idea behind stopping spam would be for ISPs 
> to levy a "use tax" on email being sent.

What about people (like me) who act as their own ISPs? I buy network 
from my upstream server. I run my own DNS. I run my own SMTP. I run my 
own web and other services.

I have to charge myself to send email now? that's gonna stop the 
spammers...

-- 
Chuq Von Rospach, Architech
[email-masked] -- http://www.plaidworks.com/chuqui/blog/

---

From: [email-masked]
Date: Fri, 21 Mar 2003 11:54:22 -0500

On Fri, 21 Mar 2003 11:36:38 EST, C Wegrzyn said:

> levy a "use tax" on email being sent.

You're assuming that the spammers are sending mail via the ISP's mail
server.   The really hard-core spammers are just buying bandwidth from
the ISP. So those ISPs *ARE* levying a use tax - they're charging for
the T-1 or T-3 or whatever.

---

From: Frank de Lange <[email-masked]>
Date: Fri, 21 Mar 2003 17:49:05 +0100

> price, unlimited usage vs. pay for services model, it would be very 

maybe we should try to use a different name for these things? Stamps are 
from a bygone era when you had to pay for mail to be sent. Email is free 
to send, and I'd prefer it to stay that way. Call them 'authentication 
tokens' or something like that, which does not have this 'pay-per-view' 
idea attached to it.

And no, I don't think we absolutely need these tokens. Since we are 
still in the research phase it is good to hear about all possibilities 
though...

Frank
-- 
    WWWWW      ________________________
   ## o o\    /     Frank de Lange     \
   }#   \|   /      +46-734352015       \
    \ `--| _/     <Hacker for Hire>      \
     `---'  \       +31-640037120        /
             \    [email-masked]    /
              `------------------------'
   [ "Omnis enim res, quae dando non deficit, dum habetur
      et non datur, nondum habetur, quomodo habenda est."  ]

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 21 Mar 2003 12:07:43 -0500

>looking for a problem to solve.

That certainly seems to be the attitude of the systems I've seen. 
However e-stamps do address an ISP concern (namely, they don't get 
reimbursed for incoming email, and they can't charge the user, but 
the user doesn't *want* most of the incoming email).  Of course 
hashcash type solutions don't address that.  Just e-stamp solutions 
where the final MTA actually gets real money.

>to levy a "use tax" on email being sent. Right now the reason spam 
>is so prevalent is

This assumes that ISPs have control over the email being sent.  If 
all ISPs did (and all ISPs wore white hats), then we wouldn't be 
sitting here.  From the white-hat ISP perspective, outbound spam is a 
bug in their security.  e-stamps won't fix that.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Rob <[email-masked]>
Date: Fri, 21 Mar 2003 09:19:50 -0800

First time I saw this - what does anyone make of it?

X-From_: [email-masked]  Fri Mar 21 02:04:29 2003
Return-Path: <[email-masked]>
Received: from hudson.redwire.net (064-186-240-103.prvnet.redwired.net 
[64.186.240.103])
	by lily.redwire.net (8.12.5/8.12.5) with ESMTP id h2LA4Qts011823
	for <[email-masked]>; Fri, 21 Mar 2003 02:04:26 -0800
Date: Fri, 21 Mar 2003 02:57:59 -0700 (MST)
Comments: Received: from Pb:;692?o4962A7C:D366D]4@>|:>=F4<J49F4<Jo2@=]4@>Nz B
           Received: from 
Jx:?7@oH2D966ED]4@>|:?7@oHHH\\3>8>FD:4D6CG:46]4@>|:?7@o36C8\D2442?:]4@>|:>3:8>2?;o2@=]4@>|:644:oAC@\FD2]4@>|9@FC=23o6C@=D]4@>Tx 
M
           Received: from 
Ma:>2E6<4@>o2@=]4@>|:==FD:@?o4J36CC62=:EJ]?6E|:?7@o2C>@C42D6]4@>|:?7@oDF3D62=6G6=]4@>|:?7@oA6C\G2D4\DFC8]4@>|:46>2?d`eo9@E>2:=]4@>Tv 
T
           Received: from 
Tu:??@G2E:G6o2C8@9@FDE@?]4@>|9J3@FoFD2]?6E|:?>JH@C=5gbo2@=]4@>|:?DFC6o:?7:]?6E|:?7@DG4DoA6?6=]4@>|:?7@o;@9??J3C@?4@]4@>Tq 
R
           Received: from 
Ac:?7@o3:==9@==:?8]4@>|:?7@o>2:?6=24C@DD6]4@>|9@DE>2DE6CoG@=@?6E]4@>|:?7@o3C25JA=4]4@]F<|:==FDA=FDo>:?5DAC:?8]4@>|:>>:Io9@E>2:=]4@>Tz 
G
           Received: from 
Rm9@DE>2DE6CoHAC6DD]4@>|:?7@oH84E]4@>|9F>2?0=628F6a__`F<oJ29@@]4@>|:?7@o7C@>A2C25:D6]4@>|9C@25DAF3277oH@C=5?6E]2EE]?6E|9F?E6C]D4o>:?5DAC:?8]4@>Mr 
Z
           Received: from 
Nr:;F:46o255C]4@>|9F>AEJ56G2o2@=]4@>|:592J?6Do>@F?6E]4@>|:4:>=@o9@>6]42|:0>:DD0J@F0H6DoJ29@@]4@>|:2CE@>o2@=]4@>TT 
T
           Received: from 
Nz:37:G6o2@=]4@>|:>2C=J>2Co9@>6]4@>|9F89aaego2@=]4@>|9A]<2H2?o<2H2?]56|:5?E9D@o4D]4@>|:?7@o52E2DFAA@CE:?4]4@>Rb 
Y
           Received: from 
PQ9@J@?8oD<J7246]4@>|9D5>2C49o2@=]4@>|:=2>@E96oH@C=5?6E]2EE]?6E|:<5EE>oJ29@@]4@]F<|:<52G:Do9@E>2:=]4@>|:?7@oE96C>2=6?8:?DE]4@>Rz 
M
Errors: [email-masked]
From: OTC-Stocks <[email-masked]>
To: ZzNjiADf <[email-masked]>

-----------------------------------------------------------
Rob Ayer   -    Network Operations
-----------------------------------------------------------
Office		858-244-9040 x205
Fax		858-244-9043
Mobile		858-518-4894
Tollfree	866-4REDWIRE
Pager		[email-masked]

RedWire Broadband
5771 Copley Drive Suite 100
San Diego, Ca 92111
http://www.redwire.net
-----------------------------------------------------------

I'm a SpamCon Foundation Member, #638
Verify it at http://www.spamcon.org/search/member-search.shtml
Why aren't you?

---

From: C Wegrzyn <[email-masked]>
Date: Fri, 21 Mar 2003 12:27:39 -0500

I too was an ISP in the very early days. I remember paying $10,000/year 
just to have routing done between the various private networks.  It 
really isn't a difficult concept to understand - it is a tax you collect 
and is collected from you. Europeans have had a VAT for years. It could 
work just like a VAT.

As to just buying bandwidth, well we all know that isn't quite true. It 
does have to go through a router some where. Intercepting the SMTP 
traffic would be trivial.

Chuck Wegrzyn

---

From: C Wegrzyn <[email-masked]>
Date: Fri, 21 Mar 2003 12:28:45 -0500

Having been an ISP (destek.net) for many years, it isn't all that 
difficult to filter traffic going through a network. It is done all the 
time.

Chuck Wegrzyn

Kee Hinckley wrote:

> reimbursed for incoming email, and they can't charge the user, but the 
> user doesn't *want* most of the incoming email).  Of course hashcash 
> type solutions don't address that.  Just e-stamp solutions where the 
> final MTA actually gets real money.
>
>> to levy a "use tax" on email being sent. Right now the reason spam is 
>> so prevalent is
>
>
> This assumes that ISPs have control over the email being sent.  If all 
> ISPs did (and all ISPs wore white hats), then we wouldn't be sitting 
> here.  From the white-hat ISP perspective, outbound spam is a bug in 
> their security.  e-stamps won't fix that.

---

From: Fred Baker <[email-masked]>
Date: Fri, 21 Mar 2003 09:35:47 -0800

>First time I saw this - what does anyone make of it?

looks like a lot of the spam I receive from Asian countries.

---

From: Chuq Von Rospach <[email-masked]>
Date: Fri, 21 Mar 2003 10:19:03 -0800

someone's trying that new sendmail exploit.

On Friday, March 21, 2003, at 09:19  AM, Rob wrote:

> Message-Id: <[email-masked]>
> Comments: Received: from 
> Pb:;692?o4962A7C:D366D]4@>|:>=F4<J49F4<Jo2@=]4@>Nz B
>           Received: from --

---

From: Scott A Crosby <[email-masked]>
Date: 21 Mar 2003 12:44:34 -0600

On Fri, 21 Mar 2003 12:07:43 -0500, Kee Hinckley <[email-masked]> writes:

> That certainly seems to be the attitude of the systems I've
> seen. However e-stamps do address an ISP concern (namely, they don't
> get reimbursed for incoming email, and they can't charge the user, but

There are a few problems with this.

  1. If the price were over $.001, it would kill mailing lists. For
  instance, this mailing list would cost IETF a $.10
  /subscriber/day. At, say, 500 subscribers, thats $15,000/year. If
  one puts in an 'exception' mechanism for lists, how does one avoid
  having it be abused?

  2. If the price were under $.001, would it really affect unwanted
  email that much?

  3. How does one enforce it. Many organizations just get a leased
  line. How would they get charged? Would you require that every
  cross-domain router MUST have a content-aware packet inspector to
  redirect all email to the 'billing machine'? This severely breaks
  end-to-end, as showable on #4.

  4. With respect to #3, such a mechanism would seriously impact
  robustness of email. Now, its not enough that the bits get there,
  but that every cross-domain router's content-aware inspector must
  work.

  5. Administrative overhead and disputes. Imagine the administrative
  horror in unravelling the accounting of something like Melissa or
  I-LOVE-YOU.

  6. Abuse. Now, someone can recieve money for getting email. They can
  use cracked machines, worms, proxies, and viruses to transfer money
  to themselves.

In any case, we already have a billing mechanism. If I want to send
email to you, do I not incur half of the technical cost? I incur
bandwidth charges and CPU utilization. I may not incur HD charges,
(but, assuming stuff is removed from the ISP server weekly, those are
pretty small in comparison to the others.)

If those sender charges are insufficient to stop spam, why would
merely doubling them, with a 'fair' fictional sender-pays model,
suddenly stop spam? Two-three years ago, internet costs were twice
what they are now, and it didn't stop abuse.

I think what you want is to charge the sender for the time wasted by
the receiver, but is that relevant to MTA's or ISP's?

> This assumes that ISPs have control over the email being sent.  If all

Not true, and not necessarily a good idea; many people are already
noticing breakage because their ISP's are unfortunately breaking
end-to-end.

> their security.  e-stamps won't fix that.

Outbound spam is not a bug in security. Outbound spam is like any
other outbound communication. Bits are sent to the internet sourced
from their customers. Though it may be annoying to you, is my ability
to give you a prank phone call a bug in the telephone system?

Scott

---

From: Frank de Lange <[email-masked]>
Date: Fri, 21 Mar 2003 19:54:21 +0100

> someone's trying that new sendmail exploit.

No, the sendmail exploit is based on overflowing a buffer in the
crackaddr() function which is fed with the contents of 'To', 'Cc' and such.

Find the exploit here: http://www.security.nnov.ru/files/linx86_sendmail.c

//Frank

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 21 Mar 2003 14:07:28 -0500

At 12:28 PM -0500 3/21/03, C Wegrzyn wrote:
>difficult to filter traffic going through a network. It is done all 
>the time.

True.  But you argued that a (per-recipient) email use tax would help 
stop tax.  But the problem you are trying to stop (arbitrary sending 
of large amounts of email from within a network) doesn't require 
that.  It just requires better ISP security.  And if you don't have 
better security, then the use tax will be evaded.

But the real point I'm trying to make here is that anti-spam 
solutions that depend on the sender obeying a rule are not going to 
be successful.  They rely on an ISP (or more likely, a bandwidth 
provider) restricting their customers. Financially they have no 
incentive to do so.  As good citizens, they should do it.  But that 
isn't their primary focus.  We could get rid of lots of DoS attacks 
with very straightforward outbound packet filtering as well--but it 
hasn't happened.

So.  Any recommendation from this group should specify certain 
actions that responsible ISPs should take to secure their networks. 
But don't expect them to be immediately followed.

---

From: Adam Back <[email-masked]>
Date: Fri, 21 Mar 2003 19:46:08 +0000

The Stamps discussion seems to be reinventing hashcash (are some not
aware of hashcash, or is there some aspect of the Stamps discussion
different from hashcash in some way I am not seeing?)

Take a look at the paper:

Aug 02 - "Hashcash - A Denial of Service Counter Measure" (5 years
on), Tech Report, Adam Back

http://www.cypherspace.org/adam/hashcash/hashcash.pdf

and the hashcash home page:

http://www.cypherspace.org/hashcash/

all of the options discussed so far in this thread are documented, or
improved upon in that paper.

In particular:

- the original hashcash proposal (made back in 1997) proposed to use
hash(email) as the challenge, but more recently this was changed to
use the string 0^k (all 0-bits) as the challenge -- simpler and
equally fair challenge.

- the expiry of tokens -- with hashcash the token includes a date /
timestamp, so that the recipient can expire tokens.  I suggest 1 month
to allow for communications delays.

- hashcash is also (by default) non-interactive, so there is no need
for an interactively issued challenge -- this makes it more suited to
store-and-forward and more efficient as you don't need the bounce

- however there is an interactive option (see section 4).

- the idea of a beacon (slowly changing public value) is discussed in
the last para of section 3.

- library, command line and client software is available for download

- there is a java implementation for "clientless" token generation via
web browser which runs at 50% of speed of native code

- MUA integration is available for a couple of mailers

From the command line tool man page an example 33 bit token:

X-Hashcash: 0:020814:foo:4333957e84db47f6

first : separated parameter is version number, next is date/time in
UTCTime format, next is resource string (email address 'foo', or other
resource identifier), and finally a random string.

Because of the format you can verify with the sha1 command line tool:

echo -n 0:020814:foo:4333957e84db47f6 | sha1
000000007fb83d9c3cbd501628b7a6c1cd352ad4

where you can visually see the leading 33 bits of 0s.

Adam

---

From: Scott A Crosby <[email-masked]>
Date: 21 Mar 2003 14:28:31 -0600

> different from hashcash in some way I am not seeing?)

Yes, it is strongly inspired by HashCash, but it is different. The
differences is that HashCash is only used for initial communication.

In my system, almost all stamps are really one-time-use random nonces
generated by the recipient. The stamps are automatically attached to
all outgoing messages, but may be obtained by solving a CAPTCHA or
other out-of-band means. This means the HashCash stamps are relegated
to only being used for the initial message in a communication.

Thus, I can afford to make the hashcash stamps incredibly expensive,
on the order of tens of minutes, because few messages ever use them.

Since so few are used, I consider it acceptable to require the
recipient to maintain a database of all of them ever used. The lack of
datestamps allows a MUA to precompute stamps ahead-of-time based on
for addresses in the address book.

Also, since MUA's may mint arbitrary stamps and bulk mailers may send
a control message requesting the same, bulk emailers do not require
users to implement an exception mechanism.

> improved upon in that paper.

I ruthlessly simplified Hashcash to suit the limited situation I am
using it for.

> where you can visually see the leading 33 bits of 0s.

Nice change.

Scott

---

From: [email-masked]
Date: Fri, 21 Mar 2003 15:37:38 -0500

> on the order of tens of minutes, because few messages ever use them.
...
> users to implement an exception mechanism.

"Hi.. I'm a bulk mailer.  Cound you send me 5 or 10 stamps?"
"Hi.. I'm some other bulk mailer.  Could you send me 5 or 10 stamps?"

Lather, rinse, repeat.  DOS. ;)

(Yes, it can probably be fixed/rate limited, but you're screwed if you don't
fix that problem....)

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 21 Mar 2003 15:40:16 -0500

>There are a few problems with this.

There are *lots* of problems with it.  But someone asked what problem 
the solution was looking for.  And there are certainly some ISPs (not 
just The World) who would very much like someone to reimburse them 
for the volume of email they have to handle--especially the bounces. 
And spammers are only part of the problem.

>   end-to-end, as showable on #4.

The proposals I've heard from ISPs is that they want to be able to 
charge bulk senders for mail destined for users at the ISP.  So if 
Microsoft wants to send thousands of non-deliverable Passport 
messages (to take an actually example) they are going to have to pay 
for it.

I understand the pain there.  A large percentage of the email I 
bounce is from non-spammers who didn't bother to verify and never 
clean their lists (for example, deerfield.com used to be a major 
offender, although they seem to have finally cleaned up their act.)

>pretty small in comparison to the others.)

No, the email sender incurs a much smaller percentage of the cost.  I 
can trivially send one message to several hundred people at your 
site.  I send one.  You have to process, store and bounce hundreds of 
messages.  Never mind the customer support costs.

>what they are now, and it didn't stop abuse.

First of all, I never said this had anything to do with spam. 
Someone asked who would want stamps--I answered.  But in answer to 
your question, it's not a doubling of the cost, is way more than that 
because you send one message and the ISP handles many more.

>other outbound communication. Bits are sent to the internet sourced

In theory, yes.  In practice, no.  Outbound spam makes very heavy use 
of security bugs to go out, precisely *because* ISPs have some degree 
of control over their email systems.

>to give you a prank phone call a bug in the telephone system?

It is if you use a bluebox to do it.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Adam Back <[email-masked]>
Date: Fri, 21 Mar 2003 20:55:15 +0000

> differences is that HashCash is only used for initial communication.

This is an optimization also proposed for hashcash when one gets down
to "so how would you deploy this" question.  See for example the
CAMRAM architecture:

	http://www.camram.org

> on the order of tens of minutes, because few messages ever use them.

ditto see CAMRAM.  I had proposed a token sent from the recipient to
the sender attached to any message which could be re-used by the
sender to send replies in the vein of Lucent's LPWA (Lucent
Personalized Web Assistant) target revokable email address:

http://www.bell-labs.com/project/lpwa/proxy_index.html

In particular I proposed such a token would be a MAC computed using a
secret key held by the user.  Then he could verify it without storage,
based just on the sender address and the token.  Having expiry could
be optional feature, but there is limited need given the storage-less
aspect.  Tokens could be revoked by putting them in a recipient local
black-list.

CAMRAM settled on using signatures for the tokens in place of a
MAC-based token but it's effectively the same idea I think.

CAMRAM also proposed allowing turing proofs in place of tokens
(CAPTCHA is one example of a turing proof).

An additional idea previously proposed was that reducing the use of
hashcash tokens to first unsolicited email could perhaps be used
instead of increasing practical hashcash cost, could be used to deploy
hashcash token creation into the senders sending mail hub.  This would
then remove the need for a hashcash aware client.  The downside is it
increases sending MTA load, but the deployment problem is easier for
MTAs than for clients.

Adam

---

From: Scott A Crosby <[email-masked]>
Date: 21 Mar 2003 15:05:28 -0600

On Fri, 21 Mar 2003 15:37:38 -0500, [email-masked] writes:

> ..

Yup. 

I didn't want to make it any longer, so I elided out some of the
policy and UI issues.  And stamped requests should be made for 3
months of average traffic, or about 6,000 for a subscriber to this
list. :)

> (Yes, it can probably be fixed/rate limited, but you're screwed if you don't

How about:

  Hi.. I'm a bulk mailer. Here's stamped request. Could you send me 5
  or 10 stamps.

So it costs a stamp (10 minutes of CPU, or a the stamp in the
subscription request) to send this message. 

There are a few policy issues that I am not going into now. For
instance, there may be a problem with unused stamps publically
viewable (mailing list archives, etc), so it might be smart policy to
only allow these requests from either recently minted stamps, hashcash
stamps, or old stamps that were previously given to that address.

If someone accepts a request and decides it was a mistake---one of the
stamps was used to send a spam---then the MUA has a 'spam' button.
Click it and the MUA forgets that the set of stamps was valid. Users
will quickly be trained to be carefull in what they accept. :)

Scott

---

From: Scott A Crosby <[email-masked]>
Date: 21 Mar 2003 15:15:09 -0600

> Microsoft wants to send thousands of non-deliverable Passport messages
> (to take an actually example) they are going to have to pay for it.

Sure. who wouldn't. I'm sure that Mc.Donalds would like to charge
patrons for unreimbursed cost of toilet paper for their patrons. :)

I don't want email to go this way, with toll roads between every
ISP. If the emails were sent to non-existant addresses, then the ISP
isn't being paid by anyone for the traffic, but the can't they just
block it? If the emails were sent to customers, then is the ISP not
being paid by their customers to deliver them?

> can trivially send one message to several hundred people at your site.
> I send one.  You have to process, store and bounce hundreds of

My error. I had forgotten about having multiple addresses in a To or
Cc line and the impact of bounce messages. It was true only insofar as
the origional message.

Scott

---

From: wayne <[email-masked]>
Date: 21 Mar 2003 15:27:00 -0600

> to give you a prank phone call a bug in the telephone system?

Prank phone calls are illegal.  Your ablility to make a single prank
call is not a bug in the telephone system.  If you had the ablility to
make even a dozen prank phone calls per week without being caught,
then I would say there is a bug in the telephone systems.

-wayne

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 21 Mar 2003 17:45:21 -0500

>being paid by their customers to deliver them?

What do you do when a legit company sends you two hundred copies of a 
mesage to 190 non-existent addresses, and 10 real ones?  You can't 
block the company.  You have to deal with the bounces.  And there are 
no customers paying for those bounces.  They left years ago.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Steve Schear <[email-masked]>
Date: Fri, 21 Mar 2003 16:26:07 -0800

>then I would say there is a bug in the telephone systems.

But anyone can.  Just go to random pay phones and make the calls.  Of 
course, the costs associated with this mean that those calls have got to be 
somewhat important to you.  Stamps to the same.  If its free it gets 
abused.  If it costs value judgements come into the picture.

steve

---

From: Scott A Crosby <[email-masked]>
Date: 22 Mar 2003 08:45:13 -0600

> This is an optimization also proposed for hashcash when one gets down

See below, but I believe that this is a necessity, not an
optimization; for hashcash to be expensive enough that spammers cannot
afford to burn the cycles, email hosts cannot afford to burn the
cycles, and legitimate end-users will go bonkers from 10-120 minute
latencies.

> to "so how would you deploy this" question.  See for example the

I think what is needed is to pragmatically answer the deployment
questions. IE, rather than offer possible design choices/ideas for
deployment, bite the bullet and choose the best set of design choices
and document them.

> 	http://www.camram.org

How does CAMRAM deal with mailing lists. Are you using the signature
stamp, but won't that force a mailing list programs to incur
relatively expensive public key operations. Or are 'expensive public
key operations' not really considered that expensive anymore? Doing
some benchmarking, I find that my P2-450 can sign&verify about 50
messages/second. What is a 'high' email load for a P2-450 running a
high-volume mailing list? Is it under 10 messages/second?

> based just on the sender address and the token.  Having expiry could

I think that using the sender's email address in any token is a design
mistake. The sender's address is forgable, so the security gained over
a plain token is relatively small. If 'they' can find the token, they
can probably find out the from address to forge. Second, many people
have systems that depend upon forgery in order to direct incoming
email where they wish.

I also am reluctant to use signatures on emails because emails get
massaged and altered between my client and your client. From robots
that add on disclaimer notices, to antivirus software to spam/bulk
classification software to mailing list software, messages are
constantly altered. How does one figure out what is and isn't safe to
MAC? I've had a pet theory that email signatures might finally work if
we redid the email spec such that a message (headers and body) was
actually implemented as a versioned archive like RCS. That way, I
could sign the first version, and each host along the email chain
would make any modifications and check in a new version.

> MAC-based token but it's effectively the same idea I think.

I think so too, the major differences are that the token is a lot
larger and a lot more expensive to verify. I do not know if these
considerations are relevant in practice anymore.

> increases sending MTA load, but the deployment problem is easier for

It depends upon the hashcash token minting cost. I'm envisioning 10
ghz*minutes or so, where I don't think this is practical. If the
minting cost is on the order of 1*ghz second, I don't think its
hashcash will alter anything at all.

A shiny new 3ghz system amortized at $1000/year over 3 years amortizes
to $3/day, and is good for 300,000 ghz seconds/day. At a 1ghz*second
of minting cost, the amortized cost per message is 100,000/$1. The
spamvertizing costs are $100 buys a million? Thats $.0001/message, or
ten times the costs to the spammer from minting. Even a minting cost
of 60 ghz*seconds would only increase the cost to $600/million. Worse,
Moore's law will eat into these costs by a factor of 8 over the next 5
years.

Thus, I think we'd need on the order of *AT LEAST* 10 ghz*minutes of
hashcash to make spamming unaffordable, and perhaps 100 ghz minutes 5
years down the line. IMO, would 10 ghz*minutes of CPU to mint just one
stamp makes it impractical to expect a mail gateway to mint hashcash
style stamps?

You know what the quote goes? ''A protocol is not done when there is
nothing more to add, but when there is nothing more to take away''

Well, I'm taking it to heart when I ruthlessly simplify your
system. :)

Scott

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 22 Mar 2003 09:03:48 -0700 (MST)

> then I would say there is a bug in the telephone systems.

That points out a problem with many spam solutions.  They assume that
ISPs that don't now care to terminate their spaming customers or their
resellers that happily resell to spammers (e.g. UUNET) will do soemthing
different because someone talks about e-stamps, authentication, or
some other techical widget.  Spam-friendly ISPs will continule to
support spammers. Other ISPs will continue to hunt down and eliminate
the monder equivalents of phone phreaks.  Spam friendly ISPs will
be happy to mint stamps or sign new, spam-for-a-day certs for spammers
where they now sell bandwidth or spam-for-a-day throw-away accounts.

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

---

From: Kee Hinckley <[email-masked]>
Date: Sat, 22 Mar 2003 11:44:48 -0500

Wait a second.  Most of my incoming email comes from mailing lists. 
And in that case, if I read your proposal correctly, I'd have to 
provide them with the stamps.  Said stamps take 10 minutes each to 
generate.  I currently *average* 1800 incoming messages a week.  (I 
love Eudora's "Statistics" window.)

Or in other words.  I'm going to need two machines dedicated to 
generating stamps 24 hours a day just so that I can read my mailing 
lists.

Did I miss something?

---

From: Scott A Crosby <[email-masked]>
Date: 22 Mar 2003 11:43:12 -0600

On Sat, 22 Mar 2003 11:44:48 -0500, Kee Hinckley <[email-masked]> writes:

> Wait a second.  Most of my incoming email comes from mailing
> lists. And in that case, if I read your proposal correctly, I'd have
> to provide them with the stamps.  Said stamps take 10 minutes each to

I have two types of stamps. One type is partial hash collision
stamps. The other is just random nonces. When you need some, you just
find some random numbers and send them to the mailing list manager, or
attached to outgoing messagges.  You remember these nonces as valid
and 'forget them' as they are used. Storage is say, 3 months worth of
nonces outstanding, or about 25000 nonces, 500kb to store.

Scott

---

From: "Damien Morton" <[email-masked]>
Date: Sat, 22 Mar 2003 13:02:44 -0500

I wonder if the problems of mailing lists are sufficient reason not to
implement a reasonable spam preventative.

I know the members of this list have a valid concern about the needs of
mailing lists, but I would suggest that the vast majority of email users
do not share those concerns.

At any rate, I tend to think that mailing lists are better handled using
NNTP.

> Behalf Of Kee Hinckley
> Sent: Saturday, 22 March 2003 11:45
> To: Scott A Crosby
> Cc: [email-masked]; [email-masked]
> Subject: [Asrg] Re: "HashStamp" == hashcash? (Re: Stamping)
> 
> 
> I'm not sure which upsets me more: that people are so 
> unwilling to accept responsibility for their own actions, or 
> that they are so eager to regulate everyone else's.

---

From: Kee Hinckley <[email-masked]>
Date: Sat, 22 Mar 2003 13:50:29 -0500

>At any rate, I tend to think that mailing lists are better handled using

There are plent of reasons not to use NNTP for mailing lists. 
Privacy, spam control and member control come immediately to mind. 
There's also a strong social reason.  If you think this list is busy 
now--imagine if it were a newsgroup and anyone could post, but nobody 
had to stick and around and deal with the volume.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 22 Mar 2003 16:43:17 -0700 (MST)

> From: Scott A Crosby <[email-masked]>

> stamp makes it impractical to expect a mail gateway to mint hashcash

What is the minimumm speed CPU that you will allow to send mail?  A
25 MHz 486 is at least 200 and perhaps 500 or 1000 times slower than
a 3 GHz P4.  A 25 MHz 486 needs several minutes to generate 60
GHz*seconds of hashcash.  You might fix the problem for mailing lists
by somehow letting one coin work on many copies with some kind of
authentication (from crypto to envelope Mail_From) and authorization
from whitelisting on.  It is unrealistic to hope that users would
stand for a mail protocol that limits them 1 one mail message afer
several minutes of hard computing.  It is insane to expect ISPs to
force their customers to get new computers or tolerate such delays.

There are reasons why after at least 6 months the hashcash proposals
are still only ideas.

---

From: Steve Schear <[email-masked]>
Date: Sat, 22 Mar 2003 17:43:17 -0800

>At any rate, I tend to think that mailing lists are better handled using

While I think NNTP still has place, the consolidation of Usenet SPs has 
allowed them to become a future choke point against unpopular or illegal 
speech (on the Internet everything is illegal all the time somewhere).

steve

---

From: Steve Schear <[email-masked]>
Date: Sat, 22 Mar 2003 17:59:41 -0800

>force their customers to get new computers or tolerate such delays.

You're still, I think foolishly, focused on an ISP-oriented 
solution.  Sender-pays makes them most sense when the client SW is capable, 
if not singularly empowered, to enforce the payment mechanism at the 
receiving point.

>There are reasons why after at least 6 months the hashcash proposals

The reason is mostly that there are lots of arm chair generals but fewer 
competent programmers.

steve

---

From: Scott A Crosby <[email-masked]>
Date: 23 Mar 2003 00:47:14 -0600

> a 3 GHz P4.  A 25 MHz 486 needs several minutes to generate 60

About 7 hours to compute a partial collision stamp. But, if the sender
already has a valid stamp (previously sent to them by the recipient),
they may use it with no computations. Recipients can compute
nonce-stamps at zero cost. Thus the 600ghz*seconds of CPU would only
be spent on new senders.

In any case, unless the cost is at least 60ghz seconds, and preferably
600ghz seconds, it is insufficient to make spam signifigantly more
expensive.

> force their customers to get new computers or tolerate such delays.

Please reread the proposal, it has none of these properties.

Scott

---

From: [email-masked]
Date: Sat, 22 Mar 2003 22:54:07 -0800 (PST)

I think there maybe problem with proposal in terms of making easy DoS 
attack on any mailing list server!

---

From: mathew <[email-masked]>
Date: Sun, 23 Mar 2003 09:59:35 -0500

On Friday, Mar 21, 2003, at 16:27 US/Eastern, wayne wrote:
> Prank phone calls are illegal.

They are? Can you explain how Comedy Central manages to avoid getting 
prosecuted for "Crank Yankers"?

mathew

---

From: mathew <[email-masked]>
Date: Sun, 23 Mar 2003 10:05:20 -0500

On Saturday, Mar 22, 2003, at 13:50 US/Eastern, Kee Hinckley wrote:
> There are plent of reasons not to use NNTP for mailing lists. Privacy, 
> spam control and member control come immediately to mind.

You know that authentication via NNTP is possible, right?

I agree with Damien Morton. Almost all mailing lists would be better as 
newsgroups.

If NNTP was the accepted way to do group discussions, you'd soon see 
yahoogroups and other discussion forum services offering NNTP. (Not 
sure why they don't already.)

mathew

---

From: Vernon Schryver <[email-masked]>
Date: Sun, 23 Mar 2003 08:16:22 -0700 (MST)

> To: Vernon Schryver <[email-masked]>, [email-masked]

> if not singularly empowered, to enforce the payment mechanism at the 

Ok, but what about the main question?  What is the minimum speed CPU
that you will allow to send mail?  Do you expect everyone from now on
to buy equal speed CPUs?  How else do you ensure that the spammers
don't have CPUs that are 10,000 times faster than spam targets?

> The reason is mostly that there are lots of arm chair generals but fewer 

I can't disagree; standards committees, netnews groups, and bars are
always filled with non-players eager to tell the players how to play.
However, a willingess to admit and deal with fundamental design problems
such as the span of real CPU speeds is part of being a competent
programmer.  At the end of the day, competent programmers are those
who have programmed competently.  How is your sender-pays implementation
working?  How much of your incoming mail is sender-paid, and how much
is simply whitelisted?  (If I'm confused about which solution you have
implemented, please forgive me and say how it is working.)

Only about 1% of the spam sent my way gets through my filters, but I
must admit that the DCC is applied to only the leavings of my static
filters.

---

From: Chuq Von Rospach <[email-masked]>
Date: Sun, 23 Mar 2003 08:27:19 -0800

> You know that authentication via NNTP is possible, right?

Of course, managing that authentication is something else. A while 
back, I was asked to investigate building a gateway between our 
corporate mail server and our corporate usenet system. With some 1x,000 
internal mailing lists, about 75% of them private and restricted and 
most of those containing confidential data. We abandoned it after 
realizing that managing the authentication of the system would require 
a full time admin (the mail list side is effectively self-administered; 
we found migrating that self-administration out to an NNTP extension 
problematic. YMMV).

You also run into a huge problem with private data on NNTP -- once a 
user authenticates to read it, they also have the ability to move it to 
their server where you've lost control of it for authentication 
purposes. This is also somewhat of a problem with e-mail, of course, 
but a lesser one. there's a huge difference here in potential calamity 
between someone forwarding email to his friends and someone attaching 
to a private newsgroup on a corporate server with his personal NNTP 
server and not realizing it's set up so that private newsgroup will 
accidentally propogate into the main public NNTP feeds. The impact of a 
leak via e-mail is almost always more restricted adn easier to resolve.

That shows one key problem with this idea: it assumes "mailing list" == 
"public discussion lists like this forum", and that's not true. Within 
an organization, most mailing lists are private, which makes an NNTP 
implementation difficult and security of the data problematic. Many of 
those lists also extend outside of the organization, which makes them 
impossible. and cross-organizational mail lists (on a simplistic level, 
any mail list that has at least one subscriber that isn't part of your 
mail server)  you can't do it.

so a significant percentage of the mail lists that exist can't use the 
solution. For those that possibly can, you create administrative and 
security issues to deal with. Will your corporate info-sec folks 
actually let you stuff corporate confidential data into private 
newsgroups on a server that gateways to the outside world (for the rest 
of usenet's groups)? I know mine would have a cow if that data got 
anywhere near a machine that could be touched by the outside world. And 
they should.

> I agree with Damien Morton. Almost all mailing lists would be better 
> as newsgroups.

you think so. So far, I've seen 2 or 3 others on this list make the 
same assertion.

That agrees with what I know from experience: back in 1998, I *did* 
make all of my public mailling lists available via an NNTP interface. 
While the main list server had a unique subscriber base of > 10,000 -- 
about a dozen used the NNTP interface.

The "pro-NNTP" people on this list seem to back up those kind of 
numbers. A very small group of people strongly prefer NNTP over other 
distribution technologies; they tend (based on my experience listening 
to them try to convince me to do the NNTP thing again every few months) 
to feel strongly it's the best thing since sliced bread; their overall 
enthusiasm is quite high; their numbers are tiny. And for the most 
part, they tend to be people who've been on the internet for a fairly 
long time, and are somewhat set in their ways -- their habits trained 
in a day when e-mail clients weren't as featured, and NNTP/Usenet was 
more central to the internet experience.

>
> If NNTP was the accepted way to do group discussions,

which it's not, for many good reasons.

> you'd soon see yahoogroups and other discussion forum services 
> offering NNTP. (Not sure why they don't already.)
>

Because NNTP is a fading, mature protocol. authentication 
administration is a pain. you might as well ask why we don't store 
files on a gopher server any more, either. Most folks don't care, don't 
want to use a separate client tool, and don't see any advantage to it, 
and it doesn't really save bandwidth under most circumstances, and many 
lists can't be wedged into the NNTP reality, so you create user 
confusion because now two things that they think are the same are done 
via different tools in different ways, and they don't understand why.

Since, because of the private list problem, you can't move all mail 
lists off to NNTP anyway, it doesn't solve he problem, it just creates 
complexity and confusion.

---

From: Kee Hinckley <[email-masked]>
Date: Sun, 23 Mar 2003 13:16:31 -0500

>You know that authentication via NNTP is possible, right?

Ah.  I understand.  You're talking about the owner of the mailing 
list running an NNTP server, as opposed to actually using Usenet. 
Okay, that makes more sense.  Yes, I wish that were more common.  Of 
course it seriously increases the cost of running a list.  You need 
to have an always up machine with some amount of fixed storage.  And 
we need better newsreaders that make it easier to download new 
messages for off-line reading.

>sure why they don't already.)

I have never understood the resistance to using newsgroups.  Yet 
customers choose web boards (which I despise) over them every time. 
I think it's just a question of what people are used to.  The came to 
the internet via the web and then discovered email (or vice versa). 
Now you want to introduce a third piece of software, and they've 
already got something that manages to do solve the problem so-so. 
They don't want to learn something new that is custom designed to 
deal with this problem, but isn't (general rule of thumb) an order of 
magnitude better.

I think there's a lesson there for people who want to replace email 
with something better.  Inertia is a real powerful force.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Kee Hinckley <[email-masked]>
Date: Sun, 23 Mar 2003 11:23:52 -0500

>nonce-stamps at zero cost. Thus the 600ghz*seconds of CPU would only

So you're saying that it's okay that people on old machines have to 
wait seven hours before they can send a message to someone they 
haven't received a message from?

(And yes, I do have friends and family on machines of that speed. 
And yes, they do send email to people whose address they got over the 
phone or off the web.)

Of course, I suppose it doesn't matter in some sense.  Because the 
odds of anyone writing the hashcash software for their machines is 
pretty close to nil.  They'll just always end up in the junk bin.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Matt Sergeant <[email-masked]>
Date: Sun, 23 Mar 2003 20:14:19 +0000 (GMT)

> customers choose web boards (which I despise) over them every time. 

Ease of administration. I actually found it easier to write my own Perl 
NNTP server than it was to setup INN and get it to do what I wanted.

Matt.

---

From: Scott A Crosby <[email-masked]>
Date: 23 Mar 2003 13:58:31 -0600

> haven't received a message from?

Correct. Unless they can use out-of-band means to obtain a nonce-stamp
in other ways such as a phone call, solving a CAPTCHA on a website, a
auto-reply robot, that sort of thing.

As the back of the envelope calculation I did earlier showed, its
about $1 for 100,000 ghz*seconds. 10ghz*seconds wouldn't seem to be
enough to stop a spammer, yet would already cost a 25ghz system at
least 7 minutes.

> pretty close to nil.  They'll just always end up in the junk bin.

Perhaps.. If there was an easy solution, its likely someone would be
using it by now. And with alternative techniques to obtain a stamp (as
above, it may be incrementally deployable.)

Is anyone collecting system proposals, with their plusses, minuses,
and practicality listed?

Scott

---

From: Scott A Crosby <[email-masked]>
Date: 23 Mar 2003 14:07:25 -0600

> > if not singularly empowered, to enforce the payment mechanism at
> > the receiving point.
> 

\epsilon. A hashcash scheme with an 'out' that allows random nonces
does not incur the full cost is still practical and requires little to
no CPU time.

> don't have CPUs that are 10,000 times faster than spam targets?

This is unlikely. Current CPU's are 3ghz, who runs a 300khz CPU
anymore? Even a Commodore 64 or an Apple ][ is faster!

I remember recently reading about a primitive, different from partial
hash collision, that is limited by memory bandwidth, not CPU
speed. Memory bandwidth varies much less that CPU performance. 

I have not looked at it, but it may help deal with this issue.

> such as the span of real CPU speeds is part of being a competent

A competent programmer also tries to keep their numbers accurate
within two orders of magnitude. Fast CPU's are 3ghz. The origional XT
(way before my time) was 4.77mhz, or only 600x slower. Do there exist
many widely deployed systems email systems that are <25mhz? Thats only
120x slower than current machines, not the 10,000x as claimed.

Scott

---

From: Vernon Schryver <[email-masked]>
Date: Sun, 23 Mar 2003 15:24:31 -0700 (MST)

> does not incur the full cost is still practical and requires little to

I cannot see how any "out" that requires little or no CPU time for 
unknown good guys could not be used by unknown bad guys.  As I see it,
a bad guy can always pretend to be 1,000,000 strangers unless you 
add some kind of authentication.

> anymore? Even a Commodore 64 or an Apple ][ is faster!

Do you think that the only influence on CPU speed is raw clock speed?
For example, a 25 MHz 386 has a raw clock speed only 100 times less
than a 2.5 GHz P4, but easily 1000 times slower.  Look at the number
of those 40 usec cycles required by 386 CPUs for common instructions.
Then look at the effects of instruction caches.

> speed. Memory bandwidth varies much less that CPU performance. 

Memory bandwidth varies by by even larger values if you look at real
systems instead of netnews cartoons.  Main memory bandwidths of cheap
systems today only about 6 times faster than they were 10 or 15 years
ago, but memory size and caches more than make up the difference.  On
the other hand, if your CPU burner has a big enough memory footprint
to bust GHz caches (including those with various burst fill schemes),
you'll need to worry about whether it can even run on old systems.
256 MBytes sounds small today, but inconceivably large for systems
of 15 years ago.

> 120x slower than current machines, not the 10,000x as claimed.

That is evidence of other than competence, because raw clock speed is
merely one component of CPU speed.  The original XT was a lot slower
than 600X slower than a 3 GHz P4 because it used an 8088 wiht an 8-bit
bus (good for 4X hit), many instructions took several cycles (good
for another ~4X hit) and there was no I or D cache (good for another
hit of 10-1000X on a pure CPU grinder).  A 5 MHz 8088 based system
was slower than that value of 600*4*4*10 compared to a 3 GHz P4.

Moreover, my number of 10,000 include several future years of Moore's Law
cycles.  I'm "only" claiming a current 1000X span of CPU speeds.

---

From: Chuq Von Rospach <[email-masked]>
Date: Sun, 23 Mar 2003 14:34:19 -0800

On Sunday, March 23, 2003, at 10:16  AM, Kee Hinckley wrote:

> customers choose web boards (which I despise) over them every time. I 
> think it's just a question of what people are used to.  The came to 

to some degree it's a generational gap (not necessarily by calendar 
age, but by how long you've been on the internet). you see these all 
over the place on the ent -- HTML email is another one folks fight 
over, coerced reply-tos on mail lists is a third, and increasingly, IM 
vs. email. the new generation of users is more of an IM first, e-mail 
as backup, where us old pharts tend to live in e-mail and remember 
fondly the days when NNTP was the primary dinosaur.

Which pointed out to me something I think this forum ought to be 
keeping in mind, the issue of parameters for (and barriers to) success. 
Whatever the solution(s) that we come up with, there are certain things 
that can keep any solution from succeeding, so I think perhaps it might 
be reasonable to think about what those parameters and barriers are.

Some of the most obvious things that come to mind for me are:

1) e-mail is easy to use. The more we complicate e-mail to solve this 
problem, the less chance joe typical user will agree to do it. If you 
don't make the benefits cleaerly visible to the user and the ease of 
use reasonable such that my mother and our aunt sally can (and will) 
accept the solution, it's a non-starter, the way PKI and S/MIME 
effectively are. Those things exist, but basically, nobody but geeks 
use it, and even most of them don't, because the hassles outweigh the 
benefits. (think of this as the 'seat belt' problem. almost everyone 
agrees we should wear our seat belts while driving. A good percentage 
of people don't anyway, even though the hassle of wearing one is 
generally trivial. That's a social issue that has to be dealt with of 
the solution won't succeed)

2) It has to save a person/company/ISP/organization/etc money, time, 
hassle. If it doesn't, it won't be implemented by that 
person/company/ISP/organization/etc. show me the money, basically. "for 
the good of the net" will get the EFF to install it. will sony? IBM?

3) If it requires implementation support from large organizations or 
ISPs, any solution that doesn't have buy-in and a hard date 
forimplementation from AOL is a non-starter. To a lesser degree also 
true of Yahoo, MSN/Hotmail, Earthlink, wannadoo, and maybe half a dozen 
of the larger international ISPs. You don't need ALL of those, but 
without AOL, you might as well go home, and until you get half a dozen 
of the top 12-15 ISPs or organizations, network providers, etc, you 
don't have a chance at building critical mass.

4) will it scale through organizations? I've seen a number of 
suggestions that really come across as if the proposer sees all e-mail 
environments as variations of THEIR environment. A solution that isn't 
tied to the individual (which arguably it can't be, since that solves 
none of the network bandwidth problems) has to scale from my site (a 
box on the end of a DSL line serving 6 users, 15 mail lists and a 
couple of hundred messages through those lists a day) to ibm.com or 
microsoft.com, to MSN, to yahoogroups, to hotmail, to AOL. If the 
solution can't scale up OR down to fit those needs, it's going to be a 
hard sell for success.

5) will the senders buy in? If not, isn't it a non-starter again? Not 
just mail list owners like me, or list sites like yahoogroups, but the 
large-volume mail senders, whether it's content (cnn.com) or 
e-marketing? How do you make it work without them? How do you convince 
them to join in?

Other thoughts?

I've found myself, as I've been watching stuff sent back and forth and 
discussed, asking myself things like "how would this affect my 
systems?" "Does it make my life easier or more of a pain?" "does it 
save or cost me money?" and the biggie: "How would we ever convince AOL 
to buy into this?"

think about AOL's position right now. Take, oh, e-stamps, or sender 
pays. how does AOL implement that on its environment? convince it's 
users to use it? migrate its users off of existing email? How long 
would that migration take? What if they weren't willing to change or 
don't upgrade their software? 25 million users, 3-5 billion pieces o' 
email a day, and users who haven't upgraded their software since they 
plugged in that windows machine 4 years ago, and won't upgrade any time 
soon. How do these plans work in THAT environment?

And if you don't get AOL bought into it, given their size adn volume, 
can you make it work without them?

I realize it's way early to get into too much detail on implementation 
issues -- but understanding certain necessary barriers to success will 
allow us to NOT go building things until we know those barriers are 
taken care of. If, for instance, it requires server upgrades by AOL or 
UI changes to the AOL client, for instance, I think it's silly to go 
beyond a certain level of discussion until someone finds out if AOL (or 
hotmail, or yahoogroups, or....) are willing to consider it. If they 
say no, it's better we consider lesser solutions that don't require 
their cooperation than building a better one that'll fail because we 
can't convince them to do it...

To me, that implies a hierarchy of solutions that can help us set 
priorities and understand the complexity and level of cooperation 
needed for success:

on the receiving end:

1) individual: build something an individual can download and 
implement. advantage: easy to do. disadvantage: limited ability to 
manage bandwidth issues, maintenance and user capability. (example: 
Apple's Mail.app junk mail filters)

2) site: things an admin can install to benefit the users of their 
machine. advantage: fewer people need to take the action, can affect 
network bandwidth issues as well as individual mail boxes. 
disadvantages: loss of user configurability (perhaps), loss of 
customization. (example: spamAssassin)

3) organization: things an organization can do to implement solutions. 
further down the scale of size from site, but effectively the same 
issue, scaled to multiple mail servers and a larger user population, 
plus perhaps issues of multiple locations and nationalities, meaning 
different parts of the system, might be regulated by different 
legislation.

4) ISP: seller of services and bandwidth to organizations. (for the 
purposes of what I'm saying, hotmail is a large organization, UUNET is 
an ISP, SpeakEasy is depending on which services you use, some of both)

5) infrastructure: making changes to the underlying structure of the 
internet (root name servers, protocols, etc) and the software that runs 
it. Basic, fundamental changes to how the net operates. (rDNS, new 
protocols for authentication, etc go here).

A) stuff that doesn't cleanly fit in the above, like yahoogroups, large 
volume senders, e-marketers, and stuff I'm forgetting off the top of my 
head...

The further you move from the individual level, the harder it'll be to 
convince everyone to implement, but the more chance you have of 
significant impact on the problems. So I think it's useful to at least 
casually keep in mind where specific proposals fall, so we can scope 
things like complexity of implementation and what buy-ins we need to 
get before we have a realistic chance of success.

(I think it also is a good visual reminder of why we need suites of 
solutions; indvidiual and site solutions to bridge us towards the 
longer-term, more strategic and structural ones -- and who needs to buy 
off on those solutions before we can hope for them to work)

---

From: [email-masked] (Justin Mason)
Date: Sun, 23 Mar 2003 14:50:00 -0800

> fondly the days when NNTP was the primary dinosaur.

Worth noting that a lot of this new generation say they don't use email,
precisely *because* the spam load makes it too much work. :(

--j.

---

From: David Finnie <[email-masked]>
Date: Mon, 24 Mar 2003 13:27:01 +1100

Scott,

I don't know if you've considered this approach - rather than the
recipient generating stamps using a computationally expensive method,
why doesn't it just generate a unique stamp using a simple method
(e.g. a random or sequential number), and then encrypt it using it's
private key ?

Private key encryption is not overly expensive, but has the attribute
that it is infeasible for the sender to "guess" cipher text that would
result in a stamp that the recipient consider valid.

When the recipient receives a stamp, it simply decrypts it using its
public key, and compares it against its database of valid stamps.

The "down" side of this is that stamps would be larger - e.g. 512 bits
for a 512 bit RSA key pair. However, I think that this increase in
traffic would be fairly neglibable considering the size of average
emails.

Dave

---

From: David Finnie <[email-masked]>
Date: Mon, 24 Mar 2003 13:36:00 +1100

Scott,

> Is anyone collecting system proposals, with their plusses, minuses,

I did post a message suggesting a slightly more formal means of
tracking and displaying important summary information, such as
requirements and proposed solutions. I think that the best place for
this is an official web site.

I haven't yet seen any responses to my proposal.

I think a useful result of this approach would be to reduce the amount
of re-hashed ideas, and also to enable list newbies (like myself) to
quickly get up to speed on the results of the research group so far.

Dave

---

From: Steve Schear <[email-masked]>
Date: Sun, 23 Mar 2003 20:50:16 -0800

At 08:16 AM 3/23/2003 -0700, Vernon Schryver wrote:
>Steve Schear <[email-masked]> wrote:
>to buy equal speed CPUs?

"Allow"?   Stamps will in all probability be "sized" at 
60-600GHz-seconds.  Whether someone is willing to tolerate this process 
delay is one based on CPU speed, patience and importance of the email.

>How else do you ensure that the spammers

Why would it matter?  The hashcash stamp generation process is highly 
asymmetric.  Stamps generated through many GHz-seconds of effort can be 
speedily authenticated by even cellphone or PDA level machines.  Even stamp 
generators constructed from state-of-the-art ASICs are unlikely to make 
stamps more economically than a cluster of x86 blades.

>must admit that the DCC is applied to only the leavings of my static

The following is an edited version of cross-posts from "Eric S. Johansson" 
<[email-masked]>, Camram's primary developer:

One of the systems proposed in camram is to switch from proof of work 
stamps to signed messages once you have been properly introduced. This some 
write-ups on this on the camram site but it's kind of obscure because the 
idea wasn't well thought out when I wrote it. The paper at 
http://harvee.org/camram/ is somewhat more illustrative but it's not fully 
documented yet. That is yet another way folks on the cypherpunks lists can 
help. Work out a system by which message has an embedded public key and the 
key is considered "good" after some introduction process involving two 
parties e-mailing each other. Then figure out how to deal with new key 
introductions if the original key has been lost to accident or deliberate 
action. It's a hoot. ;-)

it is safe to assume that these keys will not have any pass phrases because 
this is a crypto system totally invisible to end-users. Argue with me on 
the no pass phrases requirement directly if you wish.

the camram protocol can be embedded: at the client, or at the server. I 
have a mostly working version at the server and could use some help with a 
few things (see end)

one thing folks aren't too aware of is that I have incorporated a Bayesian 
style filter into the camram environment in order to reduce the number of 
"postage do" notices. As many folks justifiably point out, if you don't 
eliminate the need for a "and then the universe changes" step, you won't 
get out of starting gates. The addition of a filter to discriminate e-mail 
into three categories (red/yellow/green) allows me to reduce the number of 
challenge messages to a small fraction what they could be. The feature that 
implements "and friends fly free" allows you to build your communications 
map and reduce the need for stamps in either direction. Again, this works 
at client side or server side.

>What I want is
>- a Eudora plugin to check for hashcash stamps, send bounce messages, auto 
>generate my hashcash stamps, and help create and maintain my white list.
>- a web site which offers a hashcash stamp generator applet and simple 
>instructions for

Figure out how to make Eudora interface with Python code and we are most of 
the way there.

what we have done:
- basic filter sequence consisting of stamp, white list, postage due 
response, basic template
- a stamp generating SMTP proxy prototype.
- spam discriminator prototype based on CRM114
- holding area management for spam and maybe spam mail
- prototype CGI for holding area operations (discarded because UI sucks eggs)
- prototype CGI for browser based stamp generation in response to postage 
due notice

what we need help with:
- holding area operations CGI. Must be simple UI allowing non-computer user 
to correct discriminator mis-recognitions and release improperly filtered 
messages.
- better CGI for browser based stamp generation.
- better SMTP proxy for outbound stamp generation (including proper BCC 
handling)
- proxies for pop 3
- Most of the code has been written in Python.  We're using Java only for 
the postage due notice web page. It needs to be rewritten a bit to be only 
Java 1.1, show only a big fat button that says "send postage" when it is 
done, and probably some other things which I can't think of right now.

any takers?

---

From: Scott A Crosby <[email-masked]>
Date: 23 Mar 2003 23:42:10 -0600

On Sun, 23 Mar 2003 23:30:12 -0500, Kee Hinckley <[email-masked]> writes:

> At 9:53 PM -0600 3/23/03, Scott A Crosby wrote:
> >  > Ah.  So unsolicited email needs CPU-generated stamps.  Solicited just
> >>  needs a one-time random token.  Thanks, that makes sense.

> 
> Fundamentally what you are doing is saying that the pain of sending
> only needs to happen once, and from then on you've given tokens that
> represent a consent to communicate.  I certainly like it better than
> the pure hash-cash/sender-pays solutions.  And as it represents less
> up-front pain, it's more likely to be accepted.

Hashcash seems utterly ineffective if its anything less than
60ghz*seconds, and more likely 600ghz*seconds. Secondly, for
legitimate bulk-mail senders such as ASRG, that is too high a cost to
put on every message. It would also be nice to send mail to my mother
without burning 10 minutes of CPU. Ergo, if hashcash is to be used,
there *must* be a way to spread around 'cheap' tokens that let those
legitimate bulk senders escape.

For the most part, everything else is just tentative mechanisms to
make it possible to spread around such 'cheap' stamps.

Not that I think this mechanism is great, but I don't think many of
the others that I've heard about are all that practical or desirable
either.

> That said, I don't see yet how it could get past the early-adopter
> phase.  Like the other systems, it offers no real benefits until a
> substantial number of people adopt it.

I can speculate one way. Remember, I haven't stated any policy as what
other means may be available to obtain stamps. I give two required
ways to obtain stamps, but others exist. For instance,
auto-reply-robots that do a two-way handshake or CAPTCHA website
challenges.

One could build this as a 'side' mechanism into a auto-reply robot
whitelisting mechanism similar to TMDA that IETF seperately
standardizes. The robot-replies sucks for older clients, but work. We
make the the stamp-missing control message machine-readible to make
conforming clients check for other valid stamps (or expend the CPU to
create a new stamp). They're also human-readible telling people to
reply to the robot and complete the handshake.

That way conforming clients are actually a benefit for
recipients. Either a sender is sending from a known-good address, or
they implement this protocol. They're also more convenient for
senders, a sender never sees those bounce messages
anymore. Eventually, in 5-10 years we depreciate the white-listing
robot and make all stamp-missing bounce messages only
machine-readible.

Conforming senders interoperate with old recievers, they just attach
some extra headers that get ignored.

Conforming receivers interoperate with old senders. During initial
deployment, they can whitelist based on completing a handshake by
replying to the stamp-missing-bounce-message. Or they can obtain nonce
stamps from a website, or an included CAPTCHA. There's no
authentication, but no worse than current by-sender whitelists.

Eventuallly most recievers will become conforming and the
stamp-missing bounce messages would not be shown to the users anymore;
clients would burn the CPU and resend automatically.

Conforming mailing list systems would keep track of whether a client
appeared to be running this system based on whether a stamp was
attached to the subscription request. Thus switching between a
non-conforming mailing list client and a conforming mailing list
client might cause one to lose list subscriptions, which isn't TOO
bad.

This might almost be the best case. If nothing happens. I can imagine
large ISP's doing the part of this (putting a auto-reply robot
whitelister), and then we'd never get the second half of the
protocol. IMHO, that'd be a horrible mess. We might as well try to use
such an auto-reply whitelister as a bootstrap mechanism to something
better.

> The other interesting thing though, that just came to me, is that
> there is a whole class of solutions (of which this is one) that change
> the nature of email in an interesting way.  Currently email is not
> really a protocol.  It's a one way communication.  (Bounces are the
> exception that prove the rule.)  These solutions change email into
> something that is actually a protocol.  The act of communicating, at
> least initially, involves automated back and forth communication.  The
> reason I find it interesting is that it introduces a whole new set of
> failure modes you need to worry about. Network latency, bounce
> messages, message-delayed messages, lost messages, vacation messages,
> vacations themselves...  All of these things could have interesting
> impacts on the system that we've never really had to think about
> before.

Good point. 

It seems that almost any consent mechanism must make email become a
two-way system.

Scott

---

From: [email-masked]
Date: Mon, 24 Mar 2003 14:04:53 -0500

> GHz*seconds of hashcash.  You might fix the problem for mailing lists

Now, Linux BogoMips are called that because they're bogus for anything except
calibrating kernel spin loops, but anyhow, here's some numbers seen in the last
week or so on the linux-kernel list.  Note that ALL the boxes are "currently in
use"(*).

Somebody's linux-based firewall system:
model name      : 486
bogomips        : 12.44

My laptop:
model name      : Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz
bogomips        : 3145.72

A dual 2.6GHz P4 Xeon (hardly a "large" system by any means) (yes, 4CPU due
to Intel's Hyperthreading stuff - actual performance is likely 60% of this):
Total of 4 processors activated (20696.26 BogoMIPS).

The current high-end Linux code is being extended to support 64-CPU well, I
don't have any numbers handy for the high-end NUMA/Summit systems....

So I have to agree that "in the field" there's over a 1,000X factor in
relative performance...

/Valdis

(*) There's a report of a 4.77mz 8086 clocking in at 0.02 BogoMIPS, but
I don't classify this box as "current in use".

---

From: Kee Hinckley <[email-masked]>
Date: Mon, 24 Mar 2003 17:47:42 -0500

>reply to the robot and complete the handshake.

Okay.  Now you're making a purchase decision.
1. A system that does challenge/response and whitelists responders.
2. A system that does challenge/response and whitelists responders, 
but also makes it harder for you to send email and requires client 
changes, but eventually will be more reliable.

And no, I don't think I'm a pessimist.  I just think that companies 
make decisions based on short-term economics.

But frankly I think that challenge/response is a non-starter.  It 
fails with all automated email systems.  Worse, it potentially 
removes me from mailing lists when it responds (I assume, since it's 
a delivery notification, it goes to the envelope from?).  So that 
means I have to manually check the queue before I allow it to send 
the challenge.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Scott A Crosby <[email-masked]>
Date: 24 Mar 2003 23:16:56 -0600

> changes, but eventually will be more reliable.

No, one where conforming clients will *hide* the challenge from the
user, do the partial hash collision, and automatically resend the
email. Only non-conforming clients would use the 'escape hatch' of the
manual challenge-response.

> fails with all automated email systems.  Worse, it potentially removes
> me from mailing lists when it responds (I assume, since it's a
> delivery notification, it goes to the envelope from?).  So that means
> I have to manually check the queue before I allow it to send the
> challenge.

Oh, I agree, but this sort of 'fun' is coming, and I'd rather get some
positive usefulness out of it, to use it as a wedge to get a better
solution into email clients.... and soon.

Look at:

    http://news.com.com/2010-1071-992911.html?tag=nl

Wanna take a bet as to whether AOL/MSN/Earthlink are contemplating the
same? 

Its the perfect hack. Its simple, it sorta works, it has great
short-term benefits for those who use it (and strong negatives for
those who don't; but those people don't matter). By Richard Gabriel's
''Worse is Better'', I almost expect it to spread like a weed, and
then we'll be stuck with it for decades.

Scott

---

From: [email-masked]
Date: Tue, 25 Mar 2003 09:59:21 -0500

> Wanna take a bet as to whether AOL/MSN/Earthlink are contemplating the

Hmm... To quote the article: "Spammers are not yet equipped to handle the kind
of challenge-response technology incorporated into Mailblocks--not yet, at
least."

So is there anything to distinguish this attempt to start a "Gee Kids, be the
first on the block to piss off all your friends by making them go to a web
page" from all the other ones they've tried?  I mean, besides the fact this
guy started the highly sucessful and widely imitated WebTV?

X-WebTV-Stationery: Standard; BGColor=black; TextColor=black

There's somebody at my site I can't send mail to, because his "I don't want
mail unless you click the website" program triggered on something I posted
to a list, I punted it because it was so stupid.. and didn't notice the
"you will only get this notice once" until it was too late.

Now let's see... what are the business benefits of (say) AOL doing this?

1) If they're the first to deploy, they risk losing subscribers who get
upset because all their friends are annoyed.

2) If their user base is large enough to matter, they will start getting
"WTF is this?" support calls when their users send e-mail to each other.

3) It actually makes life worse for their mail system. Let's work it through:

a) It's identifiable as spam.  AOL is certainly NOT going to quarantine it
for a week in hopes the spammer will ID themselves when they can drop it on
the floor and get it out of the queue.  So if your current spam filter is 95%
accurate, then 95% of the time you'd make things worse by deploying it.

b) It's not identified as spam because it isn't spam.  So now you're
annoying the sender the first time, delaying mail, quarantining it, taking
on the whitelist database headaches - and it didn't help any.

c) It's spam that your filters didn't catch.  This is the only place where
it actually does any good. But now, rather than being able to dump it into
a mailbox and get it out of the queue, you need to quarantine it, and all
the queue management hassles that involves...

The basic problem here is that for it to work, you have to accept and
quarantine the mail.  If you're looking to actually make a challenge-response
system work, you need some SMTP extension to provide a 4XX reply code
so the mail *STAYS AT THE SENDER* until the challenge-response is finished.

Unfortunately, (1) this requires an ESMTP extension to do the 4XX pushback
and (2) I've not had enough caffeine to figure out how to prevent the obvious
livelock on the "You must XYZ to confirm" e-mail (part of why it needs to go
in the 4XX not as a reply msg)....