Network Working Group Z. Duan Internet-Draft K. Gopalan Expires: November 5, 2005 Florida State University Y. Dong University of Hawaii May 4, 2005 Receiver-Driven Extensions to SMTP draft-duan-smtp-receiver-driven-00.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 November 5, 2005. Copyright Notice Copyright (C) The Internet Society (2005). 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 November 5, 2005 [Page 1] Internet-Draft Receiver-Driven Extensions to SMTP May 2005 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 . . . . . 7 3.3 Differentiated Mail Transfer Protocol (DMTP) . . . . . . . 7 3.4 Constructing Message IDs . . . . . . . . . . . . . . . . . 11 3.5 Populating Sender Classifiers . . . . . . . . . . . . . . 11 3.6 Incremental Deployment . . . . . . . . . . . . . . . . . . 12 3.7 Considerations for Supporting Mailing lists . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 18 Duan, et al. Expires November 5, 2005 [Page 2] Internet-Draft Receiver-Driven Extensions to SMTP May 2005 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] that complements the current sender-driven SMTP protocol with two new commands and one new reply code. DMTP attempts to achieve the following design goals: o Receivers should have greater control over how messages are delivered to them; o Messages from regular correspondents (or trusted sites) should be handled in the same manner as in the current SMTP architecture; o Senders other than regular correspondents (or trusted sites) should be given the capability to express their intention to communicate without delivering the entire message; o DMTP must allow for incremental deployment. 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 places greater overhead on the spammers for storing and managing their own outgoing messages. DMTP also provides a smooth transition path from the current SMTP architecture. By granting greater control over message delivery to the receivers and imposing greater message storage and Duan, et al. Expires November 5, 2005 [Page 3] Internet-Draft Receiver-Driven Extensions to SMTP May 2005 maintenance overhead on the senders, DMTP provides significant advantages in controlling spam. For example, DMTP provides a disincentive for spammers to hide their tracks by frequently changing their IP addresses. This also helps to improve the effectiveness of real-time blacklists against spamming sites. 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 extensions to the SMTP architecture. Duan, et al. Expires November 5, 2005 [Page 4] Internet-Draft Receiver-Driven Extensions to SMTP May 2005 2. Terminology o Sender: The end-user sending an email message. o Receiver: The 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 -- MUA receiving an email message. o SMUA: Sending Mail User Agent -- 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 -- MTA that accepts an email from a Sending MTA (SMTA) and delivers it to an RMUA. o SMTA: Sending Mail Transfer Agent -- MTA that accepts an email from an SMUA and delivers it to an RMTA. Duan, et al. Expires November 5, 2005 [Page 5] Internet-Draft Receiver-Driven Extensions to SMTP May 2005 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. Email-address-level classifiers are similar to the mail filters configured by end-users within current MUAs. MTA-level classifiers are managed by administrators of MTA servers, whereas the email- address-level classifiers are managed by end-users. 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. Duan, et al. Expires November 5, 2005 [Page 6] Internet-Draft Receiver-Driven Extensions to SMTP May 2005 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 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 (or headers) 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. In the next section, we present the details of the simple receiver-driven extensions to SMTP that support differentiated message delivery. 3.3 Differentiated Mail Transfer Protocol (DMTP) DMTP adds a new reply code (253) and two new commands (MSID and GTML) to SMTP. The new reply code 253 conveys the following meaning: 253: the message will not be accepted immediately, don't send DATA command. Instead, send a message identifier using the MSID command (see below). When an SMTA receives reply code 253, it stores the message locally at the sender side in a sender-specific folder and generates a reference message identifier (which will be described in the next subsection). 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 [SP Subject] CRLF Duan, et al. Expires November 5, 2005 [Page 7] Internet-Draft Receiver-Driven Extensions to SMTP May 2005 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 should not exceed a configurable maximum length. 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: "GTML:" 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. 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 using (1) the msid of the intent message received from SMTA, (2) the receiver email address, and (3) K_RMTA -- the secret key of the RMTA. 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 an email message. This intent message is delivered to the receiver 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 Duan, et al. Expires November 5, 2005 [Page 8] Internet-Draft Receiver-Driven Extensions to SMTP May 2005 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. Duan, et al. Expires November 5, 2005 [Page 9] Internet-Draft Receiver-Driven Extensions to SMTP May 2005 The following algorithm summarizes the message delivery mechanism at RMTA that uses only MTA-level classifiers. 0. /* RMTA's logic to handle message delivery from SMTA */ 1. ip = SMTA's IP address; 2. dn = SMTA's domain name; 3. if { (ip OR dn) is denied } 4. /* messages to be blocked */ 5. reply with 550; /* to the requesting TCP session*/ 6. close TCP session; 7. else if { (ip OR dn) is allowed } 8. /* good citizens */ 9. reply with 220; 10. proceed as original SMTP does; 11. else 12. /* unclassified sources */ 13. reply with 253; /* new reply code */ 14. accept MAIL FROM command; 15. accept RCPT TO command; 16. accept MSID command; /* new command */ 17. reject DATA command; 18. hash H = phi(msid, receiver, K_RMTA); 19. Compose a short message 20. /* with H being the Subject and intent being the Body 21. and sender being a special account on RMTA */ 22. Store the short message in receiver's incoming message folder; 23. 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. RMTA: Send ELHO command; 7. RMTA: Send GTML command; 8. SMTA: Send DATA command followed by the message; 9. RTMA: Close TCP connection with SMTA; 10. RMTA: Store message in receiver's incoming message folder; 11. RMTA: else 12. RMTA: Discard the short message; 13. RMTA: end if 14. RMUA: Retrieve new messages from POP3; Duan, et al. Expires November 5, 2005 [Page 10] Internet-Draft Receiver-Driven Extensions to SMTP May 2005 3.4 Constructing Message IDs A sender uses an MUA to compose outgoing messages [RFC2821]. After a message is composed by the sender, the MUA delivers the message to the SMTA. The SMTA maintains one outgoing message folder for each sender. This folder contains every 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.) 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, say 128 (or 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. The following text describes one possible technique for generating secure msids, though other techniques such as using a simple hash function might also be deemed sufficient. First, when an SMTA stores a message M, it assigns a 16-byte random index string M_index to the message, which can be a file name or a primary search key in a fast-lookup database. This index is only known to the SMTA. Then, SMTA generates an msid for M using the tuple (M_index, IP_SMTA, IP_RMTA, K_SMTA) where IP_SMTA is the IP address of the SMTA, IP_RMTA is the IP address of the RMTA, and K_SMTA is a secret key at the SMTA and is not shared with anyone. We have M_msid = M_index XOR H(IP_SMTA || IP_RMTA, K_SMTA), where function H is a secure hash function (e.g., MD5 or SHA-1) and || is a string concatenation operation. When the SMTA needs to fetch the message, it can easily restore the index of the message as follows: M_index = M_msid XOR H(IP_SMTA || IP_RMTA, K_SMTA). To speed up the message search, the SMTA can use both M_msid and IP_RMTA as search keys, where the extra IP_RMTA helps to further minimize the chances of conflicting M_msids from different RMTAs. 3.5 Populating Sender Classifiers As discussed earlier, 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 Duan, et al. Expires November 5, 2005 [Page 11] Internet-Draft Receiver-Driven Extensions to SMTP May 2005 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 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, it is highly likely that market forces would result in reputed sources compiling a reliable list of allowed and denied SMTAs which can be readily used by DMTP-compliant RMTAs in much the same manner as the current DNS-based reverse black-lists (RBLs) operate. 3.6 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 alternative incremental deployment paths 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 Duan, et al. Expires November 5, 2005 [Page 12] Internet-Draft Receiver-Driven Extensions to SMTP May 2005 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. In the following discussion, we give the example of one possible sender-discouragement scheme that relies on challenges and responses. However other sender-discouragement schemes may also be employed depending on their effectiveness. In order to distinguish traditional SMTP-compliant MTAs from DMTP- compliant MTAs, the DMTP-compliant MTAs include the keyword "DMTP" in the EHLO command. Essentially when a message delivery request arrives from an unclassified non-DMTP-compliant SMTA, the RMTA sends a challenge to the sender and the complete message is delivered to the receiver only if the sender can solve the challenge. After an RMTA receives a message from an unclassified non-DMTP-compliant source, it stores the message on the server (will not deliver to the receiver), and hashes the message to create a handle. Then a challenge is sent to the sender via email with the handle included in the Subject line of the challenge message. When the sender replies back with the response to the challenge, it includes the same handle in the Subject line. This enable RMTA to match the sender's response with the corresponding challenge and verify that the response to the challenge is indeed correct. The complete message is delivered to the receiver only if the challenge is correctly solved by the sender. In certain circumstances, it may be desirable to perform special processing on challenge messages at the SMTA. For instance, as we discuss below, challenges sent by mistake to a mailing list should not be delivered to the entire list, but should be filtered and either automatically processed or discarded. For such automated processing needs at the SMTA, the Subject line in challenge messages from RMTA should begin with the pattern [CHALLENGE], followed by the challenge handle. The following figure illustrates the message acceptance algorithm executed at a DMTP-compliant RMTA to support incremental deployment of DMTP. Duan, et al. Expires November 5, 2005 [Page 13] Internet-Draft Receiver-Driven Extensions to SMTP May 2005 1. ip = SMTA's IP address; 2. dn = SMTA's domain name; 3. if { (ip OR dn) is denied } 4. /* block such senders */ 5. reply with 550; /* to the requesting TCP session) */ 6. close TCP session; 7. else if { (ip OR dn) is allowed } 8. reply with 220; 9. proceed as original SMTP does; 10. else 11. /* unclassified sources */ 12. reply with 220; 13. proceed to the EHLO command; 14. /* SMTA supporting DMTP will include 15. keyword ``DMTP'' in EHLO command */ 16. if { found keyword ``DMTP'' in EHLO } 17. /* SMTA supports DMTP */ 18. proceed according to DMTP; 19. else 20. /* SMTA does not support DMTP */ 21. respond to DATA command with reply code 354; 22. receive message; 23. respond with 550; /* permanent error */ 24. store message; /* message invisible to receiver */ 25. hash message to get a handle; 26. send challenge to sender with the handle; 27. /* message becomes visible to receiver 28. only after challenge is solved by the sender */ 29. end if 30. end if 3.7 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 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- Duan, et al. Expires November 5, 2005 [Page 14] Internet-Draft Receiver-Driven Extensions to SMTP May 2005 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, then the RMTA will reply back with the reply code 253, requesting an intent message instead of the complete message. Second, if the mailing list RMTA is non-DMTP-compliant, the RMTA will send a challenge email 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 253, it immediately closes the corresponding TCP connection and if the non-DMTP-compliant SMTA receives a challenge message (which is identified by the [CHALLENGE] pattern in the Subject line), then it simply ignores and discards the challenge 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 forward large number of challenge messages from every posting back onto the mailing lists. 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. Duan, et al. Expires November 5, 2005 [Page 15] Internet-Draft Receiver-Driven Extensions to SMTP May 2005 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 and SMTA uses the RMTA's IP address as input 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, "DiffMail: A Differentiated Message Delivery Architecture to Control Spam", Technical Report TR-041025, Department of Computer Science, Florida State University, October 2004, . [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: Implications of Protocol Design on Controlling Unwanted Traffic", Usenix SRUTI 2005 Workshop, Cambridge, MA, July 2005, . Duan, et al. Expires November 5, 2005 [Page 16] Internet-Draft Receiver-Driven Extensions to SMTP May 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 November 5, 2005 [Page 17] Internet-Draft Receiver-Driven Extensions to SMTP May 2005 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 (2005). 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 November 5, 2005 [Page 18]