RFC 4095
Attaching Meaning to Solicitation Class Keywords
RFC 4095: Attaching Meaning to Solicitation Class Keywords 💖
okay bestie, let's get into RFC 4095 🎀 It's a Standards Track doc by C. Malamud from Memory Palace Press, dated May 2005. It's part of the Network Working Group stream. The header has no "Obsoletes" or "Updates" line, so it doesn't replace or change any other RFC. 🌸
Status of This Memo ✨
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Check the current edition of the "Internet Official Protocol Standards" (STD 1) to see the standardization state and status of this protocol. Distribution of this memo is unlimited. 💅
Copyright Notice 🦋
Copyright (C) The Internet Society (2005).
Abstract 🧚
okay so this doc is about finding a URI (a link to more info) for a solicitation class keyword. Those are labels defined in RFC 3865, the No Soliciting SMTP Service Extension 📬 They look like reversed domain names, like "org.example.adv". 🔥
The keywords go into selected header fields or get used in the ESMTP service extension. That includes a brand new "No-Solicit:" header, which can hold one or more keywords the sender adds. 💌
The spec then builds on the Dynamic Delegation Discovery System (DDDS) from RFC 3401 and related docs. It defines an algorithm that links a keyword to a URI with more details about what the keyword means and how it's used. For example, the owner of the "example.org" domain could use this to make a URI that explains "org.example.adv" in detail. It's giving organized, honestly 😭✨
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 ....................................101. Solicitation Class Keywords 🍓
okay so [RFC3865] introduces the idea of a "solicitation class keyword" 💖 It's just an arbitrary string or label that can be attached to an email message and carried by the ESMTP mail service defined in [RFC2821] and related docs.
The keywords are formatted like domain names, but backwards. Say the zone admin of "example.com" wants a keyword like "com.example.adv". It could go in a "No-Solicit:" header, added by the sender, or in a trace field, added by a message transfer agent (MTA). 📨 The sender adds it, and they can add lots of other keywords too, whether they made them or someone else did. 🫶
[RFC3865] is clear that figuring out what a keyword means is out of scope for the basic ESMTP extension 🙅♀️ For transport, keywords are opaque, so nobody's decoding them mid-delivery. BUT if RFC 3865 gets really popular, a single message could end up with a ton of keywords. 😳 The "No-Solicit:" header can hold keywords from the sender, including the sender's own, plus ones required by regulators or recommended by voluntary industry groups. The "received:" trace fields can also collect loads of keywords from MTAs, filtering software, forwarding software in the message user agent (MUA), or any other system in the delivery chain. Chaos energy 🌀
As the number of keywords grows, it'll get important to figure out what they all mean. That's the whole point of this doc 🎯 It specifies a mechanism that links a keyword to a URI with more info, using the DNS NAPTR Resource Record defined in [RFC3403]. The big design goal is to keep things as simple as possible 🧸 The team ruled out approaches like an XML structure for specific metadata about a keyword, or other formats for the explanation. Instead, the goal is just to connect a keyword to a URI, and that URI contains the explanation. Simple and iconic 👑
1.1. Terminology 💜
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, [RFC2119]. 📖
2. The No-Solicit NAPTR Application 🦋
okay so the DDDS framework from [RFC3401] and related docs is super powerful 🔥 It can power fancy apps like ENUM, which is specified in [RFC3761]. There's also a simpler version called Straightforward-NAPTR (S-NAPTR), specified in [RFC3958]. Unfortunately, S-NAPTR doesn't allow the "U" flag for terminal lookups, and it doesn't support the regular expression field of the NAPTR RR 😭 A replacement field in a NAPTR record can only hold a domain name, but we need a URI. So this doc does not use S-NAPTR. 🙅♀️
This doc uses the NAPTR RR for one single lookup, from keyword to URI 🎀 Here's how it works. First, every : gets swapped for a .. Then the keyword gets reversed, using . as the delimiter. That result becomes the domain name lookup key. For example, "org.example:ADV" becomes "ADV.example.org" ✨
Note On Domain Names: RFC3865 says a solicitation class keyword is a valid domain name, then a:, then more valid characters. Implementers, listen up 👂 Domain names aren't case sensitive, and:turns into., so for this DDDS app these keywords are syntactically equivalent:"com.example:ADV","com.Example:adv", and"com:example:ADV". 🤯
The resulting string also has to pass the other DNS validity checks 🧐 Domain labels max out at 63 characters, and the total length of the result must be less than 253 characters. Any non-ASCII characters must be encoded using the Internationalized Domain Names (IDN) specs in [RFC3490] and related docs. Non-ASCII characters can also be encoded after the : character 🌍
The fields of the NAPTR RR work like this:
- The
"ORDER"and"PREFERENCE"fields get processed as specified in [RFC3403]. If multiple records come back, the one(s) with the lowest"ORDER"value that have a matching"SERVICE"field MUST be used. Of those, the ones 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 [RFC3402] as a "delim-character", a POSIX Extended Regular Expression, another "delim-character", a replacement value, and a final "delim-character". For this app, these rules apply:
- The
"delim-character"MAY be any valid character as defined in section 3.2 of [RFC3402]. 🌸 - The extended regular expression MUST be empty. 🙈
- The replacement value MUST contain a valid URI as specified in [RFC3986]. 💖
- The replacement value SHOULD contain a URI limited to the
"ftp","http", and"https"schemes, as specified in [RFC3986] and [RFC2660]. 🌐 - The document retrieved at the URI SHOULD conform to [HTML-4.01], including the Accessibility Guidelines contained therein. ♿✨
3. Example ✨
okay so this example is giving "set up a few NAPTR records in example.com, then go fetch them with dig" 💅 In the zone, we add a bunch of records, and anyone can look them up with dig or another DNS tool 🔍
[carl@example.com]% dig 2795.example.com naptr
; <<>> DiG 9.2.3 <<>> 2795.example.com 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.example.com. IN NAPTR
;; ANSWER SECTION:
2795.example.com. 86400 IN
NAPTR 1 1 "U" "iam+invalid"
"!!http://invalid.example.com/contact.html!" .
2795.example.com. 86400 IN
NAPTR 1 1 "U" "sip+invalid"
"!!http://invalid.example.com/contact.html!" .
2795.example.com. 86400 IN
NAPTR 1 2 "U" "no-solicit"
"!!http://infinite.example.com/keywordinfo.html!" .
2795.example.com. 86400 IN
NAPTR 2 1 "U" "no-solicit"
"!!http://infinite.example.com/keywordinfo.html!" .
2795.example.com. 86400 IN
NAPTR 1 1 "U" "no-solicit"
"!!http://infinite.example.com/keywordinfo.html!" .There's also a little PERL utility 🐪 that takes a lookup key and hands back a URI, following the rules in this document. Just so we're clear, this example is non-normative 🙈
#!/usr/bin/perl
# THIS SAMPLE CODE IS NOT NORMATIVE
# This program accepts a solicitation class keyword and
# returns a URI 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
$ARGV[0] =~ tr/:/./ ;
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 sample code gives the following results:
[carl@example.com]% lynx -source `./discover.pl com.example.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 com.example.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>4. DDDS Application Specification 🧚
okay, here are the definitions that apply to this application 📝
- Application Unique String: The application unique string is a Solicitation Class Keyword as defined in [RFC3865].
- First Well Known Rule: The character "." is substituted for the character ":" and then 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 Section 2.
Wildcards are a good fit here 🌸 They let a bunch of solicitation class keywords that share a common prefix all point to the same URI. Also, the NAPTR Resource Record is what's called a "subtyping" RR, which means there are extra selectors inside the RR to "winnow down" the choices. The catch is that more records get returned than you actually need, so there's more traffic 🚛
But, wildcards can have unintended effects if multiple types of NAPTR resource records are used. Implementors and zone administrators should exercise care in the use of such wildcards in this application. 🙈
5. Acknowledgements 🫶
The author would like to thank the following folks for their helpful suggestions and reviews of this document: Leslie Daigle, Spencer Dawkins, Arnt Gulbrandsen, Ted Hardie, Scott Hollenbeck, Russ Housley, David Kessens, Peter Koch, Michael Mealling, Pekka Savola, Mark Townsley, and Margaret Wasserman. Thank you all, you're the real MVPs 👑
6. Security Considerations 💀
Okay, this section is serious, so buckle up 😭 This document specifies an application that depends on the Domain Name System to link a solicitation class keyword to a URI. Four security considerations come with this application:
- If the domain name lookup has been compromised, the application may return a URI with incorrect guidance on how to use a particular solicitation class keyword. Here's the scary part: if the application returns a URI with the "https:" scheme, and the DNS Security Extensions as defined in [RFC4033] and related documents are not used, the user would have an unwarranted illusion of authenticity. That makes active attacks a serious concern 🚨 Even if both DNS Security Extensions and the "https:" scheme are used, the client will need to take additional steps to make sure the two different digital signature validation contexts are administered by the same domain owner.
- RFC 3865 bases solicitation class keywords on domain names. However, it does not define whom a user should trust. A sender or an intermediate MTA could insert a solicitation class keyword into a message and then use the application defined in this document to mislead the message recipient. For example, a malicious direct marketer might insert a keyword such as "org.example.certified.message" and use a URI to somehow suggest the message (falsely) has some official status 🕵️ As with any URI, users must take further steps, outside the scope of this specification, to determine what and whom to believe.
- Domain names are not persistent identifiers. As with any application that uses domain names, including the World Wide Web, if a domain name or a URI is embedded in an electronic mail message, there is a possibility that in the future the domain name will be controlled by a different zone administrator, and that use of the application described in this document will yield different and possibly inconsistent results over time ⏳
- A malicious sender could insert a large number of solicitation class keywords, or improperly formatted solicitation keywords, and cause a Denial of Service attack on the recipient's resources through an excessive number of DNS lookups. If such a message is sent to many recipients, this can result in a Denial of Service attack on the provider at a particular URI (e.g., a large number of requests attempting to access a URI such as "http://example.net/index.html"). Improperly formatted solicitation class keywords, particularly those with a non-existent top level or second level domain, could result in a Denial of Service attack on DNS registry providers or the DNS root servers 🔥
7. IANA Considerations 🌈
There is no central registry maintained by the IANA of values that might appear in the "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 [RFC3958]. The IANA is advised that the "no-solicit" value for the SERVICE field is in use per this document, and thus should not be used in the Application Service Tag Registry for other applications 🦋
8. References 📚
8.1. Normative References
- [HTML-4.01] Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 Specification", W3C REC REC-html401-19991224, December 1999.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2660] Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer Protocol", RFC 2660, August 1999.
- [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
- [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
- [RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension", RFC 3865, September 2004.
- [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
- [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
8.2. Informative References
- [RFC2795] Christey, S., "The Infinite Monkey Protocol Suite (IMPS)", RFC 2795, 1 April 2000.
- [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
- [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
- [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
- [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
Author's Address 🖊️
Carl Malamud
Memory Palace Press
PO Box 300
Sixes, OR 97476
US
EMail: carl@media.orgFull Copyright Statement ©️
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 💅
okay so the IETF is basically saying, "we are NOT taking a side on whether any patents or other rights people claim about this tech are valid, or how far they reach, or whether you can get a license for them." 🙅 It also isn't claiming it went digging to find every right out there. 🫣 If you want the rules on rights for RFC documents, check out BCP 78 and BCP 79 📚 (those are the official rulebooks, bestie).
Copies of IPR disclosures sent to the IETF Secretariat, any promises to make licenses available, and the results of trying to get a general license or permission for implementers or users of this spec to use the proprietary stuff can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr. 🗂️✨
The IETF also invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard to let them know. 🦋 Send that info to the IETF at ietf-ipr@ietf.org. 💌
Acknowledgement 🌸
Funding for the RFC Editor function is currently coming from the Internet Society. 💜 Thank you, Internet Society, you're literally keeping the lights on for the RFC Editor 🫶
📦 where this page comes from
- ietf: rfc4095 2005-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms