agree with those found in the "Solicitation:" header and trace fields
may exist even if the header is not present. When determining which
keywords are applicable to a particular exchange of messages,
implementors SHOULD examine any keywords found in the "Solicitation:"
header. Implementors MAY examine other keywords found in the trace
fields.
2.7. Relay of Messages
The "NO-SOLICITING" service extension, if present, applies to all
messages handled by the receiving Message Transfer Agent (MTA),
including those messages intended to be relayed to another system.
Solicitation class keywords supplied by a client on a "SOLICIT"
parameter on a "MAIL FROM" command SHOULD be obtained from the
"Solicitation:" field in the message header. An SMTP client SHOULD,
however, verify that the list of solicitation class keywords obtained
from the "Solicitation:" field uses valid syntax before conveying its
contents. An SMTP server SHOULD set this parameter after detecting
the presence of the "Solicitation:" header field when receiving a
message from a non-conforming MTA.
2.8. No Default Solicitation Class
Implementations of "NO-SOLICITING" service extension SHOULD NOT
enable specific solicitation class keywords as a default in their
software. There are some indications that some policy makers may
view a default filtering in software as a prior restraint on
commercial speech. In other words, because the person installing and
using the software did not make an explicit choice to enable a
certain type of filtering, some might argue that such filtering was
not desired.
Likewise, it is recommended that a system administrator installing
software SHOULD NOT enable additional per-recipient filtering by
default for a user. Again, individual users should specifically
request any additional solicitation class keywords.
The mechanism for an individual user to communicate their desire to
enable certain types of filtering is outside the scope of this
document.
3. Security Considerations
This extension does not provide authentication of senders or other
measures intended to promote security measures during the message
exchange process.
In particular, this document does not address the circumstances under
which a sender of electronic mail should or should not use this
extension and does not address the issues of whether consent to send
mail has been granted.
This might lead to a scenario in which a sender of electronic mail
begins to use this extension well before the majority of end users
have begun to use it. In this scenario, the sender might wish to use
the absence of the extension on the receiving MTA as an implication
of consent to receive mail. Non-use of the "NO-SOLICITING" extension
by a receiving MTA SHALL NOT indicate consent.
4. IANA Considerations
There are three IANA considerations presented in this document:
1. Addition of the "NO-SOLICITING" service extension to the Mail
Parameters registry.
2. Documentation of the use of comments in trace fields.
3. Creation of a "Solicitation:" mail header.
4.1. The Mail Parameters Registry
The IANA Mail Parameters registry documents SMTP service extensions.
The "NO-SOLICITATION" service extension has been added to this
registry as follows.
Keywords Description Reference
------------ ------------------------------ ---------
NO-SOLICITING Notification of no soliciting. RFC3865
The parameters subregistry would need to be modified as follows:
Service Ext EHLO Keyword Parameters Reference
----------- ------------ ----------- ---------
No Soliciting NO-SOLICITING Solicitation-keywords RFC3865
The maximum length of Solicitation-keywords is 1000 characters. The
"SOLICIT=" parameter is defined for use on the MAIL FROM command.
The potential length of the MAIL FROM command is thus increased by
1007 characters.
4.2. Trace Fields
The Mail Parameters registry would need to be modified to note the
use of the comment facility in trace fields to indicate Solicitation
Class Keywords.
4.3. The Solicitation Mail Header
Per [RFC3864], the "Solicitation:" header field is added to the IANA
Permanent Message Header Field Registry. The following is the
registration template:
o Header field name: Solicitation
o Applicable protocol: mail
o Status: standard
o Author/Change controller: IETF
o Specification document(s): RFC3865
o Related information:
5. Author’s Acknowledgements
The author would like to thank Rebecca Malamud for many discussions
and ideas that led to this proposal and to John C. Klensin and
Marshall T. Rose for their extensive input on how it could be
properly implemented in SMTP. Eric Allman, Harald Alvestrand, Steven
M. Bellovin, Doug Barton, Kent Crispin, Dave Crocker, Ned Freed,
Curtis Generous, Arnt Gulbrandsen, John Levine, Keith Moore, Hector
Santos, Ted Hardie, Paul Vixie, and Pindar Wong kindly provided
reviews of the document and/or suggestions for improvement.
Information about soliciting outside the U.S. was received from Rob
Blokzijl, Jon Crowcroft, Christian Huitema, Geoff Huston, and Pindar
Wong. John Levine pointed out the contrast between this proposal and
"do not spam" lists. As always, all errors and omissions are the
responsibility of the author.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
2821, April 2001.
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
April 2001.
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
3463, January 2003.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
6.2. Informative References
[Assassin] Mason, J., "Spamassassin - Mail Filter to Identify Spam
Using Text Analysis", Version 2.55, May 2003,
<http://www.mirror.ac.uk/sites/spamassassin.taint.org/
spamassassin.org/doc/spamassassin.html>
[CNET] CNET News.Com, "AOL touts spam-fighting prowess", April
2003, <http://news.com.com/2100-1025-998944.html>.
[Cantwell] U.S. Supreme Court, "Cantwell v. State of Connecticut",
310 U.S. 296 (1940), May 1940,
<http://caselaw.lp.findlaw.com/scripts/
getcase.pl?court=US&vol=310&invol=296>
[FTC] Federal Trade Commission, "Federal, State, Local Law
Enforcers Target Deceptive Spam and Internet Scams",
November 2002,
<http://www.ftc.gov/opa/2002/11/nenetforcema.htm>.
[FTC.TSR] Federal Trade Commission, "Telemarketing Sales Rule",
Federal Register Vol. 68, No. 19, January 2003,
<http://www.ftc.gov/os/2002/12/tsrfinalrule.pdf>.
[Ferris] Associated Press, "Study: Spam costs businesses $13
billion", January 2003,
<http://www.cnn.com/2003/TECH/biztech/01/03/
spam.costs.ap/index.html>
[Habeas] Habeas, Inc., "Habeas Compliance Message", 2004,
<http://www.habeas.com/servicesComplianceStds.html>
[crocker-spam-techconsider]
Crocker, D., "Technical Considerations for Spam Control
Mechanisms", Work in Progress, February 2004.
[crouzet-amtp]
Crouzet, B., "Authenticated Mail Transfer Protocol",
Work in Progress, May 2004.
[daboo-sieve-spamtest]
Daboo, C., "SIEVE Spamtest and Virustest Extensions",
Work in Progress, October 2003.
[danisch-dns-rr-smtp]
Danisch, H., "The RMX DNS RR and method for lightweight
SMTP sender authorization", Work in Progress, August
2004.
[Levine] Levine, J. and P. Hoffman, "Anti-UBE and Anti-UCE
Keywords in SMTP Banners", Revision 1.1, March 1999,
<http://www.cauce.org/proposal/smtp-banner-rfc.shtml>.
[Malamud] Malamud, C., "An Internet Prayer Wheel", Mappa.Mundi
Magazine, August 1999,
<http://mappa.mundi.net/cartography/Wheel/>.
[Martin] U.S. Supreme Court, "Martin v. City of Struthers, Ohio",
319 U.S. 141 (1943), May 1943,
<http://caselaw.lp.findlaw.com/scripts/
getcase.pl?court=US&vol=319&invol=141>
[Newbury] The Town of West Newbury, Massachusetts, "Soliciting/
Canvassing By-Law", Chapter 18 Section 10, March 2002,
<http://www.town.west-newbury.ma.us/Public_Documents/
WestNewburyMA_Bylaws/000A1547-70E903AC>
[Perry] U.S. Supreme Court, "Perry Education Association v.
Perry Local Educators’ Association", 460 U.S. 37 (1983),
February 1983, <http://caselaw.lp.findlaw.com/scripts/
getcase.pl?court=US&vol=460&invol=37>
[RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs",
BCP 30, RFC 2505, February 1999.
[ROKSO] Spamhaus.Org, "Register of Known Spam Operations",
November 2003,
<http://www.spamhaus.org/rokso/index.lasso>.
[Schumer] Charles, C., "Schumer, Christian Coalition Team Up to
Crack Down on Email Spam Pornography", June 2003,
<http://
www.senate.gov/~schumer/SchumerWebsite/pressroom/
press_releases/PR01782.html>.
[Watchtower] U.S. Supreme Court, "Watchtower Bible & Tract Society of
New York, Inc., et al. v. Village of Stratton et al.",
122 S.Ct. 2080 (2002), June 2002,
<http://caselaw.lp.findlaw.com/scripts/
getcase.pl?court=US&vol=000&invol=00-1737>
Appendix A. Collected ABNF Descriptions (Normative)
Solicitation-keywords = word
0*("," word)
; length of this string is limited
; to <= 1000 characters
word = ALPHA 0*(wordchar)
wordchar = ("." / "-" / "_" / ":" / ALPHA / DIGIT)
; used in the initial EHLO exchange
No-Soliciting-Service = "NO-SOLICITING"
[ SP Solicitation-keywords ]
; used on the Solicitation: message header
Solicitation-header = "Solicitation:" 1*SP Solicitation-keywords
; used on the MAIL FROM command and replies,
; and on Received: headers.
Mail-From-Solicit-Parameter =
"SOLICIT" "=" Solicitation-keywords
; Solicitation-keywords, when used in
; the MAIL FROM command MUST be identical
; to those in the Solicitation: header.
; Used on Received: headers
With-Solicit = "WITH" FWS Protocol
"(" [FWS] comment [FWS] ")"
; From RFC 2822
comment = "(" *([FWS] ccontent) [FWS] ")"
ccontent = ctext / quoted-pair /
comment / Mail-From-Solicit-Parameter
; The Mail-From-Solicit-Parameter
; is a restricted form of ctext
; From RFC 2821
With = "WITH" FWS Protocol CFWS
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
Attdl-Protocol = Atom
Author’s Address
Carl Malamud
Memory Palace Press
PO Box 300
Sixes, OR 97476
US
EMail: carl@media.org
Full Copyright Statement
Copyright (C) The Internet Society (2004). 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
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.