[ILUG] spam: requiring signed email

[Paul Jakma]

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:

Sender: some-well-known-list
Recipient: you

and hashing that?

> Problems:
> 
> - 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
>   sa-learn.

Yep.

>   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
>   through.

If the scheme is just a hash, surely they can "mint" tokens 
themselves anyway?

>   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:

Sender: joe.bloggs
Recipient: you
Recipient: list

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:

Sender: list
Recipient: you
Recipient: list

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.

> --j.

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
	warning: do not ever send email to spam at dishone.st
Fortune:
You have an unusual understanding of the problems of human relationships.