Network Working Group                                         C. Malamud
Internet-Draft                                             June 12, 2003
Expires: December 11, 2003

                A "No Soliciting" SMTP Service Extension

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on December 11, 2003.

Copyright Notice

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


   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.

Malamud                Expires December 11, 2003                [Page 1]

draft-malamud-no-soliciting     DNS-MODA                       June 2003

Table of Contents

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

Malamud                Expires December 11, 2003                [Page 2]

draft-malamud-no-soliciting     DNS-MODA                       June 2003

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:

   o  Whitelists are lists of known non-spammers.  For example, Habeas,
      Inc. maintains a Habeas User List (HUL) of people who have agreed
      to not spam.  By including a haiku in email headers and enforcing
      copyright on that ditty, they enforce their anti-spamming terms of
      service. [5]

   o  Blacklists are lists of known spammers or ISPs that allow spam.[6]

   o  Spam filters run client-side or server-side to filter out spam
      based on whitelists, blacklists, and textual and header

   o  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]

   o  Various proposals have been advanced for "do not spam" lists, akin
      to the Federal Trade Commission's "Do Not Call" list for

   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

   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.

Malamud                Expires December 11, 2003                [Page 3]

draft-malamud-no-soliciting     DNS-MODA                       June 2003

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

Malamud                Expires December 11, 2003                [Page 4]

draft-malamud-no-soliciting     DNS-MODA                       June 2003

   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

   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:

   o  In Hong Kong, offices frequently post "no soliciting" signs.

   o  In the United Kingdom, where door-to-door peddlers are fairly
      common, "no soliciting" signs are also common.

   o  In Australia, where door-to-door does not appear to be a pressing
      social problem, there was legislation passed which outlawed the
      practice of placing ads under wipers of parked cars.

   o  In France, which has a long tradition of door-to-door
      solicitation, apartment buildings often use trespass laws to
      enforce "no solicitation" policies.

   o  In the Netherlands, where door-to-door solicitation is not a
      pressing issue, there is a practice of depositing free
      publications in mailboxes.  The postal equivalent of "no spam"
      signs are quite prevalent and serve notice that the publications
      are not desired.

Malamud                Expires December 11, 2003                [Page 5]

draft-malamud-no-soliciting     DNS-MODA                       June 2003

3. The No-Soliciting SMTP Service Extension

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




   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

          R: <wait for connection on TCP port 25>
          S: <open connection to server>
          R: 220 SMTP service ready
          S: EHLO
          R: says hello

   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]).


   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

          R: <wait for connection on TCP port 25>
          S: <open connection to server>
          R: 220 SMTP service ready
          S: EHLO

Malamud                Expires December 11, 2003                [Page 6]

draft-malamud-no-soliciting     DNS-MODA                       June 2003

          R: says hello

   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: RCPT TO:<>
          R: 250 <>... Recipient ok
          S: RCPT TO:<>
          R: 550 <>... No spam pls

3.3 Solicitation Mail Header

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

          To: Coupon Clipper <>
          From: Spam King <>
          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."

   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

Malamud                Expires December 11, 2003                [Page 7]

draft-malamud-no-soliciting     DNS-MODA                       June 2003


Malamud                Expires December 11, 2003                [Page 8]

draft-malamud-no-soliciting     DNS-MODA                       June 2003

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

   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

   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.

Malamud                Expires December 11, 2003                [Page 9]

draft-malamud-no-soliciting     DNS-MODA                       June 2003

5. Security Considerations

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

Malamud                Expires December 11, 2003               [Page 10]

draft-malamud-no-soliciting     DNS-MODA                       June 2003

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.

Malamud                Expires December 11, 2003               [Page 11]

draft-malamud-no-soliciting     DNS-MODA                       June 2003

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
   and Paul Vixie provided reviews of the draft and numerous
   suggestions.  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 are the responsibility of the

Malamud                Expires December 11, 2003               [Page 12]

draft-malamud-no-soliciting     DNS-MODA                       June 2003

Informative References

   [1]   Associated Press, "Study: Spam costs businesses $13 billion",
         January 2003.

   [2]   CNET News.Com, "AOL touts spam-fighting prowess", April 2003.

   [3]   Charles, C., "Schumer, Christian Coalition Team Up to Crack
         Down on Email Spam Pornography", June 2003.

   [4]   Federal Trade Commission, "Federal, State, Local Law Enforcers
         Target Deceptive Spam and Internet Scams", November 2002.

   [5]   Habeas, Inc., "Habeas Compliant Message", April 2003.

   [6]   Spamhaus.Org, "Register of Known Spam Operations".

   [7]   Mason, J., "Spamassassin - Mail Filter to Identify Spam Using
         Text Analysis", Version 2.55, May 2003.

   [8]   Crocker, D., "Technical Considerations for Spam Control
         Mechanisms", draft-crocker-spam-techconsider-01 (work in
         progress), May 2003.

   [9]   Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP
         30, RFC 2505, February 1999.

   [10]  Danisch, H., "A DNS RR for simple SMTP sender authentication",
         draft-danisch-dns-rr-smtp-02 (work in progress), June 2003.

   [11]  Daboo, C., "SIEVE Spamtest and Virustest Extensions",
         draft-daboo-sieve-spamtest-03 (work in progress), April 2003.

   [12]  Crouzet, B., "Authenticated Mail Transfer Protocol",
         draft-crouzet-amtp-00 (work in progress), June 2003.

   [13]  Federal Trade Commission, "Telemarketing Sales Rule", Federal
         Register Vol. 68, No. 19, January 2003.

   [14]  The Town of West Newbury, Massachusetts, "Soliciting/Canvassing
         By-Law", Chapter 18 Section 10, March 2002.

   [15]  U.S. Supreme Court, "Watchtower Bible & Tract Society of New
         York, Inc., et al. v. Village of Stratton et al.", 122 S.Ct.
         2080 (2002), June 2002.

   [16]  U.S. Supreme Court, "Perry Education Association v. Perry Local
         Educators' Association", 460 U.S. 37 (1983), February 1983.

Malamud                Expires December 11, 2003               [Page 13]

draft-malamud-no-soliciting     DNS-MODA                       June 2003

   [17]  U.S. Supreme Court, "Cantwell v. State of Connecticut", 310
         U.S. 296 (1940), May 1940.

   [18]  U.S. Supreme Court, "Martin v. City of Struthers, Ohio", 319
         U.S. 141 (1943), May 1943.

   [19]  Levine, J. and P. Hoffman, "Anti-UBE and Anti-UCE Keywords in
         SMTP Banners", Revision 1.1, March 1999.

   [20]  Malamud, C., "An Internet Prayer Wheel", Mappa.Mundi Magazine,
         August 1999.

   [21]  State of California, "California Business and Professions
         Code", Section 17538.4(g).

Malamud                Expires December 11, 2003               [Page 14]

draft-malamud-no-soliciting     DNS-MODA                       June 2003

Normative References

   [22]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April

   [23]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.

Author's Address

   Carl Malamud
   PO Box 300
   Sixes, OR  97476


Malamud                Expires December 11, 2003               [Page 15]

draft-malamud-no-soliciting     DNS-MODA                       June 2003

Intellectual Property Statement

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

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

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

   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

Malamud                Expires December 11, 2003               [Page 16]

draft-malamud-no-soliciting     DNS-MODA                       June 2003



   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Malamud                Expires December 11, 2003               [Page 17]