4 INTERNET-DRAFT Hadmut Danisch
5 Category: Experimental Oct 2003
8 The RMX DNS RR and method for lightweight SMTP sender authorization
9 draft-danisch-dns-rr-smtp-03.txt
13 This document is an Internet-Draft and is subject to all provisions
14 of Section 10 of RFC2026.
16 Internet-Drafts are working documents of the Internet Engineering
17 Task Force (IETF), its areas, and its working groups. Note that
18 other groups may also distribute working documents as Internet-
21 Internet-Drafts are draft documents valid for a maximum of six
22 months and may be updated, replaced, or obsoleted by other
23 documents at any time. It is inappropriate to use Internet-Drafts
24 as reference material or to cite them other than as "work in
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/1id-abstracts.html
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html
35 This memo introduces a new authorization scheme for SMTP e-mail
36 transport. It is designed to be a simple and robust protection
37 against e-mail fraud, spam and worms. It is based solely on
38 organisational security mechanisms and does not require but still
39 allow use of cryptography. This memo also focuses on security and
40 privacy problems and requirements in context of spam defense. In
41 contrast to prior versions of the draft a new RR type is not
55 Hadmut Danisch Experimental [Page 1]
57 INTERNET-DRAFT DNS RMX RR Oct 2003
63 1. General Issues . . . . . . . . . . . . . . . . . . . . . . . . . 4
64 2. Problem and threat description . . . . . . . . . . . . . . . . . 4
65 2.1. Mail sender forgery . . . . . . . . . . . . . . . . . . . 4
66 2.1.1 Definition of sender forgery . . . . . . . . . . . 4
67 2.1.2 Spam . . . . . . . . . . . . . . . . . . . . . . . 5
68 2.1.3 E-Mail Worms . . . . . . . . . . . . . . . . . . . 5
69 2.1.4 E-Mail spoofing and fraud . . . . . . . . . . . . . 5
70 2.2. Indirect damage caused by forgery . . . . . . . . . . . . 6
71 2.3. Technical problem analysis . . . . . . . . . . . . . . . . 6
72 2.4. Shortcomings of cryptographical approaches . . . . . . . . 7
73 3. A DNS based sender address verification . . . . . . . . . . . . 7
74 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7
75 3.2. Envelope vs. header sender address . . . . . . . . . . . . 9
76 3.3. Domain part vs. full sender address . . . . . . . . . . . 9
77 4. Mapping of E-Mail addresses to DNS names . . . . . . . . . . . . 10
78 4.1. Domain part only . . . . . . . . . . . . . . . . . . . . . 10
79 4.2. Full address . . . . . . . . . . . . . . . . . . . . . . . 11
80 4.3. Empty address . . . . . . . . . . . . . . . . . . . . . . 11
81 5. Mandatory entry types and their syntax . . . . . . . . . . . . . 11
82 5.1. Overall structure . . . . . . . . . . . . . . . . . . . . 11
83 5.2. Unused . . . . . . . . . . . . . . . . . . . . . . . . . . 12
84 5.3. IPv4 and IPv6 address ranges . . . . . . . . . . . . . . . 12
85 5.4. DNS Hostname . . . . . . . . . . . . . . . . . . . . . . . 13
86 5.4.1 Road warriors and DynDNS entries . . . . . . . . . 13
87 5.5. APL Reference . . . . . . . . . . . . . . . . . . . . . . 14
88 5.6. Domain Member . . . . . . . . . . . . . . . . . . . . . . 14
89 5.7. Full Address Query . . . . . . . . . . . . . . . . . . . . 15
90 5.8. DNS mapped authorization . . . . . . . . . . . . . . . . . 15
91 5.9. RMX reference . . . . . . . . . . . . . . . . . . . . . . 16
92 6. Optional and experimental entry types . . . . . . . . . . . . . 16
93 6.1. TLS fingerprint . . . . . . . . . . . . . . . . . . . . . 16
94 6.2. TLS and LDAP . . . . . . . . . . . . . . . . . . . . . . . 16
95 6.3. PGP or S/MIME signature . . . . . . . . . . . . . . . . . 16
96 6.4. Transparent Challenge/Response . . . . . . . . . . . . . . 17
97 6.5. SASL Challenge/Response . . . . . . . . . . . . . . . . . 17
98 7. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
99 7.1. Alternative encoding as TXT records . . . . . . . . . . . 17
100 7.2. RMX Records . . . . . . . . . . . . . . . . . . . . . . . 17
101 7.2.1 Overall structure . . . . . . . . . . . . . . . . . 18
102 7.2.2 Record encoding . . . . . . . . . . . . . . . . . . 18
103 7.2.3 Encoding of IPv4 and IPv6 address ranges . . . . . 18
104 7.2.4 Encoding of DNS . . . . . . . . . . . . . . . . . . 18
105 7.2.5 Encoding of unused and full query . . . . . . . . . 19
106 7.2.6 Additional Records . . . . . . . . . . . . . . . . 19
107 8. Message Headers . . . . . . . . . . . . . . . . . . . . . . . . 19
111 Hadmut Danisch Experimental [Page 2]
113 INTERNET-DRAFT DNS RMX RR Oct 2003
116 9. SMTP error messages . . . . . . . . . . . . . . . . . . . . . . 20
117 10. Message relaying and forwarding . . . . . . . . . . . . . . . . 20
118 10.1. Problem description . . . . . . . . . . . . . . . . . . . 20
119 10.2. Trusted relaying/forwarding . . . . . . . . . . . . . . . 21
120 10.3. Untrusted relaying/forwarding . . . . . . . . . . . . . . 21
121 11. Security Considerations . . . . . . . . . . . . . . . . . . . . 22
122 11.1. Draft specific considerations . . . . . . . . . . . . . . 22
123 11.1.1 Authentication strength . . . . . . . . . . . . . 22
124 11.1.2 Where Authentication and Authorization end . . . . 22
125 11.1.3 Vulnerability of DNS . . . . . . . . . . . . . . . 23
126 11.1.4 Sneaking RMX attack? . . . . . . . . . . . . . . 25
127 11.1.5 Open SMTP relays . . . . . . . . . . . . . . . . . 25
128 11.1.6 Unforged Spam . . . . . . . . . . . . . . . . . . 25
129 11.1.7 Reliability of Whois Entries . . . . . . . . . . . 26
130 11.1.8 Hazards for Freedom of Speech . . . . . . . . . . 26
131 11.2. General Considerations about spam defense . . . . . . . . 27
132 11.2.1 Action vs. reaction . . . . . . . . . . . . . . . 27
133 11.2.2 Content based Denial of Service attacks . . . . . 27
134 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 28
135 12.1. Draft specific considerations . . . . . . . . . . . . . . 28
136 12.1.1 No content leaking . . . . . . . . . . . . . . . . 28
137 12.1.2 Message reception and sender domain . . . . . . . 28
138 12.1.3 Network structure . . . . . . . . . . . . . . . . 29
139 12.1.4 Owner information distribution . . . . . . . . . . 29
140 12.2. General Considerations about spam defense . . . . . . . . 29
141 12.2.1 Content leaking of content filters . . . . . . . . 29
142 12.2.2 Black- and Whitelists . . . . . . . . . . . . . . 30
143 13. Deployment Considerations . . . . . . . . . . . . . . . . . . . 30
144 13.1. Compatibility . . . . . . . . . . . . . . . . . . . . . . 30
145 13.1.1 Compatibility with old mail receivers . . . . . . 30
146 13.1.2 Compatibility with old mail senders . . . . . . . 30
147 13.1.3 Compatibility with old DNS clients . . . . . . . . 30
148 13.1.4 Compatibility with old DNS servers . . . . . . . . 30
149 13.2. Enforcement policy . . . . . . . . . . . . . . . . . . . 31
150 14. General considerations about fighting spam . . . . . . . . . . 31
151 14.1. The economical problem . . . . . . . . . . . . . . . . . 31
152 14.2. The POP problem . . . . . . . . . . . . . . . . . . . . . 32
153 14.3. The network structure problem . . . . . . . . . . . . . . 33
154 14.4. The mentality problem . . . . . . . . . . . . . . . . . . 33
155 14.5. The identity problem . . . . . . . . . . . . . . . . . . 33
156 14.6. The multi-legislation problem . . . . . . . . . . . . . . 34
157 Implementation and further Information . . . . . . . . . . . . . . . 34
158 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
159 Draft History . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
160 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 35
167 Hadmut Danisch Experimental [Page 3]
169 INTERNET-DRAFT DNS RMX RR Oct 2003
174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
176 this document are to be interpreted as described in RFC 2119 [1].
178 2. Problem and threat description
180 2.1. Mail sender forgery
182 The amount of e-mails with forged sender addresses has dramatically
183 increased. As a consequence, damages and annoyances caused by such
184 e-mails increased as well. In the majority of examined e-mails the
185 domain name of the envelope sender address was forged, and the e-
186 mail was sent from an IP address which does not belong to a network
187 used by the actual owner of the domain.
189 2.1.1. Definition of sender forgery
191 As discussions, comments to prior versions of this draft, and
192 different approaches to stop forgery showed, different perceptions
193 of "mail forgery" exist. For example, there are mechanisms to
194 verify e-mail addresses for mailing lists, web servers, or to stop
195 spam, which do send a message with a random number to the given
196 address and expect the user to send a reply. Here, someone is
197 considered to be allowed to use a particular e-mail address, if and
198 only if he is able to receive informations sent to this address,
199 and is able to reply to such a message. While this definition
200 appears to be quite plausible and natural, it can't be used for a
201 simple technical solution. Sending back a challenge and expecting a
202 reply is simply too much overhead and time delay, and not every
203 authorized sender is able or willing to reply (e.g. because he went
204 offline or is not a human).
206 Within the scope of this memo, sender forgery means that the
207 initiator of an e-mail transfer (which is the original sender in
208 contrast to relays) uses a sender address which he was not
209 authorized to use. Being authorized to use an address means that
210 the owner (administrator) of the internet domain has given
211 permission, i.e. agrees with the use of the address by that
212 particular sender. This memo will cover both the permission of the
213 full e-mail address and the domain part only for simplicity.
215 Within context of Internet and SMTP, the sender address usually
216 occurs twice, once as the envelope sender address in SMTP, and once
217 as the address given in the RFC822 mail header. While the following
218 considerations apply to both addresses in principle, it is
219 important to stress that both addresses have distinct semantics and
223 Hadmut Danisch Experimental [Page 4]
225 INTERNET-DRAFT DNS RMX RR Oct 2003
228 are not neccessarily the same. The envelope address identifies the
229 initiator of the transport, while the header identifies the author
230 of the message content. Since this memo deals with the message
231 transport only and completely ignores the message content, the
232 method should naturally be applied to the envelope sender address.
236 A common and well known problem is the dramatic increase of
237 unsolicited e-mail, commonly called "spam". Again, the majority of
238 examined e-mails had forged sender addresses. The abused domains
239 were mainly those of common webmailers as hotmail or yahoo, or
240 well-known companies.
242 Unfortunately, there is no accurate definition of spam availabe
243 yet, and neither are the concise technical criterions to filter or
244 block spam with technical mechanisms. There are efforts to design
245 content based filters, but these filters are expensive in
246 calculation time (and sometimes money), and they do not reliably
247 provide predictable results. Usually they give false positives
248 and/or require user interaction. Content filters in general suffer
249 from a design problem described later in this memo. Therefore,
250 this proposal does not use the content based approach to block
253 As analysis of spam messages showed, most of spam messages were
254 sent with forged envelope sender addresses. This has mainly three
255 reasons. The first reason is, that spam senders usually do not
256 want to be contacted by e-mail. The second reason is, that they do
257 not want to be blacklisted easily. The third reason is, that spam
258 is or is going to be unlawful in many countries, and the sender
259 does not want to reveal his identity. Therefore, spam is considered
260 to be a special case of sender forgery.
264 Another example of sender forgery is the reproduction of e-mail
265 worms. Most worms do choose random sender addresses, e.g. using
266 the addresses found in mailboxes on the infected system. In most
267 cases analyzed by the author, the e-mails sent by the reproduction
268 process can also be categorized as forged, since the infected
269 system would under normal circumstances not be authorized to send
270 e-mails with such e-mail addresses. So forgery does not require a
271 malicious human to be directly involved. This memo covers any kind
272 of e-mail sender address forgery, included those generated by
275 2.1.4. E-Mail spoofing and fraud
279 Hadmut Danisch Experimental [Page 5]
281 INTERNET-DRAFT DNS RMX RR Oct 2003
284 Forging e-mail sender addresses for fraud or other kinds of
285 deception ("human engineering") has also dramatically increased.
286 There are many known cases where single or mass e-mails were sent
287 with wrong sender addresses, pretending to come from service
288 provider, software manufacturers etc., and asking the receiver to
289 install any software or patches, or to reply with any confidential
290 information. The Internet is becoming more and more a scene of
291 crime, and so are it's services, including e-mail. It is obvious
292 that crime based on e-mail is eased by the fact that SMTP allows
293 arbitrary sender address spoofing.
295 2.2. Indirect damage caused by forgery
297 As observed by the author, mass mails and worms with forged sender
298 addresses can cause a severe damage for the real owner of the
299 abused sender addresses. If a sender A is sending an e-mail to the
300 receiver B, pretending to be C by using a sender address of C's
301 domain, then C has currently no chance to prevent this, since C's
302 machines and software are not involved in any way in the delivery
303 process between A and B. B will nevertheless send any error
304 messages (virus/spam alert, "no such user", etc.) to C, erroneously
305 assuming that the message was sent by C. The author found several
306 cases where this flood of error messages caused a severe denial of
307 service or a dramatic increase of costs, e.g. when C was
308 downloading the e-mail through expensive or low bandwidth
309 connections (e.g. modem or mobile phones), or where disk space was
310 limited. The author examined mass mailings, where several tens or
311 hundreds of thousands of messages were sent to several addresses
312 around the world, where these messages caused only annoyance. But
313 since several thousands of these addresses were invalid or didn't
314 accept the message, the owner of the DNS domain which was abused by
315 the spammer to forge sender addresses was flooded for several
316 months with thousands of error messages, jamming the e-mail system
317 and causing severe costs and damages.
319 As a consequence, when A sends a message to B, pretending to be C,
320 there must be any mechanism to allow C to inform B about the fact,
321 that A is not authorized to use C as a sender address. This is what
324 2.3. Technical problem analysis
326 Why does e-mail forgery actually exist? Because of the lack of the
327 Simple Mail Transfer Protocol SMTP[2] to provide any kind of sender
328 authentication, authorisation, or verification. This protocol was
329 designed at a time where security was not an issue. Efforts have
330 been made to block forged e-mails by requiring the sender address
331 domain part to be resolvable. This method provides protection from
335 Hadmut Danisch Experimental [Page 6]
337 INTERNET-DRAFT DNS RMX RR Oct 2003
340 e-mails with non-existing sender domains, and indeed, for some time
341 it blocked most spam e-mails. However, since attackers and spam
342 senders began to abuse existing domain names, this method was
343 rendered ineffective.
345 2.4. Shortcomings of cryptographical approaches
347 At a first glance, the problem of sender address forgery might
348 appear to be solvable with cryptographic methods such as challenge
349 response authentications or digital signatures. A deeper analysis
350 shows that only a small, closed user group could be covered with
351 cryptographical methods. Any method used to stop spam forgery must
352 be suitable to detect forgery not only for a small number of
353 particular addresses, but for all addresses on the world. An
354 attacker does not need to know the secrets belonging to a
355 particular address. It is sufficient to be able to forge any
356 address and thus to know any secret key. Since there are several
357 hundreds of millions of users, there will always be a large amount
358 of compromised keys, thus spoiling any common cryptographic method.
359 Furthermore, cryptography has proven to be far too complicated and
360 error prone to be commonly administered and reliably implemented.
361 Many e-mail and DNS administrators do not have the knowledge
362 required to deal with cryptographic mechanisms. Many legislations
363 do not allow the general deployment of cryptography and a directory
364 service with public keys. For these reasons, cryptography is
365 applicable only to a small and closed group of users, but not to
366 all participants of the e-mail service.
368 3. A DNS based sender address verification
372 To gain improvement in e-mail authenticity while keeping as much
373 SMTP compatibility as possible, a method is suggested which doesn't
376 The idea is to store informations about how to verify who is
377 authorized to transmit e-mails through SMTP with a particular
378 sender address (either full address or - for simplicity - only the
379 domain part of the address) in a directory service, which is
380 currently the DNS. To be precise, the verification consists of two
381 steps, the classical pair of authentication and authorization:
383 The first step is the authentication. While several methods are
384 possible to perform authentication (see below), the most important
385 and robust method is the verification of the sender's IP address.
386 This is done implicitely by TCP/IP and the TCP sequence number. The
387 authenticated identity is the IP address. It has to be stressed
391 Hadmut Danisch Experimental [Page 7]
393 INTERNET-DRAFT DNS RMX RR Oct 2003
396 that this TCP/IP "authentication" is a weak authentication and
397 vulnerable to several attacks. It is nevertheless sufficient for
398 this purpose, especially for blocking spam. It doesn't take any
399 implementation and it doesn't cost: It is already there, it is a
400 functionality of TCP/IP. An incoming SMTP connection based on
401 TCP/IP already carries the sender's IP address without any
402 modification of SMTP. See below (section Entry types) for more
403 details about authentication methods.
405 The second step is the authorization. It is based on the identity
406 given by the previous authentication step, e.g. the IP address of
407 the originator of the incoming SMTP connection, and on the
408 envelope sender address. The mechanism proposed in this memo
409 answers the question "Is that particular sender (IP address,...)
410 allowed to send with that sender address" by querying and
411 processing informations stored in a directory service, which is
414 When the sender has issued the "MAIL FROM:" SMTP command, the
415 receiving mail transfer agent (MTA) can - and modern MTAs do -
416 perform some authorization checks, e.g. run a local rule database
417 or check whether the sender domain is resolvable.
419 The suggested method is to let the DNS server for the sender domain
420 provide informations about who - this means for example which IP
421 address - is authorized to use an address or a domain as a part of
422 it. After receiving the "MAIL FROM:" SMTP command, the receiving
423 MTA can verify, whether e. g. the IP address of the sending MTA is
424 authorized to send mails with this domain name. Therefore, a list
425 of entries with authorized IP addresses or other informations is
426 provided by the authoritative DNS server of that domain. The entry
427 types are described in the subsequent chapters. Some of these
430 - An IPv4 or IPv6 network address and mask
431 - A fully qualified domain name referring to an A record
432 - A fully qualified domain name referring to an APL record
434 RMX records of these types would look like this:
436 somedomain.de. IN RMX ipv4:10.0.0.0/8
437 rmxtest.de. IN RMX host:relay.provider.com
438 danisch.de. IN RMX apl:relays.rackland.de
439 relays.rackland.de. IN APL 1:213.133.101.23/32 1:1.2.3.0/24
441 where the machine with the example address 213.133.101.23 and the
442 machines in the example subnet 1.2.3.0/24 are the only machines
443 allowed to send e-mails with an envelope sender address of domain
447 Hadmut Danisch Experimental [Page 8]
449 INTERNET-DRAFT DNS RMX RR Oct 2003
452 danisch.de. Since the APL records do not necessarily belong to the
453 same domain or zone table as the RMX records, this easily allows to
454 refer to APL records defined by someone else, e.g. the internet
455 access or server hosting provider, thus reducing administrative
456 overhead to a minimum. In the example given above, the domain
457 danisch.de and several other domains are hosted by the service
458 provider Rackland. So if the relay structure of Rackland is
459 modified, only the zone of rackland.de needs to be modified. The
460 domain owners don't need to care about such details.
462 3.2. Envelope vs. header sender address
464 Questions were raised why the proposed mechanism is based on the
465 envelope sender address, and not on the sender address given in the
466 message header. Technically, both can be used. Actually, it makes
467 sense to use the envelope address.
469 In common, the header sender address identifies the author of the
470 content, while the envelope sender tells who caused the
471 transmission. The approach proposed in this memo is transmission
472 based, not content based. We can not authorize the author of a
473 message if we don't have contact with him, if the message does not
474 already contain a signature. In contrast, the sending MTA is linked
475 to an IP address which can be used for authentication. This
476 mechanism might not be very strong, but it is available and
477 sufficient to solve today's e-mail security problems.
479 Some people argued that it is the header address and not the sender
480 address, which is displayed in common mail readers (MUAs), and
481 where the receiver believes the mail comes from. That's true, but
482 it doesn't help. There are many cases where the header sender
483 differs from the envelope sender for good reasons (see below in the
484 consequences chapter for the discussion about relaying). Relaying,
485 mailing lists etc. require to replace the sender address used for
486 RMX. If this were the header address, the message header would have
487 to be modified. This is undesirable.
489 3.3. Domain part vs. full sender address
491 Former versions of this draft were limited to the domain part of
492 the sender address. The first reason is that it is common and MX-
493 like, to lookup only the domain part of an e-mail address in DNS.
494 The second reason is, that it was left to the private business of
495 the domain administration to handle details of user verification.
496 The idea was that the domain administration takes care to verify
497 the left part of an e-mail address with an arbitrary method of
498 their individual taste. RMX was originally designed to ignore the
499 left part of the address and to expect the domain administration to
503 Hadmut Danisch Experimental [Page 9]
505 INTERNET-DRAFT DNS RMX RR Oct 2003
508 take over responsibility for enforcing their policy. If, e.g., a
509 spam message arrived and passed the RMX mechanism, it is known to
510 be authorized by the domain administration and they can be blamed,
511 no matter what is on the left side of the sender address - it's
512 their private problem what happens on the left side of the @. By
513 far the most of the comments to prior versions of this draft agreed
514 with that. A few comments asked for a finer granularity.
516 And indeed, there is no technical reason against a finer
517 granularity. All it takes is a mapping from a given envelope
518 sender address to a DNS name, and the RMX lookup for that
519 particular e-mail address could be done instead of a lookup for the
520 domain part only. However, to my knowledge, most domain
521 administrators would not like to provide an RMX entry for every
522 single e-mail address. In many cases, this would also overload DNS
525 It is to be discussed how to cover both views. One method could be
526 to query the full address, and if no RMX records were found to
527 query the domain part only. A different approach would be to query
528 the domain part only, and if it's RMX record contain a special
529 entry, then a new query for the full address is triggered. A third
530 way would be to always query the full address and to leave the
531 problem to the wildcard mechanism of DNS. This still has to be
532 discussed and will be described in future versions of this draft.
544 4. Mapping of E-Mail addresses to DNS names
546 To perform the RMX query, a mapping is needed from E-Mail addresses
547 to DNS fully qualified domain names.
549 This chapter is under development and just a first approach.
551 4.1. Domain part only
553 Mapping of the domain part is trivial, since the domain part of an
554 e-mail address itself is a valid DNS name and does not need
555 translation. It might be nevertheless desirable to distinguish the
559 Hadmut Danisch Experimental [Page 10]
561 INTERNET-DRAFT DNS RMX RR Oct 2003
564 RMX entries from other entries, depending of the encoding of the
565 records. If the RMX entries are encoded in TXT record types, they
566 might collide with other uses of TXT records. It might be
567 necessary to prepend the domain part with a special prefix, e.g.
568 _rmx. So the e-mail address some.user@example.com could be mapped
569 to example.com or _rmx.example.com.
573 Mapping a full address is slightly more difficult. The @ sign must
574 be unambiguously translated, and therefore can not be simply
575 translated into a dot. The e-mail addresses some.user@example.com
576 and some@user.example.com must have different mappings. Therefore,
577 the @ sign could be translated into _rmx, implicitely assuming that
578 this is not an allowed domain name component of normal domain
579 names. Then the rightmost _rmx in the mapped DNS name always
580 corresponds to the @ sign. some.user@example.com would e translated
581 into some.user._rmx.example.com and can be covered by a wildcard
582 entry like *._rmx.example.com.
584 Character encoding and character sets are still to be discussed.
588 Unfortunately, SMTP allows empty envelope sender addresses to be
589 used for error messages. Empty sender addresses can therefore not
590 be prohibited. As observed, a significant amount of spam was sent
591 with such an empty sender address. To solve this problem, the host
592 name given in the HELO or EHLO command is taken to lookup the RMX
593 records instead. This makes sense, since such messages were
594 generated by the machine, not a human.
599 5. Mandatory entry types and their syntax
601 The entry types described in this section MUST be supported by any
602 implementation of this draft.
604 5.1. Overall structure
606 Similar to APL, an RMX record is just a concatenation of zero or
607 more RMX entries. The entries within one record form an ordered
608 rule base as commonly usual in packet filtes and firewall rulesets,
609 i. e. they are processed one ofter another until the first entry
610 matches. This entry determines the result of the query. Once a
611 matching entry is found, the RMX processing is finished.
615 Hadmut Danisch Experimental [Page 11]
617 INTERNET-DRAFT DNS RMX RR Oct 2003
620 For any domain name there should not exist more than a single RMX
621 record. Due to the structure of DNS, it is nevertheless possible to
622 have more than a single RMX record. Multiple RMX records are
623 treated as a single record consisting of the concatenation of all
624 records. While the entries in a record are ordered, the records are
625 not ordered and may be processed in arbitrary order. If the order
626 of the entries matters, it is the zone maintainer's responsibility
627 to keep those entries in a single record. For example, there are
628 negative entries, which exclude IP addresses from authorization.
629 It is important that these entries are processed before positive
630 entries giving permission to a wider address range. Since order is
631 guaranteed only within a record, corresponding negative and
632 positive entries must be put in the same record.
634 An RMX record may consist of one or more entries, where the entries
635 are separated by whitespace. An entry must not contain white space.
636 Each entry consists of an optional exclamation sign, a tag, a
637 colon, and the entry data:
639 [!] TAG : ENTRY-SPECIFIC-DATA
641 If the entry starts with an exclamation sign, the entry is negated.
642 See the entry type description below for details.
644 The TAG is the mnemonic type identifier or the decimal number of
645 the entry. The TAG is case-insensitive. It is immediately followed
648 The syntax and semantics of ENTRY-SPECIFIC-DATA depends of the the
649 entry type. See description below.
653 danisch.de. IN RMX apl:relays.rackland.de !ipv4:1.2.3.5
658 This is a primitive entry which just says that this sender address
659 will never be used as a sender address under any circumstances.
662 testdomain.danisch.de IN RMX unused:
664 5.3. IPv4 and IPv6 address ranges
666 These entry types contain a bit sequence representing a CIDR
667 address part. If that bit sequence matches the given IP address,
671 Hadmut Danisch Experimental [Page 12]
673 INTERNET-DRAFT DNS RMX RR Oct 2003
676 authorization is granted or denied, depending on the negation flag.
678 The entry is prepended with the tag "IPv4" or "IPv6". The colon is
679 followed with an IPv4 or IPv6 address in standard notation,
680 optionally followed by a slash and a mask length. If the negation
681 flag is set, then the given address range is excluded. Examples:
683 danisch.de IN RMX ipv4:213.133.101.23 ipv6:fe00::0
684 IN RMX ipv4:10.0.0.0/8 ipv6:fec0::0/16
687 (Please note that it does not make much sense to use
688 RFC1918-Addresses in RMX records, this is just to give a syntax
694 This entry type simply contains a regular DNS name, which is to be
695 resolved as a host name (fetch the A record or IPv6 equivalent). If
696 the given IP address matches the result, authorization is granted
697 or denied, depending on the negation flag. It is still to be
698 defined how to treat unresolvable entries.
700 The entry is prepended with the tag "host", followed by a colon and
701 the hostname. Examples:
703 danisch.de IN RMX host:relay.provider.de
704 IN RMX !host:badmachine.domain.de apl:relays.domain.de
706 5.4.1. Road warriors and DynDNS entries
708 Several people argued against RMX that it would break their
709 existing installation which delivers e-mail from dynamically
710 assigned IP addresses, because their IP providers didn't assign a
711 static address, or because they are a road warrior, plugging their
712 notebook in any hotel room on the world.
714 RMX provides a simple solution. If such a machine has a dynamically
715 updated DNS entry (e.g. DynDNS), all it takes is an RMX entry of
716 the hostname type pointing to this dynamic DNS entry.
718 The cleaner solution would be to deliver mail the same way as it is
719 received: If downloaded by POP from a central relay with a static
720 address, where the MX points to, then it would be a good idea to
721 deliver e-mail the same way in reverse direction. Unfortunately,
722 plain POP does not support uploading yet.
727 Hadmut Danisch Experimental [Page 13]
729 INTERNET-DRAFT DNS RMX RR Oct 2003
734 This entry type simply contains a regular DNS name, which is to be
735 resolved as an APL record index (fetch the APL record). If the
736 given IP address positively matches the APL, authorization is
737 granted. Details of the semantic (espially when the negation bit is
738 set) are still to be defined. It is still to be defined how to
739 treat unresolvable entries.
741 The entry is prepended with the tag "host", followed by a colon and
742 the hostname. Example:
744 danisch.de IN RMX apl:relays.rackland.de
748 In many cases it is desirable to cover all hosts of a given domain
749 with an RMX record without the need to duplicate the list of these
750 hosts. This entry type does it (thanks to Eric A. Hall for pointing
751 out this entry type). It contains a regular DNS name.
753 If this entry type is given, a reverse DNS query for the IP address
754 of the sending MTA is performed to find its official fully
755 qualified domain name. To prevent spoofing, this domain name is
756 accepted only if a subsequent address query to the given domain
757 name points to exactly the IP address of the sending MTA (the usual
758 procedure to verify PTR records).
760 The entry matches if the fully qualified domain name of the sending
761 MTA ends in the given domain. The negation flag works as usual.
763 The tag for this entry type is "domain". After the colon the domain
764 name is given, but might be empty, thus pointing to itself.
767 somedomain.org IN RMX domain:somedomain.org domain:provider.com
769 would authorize all machines which's hostname can be verified
770 through an PTR and A query, and which ends in "somedomain.org" or
773 With such an entry, large companies with different networks can
774 easily be covered with just a single and simple RMX entry.
775 Obviously, it requires proper PTR records.
777 As a special shortcut, the DNS name may be empty. In this case the
778 domain name of the zone itself is taken. Thus, with a very simple
783 Hadmut Danisch Experimental [Page 14]
785 INTERNET-DRAFT DNS RMX RR Oct 2003
788 somecompany.com IN RMX domain:
790 a company could authorize all machines which's IP addresses map to
791 DNS names end in somecompany.com, which applies in the majority of
797 5.7. Full Address Query
799 As described above, RMX records will in most cases apply to the
800 domain part of the sender address. In special cases it might be
801 desirable to query the RMX record for a particular address. An RMX
802 entry of the Full Address Query type may occur in a domain RMX
803 record only. It signals that the RMX record for the full address is
804 to be fetched and processed.
806 This entry type does not take arguments. The negation flag is not
807 supported. The tag is "full".
809 If such a full address query is to be performed, the mail address
810 must be mapped to a valid and non-ambiguos DNS name. This mapping
811 is still to be defined. It is not sufficient to simply replace the
812 @ with a dot, because of case sensitivity, character sets, etc. The
819 must all be mapped to different DNS entries. This entry type might
820 vanish in future versions of the draft, depending on the discussion
821 about whether to query the domain name part only or the full
824 5.8. DNS mapped authorization
826 As I learned from comments to prior versions of the draft and from
827 alternative proposals, many users wish to have a DNS mapped
828 authorization table, i. e. the client queries a DNS entry of the
829 form a.b.c.d.domain, where a.b.c.d is the sender's IP address.
830 Since people wish to have this, RMX will now include such a mapping
831 entry. The entry has a parameter giving the DNS domain name where
832 to look at. If the parameter is empty, then the same domain is
833 taken as for the RMX lookup.
835 As this is currently under construction and discussion in an IETF
839 Hadmut Danisch Experimental [Page 15]
841 INTERNET-DRAFT DNS RMX RR Oct 2003
844 group, details will be published in future versions of this draft.
848 This entry type has no parameters. It means that all those machines
849 are authorized, which are pointed to by an MX record.
851 6. Optional and experimental entry types
853 The following subsections roughly describe further entry types
854 which might not be supported by all implementations and might not
855 be allowed in all legislations. These methods might vanish in
856 future versions of the draft and are just considerations about what
857 to include in RMX and what to not include. The main purpose of this
858 section is to start discussion about such entry types.
860 The disadvantage of the following methods is that they violate the
861 basic idea of RMX, i. e. to be simple, robust, easy to implement
862 and easy to administer. I personally do not believe that it is a
863 good idea or even feasible to implement cryptography for a world
864 wide e-mail transfer network. Keep in mind that cryptographic keys
865 can be copied. If only <0.1% of cryptographic keys were revealed,
866 this completely compromises and spoils RMX. Cryptography is simply
867 the wrong tool for the problem RMX is intended to solve. I
868 nevertheless like to discuss these methods.
872 The sender is considered to be authorized if the message was
873 transmitted through SMTP and TLS, and the sender used a certificate
874 matching the fingerprint given in the RMX record.
878 This means that the receiver should perform an LDAP query for the
879 sender address (through the LDAP SRV record or given in the RMX
880 record), fetch the X.509 certificate for the sender. The sender is
881 considered to be authorized when the message was transmitted
882 through SMTP and TLS using this certificate.
884 6.3. PGP or S/MIME signature
886 It would be possible to accept a message only if it was signed with
887 PGP or S/MIME with a key which's fingerprint is given in the RMX
888 record or to be fetched from LDAP or any PGP database. This is
889 just for discussion, since it violates the idea of RMX to focus on
890 the transport, not on the content. It would also allow replay
891 attacks and not cover the envelope sender address or message
895 Hadmut Danisch Experimental [Page 16]
897 INTERNET-DRAFT DNS RMX RR Oct 2003
902 6.4. Transparent Challenge/Response
904 It would also be possible to implement a challenge-response
905 mechanism without modifying the syntax of SMTP. For example, the
906 receiving MTA could issue a challenge with it's very first greeting
907 message, the sending MTA could hide the response in the HELO
908 parameter and when the receiving MTA later learns the sender
909 envelope address, it could verify the response based on
910 informations in the RMX record.
912 6.5. SASL Challenge/Response
914 Modern SMTP implementations already include a SASL mechanisms,
915 which easily allows to plugin new authentication mechanisms. While
916 common SASL mechanisms require to use a previously shared password,
917 a new mechanism could perform a challenge response authentication
927 7.1. Alternative encoding as TXT records
929 The main objection against the prior versions of this draft was
930 that it requires a new RR entry type and upgrading all DNS servers.
932 Therefore and alternative encoding is proposed. Instead of using a
933 new RR type, the TXT record type is used to contain the RMX record.
934 The records would simply look as described in the entry type
937 _rmx.danisch.de. IN TXT "apl:relays.rackland.de"
939 To allow smooth introduction of RMX without the need to immediately
940 upgrade all DNS servers, all clients (which have to be newly
941 installed anyway) MUST support both the TXT and the RMX records. A
942 client has to perform an ANY or a TXT and a RMX query. Servers/zone
943 tables may currently use TXT entries but SHOULD use RMX entries in
951 Hadmut Danisch Experimental [Page 17]
953 INTERNET-DRAFT DNS RMX RR Oct 2003
956 7.2.1. Overall structure
958 Each entry starts with an octet containting the entry type and the
961 +---+---+---+---+---+---+---+---+------
962 | N | Entry Type Code | Parameters...
963 +---+---+---+---+---+---+---+---+------
965 N If this bit (MSB) is set, an IP address
966 matching this entry is not authorized,
967 but explicitely rejected. See entry
968 type descriptions for details.
970 Entry Type A 7bit number simply determining the entry
974 Currently, entries do not have an explicit length field, the entry
975 length is determined implicitely by the entry type. Applications
976 are required to abort if an unknown entry type is found, instead of
977 skipping unknown entries.
979 7.2.2. Record encoding
981 A RMX record is simply a concatenation of RMX entries.
983 7.2.3. Encoding of IPv4 and IPv6 address ranges
985 After the entry type tag as described above, one octet follows
986 giving the length L of the bit sequence. Then a sequence of exactly
987 as many octets follows as needed to carry L bits of information (=
990 +---+---+---+---+---+---+---+---+
991 | N | Entry Type Code (1 or 2) |
992 +---+---+---+---+---+---+---+---+
994 +---+---+---+---+---+---+---+---+
997 +---+---+---+---+---+---+---+---+
1000 7.2.4. Encoding of DNS
1002 After the entry type tag immediately follows a DNS encoded and
1003 compressed [3] domain name.
1007 Hadmut Danisch Experimental [Page 18]
1009 INTERNET-DRAFT DNS RMX RR Oct 2003
1012 +---+---+---+---+---+---+---+---+
1013 | N | Entry Type Code (3..5) |
1014 +---+---+---+---+---+---+---+---+
1016 +---+---+---+---+---+---+---+---+
1018 / Name as described in RFC1035 /
1019 +---+---+---+---+---+---+---+---+
1021 In contrast to earlier versions of this draft, the DNS name cannot
1022 be compressed, since this would cause decompression errors when a
1023 DNS server is part of the query chain which does not know this
1026 7.2.5. Encoding of unused and full query
1028 These entries do not contain parameters and does not allow the
1029 negation flag. So the encoding is quite simple:
1031 +---+---+---+---+---+---+---+---+
1032 | 0 | Entry Type Code (6 or 7)|
1033 +---+---+---+---+---+---+---+---+
1037 7.2.6. Additional Records
1039 In order to avoid the need of a second query to resolve the given
1040 host name, a DNS server should enclose the A record for that domain
1041 name in the additional section of the additional section of the DNS
1042 reply, if the server happens to be authoritative.
1044 In order to avoid the need of a second query to resolve the given
1045 host name, a DNS server should enclose the APL record for that
1046 domain name in the additional section of the additional section of
1047 the DNS reply, if the server happens to be authoritative.
1053 An RMX query must be followed by any kind of action depending on
1054 the RMX result. One action might be to reject the message. Another
1055 action might be to add a header line to the message body, thus
1056 allowing MUAs and delivery programs to filter or sort messages.
1058 In future, the RMX result might be melted into the Received: header
1063 Hadmut Danisch Experimental [Page 19]
1065 INTERNET-DRAFT DNS RMX RR Oct 2003
1068 The details of such entries are to be discussed. As a proposal the
1069 following form is suggested:
1071 X-RMX: RESULT addr ADDRESS by HOST on DATE mechanism MECHANISM
1075 RESULT is one of "Granted", "Denied", "NotInRMX", "NoRMX",
1076 "TempFail", "BadData", "Trusted".
1078 ADDRESS is the IP address of the sending machine
1080 HOST is the name of the machine performing the RMX query.
1082 DATE is the date of the query.
1084 MECHANISM is the RMX method used to authorize the sender.
1088 9. SMTP error messages
1090 If a message is rejected because of RMX records, an error message
1091 should be issued which explains the details. It is to be discussed
1092 whether new SMTP error codes are to be defined.
1095 10. Message relaying and forwarding
1097 10.1. Problem description
1099 Message forwarding and relaying means that an MTA which received an
1100 e-mail by SMTP does not deliver it locally, but resends the message
1101 - usually unchanged except for an additional Received header line
1102 and maybe the recipient's address rewritten - to the next SMTP MTA.
1103 Message forwarding is an essential functionality of e-mail
1104 transport services, for example:
1106 - Message transport from outer MX relay to the intranet
1107 - Message forwarding and Cc-ing by .forward or .procmail-alike
1109 - Mailing list processing
1110 - Message reception by mail relays with low MX priority,
1111 usually provided by third parties as a stand-by service
1112 in case of relay failure or maintenance
1113 - "Forwarding" and "Bouncing" as a MUA functionality
1115 In all these cases a message is sent by SMTP from a host which is
1119 Hadmut Danisch Experimental [Page 20]
1121 INTERNET-DRAFT DNS RMX RR Oct 2003
1124 not covered by the original sender domain's RMX records. While the
1125 RMX records would forbid accepting this message, it still must be
1126 accepted. The following subsections explain how to cope with
1129 10.2. Trusted relaying/forwarding
1131 In some cases the receiving MTA trusts the sending MTA to not fake
1132 messages and to already have checked the RMX records at message
1133 reception. As a typical example, a company might have an outer mail
1134 relay which receives messages from the Internet and checks the RMX
1135 records. This relay then forwards the messages to the different
1136 department's mail servers. It does not make sense for these
1137 department mail servers to check the RMX record, since the RMX
1138 records have already been checked and - since the message was
1139 relayed by the outer relay - always would deny the message. In this
1140 case there is a trust relationship between the department relays
1141 and the outer relay. So RMX checking is turned off for trusted
1142 relays. In this example, the department relays would not check
1143 messages from the outer relay (but for intranet security, they
1144 could still check RMX records of the other departments sub-domains
1145 to avoid internal forgery between departments).
1147 Another common example are the low-priority MX relays, which
1148 receive and cache e-mails when the high-priority relays are down.
1149 In this case, the high-priority relay would trust the low-priority
1150 relay to have verified the sender authorization and would not
1151 perform another RMX verification (which would obviously fail).
1153 When a relay forwards a message to a trusting machine, the envelope
1154 sender address should remain unchanged.
1156 10.3. Untrusted relaying/forwarding
1158 If the receiving MTA does not trust the forwarding MTA, then there
1159 is no chance to leave the sender envelope address unchanged. At a
1160 first glance this might appear impracticable, but this is
1161 absolutely necessary. If an untrusted MTA could claim to have
1162 forwarded a message from a foreign sender address, it could have
1163 forged the message as well. Spammers and forgers would just have to
1164 act as such a relay.
1166 Therefore, it is required that, when performing untrusted
1167 forwarding, the envelope sender address has to be replaced by the
1168 sender address of someone responsible for the relaying mechanism,
1169 e.g. the owner of the mailing list or the mail address of the user
1170 who's .forward caused the transmission. It is important to stress
1171 that untrusted relaying/forwarding means taking over responsibility
1175 Hadmut Danisch Experimental [Page 21]
1177 INTERNET-DRAFT DNS RMX RR Oct 2003
1180 for the message. It is the idea of RMX records to tie
1181 responsibility to message transmission. Untrusted relaying without
1182 replacing the sender address would mean to transmit without taking
1185 The disadvantage is that the original sender address is lost.
1186 Therefore, whenever a sender address replacement happens, the
1187 Received-Line must contain the old address. Many of today's MTAs
1188 already insert the envelope recipient address, but not the sender
1189 address into the Received header line. It seems reasonable to
1190 require every Received line to include both the sender and
1191 recipient address of the incoming SMTP connection.
1194 11. Security Considerations
1196 11.1. Draft specific considerations
1198 11.1.1. Authentication strength
1200 It is important to stress, that the suggested method does not
1201 provide high level security and does not completely prevent forged
1202 e-mails or spam under any circumstances. It is a robust, but not
1203 highly reliable and completely secure security mechanism. Keep in
1204 mind that it is based on DNS, and DNS is not secure today.
1205 Authorization is based on the IP address. The very same machine
1206 with the very same IP address could be authorized to send e-mail
1207 with a given sender address and sending spam at the same time.
1208 Maybe because several users are logged in. Or because several
1209 customers use the same relay of the same ISP, where one customer
1210 could use the sender address of a different customer. It is up to
1211 the ISP to prevent this or not. Machines can still be hijacked.
1212 Spammers are also domain owners. They can simply use their own
1213 domain and authorize themselves. You will always find people on the
1214 world who do not care about security and open their relays and RMX
1215 records for others to abuse them. RMX is to be considered as a
1216 very cheap and simple light weight mechanism, which can
1217 nevertheless provide a significant improvement in mail security
1218 against a certain class of attacks, until a successor of SMTP has
1219 been defined and commonly accepted.
1221 11.1.2. Where Authentication and Authorization end
1223 Previous versions of RMX records did not cover the local part of
1224 the e-mail address, i.e. what's on the left side of the @ sign.
1225 This is still to be discussed. Authentication and authorization are
1226 limited to the sending MTA's IP address. The authentication is
1227 limited to the TCP functionality, which is sufficient for light
1231 Hadmut Danisch Experimental [Page 22]
1233 INTERNET-DRAFT DNS RMX RR Oct 2003
1236 weight authentication. The RMX records authorize the IP address of
1237 the sending host only, not the particular sender of the message. So
1238 if a machine is authorized to use sender addresses of more than a
1239 single domain, the authentication scheme does not prevent that any
1240 user on this machine can send with any of these domains. RMX is not
1241 a substitute for the host security of the involved machines.
1243 The proposed authentication scheme can be seen as a "half way
1244 authentication": It does not track back an e-mail to the effective
1245 sender. It tracks only half of the way, i. e. it tracks back to the
1246 domain and it's DNS administrators who authorized that particular
1247 sender IP address to use it for sending e-mail. How the party
1248 responsible for that domain performs user authentication, whom it
1249 grants access to, how it helds people responsible for abuse, is
1250 completely left as the private business of those who are in charge
1251 of that domain. So this draft does not interfere with the domain's
1252 individual security policy or any legislation about such policies.
1253 On the other hand, the proposed authentication scheme does not give
1254 any statement about the nature and quality of the domain's security
1255 policy. This is an essential feature of the proposal: E-mail
1256 authentication must be deployed world wide, otherwise it won't do
1257 the job. Any security scheme interfering with the local
1258 legislations or the domain's security policy will not be accepted
1259 and can't effectively deployed. Therefore, the security policy must
1260 remain the domain's private business, no matter how lousy the
1263 In order to achieve this and to make use of the only existing world
1264 wide Internet directory scheme (DNS), the approach of this proposal
1265 is to just ignore the local part of the sender address (i.e. what's
1266 left of the @ part) and limit view to the domain part. After all,
1267 that's what we do anyway when delivering to a given address with
1270 11.1.3. Vulnerability of DNS
1272 DNS is an essential part of the proposed authentication scheme,
1273 since it requires any directory service, and DNS is currently the
1274 only one available. Unfortunately, DNS is vulnerable and can be
1275 spoofed and poisoned. This flaw is commonly known and weakens many
1276 network services, but for reasons beyond that draft DNS has not
1277 been significantly improved yet. After the first version of this
1278 draft, I received several comments who asked me not to use DNS
1279 because of its lack of security. I took this into consideration,
1280 but came to the conclusion that this is unfeasible: Any
1281 authentication scheme linked to some kind of symbolic identity (in
1282 this case the domain name) needs some kind of infrastructure and
1283 trusted assignment. There are basically two ways to do it: Do it
1287 Hadmut Danisch Experimental [Page 23]
1289 INTERNET-DRAFT DNS RMX RR Oct 2003
1292 yourself and trust nobody else, or let someone else do it. There
1293 are methods to do it the former way, e.g. to give someone some kind
1294 of authentication information after a first successful e-mail
1295 exchange, e.g. some kind of cookie or special e-mail address. This
1296 is certainly interesting and powerful, but it does not solve the
1297 problem on a world wide scale and is far to complicated and error
1298 prone for the average user, i. e. 99% of the users.
1300 The latter method to let someone else do the symbolic name
1301 assignment and create the authentication framework is well known.
1302 It context of public key cryptography, this is called a Public Key
1303 Infrastructure (PKI). On of the best known facts about PKIs is
1304 that, until now, we don't have any covering a significant part of
1305 the Internet. And we won't have any in near future. The complexity
1306 is far too high, it is too expensive, and it involves cooperation
1307 of every single user, which is simply unrealistic and extremely
1308 error prone. So what do we have we can use? All we have is the DNS
1309 and the Whois database. And we have countries who don't allow
1310 cryptography. So the proposal was designed to use DNS without
1311 cryptography. It does not avoid DNS because of its vulnerability,
1312 it asks for a better DNS, but accepts the DNS as it is for the
1313 moment. Currently there are two main threats caused by the DNS
1316 - A spammer/forger could spoof DNS in order to gain false
1317 authorization to send fake e-mails.
1319 - An attacker could spoof DNS in order to block delivery from
1320 authorized machines, i. e. perform a Denial of Service attack.
1322 The first one is rather unrealistic, because it would require an
1323 average spammer to poison a significant part of the DNS servers of
1324 its victims. A spammer sending messages to one million receipients
1325 would need to poison at least 1-10% which is 10,000 to 100,000
1326 receipient's DNS servers. This should be unfeasible in most cases.
1328 In contrast, the second threat is a severe one. If an attacker
1329 wanted to block messages from one company to another, he just needs
1330 to poison the recipients DNS server with a wrong RMX record in
1331 order to make the recipient's SMTP machine reject all messages. And
1332 this is feasible since the attacker needs to poison only a single
1333 DNS server. But does this make SMTP more vulnerable? No. Because
1334 the attacker can already do even more without RMX. By poisoning the
1335 sender's DNS server with wrong MX records, the attacker can also
1336 block message delivery or even redirect the messages to the
1337 attacker's machine, thus preventing any delivery error messages and
1338 furthermore getting access to the messages.
1343 Hadmut Danisch Experimental [Page 24]
1345 INTERNET-DRAFT DNS RMX RR Oct 2003
1348 As a consequence, e-mail delivery by SMTP requires a better DNS
1349 anyway. The requirements are not significantly expanded by RMX.
1351 11.1.4. Sneaking RMX attack?
1353 While writing a test implementation, a certain kind of attack came
1354 into my mind. I'm still not sure, whether this attack is possible
1355 on any DNS server, but I believe it should be mentioned:
1357 Imagine an unauthorized sender is sending a forged mail (e.g.
1358 spam). At connection time, before querying the RMX record, the
1359 receiving MTA usually performs a PTR query for the IP address of
1360 the sending MTA. If the sender has control over the authoritative
1361 name server for that particular IP address, the sender could give a
1362 normal PTR answer, but could append a wrong RMX, APL, or A record
1363 in the additional section of the query. A subsequent RMX query
1364 could receive wrong DNS data if the DNS server used by the
1365 receiving MTA accepted those forged records.
1367 11.1.5. Open SMTP relays
1369 Open SMTP relays (i.e. machines who accept any e-mail message from
1370 anyone and deliver to the world) abused by spammers are a one of
1371 the main problems of spam defense and sender backtracking. In most
1372 cases this problem just vanishes because foreign open relay
1373 machines will not be covered by the RMX records of the forged
1374 sender address. But there are two special cases:
1376 If the spammer knows about a domain which authorizes this
1377 particular machine, that domain can be used for forgery. But in
1378 this case, the IP address of the relay machine and the RMX records
1379 of the domain track back to the persons responsible. Both can be
1380 demanded to fix the relay or remove the RMX record for this
1381 machine. An open relay is a security flaw like leaving the machine
1382 open for everybody to login and send random mails from inside. Once
1383 the administrative persons refuse to solve the problem, they can be
1384 identified as spammers and held responsible.
1386 The second special case is when a domain authorizes all IP
1387 addresses by having the network 0.0.0.0/0 in the RMX/APL record. In
1388 this case, open relays don't make things worse. It's up to the
1389 recipient's MTA to reject mails from domains with loose security
1392 11.1.6. Unforged Spam
1394 This proposal does not prevent spam (which is, by the way, not yet
1395 exactly defined), it prevents forgery. Since spam is against law
1399 Hadmut Danisch Experimental [Page 25]
1401 INTERNET-DRAFT DNS RMX RR Oct 2003
1404 and violates the recipients rights, spam depends on untracability
1405 of the sender. In practice the sender forges the sender address
1406 (other cases see below). This proposal is designed to detect such
1409 However, the RMX approach is rendered ineffective, if the sender
1410 doesn't forge. If the sender uses just a normal address of it's own
1411 domain, this is just a plain, normal e-mail, which needs to be let
1412 through. Since it is up to the human's taste whether this is spam
1413 or not, there's no technical way to reliably identify this as spam.
1414 But since the sender domain is known, this domain can be
1415 blacklisted or legal steps can be gone into.
1417 11.1.7. Reliability of Whois Entries
1419 Once the RMX infrastructure gets deployed, what's the security
1420 gain? It allows to determine the domain which's DNS zone
1421 authorized the sending machine. What's that good for? There are
1422 some immediate uses of the domain name, e.g. in black- and
1423 whitelisting. But in most cases this is just the starting point of
1424 further investigations, either performed automatically before
1425 message acceptance, or manually after spam has been received and
1428 The next step after determining the domain is determining the
1429 people responsible for this domain. This can sometimes be achieved
1430 by querying the Whois databases. Unfortunately, many whois entries
1431 are useless because they are incomplete, wrong, obsolete, or in
1432 uncommon languages. Furthermore, there are several formats of
1433 address informations which make it difficult to automatically
1434 extract the address. Sometimes the whois entry identifies the
1435 provider and not the owner of the domain. Whois servers are not
1436 built for high availability and sometimes unreachable.
1438 Therefore, a mandatory standard is required about the contents and
1439 the format of whois entries, and the availability of the servers.
1440 After receiving the MAIL FROM SMTP command with the sender envelope
1441 address, the receiving MTA could check the RMX record and Whois
1442 entry. If it doesn't point to a real human, the message could be
1443 rejected and an error message like "Ask your provider to fix your
1444 Whois entry" could be issued. Obviously, domain providers must be
1445 held responsible for wrong entries. It might still be acceptable to
1446 allow anonymous domains, i. e. domains which don't point to a
1447 responsible human. But it is the receivers choice to accept e-mails
1448 from such domains or not.
1450 11.1.8. Hazards for Freedom of Speech
1455 Hadmut Danisch Experimental [Page 26]
1457 INTERNET-DRAFT DNS RMX RR Oct 2003
1460 Currently, some governments try to enforce limitations of internet
1461 traffic in order to cut unwanted content providers from the
1462 network. Some of these governments try to hide a whole country
1463 behind firewalls, others try to force Internet providers to poison
1464 DNS servers with wrong A records for web servers, e.g. one county
1465 administration in Germany tries to do so. If message reception
1466 depends on DNS entries, the same governments will try to block not
1467 only HTTP, but SMTP also.
1469 However, since most MTAs already reject messages from unresolvable
1470 domain names this is not a new threat.
1472 11.2. General Considerations about spam defense
1474 After discussing security requirements of the proposal, now the
1475 security advantages of the RMX approach over content based filters
1476 will be explained. Basically, there are three kinds of content
1479 - Those who upload the message or some digest to an external
1480 third party and ask "Is this spam"?
1482 - Those who download a set of patterns and rules from a third
1483 party and apply this set to incoming messages in order to
1484 determine whether it is spam.
1486 - Those who are independent and don't contact any third party,
1487 but try to learn themselves what is spam and what isn't.
1490 The message filters provided by some e-mail service providers are
1491 usually not a kind of their own, but a combination of the first two
1494 11.2.1. Action vs. reaction
1496 Content filters suffer from a fundamental design problem: They are
1497 late. They need to see some content of the same kind before in
1498 order to learn and to block further distribution.
1500 This works for viruses and worms, which redistribute. This doesn't
1501 work for spam, since spam is usually not redistributed after the
1502 first delivery. When the filters have learned or downloaded new
1503 pattern sets, it's too late.
1505 This proposal does not have this problem.
1507 11.2.2. Content based Denial of Service attacks
1511 Hadmut Danisch Experimental [Page 27]
1513 INTERNET-DRAFT DNS RMX RR Oct 2003
1516 All three kinds of content filters, but especially the second and
1517 the third kind are vulnerable to content based Denial of Service
1520 If some kind of third party (e.g. non-democratic government,
1521 intellectual property warriors, religious groups, military, secret
1522 services, patriots, public relation agents, etc.) wants certain
1523 contents not to be distributed, they could either poison the
1524 pattern/rule databases or feed wrong sets to particular receivers.
1526 Such pattern/rule sets are the perfect tool for censoring e-mail
1527 traffic and denial of service attacks by governments and other
1528 parties, and a similar threat are virus filters. E. g. the content
1529 industry could demand to teach all virus and spam filters to delete
1530 all e-mails containing the URL of an MP3 web server outside the
1531 legislations. Software manufacturers could try to block all e-mails
1532 containing software license keys, thus trying to make unallowed
1533 distribution more difficult. Governments could try to block
1534 distribution of unwanted informations.
1536 This proposal does not have this problem.
1539 12. Privacy Considerations
1541 (It was proposed on the 56th IETF meeting to have a privacy section
1542 in drafts and RFCs.)
1544 12.1. Draft specific considerations
1546 12.1.1. No content leaking
1548 Since the RMX approach doesn't touch the contents of a message in
1549 any way, there is obviously no way of leaking out any information
1550 about the content of the message. RMX is based solely on the
1551 envelope recipient address. However, methods to fix problems not
1552 covered by RMX might allow content leaking, e.g. if the acceptance
1553 of a message with an empty sender address requires the reference to
1554 the message id of an e-mail recently sent, this allows an attacker
1555 to verify whether a certain message was delivered from there.
1557 12.1.2. Message reception and sender domain
1559 Message delivery triggers RMX and APL requests by the recipient.
1560 Thus, the admin of the DNS server or an eavesdropper could learn
1561 that the given machine has just received a message with a sender
1562 from this address, even if the SMTP traffic itself had been
1567 Hadmut Danisch Experimental [Page 28]
1569 INTERNET-DRAFT DNS RMX RR Oct 2003
1572 However, most of today's MTAs do query the MX and A records of the
1573 domain after the MAIL FROM command, so this is not a real new
1576 12.1.3. Network structure
1578 Since RMX and its associated APL records provide a complete list of
1579 all IP addresses of hosts authorized to send messages from this
1580 address, they do reveal informations about the network structure
1581 and maybe the lifestyle of the domain owner, since a growing number
1582 of domains are owned by single persons or families. E.g. the RMX
1583 records could reveal where someone has his job or spends his time
1586 If such informations are to be kept secret, it is the user's job to
1587 not sent e-mails from there and to relay them from non-compromising
1590 12.1.4. Owner information distribution
1592 As described above, RMX depends partly on the reliability of the
1593 whois database entries. It does not make anonymous domains
1594 impossible, but it requires to keep the database entries "true", i.
1595 e. if a whois entry does not contain informations about the
1596 responsible person, this must be unambigously labeled as anonymous.
1597 It must not contain fake names and addresses to pretend a non-
1598 existing person. However, since most Internet users on the world
1599 feel extremely annoyed by spam, they will urge their MTA admin to
1600 reject messages from anonymous domains. The domain owner will have
1601 the choice to either remain anonymous but be not able to send e-
1602 mail to everyone in the world, or to be able but to reveal his
1603 identity to everyone on the world.
1605 It would be possible to provide whois-like services only to
1606 recipients of recent messages, but this would make things too
1607 complicated to be commonly adopted.
1609 12.2. General Considerations about spam defense
1611 12.2.1. Content leaking of content filters
1613 As described above in the Security chapter, there are spam filters
1614 which inherently allow leakage of the message body. Those filters
1615 upload either the message body, or in most cases just some kind of
1616 checksum to a third party, which replies whether this is to be seen
1617 as spam or not. The idea is to keep a databases of all digests of
1618 all messages. If a message is sent more often than some threshold,
1619 it is to be considered as a mass mail and therefore tagged as spam.
1623 Hadmut Danisch Experimental [Page 29]
1625 INTERNET-DRAFT DNS RMX RR Oct 2003
1628 While the digest itself does not reveal the content of the message,
1629 it perfectly reveals where a particular message has been delivered
1630 to. If a government finds just a single unwanted message, if a
1631 software manufacturer finds a single message with a stolen product
1632 license key, if someone finds a message with unpatriotic content,
1633 it takes just a single database lookup to get a list of all people
1634 who received this particular message. Content filters with digest
1635 upload are the perfect "Big Brother".
1637 12.2.2. Black- and Whitelists
1639 Some proposals against spam are based on a central database of
1640 white- or blacklisted IP addresses, Sender names, Message IDs or
1641 whatever. Again, there is a central database which learns who has
1642 received which e-mail or from which sender with every query. This
1643 allows tracking relations between persons, which is also a breach
1648 13. Deployment Considerations
1652 13.1.1. Compatibility with old mail receivers
1654 Since the suggested extension doesn't change the SMTP protocol at
1655 all, it is fully compatible with old mail receivers. They simply
1656 don't ask for the RMX records and don't perform the check.
1658 13.1.2. Compatibility with old mail senders
1660 Since the SMTP protocol is unchanged and the SMTP sender is not
1661 involved in the check, the method is fully compatible with old mail
1664 13.1.3. Compatibility with old DNS clients
1666 Since the RMX is a new RR, the existing DNS protocol and zone
1667 informations remain completely untouched.
1669 If RMX is provided as a TXT record instead, it must be ensured that
1670 no other software is misinterpreting this entry.
1672 13.1.4. Compatibility with old DNS servers
1674 Full compatibility: If the server does not support RMX records, RMX
1675 in TXT records can be used.
1679 Hadmut Danisch Experimental [Page 30]
1681 INTERNET-DRAFT DNS RMX RR Oct 2003
1684 13.2. Enforcement policy
1686 Obviously, for reasons of backward compatibility and smooth
1687 introduction of this scheme, RMX records can't be required
1688 immediately. Domains without RMX records must temporarily be
1689 treated the same way as they are treated right now, i.e. e-mail
1690 must be accepted from anywhere. But once the scheme becomes
1691 sufficiently widespread, mail relays can start to refuse e-mails
1692 with sender addresses from domains without RMX records, thus
1693 forcing the owner of the domain to include a statement of
1694 authorization into the domain's zone table. Domain owners will
1695 still be free to have an RMX record with a network and mask
1696 0.0.0.0/0, i.e. to allow e-mails with that domain from everywhere.
1697 On the other hand, mail receivers will be free to refuse mails from
1698 domains without RMX records or RMX records which are too loose.
1699 Advanced MTAs might have a configuration option to set the maximum
1700 number of IP addresses authorized to use a domain. E-mails from a
1701 domain, which's RMX records exceed this limit, would be rejected.
1702 For example, a relay could reject e-mails from domains which
1703 authorize more than 8 IP addresses. That allows to accept e-mails
1704 only from domains with a reasonable security policy.
1708 14. General considerations about fighting spam
1710 Is there a concise technical solution against spam? Yes.
1712 Will it be deployed? Certainly not.
1714 Why not? Because of the strong non-technical interests of several
1715 parties against a solution to the problem, as described below.
1716 Since these are non-technical reasons, they might be beyond the
1717 scope of such a draft. But since they are the main problems that
1718 prevent fighting spam, it is unavoidable to address them. This
1719 chapter exists temporarily only and should support the discussion
1720 of solutions. It is not supposed to be included in a later RFC.
1722 14.1. The economical problem
1724 As has been recently illustrated in the initial session of the
1725 IRTF's Anti Spam Research Group (ASRG) on the 56th IETF meeting,
1726 sending spam is a business with significant revenues.
1728 But a much bigger business is selling Anti-Spam software. This is a
1729 billion dollar market, and it is rapidly growing. Any simple and
1730 effective solution against spam would defeat revenues and drive
1731 several companies into bankrupt, would make consultants jobless.
1735 Hadmut Danisch Experimental [Page 31]
1737 INTERNET-DRAFT DNS RMX RR Oct 2003
1740 Therefore, spam is essential for the Anti-Spam business. If there
1741 is no spam, then no Anti-Spam software can be sold, similar to the
1742 Anti-Virus business. There are extremely strong efforts to keep
1743 this market growing. Viruses, Worms, and now spam are just perfect
1744 to keep this market alive: It is not sufficient to just buy a
1745 software. Databases need to be updated continuously, thus making
1746 the cash flow continuously. Have a single, simple, and permanent
1747 solution to the problem and - boom - this billion dollar market is
1750 That's one of the reasons why people are expected to live with
1751 spam. They have to live with it to make them buy Anti-Spam
1752 software. Content filters are perfect products to keep this market
1755 14.2. The POP problem
1757 Another problem is the history of mail delivery. Once upon a time,
1758 there used to be very few SMTP relays which handled the e-mail
1759 traffic of all the world, and everybody was happy with that. Then
1760 odd things like Personal Computers, which are sometimes switched
1761 off, portable computers, dynamicly assigned IP addresses, IP access
1762 from hotel rooms, etc. was invented, and people became unhappy,
1763 because SMTP does not support delivery to such machines. To make
1764 them happy again, the Post Office Protocol[4] was invented, which
1765 turned the last part of message delivery from SMTP's push style
1766 into a pull style, thus making virtually every computer on the
1767 world with any random IP address a potential receiver of mails for
1768 random domains. Unfortunately, only receiving e-mail was covered,
1769 but sending e-mail was left to SMTP.
1771 The result is that today we have only very few SMTP relays pointed
1772 to by MX records, but an extreme number of hosts sending e-mail
1773 with SMTP from any IP address with sender addresses from any
1774 domain. Mail delivery has become very asymmetric. Insecurity,
1775 especially forgeability, has become an essential part of mail
1778 That problem could easily be fixed: Use protocols which allow
1779 uploading of messages to be delivered. If a host doesn't receive
1780 messages by SMTP, it shouldn't deliver by SMTP. Mail delivery
1781 should go the same way back that incoming mail went in. This is
1782 not a limitation to those people on the road who plug their
1783 portable computer in any hotel room's phone plug and use any
1784 provider. If there is a POP server granting download access from
1785 anywhere, then the same server should be ready to accept uploading
1786 of outgoing messages.
1791 Hadmut Danisch Experimental [Page 32]
1793 INTERNET-DRAFT DNS RMX RR Oct 2003
1796 But as I saw from the comments on the first version of this draft,
1797 people religiously insist on sending e-mail with their domain from
1798 any computer with any IP address in the world, e.g. when visiting a
1799 friend using her computer. It appears to be impossible to convince
1800 people that stopping mail forgery requires every one of them to
1803 14.3. The network structure problem
1805 A subsequent problem is that many organisations failed to implement
1806 a proper mail delivery structure and heavily based their network on
1807 this asymmetry. I received harsh comments from Universities who
1808 were unable to give their network a good structure. While they do
1809 have a central mail relay for incoming mail to the universities
1810 domain, they developed a structure where every member of the
1811 University randomly sends e-mails with that University's domain as
1812 a sender address from home or everywhere in the world with any
1813 dynamically assigned IP address from any provider. So this domain
1814 is to be used from every possible IP address on earth, and they are
1815 unable to operate any authentication scheme. Furthermore, they were
1816 unable to understand that such a policy heavily supports spam and
1817 that they have to expect that people don't accept such e-mails
1818 anymore once they become blacklisted.
1820 As long as organisations insist on having such policies, spammers
1821 will have a perfect playground.
1823 14.4. The mentality problem
1825 Another problem is the mentality of many internet users of certain
1826 countries. I received harsh comments from people who strongly
1827 insisted on the freedom to send any e-mail with any sender address
1828 from anywhere, and who heavily refused any kind of authentication
1829 step or any limitation, because they claimed that this would
1830 infringe their constitutional "Freedom of speech". They are
1831 undeviatingly convinced that "Freedom of speech" guarantees their
1832 right to talk to everybody with any sender address, and that is has
1833 to be kept the recipient's own problem to sort out what he doesn't
1834 want to read - on the recipient's expense.
1836 It requires a clear statement that the constitutional "Freedom of
1837 Speech" does not cover molesting people with unsolicited e-mail
1838 with forged sender address.
1840 14.5. The identity problem
1842 How does one fight against mail forgery? With authentication. What
1843 is authentication? In simple words: Making sure that the sender's
1847 Hadmut Danisch Experimental [Page 33]
1849 INTERNET-DRAFT DNS RMX RR Oct 2003
1852 real identity meets the recipients idea of who is the sender, based
1853 on the sender address which came with the message.
1855 What is identity? It is the main problem. Several countries have
1856 different ideas of "identity", which turn out to be somehow
1857 incompatible. In some countries people have identity cards and
1858 never change their name and birthday. Identities are created by
1859 human birth, not by identity changes. Other countries do not have
1860 such a tight idea about identity. People's temporary identity is
1861 based on nothing more than a driving license and a social security
1862 number. With this background, it is virtually impossible to create
1863 a trustworthy PKI covering all Internet users. I learned that it is
1864 extremely difficult to convince some people to give up random e-
1867 14.6. The multi-legislation problem
1869 Many proposals about fighting spam are feasible under certain
1870 legislations only, and are inacceptable under some of the
1871 legislations. But a world wide applicable method is required.
1872 That's why the approach to ask everone on the world to sign
1873 messages with cryptographic keys is not feasible.
1876 Implementation and further Information
1878 Further informations and a test implementation are available at
1880 http://www.danisch.de/work/security/antispam.html
1881 http://www.danisch.de/software/rmx/
1884 Additional informations and a technology overview are also
1887 http://www.mikerubel.org/computers/rmx_records/
1894 1. S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev-
1895 els," RFC 2119 (March 1997).
1897 2. J. Klensin, "Simple Mail Transfer Protocol," RFC 2821 (April 2001).
1903 Hadmut Danisch Experimental [Page 34]
1905 INTERNET-DRAFT DNS RMX RR Oct 2003
1908 3. P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION,"
1909 RFC 1035 (November 1987).
1911 4. J. Myers, M. Rose, "Post Office Protocol - Version 3," RFC 1939
1930 Phone: ++49-721-843004 or ++49-351-4850477
1931 E-Mail: rfc@danisch.de
1935 Please send comments to rfc@danisch.de.
1939 This drafts expires on Apr 1, 2004.
1959 Hadmut Danisch Experimental [Page 35]
projects / FreeBSD / releng / 7.2.git / blob