> In the case of email, meeting that goal with end-to-end encryption mechanisms > like S/MIME or PGP is necessarily going to mean having a nonnegligable amount > of email traffic encrypted. The minute that happens spammers are going to join > the party in a big way precisely because of the ability this confers to get > past transport-side content inspection and filtering.
This is a real serious problem. But it may also be an unprecedented golden opportunity. The reason we have spam is that email is default 'permit'. What if encrypted email were default 'deny'? This would require the user whitelist anyone that was to be communicated with in encrypted email. The normal unencrypted systems would still be in place, default 'permit', and all the filtering would still work just as before. So, the very first time I email someone, it MUST be in plain text. They then whitelist me (if they wish), and henceforth our mail is encrypted. If you labeled the whitelist or blacklist buttons 'Friend' and 'Unfriend' probably millions of people would use such a system reflexively. This would require some technical changes - the email server would need to have a list of whitelisted people for each user. I think most large systems probably already have a way for individual users to whitelist or blacklist addresses or envelope senders, so that shoud not be too difficult. And these lists would be small, most people only communicate with a few others - family, friends, work. There would need to be some way for mail server to mail server connections to indicate a message is encrypted, since at that point the server sees only the connecting ip and envelope sender. Perhaps that could be done by another hack on 'HELO' in the connection dialog (as is done now to indicate extended commands with 'EHLO'), perhaps something like changing the last letter to E, 'EHLE'. (E for encrypted ;-) ) >From the user agent point of view, if you want 'default to encrypted', the >user agent could try to send encrypted, if that fails, let the user know >immediately and ask them if they wish to send unencrypted. I think the changes needed to do this might be pretty easy to make; in Sendmail, at least, they could probably be done just though the normal sendmail.cf and some scripts. > So let me close by noting that quite a lot of spam originates > from infected PCs, and is done by sending those messages using whatever > submission mechanism that user uses, borrowing their credentials in the > process. Consider the result under a default deny system. If a spammer has hacked a machine, they may be able to use the users credentials, but they can ONLY send encrypted emails to someone who has whitelisted them. So they can't hack a machine and send out 10,000 emails - only ONE would actually be accepted. Their remaining choice would be to send unencrypted, in which case the usual filtering would be applied. Over time, as more and more people used encrypted email, spammers would have a harder time of it. -Mike _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
