idnits 2.17.1 draft-levine-bmtp-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (13 November 1997) is 9659 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '5' is defined on line 216, but no explicit reference was found in the text ** Obsolete normative reference: RFC 821 (ref. '1') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1869 (ref. '2') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (ref. '3') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 974 (ref. '4') (Obsoleted by RFC 2821) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '5') ** Obsolete normative reference: RFC 2197 (ref. '6') (Obsoleted by RFC 2920) ** Obsolete normative reference: RFC 1652 (ref. '9') (Obsoleted by RFC 6152) -- Duplicate reference: RFC1869, mentioned in '10', was also mentioned in '2'. ** Obsolete normative reference: RFC 1869 (ref. '10') (Obsoleted by RFC 2821) Summary: 18 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft J. R. Levine 3 Expires 13 May 1998 I.E.C.C. 4 draft-levine-bmtp-00.txt 13 November 1997 6 Bulk Mail Transfer Protocol 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working docu- 11 ments of the Internet Engineering Task Force (IETF), its areas, and its 12 working groups. Note that other groups may also distribute working doc- 13 uments as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference material 18 or to cite them other than as "work in progress." 20 To view the entire list of current Internet-Drafts, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 1. Abstract 28 Bulk Mail Transfer Protocol (BMTP) provides a channel for the delivery 29 of ''bulk mail'' electronic mail. BMTP is a service parallel to but sepa- 30 rate from SMTP. The specification of BMTP is intended to be similar 31 enough to SMTP that existing SMTP clients and servers can easily be 32 adapted for BMTP. Extensions provide for categorizing messages by 33 class, and for authorizing the client to the server, to aid in the 34 implementation of cost-sharing systems. 36 2. Introduction 38 SMTP[1,2] has gained wide acceptance as the Internet's delivery system 39 for electronic mail. SMTP mail is analogous to postal "first class" 40 mail in that messages are addressed individually and delivered as 41 quickly as possible. As the Internet has evolved from its origins in 42 research and acadaemia, the need has become apparent for a service anal- 43 ogous to "third class" mail, a lower urgency service where messages may 44 or may not be individually addressed. Just as with SMTP mail, each 45 server's management can set their own policies about whether and from 46 whom they will accept BMTP mail and how incoming mail is processed. 48 The BMTP protocol is identical to extended SMTP with two exceptions: 49 BMTP omits a few features not appropriate for the delivery of bulk mail, 50 and BMTP provides one ESMTP-like extension, Class. The Class extension 51 advises the server of the class of an incoming message so that the 52 server may direct the message to recipients wishing to receive that 53 class of message. 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC 2119. 59 3. Service Port 61 BMTP servers listen on well-known port 668. 63 4. BMTP Addressing 65 The form of a BMTP address is identical to that of an SMTP address, 66 except that a BMTP address MUST NOT use path routing or the informal 67 "percent hack" to attempt to route mail through intermediate hosts. 69 BMTP adds the concept of a "boxholder" message, one intended to be sent 70 to all interested recipients. To send a boxholder message, the client 71 uses the reserved address "boxholder" with no @-sign or domain in the 72 MAIL command. 74 Boxholder messages permit more efficient delivery of bulk mail. A 75 client SHOULD transmit a single unaddressed copy of a message to a 76 server, rather than multiple individually addressed copies if the inten- 77 tion is to send the message to all interested recipients on the server. 78 A system's management may provide a scheme through which users can spec- 79 ify their preferences regarding which classes of bulk mail they wish to 80 receive. Any boxholder message is delivered to the recipients who wish 81 to receive that message's class of mail. Should a user's preferences 82 change, he or she can advise local system management of the new prefer- 83 ences, so the new preferences take effect immediately with no need to 84 update a central preference database nor to notify all the BMTP clients 85 individually. 87 The Class extension, described below, tells the server to which topic 88 class a message belongs, so the server can deliver BMTP messages appro- 89 priately. 91 5. Cost Sharing 93 The implementation of SMTP places most of the cost of delivering a mes- 94 sage on the receipient, who must receive, store, and often forward or 95 redeliver the message to the ultimate recipient. Since SMTP does not 96 provide any facilities to authenticate the sender, SMTP servers must 97 accept mail from all senders indiscriminately, or use crude measures 98 such as IP address ranges to decide whether to accept or reject incoming 99 mail. 101 BMTP encourages a more flexible model in which senders and receivers may 102 decide to share the costs of delivering mail, or a sender may wish to 103 offer a financial inducement to the recipient to deliver its messages. 104 Note that cost sharing is optional; any BMTP server MAY accept mail 105 whether or not the sender has identified itself. 107 Initially, receivers must identify senders by the sender's IP address. 108 When authentication features are added to SMTP, those same features will 109 be added to BMTP to permit more secure and flexible identification of 110 senders to receivers. 112 6. Locating BMTP Hosts 114 A client locates a host for the delivery of BMTP mail in exactly the 115 same way that a client locates an SMTP host, using MX and A records from 116 the Domain Name Service[4]. Although many hosts will provide both BMTP 117 and SMTP, if a host does not respond or refuses a connection on port 118 668, a client MUST NOT attempt to deliver BMTP messages using SMTP or 119 any other service. 121 7. BMTP Verbs 123 BMTP uses the same command syntax and formats as extended SMTP, but 124 omits verbs not appropriate for bulk mail. The verbs DATA, EHLO, HELO, 125 QUIT, RSET, HELP, and NOOP are defined as in extended SMTP and MUST be 126 provided by a server. The verbs VRFY, EXPN, SEND, SOML, SAML, and TURN 127 are not included in BMTP, and BMTP clients MUST NOT send them. 129 The ESMTP extensions for command pipelining[6], enhanced error codes 130 [7], message size declaration [8], and 8bit-MIME transport[9] are 131 defined as for SMTP. BMTP servers MAY support any or all of them; BMTP 132 clients MUST use only extensions supported by a server as defined in 133 [10]. 135 The MAIL verb is defined as in SMTP, except that the argument is a mail- 136 box, rather than a return path. Note that a null address <> is not a 137 valid mailbox. The mailbox must be a valid address where error reports 138 will be received and acted upon. 140 The RCPT verb is defined as in SMTP, except that the argument is a mail- 141 box, not a forward-path. The argument to RCPT can also contain the 142 reserved address BOXHOLDER, indicating a message to be delivered to all 143 interested recipients. As in SMTP, the server's acceptance of the 144 address in a RCPT command does not guarantee delivery of the message to 145 any particular person or mailbox. 147 BMTP servers MAY implement any ESMTP extensions beyond the ones listed 148 above. 150 8. Response codes 152 BMTP uses the same response codes as SMTP. 154 9. ESMTP-like Service Extensions 156 BSMTP defines one new EHLO keyword CLASS. The CLASS keyword indicates 157 that the Class service extension is supported, and takes no parameters. 158 BMTP servers SHOULD implement the Class extension. 160 To support cost-sharing, BMTP servers SHOULD provide client authentica- 161 tion when possible. When authentication extension(s) are defined for 162 ESMTP, identical extenstions will be defined for BMTP. 164 10. The Class service extension 166 The Class service extension adds a single new optional parameter "CLASS" 167 to the MAIL FROM command. The value associated with this parameter is a 168 keyword of up to 10 chacters drawn fro the set of upper case letters and 169 digits, identifying the topic of the message. 171 The server returns 250 if the MAIL FROM command including the class is 172 accepted, or 550 if the class is rejected. Accepting the class does not 173 imply how many if any recipients accept mail in this class; it indicates 174 only that the server recognizes the name of the class and is prepared to 175 handle a message according to its procedures for that class. A Class 176 parameter with the special class name NONE declares that the message 177 belongs to no class. 179 11. Message Format 181 The format of a BMTP message is identical to that of an SMTP message[3]. 182 Every message MUST contain a From: header line specifying a valid mail- 183 box where responses to the message will be accepted and acted upon. 185 12. Message Delivery 187 Once a server has accepted a message via BMTP, it may deliver the mes- 188 sage in the same manner as SMTP messages or process it by other means, 189 e.g., place it in separate mailboxes or display it in a "billboard" in a 190 system with a graphical interface. 192 Unlike SMTP messages, undeliverable BMTP messages are discarded without 193 notice to the sender. 195 13. Security Considerations 197 BMTP is modelled on SMTP and so has most of the same security issues as 198 SMTP. BMTP deliberately returns less status information to the client 199 to avoid disclosing details about the mailboxes supported by the server 200 and the mail receipt preferences of the server's users. 202 14. References 204 [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 205 USC/Information Sciences Institute, August 1982. 207 [2] Klensin, J., N. Freed, M. Rose, E. Stefferud & D. Crocker, "SMTP 208 Service Extensions", MCI et al., STD 11, RFC 1869, November 1995. 210 [3] Crocker, D., "Standard for the Format of ARPA Internet Text Mes- 211 sages", STD 11, RFC 822, UDEL, August 1982. 213 [4] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 214 974, BBN, January 1986. 216 [5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 217 MIT/RSADSI, April 1992. 219 [6] Freed, N., "SMTP Service Extension for Command Pipelining", RFC 220 2197, Innosoft, September 1997. 222 [7] Freed, N., "SMTP Service Extension for Returning Enhanced Error 223 Codes", RFC 2034, Innosoft, October 1996. 225 [8] Klensin, J., N. Freed, & K. Moore, "SMTP Service Extension for Mes- 226 sage Size Declaration", RFC 1870, MCI/Innosoft/U. of Tennessee, 227 November 1995. 229 [9] Klensin, J., N. Freed, M. Rose, E. Stefferud & D. Crocker, "SMTP 230 Service Extension for 8bit-MIMEtransport", RFC 1652, 231 MCI/Innosoft/Dover Beach/NMA/Silicon Graphics, July 1994. 233 [10] Klensin, J., N. Freed, M. Rose, E. Stefferud & D. Crocker, "SMTP 234 Service Extensions", RFC 1869, MCI/Innosoft/Dover Beach/NMA/Silicon 235 Graphics, November 1995. 237 15. Author's Address 239 John R. Levine 240 I.E.C.C. 242 PO Box 640 243 Trumansburg NY 14886 USA 244 johnl@iecc.com