User:David MacQuigg/Sandbox/Email security

Talk: Email security is such a huge topic, we could write a book. What are the most important things we can say to students in just a few pages?

---

This article on Email security provides a brief overview of the ways in which email systems may be abused, and the techniques that are most effective in fighting that abuse. We classify the vulnerabilities according to their locality in Figure 1 of Email system, repeated here for convenience. We assume the reader is familiar with that article.

(CC) Image: David MacQuigg
Figure 1 Actors (Users and Agents) and their roles in an ideal email system.

Client vulnerabilities

After running a malicious program, perhaps from a phony website or attached to an email, the user's computer may become infected with a zombie program controlled by a remote criminal system. This can result in stolen passwords or the loss of other personal and financial data, or the sending of spam from the user's computer.

Users should be:
1) trained to not run any programs that may infect their computer.
2) required to maintain secure passwords.

Note: These requirements are only guidelines. The same level of security may be provided in some other way. For example, there is less need for passwords if every user can be authenticated by their address on a local network, secure from any outside intruder.

MSA vulnerabilites

An MSA may be tricked into relaying mail from an unauthorized source, or from an authorized source that has been compromised. Some large mail services, eager to get new accounts, may allow criminals to sign up for free accounts.

MSA agents should:
1) authenticate any user attempting to submit an email.
2) require their users to maintain secure passwords.
3) treat new accounts with special caution, ensuring that the benefits of abuse are less than the cost of establishing new accounts.

Transmitter vulnerabilites

The Transmitter is the weakest link in the passage of email from Author to Recipient. This may be inevitable, given the necessity for a communications link between unrelated parties across the open Internet. All other links in Figure 1 are between parties that have at least an indirect relationship with each other.

The Internet link is uniquely vulnerable to criminal intrusion. It is very easy to set up an exact replica of a legitimate transmitter relay, duplicating everything from message headers, to the envelope Return Address, to the name of the legitimate transmitter, everything but the transmitter's IP address. That has to be the actual transmitter address, or there is no TCP connection.

Criminals never use their own names in malicious transmissions. They will either make up a new name, or forge the name of a trusted domain. Criminal use of a trusted domain name provides better access to victim systems, and damages the reputation of the trusted name.

Domain owners who care about their reputation should publish authentication records protecting that name. Agents who operate transmitters on behalf of another domain (as opposed to transmitting under their own name) should work closely with the other domain to ensure that the domain's authentication records are kept up to date.

Domain owners should:
1) publish SPF records for their authorized transmitters (outgoing Border MTAs of their authorized Transmitter agent).
2) publish SPF or Sender ID records as needed to protect the use of their name in Return Addresses and in From: headers.
3) publish DKIM records as needed to provide digital signature protection for the entire content of email messages.

Transmitter agents should:
1) publish SPF records with the IP addresses for their own authorized transmitters.
1a) work with their MSA agents and other domain owners to publish additional authentication information helpful in their business situation. This could include SPF, Sender ID, and DKIM records.
2) implement rate limits on outgoing mail from each user account.
2a) work with their MSA agents to provide additional security as needed in their situation. This could include analyzing the content of messages, or providing alerts to anyone who might be an innocent source of abuse.
3) respond promptly to reports of abuse, even if their transmitters are not responsible.
4) maintain a good reputation for the domain names used by their transmitters.
5) comply with all standards relating to their operations, thus helping receivers to avoid mistakes affecting security.
6) handle bounce messages (Delivery Status Notifications) in a way that provides maximum reliability while avoiding abuse. This could include adding validation codes to the Return Address on every outgoing message.

Receiver vulnerabilities

Receivers have the biggest burden of all. Over 90% of incoming messages are spam, many from senders that are transmitting such huge volumes that it would be a Denial of Service (DoS) attack on the receiver if it were unavoidable. Luckily, most of the high-volume sources can be identified by their IP addresses, and blocked without further processing.

Separating the few good messages from this flood of sewage can be a challenge. Traditional spam filtering techniques include statistical analysis of message content, looking for words and phrases that have high probability as spam indicators, and looking for abnormalities in the message headers, using heuristic rule-sets that are updated periodically to follow the latest trends in spam. Both of these techniques reject some legitimate messages, and there is always a compromise between minimizing false rejects and minimizing the amount of spam that gets through to the user's inbox.

A recent trend in receiver security is to rely less on statistical techniques, and more on the reputation of the sender. If a sender has a good reputation, messages from that sender can be "whitelisted" and passed directly to the recipient's inbox, not suffering the delays and possible losses in a spam filter. Blocking spam at the source is far easier than at the destination, because transmitting agents know their customers. Many well-managed transmitters send no spam at all, and the agents operating those transmitters have a good reputation.

Receiver agents should:
1) block high-volume sources of spam efficiently. This is typically done with an IP blacklist.
2) provide clear and concise feedback to the senders of rejected messages, so that mistakes can be corrected quickly. This should be done in the SMTP reject message.
3) authenticate the domain associated with the transmitter. This is typically done by comparing the transmitter's IP address to SPF or Sender ID records.
3a) perform additional authentications as needed for better security. This can include SPF checks on the Return Address, Sender ID checks on the header From: address, and DKIM checks on the entire message content.
4) assess the reputation of the sender. This can be done using local or shared whitelists.
5) filter any messages that cannot be rejected at authentication, or whitelisted at the reputation check, and use the resulting spam score to prioritize filtered messages for review by the recipient.

Forwarder vulnerabilities

A Forwarder is very much like a Transmitter, but instead of sending a message to an unrelated Receiver, the message goes to a related party, the Mail Delivery Agent designated by a recipient who has an account with that agent. Ideally, the recipient can ensure that the forwarding arrangement is secure, using a private alias at the MDA, and turning off spam filters, SPF checks, and any other mechanisms at the MDA that might conflict with the forwarding arrangement. In reality, recipients (non-expert users) don't do any of this.

The resulting confusion leads to a special vulnerability that we can associate with the Forwarder. Messed up forwarding arrangements often lead to lost messages.

A Forwarder should: 1)