Atwill.Com

Since there is a lot of talk and work recently on email encryption I thought I would attempt to list the requirements.  These requirements are a combination of things that I would want and some things that others have asked for.

1. Easy to use - Everybody and their Grand MOM should be able to use it.  That means it shouldn't take 20 minutes to apply for and setup keys and certificates.
2. TKO (Trust No One) - There can't be any organization responsible for holding encryption keys.  All keys need to be generated by the client and never leave the client.
3. Key Negotiation (Perfect Forward Secrecy) - No key should be able to decrypt a message after the fact.  That fact that your machine and key is compromised it shouldn't be able to decrypt all your messages from the past. 
4. Meta data protection - Headers must be encrypted.  The email headers can reveal a lot of information in addition to the Sender and Recipient information. 
5. Key Management - Keys need to be revoked and updated.  Losing your private key shouldn't mean you lose all your messages.
6. Compatibility - Should be able to work with most existing mail clients.  Without compatibility you will not get everyone on board.
7. Spam Free - Spam filtering techniques need to be leveraged to block unwanted encrypted emails.  These need to work as well as those available today on non-encrypted email.
8. Standardization – There needs to be a single agreed upon standard that allows all mail clients to compatible with each other.

 As you can see some of these are tuff requirements while some seem to contradict each other.  There is going to be a long road ahead for those attempting to standardize this. 

There are lots of articles online that will teach you, "How to connect to a mail server using telnet and send an mail."  Lots of them have good information on SMTP command syntax.   The problems start when you are trying to do something that is hard or can't be done using telnet.   Because of this I wrote this handy telnet replacement tool for debugging SMTP.  Below are the top reason to use this to test with instead of telnet.

1. Authentication - Sending encoded strings using telnet requires you to build the authentication strings yourself using a mime tool.   This tool has authentication built in so you can just specify the user name and password.
2. TLS Encryption - This tool has the ability to connect using SSL directly or issue the StartTLS command and work securely.
3. Telnet protection - Many servers do not allow commands to be send one character at a time.  When they detect this they will disconnect you thinking you are a hacker.   This tool will buffer the response while you type and send the full command when finished.
4. Multihomed IP Address selection and binding - Telnet will always use the main IP on the machine.   When using this tool you can choose from any IP address on the local machine.  This makes trouble shooting IP address reputation issues very easy.   For example if a single IP is black listed you can easily test using that IP.
5. Remembering SMTP Commands - This tool has macros built in for MAIL FROM, RCPT TO, DATA, and many other commands so you don't need RFC 2821 with you while testing. 

The SMTP Server Connection Diagnostics Tool, released by SocketLabs, Inc. can be found here: http://www.socketlabs.com/smtp-server-connection-diagnostics-tool/