Not necessary, if the stamp cryptographically includes both the
sender and recipient addresses.
Then the recipient needs a way to check the crypto signature - and even
then, you have to figure out a way that stamps can't get reused with
forged sender addresses. (That is, X sends mail to Y, with a valid
stamp <X,Y>. Spammer gets hold of a copy (through any of many possible
means) and sends mail with that stamp, to Y, forging X's address as the
sender.)
But the recipient Y will be able to tell if he's seen the same stamp
twice. That's trivial to deal with, especially since most modern MUAs
(well, Eudora and Apple Mail, anyway) index their mail archive already
by default.Why is this?
Why? Simply because all the hashcash protocols I've seen outlined, or
that I've thought of, involve some kind of challenge by the recipient
which must be answered by the "payer". A simple example might be "find
a data blob whose SHA-1 hash has these 20 bits set to these values".
As I said, I don't know whether this is an inherent property of
hashcash (by which I really mean "proof-of-work", even though,
strictly, hashcash is but one form of p-o-w) or whether it's just an
artifact of the hashcash schemes I am aware of. But until someone
shows me one which doesn't have that property, I have to operate under
the assumption that no such thing exists.
Ah, I see what you're missing. What you need is more like "find a data
blob Y, which is different from this challenge X, where both X and Y
have the same first N bits in their SHA-1 hash". The challenge can
then be arranged so that it contains various pieces of information
about the mail itself, such as the sender, recipient, creation date and
time, and possibly part of the content and/or some of the other header
fields.