The 'to' header isn't required to deliver email. You could essentially encrypt the entire header block if you're changing the protocols. What actually delivers

The 'to' header isn't required to deliver email. You could essentially encrypt the entire header block if you're changing the protocols. What actually delivers the email is the 'RCPT TO' command on the SMTP transaction. At the moment, SMTP requires that you also give it a 'MAIL FROM' command that tells who the sender is. Most servers also require a HELO that identifies the sending server, but you can basically get away with putting anything in there. But now you're left with an authorization problem. Currently the combination of these three fields is what determines whether an SMTP server will accept the message for delivery or relay. If all you get is the 'RCPT TO' command, then you have no idea who's sending the message until it's decoded. This puts the authorization task on to the recipient's computer. So the 90% of all email that's spam will now need to be parsed on the desktop. One solution here would be to include another section above the encrypted email header+body that is the authorization block. Now the recipient's server holds then entire encrypted message using the RCPT TO as the destination. The recipient downloads a list of auth-blocks addressed to them and issues back a DENY if they don't want the message. The authorization block would identify the sender who has signed their identity in a publicly identifiable way. BAM! There goes spam. Unfortunately the BIGGEST problem in all this is Microsoft. They could have added simple-to-set-up PGP to Outlook years back. So how likely do you think it is that they'll switch to any new protocol. (The anti-spam industry really lives in fear of Microsoft waking up and working on implementing any of the new protocols that would instantly stop spam.) In all this, I'm ignoring web-based email for all this: that's a much bigger security nightmare as you have to trust your private keys to the third party