[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

INTERNET-DRAFT
                                                                T. Rollo
                                                           CorVu Pty Ltd
                                                            31 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-03.txt  Expires 31 January 1999                [Page 1]


INTERNET-DRAFT    Bulk Mail Preferences Protocol - BMPP     31 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-03.txt  Expires 31 January 1999                [Page 2]


INTERNET-DRAFT    Bulk Mail Preferences Protocol - BMPP     31 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-03.txt  Expires 31 January 1999                [Page 3]


INTERNET-DRAFT    Bulk Mail Preferences Protocol - BMPP     31 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-03.txt  Expires 31 January 1999                [Page 4]


INTERNET-DRAFT    Bulk Mail Preferences Protocol - BMPP     31 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-03.txt  Expires 31 January 1999                [Page 5]


INTERNET-DRAFT    Bulk Mail Preferences Protocol - BMPP     31 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-03.txt  Expires 31 January 1999                [Page 6]


INTERNET-DRAFT    Bulk Mail Preferences Protocol - BMPP     31 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-03.txt  Expires 31 January 1999                [Page 7]


INTERNET-DRAFT    Bulk Mail Preferences Protocol - BMPP     31 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-03.txt  Expires 31 January 1999                [Page 8]


INTERNET-DRAFT    Bulk Mail Preferences Protocol - BMPP     31 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 "<category used>" and a rating of "<rating used>"
      between <start date> and <end date>. If you wish to prevent future



draft-rollo-bmpp-03.txt  Expires 31 January 1999                [Page 9]


INTERNET-DRAFT    Bulk Mail Preferences Protocol - BMPP     31 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 <number of days> 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-03.txt  Expires 31 January 1999               [Page 10]


INTERNET-DRAFT    Bulk Mail Preferences Protocol - BMPP     31 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-03.txt  Expires 31 January 1999               [Page 11]


INTERNET-DRAFT    Bulk Mail Preferences Protocol - BMPP     31 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-03.txt  Expires 31 January 1999               [Page 12]


INTERNET-DRAFT    Bulk Mail Preferences Protocol - BMPP     31 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.

   8.4 31-Jul-98 Draft Version 03

   Corrected reference for RFC 2052

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



draft-rollo-bmpp-03.txt  Expires 31 January 1999               [Page 13]


INTERNET-DRAFT    Bulk Mail Preferences Protocol - BMPP     31 July 1998


[3] ANSI, "Coded Character Set -- 7-Bit American Standard Code For
    Information Interchange", ANSI X3.4-1986

[4] Gulbrandsen, A. and Vixie, P., "A DNS RR for specifying the location
    of services (DNS SRV)", RFC 2052, Troll Technologies and Vixie
    Enterprises, October 1996

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-03.txt  Expires 31 January 1999               [Page 14]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/