A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension
RFC 3865

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 07

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

Abstract

   This 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.

Malamud                     Standards Track                     [Page 1]
RFC 3865                     No Soliciting                September 2004

Table of Contents

   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

Malamud                     Standards Track                     [Page 2]
RFC 3865                     No Soliciting                September 2004

1.  Introduction

1.1.  The Spam Pandemic

   Unsolicited Bulk Email (UBE), otherwise known as spam, has become as
   one of the most pressing issues on the Internet.  One oft-quoted
   study estimated that spam would cost businesses $13 billion in 2003
   [Ferris].  In April 2003, AOL reported that it had blocked 2.37
   billion pieces of UBE in a single day [CNET].  And, in a sure sign
   that UBE has become of pressing concern, numerous politicians have
   begun to issue pronouncements and prescriptions for fighting this
   epidemic [Schumer][FTC].

   A variety of mechanisms from the technical community have been
   proposed and/or implemented to fight UBE:

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

   o  Blacklists are lists of known spammers or ISPs that allow spam
      [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