| TOC |
|
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 May 29, 2004.
Copyright (C) The Internet Society (2003). All Rights Reserved.
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.
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].
1.
Introduction
1.1
The Spam Pandemic
1.2
No Soliciting in the Real World
1.3
A Distributed No Soliciting Extension
2.
The No-Soliciting SMTP Service Extension
2.1
The SYSTEM-WIDE Option
2.2
Solicitation Class Keywords
2.3
The PER-RECIPIENT Option
2.4
Use of Enhanced Mail Status Codes
2.5
Solicitation Mail Header
2.6
Insertion of Solicitation Keywords in Trace Fields
2.7
Relay of Messages
2.8
Recommendations for Developers and Administrators
3.
Use of the Extension
3.1
Relationship to Centralized Approaches
4.
Security Considerations
5.
IANA Considerations
5.1
The Mail Parameters Registry
5.2
ESMTP-Solicitation Additional Protocol
5.3
The Solicitation Class Keywords Registry
5.4
The Solicitation Mail Header
6.
Author's Acknowledgements
§
Informative References
§
Normative References
§
Author's Address
A.
Status of This Document
A.1
RFC Category
A.2
Document Repository
A.3
Discussion
A.4
Changes From Previous Drafts
B.
Transmittal
§
Intellectual Property and Copyright Statements
| TOC |
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.[1] In April 2003, AOL reported that it had blocked 2.37 billion pieces of UBE in a single day. [2] And, in a sure sign that UBE has become of pressing concern, numerous politicians have begun to issue pronouncements and prescriptions for fighting this epidemic.[3][4]
A variety of mechanisms from the technical community have been proposed and/or implemented to fight UBE:
Municipalities frequently require solicitors to register with the town government. And, in many cases, the municipalities prohibit soliciting in residences where the occupant has posted a sign. The town of West Newbury, Massachusetts, for example, requires:
"It shall be unlawful for any canvasser or solicitor to enter the premises of a resident or business who has displayed a 'No Trespassing' or 'No Soliciting' sign or poster. Further, it shall be unlawful for canvassers or solicitors to ignore a resident or business person's no solicitation directive or remain on private property after its owner has indicated that the canvasser or solicitor is not welcome." [14]
Registration requirements for solicitors, particularly those soliciting for political or religious reasons, have been the subject of a long string of court cases. However, the courts have generally recognized that individuals may post "No Soliciting" signs and the government may enforce the citizen's desire. In a recent case where Jehovah's Witnesses challenged a registration requirement in the city of Stratton, Connecticut, saying they derived their authority from the Scriptures, not the city. However, the court noted:
"A section of the ordinance that petitioners do not challenge establishes a procedure by which a resident may prohibit solicitation even by holders of permits. If the resident files a 'No Solicitation Registration Form' with the mayor, and also posts a 'No Solicitation' sign on his property, no uninvited canvassers may enter his property ..." [15]
Even government, which has a duty to promote free expression, may restrict the use of soliciting on government property. In one case, for example, a school district was allowed to give access to its internal electronic mail system to the union that was representing teachers, but was not required to do so to a rival union that was attempting to gain the right to represent the teachers. The court held that where property is not a traditional public forum "and the Government has not dedicated its property to First Amendment activity, such regulation is examined only for reasonableness."[16]
The courts have consistently held that the state has a compelling public safety reason for regulating solicitation. In Cantwell v. Connecticut, the Supreme Court held that "a State may protect its citizens from fraudulent solicitation by requiring a stranger in the community, before permitting him publicly to solicit funds for any purpose, to establish his identity and his authority to act for the cause which he purports to represent."[17] And, in Martin v. City of Struthers, the court noted that "burglars frequently pose as canvassers, either in order that they may have a pretense to discover whether a house is empty and hence ripe for burglary, or for the purpose of spying out the premises in order that they may return later."[18] The public safety issue applies very much to email, where viruses can easily be delivered, in contrast to telephone solicitations where public safety is not nearly as much an issue.
This analysis is very U.S.-centric, which may be appropriate given that the large majority of UBE appears to originate from U.S. citizens. However, the concept of prohibiting unwanted solicitation does carry over to other countries:
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:
This memo details a series of extensions to SMTP that have the following characteristics:
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.
| TOC |
Per RFC 2821,[22] a NO-SOLICITING SMTP service extension is defined. The service extension is declared during the initial EHLO SMTP exchange. The extension has one optional parameter and zero or more solicitation class keywords. Using the notation as described in the Augmented BNF[23], the syntax is:
No-Soliciting-Service = "NO-SOLICITING"
[ "SYSTEM-WIDE" / "PER-RECIPIENT" ]
0*( Solicitation-keywords )
NO-SOLICITING SYSTEM-WIDE indicates that no soliciting is in effect for all messages delivered to this system. It is equivalent to the sign on the door of an office building announcing a company-wide policy.
The parameter is presented during the initial exchange between sender and receiver:
R: <wait for connection on TCP port 25> S: <open connection to server> R: 220 trusted.example.com SMTP service ready S: EHLO untrusted.example.com R: 250-trusted.example.com says hello R: 250-NO-SOLICITING SYSTEM-WIDE ADV
(The ADV keyword is one of several possible values and is described in the following section.)
A similar proposal was advanced in 1999 by John Levine and Paul Hoffman. This proposal used the SMTP greeting banner to specify that unsolicited bulk email is prohibited on a particular system through the use of the "NO UCE" keyword.[19] As the authors note, their proposal has the potential of overloading the semantics of the greeting banner, which may also be used for other purposes (see, e.g., [20]).
The NO-SOLICITING service extension may use solicitation class keywords that signify a specific class of solicitations that are not accepted. Keywords are separated by commas and follow the SYSTEM-WIDE parameter.
Three classes are defined in this draft:
Keywords Description Reference --------- -------------------------------- --------- MAPS-UBE Unsolicited Bulk Email http://mail-abuse.org/ ADV Unsolicited Commercial Email http://www.spamlaws.com/ ADV:ADLT Sexually Explicit Commercial Mail http://www.spamlaws.com/
MAPS-UBE is the standard advanced by the Mail Abuse Prevention System (MAPS), which states:
An electronic message is "spam" IF: (1) the recipient's personal identity and context are irrelevant because the message is equally applicable to many other potential recipients; AND (2) the recipient has not verifiably granted deliberate, explicit, and still-revocable permission for it to be sent; AND (3) the transmission and reception of the message appears to the recipient to give a disproportionate benefit to the sender.
Numerous states have adopted the "ADV" and "ADV:ADLT" conventions. We cite the spamlaws.com site as a reference because it provides an excellent summary of the definitions and pointers to the relevant statutes.
There is no default keyword for the service. In other words, the following example is a "no-op":
R: 250-NO-SOLICITING SYSTEM-WIDE
Additional solicitation class keywords may be defined and registered in the registry as specified in Section 5. Multiple solicitation class keywords are separated by a comma to form a list:
Solicitation-keywords = 1Solicit-word 0*("," 1Solicit-word)
Solicit-word = [ "MAPS-UBE" / "ADV" / "ADV:ADLT"
/ x-word / registered-word ]
x-word = ["x-" / "X-"] 1*(wordchars)
registered-word = ALPHA 0*(wordchars)
; registered-word(s) are registered
; with the IANA
wordchars = 1*("-" / "_" / ":" / ALPHA / DIGIT)
The NO-SOLICITING PER-RECIPIENT extension specifies that each MAIL FROM command must identify if a message is a solicitation.
The presence of this extension is identified during the initial greeting:
R: <wait for connection on TCP port 25> S: <open connection to server> R: 220 trusted.example.com SMTP service ready S: EHLO untrusted.example.com R: 250-trusted.example.com says hello R: 250-NO-SOLICITING PER-RECIPIENT
Additionally, SOLICIT is defined as a parameter for the MAIL FROM command. The SOLICIT parameter is followed by an optional equal sign and a comma separated list of solicitation class keywords.
The syntax for this parameter is:
Mail-From-Solicit-Parameter = "SOLICIT"
1( "=" Solicitation-keywords)
As an informational message, the 550 or 250 replies to the RCPT TO command may also contain the SOLICIT parameter.
The receiving system may decide on a per-user basis the appropriate disposition of messages:
S: MAIL FROM:<savebigbucks@hotmail.com> SOLICIT=ADV,MAPS-UBE S: RCPT TO:<coupon_clipper@trusted.resource.org> R: 250 <coupon_clipper@trusted.resource.org>... Recipient ok S: RCPT TO:<grumpy_old_boy@trusted.resource.org> R: 550 <grumpy_old_boy@trusted.resource.org>... SOLICIT=ADV
In the previous example, the receiving MTA returned a 550 status code, indicating that the message was being rejected. Note that the implementation also echoes back the currently set keywords for that user as a rudimentary informational message.
If a session between two MTAs is using both the NO-SOLICITING extension and the Enhanced Mail Status Codes as defined in RFC 3463[25] and a message is rejected based on the presence of a SOLICIT parameter, the correct error message to return is 5.7.1, defined as "the sender is not authorized to send to the destination ... [because] of per-host or per-recipient filtering."
Per RFC 2822,[24] a new Solicitation: header field is defined which contains one or more solicitation class keywords.
To: Coupon Clipper <coupon_clipper@trusted.resource.org> From: Spam King <savebigbucks@hotmail.com> Solicitation: ADV,ADV:ADLT
Several proposals, particularly legal ones, have suggested requiring the use of keywords in the Subject: header. While embedding information in the Subject: header may provide visual cues to end users, it does not provide a straightforward set of cues for computer programs such as mail transfer agents. As with embedding a "no solicitation" message in a greeting banner, this would overload the semantics of the Subject: header. Of course, there is no reason why both mechanisms can't be used, and in any case the Solicitation: header could be automatically inserted based on the contents of the subject line.
It should be noted that the presence of both a Solicitation: header and a SOLICIT service extension leads to the possibility of conflict between the two. Implementors SHOULD always include any values found in the Solicitation: header in the fields presented in the service extension. Implementors MAY add additional keywords for operational reasons as defined in Section 7.7 of RFC 2821[22].
The Solicitation: mail header is only available to the sending client. RFCs 2821 and 2822 are quite specific that intermediate MTAs shall not change message headers, with the sole exception of the Received: trace field. Since many current systems use an intermediate relay to detect unsolicited mail, an addition to the Received: header is described.
As a review, RFC 2821[22] documents the following productions for the Received: header in a mail message:
Time-stamp-line = "Received:" FWS Stamp <CRLF>
Stamp = From-domain By-domain Opt-info ";" FWS date-time
; where "date-time" is as defined in [32]
; but the "obs-" forms, especially two-digit
; years, are prohibited in SMTP and MUST NOT be used.
Opt-info = [Via] [With] [ID] [For]
With = "WITH" FWS Protocol CFWS
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
Attdl-Protocol = Atom
; Additional standard names for protocols are registered with
; the Internet Assigned Numbers Authority (IANA). SMTP servers
; SHOULD NOT use unregistered names.
The appropriate location for solicitation information is the Attdl-Protocol field, which is defined in this document as ESMTP-Solicitation. The RFC 2821 productions are supplemented as follows:
Protocol = "ESMTP" / "SMTP" / ESMTP-Solicitation / Attdl-Protocol
ESMTP-Solicitation = "ESMTP-Solicitation"
FWS 0*( Solicitation-keywords )
An example of a Received: header from a conforming MTA is as follows:
Received: by foo-mta.example.com with
ESMTP-Solicitation ADV,ADV:ADLT ; Sat, 9 Aug 2003
16:54:42 -0700 (PDT)
The NO-SOLICITING SYSTEM-WIDE service extension, if present, applies to all messages handled by the receiving Message Transfer Agent (MTA), including those messages intended to be relayed to another system.
When relaying a message which was received via the SMTP protocol in which the SOLICIT parameter was set on the MAIL FROM command, the MTA MUST also set the SOLICIT parameter when delivering the message to an SMTP server that supports this extension.
The SOLICIT parameter on a MAIL FROM command can be derived from a variety of sources, including receipt of a message from a conforming SMTP server. An SMTP server MAY, for operational reasons as defined in Section 7.7 of RFC 2821[22], set this parameter after detecting the presence of the Solicitation: or extended Received: message header field or by using other system-specific techniques.
Implementers should be aware that the NO-SOLICITING service extension is not a guaranteed end-to-end service. Specifically, intermediate relays that do not support this service may "lose" the per-message parameters. However, any trace fields inserted during the message transfer process will persist.
It is strongly recommended that any developers that implement the NO-SOLICITING service extension SHOULD NOT enable the service as a default. There are some indications that some policy makers may view a default filtering in software as a prior restraint on commercial speech. In other words, because the person installing the software did not make an explicit choice to enable a certain type of filtering, some might argue that such filtering was not desired.
Likewise, it is recommended that a system administrator installing software SHOULD NOT enable PER-RECIPIENT filtering by default for a user. Again, individual users should request the service.
The mechanism for an individual user to communicate their desire to enable certain types of filtering is outside the scope of this document.
It should be noted that for recipient MTAs, implementation of the SYSTEM-WIDE option is significantly simpler than adding PER-RECIPIENT capabilities. Because PER-RECIPIENT is an optional parameter, it should be noted that:
Implementation of the SYSTEM-WIDE on a receiving MTA is almost trivial. For example, on the popular sendmail package, a few minor changes need to be made to three files.
| TOC |
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:
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:
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 NO-SOLICITING assertion could both be factors taken into consideration in levying fines or taking other corrective actions.
| TOC |
This proposal does not present additional security complications beyond those already amply represented in the current architecture for electronic mail.
| TOC |
There are four IANA considerations presented in this draft:
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>]
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.
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:
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.
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.
| TOC |
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.
| TOC |
| TOC |
| [21] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [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 (TXT, HTML, XML). |
| TOC |
| Carl Malamud | |
| Memory Palace Press | |
| PO Box 300 | |
| Sixes, OR 97476 | |
| US | |
| EMail: | carl@media.org |
| TOC |
This document will be submitted for publication as an Informational RFC.
The source for this document can be found at http://trusted.resource.org/no-solicit.
Discussions of this draft may be directed towards the following targets:
Changes from draft-malamud-no-soliciting-01 to draft-malamud-no-soliciting-02:
Changes from draft-malamud-no-soliciting-00 to draft-malamud-no-soliciting-01:
| TOC |
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
Dear Mr. Muris:
On October 23, 2003, the U.S. Senate passed S.877, known as the CAN-SPAM Act of 2003. 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—
- sets forth a plan and timetable for establishing a nationwide marketing Do-Not-E-mail registry;
- includes an explanation of any practical, technical, security, privacy, enforceability, or other concerns that the Commission has regarding such a registry; and
- 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:
I should note that the above-referenced proposal is not the only way 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
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
The Honorable Edward J. Markey
U.S. House of Representatives
2108 Rayburn House Office Building
Washington, DC 20515
ed@markey.house.gov
| TOC |
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.
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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Funding for the RFC Editor function is currently provided by the Internet Society.