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 January 19, 2004.

Copyright Notice

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

This note presents an extension to SMTP for an electronic mail equivalent to the real-world "No Soliciting Sign." By itself, this extension does little to stop unsolicited bulk electronic mail. However, the extension gives policy makers in the real world a "hook" on which to pass anti-spam laws.

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

Table of Contents

1.  The Spam Pandemic
2.  No Soliciting in the Real World
3.  The No-Soliciting SMTP Service Extension
3.1  SYSTEM-WIDE-NO-SOLICITING
3.2  PER-MESSAGE-NO-SOLICITING
3.3  Solicitation Mail Header
3.4  Relay of Messages
4.  Hooks for ISPs and Other Policy Makers
5.  Security Considerations
6.  IANA Considerations
7.  Author's Acknowledgements
§  Informative References
§  Normative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1. The Spam Pandemic

Spam, otherwise known as Unsolicited Bulk Email (UBE), 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 spam in a single day. [2] And, in a sure sign that spam 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 spam:

• Whitelists are lists of known non-spammers. For example, Habeas, Inc. maintains a Habeas User List (HUL) of people who have agreed to not spam. By including a haiku in email headers and enforcing copyright on that ditty, they enforce their anti-spamming terms of service. [5]
• Blacklists are lists of known spammers or ISPs that allow spam.[6]
• Spam filters run client-side or server-side to filter out spam based on whitelists, blacklists, and textual and header analysis.[7]
• A large number of documents address the overall technical considerations for the control of spam [8], operational considerations for SMTP agents[9], and various extensions to the protocols to support spam identification and filtering. [10][11][12]
• Various proposals have been advanced for "do not spam" lists, akin to the Federal Trade Commission's "Do Not Call" list for telemarketers.[13]

Many of these proposals and services have great merit, however none of them put an SMTP agent in the process of delivering mail that the receiver does not wish to receive solicitations. Such a virtual sign would permit the SMTP delivery service to declare that solicitations are not desired at this site or by a particular recipient at this site.

For purposes of this proposal, we'll use the common definition of spam, which is "Unsolicited Bulk Email." Unsolicited means "not requested" and bulk means "large in volume." As will be seen in subsequent sections, we leave the precise definitions of these terms to policy makers.

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 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] Note that the public safety issue applies very much to email, where viruses and 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 spam appears to originate from U.S. citizens. However, the concept of prohibiting unwanted solicitation does carry over to other countries:

• In Hong Kong, offices frequently post "no soliciting" signs.
• In the United Kingdom, where door-to-door peddlers are fairly common, "no soliciting" signs are also common.
• 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.
• In France, which has a long tradition of door-to-door solicitation, apartment buildings often use trespass laws to enforce "no solicitation" policies.
• 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.

3. The No-Soliciting SMTP Service Extension

Per RFC 2821,[23] two SMTP service extensions are defined:

1. SYSTEM-WIDE-NO-SOLICITING
2. PER-MESSAGE-NO-SOLICITING

3.1 SYSTEM-WIDE-NO-SOLICITING

The SYSTEM-WIDE-NO-SOLICITING extension is a simple Boolean flag, indicating 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 flag 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-SYSTEM-WIDE-NO-SOLICITING

No further actions are specified in this extension.

It should be noted that 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 UCB" 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]).

3.2 PER-MESSAGE-NO-SOLICITING

The PER-MESSAGE-NO-SOLICITING extension specifies that each MAIL FROM command must identify if this 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-PER-MESSAGE-NO-SOLICITING

Additionally, the SOLICIT keyword is defined as a parameter for the MAIL FROM command. It has one value, "yes," which identifies this message as a solicitation. In turn, the receiving system may decide on a per-user basis the appropriate disposition of messages:

       S: MAIL FROM:<savebigbucks@hotmail.com> SOLICIT=YES
       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>... No spam pls

3.3 Solicitation Mail Header

As specified in RFC 2822,[24] a new header field "Solicitation" is defined, which has only one value "TRUE":

       To: Coupon Clipper <coupon_clipper@trusted.resource.org> 
       From: Spam King <savebigbucks@hotmail.com>
       Solicitation: TRUE

Several proposals, particularly legal ones, have suggested requiring the use of keywords in the "Subject" header. For example, the State of California requires that:

"In the case of e-mail that consists of unsolicited advertising material for the lease, sale, rental, gift offer, or other disposition of any realty, goods, services, or extension of credit the subject line of each and every message shall include "ADV:" as the first four characters. If these messages contain information that consists of unsolicited advertising material for the lease, sale, rental, gift offer, or other disposition of any realty, goods, services, or extension of credit, that may only be viewed, purchased, rented, leased, or held in possession by an individual 18 years of age and older, the subject line of each and every message shall include "ADV:ADLT" as the first eight characters." [21]

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, the semantics of the header are overloaded. Of course, there is no reason why both mechanisms can't be used, and in many cases the "Solicitation" header could be automatically inserted based on the contents of the subject line.

3.4 Relay of Messages

The SYSTEM-WIDE-NO-SOLICITING service extension, if set, 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=YES flag was set on the MAIL FROM command, the MTA MUST also set the SOLICIT=YES flag when delivering the message to an SMTP server that supports this extension.

The SOLICIT=YES flag can be derived from a variety of sources, including receipt of a message from a conforming SMTP server. An SMTP server MAY set this flag after detecting the presence of the Solicitation: message header field. An SMTP server MAY also set this flag using system-specific techniques such as keyword analysis.

Implementors 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 flags.

4. Hooks for ISPs and Other Policy Makers

This proposal is not meant to "solve" the spam 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.

By providing a service-level extension to SMTP, this proposal provides a simple mechanism that allows a system or ISP to put email senders on notice that mail that is both bulk and unsolicited is not wanted.

One common criticism of any technical or legal measures to prevent spam is that the global reach of the Internet makes any such measures futile. Several points are worth noting:

1. First, anti-spam protests are often pursued through the Appropriate Use Policy in a service agreement between an Internet Service Provider and an end-user.
2. Disparity between laws of different jurisdictions is an age-old problem and many mechanisms have evolved to solve these issues. In the United States, conflicts of state laws are dealt with through the courts and a well-established body of law.
3. On an international level, conflicts of law are dealt with through international agreements, particularly trade agreements. Thus, if the U.S. believes that spam is a pressing commercial issue, it will bring the issue into a forum such as the World Trade Organization, perhaps trading off a stronger agreement on spam for a more liberal policy on the import of produce.
4. As previously noted, much if not most spam originates from U.S. citizens. A policy "hook" in the SMTP architecture will thus prove highly effective if not universally effective.

In summary, no one proposal will solve all issues with unsolicited bulk email, but adding a mechanism at the SMTP service level provides one more tool in that fight.

5. Security Considerations

This proposal does not present additional security complications beyond those already amply represented in the current architecture for electronic mail.

6. IANA Considerations

The proposed service extensions would have to be added to the IANA "Mail Parameters" registry. The IANA does not maintain a registry of mail headers, though such a registry would no doubt prove useful.

7. Author's Acknowledgements

The author would like to thank Rebecca Malamud for many discussions and ideas that led to this proposal and to Marshall T. Rose for his input on how it could be properly implemented in SMTP. Dave Crocker, Paul Hoffman, John Levine, Paul Vixie, and Pindar Wong provided reviews of the draft. Information about soliciting outside the U.S. was received from Rob Blokzijl, Jon Crowcroft, Christian Huitema, Geoff Huston, and Pindar Wong. As always, all errors, omissions, generalizations, and simplifications (EOGS) are the responsibility of the author.

Informative References

Normative References

Author's Address

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

Full Copyright Statement

Copyright (C) The Internet Society (2003). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 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.