Network Working Group C. Malamud Request for Comments: 3865 Memory Palace Press Category: Standards Track September 2004 A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004).
AbstractThis document proposes an extension to Soliciting Simple Mail Transfer Protocol (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.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Spam Pandemic. . . . . . . . . . . . . . . . . . . . 3 1.2. No Soliciting in the Real World. . . . . . . . . . . . . 4 1.3. No Soliciting and Electronic Mail. . . . . . . . . . . . 5 2. The No-Soliciting SMTP Service Extension . . . . . . . . . . . 6 2.1. The EHLO Exchange. . . . . . . . . . . . . . . . . . . . 7 2.2. Solicitation Class Keywords. . . . . . . . . . . . . . . 7 2.2.1. Note on Choice of Solicitation Class Keywords. . 8 2.3. The MAIL FROM Command. . . . . . . . . . . . . . . . . . 9 2.4. Error Reporting and Enhanced Mail Status Codes . . . . . 10 2.5. Solicitation Mail Header . . . . . . . . . . . . . . . . 10 2.6. Insertion of Solicitation Keywords in Trace Fields . . . 11 2.7. Relay of Messages. . . . . . . . . . . . . . . . . . . . 12 2.8. No Default Solicitation Class. . . . . . . . . . . . . . 12 3. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4.1. The Mail Parameters Registry . . . . . . . . . . . . . . 13 4.2. Trace Fields . . . . . . . . . . . . . . . . . . . . . . 14 4.3. The Solicitation Mail Header . . . . . . . . . . . . . . 14 5. Author's Acknowledgements . . . . . . . . . . . . . . . . . . 14 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Normative References . . . . . . . . . . . . . . . . . . 15 6.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Collected ABNF Descriptions (Normative) . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 19
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 [ROKSO]. o Spam filters run client-side or server-side to filter out spam based on whitelists, blacklists, and textual and header analysis [Assassin]. o A large number of documents address the overall technical considerations for the control of UBE [crocker-spam-techconsider], operational considerations for SMTP agents [RFC2505], and various extensions to the protocols to support UBE identification and filtering [danisch-dns-rr-smtp][daboo-sieve-spamtest][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]. 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 [RFC2119].
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 solicitations where public safety is not nearly as much an issue. This analysis is U.S.-centric, which is partly due to the background of the author. However, the concept of prohibiting unwanted solicitation does carry over to other countries: o In Hong Kong, offices frequently post "no soliciting" signs. o In the United Kingdom, where door-to-door peddlers are fairly common, "no soliciting" signs are also common. o In Australia, where door-to-door does not appear to be a pressing social problem, there was legislation passed which outlawed the practice of placing ads under wipers of parked cars. o In France, which has a long tradition of door-to-door solicitation, apartment buildings often use trespass laws to enforce "no solicitation" policies. o In the Netherlands, where door-to-door solicitation is not a pressing issue, there is a practice of depositing free publications in mailboxes. The postal equivalent of "no spam" signs are quite prevalent and serve notice that the publications are not desired.
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 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 is in a certain class. Allowing the sender of a message to tag a message as being, for example, unsolicited commercial email with adult content, allows "good" spammers to conform to legal content labelling requirements by governmental authorities, license agreements with service providers, or conventions imposed by "whitelist" services. For senders of mail who choose not to abide by these conventions, the intermediate trace fields defined here allow the destination MTAs to perform appropriate dispositions on the received message. This extension provides a simple mean for senders, MTAs, and receivers to assert keywords. This extension does not deal with any issues of authentication or consent. 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, consisting of zero or more solicitation class keywords. Using the notation as described in the Augmented BNF [RFC2234], the syntax is: No-Soliciting-Service = "NO-SOLICITING" [ SP Solicitation-keywords ] As will be further described below, the "Solicitation-keywords" construct is used to indicate which classes of messages are not desired. A keyword that is presented during the initial "EHLO" exchange applies to all messages exchanged in this session. As will also be further described below, additional keywords may be specified on a per-recipient basis as part of the response to a "RCPT TO" command.
The initial set of solicitation class keywords all begin with a domain name with the labels reversed, followed by a colon. For example, the domain name "example.com" could be used to form the beginning of a solicitation class keyword of "com.example:". The solicitation class keyword is then followed by an arbitrary set of characters drawn from the following construct: Solicitation-keywords = word 0*("," word) ; length of this string is limited ; to <= 1000 characters word = ALPHA 0*(wordchar) wordchar = ("." / "-" / "_" / ":" / ALPHA / DIGIT) A solicitation class keyword MUST be less than 1000 characters. Note however that a set of keywords used in the operations defined in this document must also be less than 1000 characters. Implementors are thus advised to keep their solicitation class keywords brief. Any registrant of a domain name may define a solicitation class keyword. Discovery of solicitation class keywords is outside the scope of this document. However, those registrants defining keywords are advised to place a definition of their solicitation class keywords on a prominent URL under their control such that search engines and other discovery mechanisms can find them. While this document defines solicitation class keywords as beginning with a reversed domain name followed by a colon (":"), future RFCs may define additional mechanisms that do not conflict with this naming scheme.
means. By using the solicitation class keywords approach, the mail infrastructure remains a neutral mechanism, allowing different definitions to co-exist. Section 2.4 for more on error reporting. The receiving system may decide on a per-message basis the appropriate disposition of messages: R: <wait for connection on TCP port 25> S: <open connection to server> R: 220 trusted.example.com SMTP service ready S: EHLO untrusted.example.com R: 250-trusted.example.com says hello R: 250-NO-SOLICITING net.example:ADV S: MAIL FROM:<firstname.lastname@example.org> SOLICIT=org.example:ADV:ADLT S: RCPT TO:<email@example.com> R: 250 <firstname.lastname@example.org>... Recipient ok S: RCPT TO:<email@example.com> R: 550 <firstname.lastname@example.org> SOLICIT=org.example:ADV:ADLT In the previous example, the receiving MTA returned a "550" status code, indicating that one message was being rejected. The implementation also echoes back the currently set keywords for that user on the "550" status message. The solicitation class keyword which is echoed back is "org.example:ADV:ADLT" which illustrates how this per-recipient solicitation class keyword has supplemented the base "net.example:ADV" class declared in the "EHLO" exchange.
It is the responsibility of a receiving MTA to maintain a consistent policy. If the receiving MTA will reject a message because of solicitation class keywords, the MTA SHOULD declare those keywords either in the initial "EHLO" exchange or on a per-recipient basis. Likewise, a receiving MTA SHOULD NOT deliver a message where the "Solicitation:" matches a solicitation class keyword that was presented during the initial "EHLO" exchange or on a per-recipient basis. Developers should also note that the source of the solicitation class keywords used in the "MAIL FROM" command MUST be the "Solicitation:" header described in Section 2.5 and MUST NOT be supplemented by additional solicitation class keywords derived from the "Received:" header trace fields which are described in Section 2.6. RFC3463] and a message is rejected based on the presence of a "SOLICIT" parameter, the correct error message to return will usually be "5.7.1", defined as "the sender is not authorized to send to the destination... (because) of per-host or per-recipient filtering." Other codes, including temporary status codes, may be more appropriate in some circumstances and developers should look to [RFC3463] on this subject. An example of such a situation might be the use of quotas or size restrictions on messages by class. An implementation MAY impose limits such as message size restrictions based on solicitation classes, and when such limits are exceed they SHOULD be reported using whatever status code is appropriate for that limit. In all cases, an implementation SHOULD include a "Mail-From-Solicit- Parameter" on a "550" or other reply that rejects message delivery. The parameter SHOULD includes the solicitation class keyword(s) that matched. In addition to the solicitation class keyword(s) that matched, an implementation MAY include additional solicitation class keywords that are in effect. RFC2822], a new "Solicitation:" header field is defined which contains one or more solicitation class keywords. Solicitation-header = "Solicitation:" 1*SP Solicitation-keywords
An example of this header follows: To: Coupon Clipper <email@example.com> From: Spam King <firstname.lastname@example.org> Solicitation: net.example:ADV,org.example: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. 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: ; From RFC 2821 With = "WITH" FWS Protocol CFWS Protocol = "ESMTP" / "SMTP" / Attdl-Protocol Additionally, [RFC2822] defines a comment field as follows: ; From RFC 2822 comment = "(" *([FWS] ccontent) [FWS] ")" ccontent = ctext / quoted-pair / comment The "Mail-From-Solicit-Parameter" defined in Section 2.3 above is a restricted form of ctext, yielding the following production: With-Solicit = "WITH" FWS Protocol "(" [FWS] comment [FWS] ")" comment = "(" *([FWS] ccontent) [FWS] ")" ccontent = ctext / quoted-pair / comment / Mail-From-Solicit-Parameter
; The Mail-From-Solicit-Parameter ; is a restricted form of ctext An example of a Received: header from a conforming MTA is as follows: Received: by foo-mta.example.com with ESMTP (SOLICIT=net.example:ADV,org.example: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 determining 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.
The mechanism for an individual user to communicate their desire to enable certain types of filtering is outside the scope of this document.
The maximum length of Solicitation-keywords is 1000 characters. The "SOLICIT=" parameter is defined for use on the MAIL FROM command. The potential length of the MAIL FROM command is thus increased by 1007 characters. RFC3864], the "Solicitation:" header field is added to the IANA Permanent Message Header Field Registry. The following is the registration template: o Header field name: Solicitation o Applicable protocol: mail o Status: standard o Author/Change controller: IETF o Specification document(s): RFC3865 o Related information:
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001. [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003. [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. [Assassin] 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> [CNET] CNET News.Com, "AOL touts spam-fighting prowess", April 2003, <http://news.com.com/2100-1025-998944.html>. [Cantwell] U.S. Supreme Court, "Cantwell v. State of Connecticut", 310 U.S. 296 (1940), May 1940, <http://caselaw.lp.findlaw.com/scripts/ getcase.pl?court=US&vol=310&invol=296> [FTC] Federal Trade Commission, "Federal, State, Local Law Enforcers Target Deceptive Spam and Internet Scams", November 2002, <http://www.ftc.gov/opa/2002/11/nenetforcema.htm>. [FTC.TSR] Federal Trade Commission, "Telemarketing Sales Rule", Federal Register Vol. 68, No. 19, January 2003, <http://www.ftc.gov/os/2002/12/tsrfinalrule.pdf>.
[Ferris] Associated Press, "Study: Spam costs businesses $13 billion", January 2003, <http://www.cnn.com/2003/TECH/biztech/01/03/ spam.costs.ap/index.html> [Habeas] Habeas, Inc., "Habeas Compliance Message", 2004, <http://www.habeas.com/servicesComplianceStds.html> [crocker-spam-techconsider] Crocker, D., "Technical Considerations for Spam Control Mechanisms", Work in Progress, February 2004. [crouzet-amtp] Crouzet, B., "Authenticated Mail Transfer Protocol", Work in Progress, May 2004. [daboo-sieve-spamtest] Daboo, C., "SIEVE Spamtest and Virustest Extensions", Work in Progress, October 2003. [danisch-dns-rr-smtp] Danisch, H., "The RMX DNS RR and method for lightweight SMTP sender authorization", Work in Progress, August 2004. [Levine] 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>. [Malamud] Malamud, C., "An Internet Prayer Wheel", Mappa.Mundi Magazine, August 1999, <http://mappa.mundi.net/cartography/Wheel/>. [Martin] U.S. Supreme Court, "Martin v. City of Struthers, Ohio", 319 U.S. 141 (1943), May 1943, <http://caselaw.lp.findlaw.com/scripts/ getcase.pl?court=US&vol=319&invol=141> [Newbury] The Town of West Newbury, Massachusetts, "Soliciting/ Canvassing By-Law", Chapter 18 Section 10, March 2002, <http://www.town.west-newbury.ma.us/Public_Documents/ WestNewburyMA_Bylaws/000A1547-70E903AC> [Perry] U.S. Supreme Court, "Perry Education Association v. Perry Local Educators' Association", 460 U.S. 37 (1983), February 1983, <http://caselaw.lp.findlaw.com/scripts/ getcase.pl?court=US&vol=460&invol=37>
[RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999. [ROKSO] Spamhaus.Org, "Register of Known Spam Operations", November 2003, <http://www.spamhaus.org/rokso/index.lasso>. [Schumer] 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>. [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, <http://caselaw.lp.findlaw.com/scripts/ getcase.pl?court=US&vol=000&invol=00-1737>
RFC 2822 comment = "(" *([FWS] ccontent) [FWS] ")" ccontent = ctext / quoted-pair / comment / Mail-From-Solicit-Parameter ; The Mail-From-Solicit-Parameter ; is a restricted form of ctext ; From RFC 2821 With = "WITH" FWS Protocol CFWS Protocol = "ESMTP" / "SMTP" / Attdl-Protocol Attdl-Protocol = Atom
Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.