Attaching Meaning to Solicitation Class Keywords
RFC 4095

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

• Versions
• 05

Network Working Group                                         C. Malamud
Request for Comments: 4095                           Memory Palace Press
Category: Standards Track                                       May 2005

            Attaching Meaning to Solicitation Class Keywords

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

Abstract

   This document proposes a mechanism for finding a URI associated with
   a solicitation class keyword, which is defined in RFC 3865, the No
   Soliciting SMTP Service Extension.  Solicitation class keywords are
   simple labels consisting of a domain name that has been reversed,
   such as "org.example.adv".  These solicitation class keywords are
   inserted in selected header fields or used in the ESMTP service
   extension, including a new "No-Solicit:" header, which can contain
   one or more solicitation class keywords inserted by the sender.

   This document specifies an application based on the Dynamic
   Delegation Discovery System (DDDS) described in RFC 3401 and related
   documents.  An algorithm is specified to associate a solicitation
   class keyword with a URI which contains further information about the
   meaning and usage of that solicitation class keyword.  For example,
   the registrant of the "example.org" domain could use this mechanism
   to create a URI which contains detailed information about the
   "org.example.adv" solicitation class keyword.

Malamud                     Standards Track                     [Page 1]
RFC 4095                  No-Solicit Discovery                  May 2005

Table of Contents

   1. Solicitation Class Keywords .....................................2
      1.1. Terminology ................................................3
   2. The No-Solicit NAPTR Application ................................3
   3. Example .........................................................5
   4. DDDS Application Specification ..................................7
   5. Acknowledgements ................................................8
   6. Security Considerations .........................................8
   7. IANA Considerations .............................................9
   8. References ......................................................9
      8.1. Normative References .......................................9
      8.2. Informative References ....................................10

1.  Solicitation Class Keywords

   [RFC3865] defines the concept of a "solicitation class keyword",
   which is an arbitrary string or label which can be associated with an
   electronic mail message and transported by the ESMTP mail service as
   defined in [RFC2821] and related documents.  Solicitation class
   keywords are formatted like domain names, but reversed.  For example,
   the zone administrator of "example.com" might specify a particular
   solicitation class keyword such as "com.example.adv" that could be
   inserted in a "No-Solicit:" header by the message sender or in a
   trace field by a message transfer agent (MTA).  This solicitation
   class keyword is inserted by the sender of the message, who may also
   insert a variety of other solicitation class keywords as defined by
   the sender or by other parties.

   [RFC3865] explicitly places discovery of the meaning of a
   solicitation class keyword as outside of the scope of the basic ESMTP
   service extension.  For the purposes of message transport, these
   solicitation class keywords are opaque.  However, if RFC 3865 becomes
   widely used, a mail message might contain a large number of
   solicitation class keywords.  The "No-Solicit:" header has keywords
   inserted by the sender of the message, which might include the
   sender's own keywords, as well as those mandated by regulatory
   authorities or recommended by voluntary industry associations.
   Likewise, the "received:" trace fields might contain a large number
   of keywords produced by message transfer agents, filtering software,
   forwarding software in the message user agent (MUA), or any other
   system in the chain of delivery.

   As the number of keywords employed grows, it will be important to
   find a method for discovering the meaning behind the various
   solicitation class keywords.  This document specifies such a
   mechanism, associating a solicitation class keyword with a URI which
   contains further information by using the DNS NAPTR Resource Record,

Malamud                     Standards Track                     [Page 2]
RFC 4095                  No-Solicit Discovery                  May 2005