Internet Draft G. Fecyk Document: draft-fecyk-dsprotocol-00.txt Pan-Am Internet Services Expires: September 2003 March 2003 Designated Senders Protocol A Way to Identify Hosts Authorized to Send SMTP Traffic 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 a proposed standard for identifying host computer systems designated as Simple Mail Transfer Protocol (SMTP) clients for an Internet domain or host through Domain Name System (DNS). This identification allows SMTP servers to verify if a connecting client is allowed to make outgoing SMTP connections on behalf of the client's domain. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. In examples, the domain name "example.net" represents a fictional domain receiving SMTP communications with servers, and "example.com" represents a fictional domain transmitting SMTP communications with clients. Fecyk Expires - September 2003 [Page 1] Designated Senders Protocol March 2003 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 [1]. Table of Contents 1. Introduction...................................................2 2. Why Identify Sending Hosts as well as Receiving Hosts..........3 2.1 Junk E-mail................................................3 2.2 Viruses and Worms..........................................3 2.3 Account Fraud..............................................3 2.4 "Joe-Jobbers"..............................................4 3. What Participating in the Designated Senders Protocol does NOT Prevent...........................................................4 3.1 Junk E-mail with Correct Envelope Information..............4 3.2 "Joe-Jobbing" Within the Same Domain.......................4 3.3 Viruses and Worms using the Infected Party's SMTP Server...4 4. Background.....................................................5 5. Designating SMTP Clients.......................................5 5.1 By Internet Protocol v4 (IPv4) Address.....................5 5.2 Example Designations by IPv4 Address.......................6 5.3 By Internet Protocol v6 (IPv6) Address.....................7 6. Protocol Flowchart.............................................8 7. Example SMTP Conversations....................................10 8. Mail Forwarding...............................................12 8.1 Authorized Mail Relay.....................................12 8.2 Secondary Mail Exchangers.................................12 8.3 Mailing List Servers......................................13 8.4 Mail Forwarding such as .forward files on *ix systems.....13 9. Accepting Mail from the Null Sender Envelope: MAIL FROM:<>....14 10. Security Considerations......................................14 10.1 DNS Security.............................................15 10.2 Mail Transfer Agent Security.............................15 10.3 DNS Outages..............................................15 10.4 Answering RFC 2821 7.1: Mail Security and Spoofing.......15 11. References...................................................16 12. Acknowledgments..............................................16 13. Author's Addresses...........................................17 14. Full Copyright Statement.....................................17 1. Introduction My ultimate goal in fighting junk e-mail is bringing accountability back to its senders. With accountability, spammers must answer for their e-mail abuse or stop sending junk e-mail. My first and most successful attempt at doing so was the Orca DUL Project. Even with projects like these and many others, spammers continued to find ways to avoid accountability. This document is my latest Fecyk Expires - September 2003 [Page 2] Designated Senders Protocol March 2003 attempt to restore it, and with accountability restored, strengthen the myriad of anti-spam measures, policies and projects already available. 2. Why Identify Sending Hosts as well as Receiving Hosts You want to identify your outgoing SMTP hosts so you can effectively audit e-mail sent in the name of your domain. While it is still possible to send authorized e-mail and still be abusive, it becomes far easier to audit the abuse and identify the senders. 2.1 Junk E-mail "Spammers," not wishing be identified or have their abused resources identified, routinely falsify their e-mail's sender information, including Sender Envelope (MAIL FROM: envelope), From: header and Reply-To: header. Spammers often target large, popular domains such as hotmail.com[tm] when they do this. If such domains participated in this Protocol, other participating domains would not receive junk e-mail from spammers falsifying their sender information. Recipients using the Protocol could reject any e-mail sent in this manner, regardless of how a resource is exploited. This includes open relay, insecure proxy, dynamic IP, insecure and unrelated resources such as older Formmail versions, and yet-undiscovered exploits. 2.2 Viruses and Worms While many viruses use the infected machine's sender address, those same viruses rarely use the sender domain's resources to send copies of itself, instead running their own SMTP engines. Domains participating in this Protocol may reject copies of viruses sent in this manner. 2.3 Account Fraud Members of both financial institutions such as PayPal, and non- financial account maintainers such as America On-Line, routinely receive communication from confidence-artists and scammers falsifying the membership host's domain in their e-mail. They do this to entice the recipients into divulging critical account information to the scam artist. Account maintainers participating in this Protocol can discourage would-be scam artists from falsifying their domain, as participating recipients may reject e-mail from them. Fecyk Expires - September 2003 [Page 3] Designated Senders Protocol March 2003 2.4 "Joe-Jobbers" People wishing to harm other people on the Internet often falsify a specific person's e-mail address to direct blame on that other person. The first well-known instance of this abuse put the domain joes.com out of business, hence the phrase "Being Joe'd" or "Joe- Jobbing." Domains participating in this Protocol could greatly diminish their chances of being "Joe'd," as participating recipients could reject such e-mail. 3. What Participating in the Designated Senders Protocol does NOT Prevent Designated Senders Protocol addresses a specific e-mail problem, and does not stop "authorized" abuse. It does, however, make "authorized" abuse far easier to track. 3.1 Junk E-mail with Correct Envelope Information The Protocol would not stop a spammer from using envelope information they are authorized to use. However, maintainers of a spammer's domain could audit their activity more effectively, as the spammer is forced to use their correct information. If spammers maintain their own domains, domain-based blocking becomes more effective. In extreme cases, where a spammer hosts multiple domains, blocking the authoritative DNS servers for the spammer's domains becomes very effective, as the recipient could reject all Protocol lookups on the spammers' DNS servers. They would effectively reject all e-mail from domains hosted there. 3.2 "Joe-Jobbing" Within the Same Domain If a user on example.com wanted to falsify e-mail coming from someone else within example.com, the Protocol would still allow for it, since the sender envelope information would be correct. However, maintainers of said domain could audit this e-mail and identify the sender. 3.3 Viruses and Worms using the Infected Party's SMTP Server If a user's computer runs such a virus that, instead of using its own SMTP engine, uses their outgoing mail server, using the Protocol would not stop it. However, domain maintainers could audit this e- mail and identify the user with the infected computer. Fecyk Expires - September 2003 [Page 4] Designated Senders Protocol March 2003 4. Background At least one similar document [2] describes identifying outgoing SMTP hosts by name using SRV RR records, and defines the sub-domain "CLIENT.SMTP.TCP" in accordance with RFC 2052. [4] However, a large number of DNS resolvers do not recognize this relatively new resource record type, nor is there a quick way to identify a sending host by IP address should a sender domain use any load balancing technique. As the connecting IP address is the most readily available bit of information we have on a host, I propose using it, instead, in the query to see if it is a designated SMTP sender. Many anti-spam projects use a variant of the addressing scheme employed by the IN-ADDR.ARPA domain, where a name record for a given IPv4 address may be found by querying each dotted-quad value as a sub-domain. For example, we should find a PTR RR record in the IN- ADDR.ARPA domain for 192.168.0.1 here: 1.0.168.192.in-addr.arpa. Anti-spam projects using IN-ADDR.ARPA-like naming to identify addresses to avoid receiving SMTP communication, do so by creating A RR records, and use an otherwise meaningless value for the A RR itself: 1.0.168.192.evil-spammers-list.example.com. A xxx.xxx.xxx.xxx A subscriber to this project would look up 192.168.0.1 by querying this name for a valid A RR record. If it found one, it would refuse further SMTP connectivity from there. The Designated Senders Protocol defines a unique set of IN- ADDR.ARPA-like records in a special name space, modeled from RFC 2052, to identify a domain as a participant of the protocol. It further defines a way to identify the IPv4 (or IPv6) addresses that are designated to make SMTP connections on behalf of the sender's domain or host. 5. Designating SMTP Clients 5.1 By Internet Protocol v4 (IPv4) Address A host or domain participating in Designated Senders would create A RR records in their DNS zone with this template [3]: ; Required: DS participant indication flag Fecyk Expires - September 2003 [Page 5] Designated Senders Protocol March 2003 ds.client.smtp.tcp.${DOMAINNAME}. A 127.0.0.1 ; Optional: Records Indicating Designated Senders ${REVERSEDIP_1}.ds.client.smtp.tcp.${DOMAINNAME}. A 127.0.0.1 ${REVERSEDIP_2}.ds.client.smtp.tcp.${DOMAINNAME}. A 127.0.0.1 [...] ${REVERSEDIP_N}.ds.client.smtp.tcp.${DOMAINNAME}. A 127.0.0.1 ${DOMAINNAME} represents the right-hand side of a SMTP mail sender envelope as used in the MAIL FROM: command. For example, the sender envelope "user@example.com" has a right-hand side of "example.com". ${REVERSEDIP_N} represents the IPv4 address in reverse-dotted-quad order. For example, the IPv4 address 192.168.0.1 would become "1.0.168.192" in reverse-dotted-quad order, as used in IN-ADDR.ARPA. The first A RR record identifies the sender domain as a participant of the Designated Senders Protocol. The remaining records identify the IPv4 addresses of the hosts designated to send SMTP traffic. The choice of 127.0.0.1 as the value for these records was arbitrary, and should not matter. A lookup will generate one of three results: A successful retrieval of a A RR, a rejected retrieval of a A RR (NXDOMAIN), or a failure to retrieve a record (SERVFAIL). Participating servers MUST distinguish between all three possible results, and MUST NOT interpret the results beyond a successful, rejected or failed lookup. A participating domain MUST have one A RR record indicating they participate in the Protocol. A participating domain MAY have NO additional Designated Sender records, thereby indicating no SMTP traffic will originate from their domain. 5.2 Example Designations by IPv4 Address Here is an example portion of a DNS zone file for example.com, where the hosts at IPv4 addresses 192.168.0.10 and 192.168.1.110 are the Designated Senders for example.com: $ORIGIN example.com. ds.client.smtp.tcp A 127.0.0.1 10.0.168.192.ds.client.smtp.tcp A 127.0.0.1 110.1.168.192.ds.client.smtp.tcp A 127.0.0.1 Here is an example of example.com designating a rack of load- balancing hosts in the network of 192.168.1.0/24 as Designated Senders: $ORIGIN example.com. ds.client.smtp.tcp A 127.0.0.1 Fecyk Expires - September 2003 [Page 6] Designated Senders Protocol March 2003 *.1.168.192.ds.client.smtp.tcp A 127.0.0.1 Here is an example of example.com stating that no SMTP traffic will originate from their domain: $ORIGIN example.com. ds.client.smtp.tcp A 127.0.0.1 Finally, here is an example of a stand-alone host with its own Fully Qualified Domain Name, "lonehost.example.com" $ORIGIN example.com. lonehost A 192.168.0.1 ds.client.smtp.tcp.lonehost A 127.0.0.1 1.0.168.192.ds.client.smtp.tcp.lonehost A 127.0.0.1 Alternately: $ORIGIN lonehost.example.com. @ A 192.168.0.1 ds.client.smtp.tcp A 127.0.0.1 1.0.168.192.ds.client.smtp.tcp A 127.0.0.1 Using reversed-dotted-quad addresses in the zone records allows us to use wildcards in the records. If we did not, we would have to enter potentially 256 A RR records in the zone file for this configuration. It's been suggested to use other resource record types, as A RRs are already heavily overused. However, every operating system that supports IP networking has a form of the gethostbyname() function, making A RRs the easiest to look up. Other record types require specialized programming to send and receive UDP packets, which varies between operating systems. In addition, not all DNS implementations support wildcarding for other record types. 5.3 By Internet Protocol v6 (IPv6) Address NOTE: This author does not claim detailed knowledge of IPv6 and requests opinions on how to implement this correctly. We can trivially extend the Protocol to identify authorized IPv6 addressed hosts. The template for identifying IPv6 hosts as Designated Senders is identical to the template for IPv4, except the records are AAAA RR records for IPv6 addresses. Again, the choice for "localhost" (::1) was arbitrary. A lookup will generate one of three results: A successful retrieval of a AAAA RR, a rejected retrieval of a AAAA RR (NXDOMAIN), or a Fecyk Expires - September 2003 [Page 7] Designated Senders Protocol March 2003 failure to retrieve a record (SERVFAIL). Participating servers MUST distinguish between all three possible results, and MUST NOT interpret the results beyond a successful, rejected or failed lookup. ; Required: DS Participant indication flag ds.client.smtp.tcp.${DOMAINNAME}. AAAA ::1 ; Optional: Designated Senders for this domain ${REVERSEDIPV6_1}.ds.client.smtp.tcp.${DOMAINNAME}. AAAA ::1 ${REVERSEDIPV6_2}.ds.client.smtp.tcp.${DOMAINNAME}. AAAA ::1 [...] ${REVERSEDIPV6_N}.ds.client.smtp.tcp.${DOMAINNAME}. AAAA ::1 The remainder of this document will use IPv4 addressing and records in its examples. Aside from the template, the actions for IPv6 participants are identical to that of IPv4 participants. 6. Protocol Flowchart The flowchart starts when the client issues the MAIL command. It ends with an acknowledgement or error before the client issues the RCPT command. ==================================== | Client issues MAIL FROM: command | ==================================== | | ============================================================= | Server checks local Allow and Auth rules on connecting IP | ============================================================= | | ============================= | Allowed or Authenticated? |-------Yes------------| ============================= | | ============ No | 250 OK | | | Resume | | | Normally | | ============ | ======================================================= | Server performs DS Protocol lookup on connecting IP | ======================================================= | Fecyk Expires - September 2003 [Page 8] Designated Senders Protocol March 2003 | ============= | Response? |-----------|--------------------| ============= | | | | | Success NXDOMAIN SERVFAIL | | | ============= ================== | | 250 OK | | Perform second | | | Resume | | lookup to see | | | Normally | | if site uses DS| | ============= ================== | | | ============= | | Response? | | ============= | | | |----------------|---------------| | | | | | Success NXDOMAIN SERVFAIL | | | | | | | | | ============= =============== =============== | 550 ERROR | | Do I accept | | Do I accept | | IP not DS | | mail from | | mail from | | for domain| | non-DS site?| | (possibly) | | | | | | non-DS site?| ============= =============== =============== | | | | |--------------| |--------------| | | | | Yes No Yes No | | | | =========== ============= =========== ============= | 250 OK | | 550 ERROR | | 250 OK | | 451 ERROR | | Resume | | Need DS | | Resume | | Cannot see| | Normally| | Records | | Normally| | DS records| =========== ============= =========== ============= Designated Senders Protocol uses error code 550 for a permanent error, indicating a policy reason, and 451 for a temporary error, indicating a local processing error. Error code 451 is the only temporary error response allowed to the MAIL command. [5] Initially, participating servers will perform two A RR lookups. The first verifies if the sender's IP address is a Designated Sender for a (possibly) participating domain. Should that lookup be rejected Fecyk Expires - September 2003 [Page 9] Designated Senders Protocol March 2003 (responds with NXDOMAIN), the second verifies that the sender domain participates in the Protocol. Later, as the Protocol becomes widespread, the second lookup will occur less and less frequently. However, participating servers MUST NOT skip the second lookup to determine if a sender domain participates in the Protocol. Participating servers MAY bypass the Protocol altogether for chosen IP addresses, for instance, their "allow relay" list for client IPs, or for client IPs running a Mail User Agent that supports some form of authentication for sending e-mail. Example authentication protocols include POPAUTH, SMTP AUTH, client certificates and so on. When a non-participating client connects to a participating server, it SHOULD respond as though the Protocol didn't exist. However, as the Protocol gains acceptance, it MAY respond as its operators wish, for instance, to refuse e-mail until the senders participate in the Protocol. 7. Example SMTP Conversations These examples introduce new error conditions in the SMTP or ESMTP protocol after the MAIL command. RFC 2821 section 4.3.2 states this is allowed. [5] An example of a successful SMTP session between hosts in participating domains: S: 220 mail.example.net MMS SMTPRCV service v0.95 C: HELO clientmachine.example.com S: 250 mail.example.net Hello clientmachine.example.com [192.168.0.1] C: MAIL FROM: S: (server looks up 1.0.168.192.ds.client.smtp.tcp.example.com and succeeds) S: 250 OK client at 192.168.0.1 verified as authorized sender for example.com [resume normally] An example of a rejected (NXDOMAIN) session from an undesignated host claiming to be part of a participating domain to a participating host: S: 220 mail.example.net MMS SMTPRCV service v0.95 C: HELO not-clientmachine.example.com S: 250 mail.example.net Hello not-clientmachine.example.com [192.168.1.1] C: MAIL FROM: Fecyk Expires - September 2003 [Page 10] Designated Senders Protocol March 2003 S: (server looks up 1.1.168.192.ds.client.smtp.tcp.example.com and returns NXDOMAIN) S: (server looks up ds.client.smtp.tcp.example.com and succeeds) S: 550 ERROR client at 192.168.1.1 is not a designated sender for example.com C: RCPT TO: S: 550 ERROR must issue MAIL FROM: command first C: DATA S: 554 ERROR must issue MAIL FROM: and RCPT TO: first An example of a rejected (NXDOMAIN) session from a host belonging to a non-participating domain, where the participating server acts as though the protocol didn't exist: S: 220 mail.example.net MMS SMTPRCV service v0.95 C: HELO not-clientmachine.example.com S: 250 mail.example.net Hello not-clientmachine.example.com [192.168.1.1] C: MAIL FROM: S: (server looks up 1.1.168.192.ds.client.smtp.tcp.example.com and returns NXDOMAIN) S: (server looks up ds.client.smtp.tcp.example.com and returns NXDOMAIN) S: 250 OK, mail from user@example.com. Consider using DS Protocol, see RFC XXXX [resume normally] An example of a rejected (NXDOMAIN) session from a host belonging to a non-participating domain, where the participating server refuses SMTP traffic from non-participating domains: S: 220 mail.example.net MMS SMTPRCV service v0.95 C: HELO not-clientmachine.example.com S: 250 mail.example.net Hello not-clientmachine.example.com [192.168.1.1] C: MAIL FROM: S: (server looks up 1.1.168.192.ds.client.smtp.tcp.example.com and returns NXDOMAIN) S: (server looks up ds.client.smtp.tcp.example.com and returns NXDOMAIN) S: 550 ERROR cannot verify 192.168.1.1 as sender for example.com. Consider using DS Protocol, see RFC XXXX An example of a failed (SERVFAIL) session from a host belonging to, possibly, a non-participating domain, where the participating server refuses SMTP traffic from, possibly, non-participating domains: S: 220 mail.example.net MMS SMTPRCV service v0.95 C: HELO not-clientmachine.example.com Fecyk Expires - September 2003 [Page 11] Designated Senders Protocol March 2003 S: 250 mail.example.net Hello not-clientmachine.example.com [192.168.1.1] C: MAIL FROM: S: (server looks up 1.1.168.192.ds.client.smtp.tcp.example.com and returns SERVFAIL) S: 451 ERROR cannot verify 192.168.1.1 as sender for example.com at this time. Consider using DS Protocol, see RFC XXXX A DNS outage may be responsible for a SERVFAIL response. For this reason, participating servers MUST use a 451 error message indicating a temporary failure, and not a 550 series message indicating a permanent failure, when any lookup returns SERVFAIL. This is a separate and distinct condition from where the server can determine (through a NXDOMAIN response) that the client is not from a participating domain. 8. Mail Forwarding Mail forwarding without altering the sender envelope in the MAIL command becomes difficult with the Designated Senders Protocol. The host acting as the forwarding agent rarely is authoritative for the sender's domain. This section covers how to accommodate mail forwarding under the Protocol. 8.1 Authorized Mail Relay Most mail user agents (MUAs) use an external SMTP server as a relay agent or "outgoing mail server." The MUA's IP address is almost never a designated sender for the sender's domain. The relaying MTA only has to use their "Allow Relay" list to permit SMTP traffic from the MUA, as is accepted practice. [6] 8.2 Secondary Mail Exchangers Larger Internet providers use a network of peer mail exchangers and directly inject e-mail from the peer into their internal mail system, so these are largely unaffected. Smaller providers use a single Primary host and one or more Secondary hosts as relays to the Primary, and the Secondary is almost never a designated sender for a sender's domain. Participants in the Protocol that use Secondary mail exchangers can use one of several ways to accept mail from their Secondary hosts again. Here are two possibilities: - Add the Secondary host's IP address to the Primary's "Allow Relay" list, similar to 8.1 above. Fecyk Expires - September 2003 [Page 12] Designated Senders Protocol March 2003 - Program the Secondary to alter the sender envelope, and designate the Secondary as a designated sender for itself as suggested in 5.2 above. An altered sender envelope could contain the original sender's information, for instance including the original sender envelope directly: MAIL FROM: ...or encode the original sender into the new sender envelope somehow, such as with a two-way hash: MAIL FROM:<236FA24C@secondarymx.example.net> Whatever method is used, a Secondary MUST return mail back to the sender if the Primary rejects it. This author understands that most MTAs relaying as a Secondary do not modify the sender envelope. While modifying the envelope is more secure, adding a Secondary to the Primary's "allow" list is acceptable. 8.3 Mailing List Servers Some list server implementations use the original envelope sender when forwarding mail from a sender to the list members, but most modern list software alters or replaces the sender envelope somehow. For example, list software uses the list-owner address in the sender envelope. Maintainers of mailing lists that do not alter the sender envelope SHOULD NOT to participate in the Protocol until they upgrade their mailing list software. 8.4 Mail Forwarding such as .forward files on *ix systems This author recognizes that every MTA using .forward files on *ix hosts or similar configurations do not alter the sender envelope when forwarding mail. However, commercial and proprietary mail- forwarding systems such as mail.com[tm] alter the sender envelope, and these are by far the most popular pure mail-forwarding instances. There is no fix for .forward usage aside from altering the sender envelope and designating the forwarding host as a designated sender for itself, as described in 5.2 above. Sites with many users using .forward files should consider the age of these entries and consider if it's worth while to continue forwarding mail for very old accounts, DS Protocol not withstanding. Fecyk Expires - September 2003 [Page 13] Designated Senders Protocol March 2003 Domain administrators may choose not to participate in the Protocol if they do not want to alter their MTA to accommodate it or purge their .forward capability. 9. Accepting Mail from the Null Sender Envelope: MAIL FROM:<> As there is no domain to perform a DS Protocol lookup in a Null Sender envelope, it is difficult to tell if the sender of such a message is authorized to do so. However, there are other ways to ensure the sender is authorized to send it. According to RFC 2821 section 4.5.5, the Null reverse-path accompanies Delivery Status Notifications, Message Disposition Notifications, and other administrative messages. These types of messages are always generated by mail delivery software only, and not by users. We can ensure that null reverse-path messages only come from hosts running MTAs and not from users. The simplest is to make the sender host a Designated Sender for itself as described in 5.2 above. To strengthen this, a recipient server MAY inspect the forward or reverse DNS records, or both, on the client host's HELO or EHLO identifier: S: 220 mail.example.net MMS SMTPRCV service v0.95 C: HELO clientmachine.example.com S: 250 mail.example.net Hello clientmachine.example.com [192.168.0.1] C: MAIL FROM:<> S: (server looks up 1.0.168.192.ds.client.smtp.tcp.clientmachine.example.com and succeeds) S: (optional: server looks up clientmachine.example.com and receives 192.168.0.1, compares A RR record to connecting IP address and they match) S: (optional: server looks up 1.0.168.192.in-addr.arpa for PTR and receives clientmachine.example.com, compares PTR RR record to HELO'd name and they match) S: 250 OK Administrative message coming from clientmachine.example.com If the server receives NXDOMAIN on any of these lookups, or if the comparisons don't match, it MAY refuse the message. If the server receives SERVFAIL on any of these lookups, it SHOULD refuse the message IF it already does so for NXDOMAIN responses. 10. Security Considerations Fecyk Expires - September 2003 [Page 14] Designated Senders Protocol March 2003 10.1 DNS Security Designated Senders Protocol relies solely on DNS to verify Designated Sender hosts. Any compromise of a domain's DNS records would make that domain vulnerable to "spoofing" in a run by spammers, but the spammers would need to insert necessary name records into your DNS zone. Likewise, a compromised server at the tier below a domain could allow spammers to insert false Designated Sender records for that domain. Best current practices for DNS server security will prevent these and similar abuses. 10.2 Mail Transfer Agent Security Compromised hosts already identified as Designated Senders may be used to send unauthorized e-mail in the name of the designator's domain. Best current practices for SMTP MTAs in general will prevent these and similar abuses. 10.3 DNS Outages A domain may still be successfully spoofed if the sender domain's records are unreachable (SERVFAIL), AND if the participating server accepts SMTP traffic from, possibly, non-participating domains. Participating sites SHOULD refuse SMTP traffic based on this case, using a 400 series error indicating a temporary failure, even if they choose to accept SMTP traffic from domains that decidedly not (NXDOMAIN) participate, to avoid this. 10.4 Answering RFC 2821 7.1: Mail Security and Spoofing From 7.1 of RFC 2821: Efforts to make it more difficult for users to set envelope return path and header "From" fields to point to valid addresses other than their own are largely misguided: they frustrate legitimate applications in which mail is sent by one user on behalf of another or in which error (or normal) replies should be directed to a special address. [...] This specification does not further address the authentication issues associated with SMTP other than to advocate that useful functionality not be disabled in the hope of providing some small margin of protection against an ignorant user who is trying to fake mail. Designated Senders Protocol still allows a user to send mail on behalf of another within the same domain. It also still allows Fecyk Expires - September 2003 [Page 15] Designated Senders Protocol March 2003 mailing list systems to send mail to subscribers on behalf of other subscribers in different domains. We are no longer looking at one or two ignorant users trying to fake mail. Today we are looking at an entire industry built on the unwilling backs of recipients, based on several hundreds of thousands of deliberately ignorant users who fake mail for fun and profit. I can live with losing a little otherwise-useful functionality for a very large margin of protection against them. 11. References 1. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 2. Credit where due: B. Gingery first brought up the topic on the SPAM-L mailing list, and it had been discussed earlier on the Spamtools mailing list. There are other documents describing similar approaches to this problem. 3. Derek J. Balling for initial design of the DNS record template and explanation, and "der Mouse" for generalizing it into the current form. 4. Gulbrandsen, A., Vixie, P., "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996 5. 4.3.2 of Klenstin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001 6. 2.1 of Lindenberg, G., "Anti-Spam Recommendations for SMTP MTAs", RFC 2505, February 1999 7. 4.5.5 of Klenstin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001 12. Acknowledgments Derek J. Balling for initial design of the DNS record template and explanation, and "der Mouse" for generalizing it into the current form. Fecyk Expires - September 2003 [Page 16] Designated Senders Protocol March 2003 13. Author's Addresses Gordon Fecyk Pan-Am Internet Services 24 - 482 Young Street Winnipeg, MB R3B 2S6 Canada Phone: (204) 292-9970 Email: gordonf@pan-am.ca 14. 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 - September 2003 [Page 17]