Internet-Draft Christopher Laforet Expires: July 10, 2004 Geoffrey Deasey Netpath, Inc. January 2004 Enhancing SMTP Mail Services To Minimize SPAM draft-laforet-deasey-imxrecords-00.txt 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 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 obsolete by other documents at anytime. 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. Abstract Unwanted Email ("SPAM") is a constantly growing scourge of the Internet. SPAM takes full advantage of the open system that was created in the spirit of cooperation that represents the original underpinnings of the Internet. Understanding that making airtight mail systems without completely destroying old software, the authors of this proposal considered the continued operation of these legacy systems while tightening up the current standards. This new proposal calls for a new DNS resource record type and a new standard of operation for organization mail- exchangers. Using this new resource record along with other standard DNS resources provides system operators to minimize exploitable inbound SPAM pathways into their systems. 1. Introduction SPAM, the affectionate name for unwanted Email, causes headaches for many system operators worldwide. SPAM's ubiquitous nature consumes resources like bandwidth and mail-server disk space and CPU cycles for almost every system attached to the Internet. End users are completely tired of the useless waste of time that SPAM represents. System operators constantly battle problems that the constant additional Email burden places on their mail servers. Tremendous amounts of money is spent on solutions to stop or minimize SPAM. Much SPAM makes it into the system because mail exchangers (MX) scattered through the Internet are compromised into participating in the distribution of unwanted Email. This happens because network MX servers have to accept all mail bound for their Email clients regardless of the source client for such mail. In other words, any Internet client currently can connect to an MX computer and deliver Email destined for a user on that server. This proposal seeks to institute a change in the way MX servers accept mail. The underlying policy change proposed herein is for MX servers to only accept mail from its internal clients or other MX servers. This will minimize the potential of SPAM from passing freely through the network since most servers permit relaying. It would also permit cracking down on SPAM senders in a more timely manner if all systems would follow this proposal since any outbreaks would be limited to being within a system administrator's purvey. 2. New DNS Resource Record Type This proposal requires a new DNS record type to supplement MX records. We propose a new type that we call IMX (Internal Mail Exchanger). This new RR type can be used to flag IP addresses of MX servers sitting within the border of an organization that may not receive mail from the Internet but which may relay mail from the inside of the organization to other border MX servers located on the Internet. A good example of this may be a busy ISP that has servers that receive and relay mail from its customer base to the outside world. 3. MX Server Protocol MX servers scattered throughout the Internet should change their philosophy to not accept mail from any client unless the mail client resolves as a mail exchanger or as a client internal to its own system. This is the reason we proposed the IMX DNS RR type, to enhance the ability to resolve a server as being an MX yet not to identify it to the world as a legitimate outside mail exchanger. The MX should reverse the client connection and determine if it matches an MX or IMX for the client domain or is one of its internal clients. If it does not resolve to either of these, then the connection needs to be ended with a 421 error rather than a standard 220 acceptance greeting. If the sending client's system does not support IMX and the server cannot determine that it is a legitimate sender, the recipient will shut out its ability to send mail. The sending system's System Administrator can resolve this in one of three ways: A. Add the IMX records into the DNS and use a version of Bind that will support IMX tags; B. Make internal outbound Email migrate to a registered MX server from internal MX servers; or C. Add the server as MX records into the DNS. The recipient system mail servers would adamantly refuse to accept mail from any client that is not an MX. The worst consequence is that Email may be bounced by a non-compliant system. 4. References RFC 2821 "Simple Mail Transfer Protocol" RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" 5. Authors' Addresses Christopher Laforet Netpath, Inc. 2260 S. Church St, Suite 601 Burlington, NC 27215, USA Phone: 336/226-0425 Email: laforet@netpath.net Geoffrey Deasey Netpath, Inc. 2260 S. Church St, Suite 601 Burlington, NC 27215, USA Phone: 336/226-0425 Email: deasey@netpath.net