INTERNET-DRAFT Hadmut Danisch Category: Experimental Dec 2002 Expires: Jun 3, 2003 A DNS RR for simple SMTP sender authentication draft-danisch-dns-rr-smtp-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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This memo suggests a new DNS RR type to provide a very simple scheme of domain name authentication for SMTP mails based on sender IP address authorization. Danisch Experimental [Page 1] INTERNET-DRAFT DNS RMX RR Dec 2002 Table of Contents 1. Threat description . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Mail sender forgery . . . . . . . . . . . . . . . . . . . 3 1.2. SPAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem analysis . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Shortcomings of strong authentication mechanisms . . . . . . . . 3 4. DNS based sender address verification . . . . . . . . . . . . . 4 4.1. Suggested method . . . . . . . . . . . . . . . . . . . . . 4 4.2. Simple approach . . . . . . . . . . . . . . . . . . . . . 4 4.3. APL RR based approach . . . . . . . . . . . . . . . . . . 4 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Compatibility with old mail receivers . . . . . . . . . . 5 5.2. Compatibility with old mail senders . . . . . . . . . . . 5 5.3. Compatibility with old DNS clients . . . . . . . . . . . . 5 5.4. Compatibility with old DNS servers . . . . . . . . . . . . 5 6. Enforcement policy . . . . . . . . . . . . . . . . . . . . . . . 5 Security Considerations . . . . . . . . . . . . . . . . . . . . . . 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Danisch Experimental [Page 2] INTERNET-DRAFT DNS RMX RR Dec 2002 1. Threat description 1.1. Mail sender forgery Security surveillances found a significant increase in the number of e-mails with forged sender addresses. As a consequence, damage caused by such e-mails increased as well. In the majority of examined e-mails the domain name of the envelope sender address was forged, and the e-mail was sent from an IP address which does not belong to a network used by the actual owner of the domain. 1.2. SPAM A common and well known problem is the dramatic increase of unsolicited e-mail, commonly called "SPAM". Again, the majority of examined e-mails had forged sender addresses. The abused domains were mainly those of common webmailers as hotmail or yahoo, or well-known companies. 2. Problem analysis The real cause for forged e-mail is the lack of the Simple Mail Transfer Protocol SMTP[1] to provide any kind of sender authentication, authorisation, or verification. Efforts have been made to block such e-mails by requiring the sender address domain part to be resolvable (e.g. latest sendmail configurations). This method provides protection from e-mails with non-existing sender domains, and indeed, for some time it blocked most SPAM e-mails. However, since attackers and SPAM senders began to abuse existing domain names, this method was rendered ineffective. 3. Shortcomings of strong authentication mechanisms Without any doubt, SMTP needs to be improved and reengineered in the future in order to resist against these kinds of threat. Cryptographical or organisational security mechanisms have to be designed an implemented for some sort of SMTPng. Unfortunately, it is impossible to seamlessly switch to a new protocol, since most of the SMTP servers and client programs can't be replaced or updated easily and quickly. Any kind of security mechanism has to be simple and backward compatible in order to be accepted. That's why extensions like SMTP with TLS are not widely spread. Danisch Experimental [Page 3] INTERNET-DRAFT DNS RMX RR Dec 2002 4. DNS based sender address verification 4.1. Suggested method To gain at least some improvement in e-mail authenticity while keeping as much SMTP compatibility as possible, a method is suggested which doesn't change SMTP at all. When the sender has issued the "MAIL FROM:" SMTP command, the receiving mail transfer agent (MTA) can - and modern MTAs do - perform some authorization checks, e.g. run a local rule database or check whether the sender domain is resolvable. The suggested method is to let the DNS server for the sender domain provide informations about which IP addresses are authorized to use the domain within a sender's address. After receiving the "MAIL FROM:" SMTP command, the receiving MTA can verify, whether the IP address of the sending MTA is authorized to send mails with this domain name. Therefore, a list of authorized IP addresses is provided by the authoritative DNS server of that domain. This is some kind of "reverse MX record", therefore it is temporarily called "RMX", until a better name is found. 4.2. Simple approach The RMX records for a domain could simply contain a list of network addresses and masks to define IP address ranges, which are allowed to use that domain, e.g. @ IN RMX 213.133.101.23/32 @ IN RMX 1.2.3.0/24 4.3. APL RR based approach The simple approach described above explains the method, but ends up in reinventing what already has been invented. Keeping address lists in DNS records was already defined in RFC 3123 [2] Therefore, instead of reinventing address ranges, we should use APL records. Here, an RMX record would contain a list of DNS names, which finally resolve to APL records. Mail is accepted if the sender IP address belongs to one of the listed networks. A configuration could look like this: danisch.de. IN RMX ( relays.danisch.de ) relays.danisch.de. IN APL ( 1:213.133.101.23/32 1:1.2.3.0/24 ) where the machine with the example address 213.133.101.23 and the Danisch Experimental [Page 4] INTERNET-DRAFT DNS RMX RR Dec 2002 machines in the example subnet 1.2.3.0/24 are the only machines allowed to send e-mails with an envelope sender address of domain danisch.de. Since the APL records do not necessarily belong to the same domain or zone table as the RMX records, this easily allows to refer to APL records defined by someone else, e.g. the internet access or server hosting provider, thus reducing administrative overhead to a minimum. 5. Compatibility 5.1. Compatibility with old mail receivers Since the suggested extension doesn't change the SMTP protocol at all, it is fully compatible with old mail receivers. They simply don't ask for the RMX records and don't perform the check. 5.2. Compatibility with old mail senders Since the SMTP protocol is unchanged and the SMTP sender is not involved in the check, the method is fully compatible with old mail senders. 5.3. Compatibility with old DNS clients Since the RMX is a new RR, the existing DNS protocol and zone informations remain completely untouched. 5.4. Compatibility with old DNS servers If a server can't provide RMX records or a zone doesn't contain them, the check can't be performed, while compatibility is still guaranteed. 6. Enforcement policy Obviously, for reasons of backward compatibility and smooth introduction of this scheme, RMX records can't be required immediately. Domains without RMX records must temporarily be treated the same way as they are treated right now, i.e. e-mail must be accepted from anywhere. But once the scheme becomes sufficiently widespread, mail relays can start to refuse e-mails with sender addresses from domains without RMX records, thus forcing the owner of the domain to include a statement of authorization into the domain's zone table. Domain owners will still be free to have an RMX record with a network and mask 0.0.0.0/0, i.e. to allow e-mails with that domain from everywhere. On the other hand, mail receivers will be free to refuse mails from domains without RMX records or RMX records which are too loose. Danisch Experimental [Page 5] INTERNET-DRAFT DNS RMX RR Dec 2002 Advanced MTAs might have a configuration option to set the maximum number of IP addresses authorized to use a domain. E-mails from a domain, which's RMX records exceed this limit, would be rejected. For example, a relay could reject e-mails from domains which authorize more than 8 IP addresses. That allows to accept e-mails only from domains with a reasonable security policy. Security Considerations It is important to stress, that the suggested method does not provide high level security and does not completely block forged e- mails or SPAM. It is not a reliable and completely secure security mechanism. It is to be considered as a very cheap and simple lightweight mechanism, which can provide at least some improvement in mail security against a certain class of attacks, until a successor of SMTP has been defined and commonly accepted. References 1. J. Klensin, "Simple Mail Transfer Protocol," RFC 2821 (April 2001). 2. P. Koch, "A DNS RR Type for Lists of Address Prefixes (APL RR)," RFC 3123 (June 2001). Author's Address Hadmut Danisch Tennesseeallee 58 76149 Karlsruhe Germany Phone: ++49-721-843004 E-Mail: rfc@danisch.de Comments Please send comments to rfc@danisch.de. Expiry This drafts expires on Jun 3, 2003 Danisch Experimental [Page 6]