WDIFF

draft-malamud-no-soliciting-04.txt --> draft-malamud-no-soliciting-05.txt

Network Working Group C. Malamud
Internet-Draft Memory Palace Press
Expires: July 24, 30, 2004 January 24, 30, 2004

A No Soliciting SMTP Service Extension
draft-malamud-no-soliciting-04
draft-malamud-no-soliciting-05

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 24, 30, 2004.

Abstract

This Internet-Draft proposes an extension to SMTP for an electronic
mail equivalent to the real-world "No Soliciting" sign. In addition
to the service extension, a new message header and extensions to the
existing "received" message header are described.

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, [RFC2119].

Malamud Expires July 24, 30, 2004 [Page 1]

draft-malamud-no-soliciting No-Solicit January 2004

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 The Spam Pandemic . . . . . . . . . . . . . . . . . . . . . 3
1.2 No Soliciting in the Real World . . . . . . . . . . . . . . 3
1.3 A Distributed No Soliciting Extension and Electronic Mail . . . . . . . . . . . . . 5
2. The No-Soliciting SMTP Service Extension . . . . . . . . . . 6
2.1 The SYSTEM-WIDE Option EHLO Exchange . . . . . . . . . . . . . . . . . . . 6 . . 7
2.2 Solicitation Class Keywords . . . . . . . . . . . . . . . . 7
2.2.1 Note on Choice of Solicitation Class Keywords . . . . . . . . . . . . . . . . . 8
2.3 The PER-RECIPIENT Option MAIL FROM Command . . . . . . . . . . . . . . . . . . . 8
2.4 Use of Error Reporting and Enhanced Mail Status Codes . . . . . . . . . . . . . 9
2.5 Solicitation Mail Header . . . . . . . . . . . . . . . . . . 10
2.6 Insertion of Solicitation Keywords in Trace Fields . . . . . 10
2.7 Relay of Messages . . . . . . . . . . . . . . . . . . . . . 11
2.8 Recommendations for Developers and Administrators . . . . . 11
3. Use of the Extension . . . . . No Default Solicitation Class . . . . . . . . . . . . . . . 12
3.1 Relationship to Centralized Approaches . . . . . . . . . . . 14
4.
3. Security Considerations . . . . . . . . . . . . . . . . . . 15
5. 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
5.1 13
4.1 The Mail Parameters Registry . . . . . . . . . . . . . . . . 16
5.2 13
4.2 Trace Fields . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3 13
4.3 The Solicitation Class Keywords Registry . . . . . . . . . . 16
5.3.1 13
4.3.1 Guidance on Keyword Specification . . . . . . . . . . . . . 16
5.4 14
4.4 The Solicitation Mail Header . . . . . . . . . . . . . . . . 17
6. 15
5. Author's Acknowledgements . . . . . . . . . . . . . . . . . 17 15
Informative References . . . . . . . . . . . . . . . . . . . 17 15
Normative References . . . . . . . . . . . . . . . . . . . . 19 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . 20 18
A. Collected ABNF Descriptions (Normative) . . . . . . . . . . 18
B. Example Solicitation Class Keywords (Non-Normative) . . . . 19
C. Status of This Document [To Be Removed Upon Publication] . . 20
A.1 19
C.1 RFC Category . . . . . . . . . . . . . . . . . . . . . . . . 20
A.2 19
C.2 Document Repository . . . . . . . . . . . . . . . . . . . . 21
A.3 19
C.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 21
A.4 19
C.4 Changes From Previous Drafts . . . . . . . . . . . . . . . . 21 20
Intellectual Property and Copyright Statements . . . . . . . 23

Malamud Expires July 24, 30, 2004 [Page 2]

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.[Ferris] In April 2003, AOL reported that it had blocked 2.37
billion pieces of UBE in a single day. [CNET] day.[CNET] 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.[Schumer][FTC]

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. [Habeas]
service.[Habeas]

o Blacklists are lists of known spammers or ISPs that allow
spam.[ROSKO]
spam.[ROKSO]

o Spam filters run client-side or server-side to filter out spam
based on whitelists, blacklists, and textual and header
analysis.[Assassin]

o A large number of documents address the overall technical
considerations for the control of UBE
[I-D.crocker-spam-techconsider],
UBE[I-D.crocker-spam-techconsider], operational considerations for
SMTP agents[RFC2505], and various extensions to the protocols to
support UBE identification and filtering.
[I-D.danisch-dns-rr-smtp][I-D.daboo-sieve-spamtest][I-D.crouzet-amtp]

o Various proposals have been advanced for "do not spam" lists, akin
to the Federal Trade Commission's "Do Not Call" list for
telemarketers.[FTC.TSR]

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:

Malamud Expires July 24, 30, 2004 [Page 3]

draft-malamud-no-soliciting No-Solicit January 2004

"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
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." [Newbury] welcome."[Newbury]

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 ..." [Watchtower] ..."[Watchtower]

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."[Perry]

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."[Cantwell] 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."[Martin] The public safety issue applies very much to email,
where viruses can easily be delivered, in contrast to telephone

Malamud Expires July 24, 30, 2004 [Page 4]

draft-malamud-no-soliciting No-Solicit January 2004

solicitations where public safety is not nearly as much an issue.

This analysis is very U.S.-centric, which may be appropriate given
that is partly due to the large majority background
of UBE appears to originate from U.S.
citizens. the author. 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 and Electronic Mail

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. desired.

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 Mail

Malamud Expires July 24, 2004 [Page 5]

draft-malamud-no-soliciting No-Solicit January 2004
Transport Agent (MTA) to signal the sending MTA that no soliciting
is in effect.

Malamud Expires July 30, 2004 [Page 5]

draft-malamud-no-soliciting No-Solicit January 2004

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
class.

o Trace fields for intermediate MTAs are extended to allow the
intermediate MTA to signal that a message conforms to is in 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 authorities, license agreements with service providers,
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 Several important
caveats should be kept in practice and contrasts mind by developers as they examine this approach to
extension:

o This extension only provides a centralized list.

2. The No-Soliciting SMTP Service Extension

Per [RFC2821], simple mean for senders, MTAs, and
receivers to assert keywords drawn from a "NO-SOLICITING" SMTP service extension is defined.
The service common registry. This
extension is declared during the initial "EHLO" does not deal with any issues of authentication or
consent.

o This extension does not specify what actions should be taken by a
recipient. In particular it does not specify that a particular
message should be accepted or deleted. That decision is well
outside of the scope of this extension and rests with the
recipient of the message.

o This extension does not relieve an intermediate MTA of its
obligations to relay a message.

2. The No-Soliciting SMTP Service Extension

Per [RFC2821], 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 parameter, consisting of
zero or more solicitation class keywords. Using the notation as
described in the Augmented BNF[RFC2234], the syntax is:

No-Soliciting-Service = "NO-SOLICITING"
( "SYSTEM-WIDE"
[ SP Solicitation-keywords ] )
/ "PER-RECIPIENT" )

Malamud Expires July 30, 2004 [Page 6]

draft-malamud-no-soliciting No-Solicit January 2004

As will be further described below, the "Solicitation-keywords"
construct is used to indicate which classes of messages are accepted or not. In
the case of the "SYSTEM-WIDE" option, this information not
desired. A keyword that is indicated presented during the initial "EHLO" exchange. In the case of the
"PER-RECIPIENT" option, this information is not present in the
initial
exchange and is instead presented applies to all messages exchanged in this session. As will
also be further described below, additional keywords may be specified
on a per-recipient basis as part of the "MAIL-FROM" "MAIL FROM" command.

2.1 The SYSTEM-WIDE Option

"NO-SOLICITING SYSTEM-WIDE" indicates EHLO Exchange

Keywords presented during the initial exchange indicate that no
soliciting is in effect

Malamud Expires July 24, 2004 [Page 6]

draft-malamud-no-soliciting No-Solicit January 2004 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: For example:

(The "ADV" keyword is one an example of several possible values and a keyword, the syntax of which is
described in the following section.) section. The example values are drawn from
the non-normative appendix in Appendix B.)

Historical Note:

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.[Levine] 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., [Malamud]).

2.2 Solicitation Class Keywords

The "NO-SOLICITING" service extension uses solicitation class
keywords to signify classes of solicitations that are not accepted.
Keywords
Solicitation class keywords are separated by commas and follow the "SYSTEM-WIDE"
parameter. As described subsequently, commas.

There is no default solicitation class keywords
are also used with keyword for the "PER-RECIPIENT" variant of this extension as
well as with service. In
other words, the "Solicitation:" and trace field message headers.

Three solicitation class keywords 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 following example is a "no-op":

R: 250-NO-SOLICITING

While the standard advanced by the Mail Abuse Prevention System
(MAPS), which states:

An electronic message above example is "spam" IF: (1) the recipient's personal
identity and context are irrelevant because the message a "no-op" it is equally
applicable to many other potential recipients; AND (2) the useful for an MTA that

Malamud Expires July 24, 30, 2004 [Page 7]

draft-malamud-no-soliciting No-Solicit January 2004

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

wishes to the recipient pass along all messages, but would also like to give pass along
"SOLICIT=" parameters on a disproportionate benefit to the sender.

Numerous states have adopted the "ADV" and "ADV:ADLT" conventions.
We cite message-by-message basis. The above
example invokes the spamlaws.com site as a reference because it provides an
excellent summary use 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 extension but does not signal any
restrictions by class of message.

Solicitation class keywords may be defined and registered as
specified in Section 5.3. 4.3. Multiple solicitation class keywords are
separated by a comma to form a list:

Solicitation-keywords = Solicit-word 0*("," Solicit-word)
Solicit-word = [ "MAPS-UBE" / "ADV" / "ADV:ADLT"
/ x-word / registered-word ]
x-word = ["x-" / "X-"] 1*(wordchars) 0*("," registered-word)
registered-word = ALPHA 0*(wordchars) 0*(wordchar)
; registered-word(s) are registered
; with the IANA
wordchars
wordchar = 1*("-" ("-" / "_" / ":" / ALPHA / DIGIT)

Developers should note that a "registered-word" MAY contain a
trailing wild card as part of the specification. See Section 5.3.1 4.3.1
for more details.

Several example solicitation class keywords are used throughout this
document and are further described in the non-normative Appendix B.

2.2.1 Note on Choice of Solicitation Class Keywords

This document does not specify which solicitation class keywords
shall or shall not be used on a particular message. The requirement
to use a particular keyword is a policy decision well outside the
scope of this document. In particular, the three keywords described
in this document are for illustrative purposes only and it is
expected that relevant policy bodies (e.g., a government, ISP, governments, ISPs,
developers, or other institution) others) will specify appropriate keywords, the
definition of the meaning of those keywords, and any other policy
requirements, such as a requirement to use or not use this extension
in particular circumstances.

2.3 The PER-RECIPIENT Option

The "NO-SOLICITING PER-RECIPIENT" extension specifies that each "MAIL

Malamud Expires July 24, 2004 [Page 8]

draft-malamud-no-soliciting No-Solicit January 2004

FROM" command must identify if a message is a solicitation.

The presence of this extension is identified during the initial
greeting:

Additionally, "SOLICIT" is defined as a parameter for the MAIL FROM Command

"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"
"=" Solicitation-keywords
; Solicitation-keywords, when used in MAIL FROM command
; MUST be identical to those in the Solicitation: header.

Note that white space is not permitted in this production.

Malamud Expires July 30, 2004 [Page 8]

draft-malamud-no-soliciting No-Solicit January 2004

As an informational message, the "550" or "250" replies to the "RCPT
TO" command may also contain the "SOLICIT" parameter. If a message is
being rejected due to a solicitation class keyword match,
implementations SHOULD echo which solicitation classes are in effect.
See Section 2.4 for more on error reporting.

The receiving system may decide on a per-user per-message basis the
appropriate disposition of messages:

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 ADV
S: MAIL FROM:<save@burntmail.example.com> SOLICIT=ADV,MAPS-UBE SOLICIT=ADV:ADLT
S: RCPT TO:<coupon_clipper@moonlink.example.com>
R: 250 <coupon_clipper@moonlink.example.com>... Recipient ok
S: RCPT TO:<grumpy_old_boy@moonlink.example.com>
R: 550 <grumpy_old_boy@moonlink.example.com>... SOLICIT=ADV <grumpy_old_boy@moonlink.example.com> SOLICIT=ADV:ADLT

In the previous example, the receiving MTA returned a "550" status
code, indicating that one message was being rejected. Note that the The
implementation also echoes back the currently set keywords for that
user on the "550" error status message.

2.4 Use of Enhanced Mail Status Codes

If a session between two MTAs The solicitation class keyword
which is using both echoed back is "ADV:ADLT" which illustrates how this
per-recipient solicitation class keyword has supplemented the "NO-SOLICITING"
extension and base
"ADV" class declared in the Enhanced Mail Status Codes as defined "EHLO" exchange.

It should be carefully noted that this document does not specify
which actions a recipient should take if a particular solicitation
class keyword is present in [RFC3463]
and a "MAIL FROM" command. The decision to
accept or reject a message is rejected based on outside of the presence scope of a "SOLICIT"
parameter, this document.

Developers should also note that the correct error message to return is "5.7.1", defined as
"the source of the solicitation class
keywords used in the "MAIL FROM" command MUST be the "Solicitation:"
header described in Section 2.5 and MUST NOT be supplemented by
additional solicitation class keywords derived from the "Received:"
header trace fields which are described in Section 2.6.

2.4 Error Reporting and 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 [RFC3463]
and a message is rejected based on the presence of a "SOLICIT"
parameter, the correct error message to return will usually be
"5.7.1", defined as "the sender is not authorized to send to the
destination ... [because] of per-host or per-recipient filtering."

Malamud Expires July 24, 30, 2004 [Page 9]

draft-malamud-no-soliciting No-Solicit January 2004

Other codes, including temporary status codes, may be more
appropriate in some circumstances and developers should look to
[RFC3463] on this subject. An example of such a situation might be
the use of quotas or size restrictions on messages by class. An
implementation MAY impose limits such as message size restrictions
based on solicitation classes, and when such limits are exceed they
SHOULD be reported using whatever status code is appropriate for that
limit.

In all cases, an implementation SHOULD include a
"Mail-From-Solicit-Parameter" on a"250" reply to the "MAIL FROM"
command. The parameter SHOULD includes the solicitation class
keyword(s) that matched. In addition to the solicitation class
keyword(s) that matched, an implementation MAY include additional
solicitation class keywords that are in effect.

2.5 Solicitation Mail Header

Per [RFC2822], a new "Solicitation:" header field is defined which
contains one or more solicitation class keywords.

Solicitation-header = "Solicitation:" 1*SP Solicitation-keywords

An example of this header follows:

To: Coupon Clipper <coupon_clipper@moonlink.example.com>
From: Spam King <save@burntmail.example.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 overloads 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 by the
sender's Mail User Agent (MUA) based on the contents of the subject
line.

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

Malamud Expires July 30, 2004 [Page 10]

draft-malamud-no-soliciting No-Solicit January 2004

"Received:" header is described.

[RFC2821] documents the following productions for the "Received:"
header in a mail message:

; From RFC 2821
With = "WITH" FWS Protocol CFWS
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol

Additionally, [RFC2822] defines a comment field as follows:

; From RFC 2822
comment = "(" *([FWS] ccontent) [FWS] ")"

Solicitation Keywords are inserted as comments using the following
production, which is based on the
ccontent = ctext / quoted-pair / comment

The "Mail-From-Solicit-Parameter" defined in Section 2.3 above: above is a
restricted form of ctext, yielding the following production:

With-Solicit = "WITH" FWS Protocol
"(" [FWS] Mail-From-Solicit-Parameter comment [FWS] ")"

Malamud Expires July 24, 2004 [Page 10]

draft-malamud-no-soliciting No-Solicit January 2004
comment = "(" *([FWS] ccontent) [FWS] ")"
ccontent = ctext / quoted-pair /
comment / Mail-From-Solicit-Parameter
; The Mail-From-Solicit-Parameter
; is a restricted form of ctext

An example of a Received: header from a conforming MTA is as follows:

Received: by foo-mta.example.com with
ESMTP (SOLICIT=ADV,ADV:ADLT) ; Sat, 9 Aug 2003
16:54:42 -0700 (PDT)

It should be noted that keywords presented in trace fields may not
agree with those found in the "Solicitation:" header and trace fields
may exist even if the header is not present. When determing which
keywords are applicable to a particular exchange of messages,
implementors SHOULD examine any keywords found in the "Solicitation:"
header. Implementors MAY examine other keywords found in the trace
fields.

2.7 Relay of Messages

The "NO-SOLICITING SYSTEM-WIDE" "NO-SOLICITING" 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 in which the "SOLICIT"
parameter was set on the "MAIL FROM" command, the MTA MUST also set faithfully

Malamud Expires July 30, 2004 [Page 11]

draft-malamud-no-soliciting No-Solicit January 2004

relay 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
conforming SMTP server. An SMTP server MAY, for operational reasons
as defined in Section 7.7 of [RFC2821], 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, the "Solicitation:" header and any
trace fields inserted during the message transfer process will
persist, and downstream MTAs MAY use this extension when relaying
receiving a message which was received without this extension. from a non-conforming MTA.

2.8 Recommendations for Developers and Administrators

Developers that implement the No Default Solicitation Class

Implementations of "NO-SOLICITING" service extension SHOULD NOT
enable the service specific solicitation class keywords as a default. default in their
software. 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 and
using the software did not make an explicit

Malamud Expires July 24, 2004 [Page 11]

draft-malamud-no-soliciting No-Solicit January 2004 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" per-recipient filtering by default for a
user. Again, individual users should specifically request the service. any
additional solicitation class keywords.

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

3. Security Considerations

This extension does not provide support for either
"SYSTEM-WIDE" or "PER-RECIPIENT" or both.

Implementation authentication of SYSTEM-WIDE on a receiving MTA is fairly trivial.
For example, on the popular sendmail [1] package, a few minor changes
need to be made to three files senders or other
measures intended to provide the appropriate "EHLO"
announcement.

3. Use of promote security measures during the Extension

This proposal is message
exchange process.

In particular, this document does not meant to solve address 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.
The service extension allows circumstances under
which a mail recipient to notify the sender
that certain forms of electronic mail are should or should not desired use this
extension and thus gives
policy makers does not address the issues of whether consent to send
mail has been granted.

This might lead to a mechanism for requiring senders scenario in which a sender of such electronic mail
begins to identify their missives any penalties for failure use this extension well before the majority of end users
have begun to do so.
To illustrate how use it. In this scenario, the system sender might work in practice, a simple
hypothetical scenario is presented.

Our scenario posits that the U.S. federal government wants wish to do
something about spam, but is uncertain about use
the effectiveness absence 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 extension on the receiving MTA as an implication
of spam and tie a keyword to that definition. This
definition needs consent to published in a permanent record receive mail. Non-use of some sort
so that it can be referenced in the following steps. The "NO-SOLICITING" extension
by a receiving MTA SHALL NOT indicate consent.

Malamud Expires July 24, 30, 2004 [Page 12]

draft-malamud-no-soliciting No-Solicit January 2004

Congressional Record [2] or the Federal Register [3] would both
be considered adequate for

4. IANA Considerations

There are four IANA considerations presented in 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 draft:

1. Addition of the "NO-SOLICITING" notice and any penalties for
violation thereof. Let us suppose that the keyword service extension to be
registered is ""WMA".

2. The appropriate authority (e.g., the Clerk Mail
Parameters registry.

2. Documentation of the House [4] 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
[5]. use of comments in trace fields.

3. To the extent that a proliferation Creation 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 Solicitation Class Keywords registry.

4. Creation of
each address on their lists by connecting to the a "Solicitation:" mail header, which does not
currently raise any IANA considerations.

4.1 The Mail Parameters Registry

The IANA Mail Parameters registry documents 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 extensions.
The "NO-SOLICITATION" service extension matches the "WMA" keyword, the address would need to be
scrubbed from the list.

5. Reputable users added to
this registry as follows.

Keywords Description Reference
------------ ------------------------------ ---------
NO-SOLICITING Notification of email lists no soliciting. [XXXX]

The parameters subregistry would add a "Solicitation: WMA"
header need to their electronic mail and activate the same simple
check described in the previous step. Any addresses matching the
check be modified as follows:

Service Ext EHLO Keyword Parameters Reference
----------- ------------ ----------- ---------
No Soliciting NO-SOLICITING Solicitation-keywords [XXXX]

4.2 Trace Fields

The Mail Parameters registry would trigger non-delivery of the message and, presumably, need to be modified to note the scrubbing
use of that address from the list.

6. comment facility in trace fields to indicate Solicitation
Class Keywords.

4.3 The Solicitation Class Keywords Registry

A system manager, under the guidance new registry (or a subregistry of the Administrative
Contact Mail Parameters) would need to be
established for a domain, Solicitation Class Keywords. The registry would configure "MX" records in
contain the Domain following fields:

1. Solicitation Class Keyword Name System

2. Solicitation Class Keyword Description

Malamud Expires July 30, 2004 [Page 13]

draft-malamud-no-soliciting No-Solicit January 2004

3. Solicitation Class Keyword Reference

The Name field conforms to designate one or more systems authorized to
receive mail for the domain in question. For each system so
designated, syntax of the system manager might enable "NO-SOLICITING
SYSTEM-WIDE WMA". These systems receiving mail on behalf "Solicitation-keywords"
in Section 2.2 of this draft. The Description field consists of text.
The Reference field should include a URI with further information.

Per the
designated domain might also be configured policies outlined in [RFC2434], it is recommended that the
IESG request the IANA to run appoint a spam
identification utility, such as SpamAssasin [6] or SpamBouncer
[7].

7. End users would configure their mail filters Designated Expert to filter out any
properly tagged messages (e.g., "Solicitation: WMA") and any
messages 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 are not properly tagged (e.g., any non-RFC derived solicitation class keywords be
documented in SpamBouncer, the
user might set the "SPAMLEVEL" parameter future informational RFCs to "10", which would
filter all messages with provide a score consistent set
of 10 or greater using the
software's own algorithms references.

Policies for the detection administration of probable spam).

Malamud Expires July 24, 2004 [Page 13]

draft-malamud-no-soliciting No-Solicit January 2004

8. Unagressive end users would simply delete their spam folder
periodically. More paranoid end users would check this registry shall be developed
by the folder for
false positives IANA and then delete it. A few users might take more
agressive steps. For example, setting may include the SpamBouncer
"SPAMREPLY" to "COMPLAIN" will automatically dispatch complaints
to ISP abuse lines. If financial penalties for violation automated processing of WMA
tagging provisions exist and include registration
requests.

4.3.1 Guidance on Keyword Specification

A set of keywords beginning with a split between common prefix may be registered
with the federal
authorities and IANA by specifying the filer of prefix followed by wild card
specified as a complaint, an additional copy of
the offending mail can single asterisk ("*") and shall be dispatched to considered a service bureau whose
function is to aggregate large amounts single
registry entry. The "keyword reference" field 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
have prompted a variety of proposals for similar "do not spam" lists.
Such a list takes registry SHOULD
contain a centralized approach to solving reference that documents the same problem
addressed by values this service extension. The centralized approach has
the following potential pitfalls:

o From the point of view of solicitation class
keyword may contain if the consumer, a centralized list
operates in batch mode: there trailing wild card is a lag between asserting the
desire to start or stop receiving a certain type of mail and the
implementation of that assertion. In addition, placing an email
address on a centralized list has a significant risk that the list
will be used by some to send even more unwanted mail.

o From specified in the point of view
"keyword name" field of the government, a centralized list
requires significant resources registry.

Note to administer Developers: In designing client and maintain.
Because the list contains aggregated information, server solutions based
on this extension, it is more
valuable important to legally irresponsible mailers and thus adequate
security provisions need remember to be made for the list contents.

o The decentralized approach is cheaper for telemarketers design your code
to
implement. From the point of view of take into account the sender possible use of unsolicited
mail, these trailing wildcards.
See the bulk approach requires a significant data processing
investment "Solicitation-keywords" production in Section 2.2 for
valid characters and delimiters.

This facility can be used to continually "scrub" lists that are received. In
contrast, the decentralized approach requires insert a simple pattern
match on one address at "score" or category tag by an
intermediate MTA. For example, a time.

It should solicitation class keyword "WMA:*"
might be noted that used as follows:

Received: by foo-mta.example.com with
ESMTP (WMA:SBRule:Haven_Domain,WMA:SBScore:10) ; Sat, 9 Aug 2003
16:54:42 -0700 (PDT)

Because of the centralized and decentralized approaches
can coexist in some manner. A useful analogy is wildcard provision, the field of
copyright. Documents IANA MAY require that each
solicitation class keyword name 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 unique beginning sequence. For
example, registering sequences such as "ADV" and "ADV:ADLT" as
different names might require implementations to assert coypright is through differentiate
between classes that use a wildcard and those that do not.

Malamud Expires July 24, 30, 2004 [Page 14]

draft-malamud-no-soliciting No-Solicit January 2004

mark on the document itself,

4.4 The Solicitation Mail Header

There is currently no registry defined for mail headers. If such a decentralized approach
registry were 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 exist, the example of spam prevention, there "Solicitation:" header field would also need
to be an inherent
right, the right not added to received unsolicited commercial mail. it.

5. Author's Acknowledgements

The
courts or executive branch, as with copyright, author would assess fines
based on a variety of factors, like to thank Rebecca Malamud for many discussions
and the degree of notice could
certainly be such a factor. Adding an address ideas that led to a registry of
do-not-spam addresses, in conjunction with a real-time
"NO-SOLICITING" assertion this proposal and to John C. Klensin and
Marshall T. Rose for their extensive input on how it could both be factors taken into
consideration
properly implemented in levying fines or taking other corrective actions.

4. Security Considerations

This extension does not provide authentication SMTP. Eric Allman, Steven M. Bellovin, Kent
Crispin, Dave Crocker, Ned Freed, Curtis Generous, Arnt Gulbrandsen,
John Levine, Keith Moore, Hector Santos, Paul Vixie, and Pindar Wong
kindly provided reviews of senders or other
measures intended to promote security measures during the message
exchange process.

In particular, this document does not address draft and/or suggestions for
improvement. Information about soliciting outside the circumstances under
which a sender of electronic mail should or should not use this
extension U.S. was
received from Rob Blokzijl, Jon Crowcroft, Christian Huitema, Geoff
Huston, and does not address the issues of whether consent to send
mail has been granted.

This might lead to a scenario in which a sender of electronic mail
begins to use this extension well before Pindar Wong. John Levine pointed out the majority of end users
have begun to use it. In contrast
between this scenario, the sender might wish to use proposal and "do not spam" lists. As always, all errors
and omissions are the absence responsibility of the extension on the receiving MTA as an implication
of consent author.

Informative References

[Assassin]
Mason, J., "Spamassassin - Mail Filter to receive mail. Non-use Identify Spam
Using Text Analysis", Version 2.55, May 2003, <http://
www.mirror.ac.uk/sites/spamassassin.taint.org/
spamassassin.org/doc/spamassassin.html>.

[CNET] CNET News.Com, "AOL touts spam-fighting prowess", April
2003, <http://news.com.com/2100-1025-998944.html>.

[Cantwell]
U.S. Supreme Court, "Cantwell v. State of the "NO-SOLICITING" extension
by a receiving MTA SHALL NOT indicate consent.

5. IANA Connecticut",
310 U.S. 296 (1940), May 1940, <http://
caselaw.lp.findlaw.com/scripts/
getcase.pl?court=US&amp;vol=310&amp;invol=296>.

[FTC] 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>.

[FTC.TSR] Federal Trade Commission, "Telemarketing Sales Rule",
Federal Register Vol. 68, No. 19, January 2003, <http://
www.ftc.gov/os/2002/12/tsrfinalrule.pdf>.

[Ferris] Associated Press, "Study: Spam costs businesses $13

Malamud Expires July 30, 2004 [Page 15]

draft-malamud-no-soliciting No-Solicit January 2004

billion", January 2003, <http://www.cnn.com/2003/TECH/
biztech/01/03/spam.costs.ap/index.html>.

[Habeas] Habeas, Inc., "Habeas Compliant Message", April 2003,
<http://www.habeas.com/services/hcm.htm>.

[I-D.crocker-spam-techconsider]
Crocker, D., "Technical Considerations

There are four IANA considerations presented for Spam Control
Mechanisms", draft-crocker-spam-techconsider-02 (work in this draft:

1. Addition of the "NO-SOLICITING" service extension to the
progress), May 2003.

[I-D.crouzet-amtp]
Crouzet, B., "Authenticated Mail
Parameters registry.

2. Documentation of the use of comments Transfer Protocol",
draft-crouzet-amtp-01 (work in trace fields.

3. Creation of a Solicitation Class progress), October 2003.

[I-D.daboo-sieve-spamtest]
Daboo, C., "SIEVE Spamtest and Virustest Extensions",
draft-daboo-sieve-spamtest-04 (work in progress), October
2003.

[I-D.danisch-dns-rr-smtp]
Danisch, H., "A DNS RR for simple SMTP sender
authentication", draft-danisch-dns-rr-smtp-03 (work in
progress), October 2003.

[Levine] Levine, J. and P. Hoffman, "Anti-UBE and Anti-UCE Keywords registry.

4. Creation
in SMTP Banners", Revision 1.1, March 1999, <http://
www.cauce.org/proposal/smtp-banner-rfc.shtml>.

[Malamud] Malamud, C., "An Internet Prayer Wheel", Mappa.Mundi
Magazine, August 1999, <http://mappa.mundi.net/
cartography/Wheel/>.

[Martin] U.S. Supreme Court, "Martin v. City of a "Solicitation:" mail header, which does not
currently raise any IANA considerations. Struthers, Ohio",
319 U.S. 141 (1943), May 1943, <http://
caselaw.lp.findlaw.com/scripts/
getcase.pl?court=US&amp;vol=319&amp;invol=141>.

[Newbury] 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>.

[Perry] 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&amp;vol=460&amp;invol=37>.

Malamud Expires July 24, 30, 2004 [Page 15] 16]

draft-malamud-no-soliciting No-Solicit January 2004

5.1 The Mail Parameters Registry

The IANA Mail Parameters registry documents

[RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP service extensions.
The "NO-SOLICITATION" service extension would need to be added to
this registry as follows.

Keywords Description Reference
------------ ------------------------------ ---------
NO-SOLICITING Notification MTAs",
BCP 30, RFC 2505, February 1999.

[ROKSO] Spamhaus.Org, "Register of no soliciting. [<this draft>]

The parameters subregistry would need Known Spam Operations",
November 2003, <http://www.spamhaus.org/rokso/
index.lasso>.

[Schumer] Charles, C., "Schumer, Christian Coalition Team Up 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 Trace Fields

The Mail Parameters registry would need to be modified to note the
use
Crack Down on Email Spam Pornography", June 2003, <http://
www.senate.gov/~schumer/SchumerWebsite/pressroom/
press_releases/PR01782.html>.

[Watchtower]
U.S. Supreme Court, "Watchtower Bible & Tract Society of the comment facility in trace fields to indicate Solicitation
Class Keywords.

5.3 The Solicitation Class Keywords Registry

A new registry (or a subregistry
New York, Inc., et al. v. Village 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").

3. Keyword reference (e.g., "<this draft>").

Per the policies outlined in [RFC2434], it is recommended that the
IESG request the IANA to appoint a Designated Expert to administer
this registry. Authority Stratton et al.", 122
S.Ct. 2080 (2002), June 2002, <http://
caselaw.lp.findlaw.com/scripts/
getcase.pl?court=US&amp;vol=000&amp;invol=00-1737>.

Normative References

[RFC2119] Bradner, S., "Key words 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 use in future informational RFCs to provide a consistent set
of references.

5.3.1 Guidance on Keyword Specification

A set of keywords beginning with a common prefix may be registered

Malamud Expires July 24, 2004 [Page 16]

draft-malamud-no-soliciting No-Solicit January 2004

with the IANA by specifying the prefix followed by wild card
specified as a single asterisk ("*") Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2234] Crocker, D. and shall be considered a single
registry entry. The "keyword reference" field of the registry SHOULD
contain a reference that documents the values this solicitation class
keyword may contain if the trailing wild card is specified in the
"keyword name" field of the registry.

Note to Developers: In designing client and server solutions based
on this extension, it is important to remember to design your code
to take into account the possible use of these trailing wildcards.
See the "Solicitation-keywords" production in Section 2.2 for
valid characters and delimiters.

This facility can be used to insert a "score" or category tag by an
intermediate MTA. For example, a solicitation class keyword "WMA:*"
might be used as follows:

Received: by foo-mta.example.com with
ESMTP (WMA:SBRule:Haven_Domain,WMA:SBScore:10) ; Sat, 9 Aug 2003
16:54:42 -0700 (PDT)

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.

6. Author's Acknowledgements

The author would like to thank Rebecca Malamud P. Overell, "Augmented BNF for many discussions
and ideas that led to this proposal and to John C. Klensin and
Marshall Syntax
Specifications: ABNF", RFC 2234, November 1997.

[RFC2434] Narten, T. Rose for their extensive input on how it could be
properly implemented in SMTP. Eric Allman, Steven M. Bellovin, Kent
Crispin, Dave Crocker, Curtis Generous, Paul Hoffman, John Levine,
Keith Moore, Ned Freed, Paul Vixie, and Pindar Wong kindly provided
reviews of the draft and/or suggestions H. Alvestrand, "Guidelines 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 and omissions are the
responsibility of the author.

Informative References

[Assassin]
Mason, Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.

[RFC2821] Klensin, J., "Spamassassin - "Simple Mail Filter to Identify Spam
Using Text Analysis", Version 2.55, May 2003, <http:// Transfer Protocol", RFC 2821,
April 2001.

[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.

[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
3463, January 2003.

URIs

[1] <mailto:carl@media.org>

[2] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-04.html>

[3] <http://trusted.resource.org/no-solicit/

Malamud Expires July 24, 30, 2004 [Page 17]

draft-malamud-no-soliciting No-Solicit January 2004

www.mirror.ac.uk/sites/spamassassin.taint.org/
spamassassin.org/doc/spamassassin.html>.

[CNET] CNET News.Com, "AOL touts spam-fighting prowess", April
2003, <http://news.com.com/2100-1025-998944.html>.

[Cantwell]
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&amp;vol=310&amp;invol=296>.

[FTC] 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>.

[FTC.TSR] Federal Trade Commission, "Telemarketing Sales Rule",
Federal Register Vol. 68, No. 19, January 2003, <http://
www.ftc.gov/os/2002/12/tsrfinalrule.pdf>.

[Ferris] Associated Press, "Study: Spam costs businesses $13
billion",

draft-malamud-no-soliciting-05.html>

[4] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-03.html>

[5] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-04.html>

[6] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-02.html>

[7] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-03.html>

[8] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-01.html>

[9] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-02.html>

[10] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-00.html>

[11] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-01.html>

Author's Address

Carl Malamud
Memory Palace Press
PO Box 300
Sixes, OR 97476
US

EMail: carl@media.org

Malamud Expires July 30, 2004 [Page 18]

draft-malamud-no-soliciting No-Solicit January 2003, <http://www.cnn.com/2003/TECH/
biztech/01/03/spam.costs.ap/index.html>.

[Habeas] Habeas, Inc., "Habeas Compliant Message", April 2003,
<http://www.habeas.com/services/hcm.htm>.

[I-D.crocker-spam-techconsider]
Crocker, D., "Technical Considerations for Spam Control
Mechanisms", draft-crocker-spam-techconsider-02 (work in
progress), May 2003.

[I-D.crouzet-amtp]
Crouzet, B., "Authenticated Mail Transfer Protocol",
draft-crouzet-amtp-01 (work in progress), October 2003.

[I-D.daboo-sieve-spamtest]
Daboo, C., "SIEVE Spamtest and Virustest Extensions",
draft-daboo-sieve-spamtest-04 (work in progress), October
2003.

[I-D.danisch-dns-rr-smtp]
Danisch, H., "A DNS RR for simple SMTP sender
authentication", draft-danisch-dns-rr-smtp-03 (work 2004

Appendix A. Collected ABNF Descriptions (Normative)

Solicitation-keywords = registered-word 0*("," registered-word)
registered-word = ALPHA 0*(wordchar)
; registered-word(s) are registered
; with the IANA
wordchar = ("-" / "_" / ":" / ALPHA / DIGIT)

; used in
progress), October 2003.

[Levine] Levine, J. the initial EHLO exchange
No-Soliciting-Service = "NO-SOLICITING"
[ SP Solicitation-keywords ]

; used on the Solicitation: message header
Solicitation-header = "Solicitation:" 1*SP Solicitation-keywords

; used on the MAIL FROM command and P. Hoffman, "Anti-UBE replies,
; and Anti-UCE Keywords

Malamud Expires July 24, 2004 [Page 18]

draft-malamud-no-soliciting No-Solicit January 2004 on Received: headers.
Mail-From-Solicit-Parameter =
"SOLICIT" "=" Solicitation-keywords
; Solicitation-keywords, when used in SMTP Banners", Revision 1.1, March 1999, <http://
www.cauce.org/proposal/smtp-banner-rfc.shtml>.

[Malamud] Malamud, C., "An Internet Prayer Wheel", Mappa.Mundi
Magazine, August 1999, <http://mappa.mundi.net/
cartography/Wheel/>.

[Martin] 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&amp;vol=319&amp;invol=141>.

[RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs",
BCP 30, RFC 2505, February 1999.

[ROSKO] Spamhaus.Org, "Register of Known Spam Operations",
November 2003, <http://www.spamhaus.org/rokso/
index.lasso>.

[Schumer] Charles, C., "Schumer, Christian Coalition Team Up
; the MAIL FROM command MUST be identical
; to
Crack Down those in the Solicitation: header.

; Used on Email Spam Pornography", June 2003, <http://
www.senate.gov/~schumer/SchumerWebsite/pressroom/
press_releases/PR01782.html>.

[Watchtower]
U.S. Supreme Court, "Watchtower Bible & Tract Society of
New York, Inc., et al. v. Village Received: headers
With-Solicit = "WITH" FWS Protocol
"(" [FWS] comment [FWS] ")"
; From RFC 2822
comment = "(" *([FWS] ccontent) [FWS] ")"
ccontent = ctext / quoted-pair /
comment / Mail-From-Solicit-Parameter
; The Mail-From-Solicit-Parameter
; is a restricted form of Stratton et al.", 122
S.Ct. 2080 (2002), June 2002, <http://
caselaw.lp.findlaw.com/scripts/
getcase.pl?court=US&amp;vol=000&amp;invol=00-1737>.

Normative References

[RFC2119] Bradner, S., "Key words ctext
; From RFC 2821
With = "WITH" FWS Protocol CFWS
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
Attdl-Protocol = Atom

Appendix B. Example Solicitation Class Keywords (Non-Normative)

Three solicitation class keywords are defined for use as examples in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
this draft:

Malamud Expires July 24, 30, 2004 [Page 19]

draft-malamud-no-soliciting No-Solicit January 2004

[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.

[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.

[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.

[RFC3463] Vaudreuil, G., "Enhanced

MAPS-UBE is the standard advanced by the Mail Abuse Prevention System Status Codes", RFC
3463, January 2003.

URIs

[1] <http://www.sendmail.org/>

[2] <http://thomas.loc.gov/>

[3] <http://www.gpoaccess.gov/fr/>

[4] <http://clerk.house.gov/index.php>

[5] <mailto:iana@iana.org>

[6] <http://spamassassin.org/index.html>

[7] <http://www.spambouncer.org/>

[8] <mailto:carl@media.org>

[9] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-03.html>

[10] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-04.html>

[11] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-02.html>

[12] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-03.html>

[13] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-01.html>

[14] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-02.html>

Malamud Expires July 24, 2004 [Page 20]

draft-malamud-no-soliciting No-Solicit January 2004

[15] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-00.html>

[16] <http://trusted.resource.org/no-solicit/
draft-malamud-no-soliciting-01.html>

Author's Address

Carl Malamud
Memory Palace Press
PO Box 300
Sixes, OR 97476
US

EMail: carl@media.org
(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.

These three examples should not form part of the initial registry.
This section is non-normative and is not part of the definition of
the extension.

Appendix A. C. Status of This Document [To Be Removed Upon Publication]

A.1

C.1 RFC Category

This document will be submitted for publication as a Proposed
Standard.

A.2

C.2 Document Repository

The source for this document can be found at http://
trusted.resource.org/no-solicit.

A.3

C.3 Discussion

Discussions of this draft may be directed towards the ietf-smtp
mailing list which can be found at http://www.imc.org/ietf-smtp/.
Comments may be sent directly to the author at carl@media.org [8].

A.4 [1].

C.4 Changes From Previous Drafts

Changes from draft-malamud-no-soliciting-04 [2] to
draft-malamud-no-soliciting-05 [3]:

o This draft incorporates comments received in response to the IESG
last call.

o A discussion of what this proposal is not trying to accomplish was
added the end of Section 1.3.

Malamud Expires July 30, 2004 [Page 20]

draft-malamud-no-soliciting No-Solicit January 2004

o The definition of solicitation class keywords has been changed.
"X-" words are no longer permitted. See Section 2.2.

o The solicitation class keywords previously defined in Section 2.2
have been moved to a non-normative appendix in Appendix B.

o The SYSTEM-WIDE and PER-RECIPIENT options have been eliminated.
Solicitation class keywords presented in the initial EHLO exchange
are in effect system-wide and additional keywords may be presented
on a per-recipient basis. See Section 2.

o Text has been added throughout the document to make clear that the
decision to reject a message is only taken by a recipient and that
the particular decision to take is outside the scope of this
draft.

o Section 3 ("Use of the Extension") of the previous draft has been
deleted. The material was non-normative.

Changes from draft-malamud-no-soliciting-03 [9] [4] to
draft-malamud-no-soliciting-04 [10]: [5]:

o The Note on Open Issues has been removed and the abstract has been
made more precise.

o All examples now use subdomains of example.com.

o The "No-Soliciting-Service" production has been changed to make
clear that a set of keywords is not presented when the
"PER-RECIPIENT" option is used. See Section 2.

Malamud Expires July 24, 2004 [Page 21]

draft-malamud-no-soliciting No-Solicit January 2004

o A Note on Keywords has been added to make clear that the initial
three keywords choosen were simply to bootstrap the registry and
that the matter of which keywords to use and the definition of
those words is a policy decision well outside the scope of this
document. See Section 2.2.1.

o Solicitation Class Keywords are now carried as a comment to the
"ESMTP" protocol and additional language has been added clarifying
the relationship of keywords in "received:" headers to those in
the "Solicitation:" header. See Section 2.6.

o Some language has been added to further clarify what should happen
when dealing with a server that doesn't support the extension. See
Section 2.7.

o The Security Considerations section has been made more explicit.
See Section 4. 3.

Malamud Expires July 30, 2004 [Page 21]

draft-malamud-no-soliciting No-Solicit January 2004

o The Solicitation Class Keywords Registry has been clarified to
permit the use of a trailing wildcard in the "keyword name" field.
See Section 5.3. 4.3.

Changes from draft-malamud-no-soliciting-02 [11] [6] to
draft-malamud-no-soliciting-03 [12]: [7]:

o A discussion of Open Issues has been preprended to the document
and comments are requested.

Changes from draft-malamud-no-soliciting-01 [13] [8] to
draft-malamud-no-soliciting-02 [14]: [9]:

o A real-world example of how the proposed service extension could
be used has been added (see Section 3). 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
"do not spam" lists has been added (see Section 3.1). added.

Changes from draft-malamud-no-soliciting-00 [15] [10] to
draft-malamud-no-soliciting-01 [16]: [11]:

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).

Malamud Expires July 24, 2004 [Page 22]

draft-malamud-no-soliciting No-Solicit January 2004

o "PER-MESSAGE" has been changed to "PER-RECIPIENT" to more properly
express the operation of the extension (see Section 2.3). 3.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). 4).

Malamud Expires July 24, 30, 2004 [Page 23] 22]

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

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 24, 30, 2004 [Page 24] 23]

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 24, 30, 2004 [Page 25] 24]

----