First
Previous
ARCHIVED—Emerging Technologies
Archived Content
Information identified as archived on the Web is for reference, research or recordkeeping purposes. It has not been altered or updated after the date of archiving. Web pages that are archived on the Web are not subject to the Government of Canada Web Standards. As per the Communications Policy of the Government of Canada, you can request alternate formats on the "Contact Us" page.
Anti-Spam Technology Overview
Task Force on Spam
Network and Technology Working Group, Telecommunications Engineering and Certification
May 2005
4.1 Domain Authentication
4.2 Internet Protocol Version 6
4.3 Presence
4.1 Domain Authentication
Domain-authentication technologies are used to ensure that a sender's domain is not forged or "spoofed." Because of the openness of SMTP, a sender is able to forge another sender's identity. This protocol weakness is frequently exploited by spammers. To avoid prosecution from legal authorities or termination of service from an ISP, spammers must remain anonymous. Protocol enhancements are, therefore, necessary to ensure the authenticity of a sender's address. The following section discusses these enhancements.
The primary stakeholders behind the technologies are AOL for the Sender Policy Framework (SPF), Microsoft for Sender ID, Yahoo! for Domain Keys, and Cisco Systems for Identified Internet Mail (IIM).
4.1.1 Sender Policy Framework
SPF has a large user base and has become generally accepted as the current method of sender authentication. Similar technologies that have been in competition with SPF include reverse mail exchange (RMX) and designated mailers protocol (DMP). All of these solutions use DNS to help authenticate senders' addresses. The main goal in implementing a sender-authentication scheme is to have a single solution in order to ensure global adoption.
The need for a single, global standard has been the cause of much debate in the technology-development community. The Internet Research Task Force (IRTF) originally formed a research group on anti-spam technologies. This group brought forth several draft specifications to the Internet Engineering Task Force (IETF). Once the need for a single solution became apparent, the MTA Authorization Records in DNS (MARID) working group was formed and was tasked with developing the next version of SPF. However, the working group was unable to agree on a common method. As a result, MARID was closed on September 22, 2004.9 Throughout the debates, SPF version 1, or SPF Classic, has gained greater acceptance among ISPs as a method for validating message sources.
SPF authenticates a sender's domain by using a reverse look-up on an MX record in the DNS. The process is similar to the one that uses MX records to locate a recipient's mail server. A receiving mail server uses a sender's domain and makes a DNS query for that sender's domain. The response to the query from the domain-name server contains the addresses it allows to send mail. The receiving MTA uses the SPF record to verify that the sending address is a valid mail source. If the addresses cannot be verified, it is assumed that the sender has forged the address, and the message can be filtered on that basis.
One known problem with SPF happens when an MTA forwards mail on behalf of a recipient. The domain of the original sender must be passed through without modification, so that the verification will not fail. The sender rewriting scheme (SRS) has been one way of solving the forwarding issue for SPF; the other has been Sender ID.
A general concern is that spammers may still be able to register SPF records for domains that can be used to send authenticated spam email. In this case, the spam may reach the recipient if alternative methods are not in place, but the message's source remains known. If the source of a message is known, methods such as blacklisting, registrar notification and legal prosecution can be used.
Disposable domains can let spammers send authenticated messages and then simply register a new domain once the abuse has been detected. This problem has not yet been solved, but a partial solution may be domain accreditation.
4.1.2 Sender Identification
Microsoft originally developed the Caller ID for E-mail proposal for sender authentication as an alternative to SPF. Once the need for a global solution was understood to be essential, technology developers, with the help of the MARID working group, tried to merge the two projects into a new draft specification called Sender ID.
The Sender ID proposal is backwards-compatible with SPF. When a recipient receives a message, the sender's "from" address is verified by checking a DNS record for that domain. The information in that record is used to ensure that the sender's mail did originate from the purported domain. To address the forwarding issue that was identified in SPF version 1 (SPFv1), a purported responsible address (PRA) was introduced into the draft.
The PRA algorithm within the Sender ID draft contained licensing terms for intellectual property held by Microsoft. Some open-source projects were unable to agree to the license terms and, therefore, could not support the draft. Since unanimous consent could not be obtained for the Sender ID proposal, the efforts of the MARID working group were discontinued.10 In November 2004, Microsoft presented the Sender-ID proposal at the U.S. Federal Trade Commission's Email Authentication Summit. The proposal has now been endorsed by AOL, which had supported SPF following the closure of the MARID working group.
4.1.3 Domain Keys
Domain Keys uses a different method for authenticating senders than do Sender ID and SPF. To ensure that users are able to trust the authenticity of a sender, Domain Keys signs all messages with a cryptographic key specific to the domain.
The Domain Keys method uses an asymmetric key algorithm with public and private keys. The sending MTA requires a Domain Keys-enabled MTA, which uses a private key to sign the message. Upon receiving a signed message, the receiving MTA looks up the sender's domain to find the public key for that domain. The public key is then used to verify that the signature of the sender is valid. If the signature proves to be valid, the recipient can be sure of the sender's domain. As with other domain-authentication protocols, only the MTAs have to support the technology.
4.1.4 Identified Internet Mail
The proposed Identified Internet Mail (IIM) solution is similar to the Domain Keys approach, but does not depend on DNS to provide the keys. Instead, it uses a key-registration server that is linked through DNS. The key-registration server allows for the authentication of hosts or groups of hosts, not just the domain. The IIM protocol is now being drafted, along with Domain Keys, by the mail-signatures draft working group of the IETF.
4.2 Internet Protocol Version 6
The current version of IP, IP version 4 (IPv4), has a limit to the number of addressable hosts that can be supported in the network. Many of these addresses have been allocated, and shortages have become apparent. A new version of IP, IP version 6 (IPv6), has been designed with substantially more address space. To take advantage of the increased network size and additional features, IPv6 has begun to be deployed, notably in the Asia-Pacific region.
As IPv6 is generally deployed, applications for mail servers and clients will need to support IPv6. The software must be able to correctly interpret the larger addresses that will be used to identify MTAs. Most software applications are capable of handling IPv6 addresses; however, some may need to be upgraded. Similarly, the systems that email depends on, such as DNS, SMTP gateways and filters, will also need to be able to support IPv6. The domain-based authentication lists that are used to block abusive senders will need to be modified to include IPv6-enabled senders. As spammers and their recipients move to IPv6, there will be an increasing need for IPv6-enabled anti-spam measures.
4.3 Presence
The concept of "presence" is being used to provide location-aware services for IM and VoIP applications. Information on a user's state and geographical location can be accessed by these applications. This information must be dealt with carefully, however. Some wireless spam already exploits this information by using location-specific advertising — for example, in airports. If the information is not properly secured, both IM and VoIP technologies could be vulnerable to abuse by spammers.
- Date modified:
