view Side-By-Side changes
Network Working Group C. Malamud Internet-DraftOctober 10, 2003Memory Palace Press Expires:April 9,May 29, 2004 November 29, 2003 A"No Soliciting"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 onApril 9,May 29, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Thisnote presentsInternet-Draft proposes an extension to SMTP for an electronic mail equivalent to the real-world "NoSoliciting Sign." By itself, thisSoliciting" sign. The service extensiondoes little to stop unsolicited bulk electronic mail. However,is described, followed by an example of how the extensiongives policy makers in the real world a "hook" on which to pass anti-spam laws.might be used. 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].Changes From Previous DraftMalamud ExpiresApril 9,May 29, 2004 [Page 1] draft-malamud-no-soliciting No-SolicitOctober 2003 Changes from draft-malamud-no-soliciting-00 to draft-malamud-no-soliciting-01: 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 3. o "PER-MESSAGE" has been changed to "PER-RECIPIENT" to more properly express the operation of the extension. Section 3.3. o A solicitation class keyword syntax is introduced to allow different kinds of unsolicited mail to be considered.Section 3.2 o The "Solicitation:" header has been supplemented with an extended "Received:" header syntax. See Section 3.5. o A discussion of the use of Enhanced Mail Status Codes has been included. See Section 3.7. o A more extensive IANA Considerations section has been added, including creation of a Solicitation Keywords registry. See Section 6. Malamud Expires April 9, 2004 [Page 2] draft-malamud-no-soliciting No-Solicit OctoberNovember 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 The Spam Pandemic . . . . . . . . . . . . . . . . . . . . . .4 2.3 1.2 No Soliciting in the Real World . . . . . . . . . . . . . . .6 3.3 1.3 A Distributed No Soliciting Extension . . . . . . . . . . . . 5 2. The No-Soliciting SMTP Service Extension . . . . . . . . . . .8 3.17 2.1 The SYSTEM-WIDE Option . . . . . . . . . . . . . . . . . . . . 7 2.2 Solicitation Class Keywords . . . . .8 3.2 Solicitation Class Keywords. . . . . . . . . . . . 7 2.3 The PER-RECIPIENT Option . . . . . . . .8 3.3 PER-RECIPIENT. . . . . . . . . . . 8 2.4 Use of Enhanced Mail Status Codes . . . . . . . . . . . . . . 93.42.5 Solicitation Mail Header . . . . . . . . . . . . . . . . . . .10 3.59 2.6 Insertion of Solicitation Keywords in Trace Fields . . . . . .11 3.610 2.7 Relay of Messages . . . . . . . . . . . . . . . . . . . . . .12 3.7 Use of Enhanced Mail Status Codes11 2.8 Recommendations for Developers and Administrators . . . . . . 12 3. Use of the Extension . . . . . . . . . . . . . . .12 3.8 Recommendations for Developers and Administrators. . . . . . 134. Hooks for ISPs and Other Policy Makers3.1 Relationship to Centralized Approaches . . . . . . . . . . . . 145.4. Security Considerations . . . . . . . . . . . . . . . . . . .15 6.17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . .16 6.118 5.1 The Mail Parameters Registry . . . . . . . . . . . . . . . . .16 6.218 5.2 ESMTP-Solicitation Additional Protocol . . . . . . . . . . . .16 6.318 5.3 The Solicitation Class Keywords Registry . . . . . . . . . . .16 6.418 5.4 The Solicitation Mail Header . . . . . . . . . . . . . . . . .17 7.19 6. Author's Acknowledgements . . . . . . . . . . . . . . . . . .1820 Informative References . . . . . . . . . . . . . . . . . . . .1921 Normative References . . . . . . . . . . . . . . . . . . . . .2123 Author's Address . . . . . . . . . . . . . . . . . . . . . . .2124 A. Status of This Document . . . . . . . . . . . . . . . . . . . 25 A.1 RFC Category . . . . . . . . . . . . . . . . . . . . . . . . . 25 A.2 Document Repository . . . . . . . . . . . . . . . . . . . . . 25 A.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 25 A.4 Changes From Previous Drafts . . . . . . . . . . . . . . . . . 25 B. Transmittal . . . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . .2229 Malamud ExpiresApril 9,May 29, 2004 [Page3]2] draft-malamud-no-soliciting No-SolicitOctoberNovember 2003 1. Introduction 1.1 The Spam Pandemic UnsolicitedUnwantedBulk Email(UUE),(UBE), otherwise known as spam, has become as one of the most pressing issues on the Internet. One oft-quoted study estimated that spam will cost businesses $13 billion in 2003.[1] In April 2003, AOL reported that it had blocked 2.37 billion pieces ofUUEUBE in a single day. [2] And, in a sure sign thatUUEUBE has become of pressing concern, numerous politicians have begun to issue pronouncements and prescriptions for fighting thisepidemic.[3] [4]epidemic.[3][4] A variety of mechanisms from the technical community have been proposed and/or implemented to fightUUE: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 ofUUEUBE [8], operational considerations for SMTP agents[9], and various extensions to the protocols to supportUUEUBE identification and filtering.[10] [11] [12][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]Many of these proposals and services have great merit, however none of them give notice to an SMTP agent1.2 No Soliciting in theprocess of delivering mail that the receiver does not wishReal World Municipalities frequently require solicitors toreceive 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, Malamud Expires April 9, 2004 [Page 4] draft-malamud-no-soliciting No-Solicit October 2003 disk space, and processing power. Malamud Expires April 9, 2004 [Page 5] draft-malamud-no-soliciting No-Solicit October 2003 2. No Soliciting in the Real World Municipalities frequently require solicitors to register withregister 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 May 29, 2004 [Page 3] draft-malamud-no-soliciting No-Solicit November 2003 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 forreasonableness.[16]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 ofMalamud Expires April 9, 2004 [Page 6] draft-malamud-no-soliciting No-Solicit October 2003Struthers, the court noted thatburglars"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]Note that theThe public safety issue applies very much to email, where virusesandcan 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 ofUUEUBE appears to originate from U.S. Malamud Expires May 29, 2004 [Page 4] draft-malamud-no-soliciting No-Solicit November 2003 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.Malamud Expires April 9, 2004 [Page 7] draft-malamud-no-soliciting No-Solicit October 2003 3. The No-Soliciting SMTP Service1.3 A Distributed No Soliciting ExtensionPer RFC 2821,[22] a "NO-SOLICITING" SMTP service extension is defined. The service extension is presented duringMany of theinitial "EHLO"anti-spam proposals that have been advanced have great merit, however none of them give notice to an SMTPexchange. The extension has one optional parameter and zero or more solicitation class keywords. Using the notation as describedagent in theAugmented BNF[23], the syntax is: No-Soliciting-Service = "NO-SOLICITING" [ "SYSTEM-WIDE" / "PER-RECIPIENT" ] 0*( Solicitation-keywords ) 3.1 SYSTEM-WIDE "NO-SOLICITING SYSTEM-WIDE" indicatesprocess of delivering mail thatno soliciting is in effect for all messages delivered to this system. It is equivalent tothe receiver does not wish to receive solicitations. Such a virtual signonwould serve two purposes: o It would allow thedoorreceiving system to "serve notice" that a certain class ofan office building announcingelectronic mail is not desired, whether or not such acompany-wide policy. The parametermessage ispresented 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 A similar proposal was advanced in 1999 by John Levine and Paul Hoffman. This proposal used the SMTP greeting bannerproperly identified as belonging tospecifythatunsolicited bulk emailclass. o If a message isprohibited onproperly identified as belonging to aparticular system through the usecertain class and that class of messages is not desired, transfer of the"NO UCB" keyword.[19] As the authors note, their proposal has the potentialmessage can be eliminated. Rather than filtering after delivery, elimination ofoverloadingthesemanticsmessage transfer can save network bandwidth, disk space, and processing power. This memo details a series of extensions to SMTP that have thegreeting banner, which may also be used for other purposes (see, e.g., [20]). 3.2 Solicitation Class Keywords The "NO-SOLICITING"following characteristics: o A service extensionmay accept additional solicitation class keywordsis described thatsignifyallows aspecific class of solicitationsreceiving MTA to signal the sending MTA thatare not accepted. Keywords are separated by commas and followno soliciting is in effect. o A header field for the"SYSTEM-WIDE" parameter. Two classes aresender of the message is definedin this draft: Keywords Description Referencethat allows the sender to flag a message as conforming to a certain Malamud ExpiresApril 9,May 29, 2004 [Page8]5] draft-malamud-no-soliciting No-SolicitOctoberNovember 2003--------- -------------------------------- --------- 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 contextclass. o Trace fields for intermediate MTAs areirrelevant because the message is equally applicableextended tomany other potential recipients; AND (2)allow therecipient has not verifiably granted deliberate, explicit, and still-revocable permission for itintermediate MTA tobe sent; AND (3) the transmission and reception of thesignal that a messageappearsconforms to a certain class. Allowing therecipientsender of a message togivetag adisproportionate benefitmessage 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, thesender. Numerous states have adoptedintermediate trace fields defined here allow the"ADV" and "ADV:ADLT" conventions. We citedestination MTA or a designated intermediate MTA to perform appropriate dispositions on thespamlaws.com sitereceived message. This distributed approach to controlling UBE is advanced asa reference because it providesanexcellent summaryalternative to centralized "do-not-spam" lists. The concluding section of this document details how thedefinitionsdecentralized approach would work in practice andpointerscontrasts this approach tothe relevant statutes. Therea centralized list. Malamud Expires May 29, 2004 [Page 6] draft-malamud-no-soliciting No-Solicit November 2003 2. The No-Soliciting SMTP Service Extension Per RFC 2821,[22] a "NO-SOLICITING" SMTP service extension isno default keyword for the service. In other words, the following exampledefined. The service extension isa "no-op": R: 250-NO-SOLICITING SYSTEM-WIDE Additionaldeclared during the initial "EHLO" SMTP exchange. The extension has one optional parameter and zero or more solicitation classkeywords may be defined and registered inkeywords. Using theregistrynotation asspecifieddescribed inSection 6. Multiple solicitation class keywords are separated by a comma to form a list: Solicitation-keywords = 1Solicit-word 0*("," 1Solicit-word) Solicit-wordthe Augmented BNF[23], the syntax is: No-Soliciting-Service = "NO-SOLICITING" ["MAPS-UBE" / "ADV" / "ADV:ADLT" / x-word"SYSTEM-WIDE" /registered-word"PER-RECIPIENT" ]x-word = ["x-" / "X-"] 1*(wordchars) registered-word = ALPHA 0*(wordchars) ; registered-word(s) are registered ; with the IANA wordchars = 1*("-" / "_" / ":" / ALPHA / DIGIT) 3.3 PER-RECIPIENT0*( Solicitation-keywords ) 2.1 The SYSTEM-WIDE Option "NO-SOLICITINGPER-RECIPIENT" extension specifiesSYSTEM-WIDE" indicates thateach "MAIL FROM" command must identify if a messageno 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 asolicitation.company-wide policy. Thepresence of this extensionparameter isidentifiedpresented during the initialgreeting: Malamud Expires April 9, 2004 [Page 9] draft-malamud-no-soliciting No-Solicit October 2003exchange 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-SOLICITINGPER-RECIPIENT Additionally, "SOLICIT"SYSTEM-WIDE ADV (The "ADV" keyword isdefined as a parameter for the "MAIL FROM" command. The "SOLICIT" parameterone of several possible values and isfolloweddescribed in the following section.) A similar proposal was advanced in 1999 byan optional equal signJohn Levine and Paul Hoffman. This proposal used the SMTP greeting banner to specify that unsolicited bulk email is prohibited on acomma separated listparticular system through the use ofsolicitation class keywords. The syntax for this parameter is: Mail-From-Solicit-Parameter = "SOLICIT" 1( "=" Solicitation-keywords)the "NO UCE" keyword.[19] Asan informational message,the550 or 250 replies toauthors note, their proposal has the"RCPT TO" commandpotential of overloading the semantics of the greeting banner, which may alsocontain the "SOLICIT" parameter.be used for other purposes (see, e.g., [20]). 2.2 Solicitation Class Keywords Thereceiving system"NO-SOLICITING" service extension maydecide 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:ADLT 3.4 Solicitation Mail Header Per RFC 2822,[24] a new "Solicitation:" header field is defined which contains one or moreuse solicitation classkeywords. 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 ofkeywordsin 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 inthat signify agreeting banner, this would overload the semanticsspecific class ofthe "Subject:" header. Of course, there is no reason why both mechanisms can't be used,solicitations that are not accepted. Keywords are separated by commas andin any case the "Solicitation:" header could be automatically inserted based on the contents offollow thesubject line."SYSTEM-WIDE" parameter. Malamud ExpiresApril 9,May 29, 2004 [Page10]7] draft-malamud-no-soliciting No-SolicitOctoberNovember 20033.5 Insertion of Solicitation KeywordsThree classes are defined inTrace Fields The "Solicitation:" mail headerthis 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 isonly available tothesending client. RFCs 2821standard advanced by the Mail Abuse Prevention System (MAPS), which states: An electronic message is "spam" IF: (1) the recipient's personal identity and2822context arequite specific that intermediate MTAs shall not changeirrelevant because the messageheaders, withis equally applicable to many other potential recipients; AND (2) thesole exceptionrecipient has not verifiably granted deliberate, explicit, and still-revocable permission for it to be sent; AND (3) the transmission and reception of the"Received:" trace field. Since many current systems use an intermediate relaymessage appears todetect unsolicited mail, an additionthe recipient to give a disproportionate benefit to the"Received:" header is described. Assender. Numerous states have adopted the "ADV" and "ADV:ADLT" conventions. We cite the spamlaws.com site as areview, RFC 2821[22] documentsreference because it provides an excellent summary of thefollowing productionsdefinitions and pointers to the relevant statutes. There is no default keyword for the"Received:" header in a mail message: Time-stamp-line = "Received:" FWS Stamp <CRLF> Stamp = From-domain By-domain Opt-info ";" FWS date-time ; where "date-time"service. In other words, the following example isasa "no-op": R: 250-NO-SOLICITING SYSTEM-WIDE Additional solicitation class keywords may be defined and registered in[32] ; butthe"obs-" forms, especially two-digit ; years, are prohibitedregistry as specified inSMTP and MUST NOT be used. From-domain = "FROM" FWS Extended-Domain CFWS By-domainSection 5. Multiple solicitation class keywords are separated by a comma to form a list: Solicitation-keywords ="BY" FWS Extended-Domain CFWS Extended-Domain1Solicit-word 0*("," 1Solicit-word) Solicit-word =Domain[ "MAPS-UBE" /( Domain FWS "(" TCP-info ")" )"ADV" /( Address-literal FWS "(" TCP-info ")" ) TCP-info = Address-literal"ADV:ADLT" /( Domain FWS Address-literal ) ; Information derived by server from TCP connection ; not client EHLO. Opt-info = [Via] [With] [ID] [For] Withx-word / registered-word ] x-word ="WITH" FWS Protocol CFWS Addtl-Link["x-" / "X-"] 1*(wordchars) registered-word =AtomALPHA 0*(wordchars) ;Additional standard names for linksregistered-word(s) are registeredwith the;Internet Assigned Numbers Authority (IANA). "Via" is ; primarily of valuewithnon-Internet transports. SMTP ; servers SHOULD NOT use unregistered names. Protocolthe IANA wordchars ="ESMTP"1*("-" /"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.":" / ALPHA / DIGIT) 2.3 Theappropriate location for solicitation information is the "Attdl-Protocol" field, whichPER-RECIPIENT Option The "NO-SOLICITING PER-RECIPIENT" extension specifies that each "MAIL FROM" command must identify if a message isdefined in this document asa solicitation. Malamud ExpiresApril 9,May 29, 2004 [Page11]8] draft-malamud-no-soliciting No-SolicitOctoberNovember 2003"ESMTP-Solicitation".TheRFC 2821 productions are supplemented as follows: Protocol = "ESMTP" / "SMTP" / ESMTP-Solicitation / Attdl-Protocol ESMTP-Solicitation = "ESMTP-Solicitation" FWS 0*( Solicitation-keywords ) An examplepresence ofa Received: header from a conforming MTAthis 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 asfollows: Received:a parameter for the "MAIL FROM" command. The "SOLICIT" parameter is followed byfoo-mta.example.com with ESMTP-Solicitation ADV,ADV:ADLT ; Sat, 9 Aug 2003 16:54:42 -0700 (PDT) 3.6 Relayan optional equal sign and a comma separated list ofMessagessolicitation class keywords. 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"syntax for this parameterwas set onis: Mail-From-Solicit-Parameter = "SOLICIT" 1( "=" Solicitation-keywords) As an informational message, the"MAIL FROM" command,"550" or "250" replies to theMTA MUST"RCPT TO" command may alsosetcontain the "SOLICIT"parameter when delivering the message to an SMTP server that supports this extension.parameter. The"SOLICIT" parameterreceiving system may decide 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 detailed in Section 7.7 of RFC 2821[22], set this parameter after detectingper-user basis thepresenceappropriate 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"Solicitation:" or extended "Received:" message header field or by using other system-specific techniques. Implementers should be aware thatprevious example, the"NO-SOLICITING" service extension is notreceiving MTA returned aguaranteed end-to-end service. Specifically, intermediate relays"550" status code, indicating thatdo not support this service may "lose" the per-message parameters. However, any trace fields inserted duringthe messagetransfer process will persist. 3.7was 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.6.0". This error message is"5.7.1", defined asbeing of class permanent failure because it "is"the sender is notlikelyauthorized tobe resolved by resending the message in Malamud Expires April 9, 2004 [Page 12] draft-malamud-no-soliciting No-Solicit October 2003 the current form. Some changesend to themessage or thedestinationmust be made for successful delivery." It... [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 May 29, 2004 [Page 9] draft-malamud-no-soliciting No-Solicit November 2003 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 assubject/detail 6.0 sincemail transfer agents. As with embedding a "no solicitation" message in a greeting banner, this would overload thepolicy decisionsemantics of the "Subject:" header. Of course, there isbased on message contentno reason why both mechanisms can't be used, andthere are not any detail fields that clearly fit this "error"indelivery. Ifany case the"NO-SOLICITING" service extension is adopted, it is recommended that a new detail code"Solicitation:" header could beadded toautomatically inserted based on the contents of the subject6 (i.e., "X.6.6 Message Not Accepted For Delivery"). 3.8 Recommendations for Developers and Administratorsline. Itis strongly recommended that any developersshould be noted thatimplementthe"NO-SOLICITING"presence of both a "Solicitation:" header and a "SOLICIT" service extensionSHOULD NOT enableleads 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 asa default. Theredefined 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 aresome indicationsquite specific thatsome policy makers may view a default filtering in software as a prior restraint on commercial speech. In other words, becauseintermediate MTAs shall not change message headers, with theperson installingsole exception of thesoftware did not make"Received:" trace field. Since many current systems use anexplicit choiceintermediate relay toenable a certain type of filtering, some might argue that such filtering was not desired. Likewise, itdetect unsolicited mail, an addition to the "Received:" header isrecommended that a system administrator installing software SHOULD NOT enable "PER-RECIPIENT" filtering by default fordescribed. As auser. Again, individual users should requestreview, RFC 2821[22] documents theservice. The mechanismfollowing productions foran individual user to communicate their desire to enable certain types of filtering is outsidethescope of this document."Received:" header in a mail message: Malamud ExpiresApril 9,May 29, 2004 [Page13]10] draft-malamud-no-soliciting No-SolicitOctoberNovember 20034. Hooks for ISPs and Other Policy Makers This proposalTime-stamp-line = "Received:" FWS Stamp <CRLF> Stamp = From-domain By-domain Opt-info ";" FWS date-time ; where "date-time" isnot meant to "solve" the UUE problem,as defined in [32] ; butoffers some tools that can be used by policy makers, be they governments defining laws or Internet Service Providers defining appropriate use policies. 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. One common criticism of any technical or legal measures to prevent UUE is that the global reach oftheInternet makes any such measures futile. Several points are worth noting: 1. First, anti-UUE complaints"obs-" forms, especially two-digit ; years, areoften pursued through the Appropriate Use Policy (AUP)prohibited ina service agreement between an Internet Service ProviderSMTP andan end user is accused of violatingMUST 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 ; theISP's AUP. AssumingInternet Assigned Numbers Authority (IANA). SMTP servers ; SHOULD NOT use unregistered names. The appropriate location for solicitation information is theAppropriate Use Policy"Attdl-Protocol" field, which ispart of a valid contract, conflicts of law do not existdefined in thiscase. 2. Disparity between lawsdocument 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 ofdifferent jurisdictionsa Received: header from a conforming MTA isan age-old problem and many mechanisms have evolved to solve these issues. In the United States, conflicts of state laws are dealtas follows: Received: by foo-mta.example.com withthrough the courts and a well-established body of law. 3. On an international level, conflictsESMTP-Solicitation ADV,ADV:ADLT ; Sat, 9 Aug 2003 16:54:42 -0700 (PDT) 2.7 Relay oflaw are dealt with through international agreements, particularly trade agreements. Thus,Messages The "NO-SOLICITING SYSTEM-WIDE" service extension, if present, applies to all messages handled by theU.S. believes that UUE isreceiving Message Transfer Agent (MTA), including those messages intended to be relayed to another system. When relaying apressing policy issue, it will bringmessage which was received via theissue into a forum such asSMTP protocol in which theWorld Trade Organization, trading off a stronger agreement on spam for a more liberal policy, for example,"SOLICIT" parameter was set on theimport of packaged meat products. 4. Anectodal evidence suggests that much if not most UUE originates from U.S. citizens. A policy "hook" in"MAIL FROM" command, theSMTP architecture will prove highly effective at a national level if not universally effective on a global level. In summary, no one proposal will solve all issues with unsolicited unwanted email, but adding a mechanism atMTA *MUST* also set the "SOLICIT" parameter when delivering the message to an SMTPservice level provides one more tool inserver thatfight.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 ExpiresApril 9,May 29, 2004 [Page14]11] draft-malamud-no-soliciting No-SolicitOctoberNovember 20035. Security Considerations This proposal does not present additional security complications beyond those already amply represented in the current architectureconforming SMTP server. An SMTP server *MAY*, forelectronic mail. Malamud Expires April 9, 2004 [Page 15] draft-malamud-no-soliciting No-Solicit October 2003 6. IANA Considerations There are four IANA considerations presentedoperational reasons as defined in Section 7.7 of RFC 2821[22], set thisdraft: 1. Additionparameter 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 extensionto the Mail Parameters registry. 2. Addition of the "ESMTP-Solicitation" Additional Protocol 3. Creation of a Solicitation Class Keywords registry. 4. Creation ofis not a"Solicitation:" mail header, which doesguaranteed end-to-end service. Specifically, intermediate relays that do notcurrently raise any IANA considerations. 6.1 The Mail Parameters Registry The IANA Mail Parameters registry documents SMTPsupport this serviceextensions. The "NO-SOLICITATION"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 extensionwould need to be added*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 May 29, 2004 [Page 12] draft-malamud-no-soliciting No-Solicit November 2003 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 May 29, 2004 [Page 13] draft-malamud-no-soliciting No-Solicit November 2003 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 May 29, 2004 [Page 14] draft-malamud-no-soliciting No-Solicit November 2003 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 May 29, 2004 [Page 15] draft-malamud-no-soliciting No-Solicit November 2003 "NO-SOLICITING" assertion could both be factors taken into consideration in levying fines or taking other corrective actions. Malamud Expires May 29, 2004 [Page 16] draft-malamud-no-soliciting No-Solicit November 2003 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 May 29, 2004 [Page 17] draft-malamud-no-soliciting No-Solicit November 2003 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 May 29, 2004 [Page 18] draft-malamud-no-soliciting No-Solicit November 2003 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 May 29, 2004 [Page 19] draft-malamud-no-soliciting No-Solicit November 2003 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 May 29, 2004 [Page 20] draft-malamud-no-soliciting No-Solicit November 2003 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 May 29, 2004 [Page 21] draft-malamud-no-soliciting No-Solicit November 2003 [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 May 29, 2004 [Page 22] draft-malamud-no-soliciting No-Solicit November 2003 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 May 29, 2004 [Page 23] draft-malamud-no-soliciting No-Solicit November 2003 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-01.html> [38] <http://trusted.resource.org/no-solicit/ draft-malamud-no-soliciting-02.html> [39] <http://trusted.resource.org/no-solicit/ draft-malamud-no-soliciting-00.html> [40] <http://trusted.resource.org/no-solicit/ draft-malamud-no-soliciting-01.html> [41] <mailto: remote-printer.Timothy_J_Muris/ FTC@12023262012.iddd.tpc.int> [42] <http://frwebgate.access.gpo.gov/cgi-bin/ getdoc.cgi?dbname=108_cong_bills&docid=f:s877es.txt.pdf> [43] <mailto:carl@media.org> [44] <mailto:hbeales@ftc.gov> [45] <mailto:ed@markey.house.gov> Malamud Expires May 29, 2004 [Page 24] draft-malamud-no-soliciting No-Solicit November 2003 Author's Address Carl Malamud Memory Palace Press PO Box 300 Sixes, OR 97476 US EMail: carl@media.org Malamud Expires May 29, 2004 [Page 25] draft-malamud-no-soliciting No-Solicit November 2003 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-01 [37] to draft-malamud-no-soliciting-02 [38]: 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 "do not spam" lists has been added (see Section 3.1). Changes from draft-malamud-no-soliciting-00 [39] to draft-malamud-no-soliciting-01 [40]: o The two service extensions previously proposed ( Malamud Expires May 29, 2004 [Page 26] draft-malamud-no-soliciting No-Solicit November 2003 "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 May 29, 2004 [Page 27] draft-malamud-no-soliciting No-Solicit November 2003 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 [41] Dear Mr. Muris: On October 23, 2003, the U.S. Senate passed S.877, known as the CAN-SPAM Act of 2003. [42] 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 May 29, 2004 [Page 28] draft-malamud-no-soliciting No-Solicit November 2003 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 [43] 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 [44] The Honorable Edward J. Markey U.S. House of Representatives 2108 Rayburn House Office Building Washington, DC 20515 ed@markey.house.gov [45] Malamud Expires May 29, 2004 [Page 29] draft-malamud-no-soliciting No-Solicit November 2003 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 (2003). 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 May 29, 2004 [Page 30] draft-malamud-no-soliciting No-Solicit November 2003 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 May 29, 2004 [Page 31] <?xml version='1.0'?> <!DOCTYPE rfc SYSTEM 'rfc2629.dtd'> <?rfc compact='no'?> <?rfc editing='no'?> <?rfc subcompact='no'?> <?rfc toc='yes'?> <?rfc header='draft-malamud-no-soliciting'?> <rfc category="info" ipr="full2026" docName="draft-malamud-no-soliciting-02"> <front> <title abbrev="No-Solicit">A No Soliciting SMTP Service Extension</title> <author initials='C.' surname='Malamud' fullname='Carl Malamud' > <organization>Memory Palace Press</organization> <address> <postal> <street>PO Box 300</street> <city>Sixes</city> <region>OR</region><code>97476</code> <country>US</country> </postal> <email>carl@media.org</email> </address> </author> <date month='November' day="29" year='2003'/> <abstract> <t>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. </t> </abstract> <note title="Terminology"> <t> 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 <xref target="RFC2119" />. </t> </note> </front> <middle> <section title="Introduction"> <section title="The Spam Pandemic"> <t> 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 will cost businesses $13 billion in 2003.<xref target="ferris" /> In April 2003, AOL reported that it had blocked 2.37 billion pieces of UBE in a single day. <xref target="aol.spam" /> 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.<xref target="schumer" /> <xref target="ftc.press.hype" /> </t> <t>A variety of mechanisms from the technical community have been proposed and/or implemented to fight UBE: <list style="symbols"> <t>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. <xref target="habeas.compliant" /> </t> <t>Blacklists are lists of known spammers or ISPs that allow spam.<xref target="rosko" /> </t> <t>Spam filters run client-side or server-side to filter out spam based on whitelists, blacklists, and textual and header analysis.<xref target="spam.assassin" /> </t> <t>A large number of documents address the overall technical considerations for the control of UBE <xref target="I-D.crocker-spam-techconsider" />, operational considerations for SMTP agents<xref target="RFC2505" />, and various extensions to the protocols to support UBE identification and filtering. <xref target="I-D.danisch-dns-rr-smtp" /> <xref target="I-D.daboo-sieve-spamtest" /> <xref target="I-D.crouzet-amtp" /> </t> <t>Various proposals have been advanced for "do not spam" lists, akin to the Federal Trade Commission's "Do Not Call" list for telemarketers.<xref target="ftc.tsr" /></t> </list></t> </section> <section title="No Soliciting in the Real World"> <t>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: <list style="empty"><t> "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." <xref target="newbury.ordinance" /> </t></list> </t> <t>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: <list style="empty"><t> "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 ..." <xref target="watchtower" /> </t></list> </t> <t>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."<xref target="perry" /> </t> <t> 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."<xref target="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."<xref target="martin" /> 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. </t> <t>This analysis is very U.S.-centric, which may be appropriate given that the large majority of UBE appears to originate from U.S. citizens. However, the concept of prohibiting unwanted solicitation does carry over to other countries: <list style="symbols"> <t>In Hong Kong, offices frequently post "no soliciting" signs.</t> <t>In the United Kingdom, where door-to-door peddlers are fairly common, "no soliciting" signs are also common.</t> <t>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.</t> <t>In France, which has a long tradition of door-to-door solicitation, apartment buildings often use trespass laws to enforce "no solicitation" policies.</t> <t>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. </t> </list> </t> </section> <section title="A Distributed No Soliciting Extension"> <t> 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: <list style="symbols"> <t>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.</t> <t>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.</t> </list></t> <t>This memo details a series of extensions to SMTP that have the following characteristics: <list style="symbols"> <t>A service extension is described that allows a receiving MTA to signal the sending MTA that no soliciting is in effect.</t> <t>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.</t> <t>Trace fields for intermediate MTAs are extended to allow the intermediate MTA to signal that a message conforms to a certain class.</t> </list></t> <t> 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. </t> <t>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. </t> </section> </section> <section anchor="extension" title="The No-Soliciting SMTP Service Extension" > <t> Per RFC 2821,<xref target="RFC2821"/> a <spanx style="verb">NO-SOLICITING</spanx> SMTP service extension is defined. The service extension is declared during the initial <spanx style="verb">EHLO</spanx> SMTP exchange. The extension has one optional parameter and zero or more solicitation class keywords. Using the notation as described in the Augmented BNF<xref target="RFC2234" />, the syntax is: </t> <figure><artwork> No-Soliciting-Service = "NO-SOLICITING" [ "SYSTEM-WIDE" / "PER-RECIPIENT" ] 0*( Solicitation-keywords ) </artwork></figure> <section title="The SYSTEM-WIDE Option"> <t><spanx style="verb">NO-SOLICITING SYSTEM-WIDE</spanx> 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.</t> <t>The parameter is presented during the initial exchange between sender and receiver: </t> <figure><artwork> 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 </artwork></figure> <t>(The <spanx style="verb">ADV</spanx> keyword is one of several possible values and is described in the following section.) </t> <t>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.<xref target="smtp-banner" /> 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., <xref target="wheel" />). </t> </section> <section anchor="keywords" title="Solicitation Class Keywords"> <t> The <spanx style="verb">NO-SOLICITING</spanx> 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 <spanx style="verb">SYSTEM-WIDE</spanx> parameter.</t> <t> Three classes are defined in this draft: </t> <figure><artwork> 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/ </artwork></figure> <t> MAPS-UBE is the standard advanced by the Mail Abuse Prevention System (MAPS), which states: <list style="empty"><t> 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. </t></list> </t> <t> 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. </t> <t>There is no default keyword for the service. In other words, the following example is a "no-op": </t> <figure><artwork> R: 250-NO-SOLICITING SYSTEM-WIDE </artwork></figure> <t> Additional solicitation class keywords may be defined and registered in the registry as specified in <xref target="iana" />. Multiple solicitation class keywords are separated by a comma to form a list: </t> <figure><artwork> 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) </artwork></figure> </section> <section anchor="per-recipient" title="The PER-RECIPIENT Option"> <t>The <spanx style="verb">NO-SOLICITING PER-RECIPIENT</spanx> extension specifies that each <spanx style="verb">MAIL FROM</spanx> command must identify if a message is a solicitation.</t> <t> The presence of this extension is identified during the initial greeting: </t> <figure><artwork> 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 </artwork></figure> <t>Additionally, <spanx style="verb">SOLICIT</spanx> is defined as a parameter for the <spanx style="verb">MAIL FROM</spanx> command. The <spanx style="verb">SOLICIT</spanx> parameter is followed by an optional equal sign and a comma separated list of solicitation class keywords. </t> <t> The syntax for this parameter is: </t> <figure><artwork> Mail-From-Solicit-Parameter = "SOLICIT" 1( "=" Solicitation-keywords) </artwork></figure> <t> As an informational message, the <spanx style="verb">550</spanx> or <spanx style="verb">250</spanx> replies to the <spanx style="verb">RCPT TO</spanx> command may also contain the <spanx style="verb">SOLICIT</spanx> parameter. </t> <t> The receiving system may decide on a per-user basis the appropriate disposition of messages:</t> <figure><artwork> 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 </artwork></figure> <t>In the previous example, the receiving MTA returned a <spanx style="verb">550</spanx> 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. </t> </section> <section anchor="enhanced" title="Use of Enhanced Mail Status Codes"> <t>If a session between two MTAs is using both the <spanx style="verb">NO-SOLICITING</spanx> extension and the Enhanced Mail Status Codes as defined in RFC 3463<xref target="RFC3463" /> and a message is rejected based on the presence of a <spanx style="verb">SOLICIT</spanx> parameter, the correct error message to return is <spanx style="verb">5.7.1</spanx>, defined as "the sender is not authorized to send to the destination ... [because] of per-host or per-recipient filtering." </t> </section> <section title="Solicitation Mail Header"> <t> Per RFC 2822,<xref target="RFC2822"/> a new <spanx style="verb">Solicitation:</spanx> header field is defined which contains one or more solicitation class keywords. </t> <figure><artwork> To: Coupon Clipper <coupon_clipper@trusted.resource.org> From: Spam King <savebigbucks@hotmail.com> Solicitation: ADV,ADV:ADLT </artwork></figure> <t>Several proposals, particularly legal ones, have suggested requiring the use of keywords in the <spanx style="verb">Subject:</spanx> header. While embedding information in the <spanx style="verb">Subject:</spanx> 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 <spanx style="verb">Subject:</spanx> header. Of course, there is no reason why both mechanisms can't be used, and in any case the <spanx style="verb">Solicitation:</spanx> header could be automatically inserted based on the contents of the subject line.</t> <t> It should be noted that the presence of both a <spanx style="verb">Solicitation:</spanx> header and a <spanx style="verb">SOLICIT</spanx> service extension leads to the possibility of conflict between the two. Implementors <spanx style="emph">SHOULD</spanx> always include any values found in the <spanx style="verb">Solicitation:</spanx> header in the fields presented in the service extension. Implementors <spanx style="verb">MAY</spanx> add additional keywords for operational reasons as defined in Section 7.7 of RFC 2821<xref target="RFC2821" />. </t> </section> <section anchor="received" title="Insertion of Solicitation Keywords in Trace Fields"> <t>The <spanx style="verb">Solicitation:</spanx> 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 <spanx style="verb">Received:</spanx> trace field. Since many current systems use an intermediate relay to detect unsolicited mail, an addition to the <spanx style="verb">Received:</spanx> header is described. </t> <t>As a review, RFC 2821<xref target="RFC2821" /> documents the following productions for the <spanx style="verb">Received:</spanx> header in a mail message: </t> <figure><artwork> 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. </artwork></figure> <t> The appropriate location for solicitation information is the <spanx style="verb">Attdl-Protocol</spanx> field, which is defined in this document as <spanx style="verb">ESMTP-Solicitation</spanx>. The RFC 2821 productions are supplemented as follows: </t> <figure><artwork> Protocol = "ESMTP" / "SMTP" / ESMTP-Solicitation / Attdl-Protocol ESMTP-Solicitation = "ESMTP-Solicitation" FWS 0*( Solicitation-keywords ) </artwork></figure> <t> An example of a Received: header from a conforming MTA is as follows: </t> <figure><artwork> Received: by foo-mta.example.com with ESMTP-Solicitation ADV,ADV:ADLT ; Sat, 9 Aug 2003 16:54:42 -0700 (PDT) </artwork></figure> </section> <section title="Relay of Messages"> <t> The <spanx style="verb">NO-SOLICITING SYSTEM-WIDE</spanx> 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. </t> <t> When relaying a message which was received via the SMTP protocol in which the <spanx style="verb">SOLICIT</spanx> parameter was set on the <spanx style="verb">MAIL FROM</spanx> command, the MTA <spanx style="emph">MUST</spanx> also set the <spanx style="verb">SOLICIT</spanx> parameter when delivering the message to an SMTP server that supports this extension. </t> <t> The <spanx style="verb">SOLICIT</spanx> parameter on a <spanx style="verb">MAIL FROM</spanx> command can be derived from a variety of sources, including receipt of a message from a conforming SMTP server. An SMTP server <spanx style="emph">MAY</spanx>, for operational reasons as defined in Section 7.7 of RFC 2821<xref target="RFC2821" />, set this parameter after detecting the presence of the <spanx style="verb">Solicitation:</spanx> or extended <spanx style="verb">Received:</spanx> message header field or by using other system-specific techniques. </t> <t> Implementers should be aware that the <spanx style="verb">NO-SOLICITING</spanx> 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. </t> </section> <section anchor="implementation" title="Recommendations for Developers and Administrators"> <t> It is strongly recommended that any developers that implement the <spanx style="verb">NO-SOLICITING</spanx> service extension <spanx style="emph">SHOULD NOT</spanx> 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. </t> <t> Likewise, it is recommended that a system administrator installing software <spanx style="emph">SHOULD NOT</spanx> enable <spanx style="verb">PER-RECIPIENT</spanx> filtering by default for a user. Again, individual users should request the service. </t> <t>The mechanism for an individual user to communicate their desire to enable certain types of filtering is outside the scope of this document. </t> <t>It should be noted that for recipient MTAs, implementation of the <spanx style="verb">SYSTEM-WIDE</spanx> option is significantly simpler than adding <spanx style="verb">PER-RECIPIENT</spanx> capabilities. Because <spanx style="verb">PER-RECIPIENT</spanx> is an optional parameter, it should be noted that: <list style="symbols"> <t>A conforming sending MTA <spanx style="emph">MUST</spanx> provide support for both <spanx style="verb">SYSTEM-WIDE</spanx> and <spanx style="verb">PER-RECIPIENT</spanx>. </t> <t>A conforming receiving MTA <spanx style="emph">MAY</spanx> provide support for either <spanx style="verb">SYSTEM-WIDE</spanx> or <spanx style="verb">PER-RECIPIENT</spanx> or both. </t> </list></t> <t>Implementation of the SYSTEM-WIDE on a receiving MTA is almost trivial. For example, on the popular <eref target="http://www.sendmail.org/">sendmail</eref> package, a few minor changes need to be made to three files. </t> </section> </section> <section anchor="scenario" title="Use of the Extension"> <t> 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. </t> <t>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.</t> <t>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: <list style="numbers"> <t>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 <eref target="http://thomas.loc.gov/">Congressional Record</eref> or the <eref target="http://www.gpoaccess.gov/fr/">Federal Register</eref> 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 <spanx style="verb">NO-SOLICITING</spanx> notice and any penalties for violation thereof. Let us suppose that the keyword to be registered is "<spanx style="verb">UCE</spanx>.</t> <t>The appropriate authority (e.g., the <eref target="http://clerk.house.gov/index.php"> Clerk of the House</eref> or an appropriate executive branch official) would register this definition with the IANA using the template as described in <xref target="iana" /> and sending the completed template to <eref target="mailto:iana@iana.org">iana@iana.org</eref>. </t> <t>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. </t> <t>Reputable email list maintainers would activate a simple check of 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 <spanx style="verb">SYSTEM-WIDE</spanx> or <spanx style="verb">PER-RECIPIENT</spanx> service extension matches the <spanx style="verb">UCE</spanx> keyword, the address would be scrubbed from the list.</t> <t>Reputable users of email lists would add a <spanx style="verb">Solicitation: UCE</spanx> 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. </t> <t>A system manager, under the guidance of the Administrative Contact for a domain, would configure <spanx style="verb">MX</spanx> 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 <spanx style="verb">NO-SOLICITING SYSTEM-WIDE UCE</spanx>. These systems receiving mail on behalf of the designated domain might also be configured to run a spam identification utility, such as <eref target="http://spamassassin.org/index.html"> SpamAssasin</eref> or <eref target="http://www.spambouncer.org/">SpamBouncer</eref>.</t> <t> End users would configure their mail filters to filter out any properly tagged messages (e.g., <spanx style="verb">Solicitation: UCE</spanx>) and any messages that are not properly tagged (e.g., in SpamBouncer, the user might set the <spanx style="verb">SPAMLEVEL</spanx> parameter to <spanx style="verb">10</spanx>, which would filter all messages with a score of 10 or greater using the software's own algorithms for the detection of probable spam). </t> <t> 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 <spanx style="verb">SPAMREPLY</spanx> to <spanx style="verb">COMPLAIN</spanx> 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. </t> </list> </t> <section anchor="spam.list" title="Relationship to Centralized Approaches"> <t>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 same problem addressed by this service extension. The centralized approach has the following potential pitfalls: <list style="symbols"> <t>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. </t> <t>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. </t> <t> 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. </t> </list> </t> <t>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. </t> <t>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 <spanx style="verb">NO-SOLICITING</spanx> assertion could both be factors taken into consideration in levying fines or taking other corrective actions.</t> </section> </section> <section title="Security Considerations"> <t>This proposal does not present additional security complications beyond those already amply represented in the current architecture for electronic mail. </t> </section> <section anchor="iana" title="IANA Considerations"> <t>There are four IANA considerations presented in this draft: <list style="numbers"> <t>Addition of the <spanx style="verb">NO-SOLICITING</spanx> service extension to the Mail Parameters registry.</t> <t>Addition of the <spanx style="verb">ESMTP-Solicitation</spanx> Additional Protocol</t> <t>Creation of a Solicitation Class Keywords registry.</t> <t>Creation of a <spanx style="verb">Solicitation:</spanx> mail header, which does not currently raise any IANA considerations.</t> </list></t> <section title="The Mail Parameters Registry"> <t>The IANA Mail Parameters registry documents SMTP service extensions. The <spanx style="verb">NO-SOLICITATION</spanx> service extension would need to be added to this registry as follows. </t> <figure><artwork> Keywords Description Reference ------------ -------------------------------- --------- NO-SOLICITING Notification of no soliciting.[<this draft>] The[<this draft>] </artwork></figure> <t>The parameters subregistry would need to be modified as follows: </t> <figure><artwork> Service Ext EHLO Keyword Parameters Reference ----------- ------------ ----------- --------- No Soliciting NO-SOLICITING SYSTEM-WIDE[<this draft>][<this draft>] No Soliciting NO-SOLICITING PER-RECIPIENT[<this draft>] 6.2 ESMTP-Solicitation[<this draft>] </artwork></figure> </section> <section title="ESMTP-Solicitation AdditionalProtocol TheProtocol"> <t>The Mail Parameters registry would need to be modified to list"ESMTP-Solicitation"<spanx style="verb">ESMTP-Solicitation</spanx> as a valid additional protocol for use in the"Received:"<spanx style="verb">Received:</spanx> header of a mail message.6.3 The</t> </section> <section title="The Solicitation Class KeywordsRegistry ARegistry"> <t>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<list style="numbers"> <t>Keyword name (e.g.,"MAPS-UBE"). 2. Keyword"MAPS-UBE").</t> <t>Keyword description (e.g., "Unsolicited BulkEmail"). Malamud Expires April 9, 2004 [Page 16] draft-malamud-no-soliciting No-Solicit October 2003 3. KeywordEmail").</t> <t>Keyword reference (e.g.,"<this draft>"). Per"<this draft>").</t> </list> </t> <t>Per the policies outlined in RFC2434[26],2434<xref target="RFC2434" />, 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.6.4 The</t> </section> <section title="The Solicitation MailHeader ThereHeader"> <t>There is currently no registry defined for mail headers. If such a registry were to exist, the"Solicitation:"<spanx style="verb">Solicitation:</spanx> header field would need to be added to it.Malamud Expires April 9, 2004 [Page 17] draft-malamud-no-soliciting No-Solicit October 2003 7. Author's Acknowledgements The</t> </section> </section> <section title="Author's Acknowledgements"> <t>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 ofthe author. Malamud Expires April 9, 2004 [Page 18] draft-malamud-no-soliciting No-Solicit October 2003 Informative References [1] Associated Press, "Study: Spam costs businesses $13 billion", January 2003. [2] CNET News.Com, "AOLthe author.</t> </section> </middle> <back> <references title="Informative References"> <reference anchor="ferris" target='http://www.cnn.com/2003/TECH/biztech/01/03/spam.costs.ap/index.html'> <front> <title>Study: Spam costs businesses $13 billion</title> <author> <organization>Associated Press</organization> </author> <date month="January" day="5" year="2003" /> </front> <format type='HTML' target='http://www.cnn.com/2003/TECH/biztech/01/03/spam.costs.ap/index.html' /> </reference> <reference anchor="aol.spam" target="http://news.com.com/2100-1025-998944.html" > <front> <title>AOL touts spam-fightingprowess", April 2003. [3] Charles, C., "Schumer,prowess</title> <author> <organization>CNET News.Com</organization> </author> <date month="April" day="30" year="2003" /> </front> <format type="HTML" target="http://news.com.com/2100-1025-998944.html" /> </reference> <reference anchor="schumer" target="http://www.senate.gov/~schumer/SchumerWebsite/pressroom/press_releases/PR01782.html" > <front> <title>Schumer, Christian Coalition Team Up to Crack Down on Email SpamPornography", June 2003. [4] Federal Trade Commission, "Federal,Pornography</title> <author surname="Charles" initials="C" fullname="Charles Schumer"> <organization>U.S. Senate</organization> </author> <date month="June" day="12" year="2003" /> </front> <format type="HTML" target="http://www.senate.gov/~schumer/SchumerWebsite/pressroom/press_releases/PR01782.html" /> </reference> <reference anchor="ftc.press.hype" target="http://www.ftc.gov/opa/2002/11/nenetforcema.htm" > <front> <title>Federal, State, Local Law Enforcers Target Deceptive Spam and InternetScams", November 2002. [5] Habeas, Inc., "HabeasScams</title> <author> <organization>Federal Trade Commission</organization> </author> <date month="November" day="7" year="2002" /> </front> <format type="HTML" target="http://www.ftc.gov/opa/2002/11/nenetforcema.htm" /> </reference> <reference anchor="habeas.compliant" target="http://www.habeas.com/services/hcm.htm"> <front> <title>Habeas CompliantMessage", April 2003. [6] Spamhaus.Org, "RegisterMessage</title> <author> <organization>Habeas, Inc.</organization> <address><uri>http://www.habeas.com/</uri></address> </author> <date month="April" day="16" year="2003" /> </front> <format type="HTML" target="http://www.habeas.com/services/hcm.htm" /> </reference> <reference anchor="rosko" target="http://www.spamhaus.org/rokso/index.lasso" > <front> <title>Register of Known SpamOperations". [7] Mason, J., "SpamassassinOperations</title> <author> <organization>Spamhaus.Org</organization> <address><uri>http://www.spamhaus.org</uri></address> </author> <date month="November" year="2003" /> </front> <format type="HTML" target="http://www.spamhaus.org/rokso/index.lasso" /> </reference> <reference anchor="spam.assassin" target="http://www.mirror.ac.uk/sites/spamassassin.taint.org/spamassassin.org/doc/spamassassin.html" > <front> <title>Spamassassin - Mail Filter to Identify Spam Using TextAnalysis", Version 2.55, May 2003. [8] Crocker, D., "TechnicalAnalysis</title> <author initials="J" surname="Mason" fullname="Justin Mason"> <organization /> <address><email>jm@jmason.org</email></address> </author> <date month="May" day="20" year="2003" /> </front> <seriesInfo name="Version" value="2.55" /> <format type="HTML" target="http://www.mirror.ac.uk/sites/spamassassin.taint.org/spamassassin.org/doc/spamassassin.html" /> </reference> <reference anchor="I-D.crocker-spam-techconsider"> <front> <title>Technical Considerations for Spam ControlMechanisms", draft-crocker-spam-techconsider-01 (work in progress), May 2003. [9] Lindberg, G., "Anti-SpamMechanisms</title> <author initials="D" surname="Crocker" fullname="Dave Crocker"> <organization /> </author> <date month="May" day="19" year="2003" /> </front> <seriesInfo name="Internet-Draft" value="draft-crocker-spam-techconsider-02" /> <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt" /> </reference> <reference anchor='RFC2505'> <front> <title abbrev='Anti-Spam Recommendations'>Anti-Spam Recommendations for SMTPMTAs", BCP 30, RFC 2505, February 1999. [10] Danisch, H., "AMTAs</title> <author initials='G.' surname='Lindberg' fullname='Gunnar Lindberg'> <organization>Chalmers University of Technology, Computer Communications Group</organization> <address> <postal> <street /> <city>Gothenburg</city> <code>SE-412 96</code> <country>SE</country></postal> <phone>+46 31 7725913</phone> <email>lindberg@cdg.chalmers.se</email></address></author> <date month='February' year='1999' /> <abstract> <t>This memo gives a number of implementation recommendations for SMTP,, MTAs (Mail Transfer Agents, e.g.sendmail) to make them more capable of reducing the impact of spam(*).</t> <t>The intent is that these recommendations will help clean up the spam situation, if applied on enough SMTP MTAs on the Internet, and that they should be used as guidelines for the various MTA vendors. We are fully aware that this is not the final solution, but if these recommendations were included, and used, on all Internet SMTP MTAs, things would improve considerably and give time to design a more long term solution. The Future Work section suggests some ideas that may be part of such a long term solution. It might, though, very well be the case that the ultimate solution is social, political, or legal, rather than technical in nature.</t> <t>The implementor should be aware of the increased risk of denial of service attacks that several of the proposed methods might lead to. For example, increased number of queries to DNS servers and increased size of logfiles might both lead to overloaded systems and system crashes during an attack.</t> <t>A brief summary of this memo is: <list style='symbols'> <t>Stop unauthorized mail relaying.</t> <t>Spammers then have to operate in the open; deal with them.</t> <t>Design a mail system that can handle spam.</t></list></t></abstract></front> <seriesInfo name='BCP' value='30' /> <seriesInfo name='RFC' value='2505' /> <format type='TXT' octets='53597' target='ftp://ftp.isi.edu/in-notes/rfc2505.txt' /> </reference> <reference anchor="I-D.danisch-dns-rr-smtp"> <front> <title>A DNS RR for simple SMTP senderauthentication", draft-danisch-dns-rr-smtp-02 (work in progress), June 2003. [11] Daboo, C., "SIEVEauthentication</title> <author initials="H" surname="Danisch" fullname="Hadmut Danisch"> <organization /> </author> <date month="October" year="2003" /> </front> <seriesInfo name="Internet-Draft" value="draft-danisch-dns-rr-smtp-03" /> <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-03.txt" /> </reference> <reference anchor="I-D.daboo-sieve-spamtest"> <front> <title>SIEVE Spamtest and VirustestExtensions", draft-daboo-sieve-spamtest-03 (work in progress), April 2003. [12] Crouzet, B., "AuthenticatedExtensions</title> <author initials="C" surname="Daboo" fullname="Cyrus Daboo"> <organization /> </author> <date month="October" year="2003" /> </front> <seriesInfo name="Internet-Draft" value="draft-daboo-sieve-spamtest-04" /> <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-daboo-sieve-spamtest-04.txt" /> </reference> <reference anchor="I-D.crouzet-amtp"> <front> <title>Authenticated Mail TransferProtocol", draft-crouzet-amtp-00 (work in progress), June 2003. [13] Federal Trade Commission, "TelemarketingProtocol</title> <author initials="B" surname="Crouzet" fullname="Brice Crouzet"> <organization /> </author> <date month="October" year="2003" /> </front> <seriesInfo name="Internet-Draft" value="draft-crouzet-amtp-01" /> <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-crouzet-amtp-01.txt" /> </reference> <reference anchor="ftc.tsr" target="http://www.ftc.gov/os/2002/12/tsrfinalrule.pdf" > <front> <title>Telemarketing SalesRule", Federal Register Vol.Rule</title> <author> <organization>Federal Trade Commission</organization> <address><uri>http://www.ftc.gov/</uri></address> </author> <date month="January" day="29" year="2003" /> </front> <seriesInfo name="Federal Register" value="Vol. 68, No.19, January 2003. [14] The19" /> <format type="PDF" target="http://www.ftc.gov/os/2002/12/tsrfinalrule.pdf" /> </reference> <reference anchor="newbury.ordinance" target="http://www.town.west-newbury.ma.us/Public_Documents/WestNewburyMA_Bylaws/chapter18" > <front> <title>Soliciting/Canvassing By-Law</title> <author> <organization>The Town ofWest Newbury, Massachusetts, "Soliciting/Canvassing By-Law", Chapter 18 Section 10, March 2002. [15] U.S. Supreme Court, "WatchtowerWest Newbury, Massachusetts</organization> </author> <date month="March" day="15" year="2002" /> </front> <seriesInfo name="Chapter 18" value="Section 10" /> <format type="html" target="http://www.town.west-newbury.ma.us/Public_Documents/WestNewburyMA_Bylaws/chapter18" /> </reference> <reference anchor="watchtower" target="http://caselaw.lp.findlaw.com/scripts/getcase.pl?court=US&vol=000&invol=00-1737"> <front> <title>Watchtower Bible&& Tract Society of New York, Inc., et al. v. Village of Stratton etal.", 122 S.Ct. 2080 (2002), June 2002. [16] U.S.al.</title> <author> <organization>U.S. SupremeCourt, "PerryCourt</organization> </author> <date month="June" day="17" year="2002" /> </front> <seriesInfo name="122 S.Ct." value="2080 (2002)" /> <format type="html" target="http://caselaw.lp.findlaw.com/scripts/getcase.pl?court=US&vol=000&invol=00-1737" /> </reference> <reference anchor="perry" target="http://caselaw.lp.findlaw.com/scripts/getcase.pl?court=US&vol=460&invol=37" > <front> <title>Perry Education Association v. Perry Local Educators'Association", 460 U.S. 37 (1983), February 1983. Malamud Expires April 9, 2004 [Page 19] draft-malamud-no-soliciting No-Solicit October 2003 [17] U.S.Association</title> <author> <organization>U.S. SupremeCourt, "CantwellCourt</organization> </author> <date month="February" day="23" year="1983" /> </front> <seriesInfo name="460 U.S." value="37 (1983)" /> <format type="html" target="http://caselaw.lp.findlaw.com/scripts/getcase.pl?court=US&vol=460&invol=37" /> </reference> <reference anchor="cantwell" target="http://caselaw.lp.findlaw.com/scripts/getcase.pl?court=US&vol=310&invol=296"> <front> <title>Cantwell v. State ofConnecticut", 310 U.S. 296 (1940), May 1940. [18] U.S.Connecticut</title> <author> <organization>U.S. SupremeCourt, "MartinCourt</organization> </author> <date month="May" day="20" year="1940" /> </front> <seriesInfo name="310 U.S." value="296 (1940)" /> <format type="html" target="http://caselaw.lp.findlaw.com/scripts/getcase.pl?court=US&vol=310&invol=296" /> </reference> <reference anchor="martin" target="http://caselaw.lp.findlaw.com/scripts/getcase.pl?court=US&vol=319&invol=141" > <front> <title>Martin v. City of Struthers,Ohio", 319 U.S. 141 (1943), May 1943. [19] Levine, J. and P. Hoffman, "Anti-UBEOhio</title> <author> <organization>U.S. Supreme Court</organization> </author> <date month="May" day="3" year="1943" /> </front> <seriesInfo name="319 U.S." value="141 (1943)" /> <format type="html" target="http://caselaw.lp.findlaw.com/scripts/getcase.pl?court=US&vol=319&invol=141" /> </reference> <reference anchor="smtp-banner" target="http://www.cauce.org/proposal/smtp-banner-rfc.shtml" > <front> <title>Anti-UBE and Anti-UCE Keywords in SMTPBanners", Revision 1.1, March 1999. [20] Malamud, C., "AnBanners</title> <author initials="J." surname="Levine" fullname="John Levine"> <organization /> </author> <author initials="P." surname="Hoffman" fullname="Paul Hoffman"> <organization /> </author> <date month="March" day="28" year="1999" /> </front> <seriesInfo name="Revision" value="1.1" /> <format type="HTML" target="http://www.cauce.org/proposal/smtp-banner-rfc.shtml" /> </reference> <reference anchor="wheel" target="http://mappa.mundi.net/cartography/Wheel/" > <front> <title>An Internet PrayerWheel", Mappa.Mundi Magazine, August 1999. Malamud Expires April 9, 2004 [Page 20] draft-malamud-no-soliciting No-Solicit October 2003 Normative References [21] Bradner, S., "KeyWheel</title> <author initials="C." surname="Malamud" fullname="Carl Malamud"> <organization /> <address><email>carl@media.org</email></address></author> <date month="August" day="1" year="1999" /></front> <seriesInfo name="Mappa.Mundi" value="Magazine" /> <format type="HTML" target="http://mappa.mundi.net/cartography/Wheel/" /> </reference> </references> <references title="Normative References"> <reference anchor='RFC2119'> <front> <title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate RequirementLevels", BCP 14,Levels</title> <author initials='S.' surname='Bradner' fullname='Scott Bradner'> <organization>Harvard University</organization> <address> <postal> <street>1350 Mass. Ave.</street> <street>Cambridge</street> <street>MA 02138</street></postal> <phone>- +1 617 495 3864</phone> <email>sob@harvard.edu</email></address></author> <date month='March' year='1997' /> <area>General</area> <keyword>keyword</keyword> <abstract> <t> In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: <list> <t> 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 RFC2119, March 1997. [22] Klensin, J., "Simple2119. </t></list></t> <t> Note that the force of these words is modified by the requirement level of the document in which they are used. </t></abstract></front> <seriesInfo name='BCP' value='14' /> <seriesInfo name='RFC' value='2119' /> <format type='TXT' octets='4723' target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' /> <format type='HTML' octets='15905' target='http://xml.resource.org/public/rfc/html/rfc2119.html' /> <format type='XML' octets='5661' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' /> </reference> <reference anchor='RFC2821'> <front> <title>Simple Mail TransferProtocol", RFC 2821, April 2001. [23] Crocker, D. and P. Overell, "AugmentedProtocol</title> <author initials='J.' surname='Klensin' fullname='J. Klensin'> <organization /></author> <date month='April' year='2001' /></front> <seriesInfo name='RFC' value='2821' /> <format type='TXT' octets='192504' target='ftp://ftp.isi.edu/in-notes/rfc2821.txt' /> </reference> <reference anchor='RFC2234'> <front> <title abbrev='ABNF for Syntax Specifications'>Augmented BNF for Syntax Specifications:ABNF", RFC 2234, November 1997. [24] Resnick, P., "InternetABNF</title> <author initials='D.H.' surname='Crocker' fullname='David H. Crocker'> <organization>Internet Mail Consortium</organization> <address> <postal> <street>675 Spruce Dr.</street> <city>Sunnyvale</city> <region>CA</region> <code>94086</code> <country>US</country></postal> <phone>+1 408 246 8253</phone> <facsimile>+1 408 249 6205</facsimile> <email>dcrocker@imc.org</email></address></author> <author initials='P.' surname='Overell' fullname='Paul Overell'> <organization>Demon Internet Ltd</organization> <address> <postal> <street>Dorking Business Park</street> <street>Dorking</street> <city>Surrey</city> <region>England</region> <code>RH4 1HN</code> <country>UK</country></postal> <email>paulo@turnpike.com</email></address></author> <date month='November' year='1997' /></front> <seriesInfo name='RFC' value='2234' /> <format type='TXT' octets='24265' target='ftp://ftp.isi.edu/in-notes/rfc2234.txt' /> </reference> <reference anchor='RFC2822'> <front> <title>Internet MessageFormat", RFC 2822, April 2001. [25] Vaudreuil, G., "EnhancedFormat</title> <author initials='P.' surname='Resnick' fullname='P. Resnick'> <organization /></author> <date month='April' year='2001' /></front> <seriesInfo name='RFC' value='2822' /> <format type='TXT' octets='110695' target='ftp://ftp.isi.edu/in-notes/rfc2822.txt' /> </reference> <reference anchor='RFC3463'> <front> <title>Enhanced Mail System StatusCodes", RFC 3463, January 2003. [26] Narten, T.Codes</title> <author initials='G.' surname='Vaudreuil' fullname='G. Vaudreuil'> <organization /></author> <date month='January' year='2003' /></front> <seriesInfo name='RFC' value='3463' /> <format type='TXT' octets='31832' target='ftp://ftp.isi.edu/in-notes/rfc3463.txt' /> </reference> <reference anchor='RFC2434'> <front> <title abbrev='Guidelines for IANA Considerations'>Guidelines for Writing an IANA Considerations Section in RFCs</title> <author initials='T.' surname='Narten' fullname='Thomas Narten'> <organization>IBM Corporation</organization> <address> <postal> <street>3039 Cornwallis Ave.</street> <street>PO Box 12195 - BRQA/502</street> <street>Research Triangle Park</street> <street>NC 27709-2195</street></postal> <phone>919-254-7798</phone> <email>narten@raleigh.ibm.com</email></address></author> <author initials='H.T.' surname='Alvestrand' fullname='Harald Tveit Alvestrand'> <organization>Maxware</organization> <address> <postal> <street>Pirsenteret</street> <street>N-7005 Trondheim</street> <country>Norway</country></postal> <phone>+47 73 54 57 97</phone> <email>Harald@Alvestrand.no</email></address></author> <date month='October' year='1998' /> <area>General</area> <keyword>Internet Assigned Numbers Authority</keyword> <keyword>IANA</keyword> <abstract> <t> Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication algorithm for IPSec). To insure that such quantities have consistent values andH. Alvestrand, "Guidelinesinterpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). </t> <t> In order forWriting anthe IANAConsiderations Sectionto manage a given name space prudently, it needs guidelines describing the conditions under which new values can be assigned. If the IANA is expected to play a role inRFCs", BCP 26, RFC 2434, October 1998. Author's Address Carl Malamud PO Box 300 Sixes, OR 97476 US EMail: carl@media.org Malamud Expires April 9, 2004 [Page 21] draft-malamud-no-soliciting No-Solicit October 2003 Intellectual Property Statement The IETF takes no position regardingthevalidity or scopemanagement ofany intellectual property or other rightsa name space, the IANA must be given clear and concise instructions describing thatmightrole. This document discusses issues that should beclaimedconsidered in formulating a policy for assigning values topertaina name space and provides guidelines to document authors on theimplementation or use of the technology describedspecific text that must be included in documents that place demands on the IANA. </t></abstract></front> <seriesInfo name='BCP' value='26' /> <seriesInfo name='RFC' value='2434' /> <format type='TXT' octets='25092' target='ftp://ftp.isi.edu/in-notes/rfc2434.txt' /> <format type='HTML' octets='37535' target='http://xml.resource.org/public/rfc/html/rfc2434.html' /> <format type='XML' octets='26924' target='http://xml.resource.org/public/rfc/xml/rfc2434.xml' /> </reference> </references> <section title="Status of This Document"> <section title="RFC Category"> <t> This document will be submitted for publication as an Informational RFC. </t> </section> <section title="Document Repository"> <t>The source for this documentorcan be found at <eref target="http://trusted.resource.org/no-solicit"> http://trusted.resource.org/no-solicit</eref>. </t> </section> <section title="Discussion"> <t> Discussions of this draft may be directed towards theextentfollowing targets: <list style="symbols"> <t> The ietf-smtp mailing list discusses clarrifications and extensions towhich any license under such rights might or might notSMTP and can beavailable; neither does it represent that itfound at <eref target="http://www.imc.org/ietf-smtp/"> http://www.imc.org/ietf-smtp/</eref>. </t> <t>The <eref target="http://www.irtf.org/charters/asrg.html">Anti-Spam Research Group,</eref> a part of the <eref target="http://www.irtf.org/">Internet Research Task Force,</eref> maintains a mailing list at <eref target="https://www1.ietf.org/mailman/listinfo/asrg"> https://www1.ietf.org/mailman/listinfo/asrg</eref>. </t> <t> Comments may be sent directly to the author at <eref target="mailto:carl@media.org">carl@media.org</eref>. </t></list></t> </section> <section title="Changes From Previous Drafts"> <t>Changes from <eref target="http://trusted.resource.org/no-solicit/draft-malamud-no-soliciting-01.html"> draft-malamud-no-soliciting-01 </eref> to <eref target="http://trusted.resource.org/no-solicit/draft-malamud-no-soliciting-02.html"> draft-malamud-no-soliciting-02 </eref>: <list style="symbols"> <t>A real-world example of how the proposed service extension could be used has been added (see <xref target="scenario" />).</t> <t>A discussion of the relative implementation difficulty of <spanx style="verb">SYSTEM-WIDE</spanx> versus <spanx style="verb">PER-RECIPIENT</spanx> has been added (see <xref target="implementation" />). </t> <t>A discussion of the relationship of this proposal to centralized "do not spam" lists has been added (see <xref target="spam.list" />). </t> </list></t> <t>Changes from <eref target="http://trusted.resource.org/no-solicit/draft-malamud-no-soliciting-00.html"> draft-malamud-no-soliciting-00</eref> to <eref target="http://trusted.resource.org/no-solicit/draft-malamud-no-soliciting-01.html"> draft-malamud-no-soliciting-01</eref>: <list style="symbols"> <t>The two service extensions previously proposed ( <spanx style="verb">SYSTEM-WIDE-NO-SOLICITING</spanx> and <spanx style="verb">PER-MESSAGE-NO-SOLICITING</spanx>) have been collapsed into a single <spanx style="verb">NO-SOLICITING</spanx> service extension ( See <xref target="extension" />).</t> <t><spanx style="verb">PER-MESSAGE</spanx> hasmade any effortbeen changed toidentify any such rights. Information on the IETF's procedures with respect<spanx style="verb">PER-RECIPIENT</spanx> torights in standards-track and standards-related documentation can be found in BCP-11. Copies of claimsmore properly express the operation ofrights made available for publication and any assurancesthe extension (see <xref target="per-recipient" />).</t> <t>A solicitation class keyword syntax is introduced to allow different kinds oflicensesunsolicited mail to bemade available, orconsidered (see <xref target="keywords" />).</t> <t>The <spanx style="verb">Solicitation:</spanx> header has been supplemented with an extended <spanx style="verb">Received:</spanx> header syntax (see <xref target="received" />). </t> <t>A discussion of theresultuse of Enhanced Mail Status Codes has been included (see <xref target="enhanced" />). </t> <t>A more extensive IANA Considerations section has been added, including creation ofan attempt made to obtainageneral license or permission forSolicitation Keywords registry (see <xref target="iana" />).</t> </list></t> </section> </section> <section title="Transmittal"> <t>November 30, 2003</t> <t>The Honorable Timothy J. Muris, Chairman<vspace blankLines="0" /> The Federal Trade Commission<vspace blankLines="0" /> 600 Pennsylvania Avenue, N.W.<vspace blankLines="0" /> Washington, D.C. 20580<vspace blankLines="0" /> <eref target="mailto: remote-printer.Timothy_J_Muris/FTC@12023262012.iddd.tpc.int">remote-printer.Timothy_J_Muris/FTC@12023262012.iddd.tpc.int</eref> </t> <t>Dear Mr. Muris:</t> <t> On October 23, 2003, theuseU.S. Senate passed S.877, known as the <eref target="http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=108_cong_bills&docid=f:s877es.txt.pdf">CAN-SPAM Act of 2003.</eref> That bill provides, in part: <list style="empty"> <t><spanx style="emph">SEC. 109. DO-NOT-EMAIL REGISTRY.</spanx> </t> <t>(a) IN GENERAL.—Not later than 6 months after the date ofsuch proprietary rights by implementors or usersenactment of thisspecification can be obtained fromtitle, theIETF Secretariat. The IETF invites any interested party to bringCommission shall transmit toits attentionthe Senate Committee on Commerce, Science, and Transportation and the House of Representatives Committee on Energy and Commerce a report that— <list style="numbers"> <t>sets forth a plan and timetable for establishing a nationwide marketing Do-Not-E-mail registry;</t> <t>includes an explanation of anycopyrights, patents or patent applications,practical, technical, security, privacy, enforceability, or otherproprietary rights which may cover technologyconcerns thatmay be required to practice this standard. Please address the information totheIETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This documentCommission has regarding such a registry; andtranslations</t> <t>includes an explanation ofit mayhow the registry would becopied and furnishedapplied with respect toothers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole orchildren with e-mail accounts. </t> </list></t> </list></t> <t> I have read with some interest comments by you and Mr. Beales inpart, without restrictionthe press regarding the practicality ofany kind, providedimplementing a centralized "do-not-spam" list. I share your feelings thatthe above copyright noticea centralized do-not-call list makes sense andthis paragraph are included on allcertainly has been popular, but that email has vastly different characteristics from telephone numbers, making suchcopies and derivative works. However,a list impractical. </t> <t>I hope that in your deliberations on thisdocument itself may not be modifiedsubject and inany way, such as by removing the copyright notice or referencesyour report to theInternet Society or other Internet organizations, exceptCongress you will consider decentralized approaches to this problem, such asneeded forthepurpose of developing Internet standardsone detailed inwhich casetheprocedures for copyrights defined inproposed SMTP extension described here: <list style="empty"> <t> <eref target="http://trusted.resource.org/no-solicit/"> http://trusted.resource.org/no-solicit/</eref> </t> </list> </t> <t> I should note that theInternet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and willabove-referenced proposal is notbe revoked bytheInternet Society or its successors or assignees. This document andonly way to accomplish theinformation contained herein is provided on an "AS IS" basisgoal of non-centralized non-solicitation notification, andTHE 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 April 9, 2004 [Page 22] draft-malamud-no-soliciting No-Solicit October 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor functioniscurrently provided by the Internet Society. Malamud Expires April 9, 2004 [Page 23]brought to your attention simply to demonstrate that non-centralized approaches to this important problem are possible and practical. </t> <t>Please don't hesitate to let me know if you would like more information or if I can answer any questions. </t> <t> Sincerely yours,</t> <t> Carl Malamud<vspace blankLines="0" /> Memory Palace Press<vspace blankLines="0" /> P.O. Box 300<vspace blankLines="0" /> Sixes, Oregon 97476<vspace blankLines="0" /> <eref target="mailto:carl@media.org">carl@media.org</eref> </t> <t>cc: <list style="empty"> <t> Mr. J. Howard Beales, III<vspace blankLines="0" /> Bureau of Consumer Protection<vspace blankLines="0" /> The Federal Trade Commission<vspace blankLines="0" /> 600 Pennsylvania Avenue, N.W.<vspace blankLines="0" /> Washington, D.C. 20580<vspace blankLines="0" /> <eref target="mailto:hbeales@ftc.gov">hbeales@ftc.gov</eref> <vspace blankLines="2" /> The Honorable Edward J. Markey<vspace blankLines="0" /> U.S. House of Representatives<vspace blankLines="0" /> 2108 Rayburn House Office Building<vspace blankLines="0" /> Washington, DC 20515<vspace blankLines="0" /> <eref target="mailto:ed@markey.house.gov">ed@markey.house.gov</eref> </t> </list> </t> </section> </back> </rfc> ----