Various schemes have been developed for sender verification where not only the validity, but also the authenticity, of the sender address is checked. The owner of a internet domain specifies certain criteria that must be fulfilled in authentic deliveries from senders within that domain.
Two early proposed schemes of this kind were:
MAIL-FROM MX records, conceived by Paul Vixie <paul (at) vix.com>
Reverse Mail Exchanger (RMX) records as an addition to DNS itself, conceived and published by Hadmut Danisch <hadmut (at) danisch.de>.
Under both of these schemes, all mails from <user@domain.com> had to come from the hosts specified in <domain.com>'s DNS zone.
These schemes have evolved. Alas, they have also forked.
"Server Policy Framework" (previously "Sender Permitted From") is perhaps the most well-known scheme for sender authorization. It is loosely based on the original schemes described above, but allows for a bit more flexibility in the criteria that can be posted by the domain holder.
SPF information is published as a TXT record in a domain's top-level DNS zone. This record can specify:
which hosts are allowed to send mail from that domain
the mandatory presence of a GPG (GNU Privacy Guard) signature in outgoing mail from the domain
other criteria; see http://spf.pobox.com/ for details.
The structure of the TXT record is still undergoing development, however basic features to accomplish the above are in place. It starts with the string v=spf1, followed by such modifiers as:
a - the IP address of the domain itself is a valid sender host
mx - the incoming mail exchanger for that domain is also a valid sender
ptr - if a rDNS lookup of the sending host's IP address yields a name within the domain portion of the sender address, it is a valid sender.
Each of these modifiers may be prefixed with a plus sign (+), minus sign (-), question mark (?), or tilde (~) to indicate whether it specifies an authorative source, an non-authorative source, a neutral stance, or a likely non-authorative source, respectively.
Each modifier may also be extended with a colon, followed by an alternate domain name. For instance, if you are a Comcast subscriber, your own DNS zone may include the string "-ptr:client.comcast.net ptr:comcast.net" to indicate that your outgoing e-mail never comes from a host that resolves to anything.client.comcast.net, but could come from other hosts that resolve to anything.comcast.net.
SPF information is currently published for a number of high-profile internet domains, such as aol.com, altavista.com, dyndns.org, earthlink.net, and google.com.
Sender authorization schemes in general and SPF in particular are not universally accepted. In particular, one objection is that domain holders may effectively establish a monopoly on relaying outgoing mail from their users/customers.
Another objection is that SPF breaks traditional e-mail forwarding - the forwarding host may not have the authority to do so per the SPF information in the envelope sender domain. This is partly addressed via SRS, or Sender Rewriting Scheme, wherein the forwarder of the mail will modify the Envelope Sender address to the format:
user=source.domain@forwarder.domain |
Similar to SPF, in that acceptance criteria are posted via a TXT record in the sending domain's DNS zone. However, rather than relying on simple keywords, MS CIDE information consists of fairly large structures encoded in XML. The XML schema is published under a license by Microsoft.
While SPF would nominally be used to check the Envelope Sender address of an e-mail, MS CIDE is mainly a tool to validate the RFC 2822 header of the message itself. Thus, the earliest point at which such a check could be applied would be after the message data has been delivered, before issuing the final 250 response.
Quite frankly, dead on arrival. Encumbered by patent issues and sheer complexity.
That said, Recent SPF tools posted on http://spf.pobox.com/ are capable of checking MS Caller-ID information in addition to SPF.
(part of Simple Caller Authorization Framework - SCAF). This scheme is developed by Hadmut Danisch, who also conceived of the original RMX.
RMX++ allows for dynamic authorization by way of HTTP servers. The domain owner publishes a server location via DNS, and the receiving host contacts that server in order to obtain an authorization record to verify the authenticity of the caller.
This scheme allows the domain owner more fine-grained control of criteria used to authenticate the sender address, without having to publicly reveal the structure of their network (as with SPF information in static TXT records). For instance, an example from Hadmut is an authorization server that allows no more than five messages from a given address per day after business hours, then issues an alert once the limit has been reached.
Moreover, SCAF is not limited to e-mail, but can also be used to provide caller authentication for other services such as Voice over IP (VoIP).
One possible downside with RMX++, as noted by Rick Stewart <rick.stewart (at) theinternetco.net>, is its impact on machine and network resources: Replies from HTTP servers are not as widely cached as information obtained directly via DNS, and it is signifcantly more expensive to make an HTTP request than a DNS request.
Further, Rick notes that the dynamic nature of RMX++ makes faults harder to track. If there is a five-message-per-day limit, as in the example above, and one message gets checked five times, then the limit is hit with a single message. It makes re-checking a message impossible.
For more information on RMX, RMX++, and SCAF, refer to: http://www.danisch.de/work/security/antispam.html.