Internet DRAFT - draft-fecyk-dsprotocol

draft-fecyk-dsprotocol




   Internet Draft
   Category: Experimental                                      G. Fecyk
   Document: draft-fecyk-dsprotocol-04.txt     Pan-Am Internet Services
   Expires: September 2003                                  August 2003


                        Designated Mailers 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.


Changes Since Last Revision

   Minor edits to conform with submissions to the RFC Editor, and a
   clarification that participating sender domains do not need to
   modify their email software to participate.

   Testing revealed an inconsistency with wildcard handling between
   various DNS implementations and RFC 1034 4.3.2 [n3].  This draft no
   longer requires wildcard records at all.

   Throughout the document, added new DNS nodes for different transport
   protocols.  Introduced the nodes "in-addr" and "ip6" so-named for
   their nodes in the arpa domain.  DMP is now extensible to any
   transport that supports address-to-name mapping through DNS.

   5. Changed the TXT RR values to "dmp=deny" and "dmp=allow" in
   accordance with RFC 1464, which describes a way to store arbitrary
   string values using TXT RR records.  The values for the "dmp"
   attribute were chosen for their English meanings.


Fecyk                  Expires - September 2003               [Page 1]
                     Designated Mailers Protocol          August 2003


   Throughout this document, renamed the Protocol to "Designated
   Mailers Protocol" and changed the acronym for the Protocol to "dmp"
   to avoid confusion with record types available in DNSSEC.

   Throughout the document, changed DNS node used for the Protocol to
   "${addr-type}._smtp-client". This avoids conflicts and confusion
   with SRV RR records.

   5. Template, description and examples rewritten to use TXT RR
   records instead of A RR records.

   6. Protocol Flowchart redesigned to demonstrate changes to the
   Protocol.  Of most import: The second Protocol lookup, eliminated in
   the second draft, was restored.

   7 and 9. Example SMTP Conversations changed to accommodate changes
   to Protocol, Template and Record Type use.

   8. An additional mail forwarding problem, Source Routing, is
   described.


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.

   All name record examples use BIND 4 syntax.  The majority of DNS
   server software supports this syntax.  If yours does not, you will
   need to translate the examples into the correct syntax for your DNS
   server.  Wildcard capability is desired, but not required.





Fecyk                  Expires - September 2003               [Page 2]
                     Designated Mailers Protocol          August 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 [n1].

Table of Contents

   1. Introduction...................................................3
   2. Why Identify Sending Hosts as well as Receiving Hosts..........4
      2.1 Junk Email.................................................4
      2.2 Viruses and Worms..........................................4
      2.3 Account Fraud..............................................5
      2.4 "Joe-Jobbers"..............................................5
   3. What Participating in the Designated Mailers Protocol does NOT
   Prevent...........................................................5
      3.1 Junk Email with Correct Envelope Information...............5
      3.2 "Joe-Jobbing" Within the Same Domain.......................5
      3.3 Viruses and Worms using the Infected Party's SMTP Server...6
   4. Background.....................................................6
   5. Designating SMTP Clients.......................................7
      5.1 By Internet Protocol v4 (IPv4) Address.....................9
      5.2 Example Designations by IPv4 Address......................10
      5.3 By Internet Protocol v6 (IPv6) Address....................11
   6. Protocol Flowchart............................................11
   7. Example SMTP Conversations....................................13
   8. Mail Forwarding...............................................15
      8.1 Authorized Mail Relay.....................................15
      8.2 Secondary Mail Exchangers.................................16
      8.3 Mailing List Servers......................................16
      8.4 Mail Forwarding such as .forward files on *ix systems.....17
      8.5 SMTP Source Routing.......................................17
   9. Accepting Mail from the Null Sender Envelope: MAIL FROM:<>....17
   10. Security Considerations......................................18
      10.1 DNS Security.............................................18
      10.2 Mail Transfer Agent Security.............................18
      10.3 DNS Outages..............................................19
      10.4 Answering RFC 2821 7.1: Mail Security and Spoofing.......19
   Appendix A: Why the Default Record was Restored..................19
   Appendix B: How to Avoid Looking Up the Default Record...........20
   Appendix C: Stupid Spammer Tricks................................21
      C.1: Bogus Subdomains.........................................21
   References.......................................................21
   Acknowledgments..................................................22
   Author's Addresses...............................................22
   Full Copyright Statement.........................................23

1. Introduction

   My ultimate goal in fighting junk email is bringing accountability
   back to its senders.  With accountability, spammers must answer for


Fecyk                  Expires - September 2003               [Page 3]
                     Designated Mailers Protocol          August 2003

   their email abuse or stop sending junk email. 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
   attempt to restore it, and with accountability restored, strengthen
   the myriad of anti-spam measures, policies and projects already
   available.

   This author wants to remind readers that implementing and using the
   Designated Mailers Protocol is entirely OPTIONAL and NOT REQUIRED to
   operate SMTP services.  Also, readers are reminded that recipients
   have the right to refuse any communication from anyone.


2. Why Identify Sending Hosts as well as Receiving Hosts

   You want to identify your outgoing SMTP hosts so you can effectively
   audit email sent in the name of your domain.  While it is still
   possible to send authorized email and still be abusive, it becomes
   far easier to audit the abuse and identify the senders.

2.1 Junk Email

   "Spammers," not wishing be identified or have their abused resources
   identified, routinely falsify their email's sender information,
   including Sender Envelope (MAIL FROM: envelope), From: header and
   Reply-To: header. Spammers often impersonate 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 email from spammers falsifying their sender
   information.

   Recipients using the Protocol could reject any email 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.




Fecyk                  Expires - September 2003               [Page 4]
                     Designated Mailers Protocol          August 2003

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 email.  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 email from them.

2.4 "Joe-Jobbers"

   People wishing to harm other people on the Internet often falsify a
   specific person's email 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 email.


3. What Participating in the Designated Mailers Protocol does NOT
   Prevent

   Designated Mailers Protocol addresses a specific email problem, and
   does not stop "authorized" abuse.  It does, however, make
   "authorized" abuse far easier to track.

3.1 Junk Email 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 email from domains hosted there.

3.2 "Joe-Jobbing" Within the Same Domain



Fecyk                  Expires - September 2003               [Page 5]
                     Designated Mailers Protocol          August 2003

   If a user on example.com wanted to falsify email 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 email 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
   email and identify the user with the infected computer.


4. Background

   At least one similar document [i1] describes identifying outgoing
   SMTP hosts by name using SRV RR records, and defines the sub-domain
   "_CLIENT._SMTP._TCP". [i2] However, there was no quick way to use
   the sending host's IP address in the query.  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 mailer.

   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.0.2.1 here:

      1.2.0.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.2.0.192.evil-spammers-list.example.com. A xxx.xxx.xxx.xxx

   A subscriber to this project would look up 192.0.2.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 Mailers Protocol defines a unique set of DNS resource
   records to identify a domain as a participant of the Protocol.  It
   further defines a way to identify the addresses that are designated
   to make SMTP connections on behalf of the sender's domain or host.




Fecyk                  Expires - September 2003               [Page 6]
                     Designated Mailers Protocol          August 2003

   Sender domains do not need to modify their email software or DNS
   software to participate.  If a domain does not wish to block email
   yet wants to use DMP to avoid being spoofed, they need only supply
   DMP DNS records.


5. Designating SMTP Clients

   DMP relies on name records stored in the DNS [n2]. All domains
   participating in DMP set up TXT RR records in a sub-domain called
   "_smtp-client".  The first is a placeholder which identifies the
   domain as a participant.  The second is a default lookup result for
   servers that support wildcard records:

   ;REQUIRED: DMP Placeholder
   _smtp-client.${DOMAINNAME}. TXT "dmp="
   ;RECOMMENDED: Default record
   *._smtp-client.${DOMAINNAME}. TXT "dmp=deny"

   Additional records are OPTIONAL and identify the network hosts
   designated as SMTP clients:

   ;OPTIONAL: DMP records
   ${ADDRESS}.${ADDR-TYPE}._smtp-client.${DOMAINNAME}. TXT "dmp=allow"

   ${ADDRESS} represents a network address in inverse form as used in
   the "arpa" node.  For instance, IPv4 addresses are represented as
   they are in the in-addr.arpa node, IPv6 addresses are represented as
   they are in ip6.arpa.  ${ADDR-TYPE} represents the address type as
   already used in the "arpa" node, such as "in-addr" for IPv4 and
   "ip6" for IPv6.  ${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".  If there is no domain part in a sender
   envelope, or the domain is "localhost", no DMP lookup is needed as
   it is a local delivery.

   Using inverse addresses in the zone records allows us to use
   wildcards in the records, reducing the number of records needed for
   a large bank of SMTP clients.

   The TXT RR record was chosen for its flexibility.  TXT RR records
   are supported by all DNS server software. The values were selected
   for their English meanings.  The record strings are case-
   insensitive, so "DMP=ALLOW" is the same as "dmp=allow".

   Software designed to look up RFC 1464 [i3] type records may be used
   to look up DMP records, but ANY algorithm that looks up TXT RR



Fecyk                  Expires - September 2003               [Page 7]
                     Designated Mailers Protocol          August 2003

   records will work.  For example, a function written in C to RFC
   1464's example would have the following parameters:

   snprintf(dmpRecordName, bufsize, "%s.in-addr._smtp-client.%s",
   reversedIP, domainName);
   getattributebyname(dmpRecordName, "dmp", result, bufsize);

   To accommodate messages using a Null Reverse Path (MAIL FROM:<>),
   participating sites MUST create a minimum of two DMP records for
   each of their servers in addition to the records for their domain:

   ;REQUIRED: DMP Placeholder and single record
   _smtp-client.${FQDN}. TXT "dmp="
   ${ADDRESS}.{ADDR-TYPE}._smtp-client.${FQDN}. TXT "dmp=allow"
   ; RECOMMENDED: Default DMP record for FQDN
   *._smtp-client.${FQDN}. TXT "dmp=deny"

   ...where ${FQDN} represents the MTA's fully qualified domain name.
   Multiple records, or Wildcards if supported, may be used for a range
   of hosts with the same FQDN.

   A lookup of a network address will generate one of four results:

     - A successful retrieval of a TXT RR record from a valid DMP
     domain node, and a value of "dmp=allow" indicating the connecting
     IP is a Designated Mailer for the domain,
     - A successful retrieval of a TXT RR record from a valid DMP
     domain node, and a value of "dmp=deny" indicating the connecting
     IP is NOT a Designated Mailer for the domain,
     - A permanent error, either NXDOMAIN, CNAME only, multiple
     conflicting DMP records or non-DMP TXT RR record retrieved,
     indicating the domain in the MAIL command does not participate in
     the Protocol, or
     - A temporary error, or failure to retrieve a record (SERVFAIL).

   A lookup of a domain itself, to see if it participates in the
   Protocol, will generate one of three possible results:

     - A successful retrieval of a TXT RR record from a valid DMP
     domain node, and a value of "dmp=" indicating the domain in the
     MAIL FROM: command participates in the Protocol,
     - A permanent error, either NXDOMAIN, CNAME only, DMP record with
     a value different from "dmp=", multiple conflicting DMP records or
     non-DMP TXT RR record retrieved, indicating the domain in the MAIL
     command does not participate in the Protocol, or
     - A temporary error, or failure to retrieve a record (SERVFAIL).





Fecyk                  Expires - September 2003               [Page 8]
                     Designated Mailers Protocol          August 2003

   Participating servers MUST distinguish between all possible results.
   Notably, SERVFAIL is a temporary error and not a permanent one, and
   a subsequent lookup of the same record may succeed.

   A participating domain MUST have one TXT RR record indicating they
   participate in the Protocol, and that record MUST have a "null"
   value for the "dmp" attribute:

   _smtp-client.${DOMAIN_NAME}. TXT "dmp="

   The "dmp=" record was introduced to operate correctly with DNS
   servers that may handle wildcards differently from another, or not
   handle wildcards at all.  A full explanation appears in Appendix A.

   A participating domain SHOULD also have an additional TXT RR record
   providing a default lookup result, if the DNS server supports
   wildcards:

   *._smtp-client.${DOMAIN_NAME}. TXT "dmp=deny"

   A participating domain MAY have NO additional Designated Mailer
   records, thereby indicating no SMTP traffic will originate from
   their domain.  The default of "deny" ensures that any lookups for
   non-designated mailers will return this value.

   This author understands that site administrators will want to permit
   SMTP client connections from any host on a network.  If a site
   administrator insists on doing this, the site MUST have its default
   "allow" record set per address type:

   *.${ADDR-TYPE}._smtp-client.${DOMAINNAME}. TXT "dmp=allow"

   Site administrators really, really SHOULD NOT do this, and instead
   SHOULD designate their own hosts and networks.  It is not difficult
   to add and remove DMP records for dynamically addressed hosts,
   testing hosts, temporary relays, third-party relays and so on.


5.1 By Internet Protocol v4 (IPv4) Address

   A host or domain participating in Designated Mailers would create
   TXT RR records in their DNS zone with this template [i4]:

   ;REQUIRED: DMP placeholder
   _smtp-client.${DOMAINNAME} TXT "dmp="
   ;RECOMMENDED: DMP default record
   *._smtp-client.${DOMAINNAME} TXT "dmp=deny"
   ;OPTIONAL: DMP records
   ${REVERSEDIP_1}.in-addr._smtp-client.${DOMAINNAME}. TXT "dmp=allow"


Fecyk                  Expires - September 2003               [Page 9]
                     Designated Mailers Protocol          August 2003

   ${REVERSEDIP_2}.in-addr._smtp-client.${DOMAINNAME}. TXT "dmp=allow"
   [...]
   ${REVERSEDIP_N}.in-addr._smtp-client.${DOMAINNAME}. TXT "dmp=allow"

   ${REVERSEDIP_N} represents the IPv4 address in reverse-dotted-quad
   order.  For example, the IPv4 address 192.0.2.1 would become
   "1.0.168.192" in reverse-dotted-quad order, as used in IN-ADDR.ARPA.

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.0.2.10 and 192.0.2.110 are the
   Designated Mailers for example.com:

   $ORIGIN example.com.
   _smtp-client TXT "dmp="
   *._smtp-client TXT "dmp=deny"
   10.2.0.192.in-addr._smtp-client TXT "dmp=allow"
   110.2.0.192.in-addr._smtp-client TXT "dmp=allow"

   Here is an example of example.com designating a rack of load
   balancing hosts in the network of 192.0.2.0/24 as Designated
   Mailers:

   $ORIGIN example.com.
   _smtp-client TXT "dmp="
   *._smtp-client TXT "dmp=deny"
   *.2.0.192.in-addr._smtp-client TXT "dmp=allow"

   Here is an example of example.com stating that no SMTP traffic will
   originate from their domain:

   $ORIGIN example.com.
   _smtp-client TXT "dmp="
   *._smtp-client TXT "dmp=deny"

   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.0.2.1
   _smtp-client.lonehost TXT "dmp="
   *._smtp-client.lonehost TXT "dmp=deny"
   1.2.0.192.in-addr._smtp-client.lonehost TXT "dmp=allow"

   Alternately:

   $ORIGIN lonehost.example.com.
   @ A 192.0.2.1


Fecyk                  Expires - September 2003              [Page 10]
                     Designated Mailers Protocol          August 2003

   _smtp-client TXT "dmp="
   *._smtp-client TXT "dmp=deny"
   1.2.0.192.in-addr._smtp-client TXT "dmp=allow"

5.3 By Internet Protocol v6 (IPv6) Address

   We can trivially extend the Protocol to identify authorized IPv6
   addressed hosts.  The template for identifying IPv6 hosts as
   Designated Mailers is identical to the template for IPv4, only using
   reversed IPv6 addresses as part of the record names.

   ;Required: DMP placeholder
   _smtp-client.${DOMAINNAME} TXT "dmp="
   ;Recommended: DMP default record
   *._smtp-client.${DOMAINNAME} TXT "dmp=deny"
   ;Optional: DMP records
   ${REVERSIPv6_1}.ip6._smtp-client.${DOMAINNAME}. TXT "dmp=allow"
   ${REVERSIPv6_2}.ip6._smtp-client.${DOMAINNAME}. TXT "dmp=allow"
   [...]
   ${REVERSIPv6_N}.ip6._smtp-client.${DOMAINNAME}. TXT "dmp=allow"

   ${REVERSIPv6_N} represents a reverse nybble of the IPv6 address as
   used in ip6.arpa.  For instance, The IPv6 address
   2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 becomes
   "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".

   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------------|
       =============================                      |
             |                                            |


Fecyk                  Expires - September 2003              [Page 11]
                     Designated Mailers Protocol          August 2003

             |                                      ============
             No                                     | 250 OK   |
             |                                      | Resume   |
             |                                      | Normally |
             |                                      ============
   =======================================
   | Server performs DMP Protocol lookup |
   =======================================
             |
       =============
       | Response? |-----------|---------------|---------------|
       =============           |               |               |
             |                 |               |               |
         Success            Success      NXDOMAIN or       SERVFAIL
     Valid DMP Record   Valid DMP Record Not Valid DMP or      |
        "dmp=allow"        "dmp=deny"    No TXT RR Record      |
             |                 |               |               |
             |                 |               |               |
             |                 |      ================  ===============
             |                 |      | Do I accept  |  | Do I accept |
             |                 |      | mail from    |  | mail from   |
             |                 |      | non-DMP site?|  | (possibly)  |
             |                 |      |              |  |non-DMP site?|
             |                 |      ================  ===============
             |                 |               |               |
             |                 | |---No--------|           |---|
             |                 | |             |           |   |
             |                 | |            Yes         Yes  No
             |                 | |             |           |   |
             |                 | |    ===================  |   |
             |                 | |    | Server Performs |  |   |
             |                 | |    | dmp= lookup     |  |   |
             |                 | |    ===================  |   |
             |                 | |             |           |   |
             |                 | |    ===================  |   |
             |                 | |    | dmp= found?     |  |   |
             |                 | |    ===================  |   |
             |                 | |             |           |   |
             |                 | |  |-Yes------|           |   |
             |                 | |  |          |           |   |
             |                 | |  |          No          |   |
             |                 | |  |          |           |   |
             |                 | |  |          |  |--------|   |
             |                 | |  |          |  |            |
         ===========      =============    ===========   ==============
         | 250 OK  |      | 550 ERROR |    | 250 OK  |   | 451 ERROR  |
         | Resume  |      | Need DMP  |    | Resume  |   | Cannot see |
         | Normally|      | Records   |    | Normally|   | DMP records|
         ===========      =============    ===========   ==============


Fecyk                  Expires - September 2003              [Page 12]
                     Designated Mailers Protocol          August 2003


   Designated Mailers 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. [n3]

   Previous drafts eliminated this second Protocol lookup to determine
   if a domain participates or not.  Because of discoveries in testing
   this had to be restored.  However, there are ways to avoid
   performing this lookup; see Appendix B.

   Participating servers MAY bypass the Protocol altogether for chosen
   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 email.  Example authentication protocols
   include POPAUTH, SMTP AUTH, client certificates and so on.  Doing
   this avoids requiring dynamically created records for dial-up users
   and roaming users.

   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, the server MAY refuse email until the senders
   participate in the Protocol, or accept the message and include
   additional headers in the message to inform the recipient.


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. [n3]

   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.0.2.1]
   C: MAIL FROM:<user@example.com>
   (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]

   An example of a rejected (dmp=deny) session from an undesignated
   host claiming to be part of a participating domain to a
   participating host:


Fecyk                  Expires - September 2003              [Page 13]
                     Designated Mailers Protocol          August 2003


   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.0.2.1]
   C: MAIL FROM:<user@example.com>
   (server looks up 1.2.0.192.in-addr._smtp-client.example.com and
   receives "dmp=deny")
   S: 550 ERROR client at 192.0.2.1 is not a Designated Mailer for
   example.com
   C: RCPT TO:<receipient@foo.bar>
   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 and dmp=) session from an
   undesignated host claiming to be part of a participating domain,
   only where the first lookup returns NXDOMAIN:

   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.0.2.1]
   C: MAIL FROM:<user@example.com>
   (server looks up 1.2.0.192.in-addr._smtp-client.example.com and
   returns NXDOMAIN)
   (server looks up _smtp-client.example.com and receives "dmp=")
   S: 550 ERROR client at 192.0.2.1 is not a Designated Mailer for
   example.com

   An example of a successful session from a host belonging to a
   non-participating domain (NXDOMAIN), 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.0.2.1]
   C: MAIL FROM:<user@example.com>
   (server looks up 1.2.0.192.in-addr._smtp-client.example.com and
   returns NXDOMAIN)
   (server looks up _smtp-client.example.com and returns NXDOMAIN)
   S: 250 OK, mail from user@example.com.
   [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:



Fecyk                  Expires - September 2003              [Page 14]
                     Designated Mailers Protocol          August 2003

   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.0.2.1]
   C: MAIL FROM:<user@example.com>
   (server looks up 1.2.0.192.in-addr._smtp-client.example.com and
   returns NXDOMAIN)
   (Note that, in this case, a lookup for _smtp-client.example.com
   isn't necessary)
   S: 550 ERROR cannot verify 192.0.2.1 as sender for example.com.

   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
   S: 250 mail.example.net Hello not-clientmachine.example.com
   [192.0.2.1]
   C: MAIL FROM:<user@example.com>
   (server looks up 1.2.0.192.in-addr._smtp-client.example.com and
   returns SERVFAIL)
   (Note that, in this case, a lookup for _smtp-client.example.com is
   not necessary)
   S: 451 ERROR cannot verify 192.0.2.1 as sender for example.com at
   this time.

   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 Mailers Protocol.  The
   host acting as the forwarding agent rarely is a Designated Mailer
   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 Mailer for the sender's domain.


Fecyk                  Expires - September 2003              [Page 15]
                     Designated Mailers Protocol          August 2003


   The relaying MTA only has to use their "Allow Relay" list or an
   authentication mechanism to permit SMTP traffic from the MUA, as is
   accepted practice. [i5] Hosts running MUAs do not need their own DMP
   records if they use a relay or smart host that has them.

8.2 Secondary Mail Exchangers

   Larger Internet providers use a network of peer mail exchangers and
   directly inject email 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 Mailer 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.
     - Program the Secondary to alter the sender envelope, and
     designate the Secondary as a Designated Mailer for itself, similar
     to 5.2 above.  An altered sender envelope could contain the
     original sender's information, for instance including the original
     sender envelope directly:

     MAIL FROM:<originalsender(at)example.com@secondarymx.example.net>

     ...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.


Fecyk                  Expires - September 2003              [Page 16]
                     Designated Mailers Protocol          August 2003


   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 Mailer
   for itself, as described in 5.2 above.

8.5 SMTP Source Routing

   While depreciated, few SMTP sites still support source routing.
   Consider the following sender envelope:

   MAIL FROM:<@host.one,@host.two:user@host.three>

   If a participating site supports source routing, the site SHOULD
   perform its Protocol lookup on "host.one" as the client should be
   from that domain.  Otherwise, the site MUST perform its Protocol
   lookup on "host.three".


9. Accepting Mail from the Null Sender Envelope: MAIL FROM:<>

   As there is no domain to perform a DMP 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 [n4], the Null reverse-path
   accompanies Delivery Status Notifications, Message Disposition
   Notifications, and other messages which are notifications about
   previous, non-null-enveloped 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 Mailer for itself as described in 5 and 5.2 above.
   To strengthen this, a recipient server MAY inspect the forward or



Fecyk                  Expires - September 2003              [Page 17]
                     Designated Mailers Protocol          August 2003

   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.0.2.1]
   C: MAIL FROM:<>
   (server looks up
   1.2.0.192.in-addr._smtp-client.clientmachine.example.com and
   receives "dmp=allow")
   (optional: server looks up clientmachine.example.com and receives
   192.0.2.1, compares A RR record to connecting IP address and they
   match)
   (optional: server looks up 1.2.0.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 Null reverse-path message coming from
   clientmachine.example.com

   With the exception of using the HELO or EHLO host name as the domain
   to perform the DMP lookup on, and the optional comparisons suggested
   above, the flowchart for handling null reverse-path messages is
   identical to that for handing other messages.

   Note that a HELO or EHLO host name is not necessarily a mail domain.
   DMP only treats it as one for the purpose of performing a Protocol
   lookup, and only for messages with null reverse-paths.


10. Security Considerations

10.1 DNS Security

   Designated Mailers Protocol relies solely on DNS to verify
   Designated Mailer 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
   Mailer records for that domain. Best current practices for DNS
   server security will prevent these and similar abuses.  DMP records
   may reside on DNSSEC servers without changes to the Protocol.

10.2 Mail Transfer Agent Security

   Compromised hosts already identified as Designated Mailers may be
   used to send unauthorized email in the name of the designator's
   domain. Best current practices for SMTP MTAs in general will prevent
   these and similar abuses.


Fecyk                  Expires - September 2003              [Page 18]
                     Designated Mailers Protocol          August 2003


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 [n5]:

     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 Mailers Protocol still allows a user to send mail on
   behalf of another within the same domain.  It also still allows
   mailing list systems to send mail to subscribers on behalf of other
   subscribers in different domains.

   DMP does not affect the From or Reply-to headers, or body of a
   message.  It still allows sending mail on behalf of another, while
   using an envelope authorized for use within the sender's domain.

   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.  This author can live with losing a little otherwise-useful
   functionality for a very large margin of protection against them.


Appendix A: Why the Default Record was Restored



Fecyk                  Expires - September 2003              [Page 19]
                     Designated Mailers Protocol          August 2003

   Those who have followed the Protocol's development to this point
   will note that this author tried to eliminate the need for more than
   one DNS query using DNS wildcard records.  Testing revealed an
   inconsistency between implementations of DNS concerning wildcards.

   RFC 1034 4.3.2 [n3] describes the algorithm with which DNS servers
   are to parse a name record file.  That algorithm allows for wildcard
   nodes, but allows for sub-nodes below the wildcard in the DNS tree
   to override the wildcard.  For instance, with the following name
   records in place:

   $ORIGIN _smtp-client.example.com.
   *                    TXT   "dmp=deny"
   1.2.0.192.in-addr TXT   "dmp=allow"

   ...a lookup of x.x.x.192.in-addr._smtp-client.example.com (where "x"
   could be any RFC 1034-legal string) would return NXDOMAIN, and not
   the originally intended default record of "dmp=deny".  A lookup of
   other records outside *.192 would return the intended default
   record.

   This is clearly defined in RFC 1034, and later clarified in a
   work-in-progress titled draft-ietf-dnsext-wcard-clarify-00.txt.
   However, most DNS server implementations treat a wildcard record of
   this nature as override ALL other possible lookups that aren't
   explicitly defined, such as 1.1.168.192 above.

   This author had to restore the second lookup in order to accommodate
   RFC 1034's requirements, and not depend on any specific
   implementation's algorithm.  This is in spite of an overwhelming
   number of DNS sites that violate RFC 1034 4.3.2 in this author's
   favour.  However, this change effectively eliminates the need for
   wildcard records, avoiding the wildcard problem entirely.

   Sites that participate in the Protocol may choose DNS
   implementations that work to their best advantage, so they can
   reduce the number of maintained records.  However, no one DNS
   implementation is required to participate.


Appendix B: How to Avoid Looking Up the Default Record

   The second Protocol lookup, originally introduced in the first draft
   and restored in this draft, will impact the DNS system harder at
   first.  This author expects this impact will diminish as sites adopt
   the Protocol.

   However, participating sites and MTA authors can take steps to avoid
   performing this lookup immediately.  For example:


Fecyk                  Expires - September 2003              [Page 20]
                     Designated Mailers Protocol          August 2003


   - A participating MTA MAY maintain a list of domains known to
   participate.  As the MTA retrieves "dmp=allow" from participating
   domains, it could store the domain name in a local list to check
   against in case future Protocol lookups on the domain return
   NXDOMAIN.  The lifetime for storing this record COULD be as long as
   the DNS record's lifetime as returned by the participating site's
   DNS server.
   - A participating site's DNS server COULD use a DNS implementation
   that treats wildcard records slightly differently from RFC 1034
   4.3.2, that is, allow the wildcard to substitute for any node not
   explicitly defined in the DNS zone file.
   - Over time, participating sites MAY choose to bypass this second
   lookup altogether.  This will depend on the adoption rate of DMP.


Appendix C: Stupid Spammer Tricks

   C.1: Bogus Subdomains

   If example.com participates in the Protocol, a spammer could still
   spoof a subdomain of example.com.  Sites that accept mail from
   non-DMP sites could accept mail from the spammer.

   Already, spam-aware MTAs could perform MX and A RR lookups on the
   domain in the MAIL FROM: command, to ensure that the domain exists
   and normally handles SMTP.  This kind of check could occur before
   any DMP lookup.

   Of course, as DMP is adopted, a participating site could refuse mail
   from non-DMP sites, eliminating this problem entirely.


References
                    
   n1. Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997

   n2. Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC
      1034, November 1987

   n3. 4.3.2 of Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
      April 2001

   n4. 4.5.5 of Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
      April 2001

   n5. 7.1 of Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
      April 2001


Fecyk                  Expires - September 2003              [Page 21]
                     Designated Mailers Protocol          August 2003

   i1. 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.

   i2. Gulbrandsen, A., Vixie, P., Esibov, L., "A DNS RR for specifying
      the location of services (DNS SRV)", RFC 2782, February 2000

   i3. Rosenbam, R., "Using the Domain Name System To Store Arbitrary
      String Attributes", RFC 1464, May 1993

   i4. Derek J. Balling <dredd@megacity.org> for initial design of the
      DNS record template and explanation, and "der Mouse"
      <mouse@rodents.montreal.qc.ca> for generalizing it into the
      current form.

   i5. 2.1 of Lindenberg, G., "Anti-Spam Recommendations for SMTP
      MTAs", RFC 2505, February 1999



Acknowledgments

   Derek J. Balling <dredd@megacity.org> for initial design of the DNS
   record template and explanation, and "der Mouse"
   <mouse@rodents.montreal.qc.ca> for generalizing it into the current
   form.

   Michael A. Smith for the hint to RFC 1464.

   Jack Bates for SMTP Source Routing hints.

   Steve Atkins and Bill Cole for DNS hints.

   "der Mouse" for IPv6 hints and implementation testing.

   "Zefram" for first uncovering the wildcard problem, and everyone
   else already mentioned for detailing it.




                                                                        

Author's Addresses

   Gordon Fecyk
   Pan-Am Internet Services



Fecyk                  Expires - September 2003              [Page 22]
                     Designated Mailers Protocol          August 2003

   24 - 482 Young Street
   Winnipeg, MB  R3B 2S6
   Canada
   Phone: (204) 292-9970
   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 - September 2003              [Page 23]