A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension
Extracted elements (25)
A new 'Solicitation:' header was introduced rather than embedding keywords in the 'Subject:' header, because embedding in Subject overloads its semantics and does not provide unambiguous cues for automated processing by MTAs.
The Received: trace field comment facility was extended to carry solicitation keywords because RFC 2821 and 2822 prohibit intermediate MTAs from modifying message headers except for Received: fields, yet intermediate relay systems are commonly where spam detection occurs.
Using solicitation class keywords (namespace-scoped, extensible) rather than a simple boolean was chosen so that the mail infrastructure remains a neutral mechanism, allowing different policy definitions (governmental, ISP, developer) to co-exist without the protocol mandating a single definition of 'solicitation'.
An EHLO response of '250-NO-SOLICITING' with no keywords is a valid no-op invocation of the extension. It is useful for MTAs that wish to relay all messages but still propagate SOLICIT= parameters on a per-message basis without enforcing any class restrictions themselves.
A solicitation class keyword MUST be less than 1000 characters. The full set of keywords used in a single operation must also be less than 1000 characters total.
An implementation SHOULD include a Mail-From-Solicit-Parameter on any 550 or other reply that rejects message delivery, including the matching solicitation class keyword(s). Additional in-effect keywords MAY also be included.
If a message is rejected due to a solicitation class keyword match, implementations SHOULD echo which solicitation classes are in effect in the 550 or 250 reply to the RCPT TO command.
If a receiving MTA will reject a message based on solicitation class keywords, it SHOULD declare those keywords either in the initial EHLO exchange or on a per-recipient basis. It SHOULD NOT deliver a message whose 'Solicitation:' header matches a keyword declared during EHLO or per-recipient.
Implementations SHOULD NOT enable specific solicitation class keywords as a default, nor should system administrators enable per-recipient filtering by default. Individual users should explicitly request any filtering. This guards against the extension being characterized as a prior restraint on commercial speech.
The NO-SOLICITING extension applies to all messages handled by the receiving MTA, including those intended to be relayed. An SMTP client SHOULD verify valid syntax of 'Solicitation:' keywords before relaying. An SMTP server SHOULD set the SOLICIT parameter when receiving from a non-conforming MTA that has a 'Solicitation:' header.
The solicitation class keywords in the MAIL FROM 'SOLICIT=' parameter MUST be identical to those in the 'Solicitation:' message header. They MUST NOT be supplemented by keywords derived from 'Received:' trace fields.
When determining which keywords apply to a message, implementors SHOULD examine keywords found in the 'Solicitation:' header. Implementors MAY also examine keywords found in trace fields.
When rejecting a message using the NO-SOLICITING extension and Enhanced Mail Status Codes (RFC 3463), the correct error code is typically '5.7.1' (sender not authorized due to per-host or per-recipient filtering). An implementation MAY impose size/quota limits by solicitation class and SHOULD use the appropriate status code for that limit.
Per-recipient solicitation class keyword filtering is supported: the 550 or 250 reply to RCPT TO may contain the SOLICIT parameter, allowing per-recipient keyword sets to supplement or differ from the session-level EHLO keywords.
Solicitation class keywords begin with a reversed domain name followed by a colon (e.g., 'com.example:'), then an arbitrary suffix of allowed characters. Any domain name registrant may define their own solicitation class keywords; discovery is out of scope.
The NO-SOLICITING SMTP service extension is declared during the initial EHLO exchange. It accepts an optional parameter of zero or more solicitation class keywords indicating which classes of messages are not desired for this session.
The IANA Mail Parameters registry is updated to document the use of the comment facility in 'Received:' trace fields to indicate Solicitation Class Keywords.
The 'NO-SOLICITING' keyword is added to the IANA Mail Parameters registry as a new SMTP service extension with the EHLO keyword NO-SOLICITING and parameter Solicitation-keywords (max 1000 characters). The SOLICIT= parameter is also registered for use on the MAIL FROM command.
The 'Solicitation:' header field is added to the IANA Permanent Message Header Field Registry per RFC 3864, with status 'standard', applicable protocol 'mail', and change controller IETF.
Because there is no authentication mechanism, a sender could begin using this extension before widespread receiver adoption and attempt to interpret the absence of the extension as implied consent. The spec explicitly forecloses this interpretation.
The NO-SOLICITING extension provides no authentication of senders and does not address consent. Absence of the extension on a receiving MTA SHALL NOT be interpreted as consent to receive solicitations; non-use must not imply permission.
Solicitation keywords may be embedded in 'Received:' trace fields using the comment facility: 'WITH ESMTP (SOLICIT=net.example:ADV,org.example:ADV:ADLT)'. The Mail-From-Solicit-Parameter is treated as a restricted form of ctext within the comment production.
The EHLO service declaration syntax is: 'NO-SOLICITING' followed by an optional space and Solicitation-keywords. Solicitation-keywords are comma-separated words starting with ALPHA followed by wordchars ('.', '-', '_', ':', ALPHA, DIGIT), with total length limited to 1000 characters.
The MAIL FROM command parameter is defined as 'SOLICIT=' followed by a comma-separated list of solicitation class keywords (no whitespace permitted). The MAIL FROM command length is thus increased by up to 1007 characters.
The 'Solicitation:' message header field is defined as 'Solicitation:' followed by one or more spaces and Solicitation-keywords. It is a new RFC 2822 header field that the sending client uses to declare the solicitation class of a message.