Deployment considerations for designated sender protocols: a Sender-ID and SPF HOWTO

Designated sender protocols protect against email forgery using a mechanism by which the recipient of a message can determine if a host is authorized to send it. An email domain advertises in the DNS the hosts that it uses to send email; these are that domain's designated sending hosts. When a recipient gets a message, it extracts from it the domain of the message's sender and uses that to determine if the sending host is one of the domain's designated senders. If not, the host is unauthorized to send the message and the recipient may reject it. The motivation for designated sender protocols is by analogy to incoming email: an email domain advertises the hosts it uses to receive email using MX records in the DNS; designated sender protocols allow domains to do the reverse. In fact one of the early designated sender proposals was called "Reverse MX" . There are a number of ways of advertising designated senders in the DNS, and there are a number of email addresses in a message which might be used to identify its sender. The IETF MARID working group (MTA Authorization Records In the DNS) was chartered to produce a standard designated sender protocol. It failed to reach consesus and was terminated; however work continues outside the working group on two designated sender protocols: SPF (the Sender Policy Framework) and Sender-ID . The MARID working group also considered some protocols which are not designated sender protocols according to the definition used in this document. These include CSA (Client SMTP Authorization) and MTA Mark . Designated sender protocols determine whether a host is authorized to emit messages with a sender address in a particular email domain, whereas CSA and MTA mark determine whether a host is authorized to send email without reference to the details of the individual messages. The rest of this document examines SPF and Sender-ID in detail. Although the details may differ, the principles will apply to other designated sender protocols.

When MARID was chartered SPF had the most momentum, though this changed when Microsoft entered the fray with their "Caller-ID for email" protocol . Both these protocols use a textual DNS record to describe the designated sending hosts: SPF uses a concise purpose-designed language, whereas Caller-ID uses XML. The MARID group decided to merge the two protocols, using the DNS record format from SPF and the sender address selection algorithm from Caller-ID. The result was called Sender-ID. The details of the DNS record format are not relevant to this document (see for the current specification). What is important is that an email domain is able to specify which hosts may and which may not emit email that claims to be from someone at that domain. In addition to that basic distinction domains can also specify a grey area: hosts whose authorization status is indeterminate. This is discussed more in . Where SPF and Sender-ID differ is the email address which is used to identify the sender of the message. SPF uses the bounce address specified in the SMTP MAIL FROM command . The advantage of this is that it allows the accept/reject decision for a message to be made as early as possible, thus minimising the resources consumed by junk email. Bounce messages have a null MAIL FROM address, so when deciding the authorization for bounce messages SPF uses the host name from the HELO command to look up the designated sending hosts. In this mode it is using similar semantics to CSA and is not really a designated sender protocol. Sender-ID uses an algorithm to extract the "purported responsible address" from the message header , using (in decreasing order of priority) the Resent-Sender:, Resent-From:, Sender:, and From: fields. This algorithm is a natural result of the message header semantics described in . The aim is to base the authorization desision on an email address that the user is likely to see, to directly counteract "phishing" (email-based confidence tricks). The main effect of this difference is to change the kinds of approaches that can be used to mitigate the compatibility problems that are described in the next section.

A basic assumption underlying designated sender protocols is that a message travels across the public Internet directly from the sender's organization to the recipient's in a single hop. Although email messages usually travel more than one hop, most of the hops are within an organization (e.g. from a user's PC to a message submission server, or from a border MX to a message store system) and therefore use private routing arrangements. When a message travels between organizations across the public Internet, it is routed using public information, i.e. MX records in the DNS. It is this hop that designated sender protocols are aimed at. However this basic assumption is not true for a significant percentage of email. It is fairly common for users to arrange for their email to be automatically forwarded to an address at another site, using the Sieve redirect command or a Unix .forward file or some equivalent facility. This kind of forwarding is almost identical to normal message relaying - the message header remains the same (apart from the addition of Received: trace fields), the MAIL FROM address remains the same - except that a recipient address in the message envelope is changed to the forwarding destination address. This kind of forwarding is different from the "forward" command offered by most MUA software, which encapsulates the original message in a new message, e.g. using the MIME type message/rfc822 . The new message has a header and bounce address similar to normal messages sent by the forwarding user. Forwarding is frequently used by people with more than one email address to consolidate their email in one place. These include contributors to Internet-based projects, such as open source software projects and collaborative web sites. Academics who move around between Universities and research institutes on short contracts often keep in touch with past colleagues by forwarding email from their old accounts. It's typical for 5%-10% of users at a University to forward their email off-site (though the proportion may be as low as 0% or as high as 20% at certain institutions) and the proportion of the actual volume of email is similar to the proportion of users. Universities often provide email forwarding services to alumni, often with tens of thousands of registered users (though the number of active users is somewhat less). When a forwarded message is making its second hop across the public Internet it still claims to come from the original sender, but it will not be coming from a designated sending host of the original sender's domain: it will come from an outgoing email system of the forwarding site, the original recipient's domain. From the point of view of the final recipient the message is unauthorized and so it may be rejected. Note that there are three (or even more) organizations involved in delivering a forwarded message: the sender, the forwarder(s), and the final recipient. Forwarding is usually set up by end users, so the administrators of the email infrastructre at the three sites will typically not have an overview of the situation, and will usually not be aware that it is happening at all. The next three sections of this document examine ways that the basic designated sender protocols can be adapted to ameliorate this problem. Forwarding is a valuable and widely used feature of Internet email so it cannot just be left as a casualty beside the road to a brave new world of secure email.