(For those who feel the need to send passwords, credit card numbers, Social Security numbers, and various other sensitive information via e-mail.)
I am going to talk about the network aspect of e-mail security, and therefore will address points 1 to 5 in the diagram below. First, a little very basic knowledge about what happens to your e-mail when it passes through a network:
When you send an e-mail, to state the obvious, there is no direct electrical connection between your computer and the computer of your recipient. In fact, as it passes between your computers, the e-mail not only passes through wires, but "hops" its way through many (conceivably many, many) routers and switches. Every time the e-mail passes through a router or switch, whomever controls that router or switch can VERY EASILY capture the digital contents of the e-mail if it is not encrypted. If you are sitting in a coffee shop using an open access point, for instance, the person next to you may be recording your e-mail during its very first hop from wireless card to wireless router. And the owner of the shop could conceivably have software running in the wireless router doing the same.
Summary of rules for secure e-mail communications:
(1) (2) (3) (4) (5) ---------- ----------- | | | | Sender =========| Sending |-----------| Receiving |========== Recipient | Server | | Server | | | | | ---------- -----------
(3) So, by the numbers: for various technical and historical reasons, segment (3) above between the two servers is virtually always unencrypted. It is not strictly true, but for simplicity at the moment lets say that for the case of a simple unencrypted e-mail, YOU CAN NEVER HAVE A SECURE COMMUNICATION IF SENDER AND RECEIVER ARE USING DIFFERENT E-MAIL SERVERS. Ie. if I us Yahoo and you use Gmail, it does not matter what else we do, when passing from the Yahoo servers to the Gmail servers, the e-mail is exposed to snooping.
Thus Rule 'a' above. If (2) and (4) are the same server, we eliminate all problems with segment (3). For Rule 'c', choose a small service with an emphasis on privacy and security. The bigger the company, the more employees who have potential access to your e-mail. (For the biggest of the free public e-mail providers, this is probably at least hundreds of people, and maybe thousands.) Best of all, use an e-mail server under the personal control of either sender or receiver (ZERO employees who have access to your e-mail).
(1)(5) To satisfy Rule 'b', only use an e-mail service that provides encrypted connections to the server:
Finally, a brief mention of something that should see more use, at least by technical people: make all of the above irrelevant by having both sender and receiver use an e-mail client with GPG encryption configured and enabled. After sender and receiver exchange public encryption keys for two specific e-mail addresses, all future e-mails between those two e-mail addresses are encrypted from the moment they leave the sender's e-mail client until the moment they are received by the recipient's e-mail client. If encryption is not desired for any particular (or even most) communications simply use a different e-mail address then the one configured for encryption. A little effort is involved on both ends for setup, but this is by far the best solution. Most desktop e-mail clients have this capability built-in, it basically just has to be turned on. Webmail users, particularly of gmail, may find the Firefox FireGPG plugin to be useful.
And if you should choose to ignore all of the above advice and send a password, credit card number, or other personal information via insecure e-mail, you would be advised to not include certain important key words in your e-mail. You might think, for instance, that there is such a vast amount of e-mail passing through an internet switch such that no one will ever notice your insignificant little e-mail. But what if they are filtering the traffic for key words, such as "password" or "credit card"? Suddenly your "insignificant" e-mail containing the word "password" becomes a part of a much shorter list of interesting (to a hacker) e-mails.
Further reading: 
This post is most particularly triggered by the fact that I have *finally*, purely by accident and no thanks to the existing documentation, figured out how to do copy&paste (not exactly a minor feature on a "PDA" phone):
After several weeks of use, some other thoughts.
lockbin.com has a reasonable method for restoring some security to the e-mail arena. The service is a little bit inconvenient so it does not qualify for daily use, but especially when you are dealing with someone who resists taking any precautions at all, this might be quite a good solution.
To use lockbin you first deliver a shared password to the other person, preferably by some means other then the same e-mail address lockbin is going to use to announce the arrival of a message. Then on lockbin's SSL-encrypted (https) website compose and send your message.
The recipient receives an e-mail which says, in part:
"Hopefully, your friend has already given you a special 'Secret Word', which will un-encrypt the message so you can read it."containing a link back to his waiting message on the lockbin website. The recipient must then enter the 'Secret Word' to see the message. If he wishes, the recipient can then reply to you using lockbin again, in the same window.
Needless to say there are some security holes in this arrangement, like the need to trust the system administrators of lockbin, and the need to send the password by some preferably secure channel.
This article talks about the increasingly tight noose around the throats of users of electronic communications in Europe:
Now, the Interception Modernisation Programme plans to force all electronic communication providers (wireless companies, cable companies, internet service providers, etc.) to keep a record of every communication by every customer for a period of 1-year, and make the data available to 653 public agencies.
You must consider all unencrypted e-mail communications to be *public* communications being read by any number of hackers and bureaucrats, and susceptible to being posted on a public website at any time.
I really do not understand people who do take measures to protect their privacy, which seems to be the vast majority of people. But there are a lot of things I do not understand, I guess....
This would be the document of record from Amazon....
First, configure ElasticFox so that there is one window connected to each of the two accounts (sending and receiving). Also, setup two terminals, each one configured with the necessary environment variables to use the standard EC2 command line tools for one of the accounts.
Second, a logistical observation.... As I am not the owner of the Amazon accounts I am using, but rather a consultant using and operating the accounts on behalf of the owners, I do not have access to the "AWS Management Console". I "only" (this is actually quite a lot) have the privileges conferred by possessing the account keys. Using these privileges I can transfer a server AMI, but there appears to be no way to transfer an EBS store between accounts. So the first step is to login to the sending account, mount any EBS stores that are desired, copy there contents into the volatile area of the server, and create a new AMI that will contain both the server and the data.
One can get the list of AMIs belonging to the sending account thusly:
ec2-describe-images -o self
Now (briefly) make the just-created AMI containing the data public. (One can make the AMI visible only to one account, but I am under time pressure and I do not at the moment know the AWS account number of the receiving account):
ec2-modify-image-attribute ami-1573907c -launch-permission --add all
Now in the receiving account start the AMI (point and click with ElasticFox), then back at the command line open SSH in the firewall (necessary if this is a new account):
ec2-authorize default -p 22
In a terminal login to your running server in the receiving account, using the keypair you used in ElasticFox when the server was started, and the "public DNS" for the server being reported by ElasticFox:
ssh -i ~/ec2/id-keypair firstname.lastname@example.org
Go back to the sending account and reset the transferred AMI to the private state:
ec2-reset-image-attribute ami-1573907c -l
Double-check the permissions on an AMI with:
ec2-describe-image-attribute ami-1573907c -l
(It would appear to return nothing when there are no non-private permissions set....)
Back to the receiving account to: use ElasticFox to create a new EBS store, format it, then move the data from the server's volatile storage into the EBS. Also create and associate an ElasticIP to the new server. (This means that the server's "public DNS" will change, and the terminal login must be redone.) Open the http port (80).
On the new server, edit the Apache configuration. Delete unneeded MySQL databases. Start Apache and MySQL. Test.
Change the keys in the EBS snapshot script and test.
Change the keys in the server snapshot script and make a bundle of this just-started AMI for the new account.