INTERNET-DRAFT T. Rollo CorVu Pty Ltd 23 June 1998 A Protocol For Identifying The Bulk Mail Receipt Preferences of an Electronic Mail Address. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents 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 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract BMPP is a protocol which allows bulk emailers to discover if a mailbox is willing to accept bulk email. From the bulk emailer's point of view, it allows them to find out for certain if their email will be accepted or rejected by the recipient. From the mailbox owner's point of view, it allows them to provide permission to bulk emailers in jurisdictions where permission is required, and allows them to express their desire not to receive such bulk mailings in jurisdictions where permission is not required. 1. Overview and Rational In recent years, bulk email has become an increasingly popular method of advertising on the Internet. There is currently no practical way for the owner of an email address to express their preferences for receipt or non receipt of such mailings. This purpose of this protocol is to provide a standard way to express and obtain preferences on the receipt of bulk email advertising. draft-rollo-bmpp-00.txt Expires 23 December 1998 [Page 1] INTERNET-DRAFT Bulk Mail Preferences Protocol - BMPP 23 June 1998 The intention of this protocol is that the information obtained from servers using this protocol be used as a categorical statement of preferences at the time of obtaining that information. A permissive response from this protocol MAY be construed as explicit permission to send bulk email. A restrictive response from this protocol MUST be construed as an explicit denial of permission to send bulk email. Nothing in this document should be taken to express any opinion on the ethics involved with bulk email advertising when this protocol cannot be used, however if and when this protocol comes into common use, it should be considered compulsory to attempt to use this protocol when sending bulk email to recipients who have not otherwise explicitly requested it. Specifically, this document makes no claim of judgement on the ethics of sending bulk mail when the protocol described here is not offered in relation to the target address. 2. Basic Operation A BMPP client program obtains the location of BMPP servers for the destination of the message as named on the right hand side of the "at" ("@") sign in the address. The location can be obtained by querying for a "BMP" resource record using the Domain Naming System [1]. This record returns the fully qualified domain names of servers which can provide the BMPP service for addresses at that destination. If there is no BMP record for the named host, the client should use the named host directly as the BMPP server. Once the client has obtained a list of BMPP servers, it then attempts to connect to one of them on the TCP port assigned to BMPP. If it is unable to connect to any servers, it SHOULD temporarily fail the transaction and retry at a later date. On connecting to the server, the client OPTIONALLY supplies a category token. This category token classifies the nature of the bulk mail transmission. After supplying a category token, the client OPTIONALLY supplies a rating token. The rating is used to determine the minimum recommended audience for the bulk mail. Following the category or rating token, the client supplies addresses to the server. The server responds by indicating for each address if it is willing to receive bulk email. If a category or rating was supplied, the preference given is strictly limited to the named category and rating. draft-rollo-bmpp-00.txt Expires 23 December 1998 [Page 2] INTERNET-DRAFT Bulk Mail Preferences Protocol - BMPP 23 June 1998 3. Commands and Responses Commands and responses are transmitted as lines of text. Only one command or response can be given on a line, and the first character of the line MUST be the first character of the keyword or response code. Lines MUST be terminated by an ASCII [3] carriage return followed by an ASCII line feed (CRLF). The maximum length of a line is 512 octets, not including the CRLF end of line characters or any termination character required by an implementation. A client or server which receives a longer line MUST truncate the received line to the maximum length and process the truncated line as if it were the entire line. BMPP clients and servers MUST understand escapes of the form "%xx" where xx is a hexadecimal digit. The ASCII characters CR, LF and NUL (13, 10 and 0 decimal) MUST be escaped when they are transmitted as part of the data of a command or response. Additionally, the "%" character itself MUST be escaped either by using the "%xx" escape or by doubling the "%" character (as in "%%"). BMPP clients and servers MUST NOT transmit an unescaped "%" character as the last octet of a line, and MUST NOT transmit an unescaped "%" character followed by anything other than another "%" character or a pair of hexadecimal digits. The hexadecimal digits in the "%xx" escape MAY be either upper or lower case. 3.1 Summary of responses The protocol includes the following commands: CAT - Specify the category of the planned messages. RATE - Specify the rating of the planned messages. ADDR - Query an address for acceptance of the message. QUIT - Terminate the connection. A server MAY return the results of ADDR requests out of order, however on receiving any other requests - including an invalid command, the server: - MUST return the results of all prior ADDR requests prior to pro- cessing or responding to the non ADDR request; and draft-rollo-bmpp-00.txt Expires 23 December 1998 [Page 3] INTERNET-DRAFT Bulk Mail Preferences Protocol - BMPP 23 June 1998 - MUST NOT respond to any subsequent ADDR requests prior to process- ing or responding to the non ADDR request. 3.1.1 The CAT Command The CAT command is used to to specify the category of the message. The command can be omitted entirely. If it is omitted entirely, the client is querying if the mailboxes accept any and all bulk mail messages. If the CAT command is used, the client is asking if the mailbox will accept messages in that category. When the CAT command is processed, the server discards the values supplied in any previous RATE commands. Categories are formed from a class name, followed by a colon, followed by the sub-category within that class. Currently defined classes are "NEWS", in which the sub-categories are USENET newsgroup names, "DOMAIN", in which the category is formed from by concatenating a domain name with a forward slash character ("/") and a category defined by the owner of that domain, and "URL", in which the client supplies a URL describing where the mailbox address was found or supplied. The CAT command may be issued at any time during the transaction with the server. Each time it is issued, it changes the category for subsequent queries. There is no way to revert to the "no category" state once the CAT command has been issued - clients wishing to query if a mailbox will accept any and all bulk mail messages MUST do so at the start of the transaction. The response to the CAT command is "200", followed by a space, followed by the value supplied to the CAT command. For example: C: CAT NEWS:news.announce.newusers S: 200 NEWS:news.announce.newusers 3.1.1.1 The USENET class A category in the USENET class expresses that the bulk mail message would be applicable to the named newsgroup if it were to be posted to a newsgroup. Example: CAT NEWS:misc.test 3.1.1.2 The DOMAIN class draft-rollo-bmpp-00.txt Expires 23 December 1998 [Page 4] INTERNET-DRAFT Bulk Mail Preferences Protocol - BMPP 23 June 1998 A category in the "DOMAIN" class expresses that the sender of the bulk mail message has permission from the owners of the named domain to send messages using that domain name and sub-category. Definition of the contents and structure of the remainder of the sub-category is entirely at the discretion of the owners of the domain, however the recommended format is a heirarchical structure with the forward slash character used to mark levels within the heirarchy. Example: CAT DOMAIN:foo.com/foo-products/widget98 3.1.1.3 The URL class A category in the "URL" class indicates that the sender of the bulk mail message obtained the address from the named URL. In particular, if a user submits their email address in a web form, and the primary purpose of submitting that address in the web form is not to subscribe to bulk email, the bulk mailer SHOULD use the URL class. The URL class SHOULD NOT be used if the URL is completely incidental to the address gathering process. For example, if the mailbox addresses are gathered by taking addresses from all newsgroups, it is not appropriate to use a "URL:news:..." category. Similarly, if the mailbox addresses are gathered by a web crawling robot, it is not appropriate to use a "URL:http:..." category. Example: CAT URL:http://www.foo.com/cgi-bin/register.cgi 3.1.2 The RATE Command The client sends this command to specify the rating of the planned message. The rating is specified as a semicolon (';') separated list of rating values. Rating values are formed by taking a rating name, formed from the letters 'A' to 'Z', concatenated with an "equal" sign ('='), concatenated with a value from 0 to 5, with 0 being "not applicable" and 5 being "strong in this category". The RATE command MUST only be submitted either as the first command in the transaction or immediately following a CAT command. The response to the RATE command is "201", followed by a space, followed by the value supplied to the RATE command. For example, the following commands could be used for bulk email regarding non violent erotica, mild pornography, hard core pornography and hard core pornography incorporating strong violence, respectively: draft-rollo-bmpp-00.txt Expires 23 December 1998 [Page 5] INTERNET-DRAFT Bulk Mail Preferences Protocol - BMPP 23 June 1998 RATE PORN=1 RATE PORN=3 RATE PORN=5 RATE PORN=5;VLNC=5 The following rating names are defined: CHLD - rates suitability for young children. MINR - rates suitability for minors. NUDE - rates nudity. PLTC - rates political items. PORN - rates the level of pornography. RLGN - rates items of a religious nature. VLNC - rates the level of violence. The assumptions made by the server for ratings categories that are not present at all is undefined. Servers SHOULD allow the mailbox owner to configure the values of ratings they will accept, as well as whether they will accept an item which is not rated in a particular category. 3.1.3 The ADDR Command The client sends this command to request the bulk mail preferences of a mail box. The server responds by indicating if the mailbox will accept a message for the currently active category with the currently active ratings. The mailbox is an SMTP [2] addressable mailbox name without comments or adornment of any kind. Specifically, it is a valid value for the "RCPT" command of SMTP, without the angle brackets. The response to this command can be any of: 250 - Mailbox will accept the specified bulk mail. 252 - Mailbox will accept all bulk mail. The client SHOULD NOT attempt to query the preferences for this mailbox again in the same session. All requests on this mailbox are expected to return this result. 550 - Invalid mailbox. The mailbox requested does not exist. The client SHOULD remove the mailbox from the mailing list per- manently. 553 - Mailbox will not accept the specified bulk email. The client MUST ensure that this mailbox does not receive the specified draft-rollo-bmpp-00.txt Expires 23 December 1998 [Page 6] INTERNET-DRAFT Bulk Mail Preferences Protocol - BMPP 23 June 1998 bulk email. 555 - Mailbox will not accept any bulk email. The client SHOULD NOT attempt to query the preferences for this mailbox again in the same session. All requests on this mailbox are expected to return this result. The client MUST ensure that this mailbox does not receive the specified bulk email or any other bulk email originating with the same sender. 556 - No information available. The server was not able to obtain any information on the bulk mail preferences of the mailbox at all. 422 - Could not contact remote server. The server needed to obtain information from a remote server and was unable to contact that server. The client SHOULD NOT try the same mailbox in the same session. The client MAY retry that mailbox in a later session. 423 - Temporary lookup failure. There was a temporary failure looking up details for the mailbox. The client SHOULD NOT try the same mailbox in the same session. The client MAY retry that mailbox in a later session. Whichever response is used, the response should include as its argument the name of the mailbox that was requested. For example: C: ADDR bar@foo.com S: 555 bar@foo.com 3.1.4 The QUIT Command The client sends this command to request termination of the transaction. The server acknowledges the QUIT command by sending the 221 response, then closing the connection. 3.2 Summary of Replies 3.2.1 Successful Actions 200 - Category Change OK 201 - Rating Change OK 221 - QUIT response 250 - Mailbox will accept this bulk mail 252 - Mailbox will accept all bulk mail 3.2.2 Temporary Failures draft-rollo-bmpp-00.txt Expires 23 December 1998 [Page 7] INTERNET-DRAFT Bulk Mail Preferences Protocol - BMPP 23 June 1998 422 - Could not contact remote server 423 - Temporary lookup failure 3.2.3 Permanent Failures 505 - Bad command 550 - Invalid Mailbox 553 - Mailbox will not accept this bulk mail 555 - Mailbox will not accept any bulk mail 556 - No information available 4 Discussion 4.1 Use of information by clients Information obtained by using BMPP in no way overrides an explicit request made by the owner of a mailbox. If the owner of a mailbox has explicitly requested a bulk mailing manually, a negative response from BMPP does not override that explicit request. If the owner of a mailbox has explicitly requested to be removed from a bulk mailing list manually, a permissive response from BMPP does not override that request. In short - a BMPP request MUST NOT be used as a statement of the preference of the mailbox owner for receiving a bulk mail message if that mailbox owner has made their preferences known to the originator by other deliberate means. A bulk mailer who receives a permissive response from a BMPP server and who has not been explicitly informed by the mailbox owner that they do not wish to receive their material MAY transmit bulk mail to that mailbox. A bulk mailer who does transmit bulk mail to that mailbox MUST reconfirm that preference using BMPP regularly, and in no event less frequently than once every two weeks. A bulk mailer who receives a restrictive response from a BMPP server and has not been explicitly informed by the mailbox owner that they do wish to receive their material MUST NOT transmit bulk mail to that mailbox. Under these circumstances, the bulk mailer MAY query that mailbox again at a later date, and in no event more frequently than the bulk mailer reconfirms permissive preferences. 4.2 Proxy servers The design of the BMPP protocol explicitly allows for proxy servers. A simplified client MAY avoid the need to look up BMP records in the DNS by querying a proxy server. The proxy server performs the DNS lookups and queries the correct servers on the behalf of the client. draft-rollo-bmpp-00.txt Expires 23 December 1998 [Page 8] INTERNET-DRAFT Bulk Mail Preferences Protocol - BMPP 23 June 1998 A second use for proxy servers is to have a single server on a firewall provide BMPP information for systems which would otherwise be inaccessible. 5 IANA Guidelines This protocol includes two facilities that may require ongoing allocations - category classes and rating labels. New category classes and rating labels should be allocated on the recommendation of the IETF or any of its nominated committees. Allocations of new labels should reflect either an omission in this document or a new development. New category classes and rating labels should not be added lightly - adding new values for these items increases the complexity of configuration for the mailbox owner, thus potentially decreasing the utility of the protocol. 6 Security Considerations There are two possible security issues with this protocol - flooding and user name discovery. 6.1 Flooding A malicious client could attempt to clog a link by sending a continuous stream of requests to the server. This is a potential problem with any network protocol. A server that wishes to protect against this MAY use a throttling system to reduce the impact. If implemented, throttling SHOULD attempt to detect either repeated requests for the same information or an unusual number of requests for invalid mailboxes. Flood protection SHOULD NOT simply throttle all connections - there SHOULD be a valid reason for suspecting an attack before throttling. 6.2 User name discovery The listed responses to the ADDR command provide an opportunity for an attacker to inexpensively determine if a particular user name exists at the target system. A server that wishes to protect against this attack MAY respond with response 556. A server SHOULD NOT respond with anything other than 550 or 556 if the requested mailbox does not exist. 7 Change Log draft-rollo-bmpp-00.txt Expires 23 December 1998 [Page 9] INTERNET-DRAFT Bulk Mail Preferences Protocol - BMPP 23 June 1998 7.1 23-Jun-1998 Draft Version 00 This is the initial draft version of this specification. 8 References [1] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987 [2] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 1035, USC/Information Sciences Institute, August 1982 [3] ANSI, Coded Character Set -- 7-Bit American Standard Code For Infor- mation Interchange", ANSI X3.4-1986 9 Author's Address Troy Rollo CorVu Pty Ltd Level 4 1 James Place North Sydney NSW 2020 AUSTRALIA Phone: +61 2 9959 3522 Fax: +61 2 9959 3583 EMail: troy@corvu.com.au draft-rollo-bmpp-00.txt Expires 23 December 1998 [Page 10]