idnits 2.17.1 draft-rollo-bmpp-02.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-23) 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 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 53: '...om this protocol MAY be construed as e...' RFC 2119 keyword, line 54: '...ve response from this protocol MUST be...' RFC 2119 keyword, line 86: '... BMPP clients MUST perform a query f...' RFC 2119 keyword, line 94: '... it SHOULD temporarily fail the tran...' RFC 2119 keyword, line 114: '... of the line MUST be the first chara...' (44 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 (24 July 1998) is 9405 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' ** Obsolete normative reference: RFC 2052 (ref. '4') (Obsoleted by RFC 2782) Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 2 T. Rollo 3 CorVu Pty Ltd 4 24 July 1998 6 A Protocol For Identifying The Bulk Mail Receipt 7 Preferences of an Electronic Mail Address. 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 24 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 25 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 27 Abstract 29 BMPP is a protocol which allows bulk emailers to discover if a 30 mailbox is willing to accept bulk email. 32 From the bulk emailer's point of view, it allows them to find out for 33 certain if their email will be accepted or rejected by the recipient. 35 From the mailbox owner's point of view, it allows them to provide 36 permission to bulk emailers in jurisdictions where permission is 37 required, and allows them to express their desire not to receive such 38 bulk mailings in jurisdictions where permission is not required. 40 1. Overview and Rational 42 In recent years, bulk email has become an increasingly popular method 43 of advertising on the Internet. There is currently no practical way 44 for the owner of an email address to express their preferences for 45 receipt or non receipt of such mailings. 47 The purpose of this protocol is to provide a standard way to express 48 and obtain preferences on the receipt of bulk email advertising. 50 The intention of this protocol is that the information obtained from 51 servers using this protocol be used as a categorical statement of 52 preferences at the time of obtaining that information. A permissive 53 response from this protocol MAY be construed as explicit permission 54 to send bulk email. A restrictive response from this protocol MUST be 55 construed as an explicit denial of permission to send bulk email. 57 Nothing in this document should be taken to express any opinion on 58 the ethics involved with bulk email advertising when this protocol 59 cannot be used, however if and when this protocol comes into common 60 use, it should be considered compulsory to attempt to use this 61 protocol when sending bulk email to recipients who have not otherwise 62 explicitly requested it. 64 Specifically, this document makes no claim of judgement on the ethics 65 of sending bulk mail when the protocol described here is not offered 66 in relation to the target address. 68 2. Basic Operation 70 A BMPP client program starts with a list of email addresses that it 71 are potential recipients of a bulk email message. The client then 72 gathers the addresses by destination as named after the "at" ('@') 73 sign in the address and conducts a single BMPP transaction for each 74 such destination. 76 For each destination, the BMPP client queries the Domain Naming 77 System [1] for SRV [4] records for that destination, with the 78 protocol being "tcp" and the service being "bmpp", and uses the list 79 returned to determine the host names and ports of the BMPP servers 80 for that destination. 82 For example, if the address is "fred@foo.com", the client would query 83 the DNS for SRV records for the name "bmpp.tcp.foo.com". 85 Unlike other protocols, where the use of SRV records is not required, 86 BMPP clients MUST perform a query for approptiate SRV records. 88 If the query returns no SRV records, the destination itself becomes 89 the sole member of the list, and the port is the assigned port for 90 BMPP - port 632. 92 Once the client has obtained a list of BMPP servers, it then attempts 93 to connect to one of them. If it is unable to connect to any servers, 94 it SHOULD temporarily fail the transaction and retry at a later date. 96 On connecting to the server, the client OPTIONALLY supplies a 97 category token. This category token classifies the nature of the bulk 98 mail transmission. 100 After supplying a category token, the client OPTIONALLY supplies a 101 rating token. The rating is used to determine the minimum recommended 102 audience for the bulk mail. 104 Following the category or rating token, the client supplies addresses 105 to the server. The server responds by indicating for each address if 106 it is willing to receive bulk email. If a category or rating was 107 supplied, the preference given is strictly limited to the named 108 category and rating. 110 3. Commands and Responses 112 Commands and responses are transmitted as lines of text. Only one 113 command or response can be given on a line, and the first character 114 of the line MUST be the first character of the keyword or response 115 code. Lines MUST be terminated by an ASCII [3] carriage return 116 followed by an ASCII line feed (CRLF). 118 Arguments to a command or response MUST be separated from the command 119 by exactly one ASCII space character. Additional spaces, including 120 both leading and trailing spaces, are taken to be a non-discardable 121 part of the argument data. 123 The maximum length of a line is 512 octets, not including the CRLF 124 end of line characters or any termination character required by an 125 implementation. A client or server which receives a longer line MUST 126 truncate the received line to the maximum length and process the 127 truncated line as if it were the entire line. 129 BMPP clients and servers MUST understand escapes of the form "%xx" 130 where xx is a hexadecimal digit. The ASCII characters CR, LF and NUL 131 (13, 10 and 0 decimal) MUST be escaped when they are transmitted as 132 part of the data of a command or response. Additionally, the "%" 133 character itself MUST be escaped either by using the "%xx" escape or 134 by doubling the "%" character (as in "%%"). BMPP clients and servers 135 MUST NOT transmit an unescaped "%" character as the last octet of a 136 line, and MUST NOT transmit an unescaped "%" character followed by 137 anything other than another "%" character or a pair of hexadecimal 138 digits. The hexadecimal digits in the "%xx" escape MAY be either 139 upper or lower case. 141 A server which receives a command with invalid escaping MUST return 142 the error code 506, with the text received up until the point of the 143 error as the argument. 145 A client which receives a response with invalid escaping MUST discard 146 the entire response. 148 Most responses in BMPP require that some or all of the input command 149 supplied by the client be returned as part of the response. A BMPP 150 server MAY return such data with different escaping to that supplied 151 by the client. A client MUST be able to recognise such modified 152 responses as being technically identical to the data supplied in the 153 original command. 155 3.1 Summary of Commands 157 The protocol includes the following commands: 159 CAT - Specify the category of the planned messages. 161 RATE - Specify the rating of the planned messages. 163 ADDR - Query an address for acceptance of the message. 165 QUIT - Terminate the connection. 167 A server MAY return the results of ADDR requests out of order, 168 however on receiving any other requests - including an invalid 169 command, the server: 171 - MUST return the results of all prior ADDR requests prior to pro- 172 cessing or responding to the non ADDR request; and 174 - MUST NOT respond to any subsequent ADDR requests prior to process- 175 ing or responding to the non ADDR request. 177 3.1.1 The CAT Command 179 The CAT command is used to to specify the category of the message. 180 The command can be omitted entirely. If it is omitted entirely, the 181 client is querying if the mailboxes accept any and all bulk mail 182 messages. 184 If the CAT command is used, the client is asking if the mailbox will 185 accept messages in that category. When the CAT command is processed, 186 the server discards the values supplied in any previous RATE 187 commands. 189 Categories are formed from a class name, followed by a colon, 190 followed by the sub-category within that class. Currently defined 191 classes are "NEWS", in which the sub-categories are USENET newsgroup 192 names, "DOMAIN", in which the category is formed from by 193 concatenating a domain name with a forward slash character ("/") and 194 a category defined by the owner of that domain, and "URL", in which 195 the client supplies a URL describing where the mailbox address was 196 found or supplied. 198 The CAT command may be issued at any time during the transaction with 199 the server. Each time it is issued, it changes the category for 200 subsequent queries. There is no way to revert to the "no category" 201 state once the CAT command has been issued - clients wishing to query 202 if a mailbox will accept any and all bulk mail messages MUST do so at 203 the start of the transaction. 205 The response to the CAT command is "200", followed by a space, 206 followed by the value supplied to the CAT command. For example: 208 C: CAT NEWS:news.announce.newusers 209 S: 200 NEWS:news.announce.newusers 211 3.1.1.1 The USENET class 213 A category in the USENET class expresses that the bulk mail message 214 would be applicable to the named newsgroup if it were to be posted to 215 a newsgroup. 217 Example: 218 CAT NEWS:misc.test 220 3.1.1.2 The DOMAIN class 222 A category in the "DOMAIN" class expresses that the sender of the 223 bulk mail message has permission from the owners of the named domain 224 to send messages using that domain name and sub-category. Definition 225 of the contents and structure of the remainder of the sub-category is 226 entirely at the discretion of the owners of the domain, however the 227 recommended format is a heirarchical structure with the forward slash 228 character used to mark levels within the heirarchy. 230 Example: 231 CAT DOMAIN:foo.com/foo-products/widget98 233 3.1.1.3 The URL class 235 A category in the "URL" class indicates that the sender of the bulk 236 mail message obtained the address from the named URL. In particular, 237 if a user submits their email address in a web form, and the primary 238 purpose of submitting that address in the web form is not to 239 subscribe to bulk email, the bulk mailer SHOULD use the URL class. 241 The URL class SHOULD NOT be used if the URL is completely incidental 242 to the address gathering process. For example, if the mailbox 243 addresses are gathered by taking addresses from all newsgroups, it is 244 not appropriate to use a "URL:news:..." category. Similarly, if the 245 mailbox addresses are gathered by a web crawling robot, it is not 246 appropriate to use a "URL:http:..." category. 248 Example: 249 CAT URL:http://www.foo.com/cgi-bin/register.cgi 251 3.1.2 The RATE Command 253 The client sends this command to specify the rating of the planned 254 message. The rating is specified as a semicolon (';') separated list 255 of rating values. Rating values are formed by taking a rating name, 256 formed from a sequence of four non accented letters ('A'..'Z'), 257 concatenated with an "equal" sign ('='), concatenated with a value 258 from 0 to 5, with 0 being "not applicable" and 5 being "strong in 259 this category". 261 An individual rating name MUST NOT appear more than once. Each rating 262 value MUST consist of exactly one digit. There MUST NOT be any white 263 space in the rating string supplied to the RATE command. 265 The RATE command MUST only be submitted either as the first command 266 in the transaction or immediately following a CAT command. 268 The response to the RATE command is "201", followed by a space, 269 followed by the value supplied to the RATE command. 271 The response to a RATE command with an illegal rating string is 501, 272 followed by a space, followed by the text of the command received. 274 The response to a RATE command which does not come as the first legal 275 command either in the entire transaction or immediately after a CAT 276 command is 503, followed by a space, followed by the text of the 277 command received. 279 For example, the following commands could be used for bulk email 280 regarding non violent erotica, mild pornography, hard core 281 pornography and hard core pornography incorporating strong violence, 282 respectively: 284 RATE PORN=1 285 RATE PORN=3 286 RATE PORN=5 287 RATE PORN=5;VLNC=5 289 The following rating names are defined: 291 CHLD - suitability for young children. 292 LANG - language which some will find offensive. 293 MINR - suitability for minors. 294 NUDE - nudity. 295 PLTC - political items. 296 PORN - level of pornography. 297 RLGN - items of a religious nature. 298 VLNC - level of violence. 300 The assumptions made by the server for ratings categories that are 301 not present at all is undefined. Servers SHOULD allow the mailbox 302 owner to configure the values of ratings they will accept, as well as 303 whether they will accept an item which is not rated in a particular 304 category. 306 3.1.3 The ADDR Command 308 The client sends this command to request the bulk mail preferences of 309 a mail box. The server responds by indicating if the mailbox will 310 accept a message for the currently active category with the currently 311 active ratings. 313 The mailbox is an SMTP [2] addressable mailbox name without comments 314 or adornment of any kind. Specifically, it is a valid value for the 315 "RCPT" command of SMTP, without the angle brackets. 317 The response to this command can be any of: 319 250 - Mailbox will accept the specified bulk mail. 321 252 - Mailbox will accept all bulk mail. The client SHOULD NOT 322 attempt to query the preferences for this mailbox again in 323 the same session. All requests on this mailbox are expected 324 to return this result. 326 550 - Invalid mailbox. The mailbox requested does not exist. The 327 client SHOULD remove the mailbox from the mailing list per- 328 manently. 330 553 - Mailbox will not accept the specified bulk email. The client 331 MUST ensure that this mailbox does not receive the specified 332 bulk email. 334 555 - Mailbox will not accept any bulk email. The client SHOULD 335 NOT attempt to query the preferences for this mailbox again 336 in the same session. All requests on this mailbox are 337 expected to return this result. The client MUST ensure that 338 this mailbox does not receive the specified bulk email or 339 any other bulk email originating with the same sender. 341 556 - No information available. The server was not able to obtain 342 any information on the bulk mail preferences of the mailbox 343 at all. 345 422 - Could not contact remote server. The server needed to obtain 346 information from a remote server and was unable to contact 347 that server. The client SHOULD NOT try the same mailbox in 348 the same session. The client MAY retry that mailbox in a 349 later session. 351 423 - Temporary lookup failure. There was a temporary failure 352 looking up details for the mailbox. The client SHOULD NOT 353 try the same mailbox in the same session. The client MAY 354 retry that mailbox in a later session. 356 Whichever response is used, the response should include as its 357 argument the name of the mailbox that was requested. For example: 359 C: ADDR bar@foo.com 360 S: 555 bar@foo.com 362 3.1.4 The QUIT Command 364 The client sends this command to request termination of the transaction. 366 The server acknowledges the QUIT command by sending the 221 response, then 367 closing the connection. 369 3.2 Summary of Replies 371 3.2.1 Successful Actions 373 200 - Category Change OK 374 201 - Rating Change OK 375 221 - QUIT response 376 250 - Mailbox will accept this bulk mail 377 252 - Mailbox will accept all bulk mail 379 3.2.2 Temporary Failures 381 422 - Could not contact remote server 382 423 - Temporary lookup failure 384 3.2.3 Permanent Failures 386 501 - Syntax error in arguments 387 503 - Incorrect command sequence 388 505 - Bad command 389 506 - Invalid escaping received 390 550 - Invalid Mailbox 391 553 - Mailbox will not accept this bulk mail 392 555 - Mailbox will not accept any bulk mail 393 556 - No information available 395 4 Discussion 397 4.1 Use of information by clients 399 Information obtained by using BMPP in no way overrides an explicit 400 request made by the owner of a mailbox. If the owner of a mailbox has 401 explicitly requested a bulk mailing manually, a negative response 402 from BMPP does not override that explicit request. If the owner of a 403 mailbox has explicitly requested to be removed from a bulk mailing 404 list manually, a permissive response from BMPP does not override that 405 request. 407 In short - a BMPP request MUST NOT be used as a statement of the 408 preference of the mailbox owner for receiving a bulk mail message if 409 that mailbox owner has made their preferences known to the originator 410 by other deliberate means. 412 A bulk mailer who receives a permissive response from a BMPP server 413 and who has not been explicitly informed by the mailbox owner that 414 they do not wish to receive their material MAY transmit bulk mail to 415 that mailbox. A bulk mailer who does transmit bulk mail to that 416 mailbox MUST reconfirm that preference using BMPP regularly, and in 417 no event less frequently than once every two weeks. 419 A bulk mailer who receives a restrictive response from a BMPP server 420 and has not been explicitly informed by the mailbox owner that they 421 do wish to receive their material MUST NOT transmit bulk mail to that 422 mailbox. Under these circumstances, the bulk mailer MAY query that 423 mailbox again at a later date, and in no event more frequently than 424 the bulk mailer reconfirms permissive preferences. 426 A bulk mailer SHOULD include a statement in bulk mail messages of the 427 form: 429 Permission for this mailing was obtained using BMPP with a 430 category of "" and a rating of "" 431 between and . If you wish to prevent future 432 mailings, you can change your personal BMPP configuration to 433 disallow either this category or some aspect of the rating. For 434 assistance with this, please contact your system administrator. We 435 reverify BMPP permissions every days. 437 Alternatively, bulk mailers may find it more useful to make their 438 initial contacts by obtaining permission using BMPP, and then 439 providing a sign-up facility that recipients can use to request 440 ongoing material. If a recipient signs up, the bulk mailer will then 441 not have to reverify their permission using BMPP. 443 4.2 Proxy servers 445 The design of the BMPP protocol explicitly allows for proxy servers. 446 A simplified client MAY avoid the need to look up SRV records in the 447 DNS and to connect to multiple hosts by querying a proxy server. The 448 proxy server performs the DNS lookups and queries the correct servers 449 on the behalf of the client. 451 A second use for proxy servers is to have a single server on a 452 firewall provide BMPP information for systems which would otherwise 453 be inaccessible. 455 4.3 Sample Conversation 457 C: ADDR fred@foo.bar 458 S: 555 fred@foo.bar 459 C: ADDR barney@foo.bar 460 C: ADDR wilma@foo.bar 461 S: 250 wilma@foo.bar 462 S: 553 barney@foo.bar 463 C: ADDR betty@foo.bar 464 S: 252 betty@foo.bar 465 C: ADDR snagglepuss@foo.bar 466 S: 550 snagglepuss@foo.bar 467 C: ADDR dino@bar.foo 468 S: 556 dino@bar.foo 469 C: CAT NEWS:comp.sys.slide-rule 470 S: 200 NEWS:comp.sys.slide-rule 471 C: HELO what is this doing here? 472 S: 505 HELO what is this doing here? 473 C: RATE CHLD = 0;MINR%20= 3 474 S: 501 RATE CHLD%20= 0;MINR = 3 475 C: RATE CHLD=0;MINR=3;PORN=0;NUDE=0;VLNC=0;LANG=0 476 S: 201 CHLD=0;MINR=3;PORN=0;NUDE=0;VLNC=0;LANG=0 477 C: ADDR barney@foo.bar 478 S: 250 barney@foo.bar 479 C: ADDR old%hack@foo.bar 480 S: 506 ADDR old 481 C: ADDR old%%hack@foo.bar 482 S: 550 old%%hack@foo.bar 483 C: RATE CHLD=0;MINR=0;PORN=5;NUDE=5;PLTC=0;RLGN=0 484 S: 503 RATE CHLD=0;MINR=0;PORN=5;NUDE=5;PLTC=0;RLGN=0 485 C: QUIT 486 S: 221 Goodbye 488 5 IANA Guidelines 490 This protocol includes two facilities that may require ongoing 491 allocations - category classes and rating names. 493 New category classes and rating names should be allocated on the 494 recommendation of the IETF or any of its nominated committees. 495 Allocations of new labels should reflect either an omission in this 496 document or a new development. 498 New category classes and rating names should not be added lightly - 499 adding new values for these items increases the complexity of 500 configuration for the mailbox owner, thus potentially decreasing the 501 utility of the protocol. 503 6 Security Considerations 505 There are two possible security issues with this protocol - flooding 506 and user name discovery. 508 6.1 Flooding 510 A malicious client could attempt to clog a link by sending a 511 continuous stream of requests to the server. This is a potential 512 problem with any network protocol. 514 A server that wishes to protect against this MAY use a throttling 515 system to reduce the impact. If implemented, throttling SHOULD 516 attempt to detect either repeated requests for the same information 517 or an unusual number of requests for invalid mailboxes. 519 Flood protection SHOULD NOT simply throttle all connections - there 520 SHOULD be a valid reason for suspecting an attack before throttling. 522 6.2 User name discovery 524 The listed responses to the ADDR command provide an opportunity for 525 an attacker to inexpensively determine if a particular user name 526 exists at the target system. A server that wishes to protect against 527 this attack MAY respond with response 555. A server SHOULD NOT 528 respond with anything other than 550 or 555 if the requested mailbox 529 does not exist. 531 7 Decision History 533 7.1 Why Not Modify SMTP 535 The SMTP servers listed for a site may not have the information 536 available. This means they would have to accept and retransmit 537 potentially large numbers of messages that would not be accepted at 538 the final destination. 540 A site that doesn't want any bulk mail at all (many corporate sites, 541 for example) can point the DNS records for the BMPP servers to a 542 server on their backbone provider that simply denies all requests, 543 thus avoiding the bandwidth cost. 545 There are huge numbers of SMTP servers out there, and as such there 546 is a huge logistical problem in getting the authors of all these to 547 update in a timely manner. 549 Even if every SMTP server gets an upgrade, many sites, once they have 550 a working SMTP server operating, are hesitant to upgrade and risk 551 breaking something. For others, upgrading the SMTP server may incur a 552 considerable cost. 554 BMPP is designed to be a simple, stand-alone protocol, which can be 555 rapidly implemented without tampering with installed software. There 556 is no dependancy on upgrading other software. 558 The cost of running a BMPP server is low - the simple protocol means 559 low overheads in both software and bandwidth. 561 BMPP offers something tangible to both bulk mailers and to 562 recipients, and as such is more likely to be used. 564 BMPP is intended to also directly address the problem of dozens of 565 sites claiming to own "the global remove list". By defining a 566 protocol which performs this function, control over the function is 567 returned to the mailbox owners, cutting out the plethora of "middle 568 men". 570 SMTP is "Simple Mail Transport Protocol". The information in BMPP is 571 not directly related to transport, and as such it is questionable 572 whether it would be appropriate to overload that protocol with the 573 functionality of BMPP. 575 8 Change Log 576 8.1 23-Jun-1998 Draft Version 00 578 This is the initial draft version of this specification. 580 8.2 07-Jul-1998 Draft Version 01 582 Documented the assigned port number of 632. 584 Corrected some headings and grammatical errors. 586 Removed some redundancy in the ratings section. 588 Added mailing list details. 590 Added the LANG rating name. 592 Added recommendations to bulk mailers on information to include in 593 messages. 595 Clarified rules regarding RATE commands. 597 Added response codes 501 and 503. 599 Corrected the options for responding to a request on an invalid 600 mailbox to allow 550 and 555 instead of 550 and 556. 602 Clarified rules for forming commands. 604 8.3 24-Jul-98 Draft Version 02 606 Changed DNS lookup description to use the SRV resource record. 608 Clarified the "Basic Operation" section. 610 This version is "complete" - it should now be possible to implement 611 fully operational clients and servers. 613 9 References 615 [1] Mockapetris, P., "Domain Names - Implementation and Specification", 616 STD 13, RFC 1035, USC/Information Sciences Institute, November 1987 618 [2] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 1035, 619 USC/Information Sciences Institute, August 1982 621 [3] ANSI, "Coded Character Set -- 7-Bit American Standard Code For 622 Information Interchange", ANSI X3.4-1986 624 [4] Gulbrandsen, A. and Vixie, P., "A DNS RR for specifying the location 625 of services (DNS SRV)", RFC 2052 627 10 Mailing List 629 To subscribe to the BMPP mailing list send email to 630 listproc@corvu.com with one line reading "subscribe BMPP@corvu.com 631 Your Name". This mailing list is for discussions relating to the 632 development of this protocol and the development of software 633 implementing this protocol. 635 11 Author's Address 637 Troy Rollo 638 CorVu Pty Ltd 639 Level 4 640 1 James Place 641 North Sydney NSW 2020 642 AUSTRALIA 644 Phone: +61 2 9959 3522 645 Fax: +61 2 9959 3583 647 EMail: troy@corvu.com.au