Internet Draft B Atkinson Category: Experimental Microsoft Corp Title:draft-atkinson-callerid-00.txt May 2004 Expires in six months Caller ID for E-mail Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright(c) The Internet Society (2004). All Rights Reserved. Abstract When e-mail is handed off today from one organization to another, as a rule no authentication of the sender of the e-mail or the computers delivering it on the senders behalf takes place. There are some simple steps which can be taken to significantly alleviate this problem, steps which mimic within the e-mail infrastructure the caller ID mechanism found in todays telephone system. This proposal specifies that in addition to todays practice of publishing in DNS the addresses of their incoming mail servers, administrators of domains also publish the addresses of their outgoing mail servers, the addresses of the computers from which mail legitimately originating from that domain will be sent. This information will then be used in enhancements to software that receives incoming mail to verify that computers handing off a message to them in fact are authorized to do so by the legitimate administrator of the domain from which the message is purported to have been sent. INTERNET DRAFT Caller ID May 2004 Table of Contents 1 Introduction......................................................3 1.1 Terminology....................................................3 2 Overview..........................................................3 3 Protocol Specification............................................6 3.1 Publication of Outbound Mail Servers...........................7 3.1.1 Examples of Outbound Mail Servers E-mail Policy Documents.12 3.1.2 Bringing Outbound Mail Servers Online and Offline.........14 3.1.3 E-mail Policy Document Processing.........................14 3.2 Identification of a Domain Responsible for a Message..........15 3.2.1 Implications for Mobile Users.............................17 3.2.2 Implications for Mailing Lists............................18 3.2.3 Implications for Mail Forwarders..........................18 3.2.4 Implications of Multiple Apparent Responsible Identities..20 3.3 Checking of Purported Responsible Domain......................21 3.3.1 Checking Purported Responsible Domains in E-mail Clients..21 3.3.1.1 Look for your inbound mail servers....................22 3.3.1.2 Look for something from your domain administrator.....23 3.3.1.3 Parsing Received: headers.............................24 3.4 Domains Which Only Send Mail Directly to Recipients...........25 4 XML Schema.......................................................26 4.1 Schema Notes..................................................29 5 Security Considerations..........................................31 5.1 DNS Security Considerations...................................31 5.2 SMTP Security Considerations..................................34 6 References.......................................................35 6.1 Normative References..........................................35 6.2 Informative References........................................36 7 Acknowledgments..................................................36 8 Author Contact Information.......................................37 9 Full Copyright Statement.........................................38 Atkinson. [Page2] INTERNET DRAFT Caller ID May 2004 1 Introduction Over recent years, the rate and frequency at which computer users receive unwanted and unsolicited e-mail (colloquially known as spam) has increased significantly. In many regions the problem has become so severe so as to perhaps threaten the viability of e- mail as a useful communication medium. "Spoofing", or falsifying the identity of the sender of a message, is a prevalent tactic used by spammers. This paper is an approach which can begin to address this issue. The approach is analogous to the caller ID technology found in the telephone system. We believe that through coordinated action by the participants in the Internet e-mail community, significant progress in deterring spam can be made, and computer users everywhere will experience significant reductions in undesired and unwanted e-mail correspondence. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [STDWORDS]. 2 Overview When e-mail is handed off today from one organization to another, as a rule absolutely no authentication of the sender of the e-mail or the computers delivering it on the senders behalf takes place. Fortunately, there are some simple steps which can be taken to significantly alleviate this problem, steps which mimic within the e-mail infrastructure the caller ID mechanism found in todays telephone system. Specifically, based on the ideas of Hadmut Danisch, Meng Weng Wong, and others (see references [RMX], [LMAP], and [SPF]), the present proposal specifies that in addition to todays practice of publishing in Domain Name System (DNS)[rfc1035] the addresses of their incoming mail servers, administrators of domains also publish the addresses of their outgoing mail servers, the addresses of the computers from which mail legitimately originating from that domain will be sent. This information will then be used in enhancements to software that receives incoming mail to verify that computers handing off a message to them in fact are authorized to do so by the legitimate administrator of the domain from which the message is purported to have been sent. While spam has been around virtually as long as there has been e- mail, in the early years the scale involved was small enough so as not to be a significant practical annoyance or problem. Thats changed now. In recent times, the rate at which spam has been in users electronic mailboxes has skyrocketed. The problem has become one of significant proportions, costing users, industry, and the economy at large billions of dollars annually in terms of lost human productivity and wasted computer resources. Left unchecked, Atkinson. [Page3] INTERNET DRAFT Caller ID May 2004 spam threatens the viability of e-mail as a useful communication medium. It is time to put a stop to this problem. Since the spammers arent going to change their behavior, it falls on the rest of us to change what we ourselves do so that the majority of the spammers no longer have a viable and profitable business. To control spam, to identify it and filter it, a variety of approaches have been developed. Although different on the surface, these approaches share some common characteristics. They all ask certain questions about an e-mail message. They all use the answers to help classify the message as legitimate or junk. One of the most important of these questions is simply "who is sending me the message?" With this information in hand, one can ask follow-up questions such as: o Do we know this person? o Do they have a history of sending legitimate e-mail or junk e-mail? o Do we trust them? It turns out that answering with certainty this one simple question "who is sending me the message?" is very problematic. When e-mail is transmitted over the Internet from one organization to another today, no authentication of the sender of the e-mail or the computers delivering it on the senders behalf occurs. That is, no verification is done to ensure that mail which purports to be sent from, say, someone@example.com does in fact originate from computers under the control of the "Example" organization. It is a trivial matter for virtually anyone with a computer connected to the Internet to send mail and appear to be someone else in doing so. This is a form of forgery, and is often called "spoofing". Automated infrastructure for preventing such forgeries is lacking: short of a human forensic investigation, there is no means to distinguish such mail from the real thing. Needless to say, spammers routinely exploit this capability. Consequently, filtering spam is an error-prone activity. Junk e- mail that appears to originate from legitimate senders slips through filters. Worse, e-mail from legitimate senders is often blocked because their e-mail addresses have been spoofed and their reputations tarnished. One way to begin to address this state of affairs is to mirror what the telephone system provides with caller ID. In the telephone system, caller ID technology reliably informs the receiver of a phone call as to which telephone number is on the other end of the line. This is often related to the human being you end up talking to, but is not one-and-the-same concept. A more direct analogy to e-mail is most evident if one considers the transmission of faxes over the telephone: caller ID provides the phone-company-provided Atkinson. [Page4] INTERNET DRAFT Caller ID May 2004 phone number of the party sending the faxes, but this is a separate notion from the identity of the party who is responsible for the contents of the fax itself. That said, in most cases one expects the two notions to be related, and would be suspicious if they were not. In the world of e-mail on the Internet today, were missing this sort of caller ID mechanism. However, as has been observed by others (see references [RMX], [LMAP] and [SPF]), a caller ID mechanism can be achieved in e-mail relatively simply by having administrators of domains publish the Internet addresses of their outgoing e-mail servers in the DNS in addition to the incoming e- mail servers that they list there today. 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, just as (in analogy) the receiver of a fax sent over the phone can use caller ID information to check that the phone number from which the fax was transmitted is consistent with what the contents of the fax actually say. With this infrastructure in place, e-mail software will be able to distinguish, for example, whether a message that claims to be from someone@example.com was actually sent from the example.com organization or not. If not, the mail is a forgery. Note that the Caller ID mechanism defined here is not a substitute for strongly authenticated e-mail: there still remains, for example, the question as to whether the user named "someone" did in fact send the e-mail or whether, say, some rogue administrator at example.com sent the e-mail instead. Even so, having reliable domain information is a huge step forward, and will be of great utility to e-mail filtering and classification systems, allowing them to distinguish between spam and non-spam e-mail with greater certainty. This in turn allows organizations to more harshly penalize e-mail they believe to be spam with less fear of misclassification or "false positives". The Caller ID for E-mail mechanism proposed here was designed with many considerations in mind. Among the more important of these were the following: 1. Ease of adoption. A key goal of this proposal is rapid and broad adoption. Therefore, it is a requirement that wherever possible any technical design operate within the capabilities, behaviors, and limitations of existing software. Clearly, it will not be possible to deploy this idea without some changes to some software. However, the proposal has been designed to keep such changes to a minimum. 2. Scalability. The design must scale up to meet the needs of the largest Internet service providers (ISPs) and down to the smallest office or home e-mail server. Specifically, it Atkinson. [Page5] INTERNET DRAFT Caller ID May 2004 must support organizations that have hundreds or even thousands of e-mail servers as well as those that have just one. It must also support those who outsource their e-mail servers to another organization. 3. Fairness. The design must fairly distribute the costs of compliance. Today the costs of detecting and remedying the forging of addresses are placed entirely on the receiving organization; the design must rectify this imbalance. Organizations that want to ensure mail from their domains is not mistakenly judged to be spoofed should bear part of the cost burden. Organizations that want to accurately determine whether or not messages they receive have been spoofed should also bear a corresponding cost. 4. Openness. The technical design must be openly published so that any organization wanting to comply with its provisions may do so. 5. Extensibility. The technical design must allow for the publication of new or additional information about an organizations e-mail policies and practices should this be required in future. It is important that this new information can be published without the need for the publication to be coordinated through a central body in order to, for example, avoid semantic collision with new information published by others. Caller ID for E-mail does not prevent spam from being sent. But it does make it easier to detect, and provides a basis for further measures which can do an even better job at such detection. As these measures are implemented and incrementally deployed more and more broadly, it will become more and more difficult to make a lucrative living as a spammer. We will never make the problem go away entirely: any system powerful enough to do that will necessarily unduly impinge on the free exchange of legitimate communication, making the solution worse than the problem it was designed to correct. But what we can do is reduce the problem back to the manageable and tolerable level it once was at. Its time we started. From a technical perspective, the Caller ID mechanism is roughly separable into three parts: 1. The publication in DNS of the outgoing mail servers for a given domain in addition to the incoming mail servers which are already published today, 2. The identification of a particular domain as being responsible for a given message, and 3. The correlation and checking of these two pieces of information to determine whether the IP address from which the message was received was reasonable or not. 3 Protocol Specification Atkinson. [Page6] INTERNET DRAFT Caller ID May 2004 3.1 Publication of Outbound Mail Servers At various points below, it is necessary that new kinds of information regarding the e-mail policies of a DNS domain be published. This section defines how to publish such information. The natural mechanism with which to publish information regarding a DNS domain is of course to use DNS itself in a straightforward, traditional manner. That said, unfortunate logistical complications are found in the selection of DNS resource record types that must be used to represent such information. A seemingly-obvious choice is to select appropriately-defined new record types for such new information. However, the use of new record types generally requires that DNS client software, server software, and administration tools all be updated to be made aware of the new types. Were we to require such updates here, the adoption of this proposal would be significantly impeded. Accordingly, an alternate means of representing the new information has been chosen, one that only makes use of existing, commonly understood DNS resource record types. Specifically, XML-encoded information stored in the TXT resource records in the _ep subdomain of a DNS domain in question is used. These records form a record set, which can thus be retrieved with a single DNS query, an important performance concern. More will be said later regarding the details of E-mail Policy Documents, but common cases are quite simple: one writes the XML, it fits in a single TXT record, and this is copied to the DNS configuration file. For example (see also section 3.1.1), the following illustrative fragment of a DNS configuration file shows an XML E-mail Policy Document indicating that the outbound mail servers of the domain example.com are exactly whatever the domains inbound mail servers are. Indeed, for those domains where this is the applicable policy, this literal boilerplate TXT record can be used verbatim. @ IN SOA ns.example.com. postmaster.example.com. (1 36000 600 86400 3600) _ep TXT ("<ep xmlns='http://ms.net/1'><out><m><mx/></m></out></ep>") This next slightly more contrived example illustrates how an E-mail Policy Document can be split across possibly several TXT records: @ IN SOA ns.example.com. postmaster.example.com. (1 36000 600 86400 3600) ep TXT ("02.3.4</a>" " </m>" " </out>" "</ep>" ) Atkinson. [Page7] INTERNET DRAFT Caller ID May 2004 TXT ("01<ep xmlns='http://ms.net/1'>" " <out>" " <m>" " <mx/> " <a>1.2" ) Here, the e-mail policy information of the example.com domain is the following XML document (note that, per the usual XML rules, with the exception of the space character between ep and xmlns, whitespace is not significant): <ep xmlns='http://ms.net/1'> <out> <m> <mx/> <a>1.2.3.4</a> </m> </out> </ep> In this proposal, the identity of the outgoing mail servers for a domain SHOULD be published in the XML E-mail Policy Document for the domain, specifically in the ep/out element. If the XML E-mail Policy Document does not exist for a domain or the document exists but does not contain either an ep/out/m element or an ep/out/noMailServers element, then the domain makes no statement about its outbound mail servers. If the document exists and contains an ep/out/noMailServers element, then the domain is making the statement that there are no outbound servers for that domain. The outbound mail servers for the domain are listed as one or more occurrences of an m element within the element ep/out. The interpretation of each m element ultimately provides two essential pieces of information about the server in question: Whether or not it makes use of the "enhanced SMTP NOOP" functionality (described in section 3.5.2 below) when making outbound SMTP connections, and The IP address or addresses of the server. Within the design, several important points were considered, including: Some domains (many of them well known) have literally thousands of outgoing mail servers. Thus, a means must be provided by which the need to list the address each server individually can be avoided. This is addressed by permitting legal address range (using address prefix list information in the style of in RFC3123) to be listed in place of individual addresses. Atkinson. [Page8] INTERNET DRAFT Caller ID May 2004 Although not as common as it once was, SMTP outbound relaying must be accommodated. In such situations, the outbound servers that actually perform the inter-domain delivery of mail (as seen by the receiving domain) may not be administratively under the direct control of the sending domain. A means of indirection is thus provided, wherein a sending domain can avoid having to repeatedly and continually update its XML E-mail Policy Document to reflect the now-current addresses of the servers used by the relaying organization. The set of IP addresses from which mail from a given domain d may be transmitted to a receiving domain is denoted as OutGoing(d). The function OutGoing(d) is defined as follows. A. If there exits an element ep/out/noMailServers in the XML E- mail Policy Document of d, then OutGoing(d) is defined to be the empty set. B. If there exists at least one element ep/out/m in the XML E- mail Policy Document of d, then OutGoing(d) is defined to be the union over all the ep/out/m elements m in the XML E-mail Policy Document of d of the set of IP addresses OutGoing(m,d) mapped to by each. C. Otherwise, the result of the function OutGoing(d) is undefined. In turn the function OutGoing(m,d) is defined as follows. If m is an element of the form ep/out/m in domain d, then OutGoing(m,d) is the set of IP addresses mapped to by m as calculated in the following manner. 1. If any child element m/indirect exists, then each MUST contain a fully qualified domain name d. OutGoing(m,d) is then defined as the union over each such d of the following: a. If d contains an E-mail Policy Document in its DNS entries, then OutGoing(d). b. Otherwise, the same set of addresses that are associated with the inbound mail servers of the domain d as determined by the usual MX and A record processing (see §5 of RFC2821). 2. Otherwise, if any child elements m/a, m/r, or m/mx exist, then OutGoing(m,d) is defined to be the set difference A+(m,d) -A-(m,d) of the two sets A+(m,d) and A-(m,d) which respectively represent explicitly listed addresses and explicitly listed address exclusions for m. These two sets are specified as follows: Atkinson. [Page9] INTERNET DRAFT Caller ID May 2004 The set A+(m,d) is defined to be the union over all child elements m/a, m/r, or m/mx of the contributions of each as defined in the following manner: a. An m/a element MUST contain one of the following 1 the (usual) dotted-decimal textual representation of an IPv4 address as defined by section 3.4.1 of RFC1035 (for example, "11.22.33.44"); in this case, the contribution to the set A+(m,d) is the IPv4 address so noted. 2 any of the three forms of the textual representation of an IPv6 address as defined by section 2.2 of RFC2373 (for example, "1080:0:0:0:8:800:200C:417A" or "::FFFF:129.144.52.38"); in this case, the contribution to the set A+(m,d) is the IPv6 address so noted. 3 a fully qualified domain name d. In this case, the contribution to the set A+(m,d) is the set of IPv4 and / or IPv6 addresses listed in DNS for the domain d using (respectively) A and / or AAAA records. 4 an empty string. Here, the contribution to the set A+(m,d) is the set of IPv4 and / or IPv6 addresses listed in DNS for the current domain d using (respectively) A and / or AAAA records. b. An m/r element MUST contain the textual representation of a single prefix-denoted range of IP addresses defined according to the following syntax (this is similar to, but is not the same as, the APL syntax used in RFC3123): [!]address/prefix Examples include "192.168.32.0/21", "!192.168.38.0/28", and "::FFFF:129.144.52.38/120". The text matching the address component must conform to the syntax of either an IPv4 or an IPv6 address as described respectively in clauses (a)(1) and (a)(2) above (for clarity: trailing zeros in the representation explicitly are permitted). The text matching the prefix component must be a decimal integer in the range 0 to 32 (for an IPv4 address) or 0 to 128 (for an IPv6 address). The set of IP addresses denoted by the textual representation is that set of IPv4 or IPv6 addresses (as appropriate) which are identical to the address indicated in at least the first prefix bits as taken in network byte order. If the textual representation begins with a ! character, then its contribution to the set A+(m,d) is the empty set; otherwise, its contribution is the set of IP addresses denoted by the textual representation. Atkinson. [Page10] INTERNET DRAFT Caller ID May 2004 c. An m/mx element MUST contain one of the following 1. a fully qualified domain name d. In this case, the contribution to the set A+(m,d) is the same set of addresses that are associated with the inbound mail servers of the domain d as determined by the usual MX and A record processing (see section 5 of RFC2821). 2. an empty string. Here, the contribution to the set A+(m,d) is the same set of addresses that are associated with the inbound mail servers of the current domain d as determined by the usual MX and A record processing (see section 5 of RFC2821). The set A-(m,d) is defined to be the union over all child elements m/r of the addresses indicated by each in the following manner: d. As was just noted above in clause (b), an m/r element MUST contain the textual representation of a single prefix- denoted range of IP addresses. If the representation begins with a ! character, then its contribution to the set A- (m,d) is the set of IP address denoted by the textual representation but with the ! removed; otherwise, its contribution is the empty set. 3. Otherwise, OutGoing(m,d) is defined to be the same set of addresses that are associated with the inbound mail servers of domain d as determined as determined by the usual MX and A record processing (see section 5 of RFC2821). Note that, as usual, internal DNS processing will automatically follow CNAME resource record aliasing should such aliases be used. Be aware that the use of the indirection mechanism or the use of the MX and / or A record processing per section 5 of RFC2821 and the like will result in more DNS queries during the resolution than would otherwise be the case. Implementations of this functionality should take internal measures to detect cycles of recursion as the evaluation progresses. While detecting actual recursion loops is RECOMMENDED, a simple approach is merely to count recursion depth; if that approach is used, then to promote interoperability a depth of at least eight recursions SHOULD be accommodated. If such a recursion cycle is detected, the results of the overall evaluation SHOULD be considered undefined, resulting in an inability to discern the outbound servers of the domain in question: the querying system SHOULD act in the same manner as if the outbound information were not published at all. If a DNS query involved in the evaluation times out or otherwise fails, then a reasonable approach is similarly to treat the query as unable to discern the outbound servers of the domain. Moreover, in order to deter a denial of service attack against querying mail Atkinson. [Page11] INTERNET DRAFT Caller ID May 2004 servers through the use of deep and broad trees of indirection, a querying system MAY itself impose a time limit on the duration of the execution of the overall query including all its indirections. If present, such a limit is implementation-dependent, but SHOULD NOT be less than twenty seconds. 3.1.1 Examples of Outbound Mail Servers E-mail Policy Documents Here are some simple illustrative examples: (1) My outbound mail servers are whatever my inbound mail servers are: <ep xmlns='http://ms.net/1'><out><m><mx/></m></out></ep> (2) My outbound mail server is at the single address 192.168.210.101: <ep xmlns='http://ms.net/1'><out><m><a> 192.168.210.101</a></m></out></ep> (3) My domain has three particular outbound mail servers: <ep xmlns='http://ms.net/1'><out><m> <a>192.168.210.101</a> <a>192.168.210.102</a> <a>192.168.210.107</a> </m></out></ep> (4) My domain has no outbound mail servers: <ep xmlns='http://ms.net/1'><out><noMailServers/></out></ep> (5) The outbound mail servers of my domain all live within one particular group of 16 IP addresses: <ep xmlns='http://ms.net/1'><out><m> <r>192.168.210.101/28</r> </m></out></ep> (6) My domain employs contoso.com to send mail on its behalf. In addition, my domain also sends mail outbound from its inbound servers and from the specific address 192.168.210.101: <ep xmlns='http://ms.net/1'><out> <m><indirect>contoso.com</indirect></m> <m><mx/></m> <m><a>192.168.210.101</a></m> </out></ep> Atkinson. [Page12] INTERNET DRAFT Caller ID May 2004 (7) My domain has multiple subdomains, all of which use the same outbound mail servers. a Create CNAME records for each subdomain: _ep.sub1.example.com IN CNAME _ep.outbound.example.com _ep.sub2.example.com IN CNAME _ep.outbound.example.com _ep.sub3.example.com IN CNAME _ep.outbound.example.com b In _ep.outbound.example.com (a dummy domain), register the required E-mail Policy Document. (8) My domain has hundreds of scattered outbound e-mail servers and will not open port 53 to TCP traffic. This can be accommodated by using <indirect> to dummy subdomains in order to build a tree of internal nodes, all of which can fit in a DNS UDP response, then populating the leaves of that tree with pieces of the necessary information. For example: a In _ep.example.com publish this E-mail Policy Document: <ep xmlns='http://ms.net/1'><out><m> <indirect>list1.outbound.example.com</indirect> <indirect>list2.outbound.example.com</indirect> </m></out></ep> b In _ep.list1.outbound.example.com (a dummy domain) publish a subset of my outbound server addresses information. For example: <ep xmlns='http://ms.net/1'><out><m> <a>192.168.210.101</a> <a>192.168.210.102</a> <a>192.168.210.107</a> <a> ... </a> </m></out></ep> c In _ep.list2.outbound.example.com (a dummy domain) publish the remaining outbound server address information. For example: <ep xmlns='http://ms.net/1'><out><m> <a>192.168.210.253</a> <a>192.168.93.17</a> <a>192.168.93.21</a> <a> ... </a> </m></out></ep> (9) The outbound servers of my domain reside at the address(es) of the domain dynamic.example.com as listed in DNS for that domain: Atkinson. [Page13] INTERNET DRAFT Caller ID May 2004 <ep xmlns='http://ms.net/1'><out><m><a>dynamic.example.com</a></ m></out></ep> 3.1.2 Bringing Outbound Mail Servers Online and Offline Domain administrators managing the publication of the identity of outbound mail servers for their domain should be cognizant of the fact that the time-to-live (TTL) value they publish on their records will adversely affect the speed with which a new outgoing mail server for the domain can be pragmatically brought online. Such effects can often be mitigated by the pre-publication of the IP addresses that such new servers will use, if such addresses can be predicted ahead of time. In particular, if the domain owns a particular range of IP addresses, and can administratively arrange that its new outgoing mail servers will use addresses in that range, the adverse effects can be eliminated by the one-time pre- publication of the address range. An analogous issue arises involving the retirement of the addresses of old servers that are taken offline. Generally speaking, even after the last message has been transmitted from a retiring server address, there may be a period of time before all the messages sent from that address have been evaluated against a Caller ID check. This period of time may be considerable: if the Caller ID check is carried out in an e-mail client, the message may perhaps sit in a POP3 server for weeks or more while a user is on vacation. In order to bound this otherwise indeterminate length of time, it is required that a Caller ID check on a given message MUST be carried out within 28 days (672 hours) of the message having been received by the checking organization (that is, within 28 days of the message having crossed the inter-organizational SMTP hop); after such a period has elapsed, a Caller ID check MUST NOT be carried out. Organizations wishing to retire addresses of old mail servers SHOULD keep those addresses listed in their domains E-mail Policy Document until this amount of time has elapsed since the last message sent from that address has crossed the inter-organizational SMTP hop and so been received by the destination domain. Once this time period has elapsed, the address can safely be removed from the E-mail Policy Document. 3.1.3 E-mail Policy Document Processing The use and interpretation of the record set forming the XML E-mail Policy Document is as follows. TXT records using this specification MUST NOT be greater than 2K characters in length. The E-mail Policy Document for the domain MUST be a valid UTF8- encoded XML[XML] document; in order to promote interoperability, other XML character encodings MUST NOT be used. Atkinson. [Page14] INTERNET DRAFT Caller ID May 2004 If there is a single record in the record set, then the E-mail Policy Document for the domain MUST be the sequence of strings in that one record concatenated together. If there are multiple records, each TXT record in the record set MUST begin with two distinguished characters (the two-digit decimal representation (with leading zeros as needed) of a non- negative integer is recommended) which is unique within the record set. Upon retrieval, the TXT records in the record set MUST be:- 1. sorted in ascending lexicographical order by these two characters 2. the first two characters removed from each record, 3. the results concatenated together to form one overall sequence of characters which is the E-mail Policy Document for the domain. The XML E-mail Policy Document of a domain SHOULD contain information which the administrators of the domain attest is pertinent to the policies under which the domain receives or sends mail. The XML schema definition which MUST be used for such XML documents is found in section 4; an E-mail Policy Document containing a root element conforming to a different schema MUST be ignored by those servers which do not understand it. XML E-mail Policy Documents SHOULD be cached in the normal manner for information returned from DNS. Applications MAY also cache at a higher semantic level the information derived from parsing these documents. 3.2 Identification of a Domain Responsible for a Message For each message transferred through SMTP from one organization to another (information regarding published outbound mail servers need not and likely ought not to be interrogated as mail is relayed within an organization, where presumably the trust relationships amongst the computers involved are such that they need not guard themselves against spam originating from within the organization itself) a purported responsible address is determined as the first from the following list of items which is both present and non- empty: 1. The first Resent-Sender header in the message, unless (per the rules of RFC2822) it is preceded by a Resent-From header and one or more Received or Return-Path headers occur after said Resent-From header and before the Resent-Sender header (see section 3.6.6. of RFC2822 for further information on Resent headers). Atkinson. [Page15] INTERNET DRAFT Caller ID May 2004 2. The first mailbox in the first Resent-From header in the message, 3. the Sender header in the message, and 4. the first mailbox in the From header in the message. Every well-formed e-mail message will contain at least one of the above headers. Any message that is sufficiently ill-formed as to not contain any of these SHOULD be considered very heavily suspect as spam (otherwise, spammers will just resort to omitting all of these headers). The particular listed order in which these headers are searched determines in a manner consistent with the defined semantics and usage of each a purported responsible address which is most immediately responsible for the transmission of a message. Roughly speaking [RFC2822], these semantics can be characterized as follows: Resent-Sender: addr1@example.com The message was previously delivered to the mailbox of its final destination, but it was subsequently reintroduced into the e-mail transport system, and addr1@example.com was the agent that actually carried out the reintroduction on behalf of the party listed in the Resent-From: header (which per RFC2822 MUST be present) whose desire it was that this occur. Resent-From: addr2@example.com The message was previously delivered to the mailbox of its final destination, but it was subsequently reintroduced into the e-mail transport system, and addr2@example.com was the party whose desire it was to have the message reintroduced; that is, addr2@example.com is responsible for the messages reintroduction. Sender: addr3@example.com addr3@example.com is the agent responsible for the actual transmission of the message. That is, it was addr3@example.com that actually caused the message to be injected into the e-mail transmission system. For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the Sender: field and the mailbox of the actual author would appear in the From: field. From: addr4@example.com addr4@example.com is the author of the message. That is, addr4@example.com is responsible for the writing of the message. The purported responsible domain of a message is defined to be the domain part of the messages purported responsible address. Atkinson. [Page16] INTERNET DRAFT Caller ID May 2004 3.2.1 Implications for Mobile Users Among todays broad community of e-mail users are some who legitimately send e-mail from IP addresses which are not administratively connected with their home domain. A common case is that of a mobile user, who may be using a laptop PC, an e-mail-enabled mobile phone, or other device. For example, suppose that Adam from example.com uses a portable e-mail messaging device to send much of his mail. Adam has an e-mail account adam@example.com that he wishes his recipients to think of as his actual address. However, he also has an account adam@consolidatedmessenger.com with the system run by his mobile device provider, and, indeed, when he sends mail from his device the message travels directly to its destination using servers under the control of consolidatedmessenger.com; the servers of example.com are not involved. To make this situation function without appearing to have a spoofed domain, Adam should ideally (although it may not be technically possible today) configure his mobile e-mail messaging device so that the following headers appear in the message: From: adam@example.com Sender: adam@consolidatedmessenger.com The purported responsible domain of Adams mail is then consolidatedmessenger.com. Many other mobile scenarios can be accommodated with an analogous approach, including that of Web-originated e-mail from greeting card sites and the like. That said, an alternate method is also applicable in many mobile scenarios. In many cases it is reasonable for mobile users to connect to their domain's inbound e-mail servers (or other administratively-related servers) to also relay their outbound messages. Adam might, for example, use his mobile e- mail messaging device in an alternate transmission mode wherein it communicates with his adam@example.com mailbox, which in turn sends the mail to its ultimate recipient in a manner indistinguishable from Adam having been sitting in front of his example.com mail reader in his home office. Where feasible, this approach is straightforward and is often to be preferred. It is worth noting in passing that it remains solely a decision for each individual domain such as example.com to choose whether or when to protect their reputation by taking the steps of section 3.1. As more and more domains take such steps, spammers will necessarily migrate their spoofing to the remaining domains, which in turn may appear more and more suspect, but in the end each domain owner is empowered to act on their own behalf. Atkinson. [Page17] INTERNET DRAFT Caller ID May 2004 3.2.2 Implications for Mailing Lists The core functionality provided by mailing list software is the provision of e-mail addresses (the address of each list) that take the mail received thereat and retransmit it on to the registered members of the list. In order to avoid the appearance of domain spoofing, such software SHOULD add a Resent-From: header to each retransmitted message to indicate that this action has been carried out. Alternately, a Sender: header MAY be used instead if one is not already present: indeed a number of existing mailing list agents already add such a Sender: header, and so need no adjustment to conform to this proposal. Continuing our example, if Adam sends mail from his mobile e-mail messaging device to the mailing list asrg@ietf.org, when the message is transmitted to the list members it might look in part like the following Resent-From: asrg@ietf.org Resent-Date: Tue, 16 Dec 2003 14:33:13 -0800 Received: from ... by ietf-mx.ietf.org ... ... To: asrg@ietf.org From: adam@example.com Sender: adam@consolidatedmessenger.com Because of the Resent-From: header, the purported responsible domain of this message is ietf.org. Note that the Resent-Date: header is included here per the requirements of RFC2822. Also note that the Resent-* headers are prepended earlier in the message than the corresponding Received: header; this is necessary in order to reliably demarcate the possibly multiple groups of Resent-* headers that may accrete as the message makes its way along its journey. 3.2.3 Implications for Mail Forwarders Today many mail forwarding services exist, wherein mail sent to one e-mail address will be automatically forwarded to a second address. The details of exactly how such services operate differ from service to service, but a widespread practice is to carry out the forwarding by retransmitting messages verbatim, preserving exactly both original the SMTP-level envelope information as well as the entire original message body. That is, in the existing verbatim retransmission practice legitimate mail sent from any domain can be legitimately delivered to its recipients systems from virtually any IP address, all in a manner entirely indistinguishable from the actions of a forger. If this behavior were to be preserved, any attempt to distinguish forgeries from legitimate mail would be problematic (see also the discussions of this issue in section 10 of reference [RMX] and section 3.4 of reference [LMAP]). Atkinson. [Page18] INTERNET DRAFT Caller ID May 2004 Therefore, the practice of forwarding mail using verbatim retransmission is to be discouraged. We propose a very small modification to forwarding practices in order to allow forwarded mail to be distinguished from spam, namely that forwarding retransmission services SHOULD annotate the message as they carry out the retransmission action. As before, this can be accomplished concretely by the inclusion by the forwarding agent of a new Resent-From: header in the message. Continuing our previous example yet again, suppose I subscribe to the ASRG mailing list using the address bob@forwarderexample.com, and further suppose that I have configured bob@forwarderexample.com to forward mail that it receives to bob@example.com. By the time Adams message reaches me at this latter address where I actually read the mail, its headers in part should look like the following. Received: from ... by example.com ... ... Resent-From: bob@forwarderexample.com Received: from ... by forwarderexample.com ... ... Resent-From: asrg@ietf.org Resent-Date: Tue, 16 Dec 2003 14:33:13 -0800 Received: from ... by ietf-mx.ietf.org ... ... To: asrg@ietf.org From: adam@example.com Sender: adam@consolidatedmessenger.com The purported responsible domain of the message is now forwarderexample.com. That all said, the legacy practice of verbatim retransmission can be accommodated to a limited degree at the expense of introducing narrow but entirely open holes in the forgery detection infrastructure. Fortunately, it is the case that most e-mail users are aware of the forwarding addresses that indirect to them, as they usually were involved in their establishment. In the above example, for instance, bob@example.com is likely aware of the existence of bob@forwarderexample.coms forwarding behavior, since Bob probably set up the forwarding relationship in the first place. Given this state of affairs, it is not unreasonable that the user of the forwarded-to system be provided with mechanisms in his e- mail software by which the filtering actions which would otherwise be carried out for the forwarded mail may be overridden. Specifically, the original destination address (here bob@forwarderexample.com) might be listed as a known recipient for bob@example.com: if this address appears in the To: or Cc: lines of mail delivered to bob@example.com, then the message would not be subjected to normal forgery detection processing. The forwarded mail thus will get through; however, this can be exploited by spammers should they become aware of this relationship Atkinson. [Page19] INTERNET DRAFT Caller ID May 2004 between these two addresses. Such controlled and focused disabling of the forgery analysis strikes a balance between accommodating legitimate legacy forwarding systems on the one hand and defeating domain-spoofing spammers on the other. 3.2.4 Implications of Multiple Apparent Responsible Identities Each of the four categories of identification of section 3.2 used in determining the purported responsible address for a message has slightly different semantics, the details of which are articulated in RFC2822 (see section 3.6.2 Originator Fields and section 3.6.6 Resent Fields). It is quite possible that a given piece of received mail contains a different address or addresses within the headers of each of these different four categories. As has been seen, sometimes such a combination of identities is reasonable, while other times it is not. The mechanisms and policies of section 3.1 through section 3.2.1 determine the purported party who was most immediately responsible for the transmission of a message and verify that the message has not been spoofed with respect to the domain of that party. Moving beyond this to consider the general relationship among the various possible categories of purported responsible address is generally beyond the scope of this proposal per se, though section 3.4 does address one important case. More properly such is a role of mail filtering and e-mail client software within a receiving system. That said, we do here offer some suggestions regarding how that might work. Common historical practice in mail reading software regarding the mail originator and resent headers has been to present only the contents of the From: header to the users; the other related headers (Sender:, Resent-From:, Resent-Sender:) have not been shown. This behavior SHOULD change. Messages with combinations of identities in the originator headers SHOULD be rendered differently than messages in which the identities are the same. Specifically, it is RECOMMENDED that if the purported responsible address of a message is not the same as the address that would be rendered as the From: address that both these addresses be exhibited to the user. For example, the message in the example from section 3.2.3 might be presented by e-mail client software as being From bob@forwarderexample.com on behalf of adam@example.com Or From adam@example.com via bob@forwarderexample.com instead of the historical From adam@example.com Atkinson. [Page20] INTERNET DRAFT Caller ID May 2004 Indeed, this suggestion is essentially a straightforward generalization of the behavior that exists today in some newer mass market e-mail clients with respect to the processing of From: and Sender: headers. 3.3 Checking of Purported Responsible Domain Once a purported responsible domain p for a message m has been determined, the IP address from which m was received should be compared with the IP addresses from which mail transmitted by the domain p are expected. To that end, the XML E-mail Policy Document of p is consulted with the evaluation of OutGoing(p) to learn the set of possible IP addresses from which mail sent by this domain can be validly transmitted (note that an actual DNS lookup need not occur for each message: significant and even pro-active caching of this information can be carried out). This set of IP addresses is compared to the IP address of the SMTP client transmitting the message (as indicated by the actual TCP connection) in order to determine whether domain spoofing is occurring or not. The outcome of this determination then forms input to the receiving systems mail filter. Moreover, if it is determined that spoofing is occurring then the receiving system SHOULD NOT (section 6.1 of RFC2821 notwithstanding) send any delivery receipts or delivery status notifications with regard to this message. This policy avoids a form of denial-of-service attack wherein such error notification messages are maliciously sent to a third party. 3.3.1 Checking Purported Responsible Domains in E-mail Clients Complications arise when the verification of the legitimacy of a purported responsible domain is carried out in e-mail client software or other software not actually on the organizational edge. Specifically, it is in general quite difficult for such software to know the IP address from which mail was actually delivered into the organization (and against which, of course, the domain check is to be made). Software running on the organizational edge owns the TCP connection in question, and thus can easily find this information; however, this is not true for other software. In many non-edge cases, though, this missing address information can be gleaned through careful and judicious processing of Received: headers (see section 3.6.7 of RFC2822 and section 4.4 of RFC2821). As mail is relayed from SMTP server to SMTP server, Received: headers noting each hop are prepended to the beginning of the message. Therefore, for messages received into a given organization, there is in general some initial prefix of the Received: headers which were added by the organization itself, with the remainder of these headers following this prefix having been Atkinson. [Page21] INTERNET DRAFT Caller ID May 2004 already present in the message before it relayed into the organizations edge SMTP server. Because they were added by the organization itself, it is reasonable that software within the organization can trust the headers in this prefix set. In particular, software can reasonably trust the last header in this prefix (the one added by the organizations edge SMTP server), which quite often has contained within it exactly the TCP-reported IP address needed to perform the Caller ID check. The thorny difficulty, of course, lies in partitioning the Received: headers into the trustable prefix and the untrustable suffix. In general, this is not reliably solvable: there will always continue to remain deployment situations where this information simply is not available, and thus the forgery check cannot be performed by software within the organizational interior. However, various approaches can be used to reduce these situations to a minimum. 3.3.1.1 Look for your inbound mail servers A first such approach seeks to locate Received: headers which indicate that they were added by the inbound mail servers of the domain in question. While the formal syntax of a Received: header is quite liberal, generally speaking a Received: header does actually contain both the SMTP server sending and the SMTP server receiving the message. The former is listed as the From address, while the latter is listed as the By address. For example (but see section 4.4 of [rfc2821] for details): Received: from sendingDomain.com ([1.2.3.4]) by mx.receivingDomain.com; Tue, 4 Nov 2003 14:03:14 -0800 An interesting observation is the following. Suppose that within your organization you find a Received: header in a message where the By address is one of your inbound mail servers (or, more accurately, where the set IP addresses resolved to by the indicated By address has non-empty overlap with the set published inbound mail addresses for your domain per section 5 of [rfc2821]). Then it is reasonable to assume for the purposes of domain spoof checking that all headers up to and including the first such header (call it header re0) were in fact added by your organization. That this is reasonable for this purpose can be seen as follows: 1. If your domain does indeed add such a header re0, then the header re0 and all previous headers were added by an organization you trust, and so the content of the headers can also be trusted. 2. If your domain does not add such a header re0, then if present in the message it must have been provided by an attacker from outside the organization in an attempt, presumably, to defeat the Caller ID check logic. Note, Atkinson. [Page22] INTERNET DRAFT Caller ID May 2004 however, that even if the attacker instead did nothing at all (that is, didnt add re0) that the Caller ID check would not in this scenario have been performed, due to lack of knowledge of the IP address from which the mail was delivered into the organization. Thus, the attacker cannot achieve any benefit by adding re0 that he would not have received anyway. Once re0 is located, then immediately subsequent headers may also be attributed as being added by your organization so long as at least one of the following is true: a. The header also has a By address which is also one of your inbound mail servers b. The header has a By address which resolves to an IP address set which contains only non-Internet routable addresses [rfc1918]. Let re be the last header added by your organization as determined by this algorithm. Then, if the From address of re contains a TCP-reported IP address (per the TCP-info production of section 4.4 [rfc2821]), it is reasonable to believe that that address is the address from which your organization received the message, and to perform the Caller ID check on the message using that address as input. It is worth repeating that the algorithm of this first approach is not reliable, in that there are many ways in which an organizations systems may be configured so as to prevent software inside the organization which parses Received: headers from finding the desired IP address. In particular, there historically has been little technical incentive to ensure that ones inbound mail servers are evident from ones added By addresses, and so it should not be surprising that some domains are not configured in this manner. Though it is usually easy to rectify this situation, the next section presents an alternative approach which may also be pursued. 3.3.1.2 Look for something from your domain administrator Locating the Received: header added by your organizational edge would be trivially easy if two conditions were met. 1. There existed some distinguished character string s that all edge SMTP servers in your organization placed in the Received: headers that they add to incoming messages. 2. The string s was not present in the Received: headers added by any of the non-edge SMTP servers in your organization If these two conditions hold, then the Received: header added by your organizational edge is simply the first Received: header which contains the distinguished string s. Moreover, in practice, it is Atkinson. [Page23] INTERNET DRAFT Caller ID May 2004 often quite straightforward to arrange that these conditions hold, often amounting to little more than using existing administrative infrastructure on the edge servers in question to add some newly concocted distinguished string. Having located the Received: header added by the organizational edge, the IP address from which the message in question was delivered into the organization can be located as described in the previous section. A less straightforward issue is that of how to communicate to software in the interior of an organization that wishes to perform Caller ID checks (for example, e-mail client software, or internal e-mail servers) whether these conditions hold and, if so, what the distinguished string s is. From an operational perspective, this could be carried out in an ad-hoc internal non-standardized manner, since, after all, all the computers in question are under the control of a single administrative entity. That said, having a standardized mechanism for disseminating this information is valuable, as it enables and supports interoperation of software from different vendors. To that end, the following mechanism is defined. The E-mail Policy Document may contain zero or more elements of the form ep/internal/edgeHeader, each of which contains an arbitrary string. If a non-zero number of such elements is present, then the set of strings contained in the collective set of such headers denotes the distinguished strings that are found in the Received: headers added by the edge SMTP servers of this domain. That is, within the domain in question, the first Received: header which contains any of these strings should be understood to be the header which was added by the edge. For example the following E-mail Policy Document indicates that the edge SMTP servers of the domain (which is presumably example.com) always add a Received: header which contains either the string "***example.com edge***" or the string "mx.example.com" and that the Received: headers by SMTP servers inside the organization never contain either of these strings. <ep xmlns="http://ms.net/1"> <internal> <edgeHeader>***example.com edge***</edgeHeader> <edgeHeader>mx.example.com</edgeHeader> </internal> </ep> 3.3.1.3 Parsing Received: headers Formally, the specification of the syntax of Received: headers of Internet mail messages is found in section 4.4 [rfc2821]. Unfortunately, actual practice exhibits considerable deviation from this specification, almost (but not quite) to the point of being free-form text. Naturally, that presents difficulty in parsing them Atkinson. [Page24] INTERNET DRAFT Caller ID May 2004 to locate the From and By addresses therein. In practice, the following heuristics to locating this information have been found to be workable. 1. If the first case-insensitive whitespace-separated word of the header isnt "From", then the header cannot be successfully parsed. 2. Find the first occurrence of the case-insensitive whitespace-separated word "By" before the first semicolon, outside of any parentheses, brackets and quotation marks. If none exists, then the header cannot be successfully parsed. 3. In between, if anything looks like an IP address, that's the From address. An IP address, for these purposes, is four sets of digits, separated by periods, and optionally followed by a colon and another set of digits. Otherwise, if anything in between looks like a domain name, then that's the From address. A domain name, for these purposes, is sets of domain-legal characters separated by periods. It must have a least one period, and its last character must be alphabetic. Otherwise, the header cannot be successfully parsed. 4. If the first word after the By looks like a domain name, then thats the By address. Otherwise, the header cannot be successfully parsed. 3.4 Domains Which Only Send Mail Directly to Recipients One important sub-case of the general issue discussed in section 3.2.4 regarding multiple apparent responsible identities warrants special attention and consideration. As we explored previously, the life of an e-mail message as it flows from its original sender to its ultimate recipient can in general be a complex one, possibly involving many occurrences of the message being delivered to a mailing list or forwarding service where it is updated and subsequently reintroduced and sent on to a different destination. However, not all mail is subject to the generality of such an arbitrary pattern of flow. In particular, there is an important volume of mail, largely that of business-to-consumer correspondence involving billing statements, account maintenance, and the like, which will never legitimately be sent to mailing-lists. From the senders perspective, such mail is being delivered directly to what they believe to be the ultimate recipient. If the organizations which have this policy can communicate that fact to mail receivers, then receiving systems can with greater confidence apply significantly pejorative penalties to mail they receive which is in violation of the policy. Domains which have this kind of policy can indicate so in their E- mail Policy Document. Specifically, a domain owner can indicate that mail from their domain only sends mail directly to their Atkinson. [Page25] INTERNET DRAFT Caller ID May 2004 ultimate recipients by including on the ep/out element of their E- mail Policy Document a directOnly attribute with a true value. A receiving system SHOULD interrogate this information once they have determined for a given message that domain spoofing is not taking place. Specifically, if the Caller ID check passes, and the purported responsible domain of the message is different than the domain of the first mailbox in the From header in the message (the From Domain), then the receiving system SHOULD retrieve the E- mail Policy Document of the From Domain. If the document exists and contains a directOnly attribute on its ep/out element which has a true value, then the receiving system can conclude that the message is in violation of the delivery policy of its sender. As a consequence, the receiving system SHOULD apply significantly pejorative penalties to mail, unless it has additional local knowledge (such as known recipient lists) that might reasonably override that behavior. Note that the policy of sending mail directly to recipients can only be expressed on the granularity of a domain. As a result, domain owners who wish to avail themselves of this facility will need to separate their direct-only mail from the rest and use a different domain for each. For example, if Humongous Insurance wished to use this mechanism, they might use humongousinsurance.com for the direct-only correspondence they have with their customers and something like corp.humongousinsurance.com as the domain by which their employees conducted their business with outside partners and collaborators. Alternately, humongousinsurance.com might be set up as the employee domain, and designated subdomains such as sales.humongousinsurance.com and support.humongousinsurance.com could be used for the direct-only customer correspondence. 4 XML Schema As was described above, the element ep from the following XML schema should be used to indicate e-mail policies associated with a given DNS domain or e-mail address. This section presents the complete schema definition for the E-mail Policy Document. <?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="http://ms.net/1" xmlns="http://ms.net/1" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" blockDefault="#all"> <xs:complexType name="ExtensibleString"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:anyAttribute namespace="##other" processContents="lax" /> Atkinson. [Page26] INTERNET DRAFT Caller ID May 2004 </xs:extension> </xs:simpleContent> </xs:complexType> <xs:element name="ep"> <xs:complexType> <xs:sequence> <xs:element name="scope" minOccurs="0"> <xs:complexType> <xs:choice> <xs:element name="domain" type="ExtensibleString" /> <xs:element name="element" type="ExtensibleString" /> <xs:sequence> <xs:element name="message-id" type="ExtensibleString"/> <xs:element name="date" type="ExtensibleString" minOccurs="0"/> </xs:sequence> <xs:any namespace="##other" ="lax"/> </xs:choice> <xs:anyAttribute namespace="##other processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="in" minOccurs="0"> <xs:complexType> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="hashedPuzzle"> <xs:complexType> <xs:attribute name="nMin" type="xs:nonNegativeInteger"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:any namespace="##other" processContents="lax"/> </xs:choice> <xs:anyAttribute namespace="##other"/> </xs:complexType> </xs:element> <xs:element name="out" minOccurs="0"> <xs:complexType> <xs:sequence> <xs:choice minOccurs="0"> <xs:element name="noMailServers"> <xs:complexType> <xs:anyAttribute namespace="##other" processContents="lax"/> Atkinson. [Page27] INTERNET DRAFT Caller ID May 2004 </xs:complexType> </xs:element> <xs:element name="m" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:choice minOccurs="0"> <xs:element name="indirect" type="ExtensibleString" maxOccurs="unbounded" /> <xs:choice maxOccurs="unbounded"> <xs:element name="a" type="ExtensibleString"/> <xs:element name="r" type="ExtensibleString"/> <xs:element name="mx" type="ExtensibleString"/> </xs:choice> </xs:choice> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="eNoop" type="xs:boolean" use="optional"/> <xs:attribute name="allETPSigned" type="xs:boolean" use="optional"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> </xs:choice> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element name="cdl" type="ExtensibleString"/> </xs:sequence> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="directOnly" type="xs:boolean" use="optional"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:element name="internal" minOccurs="0"> <xs:complexType> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="edgeHeader" Atkinson. [Page28] INTERNET DRAFT Caller ID May 2004 type="ExtensibleString"/> <xs:any namespace="##other" processContents="lax"/> </xs:choice> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:any namespace="##other" processContents="lax"/> </xs:sequence> </xs:sequence> <xs:attribute name="testing" type="xs:boolean" use="optional" default="false"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:element> </xs:schema> 4.1 Schema Notes The testing attribute which may optionally be present on an ep element provides a means by which an E-mail Policy Document can be tentatively deployed in an experimental mode. Documents in which such attribute is present with a true value SHOULD be entirely ignored (one should act as if the document were absent) unless one has cause by some other means (such as a private arrangement with the document publisher) to do otherwise. Most of the XML elements defined here allow for an extensible set of attributes to be attached; this is signified by the presence of definitions of the form <xs:anyAttribute namespace="##other"/> in the schema. Software interpreting an E-mail Policy Document SHOULD ignore such extended attributes that it finds which it doesnt semantically understand; those wishing to avail themselves of this mechanism MUST in their design allow that this may occur. Similarly, several places in the schema permit extensibility in the form of the introduction of arbitrary new XML elements; this is signified by the presence in the schema of wildcard definitions of the form <xs:any namespace="##other" processContents="lax"/>. With one exception, software interpreting an E-mail Policy Document SHOULD simply ignore any extended elements that it finds which it doesnt semantically understand. The exception pertains to the extensible elements permitted in the scope element: E-mail Policy Documents indicated as applying to scopes not understood by the interpreting application should be ignored in their entirety. Those wishing to avail themselves of the use of extended XML elements in Atkinson. [Page29] INTERNET DRAFT Caller ID May 2004 E-mail Policy Documents MUST in their design accommodate these processing rules. The optional scope element indicates the applicability of this particular policy. The possible options are a given DNS domain, a particular e-mail address, or a particular e-mail message as designated by the value of its Message-Id: header; alternate scoping mechanisms can be accommodated in the wildcard child of the scope element. If the scope element is omitted, the scope it is to be inferred from contextual use. If an ep element is stored in the E-mail Policy Document of a given DNS domain, then the scope MUST either be present with a value of domain equal to the domain in question, or scope MUST be omitted. Use of E-mail Policy Documents with message-id scope begins to enable a form of a machine-interpretable challenge-response mechanism. When attached to a transmitted message (in an E- mailPolicy: header) such a policy document indicates policy that the address listed in the From: header of the message has with regard to a second message, namely the one whose Message-Id: header is as indicated (and where, if present, the scope/date element, which must contain a date formatted per section 3.6.1 [rfc2822], also semantically matches the Date: header on the message). On a challenging side, the policy indicated usually has its useful semantic content beneath the ep/in element, where it can list information that it wishes were known for the second identified message; on the response side, useful information is usually contained beneath the ep/out element. Further details of such mechanisms are beyond the scope of this specification. The optional internal element indicates e-mail related policies that might be of interest internally within the scope (usually a domain) with which this policy is associated. Publishing this internal information in DNS might be a convenient mechanism for disseminating the information through the organization associated with the domain. Be aware, however, that generally speaking, such information will be publicly accessible, and so private or sensitive information should not be placed here. The one architected element within internal is edgeHeader which denotes, as previously described, a distinguished string which will reliably be found in Received: headers added the incoming SMTP serves on the edge of a given domain (in e-mail policy documents of non-domain scope, the edgeHeader element has no meaning). Publishing this information in this publicly accessible way should cause little concern, since the contents of the Received: headers in ones mail undoubtedly already make their way outside the organization as mail is forwarded, bounced, and so on, and so ought not to be sensitive information. That said, those organizations for which this remains a concern should simply not avail themselves of the edgeHeader mechanism. Atkinson. [Page30] INTERNET DRAFT Caller ID May 2004 The description of the remaining elements of this schema is beyond the scope of this specification. Readers are reminded that XML Schema specifies that values of type boolean may use either "true" or "1" to represent a true value and either "false" or "0" to represent a false value. The following is an example XML instance of an ep element that applies to the example.com domain. example.com list two outbound mail servers: the IP address 1.2.3.4, together with whatever IP addresses result from DNS address resolution on the domain example.com itself. Note that, per reference [XML], the encoding declaration <?xml ... ?> may generally be omitted on XML instances that are UTF-8 encoded. <?xml version="1.0" encoding="UTF-8"?> <ep xmlns='http://ms.net/1'> <scope> <domain>example.com</domain> </scope> <out> <m> <a>1.2.3.4</a> </m> <m><mx/></m> </out> </ep> 5 Security Considerations There are some subtle consequences of the approach presented here for providing Caller ID information for e-mail. 5.1 DNS Security Considerations The use of DNS described in section 3.1 warrants careful examination from a security perspective. The DNS protocol has a simple request-response design. DNS requests and responses are traditionally transported using UDP, though TCP is also broadly supported [rfc1035]. All DNS communications are carried out in a single message format; the same format is used in both requests and responses. The top level format of the message is divided into five sections, some of which are empty in certain cases: 1. a header, 2. a question for the DNS server, 3. some resources records answering the question, Atkinson. [Page31] INTERNET DRAFT Caller ID May 2004 4. some resource records pointing towards other servers that might be of better assistance in answering the question, and 5. resource records holding additional information. An important aspect of the DNS architecture is that answers may be cached by clients so that subsequent requests to the server may be avoided; the duration over which this caching may be permitted is indicated by the server as part of each answer, and is known as a "time to live" (TTL). One particular piece of information in the DNS header is used to match up responses to outstanding requests: a 16-bit identification field is provided by the requesting client, and this value is copied into the corresponding response by the DNS server (the questions in the request are similarly copied to the response). If a client is careful in the manner in which it reuses values for the identification field, this allows several DNS requests to be issued in parallel from a given source IP address, source UDP port pair. The same mechanism, however, provides opportunity for a straightforward hijacking attack, though one difficult to achieve in practice: if an attacker manages to deliver a matching response for an outstanding request before the arrival of the legitimate response from the DNS server, such a fraudulent response will be indistinguishable from the legitimate one. The primary impediments to carrying out this attack include providing the correct value of the identification field, ensuring that the questions in the response match those in the request, and achieving the necessary packet timing. If the DNS client software uses a good random number for the generation of the identification field, an attacker on average must attempt roughly 216 responses differing significantly only in this field in order to be successful in achieving the correct value; all but one of these will be seen by the DNS client as ill-formed. Moreover, all these responses must be sent quickly, in order that they arrive before the legitimate response. These characteristics taken together provide a means of defense: DNS client software ought to monitor for such situations and consider themselves under attack if detected. Unfortunately, such sophistication is rare today. Normally, it is virtually impossible for an attacker to successfully carry out a DNS hijack attack. In addition to the difficulty in matching the identification field value, attackers usually have no intrinsic means to know when a particular DNS client might happen to make a certain particular query request, so providing a corresponding fraudulent response before the DNS server does is very, very difficult. However, if we are not careful, then depending on the particular usage scenario the same may not always hold true of the use of DNS as articulated above for publishing the identity of outbound mail Atkinson. [Page32] INTERNET DRAFT Caller ID May 2004 servers. Specifically, if an attacker attempting to send domain- spoofed mail to an SMTP server also carries out a DNS hijacking attack on the server, he can to some degree use the timing of his delivery of the mail in order to help estimate when the receiving infrastructure will query DNS for the outbound mail server information of the domain in question. Moreover, given the specification of XML E-mail Policy Document s, the attacker knows to a very high degree the nature of the questions in these query requests. By using this timing and question-knowledge information, the attacker has an easier time succeeding than would otherwise be the case. That said, important mitigating factors should be noted. First, while the architecture of DNS does indeed admit attacks, it is unclear whether it is economical for a spammer to exploit them, especially on a scale of any significant volume. Second, unlike many spamming activities, this particular form of attack is a criminal act in many jurisdictions. Moreover, due to the nature of the DNS caching architecture, the execution of the attack tends to leave persistent evidence of its existence. Finally, the degree of vulnerability varies considerably depending on the particular usage scenario: for example, scenarios where the caller ID check is performed in the organizational interior rather than on the organizational edge because there is a lesser timing correlation with the actions of the attacker. Fortunately, in these latter scenarios (the edge ones), there is already an expectation of SMTP queuing and delay, which allows us to take certain countermeasures. With these considerations in mind, the following additional mitigating approaches may be employed: 1. Applications SHOULD where possible use DNS client software that monitors for and guards against attacks. 2. Especially for DNS queries for XML E-mail Policy Documents issued against DNS servers that reside outside of ones organization, applications SHOULD where possible specify to their DNS client software that TCP-based DNS queries be used and UDP-based queries be avoided (note that this approach is also driven by size considerations). If this technique is used, then attackers attempting to spoof the result of the query face the additional burden of guessing TCP/IP sequence numbers used within the connection. This significantly decreases the feasibility of a successful attack. 3. SMTP servers receiving mail SHOULD introduce a random delay between the determination that the outbound servers for a certain domain are required and the issuance of the actual DNS query that requests their addresses. Though clearly a greater variability in this delay provides greater protection, even variability on the order of several seconds is very worthwhile. 4. As XML E-mail Policy Document s cached by a DNS client on behalf of an SMTP server expire under the TTL caching policy indicated by the server, they MAY be proactively refreshed Atkinson. [Page33] INTERNET DRAFT Caller ID May 2004 by the SMTP server on a schedule independent of the further reception of mail from the domains in question. For these domains, this decouples the timing of the XML E-mail Policy Document DNS queries from the timing of transmission of mail from those domains, thus making attacks more difficult. The benefit to be achieved in adopting any one or all of these mitigating approaches needs to be balanced against the costs and impediments each has to successful and broad deployment (indeed, for these reasons, use of DNSSEC is not among the list of recommended mitigations). We must also keep in perspective that the consequence of a successful attack is simply that some mail that ought to be considered to be spam may fail to be detected as such and thus appear with more prominence to a user; that is, such consequences are considerably less severe than attacks in other situations, such as computer viruses. 5.2 SMTP Security Considerations In using the IP address as reported by TCP as part of the process of eliminating domain spoofing described above, there is a small concern that TCP hijacking may successfully be able to forge this address. While such hijacking is not easy and is somewhat expensive to achieve, particularly with reasonable TCP/IP implementations which well-randomize their initial TCP sequence numbers and monitor for sequence number guessing attacks, it is unfortunately the case that the SMTP protocol is of the nature that one can accomplish significant mayhem (specifically, one can send mail) by hijacking just the sending side of the two-way TCP connection; this is in contrast to many other protocols where hijacking of both directions of the connection is effectively necessary in order to wreak havoc, a much more difficult attack to carry out. In order to alleviate the concern of such an attack, we propose here a small enhancement to the SMTP protocol wherein the SMTP client demonstrates to the SMTP server that it has actually received some unique data returned previously by the server. With such enhancements in use, one-sided TCP hijackings are no longer effective against SMTP. Because this enhancement operates at the SMTP level, it can be used without the need to rely on particular safety-conscious behavior of the perhaps varying underlying TCP implementations on which the SMTP software may be deployed, thus providing an increase in overall resilience of the system to attack. Specifically, prior to sending any SMTP MAIL commands, an SMTP client SHOULD send to its server an SMTP NOOP command (see section 4.1.1.9 of [rfc2821]) with a parameter containing the following: Atkinson. [Page34] INTERNET DRAFT Caller ID May 2004 The 40 case-insensitive characters of the hexadecimal encoding of the SHA1 hash of the entire data provided previously by the server in its EHLO response (that is, the entire sequence of characters matching the ehlo-ok-rsp production found in section 4.1.1.1 of [rfc2821]). By including a pseudorandom string as part of its EHLO response, an SMTP server can have reasonable confidence that, upon the receipt of such a NOOP command, the SMTP client is in fact receiving its responses, and one-side TCPIP hijacking is not occurring. Note that, as a security consideration, the SMTP server provides no indication in response to the NOOP as to whether a correct hash value was provided. Use or support of this enhanced NOOP command on the part of SMTP clients (and servers) is wholly OPTIONAL: absent the need to send this NOOP, no e-mail or DNS server software need be updated on the client side in order to for an SMTP client to participate in the design proposed here for publication of outbound mail server information; this simplicity is a significant factor that ought to foster its adoption. In order to preserve this characteristic while also allowing for enhanced NOOP support where possible, we provide a means by which the administrator of a domain can indicate whether any or all of its outbound mail servers support the enhanced NOOP. Such administrative indication on the part of the legitimate domain owner defeats an attempt by a potential hijacker to merely pretend that the domain he wishes to impersonate merely does not have enhanced-NOOP-aware software. The administrative mechanism makes use of the optional eNoop XML attribute which may be found on ep/out/m elements in XML E-mail Policy Documents (see section 4 above for details of this XML schema). This attribute, if present, indicates published knowledge of the behavior of particular outbound mail server(s) with respect to their using the enhanced NOOP; if the attribute is absent, then no information is provided as to whether the outbound servers will use the NOOP or not. 6 References Normative and informative references are provided. 6.1 Normative References [STDWORDS] Bradner, S.; "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119. http://www.ietf.org/rfc/rfc2119.txt?number=2119 [XML] Worldwide Web Consortium, Extensible Markup Language (XML) 1.0 (Second Edition), http://www.w3.org/TR/REC-xml Atkinson. [Page35] INTERNET DRAFT Caller ID May 2004 [rfc1035] Mockapetris. P; "Domain Names - Implementation And Specification" RFC1035 http://www.ietf.org/rfc/rfc1035.txt [rfc1918] Rekhter, Y. et al; "Address Allocation for Private Internets" RFC1918 http://www.ietf.org/rfc/rfc1918.txt [rfc2821] Klensin, J. Editor; "Simple Mail Transfer Protocol" RFC2821 http://www.ietf.org/rfc/rfc2821.txt [rfc2822] Resnick, P. Editor; "Internet Message Format" RFC 2822 http://www.ietf.org/rfc/rfc2822.txt 6.2 Informative References [RMX] Danisch, Hadmut, The RMX DNS RR and method for lightweight SMTP sender authorization, http://www.danisch.de/work/security/txt/draft- danisch-dns-rr-smtp-03.txt. [LMAP] DeKok, A. (Ed.), Lightweight MTA Authentication Protocol (LMAP) Discussion and Applicability Statement, November 3, 2003, http://asrg.kavi.com/apps/group_public/download.php/1 8/draft-irtf-asrg-lmap-discussion-00.txt [SPF] Wong, Meng Weng, Hadmut Danish, Gordon Fecyk Mark Lentczner, Sender Permitted From, http://spf.pobox.com. [rfc3123] Koch, P; "A DNS RR Type for Lists of Address Prefixes" RFC3123 http://www.ietf.org/rfc/rfc3123.txt 7 Acknowledgments The authors would like to thank the following for their lively debate and input which greatly improved this document. Khaja Ahmed, Eric Allman, Hans Peter Brondmo, Cynthia Dwork, Andrew Goldberg, Joshua Goodman, Phillip Hallam-Baker, Jim Lyon, Harry Katz, Margaret Olson, Robert Rounthwaite, Ken Schneider, Roy Williams. Atkinson. [Page36] INTERNET DRAFT Caller ID May 2004 8 Author Contact Information Robert Atkinson Microsoft Corporation One Microsoft Way Redmond WA 98052 USA E-mail: bobatk@microsoft.com Atkinson. [Page37] INTERNET DRAFT Caller ID May 2004 9 Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Atkinson. [Page38]