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 msid [ Subject] 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 msid Receiver 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, . [NET2006] Duan, Z., Dong, Y., and K. Gopalan, "DMTP: Controlling Spam Through Message Delivery Differentiation", Proc. Networking 2006, Coimbra, Portugal, May 2006, . [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, . 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]