Internet DRAFT - draft-duan-smtp-receiver-driven
draft-duan-smtp-receiver-driven
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]
