diff options
Diffstat (limited to 'contrib/bind9/doc/draft/draft-danisch-dns-rr-smtp-03.txt')
| -rw-r--r-- | contrib/bind9/doc/draft/draft-danisch-dns-rr-smtp-03.txt | 1960 |
1 files changed, 0 insertions, 1960 deletions
diff --git a/contrib/bind9/doc/draft/draft-danisch-dns-rr-smtp-03.txt b/contrib/bind9/doc/draft/draft-danisch-dns-rr-smtp-03.txt deleted file mode 100644 index 4a01d91b9a8be..0000000000000 --- a/contrib/bind9/doc/draft/draft-danisch-dns-rr-smtp-03.txt +++ /dev/null @@ -1,1960 +0,0 @@ - - - -INTERNET-DRAFT Hadmut Danisch -Category: Experimental Oct 2003 -Expires: Apr 1, 2004 - - The RMX DNS RR and method for lightweight SMTP sender authorization - draft-danisch-dns-rr-smtp-03.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 introduces a new authorization scheme for SMTP e-mail - transport. It is designed to be a simple and robust protection - against e-mail fraud, spam and worms. It is based solely on - organisational security mechanisms and does not require but still - allow use of cryptography. This memo also focuses on security and - privacy problems and requirements in context of spam defense. In - contrast to prior versions of the draft a new RR type is not - required anymore. - - - - - - - - - - - - -Hadmut Danisch Experimental [Page 1] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - Table of Contents - - -1. General Issues . . . . . . . . . . . . . . . . . . . . . . . . . 4 -2. Problem and threat description . . . . . . . . . . . . . . . . . 4 - 2.1. Mail sender forgery . . . . . . . . . . . . . . . . . . . 4 - 2.1.1 Definition of sender forgery . . . . . . . . . . . 4 - 2.1.2 Spam . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.1.3 E-Mail Worms . . . . . . . . . . . . . . . . . . . 5 - 2.1.4 E-Mail spoofing and fraud . . . . . . . . . . . . . 5 - 2.2. Indirect damage caused by forgery . . . . . . . . . . . . 6 - 2.3. Technical problem analysis . . . . . . . . . . . . . . . . 6 - 2.4. Shortcomings of cryptographical approaches . . . . . . . . 7 -3. A DNS based sender address verification . . . . . . . . . . . . 7 - 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.2. Envelope vs. header sender address . . . . . . . . . . . . 9 - 3.3. Domain part vs. full sender address . . . . . . . . . . . 9 -4. Mapping of E-Mail addresses to DNS names . . . . . . . . . . . . 10 - 4.1. Domain part only . . . . . . . . . . . . . . . . . . . . . 10 - 4.2. Full address . . . . . . . . . . . . . . . . . . . . . . . 11 - 4.3. Empty address . . . . . . . . . . . . . . . . . . . . . . 11 -5. Mandatory entry types and their syntax . . . . . . . . . . . . . 11 - 5.1. Overall structure . . . . . . . . . . . . . . . . . . . . 11 - 5.2. Unused . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 5.3. IPv4 and IPv6 address ranges . . . . . . . . . . . . . . . 12 - 5.4. DNS Hostname . . . . . . . . . . . . . . . . . . . . . . . 13 - 5.4.1 Road warriors and DynDNS entries . . . . . . . . . 13 - 5.5. APL Reference . . . . . . . . . . . . . . . . . . . . . . 14 - 5.6. Domain Member . . . . . . . . . . . . . . . . . . . . . . 14 - 5.7. Full Address Query . . . . . . . . . . . . . . . . . . . . 15 - 5.8. DNS mapped authorization . . . . . . . . . . . . . . . . . 15 - 5.9. RMX reference . . . . . . . . . . . . . . . . . . . . . . 16 -6. Optional and experimental entry types . . . . . . . . . . . . . 16 - 6.1. TLS fingerprint . . . . . . . . . . . . . . . . . . . . . 16 - 6.2. TLS and LDAP . . . . . . . . . . . . . . . . . . . . . . . 16 - 6.3. PGP or S/MIME signature . . . . . . . . . . . . . . . . . 16 - 6.4. Transparent Challenge/Response . . . . . . . . . . . . . . 17 - 6.5. SASL Challenge/Response . . . . . . . . . . . . . . . . . 17 -7. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 7.1. Alternative encoding as TXT records . . . . . . . . . . . 17 - 7.2. RMX Records . . . . . . . . . . . . . . . . . . . . . . . 17 - 7.2.1 Overall structure . . . . . . . . . . . . . . . . . 18 - 7.2.2 Record encoding . . . . . . . . . . . . . . . . . . 18 - 7.2.3 Encoding of IPv4 and IPv6 address ranges . . . . . 18 - 7.2.4 Encoding of DNS . . . . . . . . . . . . . . . . . . 18 - 7.2.5 Encoding of unused and full query . . . . . . . . . 19 - 7.2.6 Additional Records . . . . . . . . . . . . . . . . 19 -8. Message Headers . . . . . . . . . . . . . . . . . . . . . . . . 19 - - - -Hadmut Danisch Experimental [Page 2] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - -9. SMTP error messages . . . . . . . . . . . . . . . . . . . . . . 20 -10. Message relaying and forwarding . . . . . . . . . . . . . . . . 20 - 10.1. Problem description . . . . . . . . . . . . . . . . . . . 20 - 10.2. Trusted relaying/forwarding . . . . . . . . . . . . . . . 21 - 10.3. Untrusted relaying/forwarding . . . . . . . . . . . . . . 21 -11. Security Considerations . . . . . . . . . . . . . . . . . . . . 22 - 11.1. Draft specific considerations . . . . . . . . . . . . . . 22 - 11.1.1 Authentication strength . . . . . . . . . . . . . 22 - 11.1.2 Where Authentication and Authorization end . . . . 22 - 11.1.3 Vulnerability of DNS . . . . . . . . . . . . . . . 23 - 11.1.4 Sneaking RMX attack? . . . . . . . . . . . . . . 25 - 11.1.5 Open SMTP relays . . . . . . . . . . . . . . . . . 25 - 11.1.6 Unforged Spam . . . . . . . . . . . . . . . . . . 25 - 11.1.7 Reliability of Whois Entries . . . . . . . . . . . 26 - 11.1.8 Hazards for Freedom of Speech . . . . . . . . . . 26 - 11.2. General Considerations about spam defense . . . . . . . . 27 - 11.2.1 Action vs. reaction . . . . . . . . . . . . . . . 27 - 11.2.2 Content based Denial of Service attacks . . . . . 27 -12. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 28 - 12.1. Draft specific considerations . . . . . . . . . . . . . . 28 - 12.1.1 No content leaking . . . . . . . . . . . . . . . . 28 - 12.1.2 Message reception and sender domain . . . . . . . 28 - 12.1.3 Network structure . . . . . . . . . . . . . . . . 29 - 12.1.4 Owner information distribution . . . . . . . . . . 29 - 12.2. General Considerations about spam defense . . . . . . . . 29 - 12.2.1 Content leaking of content filters . . . . . . . . 29 - 12.2.2 Black- and Whitelists . . . . . . . . . . . . . . 30 -13. Deployment Considerations . . . . . . . . . . . . . . . . . . . 30 - 13.1. Compatibility . . . . . . . . . . . . . . . . . . . . . . 30 - 13.1.1 Compatibility with old mail receivers . . . . . . 30 - 13.1.2 Compatibility with old mail senders . . . . . . . 30 - 13.1.3 Compatibility with old DNS clients . . . . . . . . 30 - 13.1.4 Compatibility with old DNS servers . . . . . . . . 30 - 13.2. Enforcement policy . . . . . . . . . . . . . . . . . . . 31 -14. General considerations about fighting spam . . . . . . . . . . 31 - 14.1. The economical problem . . . . . . . . . . . . . . . . . 31 - 14.2. The POP problem . . . . . . . . . . . . . . . . . . . . . 32 - 14.3. The network structure problem . . . . . . . . . . . . . . 33 - 14.4. The mentality problem . . . . . . . . . . . . . . . . . . 33 - 14.5. The identity problem . . . . . . . . . . . . . . . . . . 33 - 14.6. The multi-legislation problem . . . . . . . . . . . . . . 34 -Implementation and further Information . . . . . . . . . . . . . . . 34 -References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 -Draft History . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 -Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 35 - - - - - - -Hadmut Danisch Experimental [Page 3] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - -1. General Issues - - 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 [1]. - -2. Problem and threat description - -2.1. Mail sender forgery - - The amount of e-mails with forged sender addresses has dramatically - increased. As a consequence, damages and annoyances 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. - -2.1.1. Definition of sender forgery - - As discussions, comments to prior versions of this draft, and - different approaches to stop forgery showed, different perceptions - of "mail forgery" exist. For example, there are mechanisms to - verify e-mail addresses for mailing lists, web servers, or to stop - spam, which do send a message with a random number to the given - address and expect the user to send a reply. Here, someone is - considered to be allowed to use a particular e-mail address, if and - only if he is able to receive informations sent to this address, - and is able to reply to such a message. While this definition - appears to be quite plausible and natural, it can't be used for a - simple technical solution. Sending back a challenge and expecting a - reply is simply too much overhead and time delay, and not every - authorized sender is able or willing to reply (e.g. because he went - offline or is not a human). - - Within the scope of this memo, sender forgery means that the - initiator of an e-mail transfer (which is the original sender in - contrast to relays) uses a sender address which he was not - authorized to use. Being authorized to use an address means that - the owner (administrator) of the internet domain has given - permission, i.e. agrees with the use of the address by that - particular sender. This memo will cover both the permission of the - full e-mail address and the domain part only for simplicity. - - Within context of Internet and SMTP, the sender address usually - occurs twice, once as the envelope sender address in SMTP, and once - as the address given in the RFC822 mail header. While the following - considerations apply to both addresses in principle, it is - important to stress that both addresses have distinct semantics and - - - -Hadmut Danisch Experimental [Page 4] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - are not neccessarily the same. The envelope address identifies the - initiator of the transport, while the header identifies the author - of the message content. Since this memo deals with the message - transport only and completely ignores the message content, the - method should naturally be applied to the envelope sender address. - -2.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. - - Unfortunately, there is no accurate definition of spam availabe - yet, and neither are the concise technical criterions to filter or - block spam with technical mechanisms. There are efforts to design - content based filters, but these filters are expensive in - calculation time (and sometimes money), and they do not reliably - provide predictable results. Usually they give false positives - and/or require user interaction. Content filters in general suffer - from a design problem described later in this memo. Therefore, - this proposal does not use the content based approach to block - spam. - - As analysis of spam messages showed, most of spam messages were - sent with forged envelope sender addresses. This has mainly three - reasons. The first reason is, that spam senders usually do not - want to be contacted by e-mail. The second reason is, that they do - not want to be blacklisted easily. The third reason is, that spam - is or is going to be unlawful in many countries, and the sender - does not want to reveal his identity. Therefore, spam is considered - to be a special case of sender forgery. - -2.1.3. E-Mail Worms - - Another example of sender forgery is the reproduction of e-mail - worms. Most worms do choose random sender addresses, e.g. using - the addresses found in mailboxes on the infected system. In most - cases analyzed by the author, the e-mails sent by the reproduction - process can also be categorized as forged, since the infected - system would under normal circumstances not be authorized to send - e-mails with such e-mail addresses. So forgery does not require a - malicious human to be directly involved. This memo covers any kind - of e-mail sender address forgery, included those generated by - malicious software. - -2.1.4. E-Mail spoofing and fraud - - - -Hadmut Danisch Experimental [Page 5] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - Forging e-mail sender addresses for fraud or other kinds of - deception ("human engineering") has also dramatically increased. - There are many known cases where single or mass e-mails were sent - with wrong sender addresses, pretending to come from service - provider, software manufacturers etc., and asking the receiver to - install any software or patches, or to reply with any confidential - information. The Internet is becoming more and more a scene of - crime, and so are it's services, including e-mail. It is obvious - that crime based on e-mail is eased by the fact that SMTP allows - arbitrary sender address spoofing. - -2.2. Indirect damage caused by forgery - - As observed by the author, mass mails and worms with forged sender - addresses can cause a severe damage for the real owner of the - abused sender addresses. If a sender A is sending an e-mail to the - receiver B, pretending to be C by using a sender address of C's - domain, then C has currently no chance to prevent this, since C's - machines and software are not involved in any way in the delivery - process between A and B. B will nevertheless send any error - messages (virus/spam alert, "no such user", etc.) to C, erroneously - assuming that the message was sent by C. The author found several - cases where this flood of error messages caused a severe denial of - service or a dramatic increase of costs, e.g. when C was - downloading the e-mail through expensive or low bandwidth - connections (e.g. modem or mobile phones), or where disk space was - limited. The author examined mass mailings, where several tens or - hundreds of thousands of messages were sent to several addresses - around the world, where these messages caused only annoyance. But - since several thousands of these addresses were invalid or didn't - accept the message, the owner of the DNS domain which was abused by - the spammer to forge sender addresses was flooded for several - months with thousands of error messages, jamming the e-mail system - and causing severe costs and damages. - - As a consequence, when A sends a message to B, pretending to be C, - there must be any mechanism to allow C to inform B about the fact, - that A is not authorized to use C as a sender address. This is what - this memo is about. - -2.3. Technical problem analysis - - Why does e-mail forgery actually exist? Because of the lack of the - Simple Mail Transfer Protocol SMTP[2] to provide any kind of sender - authentication, authorisation, or verification. This protocol was - designed at a time where security was not an issue. Efforts have - been made to block forged e-mails by requiring the sender address - domain part to be resolvable. This method provides protection from - - - -Hadmut Danisch Experimental [Page 6] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - 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. - -2.4. Shortcomings of cryptographical approaches - - At a first glance, the problem of sender address forgery might - appear to be solvable with cryptographic methods such as challenge - response authentications or digital signatures. A deeper analysis - shows that only a small, closed user group could be covered with - cryptographical methods. Any method used to stop spam forgery must - be suitable to detect forgery not only for a small number of - particular addresses, but for all addresses on the world. An - attacker does not need to know the secrets belonging to a - particular address. It is sufficient to be able to forge any - address and thus to know any secret key. Since there are several - hundreds of millions of users, there will always be a large amount - of compromised keys, thus spoiling any common cryptographic method. - Furthermore, cryptography has proven to be far too complicated and - error prone to be commonly administered and reliably implemented. - Many e-mail and DNS administrators do not have the knowledge - required to deal with cryptographic mechanisms. Many legislations - do not allow the general deployment of cryptography and a directory - service with public keys. For these reasons, cryptography is - applicable only to a small and closed group of users, but not to - all participants of the e-mail service. - -3. A DNS based sender address verification - -3.1. Overview - - To gain improvement in e-mail authenticity while keeping as much - SMTP compatibility as possible, a method is suggested which doesn't - change SMTP at all. - - The idea is to store informations about how to verify who is - authorized to transmit e-mails through SMTP with a particular - sender address (either full address or - for simplicity - only the - domain part of the address) in a directory service, which is - currently the DNS. To be precise, the verification consists of two - steps, the classical pair of authentication and authorization: - - The first step is the authentication. While several methods are - possible to perform authentication (see below), the most important - and robust method is the verification of the sender's IP address. - This is done implicitely by TCP/IP and the TCP sequence number. The - authenticated identity is the IP address. It has to be stressed - - - -Hadmut Danisch Experimental [Page 7] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - that this TCP/IP "authentication" is a weak authentication and - vulnerable to several attacks. It is nevertheless sufficient for - this purpose, especially for blocking spam. It doesn't take any - implementation and it doesn't cost: It is already there, it is a - functionality of TCP/IP. An incoming SMTP connection based on - TCP/IP already carries the sender's IP address without any - modification of SMTP. See below (section Entry types) for more - details about authentication methods. - - The second step is the authorization. It is based on the identity - given by the previous authentication step, e.g. the IP address of - the originator of the incoming SMTP connection, and on the - envelope sender address. The mechanism proposed in this memo - answers the question "Is that particular sender (IP address,...) - allowed to send with that sender address" by querying and - processing informations stored in a directory service, which is - DNS. - - 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 who - this means for example which IP - address - is authorized to use an address or a domain as a part of - it. After receiving the "MAIL FROM:" SMTP command, the receiving - MTA can verify, whether e. g. the IP address of the sending MTA is - authorized to send mails with this domain name. Therefore, a list - of entries with authorized IP addresses or other informations is - provided by the authoritative DNS server of that domain. The entry - types are described in the subsequent chapters. Some of these - methods are - - - An IPv4 or IPv6 network address and mask - - A fully qualified domain name referring to an A record - - A fully qualified domain name referring to an APL record - - RMX records of these types would look like this: - - somedomain.de. IN RMX ipv4:10.0.0.0/8 - rmxtest.de. IN RMX host:relay.provider.com - danisch.de. IN RMX apl:relays.rackland.de - relays.rackland.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 - 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 - - - -Hadmut Danisch Experimental [Page 8] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - 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. In the example given above, the domain - danisch.de and several other domains are hosted by the service - provider Rackland. So if the relay structure of Rackland is - modified, only the zone of rackland.de needs to be modified. The - domain owners don't need to care about such details. - -3.2. Envelope vs. header sender address - - Questions were raised why the proposed mechanism is based on the - envelope sender address, and not on the sender address given in the - message header. Technically, both can be used. Actually, it makes - sense to use the envelope address. - - In common, the header sender address identifies the author of the - content, while the envelope sender tells who caused the - transmission. The approach proposed in this memo is transmission - based, not content based. We can not authorize the author of a - message if we don't have contact with him, if the message does not - already contain a signature. In contrast, the sending MTA is linked - to an IP address which can be used for authentication. This - mechanism might not be very strong, but it is available and - sufficient to solve today's e-mail security problems. - - Some people argued that it is the header address and not the sender - address, which is displayed in common mail readers (MUAs), and - where the receiver believes the mail comes from. That's true, but - it doesn't help. There are many cases where the header sender - differs from the envelope sender for good reasons (see below in the - consequences chapter for the discussion about relaying). Relaying, - mailing lists etc. require to replace the sender address used for - RMX. If this were the header address, the message header would have - to be modified. This is undesirable. - -3.3. Domain part vs. full sender address - - Former versions of this draft were limited to the domain part of - the sender address. The first reason is that it is common and MX- - like, to lookup only the domain part of an e-mail address in DNS. - The second reason is, that it was left to the private business of - the domain administration to handle details of user verification. - The idea was that the domain administration takes care to verify - the left part of an e-mail address with an arbitrary method of - their individual taste. RMX was originally designed to ignore the - left part of the address and to expect the domain administration to - - - -Hadmut Danisch Experimental [Page 9] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - take over responsibility for enforcing their policy. If, e.g., a - spam message arrived and passed the RMX mechanism, it is known to - be authorized by the domain administration and they can be blamed, - no matter what is on the left side of the sender address - it's - their private problem what happens on the left side of the @. By - far the most of the comments to prior versions of this draft agreed - with that. A few comments asked for a finer granularity. - - And indeed, there is no technical reason against a finer - granularity. All it takes is a mapping from a given envelope - sender address to a DNS name, and the RMX lookup for that - particular e-mail address could be done instead of a lookup for the - domain part only. However, to my knowledge, most domain - administrators would not like to provide an RMX entry for every - single e-mail address. In many cases, this would also overload DNS - servers. - - It is to be discussed how to cover both views. One method could be - to query the full address, and if no RMX records were found to - query the domain part only. A different approach would be to query - the domain part only, and if it's RMX record contain a special - entry, then a new query for the full address is triggered. A third - way would be to always query the full address and to leave the - problem to the wildcard mechanism of DNS. This still has to be - discussed and will be described in future versions of this draft. - - - - - - - - - - - -4. Mapping of E-Mail addresses to DNS names - - To perform the RMX query, a mapping is needed from E-Mail addresses - to DNS fully qualified domain names. - - This chapter is under development and just a first approach. - -4.1. Domain part only - - Mapping of the domain part is trivial, since the domain part of an - e-mail address itself is a valid DNS name and does not need - translation. It might be nevertheless desirable to distinguish the - - - -Hadmut Danisch Experimental [Page 10] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - RMX entries from other entries, depending of the encoding of the - records. If the RMX entries are encoded in TXT record types, they - might collide with other uses of TXT records. It might be - necessary to prepend the domain part with a special prefix, e.g. - _rmx. So the e-mail address some.user@example.com could be mapped - to example.com or _rmx.example.com. - -4.2. Full address - - Mapping a full address is slightly more difficult. The @ sign must - be unambiguously translated, and therefore can not be simply - translated into a dot. The e-mail addresses some.user@example.com - and some@user.example.com must have different mappings. Therefore, - the @ sign could be translated into _rmx, implicitely assuming that - this is not an allowed domain name component of normal domain - names. Then the rightmost _rmx in the mapped DNS name always - corresponds to the @ sign. some.user@example.com would e translated - into some.user._rmx.example.com and can be covered by a wildcard - entry like *._rmx.example.com. - - Character encoding and character sets are still to be discussed. - -4.3. Empty address - - Unfortunately, SMTP allows empty envelope sender addresses to be - used for error messages. Empty sender addresses can therefore not - be prohibited. As observed, a significant amount of spam was sent - with such an empty sender address. To solve this problem, the host - name given in the HELO or EHLO command is taken to lookup the RMX - records instead. This makes sense, since such messages were - generated by the machine, not a human. - - - - -5. Mandatory entry types and their syntax - - The entry types described in this section MUST be supported by any - implementation of this draft. - -5.1. Overall structure - - Similar to APL, an RMX record is just a concatenation of zero or - more RMX entries. The entries within one record form an ordered - rule base as commonly usual in packet filtes and firewall rulesets, - i. e. they are processed one ofter another until the first entry - matches. This entry determines the result of the query. Once a - matching entry is found, the RMX processing is finished. - - - -Hadmut Danisch Experimental [Page 11] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - For any domain name there should not exist more than a single RMX - record. Due to the structure of DNS, it is nevertheless possible to - have more than a single RMX record. Multiple RMX records are - treated as a single record consisting of the concatenation of all - records. While the entries in a record are ordered, the records are - not ordered and may be processed in arbitrary order. If the order - of the entries matters, it is the zone maintainer's responsibility - to keep those entries in a single record. For example, there are - negative entries, which exclude IP addresses from authorization. - It is important that these entries are processed before positive - entries giving permission to a wider address range. Since order is - guaranteed only within a record, corresponding negative and - positive entries must be put in the same record. - - An RMX record may consist of one or more entries, where the entries - are separated by whitespace. An entry must not contain white space. - Each entry consists of an optional exclamation sign, a tag, a - colon, and the entry data: - - [!] TAG : ENTRY-SPECIFIC-DATA - - If the entry starts with an exclamation sign, the entry is negated. - See the entry type description below for details. - - The TAG is the mnemonic type identifier or the decimal number of - the entry. The TAG is case-insensitive. It is immediately followed - by a colon. - - The syntax and semantics of ENTRY-SPECIFIC-DATA depends of the the - entry type. See description below. - - Example: - - danisch.de. IN RMX apl:relays.rackland.de !ipv4:1.2.3.5 - ipv4:1.2.3.0/24 - -5.2. Unused - - This is a primitive entry which just says that this sender address - will never be used as a sender address under any circumstances. - Example: - - testdomain.danisch.de IN RMX unused: - -5.3. IPv4 and IPv6 address ranges - - These entry types contain a bit sequence representing a CIDR - address part. If that bit sequence matches the given IP address, - - - -Hadmut Danisch Experimental [Page 12] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - authorization is granted or denied, depending on the negation flag. - - The entry is prepended with the tag "IPv4" or "IPv6". The colon is - followed with an IPv4 or IPv6 address in standard notation, - optionally followed by a slash and a mask length. If the negation - flag is set, then the given address range is excluded. Examples: - - danisch.de IN RMX ipv4:213.133.101.23 ipv6:fe00::0 - IN RMX ipv4:10.0.0.0/8 ipv6:fec0::0/16 - IN RMX !ipv4:1.2.3.4 - - (Please note that it does not make much sense to use - RFC1918-Addresses in RMX records, this is just to give a syntax - example.) - - -5.4. DNS Hostname - - This entry type simply contains a regular DNS name, which is to be - resolved as a host name (fetch the A record or IPv6 equivalent). If - the given IP address matches the result, authorization is granted - or denied, depending on the negation flag. It is still to be - defined how to treat unresolvable entries. - - The entry is prepended with the tag "host", followed by a colon and - the hostname. Examples: - - danisch.de IN RMX host:relay.provider.de - IN RMX !host:badmachine.domain.de apl:relays.domain.de - -5.4.1. Road warriors and DynDNS entries - - Several people argued against RMX that it would break their - existing installation which delivers e-mail from dynamically - assigned IP addresses, because their IP providers didn't assign a - static address, or because they are a road warrior, plugging their - notebook in any hotel room on the world. - - RMX provides a simple solution. If such a machine has a dynamically - updated DNS entry (e.g. DynDNS), all it takes is an RMX entry of - the hostname type pointing to this dynamic DNS entry. - - The cleaner solution would be to deliver mail the same way as it is - received: If downloaded by POP from a central relay with a static - address, where the MX points to, then it would be a good idea to - deliver e-mail the same way in reverse direction. Unfortunately, - plain POP does not support uploading yet. - - - - -Hadmut Danisch Experimental [Page 13] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - -5.5. APL Reference - - This entry type simply contains a regular DNS name, which is to be - resolved as an APL record index (fetch the APL record). If the - given IP address positively matches the APL, authorization is - granted. Details of the semantic (espially when the negation bit is - set) are still to be defined. It is still to be defined how to - treat unresolvable entries. - - The entry is prepended with the tag "host", followed by a colon and - the hostname. Example: - - danisch.de IN RMX apl:relays.rackland.de - -5.6. Domain Member - - In many cases it is desirable to cover all hosts of a given domain - with an RMX record without the need to duplicate the list of these - hosts. This entry type does it (thanks to Eric A. Hall for pointing - out this entry type). It contains a regular DNS name. - - If this entry type is given, a reverse DNS query for the IP address - of the sending MTA is performed to find its official fully - qualified domain name. To prevent spoofing, this domain name is - accepted only if a subsequent address query to the given domain - name points to exactly the IP address of the sending MTA (the usual - procedure to verify PTR records). - - The entry matches if the fully qualified domain name of the sending - MTA ends in the given domain. The negation flag works as usual. - - The tag for this entry type is "domain". After the colon the domain - name is given, but might be empty, thus pointing to itself. - Example: - - somedomain.org IN RMX domain:somedomain.org domain:provider.com - - would authorize all machines which's hostname can be verified - through an PTR and A query, and which ends in "somedomain.org" or - "provider.com". - - With such an entry, large companies with different networks can - easily be covered with just a single and simple RMX entry. - Obviously, it requires proper PTR records. - - As a special shortcut, the DNS name may be empty. In this case the - domain name of the zone itself is taken. Thus, with a very simple - entry of the type - - - -Hadmut Danisch Experimental [Page 14] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - somecompany.com IN RMX domain: - - a company could authorize all machines which's IP addresses map to - DNS names end in somecompany.com, which applies in the majority of - companies. - - - - -5.7. Full Address Query - - As described above, RMX records will in most cases apply to the - domain part of the sender address. In special cases it might be - desirable to query the RMX record for a particular address. An RMX - entry of the Full Address Query type may occur in a domain RMX - record only. It signals that the RMX record for the full address is - to be fetched and processed. - - This entry type does not take arguments. The negation flag is not - supported. The tag is "full". - - If such a full address query is to be performed, the mail address - must be mapped to a valid and non-ambiguos DNS name. This mapping - is still to be defined. It is not sufficient to simply replace the - @ with a dot, because of case sensitivity, character sets, etc. The - e-mail addresses - - john.doe@example.org - John.Doe@example.org - john@doe.example.org - - must all be mapped to different DNS entries. This entry type might - vanish in future versions of the draft, depending on the discussion - about whether to query the domain name part only or the full - address. - -5.8. DNS mapped authorization - - As I learned from comments to prior versions of the draft and from - alternative proposals, many users wish to have a DNS mapped - authorization table, i. e. the client queries a DNS entry of the - form a.b.c.d.domain, where a.b.c.d is the sender's IP address. - Since people wish to have this, RMX will now include such a mapping - entry. The entry has a parameter giving the DNS domain name where - to look at. If the parameter is empty, then the same domain is - taken as for the RMX lookup. - - As this is currently under construction and discussion in an IETF - - - -Hadmut Danisch Experimental [Page 15] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - group, details will be published in future versions of this draft. - -5.9. RMX reference - - This entry type has no parameters. It means that all those machines - are authorized, which are pointed to by an MX record. - -6. Optional and experimental entry types - - The following subsections roughly describe further entry types - which might not be supported by all implementations and might not - be allowed in all legislations. These methods might vanish in - future versions of the draft and are just considerations about what - to include in RMX and what to not include. The main purpose of this - section is to start discussion about such entry types. - - The disadvantage of the following methods is that they violate the - basic idea of RMX, i. e. to be simple, robust, easy to implement - and easy to administer. I personally do not believe that it is a - good idea or even feasible to implement cryptography for a world - wide e-mail transfer network. Keep in mind that cryptographic keys - can be copied. If only <0.1% of cryptographic keys were revealed, - this completely compromises and spoils RMX. Cryptography is simply - the wrong tool for the problem RMX is intended to solve. I - nevertheless like to discuss these methods. - -6.1. TLS fingerprint - - The sender is considered to be authorized if the message was - transmitted through SMTP and TLS, and the sender used a certificate - matching the fingerprint given in the RMX record. - -6.2. TLS and LDAP - - This means that the receiver should perform an LDAP query for the - sender address (through the LDAP SRV record or given in the RMX - record), fetch the X.509 certificate for the sender. The sender is - considered to be authorized when the message was transmitted - through SMTP and TLS using this certificate. - -6.3. PGP or S/MIME signature - - It would be possible to accept a message only if it was signed with - PGP or S/MIME with a key which's fingerprint is given in the RMX - record or to be fetched from LDAP or any PGP database. This is - just for discussion, since it violates the idea of RMX to focus on - the transport, not on the content. It would also allow replay - attacks and not cover the envelope sender address or message - - - -Hadmut Danisch Experimental [Page 16] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - header. - -6.4. Transparent Challenge/Response - - It would also be possible to implement a challenge-response - mechanism without modifying the syntax of SMTP. For example, the - receiving MTA could issue a challenge with it's very first greeting - message, the sending MTA could hide the response in the HELO - parameter and when the receiving MTA later learns the sender - envelope address, it could verify the response based on - informations in the RMX record. - -6.5. SASL Challenge/Response - - Modern SMTP implementations already include a SASL mechanisms, - which easily allows to plugin new authentication mechanisms. While - common SASL mechanisms require to use a previously shared password, - a new mechanism could perform a challenge response authentication - as a SASL method. - - - - - - -7. Encoding - -7.1. Alternative encoding as TXT records - - The main objection against the prior versions of this draft was - that it requires a new RR entry type and upgrading all DNS servers. - - Therefore and alternative encoding is proposed. Instead of using a - new RR type, the TXT record type is used to contain the RMX record. - The records would simply look as described in the entry type - chapters above, e.g. - - _rmx.danisch.de. IN TXT "apl:relays.rackland.de" - - To allow smooth introduction of RMX without the need to immediately - upgrade all DNS servers, all clients (which have to be newly - installed anyway) MUST support both the TXT and the RMX records. A - client has to perform an ANY or a TXT and a RMX query. Servers/zone - tables may currently use TXT entries but SHOULD use RMX entries in - future. - -7.2. RMX Records - - - - -Hadmut Danisch Experimental [Page 17] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - -7.2.1. Overall structure - - Each entry starts with an octet containting the entry type and the - negation flag: - - +---+---+---+---+---+---+---+---+------ - | N | Entry Type Code | Parameters... - +---+---+---+---+---+---+---+---+------ - - N If this bit (MSB) is set, an IP address - matching this entry is not authorized, - but explicitely rejected. See entry - type descriptions for details. - - Entry Type A 7bit number simply determining the entry - type. - - - Currently, entries do not have an explicit length field, the entry - length is determined implicitely by the entry type. Applications - are required to abort if an unknown entry type is found, instead of - skipping unknown entries. - -7.2.2. Record encoding - - A RMX record is simply a concatenation of RMX entries. - -7.2.3. Encoding of IPv4 and IPv6 address ranges - - After the entry type tag as described above, one octet follows - giving the length L of the bit sequence. Then a sequence of exactly - as many octets follows as needed to carry L bits of information (= - trunc((L+7)/8) ). - - +---+---+---+---+---+---+---+---+ - | N | Entry Type Code (1 or 2) | - +---+---+---+---+---+---+---+---+ - | Length Field L | - +---+---+---+---+---+---+---+---+ - | Bit Field | - / ((L+7)/8) Octets / - +---+---+---+---+---+---+---+---+ - - -7.2.4. Encoding of DNS - - After the entry type tag immediately follows a DNS encoded and - compressed [3] domain name. - - - -Hadmut Danisch Experimental [Page 18] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - +---+---+---+---+---+---+---+---+ - | N | Entry Type Code (3..5) | - +---+---+---+---+---+---+---+---+ - | Length Field L | - +---+---+---+---+---+---+---+---+ - | Encoded DNS | - / Name as described in RFC1035 / - +---+---+---+---+---+---+---+---+ - - In contrast to earlier versions of this draft, the DNS name cannot - be compressed, since this would cause decompression errors when a - DNS server is part of the query chain which does not know this - particular RR type. - -7.2.5. Encoding of unused and full query - - These entries do not contain parameters and does not allow the - negation flag. So the encoding is quite simple: - - +---+---+---+---+---+---+---+---+ - | 0 | Entry Type Code (6 or 7)| - +---+---+---+---+---+---+---+---+ - - - -7.2.6. Additional Records - - In order to avoid the need of a second query to resolve the given - host name, a DNS server should enclose the A record for that domain - name in the additional section of the additional section of the DNS - reply, if the server happens to be authoritative. - - In order to avoid the need of a second query to resolve the given - host name, a DNS server should enclose the APL record for that - domain name in the additional section of the additional section of - the DNS reply, if the server happens to be authoritative. - - - -8. Message Headers - - An RMX query must be followed by any kind of action depending on - the RMX result. One action might be to reject the message. Another - action might be to add a header line to the message body, thus - allowing MUAs and delivery programs to filter or sort messages. - - In future, the RMX result might be melted into the Received: header - line. - - - -Hadmut Danisch Experimental [Page 19] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - The details of such entries are to be discussed. As a proposal the - following form is suggested: - - X-RMX: RESULT addr ADDRESS by HOST on DATE mechanism MECHANISM - - where - - RESULT is one of "Granted", "Denied", "NotInRMX", "NoRMX", - "TempFail", "BadData", "Trusted". - - ADDRESS is the IP address of the sending machine - - HOST is the name of the machine performing the RMX query. - - DATE is the date of the query. - - MECHANISM is the RMX method used to authorize the sender. - - - -9. SMTP error messages - - If a message is rejected because of RMX records, an error message - should be issued which explains the details. It is to be discussed - whether new SMTP error codes are to be defined. - - -10. Message relaying and forwarding - -10.1. Problem description - - Message forwarding and relaying means that an MTA which received an - e-mail by SMTP does not deliver it locally, but resends the message - - usually unchanged except for an additional Received header line - and maybe the recipient's address rewritten - to the next SMTP MTA. - Message forwarding is an essential functionality of e-mail - transport services, for example: - - - Message transport from outer MX relay to the intranet - - Message forwarding and Cc-ing by .forward or .procmail-alike - mechanisms - - Mailing list processing - - Message reception by mail relays with low MX priority, - usually provided by third parties as a stand-by service - in case of relay failure or maintenance - - "Forwarding" and "Bouncing" as a MUA functionality - - In all these cases a message is sent by SMTP from a host which is - - - -Hadmut Danisch Experimental [Page 20] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - not covered by the original sender domain's RMX records. While the - RMX records would forbid accepting this message, it still must be - accepted. The following subsections explain how to cope with - relaying. - -10.2. Trusted relaying/forwarding - - In some cases the receiving MTA trusts the sending MTA to not fake - messages and to already have checked the RMX records at message - reception. As a typical example, a company might have an outer mail - relay which receives messages from the Internet and checks the RMX - records. This relay then forwards the messages to the different - department's mail servers. It does not make sense for these - department mail servers to check the RMX record, since the RMX - records have already been checked and - since the message was - relayed by the outer relay - always would deny the message. In this - case there is a trust relationship between the department relays - and the outer relay. So RMX checking is turned off for trusted - relays. In this example, the department relays would not check - messages from the outer relay (but for intranet security, they - could still check RMX records of the other departments sub-domains - to avoid internal forgery between departments). - - Another common example are the low-priority MX relays, which - receive and cache e-mails when the high-priority relays are down. - In this case, the high-priority relay would trust the low-priority - relay to have verified the sender authorization and would not - perform another RMX verification (which would obviously fail). - - When a relay forwards a message to a trusting machine, the envelope - sender address should remain unchanged. - -10.3. Untrusted relaying/forwarding - - If the receiving MTA does not trust the forwarding MTA, then there - is no chance to leave the sender envelope address unchanged. At a - first glance this might appear impracticable, but this is - absolutely necessary. If an untrusted MTA could claim to have - forwarded a message from a foreign sender address, it could have - forged the message as well. Spammers and forgers would just have to - act as such a relay. - - Therefore, it is required that, when performing untrusted - forwarding, the envelope sender address has to be replaced by the - sender address of someone responsible for the relaying mechanism, - e.g. the owner of the mailing list or the mail address of the user - who's .forward caused the transmission. It is important to stress - that untrusted relaying/forwarding means taking over responsibility - - - -Hadmut Danisch Experimental [Page 21] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - for the message. It is the idea of RMX records to tie - responsibility to message transmission. Untrusted relaying without - replacing the sender address would mean to transmit without taking - responsibility. - - The disadvantage is that the original sender address is lost. - Therefore, whenever a sender address replacement happens, the - Received-Line must contain the old address. Many of today's MTAs - already insert the envelope recipient address, but not the sender - address into the Received header line. It seems reasonable to - require every Received line to include both the sender and - recipient address of the incoming SMTP connection. - - -11. Security Considerations - -11.1. Draft specific considerations - -11.1.1. Authentication strength - - It is important to stress, that the suggested method does not - provide high level security and does not completely prevent forged - e-mails or spam under any circumstances. It is a robust, but not - highly reliable and completely secure security mechanism. Keep in - mind that it is based on DNS, and DNS is not secure today. - Authorization is based on the IP address. The very same machine - with the very same IP address could be authorized to send e-mail - with a given sender address and sending spam at the same time. - Maybe because several users are logged in. Or because several - customers use the same relay of the same ISP, where one customer - could use the sender address of a different customer. It is up to - the ISP to prevent this or not. Machines can still be hijacked. - Spammers are also domain owners. They can simply use their own - domain and authorize themselves. You will always find people on the - world who do not care about security and open their relays and RMX - records for others to abuse them. RMX is to be considered as a - very cheap and simple light weight mechanism, which can - nevertheless provide a significant improvement in mail security - against a certain class of attacks, until a successor of SMTP has - been defined and commonly accepted. - -11.1.2. Where Authentication and Authorization end - - Previous versions of RMX records did not cover the local part of - the e-mail address, i.e. what's on the left side of the @ sign. - This is still to be discussed. Authentication and authorization are - limited to the sending MTA's IP address. The authentication is - limited to the TCP functionality, which is sufficient for light - - - -Hadmut Danisch Experimental [Page 22] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - weight authentication. The RMX records authorize the IP address of - the sending host only, not the particular sender of the message. So - if a machine is authorized to use sender addresses of more than a - single domain, the authentication scheme does not prevent that any - user on this machine can send with any of these domains. RMX is not - a substitute for the host security of the involved machines. - - The proposed authentication scheme can be seen as a "half way - authentication": It does not track back an e-mail to the effective - sender. It tracks only half of the way, i. e. it tracks back to the - domain and it's DNS administrators who authorized that particular - sender IP address to use it for sending e-mail. How the party - responsible for that domain performs user authentication, whom it - grants access to, how it helds people responsible for abuse, is - completely left as the private business of those who are in charge - of that domain. So this draft does not interfere with the domain's - individual security policy or any legislation about such policies. - On the other hand, the proposed authentication scheme does not give - any statement about the nature and quality of the domain's security - policy. This is an essential feature of the proposal: E-mail - authentication must be deployed world wide, otherwise it won't do - the job. Any security scheme interfering with the local - legislations or the domain's security policy will not be accepted - and can't effectively deployed. Therefore, the security policy must - remain the domain's private business, no matter how lousy the - policy might be. - - In order to achieve this and to make use of the only existing world - wide Internet directory scheme (DNS), the approach of this proposal - is to just ignore the local part of the sender address (i.e. what's - left of the @ part) and limit view to the domain part. After all, - that's what we do anyway when delivering to a given address with - SMTP. - -11.1.3. Vulnerability of DNS - - DNS is an essential part of the proposed authentication scheme, - since it requires any directory service, and DNS is currently the - only one available. Unfortunately, DNS is vulnerable and can be - spoofed and poisoned. This flaw is commonly known and weakens many - network services, but for reasons beyond that draft DNS has not - been significantly improved yet. After the first version of this - draft, I received several comments who asked me not to use DNS - because of its lack of security. I took this into consideration, - but came to the conclusion that this is unfeasible: Any - authentication scheme linked to some kind of symbolic identity (in - this case the domain name) needs some kind of infrastructure and - trusted assignment. There are basically two ways to do it: Do it - - - -Hadmut Danisch Experimental [Page 23] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - yourself and trust nobody else, or let someone else do it. There - are methods to do it the former way, e.g. to give someone some kind - of authentication information after a first successful e-mail - exchange, e.g. some kind of cookie or special e-mail address. This - is certainly interesting and powerful, but it does not solve the - problem on a world wide scale and is far to complicated and error - prone for the average user, i. e. 99% of the users. - - The latter method to let someone else do the symbolic name - assignment and create the authentication framework is well known. - It context of public key cryptography, this is called a Public Key - Infrastructure (PKI). On of the best known facts about PKIs is - that, until now, we don't have any covering a significant part of - the Internet. And we won't have any in near future. The complexity - is far too high, it is too expensive, and it involves cooperation - of every single user, which is simply unrealistic and extremely - error prone. So what do we have we can use? All we have is the DNS - and the Whois database. And we have countries who don't allow - cryptography. So the proposal was designed to use DNS without - cryptography. It does not avoid DNS because of its vulnerability, - it asks for a better DNS, but accepts the DNS as it is for the - moment. Currently there are two main threats caused by the DNS - weakness: - - - A spammer/forger could spoof DNS in order to gain false - authorization to send fake e-mails. - - - An attacker could spoof DNS in order to block delivery from - authorized machines, i. e. perform a Denial of Service attack. - - The first one is rather unrealistic, because it would require an - average spammer to poison a significant part of the DNS servers of - its victims. A spammer sending messages to one million receipients - would need to poison at least 1-10% which is 10,000 to 100,000 - receipient's DNS servers. This should be unfeasible in most cases. - - In contrast, the second threat is a severe one. If an attacker - wanted to block messages from one company to another, he just needs - to poison the recipients DNS server with a wrong RMX record in - order to make the recipient's SMTP machine reject all messages. And - this is feasible since the attacker needs to poison only a single - DNS server. But does this make SMTP more vulnerable? No. Because - the attacker can already do even more without RMX. By poisoning the - sender's DNS server with wrong MX records, the attacker can also - block message delivery or even redirect the messages to the - attacker's machine, thus preventing any delivery error messages and - furthermore getting access to the messages. - - - - -Hadmut Danisch Experimental [Page 24] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - As a consequence, e-mail delivery by SMTP requires a better DNS - anyway. The requirements are not significantly expanded by RMX. - -11.1.4. Sneaking RMX attack? - - While writing a test implementation, a certain kind of attack came - into my mind. I'm still not sure, whether this attack is possible - on any DNS server, but I believe it should be mentioned: - - Imagine an unauthorized sender is sending a forged mail (e.g. - spam). At connection time, before querying the RMX record, the - receiving MTA usually performs a PTR query for the IP address of - the sending MTA. If the sender has control over the authoritative - name server for that particular IP address, the sender could give a - normal PTR answer, but could append a wrong RMX, APL, or A record - in the additional section of the query. A subsequent RMX query - could receive wrong DNS data if the DNS server used by the - receiving MTA accepted those forged records. - -11.1.5. Open SMTP relays - - Open SMTP relays (i.e. machines who accept any e-mail message from - anyone and deliver to the world) abused by spammers are a one of - the main problems of spam defense and sender backtracking. In most - cases this problem just vanishes because foreign open relay - machines will not be covered by the RMX records of the forged - sender address. But there are two special cases: - - If the spammer knows about a domain which authorizes this - particular machine, that domain can be used for forgery. But in - this case, the IP address of the relay machine and the RMX records - of the domain track back to the persons responsible. Both can be - demanded to fix the relay or remove the RMX record for this - machine. An open relay is a security flaw like leaving the machine - open for everybody to login and send random mails from inside. Once - the administrative persons refuse to solve the problem, they can be - identified as spammers and held responsible. - - The second special case is when a domain authorizes all IP - addresses by having the network 0.0.0.0/0 in the RMX/APL record. In - this case, open relays don't make things worse. It's up to the - recipient's MTA to reject mails from domains with loose security - policies. - -11.1.6. Unforged Spam - - This proposal does not prevent spam (which is, by the way, not yet - exactly defined), it prevents forgery. Since spam is against law - - - -Hadmut Danisch Experimental [Page 25] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - and violates the recipients rights, spam depends on untracability - of the sender. In practice the sender forges the sender address - (other cases see below). This proposal is designed to detect such - forgeries. - - However, the RMX approach is rendered ineffective, if the sender - doesn't forge. If the sender uses just a normal address of it's own - domain, this is just a plain, normal e-mail, which needs to be let - through. Since it is up to the human's taste whether this is spam - or not, there's no technical way to reliably identify this as spam. - But since the sender domain is known, this domain can be - blacklisted or legal steps can be gone into. - -11.1.7. Reliability of Whois Entries - - Once the RMX infrastructure gets deployed, what's the security - gain? It allows to determine the domain which's DNS zone - authorized the sending machine. What's that good for? There are - some immediate uses of the domain name, e.g. in black- and - whitelisting. But in most cases this is just the starting point of - further investigations, either performed automatically before - message acceptance, or manually after spam has been received and - complainted about. - - The next step after determining the domain is determining the - people responsible for this domain. This can sometimes be achieved - by querying the Whois databases. Unfortunately, many whois entries - are useless because they are incomplete, wrong, obsolete, or in - uncommon languages. Furthermore, there are several formats of - address informations which make it difficult to automatically - extract the address. Sometimes the whois entry identifies the - provider and not the owner of the domain. Whois servers are not - built for high availability and sometimes unreachable. - - Therefore, a mandatory standard is required about the contents and - the format of whois entries, and the availability of the servers. - After receiving the MAIL FROM SMTP command with the sender envelope - address, the receiving MTA could check the RMX record and Whois - entry. If it doesn't point to a real human, the message could be - rejected and an error message like "Ask your provider to fix your - Whois entry" could be issued. Obviously, domain providers must be - held responsible for wrong entries. It might still be acceptable to - allow anonymous domains, i. e. domains which don't point to a - responsible human. But it is the receivers choice to accept e-mails - from such domains or not. - -11.1.8. Hazards for Freedom of Speech - - - - -Hadmut Danisch Experimental [Page 26] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - Currently, some governments try to enforce limitations of internet - traffic in order to cut unwanted content providers from the - network. Some of these governments try to hide a whole country - behind firewalls, others try to force Internet providers to poison - DNS servers with wrong A records for web servers, e.g. one county - administration in Germany tries to do so. If message reception - depends on DNS entries, the same governments will try to block not - only HTTP, but SMTP also. - - However, since most MTAs already reject messages from unresolvable - domain names this is not a new threat. - -11.2. General Considerations about spam defense - - After discussing security requirements of the proposal, now the - security advantages of the RMX approach over content based filters - will be explained. Basically, there are three kinds of content - filters: - - - Those who upload the message or some digest to an external - third party and ask "Is this spam"? - - - Those who download a set of patterns and rules from a third - party and apply this set to incoming messages in order to - determine whether it is spam. - - - Those who are independent and don't contact any third party, - but try to learn themselves what is spam and what isn't. - - - The message filters provided by some e-mail service providers are - usually not a kind of their own, but a combination of the first two - kinds. - -11.2.1. Action vs. reaction - - Content filters suffer from a fundamental design problem: They are - late. They need to see some content of the same kind before in - order to learn and to block further distribution. - - This works for viruses and worms, which redistribute. This doesn't - work for spam, since spam is usually not redistributed after the - first delivery. When the filters have learned or downloaded new - pattern sets, it's too late. - - This proposal does not have this problem. - -11.2.2. Content based Denial of Service attacks - - - -Hadmut Danisch Experimental [Page 27] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - All three kinds of content filters, but especially the second and - the third kind are vulnerable to content based Denial of Service - attacks. - - If some kind of third party (e.g. non-democratic government, - intellectual property warriors, religious groups, military, secret - services, patriots, public relation agents, etc.) wants certain - contents not to be distributed, they could either poison the - pattern/rule databases or feed wrong sets to particular receivers. - - Such pattern/rule sets are the perfect tool for censoring e-mail - traffic and denial of service attacks by governments and other - parties, and a similar threat are virus filters. E. g. the content - industry could demand to teach all virus and spam filters to delete - all e-mails containing the URL of an MP3 web server outside the - legislations. Software manufacturers could try to block all e-mails - containing software license keys, thus trying to make unallowed - distribution more difficult. Governments could try to block - distribution of unwanted informations. - - This proposal does not have this problem. - - -12. Privacy Considerations - - (It was proposed on the 56th IETF meeting to have a privacy section - in drafts and RFCs.) - -12.1. Draft specific considerations - -12.1.1. No content leaking - - Since the RMX approach doesn't touch the contents of a message in - any way, there is obviously no way of leaking out any information - about the content of the message. RMX is based solely on the - envelope recipient address. However, methods to fix problems not - covered by RMX might allow content leaking, e.g. if the acceptance - of a message with an empty sender address requires the reference to - the message id of an e-mail recently sent, this allows an attacker - to verify whether a certain message was delivered from there. - -12.1.2. Message reception and sender domain - - Message delivery triggers RMX and APL requests by the recipient. - Thus, the admin of the DNS server or an eavesdropper could learn - that the given machine has just received a message with a sender - from this address, even if the SMTP traffic itself had been - encrypted. - - - -Hadmut Danisch Experimental [Page 28] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - However, most of today's MTAs do query the MX and A records of the - domain after the MAIL FROM command, so this is not a real new - threat. - -12.1.3. Network structure - - Since RMX and its associated APL records provide a complete list of - all IP addresses of hosts authorized to send messages from this - address, they do reveal informations about the network structure - and maybe the lifestyle of the domain owner, since a growing number - of domains are owned by single persons or families. E.g. the RMX - records could reveal where someone has his job or spends his time - at weekends. - - If such informations are to be kept secret, it is the user's job to - not sent e-mails from there and to relay them from non-compromising - IP addresses. - -12.1.4. Owner information distribution - - As described above, RMX depends partly on the reliability of the - whois database entries. It does not make anonymous domains - impossible, but it requires to keep the database entries "true", i. - e. if a whois entry does not contain informations about the - responsible person, this must be unambigously labeled as anonymous. - It must not contain fake names and addresses to pretend a non- - existing person. However, since most Internet users on the world - feel extremely annoyed by spam, they will urge their MTA admin to - reject messages from anonymous domains. The domain owner will have - the choice to either remain anonymous but be not able to send e- - mail to everyone in the world, or to be able but to reveal his - identity to everyone on the world. - - It would be possible to provide whois-like services only to - recipients of recent messages, but this would make things too - complicated to be commonly adopted. - -12.2. General Considerations about spam defense - -12.2.1. Content leaking of content filters - - As described above in the Security chapter, there are spam filters - which inherently allow leakage of the message body. Those filters - upload either the message body, or in most cases just some kind of - checksum to a third party, which replies whether this is to be seen - as spam or not. The idea is to keep a databases of all digests of - all messages. If a message is sent more often than some threshold, - it is to be considered as a mass mail and therefore tagged as spam. - - - -Hadmut Danisch Experimental [Page 29] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - While the digest itself does not reveal the content of the message, - it perfectly reveals where a particular message has been delivered - to. If a government finds just a single unwanted message, if a - software manufacturer finds a single message with a stolen product - license key, if someone finds a message with unpatriotic content, - it takes just a single database lookup to get a list of all people - who received this particular message. Content filters with digest - upload are the perfect "Big Brother". - -12.2.2. Black- and Whitelists - - Some proposals against spam are based on a central database of - white- or blacklisted IP addresses, Sender names, Message IDs or - whatever. Again, there is a central database which learns who has - received which e-mail or from which sender with every query. This - allows tracking relations between persons, which is also a breach - of privacy. - - - -13. Deployment Considerations - -13.1. Compatibility - -13.1.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. - -13.1.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. - -13.1.3. Compatibility with old DNS clients - - Since the RMX is a new RR, the existing DNS protocol and zone - informations remain completely untouched. - - If RMX is provided as a TXT record instead, it must be ensured that - no other software is misinterpreting this entry. - -13.1.4. Compatibility with old DNS servers - - Full compatibility: If the server does not support RMX records, RMX - in TXT records can be used. - - - -Hadmut Danisch Experimental [Page 30] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - -13.2. 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. - 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. - - - -14. General considerations about fighting spam - - Is there a concise technical solution against spam? Yes. - - Will it be deployed? Certainly not. - - Why not? Because of the strong non-technical interests of several - parties against a solution to the problem, as described below. - Since these are non-technical reasons, they might be beyond the - scope of such a draft. But since they are the main problems that - prevent fighting spam, it is unavoidable to address them. This - chapter exists temporarily only and should support the discussion - of solutions. It is not supposed to be included in a later RFC. - -14.1. The economical problem - - As has been recently illustrated in the initial session of the - IRTF's Anti Spam Research Group (ASRG) on the 56th IETF meeting, - sending spam is a business with significant revenues. - - But a much bigger business is selling Anti-Spam software. This is a - billion dollar market, and it is rapidly growing. Any simple and - effective solution against spam would defeat revenues and drive - several companies into bankrupt, would make consultants jobless. - - - -Hadmut Danisch Experimental [Page 31] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - Therefore, spam is essential for the Anti-Spam business. If there - is no spam, then no Anti-Spam software can be sold, similar to the - Anti-Virus business. There are extremely strong efforts to keep - this market growing. Viruses, Worms, and now spam are just perfect - to keep this market alive: It is not sufficient to just buy a - software. Databases need to be updated continuously, thus making - the cash flow continuously. Have a single, simple, and permanent - solution to the problem and - boom - this billion dollar market is - dead. - - That's one of the reasons why people are expected to live with - spam. They have to live with it to make them buy Anti-Spam - software. Content filters are perfect products to keep this market - alive. - -14.2. The POP problem - - Another problem is the history of mail delivery. Once upon a time, - there used to be very few SMTP relays which handled the e-mail - traffic of all the world, and everybody was happy with that. Then - odd things like Personal Computers, which are sometimes switched - off, portable computers, dynamicly assigned IP addresses, IP access - from hotel rooms, etc. was invented, and people became unhappy, - because SMTP does not support delivery to such machines. To make - them happy again, the Post Office Protocol[4] was invented, which - turned the last part of message delivery from SMTP's push style - into a pull style, thus making virtually every computer on the - world with any random IP address a potential receiver of mails for - random domains. Unfortunately, only receiving e-mail was covered, - but sending e-mail was left to SMTP. - - The result is that today we have only very few SMTP relays pointed - to by MX records, but an extreme number of hosts sending e-mail - with SMTP from any IP address with sender addresses from any - domain. Mail delivery has become very asymmetric. Insecurity, - especially forgeability, has become an essential part of mail - transport. - - That problem could easily be fixed: Use protocols which allow - uploading of messages to be delivered. If a host doesn't receive - messages by SMTP, it shouldn't deliver by SMTP. Mail delivery - should go the same way back that incoming mail went in. This is - not a limitation to those people on the road who plug their - portable computer in any hotel room's phone plug and use any - provider. If there is a POP server granting download access from - anywhere, then the same server should be ready to accept uploading - of outgoing messages. - - - - -Hadmut Danisch Experimental [Page 32] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - But as I saw from the comments on the first version of this draft, - people religiously insist on sending e-mail with their domain from - any computer with any IP address in the world, e.g. when visiting a - friend using her computer. It appears to be impossible to convince - people that stopping mail forgery requires every one of them to - give up forging. - -14.3. The network structure problem - - A subsequent problem is that many organisations failed to implement - a proper mail delivery structure and heavily based their network on - this asymmetry. I received harsh comments from Universities who - were unable to give their network a good structure. While they do - have a central mail relay for incoming mail to the universities - domain, they developed a structure where every member of the - University randomly sends e-mails with that University's domain as - a sender address from home or everywhere in the world with any - dynamically assigned IP address from any provider. So this domain - is to be used from every possible IP address on earth, and they are - unable to operate any authentication scheme. Furthermore, they were - unable to understand that such a policy heavily supports spam and - that they have to expect that people don't accept such e-mails - anymore once they become blacklisted. - - As long as organisations insist on having such policies, spammers - will have a perfect playground. - -14.4. The mentality problem - - Another problem is the mentality of many internet users of certain - countries. I received harsh comments from people who strongly - insisted on the freedom to send any e-mail with any sender address - from anywhere, and who heavily refused any kind of authentication - step or any limitation, because they claimed that this would - infringe their constitutional "Freedom of speech". They are - undeviatingly convinced that "Freedom of speech" guarantees their - right to talk to everybody with any sender address, and that is has - to be kept the recipient's own problem to sort out what he doesn't - want to read - on the recipient's expense. - - It requires a clear statement that the constitutional "Freedom of - Speech" does not cover molesting people with unsolicited e-mail - with forged sender address. - -14.5. The identity problem - - How does one fight against mail forgery? With authentication. What - is authentication? In simple words: Making sure that the sender's - - - -Hadmut Danisch Experimental [Page 33] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - real identity meets the recipients idea of who is the sender, based - on the sender address which came with the message. - - What is identity? It is the main problem. Several countries have - different ideas of "identity", which turn out to be somehow - incompatible. In some countries people have identity cards and - never change their name and birthday. Identities are created by - human birth, not by identity changes. Other countries do not have - such a tight idea about identity. People's temporary identity is - based on nothing more than a driving license and a social security - number. With this background, it is virtually impossible to create - a trustworthy PKI covering all Internet users. I learned that it is - extremely difficult to convince some people to give up random e- - mail sending. - -14.6. The multi-legislation problem - - Many proposals about fighting spam are feasible under certain - legislations only, and are inacceptable under some of the - legislations. But a world wide applicable method is required. - That's why the approach to ask everone on the world to sign - messages with cryptographic keys is not feasible. - - -Implementation and further Information - - Further informations and a test implementation are available at - - http://www.danisch.de/work/security/antispam.html - http://www.danisch.de/software/rmx/ - - - Additional informations and a technology overview are also - available at - - http://www.mikerubel.org/computers/rmx_records/ - - -References - - - -1. S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev- - els," RFC 2119 (March 1997). - -2. J. Klensin, "Simple Mail Transfer Protocol," RFC 2821 (April 2001). - - - - - -Hadmut Danisch Experimental [Page 34] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - -3. P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION," - RFC 1035 (November 1987). - -4. J. Myers, M. Rose, "Post Office Protocol - Version 3," RFC 1939 - (May 1996). - - -Draft History - - 00 Dec 2002 - 01 Apr 2003 - 02 Jun 2003 - 03 Oct 2003 - -Author's Address - - Hadmut Danisch - - Tennesseeallee 58 - 76149 Karlsruhe - Germany - - Phone: ++49-721-843004 or ++49-351-4850477 - E-Mail: rfc@danisch.de - -Comments - - Please send comments to rfc@danisch.de. - -Expiry - - This drafts expires on Apr 1, 2004. - - - - - - - - - - - - - - - - - - - -Hadmut Danisch Experimental [Page 35] - |