idnits 2.17.1 draft-danisch-dns-rr-smtp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 77 longer pages, the longest (page 44) being 73 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 89 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 511: '... in this section MUST be supported by ...' RFC 2119 keyword, line 875: '...nstalled anyway) MUST support both the...' RFC 2119 keyword, line 877: '...rrently use TXT entries but SHOULD use...' RFC 2119 keyword, line 2278: '... in this section MUST be supported by ...' RFC 2119 keyword, line 2642: '...nstalled anyway) MUST support both the...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 620 has weird spacing: '...itively match...' == Line 2387 has weird spacing: '...itively match...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2004) is 7286 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 2040 looks like a reference -- Missing reference section? '2' on line 2656 looks like a reference -- Missing reference section? '3' on line 2386 looks like a reference -- Missing reference section? '4' on line 2503 looks like a reference -- Missing reference section? '5' on line 2536 looks like a reference -- Missing reference section? '6' on line 2590 looks like a reference -- Missing reference section? '7' on line 2799 looks like a reference -- Missing reference section? '8' on line 2833 looks like a reference -- Missing reference section? '9' on line 3398 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Hadmut Danisch 3 Category: Experimental May 2004 4 Expires: Nov 1, 2004 6 The RMX DNS RR and method for lightweight SMTP sender authorization 7 draft-danisch-dns-rr-smtp-04.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Abstract 33 This memo introduces a new authorization scheme for SMTP e-mail 34 transport. It is designed to be a simple and robust protection 35 against e-mail fraud, spam, and worms. It is based solely on 36 organisational security mechanisms and does not require but still 37 allow use of cryptography. This memo also focuses on security and 38 privacy problems and requirements in context of spam defense. 40 This document is part of the LMAP work of the Anti-Spam Research 41 Group (ASRG) of the IRTF. 43 Table of Contents 45 1. Problem and threat description . . . . . . . . . . . . . . . . . 4 46 1.1. Mail sender forgery . . . . . . . . . . . . . . . . . . . 4 47 1.1.1 Definition of sender forgery . . . . . . . . . . . 4 48 1.1.2 Spam . . . . . . . . . . . . . . . . . . . . . . . 5 49 1.1.3 E-Mail Worms . . . . . . . . . . . . . . . . . . . 5 50 1.1.4 E-Mail spoofing and fraud . . . . . . . . . . . . . 5 51 1.2. Indirect damage caused by forgery . . . . . . . . . . . . 6 52 1.3. Technical problem analysis . . . . . . . . . . . . . . . . 6 53 1.4. Shortcomings of cryptographical approaches . . . . . . . . 7 54 2. A DNS based sender address verification . . . . . . . . . . . . 8 55 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 2.2. Envelope vs. header sender address . . . . . . . . . . . . 9 57 2.3. Domain part vs. full sender address . . . . . . . . . . . 10 58 3. Mapping of E-Mail addresses to DNS names . . . . . . . . . . . . 12 59 3.1. Domain part only . . . . . . . . . . . . . . . . . . . . . 12 60 3.2. Full address . . . . . . . . . . . . . . . . . . . . . . . 12 61 3.3. Empty address . . . . . . . . . . . . . . . . . . . . . . 12 62 4. Mandatory entry types and their syntax . . . . . . . . . . . . . 13 63 4.1. Overall structure . . . . . . . . . . . . . . . . . . . . 13 64 4.2. Unused . . . . . . . . . . . . . . . . . . . . . . . . . . 14 65 4.3. IPv4 and IPv6 address ranges . . . . . . . . . . . . . . . 14 66 4.4. DNS Hostnames and Dynamic IP addresses . . . . . . . . . . 14 67 4.5. APL Reference . . . . . . . . . . . . . . . . . . . . . . 15 68 4.6. Domain Member . . . . . . . . . . . . . . . . . . . . . . 15 69 4.7. Full Address Query . . . . . . . . . . . . . . . . . . . . 16 70 4.8. MX reference . . . . . . . . . . . . . . . . . . . . . . . 17 71 5. Optional and experimental entry types . . . . . . . . . . . . . 18 72 5.1. TLS fingerprint . . . . . . . . . . . . . . . . . . . . . 18 73 5.2. TLS and LDAP . . . . . . . . . . . . . . . . . . . . . . . 18 74 5.3. PGP or S/MIME signature . . . . . . . . . . . . . . . . . 18 75 5.4. Transparent Challenge/Response . . . . . . . . . . . . . . 18 76 5.5. SASL Challenge/Response . . . . . . . . . . . . . . . . . 19 77 6. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 78 6.1. RMX Records . . . . . . . . . . . . . . . . . . . . . . . 20 79 6.1.1 Overall structure . . . . . . . . . . . . . . . . . 20 80 6.1.2 Record encoding . . . . . . . . . . . . . . . . . . 20 81 6.1.3 Encoding of IPv4 and IPv6 address ranges . . . . . 20 82 6.1.4 Encoding of DNS . . . . . . . . . . . . . . . . . . 21 83 6.1.5 Encoding of unused and full address query . . . . . 21 84 6.1.6 Additional Records . . . . . . . . . . . . . . . . 21 85 6.2. Alternative encoding as TXT records . . . . . . . . . . . 21 86 7. Message Headers . . . . . . . . . . . . . . . . . . . . . . . . 23 87 8. SMTP error messages . . . . . . . . . . . . . . . . . . . . . . 23 88 9. Message relaying and forwarding . . . . . . . . . . . . . . . . 24 89 9.1. Problem description . . . . . . . . . . . . . . . . . . . 24 90 9.2. Trusted relaying/forwarding . . . . . . . . . . . . . . . 24 91 9.3. Untrusted relaying/forwarding . . . . . . . . . . . . . . 25 92 10. Further development and improvements of RMX . . . . . . . . . . 26 93 10.1. Separate RMX records for address types . . . . . . . . . 26 94 10.2. SCAF - Simple Caller Authorization Framework . . . . . . 26 95 10.3. RMX++ . . . . . . . . . . . . . . . . . . . . . . . . . . 27 96 11. Security Considerations . . . . . . . . . . . . . . . . . . . . 30 97 11.1. Draft specific considerations . . . . . . . . . . . . . . 30 98 11.1.1 Authentication strength . . . . . . . . . . . . . 30 99 11.1.2 Where Authentication and Authorization end . . . . 30 100 11.1.3 Vulnerability of DNS . . . . . . . . . . . . . . . 31 101 11.1.4 Sneaking RMX attack? . . . . . . . . . . . . . . 32 102 11.1.5 Open SMTP relays . . . . . . . . . . . . . . . . . 33 103 11.1.6 Unforged Spam . . . . . . . . . . . . . . . . . . 33 104 11.1.7 Reliability of Whois Entries . . . . . . . . . . . 33 105 11.1.8 Hazards for Freedom of Speech . . . . . . . . . . 34 106 11.2. General Considerations about spam defense . . . . . . . . 34 107 11.2.1 Action vs. reaction . . . . . . . . . . . . . . . 35 108 11.2.2 Content based Denial of Service attacks . . . . . 35 109 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 37 110 12.1. Draft specific considerations . . . . . . . . . . . . . . 37 111 12.1.1 No content leaking . . . . . . . . . . . . . . . . 37 112 12.1.2 Message reception and sender domain . . . . . . . 37 113 12.1.3 Network structure . . . . . . . . . . . . . . . . 37 114 12.1.4 Owner information distribution . . . . . . . . . . 37 115 12.2. General Considerations about spam defense . . . . . . . . 38 116 12.2.1 Content leaking of content filters . . . . . . . . 38 117 12.2.2 Black- and Whitelists . . . . . . . . . . . . . . 38 118 13. Deployment Considerations . . . . . . . . . . . . . . . . . . . 39 119 13.1. Compatibility . . . . . . . . . . . . . . . . . . . . . . 39 120 13.1.1 Compatibility with old mail receivers . . . . . . 39 121 13.1.2 Compatibility with old mail senders . . . . . . . 39 122 13.1.3 Compatibility with old DNS clients . . . . . . . . 39 123 13.1.4 Compatibility with old DNS servers . . . . . . . . 39 124 13.2. Enforcement policy . . . . . . . . . . . . . . . . . . . 39 125 14. General considerations about fighting spam . . . . . . . . . . 41 126 14.1. The economical problem . . . . . . . . . . . . . . . . . 41 127 14.2. The POP problem . . . . . . . . . . . . . . . . . . . . . 41 128 14.3. The network structure problem . . . . . . . . . . . . . . 42 129 14.4. The mentality problem . . . . . . . . . . . . . . . . . . 43 130 14.5. The identity problem . . . . . . . . . . . . . . . . . . 43 131 14.6. The multi-legislation problem . . . . . . . . . . . . . . 43 132 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 133 Draft History . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 134 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 44 135 1. Problem and threat description 137 1.1. Mail sender forgery 139 The amount of e-mails with forged sender addresses has dramatically 140 increased. As a consequence, damages and annoyances caused by such 141 e-mails increased as well. In the majority of examined e-mails the 142 domain name of the envelope sender address was forged, and the e- 143 mail was sent from an IP address which does not belong to a network 144 used by the actual owner of the domain. 146 1.1.1. Definition of sender forgery 148 As discussions, comments to prior drafts of this RFC, and different 149 approaches to stop forgery showed, different perceptions of "mail 150 forgery" exist. For example, there are mechanisms to verify e-mail 151 addresses for mailing lists, web servers, or to stop spam, which do 152 send a message with a random number to the given address and expect 153 the user to send a reply. Here, someone is considered to be 154 allowed to use a particular e-mail address, if and only if he is 155 able to receive messages sent to this address, and is able to reply 156 to such a message. While this definition appears to be quite 157 plausible and natural, it can't be used for a simple technical 158 solution. Sending back a challenge and expecting a reply is simply 159 too much overhead and time delay, and not every authorized sender 160 is able and willing to reply (e.g. because he went offline or is 161 not a human). 163 Within the scope of this memo, sender forgery means that the 164 initiator of an e-mail transfer (which is the original sender in 165 contrast to relays) uses a sender address which he was not 166 authorized to use. Being authorized to use an address means that 167 the owner (administrator) of the internet domain has given 168 permission, i.e. agrees with the use of the address by that 169 particular sender. This memo will cover both the permission of the 170 full e-mail address and the domain part only for simplicity. 172 Within context of Internet and SMTP, the sender address usually 173 occurs twice, once as the envelope sender address in SMTP [1], and 174 once as the address given in the mail header [2]. While the 175 following considerations apply to both addresses in principle, it 176 is important to stress that both addresses have distinct semantics 177 and are not necessarily the same. The envelope address identifies 178 the initiator of the transport, while the header identifies the 179 author of the message content. Since this memo deals with the 180 message transport only and completely ignores the message content, 181 the method should naturally be applied to the envelope sender 182 address. However, this is currently under discussion in the ASRG 183 and the IETF working groups. 185 1.1.2. Spam 187 A common and well known problem is the dramatic increase of 188 unsolicited e-mail, commonly called "spam". Again, the majority of 189 examined e-mails had forged sender addresses. The abused domains 190 were mainly those of common webmailers as hotmail or yahoo, or 191 well-known companies. 193 Unfortunately, there is no accurate definition of spam available 194 yet, and neither are there concise technical criterions to filter 195 or block spam with technical mechanisms. There are efforts to 196 design content based filters, but these filters are expensive in 197 calculation time (and sometimes money), and they do not reliably 198 produce predictable results. They usually give false positives 199 and/or require user interaction. Content filters in general suffer 200 from a design problem described later in this memo. Therefore, 201 this proposal does not use the content based approach to block 202 spam. 204 As analysis of spam messages showed, most of spam messages were 205 sent with forged envelope sender addresses. This has mainly three 206 reasons. The first reason is, that spam senders usually do not 207 want to be contacted by e-mail. The second reason is, that they do 208 not want to be blacklisted easily. The third reason is, that spam 209 is or is going to be unlawful in many countries, and the sender 210 does not want to reveal his identity. Therefore, spam is 211 considered to be a special case of sender forgery throughout this 212 memo. 214 1.1.3. E-Mail Worms 216 Another example of sender forgery is the reproduction of e-mail 217 worms. Most worms use random sender addresses, e.g. the addresses 218 found in mailboxes on the infected system. In most cases analyzed 219 by the author, the e-mails sent by the reproduction process can 220 also be categorized as forged, since the infected system would 221 under normal circumstances not be authorized to send e-mails with 222 such e-mail addresses. So forgery does not require a malicious 223 human to be directly involved. This memo covers any kind of e-mail 224 sender address forgery, included those generated by malicious 225 software. 227 1.1.4. E-Mail spoofing and fraud 229 Forging e-mail sender addresses for fraud or other kinds of 230 deception ("human engineering") has also dramatically increased. 232 There are many known cases where single or mass e-mails were sent 233 with false sender addresses, pretending to come from service 234 providers, software manufacturers etc., and asking the receiver to 235 install any software or patches, or to reply with any confidential 236 information. The Internet is increasingly becoming a scene of 237 crime, and so are it's services, including e-mail. It is obvious 238 that crime based on e-mail is eased by the fact that SMTP allows 239 arbitrary sender address spoofing. 241 1.2. Indirect damage caused by forgery 243 As observed by the author, mass mails and worms with forged sender 244 addresses can cause a severe damage for the real owner of the 245 abused sender addresses. If a sender A is sending an e-mail to the 246 receiver B, pretending to be C by using a sender address of C's 247 domain, then C has currently no chance to prevent this, since C's 248 machines and software are not involved in any way in the delivery 249 process between A and B. B will nevertheless send any error 250 messages (virus/spam alert, "no such user", etc.) to C, erroneously 251 assuming that the message was sent by C. The author found several 252 cases where this flood of error messages caused a severe denial of 253 service or a dramatic increase of costs, e.g. when C was 254 downloading the e-mail through expensive or low bandwidth 255 connections (e.g. modem or mobile phones), or where disk space was 256 limited. The author examined mass mailings, where several tens or 257 hundreds of thousands of messages were sent to recipients around 258 the world, where these messages caused only annoyance. But since 259 several thousands of these recipient addresses were invalid or 260 didn't accept the message, the owner of the DNS domain which was 261 abused by the spammer to forge sender addresses was flooded for 262 several months with thousands of error messages, jamming the e-mail 263 system and causing severe costs and damages. 265 As a consequence, when A sends a message to B, pretending to be C, 266 there must be any mechanism to allow C to inform B about the fact, 267 that A is not authorized to use C as a sender address. This is 268 what this memo is about. 270 1.3. Technical problem analysis 272 Why does e-mail forgery actually exist? Because of the lack of the 273 Simple Mail Transfer Protocol SMTP[1] to provide any kind of sender 274 authentication, authorization, or verification. SMTP was designed 275 at a time where security was not an issue. Efforts have been made 276 to block forged e-mails by requiring the domain part of the sender 277 address to be resolvable. This method provides protection from e- 278 mails with non-existing sender domains, and indeed, for some time 279 it blocked most spam e-mails. However, since attackers and spam 280 senders began to abuse existing domain names, this method was 281 rendered ineffective. 283 1.4. Shortcomings of cryptographical approaches 285 At a first glance, the problem of sender address forgery might 286 appear to be solvable with cryptographical methods such as 287 challenge response authentications or digital signatures. A deeper 288 analysis shows that only a small, closed user group could be 289 covered with cryptographical methods. Any method used to stop spam 290 forgery must be suitable to detect forgery not only for a small 291 number of particular addresses, but for all addresses on the world. 292 An attacker does not need to know the secrets belonging to a 293 particular address. For him it is sufficient to be able to forge 294 any address and thus to know any secret key. Since there are 295 several hundreds of millions of users, there will always be a large 296 amount of compromised keys, thus spoiling any common cryptographic 297 method. Furthermore, cryptography has proven to be far too 298 complicated and error prone to be commonly administered and 299 reliably implemented. Many e-mail and DNS administrators do not 300 have the knowledge required to deal with cryptographic mechanisms. 301 The most important requirement for a world wide applicable spam 302 protection is simplicity. Many legislations do not allow the 303 general deployment of cryptography and a directory service with 304 public keys. For these reasons, cryptography is applicable only to 305 a small and closed group of users, but not to all participants of 306 the e-mail service. 308 After all, after more than 20 years of Public Key Cryptography, 309 there is still no common Public Key Infrastructure, there is still 310 not enough adequate crypto software available, neither hardware 311 devices, and existing crypto software is far from being robust and 312 free of severe bugs. Cryptography cannot be expected to solve the 313 spam problem in the foreseeable future. 315 2. A DNS based sender address verification 317 2.1. Overview 319 To gain an improvement in e-mail authenticity while keeping as much 320 SMTP compatibility as possible, a method is suggested which doesn't 321 change SMTP at all. 323 The idea is to store the information about how to verify who is 324 authorized to transmit e-mails through SMTP with a particular 325 sender address (either full address or - for simplicity - only the 326 domain part of the address) in a directory service. The internet's 327 directory service is currently DNS. To be precise, the 328 verification consists of two steps, the classical pair of 329 authentication and authorization: 331 The first step is the authentication. While several methods are 332 possible to perform authentication (see below), the most important 333 and robust method is the verification of the sender's IP address. 334 This is done implicitely by TCP/IP and the TCP sequence number. 335 The authenticated identity is the IP address. It has to be 336 stressed that this TCP/IP "authentication" is a weak authentication 337 and vulnerable to several attacks. It is nevertheless sufficient 338 for this purpose, especially for blocking spam. It doesn't take 339 any implementation and it doesn't cost: It is already there, it is 340 a functionality of TCP/IP. An incoming SMTP connection based on 341 TCP/IP already carries the sender's IP address without any 342 modification of SMTP. See below (section Entry types) for more 343 details about authentication methods. 345 The second step is the authorization. It is based on the identity 346 given by the previous authentication step, e.g. the IP address of 347 the originator of the incoming SMTP connection, and on the 348 envelope sender address. The mechanism proposed in this memo 349 answers the question "Is that particular sender (IP address,...) 350 allowed to send with that sender address" by querying and 351 processing authorization records stored in a directory service, 352 which is DNS. 354 When the sender has issued the "MAIL FROM:" SMTP command, the 355 receiving mail transfer agent (MTA) can - and modern MTAs do - 356 perform some authorization checks, e.g. run a local rulebase or 357 check whether the sender domain is resolvable. 359 The suggested method is to let the DNS server for the sender domain 360 provide informations about who - this means for example which IP 361 address - is authorized to use an address or a domain as a part of 362 it. After receiving the "MAIL FROM:" SMTP command, the receiving 363 MTA can verify, whether e. g. the IP address of the sending MTA is 364 authorized to send mails with this domain name. Therefore, a list 365 of entries with authorized IP addresses or other descriptions is 366 provided by the authoritative DNS server of that domain. The entry 367 types are described in the subsequent chapters. Some of these 368 entry types are 370 - An IPv4 or IPv6 network address and mask 371 - A fully qualified domain name referring to an A record 372 - A fully qualified domain name referring to an APL record 374 RMX records of these types would look like this: 376 somedomain.de. IN RMX ipv4:10.0.0.0/8 377 rmxtest.de. IN RMX host:relay.anyprovider.com 378 danisch.de. IN RMX apl:relays.rackland.de 379 relays.rackland.de. IN APL 1:213.133.101.23/32 1:1.2.3.0/24 381 where the machine with the example address 213.133.101.23 and the 382 machines in the example subnet 1.2.3.0/24 are the only machines 383 allowed to send e-mails with an envelope sender address of domain 384 danisch.de. Since the APL records do not necessarily belong to the 385 same domain or zone table as the RMX records, this easily allows to 386 refer to APL records defined by someone else, e.g. the internet 387 access or server hosting provider, thus reducing administrative 388 overhead to a minimum. In the example given above, the domain 389 danisch.de and several other domains are hosted by the service 390 provider Rackland. So if the relay structure of Rackland is 391 modified, only the zone of rackland.de needs to be updated. The 392 domain owners don't need to care about such details. 394 2.2. Envelope vs. header sender address 396 Questions were raised why the proposed mechanism is based on the 397 envelope sender address, and not on the sender address given in the 398 message header. Technically, both can be used. Actually, it makes 399 sense to use the envelope address. 401 In common, the header sender address identifies the author of the 402 content, while the envelope sender tells who caused the 403 transmission. The approach proposed in this memo is transmission 404 based, not content based. We can not authorize the author of a 405 message if we don't have contact with him, if the message does not 406 already contain a signature. In contrast, the sending MTA is 407 linked to an IP address which can be used for authentication. This 408 mechanism might not be very strong, but it is available and 409 sufficient to solve today's e-mail security problems. 411 Some people argued that it is the header address and not the sender 412 address, which is displayed in common mail readers (MUAs), and 413 where the receiver believes the mail to come from. That's true, 414 but it doesn't help. There are many cases where the header sender 415 differs from the envelope sender for good reasons (see below in the 416 consequences chapter for the discussion about relaying). Relaying, 417 mailing lists etc. require to replace the sender address used for 418 RMX. If this were the header address, the message header would 419 have to be modified. This is undesirable. 421 2.3. Domain part vs. full sender address 423 Early draft versions of this memo were limited to the domain part 424 of the sender address. The first reason is that it is common and 425 MX-like, to lookup only the domain part of an e-mail address in 426 DNS. The second reason is, that it was left to the private 427 business of the domain administration to handle details of user 428 verification. The idea was that the domain administration takes 429 care to verify the left part of an e-mail address with an arbitrary 430 method of their individual taste. RMX was originally designed to 431 ignore the left part of the address and to expect the domain 432 administration to take over responsibility for enforcing their 433 policy. If, e.g., a spam message arrived and passed the RMX 434 mechanism, it is known to be authorized by the domain 435 administration and they can be blamed, no matter what is on the 436 left side of the sender address - it's their private problem what 437 happens on the left side of the @. By far the most of the comments 438 to prior draft versions of this memo agreed with that. A few 439 comments asked for a finer granularity. 441 And indeed, there is no technical reason against a finer 442 granularity. All it takes is a mapping from a given envelope 443 sender address to a DNS name, and the RMX lookup for that 444 particular e-mail address could be done instead of a lookup for the 445 domain part only. However, to my knowledge, most domain 446 administrators would not like to provide an RMX entry for every 447 single e-mail address. In many cases, this would also overload DNS 448 servers. 450 It is to be discussed how to cover both views. One method could be 451 to query the full address, and if no RMX records were found to 452 query the domain part only. A different approach would be to query 453 the domain part only, and if it's RMX record contains a special 454 entry, then a new query for the full address is triggered. A third 455 way would be to always query the full address and to leave the 456 problem to the wildcard mechanism of DNS. 458 A completely different approach to allow authorization with full 459 address and even much finer granularity is the RMX++ proposal 460 mentioned in the future development section below. 462 3. Mapping of E-Mail addresses to DNS names 464 To perform the RMX query, a mapping is needed from E-Mail addresses 465 to DNS fully qualified domain names. In other words: A function is 466 needed which tells for every incoming e-mail where in DNS to look 467 for authorization records. 469 This chapter is only a rough outline. Details are currently under 470 discussion in the ASRG and IETF working groups. 472 3.1. Domain part only 474 Mapping of the domain part is trivial, since the domain part of an 475 e-mail address itself is a valid DNS name and does not need 476 translation. It might be nevertheless desirable to distinguish the 477 RMX entries from other entries, depending of the encoding of the 478 records. If the RMX entries are encoded in TXT record types, they 479 might collide with other uses of TXT records. It might be 480 necessary to prepend the domain part with a special prefix, e.g. 481 _rmx. So the e-mail address some.user@example.com could be mapped 482 to example.com or _rmx.example.com. 484 3.2. Full address 486 Mapping a full address is slightly more difficult. The @ symbol 487 must be unambiguously translated, and therefore can not be simply 488 translated into a dot. The e-mail addresses some.user@example.com 489 and some@user.example.com must have different mappings. Therefore, 490 the @ symbol could be translated into _rmx, implicitely assuming 491 that this is not an allowed domain name component of normal domain 492 names. Then the rightmost _rmx in the mapped DNS name always 493 corresponds to the @ symbol. some.user@example.com would be 494 translated into some.user._rmx.example.com and can be covered by a 495 wildcard entry like *._rmx.example.com. 497 Character encoding and character sets are still to be discussed. 499 3.3. Empty address 501 Unfortunately, SMTP allows empty envelope sender addresses to be 502 used for error messages. Empty sender addresses can therefore not 503 be prohibited. As observed, a significant amount of spam was sent 504 with such an empty sender address. To solve this problem, the host 505 name given in the HELO or EHLO command could be used instead to 506 lookup the RMX records. This makes sense, since such messages were 507 generated by the machine, not a human. 509 4. Mandatory entry types and their syntax 511 The entry types described in this section MUST be supported by all 512 implementations of this memo. 514 4.1. Overall structure 516 Similar to APL, an RMX record is just a concatenation of zero or 517 more RMX entries. The entries within one record form an ordered 518 rule base as commonly usual in packet filtes and firewall rulesets, 519 i. e. they are processed one ofter another until the first entry 520 matches. This entry determines the result of the query. Once a 521 matching entry is found, the RMX processing is finished. 523 For any domain name there should not exist more than a single RMX 524 record. Due to the structure of DNS, it is nevertheless possible 525 to have more than a single RMX record. Multiple RMX records are 526 treated as a single record consisting of the concatenation of all 527 records. While the entries in a record are ordered, the records 528 are not ordered and may be processed in arbitrary order. If the 529 order of the entries matters, it is the zone maintainer's 530 responsibility to keep those entries in a single record. For 531 example, there are negative entries, which exclude IP addresses 532 from authorization. It is important that these entries are 533 processed before positive entries giving permission to a wider 534 address range. Since order is guaranteed only within a record, 535 corresponding negative and positive entries must be put in the same 536 record. 538 An RMX record may consist of one or more entries, where the entries 539 are separated by whitespace. An entry must not contain white 540 space. Each entry consists of an optional exclamation sign, a tag, 541 a colon, and the entry data: 543 [!] TAG : ENTRY-SPECIFIC-DATA 545 If the entry starts with an exclamation sign, the entry is negated. 546 See the entry type description below for details. 548 The TAG is the mnemonic type identifier or the decimal number of 549 the entry. The TAG is case-insensitive. It is immediately 550 followed by a colon. 552 The syntax and semantics of ENTRY-SPECIFIC-DATA depends of the the 553 entry type. See description below. 555 Example: 557 danisch.de. IN RMX apl:relays.rackland.de !ipv4:1.2.3.5 558 ipv4:1.2.3.0/24 560 4.2. Unused 562 This is a primitive entry which just says that this sender address 563 will never be used as a sender address under any circumstances. 564 Example: 566 testdomain.danisch.de IN RMX unused: 568 4.3. IPv4 and IPv6 address ranges 570 These entry types contain a bit sequence representing a CIDR 571 address part. If that bit sequence matches the given IP address, 572 authorization is granted or denied, depending on the negation flag. 574 The entry is prepended with the tag "IPv4" or "IPv6". The colon is 575 followed with an IPv4 or IPv6 address in standard notation, 576 optionally followed by a slash and a mask length. If the negation 577 flag is set, then the given address range is excluded. Examples: 579 danisch.de IN RMX ipv4:213.133.101.23 ipv6:fe00::0 580 IN RMX ipv4:10.0.0.0/8 ipv6:fec0::0/16 581 IN RMX !ipv4:1.2.3.4 583 (Please note that it does not make much sense to use 584 RFC1918-Addresses in RMX records, this is just to give a syntax 585 example.) 587 4.4. DNS Hostnames and Dynamic IP addresses 589 This entry type simply contains a regular DNS name, which is to be 590 resolved as a host name (fetch the A record or IPv6 equivalent). 591 If the given IP address matches the result, authorization is 592 granted or denied, depending on the negation flag. 594 The entry is prepended with the tag "host", followed by a colon and 595 the hostname. Examples: 597 danisch.de IN RMX host:relay.provider.de 598 IN RMX !host:badmachine.domain.de apl:relays.domain.de 600 Several people argued against RMX that it would break their 601 existing installation which delivers e-mail from dynamically 602 assigned IP addresses, because their IP providers didn't assign a 603 static address, or because they are road warriors, plugging their 604 notebook in any hotel room on the world. 606 RMX provides a simple solution: If such a machine has a dynamically 607 updated DNS entry (e.g. DynDNS), all it takes is an RMX entry of 608 the hostname type pointing to this dynamic DNS entry. 610 The cleaner solution would be to deliver mail the same way as it is 611 received: If downloaded by POP from a central relay with a static 612 address, where the MX points to, then it would be a good idea to 613 deliver e-mail the same way in reverse direction. Unfortunately, 614 plain POP does not support uploading yet. 616 4.5. APL Reference 618 This entry type simply contains a regular DNS name, which is to be 619 resolved as an APL record [3] index (fetch the APL record). If 620 the given IP address positively matches the APL, authorization is 621 granted. Details of the semantic (espially when the negation bit 622 is set) are still to be defined. It is still to be defined how to 623 treat unresolvable entries. 625 The entry is prepended with the tag "host", followed by a colon and 626 the hostname. Example: 628 danisch.de IN RMX apl:relays.rackland.de 630 4.6. Domain Member 632 In many cases it is desirable to cover all hosts of a given domain 633 with an RMX record without the need to duplicate the list of these 634 hosts. This entry type does it (thanks to Eric A. Hall for 635 pointing out this entry type). It contains a regular DNS name. 637 If this entry type is given, a reverse DNS query for the IP address 638 of the sending MTA is performed to find its official fully 639 qualified domain name. To prevent spoofing, this domain name is 640 accepted only if a subsequent address query to the given domain 641 name points to exactly the IP address of the sending MTA (the usual 642 procedure to verify PTR records). 644 The entry matches if the fully qualified domain name of the sending 645 MTA ends in the given domain. The negation flag works as usual. 647 The tag for this entry type is "domain". After the colon the 648 domain name is given, but might be empty, thus pointing to itself. 649 Example: 651 somedomain.org IN RMX domain:somedomain.org domain:provider.com 653 would authorize all machines which's hostname can be verified 654 through an PTR and A query, and which ends in "somedomain.org" or 655 "provider.com". 657 With such an entry, large companies with different networks can 658 easily be covered with just a single and simple RMX entry. 659 Obviously, it requires proper PTR records. 661 As a special shortcut, the DNS name may be empty. In this case the 662 domain name of the zone itself is taken. Thus, with a very simple 663 entry of the type 665 somecompany.com IN RMX domain: 667 a company could authorize all machines which's IP addresses map to 668 DNS names end in somecompany.com, which applies in the majority of 669 companies. 671 Thus, a simple entry of the form 673 @ IN RMX domain: 675 would be a good starting point for company networks and would in 676 most cases allow easy and simple RMX configuration if the network 677 can't be described with a simple network mask. 679 4.7. Full Address Query 681 As described above, RMX records will in most cases apply to the 682 domain part of the sender address. In special cases it might be 683 desirable to query the RMX record for a particular address. An RMX 684 entry of the Full Address Query type may occur in a domain RMX 685 record only. It signals that the RMX record for the full address 686 is to be fetched and processed. 688 This entry type does not take arguments. The negation flag is not 689 supported. The tag is "full". 691 If such a full address query is to be performed, the mail address 692 must be mapped to a valid and non-ambiguos DNS name. This mapping 693 is still to be defined. It is not sufficient to simply replace the 694 @ with a dot, because of case sensitivity, character sets, etc. 695 The e-mail addresses 697 john.doe@example.org 698 John.Doe@example.org 699 john@doe.example.org 701 must all be mapped to different DNS entries. A better approach is 702 RMX++ (see below). 704 4.8. MX reference 706 This entry type has no parameters. It means that all those 707 machines are authorized, which are pointed to by an MX record. 709 Example: 711 danisch.de. IN RMX MX: 713 would simply allow all machines receiving mails for danisch.de 714 (i.e. the MX machines) to deliver as well. 716 5. Optional and experimental entry types 718 The following subsections roughly describe further experimental 719 entry types. These methods are just considerations about what to 720 include in RMX and what to not include. The main purpose of this 721 section is to start a discussion about such entry types. 723 The disadvantage of the following methods is that they violate the 724 basic idea of RMX, i. e. to be simple, robust, easy to implement 725 and easy to administer. The author does not believe that it is a 726 good idea or even feasible to implement cryptography for a world 727 wide e-mail transfer network. Keep in mind that cryptographic keys 728 can be copied. Even if only around 0.01% of the cryptographic keys 729 are stolen, this still compromises and spoils RMX. Cryptography is 730 simply the wrong tool for the problem RMX is intended to solve. It 731 is nevertheless to be discussed. 733 5.1. TLS fingerprint 735 The sender is considered to be authorized if the message was 736 transmitted through SMTP and TLS[4], and the sender used a 737 certificate matching the fingerprint given in the RMX record. 739 5.2. TLS and LDAP 741 The receiver could perform an LDAP query for the sender address 742 (through the LDAP SRV record or given in the RMX record), fetch the 743 X.509 certificate for the sender. The sender is considered to be 744 authorized when the message was transmitted through SMTP and TLS 745 using this certificate. 747 5.3. PGP or S/MIME signature 749 It would be possible to accept a message only if it was signed with 750 PGP or S/MIME with a key which's fingerprint is given in the RMX 751 record or to be fetched from LDAP or any PGP database. This is 752 just for discussion, since it violates the idea of RMX to focus on 753 the transport, not on the content. It would also allow replay 754 attacks and not cover the envelope sender address or message 755 header. 757 5.4. Transparent Challenge/Response 759 It would also be possible to implement a challenge-response 760 mechanism without modifying the syntax of SMTP. For example, the 761 receiving MTA could issue a challenge with it's very first greeting 762 message, the sending MTA could include the response in the HELO or 763 EHLO parameter and when the receiving MTA later learns the sender 764 envelope address, it could verify the response based on entries in 765 the RMX record. 767 5.5. SASL Challenge/Response 769 Modern SMTP implementations already include a SASL[5] mechanism, 770 which easily allows to plugin new authentication mechanisms. While 771 common SASL mechanisms require to use a previously shared password, 772 a new mechanism could perform a challenge response authentication 773 as a SASL method. 775 6. Encoding 777 6.1. RMX Records 779 6.1.1. Overall structure 781 Each entry starts with an octet containing the entry type and the 782 negation flag: 784 +---+---+---+---+---+---+---+---+------ 785 | N | Entry Type Code | Parameters... 786 +---+---+---+---+---+---+---+---+------ 788 N If this bit (MSB) is set, an IP address 789 matching this entry is not authorized, 790 but explicitely rejected. See entry 791 type descriptions for details. 793 Entry Type A 7bit number simply determining the entry 794 type. 796 Currently, entries do not have an explicit length field, the entry 797 length is determined implicitely by the entry type. Applications 798 are required to abort if an unknown entry type is found, instead of 799 skipping unknown entries. 801 6.1.2. Record encoding 803 A RMX record is simply a concatenation of RMX entries. 805 6.1.3. Encoding of IPv4 and IPv6 address ranges 807 After the entry type tag as described above, one octet follows 808 giving the length L of the bit sequence. Then a sequence of 809 exactly as many octets follows as needed to carry L bits of 810 information (= trunc((L+7)/8) ). 812 +---+---+---+---+---+---+---+---+ 813 | N | Entry Type Code (1 or 2) | 814 +---+---+---+---+---+---+---+---+ 815 | Length Field L | 816 +---+---+---+---+---+---+---+---+ 817 | Bit Field | 818 / ((L+7)/8) Octets / 819 +---+---+---+---+---+---+---+---+ 821 6.1.4. Encoding of DNS 823 After the entry type tag immediately follows a DNS encoded[6] 824 domain name. 826 +---+---+---+---+---+---+---+---+ 827 | N | Entry Type Code (3..5) | 828 +---+---+---+---+---+---+---+---+ 829 | Length Field L | 830 +---+---+---+---+---+---+---+---+ 831 | Encoded DNS | 832 / Name as described in RFC1035 / 833 +---+---+---+---+---+---+---+---+ 835 In contrast to earlier draft versions of this memo, the DNS name 836 cannot be compressed, since this would cause decompression errors 837 when a DNS server which does not know this particular RR type is 838 part of the query chain. 840 6.1.5. Encoding of unused and full address query 842 These entries do not contain parameters and does not allow the 843 negation flag. So the encoding is quite simple: 845 +---+---+---+---+---+---+---+---+ 846 | 0 | Entry Type Code (6 or 7)| 847 +---+---+---+---+---+---+---+---+ 849 6.1.6. Additional Records 851 In order to avoid the need of a second query to resolve the given 852 host name, a DNS server should enclose the A record for that domain 853 name in the additional section of the additional section of the DNS 854 reply, if the server happens to be authoritative. 856 In order to avoid the need of a second query to resolve the given 857 host name, a DNS server should enclose the APL record for that 858 domain name in the additional section of the additional section of 859 the DNS reply, if the server happens to be authoritative. 861 6.2. Alternative encoding as TXT records 863 The main objection against the prior versions of this draft was 864 that it requires a new RR entry type and upgrading all DNS servers. 866 Therefore and alternative encoding is proposed. Instead of using a 867 new RR type, the TXT record type is used to contain the RMX record. 868 The records would simply look as described in the entry type 869 chapters above, e.g. 871 _rmx.danisch.de. IN TXT "apl:relays.rackland.de" 873 To allow smooth introduction of RMX without the need to immediately 874 upgrade all DNS servers, all clients (which have to be newly 875 installed anyway) MUST support both the TXT and the RMX records. A 876 client has to perform an ANY or a TXT and a RMX query. 877 Servers/zone tables may currently use TXT entries but SHOULD use 878 RMX entries in future. 880 7. Message Headers 882 An RMX query must be followed by any kind of action depending on 883 the RMX result. One action might be to reject the message. 884 Another action might be to add a header line to the message body, 885 thus allowing MUAs and delivery programs to filter or sort 886 messages. 888 In future, the RMX result might be melted into the Received: header 889 line [2]. 891 The details of such entries are to be discussed. As a proposal the 892 following form is suggested: 894 X-RMX: RESULT addr ADDRESS by HOST on DATE mechanism MECHANISM 896 where 898 RESULT is one of "Granted", "Denied", "NotInRMX", "NoRMX", 899 "TempFail", "BadData", "Trusted". 901 ADDRESS is the IP address of the sending machine 903 HOST is the name of the machine performing the RMX query. 905 DATE is the date of the query. 907 MECHANISM is the RMX method used to authorize the sender. 909 8. SMTP error messages 911 If a message is rejected because of RMX records, an error message 912 should be issued which explains the details. It is to be discussed 913 whether new SMTP error codes are to be defined. Error messages 914 should be verbose to make debugging of configuration errors easy. 916 9. Message relaying and forwarding 918 9.1. Problem description 920 Message forwarding and relaying means that an MTA which received an 921 e-mail by SMTP does not deliver it locally, but resends the message 922 - usually unchanged except for an additional Received header line 923 and maybe the recipient's address rewritten - to another SMTP MTA. 924 Message forwarding is an essential functionality of e-mail 925 transport services, for example: 927 - Message transport from outer MX relay to the intranet 928 - Message forwarding and Cc-ing by .forward or .procmail-alike 929 mechanisms 930 - Mailing list processing 931 - Message reception by mail relays with low MX priority, 932 usually provided by third parties as a stand-by service 933 in case of relay failure or maintenance 934 - "Forwarding" and "Bouncing" as a MUA functionality 936 In all of these cases a message is sent by SMTP from a host which 937 is not covered by the original sender domain's RMX records. While 938 the RMX records would forbid accepting this message, it still must 939 be accepted. The following subsections explain how to cope with 940 relaying. 942 9.2. Trusted relaying/forwarding 944 In some cases the receiving MTA trusts the sending MTA to not fake 945 messages and to already have checked the RMX records at message 946 reception. As a typical example, a company might have an outer 947 mail relay which receives messages from the Internet and checks the 948 RMX records. This relay then forwards the messages to the several 949 department's mail servers. It does not make sense for these 950 department mail servers to check the RMX records, because the RMX 951 records have already been checked and because they would always 952 reject messages, since the relay is not covered by the originator's 953 RMX records. In this case there is a trust relationship between 954 the department relays and the outer relay. So RMX checking is 955 turned off for trusted relays. In this example, the department 956 relays would not check messages from the outer relay (but for 957 intranet security, they could still check RMX records of the other 958 departments sub-domains to avoid internal forgery between 959 departments). 961 Another common example are the low-priority MX relays, which 962 receive and cache e-mails when the high-priority relays are down. 963 In this case, the high-priority relay would trust the low-priority 964 relay to have verified the sender authorization and would not 965 perform another RMX verification (which would obviously fail). 967 When a relay forwards a message to a trusting machine, the envelope 968 sender address should remain unchanged. 970 9.3. Untrusted relaying/forwarding 972 If the receiving MTA does not trust the forwarding MTA, then there 973 is no chance to leave the sender envelope address unchanged. At a 974 first glance this might appear impracticable, but this is 975 absolutely necessary. If an untrusted MTA could claim to have 976 forwarded a message from a foreign sender address, it could have 977 forged the message as well. Spammers and forgers would just have 978 to act as such a relay. 980 Therefore, it is required that, when performing untrusted 981 forwarding, the envelope sender address has to be replaced by the 982 sender address of someone responsible for the relaying mechanism, 983 e.g. the owner of the mailing list or the mail address of the user 984 who's forwarding mechanism caused the transmission. It is 985 important to stress that untrusted relaying/forwarding means taking 986 over responsibility for the message. It is the idea of RMX records 987 to tie responsibility to message transmission. Untrusted relaying 988 without replacing the sender address would mean to transmit without 989 taking responsibility. 991 The disadvantage is that the original sender address is lost. 992 Therefore, whenever a sender address replacement happens, the 993 Received-Line must contain the old address. Many of today's MTAs 994 already insert the envelope recipient address, but not the sender 995 address into the Received header line. It seems reasonable to 996 require every Received line to include both the sender and 997 recipient address of the incoming SMTP connection. 999 10. Further development and improvements of RMX 1001 This RFC is intended to be close to the earlier RMX drafts for 1002 historical reasons. Therefore, the further development and 1003 improvements are not made "in place" but described in this new 1004 chapter. 1006 10.1. Separate RMX records for address types 1008 In earlier draft versions of this memo there was only one RMX 1009 record covering all possible identity classes provided by the 1010 authentication step, e.g. IPv4 and IPv6 addresses were described by 1011 the same RMX record. 1013 This does not make sense and unnecessarily inflates the RMX 1014 records. Since the receiving MTA knows the identity class at query 1015 time, separate RMX records can be provided for each supported 1016 identity class, e.g. different RMX records for IPv4 and IPv6 1017 addresses. 1019 So RMX records could look like 1021 _ipv4._rmx.danisch.de IN RMX ipv4:213.133.101.23 1022 _ipv6._rmx.danisch.de IN RMX ipv6:fec0::0/16 1024 10.2. SCAF - Simple Caller Authorization Framework 1026 Fraud, spam, worms, spoofing are not limited to SMTP only. Other 1027 internet protocols like news transfer, chat and instant messaging, 1028 and even non-internet protocols can be protected against spoofing 1029 with RMX. It could also become a simple, password-less caller 1030 identification mechanism for protocols like HTTP or FTP. For 1031 example, a web browser could provide a user address similar to an 1032 e-mail address as a HTTP [7] cookie, in a new request header entry 1033 type, or as a password-less HTTP authentication header. 1035 Imagine there is a vendor's web server providing web pages 1036 available for employees of a particular company only (e.g. software 1037 upgrades for a customer). The customer could be required to 1038 provide an RMX-like record describing it's network which allows the 1039 web server to limit access based on the given user address and the 1040 RMX record for this application. (It can be understood as a kind 1041 of external firewall rule. Even firewalls and proxies could 1042 support it.) 1044 To distinguish records for different applications, the records must 1045 be stored at different locations in DNS, e.g. 1047 _ipv4._smtp._rmx.danisch.de IN RMX ipv4:213.133.101.23 1048 _ipv4._http._rmx.danisch.de IN RMX host:homeoffice.danisch.de 1050 would restrict access to web servers with "hadmut@danisch.de" to 1051 the IP address pointed to by the A record of homeoffice.danisch.de 1052 (which can be a dynamically assigned address). 1054 10.3. RMX++ 1056 RMX has restrictions and might not be applicable or desirable in 1057 all cases due to it's inflexible record types, it's nature to 1058 reveal the domain's network structure, and limitations of DNS. The 1059 domain owner would always be limited to those entry types commonly 1060 defined. 1062 To overcome these restrictions, the successor RMX++ significantly 1063 differs from RMX. With RMX++, the query is split into two distinct 1064 steps. In a first step, the receiving MTA takes the domain name of 1065 the sender address to query DNS as with RMX. But instead of an RMX 1066 record, the MTA queries an A record, an SRV record [8], and a TXT 1067 record. 1069 The A or SRV records are then used to locate a server for the 1070 second step. The TXT record contains a URL pattern. A default 1071 pattern is used in absence of the TXT record. The pattern contains 1072 macros which are to be expanded, e.g. substituted with the server 1073 address, the mail sender address, the calling MTA's IP address, 1074 message ID, content type etc. The MTA then fetches the RMX record 1075 found at that URL. The preferred protocol type is HTTP or HTTPS, 1076 but other protocols could be used as well. Even DNS and LDAP 1077 queries can be described in URLs. 1079 In general, there are three types of RMX records: In the first 1080 case, the RMX record is a static one and stored as a file on the 1081 web server. In the second case, it is dynamically generated by the 1082 web server (e.g. through a CGI program). In the third case, the 1083 MTA passes required information to the server and the server 1084 replies with "Allow" or "Reject". The receiving MTA does query and 1085 handle all three types the very same way. 1087 This method has several advantages: 1089 - No need for a new DNS RR type. DNS servers don't need to 1090 be upgraded. 1092 - Easier to administer: Today, every domain owner is 1093 able to put a file on a web site. Helper programs run on 1094 the web server will help to generate the RMX records with 1095 easy and foolproof user interfaces. In contrast, DNS zone 1096 tables are more difficult and not as easy available for 1097 modification for everyone at any time. 1099 - There is no size limit for the record as with DNS. The 1100 RMX record does not need to be split into several 1101 DNS records and stitched together. The encoding does not 1102 need to be as tight as described above, and can be 1103 plain text, ASN.1, XML, etc. 1105 - Simple encryption with HTTPS 1107 - Support of full sender address verification (not just 1108 the domain part) is trivial. 1110 - Caching with HTTP proxies, caching control and expiry 1111 with HTTP headers 1113 - The RMX record can be generated dynamically on request. 1114 Large sites where thousands of users log in and out 1115 all the time (e.g. large mail service providers) 1116 can provide "fresh" records for every request without 1117 the need to update their zone table every second. 1119 Dynamic RMX records can be easily generated with CGI 1120 applications, a well known and robust mechanism. 1122 - RMX records can be smaller because they need to cover 1123 only the query sent to the server and don't need to 1124 describe the full network structure which might consist 1125 of thousands of computers. 1127 - RMX verification can be moved from the receiving MTA 1128 to the domain owner's server, because the MTA can 1129 pass all required data such as sender address, IP addresses, 1130 size, message ID, etc. as CGI parameters. It allows the 1131 domain owner to completely hide his network structure and 1132 the authorization method, and to implement any arbitrary 1133 mechanism. Just as an extreme example to point out the 1134 capability, the domain owner's server could calculate a 1135 horoscope on request and decide whether to permit or not 1136 based on whether the planet constellation promises the 1137 e-mail to be lucky. Obviously, in reality the domain 1138 owner would use some kind of database to verify the sender. 1139 The domain owner is free to implement anything. 1141 - If the domain owner chooses to use a URL with CGI parameters, 1142 to use HTTPS, or to instruct caches to not cache, the server 1143 will be queried for every single e-mail. This allows the 1144 server to limit the number of e-mails sent and to detect 1145 anomalies, e.g. that a machine has been infected by some 1146 worm or virus. 1148 11. Security Considerations 1150 11.1. Draft specific considerations 1152 11.1.1. Authentication strength 1154 It is important to stress, that the suggested method does not 1155 provide high level security and does not completely prevent forged 1156 e-mails or spam under any circumstances. It is a robust, but not 1157 highly reliable and completely secure security mechanism. Keep in 1158 mind that it is based on DNS, and DNS is not secure today. 1159 Authorization is based on the IP address. The very same machine 1160 with the very same IP address could be authorized to send e-mail 1161 with a given sender address and sending spam at the same time. 1162 Maybe because several users are logged in. Or because several 1163 customers use the same relay of the same ISP, where one customer 1164 could use the sender address of a different customer. It is up to 1165 the ISP to prevent this or not. Machines can still be hijacked. 1166 Spammers are also domain owners. They can simply use their own 1167 domain and authorize themselves. You will always find people on 1168 the world who do not care about security and open their relays and 1169 RMX records for others to abuse them. RMX is to be considered as a 1170 very cheap and simple light weight mechanism, which can 1171 nevertheless provide a significant improvement in mail security 1172 against a certain class of attacks, until a successor of SMTP has 1173 been defined and commonly accepted. 1175 11.1.2. Where Authentication and Authorization end 1177 Early versions of RMX drafts did not cover the local part of the e- 1178 mail address, i.e. what's on the left side of the @ sign. This is 1179 still to be discussed. Authentication and authorization are 1180 limited to the sending MTA's IP address. The authentication is 1181 limited to the TCP functionality, which is sufficient for light 1182 weight authentication. The RMX records authorize the IP address of 1183 the sending host only, not the particular sender of the message. 1184 So if a machine is authorized to use sender addresses of more than 1185 a single domain, the authentication scheme does not prevent that 1186 any user on this machine can send with any of these domains. RMX 1187 is not a substitute for the host security of the involved machines. 1189 The proposed authentication scheme can be seen as a "half way 1190 authentication": It does not track back an e-mail to the effective 1191 sender. It tracks only half of the way, i. e. it tracks back to 1192 the domain and it's DNS administrators who authorized that 1193 particular sender IP address to use it for sending e-mail. How the 1194 party responsible for that domain performs user authentication, 1195 whom it grants access to, how it helds people responsible for 1196 abuse, is completely left as the private business of those who are 1197 in charge of that domain. So this draft does not interfere with 1198 the domain's individual security policy or any legislation about 1199 such policies. On the other hand, the proposed authentication 1200 scheme does not give any statement about the nature and quality of 1201 the domain's security policy. This is an essential feature of the 1202 proposal: E-mail authentication must be deployed world wide, 1203 otherwise it won't do the job. Any security scheme interfering 1204 with the local legislations or the domain's security policy will 1205 not be accepted and can't effectively deployed. Therefore, the 1206 security policy must remain the domain's private business, no 1207 matter how lousy the policy might be. 1209 In order to achieve this and to make use of the only existing world 1210 wide Internet directory scheme (DNS), the approach of this proposal 1211 is to just ignore the local part of the sender address (i.e. what's 1212 left of the @ part) and limit view to the domain part. After all, 1213 that's what we do anyway when delivering to a given address with 1214 SMTP. 1216 11.1.3. Vulnerability of DNS 1218 DNS is an essential part of the proposed authentication scheme, 1219 since it requires any directory service, and DNS is currently the 1220 only one available. Unfortunately, DNS is vulnerable and can be 1221 spoofed and poisoned. This flaw is commonly known and weakens many 1222 network services, but for reasons beyond that draft DNS has not 1223 been significantly improved yet. Several commentors to previous 1224 drafts asked to not use DNS because of its lack of security. This 1225 is unfeasible: Any authentication/authorization system linked to 1226 some kind of symbolic identity (in this case the domain name) needs 1227 some kind of infrastructure and trusted assignment. There are 1228 basically two ways to do it: Do it yourself and trust nobody else, 1229 or let someone else do it. There are methods to do it the former 1230 way, e.g. to give someone some kind of authentication/authorization 1231 information after a first successful e-mail exchange, e.g. some 1232 kind of cookie or special e-mail address. This is certainly 1233 interesting and powerful, but it does not solve the problem on a 1234 world wide scale and is far to complicated and error prone for the 1235 average user, i. e. 99% of the users. 1237 The latter method to let someone else do the symbolic name 1238 assignment and create the authentication framework is well known. 1239 It context of public key cryptography, this is called a Public Key 1240 Infrastructure (PKI). One of the best known facts about PKIs is 1241 that, until now, we don't have any covering a significant part of 1242 the Internet. And we won't have any in near future. The 1243 complexity is far too high, it is too expensive, and it involves 1244 cooperation of every single user, which is simply unrealistic and 1245 extremely error prone. So what do we have we can use? All we have 1246 is the DNS and the Whois database. And we have countries who don't 1247 allow cryptography. So the proposal was designed to use DNS 1248 without cryptography. It does not avoid DNS because of its 1249 vulnerability, it asks for a better DNS, but accepts the DNS as it 1250 is for the moment. Currently there are two main threats caused by 1251 the DNS weakness: 1253 - A spammer/forger could spoof DNS in order to gain false 1254 authorization to send fake e-mails. 1256 - An attacker could spoof DNS in order to block delivery from 1257 authorized machines, i. e. perform a Denial of Service attack. 1259 The first one is rather unrealistic, because it would require an 1260 average spammer to poison a significant part of the DNS servers of 1261 its victims. A spammer sending messages to one million receipients 1262 would need to poison at least 1-10% which is 10,000 to 100,000 1263 receipient's DNS servers. This should be unfeasible in most cases. 1265 In contrast, the second threat is a severe one. If an attacker 1266 wanted to block messages from one company to another, he just needs 1267 to poison the recipients DNS server with a wrong RMX record in 1268 order to make the recipient's SMTP machine reject all messages. 1269 And this is feasible since the attacker needs to poison only a 1270 single DNS server. But does this make SMTP more vulnerable? No. 1271 Because the attacker can already do even more without RMX. By 1272 poisoning the sender's DNS server with wrong MX records, the 1273 attacker can also block message delivery or even redirect the 1274 messages to the attacker's machine, thus preventing any delivery 1275 error messages and furthermore getting access to the messages. 1277 As a consequence, e-mail delivery by SMTP requires a better DNS 1278 anyway. The requirements are not significantly expanded by RMX. 1280 11.1.4. Sneaking RMX attack? 1282 A certain kind of sneaking DNS attack could be possible. DNS and 1283 RMX implementors should take care to void it. 1285 Imagine an unauthorized sender is sending a forged mail (e.g. 1286 spam). At connection time, before querying the RMX record, the 1287 receiving MTA usually performs a PTR query for the IP address of 1288 the sending MTA. If the sender has control over the authoritative 1289 name server for that particular IP address, the sender could give a 1290 normal PTR answer, but could append a wrong RMX, APL, or A record 1291 in the additional section of the query. A subsequent RMX query 1292 could receive wrong DNS data if the DNS server used by the 1293 receiving MTA accepted those forged records. 1295 11.1.5. Open SMTP relays 1297 Open SMTP relays (i.e. machines which accept any e-mail message 1298 from anyone and deliver to the world) abused by spammers are a one 1299 of the main problems of spam defense and sender backtracking. In 1300 most cases this problem just vanishes because foreign open relay 1301 machines will not be covered by the RMX records of the forged 1302 sender address. But there are two special cases: 1304 If the spammer knows about a domain which authorizes this 1305 particular machine, that domain can be abused for forgery. But in 1306 this case, the IP address of the relay machine and the RMX records 1307 of the domain track back to the persons responsible. Both can be 1308 demanded to fix the relay or remove the RMX record for this 1309 machine. An open relay is a security flaw like leaving the machine 1310 open for everybody to login and send random mails from inside. 1311 Once the administrative persons refuse to solve the problem, they 1312 can be identified as spammers and held responsible. 1314 The second special case is when a domain authorizes all IP 1315 addresses by having the network 0.0.0.0/0 in the RMX/APL record. 1316 In this case, open relays don't make things worse. It's up to the 1317 recipient's MTA to reject mails from domains with loose security 1318 policies. 1320 11.1.6. Unforged Spam 1322 RMX does not prevent spam (which is, by the way, not yet exactly 1323 defined), it prevents forgery. Since spam is against law and 1324 violates the recipients rights, spam depends on untracability of 1325 the sender. In practice the sender forges the sender address 1326 (other cases see below). RMX is designed to detect such forgeries. 1328 However, the RMX approach is rendered ineffective, if the sender 1329 does not forge. If the sender uses just a normal address of his 1330 own domain, this is just a plain, normal e-mail, which needs to be 1331 let through. Since it is up to the human's taste whether this is 1332 spam or not, there's no technical way to reliably identify this as 1333 spam. But since the sender domain is known, this domain can be 1334 blacklisted or legal steps can be gone into. 1336 11.1.7. Reliability of Whois Entries 1338 Once the RMX infrastructure gets deployed, what's the security 1339 gain? It allows to determine the domain which's DNS zone 1340 authorized the sending machine. What's that good for? There are 1341 some immediate uses of the domain name, e.g. in black- and 1342 whitelisting. But in most cases this is just the starting point of 1343 further investigations, either performed automatically before 1344 message acceptance, or manually after spam has been received and 1345 complainted about. 1347 The next step after determining the domain is determining the 1348 people responsible for this domain. This can sometimes be achieved 1349 by querying the Whois databases. Unfortunately, many whois entries 1350 are useless because they are incomplete, wrong, obsolete, or in 1351 uncommon languages. Furthermore, there are several formats of 1352 address informations which make it difficult to automatically 1353 extract the address. Sometimes the whois entry identifies the 1354 provider and not the owner of the domain. Whois servers are not 1355 built for high availability and sometimes unreachable. 1357 Therefore, a mandatory standard is required about the contents and 1358 the format of whois entries, and the availability of the servers. 1359 After receiving the MAIL FROM SMTP command with the sender envelope 1360 address, the receiving MTA could check the RMX record and Whois 1361 entry. If it doesn't point to a real human, the message could be 1362 rejected and an error message like "Ask your provider to fix your 1363 Whois entry" could be issued. Obviously, domain providers must be 1364 held responsible for wrong entries. It might still be acceptable 1365 to allow anonymous domains, i. e. domains which don't point to a 1366 responsible human. But it is the receivers choice to accept e- 1367 mails from such domains or not. 1369 11.1.8. Hazards for Freedom of Speech 1371 Currently, some governments try to enforce limitations of internet 1372 traffic in order to cut unwanted content providers from the 1373 network. Some of these governments try to hide a whole country 1374 behind firewalls, others try to force Internet providers to poison 1375 DNS servers with wrong A records for web servers, e.g. one county 1376 administration in Germany tries to do so. If message reception 1377 depends on DNS entries, the same governments will try to block not 1378 only HTTP, but SMTP from these domains also. 1380 However, since most MTAs already reject messages from unresolvable 1381 domain names this is not a new threat. 1383 11.2. General Considerations about spam defense 1385 After discussing security requirements of the proposal, now the 1386 security advantages of the RMX approach over content based filters 1387 will be explained. Basically, there are three kinds of content 1388 filters: 1390 - Those which upload the message or some digest to an external 1391 third party and ask "Is this spam"? 1393 - Those which download a set of patterns and rules from a third 1394 party and apply this set to incoming messages in order to 1395 determine whether it is spam. 1397 - Those which are independent and don't contact any third party, 1398 but try to learn themselves what is spam and what isn't. 1400 The message filters provided by some e-mail service providers are 1401 usually not a kind of their own, but a combination of the first two 1402 kinds. 1404 11.2.1. Action vs. reaction 1406 Content filters suffer from a fundamental design problem: They are 1407 late. They need to see some content of the same kind before in 1408 order to learn and to block further distribution. 1410 This works for viruses and worms, which redistribute. This doesn't 1411 work for spam, since spam is usually not redistributed after the 1412 first delivery. When the filters have learned or downloaded new 1413 pattern sets, it's too late. 1415 RMX does not have this problem. 1417 11.2.2. Content based Denial of Service attacks 1419 All three kinds of content filters, but especially the second and 1420 the third kind are vulnerable to content based Denial of Service 1421 attacks. 1423 If some kind of third party (e.g. non-democratic government, 1424 intellectual property warriors, religious groups, military, secret 1425 services, patriots, public relation agents, etc.) wants certain 1426 contents not to be distributed, they could either poison the 1427 pattern/rule databases or feed wrong sets to particular receivers. 1429 Such pattern/rule sets are the perfect tool for censoring e-mail 1430 traffic and denial of service attacks by governments and other 1431 parties, and a similar threat are virus filters. E. g. the content 1432 industry could demand to teach all virus and spam filters to delete 1433 all e-mails containing the URL of an MP3 web server outside the 1434 legislation. Software manufacturers could try to block all e-mails 1435 containing software license keys, thus trying to make unallowed 1436 distribution more difficult. Governments could try to block 1437 distribution of unwanted information and politically incorrect 1438 speech. 1440 RMX does not have this problem. 1442 12. Privacy Considerations 1444 (It was proposed on the 56th IETF meeting to have a privacy section 1445 in drafts and RFCs.) 1447 12.1. Draft specific considerations 1449 12.1.1. No content leaking 1451 Since the RMX approach doesn't touch the contents of a message in 1452 any way, there is obviously no way of leaking out any information 1453 about the content of the message. RMX is based solely on the 1454 envelope recipient address. However, methods to fix problems not 1455 covered by RMX might allow content leaking, e.g. if the acceptance 1456 of a message with an empty sender address requires the reference to 1457 the message id of an e-mail recently sent, this allows an attacker 1458 to verify whether a certain message was delivered from there. 1460 12.1.2. Message reception and sender domain 1462 Message delivery triggers RMX and APL requests by the recipient. 1463 Thus, the admin of the DNS server or an eavesdropper could learn 1464 that the given machine has just received a message with a sender 1465 from this address, even if the SMTP traffic itself had been 1466 encrypted. 1468 However, most of today's MTAs do query the MX and A records of the 1469 domain after the MAIL FROM command, so this is not a real new 1470 threat. 1472 12.1.3. Network structure 1474 Since RMX and its associated APL records provide a complete list of 1475 all IP addresses of hosts authorized to send messages from this 1476 address, they do reveal informations about the network structure 1477 and maybe the lifestyle of the domain owner, since a growing number 1478 of domains are owned by single persons or families. E.g. the RMX 1479 records could reveal where someone has his job or spends his time 1480 at weekends. 1482 If such informations are to be kept secret, it is the user's job to 1483 not sent e-mails from there and to relay them from non-compromising 1484 IP addresses. 1486 12.1.4. Owner information distribution 1488 As described above, RMX depends partly on the reliability of the 1489 whois database entries. It does not make anonymous domains 1490 impossible, but it requires to keep the database entries "true", i. 1491 e. if a whois entry does not contain informations about the 1492 responsible person, this must be unambigously labeled as anonymous. 1493 It must not contain fake names and addresses to pretend a non- 1494 existing person. However, since most Internet users on the world 1495 feel extremely annoyed by spam, they will urge their MTA admin to 1496 reject messages from anonymous domains. The domain owner will have 1497 the choice to either remain anonymous but be not able to send e- 1498 mail to everyone in the world, or to be able but to reveal his 1499 identity to everyone on the world. 1501 It would be possible to provide whois-like services only to 1502 recipients of recent messages, but this would make things too 1503 complicated to be commonly adopted. 1505 12.2. General Considerations about spam defense 1507 12.2.1. Content leaking of content filters 1509 As described above in the Security chapter, there are spam filters 1510 which inherently allow leakage of the message body. Those filters 1511 upload either the message body, or in most cases just some kind of 1512 checksum to a third party, which replies whether this is to be seen 1513 as spam or not. The idea is to keep a databases of all digests of 1514 all messages. If a message is sent more often than some threshold, 1515 it is to be considered as a mass mail and therefore tagged as spam. 1517 While the digest itself does not reveal the content of the message, 1518 it perfectly reveals where a particular message has been delivered 1519 to. If a government finds just a single unwanted message, if a 1520 software manufacturer finds a single message with a stolen product 1521 license key, if someone finds a message with unpatriotic content, 1522 it takes just a single database lookup to get a list of all people 1523 who received this particular message. Content filters with digest 1524 upload are "Big Brother's" favourite toy. 1526 12.2.2. Black- and Whitelists 1528 Some proposals against spam are based on a central database of 1529 white- or blacklisted IP addresses, Sender names, Message IDs or 1530 whatever. Again, there is a central database which learns who has 1531 received which e-mail or from which sender with every query. This 1532 allows tracking relations between persons, which is also a breach 1533 of privacy. 1535 13. Deployment Considerations 1537 13.1. Compatibility 1539 13.1.1. Compatibility with old mail receivers 1541 Since the suggested extension doesn't change the SMTP protocol at 1542 all, it is fully compatible with old mail receivers. They simply 1543 don't ask for the RMX records and don't perform the check. 1545 13.1.2. Compatibility with old mail senders 1547 Since the SMTP protocol is unchanged and the SMTP sender is not 1548 involved in the check, the method is fully compatible with old mail 1549 senders. 1551 13.1.3. Compatibility with old DNS clients 1553 Since the RMX is a new RR, the existing DNS protocol and zone 1554 informations remain completely untouched. 1556 If RMX is provided as a TXT record instead, it must be ensured that 1557 no other software is misinterpreting this entry. 1559 13.1.4. Compatibility with old DNS servers 1561 Full compatibility: If the server does not support RMX records, RMX 1562 in TXT records can be used. 1564 13.2. Enforcement policy 1566 Obviously, for reasons of backward compatibility and smooth 1567 introduction of this scheme, RMX records can't be required 1568 immediately. Domains without RMX records must temporarily be 1569 treated the same way as they are treated right now, i.e. e-mail 1570 must be accepted from anywhere. But once the scheme becomes 1571 sufficiently widespread, mail relays can start to refuse e-mails 1572 with sender addresses from domains without RMX records, thus 1573 forcing the owner of the domain to include a statement of 1574 authorization into the domain's zone table. Domain owners will 1575 still be free to have an RMX record with a network and mask 1576 0.0.0.0/0, i.e. to allow e-mails with that domain from everywhere. 1577 On the other hand, mail receivers will be free to refuse mails from 1578 domains without RMX records or RMX records which are too loose. 1579 Advanced MTAs might have a configuration option to set the maximum 1580 number of IP addresses authorized to use a domain. E-mails from a 1581 domain, which's RMX records exceed this limit, would be rejected. 1582 For example, a relay could reject e-mails from domains which 1583 authorize more than 8 IP addresses. That allows to accept e-mails 1584 only from domains with a reasonable security policy. 1586 14. General considerations about fighting spam 1588 Is there a concise technical solution against spam? Yes. 1590 Will it be deployed? Probably not. 1592 Why not? Because of the strong non-technical interests of several 1593 parties against a solution to the problem, as described below. 1594 Since these are non-technical reasons, they might be beyond the 1595 scope of such a draft. But since they are the main problems that 1596 prevent fighting spam, it is unavoidable to address them. 1598 14.1. The economical problem 1600 As has been recently illustrated in the initial session of the 1601 IRTF's Anti Spam Research Group (ASRG) on the 56th IETF meeting, 1602 sending spam is a business with significant revenues. 1604 But a much bigger business is selling anti-spam software. This is 1605 a billion dollar market, and it is rapidly growing. Any simple and 1606 effective solution against spam would defeat revenues and drive 1607 several companies into bankrupt, would make consultants jobless. 1609 Therefore, spam is essential for the anti-spam business. If there 1610 is no spam, then no Anti-Spam software can be sold, similar to the 1611 anti-virus business. There are extremely strong efforts to keep 1612 this market growing. Viruses, Worms, and now spam are just perfect 1613 to keep this market alive: It is not sufficient to just buy a 1614 software. Databases need to be updated continuously, thus making 1615 the cash flow continuously. Have a single, simple, and permanent 1616 solution to the problem and - boom - this billion dollar market is 1617 dead. That's one of the reasons why people are expected to live 1618 with spam. They have to live with it to make them buy anti-spam 1619 software. Content filters are perfect products to keep this market 1620 alive. 1622 14.2. The POP problem 1624 Another problem is the history of mail delivery. Once upon a time, 1625 there used to be very few SMTP relays which handled the e-mail 1626 traffic of all the world, and everybody was happy with that. Then 1627 odd things like Personal Computers, which are sometimes switched 1628 off, portable computers, dynamicaly assigned IP addresses, IP 1629 access from hotel rooms, etc. was invented, and people became 1630 unhappy, because SMTP does not support delivery to such machines. 1631 To make them happy again, the Post Office Protocol[9] was invented, 1632 which turned the last part of message delivery from SMTP's push 1633 style into a pull style, thus making virtually every computer on 1634 the world with any random IP address a potential receiver of mails 1635 for random domains. Unfortunately, only receiving e-mail was 1636 covered, but sending e-mail was left to SMTP. 1638 The result is that today we have only very few SMTP relays pointed 1639 to by MX records, but an extreme number of hosts sending e-mail 1640 with SMTP from any IP address with sender addresses from any 1641 domain. Mail delivery has become very asymmetric. Insecurity, 1642 especially forgeability, has become an essential part of mail 1643 transport. 1645 That problem could easily be fixed: Use protocols which allow 1646 uploading of messages to be delivered. If a host doesn't receive 1647 messages by SMTP, it shouldn't deliver by SMTP. Mail delivery 1648 should go the same way back that incoming mail went in. This is 1649 not a limitation to those people on the road who plug their 1650 portable computer in any hotel room's phone plug and use any 1651 provider. If there is a POP server granting download access from 1652 anywhere, then the same server should be ready to accept uploading 1653 of outgoing messages. 1655 But as comments on the first draft version of this RFC showed, 1656 people religiously insist on sending e-mail with their domain from 1657 any computer with any IP address in the world, e.g. when visiting a 1658 friend using her computer. It appears to be impossible to convince 1659 people that stopping mail forgery requires every one of them to 1660 give up forging. 1662 14.3. The network structure problem 1664 A subsequent problem is that many organisations failed to implement 1665 a proper mail delivery structure and heavily based their network on 1666 this asymmetry. The author received harsh comments from 1667 Universities who were unable to give their network a reasonable 1668 structure. While they do have a central mail relay for incoming 1669 mail to the universities domain, they developed a structure where 1670 every member of the University randomly sends e-mails with that 1671 University's domain as a sender address from home or everywhere in 1672 the world with any dynamically assigned IP address from any 1673 provider. So this domain is to be used from every possible IP 1674 address on earth, and they are unable to operate any authentication 1675 scheme. Furthermore, they were unable to understand that such a 1676 policy heavily supports spam and that they have to expect that 1677 people don't accept such e-mails anymore once they become 1678 blacklisted. 1680 As long as organisations insist on having such policies, spammers 1681 will have a perfect playground. 1683 14.4. The mentality problem 1685 Another problem is the mentality of many internet users of certain 1686 countries. The author received harsh comments from people who 1687 strongly insisted on the freedom to send any e-mail with any sender 1688 address from anywhere, and who heavily refused any kind of 1689 authentication step or any limitation, because they claimed that 1690 this would infringe their constitutional "Freedom of Speech". They 1691 are undeviatingly convinced that "Freedom of Speech" guarantees 1692 their right to talk to everybody with any sender address, and that 1693 is has to be kept the recipient's own problem to sort out what he 1694 doesn't want to read - on the recipient's expense. The author 1695 learned that it is extremely difficult to convince some people to 1696 give up random e-mail sending. However, a security mechanism for 1697 the world wide mail system can never meet the taste and the 1698 requirements of every single one of all those hundreds of millions 1699 of users. 1701 It requires a clear statement that the constitutional "Freedom of 1702 Speech" does not cover molesting people with unsolicited e-mail 1703 with forged sender address. 1705 14.5. The identity problem 1707 How does one fight against mail forgery? With authentication. What 1708 is authentication? In simple words: Making sure that the sender's 1709 real identity meets the recipients idea of who is the sender, based 1710 on the sender address which came with the message. 1712 What is identity? It is the main problem. Several countries have 1713 different ideas of "identity", which turn out to be somehow 1714 incompatible. In some countries people have identity cards and 1715 never change their name and birthday. Identities are created by 1716 human birth, not by identity changes. Other countries do not have 1717 such a tight idea about identity. People's temporary identity is 1718 based on nothing more than a driving license and a social security 1719 number. With this background, it is virtually impossible to create 1720 a trustworthy PKI covering all Internet users. 1722 14.6. The multi-legislation problem 1724 Many proposals about fighting spam are feasible under certain 1725 legislations only, and are inacceptable under some of the 1726 legislations. But a world wide applicable method is required. 1727 That's why the approach to ask everone on the world to sign 1728 messages with cryptographic keys is not feasible. 1730 References 1732 1. J. Klensin, "Simple Mail Transfer Protocol," RFC 2821 (April 2001). 1734 2. P. Resnick, "Internet Message Format," RFC 2822 (April 2001). 1736 3. P. Koch, "A DNS RR Type for Lists of Address Prefixes (APL RR)," 1737 RFC 3123 (June 2001). 1739 4. T. Dierks, C. Allen, "The TLS Protocol," RFC 2246 (January 1999). 1741 5. J. Myers, "Simple Authentication and Security Layer (SASL)," RFC 1742 2222 (October 1997). 1744 6. P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION," 1745 RFC 1035 (November 1987). 1747 7. T. Berners-Lee and others, "Hypertext Transfer Protocol HTTP/1.1," 1748 RFC 2616 (June 1999). 1750 8. A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying the 1751 location of services (DNS SRV)," RFC 2782 (February 2000). 1753 9. J. Myers, M. Rose, "Post Office Protocol - Version 3," RFC 1939 1754 (May 1996). 1756 Draft History 1758 00 Dec 2002 1759 01 Apr 2003 1760 02 Jun 2003 1761 03 Oct 2003 1763 Author's Address 1765 Hadmut Danisch 1767 Tennesseeallee 58 1768 76149 Karlsruhe 1769 Germany 1771 Phone: ++49-721-843004 or ++49-351-4850477 1772 E-Mail: rfc@danisch.de 1774 Comments 1775 Please send comments to rfc@danisch.de. 1777 Expiry 1779 This drafts expires on Nov 1, 2004. 1781 Network Working Group H. Danisch 1782 Request for Comments: nnnn May 2004 1783 Category: Experimental 1785 The RMX DNS RR and method for 1786 lightweight SMTP sender authorization 1788 Status of this Memo 1790 This memo provides information for the Internet community. It does 1791 not specify an Internet standard of any kind. Distribution of this 1792 memo is unlimited. 1794 Copyright Notice 1796 Copyright (C) The Internet Society (2004). All Rights Reserved. 1798 Abstract 1800 This memo introduces a new authorization scheme for SMTP e-mail 1801 transport. It is designed to be a simple and robust protection 1802 against e-mail fraud, spam, and worms. It is based solely on 1803 organisational security mechanisms and does not require but still 1804 allow use of cryptography. This memo also focuses on security and 1805 privacy problems and requirements in context of spam defense. 1807 This document is part of the LMAP work of the Anti-Spam Research 1808 Group (ASRG) of the IRTF. 1810 Table of Contents 1812 1. Problem and threat description . . . . . . . . . . . . . . . . . 4 1813 1.1. Mail sender forgery . . . . . . . . . . . . . . . . . . . 4 1814 1.1.1 Definition of sender forgery . . . . . . . . . . . 4 1815 1.1.2 Spam . . . . . . . . . . . . . . . . . . . . . . . 5 1816 1.1.3 E-Mail Worms . . . . . . . . . . . . . . . . . . . 5 1817 1.1.4 E-Mail spoofing and fraud . . . . . . . . . . . . . 5 1818 1.2. Indirect damage caused by forgery . . . . . . . . . . . . 6 1819 1.3. Technical problem analysis . . . . . . . . . . . . . . . . 6 1820 1.4. Shortcomings of cryptographical approaches . . . . . . . . 7 1821 2. A DNS based sender address verification . . . . . . . . . . . . 8 1822 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 1823 2.2. Envelope vs. header sender address . . . . . . . . . . . . 9 1824 2.3. Domain part vs. full sender address . . . . . . . . . . . 10 1825 3. Mapping of E-Mail addresses to DNS names . . . . . . . . . . . . 12 1826 3.1. Domain part only . . . . . . . . . . . . . . . . . . . . . 12 1827 3.2. Full address . . . . . . . . . . . . . . . . . . . . . . . 12 1828 3.3. Empty address . . . . . . . . . . . . . . . . . . . . . . 12 1829 4. Mandatory entry types and their syntax . . . . . . . . . . . . . 13 1830 4.1. Overall structure . . . . . . . . . . . . . . . . . . . . 13 1831 4.2. Unused . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1832 4.3. IPv4 and IPv6 address ranges . . . . . . . . . . . . . . . 14 1833 4.4. DNS Hostnames and Dynamic IP addresses . . . . . . . . . . 14 1834 4.5. APL Reference . . . . . . . . . . . . . . . . . . . . . . 15 1835 4.6. Domain Member . . . . . . . . . . . . . . . . . . . . . . 15 1836 4.7. Full Address Query . . . . . . . . . . . . . . . . . . . . 16 1837 4.8. MX reference . . . . . . . . . . . . . . . . . . . . . . . 17 1838 5. Optional and experimental entry types . . . . . . . . . . . . . 18 1839 5.1. TLS fingerprint . . . . . . . . . . . . . . . . . . . . . 18 1840 5.2. TLS and LDAP . . . . . . . . . . . . . . . . . . . . . . . 18 1841 5.3. PGP or S/MIME signature . . . . . . . . . . . . . . . . . 18 1842 5.4. Transparent Challenge/Response . . . . . . . . . . . . . . 18 1843 5.5. SASL Challenge/Response . . . . . . . . . . . . . . . . . 19 1844 6. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1845 6.1. RMX Records . . . . . . . . . . . . . . . . . . . . . . . 20 1846 6.1.1 Overall structure . . . . . . . . . . . . . . . . . 20 1847 6.1.2 Record encoding . . . . . . . . . . . . . . . . . . 20 1848 6.1.3 Encoding of IPv4 and IPv6 address ranges . . . . . 20 1849 6.1.4 Encoding of DNS . . . . . . . . . . . . . . . . . . 21 1850 6.1.5 Encoding of unused and full address query . . . . . 21 1851 6.1.6 Additional Records . . . . . . . . . . . . . . . . 21 1852 6.2. Alternative encoding as TXT records . . . . . . . . . . . 21 1853 7. Message Headers . . . . . . . . . . . . . . . . . . . . . . . . 23 1854 8. SMTP error messages . . . . . . . . . . . . . . . . . . . . . . 23 1855 9. Message relaying and forwarding . . . . . . . . . . . . . . . . 24 1856 9.1. Problem description . . . . . . . . . . . . . . . . . . . 24 1857 9.2. Trusted relaying/forwarding . . . . . . . . . . . . . . . 24 1858 9.3. Untrusted relaying/forwarding . . . . . . . . . . . . . . 25 1859 10. Further development and improvements of RMX . . . . . . . . . . 26 1860 10.1. Separate RMX records for address types . . . . . . . . . 26 1861 10.2. SCAF - Simple Caller Authorization Framework . . . . . . 26 1862 10.3. RMX++ . . . . . . . . . . . . . . . . . . . . . . . . . . 27 1863 11. Security Considerations . . . . . . . . . . . . . . . . . . . . 30 1864 11.1. Draft specific considerations . . . . . . . . . . . . . . 30 1865 11.1.1 Authentication strength . . . . . . . . . . . . . 30 1866 11.1.2 Where Authentication and Authorization end . . . . 30 1867 11.1.3 Vulnerability of DNS . . . . . . . . . . . . . . . 31 1868 11.1.4 Sneaking RMX attack? . . . . . . . . . . . . . . 32 1869 11.1.5 Open SMTP relays . . . . . . . . . . . . . . . . . 33 1870 11.1.6 Unforged Spam . . . . . . . . . . . . . . . . . . 33 1871 11.1.7 Reliability of Whois Entries . . . . . . . . . . . 33 1872 11.1.8 Hazards for Freedom of Speech . . . . . . . . . . 34 1873 11.2. General Considerations about spam defense . . . . . . . . 34 1874 11.2.1 Action vs. reaction . . . . . . . . . . . . . . . 35 1875 11.2.2 Content based Denial of Service attacks . . . . . 35 1876 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 37 1877 12.1. Draft specific considerations . . . . . . . . . . . . . . 37 1878 12.1.1 No content leaking . . . . . . . . . . . . . . . . 37 1879 12.1.2 Message reception and sender domain . . . . . . . 37 1880 12.1.3 Network structure . . . . . . . . . . . . . . . . 37 1881 12.1.4 Owner information distribution . . . . . . . . . . 37 1882 12.2. General Considerations about spam defense . . . . . . . . 38 1883 12.2.1 Content leaking of content filters . . . . . . . . 38 1884 12.2.2 Black- and Whitelists . . . . . . . . . . . . . . 38 1885 13. Deployment Considerations . . . . . . . . . . . . . . . . . . . 39 1886 13.1. Compatibility . . . . . . . . . . . . . . . . . . . . . . 39 1887 13.1.1 Compatibility with old mail receivers . . . . . . 39 1888 13.1.2 Compatibility with old mail senders . . . . . . . 39 1889 13.1.3 Compatibility with old DNS clients . . . . . . . . 39 1890 13.1.4 Compatibility with old DNS servers . . . . . . . . 39 1891 13.2. Enforcement policy . . . . . . . . . . . . . . . . . . . 39 1892 14. General considerations about fighting spam . . . . . . . . . . 41 1893 14.1. The economical problem . . . . . . . . . . . . . . . . . 41 1894 14.2. The POP problem . . . . . . . . . . . . . . . . . . . . . 41 1895 14.3. The network structure problem . . . . . . . . . . . . . . 42 1896 14.4. The mentality problem . . . . . . . . . . . . . . . . . . 43 1897 14.5. The identity problem . . . . . . . . . . . . . . . . . . 43 1898 14.6. The multi-legislation problem . . . . . . . . . . . . . . 43 1899 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 1900 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 1901 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 44 1902 1. Problem and threat description 1904 1.1. Mail sender forgery 1906 The amount of e-mails with forged sender addresses has dramatically 1907 increased. As a consequence, damages and annoyances caused by such 1908 e-mails increased as well. In the majority of examined e-mails the 1909 domain name of the envelope sender address was forged, and the e- 1910 mail was sent from an IP address which does not belong to a network 1911 used by the actual owner of the domain. 1913 1.1.1. Definition of sender forgery 1915 As discussions, comments to prior drafts of this RFC, and different 1916 approaches to stop forgery showed, different perceptions of "mail 1917 forgery" exist. For example, there are mechanisms to verify e-mail 1918 addresses for mailing lists, web servers, or to stop spam, which do 1919 send a message with a random number to the given address and expect 1920 the user to send a reply. Here, someone is considered to be 1921 allowed to use a particular e-mail address, if and only if he is 1922 able to receive messages sent to this address, and is able to reply 1923 to such a message. While this definition appears to be quite 1924 plausible and natural, it can't be used for a simple technical 1925 solution. Sending back a challenge and expecting a reply is simply 1926 too much overhead and time delay, and not every authorized sender 1927 is able and willing to reply (e.g. because he went offline or is 1928 not a human). 1930 Within the scope of this memo, sender forgery means that the 1931 initiator of an e-mail transfer (which is the original sender in 1932 contrast to relays) uses a sender address which he was not 1933 authorized to use. Being authorized to use an address means that 1934 the owner (administrator) of the internet domain has given 1935 permission, i.e. agrees with the use of the address by that 1936 particular sender. This memo will cover both the permission of the 1937 full e-mail address and the domain part only for simplicity. 1939 Within context of Internet and SMTP, the sender address usually 1940 occurs twice, once as the envelope sender address in SMTP [1], and 1941 once as the address given in the mail header [2]. While the 1942 following considerations apply to both addresses in principle, it 1943 is important to stress that both addresses have distinct semantics 1944 and are not necessarily the same. The envelope address identifies 1945 the initiator of the transport, while the header identifies the 1946 author of the message content. Since this memo deals with the 1947 message transport only and completely ignores the message content, 1948 the method should naturally be applied to the envelope sender 1949 address. However, this is currently under discussion in the ASRG 1950 and the IETF working groups. 1952 1.1.2. Spam 1954 A common and well known problem is the dramatic increase of 1955 unsolicited e-mail, commonly called "spam". Again, the majority of 1956 examined e-mails had forged sender addresses. The abused domains 1957 were mainly those of common webmailers as hotmail or yahoo, or 1958 well-known companies. 1960 Unfortunately, there is no accurate definition of spam available 1961 yet, and neither are there concise technical criterions to filter 1962 or block spam with technical mechanisms. There are efforts to 1963 design content based filters, but these filters are expensive in 1964 calculation time (and sometimes money), and they do not reliably 1965 produce predictable results. They usually give false positives 1966 and/or require user interaction. Content filters in general suffer 1967 from a design problem described later in this memo. Therefore, 1968 this proposal does not use the content based approach to block 1969 spam. 1971 As analysis of spam messages showed, most of spam messages were 1972 sent with forged envelope sender addresses. This has mainly three 1973 reasons. The first reason is, that spam senders usually do not 1974 want to be contacted by e-mail. The second reason is, that they do 1975 not want to be blacklisted easily. The third reason is, that spam 1976 is or is going to be unlawful in many countries, and the sender 1977 does not want to reveal his identity. Therefore, spam is 1978 considered to be a special case of sender forgery throughout this 1979 memo. 1981 1.1.3. E-Mail Worms 1983 Another example of sender forgery is the reproduction of e-mail 1984 worms. Most worms use random sender addresses, e.g. the addresses 1985 found in mailboxes on the infected system. In most cases analyzed 1986 by the author, the e-mails sent by the reproduction process can 1987 also be categorized as forged, since the infected system would 1988 under normal circumstances not be authorized to send e-mails with 1989 such e-mail addresses. So forgery does not require a malicious 1990 human to be directly involved. This memo covers any kind of e-mail 1991 sender address forgery, included those generated by malicious 1992 software. 1994 1.1.4. E-Mail spoofing and fraud 1996 Forging e-mail sender addresses for fraud or other kinds of 1997 deception ("human engineering") has also dramatically increased. 1999 There are many known cases where single or mass e-mails were sent 2000 with false sender addresses, pretending to come from service 2001 providers, software manufacturers etc., and asking the receiver to 2002 install any software or patches, or to reply with any confidential 2003 information. The Internet is increasingly becoming a scene of 2004 crime, and so are it's services, including e-mail. It is obvious 2005 that crime based on e-mail is eased by the fact that SMTP allows 2006 arbitrary sender address spoofing. 2008 1.2. Indirect damage caused by forgery 2010 As observed by the author, mass mails and worms with forged sender 2011 addresses can cause a severe damage for the real owner of the 2012 abused sender addresses. If a sender A is sending an e-mail to the 2013 receiver B, pretending to be C by using a sender address of C's 2014 domain, then C has currently no chance to prevent this, since C's 2015 machines and software are not involved in any way in the delivery 2016 process between A and B. B will nevertheless send any error 2017 messages (virus/spam alert, "no such user", etc.) to C, erroneously 2018 assuming that the message was sent by C. The author found several 2019 cases where this flood of error messages caused a severe denial of 2020 service or a dramatic increase of costs, e.g. when C was 2021 downloading the e-mail through expensive or low bandwidth 2022 connections (e.g. modem or mobile phones), or where disk space was 2023 limited. The author examined mass mailings, where several tens or 2024 hundreds of thousands of messages were sent to recipients around 2025 the world, where these messages caused only annoyance. But since 2026 several thousands of these recipient addresses were invalid or 2027 didn't accept the message, the owner of the DNS domain which was 2028 abused by the spammer to forge sender addresses was flooded for 2029 several months with thousands of error messages, jamming the e-mail 2030 system and causing severe costs and damages. 2032 As a consequence, when A sends a message to B, pretending to be C, 2033 there must be any mechanism to allow C to inform B about the fact, 2034 that A is not authorized to use C as a sender address. This is 2035 what this memo is about. 2037 1.3. Technical problem analysis 2039 Why does e-mail forgery actually exist? Because of the lack of the 2040 Simple Mail Transfer Protocol SMTP[1] to provide any kind of sender 2041 authentication, authorization, or verification. SMTP was designed 2042 at a time where security was not an issue. Efforts have been made 2043 to block forged e-mails by requiring the domain part of the sender 2044 address to be resolvable. This method provides protection from e- 2045 mails with non-existing sender domains, and indeed, for some time 2046 it blocked most spam e-mails. However, since attackers and spam 2047 senders began to abuse existing domain names, this method was 2048 rendered ineffective. 2050 1.4. Shortcomings of cryptographical approaches 2052 At a first glance, the problem of sender address forgery might 2053 appear to be solvable with cryptographical methods such as 2054 challenge response authentications or digital signatures. A deeper 2055 analysis shows that only a small, closed user group could be 2056 covered with cryptographical methods. Any method used to stop spam 2057 forgery must be suitable to detect forgery not only for a small 2058 number of particular addresses, but for all addresses on the world. 2059 An attacker does not need to know the secrets belonging to a 2060 particular address. For him it is sufficient to be able to forge 2061 any address and thus to know any secret key. Since there are 2062 several hundreds of millions of users, there will always be a large 2063 amount of compromised keys, thus spoiling any common cryptographic 2064 method. Furthermore, cryptography has proven to be far too 2065 complicated and error prone to be commonly administered and 2066 reliably implemented. Many e-mail and DNS administrators do not 2067 have the knowledge required to deal with cryptographic mechanisms. 2068 The most important requirement for a world wide applicable spam 2069 protection is simplicity. Many legislations do not allow the 2070 general deployment of cryptography and a directory service with 2071 public keys. For these reasons, cryptography is applicable only to 2072 a small and closed group of users, but not to all participants of 2073 the e-mail service. 2075 After all, after more than 20 years of Public Key Cryptography, 2076 there is still no common Public Key Infrastructure, there is still 2077 not enough adequate crypto software available, neither hardware 2078 devices, and existing crypto software is far from being robust and 2079 free of severe bugs. Cryptography cannot be expected to solve the 2080 spam problem in the foreseeable future. 2082 2. A DNS based sender address verification 2084 2.1. Overview 2086 To gain an improvement in e-mail authenticity while keeping as much 2087 SMTP compatibility as possible, a method is suggested which doesn't 2088 change SMTP at all. 2090 The idea is to store the information about how to verify who is 2091 authorized to transmit e-mails through SMTP with a particular 2092 sender address (either full address or - for simplicity - only the 2093 domain part of the address) in a directory service. The internet's 2094 directory service is currently DNS. To be precise, the 2095 verification consists of two steps, the classical pair of 2096 authentication and authorization: 2098 The first step is the authentication. While several methods are 2099 possible to perform authentication (see below), the most important 2100 and robust method is the verification of the sender's IP address. 2101 This is done implicitely by TCP/IP and the TCP sequence number. 2102 The authenticated identity is the IP address. It has to be 2103 stressed that this TCP/IP "authentication" is a weak authentication 2104 and vulnerable to several attacks. It is nevertheless sufficient 2105 for this purpose, especially for blocking spam. It doesn't take 2106 any implementation and it doesn't cost: It is already there, it is 2107 a functionality of TCP/IP. An incoming SMTP connection based on 2108 TCP/IP already carries the sender's IP address without any 2109 modification of SMTP. See below (section Entry types) for more 2110 details about authentication methods. 2112 The second step is the authorization. It is based on the identity 2113 given by the previous authentication step, e.g. the IP address of 2114 the originator of the incoming SMTP connection, and on the 2115 envelope sender address. The mechanism proposed in this memo 2116 answers the question "Is that particular sender (IP address,...) 2117 allowed to send with that sender address" by querying and 2118 processing authorization records stored in a directory service, 2119 which is DNS. 2121 When the sender has issued the "MAIL FROM:" SMTP command, the 2122 receiving mail transfer agent (MTA) can - and modern MTAs do - 2123 perform some authorization checks, e.g. run a local rulebase or 2124 check whether the sender domain is resolvable. 2126 The suggested method is to let the DNS server for the sender domain 2127 provide informations about who - this means for example which IP 2128 address - is authorized to use an address or a domain as a part of 2129 it. After receiving the "MAIL FROM:" SMTP command, the receiving 2130 MTA can verify, whether e. g. the IP address of the sending MTA is 2131 authorized to send mails with this domain name. Therefore, a list 2132 of entries with authorized IP addresses or other descriptions is 2133 provided by the authoritative DNS server of that domain. The entry 2134 types are described in the subsequent chapters. Some of these 2135 entry types are 2137 - An IPv4 or IPv6 network address and mask 2138 - A fully qualified domain name referring to an A record 2139 - A fully qualified domain name referring to an APL record 2141 RMX records of these types would look like this: 2143 somedomain.de. IN RMX ipv4:10.0.0.0/8 2144 rmxtest.de. IN RMX host:relay.anyprovider.com 2145 danisch.de. IN RMX apl:relays.rackland.de 2146 relays.rackland.de. IN APL 1:213.133.101.23/32 1:1.2.3.0/24 2148 where the machine with the example address 213.133.101.23 and the 2149 machines in the example subnet 1.2.3.0/24 are the only machines 2150 allowed to send e-mails with an envelope sender address of domain 2151 danisch.de. Since the APL records do not necessarily belong to the 2152 same domain or zone table as the RMX records, this easily allows to 2153 refer to APL records defined by someone else, e.g. the internet 2154 access or server hosting provider, thus reducing administrative 2155 overhead to a minimum. In the example given above, the domain 2156 danisch.de and several other domains are hosted by the service 2157 provider Rackland. So if the relay structure of Rackland is 2158 modified, only the zone of rackland.de needs to be updated. The 2159 domain owners don't need to care about such details. 2161 2.2. Envelope vs. header sender address 2163 Questions were raised why the proposed mechanism is based on the 2164 envelope sender address, and not on the sender address given in the 2165 message header. Technically, both can be used. Actually, it makes 2166 sense to use the envelope address. 2168 In common, the header sender address identifies the author of the 2169 content, while the envelope sender tells who caused the 2170 transmission. The approach proposed in this memo is transmission 2171 based, not content based. We can not authorize the author of a 2172 message if we don't have contact with him, if the message does not 2173 already contain a signature. In contrast, the sending MTA is 2174 linked to an IP address which can be used for authentication. This 2175 mechanism might not be very strong, but it is available and 2176 sufficient to solve today's e-mail security problems. 2178 Some people argued that it is the header address and not the sender 2179 address, which is displayed in common mail readers (MUAs), and 2180 where the receiver believes the mail to come from. That's true, 2181 but it doesn't help. There are many cases where the header sender 2182 differs from the envelope sender for good reasons (see below in the 2183 consequences chapter for the discussion about relaying). Relaying, 2184 mailing lists etc. require to replace the sender address used for 2185 RMX. If this were the header address, the message header would 2186 have to be modified. This is undesirable. 2188 2.3. Domain part vs. full sender address 2190 Early draft versions of this memo were limited to the domain part 2191 of the sender address. The first reason is that it is common and 2192 MX-like, to lookup only the domain part of an e-mail address in 2193 DNS. The second reason is, that it was left to the private 2194 business of the domain administration to handle details of user 2195 verification. The idea was that the domain administration takes 2196 care to verify the left part of an e-mail address with an arbitrary 2197 method of their individual taste. RMX was originally designed to 2198 ignore the left part of the address and to expect the domain 2199 administration to take over responsibility for enforcing their 2200 policy. If, e.g., a spam message arrived and passed the RMX 2201 mechanism, it is known to be authorized by the domain 2202 administration and they can be blamed, no matter what is on the 2203 left side of the sender address - it's their private problem what 2204 happens on the left side of the @. By far the most of the comments 2205 to prior draft versions of this memo agreed with that. A few 2206 comments asked for a finer granularity. 2208 And indeed, there is no technical reason against a finer 2209 granularity. All it takes is a mapping from a given envelope 2210 sender address to a DNS name, and the RMX lookup for that 2211 particular e-mail address could be done instead of a lookup for the 2212 domain part only. However, to my knowledge, most domain 2213 administrators would not like to provide an RMX entry for every 2214 single e-mail address. In many cases, this would also overload DNS 2215 servers. 2217 It is to be discussed how to cover both views. One method could be 2218 to query the full address, and if no RMX records were found to 2219 query the domain part only. A different approach would be to query 2220 the domain part only, and if it's RMX record contains a special 2221 entry, then a new query for the full address is triggered. A third 2222 way would be to always query the full address and to leave the 2223 problem to the wildcard mechanism of DNS. 2225 A completely different approach to allow authorization with full 2226 address and even much finer granularity is the RMX++ proposal 2227 mentioned in the future development section below. 2229 3. Mapping of E-Mail addresses to DNS names 2231 To perform the RMX query, a mapping is needed from E-Mail addresses 2232 to DNS fully qualified domain names. In other words: A function is 2233 needed which tells for every incoming e-mail where in DNS to look 2234 for authorization records. 2236 This chapter is only a rough outline. Details are currently under 2237 discussion in the ASRG and IETF working groups. 2239 3.1. Domain part only 2241 Mapping of the domain part is trivial, since the domain part of an 2242 e-mail address itself is a valid DNS name and does not need 2243 translation. It might be nevertheless desirable to distinguish the 2244 RMX entries from other entries, depending of the encoding of the 2245 records. If the RMX entries are encoded in TXT record types, they 2246 might collide with other uses of TXT records. It might be 2247 necessary to prepend the domain part with a special prefix, e.g. 2248 _rmx. So the e-mail address some.user@example.com could be mapped 2249 to example.com or _rmx.example.com. 2251 3.2. Full address 2253 Mapping a full address is slightly more difficult. The @ symbol 2254 must be unambiguously translated, and therefore can not be simply 2255 translated into a dot. The e-mail addresses some.user@example.com 2256 and some@user.example.com must have different mappings. Therefore, 2257 the @ symbol could be translated into _rmx, implicitely assuming 2258 that this is not an allowed domain name component of normal domain 2259 names. Then the rightmost _rmx in the mapped DNS name always 2260 corresponds to the @ symbol. some.user@example.com would be 2261 translated into some.user._rmx.example.com and can be covered by a 2262 wildcard entry like *._rmx.example.com. 2264 Character encoding and character sets are still to be discussed. 2266 3.3. Empty address 2268 Unfortunately, SMTP allows empty envelope sender addresses to be 2269 used for error messages. Empty sender addresses can therefore not 2270 be prohibited. As observed, a significant amount of spam was sent 2271 with such an empty sender address. To solve this problem, the host 2272 name given in the HELO or EHLO command could be used instead to 2273 lookup the RMX records. This makes sense, since such messages were 2274 generated by the machine, not a human. 2276 4. Mandatory entry types and their syntax 2278 The entry types described in this section MUST be supported by all 2279 implementations of this memo. 2281 4.1. Overall structure 2283 Similar to APL, an RMX record is just a concatenation of zero or 2284 more RMX entries. The entries within one record form an ordered 2285 rule base as commonly usual in packet filtes and firewall rulesets, 2286 i. e. they are processed one ofter another until the first entry 2287 matches. This entry determines the result of the query. Once a 2288 matching entry is found, the RMX processing is finished. 2290 For any domain name there should not exist more than a single RMX 2291 record. Due to the structure of DNS, it is nevertheless possible 2292 to have more than a single RMX record. Multiple RMX records are 2293 treated as a single record consisting of the concatenation of all 2294 records. While the entries in a record are ordered, the records 2295 are not ordered and may be processed in arbitrary order. If the 2296 order of the entries matters, it is the zone maintainer's 2297 responsibility to keep those entries in a single record. For 2298 example, there are negative entries, which exclude IP addresses 2299 from authorization. It is important that these entries are 2300 processed before positive entries giving permission to a wider 2301 address range. Since order is guaranteed only within a record, 2302 corresponding negative and positive entries must be put in the same 2303 record. 2305 An RMX record may consist of one or more entries, where the entries 2306 are separated by whitespace. An entry must not contain white 2307 space. Each entry consists of an optional exclamation sign, a tag, 2308 a colon, and the entry data: 2310 [!] TAG : ENTRY-SPECIFIC-DATA 2312 If the entry starts with an exclamation sign, the entry is negated. 2313 See the entry type description below for details. 2315 The TAG is the mnemonic type identifier or the decimal number of 2316 the entry. The TAG is case-insensitive. It is immediately 2317 followed by a colon. 2319 The syntax and semantics of ENTRY-SPECIFIC-DATA depends of the the 2320 entry type. See description below. 2322 Example: 2324 danisch.de. IN RMX apl:relays.rackland.de !ipv4:1.2.3.5 2325 ipv4:1.2.3.0/24 2327 4.2. Unused 2329 This is a primitive entry which just says that this sender address 2330 will never be used as a sender address under any circumstances. 2331 Example: 2333 testdomain.danisch.de IN RMX unused: 2335 4.3. IPv4 and IPv6 address ranges 2337 These entry types contain a bit sequence representing a CIDR 2338 address part. If that bit sequence matches the given IP address, 2339 authorization is granted or denied, depending on the negation flag. 2341 The entry is prepended with the tag "IPv4" or "IPv6". The colon is 2342 followed with an IPv4 or IPv6 address in standard notation, 2343 optionally followed by a slash and a mask length. If the negation 2344 flag is set, then the given address range is excluded. Examples: 2346 danisch.de IN RMX ipv4:213.133.101.23 ipv6:fe00::0 2347 IN RMX ipv4:10.0.0.0/8 ipv6:fec0::0/16 2348 IN RMX !ipv4:1.2.3.4 2350 (Please note that it does not make much sense to use 2351 RFC1918-Addresses in RMX records, this is just to give a syntax 2352 example.) 2354 4.4. DNS Hostnames and Dynamic IP addresses 2356 This entry type simply contains a regular DNS name, which is to be 2357 resolved as a host name (fetch the A record or IPv6 equivalent). 2358 If the given IP address matches the result, authorization is 2359 granted or denied, depending on the negation flag. 2361 The entry is prepended with the tag "host", followed by a colon and 2362 the hostname. Examples: 2364 danisch.de IN RMX host:relay.provider.de 2365 IN RMX !host:badmachine.domain.de apl:relays.domain.de 2367 Several people argued against RMX that it would break their 2368 existing installation which delivers e-mail from dynamically 2369 assigned IP addresses, because their IP providers didn't assign a 2370 static address, or because they are road warriors, plugging their 2371 notebook in any hotel room on the world. 2373 RMX provides a simple solution: If such a machine has a dynamically 2374 updated DNS entry (e.g. DynDNS), all it takes is an RMX entry of 2375 the hostname type pointing to this dynamic DNS entry. 2377 The cleaner solution would be to deliver mail the same way as it is 2378 received: If downloaded by POP from a central relay with a static 2379 address, where the MX points to, then it would be a good idea to 2380 deliver e-mail the same way in reverse direction. Unfortunately, 2381 plain POP does not support uploading yet. 2383 4.5. APL Reference 2385 This entry type simply contains a regular DNS name, which is to be 2386 resolved as an APL record [3] index (fetch the APL record). If 2387 the given IP address positively matches the APL, authorization is 2388 granted. Details of the semantic (espially when the negation bit 2389 is set) are still to be defined. It is still to be defined how to 2390 treat unresolvable entries. 2392 The entry is prepended with the tag "host", followed by a colon and 2393 the hostname. Example: 2395 danisch.de IN RMX apl:relays.rackland.de 2397 4.6. Domain Member 2399 In many cases it is desirable to cover all hosts of a given domain 2400 with an RMX record without the need to duplicate the list of these 2401 hosts. This entry type does it (thanks to Eric A. Hall for 2402 pointing out this entry type). It contains a regular DNS name. 2404 If this entry type is given, a reverse DNS query for the IP address 2405 of the sending MTA is performed to find its official fully 2406 qualified domain name. To prevent spoofing, this domain name is 2407 accepted only if a subsequent address query to the given domain 2408 name points to exactly the IP address of the sending MTA (the usual 2409 procedure to verify PTR records). 2411 The entry matches if the fully qualified domain name of the sending 2412 MTA ends in the given domain. The negation flag works as usual. 2414 The tag for this entry type is "domain". After the colon the 2415 domain name is given, but might be empty, thus pointing to itself. 2416 Example: 2418 somedomain.org IN RMX domain:somedomain.org domain:provider.com 2420 would authorize all machines which's hostname can be verified 2421 through an PTR and A query, and which ends in "somedomain.org" or 2422 "provider.com". 2424 With such an entry, large companies with different networks can 2425 easily be covered with just a single and simple RMX entry. 2426 Obviously, it requires proper PTR records. 2428 As a special shortcut, the DNS name may be empty. In this case the 2429 domain name of the zone itself is taken. Thus, with a very simple 2430 entry of the type 2432 somecompany.com IN RMX domain: 2434 a company could authorize all machines which's IP addresses map to 2435 DNS names end in somecompany.com, which applies in the majority of 2436 companies. 2438 Thus, a simple entry of the form 2440 @ IN RMX domain: 2442 would be a good starting point for company networks and would in 2443 most cases allow easy and simple RMX configuration if the network 2444 can't be described with a simple network mask. 2446 4.7. Full Address Query 2448 As described above, RMX records will in most cases apply to the 2449 domain part of the sender address. In special cases it might be 2450 desirable to query the RMX record for a particular address. An RMX 2451 entry of the Full Address Query type may occur in a domain RMX 2452 record only. It signals that the RMX record for the full address 2453 is to be fetched and processed. 2455 This entry type does not take arguments. The negation flag is not 2456 supported. The tag is "full". 2458 If such a full address query is to be performed, the mail address 2459 must be mapped to a valid and non-ambiguos DNS name. This mapping 2460 is still to be defined. It is not sufficient to simply replace the 2461 @ with a dot, because of case sensitivity, character sets, etc. 2462 The e-mail addresses 2464 john.doe@example.org 2465 John.Doe@example.org 2466 john@doe.example.org 2468 must all be mapped to different DNS entries. A better approach is 2469 RMX++ (see below). 2471 4.8. MX reference 2473 This entry type has no parameters. It means that all those 2474 machines are authorized, which are pointed to by an MX record. 2476 Example: 2478 danisch.de. IN RMX MX: 2480 would simply allow all machines receiving mails for danisch.de 2481 (i.e. the MX machines) to deliver as well. 2483 5. Optional and experimental entry types 2485 The following subsections roughly describe further experimental 2486 entry types. These methods are just considerations about what to 2487 include in RMX and what to not include. The main purpose of this 2488 section is to start a discussion about such entry types. 2490 The disadvantage of the following methods is that they violate the 2491 basic idea of RMX, i. e. to be simple, robust, easy to implement 2492 and easy to administer. The author does not believe that it is a 2493 good idea or even feasible to implement cryptography for a world 2494 wide e-mail transfer network. Keep in mind that cryptographic keys 2495 can be copied. Even if only around 0.01% of the cryptographic keys 2496 are stolen, this still compromises and spoils RMX. Cryptography is 2497 simply the wrong tool for the problem RMX is intended to solve. It 2498 is nevertheless to be discussed. 2500 5.1. TLS fingerprint 2502 The sender is considered to be authorized if the message was 2503 transmitted through SMTP and TLS[4], and the sender used a 2504 certificate matching the fingerprint given in the RMX record. 2506 5.2. TLS and LDAP 2508 The receiver could perform an LDAP query for the sender address 2509 (through the LDAP SRV record or given in the RMX record), fetch the 2510 X.509 certificate for the sender. The sender is considered to be 2511 authorized when the message was transmitted through SMTP and TLS 2512 using this certificate. 2514 5.3. PGP or S/MIME signature 2516 It would be possible to accept a message only if it was signed with 2517 PGP or S/MIME with a key which's fingerprint is given in the RMX 2518 record or to be fetched from LDAP or any PGP database. This is 2519 just for discussion, since it violates the idea of RMX to focus on 2520 the transport, not on the content. It would also allow replay 2521 attacks and not cover the envelope sender address or message 2522 header. 2524 5.4. Transparent Challenge/Response 2526 It would also be possible to implement a challenge-response 2527 mechanism without modifying the syntax of SMTP. For example, the 2528 receiving MTA could issue a challenge with it's very first greeting 2529 message, the sending MTA could include the response in the HELO or 2530 EHLO parameter and when the receiving MTA later learns the sender 2531 envelope address, it could verify the response based on entries in 2532 the RMX record. 2534 5.5. SASL Challenge/Response 2536 Modern SMTP implementations already include a SASL[5] mechanism, 2537 which easily allows to plugin new authentication mechanisms. While 2538 common SASL mechanisms require to use a previously shared password, 2539 a new mechanism could perform a challenge response authentication 2540 as a SASL method. 2542 6. Encoding 2544 6.1. RMX Records 2546 6.1.1. Overall structure 2548 Each entry starts with an octet containing the entry type and the 2549 negation flag: 2551 +---+---+---+---+---+---+---+---+------ 2552 | N | Entry Type Code | Parameters... 2553 +---+---+---+---+---+---+---+---+------ 2555 N If this bit (MSB) is set, an IP address 2556 matching this entry is not authorized, 2557 but explicitely rejected. See entry 2558 type descriptions for details. 2560 Entry Type A 7bit number simply determining the entry 2561 type. 2563 Currently, entries do not have an explicit length field, the entry 2564 length is determined implicitely by the entry type. Applications 2565 are required to abort if an unknown entry type is found, instead of 2566 skipping unknown entries. 2568 6.1.2. Record encoding 2570 A RMX record is simply a concatenation of RMX entries. 2572 6.1.3. Encoding of IPv4 and IPv6 address ranges 2574 After the entry type tag as described above, one octet follows 2575 giving the length L of the bit sequence. Then a sequence of 2576 exactly as many octets follows as needed to carry L bits of 2577 information (= trunc((L+7)/8) ). 2579 +---+---+---+---+---+---+---+---+ 2580 | N | Entry Type Code (1 or 2) | 2581 +---+---+---+---+---+---+---+---+ 2582 | Length Field L | 2583 +---+---+---+---+---+---+---+---+ 2584 | Bit Field | 2585 / ((L+7)/8) Octets / 2586 +---+---+---+---+---+---+---+---+ 2588 6.1.4. Encoding of DNS 2590 After the entry type tag immediately follows a DNS encoded[6] 2591 domain name. 2593 +---+---+---+---+---+---+---+---+ 2594 | N | Entry Type Code (3..5) | 2595 +---+---+---+---+---+---+---+---+ 2596 | Length Field L | 2597 +---+---+---+---+---+---+---+---+ 2598 | Encoded DNS | 2599 / Name as described in RFC1035 / 2600 +---+---+---+---+---+---+---+---+ 2602 In contrast to earlier draft versions of this memo, the DNS name 2603 cannot be compressed, since this would cause decompression errors 2604 when a DNS server which does not know this particular RR type is 2605 part of the query chain. 2607 6.1.5. Encoding of unused and full address query 2609 These entries do not contain parameters and does not allow the 2610 negation flag. So the encoding is quite simple: 2612 +---+---+---+---+---+---+---+---+ 2613 | 0 | Entry Type Code (6 or 7)| 2614 +---+---+---+---+---+---+---+---+ 2616 6.1.6. Additional Records 2618 In order to avoid the need of a second query to resolve the given 2619 host name, a DNS server should enclose the A record for that domain 2620 name in the additional section of the additional section of the DNS 2621 reply, if the server happens to be authoritative. 2623 In order to avoid the need of a second query to resolve the given 2624 host name, a DNS server should enclose the APL record for that 2625 domain name in the additional section of the additional section of 2626 the DNS reply, if the server happens to be authoritative. 2628 6.2. Alternative encoding as TXT records 2630 The main objection against the prior versions of this draft was 2631 that it requires a new RR entry type and upgrading all DNS servers. 2633 Therefore and alternative encoding is proposed. Instead of using a 2634 new RR type, the TXT record type is used to contain the RMX record. 2635 The records would simply look as described in the entry type 2636 chapters above, e.g. 2638 _rmx.danisch.de. IN TXT "apl:relays.rackland.de" 2640 To allow smooth introduction of RMX without the need to immediately 2641 upgrade all DNS servers, all clients (which have to be newly 2642 installed anyway) MUST support both the TXT and the RMX records. A 2643 client has to perform an ANY or a TXT and a RMX query. 2644 Servers/zone tables may currently use TXT entries but SHOULD use 2645 RMX entries in future. 2647 7. Message Headers 2649 An RMX query must be followed by any kind of action depending on 2650 the RMX result. One action might be to reject the message. 2651 Another action might be to add a header line to the message body, 2652 thus allowing MUAs and delivery programs to filter or sort 2653 messages. 2655 In future, the RMX result might be melted into the Received: header 2656 line [2]. 2658 The details of such entries are to be discussed. As a proposal the 2659 following form is suggested: 2661 X-RMX: RESULT addr ADDRESS by HOST on DATE mechanism MECHANISM 2663 where 2665 RESULT is one of "Granted", "Denied", "NotInRMX", "NoRMX", 2666 "TempFail", "BadData", "Trusted". 2668 ADDRESS is the IP address of the sending machine 2670 HOST is the name of the machine performing the RMX query. 2672 DATE is the date of the query. 2674 MECHANISM is the RMX method used to authorize the sender. 2676 8. SMTP error messages 2678 If a message is rejected because of RMX records, an error message 2679 should be issued which explains the details. It is to be discussed 2680 whether new SMTP error codes are to be defined. Error messages 2681 should be verbose to make debugging of configuration errors easy. 2683 9. Message relaying and forwarding 2685 9.1. Problem description 2687 Message forwarding and relaying means that an MTA which received an 2688 e-mail by SMTP does not deliver it locally, but resends the message 2689 - usually unchanged except for an additional Received header line 2690 and maybe the recipient's address rewritten - to another SMTP MTA. 2691 Message forwarding is an essential functionality of e-mail 2692 transport services, for example: 2694 - Message transport from outer MX relay to the intranet 2695 - Message forwarding and Cc-ing by .forward or .procmail-alike 2696 mechanisms 2697 - Mailing list processing 2698 - Message reception by mail relays with low MX priority, 2699 usually provided by third parties as a stand-by service 2700 in case of relay failure or maintenance 2701 - "Forwarding" and "Bouncing" as a MUA functionality 2703 In all of these cases a message is sent by SMTP from a host which 2704 is not covered by the original sender domain's RMX records. While 2705 the RMX records would forbid accepting this message, it still must 2706 be accepted. The following subsections explain how to cope with 2707 relaying. 2709 9.2. Trusted relaying/forwarding 2711 In some cases the receiving MTA trusts the sending MTA to not fake 2712 messages and to already have checked the RMX records at message 2713 reception. As a typical example, a company might have an outer 2714 mail relay which receives messages from the Internet and checks the 2715 RMX records. This relay then forwards the messages to the several 2716 department's mail servers. It does not make sense for these 2717 department mail servers to check the RMX records, because the RMX 2718 records have already been checked and because they would always 2719 reject messages, since the relay is not covered by the originator's 2720 RMX records. In this case there is a trust relationship between 2721 the department relays and the outer relay. So RMX checking is 2722 turned off for trusted relays. In this example, the department 2723 relays would not check messages from the outer relay (but for 2724 intranet security, they could still check RMX records of the other 2725 departments sub-domains to avoid internal forgery between 2726 departments). 2728 Another common example are the low-priority MX relays, which 2729 receive and cache e-mails when the high-priority relays are down. 2730 In this case, the high-priority relay would trust the low-priority 2731 relay to have verified the sender authorization and would not 2732 perform another RMX verification (which would obviously fail). 2734 When a relay forwards a message to a trusting machine, the envelope 2735 sender address should remain unchanged. 2737 9.3. Untrusted relaying/forwarding 2739 If the receiving MTA does not trust the forwarding MTA, then there 2740 is no chance to leave the sender envelope address unchanged. At a 2741 first glance this might appear impracticable, but this is 2742 absolutely necessary. If an untrusted MTA could claim to have 2743 forwarded a message from a foreign sender address, it could have 2744 forged the message as well. Spammers and forgers would just have 2745 to act as such a relay. 2747 Therefore, it is required that, when performing untrusted 2748 forwarding, the envelope sender address has to be replaced by the 2749 sender address of someone responsible for the relaying mechanism, 2750 e.g. the owner of the mailing list or the mail address of the user 2751 who's forwarding mechanism caused the transmission. It is 2752 important to stress that untrusted relaying/forwarding means taking 2753 over responsibility for the message. It is the idea of RMX records 2754 to tie responsibility to message transmission. Untrusted relaying 2755 without replacing the sender address would mean to transmit without 2756 taking responsibility. 2758 The disadvantage is that the original sender address is lost. 2759 Therefore, whenever a sender address replacement happens, the 2760 Received-Line must contain the old address. Many of today's MTAs 2761 already insert the envelope recipient address, but not the sender 2762 address into the Received header line. It seems reasonable to 2763 require every Received line to include both the sender and 2764 recipient address of the incoming SMTP connection. 2766 10. Further development and improvements of RMX 2768 This RFC is intended to be close to the earlier RMX drafts for 2769 historical reasons. Therefore, the further development and 2770 improvements are not made "in place" but described in this new 2771 chapter. 2773 10.1. Separate RMX records for address types 2775 In earlier draft versions of this memo there was only one RMX 2776 record covering all possible identity classes provided by the 2777 authentication step, e.g. IPv4 and IPv6 addresses were described by 2778 the same RMX record. 2780 This does not make sense and unnecessarily inflates the RMX 2781 records. Since the receiving MTA knows the identity class at query 2782 time, separate RMX records can be provided for each supported 2783 identity class, e.g. different RMX records for IPv4 and IPv6 2784 addresses. 2786 So RMX records could look like 2788 _ipv4._rmx.danisch.de IN RMX ipv4:213.133.101.23 2789 _ipv6._rmx.danisch.de IN RMX ipv6:fec0::0/16 2791 10.2. SCAF - Simple Caller Authorization Framework 2793 Fraud, spam, worms, spoofing are not limited to SMTP only. Other 2794 internet protocols like news transfer, chat and instant messaging, 2795 and even non-internet protocols can be protected against spoofing 2796 with RMX. It could also become a simple, password-less caller 2797 identification mechanism for protocols like HTTP or FTP. For 2798 example, a web browser could provide a user address similar to an 2799 e-mail address as a HTTP [7] cookie, in a new request header entry 2800 type, or as a password-less HTTP authentication header. 2802 Imagine there is a vendor's web server providing web pages 2803 available for employees of a particular company only (e.g. software 2804 upgrades for a customer). The customer could be required to 2805 provide an RMX-like record describing it's network which allows the 2806 web server to limit access based on the given user address and the 2807 RMX record for this application. (It can be understood as a kind 2808 of external firewall rule. Even firewalls and proxies could 2809 support it.) 2811 To distinguish records for different applications, the records must 2812 be stored at different locations in DNS, e.g. 2814 _ipv4._smtp._rmx.danisch.de IN RMX ipv4:213.133.101.23 2815 _ipv4._http._rmx.danisch.de IN RMX host:homeoffice.danisch.de 2817 would restrict access to web servers with "hadmut@danisch.de" to 2818 the IP address pointed to by the A record of homeoffice.danisch.de 2819 (which can be a dynamically assigned address). 2821 10.3. RMX++ 2823 RMX has restrictions and might not be applicable or desirable in 2824 all cases due to it's inflexible record types, it's nature to 2825 reveal the domain's network structure, and limitations of DNS. The 2826 domain owner would always be limited to those entry types commonly 2827 defined. 2829 To overcome these restrictions, the successor RMX++ significantly 2830 differs from RMX. With RMX++, the query is split into two distinct 2831 steps. In a first step, the receiving MTA takes the domain name of 2832 the sender address to query DNS as with RMX. But instead of an RMX 2833 record, the MTA queries an A record, an SRV record [8], and a TXT 2834 record. 2836 The A or SRV records are then used to locate a server for the 2837 second step. The TXT record contains a URL pattern. A default 2838 pattern is used in absence of the TXT record. The pattern contains 2839 macros which are to be expanded, e.g. substituted with the server 2840 address, the mail sender address, the calling MTA's IP address, 2841 message ID, content type etc. The MTA then fetches the RMX record 2842 found at that URL. The preferred protocol type is HTTP or HTTPS, 2843 but other protocols could be used as well. Even DNS and LDAP 2844 queries can be described in URLs. 2846 In general, there are three types of RMX records: In the first 2847 case, the RMX record is a static one and stored as a file on the 2848 web server. In the second case, it is dynamically generated by the 2849 web server (e.g. through a CGI program). In the third case, the 2850 MTA passes required information to the server and the server 2851 replies with "Allow" or "Reject". The receiving MTA does query and 2852 handle all three types the very same way. 2854 This method has several advantages: 2856 - No need for a new DNS RR type. DNS servers don't need to 2857 be upgraded. 2859 - Easier to administer: Today, every domain owner is 2860 able to put a file on a web site. Helper programs run on 2861 the web server will help to generate the RMX records with 2862 easy and foolproof user interfaces. In contrast, DNS zone 2863 tables are more difficult and not as easy available for 2864 modification for everyone at any time. 2866 - There is no size limit for the record as with DNS. The 2867 RMX record does not need to be split into several 2868 DNS records and stitched together. The encoding does not 2869 need to be as tight as described above, and can be 2870 plain text, ASN.1, XML, etc. 2872 - Simple encryption with HTTPS 2874 - Support of full sender address verification (not just 2875 the domain part) is trivial. 2877 - Caching with HTTP proxies, caching control and expiry 2878 with HTTP headers 2880 - The RMX record can be generated dynamically on request. 2881 Large sites where thousands of users log in and out 2882 all the time (e.g. large mail service providers) 2883 can provide "fresh" records for every request without 2884 the need to update their zone table every second. 2886 Dynamic RMX records can be easily generated with CGI 2887 applications, a well known and robust mechanism. 2889 - RMX records can be smaller because they need to cover 2890 only the query sent to the server and don't need to 2891 describe the full network structure which might consist 2892 of thousands of computers. 2894 - RMX verification can be moved from the receiving MTA 2895 to the domain owner's server, because the MTA can 2896 pass all required data such as sender address, IP addresses, 2897 size, message ID, etc. as CGI parameters. It allows the 2898 domain owner to completely hide his network structure and 2899 the authorization method, and to implement any arbitrary 2900 mechanism. Just as an extreme example to point out the 2901 capability, the domain owner's server could calculate a 2902 horoscope on request and decide whether to permit or not 2903 based on whether the planet constellation promises the 2904 e-mail to be lucky. Obviously, in reality the domain 2905 owner would use some kind of database to verify the sender. 2906 The domain owner is free to implement anything. 2908 - If the domain owner chooses to use a URL with CGI parameters, 2909 to use HTTPS, or to instruct caches to not cache, the server 2910 will be queried for every single e-mail. This allows the 2911 server to limit the number of e-mails sent and to detect 2912 anomalies, e.g. that a machine has been infected by some 2913 worm or virus. 2915 11. Security Considerations 2917 11.1. Draft specific considerations 2919 11.1.1. Authentication strength 2921 It is important to stress, that the suggested method does not 2922 provide high level security and does not completely prevent forged 2923 e-mails or spam under any circumstances. It is a robust, but not 2924 highly reliable and completely secure security mechanism. Keep in 2925 mind that it is based on DNS, and DNS is not secure today. 2926 Authorization is based on the IP address. The very same machine 2927 with the very same IP address could be authorized to send e-mail 2928 with a given sender address and sending spam at the same time. 2929 Maybe because several users are logged in. Or because several 2930 customers use the same relay of the same ISP, where one customer 2931 could use the sender address of a different customer. It is up to 2932 the ISP to prevent this or not. Machines can still be hijacked. 2933 Spammers are also domain owners. They can simply use their own 2934 domain and authorize themselves. You will always find people on 2935 the world who do not care about security and open their relays and 2936 RMX records for others to abuse them. RMX is to be considered as a 2937 very cheap and simple light weight mechanism, which can 2938 nevertheless provide a significant improvement in mail security 2939 against a certain class of attacks, until a successor of SMTP has 2940 been defined and commonly accepted. 2942 11.1.2. Where Authentication and Authorization end 2944 Early versions of RMX drafts did not cover the local part of the e- 2945 mail address, i.e. what's on the left side of the @ sign. This is 2946 still to be discussed. Authentication and authorization are 2947 limited to the sending MTA's IP address. The authentication is 2948 limited to the TCP functionality, which is sufficient for light 2949 weight authentication. The RMX records authorize the IP address of 2950 the sending host only, not the particular sender of the message. 2951 So if a machine is authorized to use sender addresses of more than 2952 a single domain, the authentication scheme does not prevent that 2953 any user on this machine can send with any of these domains. RMX 2954 is not a substitute for the host security of the involved machines. 2956 The proposed authentication scheme can be seen as a "half way 2957 authentication": It does not track back an e-mail to the effective 2958 sender. It tracks only half of the way, i. e. it tracks back to 2959 the domain and it's DNS administrators who authorized that 2960 particular sender IP address to use it for sending e-mail. How the 2961 party responsible for that domain performs user authentication, 2962 whom it grants access to, how it helds people responsible for 2963 abuse, is completely left as the private business of those who are 2964 in charge of that domain. So this draft does not interfere with 2965 the domain's individual security policy or any legislation about 2966 such policies. On the other hand, the proposed authentication 2967 scheme does not give any statement about the nature and quality of 2968 the domain's security policy. This is an essential feature of the 2969 proposal: E-mail authentication must be deployed world wide, 2970 otherwise it won't do the job. Any security scheme interfering 2971 with the local legislations or the domain's security policy will 2972 not be accepted and can't effectively deployed. Therefore, the 2973 security policy must remain the domain's private business, no 2974 matter how lousy the policy might be. 2976 In order to achieve this and to make use of the only existing world 2977 wide Internet directory scheme (DNS), the approach of this proposal 2978 is to just ignore the local part of the sender address (i.e. what's 2979 left of the @ part) and limit view to the domain part. After all, 2980 that's what we do anyway when delivering to a given address with 2981 SMTP. 2983 11.1.3. Vulnerability of DNS 2985 DNS is an essential part of the proposed authentication scheme, 2986 since it requires any directory service, and DNS is currently the 2987 only one available. Unfortunately, DNS is vulnerable and can be 2988 spoofed and poisoned. This flaw is commonly known and weakens many 2989 network services, but for reasons beyond that draft DNS has not 2990 been significantly improved yet. Several commentors to previous 2991 drafts asked to not use DNS because of its lack of security. This 2992 is unfeasible: Any authentication/authorization system linked to 2993 some kind of symbolic identity (in this case the domain name) needs 2994 some kind of infrastructure and trusted assignment. There are 2995 basically two ways to do it: Do it yourself and trust nobody else, 2996 or let someone else do it. There are methods to do it the former 2997 way, e.g. to give someone some kind of authentication/authorization 2998 information after a first successful e-mail exchange, e.g. some 2999 kind of cookie or special e-mail address. This is certainly 3000 interesting and powerful, but it does not solve the problem on a 3001 world wide scale and is far to complicated and error prone for the 3002 average user, i. e. 99% of the users. 3004 The latter method to let someone else do the symbolic name 3005 assignment and create the authentication framework is well known. 3006 It context of public key cryptography, this is called a Public Key 3007 Infrastructure (PKI). One of the best known facts about PKIs is 3008 that, until now, we don't have any covering a significant part of 3009 the Internet. And we won't have any in near future. The 3010 complexity is far too high, it is too expensive, and it involves 3011 cooperation of every single user, which is simply unrealistic and 3012 extremely error prone. So what do we have we can use? All we have 3013 is the DNS and the Whois database. And we have countries who don't 3014 allow cryptography. So the proposal was designed to use DNS 3015 without cryptography. It does not avoid DNS because of its 3016 vulnerability, it asks for a better DNS, but accepts the DNS as it 3017 is for the moment. Currently there are two main threats caused by 3018 the DNS weakness: 3020 - A spammer/forger could spoof DNS in order to gain false 3021 authorization to send fake e-mails. 3023 - An attacker could spoof DNS in order to block delivery from 3024 authorized machines, i. e. perform a Denial of Service attack. 3026 The first one is rather unrealistic, because it would require an 3027 average spammer to poison a significant part of the DNS servers of 3028 its victims. A spammer sending messages to one million receipients 3029 would need to poison at least 1-10% which is 10,000 to 100,000 3030 receipient's DNS servers. This should be unfeasible in most cases. 3032 In contrast, the second threat is a severe one. If an attacker 3033 wanted to block messages from one company to another, he just needs 3034 to poison the recipients DNS server with a wrong RMX record in 3035 order to make the recipient's SMTP machine reject all messages. 3036 And this is feasible since the attacker needs to poison only a 3037 single DNS server. But does this make SMTP more vulnerable? No. 3038 Because the attacker can already do even more without RMX. By 3039 poisoning the sender's DNS server with wrong MX records, the 3040 attacker can also block message delivery or even redirect the 3041 messages to the attacker's machine, thus preventing any delivery 3042 error messages and furthermore getting access to the messages. 3044 As a consequence, e-mail delivery by SMTP requires a better DNS 3045 anyway. The requirements are not significantly expanded by RMX. 3047 11.1.4. Sneaking RMX attack? 3049 A certain kind of sneaking DNS attack could be possible. DNS and 3050 RMX implementors should take care to void it. 3052 Imagine an unauthorized sender is sending a forged mail (e.g. 3053 spam). At connection time, before querying the RMX record, the 3054 receiving MTA usually performs a PTR query for the IP address of 3055 the sending MTA. If the sender has control over the authoritative 3056 name server for that particular IP address, the sender could give a 3057 normal PTR answer, but could append a wrong RMX, APL, or A record 3058 in the additional section of the query. A subsequent RMX query 3059 could receive wrong DNS data if the DNS server used by the 3060 receiving MTA accepted those forged records. 3062 11.1.5. Open SMTP relays 3064 Open SMTP relays (i.e. machines which accept any e-mail message 3065 from anyone and deliver to the world) abused by spammers are a one 3066 of the main problems of spam defense and sender backtracking. In 3067 most cases this problem just vanishes because foreign open relay 3068 machines will not be covered by the RMX records of the forged 3069 sender address. But there are two special cases: 3071 If the spammer knows about a domain which authorizes this 3072 particular machine, that domain can be abused for forgery. But in 3073 this case, the IP address of the relay machine and the RMX records 3074 of the domain track back to the persons responsible. Both can be 3075 demanded to fix the relay or remove the RMX record for this 3076 machine. An open relay is a security flaw like leaving the machine 3077 open for everybody to login and send random mails from inside. 3078 Once the administrative persons refuse to solve the problem, they 3079 can be identified as spammers and held responsible. 3081 The second special case is when a domain authorizes all IP 3082 addresses by having the network 0.0.0.0/0 in the RMX/APL record. 3083 In this case, open relays don't make things worse. It's up to the 3084 recipient's MTA to reject mails from domains with loose security 3085 policies. 3087 11.1.6. Unforged Spam 3089 RMX does not prevent spam (which is, by the way, not yet exactly 3090 defined), it prevents forgery. Since spam is against law and 3091 violates the recipients rights, spam depends on untracability of 3092 the sender. In practice the sender forges the sender address 3093 (other cases see below). RMX is designed to detect such forgeries. 3095 However, the RMX approach is rendered ineffective, if the sender 3096 does not forge. If the sender uses just a normal address of his 3097 own domain, this is just a plain, normal e-mail, which needs to be 3098 let through. Since it is up to the human's taste whether this is 3099 spam or not, there's no technical way to reliably identify this as 3100 spam. But since the sender domain is known, this domain can be 3101 blacklisted or legal steps can be gone into. 3103 11.1.7. Reliability of Whois Entries 3105 Once the RMX infrastructure gets deployed, what's the security 3106 gain? It allows to determine the domain which's DNS zone 3107 authorized the sending machine. What's that good for? There are 3108 some immediate uses of the domain name, e.g. in black- and 3109 whitelisting. But in most cases this is just the starting point of 3110 further investigations, either performed automatically before 3111 message acceptance, or manually after spam has been received and 3112 complainted about. 3114 The next step after determining the domain is determining the 3115 people responsible for this domain. This can sometimes be achieved 3116 by querying the Whois databases. Unfortunately, many whois entries 3117 are useless because they are incomplete, wrong, obsolete, or in 3118 uncommon languages. Furthermore, there are several formats of 3119 address informations which make it difficult to automatically 3120 extract the address. Sometimes the whois entry identifies the 3121 provider and not the owner of the domain. Whois servers are not 3122 built for high availability and sometimes unreachable. 3124 Therefore, a mandatory standard is required about the contents and 3125 the format of whois entries, and the availability of the servers. 3126 After receiving the MAIL FROM SMTP command with the sender envelope 3127 address, the receiving MTA could check the RMX record and Whois 3128 entry. If it doesn't point to a real human, the message could be 3129 rejected and an error message like "Ask your provider to fix your 3130 Whois entry" could be issued. Obviously, domain providers must be 3131 held responsible for wrong entries. It might still be acceptable 3132 to allow anonymous domains, i. e. domains which don't point to a 3133 responsible human. But it is the receivers choice to accept e- 3134 mails from such domains or not. 3136 11.1.8. Hazards for Freedom of Speech 3138 Currently, some governments try to enforce limitations of internet 3139 traffic in order to cut unwanted content providers from the 3140 network. Some of these governments try to hide a whole country 3141 behind firewalls, others try to force Internet providers to poison 3142 DNS servers with wrong A records for web servers, e.g. one county 3143 administration in Germany tries to do so. If message reception 3144 depends on DNS entries, the same governments will try to block not 3145 only HTTP, but SMTP from these domains also. 3147 However, since most MTAs already reject messages from unresolvable 3148 domain names this is not a new threat. 3150 11.2. General Considerations about spam defense 3152 After discussing security requirements of the proposal, now the 3153 security advantages of the RMX approach over content based filters 3154 will be explained. Basically, there are three kinds of content 3155 filters: 3157 - Those which upload the message or some digest to an external 3158 third party and ask "Is this spam"? 3160 - Those which download a set of patterns and rules from a third 3161 party and apply this set to incoming messages in order to 3162 determine whether it is spam. 3164 - Those which are independent and don't contact any third party, 3165 but try to learn themselves what is spam and what isn't. 3167 The message filters provided by some e-mail service providers are 3168 usually not a kind of their own, but a combination of the first two 3169 kinds. 3171 11.2.1. Action vs. reaction 3173 Content filters suffer from a fundamental design problem: They are 3174 late. They need to see some content of the same kind before in 3175 order to learn and to block further distribution. 3177 This works for viruses and worms, which redistribute. This doesn't 3178 work for spam, since spam is usually not redistributed after the 3179 first delivery. When the filters have learned or downloaded new 3180 pattern sets, it's too late. 3182 RMX does not have this problem. 3184 11.2.2. Content based Denial of Service attacks 3186 All three kinds of content filters, but especially the second and 3187 the third kind are vulnerable to content based Denial of Service 3188 attacks. 3190 If some kind of third party (e.g. non-democratic government, 3191 intellectual property warriors, religious groups, military, secret 3192 services, patriots, public relation agents, etc.) wants certain 3193 contents not to be distributed, they could either poison the 3194 pattern/rule databases or feed wrong sets to particular receivers. 3196 Such pattern/rule sets are the perfect tool for censoring e-mail 3197 traffic and denial of service attacks by governments and other 3198 parties, and a similar threat are virus filters. E. g. the content 3199 industry could demand to teach all virus and spam filters to delete 3200 all e-mails containing the URL of an MP3 web server outside the 3201 legislation. Software manufacturers could try to block all e-mails 3202 containing software license keys, thus trying to make unallowed 3203 distribution more difficult. Governments could try to block 3204 distribution of unwanted information and politically incorrect 3205 speech. 3207 RMX does not have this problem. 3209 12. Privacy Considerations 3211 (It was proposed on the 56th IETF meeting to have a privacy section 3212 in drafts and RFCs.) 3214 12.1. Draft specific considerations 3216 12.1.1. No content leaking 3218 Since the RMX approach doesn't touch the contents of a message in 3219 any way, there is obviously no way of leaking out any information 3220 about the content of the message. RMX is based solely on the 3221 envelope recipient address. However, methods to fix problems not 3222 covered by RMX might allow content leaking, e.g. if the acceptance 3223 of a message with an empty sender address requires the reference to 3224 the message id of an e-mail recently sent, this allows an attacker 3225 to verify whether a certain message was delivered from there. 3227 12.1.2. Message reception and sender domain 3229 Message delivery triggers RMX and APL requests by the recipient. 3230 Thus, the admin of the DNS server or an eavesdropper could learn 3231 that the given machine has just received a message with a sender 3232 from this address, even if the SMTP traffic itself had been 3233 encrypted. 3235 However, most of today's MTAs do query the MX and A records of the 3236 domain after the MAIL FROM command, so this is not a real new 3237 threat. 3239 12.1.3. Network structure 3241 Since RMX and its associated APL records provide a complete list of 3242 all IP addresses of hosts authorized to send messages from this 3243 address, they do reveal informations about the network structure 3244 and maybe the lifestyle of the domain owner, since a growing number 3245 of domains are owned by single persons or families. E.g. the RMX 3246 records could reveal where someone has his job or spends his time 3247 at weekends. 3249 If such informations are to be kept secret, it is the user's job to 3250 not sent e-mails from there and to relay them from non-compromising 3251 IP addresses. 3253 12.1.4. Owner information distribution 3255 As described above, RMX depends partly on the reliability of the 3256 whois database entries. It does not make anonymous domains 3257 impossible, but it requires to keep the database entries "true", i. 3258 e. if a whois entry does not contain informations about the 3259 responsible person, this must be unambigously labeled as anonymous. 3260 It must not contain fake names and addresses to pretend a non- 3261 existing person. However, since most Internet users on the world 3262 feel extremely annoyed by spam, they will urge their MTA admin to 3263 reject messages from anonymous domains. The domain owner will have 3264 the choice to either remain anonymous but be not able to send e- 3265 mail to everyone in the world, or to be able but to reveal his 3266 identity to everyone on the world. 3268 It would be possible to provide whois-like services only to 3269 recipients of recent messages, but this would make things too 3270 complicated to be commonly adopted. 3272 12.2. General Considerations about spam defense 3274 12.2.1. Content leaking of content filters 3276 As described above in the Security chapter, there are spam filters 3277 which inherently allow leakage of the message body. Those filters 3278 upload either the message body, or in most cases just some kind of 3279 checksum to a third party, which replies whether this is to be seen 3280 as spam or not. The idea is to keep a databases of all digests of 3281 all messages. If a message is sent more often than some threshold, 3282 it is to be considered as a mass mail and therefore tagged as spam. 3284 While the digest itself does not reveal the content of the message, 3285 it perfectly reveals where a particular message has been delivered 3286 to. If a government finds just a single unwanted message, if a 3287 software manufacturer finds a single message with a stolen product 3288 license key, if someone finds a message with unpatriotic content, 3289 it takes just a single database lookup to get a list of all people 3290 who received this particular message. Content filters with digest 3291 upload are "Big Brother's" favourite toy. 3293 12.2.2. Black- and Whitelists 3295 Some proposals against spam are based on a central database of 3296 white- or blacklisted IP addresses, Sender names, Message IDs or 3297 whatever. Again, there is a central database which learns who has 3298 received which e-mail or from which sender with every query. This 3299 allows tracking relations between persons, which is also a breach 3300 of privacy. 3302 13. Deployment Considerations 3304 13.1. Compatibility 3306 13.1.1. Compatibility with old mail receivers 3308 Since the suggested extension doesn't change the SMTP protocol at 3309 all, it is fully compatible with old mail receivers. They simply 3310 don't ask for the RMX records and don't perform the check. 3312 13.1.2. Compatibility with old mail senders 3314 Since the SMTP protocol is unchanged and the SMTP sender is not 3315 involved in the check, the method is fully compatible with old mail 3316 senders. 3318 13.1.3. Compatibility with old DNS clients 3320 Since the RMX is a new RR, the existing DNS protocol and zone 3321 informations remain completely untouched. 3323 If RMX is provided as a TXT record instead, it must be ensured that 3324 no other software is misinterpreting this entry. 3326 13.1.4. Compatibility with old DNS servers 3328 Full compatibility: If the server does not support RMX records, RMX 3329 in TXT records can be used. 3331 13.2. Enforcement policy 3333 Obviously, for reasons of backward compatibility and smooth 3334 introduction of this scheme, RMX records can't be required 3335 immediately. Domains without RMX records must temporarily be 3336 treated the same way as they are treated right now, i.e. e-mail 3337 must be accepted from anywhere. But once the scheme becomes 3338 sufficiently widespread, mail relays can start to refuse e-mails 3339 with sender addresses from domains without RMX records, thus 3340 forcing the owner of the domain to include a statement of 3341 authorization into the domain's zone table. Domain owners will 3342 still be free to have an RMX record with a network and mask 3343 0.0.0.0/0, i.e. to allow e-mails with that domain from everywhere. 3344 On the other hand, mail receivers will be free to refuse mails from 3345 domains without RMX records or RMX records which are too loose. 3346 Advanced MTAs might have a configuration option to set the maximum 3347 number of IP addresses authorized to use a domain. E-mails from a 3348 domain, which's RMX records exceed this limit, would be rejected. 3349 For example, a relay could reject e-mails from domains which 3350 authorize more than 8 IP addresses. That allows to accept e-mails 3351 only from domains with a reasonable security policy. 3353 14. General considerations about fighting spam 3355 Is there a concise technical solution against spam? Yes. 3357 Will it be deployed? Probably not. 3359 Why not? Because of the strong non-technical interests of several 3360 parties against a solution to the problem, as described below. 3361 Since these are non-technical reasons, they might be beyond the 3362 scope of such a draft. But since they are the main problems that 3363 prevent fighting spam, it is unavoidable to address them. 3365 14.1. The economical problem 3367 As has been recently illustrated in the initial session of the 3368 IRTF's Anti Spam Research Group (ASRG) on the 56th IETF meeting, 3369 sending spam is a business with significant revenues. 3371 But a much bigger business is selling anti-spam software. This is 3372 a billion dollar market, and it is rapidly growing. Any simple and 3373 effective solution against spam would defeat revenues and drive 3374 several companies into bankrupt, would make consultants jobless. 3376 Therefore, spam is essential for the anti-spam business. If there 3377 is no spam, then no Anti-Spam software can be sold, similar to the 3378 anti-virus business. There are extremely strong efforts to keep 3379 this market growing. Viruses, Worms, and now spam are just perfect 3380 to keep this market alive: It is not sufficient to just buy a 3381 software. Databases need to be updated continuously, thus making 3382 the cash flow continuously. Have a single, simple, and permanent 3383 solution to the problem and - boom - this billion dollar market is 3384 dead. That's one of the reasons why people are expected to live 3385 with spam. They have to live with it to make them buy anti-spam 3386 software. Content filters are perfect products to keep this market 3387 alive. 3389 14.2. The POP problem 3391 Another problem is the history of mail delivery. Once upon a time, 3392 there used to be very few SMTP relays which handled the e-mail 3393 traffic of all the world, and everybody was happy with that. Then 3394 odd things like Personal Computers, which are sometimes switched 3395 off, portable computers, dynamicaly assigned IP addresses, IP 3396 access from hotel rooms, etc. was invented, and people became 3397 unhappy, because SMTP does not support delivery to such machines. 3398 To make them happy again, the Post Office Protocol[9] was invented, 3399 which turned the last part of message delivery from SMTP's push 3400 style into a pull style, thus making virtually every computer on 3401 the world with any random IP address a potential receiver of mails 3402 for random domains. Unfortunately, only receiving e-mail was 3403 covered, but sending e-mail was left to SMTP. 3405 The result is that today we have only very few SMTP relays pointed 3406 to by MX records, but an extreme number of hosts sending e-mail 3407 with SMTP from any IP address with sender addresses from any 3408 domain. Mail delivery has become very asymmetric. Insecurity, 3409 especially forgeability, has become an essential part of mail 3410 transport. 3412 That problem could easily be fixed: Use protocols which allow 3413 uploading of messages to be delivered. If a host doesn't receive 3414 messages by SMTP, it shouldn't deliver by SMTP. Mail delivery 3415 should go the same way back that incoming mail went in. This is 3416 not a limitation to those people on the road who plug their 3417 portable computer in any hotel room's phone plug and use any 3418 provider. If there is a POP server granting download access from 3419 anywhere, then the same server should be ready to accept uploading 3420 of outgoing messages. 3422 But as comments on the first draft version of this RFC showed, 3423 people religiously insist on sending e-mail with their domain from 3424 any computer with any IP address in the world, e.g. when visiting a 3425 friend using her computer. It appears to be impossible to convince 3426 people that stopping mail forgery requires every one of them to 3427 give up forging. 3429 14.3. The network structure problem 3431 A subsequent problem is that many organisations failed to implement 3432 a proper mail delivery structure and heavily based their network on 3433 this asymmetry. The author received harsh comments from 3434 Universities who were unable to give their network a reasonable 3435 structure. While they do have a central mail relay for incoming 3436 mail to the universities domain, they developed a structure where 3437 every member of the University randomly sends e-mails with that 3438 University's domain as a sender address from home or everywhere in 3439 the world with any dynamically assigned IP address from any 3440 provider. So this domain is to be used from every possible IP 3441 address on earth, and they are unable to operate any authentication 3442 scheme. Furthermore, they were unable to understand that such a 3443 policy heavily supports spam and that they have to expect that 3444 people don't accept such e-mails anymore once they become 3445 blacklisted. 3447 As long as organisations insist on having such policies, spammers 3448 will have a perfect playground. 3450 14.4. The mentality problem 3452 Another problem is the mentality of many internet users of certain 3453 countries. The author received harsh comments from people who 3454 strongly insisted on the freedom to send any e-mail with any sender 3455 address from anywhere, and who heavily refused any kind of 3456 authentication step or any limitation, because they claimed that 3457 this would infringe their constitutional "Freedom of Speech". They 3458 are undeviatingly convinced that "Freedom of Speech" guarantees 3459 their right to talk to everybody with any sender address, and that 3460 is has to be kept the recipient's own problem to sort out what he 3461 doesn't want to read - on the recipient's expense. The author 3462 learned that it is extremely difficult to convince some people to 3463 give up random e-mail sending. However, a security mechanism for 3464 the world wide mail system can never meet the taste and the 3465 requirements of every single one of all those hundreds of millions 3466 of users. 3468 It requires a clear statement that the constitutional "Freedom of 3469 Speech" does not cover molesting people with unsolicited e-mail 3470 with forged sender address. 3472 14.5. The identity problem 3474 How does one fight against mail forgery? With authentication. What 3475 is authentication? In simple words: Making sure that the sender's 3476 real identity meets the recipients idea of who is the sender, based 3477 on the sender address which came with the message. 3479 What is identity? It is the main problem. Several countries have 3480 different ideas of "identity", which turn out to be somehow 3481 incompatible. In some countries people have identity cards and 3482 never change their name and birthday. Identities are created by 3483 human birth, not by identity changes. Other countries do not have 3484 such a tight idea about identity. People's temporary identity is 3485 based on nothing more than a driving license and a social security 3486 number. With this background, it is virtually impossible to create 3487 a trustworthy PKI covering all Internet users. 3489 14.6. The multi-legislation problem 3491 Many proposals about fighting spam are feasible under certain 3492 legislations only, and are inacceptable under some of the 3493 legislations. But a world wide applicable method is required. 3494 That's why the approach to ask everone on the world to sign 3495 messages with cryptographic keys is not feasible. 3497 References 3499 1. J. Klensin, "Simple Mail Transfer Protocol," RFC 2821 (April 2001). 3501 2. P. Resnick, "Internet Message Format," RFC 2822 (April 2001). 3503 3. P. Koch, "A DNS RR Type for Lists of Address Prefixes (APL RR)," 3504 RFC 3123 (June 2001). 3506 4. T. Dierks, C. Allen, "The TLS Protocol," RFC 2246 (January 1999). 3508 5. J. Myers, "Simple Authentication and Security Layer (SASL)," RFC 3509 2222 (October 1997). 3511 6. P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION," 3512 RFC 1035 (November 1987). 3514 7. T. Berners-Lee and others, "Hypertext Transfer Protocol HTTP/1.1," 3515 RFC 2616 (June 1999). 3517 8. A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying the 3518 location of services (DNS SRV)," RFC 2782 (February 2000). 3520 9. J. Myers, M. Rose, "Post Office Protocol - Version 3," RFC 1939 3521 (May 1996). 3523 History 3525 1992-... Research on organisational E-Mail security 3526 Dec 2002 Internet-Draft 00 3527 Mar 2003 IRTF's Anti Spam Research Group started it's work 3528 Apr 2003 Internet-Draft 01 3529 Jun 2003 Internet-Draft 02 3530 Oct 2003 Internet-Draft 03 3532 Author's Address 3534 Hadmut Danisch rfc@danisch.de 3535 Tennesseeallee 58 http://www.danisch.de 3536 76149 Karlsruhe Phone: +49-721-843004 3537 Germany Phone: +49-351-4850477 3539 Comments 3541 Please send comments to rfc@danisch.de.