Application Working Group C. Haas Internet-Draft Ovation Updates: 2821, 1035, 1183 August 2003 SMTP - Checking Mail Domain Origin draft-haas-smtp-check-mail-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes a method to eliminate domain name "spoofing" over SMTP by introducing a new DNS resource record (RR) [1] type "MDO" that contains valid SMTP sending server for a specified DNS domain. In doing so it addresses section 7.1 of RFC 2821, "Mail Security and Spoofing". 1. Overview The current SMTP specification [2] has no provision to ensure that a "client" has permission to send from a specified domain when sending Internet mail, although it does addresses the fact that this issue can and will occur. Currently the MAIL FROM command is parsed to see Haas [Page 1] RFC nnnn SMTP - Checking Mail Domain Origin August 2003 if it fits the syntax of "user@example.com". This means that any user of any domain can send from any other domain without restrictions. Virus writers and mass mailers have exploited this fact by sending their mail from random addresses and from the recipient's own address. Section 7.1 of RFC 2821 advocated "that useful functionality not be disabled in the hope of providing some small margin of protection against an ignorant user who is trying to fake mail." Unfortunately the scope of the problem has gone from ignorant users to knowledgeable virus writers and mass mailers. While this document is in no way a means to end viruses and unsolicited bulk email (UBE), it is a means for a domain name holder to control the integrity of mail sent from their domain. The goal of this document is to introduce a new DNS RR type called a Mail Domain Origin (MDO) record that will be similar to the current MX record, except its only purpose is to qualify hosts as valid senders for specified domains. This document relies on knowledge of RFC 2821, which defines the current mail protocol, as well as RFC 1034 and 1035 which define the DNS specification. 2. Definitions The terms "sender" and "recipient" can be ambiguous when dealing with mail routing, as there can be multiple hops between the message origin and its intended destination. In this document, the term "sending machine" will designate the machine initiating the SMTP connection and the term "recipient machine" will designate the machine receiving the SMTP session. The term "server" has deliberately been left out to avoid any confusion. In addition, the term "gateway" defines a machine that routes mail between two networks. When a gateway is involved, either the sending machine or the recipient machine will actually be the gateway. 3. The MDO Resource Record The MDO RR is defined with mnemonic MDO and type code . The MDO RR has the structure given below: MDO is required in all MDO RRs Haas [Page 2] RFC nnnn SMTP - Checking Mail Domain Origin August 2003 is the domain name of a host that is authorized to send mail from the domain specified in . The format of the MDO RR is class insensitive. MDO records cause type A additional section processing for . Like MX records, MDO records are not implicitly recursive. An MDO record defined for host.example.com gives privileges to neither sub.host.example.com nor example.com. While most hosts that have MX records listed will have duplicate MDO records, the reverse won't necessarily be true. An organization might have 3 mail servers that can accept incoming mail (thus having MX records) but might have 6 servers that are allowed to send mail. This list could include the 3 original incoming mail servers along with 2 off-site web servers and an internal mailing list server. example.com. IN MX 10 mail1.example.com example.com. IN MX 15 mail2.example.com example.com. IN MX 20 mail3.example.com example.com. IN MDO mail1.example.com example.com. IN MDO mail2.example.com example.com. IN MDO mail3.example.com example.com. IN MDO ww1.example.com example.com. IN MDO ww2.example.com example.com. IN MDO listsrv.example.com 4. Handling MAIL FROM command Upon receiving the MAIL FROM command from the sending machine, the recipient machine will lookup the domain of the address listed in MAIL FROM and check the MDO records for IP addresses that match the IP of the machine initiating the SMTP session. If the IP address is NOT listed, the recipient machine will return an error code of: 550 Sender not authorized for specified domain If the sending machine is listed in the MDO records, then the standard 250 OK will be returned. 5. Gateways The MDO record is intended to help protect domain name owners on the public Internet. Therefore, gateways that take mail from a private network to a public network should have an MDO record as well as implement MDO records checking for all outbound email. Gateways that accept mail from the public Internet should also implement MDO record Haas [Page 3] RFC nnnn SMTP - Checking Mail Domain Origin August 2003 checking. However, recipient servers in private networks behind a gateway are not expected to implement MDO record checking because this would require the gateway to have an MDO record in every sending domain. 6. Ramifications While the changes proposed in this document are relatively minor, their scope will reach across the entire Internet. a) No machine will be allowed to send mail unless it has a proper MDO record or it routes its mail through a machine with a proper one. While most organizations have one or more central mail servers, many have single machines that act as their own SMTP sending servers. These machines would be required to have MDO records for the domains that they send from. b) Because sending machines need MDO records, organizations might decide to route all outgoing mail through certain SMTP machines, thus increasing the number of outgoing messages per machine. 7. Notes This specification is only intended to give domain name holders control over mail sent from their domains. It in no way provides a mechanism for controlling which user at a specified domain can send mail. It is hoped that domain name holders will enforce their own policies so that one user cannot spoof another user's address. 8. References [1] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987. [2] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. 9. Security Considerations If an organization had machines capable of sending and receiving SMTP traffic but only utilized the sending portion, this specification would require either that machine to have an MDO record or that machine to route through a gateway. Using the MDO record an attacker could find additional SMTP machines that a normal MX record lookup wouldn't show. However, the impact of this is negligible because this information could easily be found using a port scan. 10. Author's Address Haas [Page 4] RFC nnnn SMTP - Checking Mail Domain Origin August 2003 Chris Haas Ovation 201 Main St. 6th Floor La Crosse, WI 54601 USA Email:ChrisH@OvationAdvertising.com 11. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE Internet SOCIETY AND THE Internet ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Haas [Page 5]