idnits 2.17.1 draft-fecyk-dsprotocol-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: ---------------------------------------------------------------------------- No issues found here. 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 15 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 1 instance of lines with non-RFC3849-compliant IPv6 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 (August 2003) is 7532 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft 2 Category: Experimental G. Fecyk 3 Document: draft-fecyk-dsprotocol-04.txt Pan-Am Internet Services 4 Expires: September 2003 August 2003 6 Designated Mailers Protocol 7 A Way to Identify Hosts Authorized to Send SMTP Traffic 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 17 Internet-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 Changes Since Last Revision 31 Minor edits to conform with submissions to the RFC Editor, and a 32 clarification that participating sender domains do not need to 33 modify their email software to participate. 35 Testing revealed an inconsistency with wildcard handling between 36 various DNS implementations and RFC 1034 4.3.2 [n3]. This draft no 37 longer requires wildcard records at all. 39 Throughout the document, added new DNS nodes for different transport 40 protocols. Introduced the nodes "in-addr" and "ip6" so-named for 41 their nodes in the arpa domain. DMP is now extensible to any 42 transport that supports address-to-name mapping through DNS. 44 5. Changed the TXT RR values to "dmp=deny" and "dmp=allow" in 45 accordance with RFC 1464, which describes a way to store arbitrary 46 string values using TXT RR records. The values for the "dmp" 47 attribute were chosen for their English meanings. 49 Throughout this document, renamed the Protocol to "Designated 50 Mailers Protocol" and changed the acronym for the Protocol to "dmp" 51 to avoid confusion with record types available in DNSSEC. 53 Throughout the document, changed DNS node used for the Protocol to 54 "${addr-type}._smtp-client". This avoids conflicts and confusion 55 with SRV RR records. 57 5. Template, description and examples rewritten to use TXT RR 58 records instead of A RR records. 60 6. Protocol Flowchart redesigned to demonstrate changes to the 61 Protocol. Of most import: The second Protocol lookup, eliminated in 62 the second draft, was restored. 64 7 and 9. Example SMTP Conversations changed to accommodate changes 65 to Protocol, Template and Record Type use. 67 8. An additional mail forwarding problem, Source Routing, is 68 described. 70 Abstract 72 This document describes a proposed standard for identifying host 73 computer systems designated as Simple Mail Transfer Protocol (SMTP) 74 clients for an Internet domain or host through Domain Name System 75 (DNS). This identification allows SMTP servers to verify if a 76 connecting client is allowed to make outgoing SMTP connections on 77 behalf of the client's domain. 79 Conventions used in this document 81 In examples, "C:" and "S:" indicate lines sent by the client and 82 server respectively. 84 In examples, the domain name "example.net" represents a fictional 85 domain receiving SMTP communications with servers, and "example.com" 86 represents a fictional domain transmitting SMTP communications with 87 clients. 89 All name record examples use BIND 4 syntax. The majority of DNS 90 server software supports this syntax. If yours does not, you will 91 need to translate the examples into the correct syntax for your DNS 92 server. Wildcard capability is desired, but not required. 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 96 this document are to be interpreted as described in RFC 2119 [n1]. 98 Table of Contents 100 1. Introduction...................................................3 101 2. Why Identify Sending Hosts as well as Receiving Hosts..........4 102 2.1 Junk Email.................................................4 103 2.2 Viruses and Worms..........................................4 104 2.3 Account Fraud..............................................5 105 2.4 "Joe-Jobbers"..............................................5 106 3. What Participating in the Designated Mailers Protocol does NOT 107 Prevent...........................................................5 108 3.1 Junk Email with Correct Envelope Information...............5 109 3.2 "Joe-Jobbing" Within the Same Domain.......................5 110 3.3 Viruses and Worms using the Infected Party's SMTP Server...6 111 4. Background.....................................................6 112 5. Designating SMTP Clients.......................................7 113 5.1 By Internet Protocol v4 (IPv4) Address.....................9 114 5.2 Example Designations by IPv4 Address......................10 115 5.3 By Internet Protocol v6 (IPv6) Address....................11 116 6. Protocol Flowchart............................................11 117 7. Example SMTP Conversations....................................13 118 8. Mail Forwarding...............................................15 119 8.1 Authorized Mail Relay.....................................15 120 8.2 Secondary Mail Exchangers.................................16 121 8.3 Mailing List Servers......................................16 122 8.4 Mail Forwarding such as .forward files on *ix systems.....17 123 8.5 SMTP Source Routing.......................................17 124 9. Accepting Mail from the Null Sender Envelope: MAIL FROM:<>....17 125 10. Security Considerations......................................18 126 10.1 DNS Security.............................................18 127 10.2 Mail Transfer Agent Security.............................18 128 10.3 DNS Outages..............................................19 129 10.4 Answering RFC 2821 7.1: Mail Security and Spoofing.......19 130 Appendix A: Why the Default Record was Restored..................19 131 Appendix B: How to Avoid Looking Up the Default Record...........20 132 Appendix C: Stupid Spammer Tricks................................21 133 C.1: Bogus Subdomains.........................................21 134 References.......................................................21 135 Acknowledgments..................................................22 136 Author's Addresses...............................................22 137 Full Copyright Statement.........................................23 139 1. Introduction 141 My ultimate goal in fighting junk email is bringing accountability 142 back to its senders. With accountability, spammers must answer for 143 their email abuse or stop sending junk email. My first and most 144 successful attempt at doing so was the Orca DUL Project. 146 Even with projects like these and many others, spammers continued to 147 find ways to avoid accountability. This document is my latest 148 attempt to restore it, and with accountability restored, strengthen 149 the myriad of anti-spam measures, policies and projects already 150 available. 152 This author wants to remind readers that implementing and using the 153 Designated Mailers Protocol is entirely OPTIONAL and NOT REQUIRED to 154 operate SMTP services. Also, readers are reminded that recipients 155 have the right to refuse any communication from anyone. 157 2. Why Identify Sending Hosts as well as Receiving Hosts 159 You want to identify your outgoing SMTP hosts so you can effectively 160 audit email sent in the name of your domain. While it is still 161 possible to send authorized email and still be abusive, it becomes 162 far easier to audit the abuse and identify the senders. 164 2.1 Junk Email 166 "Spammers," not wishing be identified or have their abused resources 167 identified, routinely falsify their email's sender information, 168 including Sender Envelope (MAIL FROM: envelope), From: header and 169 Reply-To: header. Spammers often impersonate large, popular domains 170 such as hotmail.com[tm] when they do this. If such domains 171 participated in this Protocol, other participating domains would not 172 receive junk email from spammers falsifying their sender 173 information. 175 Recipients using the Protocol could reject any email sent in this 176 manner, regardless of how a resource is exploited. This includes 177 open relay, insecure proxy, dynamic IP, insecure and unrelated 178 resources such as older Formmail versions, and yet-undiscovered 179 exploits. 181 2.2 Viruses and Worms 183 While many viruses use the infected machine's sender address, those 184 same viruses rarely use the sender domain's resources to send copies 185 of itself, instead running their own SMTP engines. 187 Domains participating in this Protocol may reject copies of viruses 188 sent in this manner. 190 2.3 Account Fraud 192 Members of both financial institutions such as PayPal, and 193 non-financial account maintainers such as America On-Line, routinely 194 receive communication from confidence-artists and scammers 195 falsifying the membership host's domain in their email. They do 196 this to entice the recipients into divulging critical account 197 information to the scam artist. 199 Account maintainers participating in this Protocol can discourage 200 would-be scam artists from falsifying their domain, as participating 201 recipients may reject email from them. 203 2.4 "Joe-Jobbers" 205 People wishing to harm other people on the Internet often falsify a 206 specific person's email address to direct blame on that other 207 person. The first well-known instance of this abuse put the domain 208 joes.com out of business, hence the phrase "Being Joe'd" or "Joe 209 Jobbing." 211 Domains participating in this Protocol could greatly diminish their 212 chances of being "Joe'd," as participating recipients could reject 213 such email. 215 3. What Participating in the Designated Mailers Protocol does NOT 216 Prevent 218 Designated Mailers Protocol addresses a specific email problem, and 219 does not stop "authorized" abuse. It does, however, make 220 "authorized" abuse far easier to track. 222 3.1 Junk Email with Correct Envelope Information 224 The Protocol would not stop a spammer from using envelope 225 information they are authorized to use. However, maintainers of a 226 spammer's domain could audit their activity more effectively, as the 227 spammer is forced to use their correct information. 229 If spammers maintain their own domains, domain-based blocking 230 becomes more effective. In extreme cases, where a spammer hosts 231 multiple domains, blocking the authoritative DNS servers for the 232 spammer's domains becomes very effective, as the recipient could 233 reject all Protocol lookups on the spammers' DNS servers. They would 234 effectively reject all email from domains hosted there. 236 3.2 "Joe-Jobbing" Within the Same Domain 237 If a user on example.com wanted to falsify email coming from someone 238 else within example.com, the Protocol would still allow for it, 239 since the sender envelope information would be correct. However, 240 maintainers of said domain could audit this email and identify the 241 sender. 243 3.3 Viruses and Worms using the Infected Party's SMTP Server 245 If a user's computer runs such a virus that, instead of using its 246 own SMTP engine, uses their outgoing mail server, using the Protocol 247 would not stop it. However, domain maintainers could audit this 248 email and identify the user with the infected computer. 250 4. Background 252 At least one similar document [i1] describes identifying outgoing 253 SMTP hosts by name using SRV RR records, and defines the sub-domain 254 "_CLIENT._SMTP._TCP". [i2] However, there was no quick way to use 255 the sending host's IP address in the query. As the connecting IP 256 address is the most readily available bit of information we have on 257 a host, I propose using it, instead, in the query to see if it is a 258 designated SMTP mailer. 260 Many anti-spam projects use a variant of the addressing scheme 261 employed by the IN-ADDR.ARPA domain, where a name record for a given 262 IPv4 address may be found by querying each dotted-quad value as a 263 sub-domain. For example, we should find a PTR RR record in the 264 IN-ADDR.ARPA domain for 192.0.2.1 here: 266 1.2.0.192.in-addr.arpa. 268 Anti-spam projects using IN-ADDR.ARPA-like naming to identify 269 addresses to avoid receiving SMTP communication, do so by creating A 270 RR records, and use an otherwise meaningless value for the A RR 271 itself: 273 1.2.0.192.evil-spammers-list.example.com. A xxx.xxx.xxx.xxx 275 A subscriber to this project would look up 192.0.2.1 by querying 276 this name for a valid A RR record. If it found one, it would refuse 277 further SMTP connectivity from there. 279 The Designated Mailers Protocol defines a unique set of DNS resource 280 records to identify a domain as a participant of the Protocol. It 281 further defines a way to identify the addresses that are designated 282 to make SMTP connections on behalf of the sender's domain or host. 284 Sender domains do not need to modify their email software or DNS 285 software to participate. If a domain does not wish to block email 286 yet wants to use DMP to avoid being spoofed, they need only supply 287 DMP DNS records. 289 5. Designating SMTP Clients 291 DMP relies on name records stored in the DNS [n2]. All domains 292 participating in DMP set up TXT RR records in a sub-domain called 293 "_smtp-client". The first is a placeholder which identifies the 294 domain as a participant. The second is a default lookup result for 295 servers that support wildcard records: 297 ;REQUIRED: DMP Placeholder 298 _smtp-client.${DOMAINNAME}. TXT "dmp=" 299 ;RECOMMENDED: Default record 300 *._smtp-client.${DOMAINNAME}. TXT "dmp=deny" 302 Additional records are OPTIONAL and identify the network hosts 303 designated as SMTP clients: 305 ;OPTIONAL: DMP records 306 ${ADDRESS}.${ADDR-TYPE}._smtp-client.${DOMAINNAME}. TXT "dmp=allow" 308 ${ADDRESS} represents a network address in inverse form as used in 309 the "arpa" node. For instance, IPv4 addresses are represented as 310 they are in the in-addr.arpa node, IPv6 addresses are represented as 311 they are in ip6.arpa. ${ADDR-TYPE} represents the address type as 312 already used in the "arpa" node, such as "in-addr" for IPv4 and 313 "ip6" for IPv6. ${DOMAINNAME} represents the right-hand side of a 314 SMTP mail sender envelope as used in the MAIL FROM: command. For 315 example, the sender envelope "user@example.com" has a right-hand 316 side of "example.com". If there is no domain part in a sender 317 envelope, or the domain is "localhost", no DMP lookup is needed as 318 it is a local delivery. 320 Using inverse addresses in the zone records allows us to use 321 wildcards in the records, reducing the number of records needed for 322 a large bank of SMTP clients. 324 The TXT RR record was chosen for its flexibility. TXT RR records 325 are supported by all DNS server software. The values were selected 326 for their English meanings. The record strings are case- 327 insensitive, so "DMP=ALLOW" is the same as "dmp=allow". 329 Software designed to look up RFC 1464 [i3] type records may be used 330 to look up DMP records, but ANY algorithm that looks up TXT RR 331 records will work. For example, a function written in C to RFC 332 1464's example would have the following parameters: 334 snprintf(dmpRecordName, bufsize, "%s.in-addr._smtp-client.%s", 335 reversedIP, domainName); 336 getattributebyname(dmpRecordName, "dmp", result, bufsize); 338 To accommodate messages using a Null Reverse Path (MAIL FROM:<>), 339 participating sites MUST create a minimum of two DMP records for 340 each of their servers in addition to the records for their domain: 342 ;REQUIRED: DMP Placeholder and single record 343 _smtp-client.${FQDN}. TXT "dmp=" 344 ${ADDRESS}.{ADDR-TYPE}._smtp-client.${FQDN}. TXT "dmp=allow" 345 ; RECOMMENDED: Default DMP record for FQDN 346 *._smtp-client.${FQDN}. TXT "dmp=deny" 348 ...where ${FQDN} represents the MTA's fully qualified domain name. 349 Multiple records, or Wildcards if supported, may be used for a range 350 of hosts with the same FQDN. 352 A lookup of a network address will generate one of four results: 354 - A successful retrieval of a TXT RR record from a valid DMP 355 domain node, and a value of "dmp=allow" indicating the connecting 356 IP is a Designated Mailer for the domain, 357 - A successful retrieval of a TXT RR record from a valid DMP 358 domain node, and a value of "dmp=deny" indicating the connecting 359 IP is NOT a Designated Mailer for the domain, 360 - A permanent error, either NXDOMAIN, CNAME only, multiple 361 conflicting DMP records or non-DMP TXT RR record retrieved, 362 indicating the domain in the MAIL command does not participate in 363 the Protocol, or 364 - A temporary error, or failure to retrieve a record (SERVFAIL). 366 A lookup of a domain itself, to see if it participates in the 367 Protocol, will generate one of three possible results: 369 - A successful retrieval of a TXT RR record from a valid DMP 370 domain node, and a value of "dmp=" indicating the domain in the 371 MAIL FROM: command participates in the Protocol, 372 - A permanent error, either NXDOMAIN, CNAME only, DMP record with 373 a value different from "dmp=", multiple conflicting DMP records or 374 non-DMP TXT RR record retrieved, indicating the domain in the MAIL 375 command does not participate in the Protocol, or 376 - A temporary error, or failure to retrieve a record (SERVFAIL). 378 Participating servers MUST distinguish between all possible results. 379 Notably, SERVFAIL is a temporary error and not a permanent one, and 380 a subsequent lookup of the same record may succeed. 382 A participating domain MUST have one TXT RR record indicating they 383 participate in the Protocol, and that record MUST have a "null" 384 value for the "dmp" attribute: 386 _smtp-client.${DOMAIN_NAME}. TXT "dmp=" 388 The "dmp=" record was introduced to operate correctly with DNS 389 servers that may handle wildcards differently from another, or not 390 handle wildcards at all. A full explanation appears in Appendix A. 392 A participating domain SHOULD also have an additional TXT RR record 393 providing a default lookup result, if the DNS server supports 394 wildcards: 396 *._smtp-client.${DOMAIN_NAME}. TXT "dmp=deny" 398 A participating domain MAY have NO additional Designated Mailer 399 records, thereby indicating no SMTP traffic will originate from 400 their domain. The default of "deny" ensures that any lookups for 401 non-designated mailers will return this value. 403 This author understands that site administrators will want to permit 404 SMTP client connections from any host on a network. If a site 405 administrator insists on doing this, the site MUST have its default 406 "allow" record set per address type: 408 *.${ADDR-TYPE}._smtp-client.${DOMAINNAME}. TXT "dmp=allow" 410 Site administrators really, really SHOULD NOT do this, and instead 411 SHOULD designate their own hosts and networks. It is not difficult 412 to add and remove DMP records for dynamically addressed hosts, 413 testing hosts, temporary relays, third-party relays and so on. 415 5.1 By Internet Protocol v4 (IPv4) Address 417 A host or domain participating in Designated Mailers would create 418 TXT RR records in their DNS zone with this template [i4]: 420 ;REQUIRED: DMP placeholder 421 _smtp-client.${DOMAINNAME} TXT "dmp=" 422 ;RECOMMENDED: DMP default record 423 *._smtp-client.${DOMAINNAME} TXT "dmp=deny" 424 ;OPTIONAL: DMP records 425 ${REVERSEDIP_1}.in-addr._smtp-client.${DOMAINNAME}. TXT "dmp=allow" 426 ${REVERSEDIP_2}.in-addr._smtp-client.${DOMAINNAME}. TXT "dmp=allow" 427 [...] 428 ${REVERSEDIP_N}.in-addr._smtp-client.${DOMAINNAME}. TXT "dmp=allow" 430 ${REVERSEDIP_N} represents the IPv4 address in reverse-dotted-quad 431 order. For example, the IPv4 address 192.0.2.1 would become 432 "1.0.168.192" in reverse-dotted-quad order, as used in IN-ADDR.ARPA. 434 5.2 Example Designations by IPv4 Address 436 Here is an example portion of a DNS zone file for example.com, where 437 the hosts at IPv4 addresses 192.0.2.10 and 192.0.2.110 are the 438 Designated Mailers for example.com: 440 $ORIGIN example.com. 441 _smtp-client TXT "dmp=" 442 *._smtp-client TXT "dmp=deny" 443 10.2.0.192.in-addr._smtp-client TXT "dmp=allow" 444 110.2.0.192.in-addr._smtp-client TXT "dmp=allow" 446 Here is an example of example.com designating a rack of load 447 balancing hosts in the network of 192.0.2.0/24 as Designated 448 Mailers: 450 $ORIGIN example.com. 451 _smtp-client TXT "dmp=" 452 *._smtp-client TXT "dmp=deny" 453 *.2.0.192.in-addr._smtp-client TXT "dmp=allow" 455 Here is an example of example.com stating that no SMTP traffic will 456 originate from their domain: 458 $ORIGIN example.com. 459 _smtp-client TXT "dmp=" 460 *._smtp-client TXT "dmp=deny" 462 Finally, here is an example of a stand-alone host with its own Fully 463 Qualified Domain Name, "lonehost.example.com": 465 $ORIGIN example.com. 466 lonehost A 192.0.2.1 467 _smtp-client.lonehost TXT "dmp=" 468 *._smtp-client.lonehost TXT "dmp=deny" 469 1.2.0.192.in-addr._smtp-client.lonehost TXT "dmp=allow" 471 Alternately: 473 $ORIGIN lonehost.example.com. 474 @ A 192.0.2.1 475 _smtp-client TXT "dmp=" 476 *._smtp-client TXT "dmp=deny" 477 1.2.0.192.in-addr._smtp-client TXT "dmp=allow" 479 5.3 By Internet Protocol v6 (IPv6) Address 481 We can trivially extend the Protocol to identify authorized IPv6 482 addressed hosts. The template for identifying IPv6 hosts as 483 Designated Mailers is identical to the template for IPv4, only using 484 reversed IPv6 addresses as part of the record names. 486 ;Required: DMP placeholder 487 _smtp-client.${DOMAINNAME} TXT "dmp=" 488 ;Recommended: DMP default record 489 *._smtp-client.${DOMAINNAME} TXT "dmp=deny" 490 ;Optional: DMP records 491 ${REVERSIPv6_1}.ip6._smtp-client.${DOMAINNAME}. TXT "dmp=allow" 492 ${REVERSIPv6_2}.ip6._smtp-client.${DOMAINNAME}. TXT "dmp=allow" 493 [...] 494 ${REVERSIPv6_N}.ip6._smtp-client.${DOMAINNAME}. TXT "dmp=allow" 496 ${REVERSIPv6_N} represents a reverse nybble of the IPv6 address as 497 used in ip6.arpa. For instance, The IPv6 address 498 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 becomes 499 "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". 501 The remainder of this document will use IPv4 addressing and records 502 in its examples. Aside from the template, the actions for IPv6 503 participants are identical to that of IPv4 participants. 505 6. Protocol Flowchart 507 The flowchart starts when the client issues the MAIL command. It 508 ends with an acknowledgement or error before the client issues the 509 RCPT command. 511 ==================================== 512 | Client issues MAIL FROM: command | 513 ==================================== 514 | 515 ============================================================= 516 | Server checks local Allow and Auth rules on connecting IP | 517 ============================================================= 518 | 519 ============================= 520 | Allowed or Authenticated? |-------Yes------------| 521 ============================= | 522 | | 523 | ============ 524 No | 250 OK | 525 | | Resume | 526 | | Normally | 527 | ============ 528 ======================================= 529 | Server performs DMP Protocol lookup | 530 ======================================= 531 | 532 ============= 533 | Response? |-----------|---------------|---------------| 534 ============= | | | 535 | | | | 536 Success Success NXDOMAIN or SERVFAIL 537 Valid DMP Record Valid DMP Record Not Valid DMP or | 538 "dmp=allow" "dmp=deny" No TXT RR Record | 539 | | | | 540 | | | | 541 | | ================ =============== 542 | | | Do I accept | | Do I accept | 543 | | | mail from | | mail from | 544 | | | non-DMP site?| | (possibly) | 545 | | | | |non-DMP site?| 546 | | ================ =============== 547 | | | | 548 | | |---No--------| |---| 549 | | | | | | 550 | | | Yes Yes No 551 | | | | | | 552 | | | =================== | | 553 | | | | Server Performs | | | 554 | | | | dmp= lookup | | | 555 | | | =================== | | 556 | | | | | | 557 | | | =================== | | 558 | | | | dmp= found? | | | 559 | | | =================== | | 560 | | | | | | 561 | | | |-Yes------| | | 562 | | | | | | | 563 | | | | No | | 564 | | | | | | | 565 | | | | | |--------| | 566 | | | | | | | 567 =========== ============= =========== ============== 568 | 250 OK | | 550 ERROR | | 250 OK | | 451 ERROR | 569 | Resume | | Need DMP | | Resume | | Cannot see | 570 | Normally| | Records | | Normally| | DMP records| 571 =========== ============= =========== ============== 573 Designated Mailers Protocol uses error code 550 for a permanent 574 error, indicating a policy reason, and 451 for a temporary error, 575 indicating a local processing error. Error code 451 is the only 576 temporary error response allowed to the MAIL command. [n3] 578 Previous drafts eliminated this second Protocol lookup to determine 579 if a domain participates or not. Because of discoveries in testing 580 this had to be restored. However, there are ways to avoid 581 performing this lookup; see Appendix B. 583 Participating servers MAY bypass the Protocol altogether for chosen 584 addresses, for instance, their "allow relay" list for client IPs, or 585 for client IPs running a Mail User Agent that supports some form of 586 authentication for sending email. Example authentication protocols 587 include POPAUTH, SMTP AUTH, client certificates and so on. Doing 588 this avoids requiring dynamically created records for dial-up users 589 and roaming users. 591 When a non-participating client connects to a participating server, 592 it SHOULD respond as though the Protocol didn't exist. However, as 593 the Protocol gains acceptance, it MAY respond as its operators wish. 594 For instance, the server MAY refuse email until the senders 595 participate in the Protocol, or accept the message and include 596 additional headers in the message to inform the recipient. 598 7. Example SMTP Conversations 600 These examples introduce new error conditions in the SMTP or ESMTP 601 protocol after the MAIL command. RFC 2821 section 4.3.2 states this 602 is allowed. [n3] 604 An example of a successful SMTP session between hosts in 605 participating domains: 607 S: 220 mail.example.net MMS SMTPRCV service v0.95 608 C: HELO clientmachine.example.com 609 S: 250 mail.example.net Hello clientmachine.example.com [192.0.2.1] 610 C: MAIL FROM: 611 (server looks up 1.2.0.192.in-addr._smtp-client.example.com and 612 receives "dmp=allow") 613 S: 250 OK client at 192.0.2.1 verified as authorized sender for 614 example.com 615 [resume normally] 617 An example of a rejected (dmp=deny) session from an undesignated 618 host claiming to be part of a participating domain to a 619 participating host: 621 S: 220 mail.example.net MMS SMTPRCV service v0.95 622 C: HELO not-clientmachine.example.com 623 S: 250 mail.example.net Hello not-clientmachine.example.com 624 [192.0.2.1] 625 C: MAIL FROM: 626 (server looks up 1.2.0.192.in-addr._smtp-client.example.com and 627 receives "dmp=deny") 628 S: 550 ERROR client at 192.0.2.1 is not a Designated Mailer for 629 example.com 630 C: RCPT TO: 631 S: 550 ERROR must issue MAIL FROM: command first 632 C: DATA 633 S: 554 ERROR must issue MAIL FROM: and RCPT TO: first 635 An example of a rejected (NXDOMAIN and dmp=) session from an 636 undesignated host claiming to be part of a participating domain, 637 only where the first lookup returns NXDOMAIN: 639 S: 220 mail.example.net MMS SMTPRCV service v0.95 640 C: HELO not-clientmachine.example.com 641 S: 250 mail.example.net Hello not-clientmachine.example.com 642 [192.0.2.1] 643 C: MAIL FROM: 644 (server looks up 1.2.0.192.in-addr._smtp-client.example.com and 645 returns NXDOMAIN) 646 (server looks up _smtp-client.example.com and receives "dmp=") 647 S: 550 ERROR client at 192.0.2.1 is not a Designated Mailer for 648 example.com 650 An example of a successful session from a host belonging to a 651 non-participating domain (NXDOMAIN), where the participating server 652 acts as though the protocol didn't exist: 654 S: 220 mail.example.net MMS SMTPRCV service v0.95 655 C: HELO not-clientmachine.example.com 656 S: 250 mail.example.net Hello not-clientmachine.example.com 657 [192.0.2.1] 658 C: MAIL FROM: 659 (server looks up 1.2.0.192.in-addr._smtp-client.example.com and 660 returns NXDOMAIN) 661 (server looks up _smtp-client.example.com and returns NXDOMAIN) 662 S: 250 OK, mail from user@example.com. 663 [resume normally] 665 An example of a rejected (NXDOMAIN) session from a host belonging to 666 a non-participating domain, where the participating server refuses 667 SMTP traffic from non-participating domains: 669 S: 220 mail.example.net MMS SMTPRCV service v0.95 670 C: HELO not-clientmachine.example.com 671 S: 250 mail.example.net Hello not-clientmachine.example.com 672 [192.0.2.1] 673 C: MAIL FROM: 674 (server looks up 1.2.0.192.in-addr._smtp-client.example.com and 675 returns NXDOMAIN) 676 (Note that, in this case, a lookup for _smtp-client.example.com 677 isn't necessary) 678 S: 550 ERROR cannot verify 192.0.2.1 as sender for example.com. 680 An example of a failed (SERVFAIL) session from a host belonging to, 681 possibly, a non-participating domain, where the participating server 682 refuses SMTP traffic from, possibly, non-participating domains: 684 S: 220 mail.example.net MMS SMTPRCV service v0.95 685 C: HELO not-clientmachine.example.com 686 S: 250 mail.example.net Hello not-clientmachine.example.com 687 [192.0.2.1] 688 C: MAIL FROM: 689 (server looks up 1.2.0.192.in-addr._smtp-client.example.com and 690 returns SERVFAIL) 691 (Note that, in this case, a lookup for _smtp-client.example.com is 692 not necessary) 693 S: 451 ERROR cannot verify 192.0.2.1 as sender for example.com at 694 this time. 696 A DNS outage may be responsible for a SERVFAIL response. For this 697 reason, participating servers MUST use a 451 error message 698 indicating a temporary failure, and not a 550 series message 699 indicating a permanent failure, when any lookup returns SERVFAIL. 700 This is a separate and distinct condition from where the server can 701 determine (through a NXDOMAIN response) that the client is not from 702 a participating domain. 704 8. Mail Forwarding 706 Mail forwarding without altering the sender envelope in the MAIL 707 command becomes difficult with the Designated Mailers Protocol. The 708 host acting as the forwarding agent rarely is a Designated Mailer 709 for the sender's domain. This section covers how to accommodate 710 mail forwarding under the Protocol. 712 8.1 Authorized Mail Relay 714 Most mail user agents (MUAs) use an external SMTP server as a relay 715 agent or "outgoing mail server." The MUA's IP address is almost 716 never a Designated Mailer for the sender's domain. 718 The relaying MTA only has to use their "Allow Relay" list or an 719 authentication mechanism to permit SMTP traffic from the MUA, as is 720 accepted practice. [i5] Hosts running MUAs do not need their own DMP 721 records if they use a relay or smart host that has them. 723 8.2 Secondary Mail Exchangers 725 Larger Internet providers use a network of peer mail exchangers and 726 directly inject email from the peer into their internal mail system, 727 so these are largely unaffected. Smaller providers use a single 728 Primary host and one or more Secondary hosts as relays to the 729 Primary, and the Secondary is almost never a Designated Mailer for a 730 sender's domain. 732 Participants in the Protocol that use Secondary mail exchangers can 733 use one of several ways to accept mail from their Secondary hosts 734 again. Here are two possibilities: 736 - Add the Secondary host's IP address to the Primary's "Allow 737 Relay" list, similar to 8.1 above. 738 - Program the Secondary to alter the sender envelope, and 739 designate the Secondary as a Designated Mailer for itself, similar 740 to 5.2 above. An altered sender envelope could contain the 741 original sender's information, for instance including the original 742 sender envelope directly: 744 MAIL FROM: 746 ...or encode the original sender into the new sender envelope 747 somehow, such as with a two-way hash: 749 MAIL FROM:<236FA24C@secondarymx.example.net> 751 Whatever method is used, a Secondary MUST return mail back to the 752 sender if the Primary rejects it. 754 This author understands that most MTAs relaying as a Secondary do 755 not modify the sender envelope. While modifying the envelope is 756 more secure, adding a Secondary to the Primary's "allow" list is 757 acceptable. 759 8.3 Mailing List Servers 761 Some list server implementations use the original envelope sender 762 when forwarding mail from a sender to the list members, but most 763 modern list software alters or replaces the sender envelope somehow. 764 For example, list software uses the list-owner address in the sender 765 envelope. 767 Maintainers of mailing lists that do not alter the sender envelope 768 SHOULD NOT to participate in the Protocol until they upgrade their 769 mailing list software. 771 8.4 Mail Forwarding such as .forward files on *ix systems 773 This author recognizes that every MTA using .forward files on *ix 774 hosts or similar configurations do not alter the sender envelope 775 when forwarding mail. However, commercial and proprietary mail- 776 forwarding systems such as mail.com[tm] alter the sender envelope, 777 and these are by far the most popular pure mail-forwarding 778 instances. 780 There is no fix for .forward usage aside from altering the sender 781 envelope and designating the forwarding host as a Designated Mailer 782 for itself, as described in 5.2 above. 784 8.5 SMTP Source Routing 786 While depreciated, few SMTP sites still support source routing. 787 Consider the following sender envelope: 789 MAIL FROM:<@host.one,@host.two:user@host.three> 791 If a participating site supports source routing, the site SHOULD 792 perform its Protocol lookup on "host.one" as the client should be 793 from that domain. Otherwise, the site MUST perform its Protocol 794 lookup on "host.three". 796 9. Accepting Mail from the Null Sender Envelope: MAIL FROM:<> 798 As there is no domain to perform a DMP Protocol lookup in a Null 799 Sender envelope, it is difficult to tell if the sender of such a 800 message is authorized to do so. However, there are other ways to 801 ensure the sender is authorized to send it. 803 According to RFC 2821 section 4.5.5 [n4], the Null reverse-path 804 accompanies Delivery Status Notifications, Message Disposition 805 Notifications, and other messages which are notifications about 806 previous, non-null-enveloped messages. These types of messages are 807 always generated by mail delivery software only, and not by users. 809 We can ensure that null reverse-path messages only come from hosts 810 running MTAs and not from users. The simplest is to make the sender 811 host a Designated Mailer for itself as described in 5 and 5.2 above. 812 To strengthen this, a recipient server MAY inspect the forward or 813 reverse DNS records, or both, on the client host's HELO or EHLO 814 identifier: 816 S: 220 mail.example.net MMS SMTPRCV service v0.95 817 C: HELO clientmachine.example.com 818 S: 250 mail.example.net Hello clientmachine.example.com [192.0.2.1] 819 C: MAIL FROM:<> 820 (server looks up 821 1.2.0.192.in-addr._smtp-client.clientmachine.example.com and 822 receives "dmp=allow") 823 (optional: server looks up clientmachine.example.com and receives 824 192.0.2.1, compares A RR record to connecting IP address and they 825 match) 826 (optional: server looks up 1.2.0.192.in-addr.arpa for PTR and 827 receives clientmachine.example.com, compares PTR RR record to HELO'd 828 name and they match) 829 S: 250 OK Null reverse-path message coming from 830 clientmachine.example.com 832 With the exception of using the HELO or EHLO host name as the domain 833 to perform the DMP lookup on, and the optional comparisons suggested 834 above, the flowchart for handling null reverse-path messages is 835 identical to that for handing other messages. 837 Note that a HELO or EHLO host name is not necessarily a mail domain. 838 DMP only treats it as one for the purpose of performing a Protocol 839 lookup, and only for messages with null reverse-paths. 841 10. Security Considerations 843 10.1 DNS Security 845 Designated Mailers Protocol relies solely on DNS to verify 846 Designated Mailer hosts. Any compromise of a domain's DNS records 847 would make that domain vulnerable to "spoofing" in a run by 848 spammers, but the spammers would need to insert necessary name 849 records into your DNS zone. Likewise, a compromised server at the 850 tier below a domain could allow spammers to insert false Designated 851 Mailer records for that domain. Best current practices for DNS 852 server security will prevent these and similar abuses. DMP records 853 may reside on DNSSEC servers without changes to the Protocol. 855 10.2 Mail Transfer Agent Security 857 Compromised hosts already identified as Designated Mailers may be 858 used to send unauthorized email in the name of the designator's 859 domain. Best current practices for SMTP MTAs in general will prevent 860 these and similar abuses. 862 10.3 DNS Outages 864 A domain may still be successfully spoofed if the sender domain's 865 records are unreachable (SERVFAIL), AND if the participating server 866 accepts SMTP traffic from, possibly, non-participating domains. 867 Participating sites SHOULD refuse SMTP traffic based on this case, 868 using a 400 series error indicating a temporary failure, even if 869 they choose to accept SMTP traffic from domains that decidedly not 870 (NXDOMAIN) participate, to avoid this. 872 10.4 Answering RFC 2821 7.1: Mail Security and Spoofing 874 From 7.1 of RFC 2821 [n5]: 876 Efforts to make it more difficult for users to set envelope return 877 path and header "From" fields to point to valid addresses other 878 than their own are largely misguided: they frustrate legitimate 879 applications in which mail is sent by one user on behalf of 880 another or in which error (or normal) replies should be directed 881 to a special address. 883 [...] 885 This specification does not further address the authentication 886 issues associated with SMTP other than to advocate that useful 887 functionality not be disabled in the hope of providing some small 888 margin of protection against an ignorant user who is trying to 889 fake mail. 891 Designated Mailers Protocol still allows a user to send mail on 892 behalf of another within the same domain. It also still allows 893 mailing list systems to send mail to subscribers on behalf of other 894 subscribers in different domains. 896 DMP does not affect the From or Reply-to headers, or body of a 897 message. It still allows sending mail on behalf of another, while 898 using an envelope authorized for use within the sender's domain. 900 We are no longer looking at one or two ignorant users trying to fake 901 mail. Today we are looking at an entire industry built on the 902 unwilling backs of recipients, based on several hundreds of 903 thousands of deliberately ignorant users who fake mail for fun and 904 profit. This author can live with losing a little otherwise-useful 905 functionality for a very large margin of protection against them. 907 Appendix A: Why the Default Record was Restored 908 Those who have followed the Protocol's development to this point 909 will note that this author tried to eliminate the need for more than 910 one DNS query using DNS wildcard records. Testing revealed an 911 inconsistency between implementations of DNS concerning wildcards. 913 RFC 1034 4.3.2 [n3] describes the algorithm with which DNS servers 914 are to parse a name record file. That algorithm allows for wildcard 915 nodes, but allows for sub-nodes below the wildcard in the DNS tree 916 to override the wildcard. For instance, with the following name 917 records in place: 919 $ORIGIN _smtp-client.example.com. 920 * TXT "dmp=deny" 921 1.2.0.192.in-addr TXT "dmp=allow" 923 ...a lookup of x.x.x.192.in-addr._smtp-client.example.com (where "x" 924 could be any RFC 1034-legal string) would return NXDOMAIN, and not 925 the originally intended default record of "dmp=deny". A lookup of 926 other records outside *.192 would return the intended default 927 record. 929 This is clearly defined in RFC 1034, and later clarified in a 930 work-in-progress titled draft-ietf-dnsext-wcard-clarify-00.txt. 931 However, most DNS server implementations treat a wildcard record of 932 this nature as override ALL other possible lookups that aren't 933 explicitly defined, such as 1.1.168.192 above. 935 This author had to restore the second lookup in order to accommodate 936 RFC 1034's requirements, and not depend on any specific 937 implementation's algorithm. This is in spite of an overwhelming 938 number of DNS sites that violate RFC 1034 4.3.2 in this author's 939 favour. However, this change effectively eliminates the need for 940 wildcard records, avoiding the wildcard problem entirely. 942 Sites that participate in the Protocol may choose DNS 943 implementations that work to their best advantage, so they can 944 reduce the number of maintained records. However, no one DNS 945 implementation is required to participate. 947 Appendix B: How to Avoid Looking Up the Default Record 949 The second Protocol lookup, originally introduced in the first draft 950 and restored in this draft, will impact the DNS system harder at 951 first. This author expects this impact will diminish as sites adopt 952 the Protocol. 954 However, participating sites and MTA authors can take steps to avoid 955 performing this lookup immediately. For example: 957 - A participating MTA MAY maintain a list of domains known to 958 participate. As the MTA retrieves "dmp=allow" from participating 959 domains, it could store the domain name in a local list to check 960 against in case future Protocol lookups on the domain return 961 NXDOMAIN. The lifetime for storing this record COULD be as long as 962 the DNS record's lifetime as returned by the participating site's 963 DNS server. 964 - A participating site's DNS server COULD use a DNS implementation 965 that treats wildcard records slightly differently from RFC 1034 966 4.3.2, that is, allow the wildcard to substitute for any node not 967 explicitly defined in the DNS zone file. 968 - Over time, participating sites MAY choose to bypass this second 969 lookup altogether. This will depend on the adoption rate of DMP. 971 Appendix C: Stupid Spammer Tricks 973 C.1: Bogus Subdomains 975 If example.com participates in the Protocol, a spammer could still 976 spoof a subdomain of example.com. Sites that accept mail from 977 non-DMP sites could accept mail from the spammer. 979 Already, spam-aware MTAs could perform MX and A RR lookups on the 980 domain in the MAIL FROM: command, to ensure that the domain exists 981 and normally handles SMTP. This kind of check could occur before 982 any DMP lookup. 984 Of course, as DMP is adopted, a participating site could refuse mail 985 from non-DMP sites, eliminating this problem entirely. 987 References 989 n1. Bradner, S., "Key words for use in RFCs to Indicate Requirement 990 Levels", BCP 14, RFC 2119, March 1997 992 n2. Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 993 1034, November 1987 995 n3. 4.3.2 of Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 996 April 2001 998 n4. 4.5.5 of Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 999 April 2001 1001 n5. 7.1 of Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1002 April 2001 1004 i1. Credit where due: B. Gingery first brought up the topic on the 1005 SPAM-L mailing list, and it had been discussed earlier on the 1006 Spamtools mailing list. There are other documents describing 1007 similar approaches to this problem. 1009 i2. Gulbrandsen, A., Vixie, P., Esibov, L., "A DNS RR for specifying 1010 the location of services (DNS SRV)", RFC 2782, February 2000 1012 i3. Rosenbam, R., "Using the Domain Name System To Store Arbitrary 1013 String Attributes", RFC 1464, May 1993 1015 i4. Derek J. Balling for initial design of the 1016 DNS record template and explanation, and "der Mouse" 1017 for generalizing it into the 1018 current form. 1020 i5. 2.1 of Lindenberg, G., "Anti-Spam Recommendations for SMTP 1021 MTAs", RFC 2505, February 1999 1023 Acknowledgments 1025 Derek J. Balling for initial design of the DNS 1026 record template and explanation, and "der Mouse" 1027 for generalizing it into the current 1028 form. 1030 Michael A. Smith for the hint to RFC 1464. 1032 Jack Bates for SMTP Source Routing hints. 1034 Steve Atkins and Bill Cole for DNS hints. 1036 "der Mouse" for IPv6 hints and implementation testing. 1038 "Zefram" for first uncovering the wildcard problem, and everyone 1039 else already mentioned for detailing it. 1041 Author's Addresses 1043 Gordon Fecyk 1044 Pan-Am Internet Services 1045 24 - 482 Young Street 1046 Winnipeg, MB R3B 2S6 1047 Canada 1048 Phone: (204) 292-9970 1049 Email: gordonf@pan-am.ca 1051 Full Copyright Statement 1053 Copyright (C) The Internet Society (2003). All Rights Reserved. 1055 This document and translations of it may be copied and furnished to 1056 others, and derivative works that comment on or otherwise explain it 1057 or assist in its implementation may be prepared, copied, published 1058 and distributed, in whole or in part, without restriction of any 1059 kind, provided that the above copyright notice and this paragraph 1060 are included on all such copies and derivative works. However, this 1061 document itself may not be modified in any way, such as by removing 1062 the copyright notice or references to the Internet Society or other 1063 Internet organizations, except as needed for the purpose of 1064 developing Internet standards in which case the procedures for 1065 copyrights defined in the Internet Standards process must be 1066 followed, or as required to translate it into languages other than 1067 English. 1069 The limited permissions granted above are perpetual and will not be 1070 revoked by the Internet Society or its successors or assigns. 1072 This document and the information contained herein is provided on an 1073 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1074 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1075 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1076 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1077 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."