Internet Draft J. R. Levine
Expires 13 May 1998 I.E.C.C.
draft-levine-bmtp-00.txt 13 November 1997
Bulk Mail Transfer Protocol
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working doc-
uments 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."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
1. Abstract
Bulk Mail Transfer Protocol (BMTP) provides a channel for the delivery
of ''bulk mail'' electronic mail. BMTP is a service parallel to but sepa-
rate from SMTP. The specification of BMTP is intended to be similar
enough to SMTP that existing SMTP clients and servers can easily be
adapted for BMTP. Extensions provide for categorizing messages by
class, and for authorizing the client to the server, to aid in the
implementation of cost-sharing systems.
2. Introduction
SMTP[1,2] has gained wide acceptance as the Internet's delivery system
for electronic mail. SMTP mail is analogous to postal "first class"
mail in that messages are addressed individually and delivered as
quickly as possible. As the Internet has evolved from its origins in
research and acadaemia, the need has become apparent for a service anal-
ogous to "third class" mail, a lower urgency service where messages may
or may not be individually addressed. Just as with SMTP mail, each
server's management can set their own policies about whether and from
whom they will accept BMTP mail and how incoming mail is processed.
The BMTP protocol is identical to extended SMTP with two exceptions:
BMTP omits a few features not appropriate for the delivery of bulk mail,
Levine [Page 1]
Internet Draft Bulk Mail Transfer Protocol 14 October 1997
and BMTP provides one ESMTP-like extension, Class. The Class extension
advises the server of the class of an incoming message so that the
server may direct the message to recipients wishing to receive that
class of message.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
3. Service Port
BMTP servers listen on well-known port 668.
4. BMTP Addressing
The form of a BMTP address is identical to that of an SMTP address,
except that a BMTP address MUST NOT use path routing or the informal
"percent hack" to attempt to route mail through intermediate hosts.
BMTP adds the concept of a "boxholder" message, one intended to be sent
to all interested recipients. To send a boxholder message, the client
uses the reserved address "boxholder" with no @-sign or domain in the
MAIL command.
Boxholder messages permit more efficient delivery of bulk mail. A
client SHOULD transmit a single unaddressed copy of a message to a
server, rather than multiple individually addressed copies if the inten-
tion is to send the message to all interested recipients on the server.
A system's management may provide a scheme through which users can spec-
ify their preferences regarding which classes of bulk mail they wish to
receive. Any boxholder message is delivered to the recipients who wish
to receive that message's class of mail. Should a user's preferences
change, he or she can advise local system management of the new prefer-
ences, so the new preferences take effect immediately with no need to
update a central preference database nor to notify all the BMTP clients
individually.
The Class extension, described below, tells the server to which topic
class a message belongs, so the server can deliver BMTP messages appro-
priately.
5. Cost Sharing
The implementation of SMTP places most of the cost of delivering a mes-
sage on the receipient, who must receive, store, and often forward or
redeliver the message to the ultimate recipient. Since SMTP does not
provide any facilities to authenticate the sender, SMTP servers must
accept mail from all senders indiscriminately, or use crude measures
Levine [Page 2]
Internet Draft Bulk Mail Transfer Protocol 14 October 1997
such as IP address ranges to decide whether to accept or reject incoming
mail.
BMTP encourages a more flexible model in which senders and receivers may
decide to share the costs of delivering mail, or a sender may wish to
offer a financial inducement to the recipient to deliver its messages.
Note that cost sharing is optional; any BMTP server MAY accept mail
whether or not the sender has identified itself.
Initially, receivers must identify senders by the sender's IP address.
When authentication features are added to SMTP, those same features will
be added to BMTP to permit more secure and flexible identification of
senders to receivers.
6. Locating BMTP Hosts
A client locates a host for the delivery of BMTP mail in exactly the
same way that a client locates an SMTP host, using MX and A records from
the Domain Name Service[4]. Although many hosts will provide both BMTP
and SMTP, if a host does not respond or refuses a connection on port
668, a client MUST NOT attempt to deliver BMTP messages using SMTP or
any other service.
7. BMTP Verbs
BMTP uses the same command syntax and formats as extended SMTP, but
omits verbs not appropriate for bulk mail. The verbs DATA, EHLO, HELO,
QUIT, RSET, HELP, and NOOP are defined as in extended SMTP and MUST be
provided by a server. The verbs VRFY, EXPN, SEND, SOML, SAML, and TURN
are not included in BMTP, and BMTP clients MUST NOT send them.
The ESMTP extensions for command pipelining[6], enhanced error codes
[7], message size declaration [8], and 8bit-MIME transport[9] are
defined as for SMTP. BMTP servers MAY support any or all of them; BMTP
clients MUST use only extensions supported by a server as defined in
[10].
The MAIL verb is defined as in SMTP, except that the argument is a mail-
box, rather than a return path. Note that a null address <> is not a
valid mailbox. The mailbox must be a valid address where error reports
will be received and acted upon.
The RCPT verb is defined as in SMTP, except that the argument is a mail-
box, not a forward-path. The argument to RCPT can also contain the
reserved address BOXHOLDER, indicating a message to be delivered to all
interested recipients. As in SMTP, the server's acceptance of the
address in a RCPT command does not guarantee delivery of the message to
any particular person or mailbox.
Levine [Page 3]
Internet Draft Bulk Mail Transfer Protocol 14 October 1997
BMTP servers MAY implement any ESMTP extensions beyond the ones listed
above.
8. Response codes
BMTP uses the same response codes as SMTP.
9. ESMTP-like Service Extensions
BSMTP defines one new EHLO keyword CLASS. The CLASS keyword indicates
that the Class service extension is supported, and takes no parameters.
BMTP servers SHOULD implement the Class extension.
To support cost-sharing, BMTP servers SHOULD provide client authentica-
tion when possible. When authentication extension(s) are defined for
ESMTP, identical extenstions will be defined for BMTP.
10. The Class service extension
The Class service extension adds a single new optional parameter "CLASS"
to the MAIL FROM command. The value associated with this parameter is a
keyword of up to 10 chacters drawn fro the set of upper case letters and
digits, identifying the topic of the message.
The server returns 250 if the MAIL FROM command including the class is
accepted, or 550 if the class is rejected. Accepting the class does not
imply how many if any recipients accept mail in this class; it indicates
only that the server recognizes the name of the class and is prepared to
handle a message according to its procedures for that class. A Class
parameter with the special class name NONE declares that the message
belongs to no class.
11. Message Format
The format of a BMTP message is identical to that of an SMTP message[3].
Every message MUST contain a From: header line specifying a valid mail-
box where responses to the message will be accepted and acted upon.
12. Message Delivery
Once a server has accepted a message via BMTP, it may deliver the mes-
sage in the same manner as SMTP messages or process it by other means,
e.g., place it in separate mailboxes or display it in a "billboard" in a
system with a graphical interface.
Unlike SMTP messages, undeliverable BMTP messages are discarded without
Levine [Page 4]
Internet Draft Bulk Mail Transfer Protocol 14 October 1997
notice to the sender.
13. Security Considerations
BMTP is modelled on SMTP and so has most of the same security issues as
SMTP. BMTP deliberately returns less status information to the client
to avoid disclosing details about the mailboxes supported by the server
and the mail receipt preferences of the server's users.
14. References
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
USC/Information Sciences Institute, August 1982.
[2] Klensin, J., N. Freed, M. Rose, E. Stefferud & D. Crocker, "SMTP
Service Extensions", MCI et al., STD 11, RFC 1869, November 1995.
[3] Crocker, D., "Standard for the Format of ARPA Internet Text Mes-
sages", STD 11, RFC 822, UDEL, August 1982.
[4] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
974, BBN, January 1986.
[5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
MIT/RSADSI, April 1992.
[6] Freed, N., "SMTP Service Extension for Command Pipelining", RFC
2197, Innosoft, September 1997.
[7] Freed, N., "SMTP Service Extension for Returning Enhanced Error
Codes", RFC 2034, Innosoft, October 1996.
[8] Klensin, J., N. Freed, & K. Moore, "SMTP Service Extension for Mes-
sage Size Declaration", RFC 1870, MCI/Innosoft/U. of Tennessee,
November 1995.
[9] Klensin, J., N. Freed, M. Rose, E. Stefferud & D. Crocker, "SMTP
Service Extension for 8bit-MIMEtransport", RFC 1652,
MCI/Innosoft/Dover Beach/NMA/Silicon Graphics, July 1994.
[10] Klensin, J., N. Freed, M. Rose, E. Stefferud & D. Crocker, "SMTP
Service Extensions", RFC 1869, MCI/Innosoft/Dover Beach/NMA/Silicon
Graphics, November 1995.
15. Author's Address
John R. Levine
I.E.C.C.
Levine [Page 5]
Internet Draft Bulk Mail Transfer Protocol 14 October 1997
PO Box 640
Trumansburg NY 14886 USA
johnl@iecc.com
Levine [Page 6]