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]