Internet Draft G. Fecyk Pan-Am Internet Services Document: draft-fecyk-dmp-01.txt Expires: April 2004 December 2003 Designated Mailers Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC 2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes the Designated Mailers Protocol (DMP); a proposal for identifying computer systems authorized to act as Simple Mail Transfer Protocol (SMTP) clients for an e-mail domain. Conventions used in this document "Client" refers to a host creating a network session with a server. Clients may also be servers in real implementations. "Server" refers to a host accepting a network session from a client as defined above. In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "Domain" refers to both a domain in the RFC 1034 sense [RFC 1034] and in the portion of an e-mail address after the "@" sign. Fecyk Expires - April 2004 [Page 1] Designated Mailers Protocol December 2003 In examples, clients act on behalf of the fictitious domain "example.com" or "example.org". Servers act on behalf of the fictitious domain "example.net". Internet Protocol v4 address examples come from the non-routable network 192.0.2.0/24. Example records use the format described in RFC 1034 section 3.6.1. The $ORIGIN keyword is used to shorten example record names. This example describes "recordname.example.com." as two lines: $ORIGIN example.com. recordname TXT "this is a test" The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. Table of Contents 1. Introduction...................................................3 2. The Argument for Authenticating Incoming E-mail by Domain......3 3. Changes Since Last Revision....................................4 4. DMP Record Format and Designating SMTP Clients.................4 4.1 Example DMP Records by Internet Protocol v4 Address........6 4.2 Example DMP Records by Internet Protocol v6 Address........6 5. Querying for DMP Records and Recommended Actions...............7 5.1 RECOMMENDED Flowchart......................................8 5.2 Participating Domain's User and Client....................11 5.3 Participating Domain's User, Forwarding Service on Participating Client..........................................11 5.4 Null Reverse Path, Participating Client...................12 5.5 Non-Participating Domain's User, Non-Participating Client where Server permits Non-Participating Domains................12 5.6 Null Reverse Path, Non-Participating Client where Server permits Non-Participating Domains.............................12 5.7 Participating Domain's User and Client where DMP lookup fails (SERVFAIL)....................................................13 5.8 Participating Domain's User, Not Participating Domain's Client (dmp=deny, NXDOMAIN)...................................13 6. Other Actions Permitted.......................................13 7. SMTP Source Routing...........................................14 8. Network Overhead and Effectiveness............................14 9. Security Considerations.......................................15 9.1 DNS Security..............................................15 9.2 Mail Transfer Agent Security..............................15 9.3 "Global Wildcard" DMP Records.............................15 Appendix A. Answers to Common Questions and Concerns.............16 A.1 Does DMP cause some mailing lists and clients that forward e- mail to be refused?...........................................16 Fecyk Expires - April 2004 [Page 2] Designated Mailers Protocol December 2003 A.2 How does DMP affect SMTP clients on dynamically configured hosts?........................................................16 Appendix B: Proposed Extensions to DMP...........................17 B.1 Designating Another Domain's Mailers......................17 B.2 Identifying the Role of Domain, Host or Forwarder.........18 References.......................................................18 Contributors.....................................................19 Author's Addresses...............................................20 Full Copyright Statement.........................................20 1. Introduction Designated Mailers Protocol is a proposal to identify computers authorized to act as Simple Mail Transfer Protocol (SMTP) [RFC 2821] clients in the name of a domain. Mail Transfer Agents (MTAs) that look up DMP records may refuse mail from sources not identified in DMP records. This reduces the amount of "spoofed" mail the MTA accepts in the name of a domain. A domain publishes DMP records in the Domain Name System (DNS) [RFC 1034]. This ensures control remains with the domain's administrators, and allows the MTA using DMP to take advantage of DNS record caching to reduce the amount of network overhead that DMP queries require. DMP uses the TXT Resource Record type, which works without modifying existing DNS software. DMP does not rely on any DNS records other than the DMP records themselves, nor does it rely on information stored in the e-mail body, including headers. This avoids problems identifying SMTP clients by Address (A), Mail Exchange (MX) or Pointer (PTR) records where the sending domain's administrators may not have control over them. This also avoids blocking otherwise useful functionality of SMTP, such as sending mail on behalf of another user. DMP is an OPTIONAL extension to SMTP. DMP supports Extended SMTP (ESMTP) and supports all SMTP functionality, including forwarding, delivery status notifications, and so on, while providing a domain with this control. 2. The Argument for Authenticating Incoming E-mail by Domain Junk e-mailers routinely falsify sender envelopes in order to misdirect complaints about their junk e-mail, resulting in an industry consisting of users who fake mail for fun and profit. Authors of viruses that propagate via e-mail falsify sender envelopes to hide the origins of the virus-infected computers. Fecyk Expires - April 2004 [Page 3] Designated Mailers Protocol December 2003 Confidence artists, posing as members of popular domains, routinely attempt to obtain confidential information from unsuspecting victims. Designated Mailers Protocol reduces the impact of "spoofing" the source of an e-mail message. DMP is not as strong as cryptographic based authentication, but it is easier to implement and does not require dramatic changes to e-mail software. DMP does not prevent e-mail with solely a falsified mailbox name, but it allows the administrators of a domain to audit such e-mail, by ensuring only its own computers may send mail on behalf of the domain. 3. Changes Since Last Revision The format of DMP records used since the last Internet-Draft (draft- fecyk-dsprotocol-04.txt) has not changed. DMP now incorporates design elements of the Designated Relays Inquiry Protocol, a work-in-progress by Raymond S Brand and others (See Contributors section). Notably, DMP provides for a second tier of inspection, permitting e-mail forwarded through certain types of mail forwarding protocols. Receiving domain administrators may choose any combination of outcomes based on the DMP query results. The -01 revision corrects grammatical problems and clarifies some of the wording. 4. DMP Record Format and Designating SMTP Clients DMP records of a domain MUST appear in a sub-domain "_smtp-client". From there, records MUST appear in sub-domains identified by protocol type, such as "in-addr" for IPv4 and "ip6" for IPv6. Further sub-domains will appear because of designating hosts and networks as allowed to send e-mail on behalf of the sender's domain. DMP records use the TXT Resource Record type. All DNS software supports this record type and it may store arbitrary values. DMP uses the format defined in [RFC 1464]. An algorithm that looks up RFC 1464 style records MAY be used but is NOT REQUIRED. A participating domain MUST publish these minimum records. ; REQUIRED: DMP Participant Identifier _smtp-client.$DOMAINNAME. TXT "dmp=" Fecyk Expires - April 2004 [Page 4] Designated Mailers Protocol December 2003 ; RECOMMENDED: Default DMP response for servers supporting wildcards *._smtp-client.$DOMAINNAME. TXT "dmp=deny" The first record identifies the domain, $DOMAINNAME, as a participant with its own designated mailer hosts. The second is a RECOMMENDED record that provides a default response to queries. If there are no additional DMP records, the domain effectively publicizes that they do not send SMTP traffic. A participating domain sending SMTP traffic MUST publish one or more additional records identifying the networks or network addresses permitted to send SMTP traffic for their domain. $REV-ADDRESS.$ADDRESS-TYPE._smtp-client.$DOMAINNAME. TXT "dmp=allow" $REV-ADDRESS is the host or network's address represented in reverse form, as used in in-addr.arpa or ip6.arpa. $ADDRESS-TYPE is the type of address, such as "in-addr" for IPv4 or "ip6" for IPv6. DMP supports any network protocol that supports address-to-name mapping in the DNS. DMP uses the keywords "allow" and "deny" for their English meanings. Record contents are case-insensitive, so "DMP=ALLOW" means the same as "dmp=allow". DMP records MAY use wildcards, if the DNS server software supports them, to publish fewer records, publish records for sub-domains, or for other purposes. As not all DNS software supports wildcards, or may handle wildcards differently, wildcards are NOT REQUIRED. Domains publishing DMP records MUST also publish DMP records for each sending host's Fully Qualified Domain Name (FQDN). This identifies the host as being permitted to send mail with null reverse paths (MAIL FROM:<>) and also being permitted to forward mail, where the sender's domain may not otherwise designate this host. ; REQUIRED: Default DMP record for hosts _smtp-client.$FQDN. TXT "dmp=" ; REQUIRED: One or more DMP records identifying the host's network address or addresses $REV-ADDRESS-1.$ADDRESS-TYPE._smtp-client.$FQDN. TXT "dmp=allow" $REV-ADDRESS-2.$ADDRESS-TYPE._smtp-client.$FQDN. TXT "dmp=allow" ; [...] $REV-ADDRESS-N.$ADDRESS-TYPE._smtp-client.$FQDN. TXT "dmp=allow" ; RECOMMENDED: Default DMP lookup result *._smtp-client.$FQDN. TXT "dmp=deny" Fecyk Expires - April 2004 [Page 5] Designated Mailers Protocol December 2003 4.1 Example DMP Records by Internet Protocol v4 Address The domain example.com designates two IPv4 addresses as allowed to send mail for example.com: $ORIGIN example.com. _smtp-client TXT "dmp=" *._smtp-client TXT "dmp=deny" 1.2.0.192.in-addr._smtp-client TXT "dmp=allow" 2.2.0.192.in-addr._smtp-client TXT "dmp=allow" The domain example.com designates the IPv4 network 192.0.2.0/24 as allowed to send mail for example.com: $ORIGIN example.com. _smtp-client TXT "dmp=" *._smtp-client TXT "dmp=deny" *.2.0.192.in-addr._smtp-client TXT "dmp=allow" The host sender.example.com designates its IPv4 address at 192.0.2.1: $ORIGIN example.com. _smtp-client.sender TXT "dmp=" *._smtp-client.sender TXT "dmp=deny" 1.2.0.192.in-addr._smtp-client.sender TXT "dmp=allow" 4.2 Example DMP Records by Internet Protocol v6 Address The domain example.com designates two IPv6 addresses as allowed to send mail for example.com: $ORIGIN example.com. _smtp-client TXT "dmp=" *._smtp-client TXT "dmp=deny" 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. _smtp-client TXT "dmp=allow" 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. _smtp-client TXT "dmp=allow" The host sender.example.com designates its own IPv6 address 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0: $ORIGIN example.com. _smtp-client.sender TXT "dmp=" *._smtp-client.sender TXT "dmp=deny" 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. _smtp-client.sender TXT "dmp=allow" Fecyk Expires - April 2004 [Page 6] Designated Mailers Protocol December 2003 5. Querying for DMP Records and Recommended Actions A server looking up DMP records queries on the following information provided by the client: . Connecting network address and Domain part of the sender envelope (MAIL FROM:<>) or . Connecting network address and HELO or EHLO identifier. The HELO or EHLO identifier MUST be the client host's Fully Qualified Domain Name (FQDN). The layout of the DMP records allows the server to query the address and domain or FQDN with a single DNS query. The result will be one of four possibilities: . A successful query, and one or more returned TXT records, at least one of which will contain the string "dmp=allow", meaning this client is permitted to send mail on behalf of this domain or FQDN, . A successful query, and one or more returned TXT records, at least one of which will contain the string "dmp=deny", meaning this client is NOT permitted to send mail on behalf of this domain or FQDN, . A query that returns NXDOMAIN, or a query that returns no DMP records or multiple and conflicting DMP records (such as two TXT records, one reading "dmp=allow" and one reading "dmp=deny"), indicating this client does not have a valid DMP record in the domain or FQDN, or . A query that returns SERVFAIL, indicating a temporary error. A server MAY perform an additional query to determine if a domain or FQDN participates in DMP. The result will be one of three possibilities: . A successful query, and one or more returned TXT records, one or more of which will contain only the string "dmp=", indicating this domain or FQDN participates in DMP, . A query that returns NXDOMAIN, or a query that returns no DMP records or multiple and conflicting DMP records (such as one record containing "dmp=" and another containing "dmp=allow" or "dmp=deny" or "dmp=[something else]", indicating the domain does not participate in DMP, or has invalid DMP records, or, . A query that returns SERVFAIL, indicating a temporary error. A server using DMP MAY bypass DMP lookups entirely, for reasons defined by the server's operators. Examples include the client connecting from a network address in an "allow relay" list, a client authenticating using another protocol such as SMTP AUTH, and other Fecyk Expires - April 2004 [Page 7] Designated Mailers Protocol December 2003 reasons. This allows client-only hosts and Mail User Agents (MUAs) to use these servers without requiring their own DMP records. Once a server has DMP query results, the server may act on the message envelope in many ways. The following flowchart demonstrates the RECOMMENDED paths. The chart starts when the client issues the HELO or EHLO command, and ends when the server responds to the MAIL FROM command. Responses allowed to MAIL FROM are from RFC 2821 section 4.3.2. . 250 indicating either HELO/EHLO or MAIL FROM were acceptable . 451 indicating a local processing error (such as SERVFAIL) . 550 indicating a rejection based on policy (in this case, the DMP query results and the server's settings determine the policy) 5.1 RECOMMENDED Flowchart ============================== | Client issues HELO or EHLO | ============================== | ========================================= | Server stores HELO or EHLO identifier | | and responds normally | ========================================= | ============================== | Client issues MAIL command | ============================== | /------------------------------------------------\ | Is the client's address allowed to bypass DMP? | \------------------------------------------------/ | | Yes No | | | /-------------------------------------------\ | | Is the MAIL envelope null (MAIL FROM:<>)? | | \-------------------------------------------/ | | | | No Yes | | | | ============================== | | | Server performs DMP Lookup | | | | on envelope's domain | | | | and client network address | | | ============================== | | | | | | | Fecyk Expires - April 2004 [Page 8] Designated Mailers Protocol December 2003 | | | | | | | /---------------------\ | | | What is the result? | | | \---------------------/ | | | | | |-----------|-------|-------|------------| | | | | | | | | allow SERVFAIL NXDOMAIN deny | | | | or invalid | | | | | DMP | | | | | | | | | | | =================== | | | | | | Server performs | | | | | | | DMP domain-only | | | | | | | lookup | | | | | | =================== | | | | | | | | | | | /-----------------\ | | | | | | Lookup result? | | | | | | \-----------------/ | | | | | | | | | | | | | SERVFAIL NXDOMAIN Yes | | | | | | or invalid | | | | | | |----| DMP | | | | | | | | |-|| | | | | | | || | | | | | /----------------\ || | | | | | | Accept non-DMP | || | | | | | | domain? | || | | | | | \----------------/ || | | | | | | | || | | | | | Yes No || | | | | | | | || | | | | | (Go to) | || | | | | | (allow) | || | | | | | | | || | | | |------------------| |---||| | | | | | | ||| | | | | | | /----------------\ | | | | |---|| | Allow HELO as | | | | | || | alternative? | | | | | || \----------------/ | | | | || | | | | | | || No Yes | | | | || | | | | | | || | | | | | | || | | | | | | || | | | Fecyk Expires - April 2004 [Page 9] Designated Mailers Protocol December 2003 | | | || | | | | | | || | ======================= | | | || | | Server performs DMP | | | | || | | on HELO/EHLO FQDN | | | | || | | and client address | | | | || | ======================= | | | || | | | | | || | /----------------\ | | | || | | Lookup result? | | | | || | \----------------/ | | | || | | | | | | | | || | allow | | deny | | | || | | | | | | | | || | (go to) | | | | | | || | (allow) | | | | | ||--------------------------------| | | | | | || || | | | | | | || || | SERVFAIL | | | | || || | | | | | | || || | (go to) | | | | || || | (fail ) | | | | || |||------------------------| | | | | || ||| | | (go to) | | || ||| | | (deny ) | | || ||| | | | | | || ||| ||-------------------| | | || ||| || | | | || ||| || | | | || ||| || | | | || ||| || NXDOMAIN | | || ||| || or invalid | | || ||| || DMP | | || ||| || | | | || ||| || =================== | | || ||| || | Server performs | | | || ||| || | DMP HELO-only | | | || ||| || | FQDN lookup | | | || ||| || =================== | | || ||| || | | | || ||| || /----------------\ | | || ||| || | Lookup result? | | | || ||| || \----------------/ | | || ||| || | | | | | || ||| || SERVFAIL | | | | || ||| || | | | | | || ||| || (go to) | | | | || ||| || (fail ) | | | | || ||| || | | | | | || ||| || | | | Fecyk Expires - April 2004 [Page 10] Designated Mailers Protocol December 2003 | | || ||| || | | | | | || ||||-------------------| Yes | | | || |||| || | | | | || |||| |||----------| | | | || |||| ||| | | | || |||| ||| NXDOMAIN | | || |||| ||| or invalid | | || |||| ||| DMP | | || |||| ||| | | | || |||| ||| /----------------\ | | || |||| ||| | Accept non-DMP | | | || |||| ||| | domain AND is | | | || |||| ||| | envelope null? | | | || |||| ||| \----------------/ | | || |||| ||| | | | | || |||| ||| Yes No | | || |||| ||| | | | | || |||| ||| (go to) | | | || |||| ||| (allow) | | | || |||| ||| | | | | |||---------------------------------| | | | ||| |||| ||| | | | ||| |||| ||||--------------| | | ||| |||| |||| ====(allow)===== =====(fail)===== ====(deny)====== | Server sends | | Server sends | | Server sends | | 250 OK and | | 451 Temp Err | | 550 Policy | | resumes SMTP | | resumes SMTP | | resumes SMTP | ================ ================ ================ These examples use IPv4 addresses. The process is identical for other address types. 5.2 Participating Domain's User and Client S: 220 mail.example.net MMS SMTPRCV service v0.95 C: HELO sender.example.com S: 250 mail.example.net Hello sender.example.com [192.0.2.1] C: MAIL FROM: (server looks up 1.2.0.192.in-addr._smtp-client.example.com and receives "dmp=allow") S: 250 OK client at 192.0.2.1 verified as authorized sender for example.com [resume normally] 5.3 Participating Domain's User, Forwarding Service on Participating Client S: 220 mail.example.net MMS SMTPRCV service v0.9.5 Fecyk Expires - April 2004 [Page 11] Designated Mailers Protocol December 2003 C: HELO othersender.example.org S: 250 mail.example.net Hello othersender.example.org [192.0.2.5] C: MAIL FROM: (server looks up 5.2.0.192.in-addr._smtp-client.example.com and receives "dmp=deny") (server looks up 5.2.0.192.in-addr._smtp-client.othersender.example.org and receives "dmp=allow") S: 250 OK client at 192.0.2.5 verified as othersender.example.org [resume normally] 5.4 Null Reverse Path, Participating Client S: 220 mail.example.net MMS SMTPRCV service v0.95 C: HELO sender.example.com S: 250 mail.example.net Hello sender.example.com [192.0.2.1] C: MAIL FROM:<> (server looks up 1.2.0.192.in-addr._smtp-client.sender.example.com and receives "dmp=allow") S: 250 OK client at 192.0.2.1 verified as sender.example.com [resume normally] 5.5 Non-Participating Domain's User, Non-Participating Client where Server permits Non-Participating Domains S: 220 mail.example.net MMS SMTPRCV service v0.95 C: HELO sender.example.com S: 250 mail.example.net Hello sender.example.com [192.0.2.1] C: MAIL FROM: (server looks up 1.2.0.192.in-addr._smtp-client.example.com and returns with NXDOMAIN) (server looks up _smtp-client.example.com and returns NXDOMAIN) S: 250 OK client at 192.0.2.1 verified as sender.example.com [resume normally] 5.6 Null Reverse Path, Non-Participating Client where Server permits Non-Participating Domains S: 220 mail.example.net MMS SMTPRCV service v0.95 C: HELO sender.example.com S: 250 mail.example.net Hello sender.example.com [192.0.2.1] C: MAIL FROM:<> (server looks up 1.2.0.192.in-addr._smtp-client.sender.example.com and returns NXDOMAIN) S: 250 OK client not verified as sender.example.com [resume normally] Fecyk Expires - April 2004 [Page 12] Designated Mailers Protocol December 2003 5.7 Participating Domain's User and Client where DMP lookup fails (SERVFAIL) S: 220 mail.example.net MMS SMTPRCV service v0.95 C: HELO sender.example.com S: 250 mail.example.net Hello sender.example.com [192.0.2.1] C: MAIL FROM: (server looks up 1.2.0.192.in-addr._smtp-client.example.com and returns with SERVFAIL) S: 451 ERROR Cannot verify 192.0.2.1 as sender for example.com at this time [resume as though MAIL FROM had not occurred] A participating server SHOULD attempt the lookup more than once on a SERVFAIL before returning a 451 response. 5.8 Participating Domain's User, Not Participating Domain's Client (dmp=deny, NXDOMAIN) S: 220 mail.example.net MMS SMTPRCV service v0.95 C: HELO othersender.example.org S: 250 mail.example.net Hello othersender.example.org [192.0.2.7] C: MAIL FROM: (server looks up 7.2.0.192.in-addr._smtp-client.example.com and receives "dmp=deny") (server looks up 7.2.0.192.in-addr._smtp-client.othersender.example.org and returns NXDOMAIN) (server looks up _smtp-client.othersender.example.org and returns NXDOMAIN) S: 550 ERROR client at 192.0.2.7 may not send for example.com [resume as though MAIL FROM had not occurred] 6. Other Actions Permitted Servers querying DMP records MAY take other actions in addition to, or instead of, the actions recommended in Section 5. Such other actions include adding extra headers to e-mail that identify the DMP query results, so recipients may filter it with their client software. Server administrators MAY switch the order of lookups around, or omit some lookups, to suit their purposes. Domains and hosts with published DMP records provide receiving servers with the means to identify the publisher's permitted SMTP clients. What receiving servers' administrators do with this information is left to them. Fecyk Expires - April 2004 [Page 13] Designated Mailers Protocol December 2003 7. SMTP Source Routing While depreciated by RFC 2821, some Mail Transfer Agents support SMTP Source Routing, where the sender can define a path through which hosts the e-mail passes through. An example sender envelope, used in the MAIL command, may look like this: MAIL FROM:<@mta1.example.com,@mta2.example.com:user@example.com> If the receiving server supports source routing, it MAY perform its DMP lookups on the first domain or host specified, as this is where the client should be. In the above example, that would be mta1.example.com. Otherwise, the receiving server MUST perform its lookup on the last domain, in this case example.com. This is equivalent to the receiver querying only the HELO or EHLO host name of the client. 8. Network Overhead and Effectiveness In November 2003, volunteers provided MTA logs allowing a realistic measurement of DMP's impact. [LOGS] The test simulated published DMP records by using a test domain labeled "dmptest.invalid" published on a DNS server. The test domain did not contain wildcard records. The DMP lookup application measured the total size of the DNS query and response packets, minus the amount used to identify ".dmptest.invalid", and added the SMTP message size to this total upon an "allow" condition. The test used the combination of options that permitted the most mail: Allow mail from non-DMP domains and allow HELO/EHLO records to override a "deny" record from a domain. From these logs, and a sampling of 19791 domains over a period of eighteen months, came the following measurements. These measurements DID NOT take DNS caching (Time-to-live, or TTL) into account. DMP's network usage alone, compared to the bandwidth used by SMTP: . DMP caused an average additional 4.15% increase in bandwidth. . 12635 (63%) of domains sampled caused a 4.15% or less increase. . 6281 (33%) of domains sampled caused a 1% or less increase. Fecyk Expires - April 2004 [Page 14] Designated Mailers Protocol December 2003 DMP's network usage plus the reduction in SMTP bandwidth by refusing "spoofed" messages, compared to the bandwidth used by SMTP alone: . Frequently "spoofed" domains with correct DMP records used 10% to 20% LESS bandwidth, including the bandwidth used by DMP. . Less-frequently "spoofed" domains with correct DMP records used 0% to 1% more bandwidth. . Domains without correct DMP record sets used 1% to 4.15% or more bandwidth. DNS server caching, with reasonably high TTL values for DMP records, will reduce the network overhead caused by DMP dramatically. Even without considering TTL, popular domains with correct DMP record sets saved up to 20% in SMTP bandwidth, while costing those domains only 1% additional bandwidth, or less. 9. Security Considerations 9.1 DNS Security DMP depends solely on DNS to publish DMP records. Any compromise of records of a domain would make that domain vulnerable to "spoofing." Likewise, a compromised DNS server hosting an upper-level domain could publish false records for multiple domains. Best current practices for DNS server security will prevent these and similar abuses and DMP records may reside on DNSSEC servers without changes to DMP. 9.2 Mail Transfer Agent Security A compromised host authorized through DMP records of a domain may send unauthorized mail in the name of the domain. Likewise, a compromised host with a DMP record set for its Fully Qualified Domain Name may send unauthorized mail in its name. This is critical in that a compromised host with DMP records may send mail in the name of any domain. Best current practices for SMTP Mail Transfer Agents in general will prevent these and similar abuses. DMP may permit administrators to identify hosts with compromised MTAs rapidly. 9.3 "Global Wildcard" DMP Records A domain publishing DMP records may try designating another network, not controlled by them, or the entire Internet as permitted to send mail on its behalf, such as: Fecyk Expires - April 2004 [Page 15] Designated Mailers Protocol December 2003 $ORIGIN example.com. *._smtp-client TXT "dmp=allow" This not only defeats the purpose of DMP, but administrators of servers using DMP may refuse mail in the name of this domain, regardless of origin, upon discovery of such a record. In any case, only the network protocol portion of the DMP records may include this type of record, for example: $ORIGIN example.com. _smtp-client TXT "dmp=" *._smtp-client TXT "dmp=deny" *.in-addr._smtp-client TXT "dmp=allow" This obtains the desired result without creating invalid DMP records. Appendix A. Answers to Common Questions and Concerns The two most common concerns appear here. Others will appear in a DMP Frequently Asked Questions document. A.1 Does DMP cause some mailing lists and clients that forward e- mail to be refused? Not anymore, provided the receiving servers will permit a client's HELO or EHLO identifier as an alternative source for DMP records. The policies of the receiving domain will dictate this. Using a host's records in this manner shifts responsibility from the administrators of the domain to the administrators of the host. A.2 How does DMP affect SMTP clients on dynamically configured hosts? Because DMP queries use the client's network address as well as its host or domain name, a change in a client's address could result in returns of NXDOMAIN or "dmp=deny". Servers using DMP may bypass DMP for "allowed" clients, and such servers may act as relays or smart hosts for such clients. The administrators of the sender domain MUST designate this relay as allowed to send mail for their domain. This is the RECOMMENDED way to send mail from a dynamically configured host to a domain querying DMP records. Fecyk Expires - April 2004 [Page 16] Designated Mailers Protocol December 2003 However, administrators MAY dynamically change DMP records alongside of Address records or Mail Exchange records, permitting a dynamically configured host to send mail directly to recipient servers that query DMP records. Note that DNS propagation delays and high Time-to-live (TTL) values may affect the ability to designate a dynamically configured host as a sender. Appendix B: Proposed Extensions to DMP To ease the administration of DMP records, many readers provided suggestions to extend DMP. These are the most common suggestions. B.1 Designating Another Domain's Mailers A network that sends mail for multiple domains may find a full set of DMP records for each domain inconvenient. To reduce the administrative burden, a domain may declare the published DMP records of another domain as authoritative for this domain. This domain only needs one DMP record to accomplish this: _smtp-client.$DOMAIN. TXT "dmp=altdomain:$ALTDOMAIN." $DOMAIN is the original domain. $ALTDOMAIN is the fully qualified domain whose designated mailers may also send mail on behalf of $DOMAIN. For consistency with other DNS record names, the $ALTDOMAIN MUST have a trailing period to identify this as a fully qualified domain. A domain may specify multiple domains, whose senders may be used, with each fully qualified domain separated by commas: _smtp-client.$DOMAIN. TXT "dmp=altdomain:$ALTDOMAIN1.,$ALTDOMAIN2." The limit to this would be the limit to the size of a TXT RR record. One drawback to this extension is the increase in DNS traffic. A server querying DMP records would need to repeat the queries for each of the designated domains. The flowchart in 5.1 would repeat the domain query for each $ALTDOMAIN specified, before querying the host itself if configured to do so, or until "dmp=allow" was found. Example default DMP record: $ORIGIN example.com. _smtp-client TXT "dmp=altdomain:example.net.,example.org." Fecyk Expires - April 2004 [Page 17] Designated Mailers Protocol December 2003 B.2 Identifying the Role of Domain, Host or Forwarder A default DMP record may identify the role of the domain, be it host only or multi-host domain, be it permitted to forward mail in the name of another domain or not. Following the example in B.1, keywords could include "domain", "forwarder", "host", "altdomain", and so on. . domain: This is an e-mail domain whose sender envelopes are <$USER@$DOMAIN>, with one or more addresses permitted to send mail on behalf of the domain and its users. A domain may also be a host. . host: This is a single host, whose permitted sender envelopes include <$USER@$HOST> and Null <>. A domain designating this host's network address as a sender may also permit envelopes for its domain from this host. . forwarder: This is a single host that may send mail on behalf of other domains. Any envelope may originate from this host, and it implies the functionality of "host". . altdomain: This domain designates another domain's DMP records as authoritative for this domain. This keyword would override any other keywords in the returned DMP record. These keywords would appear in the domain or host's default DMP record. A resulting lookup could return "dmp=domain,host,forwarder". "altdomain" would override any other keyword. This has the potential to solve certain kinds of forgeries, by identifying what a host or domain intends to have the domain or host do. For instance, a host that does not forward mail could not send mail on behalf of other domains. This would allow servers querying DMP to refuse mail from a compromised host, while still permitting Null Sender envelopes and mail sent in the name of the host. The default of "dmp=" would assume "dmp=domain". A domain with a misspelled keyword or a keyword with incorrect parameters would appear as a non-participating domain with invalid DMP records. References Normative References [RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Fecyk Expires - April 2004 [Page 18] Designated Mailers Protocol December 2003 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC 2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001 [RFC 1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1034, November 1987 Informative References [RFC 1464] Rosenbaum, R., "Using the Domain Name System To Store Arbitrary String Attributes", RFC 1464, May 1993 [LOGS] The logs used to obtain this information are available from the Pan-Am Internet DMP web site, at , in Microsoft Access 97 and plain text formats. The archive is approximately 18 MB in size. Contributors Raymond S Brand, Lawrence Sherzer and Richard W Rognlie developed the Designated Relays Inquiry Protocol (DRIP), a work-in-progress. DMP uses portions of DRIP to support some mail forwarding systems. Hadmut Danisch originally approached the idea of publishing a list of hosts to permit mail for a domain; a work-in-progress called the Reverse Mail Exchanger (RMX) DNS Resource Record. Derek J. Balling provided the initial design of the DMP DNS record template. "der Mouse" generalized it, resulting in the current form. Michael A. Smith provided a format for the actual contents of DMP records, based on RFC 1464. Jack Bates assisted with supporting SMTP Source Routing. Steve Atkins and Bill Cole assisted with their DNS expertise. "der Mouse" assisted with testing and with formatting IPv6 versions of DMP records. Fecyk Expires - April 2004 [Page 19] Designated Mailers Protocol December 2003 NOTE to RFC Editor: "der Mouse" does not wish to be identified by his real name. Members of the IMS Users mailing list contributed MTA logs and ran a statistics gathering application to obtain the information in Chapter 8. Piotr Kubala provided the majority of this information. Author's Addresses Gordon Fecyk 24 - 482 Young Street Winnipeg, MB R3B 2S6 Canada Email: gordonf@pan-am.ca Full Copyright Statement "Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Fecyk Expires - April 2004 [Page 20]