On Wed, May 14, 2003 at 02:49:34PM +0000, Justin wrote:
Adam Back (2003-05-14 05:27Z) wrote:
Well there are different things you could hash. This simplest is just to hash the recipient address and the current time (to a day resolution).
The recipient looks at the token and knows it is addressed to him because it's his address. He stores it in his double spend database and won't accept the same token twice.
This is just broken.
How do you know what address the sender was sending to? You have no reliable access to envelope to: addresses.
Well the address the token was minted for is contined in the hashcash header, and the recipient knows what email addresses he accepts mail for. To take your example:
Joe bcc's james@nowhere.net, politely generating a hashcash token over james@nowhere.net and the mesID. Nowhere.net expands that alias to james.t.doe@treas.gov.
The sender as he Bcc'd james@nowhere.net thinks this the recipient's address, so it delivers to envelope address james@nowhere.net and for that delivery adds header: X-Hashcash: 0:030514:james@nowhere.net:b384c3cc66319383 Then the .forward file forwards to james.t.doe@treas.gov, who reads his mail; his MUA sees that the message is to james@nowhere.net an address he reads mail for, checks the collision: % echo -n 0:030514:james@nowhere.net:b384c3cc66319383 | sha1 000002e07c7aac5697396f41dbb277aee02f6517 sees there are enough bits of collision, and if he hasn't seen this token before he accepts the mail. The message will also contain one hashcash header per to or cc recipient. (Bcc recipients must be delivered separately because otherwise bcc semantics are lost -- other recipients should not learn from the hashcash headers that the bcc recipient received the mail).
Worse, even if there were a reliable mechanism, all it takes is one loose cannon with an open mass-mail list and as long as it doesn't delete whatever header (maybe delivered-to:, maybe something else) that indicates the list was an envelope to: address, one hashcash token works for one email to the entire list.
I take it this comment is about mailing lists? Mailing lists have to be treated separately. The sender probably can't afford to create a token for each recipient. (Also he doesn't know the recipient's addresses). Mailing lists deal with spam with filtered versions of lists.
After the validity period of a token has expired he can remove it from his double-psend database to avoid the database growing indefinately. (He can reject out-of-date mail based purely on it's date).
Isn't it simpler to use message IDs for replay detection? No need to look for replays using another mechanism when there's already one that works fine, and that many people use for dup detection today.
You have to cope with multiple hashcash headers when a mail has multiple recipients, Message-ID only suports one header. For USENET postings putting the hashcash token in the Message-ID can work because USENET uses the Message-ID to supress duplicates in it's flooding algorithm, and you could argue that there is just one recipient: USENET (or the cross-posted group list). Adam