Re: Thinking outside the box

How about simple end-to-end authentication?

Such as:

- When I receive a message, I look for a 'Password' header field. If 
there isn't one with my value, then I can be suspicious about the 
message. Depending on my requirements, I could discard the message, 
treat it as spammy, or accept it anyway etc
- When I send a message to someone, I have the option of telling them my 
password in a header
- The email client tracks passwords, so if I receive a message from 
[email protected], which included his password in the header, then 
whenever I send a message back to him, my email client automatically 
includes the password in the header. The passwords can be stored in 
address books, or published on websites if you wish, or whatever.
- Potentially different people could be given different passwords.
- There could be a way of sending an email to someone just telling them 
your password, and the email client could take the information from it, 
and delete the email (making it possible to automatically tell everyone 
of password updates, etc)
- The 'mailto:' url form could be expanded to include the password for 
having email links on websites.

(NB - By password, I mean something simple that could easily be 
transferred by humans 'offline' - not a cryptographically secure public 
key. It would be open to capture by MITM attacks, but I'm not sure 
that's such a big problem, compared to simple mass-mail spam)

When signing up for mailing lists, announcements etc, as well as giving 
your email address, you could give your password (possibly specific for 
that mailing list). The mailing list daemon would include the relevant 
passwords when distributing the messages.

There would be no need for a central authority, and it would be quite 
flexible. It could be implemented with a large degree of backwards 
compatibility - eg even if only 3 people in the world support the 
system, you could just treat a message as more 'trustworthy', if it 
includes the password, and do the current spam checking stuff if there 
isn't a password.

One downside would be that you couldn't easily specify multiple 
recipients in a single message; if you send a message Cc'd to 20 people, 
your email client would have to send out 20 copies, each with a 
different recipient password (including all passwords in a single 
message would publish the passwords to all the recipients).

All it would really need is some standard way of specifying the 
passwords in the header, and then, over time, email clients could add 
support for it.

It wouldn't be foolproof at all, but it would be simple to implement and 
should have the potential to cut down a lot of spam.



-

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53