INTERNET-DRAFT T. Rollo CorVu Pty Ltd 24 July 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. The 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-02.txt Expires 24 January 1999 [Page 1] INTERNET-DRAFT Bulk Mail Preferences Protocol - BMPP 24 July 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 starts with a list of email addresses that it are potential recipients of a bulk email message. The client then gathers the addresses by destination as named after the "at" ('@') sign in the address and conducts a single BMPP transaction for each such destination. For each destination, the BMPP client queries the Domain Naming System [1] for SRV [4] records for that destination, with the protocol being "tcp" and the service being "bmpp", and uses the list returned to determine the host names and ports of the BMPP servers for that destination. For example, if the address is "fred@foo.com", the client would query the DNS for SRV records for the name "bmpp.tcp.foo.com". Unlike other protocols, where the use of SRV records is not required, BMPP clients MUST perform a query for approptiate SRV records. If the query returns no SRV records, the destination itself becomes the sole member of the list, and the port is the assigned port for BMPP - port 632. Once the client has obtained a list of BMPP servers, it then attempts to connect to one of them. 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 draft-rollo-bmpp-02.txt Expires 24 January 1999 [Page 2] INTERNET-DRAFT Bulk Mail Preferences Protocol - BMPP 24 July 1998 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. 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). Arguments to a command or response MUST be separated from the command by exactly one ASCII space character. Additional spaces, including both leading and trailing spaces, are taken to be a non-discardable part of the argument data. 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. A server which receives a command with invalid escaping MUST return the error code 506, with the text received up until the point of the error as the argument. A client which receives a response with invalid escaping MUST discard draft-rollo-bmpp-02.txt Expires 24 January 1999 [Page 3] INTERNET-DRAFT Bulk Mail Preferences Protocol - BMPP 24 July 1998 the entire response. Most responses in BMPP require that some or all of the input command supplied by the client be returned as part of the response. A BMPP server MAY return such data with different escaping to that supplied by the client. A client MUST be able to recognise such modified responses as being technically identical to the data supplied in the original command. 3.1 Summary of Commands 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 - 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 draft-rollo-bmpp-02.txt Expires 24 January 1999 [Page 4] INTERNET-DRAFT Bulk Mail Preferences Protocol - BMPP 24 July 1998 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 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. draft-rollo-bmpp-02.txt Expires 24 January 1999 [Page 5] INTERNET-DRAFT Bulk Mail Preferences Protocol - BMPP 24 July 1998 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 a sequence of four non accented letters ('A'..'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". An individual rating name MUST NOT appear more than once. Each rating value MUST consist of exactly one digit. There MUST NOT be any white space in the rating string supplied to the RATE command. 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. The response to a RATE command with an illegal rating string is 501, followed by a space, followed by the text of the command received. The response to a RATE command which does not come as the first legal command either in the entire transaction or immediately after a CAT command is 503, followed by a space, followed by the text of the command received. 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: RATE PORN=1 RATE PORN=3 RATE PORN=5 RATE PORN=5;VLNC=5 draft-rollo-bmpp-02.txt Expires 24 January 1999 [Page 6] INTERNET-DRAFT Bulk Mail Preferences Protocol - BMPP 24 July 1998 The following rating names are defined: CHLD - suitability for young children. LANG - language which some will find offensive. MINR - suitability for minors. NUDE - nudity. PLTC - political items. PORN - level of pornography. RLGN - items of a religious nature. VLNC - 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 bulk email. 555 - Mailbox will not accept any bulk email. The client SHOULD NOT attempt to query the preferences for this mailbox again draft-rollo-bmpp-02.txt Expires 24 January 1999 [Page 7] INTERNET-DRAFT Bulk Mail Preferences Protocol - BMPP 24 July 1998 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 422 - Could not contact remote server 423 - Temporary lookup failure draft-rollo-bmpp-02.txt Expires 24 January 1999 [Page 8] INTERNET-DRAFT Bulk Mail Preferences Protocol - BMPP 24 July 1998 3.2.3 Permanent Failures 501 - Syntax error in arguments 503 - Incorrect command sequence 505 - Bad command 506 - Invalid escaping received 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. A bulk mailer SHOULD include a statement in bulk mail messages of the form: Permission for this mailing was obtained using BMPP with a category of "" and a rating of "" between and . If you wish to prevent future draft-rollo-bmpp-02.txt Expires 24 January 1999 [Page 9] INTERNET-DRAFT Bulk Mail Preferences Protocol - BMPP 24 July 1998 mailings, you can change your personal BMPP configuration to disallow either this category or some aspect of the rating. For assistance with this, please contact your system administrator. We reverify BMPP permissions every days. Alternatively, bulk mailers may find it more useful to make their initial contacts by obtaining permission using BMPP, and then providing a sign-up facility that recipients can use to request ongoing material. If a recipient signs up, the bulk mailer will then not have to reverify their permission using BMPP. 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 SRV records in the DNS and to connect to multiple hosts by querying a proxy server. The proxy server performs the DNS lookups and queries the correct servers on the behalf of the client. 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. 4.3 Sample Conversation C: ADDR fred@foo.bar S: 555 fred@foo.bar C: ADDR barney@foo.bar C: ADDR wilma@foo.bar S: 250 wilma@foo.bar S: 553 barney@foo.bar C: ADDR betty@foo.bar S: 252 betty@foo.bar C: ADDR snagglepuss@foo.bar S: 550 snagglepuss@foo.bar C: ADDR dino@bar.foo S: 556 dino@bar.foo C: CAT NEWS:comp.sys.slide-rule S: 200 NEWS:comp.sys.slide-rule C: HELO what is this doing here? S: 505 HELO what is this doing here? C: RATE CHLD = 0;MINR%20= 3 S: 501 RATE CHLD%20= 0;MINR = 3 C: RATE CHLD=0;MINR=3;PORN=0;NUDE=0;VLNC=0;LANG=0 S: 201 CHLD=0;MINR=3;PORN=0;NUDE=0;VLNC=0;LANG=0 C: ADDR barney@foo.bar S: 250 barney@foo.bar C: ADDR old%hack@foo.bar draft-rollo-bmpp-02.txt Expires 24 January 1999 [Page 10] INTERNET-DRAFT Bulk Mail Preferences Protocol - BMPP 24 July 1998 S: 506 ADDR old C: ADDR old%%hack@foo.bar S: 550 old%%hack@foo.bar C: RATE CHLD=0;MINR=0;PORN=5;NUDE=5;PLTC=0;RLGN=0 S: 503 RATE CHLD=0;MINR=0;PORN=5;NUDE=5;PLTC=0;RLGN=0 C: QUIT S: 221 Goodbye 5 IANA Guidelines This protocol includes two facilities that may require ongoing allocations - category classes and rating names. New category classes and rating names 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 names 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 555. A server SHOULD NOT draft-rollo-bmpp-02.txt Expires 24 January 1999 [Page 11] INTERNET-DRAFT Bulk Mail Preferences Protocol - BMPP 24 July 1998 respond with anything other than 550 or 555 if the requested mailbox does not exist. 7 Decision History 7.1 Why Not Modify SMTP The SMTP servers listed for a site may not have the information available. This means they would have to accept and retransmit potentially large numbers of messages that would not be accepted at the final destination. A site that doesn't want any bulk mail at all (many corporate sites, for example) can point the DNS records for the BMPP servers to a server on their backbone provider that simply denies all requests, thus avoiding the bandwidth cost. There are huge numbers of SMTP servers out there, and as such there is a huge logistical problem in getting the authors of all these to update in a timely manner. Even if every SMTP server gets an upgrade, many sites, once they have a working SMTP server operating, are hesitant to upgrade and risk breaking something. For others, upgrading the SMTP server may incur a considerable cost. BMPP is designed to be a simple, stand-alone protocol, which can be rapidly implemented without tampering with installed software. There is no dependancy on upgrading other software. The cost of running a BMPP server is low - the simple protocol means low overheads in both software and bandwidth. BMPP offers something tangible to both bulk mailers and to recipients, and as such is more likely to be used. BMPP is intended to also directly address the problem of dozens of sites claiming to own "the global remove list". By defining a protocol which performs this function, control over the function is returned to the mailbox owners, cutting out the plethora of "middle men". SMTP is "Simple Mail Transport Protocol". The information in BMPP is not directly related to transport, and as such it is questionable whether it would be appropriate to overload that protocol with the functionality of BMPP. 8 Change Log draft-rollo-bmpp-02.txt Expires 24 January 1999 [Page 12] INTERNET-DRAFT Bulk Mail Preferences Protocol - BMPP 24 July 1998 8.1 23-Jun-1998 Draft Version 00 This is the initial draft version of this specification. 8.2 07-Jul-1998 Draft Version 01 Documented the assigned port number of 632. Corrected some headings and grammatical errors. Removed some redundancy in the ratings section. Added mailing list details. Added the LANG rating name. Added recommendations to bulk mailers on information to include in messages. Clarified rules regarding RATE commands. Added response codes 501 and 503. Corrected the options for responding to a request on an invalid mailbox to allow 550 and 555 instead of 550 and 556. Clarified rules for forming commands. 8.3 24-Jul-98 Draft Version 02 Changed DNS lookup description to use the SRV resource record. Clarified the "Basic Operation" section. This version is "complete" - it should now be possible to implement fully operational clients and servers. 9 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 Information Interchange", ANSI X3.4-1986 draft-rollo-bmpp-02.txt Expires 24 January 1999 [Page 13] INTERNET-DRAFT Bulk Mail Preferences Protocol - BMPP 24 July 1998 [4] Gulbrandsen, A. and Vixie, P., "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052 10 Mailing List To subscribe to the BMPP mailing list send email to listproc@corvu.com with one line reading "subscribe BMPP@corvu.com Your Name". This mailing list is for discussions relating to the development of this protocol and the development of software implementing this protocol. 11 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-02.txt Expires 24 January 1999 [Page 14]