summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3865.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3865.txt')
-rw-r--r--doc/rfc/rfc3865.txt1067
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc3865.txt b/doc/rfc/rfc3865.txt
new file mode 100644
index 0000000..d7c1470
--- /dev/null
+++ b/doc/rfc/rfc3865.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group C. Malamud
+Request for Comments: 3865 Memory Palace Press
+Category: Standards Track September 2004
+
+
+ A No Soliciting Simple Mail Transfer Protocol (SMTP)
+ Service Extension
+
+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 (2004).
+
+Abstract
+
+ This document proposes an extension to Soliciting Simple Mail
+ Transfer Protocol (SMTP) for an electronic mail equivalent to the
+ real-world "No Soliciting" sign. In addition to the service
+ extension, a new message header and extensions to the existing
+ "received" message header are described.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malamud Standards Track [Page 1]
+
+RFC 3865 No Soliciting September 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. The Spam Pandemic. . . . . . . . . . . . . . . . . . . . 3
+ 1.2. No Soliciting in the Real World. . . . . . . . . . . . . 4
+ 1.3. No Soliciting and Electronic Mail. . . . . . . . . . . . 5
+ 2. The No-Soliciting SMTP Service Extension . . . . . . . . . . . 6
+ 2.1. The EHLO Exchange. . . . . . . . . . . . . . . . . . . . 7
+ 2.2. Solicitation Class Keywords. . . . . . . . . . . . . . . 7
+ 2.2.1. Note on Choice of Solicitation Class Keywords. . 8
+ 2.3. The MAIL FROM Command. . . . . . . . . . . . . . . . . . 9
+ 2.4. Error Reporting and Enhanced Mail Status Codes . . . . . 10
+ 2.5. Solicitation Mail Header . . . . . . . . . . . . . . . . 10
+ 2.6. Insertion of Solicitation Keywords in Trace Fields . . . 11
+ 2.7. Relay of Messages. . . . . . . . . . . . . . . . . . . . 12
+ 2.8. No Default Solicitation Class. . . . . . . . . . . . . . 12
+ 3. Security Considerations . . . . . . . . . . . . . . . . . . . 13
+ 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
+ 4.1. The Mail Parameters Registry . . . . . . . . . . . . . . 13
+ 4.2. Trace Fields . . . . . . . . . . . . . . . . . . . . . . 14
+ 4.3. The Solicitation Mail Header . . . . . . . . . . . . . . 14
+ 5. Author's Acknowledgements . . . . . . . . . . . . . . . . . . 14
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 6.1. Normative References . . . . . . . . . . . . . . . . . . 15
+ 6.2. Informative References . . . . . . . . . . . . . . . . . 15
+ Appendix A. Collected ABNF Descriptions (Normative) . . . . . . . 18
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 19
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malamud Standards Track [Page 2]
+
+RFC 3865 No Soliciting September 2004
+
+
+1. Introduction
+
+1.1. The Spam Pandemic
+
+ Unsolicited Bulk Email (UBE), otherwise known as spam, has become as
+ one of the most pressing issues on the Internet. One oft-quoted
+ study estimated that spam would cost businesses $13 billion in 2003
+ [Ferris]. In April 2003, AOL reported that it had blocked 2.37
+ billion pieces of UBE in a single day [CNET]. And, in a sure sign
+ that UBE has become of pressing concern, numerous politicians have
+ begun to issue pronouncements and prescriptions for fighting this
+ epidemic [Schumer][FTC].
+
+ A variety of mechanisms from the technical community have been
+ proposed and/or implemented to fight UBE:
+
+ o Whitelists are lists of known non-spammers. For example, Habeas,
+ Inc. maintains a Habeas User List (HUL) of people who have agreed
+ to not spam. By including a haiku in email headers and enforcing
+ copyright on that ditty, they enforce their anti-spamming terms of
+ service [Habeas].
+
+ o Blacklists are lists of known spammers or ISPs that allow spam
+ [ROKSO].
+
+ o Spam filters run client-side or server-side to filter out spam
+ based on whitelists, blacklists, and textual and header analysis
+ [Assassin].
+
+ o A large number of documents address the overall technical
+ considerations for the control of UBE [crocker-spam-techconsider],
+ operational considerations for SMTP agents [RFC2505], and various
+ extensions to the protocols to support UBE identification and
+ filtering [danisch-dns-rr-smtp][daboo-sieve-spamtest][crouzet-
+ amtp].
+
+ o Various proposals have been advanced for "do not spam" lists, akin
+ to the Federal Trade Commission's "Do Not Call" list for
+ telemarketers [FTC.TSR].
+
+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, RFC 2119
+ [RFC2119].
+
+
+
+
+
+Malamud Standards Track [Page 3]
+
+RFC 3865 No Soliciting September 2004
+
+
+1.2. No Soliciting in the Real World
+
+ Municipalities frequently require solicitors to register with the
+ town government. And, in many cases, the municipalities prohibit
+ soliciting in residences where the occupant has posted a sign. The
+ town of West Newbury, Massachusetts, for example, requires:
+
+ "It shall be unlawful for any canvasser or solicitor to enter the
+ premises of a resident or business who has displayed a 'No
+ Trespassing' or 'No Soliciting' sign or poster. Further, it shall
+ be unlawful for canvassers or solicitors to ignore a resident or
+ business person's no solicitation directive or remain on private
+ property after its owner has indicated that the canvasser or
+ solicitor is not welcome" [Newbury].
+
+ Registration requirements for solicitors, particularly those
+ soliciting for political or religious reasons, have been the subject
+ of a long string of court cases. However, the courts have generally
+ recognized that individuals may post "No Soliciting" signs and the
+ government may enforce the citizen's desire. In a recent case where
+ Jehovah's Witnesses challenged a registration requirement in the city
+ of Stratton, Connecticut, saying they derived their authority from
+ the Scriptures, not the city. However, the court noted:
+
+ "A section of the ordinance that petitioners do not challenge
+ establishes a procedure by which a resident may prohibit
+ solicitation even by holders of permits. If the resident files a
+ 'No Solicitation Registration Form' with the mayor, and also posts
+ a 'No Solicitation' sign on his property, no uninvited canvassers
+ may enter his property... " [Watchtower].
+
+ Even government, which has a duty to promote free expression, may
+ restrict the use of soliciting on government property. In one case,
+ for example, a school district was allowed to give access to its
+ internal electronic mail system to the union that was representing
+ teachers, but was not required to do so to a rival union that was
+ attempting to gain the right to represent the teachers. The court
+ held that where property is not a traditional public forum "and the
+ Government has not dedicated its property to First Amendment
+ activity, such regulation is examined only for reasonableness"
+ [Perry].
+
+ The courts have consistently held that the state has a compelling
+ public safety reason for regulating solicitation. In Cantwell v.
+ Connecticut, the Supreme Court held that "a State may protect its
+ citizens from fraudulent solicitation by requiring a stranger in the
+ community, before permitting him publicly to solicit funds for any
+ purpose, to establish his identity and his authority to act for the
+
+
+
+Malamud Standards Track [Page 4]
+
+RFC 3865 No Soliciting September 2004
+
+
+ cause which he purports to represent" [Cantwell]. And, in Martin v.
+ City of Struthers, the court noted that "burglars frequently pose as
+ canvassers, either in order that they may have a pretense to discover
+ whether a house is empty and hence ripe for burglary, or for the
+ purpose of spying out the premises in order that they may return
+ later" [Martin]. The public safety issue applies very much to email,
+ where viruses can easily be delivered, in contrast to telephone
+ solicitations where public safety is not nearly as much an issue.
+
+ This analysis is U.S.-centric, which is partly due to the background
+ of the author. However, the concept of prohibiting unwanted
+ solicitation does carry over to other countries:
+
+ o In Hong Kong, offices frequently post "no soliciting" signs.
+
+ o In the United Kingdom, where door-to-door peddlers are fairly
+ common, "no soliciting" signs are also common.
+
+ o In Australia, where door-to-door does not appear to be a pressing
+ social problem, there was legislation passed which outlawed the
+ practice of placing ads under wipers of parked cars.
+
+ o In France, which has a long tradition of door-to-door
+ solicitation, apartment buildings often use trespass laws to
+ enforce "no solicitation" policies.
+
+ o In the Netherlands, where door-to-door solicitation is not a
+ pressing issue, there is a practice of depositing free
+ publications in mailboxes. The postal equivalent of "no spam"
+ signs are quite prevalent and serve notice that the publications
+ are not desired.
+
+1.3. No Soliciting and Electronic Mail
+
+ Many of the anti-spam proposals that have been advanced have great
+ merit, however none of them give notice to an SMTP agent in the
+ process of delivering mail that the receiver does not wish to receive
+ solicitations. Such a virtual sign would serve two purposes:
+
+ o It would allow the receiving system to "serve notice" that a
+ certain class of electronic mail is not desired.
+
+ o If a message is properly identified as belonging to a certain
+ class and that class of messages is not desired, transfer of the
+ message can be eliminated. Rather than filtering after delivery,
+ elimination of the message transfer can save network bandwidth,
+ disk space, and processing power.
+
+
+
+
+Malamud Standards Track [Page 5]
+
+RFC 3865 No Soliciting September 2004
+
+
+ This memo details a series of extensions to SMTP that have the
+ following characteristics:
+
+ o A service extension is described that allows a receiving Mail
+ Transport Agent (MTA) to signal the sending MTA that no soliciting
+ is in effect.
+
+ o A header field for the sender of the message is defined that
+ allows the sender to flag a message as conforming to a certain
+ class.
+
+ o Trace fields for intermediate MTAs are extended to allow the
+ intermediate MTA to signal that a message is in a certain class.
+
+ Allowing the sender of a message to tag a message as being, for
+ example, unsolicited commercial email with adult content, allows
+ "good" spammers to conform to legal content labelling requirements by
+ governmental authorities, license agreements with service providers,
+ or conventions imposed by "whitelist" services. For senders of mail
+ who choose not to abide by these conventions, the intermediate trace
+ fields defined here allow the destination MTAs to perform appropriate
+ dispositions on the received message.
+
+ This extension provides a simple mean for senders, MTAs, and
+ receivers to assert keywords. This extension does not deal with any
+ issues of authentication or consent.
+
+2. The No-Soliciting SMTP Service Extension
+
+ Per [RFC2821], a "NO-SOLICITING" SMTP service extension is defined.
+ The service extension is declared during the initial "EHLO" SMTP
+ exchange. The extension has one optional parameter, consisting of
+ zero or more solicitation class keywords. Using the notation as
+ described in the Augmented BNF [RFC2234], the syntax is:
+
+ No-Soliciting-Service = "NO-SOLICITING"
+ [ SP Solicitation-keywords ]
+
+ As will be further described below, the "Solicitation-keywords"
+ construct is used to indicate which classes of messages are not
+ desired. A keyword that is presented during the initial "EHLO"
+ exchange applies to all messages exchanged in this session. As will
+ also be further described below, additional keywords may be specified
+ on a per-recipient basis as part of the response to a "RCPT TO"
+ command.
+
+
+
+
+
+
+Malamud Standards Track [Page 6]
+
+RFC 3865 No Soliciting September 2004
+
+
+2.1. The EHLO Exchange
+
+ Keywords presented during the initial exchange indicate that no
+ soliciting in the named classes is in effect for all messages
+ delivered to this system. It is equivalent to the sign on the door
+ of an office building announcing a company-wide policy. For example:
+
+ R: <wait for connection on TCP port 25>
+ S: <open connection to server>
+ R: 220 trusted.example.com SMTP service ready
+ S: EHLO untrusted.example.com
+ R: 250-trusted.example.com says hello
+ R: 250-ENHANCEDSTATUSCODES
+ R: 250-NO-SOLICITING net.example:ADV
+ R: 250 SIZE 20480000
+
+ The "net.example:ADV" parameter to the "NO-SOLICITING" extension is
+ an example of a solicitation class keyword, the syntax of which is
+ described in the following section.
+
+ Historical Note:
+
+ A similar proposal was advanced in 1999 by John Levine and Paul
+ Hoffman. This proposal used the SMTP greeting banner to specify
+ that unsolicited bulk email is prohibited on a particular system
+ through the use of the "NO UCE" keyword [Levine]. As the authors
+ note, their proposal has the potential of overloading the
+ semantics of the greeting banner, which may also be used for other
+ purposes (see, e.g., [Malamud]).
+
+2.2. Solicitation Class Keywords
+
+ The "NO-SOLICITING" service extension uses solicitation class
+ keywords to signify classes of solicitations that are not accepted.
+ Solicitation class keywords are separated by commas.
+
+ There is no default solicitation class keyword for the service. In
+ other words, the following example is a "no-op":
+
+ R : 250-NO-SOLICITING
+
+ While the above example is a "no-op" it is useful for an MTA that
+ wishes to pass along all messages, but would also like to pass along
+ "SOLICIT=" parameters on a message-by-message basis. The above
+ example invokes the use of the extension but does not signal any
+ restrictions by class of message.
+
+
+
+
+
+Malamud Standards Track [Page 7]
+
+RFC 3865 No Soliciting September 2004
+
+
+ The initial set of solicitation class keywords all begin with a
+ domain name with the labels reversed, followed by a colon. For
+ example, the domain name "example.com" could be used to form the
+ beginning of a solicitation class keyword of "com.example:". The
+ solicitation class keyword is then followed by an arbitrary set of
+ characters drawn from the following construct:
+
+ Solicitation-keywords = word
+ 0*("," word)
+ ; length of this string is limited
+ ; to <= 1000 characters
+ word = ALPHA 0*(wordchar)
+ wordchar = ("." / "-" / "_" / ":" / ALPHA / DIGIT)
+
+ A solicitation class keyword MUST be less than 1000 characters. Note
+ however that a set of keywords used in the operations defined in this
+ document must also be less than 1000 characters. Implementors are
+ thus advised to keep their solicitation class keywords brief.
+
+ Any registrant of a domain name may define a solicitation class
+ keyword. Discovery of solicitation class keywords is outside the
+ scope of this document. However, those registrants defining keywords
+ are advised to place a definition of their solicitation class
+ keywords on a prominent URL under their control such that search
+ engines and other discovery mechanisms can find them.
+
+ While this document defines solicitation class keywords as beginning
+ with a reversed domain name followed by a colon (":"), future RFCs
+ may define additional mechanisms that do not conflict with this
+ naming scheme.
+
+2.2.1. Note on Choice of Solicitation Class Keywords
+
+ This document does not specify which solicitation class keywords
+ shall or shall not be used on a particular message. The requirement
+ to use a particular keyword is a policy decision well outside the
+ scope of this document. It is expected that relevant policy bodies
+ (e.g., governments, ISPs, developers, or others) will specify
+ appropriate keywords, the definition of the meaning of those
+ keywords, and any other policy requirements, such as a requirement to
+ use or not use this extension in particular circumstances.
+
+ During discussions of this proposal, there were several suggestions
+ to do away with the solicitation class keywords altogether and
+ replace the mechanism with a simple boolean (e.g., "NO-SOLICITING
+ YES" or "ADV" or "UBE"). Under a boolean mechanism, this extension
+ would have to adopt a single definition of what "YES" or other label
+
+
+
+
+Malamud Standards Track [Page 8]
+
+RFC 3865 No Soliciting September 2004
+
+
+ means. By using the solicitation class keywords approach, the mail
+ infrastructure remains a neutral mechanism, allowing different
+ definitions to co-exist.
+
+2.3. The MAIL FROM Command
+
+ "SOLICIT" is defined as a parameter for the "MAIL FROM" command. The
+ "SOLICIT" parameter is followed by an equal sign and a comma
+ separated list of solicitation class keywords. The syntax for this
+ parameter is:
+
+ Mail-From-Solicit-Parameter = "SOLICIT"
+ "=" Solicitation-keywords
+ ; Solicitation-keywords, when used in MAIL FROM command
+ ; MUST be identical to those in the Solicitation: header.
+
+ Note that white space is not permitted in this production.
+
+ As an informational message, the "550" or "250" replies to the "RCPT
+ TO" command may also contain the "SOLICIT" parameter. If a message
+ is being rejected due to a solicitation class keyword match,
+ implementations SHOULD echo which solicitation classes are in effect.
+ See Section 2.4 for more on error reporting.
+
+ The receiving system may decide on a per-message basis the
+ appropriate disposition of messages:
+
+ R: <wait for connection on TCP port 25>
+ S: <open connection to server>
+ R: 220 trusted.example.com SMTP service ready
+ S: EHLO untrusted.example.com
+ R: 250-trusted.example.com says hello
+ R: 250-NO-SOLICITING net.example:ADV
+ S: MAIL FROM:<save@example.com> SOLICIT=org.example:ADV:ADLT
+ S: RCPT TO:<coupon_clipper@moonlink.example.com>
+ R: 250 <coupon_clipper@moonlink.example.com>... Recipient ok
+ S: RCPT TO:<grumpy_old_boy@example.net>
+ R: 550 <grumpy_old_boy@example.net> SOLICIT=org.example:ADV:ADLT
+
+ In the previous example, the receiving MTA returned a "550" status
+ code, indicating that one message was being rejected. The
+ implementation also echoes back the currently set keywords for that
+ user on the "550" status message. The solicitation class keyword
+ which is echoed back is "org.example:ADV:ADLT" which illustrates how
+ this per-recipient solicitation class keyword has supplemented the
+ base "net.example:ADV" class declared in the "EHLO" exchange.
+
+
+
+
+
+Malamud Standards Track [Page 9]
+
+RFC 3865 No Soliciting September 2004
+
+
+ It is the responsibility of a receiving MTA to maintain a consistent
+ policy. If the receiving MTA will reject a message because of
+ solicitation class keywords, the MTA SHOULD declare those keywords
+ either in the initial "EHLO" exchange or on a per-recipient basis.
+ Likewise, a receiving MTA SHOULD NOT deliver a message where the
+ "Solicitation:" matches a solicitation class keyword that was
+ presented during the initial "EHLO" exchange or on a per-recipient
+ basis.
+
+ Developers should also note that the source of the solicitation class
+ keywords used in the "MAIL FROM" command MUST be the "Solicitation:"
+ header described in Section 2.5 and MUST NOT be supplemented by
+ additional solicitation class keywords derived from the "Received:"
+ header trace fields which are described in Section 2.6.
+
+2.4. Error Reporting and Enhanced Mail Status Codes
+
+ If a session between two MTAs is using both the "NO-SOLICITING"
+ extension and the Enhanced Mail Status Codes as defined in [RFC3463]
+ and a message is rejected based on the presence of a "SOLICIT"
+ parameter, the correct error message to return will usually be
+ "5.7.1", defined as "the sender is not authorized to send to the
+ destination... (because) of per-host or per-recipient filtering."
+
+ Other codes, including temporary status codes, may be more
+ appropriate in some circumstances and developers should look to
+ [RFC3463] on this subject. An example of such a situation might be
+ the use of quotas or size restrictions on messages by class. An
+ implementation MAY impose limits such as message size restrictions
+ based on solicitation classes, and when such limits are exceed they
+ SHOULD be reported using whatever status code is appropriate for that
+ limit.
+
+ In all cases, an implementation SHOULD include a "Mail-From-Solicit-
+ Parameter" on a "550" or other reply that rejects message delivery.
+ The parameter SHOULD includes the solicitation class keyword(s) that
+ matched. In addition to the solicitation class keyword(s) that
+ matched, an implementation MAY include additional solicitation class
+ keywords that are in effect.
+
+2.5. Solicitation Mail Header
+
+ Per [RFC2822], a new "Solicitation:" header field is defined which
+ contains one or more solicitation class keywords.
+
+ Solicitation-header = "Solicitation:" 1*SP Solicitation-keywords
+
+
+
+
+
+Malamud Standards Track [Page 10]
+
+RFC 3865 No Soliciting September 2004
+
+
+ An example of this header follows:
+
+ To: Coupon Clipper <coupon_clipper@moonlink.example.com>
+ From: Spam King <save@burntmail.example.com>
+ Solicitation: net.example:ADV,org.example:ADV:ADLT
+
+ Several proposals, particularly legal ones, have suggested requiring
+ the use of keywords in the "Subject:" header. While embedding
+ information in the "Subject:" header may provide visual cues to end
+ users, it does not provide a straightforward set of cues for computer
+ programs such as mail transfer agents. As with embedding a "no
+ solicitation" message in a greeting banner, this overloads the
+ semantics of the "Subject:" header. Of course, there is no reason
+ why both mechanisms can't be used, and in any case the
+ "Solicitation:" header could be automatically inserted by the
+ sender's Mail User Agent (MUA) based on the contents of the subject
+ line.
+
+2.6. Insertion of Solicitation Keywords in Trace Fields
+
+ The "Solicitation:" mail header is only available to the sending
+ client. RFCs 2821 and 2822 are quite specific that intermediate MTAs
+ shall not change message headers, with the sole exception of the
+ "Received:" trace field. Since many current systems use an
+ intermediate relay to detect unsolicited mail, an addition to the
+ "Received:" header is described.
+
+ [RFC2821] documents the following productions for the "Received:"
+ header in a mail message:
+
+ ; From RFC 2821
+ With = "WITH" FWS Protocol CFWS
+ Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
+
+ Additionally, [RFC2822] defines a comment field as follows:
+
+ ; From RFC 2822
+ comment = "(" *([FWS] ccontent) [FWS] ")"
+ ccontent = ctext / quoted-pair / comment
+
+ The "Mail-From-Solicit-Parameter" defined in Section 2.3 above is a
+ restricted form of ctext, yielding the following production:
+
+ With-Solicit = "WITH" FWS Protocol
+ "(" [FWS] comment [FWS] ")"
+ comment = "(" *([FWS] ccontent) [FWS] ")"
+ ccontent = ctext / quoted-pair /
+ comment / Mail-From-Solicit-Parameter
+
+
+
+Malamud Standards Track [Page 11]
+
+RFC 3865 No Soliciting September 2004
+
+
+ ; The Mail-From-Solicit-Parameter
+ ; is a restricted form of ctext
+
+ An example of a Received: header from a conforming MTA is as follows:
+
+ Received: by foo-mta.example.com with
+ ESMTP (SOLICIT=net.example:ADV,org.example:ADV:ADLT) ;
+ Sat, 9 Aug 2003 16:54:42 -0700 (PDT)
+
+ It should be noted that keywords presented in trace fields may not
+ 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.
+
+
+
+
+Malamud Standards Track [Page 12]
+
+RFC 3865 No Soliciting September 2004
+
+
+ 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
+
+
+
+Malamud Standards Track [Page 13]
+
+RFC 3865 No Soliciting September 2004
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Malamud Standards Track [Page 14]
+
+RFC 3865 No Soliciting September 2004
+
+
+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>.
+
+
+
+
+
+Malamud Standards Track [Page 15]
+
+RFC 3865 No Soliciting September 2004
+
+
+ [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>
+
+
+
+
+Malamud Standards Track [Page 16]
+
+RFC 3865 No Soliciting September 2004
+
+
+ [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>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malamud Standards Track [Page 17]
+
+RFC 3865 No Soliciting September 2004
+
+
+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
+
+
+
+
+Malamud Standards Track [Page 18]
+
+RFC 3865 No Soliciting September 2004
+
+
+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.
+
+
+
+
+
+
+
+
+
+Malamud Standards Track [Page 19]
+