idnits 2.17.1 draft-stumpf-dns-mtamark-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 13) being 72 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2004) is 7375 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1101' is defined on line 385, but no explicit reference was found in the text == Unused Reference: 'RFC1912' is defined on line 397, but no explicit reference was found in the text == Unused Reference: 'RFC2181' is defined on line 403, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 409, but no explicit reference was found in the text ** Downref: Normative reference to an Unknown state RFC: RFC 1101 ** Downref: Normative reference to an Experimental RFC: RFC 1183 ** Downref: Normative reference to an Experimental RFC: RFC 1464 ** Obsolete normative reference: RFC 1893 (Obsoleted by RFC 3463) ** Downref: Normative reference to an Informational RFC: RFC 1912 ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Downref: Normative reference to an Informational RFC: RFC 3232 Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Stumpf 2 Internet-Draft S. Hoehne 3 Expires: August 1, 2004 SpaceNet AG 4 February 2004 6 Marking Mail Transfer Agents in Reverse DNS with TXT RRs 7 draft-stumpf-dns-mtamark-02 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on August 1, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 In contrast to other more extensive approaches to deal with 38 unsolicited email, commonly called "spam", this memo discusses a very 39 simple authentication scheme. It uses marking of hosts in reverse DNS 40 (IN-ADDR.ARPA and IP6.ARPA zones) to allow the receiving mail 41 transfer agents to decide whether the connecting (sending) host is a 42 designated mail transfer agent (MTA) or not. 44 Despite being a weaker scheme than most of the other proposals 45 currently discussed, it can reduce the amount of spam and viruses/ 46 worms significantly and has the advantage that it can be implemented 47 based on existing and well-established Internet technology like DNS 48 without any changes to that technology. 50 This document is part of the LMAP work of the Anti-Spam Research 51 Group (ASRG) of the IRTF. 53 Table of Contents 55 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. PROPOSAL . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1 Defining A Well Known Subdomain for the Reverse DNS Tree . . 5 60 2.2 Service Specific Resource Records . . . . . . . . . . . . . 5 61 2.2.1 Terms and Definitions . . . . . . . . . . . . . . . . . . . 5 62 2.2.2 Hints for Implementors . . . . . . . . . . . . . . . . . . . 6 63 2.3 Contact Information . . . . . . . . . . . . . . . . . . . . 6 64 2.3.1 Terms and Definitions . . . . . . . . . . . . . . . . . . . 6 65 2.3.2 Hints for Implementors . . . . . . . . . . . . . . . . . . . 7 66 2.4 Example Records . . . . . . . . . . . . . . . . . . . . . . 7 67 3. EFFECTS ON EXISTING MAIL INFRASTRUCTURE . . . . . . . . . . 8 68 3.1 Unmarked Addresses . . . . . . . . . . . . . . . . . . . . . 8 69 3.2 Local Mail Clients . . . . . . . . . . . . . . . . . . . . . 8 70 3.3 Roaming Users . . . . . . . . . . . . . . . . . . . . . . . 8 71 3.4 IPv6 Compatibility . . . . . . . . . . . . . . . . . . . . . 8 72 4. EXPANDING THIS PROPOSAL . . . . . . . . . . . . . . . . . . 9 73 4.1 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.2 Blacklists, Whitelists and Accreditation Systems . . . . . . 9 75 5. WHY NOT A NEW DNS RR . . . . . . . . . . . . . . . . . . . . 10 76 6. IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . 11 77 7. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . 12 78 References . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 80 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 81 Intellectual Property and Copyright Statements . . . . . . . 16 83 1. INTRODUCTION 85 1.1 Motivation 87 The problem with spam and viruses/worms has increased and changed a 88 lot during the last years. In the beginning, distributing unsolicited 89 email was accomplished by abusing relay open mail servers [RFC2505]. 90 Spread of viruses needed humans passing on infected data. The 91 situation today shows worms coming packed with their own SMTP 92 modules, utilizing address books and scanning documents for new 93 addresses and therefore victims. A lot of worms install backdoors and 94 (enable) proxy servers. These infected hosts are afterwards abused by 95 spammers to send unsolicited email. 97 With the growing adoption of DSL techniques, a significant part of 98 the Internet hosts shifted to poorly maintained workstations in 99 homes. Permanently connected to the Internet, these hosts form an 100 easy and "paying" prey for worms and abusers. Not only in homes, also 101 in companies the number of poorly maintained hosts is growing. 103 History and viruses like VBS/LoveLet class or worms like CodeRed and 104 Nimda and the zillions of open proxy servers show, we cannot count on 105 users or administrators to get the problems fixed. 107 However, what the administrators can decide proactively is whether a 108 certain host, represented by its IP address, is meant to be a MTA 109 that should have the ability to talk to other MTAs across the 110 Internet. Most - if not all - of the proxy servers or workstations do 111 not need to have this ability. 113 We suggest a mechanism to enable the administrator to mark IP 114 addresses in the Domain Name System [RFC1034], [RFC1035] with labels 115 meaning 117 o "This IP address is assigned to a MTA that is intended to send 118 messages across the Internet" 120 o "This IP address does not host a MTA, it is not recommended to 121 accept unauthorized message transmission from that IP address." 123 and therefore give receiving MTAs a hint as whether to accept 124 messages from the sending MTA or not. 126 This document describes such a mechanism that 128 o is easy, fast and cheap to deploy and implement, 130 o uses existing Internet technology without modification and without 131 breaking it or the need for workarounds 133 While this document specializes on SMTP the technique used in this 134 proposal is not limited to SMTP, but can be adopted by any service 135 and is easily extensible. 137 1.2 Terminology 139 The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", 140 "RECOMMENDED", "NOT RECOMMENDED", and "MAY" in this document are to 141 be interpreted as described in RFC2119 [RFC2119]. 143 2. PROPOSAL 145 2.1 Defining A Well Known Subdomain for the Reverse DNS Tree 147 Storing arbitrary string attributes in the Domain Name System 148 [RFC1464] is a technique described and used at least since 1993. One 149 solution that we took into consideration has been to store string 150 attributes like "MTA=1" or "MTA=0" at the same level as PTR records. 152 However this method does not support specific queries and has a high 153 overhead for parsing the responses, is prone to naming collisions and 154 will trigger errors and problems in old implementations of DNS 155 servers with the 512 byte size limit. 157 Thus we propose expanding the reverse DNS tree with a subdomain with 158 the well known name 160 _srv 162 This subdomain MAY be inserted at any level in the DNS tree for IPv4 163 IN-ADDR.ARPA reverse zones. For IPv6, to limit the number of DNS 164 queries, _srv is only queried at the /128 (host), /64 (subnet) and / 165 32 (site) level. That way it can either provide information for a 166 specific IP address or for a whole network block. More specific 167 information takes precedence over information found closer to the top 168 of the tree. 170 2.2 Service Specific Resource Records 172 2.2.1 Terms and Definitions 174 Within the above "_srv" subdomain there will be another subdomain 175 named after the service for which the specific records will be 176 defined. For SMTP the name of the subdomain will be 178 _smtp 180 The symbolic name of the desired service is the same as defined in 181 Assigned Numbers [RFC3232] or locally. An underscore (_) is prepended 182 to the service identifier to avoid collisions with DNS labels that 183 occur in nature. The service name is case insensitive. Readers 184 familiar with RFC2782 [RFC2782] are already accustomed to that naming 185 scheme. 187 Whether SMTP message transmissions should be accepted from that host 188 is specified by a TXT record within the service subdomain for the 189 entry 190 _send 192 The name "_send" is case insensitive. 194 The value of the TXT record will be either "1" or "0": 196 1 - (MTA=yes) indicates that the connection is originating from an 197 IP address that is intended to be a MTA talking to other MTAs 198 across the public Internet and that the message SHOULD be 199 accepted. 201 0 - (MTA=no) indicates that the IP address of the sending 202 communication partner is NOT meant to be an accredited sending MTA 203 and that messages SHOULD NOT be accepted from that connection, 204 unless successful authentification via other methods (e.g. ODMR 205 [RFC2645]) advise the contrary. 207 2.2.2 Hints for Implementors 209 o The "_send" record for a given service MUST be unique for a given 210 IP address within the "_smtp" subdomain. In the case of multiple 211 (contradictory) records implementors are free which record to 212 choose. However we recommend using the first record found. 214 o If the value of the resource record is other than "1" (MTA=yes) or 215 "0" (MTA=no) the value MUST be treated as "0" (MTA=no). 217 2.3 Contact Information 219 2.3.1 Terms and Definitions 221 The contact information provides automatic notification of 222 administrators, if hosts within their responsibility get abused or 223 infected by viruses. 225 Currently there is no easy way to get information about contacts for 226 a given IP address. There are a lot of different sources, where the 227 best are probably the whois databases of the various (Regional 228 Internet Registries (RIR) like ARIN, RIPE, APNIC or LACNIC. However, 229 there is no common agreed upon format for abuse contacts, and for 230 some allocations, referrals have to be followed to other registries 231 like BRNIC or KRNIC, that again use different record formats. 233 An easy way to specify contact information for a given IP address is 234 to use the Responsible Person (RP) resource record as defined in RFC 235 1183 [RFC1183]. 237 Another use of an email address provided with the contact information 238 is the possibility for a MTA to customize the error message 239 [RFC2821], [RFC1893] like in 241 550-5.7.1 Message rejected. Sender is not labeled a sending MTA. 242 550 5.7.1 Please contact . 244 where "abuse@example.com" is derived from the information stored in 245 the RP records. 247 The RP resource records SHOULD be inserted into the IN-ADDR.ARPA and 248 IP6.ARPA zone at the same level as the "_srv" records. 250 However, there MAY be more than one contact address for various 251 services involved, so service specific contact information MAY also 252 be provided at the service subdomain level. 254 2.3.2 Hints for Implementors 256 o Programs utilizing these records should first query for RP records 257 along with the service subdomain and if that fails try again and 258 query for RP records at the "e;_srv" level. 260 o More than one RP resource record may be specified. It is up to the 261 reporting program or person to choose a random contact to notify 262 or send notification to all of them. 264 2.4 Example Records 266 Some examples, how records might look like in BIND syntax: 268 $ORIGIN 0.0.10.IN-ADDR.ARPA. 270 1 IN PTR mail.example.com. 271 _send._smtp._srv.1 IN TXT "1" 272 _smtp._srv.1 IN RP abuse.example.com. . 274 2 IN PTR www.example.com. 275 2 IN RP abuse.example.com. . 276 _send._smtp._srv.2 IN TXT "0" 277 _smtp._srv.2 IN RP spam.example.com. . 279 3. EFFECTS ON EXISTING MAIL INFRASTRUCTURE 281 One of the main goals of this proposal has been to limit the impact 282 on existing Internet infrastructure as much as possible. 284 Putting this proposal in effect will not break existing 285 infrastructure or widely used mechanisms like gatewaying, forwarding 286 and (authenticated) relaying of emails 288 3.1 Unmarked Addresses 290 Each receiving MTA is free to decide how to classify connections from 291 IP addresses without the marks as defined in this document. 293 However, as a general guideline, we propose a grace period of six 294 months after publication of this document, where missing marks are to 295 be treated with a default of "MTA=yes" and after the grace period 296 missing marks are to be treated as "MTA=no". 298 Implementors are asked to provide a mechanism for the administrator 299 to easily specify a default behavior for unmarked IP addresses. 301 3.2 Local Mail Clients 303 MTAs implementing the policy defined in this document should take 304 care to provide mechanisms for the administrators to easily specify a 305 list of "local addresses" which use the receiving MTA as an outgoing 306 relay. The MTA will accept messages from those IP addresses despite 307 them being marked as "MTA=no". 309 3.3 Roaming Users 311 Typically, roaming users or local users from dialin/dynamic IP 312 addresses have "MTA=no" set on the connection to the receiving MTA. 313 The ODMR [RFC2645] extension to SMTP [RFC2821] specifies a way for 314 roaming users to authenticate themselves to the receiving MTA and 315 validate the connection. 317 Connections MUST NOT be rejected solely based on a "MTA=no" label 318 before the initiator of the connection had the chance to 319 authenticate. 321 3.4 IPv6 Compatibility 323 This proposal is fully compatible with IPv6. The same TXT and RP RRs 324 and lookup mechanisms can be applied to the "IP6.ARPA" zone as well. 326 4. EXPANDING THIS PROPOSAL 328 4.1 Extensibility 330 This proposal concentrates on labeling SMTP servers. However the 331 principle is generic and can be used for other services, too. 333 Other entries in the service subdomain like e.g. "_key" can be used 334 to store the public key the MTA at that IP address uses for 335 authentication or signing of messages. 337 4.2 Blacklists, Whitelists and Accreditation Systems 339 While this document specifies the mechanisms for the reverse DNS tree 340 the same labeling scheme can also be used within other domains. 341 Accreditation systems can use this technique to store multiple 342 information for an IP address or a network block within one 343 (sub-)domain. 345 5. WHY NOT A NEW DNS RR 347 The problem with a new DNS RR (and one reason why we try to avoid it) 348 is the resulting need to modify all kinds of DNS software. DNS 349 servers, DNS resolvers and - probably the strongest argument against 350 - ISP management software. Internet Service Providers do not edit 351 zone files with an editor. They have a database and a GUI of some 352 sort that is capable handling all kinds of "well known" RRs. 354 We had quick, easy and cheap adoption in mind and if all ISP 355 management software has to be changed to make use of the new RR, it 356 will either take a long time or will never happen. TXT and RP records 357 are well understood for years. 359 6. IANA CONSIDERATIONS 361 The IANA already maintains the registry for service names [RFC3232] 362 that are used to name the service subdomain proposed. No other IANA 363 services are required by this document. 365 7. SECURITY CONSIDERATIONS 367 The authors believe that this specification does not cause any new 368 security problems. 370 The same security issues apply as to other DNS based services. 372 Probably the worst case scenario is hijacking of a part of the 373 reverse DNS zone and modification of the special TXT record defined 374 in this document to "MTA=no" to block email sending capabilities for 375 hosts with that IP addresses. 377 References 379 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 380 STD 13, RFC 1034, November 1987. 382 [RFC1035] Mockapetris, P., "Domain names - implementation and 383 specification", STD 13, RFC 1035, November 1987. 385 [RFC1101] Mockapetris, P., "DNS encoding of network names and other 386 types", RFC 1101, April 1989. 388 [RFC1183] Everhart, C., Mamakos, L., Ullmann, R. and P. Mockapetris, 389 "New DNS RR Definitions", RFC 1183, October 1990. 391 [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store 392 Arbitrary String Attributes", RFC 1464, May 1993. 394 [RFC1893] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 395 1893, January 1996. 397 [RFC1912] Barr, D., "Common DNS Operational and Configuration 398 Errors", RFC 1912, February 1996. 400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 401 Requirement Levels", BCP 14, RFC 2119, March 1997. 403 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 404 Specification", RFC 2181, July 1997. 406 [RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", 407 BCP 30, RFC 2505, February 1999. 409 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 410 June 1999. 412 [RFC2645] Gellens, R., "ON-DEMAND MAIL RELAY (ODMR) SMTP with 413 Dynamic IP Addresses", RFC 2645, August 1999. 415 [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 416 specifying the location of services (DNS SRV)", RFC 2782, 417 February 2000. 419 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 420 April 2001. 422 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 423 an On-line Database", RFC 3232, January 2002. 425 Authors' Addresses 427 Markus Stumpf 428 SpaceNet AG 429 Joseph-Dollinger-Bogen 14 430 Muenchen, 80807 431 DE 433 Phone: +49 89 32356-0 434 Fax: +49 89 32356-299 435 EMail: maex-rfc@space.net 436 URI: http://www.space.net/ 438 Steff Hoehne 439 SpaceNet AG 440 Joseph-Dollinger-Bogen 14 441 Muenchen, 80807 442 DE 444 Phone: +49 89 32356-0 445 Fax: +49 89 32356-299 446 EMail: steff-rfc@space.net 447 URI: http://www.space.net/ 449 Appendix A. Acknowledgements 451 The authors gratefully acknowledge the contributions of: Christian 452 Brunner, Gert Doering and Sebastian von Bomhard, Elmar Bartel also 453 for some good hints that should plate our English, Arnt Gulbrandsen, 454 Phillip Hallam-Baker, Scott Nelson and all the members of the RIPE 455 Antispam list, the IRTF ASRG, IETF MARID and a lot of our net.friends 456 for their comments and input. 458 Our sincere thanks go to Yakov Shafranovich, one of the chairs of the 459 IRTF ASRG, who always was willing to help. His dedication formed the 460 IRTF ASRG into a productive group and set the stage for successfully 461 addressing the spam problem. 463 A big 'Thank You' goes also to Marshall T. Rose for the wonderful 464 xml2rfc. 466 Intellectual Property Statement 468 The IETF takes no position regarding the validity or scope of any 469 intellectual property or other rights that might be claimed to 470 pertain to the implementation or use of the technology described in 471 this document or the extent to which any license under such rights 472 might or might not be available; neither does it represent that it 473 has made any effort to identify any such rights. Information on the 474 IETF's procedures with respect to rights in standards-track and 475 standards-related documentation can be found in BCP-11. Copies of 476 claims of rights made available for publication and any assurances of 477 licenses to be made available, or the result of an attempt made to 478 obtain a general license or permission for the use of such 479 proprietary rights by implementors or users of this specification can 480 be obtained from the IETF Secretariat. 482 The IETF invites any interested party to bring to its attention any 483 copyrights, patents or patent applications, or other proprietary 484 rights which may cover technology that may be required to practice 485 this standard. Please address the information to the IETF Executive 486 Director. 488 Full Copyright Statement 490 Copyright (C) The Internet Society (2004). All Rights Reserved. 492 This document and translations of it may be copied and furnished to 493 others, and derivative works that comment on or otherwise explain it 494 or assist in its implementation may be prepared, copied, published 495 and distributed, in whole or in part, without restriction of any 496 kind, provided that the above copyright notice and this paragraph are 497 included on all such copies and derivative works. However, this 498 document itself may not be modified in any way, such as by removing 499 the copyright notice or references to the Internet Society or other 500 Internet organizations, except as needed for the purpose of 501 developing Internet standards in which case the procedures for 502 copyrights defined in the Internet Standards process must be 503 followed, or as required to translate it into languages other than 504 English. 506 The limited permissions granted above are perpetual and will not be 507 revoked by the Internet Society or its successors or assignees. 509 This document and the information contained herein is provided on an 510 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 511 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 512 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 513 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 514 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 516 Acknowledgement 518 Funding for the RFC Editor function is currently provided by the 519 Internet Society.