Attaching Meaning to Solicitation Class KeywordsMemory Palace PressPO Box 300SixesOR97476UScarl@media.orgThis Internet-Draft proposes a mechanism for finding information about
solicitation class keywords which are defined in RFC 3865, the No Soliciting
SMTP Service Extension. The mechanism
uses a DNS NAPTR Resource Record to associate a URI with a solicitation
class keyword.
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,
.
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
and related documents. Solicitation class keywords are formatted like domain names,
but reversed.
For example, the registrant of
example.com might specify a particular solicitation class
keyword such as com.example.adv that could be inserted in
a No-Solicit: header or in a trace field.
explicitly placed discovery of the meaning of a
solicitation class keywords as outside of the scope of the basic ESMTP service
extension.If that standard becomes widely deployed, 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 (MTAs), 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 labels. This draft
specifies such a mechanism using the DNS NAPTR Resource Record, which is
defined in . An explicit design goal is to keep
the system as simple as possible. Approaches such as defining an XML-based
structure that would contain keyword meta-data or other approaches that
define the format of the explanation were ruled out. Instead, the goal is
to associate a solicitation class keyword with a URI, which in turn contains
an explanation of the keyword.
The DDDS framework of and related documents
provides a powerful set of mechanisms that can yield sophisticated
applications such as ENUM.
There is a simplification of the DDDS framework called the
Straightforward-NAPTR (S-NAPTR) application .
Unfortunately, S-NAPTR does not permit the use of the "U" flag for
terminal lookups and does not support the regular expression field
of the NAPTR RR. Since a replacement field in a NAPTR record must
contain only a domain name, and our goal is to find a URI, this
draft does not use the S-NAPTR mechanism.
This draft uses the NAPTR RR to do a single lookup from solicitation class
keyword to URI. The fields of the NAPTR RR are used as follows:
The ORDER and PREFERENCE fields are to be processed as specified
in : if multiple records are returned,
the one(s) with the lowest ORDER value that have a matching SERVICE
field MUST be used. Of those with the lowest ORDER value, those
with the lowest PREFERENCE SHOULD be used.The FLAGS field MUST contain the character "U".The SERVICES field MUST contain only the string "no-solicit".
The REGEXP field MUST contain a valid URI as further specified in this
section.The REPLACEMENT field MUST be empty.
The REGEXP field is defined in as consisting
of a delim-character, a POSIX Extended Regular Expression, another
delim-character, a replacement value, and a final
delim-character. For
this application the following rules apply:
The delim-character MAY be any valid character as defined in
section 3.2 of .The extended regular expression MUST be empty.The replacement value
MUST contain a valid URI as specified in
.The replacement value SHOULD contain
a URI limited to the "ftp", "http", and "https" schemes as
specified in and .
The document that is retrieved at the URI SHOULD
conform to ,
including the Accessibility Guidelines contained therein.A set of NAPTR records have been installed in the
simians.net subdomain and can be
retrieved using
dig or
other DNS utilities:
[carl@example.com]% dig 2795.simians.net naptr
; <<>> DiG 9.2.3 <<>> 2795.simians.net naptr
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY,
status: NOERROR, id: 43494
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5,
AUTHORITY: 2, ADDITIONAL: 1
;; QUESTION SECTION:
;2795.simians.net. IN NAPTR
;; ANSWER SECTION:
2795.simians.net. 86400 IN
NAPTR 1 1 "U" "iam+invalid"
"!!http://invalid.simians.net/contact.html!" .
2795.simians.net. 86400 IN
NAPTR 1 1 "U" "sip+invalid"
"!!http://invalid.simians.net/contact.html!" .
2795.simians.net. 86400 IN
NAPTR 1 2 "U" "no-solicit"
"!!http://infinite.simians.net/keywordinfo.html!" .
2795.simians.net. 86400 IN
NAPTR 2 1 "U" "no-solicit"
"!!http://infinite.simians.net/keywordinfo.html!" .
2795.simians.net. 86400 IN
NAPTR 1 1 "U" "no-solicit"
"!!http://infinite.simians.net/keywordinfo.html!" .
A simple utility written in PERL accepts a lookup key and
returns a URL using the specifications in this document:
#!/usr/bin/perl
# This program accepts a solicitation class keyword and
# returns a URL on success. It dies quietly on failure.
use strict;
# http://www.net-dns.org/
use Net::DNS;
# reverse the label to create a domain name
my $target = join( ".", reverse( split( /\./, $ARGV[0]) ) );
# create a resolver
my $res = Net::DNS::Resolver->new;
# find all naptr records
my $query = $res->query( "$target", "NAPTR" ) || exit ;
# Do your DNSSEC checks here, throw away all invalid RRs
# get the answers, strip out non-matching services,
# sort by order, preference
my @rr =
sort {
# sort records numerically by order, preference
$a->order <=> $b->order
|| $a->preference <=> $b->preference
}
grep { $_->service =~ /no-solicit/ } $query->answer;
# print the first qualifying record, strip out the
# regexp markers
my $op = substr( my $answer = $rr[0]->regexp , 0, 1 )
|| exit ;
print split ( $op, $answer ) ; exit ;
Running the code gives the
following results:
[carl@example.com]% lynx -source `./discover.pl net.simians.2795`
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>About Our Solicitation Class Keyword</title>
</head>
<body>
<center>
<a href="monkey.mp3">
<img alt="bouncy monkey logo"
src="images/monkey_fpo.gif" border="0" />
<br />
</a>
<br />
About net.simians.2795:<br />
It has been determined that the content of this
mail message<br />
conforms to the spirit of RFC 2795.
Congratulations?
</center>
</body>
</html>
The following definitions apply to this application:
Application Unique String: The application unique string
is a Solicitation Class Keyword as defined in .First Well Known Rule: The Solicitation Class Keyword is reversed
in order to produce a valid domain name. For example,
com.example.adv would become
adv.example.com.Valid Databases: The DNS is the database.Expected Output: A URI.The SERVICE field MUST contain the string "no-solicit", the
FLAGS field MUST contain the string "U", the REPLACEMENT field
MUST be empty, and the REGEXP field MUST be formatted as specified
in .Wildcards are appropriate for this application, allowing multiple
solicitation class keywords that share a common prefix to all point
to the same URI.The author would like to thank the following for their helpful suggestions
and reviews of this draft: Leslie Daigle, Arnt Gulbrandsen, Scott Hollenbeck, Michael
Mealling, and Ted Hardie.Use of a URI with the https: scheme without
the use of DNSSEC
makes an unwarranted illusion of authenticity and the possibility
of active attacks a serious concern.
There does not appear to be a central registry maintained
by the IANA of values that might appear in a SERVICE field
of a NAPTR resource record. Thus, no direct IANA actions are
required.
However, the IANA does maintain an
Application Service Tag Registry, which is used to support the
S-NAPTR DDDS application defined in .
The IANA is advised that the "no-solicit" value for the
SERVICE field is in use per
this draft and thus should not be used in the Application
Service Tag Registry for other applications.This draft is being submitted as an individual
submission with an intended publication as a Proposed Standard. Discussion
of this draft should take place on the
mailing list ( to
subscribe). The source and alternative transformations for this
draft may be found at .
From draft-malamud-keyword-discovery-01 to
draft-malamud-keyword-discovery-02:
Clarified intended publication status.From draft-malamud-keyword-discovery-00 to
draft-malamud-keyword-discovery-01:
Moved the example from the appendix to the main text.Added a brief note on use of wildcards to the DDDS application
definition.Minor re-arranging to conform to RFC Editor requirements.