MARID M. Lentczner Internet-Draft M. Wong Expires: March 16, 2005 September 15, 2004 Authorizing Use of Domains in MAIL FROM draft-ietf-marid-mailfrom-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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. This Internet-Draft will expire on March 16, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract Mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction in what a sending host can use as the reverse-path of a message. This document describes a protocol whereby a domain can explicitly authorize the hosts that are allowed to use its domain name in a reverse-path, and a way for receiving hosts to check such authorization. Lentczner & Wong Expires March 16, 2005 [Page 1] Internet-Draft Authorizing Use of Domains in MAIL FROM September 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 The Mail From Identity . . . . . . . . . . . . . . . . . . 3 2.2 Publishing Authorization . . . . . . . . . . . . . . . . . 4 2.3 Checking Authorization . . . . . . . . . . . . . . . . . . 4 2.4 Interpreting the Result . . . . . . . . . . . . . . . . . 5 2.4.1 Neutral . . . . . . . . . . . . . . . . . . . . . . . 5 2.4.2 Pass . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4.3 Fail . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4.4 SoftFail . . . . . . . . . . . . . . . . . . . . . . . 6 2.4.5 None . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4.6 TempError . . . . . . . . . . . . . . . . . . . . . . 6 2.4.7 PermError . . . . . . . . . . . . . . . . . . . . . . 7 3. Implications . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Sending Domains . . . . . . . . . . . . . . . . . . . . . 7 3.2 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 7 3.3 Forwarding Services . . . . . . . . . . . . . . . . . . . 8 3.4 Mail Services . . . . . . . . . . . . . . . . . . . . . . 8 3.5 MTA Relays . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 11 Lentczner & Wong Expires March 16, 2005 [Page 2] Internet-Draft Authorizing Use of Domains in MAIL FROM September 2004 1. Introduction The current e-mail infrastructure has the property that any host injecting mail into the mail system can identify itself as any domain name it wants. Hosts can do this at a variety of levels: in particular, the session, the envelope, and the mail headers. While this feature is desirable in some circumstances, it is a major obstacle to reducing end-user unwanted e-mail (or "spam"). Furthermore, many domain name holders are understandably concerned about the ease with which other entities may make use of their domain names, often with intent to impersonate. This document defines a protocol by which hosts my be authorized by domains to use the domain name in the envelope "Mail From" identity. Compliant domain name holders publish SPF records about which hosts are permitted to use their names, and compliant mail receivers use the published SPF records to test the authorization of hosts using a given "Mail From" identity during a mail transaction. An additional benefit to mail receivers is that when the use of an identity is verified, then local policy decisions about the mail can be made on the basis of the domain, rather than the host's IP address. This is advantageous because reputation of domain names is likely to be more accurate than reputation of host IP addresses. Furthermore, if a claimed identity fails verification, then local policy can take stronger action against such e-mail, such as rejecting it. 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 [RFC2119]. This document is concerned with a portion of a mail message commonly called "envelope sender", "return path", "reverse path", "bounce address", "2821 from", or "mail from". Since these terms are either not well defined, or often used casually, this document defines the "Mail From" identity in Section 2.1. Note that other terms, that may superficially look like the common terms, such as "reverse-path" or "Return-Path" are used only with the defined meanings from normative documents. 2. Operation 2.1 The Mail From Identity The "Mail From" identity derives from the SMTP MAIL command (see Lentczner & Wong Expires March 16, 2005 [Page 3] Internet-Draft Authorizing Use of Domains in MAIL FROM September 2004 [RFC2821].) This command supplies the "reverse-path" for a message, which generally consists of the sender mailbox, and is the mailbox to which notification messages are sent if there are problems delivering the message. This document defines the "Mail From" identity to be mailbox portion of the path of the reverse-path as defined in [RFC2821], Section 4.1.2. when it is non-null. [RFC2821] allows the reverse-path to be null (see Section 4.5.5.) In this case, there is no explicit sender mailbox, and such a message can be assumed to be a notification message from the mail system itself. When the reverse-path is null, this document defines the "Mail From" identity to be the mailbox composed of the localpart "postmaster" and the domain supplied with the SMTP EHLO or HELO command. Note that requirements for the domain presented in the EHLO and HELO commands are not strict, and software must be prepared for a "Mail From" identity so constructed to be ill formed. Generally, software that checks the authorization checks described below does so during a SMTP transaction, and so readily has the information required at hand. However, software could perform these checks at a different time, and if so, may extract the reverse-path from the "Return-path" header as described in [RFC2821]. However, it must be noted that while required, not all software complies with inserting such headers. Furthermore, in these cases, if the reverse-path is null, there may not be a reliable way to determine the corresponding EHLO or HELO domain from the "Received:" headers. 2.2 Publishing Authorization To authorize hosts to use a domain name in the "Mail From" identity, those domains MUST publish SPF records for the domain name as described in [Protocol]. SPF records used for the "Mail From" identity use the "mfrom" scope identifier. Domains SHOULD publish SPF records that end in "-all", or redirect to other records that do, so that a definitive determination of authorization can be made. 2.3 Checking Authorization A mail server receiving mail can test the authorization of a client host to inject mail with a given "Mail From" identity. To make the test, the mail receiver MUST evaluate the check_host() function as defined in [Protocol] with the arguments set as follows: Lentczner & Wong Expires March 16, 2005 [Page 4] Internet-Draft Authorizing Use of Domains in MAIL FROM September 2004 - the "mfrom" scope identifier - the IP address of the client host that is injecting the mail - the domain portion of the "Mail From" identity - the "Mail From" identity Note that the argument may not be a well formed domain name. For example, if the reverse-path was null, then the EHLO or HELO domain is used, and that can be an address literal or entirely malformed in a valid SMTP transaction. In these cases, check_host() is defined in [Protocol], Section 3.3, "Initial Processing" to return a Fail result. Software SHOULD perform this authorization check during the processing of the SMTP transaction that injects the mail. This allows errors to be returned directly to the injecting server by way of SMTP replies. Software can perform the check as early as the MAIL command, though it may be easier to delay the check to some later stage of the transaction. Software can perform the authorization after the corresponding SMTP transaction has completed. There are two problems with this approach: 1) As described above, it may not be possible to reconstruct the "Mail From" identity. 2) If the authorization fails, then generating a nondelivery notification to the alleged sender is problematic as such an action would go against the explicit wishes of that sender. 2.4 Interpreting the Result The check_host() function returns one of seven results, some with additional information. This section describes how software that performs the authorization must interpret the results. If the check is being performed during the SMTP mail transaction, it also describes how to respond. 2.4.1 Neutral A Neutral result MUST be treated exactly like a None result. 2.4.2 Pass A Pass result means that the client is authorized to inject mail with the given "Mail From" identity. Further policy checks, such as reputation, or black and/or white listing, can now proceed with confidence based on the "Mail From" identity. Lentczner & Wong Expires March 16, 2005 [Page 5] Internet-Draft Authorizing Use of Domains in MAIL FROM September 2004 2.4.3 Fail A Fail result is an explicit statement that the client is not authorized to use the domain in the "Mail From" identity. The checking software can choose to mark the mail based on this, or to reject the mail outright. If the checking software chooses to reject the mail during the SMTP transaction, then it MUST use a 550 reply code with an appropriate message. The Fail result includes a reason. The reason can be used to construct an appropriate message. If the reason is "Not Permitted", then an explanation string is also returned. This explanation string comes from the domain that published the SPF records and may contain a URL. Since that information doesn't originate with the checking software, the checking software will want to make it clear that text is not trusted. Example reply messages for rejecting are: 550 SPF Mail From check failed: Malformed Domain 550 SPF Mail From check failed: Domain Does Not Exist 550-SPF Mail From check failed: Not Permitted 550-The domain example.com said: 550 Please see http://www.example.com/mailpolicy.html 2.4.4 SoftFail A SoftFail result should be treated as somewhere between a Fail and a Neutral. This value is used by domains as an intermediate state during roll-out of publishing records. The domain believes the host isn't authorized but isn't willing to make that strong of a statement. Receiving software SHOULD NOT reject the message based on this result, but MAY subject the message to closer scrutiny. 2.4.5 None A result of None means that no records were published by the domain. The checking software cannot ascertain if the client host is authorized or not. 2.4.6 TempError A TempError result means that the receiving server encountered a transient error when performing the check. Checking software can choose to accept or temporarily reject the message. If the message is rejected during the SMTP transaction for this reason, the software Lentczner & Wong Expires March 16, 2005 [Page 6] Internet-Draft Authorizing Use of Domains in MAIL FROM September 2004 MUST use a 450 reply code. 2.4.7 PermError A PermError result means that the domain's published records couldn't be correctly interpreted for this "Mail From" identity. Checking software SHOULD reject the message. If rejecting during SMTP transaction time, a 550 reply MUST be used. 3. Implications This section outlines the major implications that adoption of this document will have on various entities involved in Internet e-mail. It is intended to make clear to the reader where this document knowingly affects the operation of such entities. This section is not a "how-to" manual, nor a "best practices" document, and is not a comprehensive list of what such entities should do in light of this document. This section is non-normative. 3.1 Sending Domains Domains that wish to be compliant with this specification will need to determine the list hosts that they allow to use their domain name in the "Mail From" identity. It is recognized that forming such a list is not just a simple technical exercise, but involves policy decisions with both technical and administrative considerations. 3.2 Mailing Lists Mailing lists must be aware of how they re-inject mail that is sent to the list. If the list re-injects mail with the same reverse-path that the mail had when it was received, then that mail may fail the authorization tests defined in this document. In particular, they will fail when the domain of the reverse-path publishes SPF records for the "Mail From" identity, those records do not authorize the mailing list host, and a receiver of the mailing list performs the authorization test. Almost all mailing list software in use for public mailing lists uses a reverse-path with the mailing list's own domain so that the software can receive mail bounces and assist in the administration of the list. Lists that use such software, configured to operate this way will require only one modest change in light of this document: The mailing list host needs to be authorized by the mailing list domain's own SPF record, if the domain publishes one. Lentczner & Wong Expires March 16, 2005 [Page 7] Internet-Draft Authorizing Use of Domains in MAIL FROM September 2004 Mailing lists based on simple alias expansion, or other software that doesn't manage bounces directly, may or may not encounter problems depending on how access to the list is restricted. Such lists that are entirely internal to a domain (only people in the domain can send to or receive from the list) are not affected. 3.3 Forwarding Services Forwarding services take mail that is received at a mailbox and direct it to some external mailbox. At the time of this writing, the near-universal practice of such services is to use the original reverse-path of a message when re-injecting it for delivery to the external mailbox. This means the external mailbox's MTA sees all such mail in a connection from a host of the forwarding service, and so the "Mail From" identity will not in general pass authorization. There are several possible ways that this authorization failure can be ameliorated. If the owner of the external mailbox wishes to trust the forwarding service, they can direct the external mailbox's MTA to skip such tests when the client host belongs to the forwarding service. Tests against some other identity may also be used to override the test against the "Mail From" identity. For larger domains, it may not be possible to have a complete or accurate list of forwarding services used by the owners of the domain's mailboxes. In such cases, white lists of generally recognized forwarding services could be employed. Forwarding services could also skirt the issue by using reverse-paths that contain their own domain. This means that mail bounced from the external mailbox will have to be re-bounced by the forwarding service. Various schemes to do this exist though they vary widely in complexity and resource requirements on the part of the forwarding service. 3.4 Mail Services Entities that offer mail services to other domains such as sending of bulk mail will may have to alter their mail in light of the authorization check in this document. If the reverse-path used for such e-mail uses the domain of the mail service provider, then the provider needs only to ensure that their sending host is authorized by their own SPF record, if any. If the reverse-path does not use the mail service provider's domain, then extra care must be taken. The SPF record format has several options for authorizing the sending MTAs of another domain (the service provider's) (see [Protocol].) Lentczner & Wong Expires March 16, 2005 [Page 8] Internet-Draft Authorizing Use of Domains in MAIL FROM September 2004 3.5 MTA Relays The authorization check generally precludes the use of arbitrary MTA relays between sender of receiver of an e-mail message. However, the use of open MTA relays on the Internet has long been noted as a security problem. Most sites do not run open relays and many refuse e-mail from known open relays. Within an organization, MTA relays can be effectively deployed. However, for purposes of this document, such relays are effectively invisible. The "Mail From" identity authorization check is a check between border MTAs. For mail senders, this means that published SPF records must authorized any MTAs that actually send across the Internet. Usually, this is just the border MTAs as internal MTAs simply forward mail to these MTAs for delivery. Mail receivers will generally want to perform the authorization check at the border MTAs. This allows mail that fails to be rejected during the SMTP session rather than bounced. Internal MTAs then do not perform the authorization test To perform the authorization test other than at the border, the host that first transferred the message to the organization must be determined, which can be difficult to extract from headers. Testing other than at the border is not recommended. 4. Security Considerations Most of the security considerations introduced by the authorization check are due to the SPF record format and the operation of the check_host() function. These considerations are described in [Protocol], Section 8, "Security Considerations". The "Mail From" identity authorization must not be construed to provide more assurance than it does. It is entirely possible for a malicious sender to inject a message with a reverse-path that uses their own domain, to have that domain's SPF record authorize the sending host, and yet the message content can easily claim other identities in the headers. Unless the user, or the MUA takes care to note that the authorized "Mail From" identity does not match the other, more commonly presented identities (such as the From: header), the user may be lulled into a false sense of security. When the authorization check fails with the code "Not Permitted", an explanation string may be included in the reject response. Both the sender and the rejecting receiver need to be aware that the explanation was determined by the publisher of the SPF record Lentczner & Wong Expires March 16, 2005 [Page 9] Internet-Draft Authorizing Use of Domains in MAIL FROM September 2004 checked, and is in general not the receiver. The explanation may contain URLs that may be malicious, and/or offensive or misleading text. This is probably less of a concern than it may seem since such messages are returned to the sender, and their source is the SPF record published by the domain in the "Mail From" identity claimed by that very sender. To put it another way, the only people who see malicious explanation strings are people who's messages claim to be from domains that publish such strings in their SPF records. 5. IANA Considerations None. 6 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [Protocol] Wong, M. and M. Lentczner, "The Sender-ID Record: Format and Interpretation", draft-ietf-marid-protocol-03 (work in progress), September 2004. Authors' Addresses Mark Lentczner 1209 Villa Street Mountain View, CA 94041 United States of America EMail: markl@glyphic.com URI: http://www.ozonehouse.com/mark/ Meng Weng Wong Singapore EMail: mengwong+spf@pobox.com Lentczner & Wong Expires March 16, 2005 [Page 10] Internet-Draft Authorizing Use of Domains in MAIL FROM September 2004 Intellectual Property Statement 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lentczner & Wong Expires March 16, 2005 [Page 11]