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
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
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
participants (4)
-
Adam Shostack -
dlv＠bwalk.dm.com -
Raph Levien -
tallpaul＠pipeline.com