RFC 3865

A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension

📅 published September 2004, from ietf

Okay bestie, let's get into RFC 3865 🎀✨

It's a Standards Track document from the Network Working Group 💜, written by C. Malamud at Memory Palace Press, and dated September 2004. Its title is A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension 💌. The header doesn't list anything it obsoletes or updates, so it's standing on its own 💅.

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 (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. 🫶

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

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:

  • 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]. 🌈
  • Blacklists are lists of known spammers or ISPs that allow spam [ROKSO]. 🔥
  • Spam filters run client-side or server-side to filter out spam based on whitelists, blacklists, and textual and header analysis [Assassin]. 💅
  • 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]. 🍓
  • 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]. Those words are the important ones, so read them carefully 🫶.

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 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: 🌍

  • In Hong Kong, offices frequently post "no soliciting" signs.
  • In the United Kingdom, where door-to-door peddlers are fairly common, "no soliciting" signs are also common.
  • 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. 🚗
  • In France, which has a long tradition of door-to-door solicitation, apartment buildings often use trespass laws to enforce "no solicitation" policies. 🥐
  • 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:

  • It would allow the receiving system to "serve notice" that a certain class of electronic mail is not desired.
  • 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. 💾

This memo details a series of extensions to SMTP that have the following characteristics:

  • A service extension is described that allows a receiving Mail Transport Agent (MTA) to signal the sending MTA that no soliciting is in effect.
  • 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.
  • 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 ✨

Okay bestie, so per [RFC2821], there's a "NO-SOLICITING" SMTP service extension 🎀. It gets announced during the very first "EHLO" hello 👋. It takes one optional parameter, which is zero or more solicitation class keywords. We write the syntax in Augmented BNF [RFC2234] (yes, that's the grammar language, don't panic 🫶):

No-Soliciting-Service = "NO-SOLICITING"
     [ SP Solicitation-keywords ]

Here's the vibe. The solicitation class keywords tell the server which kinds of messages nobody wants 🙅‍♀️. A keyword announced during the "EHLO" exchange applies to every message in that session 🌸. We'll get into it below, but you can also add extra keywords per recipient, in the reply to a "RCPT TO" command 💜.

2.1. The EHLO Exchange

Keywords dropped during the initial exchange mean no soliciting in those named classes is in effect for every message delivered to this system ✨. It's basically a company-wide policy sign taped to the front door of an office building 🏢. Here's how it looks:

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

So "net.example:ADV" is the parameter that goes with "NO-SOLICITING", and it's an example of a solicitation class keyword 💅. The exact syntax is in the next section, so keep reading, bestie 🧚.

Historical Note: A proposal basically like this one came out in 1999, from John Levine and Paul Hoffman 🕰️. Their version put the "no unsolicited bulk email" message in the SMTP greeting banner, using a "NO UCE" keyword [Levine]. The authors pointed out that this could overload what the greeting banner means, since it's also used for other things (see, e.g., [Malamud]) 🙈.

2.2. Solicitation Class Keywords

The "NO-SOLICITING" extension uses solicitation class keywords to say which classes of solicitations are not accepted 🚫. Multiple keywords are separated by commas 🍓.

There's no default solicitation class keyword, so this next one is a total "no-op" 😭:

R : 250-NO-SOLICITING

Even though it's a no-op, it's still useful. Imagine an MTA that wants to pass along every message, but also wants to pass along "SOLICIT=" parameters on a message-by-message basis 🧐. Announcing the extension this way turns it on without restricting any class of message. Iconic, honestly 👑.

Every initial solicitation class keyword starts with a domain name with its labels reversed, followed by a colon ✨. So the domain "example.com" could start a keyword like "com.example:". After that colon comes an arbitrary set of characters from this construct:

Solicitation-keywords = word
     0*("," word)
     ; length of this string is limited
     ; to <= 1000 characters
word = ALPHA 0*(wordchar)
wordchar = ("." / "-" / "_" / ":" / ALPHA / DIGIT)

Here's the important bit 🚨: a solicitation class keyword MUST be less than 1000 characters. And a whole set of keywords used in the operations defined in this document must also be less than 1000 characters. So implementors are advised to keep their solicitation class keywords brief 💖.

Any registrant of a domain name is allowed to define a solicitation class keyword 🌈. How you discover these keywords is outside the scope of this document. Still, anyone defining keywords is advised to put their definitions at a prominent URL they control, so search engines and other discovery mechanisms can find them 🔍.

Also, while this document says solicitation class keywords begin with a reversed domain name and a colon (":"), future RFCs may define other mechanisms, as long as they don't clash 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 🙅‍♀️. Deciding that a particular keyword has to be used is a policy decision, and that's well outside what this document covers. It's expected that relevant policy bodies (e.g., governments, ISPs, developers, or others) will specify appropriate keywords, what those keywords mean, and any other policy requirements, like whether this extension has to be used, or not used, in particular circumstances ⚖️.

During the discussions for this proposal, people suggested getting rid of solicitation class keywords altogether and replacing them with a simple boolean (for example, "NO-SOLICITING YES", or "ADV", or "UBE") 🤔. But with a boolean, the extension would have to pick one single meaning for "YES" or whatever other label. Using solicitation class keywords instead keeps the mail infrastructure neutral, so different definitions can co-exist 🫶.

2.3. The MAIL FROM Command

"SOLICIT" is defined as a parameter for the "MAIL FROM" command 💌. It's 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 because of 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 can decide how to handle each message, on a per-message basis 🧁:

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 that example, the receiving MTA sent back a "550" status code, which means one message got rejected 🙅. The implementation also echoes back the keywords currently set for that user on the "550" status message 📣. The keyword it echoes is "org.example:ADV:ADLT", which shows how this per-recipient keyword added on to the base "net.example:ADV" class announced in the "EHLO" exchange 💜.

It's the receiving MTA's job to keep its policy consistent 🫡. If the receiving MTA is going to 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. And 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, listen up 👀: the source of the solicitation class keywords used in the "MAIL FROM" command MUST be the "Solicitation:" header described in Section 2.5. It MUST NOT be supplemented by extra 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 two MTAs are in a session using both the "NO-SOLICITING" extension and the Enhanced Mail Status Codes defined in [RFC3463], and a message gets rejected because a "SOLICIT" parameter is present, the correct error message to return will usually be "5.7.1" 🙈. That code is 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, might be a better fit in some situations, and developers should check [RFC3463] on this topic 📚. One example would be quotas or size restrictions on messages by class. An implementation MAY impose limits such as message size restrictions based on solicitation classes. When those limits are exceed, they SHOULD be reported using whatever status code is appropriate for that limit 💖.

In every case, 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. On top of the 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, and it contains one or more solicitation class keywords 💌:

Solicitation-header = "Solicitation:" 1*SP Solicitation-keywords

Here's what that header looks like in a message ✨:

To: Coupon Clipper <coupon_clipper@moonlink.example.com>
From: Spam King <save@burntmail.example.com>
Solicitation: net.example:ADV,org.example:ADV:ADLT

Lots of proposals, legal ones especially, have wanted keywords in the "Subject:" header 🙃. Visual cues in the subject can help human end users, but they don't give computer programs like mail transfer agents a clean set of cues to work with 🤖. Just like putting a "no solicitation" message in a greeting banner, this would overload what the "Subject:" header means 😬. Of course, there's no reason both mechanisms couldn't be used together. And either way, 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 🦋

okay so the Solicitation: mail header is only visible to the sending client 🫣 RFCs 2821 and 2822 are super strict that intermediate MTAs shall not change message headers, with the one exception of the Received: trace field. Since lots of current systems use a middle relay to spot unsolicited mail, they described an addition to the Received: header. 💅

[RFC2821] documents these productions for the Received: header:

   ; From RFC 2821
   With = "WITH" FWS Protocol CFWS
   Protocol = "ESMTP" / "SMTP" / Attdl-Protocol

And [RFC2822] defines a comment field like this:

   ; From RFC 2822
   comment         =       "(" *([FWS] ccontent) [FWS] ")"
   ccontent        =       ctext / quoted-pair / comment

The Mail-From-Solicit-Parameter from Section 2.3 above is a restricted form of ctext, so it gives us this production 🎀:

   With-Solicit = "WITH" FWS Protocol
              "(" [FWS] comment [FWS] ")"
   comment         =       "(" *([FWS] ccontent) [FWS] ")"
   ccontent = ctext / quoted-pair /
              comment / Mail-From-Solicit-Parameter
              ; The Mail-From-Solicit-Parameter
              ; is a restricted form of ctext

Here's an example of a Received: header from a conforming MTA 🌸:

   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)

Now the tea ☕: keywords in trace fields may not match the ones in the Solicitation: header, and trace fields can show up even when the header isn't there at all. So when you're figuring out which keywords apply 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 the ones meant to be relayed to another system. 🧚

Solicitation class keywords that a client sends 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 it got from the Solicitation: field uses valid syntax before it passes the contents along 🫶. An SMTP server SHOULD set this parameter after it detects the Solicitation: header field when it receives a message from a non-conforming MTA. 💜

2.8. No Default Solicitation Class 🙈

Implementations of the NO-SOLICITING service extension SHOULD NOT enable specific solicitation class keywords as a default in their software. Some policy makers apparently see default filtering in software as a prior restraint on commercial speech 😭 The thinking is that because the person installing and using the software never explicitly chose to turn on a certain type of filtering, some people could argue that filtering wasn't wanted at all. Not me being dramatic, it's literally in the doc 💀

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 way a user tells the system they want 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 meant to promote security during the message exchange process. Not a vibe for security, sorry bestie 😬

Also, this document does not address when a sender of electronic mail should or should not use this extension, and it does not address whether consent to send mail has been granted. 🙃

Here's the spicy part 🔥: this could lead to a situation where a sender starts using this extension well before most end users have started using it. In that situation, the sender might want to treat the absence of the extension on the receiving MTA as a sign of consent to receive mail. Absolutely not. Non-use of the NO-SOLICITING extension by a receiving MTA SHALL NOT indicate consent. No consent by silence, periodt. 💅👑

4. IANA Considerations 🌸

There are three IANA considerations in this document:

  1. Adding the NO-SOLICITING service extension to the Mail Parameters registry.
  2. Documenting the use of comments in trace fields.
  3. Creating 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 like so ✨:

   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. So the potential length of the MAIL FROM command goes up 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. Here's the registration template 🍓:

  • Header field name: Solicitation
  • Applicable protocol: mail
  • Status: standard
  • Author/Change controller: IETF
  • Specification document(s): RFC3865
  • Related information:

5. Author's Acknowledgements 🫶

The author would like to thank Rebecca Malamud for many discussions and ideas that led to this proposal. Big thanks too 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. came 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 📚✨

These are the extra reads. They're not required to implement anything, but they give the backstory on the spam fight, the court cases, and the numbers behind it. 🌸

Appendix A. Collected ABNF Descriptions (Normative) 💅

Here's the grammar all in one spot, so you can check every rule. The MUST in here is a real requirement, so don't skip it. 🫶

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

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. ✨

📦 where this page comes from