Attaching Meaning to Solicitation Class Keywords
RFC 4095
Document | Type |
RFC - Proposed Standard
(May 2005; No errata)
Was draft-malamud-keyword-discovery (individual in app area)
|
|
---|---|---|---|
Author | Carl Malamud | ||
Last updated | 2018-12-20 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4095 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Scott Hollenbeck | ||
Send notices to | (None) |
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 2005Show full document text