Re: Only accepting e-mail from known parties

How about one-time electronic stamps. 
 
I generate a large-ish number of long-ish random numbers. 
 
I store these into a data base on my system. 
 
I send one e-stamp to all of the people I want to communicate with and vice
versa. 
 
Each person uses the e-stamp in the header or some other area of their
message to me easily accessible to my mail bot. 
 
My bot reads the e-stamp and then checks the data base to see if the stamp
is valid. 
 
If not, then /dev/null. If so, then: 
 
     a) send the message to me; 
     b) delete the used e-stamp from the data base; 
     c) send a confirmation of received message with a new e-stamp in it. 
 
Thoughts? (I see one problem with this but it should be able to be worked
out once the basic method is agreed to). 
 
--tallpaul

The basic problem is that (personal) spam is a social, not a
technical problem.  If someone wants to annoy you via the internet,
they can do so.  You can raise the cost of their annoying you, but you
need to be careful not to make it difficult to talk to you.

	Stamps are an annoying solution unless the stamp buys the
sender something that the sender wants (perhaps such as
pseudononymity).

	It would seem that only accepting signed mail, and caching the
hash of the signed part would work pretty well, and also not require
anything (other than a signature) from the remote end.  The cost of a
spam is the time to generate a new key pair.  (You probably need some
way to add new keys, for people to be able to say 'I'd like to talk to
you.')

Adam


| If not, then /dev/null. If so, then: 
|  
|      a) send the message to me; 
|      b) delete the used e-stamp from the data base; 
|      c) send a confirmation of received message with a new e-stamp in it. 
|  
| Thoughts? (I see one problem with this but it should be able to be worked
| out once the basic method is agreed to). 

-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume

I think the underlying problem is that the way PGP signatures are used by most
people, they validate a text, but allow it to be quoted out of context in an
e-mail or Usenet forgery. E.g., suppose Alice posts a PGP-signed text in
alt.sex. Bob forges a Usenet article in misc.kids, making it look like it came
from Alice and quoting her PGP-signed body. Alice will have a tough time
convincing the public that she didn't post it -- after all, her signature
verifies. (There are many people on the net who don't comprehend the
argument that the Path: is clearly bogus). Or: Bob writes Alice a sexually
explicit letter and forgets to say "Dear Alice" in the signed block. Alice
forges an e-mail to Carol, making it look like it came from Bob and quoting
the signed block. Bob would have to realy on the analysis of Received:
headers to repudiate such a forgery.

I suggest to the kind folks working on PGP 3 that there should be a standard
protocol to include within the signed portion the information on when and for
whom this text is written: i.e. the list of e-mail recipients and/or Usenet
newsgroups, which could be easily compared with the RFC 822/1036 headers of
an e-mail/Usenet article. Perhaps there could be a new option for PGP to look
_outside_ the signed block and match the headers with what's inside the
block. E.g., suppose the signature block says: this text was written by
alice@zog.org, posted to alt.sex and alt.sex.banal and e-mailed to
bob@masons.com. Suppose PGP is asked to check the signature in a file that
purports to be a e-mail or a Usenet article and has some headers before the
signed portion. If there is a list of To: recipients, and it includes someone
other than the recipients listed within the signed block; or if there is
a Newsgroups: header, and it includes newsgroups not listed within the signed
portion; then the input is bogus. For compatibility with the existing
software, if the signed block doesn't include this info, then this checking
should't be done, of course.

(Yes, one could do this with a wrapper to PGP, making the whole thing even
more user-hostile.)

---

Dr. Dimitri Vulis
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

Dr. Dimitri Vulis wrote:
> I suggest to the kind folks working on PGP 3 that there should be a
> standard protocol to include within the signed portion the information
> on when and for whom this text is written: i.e. the list of e-mail
> recipients and/or Usenet newsgroups, which could be easily compared
> with the RFC 822/1036 headers of an e-mail/Usenet article. Perhaps
> there could be a new option for PGP to look _outside_ the signed block
> and match the headers with what's inside the block. E.g., suppose the
> signature block says: this text was written by alice@zog.org, posted
> to alt.sex and alt.sex.banal and e-mailed to bob@masons.com. Suppose
> PGP is asked to check the signature in a file that purports to be a
> e-mail or a Usenet article and has some headers before the signed
> portion. If there is a list of To: recipients, and it includes someone
> other than the recipients listed within the signed block; or if there
> is a Newsgroups: header, and it includes newsgroups not listed within
> the signed portion; then the input is bogus. For compatibility with
> the existing software, if the signed block doesn't include this info,
> then this checking should't be done, of course.

In fact, the security multiparts standard (RFC 1848) includes a
provision for signing the headers as well as the body of a message.
The security multiparts can be used with PGP, and there is even an
Internet Draft for it (draft-elkins-pem-pgp-02.txt), but there is not
yet consensus for adopting this as a standard on the pgp-mime mailing
list. Perhaps your example can be used to argue one the advantages of
the security multiparts approach.

Raph

Adam Shostack <adam@homeport.org> writes:
> 	It would seem that only accepting signed mail, and caching the
> hash of the signed part would work pretty well, and also not require

Keeping a hash of the signed part sounds like an excellent defense from the
attack of recycled messages. "Your mail blah blah is being returned to you
because it appears to be similar to the e-mail you send on dd/mm/yy". Cool.

> anything (other than a signature) from the remote end.  The cost of a
> spam is the time to generate a new key pair.  (You probably need some
> way to add new keys, for people to be able to say 'I'd like to talk to
> you.')

When thinking of a protocol, it's useful to consider what do we do in "real
life" to reach an important person: Either ask a common acquiantance to
introduce you, or go through a secretary.

Say, Alice wants to send e-mail to Bob who doesn't accept e-mail to strangers.
Alce may learn that Bob accepts Carol's e-mail, and ask Carol to forward
Alice's e-mail to Bob (with Carol's signature).

An interesting idea would be for Bob (together with other people) to pay some
David to screen their e-mail received from strangers (manually, or with the
help of some programs) and to decide whether to pass them on to Bob or to
discard it. E-mail from known senders goes straight to Bob, and e-mail from
strangers goes to David the screener. Not unlike "real life".

---

Dr. Dimitri Vulis
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps