Domain-Based Authentication Protocols

The deluge of spam and concerns about authenticity of email have engendered both enhanced and new protocols for verifying that the purported sender of an email message is the actual sender of the mail. Email Firewall Network Connections provides these additional tools to address these concerns.

Both the Sender Policy Framework (SPF) and Microsoft’s Caller ID for Email are domain-based authentication protocols. They encourage email domain administrators to publish information about their outbound mail servers in the DNS. Doing so enables inbound mail servers to determine whether the sending host is authorized to send mail on behalf of the domain name appearing in the sender’s email address. If the host is not authorized, the sender address may be

“spoofed” and the message can be rejected. Use of these protocols may help to eliminate large quantities of spam on the Internet, since spammers frequently use spoofed sender addresses.

Support for both SPF and Caller ID are integrated into the Inbound SMTP Relay Service. When testing is enabled, the SMTP Relay will reject messages that fail the test. All messages that have been tested and accepted are marked with message properties so that downstream components can distinguish messages that successfully passed the test from the messages not tested at all. By default, SPF and Caller ID checking are not to be performed. The administrator must explicitly enable this feature.

The SPF and Caller ID authentication techniques are primarily intended for SMTP Inbound “gateway” machines that are receiving mail directly from the

Inbound SMTP Relay is deployed such that inbound mail from external domains is received directly.

If Email Firewall is deployed such that a non-Email Firewall SMTP relay receives the inbound mail in the DMZ and then relays the mail to Email Firewall, SPF and Caller ID cannot be enabled. If enabled in this environment, messages will be incorrectly rejected because they will appear to have failed the authentication test.

The Caller ID specification describes how a sender could be authenticated with a Caller ID test when the message is on a system that is not the one that received the message from the purported sender’s domain. However, this type of support for Caller ID is not supported in this release.

Sender Policy Framework

The Sender Policy Framework provides one way to address the problem of domain name forgery. Malicious entities often falsify envelope and header addresses to conceal the identity of the true source of a message. When the forged addresses correspond to legitimate addresses, the victims of the forgery suffer the cost.

SPF is designed to fight this type of email address forgery. It does this by establishing a policy framework and an authentication scheme. SPF defines a simple language that domains can use to describe the mail they send. SMTP receivers can then use these descriptions to evaluate messages.

In an SPF sender authentication scheme, a domain owner asserts that legitimate messages from that domain must meet a certain description. Messages which do not meet that description are not legitimate. These assertions are made in machine-readable form.

The SPF specific sender authentication scheme is based on the designated sender model. A domain identifies certain hosts as designated senders and mail from those hosts is considered legitimate while mail from other hosts is not. The SPF publishes policy data in the DNS. DNS resolvers can then cache the SPF data to reduce lookup traffic.

Although SPF appears to function very similarly to RDNs lookups, the two are different. The main difference between SPF and RDNS is that in the SPF case, the sending domain is given the opportunity to publish in the DNS a “policy statement” that declares what are the hosts on the Internet that may legitimately

SPF becomes widely deployed, spam filters like DAS can also cast more doubt on mail received from domains that publish no SPF information.)

In the case of RDNS, receiving SMTP servers are simply making an educated guess about whether the mail is coming from a host that should be authorized to send on behalf of the sending domain. This guess is prone to errors because mail could be routed through service providers' machines and because the reverse-DNS names of outbound SMTP relays are sometimes not in the reverse-DNS at all.

Additional information about SPF can be found at http://spf.pobox.com/spf-draft-20040209.txt.

Microsoft’s Caller ID

Caller ID for E-Mail is the Microsoft draft specification to address the problem of domain spoofing and email forgery. Caller ID verifies that each message originates from the Internet domain it claims to come from. Caller ID checking is based on addresses found in the message headers, not the SMTP envelope.

The Caller ID mechanism is achieved by having administrators of domains publish the Internet addresses of their outgoing email servers in the Domain Name System (DNS) in addition to the incoming email servers that they list there today. When email is transmitted from one organization to another, the computers of the sending organization need to determine which computer the receiving organization has designated as the one that handles its incoming mail.

With the information listing outgoing mail servers in place, software that receives an incoming message can now verify that the computer used to send the message was in fact under the control of the domain from which the message purports to have originated.

Additional information about Microsoft’s Caller ID specification can be found at http://www.microsoft.com/mscorp/twc/privacy/spam_callerid.mspx.