IETF-MARID A. Lorenzen Internet Draft Server Authority Inc Expires: October 2004 April 2004 DNS Naming Convention for Outbound Internet Email Servers draft-lorenzen-marid-mxout-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/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 October 20, 2004. Abstract This document offers a recommended standardized FQDN (Fully Qualified Domain Name) naming convention pattern for servers used to send outbound internet email. The purpose is to allow inbound internet email servers to recognize outbound email servers designated as authorized or unauthorized by those in control of DNS for the sending server IP addresses. Please address comments and discussion of this document to the ietf-mxcomp@imc.org mailing list. Conventions used in this document 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 RFC-2119 [ ]. Lorenzen, A. Expires October 20, 2004 [Page 1] Internet-Draft .mxout. Naming Convention April 2004 Table of Contents 1. Introduction ............................................ 2 2. Specification of the Naming Convention .................. 3 2.1 Specification of mxout DNS A record ................. 4 2.2 Shared Purpose Machines ............................. 5 3. Assumptions ............................................. 5 4. Anticipated Benefits .................................... 5 5. Security Considerations ................................. 5 6. Informative References .................................. 5 7. Acknowledgements ........................................ 6 8. Author's Addresses ...................................... 6 9. Full Copyright Statement ................................ 6 10. Appendix: Spam Control Proposal Evaluation Checklist ... 7 Introduction Many large ISPs have a PTR record for each IP address they control, including IP addresses assigned to home users such as cable modem, DSL, or dialup usres. Independent organizations have attempted to compile lists of such IP addresses for use by inbound email servers in rejecting mail from unauthorized sources. Some inbound email server administrators have written code to reject connections based on naming convention patterns of dynamic IP assignment such as "pool" or "dhcp" etc. These lists may be extremely time consuming to maintain and contain inaccuracies which lead to rejection of mail recipients wanted. Often, the ISP whose IP addresses are being used to send mail, has had no input into the formation or maintenance of the list of authorized and unauthorized patterns or IPs - and may make changes which dramatically affect accuracy, without notice to the list maintainer. ISPs with customers who are not authorized to operate an outbound email server have used port 25 blocking as a method to prevent unauthorized outbound mail server operation. A side effect of port 25 blocking is that customers cannot utilize the outbound server of their choice, such as a corporate email server while travelling or at home. An ISP with many home user customers may gain substantial advantages by conformance to a standard naming convention such Lorenzen, A. Expires October 20, 2004 [Page 2] Internet-Draft .mxout. Naming Convention April 2004 as .mxout. for authorized outbound servers, and a DNS A record announcing their .mxout. conformance. Inbound email servers may then reject all mail from one of that ISPs IP addresses if the verified DNS of the connecting IP does not conform to the .mxout. naming convention. Example of Foo ISP, Inc., an ISP with both home user and business access customers: 00-000-0-00.nyc-14.fooisp.net (home cable modem user) 00.cpe.0.hxz.adsl.fooisp.net (business DSL user) rwclmhc000.fooisp.net (Foo's outbound server) To conform to the .mxout. naming convention, Foo ISP, Inc. changes naming convention to: rwclmhc000.mxout.fooisp.net (Foo's outbound server) and, if Foo ISP, Inc. wants to to authorize a class of business DSL customer to operate an outbound email server: 00.cpe.0.hxz.adsl.mxout.fooisp.net (business DSL user) Inbound email servers can now reject viruses and zombie spam sources which connect directly from any IP with a PTR record ending in .fooisp.net, which does not end with mxout.fooisp.net. 1. Specification of the Naming Convention for Outbound Email Servers differentiator.standard-identifier.example.com No characters other than a dot (.) comes between the standard identifier and the base domain name. Correct: nyc09.mxout.example.com Incorrect: nyc.mxout09.example.com The differentiator portion of the FQDN used for location or other codifying, is placed to the LEFT of the standard identifier and is separated from the standard identifier by a dot. Correct: a09.mxout.example.com, toledo.mxout.example.com, nyc.mxout.example.com. Incorrect: mxouta09.example.com, mxout.toledo.example.com, mxoutnyc.example.com Lorenzen, A. Expires October 20, 2004 [Page 3] Internet-Draft .mxout. Naming Convention April 2004 At least one character and one dot shall appear immediately to the left of standard identifier, to prevent spoofing and simplify parser design by bounding the standard identifier with dots. Correct: nyc-44.mxout.example.com Incorrect: mxout.example.com, nyc-44-mxout.example.com 1.1 Specification of mxout DNS A record A DNS A record: mxout IN A 127.0.0.x shall be included in the zone file for each domain which uses the outbound server naming convention specified in 1.0 above. The purpose of the mxout A record is to verify that the domain owner is participating in the .mxout. naming convention, and for the domain owner to optionally convey instructions for rejecting connections from unauthorized outbound servers which utilize that domain name. The IP address returned by the mxout A record may optionally be interpreted by the querying inbound email server as an instruction from the outbound server domain administrator. Instructions inferred by responses 127.0.0.1 and 127.0.0.2 may optionally be followed by all inbound internet email servers. Instructions inferred by responses 127.0.0.3 through 127.0.0.7 must not be followed by any inbound internet email server with users who forward email accounts inbound to that server, and may optionally be followed by other inbound internet email servers. An inbound email server which does not meet the requirements for, or have the capacity for the lookups required by 127.0.0.3 through 127.0.0.7, may treat response 127.0.0.3 through 127.0.0.7 the same as response 127.0.0.2. The recommended meaning for 127.0.0.1 through 127.0.0.7 is as follows: 127.0.0.1 "Servers conforming to the .mxout. convention using this domain as a base, are authorized outbound email servers." (Only identifies authorized servers - does not specify anything about unauthorized servers.) 127.0.0.2 "Servers conforming to the .mxout. convention using this domain as a base, are authorized outbound email servers. Please reject connections from any server which uses this domain as a base, and does not conform to the .mxout. convention." (Also specifies a convention for recognizing unauthorized servers by exclusion.) 127.0.0.3 "Servers conforming to the .mxout. convention using this domain as a base, are authorized outbound email servers. Please reject connections from any server which uses this domain as a base, and does not conform to the .mxout. convention. In addition, please reject mail having an envelope-from of this base domain, if the connection is from a server using any base domain which does not conform to the .mxout. convention." (Additionally specifies a broad designated sender authorization for this domain, basically allowing all servers where the domain owner has reverse DNS delegation and the domain owner chooses to conform to the .mxout. convention. This broad designated sender specification would authorize sending servers who demonstrate this nominal level of server control, such as hotels which force travellers to use special SMTP setting or greeting cards sites and others who forge the supposed sender email domain in the envelope-from.) 127.0.0.4 "Servers conforming to the .mxout. convention using this domain as a base, are authorized outbound email servers. Please reject connections from any server which uses this domain as a base, and does not conform to the .mxout. convention. In addition, please reject mail from our authorized servers if the envelope-from domain does not share a name server host with this domain." (An example application for this "shared name server host" restriction: a measure of AUP policy enforcement for an ISP which hosts domains for a large number of customers. No list needs to be maintained as hosting customers are acquired or leave.) 127.0.0.5 "Servers conforming to the .mxout. convention using this domain as a base, are authorized outbound email servers. Please reject connections from any server which uses this domain as a base, and does not conform to the .mxout. convention. In addition, please reject mail claiming to be from this base domain, if the connection is from a server using any base domain which does not conform to the .mxout. convention. In addition, please reject mail from our authorized servers if the envelope-from domain does not share a name server with this domain." (Combines the 127.0.0.3 and 127.0.0.4 instruction. Designates all .mxout. conforming servers in the world as authorized to send for this domain. Additionally specifies to reject mail from this domain authorized servers, if the envelope-from domain cannot prove a relationship to this domain by way of shared name server hosts.) 127.0.0.6 "Servers conforming to the .mxout. convention using this domain as a base, are authorized outbound email servers. Please reject connections from any server which uses this domain as a base, and does not conform to the .mxout. convention. In addition, please reject mail with an envelope-from of this base domain, if the connection is from a server using any base domain other than this one." (Designates only its own servers as authorized senders for this domain, and specifies that all others are unauthorized. An example application for this strict designation might be a high security domain such as those which process financial transactions.) 127.0.0.7 "Servers conforming to the .mxout. convention using this domain as a base, are authorized outbound email servers. Please reject connections from any server which uses this domain as a base, and does not conform to the .mxout. convention. In addition, please reject mail with an envelope-from of this base domain, if the connection is from a server using any base domain other than this one. In addition, please reject mail from our authorized servers if the envelope-from domain does not share a name server with this Lorenzen, A. Expires October 20, 2004 [Page 4] Internet-Draft .mxout. Naming Convention April 2004 domain." (Combines the 127.0.0.4 and 127.0.0.6 instruction. Designates only its own servers as authorized senders for this domain, and specifies that all others are unauthorized. Further classifies all envelope-from domains that do not share a name server with this domain, as unauthorized.) 1.2 Shared Purpose Machines Small organizations may put www, inbound email, outbound email, dns, and other functions on one shared purpose machine. It is proposed that the PTR record be named with priority to the fact that one of the machine functions is outbound email, thus something.mxout.example.com, and a matching A record included in forward DNS. 2. Assumptions By conforming to this convention, outbound server operators prove reverse delegation or full knowledge and cooperation from the entity with reverse delegation. Reverse delegation is unlikely to be granted to short term customers or non-customers. Upstream vendors asked to set PTR records using this naming convention should be fully aware that the machine will be used for outbound internet email, and may thus be better prepared to enforce AUPs (Acceptable Use Policy.) 3. Anticipated Benefits Inbound email servers may optionally skip additional anti-spam processing for messages from outbound servers which conform to a standardized naming convention. A standardized naming convention may allow inbound email servers to identify connection attempts which are from machines not authorized by IP block administrators as outbound email servers. A standardized naming convention requires less programming logic to recognize authorized outbound email servers, than accommodating numerous non-standard naming conventions. The need for updates (as IP addresses of outbound servers change) is eliminated by a standardized FQDN naming convention. A standardized naming convention eliminates the need for a look up table of base domains and their non-standard FQDN naming convention for outbound email servers. 4. Security Considerations The proposed FQDN naming convention relies on queries of the domain name system and thus inherits security risks of the domain name system, including inaccuracy introduced by DNS poisoning, DDOS (Distributed Denial Of Service) attacks, and other exploits. The internet email system already relies on queries of the domain name system. Most inbound email servers will not accept mail if the envelope-from domain does not answer a DNS query. Similarly, an inbound server making use of .mxout. checking, may not accept mail if it has cached the presence of an mxout A record for example.com, but due to some transient failure of the DNS system, does not get an accurate PTR record response for the connecting server at the moment of attempted delivery. All losses associated with trusting messages which later are found to contain malicious code or unwanted content, or rejecting messages which are wanted by recipients - are possible, depending on policies adopted by individual inbound email servers regarding actions to take based on the interpretation of FQDNs encountered during message delivery connections. All adverse consequences from forwarding accounts that are shared by other designated sender schemes, are issues of concern for inbound email servers using .mxout. to reject mail based on the envelope-from. Inbound servers should not use .mxout. for rejecting based on the envelope-from domain, or should not allow their recipient users to forward accounts from other domains, unless the forwarder ISP is trusted and verified to be prepared to properly handle bounces back to forwarded accounts and any other pertinent issues. To guard against FQDN spoofing, the inbound server software must check for an exact match between forward and reverse DNS of the connecting IP, if the PTR record response would qualify the message for acceptance. If the PTR record response qualifies the message for rejection, it is not necessary to cross-check the DNS response. Informative References 1. Wong, M., "Sender Policy Framework", Internet Draft, February 2003, http://www.ietf.org/internet-drafts/draft-mengwong-spf- 00.txt 2. Nelson, R., "SMTP DNS authorization", May 2003, http://www.crynwr.com/spam/smtp-dns-authorization.html Lorenzen, A. Expires October 20, 2004 [Page 5] Internet-Draft .mxout. Naming Convention April 2004 3. Levine, J. et al, "Lightweight MTA Authentication Protocol (LMAP) Discussion and Comparison", February 2004, http://asrg.kavi.com/apps/group_public/download.php/31/draft-i rtf-asrg-lmap-discussion-00.txt 4. Crocker, D., "Spam Control Proposal Evaluation Checklist", June 2003, Appendix of http://asrg.kavi.com/apps/group_public/download.php/30/draft-c rocker-spam-techconsider-02.txt Acknowledgments The author gratefully acknowledges the contributions of the worldwide community of open source programmers and legislative advocates, Derek Balling, Brad Knowles, Petru Paler, Kristin Zhivago, Bruce Gingery, and Kenneth Beauregard. Author's Addresses April Lorenzen Server Authority Inc POB 293, Jamestown RI 02835 USA Phone: (810) 636-2514 Email: ietf@codelock.com Please address comments and discussion of this document to the ietf-mxcomp@imc.org mailing list. 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Lorenzen, A. Expires October 20, 2004 [Page 6] Internet-Draft .mxout. Naming Convention April 2004 10. APPENDIX Spam Control Proposal Evaluation Checklist 1) Adoption Effort Requires labor costs to alter forward DNS records and PTR records for outbound internet email servers, internal company resource tracking databases, possible reconfiguration of internal use scripts or software written to utilize old DNS names. Many inbound email servers are already capable of finding PTR record and checking for a forward DNS match, as well as doing a DNS A record lookup. However, writing or installation of some additional code is required to specifically parse for .mxout. in the connecting IP DNS, and to take a specific action based on the IP returned from an mxout A record query, such as reject before DATA, or continue. 2) Threshold to benefit One major USA based cable/dsl operator adoption on the sender end is likely to result in payback of labor costs for receiving end implementation in less than one month. http://www.senderbase.org/search Ironport Senderbase stats suggest that the volume of mail sent from non-authorized USA based cable/dsl ISP IP addresses represents a substantial percentage of worldwide spam and viruses. The author suggests that adoption by the top twelve USA based cable/dsl ISPs listed on Senderbase, would result in a substantial and immediate - within seconds - benefit to any individual ISP implementing the receiving end. Another benefit would be the reduction of duplication of implementation and maintenance efforts around the world by those investing energy into trying to keep track of all the non-standard "maybe-this-is-their-outbound" naming conventions and changes, and resulting false positives when guesses are inaccurate or outdated. 3) Impact on Participants Lowered operational costs for abuse desk, bandwidth, storage, reduced inbound server loading due to "before DATA" rejections and lightweight nature of requirements. Annoyances which arise from renaming machines. However, only the relatively small number of outbound email servers need to be renamed, while the vast millions of home cable/dsl user IP addresses can be left as is. 4) Impact on Others This is an ISP server level measure, having little impact on consumers other than incorrect implementation resulting in undelivered mail or undeliverable notices. 5) Ongoing Usage effort New IP addresses put into service as outbound servers must be named by the .mxout. convention and there is some effort involved in enforcing this policy within an ISP with multiple decision makers. So long as the inbound implementation specification does not change, no ongoing usage effort on the inbound side. ISPs, EDUs, etc - which allow certain customers to operate outbound email servers will need to give those customers reverse delegation or will need to set up PTR records as requested by those customers. This is an ongoing customer service cost, if reverse delegation is not already the common practice. 6) Balance of burdens The burden seems reasonably balanced between sender and receiver, with neither needing to make major implementation investments nor incurring major ongoing costs. 7) Use by Full Internet Since this is a DNS distributed solution, it does scale globally, yet is also useful when used by as few as one sender and one receiver. 8) Growth of Internet Remains useful and scaleable regardless of internet size. 9) Efficiency Believed to be lighterweight in terms of CPU cycles used in the inbound server, than many proposed solutions which do not have a substantially greater potential to reduce inbound unauthorized mail volume. Like all DNS based anti-spam solutions, takes advantage of caching through already existing software. 10)Cost Low cost - just the cost of labor to change DNS records for outbound server domains or domains which are not authorized to operate outbound servers - possibly under $150 per server for inhouse labor costs. Lorenzen, A. Expires October 20, 2004 [Page 6] Internet-Draft .mxout. Naming Convention April 2004 11)Reliability As reliable and secure as the DNS system itself :). Consequences of failure of lookup is that spam may be received during times of DNS errors or timeouts, which could be brought on intentionally by well-known methods of DNS DDOS or other DNS subversion. Risks of receiving spam are lower or not unlike present risks of receiving spam. In unlikely circumstances or poorly designed inbound systems, false positives could occur, not unlike the current risks of poor designed inbound systems. 12)Internet Impact Reduction of unauthorized email in proportion to adoption. 13)Spam Impact Reduction in proportion to adoption, lessened by spammer moves to other practices. 14)Circumvention Spammers may create their own .mxout. PTR records if they have reverse delegation or a willing accomplice ISP, and utilize a domain they control forward DNS for. However, there is no way that they can cause ten thousand cable modem IP addresses over which they have no reverse delegation or ability to alter forward DNS - to appear to have an .mxout. naming convention. In the case of adoption by major cable/dsl ISPs, spammer circumvention must take the form of finding a new delivery path, abandoning the present highly efficient zombie delivery system which has allowed them to dramatically increase spam volume in the past year. 15)Personal post/Reply None. 16)Mailing List Please address comments and discussion of this document to the ietf-mxcomp@imc.org mailing list. 17)Inter-Enterprise Mail between enterprise units benefits from additional protection from virus infected non-.mxout. labelled machines belonging to the enterprise.