The proliferation of spam, e-mail fraud and messages with malicious attachments is a serious problem for businesses and consumers. While various e-mail filtering technologies can reduce the quantity of spam that finds its way to in-boxes, spam and virus senders still can disguise the true source of e-mail or make it appear as if messages came from entities the recipient trusts - such as a bank.
The Identified Internet Mail (IIM) specification was submitted to the IETF as an Internet draft in July 2004 and is under review. IIM provides new protection that can help stem the tide of unwanted and harmful e-mail. Compared with other signature-based approaches, IIM offers a more reliable way to authenticate messages and is designed to provide scalability for authorizing large numbers of public keys. IIM enables e-mail systems to confirm that a sender is authorized to send messages using a specific e-mail address and that the original message has not been altered by an unauthorized user.
In a typical IIM use, the sending e-mail domain's outgoing mail server, known formally as a mail transfer agent (MTA),"signs" the message by inserting a new header with the sending user's signature and the public key to be used to verify it. The key used for signing the message is one that has been authorized by the domain administrator for the specific e-mail address or for the entire e-mail domain. Alternatively, a mail user agent (MUA), software used by the message writer or reader, or mail submission agent, a type of MTA that authenticates the message sender, can sign the message.
At the recipient's domain, an MTA or MUA uses the public key included in the signature header to determine whether the sender's IIM signature is correct for the message. The server also queries the originating domain to determine whether the key matches that of an authorized sender. This query can be to DNS records published by the originating domain or to an HTTP-based server known as a key registration server, depending on the deployment needs of the originating domain. Based on the response, the message can be sent to the recipient or flagged as a possible fraudulent e-mail.
Keys used to sign messages can be authorized for an individual e-mail address or for all addresses in the domain.
The receiving MTA can attach an optional verification header that communicates the results of the verification process to the MUA. This lets the MUA in the receiving domain offload verification tasks to an MTA, thereby improving the timeliness of verification and requiring less change at the user's desktop.
Easy to implement, IIM mail signing is compatible with current e-mail infrastructures and client software. Signing and verification can be implemented by plug-ins to popular mail servers and client software.
Because IIM signing involves only the addition of a new message header, receiving domains that have not implemented IIM still can receive IIM-signed messages. And network managers can deploy IIM in a manner that lets a signed message pass verification if only insignificant changes, such as modifications to spacing or line breaks, have been made to the message.