eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
There are many who say the only way to truly eliminate spam is to change the way e-mail works. However, changes to the most fundamental standards behind sending e-mail over the Internet—SMTP and Domain Name System—are a long way off and will likely only reduce spam, not eliminate it.
At this point, changes to SMTP and DNS that would significantly limit the flow of spam are years away. Most proposals are only in working draft form or are ideas that originate from vendors and have not yet been submitted to the Internet Engineering Task Forces working groups for consideration. The Anti-Spam Research Group, a working group within the IETFs Internet Research Task Force, is the main industry body studying proposals for managing spam.
Most proposals involve creating a way to validate that the sender of a message is an authorized sender of e-mail over the Internet. Validation methods include authentication, modifying mail exchangers, using DomainKeys (a proposed method of authentication from Yahoo Inc.) and standardizing C/R (challenge/response) systems.
Two fundamental problems with SMTP contribute to the volume of spam.
SMTP
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.
DMP
|
||||
In addition, DMP (Designated Mailers Protocol), a draft proposal in front of the IETF, provides a way for mail transfer agents to determine if a system sending mail is authorized to do so by storing sender permission in a form. At the core of DMP is a record of systems in the DNS that are authorized to send e-mail. Rather than performing an address look-up every time a mail transfer agent receives a message, the agent checks the DMP record to verify that the sender is an authorized system. Unauthorized traffic is blocked.
An effort is also under way to make anti-spam systems handle C/R in a standard way. The IETFs Challenge/ Response Interworking Framework creates a set of rules for establishing interoperability among C/R systems. The basic model is designed to simplify C/R interworking by allowing a sender running a C/R system to automatically respond to the challenge message from the recipient. If the sender does not have a C/R system, the message from the recipients C/R system would specify actions required to respond to the challenge manually.
A standard model would help manage C/R systems, but they would still be subject to abuses such as e-mail address harvesting.
Another idea involves charging for e-mail sent over the Internet. One such project, Microsoft Corp.s Penny Black, suggests that ticket costs or CPU cycle costs should be added to the process of sending e-mail. (No “charge-for-e-mail” proposals have been submitted to the Anti-Spam Research Group.)
This would make it expensive for spammers to hawk their wares, but it would also add cost for everyone to what has been up until now an inexpensive communications medium. More information on Penny Black can be found here.
Technical Analyst Michael Caton can be reached at michael_caton@ziffdavis.com.