Network Working Group M. Stumpf Internet-Draft S. Hoehne Expires: August 9, 2004 SpaceNet AG February 9, 2004 Marking Mail Transfer Agents in reverse DNS with TXT RRs draft-stumpf-dns-mtamark-00 Status of this Memo This document is an Internet-Draft and is in full conformance with 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/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 August 9, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract In contrast to other more extensive approaches to deal with unsolicited email, commonly called "spam", this memo discusses a very simple authentication scheme. It uses marking of hosts in reverse DNS (in-addr.arpa zone) to allow the receiving mail transfer agents to decide whether the connecting (sending) host is a designated mail transfer agent (MTA) or not. Despite being a weaker scheme than most of the other proposals currently discussed, it can reduce the amount of spam and viruses/ worms significantly and has the advantage that it can be implemented based on existing and well-established Internet technology like DNS without any changes to that technology. Stumpf & Hoehne Expires August 9, 2004 [Page 1] Internet-Draft Marking MTAs in reverse DNS February 2004 Table of Contents 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. PROPOSAL . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Defining a wellknown subdomain for the reverse DNS tree . . 5 2.2 Protocol specific resource records . . . . . . . . . . . . . 5 2.2.1 Hints for implementors . . . . . . . . . . . . . . . . . . . 6 2.3 Contact Information . . . . . . . . . . . . . . . . . . . . 6 3. Example Records . . . . . . . . . . . . . . . . . . . . . . 8 4. EFFECTS ON EXISTING MAIL INFRASTRUCTURE . . . . . . . . . . 9 4.1 Unmarked Addresses . . . . . . . . . . . . . . . . . . . . . 9 4.2 Local Mail Clients . . . . . . . . . . . . . . . . . . . . . 9 4.3 Roaming Users . . . . . . . . . . . . . . . . . . . . . . . 9 4.4 Classless IP Allocations . . . . . . . . . . . . . . . . . . 9 4.5 IPv6 Compatibility . . . . . . . . . . . . . . . . . . . . . 10 5. REGISTRATION OF A NEW DNS RR . . . . . . . . . . . . . . . . 11 5.1 Why we do not propose a new DNS RR . . . . . . . . . . . . . 11 5.2 Into the Future . . . . . . . . . . . . . . . . . . . . . . 11 6. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . 12 References . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . 16 Stumpf & Hoehne Expires August 9, 2004 [Page 2] Internet-Draft Marking MTAs in reverse DNS February 2004 1. INTRODUCTION The problem with spam and viruses/worms has increased and changed a lot during the last years. At the beginning distributing unsolicited email was accomplished by abusing relay open mailservers [14]. Spread of viruses needed humans passing on infected data. The situation today shows worms coming packed with their own SMTP modules and utilizing address books and scanning documents for new addresses and therefore victims. A lot of worms install backdoors and (enable) proxy servers. These infected hosts are afterwards abused by spammers to send unsolicited email. With growing adoption of DSL techniques a significant part of the Internet, hosts shifted to poorly maintained workstations in homes. Permanently connected to the Internet, these hosts form an easy and "paying" prey for worms and abusers. Not only in homes, also in companies the number of poorly maintained hosts is growing. History and viruses like VBS/LoveLet class or worms like CodeRed and Nimda and the zillions of open proxy servers show, we cannot count on users or administrators to get the problems fixed. However, what the administrators can decide proactively is whether a certain host, represented by its IP address, is meant to be a MTA that should have the ability to talk to other MTAs across the Internet. Most - if not all - proxy servers or workstations do not need to have this ability. We suggest a mechanism to enable the administrator to mark IP addresses in the Domain Name System [1], [2] with labels meaning o "This IP address is assigned to a MTA that is intended to send messages across the Internet" o "This IP address does not host a MTA, do not accept emails from that IP address." and therefore give receiving MTAs a hint as whether to accept messages from the sending MTA or not. This document describes such a mechanism that o is easy, fast and cheap to deploy and implement, o uses existing Internet technology without modification and without breaking it or the need for workarounds While this document specializes on SMTP the proposal ist not limited Stumpf & Hoehne Expires August 9, 2004 [Page 3] Internet-Draft Marking MTAs in reverse DNS February 2004 to SMTP, but can be adopted to any protocol and is easily extensible. 1.1 Terminology The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC2119 [11]. Stumpf & Hoehne Expires August 9, 2004 [Page 4] Internet-Draft Marking MTAs in reverse DNS February 2004 2. PROPOSAL 2.1 Defining a wellknown subdomain for the reverse DNS tree Storing arbitrary string attributes in the Domain Name System [5] is a technique described and used at least since 1993. However this method does not support specific queries and has a high overhead in parsing the responses, is prone to naming collisions and will trigger errors and problems in old implementations of DNS servers with the 512 byte size limit. Thus we propose expanding the reverse DNS tree by a service subdomain with the wellknown name _srv 2.2 Protocol specific resource records Within this service subdomain there will be another subdomain named after the protocol for which the service specific records will be defined. For SMTP the name of the subdomain will be _smtp Whether SMTP connections are to be allowed/or disallowed from that host is specified by a TXT record within the protocol subdomain for the entry _perm The value of the TXT record will be either "1" or "0": 1 - (MTA=yes) indicates that the connection is originating from an IP address that is intended to be a MTA talking to other MTAs across the public Internet and that the message SHOULD be accepted. 0 - (MTA=no) indicates that the IP address of the sending communication partner is NOT meant to be a MTA and that messages SHOULD NOT be accepted from that connection, unless successful authentification via other methods (e.g. ODMR [16]) advise the contrary. Stumpf & Hoehne Expires August 9, 2004 [Page 5] Internet-Draft Marking MTAs in reverse DNS February 2004 2.2.1 Hints for implementors o The record for a given protocol MUST be unique for a given IP address within the "_perm" subdomain. In the case of multiple contradictory records they MUST be treated as one record having the value 0 (MTA=no). o If the value of the resource record is other than "1" (MTA=yes) or "0" (MTA=no) the value MUST be treated as "0" (MTA=no). o If there are multiple TXT resource records for one protocol with identical values implementors SHOULD treat them as one record. 2.3 Contact Information The contact information provides automatic notification of administrators, if hosts within their responsibility get abused or infected by viruses. Currently there is no easy way to get information about contacts for a given IP address. There are a lot of different sources, where the best are probably the whois databases of the various (Regional Internet Registries (RIR) like ARIN, RIPE or APNIC. However, there is no common agreed upon format for abuse contacts, and for some allocations referrals have to be followed to other registries like BRNIC or AUNIC, that again use different record formats. An easy way to specify contact information for a given IP address is to use the Responsible Person (RP) resource record as defined in RFC 1183 [4] Another use of an email address provided with the contact information is the possibility for a MTA to customize the error message [18], [8] like in 550-5.7.1 Message rejected. Sender is not labelled a valid MTA. 550 5.7.1 Please contact . where "abuse@example.com" is derived from the information stored in the RP records. The RP resource records SHOULD be inserted into the IN-ADDR.ARPA zone at the same level as the PTR records for reverse DNS. However, there may be more than one contact address for various protocols involved, so protocol specific contact information may also be provided at the protocol subdomain level. Programs utilizing Stumpf & Hoehne Expires August 9, 2004 [Page 6] Internet-Draft Marking MTAs in reverse DNS February 2004 these records should first query for RP records along with the protocol subdomain and if that fails try again and query for RP records at the PTR level. More than one RP resource record may be specified. It is up to the reporting program or person to choose a random contact to notify or send notification to all of them. Stumpf & Hoehne Expires August 9, 2004 [Page 7] Internet-Draft Marking MTAs in reverse DNS February 2004 3. Example Records Some examples how records might look like in BIND syntax: 1.0.0.10.in-addr.arpa. IN PTR mail.example.com. _perm._smtp._srv.1.0.0.10.in-addr.arpa. IN TXT "1" _smtp._srv.1.0.0.10.in-addr.arpa. IN RP abuse.example.com. . 2.0.0.10.in-addr.arpa. IN PTR www.example.com. 2.0.0.10.in-addr.arpa. IN RP abuse.example.com. . _perm._smtp._srv.2.0.0.10.in-addr.arpa. IN TXT "0" _smtp._srv.2.0.0.10.in-addr.arpa. IN RP spam.example.com. . Stumpf & Hoehne Expires August 9, 2004 [Page 8] Internet-Draft Marking MTAs in reverse DNS February 2004 4. EFFECTS ON EXISTING MAIL INFRASTRUCTURE One of the main goals of this proposal has been to limit the impact on existing Internet infrastructure as much as possible. Putting this proposal in effect will not break existing infrastructure or widely used mechanisms like gatewaying, forwarding and (authenticated) relaying of emails 4.1 Unmarked Addresses Each receiving MTA is free to decide how to classify connections from IP addresses without the marks as defined in this document. However, as a general guideline, we propose a grace period of six months after publication of this document, where missing marks are to be treated with a default of "MTA=yes" and after the grace period missing marks are to be treated as "MTA=no". Implementors are asked to provide a mechanism for the administrator to easily specify a default behavior for unmarked IP addresses. 4.2 Local Mail Clients MTAs implementing the policy defined in this document should take care to provide mechanisms for the administrators to easily specify a list of "local addresses" which use the receiving MTA as an outgoing relay. The MTA will accept messages from those IP addresses despite not being marked as "MTA=no". 4.3 Roaming Users Typically, roaming users or local users from dialin/dynamic IP addresses have "MTA=no" set on the connection to the receiving MTA. The ODMR [16] extension to the SMTP protocol [18] specifies a way for roaming users to authenticate themselves to the receiving MTA and validate the connection. Authenticated connections must be accepted, even when the connecting IP address is marked as "MTA=no". Implementors must take care not to reject connections before the initiator of the connection had the chance to authenticate himself. 4.4 Classless IP Allocations In case of delegated address spaces covering fewer than 256 addresses and therefore using an extended IN-ADDR.ARPA tree [12] the Stumpf & Hoehne Expires August 9, 2004 [Page 9] Internet-Draft Marking MTAs in reverse DNS February 2004 specification of the resource records must take place in the corresponding IN-ADDR.ARPA zone of the (autonomous/current) maintaining authority of the subnet. No other records are allowed to coexist with a CNAME record [9]. 4.5 IPv6 Compatibility This proposal is fully compatible with IPv6. The same TXT and RP RRs and lookup mechanisms can be applied to the "ip6.arpa" zone. Stumpf & Hoehne Expires August 9, 2004 [Page 10] Internet-Draft Marking MTAs in reverse DNS February 2004 5. REGISTRATION OF A NEW DNS RR 5.1 Why we do not propose a new DNS RR The problem with a new DNS RR (and one reason why we try to avoid it) is the resulting need to modify all kinds of DNS software. DNS servers, DNS resolvers and - probably the strongest argument against - ISP management software. Internet Service Providers do not edit zone files with an editor. They have a database and a GUI of some sort that is capable handling all kinds of "well known" RRs. We had quick, easy and cheap adoption in mind and if all ISP management software has to be changed to make use of the new RR, it will either take a long time or will never happen. TXT and RP records are well understood for years and our approach is even backed up by a RFC [18]. 5.2 Into the Future Should the future show that TXT RRs should be better substituted by a new DNS RR to carry the labels, we are all for it. But for now something has to happen, and it is better to happen quick. Stumpf & Hoehne Expires August 9, 2004 [Page 11] Internet-Draft Marking MTAs in reverse DNS February 2004 6. SECURITY CONSIDERATIONS The same security issues apply as to other DNS based services. Probably the worst case scenario is hijacking of a part of the in-addr.arpa zone and modification of the special TXT record defined in this document to "MTA=no" to block email sending capabilities for hosts with that IP addresses. Stumpf & Hoehne Expires August 9, 2004 [Page 12] Internet-Draft Marking MTAs in reverse DNS February 2004 References [1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [3] Mockapetris, P., "DNS encoding of network names and other types", RFC 1101, April 1989. [4] Everhart, C., Mamakos, L., Ullmann, R. and P. Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990. [5] Rosenbaum, R., "Using the Domain Name System To Store Arbitrary String Attributes", RFC 1464, May 1993. [6] Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web", RFC 1630, June 1994. [7] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. [8] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996. [9] Barr, D., "Common DNS Operational and Configuration Errors", RFC 1912, February 1996. [10] Daniel, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997. [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [12] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998. [13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [14] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999. [15] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June Stumpf & Hoehne Expires August 9, 2004 [Page 13] Internet-Draft Marking MTAs in reverse DNS February 2004 1999. [16] Gellens, R., "ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses", RFC 2645, August 1999. [17] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [18] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [19] Mealling, M. and R. Denenberg, "Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations", RFC 3305, August 2002. Authors' Addresses Markus Stumpf SpaceNet AG Joseph-Dollinger-Bogen 14 Muenchen, 80807 DE Phone: +49 89 32356-0 Fax: +49 89 32356-299 EMail: maex-rfc@space.net URI: http://www.space.net/ Steff Hoehne SpaceNet AG Joseph-Dollinger-Bogen 14 Muenchen, 80807 DE Phone: +49 89 32356-0 Fax: +49 89 32356-299 EMail: steff-rfc@space.net URI: http://www.space.net/ Stumpf & Hoehne Expires August 9, 2004 [Page 14] Internet-Draft Marking MTAs in reverse DNS February 2004 Appendix A. Acknowledgements The authors gratefully acknowledges the contributions of: Christian Brunner and Sebastian von Bomhard, Elmar Bartel for some good hints that should plate our English, Scott Nelson for directing us towards RFC1464 [5] and all the members of the RIPE Antispam list, the IRTF ASRG group and a lot of our net.friends for their comments and input. A big 'Thank You' goes also to Marshal T. Rose for the wonderful xml2rfc Stumpf & Hoehne Expires August 9, 2004 [Page 15] Internet-Draft Marking MTAs in reverse DNS February 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 Stumpf & Hoehne Expires August 9, 2004 [Page 16] Internet-Draft Marking MTAs in reverse DNS February 2004 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. Stumpf & Hoehne Expires August 9, 2004 [Page 17]