[ILUG] spam: requiring signed email

[Paul Jakma]

Just curious... could spam be killed by requiring an encrypted
attachment to every email? Basically:

- introduce a mime section/content-thingy to allow for the
(sender,recipient) tuple to be attached to an email, encrypted. Ie to
allow for a mime section to allow a client to verify the sender has
put some effort into sending this email to the client's user.

Something like:

<mime boundary>
Content-type: application/pgp-sender-effort
Content-Disposition: inline

<pgp-sender-effort body>
<mime boundary>

The pgp-sender-effort body would be a standard ASCII armoured PGP 
message of the following text:

Sender: <sender address>
Recipient: <recipient address>
[Recipient: .....
[ ...... ]]

It would be encrypted with the private key of the sender, such that 
it could be decrypted with the sender's public key.

When you receive an email, your MUA could decrypt the sender-effort 
part (retrieving the key from a keyserver if neccessary), and check 
that:

1 (optional). Address in Sender field matches address in email From.

and

2a. one of the user's email addresses was listed in a Recipient 
line.

or

2b. The key used is 'trusted' to send me email.

If true: accept mail
If not: dump (or put in spam folder, until such time as this is 
             widely supported)

For email lists, part of the signup/confirmation process would be to
'trust' the list key to send the user email. MUAs would need to make
this reasonably easy for people to do[1]. The cost or effort to the
list would be O(1) per reflected message, ie it would form one
pgp-sender-effort part for a given mail to the list, and use that
single part for all resent messages (with Sender in pgp-sender-effort
set to sender of email).

The benefit being that UCE would suddenly cost a lot of computing
time - each message would require calculation of an encrypted
pgp-sender-effort part. So sending out n emails would require
calculating maybe n/x seperate pgp-sender-effort parts. (where x is
the maximum number of addresses one can additionally send an email to
and still reasonably expect common open-relay MTAs not to barf on the
X number of recipients). I'm not sure what that number is, but I'd 
guess it's less than 100, so if we assume its 200, sending a million 
emails will require at least 5000 pgp-sender-effort parts to be 
calculated. 

The more expensive, computationally, the algorithm and key size
mandated for this pgp-sender-effort part is, the better.

1. This could be done with an additional
pgp-sender-effort-trust-request part, a part that could be included
in the list's 'welcome to' or 'confirm' email and which the MUA would
use to ask the user "this list wants to send you email, do you want
to allow it?". Obviously spammers might start sending out such emails
in the hope that dumb users would click on "Yes", however, there
really is no protecting such users. If someone wants to trust
spammers to send them email, great. (and spammers /do/ have a right
to send spam to those who sign up for it).

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:
Interchangeable parts won't.