idnits 2.17.1 draft-rollo-bmpp-00.txt: 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-26) 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. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages 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 are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 54: '...om this protocol MAY be construed as e...' RFC 2119 keyword, line 55: '...ve response from this protocol MUST be...' RFC 2119 keyword, line 82: '... any servers, it SHOULD temporarily fa...' RFC 2119 keyword, line 103: '... of the line MUST be the first chara...' RFC 2119 keyword, line 104: '... code. Lines MUST be terminated by an ASCII [3] carriage return...' (35 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (23 June 1998) is 9439 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) -- Duplicate reference: RFC1035, mentioned in '2', was also mentioned in '1'. -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 3 T. Rollo 4 CorVu Pty Ltd 5 23 June 1998 7 A Protocol For Identifying The Bulk Mail Receipt 8 Preferences of an Electronic Mail Address. 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 25 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 26 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 Abstract 30 BMPP is a protocol which allows bulk emailers to discover if a 31 mailbox is willing to accept bulk email. 33 From the bulk emailer's point of view, it allows them to find out for 34 certain if their email will be accepted or rejected by the recipient. 36 From the mailbox owner's point of view, it allows them to provide 37 permission to bulk emailers in jurisdictions where permission is 38 required, and allows them to express their desire not to receive such 39 bulk mailings in jurisdictions where permission is not required. 41 1. Overview and Rational 43 In recent years, bulk email has become an increasingly popular method 44 of advertising on the Internet. There is currently no practical way 45 for the owner of an email address to express their preferences for 46 receipt or non receipt of such mailings. 48 This purpose of this protocol is to provide a standard way to express 49 and obtain preferences on the receipt of bulk email advertising. 51 The intention of this protocol is that the information obtained from 52 servers using this protocol be used as a categorical statement of 53 preferences at the time of obtaining that information. A permissive 54 response from this protocol MAY be construed as explicit permission 55 to send bulk email. A restrictive response from this protocol MUST be 56 construed as an explicit denial of permission to send bulk email. 58 Nothing in this document should be taken to express any opinion on 59 the ethics involved with bulk email advertising when this protocol 60 cannot be used, however if and when this protocol comes into common 61 use, it should be considered compulsory to attempt to use this 62 protocol when sending bulk email to recipients who have not otherwise 63 explicitly requested it. 65 Specifically, this document makes no claim of judgement on the ethics 66 of sending bulk mail when the protocol described here is not offered 67 in relation to the target address. 69 2. Basic Operation 71 A BMPP client program obtains the location of BMPP servers for the 72 destination of the message as named on the right hand side of the 73 "at" ("@") sign in the address. The location can be obtained by 74 querying for a "BMP" resource record using the Domain Naming System 75 [1]. This record returns the fully qualified domain names of servers 76 which can provide the BMPP service for addresses at that destination. 77 If there is no BMP record for the named host, the client should use 78 the named host directly as the BMPP server. 80 Once the client has obtained a list of BMPP servers, it then attempts 81 to connect to one of them on the TCP port assigned to BMPP. If it is 82 unable to connect to any servers, it SHOULD temporarily fail the 83 transaction and retry at a later date. 85 On connecting to the server, the client OPTIONALLY supplies a 86 category token. This category token classifies the nature of the bulk 87 mail transmission. 89 After supplying a category token, the client OPTIONALLY supplies a 90 rating token. The rating is used to determine the minimum recommended 91 audience for the bulk mail. 93 Following the category or rating token, the client supplies addresses 94 to the server. The server responds by indicating for each address if 95 it is willing to receive bulk email. If a category or rating was 96 supplied, the preference given is strictly limited to the named 97 category and rating. 99 3. Commands and Responses 101 Commands and responses are transmitted as lines of text. Only one 102 command or response can be given on a line, and the first character 103 of the line MUST be the first character of the keyword or response 104 code. Lines MUST be terminated by an ASCII [3] carriage return 105 followed by an ASCII line feed (CRLF). 107 The maximum length of a line is 512 octets, not including the CRLF 108 end of line characters or any termination character required by an 109 implementation. A client or server which receives a longer line MUST 110 truncate the received line to the maximum length and process the 111 truncated line as if it were the entire line. 113 BMPP clients and servers MUST understand escapes of the form "%xx" 114 where xx is a hexadecimal digit. The ASCII characters CR, LF and NUL 115 (13, 10 and 0 decimal) MUST be escaped when they are transmitted as 116 part of the data of a command or response. Additionally, the "%" 117 character itself MUST be escaped either by using the "%xx" escape or 118 by doubling the "%" character (as in "%%"). BMPP clients and servers 119 MUST NOT transmit an unescaped "%" character as the last octet of a 120 line, and MUST NOT transmit an unescaped "%" character followed by 121 anything other than another "%" character or a pair of hexadecimal 122 digits. The hexadecimal digits in the "%xx" escape MAY be either 123 upper or lower case. 125 3.1 Summary of responses 127 The protocol includes the following commands: 129 CAT - Specify the category of the planned messages. 131 RATE - Specify the rating of the planned messages. 133 ADDR - Query an address for acceptance of the message. 135 QUIT - Terminate the connection. 137 A server MAY return the results of ADDR requests out of order, 138 however on receiving any other requests - including an invalid 139 command, the server: 141 - MUST return the results of all prior ADDR requests prior to pro- 142 cessing or responding to the non ADDR request; and 144 - MUST NOT respond to any subsequent ADDR requests prior to process- 145 ing or responding to the non ADDR request. 147 3.1.1 The CAT Command 149 The CAT command is used to to specify the category of the message. 150 The command can be omitted entirely. If it is omitted entirely, the 151 client is querying if the mailboxes accept any and all bulk mail 152 messages. 154 If the CAT command is used, the client is asking if the mailbox will 155 accept messages in that category. When the CAT command is processed, 156 the server discards the values supplied in any previous RATE 157 commands. 159 Categories are formed from a class name, followed by a colon, 160 followed by the sub-category within that class. Currently defined 161 classes are "NEWS", in which the sub-categories are USENET newsgroup 162 names, "DOMAIN", in which the category is formed from by 163 concatenating a domain name with a forward slash character ("/") and 164 a category defined by the owner of that domain, and "URL", in which 165 the client supplies a URL describing where the mailbox address was 166 found or supplied. 168 The CAT command may be issued at any time during the transaction with 169 the server. Each time it is issued, it changes the category for 170 subsequent queries. There is no way to revert to the "no category" 171 state once the CAT command has been issued - clients wishing to query 172 if a mailbox will accept any and all bulk mail messages MUST do so at 173 the start of the transaction. 175 The response to the CAT command is "200", followed by a space, 176 followed by the value supplied to the CAT command. For example: 178 C: CAT NEWS:news.announce.newusers 179 S: 200 NEWS:news.announce.newusers 181 3.1.1.1 The USENET class 183 A category in the USENET class expresses that the bulk mail message 184 would be applicable to the named newsgroup if it were to be posted to 185 a newsgroup. 187 Example: 188 CAT NEWS:misc.test 190 3.1.1.2 The DOMAIN class 191 A category in the "DOMAIN" class expresses that the sender of the 192 bulk mail message has permission from the owners of the named domain 193 to send messages using that domain name and sub-category. Definition 194 of the contents and structure of the remainder of the sub-category is 195 entirely at the discretion of the owners of the domain, however the 196 recommended format is a heirarchical structure with the forward slash 197 character used to mark levels within the heirarchy. 199 Example: 200 CAT DOMAIN:foo.com/foo-products/widget98 202 3.1.1.3 The URL class 204 A category in the "URL" class indicates that the sender of the bulk 205 mail message obtained the address from the named URL. In particular, 206 if a user submits their email address in a web form, and the primary 207 purpose of submitting that address in the web form is not to 208 subscribe to bulk email, the bulk mailer SHOULD use the URL class. 210 The URL class SHOULD NOT be used if the URL is completely incidental 211 to the address gathering process. For example, if the mailbox 212 addresses are gathered by taking addresses from all newsgroups, it is 213 not appropriate to use a "URL:news:..." category. Similarly, if the 214 mailbox addresses are gathered by a web crawling robot, it is not 215 appropriate to use a "URL:http:..." category. 217 Example: 218 CAT URL:http://www.foo.com/cgi-bin/register.cgi 220 3.1.2 The RATE Command 222 The client sends this command to specify the rating of the planned 223 message. The rating is specified as a semicolon (';') separated list 224 of rating values. Rating values are formed by taking a rating name, 225 formed from the letters 'A' to 'Z', concatenated with an "equal" sign 226 ('='), concatenated with a value from 0 to 5, with 0 being "not 227 applicable" and 5 being "strong in this category". 229 The RATE command MUST only be submitted either as the first command 230 in the transaction or immediately following a CAT command. 232 The response to the RATE command is "201", followed by a space, 233 followed by the value supplied to the RATE command. 235 For example, the following commands could be used for bulk email 236 regarding non violent erotica, mild pornography, hard core 237 pornography and hard core pornography incorporating strong violence, 238 respectively: 240 RATE PORN=1 241 RATE PORN=3 242 RATE PORN=5 243 RATE PORN=5;VLNC=5 245 The following rating names are defined: 247 CHLD - rates suitability for young children. 248 MINR - rates suitability for minors. 249 NUDE - rates nudity. 250 PLTC - rates political items. 251 PORN - rates the level of pornography. 252 RLGN - rates items of a religious nature. 253 VLNC - rates the level of violence. 255 The assumptions made by the server for ratings categories that are 256 not present at all is undefined. Servers SHOULD allow the mailbox 257 owner to configure the values of ratings they will accept, as well as 258 whether they will accept an item which is not rated in a particular 259 category. 261 3.1.3 The ADDR Command 263 The client sends this command to request the bulk mail preferences of 264 a mail box. The server responds by indicating if the mailbox will 265 accept a message for the currently active category with the currently 266 active ratings. 268 The mailbox is an SMTP [2] addressable mailbox name without comments 269 or adornment of any kind. Specifically, it is a valid value for the 270 "RCPT" command of SMTP, without the angle brackets. 272 The response to this command can be any of: 274 250 - Mailbox will accept the specified bulk mail. 276 252 - Mailbox will accept all bulk mail. The client SHOULD NOT 277 attempt to query the preferences for this mailbox again in 278 the same session. All requests on this mailbox are expected 279 to return this result. 281 550 - Invalid mailbox. The mailbox requested does not exist. The 282 client SHOULD remove the mailbox from the mailing list per- 283 manently. 285 553 - Mailbox will not accept the specified bulk email. The client 286 MUST ensure that this mailbox does not receive the specified 287 bulk email. 289 555 - Mailbox will not accept any bulk email. The client SHOULD 290 NOT attempt to query the preferences for this mailbox again 291 in the same session. All requests on this mailbox are 292 expected to return this result. The client MUST ensure that 293 this mailbox does not receive the specified bulk email or 294 any other bulk email originating with the same sender. 296 556 - No information available. The server was not able to obtain 297 any information on the bulk mail preferences of the mailbox 298 at all. 300 422 - Could not contact remote server. The server needed to obtain 301 information from a remote server and was unable to contact 302 that server. The client SHOULD NOT try the same mailbox in 303 the same session. The client MAY retry that mailbox in a 304 later session. 306 423 - Temporary lookup failure. There was a temporary failure 307 looking up details for the mailbox. The client SHOULD NOT 308 try the same mailbox in the same session. The client MAY 309 retry that mailbox in a later session. 311 Whichever response is used, the response should include as its 312 argument the name of the mailbox that was requested. For example: 314 C: ADDR bar@foo.com 315 S: 555 bar@foo.com 317 3.1.4 The QUIT Command 319 The client sends this command to request termination of the transaction. 321 The server acknowledges the QUIT command by sending the 221 response, then 322 closing the connection. 324 3.2 Summary of Replies 326 3.2.1 Successful Actions 328 200 - Category Change OK 329 201 - Rating Change OK 330 221 - QUIT response 331 250 - Mailbox will accept this bulk mail 332 252 - Mailbox will accept all bulk mail 334 3.2.2 Temporary Failures 335 422 - Could not contact remote server 336 423 - Temporary lookup failure 338 3.2.3 Permanent Failures 340 505 - Bad command 341 550 - Invalid Mailbox 342 553 - Mailbox will not accept this bulk mail 343 555 - Mailbox will not accept any bulk mail 344 556 - No information available 346 4 Discussion 348 4.1 Use of information by clients 350 Information obtained by using BMPP in no way overrides an explicit 351 request made by the owner of a mailbox. If the owner of a mailbox has 352 explicitly requested a bulk mailing manually, a negative response 353 from BMPP does not override that explicit request. If the owner of a 354 mailbox has explicitly requested to be removed from a bulk mailing 355 list manually, a permissive response from BMPP does not override that 356 request. 358 In short - a BMPP request MUST NOT be used as a statement of the 359 preference of the mailbox owner for receiving a bulk mail message if 360 that mailbox owner has made their preferences known to the originator 361 by other deliberate means. 363 A bulk mailer who receives a permissive response from a BMPP server 364 and who has not been explicitly informed by the mailbox owner that 365 they do not wish to receive their material MAY transmit bulk mail to 366 that mailbox. A bulk mailer who does transmit bulk mail to that 367 mailbox MUST reconfirm that preference using BMPP regularly, and in 368 no event less frequently than once every two weeks. 370 A bulk mailer who receives a restrictive response from a BMPP server 371 and has not been explicitly informed by the mailbox owner that they 372 do wish to receive their material MUST NOT transmit bulk mail to that 373 mailbox. Under these circumstances, the bulk mailer MAY query that 374 mailbox again at a later date, and in no event more frequently than 375 the bulk mailer reconfirms permissive preferences. 377 4.2 Proxy servers 379 The design of the BMPP protocol explicitly allows for proxy servers. 380 A simplified client MAY avoid the need to look up BMP records in the 381 DNS by querying a proxy server. The proxy server performs the DNS 382 lookups and queries the correct servers on the behalf of the client. 384 A second use for proxy servers is to have a single server on a 385 firewall provide BMPP information for systems which would otherwise 386 be inaccessible. 388 5 IANA Guidelines 390 This protocol includes two facilities that may require ongoing 391 allocations - category classes and rating labels. 393 New category classes and rating labels should be allocated on the 394 recommendation of the IETF or any of its nominated committees. 395 Allocations of new labels should reflect either an omission in this 396 document or a new development. 398 New category classes and rating labels should not be added lightly - 399 adding new values for these items increases the complexity of 400 configuration for the mailbox owner, thus potentially decreasing the 401 utility of the protocol. 403 6 Security Considerations 405 There are two possible security issues with this protocol - flooding 406 and user name discovery. 408 6.1 Flooding 410 A malicious client could attempt to clog a link by sending a 411 continuous stream of requests to the server. This is a potential 412 problem with any network protocol. 414 A server that wishes to protect against this MAY use a throttling 415 system to reduce the impact. If implemented, throttling SHOULD 416 attempt to detect either repeated requests for the same information 417 or an unusual number of requests for invalid mailboxes. 419 Flood protection SHOULD NOT simply throttle all connections - there 420 SHOULD be a valid reason for suspecting an attack before throttling. 422 6.2 User name discovery 424 The listed responses to the ADDR command provide an opportunity for 425 an attacker to inexpensively determine if a particular user name 426 exists at the target system. A server that wishes to protect against 427 this attack MAY respond with response 556. A server SHOULD NOT 428 respond with anything other than 550 or 556 if the requested mailbox 429 does not exist. 431 7 Change Log 432 7.1 23-Jun-1998 Draft Version 00 434 This is the initial draft version of this specification. 436 8 References 438 [1] Mockapetris, P., "Domain Names - Implementation and Specification", 439 STD 13, RFC 1035, USC/Information Sciences Institute, November 1987 441 [2] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 1035, 442 USC/Information Sciences Institute, August 1982 444 [3] ANSI, Coded Character Set -- 7-Bit American Standard Code For Infor- 445 mation Interchange", ANSI X3.4-1986 447 9 Author's Address 449 Troy Rollo 450 CorVu Pty Ltd 451 Level 4 452 1 James Place 453 North Sydney NSW 2020 454 AUSTRALIA 456 Phone: +61 2 9959 3522 457 Fax: +61 2 9959 3583 459 EMail: troy@corvu.com.au