Network Working Group C. Malamud
Internet-Draft Memory Palace Press
Expires: July 6, 2004 January 6, 2004
A No Soliciting SMTP Service Extension
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 6, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This Internet-Draft proposes an extension to SMTP for an electronic
mail equivalent to the real-world "No Soliciting" sign. The service
extension is described, followed by an example of how the extension
might be used.
Open Issues
This Internet-Draft has the following open issues, based on reviews
of the three previous drafts:
1. It has been observed that the format of trace fields as described
in Section 2.6 may lead to confusion or annoyance:
"The Addtl-Protocol specifies an Atom as the value; you have
Malamud Expires July 6, 2004 [Page 1]
draft-malamud-no-soliciting No-Solicit January 2004
changed this in ways that may confuse existing
implementations. In particular, there is no direct way to
mark the end of Solicitation-keywords and the beginning of the
next Opt-info. This may not be critical, but it does seem
annoying."
2. It has been observed that the Designated Expert who will
formulate policies and administer the registry described in
Section 5 might be better appointed by the IANA instead of the
IESG since the IANA would have responsibility for administration.
3. It has been observed that a simple scheme for keywords as
described in Section 2.2 might be insufficiently flexible. In
particular, some popular filtering implementations use a system
of labels and scores. One proposal was for a two-part system,
with a label registered with the IANA, followed by optional data.
For example:
"USDA_SPAM:150"
4. It has been remarked several times that the keywords used as
examples in Section 2.2 and as the initial "load" of the registry
described in Section 5 are "bad" examples for a variety of
reasons. The intention of this memorandum was that labels used
in operation would be registered by others and that the initial
examples would provide concrete examples for implementation,
however an empty registry could be used instead.
Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [21].
Malamud Expires July 6, 2004 [Page 2]
draft-malamud-no-soliciting No-Solicit January 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 The Spam Pandemic . . . . . . . . . . . . . . . . . . . . . . 4
1.2 No Soliciting in the Real World . . . . . . . . . . . . . . . 4
1.3 A Distributed No Soliciting Extension . . . . . . . . . . . . 6
2. The No-Soliciting SMTP Service Extension . . . . . . . . . . . 8
2.1 The SYSTEM-WIDE Option . . . . . . . . . . . . . . . . . . . . 8
2.2 Solicitation Class Keywords . . . . . . . . . . . . . . . . . 8
2.3 The PER-RECIPIENT Option . . . . . . . . . . . . . . . . . . . 9
2.4 Use of Enhanced Mail Status Codes . . . . . . . . . . . . . . 10
2.5 Solicitation Mail Header . . . . . . . . . . . . . . . . . . . 10
2.6 Insertion of Solicitation Keywords in Trace Fields . . . . . . 11
2.7 Relay of Messages . . . . . . . . . . . . . . . . . . . . . . 12
2.8 Recommendations for Developers and Administrators . . . . . . 13
3. Use of the Extension . . . . . . . . . . . . . . . . . . . . . 14
3.1 Relationship to Centralized Approaches . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
5.1 The Mail Parameters Registry . . . . . . . . . . . . . . . . . 19
5.2 ESMTP-Solicitation Additional Protocol . . . . . . . . . . . . 19
5.3 The Solicitation Class Keywords Registry . . . . . . . . . . . 19
5.4 The Solicitation Mail Header . . . . . . . . . . . . . . . . . 20
6. Author's Acknowledgements . . . . . . . . . . . . . . . . . . 21
Informative References . . . . . . . . . . . . . . . . . . . . 22
Normative References . . . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 25
A. Status of This Document . . . . . . . . . . . . . . . . . . . 26
A.1 RFC Category . . . . . . . . . . . . . . . . . . . . . . . . . 26
A.2 Document Repository . . . . . . . . . . . . . . . . . . . . . 26
A.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 26
A.4 Changes From Previous Drafts . . . . . . . . . . . . . . . . . 26
B. Transmittal . . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . 30
Malamud Expires July 6, 2004 [Page 3]
draft-malamud-no-soliciting No-Solicit January 2004
1. Introduction
1.1 The Spam Pandemic
Unsolicited Bulk Email (UBE), otherwise known as spam, has become as
one of the most pressing issues on the Internet. One oft-quoted
study estimated that spam would cost businesses $13 billion in
2003.[1] In April 2003, AOL reported that it had blocked 2.37 billion
pieces of UBE in a single day. [2] And, in a sure sign that UBE has
become of pressing concern, numerous politicians have begun to issue
pronouncements and prescriptions for fighting this epidemic.[3][4]
A variety of mechanisms from the technical community have been
proposed and/or implemented to fight UBE:
o Whitelists are lists of known non-spammers. For example, Habeas,
Inc. maintains a Habeas User List (HUL) of people who have agreed
to not spam. By including a haiku in email headers and enforcing
copyright on that ditty, they enforce their anti-spamming terms of
service. [5]
o Blacklists are lists of known spammers or ISPs that allow spam.[6]
o Spam filters run client-side or server-side to filter out spam
based on whitelists, blacklists, and textual and header
analysis.[7]
o A large number of documents address the overall technical
considerations for the control of UBE [8], operational
considerations for SMTP agents[9], and various extensions to the
protocols to support UBE identification and filtering.
[10][11][12]
o Various proposals have been advanced for "do not spam" lists, akin
to the Federal Trade Commission's "Do Not Call" list for
telemarketers.[13]
1.2 No Soliciting in the Real World
Municipalities frequently require solicitors to register with the
town government. And, in many cases, the municipalities prohibit
soliciting in residences where the occupant has posted a sign. The
town of West Newbury, Massachusetts, for example, requires:
"It shall be unlawful for any canvasser or solicitor to enter the
premises of a resident or business who has displayed a 'No
Trespassing' or 'No Soliciting' sign or poster. Further, it shall
Malamud Expires July 6, 2004 [Page 4]
draft-malamud-no-soliciting No-Solicit January 2004
be unlawful for canvassers or solicitors to ignore a resident or
business person's no solicitation directive or remain on private
property after its owner has indicated that the canvasser or
solicitor is not welcome." [14]
Registration requirements for solicitors, particularly those
soliciting for political or religious reasons, have been the subject
of a long string of court cases. However, the courts have generally
recognized that individuals may post "No Soliciting" signs and the
government may enforce the citizen's desire. In a recent case where
Jehovah's Witnesses challenged a registration requirement in the city
of Stratton, Connecticut, saying they derived their authority from
the Scriptures, not the city. However, the court noted:
"A section of the ordinance that petitioners do not challenge
establishes a procedure by which a resident may prohibit
solicitation even by holders of permits. If the resident files a
'No Solicitation Registration Form' with the mayor, and also posts
a 'No Solicitation' sign on his property, no uninvited canvassers
may enter his property ..." [15]
Even government, which has a duty to promote free expression, may
restrict the use of soliciting on government property. In one case,
for example, a school district was allowed to give access to its
internal electronic mail system to the union that was representing
teachers, but was not required to do so to a rival union that was
attempting to gain the right to represent the teachers. The court
held that where property is not a traditional public forum "and the
Government has not dedicated its property to First Amendment
activity, such regulation is examined only for reasonableness."[16]
The courts have consistently held that the state has a compelling
public safety reason for regulating solicitation. In Cantwell v.
Connecticut, the Supreme Court held that "a State may protect its
citizens from fraudulent solicitation by requiring a stranger in the
community, before permitting him publicly to solicit funds for any
purpose, to establish his identity and his authority to act for the
cause which he purports to represent."[17] And, in Martin v. City of
Struthers, the court noted that "burglars frequently pose as
canvassers, either in order that they may have a pretense to discover
whether a house is empty and hence ripe for burglary, or for the
purpose of spying out the premises in order that they may return
later."[18] The public safety issue applies very much to email, where
viruses can easily be delivered, in contrast to telephone
solicitations where public safety is not nearly as much an issue.
This analysis is very U.S.-centric, which may be appropriate given
that the large majority of UBE appears to originate from U.S.
Malamud Expires July 6, 2004 [Page 5]
draft-malamud-no-soliciting No-Solicit January 2004
citizens. However, the concept of prohibiting unwanted solicitation
does carry over to other countries:
o In Hong Kong, offices frequently post "no soliciting" signs.
o In the United Kingdom, where door-to-door peddlers are fairly
common, "no soliciting" signs are also common.
o In Australia, where door-to-door does not appear to be a pressing
social problem, there was legislation passed which outlawed the
practice of placing ads under wipers of parked cars.
o In France, which has a long tradition of door-to-door
solicitation, apartment buildings often use trespass laws to
enforce "no solicitation" policies.
o In the Netherlands, where door-to-door solicitation is not a
pressing issue, there is a practice of depositing free
publications in mailboxes. The postal equivalent of "no spam"
signs are quite prevalent and serve notice that the publications
are not desired.
1.3 A Distributed No Soliciting Extension
Many of the anti-spam proposals that have been advanced have great
merit, however none of them give notice to an SMTP agent in the
process of delivering mail that the receiver does not wish to receive
solicitations. Such a virtual sign would serve two purposes:
o It would allow the receiving system to "serve notice" that a
certain class of electronic mail is not desired, whether or not
such a message is properly identified as belonging to that class.
o If a message is properly identified as belonging to a certain
class and that class of messages is not desired, transfer of the
message can be eliminated. Rather than filtering after delivery,
elimination of the message transfer can save network bandwidth,
disk space, and processing power.
This memo details a series of extensions to SMTP that have the
following characteristics:
o A service extension is described that allows a receiving MTA to
signal the sending MTA that no soliciting is in effect.
o A header field for the sender of the message is defined that
allows the sender to flag a message as conforming to a certain
Malamud Expires July 6, 2004 [Page 6]
draft-malamud-no-soliciting No-Solicit January 2004
class.
o Trace fields for intermediate MTAs are extended to allow the
intermediate MTA to signal that a message conforms to a certain
class.
Allowing the sender of a message to tag a message as being, for
example, unsolicited commercial email with adult content, allows
"good" spammers to conform to legal content labelling requirements by
governmental authorities or conventions imposed by "whitelist"
services. For senders of mail who choose not to abide by these
conventions, the intermediate trace fields defined here allow the
destination MTA or a designated intermediate MTA to perform
appropriate dispositions on the received message.
This distributed approach to controlling UBE is advanced as an
alternative to centralized "do-not-spam" lists. The concluding
section of this document details how the decentralized approach would
work in practice and contrasts this approach to a centralized list.
Malamud Expires July 6, 2004 [Page 7]
draft-malamud-no-soliciting No-Solicit January 2004
2. The No-Soliciting SMTP Service Extension
Per RFC 2821,[22] a "NO-SOLICITING" SMTP service extension is
defined. The service extension is declared during the initial "EHLO"
SMTP exchange. The extension has one optional parameter and zero or
more solicitation class keywords. Using the notation as described in
the Augmented BNF[23], the syntax is:
No-Soliciting-Service = "NO-SOLICITING"
[ "SYSTEM-WIDE" / "PER-RECIPIENT" ]
0*( Solicitation-keywords )
2.1 The SYSTEM-WIDE Option
"NO-SOLICITING SYSTEM-WIDE" indicates that no soliciting is in effect
for all messages delivered to this system. It is equivalent to the
sign on the door of an office building announcing a company-wide
policy.
The parameter is presented during the initial exchange between sender
and receiver:
R: <wait for connection on TCP port 25>
S: <open connection to server>
R: 220 trusted.example.com SMTP service ready
S: EHLO untrusted.example.com
R: 250-trusted.example.com says hello
R: 250-NO-SOLICITING SYSTEM-WIDE ADV
(The "ADV" keyword is one of several possible values and is described
in the following section.)
A similar proposal was advanced in 1999 by John Levine and Paul
Hoffman. This proposal used the SMTP greeting banner to specify that
unsolicited bulk email is prohibited on a particular system through
the use of the "NO UCE" keyword.[19] As the authors note, their
proposal has the potential of overloading the semantics of the
greeting banner, which may also be used for other purposes (see,
e.g., [20]).
2.2 Solicitation Class Keywords
The "NO-SOLICITING" service extension may use solicitation class
keywords that signify a specific class of solicitations that are not
accepted. Keywords are separated by commas and follow the
"SYSTEM-WIDE" parameter.
Malamud Expires July 6, 2004 [Page 8]
draft-malamud-no-soliciting No-Solicit January 2004
Three classes are defined in this draft:
Keywords Description Reference
--------- -------------------------------- ---------
MAPS-UBE Unsolicited Bulk Email http://mail-abuse.org/
ADV Unsolicited Commercial Email http://www.spamlaws.com/
ADV:ADLT Sexually Explicit Commercial Mail http://www.spamlaws.com/
MAPS-UBE is the standard advanced by the Mail Abuse Prevention System
(MAPS), which states:
An electronic message is "spam" IF: (1) the recipient's personal
identity and context are irrelevant because the message is equally
applicable to many other potential recipients; AND (2) the
recipient has not verifiably granted deliberate, explicit, and
still-revocable permission for it to be sent; AND (3) the
transmission and reception of the message appears to the recipient
to give a disproportionate benefit to the sender.
Numerous states have adopted the "ADV" and "ADV:ADLT" conventions.
We cite the spamlaws.com site as a reference because it provides an
excellent summary of the definitions and pointers to the relevant
statutes.
There is no default keyword for the service. In other words, the
following example is a "no-op":
R: 250-NO-SOLICITING SYSTEM-WIDE
Additional solicitation class keywords may be defined and registered
in the registry as specified in Section 5. Multiple solicitation
class keywords are separated by a comma to form a list:
Solicitation-keywords = 1Solicit-word 0*("," 1Solicit-word)
Solicit-word = [ "MAPS-UBE" / "ADV" / "ADV:ADLT"
/ x-word / registered-word ]
x-word = ["x-" / "X-"] 1*(wordchars)
registered-word = ALPHA 0*(wordchars)
; registered-word(s) are registered
; with the IANA
wordchars = 1*("-" / "_" / ":" / ALPHA / DIGIT)
2.3 The PER-RECIPIENT Option
The "NO-SOLICITING PER-RECIPIENT" extension specifies that each "MAIL
FROM" command must identify if a message is a solicitation.
Malamud Expires July 6, 2004 [Page 9]
draft-malamud-no-soliciting No-Solicit January 2004
The presence of this extension is identified during the initial
greeting:
R: <wait for connection on TCP port 25>
S: <open connection to server>
R: 220 trusted.example.com SMTP service ready
S: EHLO untrusted.example.com
R: 250-trusted.example.com says hello
R: 250-NO-SOLICITING PER-RECIPIENT
Additionally, "SOLICIT" is defined as a parameter for the "MAIL FROM"
command. The "SOLICIT" parameter is followed by an optional equal
sign and a comma separated list of solicitation class keywords.
The syntax for this parameter is:
Mail-From-Solicit-Parameter = "SOLICIT"
1( "=" Solicitation-keywords)
As an informational message, the "550" or "250" replies to the "RCPT
TO" command may also contain the "SOLICIT" parameter.
The receiving system may decide on a per-user basis the appropriate
disposition of messages:
S: MAIL FROM:<savebigbucks@hotmail.com> SOLICIT=ADV,MAPS-UBE
S: RCPT TO:<coupon_clipper@trusted.resource.org>
R: 250 <coupon_clipper@trusted.resource.org>... Recipient ok
S: RCPT TO:<grumpy_old_boy@trusted.resource.org>
R: 550 <grumpy_old_boy@trusted.resource.org>... SOLICIT=ADV
In the previous example, the receiving MTA returned a "550" status
code, indicating that the message was being rejected. Note that the
implementation also echoes back the currently set keywords for that
user as a rudimentary informational message.
2.4 Use of Enhanced Mail Status Codes
If a session between two MTAs is using both the "NO-SOLICITING"
extension and the Enhanced Mail Status Codes as defined in RFC
3463[25] and a message is rejected based on the presence of a
"SOLICIT" parameter, the correct error message to return is "5.7.1",
defined as "the sender is not authorized to send to the destination
... [because] of per-host or per-recipient filtering."
2.5 Solicitation Mail Header
Per RFC 2822,[24] a new "Solicitation:" header field is defined which
Malamud Expires July 6, 2004 [Page 10]
draft-malamud-no-soliciting No-Solicit January 2004
contains one or more solicitation class keywords.
To: Coupon Clipper <coupon_clipper@trusted.resource.org>
From: Spam King <savebigbucks@hotmail.com>
Solicitation: ADV,ADV:ADLT
Several proposals, particularly legal ones, have suggested requiring
the use of keywords in the "Subject:" header. While embedding
information in the "Subject:" header may provide visual cues to end
users, it does not provide a straightforward set of cues for computer
programs such as mail transfer agents. As with embedding a "no
solicitation" message in a greeting banner, this would overload the
semantics of the "Subject:" header. Of course, there is no reason
why both mechanisms can't be used, and in any case the
"Solicitation:" header could be automatically inserted based on the
contents of the subject line.
It should be noted that the presence of both a "Solicitation:" header
and a "SOLICIT" service extension leads to the possibility of
conflict between the two. Implementors *SHOULD* always include any
values found in the "Solicitation:" header in the fields presented in
the service extension. Implementors "MAY" add additional keywords
for operational reasons as defined in Section 7.7 of RFC 2821[22].
2.6 Insertion of Solicitation Keywords in Trace Fields
The "Solicitation:" mail header is only available to the sending
client. RFCs 2821 and 2822 are quite specific that intermediate MTAs
shall not change message headers, with the sole exception of the
"Received:" trace field. Since many current systems use an
intermediate relay to detect unsolicited mail, an addition to the
"Received:" header is described.
As a review, RFC 2821[22] documents the following productions for the
"Received:" header in a mail message:
Malamud Expires July 6, 2004 [Page 11]
draft-malamud-no-soliciting No-Solicit January 2004
Time-stamp-line = "Received:" FWS Stamp <CRLF>
Stamp = From-domain By-domain Opt-info ";" FWS date-time
; where "date-time" is as defined in [32]
; but the "obs-" forms, especially two-digit
; years, are prohibited in SMTP and MUST NOT be used.
Opt-info = [Via] [With] [ID] [For]
With = "WITH" FWS Protocol CFWS
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
Attdl-Protocol = Atom
; Additional standard names for protocols are registered with
; the Internet Assigned Numbers Authority (IANA). SMTP servers
; SHOULD NOT use unregistered names.
The appropriate location for solicitation information is the
"Attdl-Protocol" field, which is defined in this document as
"ESMTP-Solicitation". The RFC 2821 productions are supplemented as
follows:
Protocol = "ESMTP" / "SMTP" / ESMTP-Solicitation / Attdl-Protocol
ESMTP-Solicitation = "ESMTP-Solicitation"
FWS 0*( Solicitation-keywords )
An example of a Received: header from a conforming MTA is as follows:
Received: by foo-mta.example.com with
ESMTP-Solicitation ADV,ADV:ADLT ; Sat, 9 Aug 2003
16:54:42 -0700 (PDT)
2.7 Relay of Messages
The "NO-SOLICITING SYSTEM-WIDE" service extension, if present,
applies to all messages handled by the receiving Message Transfer
Agent (MTA), including those messages intended to be relayed to
another system.
When relaying a message which was received via the SMTP protocol in
which the "SOLICIT" parameter was set on the "MAIL FROM" command, the
MTA *MUST* also set the "SOLICIT" parameter when delivering the
message to an SMTP server that supports this extension.
The "SOLICIT" parameter on a "MAIL FROM" command can be derived from
a variety of sources, including receipt of a message from a
Malamud Expires July 6, 2004 [Page 12]
draft-malamud-no-soliciting No-Solicit January 2004
conforming SMTP server. An SMTP server *MAY*, for operational reasons
as defined in Section 7.7 of RFC 2821[22], set this parameter after
detecting the presence of the "Solicitation:" or extended "Received:"
message header field or by using other system-specific techniques.
Implementers should be aware that the "NO-SOLICITING" service
extension is not a guaranteed end-to-end service. Specifically,
intermediate relays that do not support this service may "lose" the
per-message parameters. However, any trace fields inserted during the
message transfer process will persist.
2.8 Recommendations for Developers and Administrators
It is strongly recommended that any developers that implement the
"NO-SOLICITING" service extension *SHOULD NOT* enable the service as
a default. There are some indications that some policy makers may
view a default filtering in software as a prior restraint on
commercial speech. In other words, because the person installing the
software did not make an explicit choice to enable a certain type of
filtering, some might argue that such filtering was not desired.
Likewise, it is recommended that a system administrator installing
software *SHOULD NOT* enable "PER-RECIPIENT" filtering by default for
a user. Again, individual users should request the service.
The mechanism for an individual user to communicate their desire to
enable certain types of filtering is outside the scope of this
document.
It should be noted that for recipient MTAs, implementation of the
"SYSTEM-WIDE" option is significantly simpler than adding
"PER-RECIPIENT" capabilities. Because "PER-RECIPIENT" is an optional
parameter, it should be noted that:
o A conforming sending MTA *MUST* provide support for both
"SYSTEM-WIDE" and "PER-RECIPIENT".
o A conforming receiving MTA *MAY* provide support for either
"SYSTEM-WIDE" or "PER-RECIPIENT" or both.
Implementation of the SYSTEM-WIDE on a receiving MTA is almost
trivial. For example, on the popular sendmail [27] package, a few
minor changes need to be made to three files.
Malamud Expires July 6, 2004 [Page 13]
draft-malamud-no-soliciting No-Solicit January 2004
3. Use of the Extension
This proposal is not meant to solve the UBE problem, but offers some
tools that can be used by policy makers, be they governments defining
laws or Internet Service Providers defining appropriate use policies.
It does not solve the issues addressed by proposals that, for
example, add "reverse MX" resource records to the Domain Name System.
However, the service extension does allow a mail recipient to notify
the sender that certain forms of electronic mail are not desired and
does give policy makers a mechanism for requiring senders of such
electronic mail to identify their missives and allows them to
establish penalties for failure to do so.
By providing a service-level extension to SMTP, this proposal
provides a simple mechanism that allows a system or ISP to put email
senders on notice that mail that is both bulk and unsolicited is not
wanted. To illustrate how the system might work in practice, a
simple hypothetical scenario is presented.
Our scenario posits that the U.S. federal government wants to do
something about spam, but is uncertain about the effectiveness of a
centralized "do not spam" list. Instead, they decide to go for a
more decentralized approach as follows:
1. The first step would be for the government to promulgate a
definition of spam and tie a keyword to that definition. This
definition needs to published in a permanent record of some sort
so that it can be referenced in the following steps. The
Congressional Record [28] or the Federal Register [29] would both
be considered adequate for this purpose. The definition needs to
include an unambiguous definition of mail covered by the keyword,
a mechanism for a sender to convey that information, and the
legal import of the "NO-SOLICITING" notice and any penalties for
violation thereof. Let us suppose that the keyword to be
registered is ""UCE".
2. The appropriate authority (e.g., the Clerk of the House [30] or
an appropriate executive branch official) would register this
definition with the IANA using the template as described in
Section 5 and sending the completed template to iana@iana.org
[31].
3. To the extent that a proliferation of keywords and conflicting
definitions is considered an issue by policy makers, appropriate
discussions would be held with other countries and the states to
make definitions consistent.
4. Reputable email list maintainers would activate a simple check of
Malamud Expires July 6, 2004 [Page 14]
draft-malamud-no-soliciting No-Solicit January 2004
each address on their lists by connecting to the SMTP port of at
least one system indicated by an MX record in the Domain Name
System. If either the "SYSTEM-WIDE" or "PER-RECIPIENT" service
extension matches the "UCE" keyword, the address would be
scrubbed from the list.
5. Reputable users of email lists would add a "Solicitation: UCE"
header to their electronic mail and activate the same simple
check described in the previous step. Any addresses matching the
check would trigger non-delivery of the message and, presumably,
the scrubbing of that address from the list.
6. A system manager, under the guidance of the Administrative
Contact for a domain, would configure "MX" records in the Domain
Name System to designate one or more systems authorized to
receive mail for the domain in question. For each system so
designated, the system manager might enable "NO-SOLICITING
SYSTEM-WIDE UCE". These systems receiving mail on behalf of the
designated domain might also be configured to run a spam
identification utility, such as SpamAssasin [32] or SpamBouncer
[33].
7. End users would configure their mail filters to filter out any
properly tagged messages (e.g., "Solicitation: UCE") and any
messages that are not properly tagged (e.g., in SpamBouncer, the
user might set the "SPAMLEVEL" parameter to "10", which would
filter all messages with a score of 10 or greater using the
software's own algorithms for the detection of probable spam).
8. Unagressive end users would simply delete their spam folder
periodically. More paranoid end users would check the folder for
false positives and then delete it. A few users might take more
agressive steps. For example, setting the SpamBouncer
"SPAMREPLY" to "COMPLAIN" will automatically dispatch complaints
to ISP abuse lines. If financial penalties for violation of UCE
tagging provisions exist and include a split between the federal
authorities and the filer of a complaint, an additional copy of
the offending mail can be dispatched to a service bureau whose
function is to aggregate large amounts of spam, find the senders,
and then file appropriate procedural motions, receiving a portion
of any recovered monies in return for its efforts.
3.1 Relationship to Centralized Approaches
The overwhelming success of the "do not call" list for telemarketing
provisions have prompted a variety of proposals for similar "do not
spam" lists. Such a list takes a centralized approach to solving the
Malamud Expires July 6, 2004 [Page 15]
draft-malamud-no-soliciting No-Solicit January 2004
same problem addressed by this service extension. The centralized
approach has the following potential pitfalls:
o From the point of view of the consumer, a centralized list
operates in batch mode: there is a lag between asserting the
desire to start or stop receiving a certain type of mail and the
implementation of that assertion. Consumers will still need to
filter mail and decide if they want to take action upon violations
of either centrally-administered or distributed solutions.
o From the point of view of the government, a centralized list
requires a bureaucracy to administer and maintain the list.
Because the list contains aggregated information, it is more
valuable to legally irresponsible mailers and thus adequate
security provisions need to be made for the list contents.
o The decentralized approach is cheaper for telemarketers to
implement. From the point of view of the sender of unsolicited
mail, the bulk approach requires a significant data processing
investment to "scrub" lists that are received. This is a classic
database cartesian product. Assume a do-not-spam list with 1
million names and a sender's list with 1 million name. If one
were to use all the methods, procedures, and systems specified in
various federal data processing regulations, this computational
program could easily consume 1 googleflop of processing power
(although it should be recognized that processing the do-not-spam
list into a structure such as hash can reduce the number of
lookups closer to the theoretical minimum of 1 million data
accesses). In contrast, the decentralized approach requires a
simple pattern match on one address at a time.
It should be noted that the centralized and decentralized approaches
can coexist in some manner. A useful analogy is the field of
copyright. Documents have an inherent copyright and the legal
definition of a copyright violation takes into account the degree to
which the alleged violator knew they were violating the conditions
imposed by the law. One common way to assert coypright is through a
mark on the document itself, a decentralized approach to copyright
assertion. One can also file a registration with the copyright
office, which adds an additional presumption that adequate notice has
been given.
In the example of spam prevention, there would also be an inherent
right, the right not to received unsolicited commercial mail. The
courts or executive branch, as with copyright, would assess fines
based on a variety of factors, and the degree of notice could
certainly be such a factor. Adding an address to a registry of
do-not-spam addresses, in conjunction with a real-time
Malamud Expires July 6, 2004 [Page 16]
draft-malamud-no-soliciting No-Solicit January 2004
"NO-SOLICITING" assertion could both be factors taken into
consideration in levying fines or taking other corrective actions.
Malamud Expires July 6, 2004 [Page 17]
draft-malamud-no-soliciting No-Solicit January 2004
4. Security Considerations
This proposal does not present additional security complications
beyond those already amply represented in the current architecture
for electronic mail.
Malamud Expires July 6, 2004 [Page 18]
draft-malamud-no-soliciting No-Solicit January 2004
5. IANA Considerations
There are four IANA considerations presented in this draft:
1. Addition of the "NO-SOLICITING" service extension to the Mail
Parameters registry.
2. Addition of the "ESMTP-Solicitation" Additional Protocol
3. Creation of a Solicitation Class Keywords registry.
4. Creation of a "Solicitation:" mail header, which does not
currently raise any IANA considerations.
5.1 The Mail Parameters Registry
The IANA Mail Parameters registry documents SMTP service extensions.
The "NO-SOLICITATION" service extension would need to be added to
this registry as follows.
Keywords Description Reference
------------ -------------------------------- ---------
NO-SOLICITING Notification of no soliciting. [<this draft>]
The parameters subregistry would need to be modified as follows:
Service Ext EHLO Keyword Parameters Reference
----------- ------------ ----------- ---------
No Soliciting NO-SOLICITING SYSTEM-WIDE [<this draft>]
No Soliciting NO-SOLICITING PER-RECIPIENT [<this draft>]
5.2 ESMTP-Solicitation Additional Protocol
The Mail Parameters registry would need to be modified to list
"ESMTP-Solicitation" as a valid additional protocol for use in the
"Received:" header of a mail message.
5.3 The Solicitation Class Keywords Registry
A new registry (or a subregistry of Mail Parameters) would need to be
established for Solicitation Class Keywords. The registry would
contain the following fields:
1. Keyword name (e.g., "MAPS-UBE").
2. Keyword description (e.g., "Unsolicited Bulk Email").
Malamud Expires July 6, 2004 [Page 19]
draft-malamud-no-soliciting No-Solicit January 2004
3. Keyword reference (e.g., "<this draft>").
Per the policies outlined in RFC 2434[26], it is recommended that the
IESG appoint a Designated Expert to administer this registry.
Authority for solicitation class keywords in this registry will come
in some cases from published RFCs, but in other cases will come from
applicable laws or regulations. It is recommended that any non-RFC
derived solicitation class keywords be documented in future
informational RFCs to provide a consistent set of references.
5.4 The Solicitation Mail Header
There is currently no registry defined for mail headers. If such a
registry were to exist, the "Solicitation:" header field would need
to be added to it.
Malamud Expires July 6, 2004 [Page 20]
draft-malamud-no-soliciting No-Solicit January 2004
6. Author's Acknowledgements
The author would like to thank Rebecca Malamud for many discussions
and ideas that led to this proposal and to John C. Klensin and
Marshall T. Rose for their extensive input on how it could be
properly implemented in SMTP. Eric Allman, Dave Crocker, Curtis
Generous, Paul Hoffman, John Levine, Keith Moore, Paul Vixie, and
Pindar Wong kindly provided reviews of the draft and/or suggestions
for improvement. Information about soliciting outside the U.S. was
received from Rob Blokzijl, Jon Crowcroft, Christian Huitema, Geoff
Huston, and Pindar Wong. John Levine pointed out the contrast
between this proposal and "do not spam" lists. As always, all
errors, omissions, generalizations, and simplifications (EOGS) are
the responsibility of the author.
Malamud Expires July 6, 2004 [Page 21]
draft-malamud-no-soliciting No-Solicit January 2004
Informative References
[1] Associated Press, "Study: Spam costs businesses $13 billion",
January 2003, <http://www.cnn.com/2003/TECH/biztech/01/03/
spam.costs.ap/index.html>.
[2] CNET News.Com, "AOL touts spam-fighting prowess", April 2003,
<http://news.com.com/2100-1025-998944.html>.
[3] Charles, C., "Schumer, Christian Coalition Team Up to Crack
Down on Email Spam Pornography", June 2003, <http://
www.senate.gov/~schumer/SchumerWebsite/pressroom/
press_releases/PR01782.html>.
[4] Federal Trade Commission, "Federal, State, Local Law Enforcers
Target Deceptive Spam and Internet Scams", November 2002,
<http://www.ftc.gov/opa/2002/11/nenetforcema.htm>.
[5] Habeas, Inc., "Habeas Compliant Message", April 2003, <http://
www.habeas.com/services/hcm.htm>.
[6] Spamhaus.Org, "Register of Known Spam Operations", November
2003, <http://www.spamhaus.org/rokso/index.lasso>.
[7] Mason, J., "Spamassassin - Mail Filter to Identify Spam Using
Text Analysis", Version 2.55, May 2003, <http://
www.mirror.ac.uk/sites/spamassassin.taint.org/spamassassin.org/
doc/spamassassin.html>.
[8] Crocker, D., "Technical Considerations for Spam Control
Mechanisms", draft-crocker-spam-techconsider-02 (work in
progress), May 2003.
[9] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP
30, RFC 2505, February 1999.
[10] Danisch, H., "A DNS RR for simple SMTP sender authentication",
draft-danisch-dns-rr-smtp-03 (work in progress), October 2003.
[11] Daboo, C., "SIEVE Spamtest and Virustest Extensions",
draft-daboo-sieve-spamtest-04 (work in progress), October 2003.
[12] Crouzet, B., "Authenticated Mail Transfer Protocol",
draft-crouzet-amtp-01 (work in progress), October 2003.
[13] Federal Trade Commission, "Telemarketing Sales Rule", Federal
Register Vol. 68, No. 19, January 2003, <http://www.ftc.gov/os/
2002/12/tsrfinalrule.pdf>.
Malamud Expires July 6, 2004 [Page 22]
draft-malamud-no-soliciting No-Solicit January 2004
[14] The Town of West Newbury, Massachusetts, "Soliciting/Canvassing
By-Law", Chapter 18 Section 10, March 2002, <http://
www.town.west-newbury.ma.us/Public_Documents/
WestNewburyMA_Bylaws/chapter18>.
[15] U.S. Supreme Court, "Watchtower Bible & Tract Society of New
York, Inc., et al. v. Village of Stratton et al.", 122 S.Ct.
2080 (2002), June 2002, <http://caselaw.lp.findlaw.com/scripts/
getcase.pl?court=US&vol=000&invol=00-1737>.
[16] U.S. Supreme Court, "Perry Education Association v. Perry Local
Educators' Association", 460 U.S. 37 (1983), February 1983,
<http://caselaw.lp.findlaw.com/scripts/
getcase.pl?court=US&vol=460&invol=37>.
[17] U.S. Supreme Court, "Cantwell v. State of Connecticut", 310
U.S. 296 (1940), May 1940, <http://caselaw.lp.findlaw.com/
scripts/getcase.pl?court=US&vol=310&invol=296>.
[18] U.S. Supreme Court, "Martin v. City of Struthers, Ohio", 319
U.S. 141 (1943), May 1943, <http://caselaw.lp.findlaw.com/
scripts/getcase.pl?court=US&vol=319&invol=141>.
[19] Levine, J. and P. Hoffman, "Anti-UBE and Anti-UCE Keywords in
SMTP Banners", Revision 1.1, March 1999, <http://www.cauce.org/
proposal/smtp-banner-rfc.shtml>.
[20] Malamud, C., "An Internet Prayer Wheel", Mappa.Mundi Magazine,
August 1999, <http://mappa.mundi.net/cartography/Wheel/>.
Malamud Expires July 6, 2004 [Page 23]
draft-malamud-no-soliciting No-Solicit January 2004
Normative References
[21] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[22] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
2001.
[23] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[24] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[25] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463,
January 2003.
[26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
Malamud Expires July 6, 2004 [Page 24]
draft-malamud-no-soliciting No-Solicit January 2004
URIs
[27] <http://www.sendmail.org/>
[28] <http://thomas.loc.gov/>
[29] <http://www.gpoaccess.gov/fr/>
[30] <http://clerk.house.gov/index.php>
[31] <mailto:iana@iana.org>
[32] <http://spamassassin.org/index.html>
[33] <http://www.spambouncer.org/>
[34] <http://www.irtf.org/charters/asrg.html>
[35] <http://www.irtf.org/>
[36] <mailto:carl@media.org>
[37] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-02.html>
[38] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-03.html>
[39] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-01.html>
[40] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-02.html>
[41] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-00.html>
[42] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-01.html>
[43] <mailto: remote-printer.Timothy_J_Muris/
FTC@12023262012.iddd.tpc.int>
[44] <http://frwebgate.access.gpo.gov/cgi-bin/
getdoc.cgi?dbname=108_cong_bills&docid=f:s877es.txt.pdf>
[45] <mailto:carl@media.org>
Malamud Expires July 6, 2004 [Page 25]
draft-malamud-no-soliciting No-Solicit January 2004
[46] <mailto:hbeales@ftc.gov>
[47] <mailto:ed@markey.house.gov>
Author's Address
Carl Malamud
Memory Palace Press
PO Box 300
Sixes, OR 97476
US
EMail: carl@media.org
Malamud Expires July 6, 2004 [Page 26]
draft-malamud-no-soliciting No-Solicit January 2004
Appendix A. Status of This Document
A.1 RFC Category
This document will be submitted for publication as an Informational
RFC.
A.2 Document Repository
The source for this document can be found at http://
trusted.resource.org/no-solicit.
A.3 Discussion
Discussions of this draft may be directed towards the following
targets:
o The ietf-smtp mailing list discusses clarrifications and
extensions to SMTP and can be found at http://www.imc.org/
ietf-smtp/.
o The Anti-Spam Research Group, [34] a part of the Internet Research
Task Force, [35] maintains a mailing list at https://
www1.ietf.org/mailman/listinfo/asrg.
o Comments may be sent directly to the author at carl@media.org
[36].
A.4 Changes From Previous Drafts
Changes from draft-malamud-no-soliciting-02 [37] to
draft-malamud-no-soliciting-03 [38]:
o A discussion of Open Issues has been preprended to the document
and comments are requested.
Changes from draft-malamud-no-soliciting-01 [39] to
draft-malamud-no-soliciting-02 [40]:
o A real-world example of how the proposed service extension could
be used has been added (see Section 3).
o A discussion of the relative implementation difficulty of
"SYSTEM-WIDE" versus "PER-RECIPIENT" has been added (see Section
2.8).
o A discussion of the relationship of this proposal to centralized
Malamud Expires July 6, 2004 [Page 27]
draft-malamud-no-soliciting No-Solicit January 2004
"do not spam" lists has been added (see Section 3.1).
Changes from draft-malamud-no-soliciting-00 [41] to
draft-malamud-no-soliciting-01 [42]:
o The two service extensions previously proposed (
"SYSTEM-WIDE-NO-SOLICITING" and "PER-MESSAGE-NO-SOLICITING") have
been collapsed into a single "NO-SOLICITING" service extension (
See Section 2).
o "PER-MESSAGE" has been changed to "PER-RECIPIENT" to more properly
express the operation of the extension (see Section 2.3).
o A solicitation class keyword syntax is introduced to allow
different kinds of unsolicited mail to be considered (see Section
2.2).
o The "Solicitation:" header has been supplemented with an extended
"Received:" header syntax (see Section 2.6).
o A discussion of the use of Enhanced Mail Status Codes has been
included (see Section 2.4).
o A more extensive IANA Considerations section has been added,
including creation of a Solicitation Keywords registry (see
Section 5).
Malamud Expires July 6, 2004 [Page 28]
draft-malamud-no-soliciting No-Solicit January 2004
Appendix B. Transmittal
November 30, 2003
The Honorable Timothy J. Muris, Chairman
The Federal Trade Commission
600 Pennsylvania Avenue, N.W.
Washington, D.C. 20580
remote-printer.Timothy_J_Muris/FTC@12023262012.iddd.tpc.int [43]
Dear Mr. Muris:
On October 23, 2003, the U.S. Senate passed S.877, known as the
CAN-SPAM Act of 2003. [44] That bill provides, in part:
*SEC. 109. DO-NOT-EMAIL REGISTRY.*
(a) IN GENERAL.--Not later than 6 months after the date of
enactment of this title, the Commission shall transmit to the
Senate Committee on Commerce, Science, and Transportation and the
House of Representatives Committee on Energy and Commerce a report
that--
1. sets forth a plan and timetable for establishing a nationwide
marketing Do-Not-E-mail registry;
2. includes an explanation of any practical, technical, security,
privacy, enforceability, or other concerns that the Commission
has regarding such a registry; and
3. includes an explanation of how the registry would be applied
with respect to children with e-mail accounts.
I have read with some interest comments by you and Mr. Beales in the
press regarding the practicality of implementing a centralized
"do-not-spam" list. I share your feelings that a centralized
do-not-call list makes sense and certainly has been popular, but that
email has vastly different characteristics from telephone numbers,
making such a list impractical.
I hope that in your deliberations on this subject and in your report
to the Congress you will consider decentralized approaches to this
problem, such as the one detailed in the proposed SMTP extension
described here:
http://trusted.resource.org/no-solicit/
I should note that the above-referenced proposal is not the only way
Malamud Expires July 6, 2004 [Page 29]
draft-malamud-no-soliciting No-Solicit January 2004
to accomplish the goal of non-centralized non-solicitation
notification, and is brought to your attention simply to demonstrate
that non-centralized approaches to this important problem are
possible and practical.
Please don't hesitate to let me know if you would like more
information or if I can answer any questions.
Sincerely yours,
Carl Malamud
Memory Palace Press
P.O. Box 300
Sixes, Oregon 97476
carl@media.org [45]
cc:
Mr. J. Howard Beales, III
Bureau of Consumer Protection
The Federal Trade Commission
600 Pennsylvania Avenue, N.W.
Washington, D.C. 20580
hbeales@ftc.gov [46]
The Honorable Edward J. Markey
U.S. House of Representatives
2108 Rayburn House Office Building
Washington, DC 20515
ed@markey.house.gov [47]
Malamud Expires July 6, 2004 [Page 30]
draft-malamud-no-soliciting No-Solicit January 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Malamud Expires July 6, 2004 [Page 31]
draft-malamud-no-soliciting No-Solicit January 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Malamud Expires July 6, 2004 [Page 32]
