[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network Working Group                                            Z. Duan
Internet-Draft                                                K. Gopalan
Expires: January 5, 2007                        Florida State University
                                                                 Y. Dong
                                                    University of Hawaii
                                                            July 4, 2006


                   Receiver-Driven Extensions to SMTP
                 draft-duan-smtp-receiver-driven-03.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on January 5, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The Differentiated Mail Transfer Protocol (DMTP) provides simple
   extensions to the Simple Mail Transfer Protocol (SMTP) that enable
   receivers to exercise greater control over the email delivery
   process.  The current SMTP-based email delivery architecture is
   fundamentally sender-driven and distinctly lacks receiver control
   over the message delivery mechanisms.  This document describes DMTP



Duan, et al.             Expires January 5, 2007                [Page 1]

Internet-Draft     Receiver-Driven Extensions to SMTP          July 2006


   that enables receivers to classify senders into three categories --
   allowed, denied, and unclassified -- and process the delivery of
   messages from each category independently.  As is the current
   practice, receivers may directly accept messages from senders in the
   allowed category and decline senders in the denied category.  In
   addition, DMTP receivers require senders in the unclassified category
   to store messages on the senders' own mail servers.  Such messages
   are retrieved only if and when the end receivers wish to do so.  By
   granting  greater control over message  delivery to receivers and
   imposing greater message storage and maintenance overhead on senders,
   DMTP provides  significant  advantages in  controlling spam.  DMTP
   also easily operates in conjunction  with (but does not require) many
   currently deployed anti-spam techniques.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.   Extending  SMTP to Support Differentiated Message Delivery .   6
     3.1  Receiver-Defined SMTA Classification . . . . . . . . . . .   6
     3.2  Receiver-Driven Differentiated Message Delivery  . . . . .   6
     3.3  New Commands in DMTP . . . . . . . . . . . . . . . . . . .   7
     3.4  Extending SMTP to Support New Commands . . . . . . . . . .   8
     3.5  Message Transmission and Retrieval using DMTP  . . . . . .   8
     3.6  Constructing Message IDs . . . . . . . . . . . . . . . . .  10
     3.7  Populating Sender Classifiers  . . . . . . . . . . . . . .  11
     3.8  Incremental Deployment . . . . . . . . . . . . . . . . . .  12
     3.9  Considerations for Supporting Mailing lists  . . . . . . .  13
     3.10   Handling Mail Relay Servers  . . . . . . . . . . . . . .  14
   4.   Security Considerations  . . . . . . . . . . . . . . . . . .  16
   5.   References . . . . . . . . . . . . . . . . . . . . . . . . .  16
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  17
        Intellectual Property and Copyright Statements . . . . . . .  18


















Duan, et al.             Expires January 5, 2007                [Page 2]

Internet-Draft     Receiver-Driven Extensions to SMTP          July 2006


1.  Introduction

   The objective of Differentiated Mail Transfer Protocol (DMTP) is to
   define simple extensions to the Simple Mail Transfer Protocol (SMTP)
   [RFC2821] that provide greater control to receivers over the email
   delivery process.  The current SMTP based email delivery architecture
   is essentially sender-driven, in which any sender can push an email
   message to any receiver at will, regardless of whether or not the
   receiver is interested in receiving the message.  It is only after
   receiving the entire message that the receiver has the opportunity to
   examine the message header and contents and either accept or discard
   it.

   This document describes DMTP -- a receiver-driven differentiated
   message   delivery  protocol   [SRUTI05] [NET2006] that complements
   the current sender-driven SMTP protocol with two new commands.  DMTP
   enables receivers to classify senders into three categories --
   allowed, denied, and unclassified -- and process the message delivery
   from each category independently.  Messages from allowed senders are
   handled in the same manner as in the  current SMTP architecture and
   messages from denied senders are summarily declined.  Senders who are
   neither allowed nor denied fall under the unclassified category by
   default.  Such unclassified senders are permitted by DMTP receivers
   to convey an intent to send an email in place of sending the entire
   email.  The email itself needs to be stored at the unclassified
   sender's mail server till the intended recipient expresses interest
   in receiving the entire email message.

   Unlike the current  SMTP architecture,  DMTP grants greater control
   over message delivery to receivers, which provides us with several
   important advantages in controlling spam [DMTP-TR].  First, the
   delivery rate of spam is determined by the spam retrieval behavior of
   receivers instead of being controlled by spammers, which helps
   eradicate the economy of scale that spammers rely on.  Second,
   spammers are forced to stay online for longer periods of time
   (because the sending rate of spam is regulated by the spam retrieval
   rate of receivers), which can significantly improve the performance
   of real-time blacklists (RBLs).  Third, regular correspondents of a
   receiver do not need to make any extra effort to communicate with the
   receiver---correspondence from regular contacts is handled in the
   same manner as in the current SMTP-based email system.  In addition,
   DMTP can be easily deployed on the Internet incrementally.

   DMTP also easily operates in conjunction with currently deployed
   anti-spam   techniques  such   as   content-based  filters   and
   sender-authentication schemes.  However, DMTP is orthogonal to these
   techniques and does not require any of them to operate correctly.
   The  rest of this document describes the details of the DMTP



Duan, et al.             Expires January 5, 2007                [Page 3]

Internet-Draft     Receiver-Driven Extensions to SMTP          July 2006


   extensions to the SMTP architecture.


















































Duan, et al.             Expires January 5, 2007                [Page 4]

Internet-Draft     Receiver-Driven Extensions to SMTP          July 2006


2.  Terminology

   o  Sender: An end-user sending an email message.

   o  Receiver: An end-user intended to receive an email message.

   o  MUA: Mail User Agent -- A  tool used by the end-user for sending
      and receiving messages.

   o  RMUA: Receiving Mail User Agent -- an MUA receiving an email
      message.

   o  SMUA: Sending Mail User Agent -- an MUA sending an email message.

   o  MTA:  Mail Transfer  Agent -- An  email server that  transfers
      email messages from one  MUA to another, possibly in  coordination
      with other MTAs.

   o  RMTA: Receiving Mail Transfer Agent -- an MTA that accepts an
      email from a Sending MTA (SMTA) and delivers it to an RMUA.

   o  SMTA: Sending Mail Transfer Agent -- an MTA that accepts an email
      from an SMUA and delivers it to an RMTA.




























Duan, et al.             Expires January 5, 2007                [Page 5]

Internet-Draft     Receiver-Driven Extensions to SMTP          July 2006


3.  Extending  SMTP to Support Differentiated Message Delivery

3.1  Receiver-Defined SMTA Classification

   In order to differentiate the delivery of messages from different
   senders, the RMTAs classify SMTAs into following three categories,
   called SMTA classifiers, depending  on how  well the RMTA trusts the
   SMTA.

   o  Allowed (or trusted) MTAs : This class contains the IP addresses
      or the domain names of the SMTAs whom the RMTA trusts and from
      whom it is willing to directly accept entire email messages using
      the sender-driven model of SMTP.

   o  Denied (or black-listed) MTAs: This class contains the IP
      addresses or the domain names of the SMTAs with whom the RMTA does
      not wish to communicate.  This class may contain well-known
      spammers, or the SMTAs whose messages the RMTA wants to block.

   o  Unclassified  (or untrusted) MTAs: This class includes all SMTAs
      that do not belong to either allowed or denied category, but who
      may possibly be legitimate SMTAs.  This is the default category
      for any SMTA unless it is explicitly listed in the allowed or
      denied category.  Note that, unlike allowed and denied categories,
      this category does not require explicit enumeration of MTAs.

   The classifiers at RMTA can potentially be defined at two levels:
   MTA-level (as in the above description) and email-address-level.  An
   MTA-level classifier contains IP addresses and/or domain  names of
   the SMTAs.  MTA-level classifiers are equivalent to the IP and domain
   level black lists employed in many of today's MTAs.  In contrast, an
   email-address-level classifier includes end-user email addresses.
   This document focuses on using only MTA-level classifiers because
   these are both simple and sufficient for the operation of DMTP.
   [DMTP-TR] describes in further detail how email-address-level
   classifiers could also be incorporated to further improve the
   effectiveness of DMTP in controlling spam.

   MTA-level classifiers support coarse-grained sender differentiation
   at the level of IP-addresses or network domains of the SMTAs.  They
   do not require (but can operate in conjunction with) any other sender
   authentication mechanisms because they simply rely on IP addresses
   and/or domain names of the SMTAs.

3.2  Receiver-Driven Differentiated Message Delivery

   RMTAs apply different handling strategies for messages from the three
   different SMTA categories.  Whereas it is relatively straightforward



Duan, et al.             Expires January 5, 2007                [Page 6]

Internet-Draft     Receiver-Driven Extensions to SMTP          July 2006


   to handle messages from allowed and denied SMTAs, the principal
   challenge lies in handling the interaction with unclassified SMTAs.

   An RMTA accepts messages from allowed SMTAs in the same manner as in
   the current SMTP architecture.  Specifically, the complete messages
   that include both headers and bodies can be pushed directly from the
   SMTA to RMTA.  On the other hand, an RMTA will decline any messages
   from denied SMTAs, which typically includes well-known MTAs used by
   spammers.

   Unlike messages from allowed and denied SMTAs, the messages from
   unclassified  SMTAs can  be either legitimate or spam messages.  The
   goal here is not to permit malicious unclassified SMTAs from pushing
   spam messages and, at the same time, enable legitimate unclassified
   SMTAs to express their intent to communicate.  Hence this is the most
   critical category that a DMTP-compliant RMTA needs to manage.

   To balance these two considerations, RMTA only accepts the envelopes
   of messages from unclassified SMTAs.  The complete messages need to
   be stored at the SMTAs.  An RMUA that wishes to read such messages at
   a later convenient time can instruct its RMTA to retrieve (or pull)
   the messages from the SMTA.

3.3  New Commands in DMTP

   If  an SMTA  cannot  directly deliver  an  entire message  to the
   RMTA, because  it  is  in  the  unclassified  class of  the  RMTA
   (Section 3.4), the SMTA stores the message locally at  the sender
   side and generates a reference message identifier (Section 3.6).
   This message identifier is then sent to the RMTA using a new command
   MSID (see below, using format defined in [RFC2234]).  The MSID
   command conveys the sender's intent to send a complete message to the
   receiver.

   MSID <SP> msid [ <SP>  Subject] <CRLF>

   where  msid is the  message identifier, and the optional Subject is a
   a brief string that is simply the original subject line of the email
   message or an auto-generated summary text of the message.  DMTP
   requires that the MSID  command line cannot exceed a maximum length
   of 32 bytes.

   The RMTA conveys this intent to the receiver's MUA (possibly through
   a POP3 [RFC1939] or IMAP [RFC3501] server) in place of the entire
   message.  If and when the actual receiver wishes to read the
   message, the RMTA retrieves the message from SMTA using a new command
   GTML which has the following syntax:




Duan, et al.             Expires January 5, 2007                [Page 7]

Internet-Draft     Receiver-Driven Extensions to SMTP          July 2006


   GTML <SP> msid <SP> Receiver <CRLF>

   where  msid  is the  identifier  of the  message  to  be retrieved,
   and Receiver is the email address of the receiver.  When the SMTA
   receives the GTML command, it first verifies that the  corresponding
   message is  intended for the receiver  listed in the command.  More
   importantly the SMTA verifies that the requesting RMTA is indeed  the
   mail  server responsible for  the receiver, i.e.,  the one which was
   originally contacted  by the SMTA  for message  delivery.

   Note  above  that we  assume  that  the  RMUA cannot  directly
   retrieve messages from SMTA.  Rather it relies on its RMTA to perform
   this function.  We  make   this   design  choice   based  on
   security considerations  (see  the  "Security Considerations"
   section),  limited resources on user machines (for  example, MTA
   servers normally have more powerful  spam filters than  user PCs),
   and the  reality that  some user email clients  (such as cell phones
   and other wireless  PDA devices) can only contact their own email
   servers.

3.4  Extending SMTP to Support New Commands

   A  DMTP-compliant SMTA  includes the  keyword  "DMTP" in  the MAIL
   FROM command to inform an RMTA that it supports the DMTP service
   extensions.  Note that  it is not necessary  for an RMTA  to inform
   an SMTA  that the RMTA  supports  the  service  extensions,  unless
   the  SMTA  is  in  the unclassified class  of the RMTA.  For  such
   SMTAs, the  RMTA will include the new commands MSID and GTML in  the
   reply code  250 to  the EHLO command from the SMTAs.  When  an SMTA
   receives reply  code 250 with the  MSID command, it implicitly
   indicates that the SMTA has to issue the MSID command instead of the
   DATA command.

3.5  Message Transmission and Retrieval using DMTP

   In the  following description, we discuss the  interaction between
   SMTA, RMTA, POP3 server, and RMUA  for retrieving a message  from an
   unclassified  source in greater detail (POP3 is considered here as
   only one example of an incoming mail access protocol used by MUA.
   Other incoming mail access protocols, such as IMAP, can also be used
   without any changes to the description below).

   When an RMTA receives an intent to send email from an SMTA, it first
   computes a hash value H based on the msid of the intent message
   received from SMTA and the receiver email address.  (H may be
   computed in the same manner as msid  in Section 3.6.)  The RMTA then
   composes a new short "intent message" whose  Subject line  is the
   hash  value H,  and the body conveys the intent of the sender to send



Duan, et al.             Expires January 5, 2007                [Page 8]

Internet-Draft     Receiver-Driven Extensions to SMTP          July 2006


   an email message.  This intent message is delivered to the receiver's
   incoming message folder from a special account on the  RMTA.  This
   account is only used  for handling  the delivery of intent messages
   to receivers (and the retrieval of the complete messages from the
   SMTAs when the receivers instruct to do so).

   An RMUA retrieves the intent message through its  POP3 server (just
   as it would retrieve complete messages) and then the receiver decides
   whether or not to retrieve the entire  message.  If the receiver
   decides to read the entire message, the receiver will simply reply to
   the intent message, which is delivered to the RMTA.  When the RMTA
   receives the reply, it will first re-compute the hash value H and
   verify that it matches the hash value in the Subject line.  If they
   do not match, the RMTA will simply discard the reply message.

   If they  do match, the RMTA then  issues the GTML command  to the
   remote SMTA to  retrieve the  complete email message.  After RMTA
   receives the complete message, it  stores the message in the
   incoming message folder of the receiver, which is then  retrieved by
   the RMUA via, say, its POP3 server.

   The  following algorithm  summarizes the message  delivery mechanism
   that uses only MTA-level classifiers.

     /* Message sequence between DMTP-compliant SMTA and RMTA*/
     0. SMTA: Open TCP connection to RMTA port 25;
     1. RMTA: ip = SMTA's IP address;
     2. RMTA: dn = SMTA's domain name;
     3. RMTA: if { (ip OR dn) is denied } /* messages to be blocked */
     4. RMTA:   reply with "554 DENIED";
     6. RMTA: else if { (ip OR dn) is allowed } /* good citizens */
     7. RMTA:   reply with "220 OK";
     8. RMTA:   proceed using original SMTP;
     9. RMTA: else /* unclassified sources */
    10. RMTA:   reply with "220 OK";
    11. SMTA:   send "EHLO domain_name";
    12. RMTA:   reply with "250-MSID";
    13  RMTA:   reply with "250 GTML";
    14. SMTA:   send "MAIL FROM: sender_email DMTP";
    15. RMTA:   reply "250 OK";
    16. SMTA:   send "RCPT TO: receiver_email";
    17. RMTA:   reply "250 OK";
    18. SMTA:   send "MSID message_id [subject];
    19. RMTA:   reply "250 OK";
    20. RMTA:   reject any attempt from SMTA to send DATA command;
    21. RMTA:   Compute an internal hash H for the intent message;
    22. RMTA:   Compose a short intent message
    23. RMTA:     /* with H as the Subject, intent as the body



Duan, et al.             Expires January 5, 2007                [Page 9]

Internet-Draft     Receiver-Driven Extensions to SMTP          July 2006


    24. RMTA:        and sender being a special account on RMTA */
    25. RMTA:   Store intent message in receiver's incoming folder;
    26. RMTA: end if

     0. /* Procedure to retrieve complete message from intent message */
     1. RMUA: Reply to the intent message;
     2. RMTA: Recompute hash value H for intent message;
     3. RMTA: If { Recomputed hash == hash in intent message }
     4. RMTA:    /* retrieve the message from the SMTA */
     5. RMTA:    open TCP connections to SMTA at port 25;
     6. SMTA:    ip = RMTA's IP address;
     7. SMTA:    dn = RMTA's domain name;
     8. SMTA:    if { (ip OR dn) is denied } /* msgs to be blocked */
     9. SMTA:       reply with "554 DENIED";
    10. SMTA:    else if { (ip OR dn) is allowed } /* good citizens */
    11. SMTA:       reply with "220 OK";
    12. RMTA:       send "EHLO domain name";
    13. SMTA:       reply "250 OK";
    14. SMTA:    else /* unclassified sources */
    15. SMTA:       reply with "220 OK";
    16. RMTA:       send "EHLO domain name";
    17. SMTA:       reply "250-MSID";
    18. SMTA:       reply "250 GTML";
    19. SMTA:    end if
    20. RMTA:    send "GTML message_id receiver_email";
    21. SMTA:    send DATA command followed by the message;
    22. SMTA:    close TCP connection with RMTA;
    23. RMTA:    store message in receiver's incoming folder;
    24. RMTA: else
    25. RMTA:     discard the short message;
    26. RMTA: end if
    27. RMUA: Retrieve new messages from POP3;



3.6  Constructing Message IDs

   A   sender   uses  an   SMUA   to   compose   outgoing  messages
   [RFC2821] .  After a  message is composed  by the  sender, the SMUA
   delivers the message to the SMTA.  The SMTA stores the sender's
   messages that have not been delivered and have not been deleted.  An
   SMTA will delete a  message on behalf of a sender after  the message
   has been delivered to all the intended  receivers or after a certain
   configurable expiry time (It is also possible to augment MUAs to
   allow individual senders to specify  the message-specific expiry
   times via a new  message  header.  This is a possible future
   extension and is beyond the scope of this document.)




Duan, et al.             Expires January 5, 2007               [Page 10]

Internet-Draft     Receiver-Driven Extensions to SMTP          July 2006


   As discussed above, if an RMTA only accepts the header of the message
   from an unclassified SMTA, a message identifier (msid) needs to be
   generated by the SMTA for that message and sent to the receiver via
   the RMTA so that the receiver can retrieve the message at a later
   time.  An msid is defined as a fixed length string with a maximum
   length of 256 bits.  When a receiver wants to retrieve the entire
   message, the RMTA uses this msid to request the message body from the
   SMTA.

   This msid can be generated  using different techniques, and each MTA
   can choose  a  scheme  according  to  the  local  preference.
   However,  the following properties are  suggested for the resulting
   msid  of a chosen scheme.

   o  The msid should not be guessable by a third party using commonly
      available information, such as sender or receiver's email address,
      or the IP address of SMTA and RMTA.

   o  The msid should be of a form that enables SMTA to quickly search
      for a message once the RMTA sends the GTML command.


3.7  Populating Sender Classifiers

   MTA-level sender classifiers are  managed by mail server
   administrators.  However, often it might be desirable for receivers
   to supply their RMTAs with the information about which senders belong
   to allowed and denied categories.  There are many possible mechanisms
   for populating sender classifiers and this document does not
   recommend one technique over another.  Below we outline one such
   mechanism as an example to illustrate the ease with which sender
   classifiers can be automatically populated by receivers.

   RMTAs can maintain a special "classifier-config" email account used
   for populating the sender classifiers.  (This account is in addition
   to another special  account for handling short intent messages that
   was described earlier.)  SMTAs can be added or removed from different
   categories by sending commands via email to this special account.  To
   add an SMTA to the allowed category, an end-user emails the
   "classifier-config" account at its RMTA with the command "add allowed
   sender-email" in the body of the email message, where sender-email is
   the email address of the allowed sender.  The RMTA will translate the
   email address to the corresponding SMTA's domain name or IP address.
   To remove an SMTA from the allowed category, the end-user emails the
   command "remove allowed sender-email".  Manipulation of other
   categories can be handled in a similar manner.  Note that from a
   security standpoint, emails to the "classifier-config" account would
   somehow need to be authenticated, so that only legitimate users can



Duan, et al.             Expires January 5, 2007               [Page 11]

Internet-Draft     Receiver-Driven Extensions to SMTP          July 2006


   request classifier modifications.

   Alternatively, one can also have a web-based mechanism where
   authenticated users can log in and submit requests for classifier
   modifications.  Also, DMTP-compliant RMTAs can make use of publicly/
   commercially available whitelist or blacklist of SMTAs and place the
   remaining SMTAs in the unclassified category.

3.8  Incremental Deployment

   This section outlines one possible incremental deployment path for
   DMTP.  DMTP does not require one uniform incremental deployment path
   across the Internet.  Network administrators may choose an
   incremental deployment path depending on their perceived
   requirements.

   There are two basic objectives for incremental deployment strategy.
   The first objective is to enable legitimate non-DMTP-compliant
   unclassified SMTAs to communicate with DMTP-compliant RMTAs.  Note
   that the converse communication, namely DMTP-compliant SMTAs
   communicating with legacy non-DMTP-compliant RMTAs, is not an issue
   because the latter accept the entire message by default.

   The second objective is to incorporate one or more forms of sender-
   discouragement schemes at DMTP-compliant RMTAs so that spammers do
   not use the incremental deployment path as a loophole to deliver spam
   messages.  However, unlike existing sender-discouragement schemes,
   DMTP requires only the subset of unclassified non-DMTP-compliant
   SMTAs to bear any extra  overhead in  sending a message.  DMTP-
   compliant SMTAs  in the allowed category do not need to shoulder the
   additional overhead because their message delivery mechanism is the
   same as in the current SMTP architecture.

   The following figure illustrates the message acceptance algorithm
   executed at a DMTP-compliant RMTA to support incremental deployment
   of DMTP.















Duan, et al.             Expires January 5, 2007               [Page 12]

Internet-Draft     Receiver-Driven Extensions to SMTP          July 2006


     /* Message sequence between DMTP-compliant RMTA and
        non-DMTP-compliant SMTA*/
     0. SMTA: Open TCP connection to RMTA port 25;
     1. RMTA: ip = SMTA's IP address;
     2. RMTA: dn = SMTA's domain name;
     3. RMTA: if { (ip OR dn) is denied } /* messages to be blocked */
     4. RMTA:   reply with "554 DENIED";
     5. RMTA: else if { (ip OR dn) is allowed } /* good citizens */
     6. RMTA:   reply with "220 OK";
     7. RMTA:   proceed using original SMTP;
     8. RMTA: else /* unclassified sources */
     9. RMTA:      reply with "220 OK";
    10. SMTA:      send "EHLO domain_name";
    11. RMTA:      reply with "250-MSID";
    12. RMTA:      reply with "250 GTML";
    13. SMTA:      if( SMTA supports DMTP)
    14. SMTA:         send "MAIL FROM: sender_email DMTP";
    15. RMTA:         proceed according to DMTP;
    16. SMTA:      else /* SMTA does not support DMTP */
    17. SMTA:         send "MAIL FROM: sender_email";
    18. RMTA:         apply sender-discouragement (such as greylisting)
    19. RMTA:         if(SMTA passes sender discouragement)
    20. RMTA:            reply "250 OK";
    21. SMTA:            send "RCPT TO: receiver_email";
    22. RMTA:            reply "250 OK";
    23. SMTA:            send "DATA";
    24. RMTA:            reply with "354";
    25. SMTA:            send entire message;
    26. RMTA:            reply "250 OK";
    27. RMTA:            store message in receiver's incoming folder
    28. RMTA:          end if
    29. SMTA:       end if
    30. RMTA: end if


3.9  Considerations for Supporting Mailing lists

   Operation of mailing lists requires careful consideration in the
   pull-based model of DMTP.  A user who joins a mailing list already
   expresses an interest in receiving all messages from the mailing
   list.  Therefore, in principle, a mailing list member should not be
   required to expend additional effort in receiving each and every
   message posted to the mailing list.  At the same time, the SMTA of a
   mailing list should not face additional overhead in delivering a
   message to a potentially large number of members on the list.

   Based on the above two considerations, this document recommends that
   the following actions should be carried out by mailing list members



Duan, et al.             Expires January 5, 2007               [Page 13]

Internet-Draft     Receiver-Driven Extensions to SMTP          July 2006


   and the SMTAs for mailing lists.  A user who joins a mailing  list
   should request his/her RMTA to add the SMTA of the mailing list into
   the allowed category.  For instance, this could be done semi-
   automatically by sending an  email message to the "classifier-config"
   account at the local RMTA as described earlier.

   It is also possible that a user may not necessarily remember to
   request his/her DMTP-compliant RMTA to add the SMTA of the mailing
   list to the allowed category.  In such a case, when the RMTA receives
   a message delivery request from a mailing list for its local user,
   there are two possible responses from RMTA.  First, if the mailing
   list SMTA is DMTP-compliant, the RMTA will request an intent message
   instead of the complete message.  Second, if the mailing list SMTA is
   non-DMTP-compliant,    the    RMTA    will   apply    a    certain
   sender-discouragement scheme to the sender of the message, which
   might simply be the email address of mailing list.

   In either case, this document recommends that the SMTA of the mailing
   list simply terminates its effort to deliver the  message intended
   receiver.  That  is, if the  DMTP-compliant SMTA receives reply  code
   250 with MSID included, it immediately closes the corresponding TCP
   connection and if the non-DMTP-compliant SMTA encounters certain
   sender-discouragement imposed by  the RMTA, it simply  ignores the
   discouragement  and give up the effort to deliver the related
   message.  In summary, only mailing list members who have included the
   SMTA of a mailing  list in the allowed category of their RMTA can
   receive messages from the mailing list.

   The practical rationale behind this recommendation is three-fold. (1)
   Mailing-list members served by DMTP-compliant RMTAs would prefer not
   having to respond to a large number intent messages generated from a
   highly active mailing list. (2) DMTP-compliant SMTAs of mailing lists
   would be better off not having to manage and track messages and their
   intents for potentially large number of postings. (3) Non-DMTP-
   compliant SMTAs of mailing lists would rather not deal with the
   discouragement for every posting.  The net effect of this policy is
   to insist that a mailing list member request its RMTA to white-list
   the SMTA of the mailing list.

3.10  Handling Mail Relay Servers

   A potential issue is the use of DMTP with mail relay servers,
   especially within large organizations.  In such a case, only the
   relay server located at the interface to the external world, which we
   call the border relay, needs to be DMTP-compliant.  In addition, the
   border relay will store the outgoing emails (that are waiting to be
   pulled by receivers) on behalf of all internal mail servers.  All the
   internal mail servers are included in the border relay's allowed SMTA



Duan, et al.             Expires January 5, 2007               [Page 14]

Internet-Draft     Receiver-Driven Extensions to SMTP          July 2006


   category.  This permits the border relay to communicate using SMTP
   with the internal mail servers and using DMTP with rest of the world.

















































Duan, et al.             Expires January 5, 2007               [Page 15]

Internet-Draft     Receiver-Driven Extensions to SMTP          July 2006


4.  Security Considerations

   Retrieving  messages from  SMTAs  using GTML  command  may raise  the
   security concern regarding a malicious third party using stolen msids
   to retrieve  others'  messages.  However,  note  that  the  RMTA
   fetches  a message using  TCP.  In addition, this document recommends
   that the SMTA should use the  RMTA's IP address as one of the inputs
   to its hash function.  Hence,  even if a malicious third party  has a
   sniffed or stolen msid, it would be very difficult for him/her to
   perform a Mitnick attack to  spoof the  IP address  of the RMTA.
   Also, as  a consequence, individual receivers  cannot retrieve  their
   messages directly  from the SMTA.  Instead they need to rely on their
   corresponding RMTAs to retrieve messages.  These RMTAs can be
   authenticated by SMTAs using the MX records in the DNS servers.
   Therefore, the proposed DMTP architecture provides a level  of
   security  that is  at least  comparable to  the  current Email
   architecture.

5.  References

   [DMTP-TR]  Duan, Z., Gopalan, K., and Y. Dong, "DMTP: Controlling
              Spam Through Message Delivery Differentiation", Technical
              Report  TR-041025, Department  of Computer Science,
              Florida State University, October 2004,
              <http://www.cs.fsu.edu/~duan/projects/dmtp/dmtp.htm>.

   [NET2006]  Duan, Z., Dong, Y., and K. Gopalan, "DMTP: Controlling
              Spam Through Message Delivery Differentiation", Proc.
              Networking 2006, Coimbra, Portugal, May 2006,
              <http://www.cs.fsu.edu/~duan/projects/dmtp/dmtp.htm>.

   [RFC1869]  Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
              Crocker, "SMTP Service Extensions", RFC 1869,
              November 1995.

   [RFC1939]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
              STD 53, RFC 1939, May 1996.

   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, March 2003.

   [SRUTI05]  Duan, Z., Gopalan, K., and Y. Dong, "Push vs. Pull:



Duan, et al.             Expires January 5, 2007               [Page 16]

Internet-Draft     Receiver-Driven Extensions to SMTP          July 2006


              Implications of Protocol Design on Controlling Unwanted
              Traffic", Usenix SRUTI 2005 Workshop, Cambridge, MA,
              July 2005,
              <http://www.cs.fsu.edu/~duan/projects/dmtp/dmtp.htm>.


Authors' Addresses

   Zhenhai Duan
   Florida State University
   Department of Computer Science
   Tallahassee, FL  32306

   Phone: +1 850 645 1561
   Email: duan@cs.fsu.edu
   URI:   http://www.cs.fsu.edu/~duan


   Kartik Gopalan
   Florida State University
   Department of Computer Science
   Tallahassee, FL  32306

   Phone: +1 850 644 1685
   Email: kartik@cs.fsu.edu
   URI:   http://www.cs.fsu.edu/~kartik


   Yingfei Dong
   University of Hawaii
   Department of Electrical Engineering
   Honolulu, HI  96822

   Phone: +1 808 956 3448
   Email: yingfei@hawaii.edu
   URI:   http://www.ee.hawaii.edu/~dong/















Duan, et al.             Expires January 5, 2007               [Page 17]

Internet-Draft     Receiver-Driven Extensions to SMTP          July 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Duan, et al.             Expires January 5, 2007               [Page 18]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/