Network Working Group C. Malamud Internet-Draft Memory Palace Press Expires: July 24, 2004 January 24, 2004 A No Soliciting SMTP Service Extension draft-malamud-no-soliciting-04 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 24, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This Internet-Draft proposes an extension to SMTP for an electronic mail equivalent to the real-world "No Soliciting" sign. In addition to the service extension, a new message header and extensions to the existing "received" message header are described. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119]. Malamud Expires July 24, 2004 [Page 1] draft-malamud-no-soliciting No-Solicit January 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 The Spam Pandemic . . . . . . . . . . . . . . . . . . . . . 3 1.2 No Soliciting in the Real World . . . . . . . . . . . . . . 3 1.3 A Distributed No Soliciting Extension . . . . . . . . . . . 5 2. The No-Soliciting SMTP Service Extension . . . . . . . . . . 6 2.1 The SYSTEM-WIDE Option . . . . . . . . . . . . . . . . . . . 6 2.2 Solicitation Class Keywords . . . . . . . . . . . . . . . . 7 2.2.1 Note on Choice of Keywords . . . . . . . . . . . . . . . . . 8 2.3 The PER-RECIPIENT Option . . . . . . . . . . . . . . . . . . 8 2.4 Use of Enhanced Mail Status Codes . . . . . . . . . . . . . 9 2.5 Solicitation Mail Header . . . . . . . . . . . . . . . . . . 10 2.6 Insertion of Solicitation Keywords in Trace Fields . . . . . 10 2.7 Relay of Messages . . . . . . . . . . . . . . . . . . . . . 11 2.8 Recommendations for Developers and Administrators . . . . . 11 3. Use of the Extension . . . . . . . . . . . . . . . . . . . . 12 3.1 Relationship to Centralized Approaches . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 5.1 The Mail Parameters Registry . . . . . . . . . . . . . . . . 16 5.2 Trace Fields . . . . . . . . . . . . . . . . . . . . . . . . 16 5.3 The Solicitation Class Keywords Registry . . . . . . . . . . 16 5.3.1 Guidance on Keyword Specification . . . . . . . . . . . . . 16 5.4 The Solicitation Mail Header . . . . . . . . . . . . . . . . 17 6. Author's Acknowledgements . . . . . . . . . . . . . . . . . 17 Informative References . . . . . . . . . . . . . . . . . . . 17 Normative References . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . 20 A. Status of This Document [To Be Removed Upon Publication] . . 20 A.1 RFC Category . . . . . . . . . . . . . . . . . . . . . . . . 20 A.2 Document Repository . . . . . . . . . . . . . . . . . . . . 21 A.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 21 A.4 Changes From Previous Drafts . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . 23 Malamud Expires July 24, 2004 [Page 2] draft-malamud-no-soliciting No-Solicit January 2004 1. Introduction 1.1 The Spam Pandemic Unsolicited Bulk Email (UBE), otherwise known as spam, has become as one of the most pressing issues on the Internet. One oft-quoted study estimated that spam would cost businesses $13 billion in 2003.[Ferris] In April 2003, AOL reported that it had blocked 2.37 billion pieces of UBE in a single day. [CNET] And, in a sure sign that UBE has become of pressing concern, numerous politicians have begun to issue pronouncements and prescriptions for fighting this epidemic.[Schumer][FTC] A variety of mechanisms from the technical community have been proposed and/or implemented to fight UBE: o Whitelists are lists of known non-spammers. For example, Habeas, Inc. maintains a Habeas User List (HUL) of people who have agreed to not spam. By including a haiku in email headers and enforcing copyright on that ditty, they enforce their anti-spamming terms of service. [Habeas] o Blacklists are lists of known spammers or ISPs that allow spam.[ROSKO] o Spam filters run client-side or server-side to filter out spam based on whitelists, blacklists, and textual and header analysis.[Assassin] o A large number of documents address the overall technical considerations for the control of UBE [I-D.crocker-spam-techconsider], operational considerations for SMTP agents[RFC2505], and various extensions to the protocols to support UBE identification and filtering. [I-D.danisch-dns-rr-smtp][I-D.daboo-sieve-spamtest][I-D.crouzet-amtp] o Various proposals have been advanced for "do not spam" lists, akin to the Federal Trade Commission's "Do Not Call" list for telemarketers.[FTC.TSR] 1.2 No Soliciting in the Real World Municipalities frequently require solicitors to register with the town government. And, in many cases, the municipalities prohibit soliciting in residences where the occupant has posted a sign. The town of West Newbury, Massachusetts, for example, requires: Malamud Expires July 24, 2004 [Page 3] draft-malamud-no-soliciting No-Solicit January 2004 "It shall be unlawful for any canvasser or solicitor to enter the premises of a resident or business who has displayed a 'No Trespassing' or 'No Soliciting' sign or poster. Further, it shall be unlawful for canvassers or solicitors to ignore a resident or business person's no solicitation directive or remain on private property after its owner has indicated that the canvasser or solicitor is not welcome." [Newbury] Registration requirements for solicitors, particularly those soliciting for political or religious reasons, have been the subject of a long string of court cases. However, the courts have generally recognized that individuals may post "No Soliciting" signs and the government may enforce the citizen's desire. In a recent case where Jehovah's Witnesses challenged a registration requirement in the city of Stratton, Connecticut, saying they derived their authority from the Scriptures, not the city. However, the court noted: "A section of the ordinance that petitioners do not challenge establishes a procedure by which a resident may prohibit solicitation even by holders of permits. If the resident files a 'No Solicitation Registration Form' with the mayor, and also posts a 'No Solicitation' sign on his property, no uninvited canvassers may enter his property ..." [Watchtower] Even government, which has a duty to promote free expression, may restrict the use of soliciting on government property. In one case, for example, a school district was allowed to give access to its internal electronic mail system to the union that was representing teachers, but was not required to do so to a rival union that was attempting to gain the right to represent the teachers. The court held that where property is not a traditional public forum "and the Government has not dedicated its property to First Amendment activity, such regulation is examined only for reasonableness."[Perry] The courts have consistently held that the state has a compelling public safety reason for regulating solicitation. In Cantwell v. Connecticut, the Supreme Court held that "a State may protect its citizens from fraudulent solicitation by requiring a stranger in the community, before permitting him publicly to solicit funds for any purpose, to establish his identity and his authority to act for the cause which he purports to represent."[Cantwell] And, in Martin v. City of Struthers, the court noted that "burglars frequently pose as canvassers, either in order that they may have a pretense to discover whether a house is empty and hence ripe for burglary, or for the purpose of spying out the premises in order that they may return later."[Martin] The public safety issue applies very much to email, where viruses can easily be delivered, in contrast to telephone Malamud Expires July 24, 2004 [Page 4] draft-malamud-no-soliciting No-Solicit January 2004 solicitations where public safety is not nearly as much an issue. This analysis is very U.S.-centric, which may be appropriate given that 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: o In Hong Kong, offices frequently post "no soliciting" signs. o In the United Kingdom, where door-to-door peddlers are fairly common, "no soliciting" signs are also common. o In Australia, where door-to-door does not appear to be a pressing social problem, there was legislation passed which outlawed the practice of placing ads under wipers of parked cars. o In France, which has a long tradition of door-to-door solicitation, apartment buildings often use trespass laws to enforce "no solicitation" policies. o In the Netherlands, where door-to-door solicitation is not a pressing issue, there is a practice of depositing free publications in mailboxes. The postal equivalent of "no spam" signs are quite prevalent and serve notice that the publications are not desired. 1.3 A Distributed No Soliciting Extension Many of the anti-spam proposals that have been advanced have great merit, however none of them give notice to an SMTP agent in the process of delivering mail that the receiver does not wish to receive solicitations. Such a virtual sign would serve two purposes: o It would allow the receiving system to "serve notice" that a certain class of electronic mail is not desired, whether or not such a message is properly identified as belonging to that class. o If a message is properly identified as belonging to a certain class and that class of messages is not desired, transfer of the message can be eliminated. Rather than filtering after delivery, elimination of the message transfer can save network bandwidth, disk space, and processing power. This memo details a series of extensions to SMTP that have the following characteristics: o A service extension is described that allows a receiving Mail Malamud Expires July 24, 2004 [Page 5] draft-malamud-no-soliciting No-Solicit January 2004 Transport Agent (MTA) to signal the sending MTA that no soliciting is in effect. o A header field for the sender of the message is defined that allows the sender to flag a message as conforming to a certain class. o Trace fields for intermediate MTAs are extended to allow the intermediate MTA to signal that a message conforms to a certain class. Allowing the sender of a message to tag a message as being, for example, unsolicited commercial email with adult content, allows "good" spammers to conform to legal content labelling requirements by governmental authorities or conventions imposed by "whitelist" services. For senders of mail who choose not to abide by these conventions, the intermediate trace fields defined here allow the destination MTA or a designated intermediate MTA to perform appropriate dispositions on the received message. This distributed approach to controlling UBE is advanced as an alternative to centralized "do-not-spam" lists. The concluding section of this document details how the decentralized approach would work in practice and contrasts this approach to a centralized list. 2. The No-Soliciting SMTP Service Extension Per [RFC2821], a "NO-SOLICITING" SMTP service extension is defined. The service extension is declared during the initial "EHLO" SMTP exchange. The extension has one optional parameter and zero or more solicitation class keywords. Using the notation as described in the Augmented BNF[RFC2234], the syntax is: No-Soliciting-Service = "NO-SOLICITING" ( "SYSTEM-WIDE" [ SP Solicitation-keywords ] ) / "PER-RECIPIENT" ) As will be further described below, the "Solicitation-keywords" construct is used to indicate which messages are accepted or not. In the case of the "SYSTEM-WIDE" option, this information is indicated during the initial "EHLO" exchange. In the case of the "PER-RECIPIENT" option, this information is not present in the initial exchange and is instead presented as part of the "MAIL-FROM" command. 2.1 The SYSTEM-WIDE Option "NO-SOLICITING SYSTEM-WIDE" indicates that no soliciting is in effect Malamud Expires July 24, 2004 [Page 6] draft-malamud-no-soliciting No-Solicit January 2004 for all messages delivered to this system. It is equivalent to the sign on the door of an office building announcing a company-wide policy. The parameter is presented during the initial exchange between sender and receiver: R: S: R: 220 trusted.example.com SMTP service ready S: EHLO untrusted.example.com R: 250-trusted.example.com says hello R: 250-NO-SOLICITING SYSTEM-WIDE ADV (The "ADV" keyword is one of several possible values and is described in the following section.) A similar proposal was advanced in 1999 by John Levine and Paul Hoffman. This proposal used the SMTP greeting banner to specify that unsolicited bulk email is prohibited on a particular system through the use of the "NO UCE" keyword.[Levine] As the authors note, their proposal has the potential of overloading the semantics of the greeting banner, which may also be used for other purposes (see, e.g., [Malamud]). 2.2 Solicitation Class Keywords The "NO-SOLICITING" service extension uses solicitation class keywords to signify classes of solicitations that are not accepted. Keywords are separated by commas and follow the "SYSTEM-WIDE" parameter. As described subsequently, solicitation class keywords are also used with the "PER-RECIPIENT" variant of this extension as well as with the "Solicitation:" and trace field message headers. Three solicitation class keywords are defined in this draft: Keywords Description Reference --------- -------------------------------- --------- MAPS-UBE Unsolicited Bulk Email http://mail-abuse.org/ ADV Unsolicited Commercial Email http://www.spamlaws.com/ ADV:ADLT Sexually Explicit Commercial Mail http://www.spamlaws.com/ MAPS-UBE is the standard advanced by the Mail Abuse Prevention System (MAPS), which states: An electronic message is "spam" IF: (1) the recipient's personal identity and context are irrelevant because the message is equally applicable to many other potential recipients; AND (2) the Malamud Expires July 24, 2004 [Page 7] draft-malamud-no-soliciting No-Solicit January 2004 recipient has not verifiably granted deliberate, explicit, and still-revocable permission for it to be sent; AND (3) the transmission and reception of the message appears to the recipient to give a disproportionate benefit to the sender. Numerous states have adopted the "ADV" and "ADV:ADLT" conventions. We cite the spamlaws.com site as a reference because it provides an excellent summary of the definitions and pointers to the relevant statutes. There is no default keyword for the service. In other words, the following example is a "no-op": R: 250-NO-SOLICITING SYSTEM-WIDE Additional solicitation class keywords may be defined and registered as specified in Section 5.3. Multiple solicitation class keywords are separated by a comma to form a list: Solicitation-keywords = Solicit-word 0*("," Solicit-word) Solicit-word = [ "MAPS-UBE" / "ADV" / "ADV:ADLT" / x-word / registered-word ] x-word = ["x-" / "X-"] 1*(wordchars) registered-word = ALPHA 0*(wordchars) ; registered-word(s) are registered ; with the IANA wordchars = 1*("-" / "_" / ":" / ALPHA / DIGIT) Developers should note that a "registered-word" MAY contain a trailing wild card as part of the specification. See Section 5.3.1 for more details. 2.2.1 Note on Choice of Keywords This document does not specify which keywords shall or shall not be used on a particular message. The requirement to use a particular keyword is a policy decision well outside the scope of this document. In particular, the three keywords described in this document are for illustrative purposes only and it is expected that relevant policy bodies (e.g., a government, ISP, or other institution) will specify appropriate keywords, the definition of the meaning of those keywords, and any other policy requirements, such as a requirement to use or not use this extension in particular circumstances. 2.3 The PER-RECIPIENT Option The "NO-SOLICITING PER-RECIPIENT" extension specifies that each "MAIL Malamud Expires July 24, 2004 [Page 8] draft-malamud-no-soliciting No-Solicit January 2004 FROM" command must identify if a message is a solicitation. The presence of this extension is identified during the initial greeting: R: S: R: 220 trusted.example.com SMTP service ready S: EHLO untrusted.example.com R: 250-trusted.example.com says hello R: 250-NO-SOLICITING PER-RECIPIENT Additionally, "SOLICIT" is defined as a parameter for the "MAIL FROM" command. The "SOLICIT" parameter is followed by an optional equal sign and a comma separated list of solicitation class keywords. The syntax for this parameter is: Mail-From-Solicit-Parameter = "SOLICIT" "=" Solicitation-keywords Note that white space is not permitted in this production. As an informational message, the "550" or "250" replies to the "RCPT TO" command may also contain the "SOLICIT" parameter. The receiving system may decide on a per-user basis the appropriate disposition of messages: S: MAIL FROM: SOLICIT=ADV,MAPS-UBE S: RCPT TO: R: 250 ... Recipient ok S: RCPT TO: R: 550 ... SOLICIT=ADV In the previous example, the receiving MTA returned a "550" status code, indicating that one message was being rejected. Note that the implementation also echoes back the currently set keywords for that user on the "550" error 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 [RFC3463] and a message is rejected based on the presence of a "SOLICIT" parameter, the correct error message to return is "5.7.1", defined as "the sender is not authorized to send to the destination ... [because] of per-host or per-recipient filtering." Malamud Expires July 24, 2004 [Page 9] draft-malamud-no-soliciting No-Solicit January 2004 2.5 Solicitation Mail Header Per [RFC2822], a new "Solicitation:" header field is defined which contains one or more solicitation class keywords. To: Coupon Clipper From: Spam King Solicitation: ADV,ADV:ADLT Several proposals, particularly legal ones, have suggested requiring the use of keywords in the "Subject:" header. While embedding information in the "Subject:" header may provide visual cues to end users, it does not provide a straightforward set of cues for computer programs such as mail transfer agents. As with embedding a "no solicitation" message in a greeting banner, this overloads the semantics of the "Subject:" header. Of course, there is no reason why both mechanisms can't be used, and in any case the "Solicitation:" header could be automatically inserted by the sender's Mail User Agent (MUA) based on the contents of the subject line. 2.6 Insertion of Solicitation Keywords in Trace Fields The "Solicitation:" mail header is only available to the sending client. RFCs 2821 and 2822 are quite specific that intermediate MTAs shall not change message headers, with the sole exception of the "Received:" trace field. Since many current systems use an intermediate relay to detect unsolicited mail, an addition to the "Received:" header is described. [RFC2821] documents the following productions for the "Received:" header in a mail message: With = "WITH" FWS Protocol CFWS Protocol = "ESMTP" / "SMTP" / Attdl-Protocol Additionally, [RFC2822] defines a comment field as follows: comment = "(" *([FWS] ccontent) [FWS] ")" Solicitation Keywords are inserted as comments using the following production, which is based on the "Mail-From-Solicit-Parameter" defined in Section 2.3 above: With-Solicit = "WITH" FWS Protocol "(" [FWS] Mail-From-Solicit-Parameter [FWS] ")" Malamud Expires July 24, 2004 [Page 10] draft-malamud-no-soliciting No-Solicit January 2004 An example of a Received: header from a conforming MTA is as follows: Received: by foo-mta.example.com with ESMTP (SOLICIT=ADV,ADV:ADLT) ; Sat, 9 Aug 2003 16:54:42 -0700 (PDT) It should be noted that keywords presented in trace fields may not agree with those found in the "Solicitation:" header and trace fields may exist even if the header is not present. When determing which keywords are applicable to a particular exchange of messages, implementors SHOULD examine any keywords found in the "Solicitation:" header. Implementors MAY examine other keywords found in the trace fields. 2.7 Relay of Messages The "NO-SOLICITING SYSTEM-WIDE" service extension, if present, applies to all messages handled by the receiving Message Transfer Agent (MTA), including those messages intended to be relayed to another system. When relaying a message which was received in which the "SOLICIT" parameter was set on the "MAIL FROM" command, the MTA MUST also set the "SOLICIT" parameter when delivering the message to an SMTP server that supports this extension. The "SOLICIT" parameter on a "MAIL FROM" command can be derived from a variety of sources, including receipt of a message from a conforming SMTP server. An SMTP server MAY, for operational reasons as defined in Section 7.7 of [RFC2821], set this parameter after detecting the presence of the "Solicitation:" or extended "Received:" message header field or by using other system-specific techniques. Implementers should be aware that the "NO-SOLICITING" service extension is not a guaranteed end-to-end service. Specifically, intermediate relays that do not support this service may "lose" the per-message parameters. However, the "Solicitation:" header and any trace fields inserted during the message transfer process will persist, and downstream MTAs MAY use this extension when relaying a message which was received without this extension. 2.8 Recommendations for Developers and Administrators Developers that implement the "NO-SOLICITING" service extension SHOULD NOT enable the service as a default. There are some indications that some policy makers may view a default filtering in software as a prior restraint on commercial speech. In other words, because the person installing the software did not make an explicit Malamud Expires July 24, 2004 [Page 11] draft-malamud-no-soliciting No-Solicit January 2004 choice to enable a certain type of filtering, some might argue that such filtering was not desired. Likewise, it is recommended that a system administrator installing software SHOULD NOT enable "PER-RECIPIENT" 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 SYSTEM-WIDE on a receiving MTA is fairly trivial. For example, on the popular sendmail [1] package, a few minor changes need to be made to three files to provide the appropriate "EHLO" announcement. 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. The service extension allows a mail recipient to notify the sender that certain forms of electronic mail are not desired and thus gives policy makers a mechanism for requiring senders of such electronic mail to identify their missives any penalties for failure to do so. 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 Malamud Expires July 24, 2004 [Page 12] draft-malamud-no-soliciting No-Solicit January 2004 Congressional Record [2] or the Federal Register [3] would both be considered adequate for 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 ""WMA". 2. The appropriate authority (e.g., the Clerk of the House [4] or an appropriate executive branch official) would register this definition with the IANA using the template as described in Section 5 and sending the completed template to iana@iana.org [5]. 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 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 "WMA" keyword, the address would be scrubbed from the list. 5. Reputable users of email lists would add a "Solicitation: WMA" 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 WMA". These systems receiving mail on behalf of the designated domain might also be configured to run a spam identification utility, such as SpamAssasin [6] or SpamBouncer [7]. 7. End users would configure their mail filters to filter out any properly tagged messages (e.g., "Solicitation: WMA") 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). Malamud Expires July 24, 2004 [Page 13] draft-malamud-no-soliciting No-Solicit January 2004 8. Unagressive end users would simply delete their spam folder periodically. More paranoid end users would check 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 WMA 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 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: 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. In addition, placing an email address on a centralized list has a significant risk that the list will be used by some to send even more unwanted mail. o From the point of view of the government, a centralized list requires significant resources to administer and maintain. 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 continually "scrub" lists that are received. 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 Malamud Expires July 24, 2004 [Page 14] draft-malamud-no-soliciting No-Solicit January 2004 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 "NO-SOLICITING" assertion could both be factors taken into consideration in levying fines or taking other corrective actions. 4. Security Considerations This extension does not provide authentication of senders or other measures intended to promote security measures during the message exchange process. In particular, this document does not address the circumstances under which a sender of electronic mail should or should not use this extension and does not address the issues of whether consent to send mail has been granted. This might lead to a scenario in which a sender of electronic mail begins to use this extension well before the majority of end users have begun to use it. In this scenario, the sender might wish to use the absence of the extension on the receiving MTA as an implication of consent to receive mail. Non-use of the "NO-SOLICITING" extension by a receiving MTA SHALL NOT indicate consent. 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. Documentation of the use of comments in trace fields. 3. Creation of a Solicitation Class Keywords registry. 4. Creation of a "Solicitation:" mail header, which does not currently raise any IANA considerations. Malamud Expires July 24, 2004 [Page 15] draft-malamud-no-soliciting No-Solicit January 2004 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. [] The parameters subregistry would need to be modified as follows: Service Ext EHLO Keyword Parameters Reference ----------- ------------ ----------- --------- No Soliciting NO-SOLICITING SYSTEM-WIDE [] No Soliciting NO-SOLICITING PER-RECIPIENT [] 5.2 Trace Fields The Mail Parameters registry would need to be modified to note the use of the comment facility in trace fields to indicate Solicitation Class Keywords. 5.3 The Solicitation Class Keywords Registry A new registry (or a subregistry of Mail Parameters) would need to be established for Solicitation Class Keywords. The registry would contain the following fields: 1. Keyword name (e.g., "MAPS-UBE"). 2. Keyword description (e.g., "Unsolicited Bulk Email"). 3. Keyword reference (e.g., ""). Per the policies outlined in [RFC2434], it is recommended that the IESG request the IANA to appoint a Designated Expert to administer this registry. Authority 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.3.1 Guidance on Keyword Specification A set of keywords beginning with a common prefix may be registered Malamud Expires July 24, 2004 [Page 16] draft-malamud-no-soliciting No-Solicit January 2004 with the IANA by specifying the prefix followed by wild card specified as a single asterisk ("*") and shall be considered a single registry entry. The "keyword reference" field of the registry SHOULD contain a reference that documents the values this solicitation class keyword may contain if the trailing wild card is specified in the "keyword name" field of the registry. Note to Developers: In designing client and server solutions based on this extension, it is important to remember to design your code to take into account the possible use of these trailing wildcards. See the "Solicitation-keywords" production in Section 2.2 for valid characters and delimiters. This facility can be used to insert a "score" or category tag by an intermediate MTA. For example, a solicitation class keyword "WMA:*" might be used as follows: Received: by foo-mta.example.com with ESMTP (WMA:SBRule:Haven_Domain,WMA:SBScore:10) ; Sat, 9 Aug 2003 16:54:42 -0700 (PDT) 5.4 The Solicitation Mail Header There is currently no registry defined for mail headers. If such a registry were to exist, the "Solicitation:" header field would need to be added to it. 6. Author's Acknowledgements The author would like to thank Rebecca Malamud 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, Steven M. Bellovin, Kent Crispin, Dave Crocker, Curtis Generous, Paul Hoffman, John Levine, Keith Moore, Ned Freed, Paul Vixie, and Pindar Wong kindly provided reviews of the draft and/or suggestions for improvement. Information about soliciting outside the U.S. was received from Rob Blokzijl, Jon Crowcroft, Christian Huitema, Geoff Huston, and Pindar Wong. John Levine pointed out the contrast between this proposal and "do not spam" lists. As always, all errors and omissions are the responsibility of the author. Informative References [Assassin] Mason, J., "Spamassassin - Mail Filter to Identify Spam Using Text Analysis", Version 2.55, May 2003, . [CNET] CNET News.Com, "AOL touts spam-fighting prowess", April 2003, . [Cantwell] U.S. Supreme Court, "Cantwell v. State of Connecticut", 310 U.S. 296 (1940), May 1940, . [FTC] Federal Trade Commission, "Federal, State, Local Law Enforcers Target Deceptive Spam and Internet Scams", November 2002, . [FTC.TSR] Federal Trade Commission, "Telemarketing Sales Rule", Federal Register Vol. 68, No. 19, January 2003, . [Ferris] Associated Press, "Study: Spam costs businesses $13 billion", January 2003, . [Habeas] Habeas, Inc., "Habeas Compliant Message", April 2003, . [I-D.crocker-spam-techconsider] Crocker, D., "Technical Considerations for Spam Control Mechanisms", draft-crocker-spam-techconsider-02 (work in progress), May 2003. [I-D.crouzet-amtp] Crouzet, B., "Authenticated Mail Transfer Protocol", draft-crouzet-amtp-01 (work in progress), October 2003. [I-D.daboo-sieve-spamtest] Daboo, C., "SIEVE Spamtest and Virustest Extensions", draft-daboo-sieve-spamtest-04 (work in progress), October 2003. [I-D.danisch-dns-rr-smtp] Danisch, H., "A DNS RR for simple SMTP sender authentication", draft-danisch-dns-rr-smtp-03 (work in progress), October 2003. [Levine] Levine, J. and P. Hoffman, "Anti-UBE and Anti-UCE Keywords Malamud Expires July 24, 2004 [Page 18] draft-malamud-no-soliciting No-Solicit January 2004 in SMTP Banners", Revision 1.1, March 1999, . [Malamud] Malamud, C., "An Internet Prayer Wheel", Mappa.Mundi Magazine, August 1999, . [Martin] U.S. Supreme Court, "Martin v. City of Struthers, Ohio", 319 U.S. 141 (1943), May 1943, . [Newbury] The Town of West Newbury, Massachusetts, "Soliciting/ Canvassing By-Law", Chapter 18 Section 10, March 2002, . [Perry] U.S. Supreme Court, "Perry Education Association v. Perry Local Educators' Association", 460 U.S. 37 (1983), February 1983, . [RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999. [ROSKO] Spamhaus.Org, "Register of Known Spam Operations", November 2003, . [Schumer] Charles, C., "Schumer, Christian Coalition Team Up to Crack Down on Email Spam Pornography", June 2003, . [Watchtower] 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, . Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. Malamud Expires July 24, 2004 [Page 19] draft-malamud-no-soliciting No-Solicit January 2004 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003. URIs [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] Malamud Expires July 24, 2004 [Page 20] draft-malamud-no-soliciting No-Solicit January 2004 [15] [16] Author's Address Carl Malamud Memory Palace Press PO Box 300 Sixes, OR 97476 US EMail: carl@media.org Appendix A. Status of This Document [To Be Removed Upon Publication] A.1 RFC Category This document will be submitted for publication as a Proposed Standard. 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 ietf-smtp mailing list which can be found at http://www.imc.org/ietf-smtp/. Comments may be sent directly to the author at carl@media.org [8]. A.4 Changes From Previous Drafts Changes from draft-malamud-no-soliciting-03 [9] to draft-malamud-no-soliciting-04 [10]: o The Note on Open Issues has been removed and the abstract has been made more precise. o All examples now use subdomains of example.com. o The "No-Soliciting-Service" production has been changed to make clear that a set of keywords is not presented when the "PER-RECIPIENT" option is used. See Section 2. Malamud Expires July 24, 2004 [Page 21] draft-malamud-no-soliciting No-Solicit January 2004 o A Note on Keywords has been added to make clear that the initial three keywords choosen were simply to bootstrap the registry and that the matter of which keywords to use and the definition of those words is a policy decision well outside the scope of this document. See Section 2.2.1. o Solicitation Class Keywords are now carried as a comment to the "ESMTP" protocol and additional language has been added clarifying the relationship of keywords in "received:" headers to those in the "Solicitation:" header. See Section 2.6. o Some language has been added to further clarify what should happen when dealing with a server that doesn't support the extension. See Section 2.7. o The Security Considerations section has been made more explicit. See Section 4. o The Solicitation Class Keywords Registry has been clarified to permit the use of a trailing wildcard in the "keyword name" field. See Section 5.3. Changes from draft-malamud-no-soliciting-02 [11] to draft-malamud-no-soliciting-03 [12]: o A discussion of Open Issues has been preprended to the document and comments are requested. Changes from draft-malamud-no-soliciting-01 [13] to draft-malamud-no-soliciting-02 [14]: 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 [15] to draft-malamud-no-soliciting-01 [16]: o The two service extensions previously proposed ( "SYSTEM-WIDE-NO-SOLICITING" and "PER-MESSAGE-NO-SOLICITING") have been collapsed into a single "NO-SOLICITING" service extension ( See Section 2). Malamud Expires July 24, 2004 [Page 22] draft-malamud-no-soliciting No-Solicit January 2004 o "PER-MESSAGE" has been changed to "PER-RECIPIENT" to more properly express the operation of the extension (see Section 2.3). o A solicitation class keyword syntax is introduced to allow different kinds of unsolicited mail to be considered (see Section 2.2). o The "Solicitation:" header has been supplemented with an extended "Received:" header syntax (see Section 2.6). o A discussion of the use of Enhanced Mail Status Codes has been included (see Section 2.4). o A more extensive IANA Considerations section has been added, including creation of a Solicitation Keywords registry (see Section 5). Malamud Expires July 24, 2004 [Page 23] draft-malamud-no-soliciting No-Solicit January 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Malamud Expires July 24, 2004 [Page 24] draft-malamud-no-soliciting No-Solicit January 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Malamud Expires July 24, 2004 [Page 25]