On Mon, 9 Feb 2004, Justin Mason wrote:
> Computational proof-of-work scheme. See hashcash. It does *exactly*
> this but a little bit more nicely, I'm afraid. ;) It's supported in
> SpamAssassin 2.70 dev version.
Why are you afraid of it being nicer? :)
What is the crypto side of it btw? Just a hash? Isnt that a bit weak
computationally? Further, what's to stop me doing:
and hashing that?
>> - recipient has to tell their spamfilter what addresses they expect to
> receive mail on.
Yep. No avoiding this. And it's surely implied by including Recipient
information in the hash? (pointless otherwise). If it is integrated
into the MUA, then the MUA can use the configured email addresses
anyway (and provide an option for user to add more, as the MUA might
already do anyway to support, eg, roles).
> For me, that's "anything at jmason.org, anything at taint.org, jmason at
> cpan.org, jm at apache.org". If you include mailing lists, then that
> includes "these mailing lists: camram-spam, SpamAssassin-users,
> SpamAssassin-dev, SpamAssassin-cvs, ilug, social at linux.ie, etc. etc.
> etc. etc." repeat for several hundred addrs I think ;)
Hmm... mailling lists? The mailling list is not your address. For the
ml you want to tell your effort-filter:
"i'm on these mailling lists"
but you need to able to establish the list actually _did_ send it,
which just a hash of a 'cookie' will not do. Hence, you are indeed
probably better off detecting (dynamically or explicitely by user)
dealing with lists seperately.
> We're thinking of ways around this, probably by using data from
> Otherwise spammers can "mint" one token for the sender/recipient pair,
> where recipient is "everyone at world.com", and unless the recipient
> checks that they do expect to receive mail at world.com, it'll get
If the scheme is just a hash, surely they can "mint" tokens
> You could avoid this by using a globally shared double-spend db. but
> that means network traffic to a single point of failure, and a race
> condition for when a mail is sent to a mailing list and cc'd to a
> recipient directly. it's not workable.
In my provisional scheme it works.
The directly mailed copy has a cookie of:
And is encrypted with the private key of joe.blogs - you verify this
by retrieving joe.bloggs' public key from the public key servers and
checking that it decrypts the cookie, and that one of the key UIDs
matches the Sender. (the plaintext header, eg Content-Description,
for the cookie obviously must have the key id).
The list copy will have:
Ie the list will replace only the sender line and verification
proceeds as above. (indeed, come to think of it, list confirm doesnt
even need to be special).
Another thing that's missing is that the cookie will need to have a
have a message digest or even a full cryptographic signature of the
message body inside it, otherwise cookies could be reused.
> - Second: there's a good chance spammers now control enough CPU power
> around the world in r00ted win32 boxes -- probably more than most of the
> supercomputers in the field -- to generate sufficient hashstamps to do
> exactly what they're doing anyway. This is a *big* issue ;)
There's almost no defence against this really. The spammers' trojans
and worms will just be made more and more sophisticated as anti-UCE
measures are increased. SPF, C/R, crypto-cookies - wont do any good.
Paul Jakma paul at clubi.iepaul at jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam at dishone.st
You have an unusual understanding of the problems of human relationships.
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!