idnits 2.17.1 draft-fecyk-dmp-00.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 12 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- 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 (November 2003) is 7467 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft G. Fecyk 3 Pan-Am Internet Services 4 Document: draft-fecyk-dmp-00.txt 5 Expires: April 2004 November 2003 7 Designated Mailers Protocol 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of [RFC 2026]. 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 documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 For potential updates to the above required-text see: 30 http://www.ietf.org/ietf/1id-guidelines.txt 32 Abstract 34 This document describes the Designated Mailers Protocol (DMP); a 35 proposal for identifying computer systems authorized to act as 36 Simple Mail Transfer Protocol (SMTP) clients for an e-mail domain. 38 Conventions used in this document 40 "Client" refers to a host creating a network session with a server. 41 Clients may also be servers in real implementations. "Server" 42 refers to a host accepting a network session from a client as 43 defined above. 45 In examples, "C:" and "S:" indicate lines sent by the client and 46 server respectively. 48 "Domain" refers to both a domain in the RFC 1034 sense [RFC 1034] 49 and in the portion of an e-mail address after the "@" sign. 51 In examples, clients act on behalf of the fictitious domain 52 "example.com" or "example.org". Servers act on behalf of the 53 fictitious domain "example.net". Internet Protocol v4 address 54 examples come from the non-routable network 192.0.2.0/24. 56 Example records use the format described in RFC 1034 section 3.6.1. 57 The $ORIGIN keyword is used to shorten example record names. This 58 example describes "recordname.example.com." as two lines: 60 $ORIGIN example.com. 61 recordname TXT "this is a test" 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 65 this document are to be interpreted as described in [RFC 2119]. 67 Table of Contents 69 1. Introduction...................................................3 70 2. The Argument for Authenticating Incoming E-mail by Domain......3 71 3. Changes Since Last Revision....................................4 72 4. DMP Record Format and Designating SMTP Clients.................4 73 4.1 Example DMP Records by Internet Protocol v4 Address........6 74 4.2 Example DMP Records by Internet Protocol v6 Address........6 75 5. Querying for DMP Records and Recommended Actions...............7 76 5.1 RECOMMENDED Flowchart......................................8 77 5.2 Participating Domain's User and Client....................11 78 5.3 Participating Domain's User, Forwarding Service on 79 Participating Client..........................................11 80 5.4 Null Reverse Path, Participating Client...................12 81 5.5 Non-Participating Domain's User, Non-Participating Client 82 where Server permits Non-Participating Domains................12 83 5.6 Null Reverse Path, Non-Participating Client where Server 84 permits Non-Participating Domains.............................12 85 5.7 Participating Domain's User and Client where DMP lookup fails 86 (SERVFAIL)....................................................13 87 5.8 Participating Domain's User, Not Participating Domain's 88 Client (dmp=deny, NXDOMAIN)...................................13 89 6. Other Actions Permitted.......................................13 90 7. SMTP Source Routing...........................................14 91 8. Network Overhead and Effectiveness............................14 92 9. Security Considerations.......................................15 93 9.1 DNS Security..............................................15 94 9.2 Mail Transfer Agent Security..............................15 95 9.3 "Global Wildcard" DMP Records.............................15 97 Appendix A. Answers to Common Questions and Concerns.............16 98 A.1 Does DMP cause some mailing lists and clients that forward e- 99 mail to be refused?...........................................16 100 A.2 How does DMP affect SMTP clients on dynamically configured 101 hosts?........................................................16 102 Appendix B: Proposed Extensions to DMP...........................17 103 B.1 Designating Another Domain's Mailers......................17 104 B.2 Identifying the Role of Domain, Host or Forwarder.........18 105 References.......................................................19 106 Contributors.....................................................19 107 Author's Addresses...............................................20 108 Full Copyright Statement.........................................20 110 1. Introduction 112 Designated Mailers Protocol is a proposal to identify computers 113 authorized to act as Simple Mail Transfer Protocol (SMTP) [RFC 2821] 114 clients in the name of a domain. Mail Transfer Agents (MTAs) that 115 look up DMP records may refuse mail from sources not identified in 116 DMP records. This reduces the amount of "spoofed" mail the MTA 117 accepts in the name of a domain. 119 A domain publishes DMP records in the Domain Name System (DNS) [RFC 120 1034]. This ensures control remains with the domain's 121 administrators, and allows the MTA using DMP to take advantage of 122 DNS record caching to reduce the amount of network overhead that DMP 123 queries require. DMP uses the TXT Resource Record type, which works 124 without modifying existing DNS software. 126 DMP does not rely on any DNS records other than the DMP records 127 themselves, nor does it rely on information stored in the e-mail 128 body, including headers. This avoids problems identifying SMTP 129 clients by Address (A), Mail Exchange (MX) or Pointer (PTR) records 130 where the sending domain's administrators may not have control over 131 them. This also avoids blocking otherwise useful functionality of 132 SMTP, such as sending mail on behalf of another user. 134 DMP is an OPTIONAL extension to SMTP. DMP supports Extended SMTP 135 (ESMTP) and supports all SMTP functionality, including forwarding, 136 delivery status notifications, and so on, while providing a domain 137 with this control. 139 2. The Argument for Authenticating Incoming E-mail by Domain 141 Junk e-mailers routinely falsify sender envelopes in order to 142 misdirect complaints about their junk e-mail, resulting in an 143 industry consisting of users who fake mail for fun and profit. 145 Authors of viruses that propagate via e-mail falsify sender 146 envelopes to hide the origins of the virus-infected computers. 148 Confidence artists, posing as members of popular domains, routinely 149 attempt to obtain confidential information from unsuspecting 150 victims. 152 Designated Mailers Protocol reduces the impact of "spoofing" the 153 source of an e-mail message. DMP is not as strong as cryptographic 154 based authentication, but it is easier to implement and does not 155 require dramatic changes to e-mail software. 157 DMP does not prevent e-mail where solely the mailbox name is 158 falsified, but it allows the administrators of a domain to audit 159 such e-mail, by ensuring only its own computers may send mail on 160 behalf of the domain. 162 3. Changes Since Last Revision 164 Readers of previous revisions will remember the origins of this 165 proposal. The format of DMP records used since the last Internet- 166 Draft (draft-fecyk-dsprotocol-04.txt) has not changed. 168 DMP now incorporates design elements of the Designated Relays 169 Inquiry Protocol, a work-in-progress by Raymond S Brand and others 170 (See Contributors section). Notably, DMP provides for a second tier 171 of inspection, permitting e-mail forwarded through certain types of 172 mail forwarding protocols. Receiving domain administrators may 173 choose any combination of outcomes based on the DMP query results. 175 4. DMP Record Format and Designating SMTP Clients 177 DMP records of a domain MUST appear in a sub-domain "_smtp-client". 178 From there, records MUST appear in sub-domains identified by 179 protocol type, such as "in-addr" for IPv4 and "ip6" for IPv6. 180 Further sub-domains will appear because of designating hosts and 181 networks as allowed to send e-mail on behalf of the sender's domain. 183 DMP records use the TXT Resource Record type. All DNS software 184 supports this record type and it may store arbitrary values. DMP 185 uses the format defined in [RFC 1464]. An algorithm that looks up 186 RFC 1464 style records MAY be used but is NOT REQUIRED. 188 A participating domain MUST publish these minimum records. 190 ; REQUIRED: DMP Participant Identifier 191 _smtp-client.$DOMAINNAME. TXT "dmp=" 192 ; RECOMMENDED: Default DMP response for servers supporting wildcards 193 *._smtp-client.$DOMAINNAME. TXT "dmp=deny" 195 The first record identifies the domain, $DOMAINNAME, as a 196 participant with its own designated mailer hosts. The second is a 197 RECOMMENDED record that provides a default response to queries. If 198 there are no additional DMP records, the domain is effectively 199 publicizing that they do not send e-mail. 201 A participating domain sending e-mail MUST publish one or more 202 additional records identifying the networks or network addresses 203 permitted to send e-mail for their domain. 205 $REV-ADDRESS.$ADDRESS-TYPE._smtp-client.$DOMAINNAME. TXT "dmp=allow" 207 $REV-ADDRESS is the host or network's address represented in reverse 208 form, as used in in-addr.arpa or ip6.arpa. $ADDRESS-TYPE is the 209 type of address, such as "in-addr" for IPv4 or "ip6" for IPv6. DMP 210 supports any transport protocol that supports address-to-name 211 mapping in DNS. 213 DMP uses the keywords "allow" and "deny" for their English meanings. 214 Record contents are case-insensitive, so "DMP=ALLOW" means the same 215 as "dmp=allow". 217 DMP records MAY use wildcards, if the DNS server software supports 218 them, to publish fewer records. As not all DNS software supports 219 wildcards, or may handle wildcards differently, wildcards are NOT 220 REQUIRED. 222 Domains publishing DMP records MUST also publish DMP records for 223 each sending host's Fully Qualified Domain Name (FQDN). This 224 identifies the host as being permitted to send mail with null 225 reverse paths (MAIL FROM:<>) and also being permitted to forward 226 mail, where the sender's domain may not otherwise designate this 227 host. 229 ; REQUIRED: Default DMP record for hosts 230 _smtp-client.$FQDN. TXT "dmp=" 231 ; REQUIRED: One or more DMP records identifying the host's network 232 address or addresses 233 $REV-ADDRESS-1.$ADDRESS-TYPE._smtp-client.$FQDN. TXT "dmp=allow" 234 $REV-ADDRESS-2.$ADDRESS-TYPE._smtp-client.$FQDN. TXT "dmp=allow" 235 ; [...] 236 $REV-ADDRESS-N.$ADDRESS-TYPE._smtp-client.$FQDN. TXT "dmp=allow" 237 ; RECOMMENDED: Default DMP lookup result 238 *._smtp-client.$FQDN. TXT "dmp=deny" 240 4.1 Example DMP Records by Internet Protocol v4 Address 242 The domain example.com designates two IPv4 addresses as allowed to 243 send mail for example.com: 245 $ORIGIN example.com. 246 _smtp-client TXT "dmp=" 247 *._smtp-client TXT "dmp=deny" 248 1.2.0.192.in-addr._smtp-client TXT "dmp=allow" 249 2.2.0.192.in-addr._smtp-client TXT "dmp=allow" 251 The domain example.com designates the IPv4 network 192.0.2.0/24 as 252 allowed to send mail for example.com: 254 $ORIGIN example.com. 255 _smtp-client TXT "dmp=" 256 *._smtp-client TXT "dmp=deny" 257 *.2.0.192.in-addr._smtp-client TXT "dmp=allow" 259 The host sender.example.com designates its IPv4 address at 260 192.0.2.1: 262 $ORIGIN example.com. 263 _smtp-client.sender TXT "dmp=" 264 *._smtp-client.sender TXT "dmp=deny" 265 1.2.0.192.in-addr._smtp-client.sender TXT "dmp=allow" 267 4.2 Example DMP Records by Internet Protocol v6 Address 269 The domain example.com designates two IPv6 addresses as allowed to 270 send mail for example.com: 272 $ORIGIN example.com. 273 _smtp-client TXT "dmp=" 274 *._smtp-client TXT "dmp=deny" 275 0.F.E.D.C.B.A.9.8.7.6.5.4.3.2.1.1.0.0.0.1.1.A.C.1.C.0.0.5.4.3.2.ip6. 276 _smtp-client TXT "dmp=allow" 277 1.F.E.D.C.B.A.9.8.7.6.5.4.3.2.1.1.0.0.0.1.1.A.C.1.C.0.0.5.4.3.2.ip6. 278 _smtp-client TXT "dmp=allow" 280 The host sender.example.com designates its own IPv6 address 281 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0: 283 $ORIGIN example.com. 284 _smtp-client.sender TXT "dmp=" 285 *._smtp-client.sender TXT "dmp=deny" 286 0.F.E.D.C.B.A.9.8.7.6.5.4.3.2.1.1.0.0.0.1.1.A.C.1.C.0.0.5.4.3.2.ip6. 287 _smtp-client.sender TXT "dmp=allow" 289 5. Querying for DMP Records and Recommended Actions 291 A server looking up DMP records queries on the following information 292 provided by the client: 294 . Connecting network address and Domain part of the sender envelope 295 (MAIL FROM:<>) or 296 . Connecting network address and HELO or EHLO identifier. The HELO 297 or EHLO identifier MUST be the client host's Fully Qualified 298 Domain Name (FQDN). 300 The layout of the DMP records allows the server to query the address 301 and domain or FQDN with a single DNS query. The result will be one 302 of four possibilities: 304 . A successful query, and one or more returned TXT records, at least 305 one of which will contain the string "dmp=allow", meaning this 306 client is permitted to send mail on behalf of this domain or FQDN, 307 . A successful query, and one or more returned TXT records, at least 308 one of which will contain the string "dmp=deny", meaning this 309 client is NOT permitted to send mail on behalf of this domain or 310 FQDN, 311 . A query that returns NXDOMAIN, or a query that returns no DMP 312 records or multiple and conflicting DMP records (such as two TXT 313 records, one reading "dmp=allow" and one reading "dmp=deny"), 314 indicating the domain or FQDN does not participate in DMP, or has 315 invalid DMP records, or 316 . A query that returns SERVFAIL, indicating a temporary error. 318 A server MAY perform an additional query to determine if a domain or 319 FQDN participates in DMP. The result will be one of three 320 possibilities: 322 . A successful query, and one or more returned TXT records, one or 323 more of which will contain only the string "dmp=", indicating this 324 domain or FQDN participates in DMP, 325 . A query that returns NXDOMAIN, or a query that returns no DMP 326 records or multiple and conflicting DMP records (such as one 327 record containing "dmp=" and another containing "dmp=allow" or 328 "dmp=deny" or "dmp=[something else]", indicating the domain does 329 not participate in DMP, or has invalid DMP records, or, 330 . A query that returns SERVFAIL, indicating a temporary error. 332 A server using DMP MAY bypass DMP lookups entirely, for reasons 333 defined by the server's operators. Examples include the client 334 connecting from an "allow relay" list, a client authenticating using 335 another protocol such as SMTP AUTH, and other reasons. Among other 336 benefits, this allows client-only hosts and Mail User Agents (MUAs) 337 to use these servers without requiring their own DMP records. 339 Once a server has DMP query results, the server may act on the 340 message envelope in many ways. The following flowchart demonstrates 341 the RECOMMENDED paths. The chart starts when the client issues the 342 HELO or EHLO command, and ends when the server responds to the MAIL 343 FROM command. Responses allowed to MAIL FROM are from RFC 2821 344 section 4.3.2. 346 . 250 indicating either HELO/EHLO or MAIL FROM were acceptable 347 . 451 indicating a local processing error (such as SERVFAIL) 348 . 550 indicating a rejection based on policy (in this case, the 349 policy is determined by the DMP query results and the server's 350 settings) 352 5.1 RECOMMENDED Flowchart 354 ============================== 355 | Client issues HELO or EHLO | 356 ============================== 357 | 358 ========================================= 359 | Server stores HELO or EHLO identifier | 360 | and responds normally | 361 ========================================= 362 | 363 ============================== 364 | Client issues MAIL command | 365 ============================== 366 | 367 /------------------------------------------------\ 368 | Is the client's address allowed to bypass DMP? | 369 \------------------------------------------------/ 370 | | 371 Yes No 372 | | 373 | /-------------------------------------------\ 374 | | Is the MAIL envelope null (MAIL FROM:<>)? | 375 | \-------------------------------------------/ 376 | | | 377 | No Yes 378 | | | 379 | ============================== | 380 | | Server performs DMP Lookup | | 381 | | on envelope's domain | | 382 | | and client network address | | 383 | ============================== | 384 | | | 385 | | | 386 | | | 387 | | | 388 | /---------------------\ | 389 | | What is the result? | | 390 | \---------------------/ | 391 | | | 392 | |-----------|-------|-------|------------| | 393 | | | | | | 394 | allow SERVFAIL NXDOMAIN deny | 395 | | | or invalid | | 396 | | | DMP | | 397 | | | | | | 398 | | | =================== | | 399 | | | | Server performs | | | 400 | | | | DMP domain-only | | | 401 | | | | lookup | | | 402 | | | =================== | | 403 | | | | | | 404 | | | /-----------------\ | | 405 | | | | Lookup result? | | | 406 | | | \-----------------/ | | 407 | | | | | | | | 408 | | | SERVFAIL NXDOMAIN Yes | | 409 | | | | or invalid | | | 410 | | | |----| DMP | | | 411 | | | | | |-|| | 412 | | | | | || | 413 | | | | /----------------\ || | 414 | | | | | Accept non-DMP | || | 415 | | | | | domain? | || | 416 | | | | \----------------/ || | 417 | | | | | | || | 418 | | | | Yes No || | 419 | | | | | | || | 420 | | | | (Go to) | || | 421 | | | | (allow) | || | 422 | | | | | | || | 423 | | |------------------| |---||| | 424 | | | | | ||| | 425 | | | | | /----------------\ | 426 | | | |---|| | Allow HELO as | | 427 | | | || | alternative? | | 428 | | | || \----------------/ | 429 | | | || | | | 430 | | | || No Yes | 431 | | | || | | | 432 | | | || | | | 433 | | | || | | | 434 | | | || | | | 435 | | | || | | | 436 | | | || | ======================= 437 | | | || | | Server performs DMP | 438 | | | || | | on HELO/EHLO FQDN | 439 | | | || | | and client address | 440 | | | || | ======================= 441 | | | || | | 442 | | | || | /----------------\ 443 | | | || | | Lookup result? | 444 | | | || | \----------------/ 445 | | | || | | | | | 446 | | | || | allow | | deny 447 | | | || | | | | | 448 | | | || | (go to) | | | 449 | | | || | (allow) | | | 450 | | ||--------------------------------| | | | 451 | | || || | | | | 452 | | || || | SERVFAIL | | 453 | | || || | | | | 454 | | || || | (go to) | | 455 | | || || | (fail ) | | 456 | | || |||------------------------| | | 457 | | || ||| | | (go to) 458 | | || ||| | | (deny ) 459 | | || ||| | | | 460 | | || ||| ||-------------------| 461 | | || ||| || | 462 | | || ||| || | 463 | | || ||| || | 464 | | || ||| || NXDOMAIN 465 | | || ||| || or invalid 466 | | || ||| || DMP 467 | | || ||| || | 468 | | || ||| || =================== 469 | | || ||| || | Server performs | 470 | | || ||| || | DMP HELO-only | 471 | | || ||| || | FQDN lookup | 472 | | || ||| || =================== 473 | | || ||| || | 474 | | || ||| || /----------------\ 475 | | || ||| || | Lookup result? | 476 | | || ||| || \----------------/ 477 | | || ||| || | | | 478 | | || ||| || SERVFAIL | | 479 | | || ||| || | | | 480 | | || ||| || (go to) | | 481 | | || ||| || (fail ) | | 482 | | || ||| || | | | 483 | | || ||| || | | | 484 | | || ||| || | | | 485 | | || ||||-------------------| Yes | 486 | | || |||| || | | 487 | | || |||| |||----------| | 488 | | || |||| ||| | 489 | | || |||| ||| NXDOMAIN 490 | | || |||| ||| or invalid 491 | | || |||| ||| DMP 492 | | || |||| ||| | 493 | | || |||| ||| /----------------\ 494 | | || |||| ||| | Accept non-DMP | 495 | | || |||| ||| | domain AND is | 496 | | || |||| ||| | envelope null? | 497 | | || |||| ||| \----------------/ 498 | | || |||| ||| | | 499 | | || |||| ||| Yes No 500 | | || |||| ||| | | 501 | | || |||| ||| (go to) | 502 | | || |||| ||| (allow) | 503 | | || |||| ||| | | 504 | | |||---------------------------------| | 505 | | ||| |||| ||| | 506 | | ||| |||| ||||--------------| 507 | | ||| |||| |||| 508 ====(allow)===== =====(fail)===== ====(deny)====== 509 | Server sends | | Server sends | | Server sends | 510 | 250 OK and | | 451 Temp Err | | 550 Policy | 511 | resumes SMTP | | resumes SMTP | | resumes SMTP | 512 ================ ================ ================ 514 These examples use IPv4 addresses. The process is identical for 515 other address types. 517 5.2 Participating Domain's User and Client 519 S: 220 mail.example.net MMS SMTPRCV service v0.95 520 C: HELO sender.example.com 521 S: 250 mail.example.net Hello sender.example.com [192.0.2.1] 522 C: MAIL FROM: 523 (server looks up 1.2.0.192.in-addr._smtp-client.example.com and 524 receives "dmp=allow") 525 S: 250 OK client at 192.0.2.1 verified as authorized sender for 526 example.com 527 [resume normally] 529 5.3 Participating Domain's User, Forwarding Service on Participating 530 Client 532 S: 220 mail.example.net MMS SMTPRCV service v0.9.5 533 C: HELO othersender.example.org 534 S: 250 mail.example.net Hello othersender.example.org [192.0.2.5] 535 C: MAIL FROM: 536 (server looks up 5.2.0.192.in-addr._smtp-client.example.com and 537 receives "dmp=deny") 538 (server looks up 539 5.2.0.192.in-addr._smtp-client.othersender.example.org 540 and receives "dmp=allow") 541 S: 250 OK client at 192.0.2.5 verified as othersender.example.org 542 [resume normally] 544 5.4 Null Reverse Path, Participating Client 546 S: 220 mail.example.net MMS SMTPRCV service v0.95 547 C: HELO sender.example.com 548 S: 250 mail.example.net Hello sender.example.com [192.0.2.1] 549 C: MAIL FROM:<> 550 (server looks up 551 1.2.0.192.in-addr._smtp-client.sender.example.com 552 and receives "dmp=allow") 553 S: 250 OK client at 192.0.2.1 verified as sender.example.com 554 [resume normally] 556 5.5 Non-Participating Domain's User, Non-Participating Client where 557 Server permits Non-Participating Domains 559 S: 220 mail.example.net MMS SMTPRCV service v0.95 560 C: HELO sender.example.com 561 S: 250 mail.example.net Hello sender.example.com [192.0.2.1] 562 C: MAIL FROM: 563 (server looks up 1.2.0.192.in-addr._smtp-client.example.com 564 and returns with NXDOMAIN) 565 (server looks up _smtp-client.example.com and returns NXDOMAIN) 566 S: 250 OK client at 192.0.2.1 verified as sender.example.com 567 [resume normally] 569 5.6 Null Reverse Path, Non-Participating Client where Server permits 570 Non-Participating Domains 572 S: 220 mail.example.net MMS SMTPRCV service v0.95 573 C: HELO sender.example.com 574 S: 250 mail.example.net Hello sender.example.com [192.0.2.1] 575 C: MAIL FROM:<> 576 (server looks up 577 1.2.0.192.in-addr._smtp-client.sender.example.com 578 and returns NXDOMAIN) 579 S: 250 OK client not verified as sender.example.com 580 [resume normally] 582 5.7 Participating Domain's User and Client where DMP lookup fails 583 (SERVFAIL) 585 S: 220 mail.example.net MMS SMTPRCV service v0.95 586 C: HELO sender.example.com 587 S: 250 mail.example.net Hello sender.example.com [192.0.2.1] 588 C: MAIL FROM: 589 (server looks up 1.2.0.192.in-addr._smtp-client.example.com 590 and returns with SERVFAIL) 591 S: 451 ERROR Cannot verify 192.0.2.1 as sender for example.com at 592 this time 593 [resume as though MAIL FROM had not occurred] 595 A participating server SHOULD attempt the lookup more than once on a 596 SERVFAIL before returning a 451 response. 598 5.8 Participating Domain's User, Not Participating Domain's Client 599 (dmp=deny, NXDOMAIN) 601 S: 220 mail.example.net MMS SMTPRCV service v0.95 602 C: HELO othersender.example.org 603 S: 250 mail.example.net Hello othersender.example.org [192.0.2.7] 604 C: MAIL FROM: 605 (server looks up 7.2.0.192.in-addr._smtp-client.example.com 606 and receives "dmp=deny") 607 (server looks up 608 7.2.0.192.in-addr._smtp-client.othersender.example.org 609 and returns NXDOMAIN) 610 (server looks up _smtp-client.othersender.example.org and returns 611 NXDOMAIN) 612 S: 550 ERROR client at 192.0.2.1 may not send for example.com 613 [resume as though MAIL FROM had not occurred] 615 6. Other Actions Permitted 617 Administrators configuring servers to perform DMP lookups MAY take 618 other actions. 620 Such other actions include adding extra headers to e-mail that 621 identify the DMP query results, so recipients may filter it with 622 their client software. Server administrators MAY switch the order 623 of lookups around, or omit some lookups, to suit their purposes. 625 Domains and hosts with published DMP records provide receiving 626 servers with the means to identify the publisher's permitted SMTP 627 clients. What receiving servers' administrators do with this 628 information is left to them. 630 7. SMTP Source Routing 632 While depreciated by RFC 2821, some Mail Transfer Agents support 633 SMTP Source Routing, where the sender can define a path through 634 which hosts the e-mail passes through. 636 An example sender envelope, used in the MAIL command, may look like 637 this: 639 MAIL FROM:<@mta1.example.com,@mta2.example.com:user@example.com> 641 If the receiving server supports source routing, it MAY perform its 642 DMP lookups on the first domain or host specified, as this is where 643 the client should be. In the above example, that would be 644 mta1.example.com. Otherwise, the receiving server MUST perform its 645 lookup on the last domain, in this case example.com. 647 This is equivalent to the receiver querying only the HELO or EHLO 648 host name of the client. 650 8. Network Overhead and Effectiveness 652 In November 2003, volunteers provided MTA logs allowing a realistic 653 measurement of DMP's impact. [LOGS] 655 The test simulated published DMP records by using a test domain 656 labeled "dmptest.invalid" published on a DNS server. The test 657 domain did not contain wildcard records. 659 The DMP lookup application measured the total size of the DNS query 660 and response packets, minus the amount used to identify 661 ".dmptest.invalid", and added the SMTP message size to this total 662 upon an "allow" condition. The test used the combination of options 663 that permitted the most mail: Allow mail from non-DMP domains and 664 allow HELO/EHLO records to override a "deny" record from a domain. 666 From these logs, and a sampling of 19791 domains over a period of 667 eighteen months, came the following measurements. These 668 measurements DID NOT take DNS caching (Time-to-live, or TTL) into 669 account. 671 DMP's network usage alone, compared to the bandwidth used by SMTP: 673 . DMP caused an average additional 4.15% increase in bandwidth. 674 . 12635 (63%) of domains sampled caused a 4.15% or less increase. 675 . 6281 (33%) of domains sampled caused a 1% or less increase. 677 DMP's network usage plus the reduction in SMTP bandwidth by refusing 678 "spoofed" messages, compared to the bandwidth used by SMTP alone: 680 . Frequently "spoofed" domains with correct DMP records used 10% to 681 20% LESS bandwidth, including the bandwidth used by DMP. 682 . Less-frequently "spoofed" domains with correct DMP records used 0% 683 to 1% more bandwidth. 684 . Domains without correct DMP record sets used 1% to 4.15% or more 685 bandwidth. 687 DNS server caching, with reasonably high TTL values for DMP records, 688 will reduce the network overhead caused by DMP dramatically. Even 689 without considering TTL, popular domains with correct DMP record 690 sets saved up to 20% in SMTP bandwidth, while costing those domains 691 only 1% additional bandwidth, or less. 693 9. Security Considerations 695 9.1 DNS Security 697 DMP depends solely on DNS to publish DMP records. Any compromise of 698 records of a domain would make that domain vulnerable to "spoofing." 699 Likewise, a compromised DNS server hosting an upper-level domain 700 could publish false records for multiple domains. 702 Best current practices for DNS server security will prevent these 703 and similar abuses and DMP records may reside on DNSSEC servers 704 without changes to DMP. 706 9.2 Mail Transfer Agent Security 708 A compromised host authorized through DMP records of a domain may 709 send unauthorized mail in the name of the domain. Likewise, a 710 compromised host with a DMP record set for its Fully Qualified 711 Domain Name may send unauthorized mail in its name. This is 712 critical in that a compromised host with DMP records may send mail 713 in the name of any domain. 715 Best current practices for SMTP Mail Transfer Agents in general will 716 prevent these and similar abuses. DMP may permit administrators to 717 identify hosts with compromised MTAs rapidly. 719 9.3 "Global Wildcard" DMP Records 721 A domain publishing DMP records may try designating another network, 722 not controlled by them, or the entire Internet as permitted to send 723 mail on its behalf, such as: 725 $ORIGIN example.com. 726 *._smtp-client TXT "dmp=allow" 728 This not only defeats the purpose of DMP, but administrators of 729 servers using DMP may refuse mail in the name of this domain, 730 regardless of origin, upon discovery of such a record. 732 If a domain administrator insists on doing this, it is RECOMMENDED 733 that this kind of record be placed in the address portion of the DMP 734 record tree, such as: 736 $ORIGIN example.com. 737 _smtp-client TXT "dmp=" 738 *._smtp-client TXT "dmp=deny" 739 *.in-addr._smtp-client TXT "dmp=allow" 741 This obtains the desired result without creating invalid DMP 742 records. 744 A receiving server administrator may refuse any traffic they wish on 745 their equipment. A domain publishing a DMP record set like this may 746 cause other administrators to refuse the mail of this domain 747 entirely. 749 Appendix A. Answers to Common Questions and Concerns 751 The two most common concerns appear here. Others will appear in a 752 DMP Frequently Asked Questions document. 754 A.1 Does DMP cause some mailing lists and clients that forward e- 755 mail to be refused? 757 Not anymore, provided the receiving servers will permit a client's 758 HELO or EHLO identifier as an alternative source for DMP records. 759 The policies of the receiving domain will dictate this. 761 Using a host's records in this manner shifts responsibility from the 762 administrators of the domain to the administrators of the host. 764 A.2 How does DMP affect SMTP clients on dynamically configured 765 hosts? 767 Because DMP queries use the client's network address as well as its 768 host or domain name, a change in a client's address could result in 769 returns of NXDOMAIN or "dmp=deny". 771 Servers using DMP may bypass DMP for "allowed" clients, and such 772 servers may act as relays or smart hosts for such clients. The 773 administrators of the sender domain MUST designate this relay as 774 allowed to send mail for their domain. This is the RECOMMENDED way 775 to send mail from a dynamically configured host to a domain querying 776 DMP records. 778 However, administrators MAY dynamically change DMP records alongside 779 of Address records or Mail Exchange records, permitting a 780 dynamically configured host to send mail directly to recipient 781 servers that query DMP records. Note that DNS propagation delays 782 and high Time-to-live (TTL) values may affect the ability to 783 designate a dynamically configured host as a sender. 785 Appendix B: Proposed Extensions to DMP 787 To ease the administration of DMP records, many readers provided 788 suggestions to extend DMP. These are the most common suggestions 789 and readers are encouraged to provide comments. 791 B.1 Designating Another Domain's Mailers 793 A network that accepts mail for multiple domains may find a full set 794 of DMP records inconvenient for each domain. 796 To reduce the administrative burden, a domain may declare the 797 published DMP records of another domain as authoritative for this 798 domain. 800 This domain only needs one DMP record to accomplish this: 802 _smtp-client.$DOMAIN. TXT "dmp=altdomain:$ALTDOMAIN." 804 $DOMAIN is the original domain. $ALTDOMAIN is the fully qualified 805 domain whose designated mailers may also send mail on behalf of 806 $DOMAIN. For consistency with other DNS record names, the 807 $ALTDOMAIN is trailed with a period to identify this as a fully 808 qualified domain. 810 A domain may specify multiple domains, whose senders may be used, 811 with each fully qualified domain separated by commas: 813 _smtp-client.$DOMAIN. TXT "dmp=altdomain:$ALTDOMAIN1.,$ALTDOMAIN2." 815 The limit to this would be the limit to the size of a TXT RR record. 817 One drawback to this extension is the increase in DNS traffic. A 818 server querying DMP records would need to repeat the queries for 819 each of the designated domains. The flowchart in 5.1 would repeat 820 the domain query for each $ALTDOMAIN specified, before querying the 821 host itself if configured to do so, or until "dmp=allow" was found. 823 Example default DMP record: 825 $ORIGIN example.com. 826 _smtp-client TXT "dmp=altdomain:example.net.,example.org." 828 B.2 Identifying the Role of Domain, Host or Forwarder 830 A default DMP record may identify the role of the domain, be it host 831 only or multi-host domain, be it permitted to forward mail in the 832 name of another domain or not. 834 Following the example in B.1, keywords could include "domain", 835 "forwarder", "host", "altdomain", and so on. 837 . domain: This is an e-mail domain whose sender envelopes are 838 <$USER@$DOMAIN>, with one or more addresses permitted to send mail 839 on behalf of the domain and its users. A domain may also be a 840 host. 841 . host: This is a single host, whose permitted sender envelopes 842 include <$USER@$HOST> and Null <>. A domain designating this 843 host's network address as a sender may also permit envelopes for 844 its domain from this host. 845 . forwarder: This is a single host that may send mail on behalf of 846 other domains. Any envelope may originate from this host, and it 847 implies the functionality of "host". 848 . altdomain: This domain designates another domain's DMP records as 849 authoritative for this domain. This keyword would override any 850 other keywords in the returned DMP record. 852 These keywords would appear in the domain or host's default DMP 853 record. A resulting lookup could return 854 "dmp=domain,host,forwarder". "altdomain" would override any other 855 keyword. 857 This has the potential to solve certain kinds of forgeries, by 858 identifying what a host or domain intends to have the domain or host 859 do. For instance, a host that does not forward mail could not send 860 mail on behalf of other domains. This would allow servers querying 861 DMP to refuse mail from a compromised host, while still permitting 862 Null Sender envelopes and mail sent in the name of the host. 864 The default of "dmp=" would assume "dmp=domain". A domain with a 865 misspelled keyword or a keyword with incorrect parameters would 866 appear as a non-participating domain with invalid DMP records. 868 References 870 Normative References 872 [RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 873 3", BCP 9, RFC 2026, October 1996. 875 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 876 Requirement Levels", BCP 14, RFC 2119, March 1997 878 [RFC 2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 879 April 2001 881 [RFC 1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND 882 FACILITIES", RFC 1034, November 1987 884 Informative References 886 [RFC 1464] Rosenbaum, R., "Using the Domain Name System To Store 887 Arbitrary String Attributes", RFC 1464, May 1993 889 [LOGS] The logs used to obtain this information are available from 890 the Pan-Am Internet DMP web site, at , in Microsoft Access 97 and plain text 892 formats. The archive is approximately 18 MB in size. 894 Contributors 896 Raymond S Brand, Lawrence Sherzer and Richard W Rognlie developed 897 the Designated Relays Inquiry Protocol (DRIP), a work-in-progress. 898 DMP uses portions of DRIP to support some mail forwarding systems. 900 Hadmut Danisch originally approached the idea of publishing a list 901 of hosts to permit mail for a domain; a work-in-progress called the 902 Reverse Mail Exchanger (RMX) DNS Resource Record. 904 Derek J. Balling provided the initial design of 905 the DMP DNS record template. "der Mouse" 906 generalized it, resulting in the 907 current form. 909 Michael A. Smith provided a format for the actual contents of DMP 910 records, based on RFC 1464. 912 Jack Bates assisted with supporting SMTP Source Routing. 914 Steve Atkins and Bill Cole assisted with their DNS expertise. 916 "der Mouse" assisted with testing and with formatting IPv6 versions 917 of DMP records. 919 NOTE to RFC Editor: "der Mouse" does not wish to be identified by 920 his real name. 922 Members of the IMS Users mailing list contributed MTA logs and ran a 923 statistics gathering application to obtain the information in 924 Chapter 8. Piotr Kubala provided the majority of this information. 926 Author's Addresses 928 Gordon Fecyk 929 24 - 482 Young Street 930 Winnipeg, MB R3B 2S6 931 Canada 932 Email: gordonf@pan-am.ca 934 Full Copyright Statement 936 "Copyright (C) The Internet Society (2003). All Rights Reserved. 938 This document and translations of it may be copied and furnished to 939 others, and derivative works that comment on or otherwise explain it 940 or assist in its implementation may be prepared, copied, published 941 and distributed, in whole or in part, without restriction of any 942 kind, provided that the above copyright notice and this paragraph 943 are included on all such copies and derivative works. However, this 944 document itself may not be modified in any way, such as by removing 945 the copyright notice or references to the Internet Society or other 946 Internet organizations, except as needed for the purpose of 947 developing Internet standards in which case the procedures for 948 copyrights defined in the Internet Standards process must be 949 followed, or as required to translate it into languages other than 950 English. 952 The limited permissions granted above are perpetual and will not be 953 revoked by the Internet Society or its successors or assigns. 955 This document and the information contained herein is provided on an 956 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 957 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 958 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 959 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 960 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.