By Michael Caton  |  Posted 2004-02-02 Print this article Print

First, spoofing a persons e-mail address is easy. Spoofing and forging e-mail addresses is common because it helps spammers evade legal action and ISP intervention, defeats simple anti-spam address-blocking settings, and makes it easier to engage in phishing schemes.

Second, the MX (mail exchanger) servers that forward e-mail around the Internet are routinely co-opted into spreading spam because they must accept e-mail from any client on the Internet and send it to the client systems they serve. Most proposals that involve validation of senders would limit the source of e-mail on the Internet to mail servers.

A solid authentication mechanism is the key to ensuring that e-mail originates only from valid mail servers. Although authentication doesnt necessarily prevent spamming, it does make it possible to more effectively blacklist spammers.

DomainKeys would make it easier to identify and block e-mail coming from a spoofed or fraudulent e-mail address. DomainKeys works by adding a header to an e-mail message that includes a digital signature and public key, and adding a public-key authentication system to the DNS on the senders network. Software running on the e-mail server would manage the validation of keys so that when a server received an e-mail, it would query the senders DNS to make sure the key pairs and digital signature matched.

The primary benefit of the DomainKeys system is that it does not break existing SMTP implementations. The new header information is backward-compatible because SMTP allows for experimental headers. In addition, the digital signatures are not implemented through Multipurpose Internet Mail Extension, so systems that do not use MIME will be able to accept messages.

The system doesnt require action on the part of end users because it is an entirely server-based approach. It will require that administrators install and manage yet-to-be-released open-source public-key software on the mail server.

Ultimately, the effectiveness of DomainKeys will depend on the diligence of administrators in designating senders and domains that may or may not use the system. The transition to such a solution will likely take many years, particularly because the proposal is currently being circulated privately. It also could take months before the proposal is ready for public review and comment, and then it must work its way through the IETF before the proposed new header can be standardized as an extension to SMTP.

Also on the table as a means to validate senders: changing the way MX servers behave through a new protocol that would ensure that they accept mail only from other MX servers and client systems internal to their own networks. When an MX server receives a message, it would determine if the sender is another valid MX server or an internal client. If not, mail would be blocked.

While this approach would not prevent spammers from sending e-mail from a legitimate domain, it would give administrators of the recipient server the ability to block or blacklist the spammer. It would also require that companies manage all outbound mail through a valid MX server.

This change would also require a change to DNS records to help identify internal mail exchangers, or IMXes, which are used to relay outbound mail from an organization to the organizations MX on the Internet. The IMX DNS record would flag the IP address of an IMX system so that it is recognized as a valid MX.

The biggest problem with this approach is that it requires changes to the DNS and updating systems. For organizations sending large volumes of outbound mail, this would likely require migrating internal MX systems to external MX systems.

Next page: DMP


Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel