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.
The pgp-sender-effort body would be a standard ASCII armoured PGP
message of the following text:
Sender: <sender address>
Recipient: <recipient address>
[ ...... ]]
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
1 (optional). Address in Sender field matches address in email From.
2a. one of the user's email addresses was listed in a Recipient
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
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. 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
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).
Paul Jakma paul at clubi.iepaul at jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam at dishone.st
Interchangeable parts won't.
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!