Network Working Group M. Stumpf Internet-Draft S. Hoehne Expires: April 20, 2005 SpaceNet AG October 20, 2004 Marking Mail Transfer Agents in Reverse DNS with TXT RRs draft-stumpf-dns-mtamark-03 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I 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 April 20, 2005. 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 and IP6.ARPA zones) 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/ Stumpf & Hoehne Expires April 20, 2005 [Page 1] Internet-Draft Marking MTAs in Reverse DNS October 2004 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. This document is part of the LMAP work of the Anti-Spam Research Group (ASRG) of the IRTF. Table of Contents 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. PROPOSAL . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Defining A Well Known Subdomain for the Reverse DNS Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Service Specific Resource Records . . . . . . . . . . . . 4 2.2.1 Terms and Definitions . . . . . . . . . . . . . . . . 4 2.2.2 Hints for Implementors . . . . . . . . . . . . . . . . 5 2.3 Contact Information . . . . . . . . . . . . . . . . . . . 5 2.3.1 Terms and Definitions . . . . . . . . . . . . . . . . 5 2.3.2 Hints for Implementors . . . . . . . . . . . . . . . . 6 2.4 Example Records . . . . . . . . . . . . . . . . . . . . . 7 3. EFFECTS ON EXISTING MAIL INFRASTRUCTURE . . . . . . . . . . . 7 3.1 Unmarked Addresses . . . . . . . . . . . . . . . . . . . . 7 3.2 Local Mail Clients . . . . . . . . . . . . . . . . . . . . 7 3.3 Roaming Users . . . . . . . . . . . . . . . . . . . . . . 8 3.4 IPv6 Compatibility . . . . . . . . . . . . . . . . . . . . 8 3.5 Deployment . . . . . . . . . . . . . . . . . . . . . . . . 8 4. EXPANDING THIS PROPOSAL . . . . . . . . . . . . . . . . . . . 8 4.1 Extensibility . . . . . . . . . . . . . . . . . . . . . . 8 4.2 Blacklists, Whitelists and Accreditation Systems . . . . . 8 5. WHY NOT A NEW DNS RR . . . . . . . . . . . . . . . . . . . . . 9 6. IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . 9 7. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 12 Stumpf & Hoehne Expires April 20, 2005 [Page 2] Internet-Draft Marking MTAs in Reverse DNS October 2004 1. INTRODUCTION 1.1 Motivation The problem with spam and viruses/worms has increased and changed a lot during the last years. In the beginning, distributing unsolicited email was accomplished by abusing relay open mail servers [RFC2505]. Spread of viruses needed humans passing on infected data. The situation today shows worms coming packed with their own SMTP modules, 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 the 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 - of the 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 [RFC1034], [RFC1035] 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, it is not recommended to accept unauthorized message transmission from that IP address." and therefore give receiving MTAs a hint as whether to accept messages from the sending MTA or not. Stumpf & Hoehne Expires April 20, 2005 [Page 3] Internet-Draft Marking MTAs in Reverse DNS October 2004 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 technique used in this proposal is not limited to SMTP, but can be adopted by any service and is easily extensible. 1.2 Terminology The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC2119 [RFC2119]. 2. PROPOSAL 2.1 Defining A Well Known Subdomain for the Reverse DNS Tree Storing arbitrary string attributes in the Domain Name System [RFC1464] is a technique described and used at least since 1993. One solution that we took into consideration has been to store string attributes like "MTA=1" or "MTA=0" at the same level as PTR records. However this method does not support specific queries and has a high overhead for 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 with a subdomain with the well known name _srv This subdomain MAY be inserted at any level in the DNS tree for IPv4 IN-ADDR.ARPA reverse zones. For IPv6, to limit the number of DNS queries, _srv is only queried at the /128 (host), /64 (subnet) and / 32 (site) level. That way it can either provide information for a specific IP address or for a whole network block. More specific information takes precedence over information found closer to the top of the tree. 2.2 Service Specific Resource Records 2.2.1 Terms and Definitions Stumpf & Hoehne Expires April 20, 2005 [Page 4] Internet-Draft Marking MTAs in Reverse DNS October 2004 Within the above "_srv" subdomain there will be another subdomain named after the service for which the specific records will be defined. For SMTP the name of the subdomain will be _smtp The symbolic name of the desired service is the same as defined in Assigned Numbers [RFC3232] or locally. An underscore (_) is prepended to the service identifier to avoid collisions with DNS labels that occur in nature. The service name is case insensitive. Readers familiar with RFC2782 [RFC2782] are already accustomed to that naming scheme. Whether SMTP message transmissions should be accepted from that host is specified by a TXT record within the service subdomain for the entry _send The name "_send" is case insensitive. 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 an accredited sending MTA and that messages SHOULD NOT be accepted from that connection, unless successful authentification via other methods (e.g. ODMR [RFC2645]) advise the contrary. 2.2.2 Hints for Implementors o The "_send" record for a given service MUST be unique for a given IP address within the "_smtp" subdomain. In the case of multiple (contradictory) records implementors are free which record to choose. However we recommend using the first record found. 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). 2.3 Contact Information 2.3.1 Terms and Definitions The contact information provides automatic notification of administrators, if hosts within their responsibility get abused or infected by viruses. Stumpf & Hoehne Expires April 20, 2005 [Page 5] Internet-Draft Marking MTAs in Reverse DNS October 2004 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, APNIC or LACNIC. 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 KRNIC, 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 [RFC1183]. Another use of an email address provided with the contact information is the possibility for a MTA to customize the error message [RFC2821], [RFC1893] like in 550-5.7.1 Message rejected. Sender is not labeled a sending 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 and IP6.ARPA zone at the same level as the "_srv" records. However, there MAY be more than one contact address for various services involved, so service specific contact information MAY also be provided at the service subdomain level. 2.3.2 Hints for Implementors o Programs utilizing these records should first query for RP records along with the service subdomain and if that fails try again and query for RP records at the "e;_srv" level. o 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 April 20, 2005 [Page 6] Internet-Draft Marking MTAs in Reverse DNS October 2004 2.4 Example Records Some examples, how records might look like in BIND syntax: $ORIGIN 0.0.10.IN-ADDR.ARPA. 1 IN PTR mail.example.com. _send._smtp._srv.1 IN TXT "1" _smtp._srv.1 IN RP abuse.example.com. . 2 IN PTR www.example.com. 2 IN RP abuse.example.com. . _send._smtp._srv.2 IN TXT "0" _smtp._srv.2 IN RP spam.example.com. . 3. 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 3.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. 3.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 them being marked as "MTA=no". Stumpf & Hoehne Expires April 20, 2005 [Page 7] Internet-Draft Marking MTAs in Reverse DNS October 2004 3.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 [RFC2645] extension to SMTP [RFC2821] specifies a way for roaming users to authenticate themselves to the receiving MTA and validate the connection. Connections MUST NOT be rejected solely based on a "MTA=no" label before the initiator of the connection had the chance to authenticate. 3.4 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 as well. 3.5 Deployment Deployment of this method is easy and cheap, even in costs of DNS records needed. Unlike other methods like SPF (Sender Policy Framework) or Caller-Id it does not require records to be added for each and every node in a domain, but only one record per mailserver. An analysis done by Peter Koch in June 2004 has shown that for the DE TLD all DNS MX records of the about 7.6 million second level domains pointed to about 140000 unique IP addresses. About 75% of those had a working reverse mapping. 4. EXPANDING THIS PROPOSAL 4.1 Extensibility This proposal concentrates on labeling SMTP servers. However the principle is generic and can be used for other services, too. Other entries in the service subdomain like e.g. "_key" can be used to store the public key the MTA at that IP address uses for authentication or signing of messages. 4.2 Blacklists, Whitelists and Accreditation Systems While this document specifies the mechanisms for the reverse DNS tree the same labeling scheme can also be used within other domains. Accreditation systems can use this technique to store multiple information for an IP address or a network block within one (sub-)domain. Stumpf & Hoehne Expires April 20, 2005 [Page 8] Internet-Draft Marking MTAs in Reverse DNS October 2004 5. WHY NOT 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. 6. IANA CONSIDERATIONS The IANA already maintains the registry for service names [RFC3232] that are used to name the service subdomain proposed. No other IANA services are required by this document. 7. SECURITY CONSIDERATIONS The authors believe that this specification does not cause any new security problems. The same security issues apply as to other DNS based services. Probably the worst case scenario is hijacking of a part of the reverse DNS 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. 8 References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1101] Mockapetris, P., "DNS encoding of network names and other types", RFC 1101, April 1989. [RFC1183] Everhart, C., Mamakos, L., Ullmann, R. and P. Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990. [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store Arbitrary String Attributes", RFC 1464, May 1993. Stumpf & Hoehne Expires April 20, 2005 [Page 9] Internet-Draft Marking MTAs in Reverse DNS October 2004 [RFC1893] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996. [RFC1912] Barr, D., "Common DNS Operational and Configuration Errors", RFC 1912, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC2645] Gellens, R., "ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses", RFC 2645, August 1999. [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 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/ Stumpf & Hoehne Expires April 20, 2005 [Page 10] Internet-Draft Marking MTAs in Reverse DNS October 2004 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/ Appendix A. Acknowledgements The authors gratefully acknowledge the contributions of: Christian Brunner, Gert Doering and Sebastian von Bomhard, Elmar Bartel also for some good hints that should plate our English, Arnt Gulbrandsen, Peter Koch, Scott Nelson, and all the members of the RIPE Antispam list, the IRTF ASRG and a lot of our net.friends for their comments and input. Our sincere thanks go to Yakov Shafranovich, one of the chairs of the IRTF ASRG, who always was willing to help. His dedication formed the IRTF ASRG into a productive group and set the stage for successfully addressing the spam problem. A big 'Thank You' goes also to Marshall T. Rose for the wonderful xml2rfc. Stumpf & Hoehne Expires April 20, 2005 [Page 11] Internet-Draft Marking MTAs in Reverse DNS October 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. Stumpf & Hoehne Expires April 20, 2005 [Page 12]