A belated response to some posts about spam.  Mainly about sender-pays
(& challenge-response) rather than legal means or retribution.

   0) Pessimism in general: the "learned helplessness" phenomenon.
   1) Recipient-gets-paid vs. sender-burns "in danger of missing
      the point"?   (David Ramsey)
   2) Why should friends, mailing lists, etc. send for free? (Ramsey)
   3) Why shouldn't everyone pay postage? (Dale Luck)
   4) Zombies, "Digital Imprimature" (Mike Albaugh)
   5) Challenge via SMTP error (Mike Van Pelt, Mark Lentczner)
   6) Sender puts up a bond (Robert Woodhead)
   7) Whitelist vs. forged "From" (Mike Albaugh)
   8) No tech can stop spam (Trevor Blackwell's Lemma)
   9) ISP does metering, $10K bill (Barry Shein, Mike Albaugh)
   10) Mechanism vs. policy, what vs. how (general)

Dates shown are Digest dates.

0) Pessimism in general
   There is an animal learning phenomenon called "learned helplessness".
      http://www.dmu.ac.uk/~jamesa/learning/learned_helplessness.htm
   You expose an animal to situations where it can't (by its own devices) 
   escape a shock (say) or eventual drowning.  Then you put it in a 
   situation where it *can* escape, but it doesn't try.  If you could 
   genetically engineer speech centers into those animals, I'm sure they 
   would spend all their free time talking about, nay, proving, why escape 
   is impossible.

   There's a learned-helplessness aspect to these discussions
   of spam.  Not to lecture on nettiquette or positive thinking, but
   this is a friggin hackers list.

1) Recipient-gets-paid vs. sender-burns "in danger of missing
   the point"?   (David Ramsey, 6/3))

   Yeah, it's a detail, but details are important and this one in
   particular.   Mainly, the recipient should set the price or whatever
   barrier there is.  The main problem of spam is its effect on recipients;
   we should be thinking in terms of empowering recipients, and the
   recipient should be in control.  Solutions should be implementable
   incrementally by the motivated people (recipients) while needing
   minimal cooperation from others (e.g. ISPs, IETF, Microsoft, 
   governments, etc.).  And, suppose $.01 is too much, or too little, for 
   some recipients, or paying by a particular means is hard for legit 
   senders.  Or certain kinds of bounce messages offend or confuse 
   legit senders.   Who should be able to change these details?

   There are also subjective, psychological & heuristic reasons why
   it might be best for the money to go to recipients.  These seem
   less critical to me than recipient control.

2) Why should friends, mailing lists, etc. send for free? (Ramsey, 6/3)

   Any system should be implementable incrementally with a minimum of
   road-bumps for the people who are not currently changing their
   implementation.  I don't want the cost of upgrading to be that all
   my friends must upgrade or I am alone.  That's a transitive seizure.
   Whitelists are almost trivial to implement in a crude but workable 
   way, and can be improved from there along a couple dimensions 
   (security, filtering before reaching the recipient).

   Another reason for whitelists is this: with whitelisting, the only
   messages that need payment are "intros"--attempts to make new
   acquaintances.  That means they can be expected to be infrequent,
   and that means we are more free to make the payment or challenge
   system involve time and complication.

3) Why shouldn't everyone pay postage? (Dale Luck, 6/3)

   I agree that things are currently paid for.  The problem is those
   situations where who pays is grossly off.  Getting email from
   friends (defined as people I want email from) is currently not a
   problem, so it shouldn't be fixed.  More reasons above in #2.

   Postage going to intermediaries, or random good causes, doesn't seem
   to empower recipients.  It seems like design aimed at the wrong goal,
   on the wrong party's behalf, with corresponding possible wrong
   incentive effects (I think Mike Albaugh mentions this).

4) Zombies, "Digital Imprimature" (Mike Albaugh, 6/4)

   Any solution should certainly be designed against existing zombie designs.
   It should NOT simply plug into the existing SMTP interface at the ISP
   and add the penny there, for instance.  The zombie should have to
   figure out *which* mail-charging system the *recipient* uses and how
   to activate it for the messages that it sends.  Designs that make
   this hard for zombies but easy for humans are obviously good.
   (One obvious one: you get a bounce the next day, and have to reply
   by going to a web page.)

   No, I'm not talking about Big Brother approaches like in John
   Walker's http://www.fourmilab.ch/documents/digital-imprimatur/ .

   Walker boasts a very learned ("learn ed") helplessness.
   He starts out by saying he has cut and pasted together parodies
   of the bad guys' arguments for various totalitarian features.
   Then he says all those bad features together are the only way we're
   going to get secure computers.  And guess what, the combination
   (which he confusingly calls "the secure internet") is really nasty.

   The problem is that at each point he does not say that this individual
   issue can be addressed in different ways, that details are all-
   important.  You can't sift out what ideas he actually likes and
   dislikes, it's all one depressing lump.  Spare me, I already know
   how to be depressed.  He ends by saying, "Of *course* this isn't
   what I want."   Okay, then, what exactly *does* he want?

   Mike, are there any zombies that find out your credit card or
   PayPal account and make payments based on it?  If so, that's much
   more profitable to the zombie-deployer than a zombie that's just as
   hard to write, but sends spam instead of collecting money directly.

5) Challenge via SMTP error (Mike Van Pelt 6/4, Mark Lentczner 6/5, others)

   This has been debugged already, but I want to make the point that
   SMTP servers shouldn't be involved in the solution initially.  Whatever
   it is should be implementable on the recipient's computer, maybe using
   somebody's website too.  Later, when the best solutions settle out,
   we can optimize them by letting SMTP servers assist with whatever is
   already going on, as long as the SMTP server is doing something at the
   request of the recipient.  (SMTP belies "intelligence at the edges".)

   One problem with existing challenge-response systems is that they
   challenge in the style of mail bounces--with a return address other
   than the recipient--rather than as a friendly note coming From the
   actual recipient (like vacation notices (which I know have
   problems too)).

6) Sender puts up a bond (Robert Woodhead, 6/4)

   I think your most important point is that a person's investment as
   a sender is limited.  (Mentioned in #4 above.)  The beauty of the
   Digital Silk Road is its simplification of the bond idea: the
   sender puts as much as he's willing to spend into the request
   packet, and the recipient puts as much as he wants to refund in
   the response packet.  If the request contains no money but the
   recipient has the sender whitelisted, then no refund message
   is needed.  Instead of a protocol with five forth-and-back
   messages, you've got one forth, and zero or one back.  Also,
   if there are intermediaries (and there are), the only response
   needed is generated at the end of the chain.

   So, while DSR isn't the only way, I would look for a solution
   that doesn't add anything to the existing protocols, but
   somehow either goes around (via web sites) or through them (via
   polite bounces or refunds in email).

7) Whitelist vs. forged "From" (Mike Albaugh, 6/5)

   Although any zombie can forge a From, there are other fields that
   are harder to fake, and getting harder.  Obviously
   signatures can be used, and obviously eventually zombies could
   find what signature to use (but see three paragraphs down).

   Also, it's not so easy (not to say impossible) to guess what
   addresses are on a recipient's whitelist.  The "likeliehood
   of modern SPAM to have a forged 'from' line that matches
   your whitelist..." is currently extremely LOW for me.
   I remember one virus From <a friend> with Return-Path <a relative
   of a friend who also had my email address>.  A zombie on a friend's
   computer could say it was From them, but then I'd know whose
   computer needed fixing.

   An interesting twist would be for ISPs to put spam filters
   on messages from their customers.  By default anyway.

   I think we should look at the current state of things and find
   solutions that can stop 99% of the problem now.  In the longer
   run we can hope for incremental improvements to fix what
   further problems actually do turn up, and more secure systems in
   general (to repeat: no, this doesn't mean Big Brother).

8) No tech can stop spam (Trevor Blackwell's Lemma, 6/5)

   See my comments at the end of #4 & end of #7.

   No disaster is 100% preventable in principle.  Therefore we should
   learn helplessness.   The fallacy is that we must solve every
   possible problem before we solve the problems at hand.

   We could have interesting discussions of your individual points, 
   but you speak overall ("Yeah, right") as if you're not interested in 
   that, so okay let's not for now.  So there.

9) ISP does metering, $10K bill (Barry Shein 6/5, Mike Albaugh 6/4)

   I have no problem with ISPs offering services to make our spam
   solutions more efficient, once those solutions are shaken out.
   For instance, having it paid out of your ISP bill seems nice.
   But getting the ISP involved up front unnecessarily is steering
   toward the deadlocked committee meeting that Barry himself
   mentioned.

   About the $10,000 charge from your ISP, or from whoever.  The
   way it works is that you pay someone a reasonable amount up front
   and get to send a limited number of paid emails for that.  If you
   try to exceed that, it just stops happening.  If that happens you
   find out that you've got a zombie, and you can deal with that or
   not, but you're not out a lot of money.

   Mike says users don't want to hear it.  Another reason for the
   ISP and SMTP server not to be involved.  Then there's no one
   with a need to listen to the infected user's whining.
   
10) Mechanism vs. policy, what vs. how.

   I seem to be developing a theme, that we
   should avoid monolithic solutions and do things that can be
   adopted incrementally.  The cliches are "separate mechanism from
   policy", and "what" from "how".  The ideas of challenging, vs. 
   whitelisting, vs. charging; when, how much, on whose behalf and under 
   whose control: these are "what" questions.  Also, what happens
   at different people's user interfaces.  If we can explore the
   different whats, the hows aren't so important at first.  The
   best places for experimentation are the recipient's computer, and web
   sites.  Once one or two good whats are found, the rest of the email 
   system can be optimized around them.

 --Steve