Stopping Spam - A Path Towards "Secure-er" Email

Copyright 2005, IT GlobalSecure Inc. Further use or distribution is permitted only with attribution to IT GlobalSecure, Inc.

Abstract - A Paper, posted July 2005,  By Steven B. Davis, CEO & Cheryl S. Campbell, President , IT GlobalSecure. A New mail transport protocol, the Simple Envelope Transfer Protocol (SETP) is proposed to significantly improve the security of email and fight spam and malware
 

Stopping E-mail Spam and Malware without an Expensive Overhaul. Why current Methods Won't Work. This paper provides a simple approach to substantially improving the security of email against attacks. It has many of the benefits of the Sender Policy Framework, Sender ID, and Domain Keys security approaches, but with less impact on the infrastructure of major Internet applications such as DNS (for an excellent introduction to the various Internet mail security approaches, see http://e-com.ic.gc.ca/epic/internet/inecic-ceac.nsf/en/gv00298e.html). The essence of our approach is to change the email system from mailing messages to sending “envelopes”.

Email is the dominant form of communication on the Internet, but it is vulnerable to numerous attacks. Viruses, Spam, Malware, and Phishing have become so prevalent that they imperil the viability of the Internet itself as a useful communications medium.

The existing approaches to protect email focus on creating a list of “good mailers” – either through changes to the existing directory or through the creation of a new mail security infrastructure. The problem with this approach and most attacks is that many malicious forms of email come from “good mailers”… or at least mailers that are “good enough” to get through the security checks of the system.

The New Simple Envelope Transfer Protocol (SETP)

The key to our approach for securing email is to simply stop sending email and start sending “envelopes”. The current SMTP protocol includes both a header and a body. The body of the message includes a base text message and perhaps multiple embedded attachments (MIME). Our SETP would send a header, just as today, but would send pointers to the mail content (MIMP, as it were) that are identified by relative URLs to the sender’s mail return address. No absolute URLs would be allowed.

The relative URL would contain a unique mail ID that is included in the mail header today to generate a unique path for each message (effectively forming a directory path or database query to extract the message when needed).

This approach would stop most phishing and spam attacks because the ability to misrepresent or spoof a legitimate sender would require compromising the actual target email server… a much more manageable problem. This approach would also make malware and virus attacks more manageable as the malicious payload would have to sit on the sender’s server as opposed to being pushed through the Internet. Once detected, the malicious code could be removed from the server and immediately stop further distribution. Also, the sender would be more easily identified and held accountable for their actions. This approach also has a general benefit of reducing and smoothing out email traffic. Mail messages would be reduced to a small list of RURLs (relative URLs) rather than the massive objects sent out today. Receiving mail servers could either pull and parse the messages for their end users or forward the MIMP mail message for processing by and end user client application. The large portion of an email message could be pulled as needed. Not only would this have an enormous benefit for reducing spam, but overall Internet mail traffic could be greatly reduced, with corresponding improving performance improvements for all.

A bit more detail

Messages are sent from email clients, just as they are today, to an email server. Hopefully, this is done in a moderately secure fashion. The email server generates a random message ID that is used for all of the message elements and “posts” the message to its web server. The SETP message is formed using the return address of the sender and the body of the message consists of a MIMP message – a list of relative URLs to the mail server with paths as follows:

FROM: senderID@itglobalsecure.com

TO: myfriend@secureplay.com, myotherfriend@urbanrevivals.com

Subject: Sample Simple Envelope Transfer Protocol Message

Message Body:

MIMP Part 1

http://…/[senderID – optional]/[Message ID]/messagebodypart1

MIMP Part 2

http://…/[senderID – optional]/[Message ID]/messagebodypart2

MIMP Part 3

http://…/[senderID – optional]/[Message ID]/messagebodypart3 …etc.

End Message

This message is then sent to the recipient(s) mail servers, just as an SMTP message is today. The receiving mail server takes the incoming SETP message and either stores it or parses it to retrieve the actual message for the local recipients. To parse the message, the receiving email server uses the return address of the sender to create the absolute URL domain name to combine with the MIMP parts to retrieve the message:

MIMP Part 1 (parsed by receiver)

http://[Sender Domain Name - itglobalsecure.com]/ /[senderID – optional]/[Message ID]/messagebodypart1

MIMP Part 2 (parsed by receiver)

http://[Sender Domain Name]/ /[senderID – optional]/[Message ID]/messagebodypart2

MIMP Part 3 (parsed by receiver)

http://[Sender Domain Name]/ /[senderID – optional]/[Message ID]/messagebodypart3

If the message cannot be retrieved from the sending mail server, then the message is marked as an error, spam, or otherwise handled.

Additional Features

In addition to the basic SETP message body, there are several features that could be added to extend the functionality of this system. First, an expiration time can be set and sent with the message to indicate to the receiving mail server or clients a deadline for retrieving mail. Second, a challenge/response password system could be used to ensure that only an actual recipient of the message can retrieve the mail message. This system would no way impact the use of encryption or digital signatures for other security features. It certainly does give a sender the ability to “unsend” a message if it has not been retrieved.

Conclusion

This paper has provided a quick introduction to an alternate approach for improving the security of email. It is a fairly robust approach that does not require the creation of a security infrastructure and could be implemented in a fairly straightforward fashion. By strengthening the link between the message content and message envelope, many attacks will be thwarted.