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]