7Network Working Group C. Malamud
8Request for Comments: 3865 Memory Palace Press
9Category: Standards Track September 2004
12 A No Soliciting Simple Mail Transfer Protocol (SMTP)
17 This document specifies an Internet standards track protocol for the
18 Internet community, and requests discussion and suggestions for
19 improvements. Please refer to the current edition of the "Internet
20 Official Protocol Standards" (STD 1) for the standardization state
21 and status of this protocol. Distribution of this memo is unlimited.
25 Copyright (C) The Internet Society (2004).
29 This document proposes an extension to Soliciting Simple Mail
30 Transfer Protocol (SMTP) for an electronic mail equivalent to the
31 real-world "No Soliciting" sign. In addition to the service
32 extension, a new message header and extensions to the existing
33 "received" message header are described.
58Malamud Standards Track [Page 1]
60RFC 3865 No Soliciting September 2004
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
66 1.1. The Spam Pandemic. . . . . . . . . . . . . . . . . . . . 3
67 1.2. No Soliciting in the Real World. . . . . . . . . . . . . 4
68 1.3. No Soliciting and Electronic Mail. . . . . . . . . . . . 5
69 2. The No-Soliciting SMTP Service Extension . . . . . . . . . . . 6
70 2.1. The EHLO Exchange. . . . . . . . . . . . . . . . . . . . 7
71 2.2. Solicitation Class Keywords. . . . . . . . . . . . . . . 7
72 2.2.1. Note on Choice of Solicitation Class Keywords. . 8
73 2.3. The MAIL FROM Command. . . . . . . . . . . . . . . . . . 9
74 2.4. Error Reporting and Enhanced Mail Status Codes . . . . . 10
75 2.5. Solicitation Mail Header . . . . . . . . . . . . . . . . 10
76 2.6. Insertion of Solicitation Keywords in Trace Fields . . . 11
77 2.7. Relay of Messages. . . . . . . . . . . . . . . . . . . . 12
78 2.8. No Default Solicitation Class. . . . . . . . . . . . . . 12
79 3. Security Considerations . . . . . . . . . . . . . . . . . . . 13
80 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
81 4.1. The Mail Parameters Registry . . . . . . . . . . . . . . 13
82 4.2. Trace Fields . . . . . . . . . . . . . . . . . . . . . . 14
83 4.3. The Solicitation Mail Header . . . . . . . . . . . . . . 14
84 5. Author's Acknowledgements . . . . . . . . . . . . . . . . . . 14
85 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
86 6.1. Normative References . . . . . . . . . . . . . . . . . . 15
87 6.2. Informative References . . . . . . . . . . . . . . . . . 15
88 Appendix A. Collected ABNF Descriptions (Normative) . . . . . . . 18
89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
90 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 19
114Malamud Standards Track [Page 2]
116RFC 3865 No Soliciting September 2004
1211.1. The Spam Pandemic
123 Unsolicited Bulk Email (UBE), otherwise known as spam, has become as
124 one of the most pressing issues on the Internet. One oft-quoted
125 study estimated that spam would cost businesses $13 billion in 2003
126 [Ferris]. In April 2003, AOL reported that it had blocked 2.37
127 billion pieces of UBE in a single day [CNET]. And, in a sure sign
128 that UBE has become of pressing concern, numerous politicians have
129 begun to issue pronouncements and prescriptions for fighting this
130 epidemic [Schumer][FTC].
132 A variety of mechanisms from the technical community have been
133 proposed and/or implemented to fight UBE:
135 o Whitelists are lists of known non-spammers. For example, Habeas,
136 Inc. maintains a Habeas User List (HUL) of people who have agreed
137 to not spam. By including a haiku in email headers and enforcing
138 copyright on that ditty, they enforce their anti-spamming terms of
141 o Blacklists are lists of known spammers or ISPs that allow spam
144 o Spam filters run client-side or server-side to filter out spam
145 based on whitelists, blacklists, and textual and header analysis
148 o A large number of documents address the overall technical
149 considerations for the control of UBE [crocker-spam-techconsider],
150 operational considerations for SMTP agents [RFC2505], and various
151 extensions to the protocols to support UBE identification and
152 filtering [danisch-dns-rr-smtp][daboo-sieve-spamtest][crouzet-
155 o Various proposals have been advanced for "do not spam" lists, akin
156 to the Federal Trade Commission's "Do Not Call" list for
157 telemarketers [FTC.TSR].
161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
163 document are to be interpreted as described in BCP 14, RFC 2119
170Malamud Standards Track [Page 3]
172RFC 3865 No Soliciting September 2004
1751.2. No Soliciting in the Real World
177 Municipalities frequently require solicitors to register with the
178 town government. And, in many cases, the municipalities prohibit
179 soliciting in residences where the occupant has posted a sign. The
180 town of West Newbury, Massachusetts, for example, requires:
182 "It shall be unlawful for any canvasser or solicitor to enter the
183 premises of a resident or business who has displayed a 'No
184 Trespassing' or 'No Soliciting' sign or poster. Further, it shall
185 be unlawful for canvassers or solicitors to ignore a resident or
186 business person's no solicitation directive or remain on private
187 property after its owner has indicated that the canvasser or
188 solicitor is not welcome" [Newbury].
190 Registration requirements for solicitors, particularly those
191 soliciting for political or religious reasons, have been the subject
192 of a long string of court cases. However, the courts have generally
193 recognized that individuals may post "No Soliciting" signs and the
194 government may enforce the citizen's desire. In a recent case where
195 Jehovah's Witnesses challenged a registration requirement in the city
196 of Stratton, Connecticut, saying they derived their authority from
197 the Scriptures, not the city. However, the court noted:
199 "A section of the ordinance that petitioners do not challenge
200 establishes a procedure by which a resident may prohibit
201 solicitation even by holders of permits. If the resident files a
202 'No Solicitation Registration Form' with the mayor, and also posts
203 a 'No Solicitation' sign on his property, no uninvited canvassers
204 may enter his property... " [Watchtower].
206 Even government, which has a duty to promote free expression, may
207 restrict the use of soliciting on government property. In one case,
208 for example, a school district was allowed to give access to its
209 internal electronic mail system to the union that was representing
210 teachers, but was not required to do so to a rival union that was
211 attempting to gain the right to represent the teachers. The court
212 held that where property is not a traditional public forum "and the
213 Government has not dedicated its property to First Amendment
214 activity, such regulation is examined only for reasonableness"
217 The courts have consistently held that the state has a compelling
218 public safety reason for regulating solicitation. In Cantwell v.
219 Connecticut, the Supreme Court held that "a State may protect its
220 citizens from fraudulent solicitation by requiring a stranger in the
221 community, before permitting him publicly to solicit funds for any
222 purpose, to establish his identity and his authority to act for the
226Malamud Standards Track [Page 4]
228RFC 3865 No Soliciting September 2004
231 cause which he purports to represent" [Cantwell]. And, in Martin v.
232 City of Struthers, the court noted that "burglars frequently pose as
233 canvassers, either in order that they may have a pretense to discover
234 whether a house is empty and hence ripe for burglary, or for the
235 purpose of spying out the premises in order that they may return
236 later" [Martin]. The public safety issue applies very much to email,
237 where viruses can easily be delivered, in contrast to telephone
238 solicitations where public safety is not nearly as much an issue.
240 This analysis is U.S.-centric, which is partly due to the background
241 of the author. However, the concept of prohibiting unwanted
242 solicitation does carry over to other countries:
244 o In Hong Kong, offices frequently post "no soliciting" signs.
246 o In the United Kingdom, where door-to-door peddlers are fairly
247 common, "no soliciting" signs are also common.
249 o In Australia, where door-to-door does not appear to be a pressing
250 social problem, there was legislation passed which outlawed the
251 practice of placing ads under wipers of parked cars.
253 o In France, which has a long tradition of door-to-door
254 solicitation, apartment buildings often use trespass laws to
255 enforce "no solicitation" policies.
257 o In the Netherlands, where door-to-door solicitation is not a
258 pressing issue, there is a practice of depositing free
259 publications in mailboxes. The postal equivalent of "no spam"
260 signs are quite prevalent and serve notice that the publications
2631.3. No Soliciting and Electronic Mail
265 Many of the anti-spam proposals that have been advanced have great
266 merit, however none of them give notice to an SMTP agent in the
267 process of delivering mail that the receiver does not wish to receive
268 solicitations. Such a virtual sign would serve two purposes:
270 o It would allow the receiving system to "serve notice" that a
271 certain class of electronic mail is not desired.
273 o If a message is properly identified as belonging to a certain
274 class and that class of messages is not desired, transfer of the
275 message can be eliminated. Rather than filtering after delivery,
276 elimination of the message transfer can save network bandwidth,
277 disk space, and processing power.
282Malamud Standards Track [Page 5]
284RFC 3865 No Soliciting September 2004
287 This memo details a series of extensions to SMTP that have the
288 following characteristics:
290 o A service extension is described that allows a receiving Mail
291 Transport Agent (MTA) to signal the sending MTA that no soliciting
294 o A header field for the sender of the message is defined that
295 allows the sender to flag a message as conforming to a certain
298 o Trace fields for intermediate MTAs are extended to allow the
299 intermediate MTA to signal that a message is in a certain class.
301 Allowing the sender of a message to tag a message as being, for
302 example, unsolicited commercial email with adult content, allows
303 "good" spammers to conform to legal content labelling requirements by
304 governmental authorities, license agreements with service providers,
305 or conventions imposed by "whitelist" services. For senders of mail
306 who choose not to abide by these conventions, the intermediate trace
307 fields defined here allow the destination MTAs to perform appropriate
308 dispositions on the received message.
310 This extension provides a simple mean for senders, MTAs, and
311 receivers to assert keywords. This extension does not deal with any
312 issues of authentication or consent.
3142. The No-Soliciting SMTP Service Extension
316 Per [RFC2821], a "NO-SOLICITING" SMTP service extension is defined.
317 The service extension is declared during the initial "EHLO" SMTP
318 exchange. The extension has one optional parameter, consisting of
319 zero or more solicitation class keywords. Using the notation as
320 described in the Augmented BNF [RFC2234], the syntax is:
322 No-Soliciting-Service = "NO-SOLICITING"
323 [ SP Solicitation-keywords ]
325 As will be further described below, the "Solicitation-keywords"
326 construct is used to indicate which classes of messages are not
327 desired. A keyword that is presented during the initial "EHLO"
328 exchange applies to all messages exchanged in this session. As will
329 also be further described below, additional keywords may be specified
330 on a per-recipient basis as part of the response to a "RCPT TO"
338Malamud Standards Track [Page 6]
340RFC 3865 No Soliciting September 2004
3432.1. The EHLO Exchange
345 Keywords presented during the initial exchange indicate that no
346 soliciting in the named classes is in effect for all messages
347 delivered to this system. It is equivalent to the sign on the door
348 of an office building announcing a company-wide policy. For example:
350 R: <wait for connection on TCP port 25>
351 S: <open connection to server>
352 R: 220 trusted.example.com SMTP service ready
353 S: EHLO untrusted.example.com
354 R: 250-trusted.example.com says hello
355 R: 250-ENHANCEDSTATUSCODES
356 R: 250-NO-SOLICITING net.example:ADV
359 The "net.example:ADV" parameter to the "NO-SOLICITING" extension is
360 an example of a solicitation class keyword, the syntax of which is
361 described in the following section.
365 A similar proposal was advanced in 1999 by John Levine and Paul
366 Hoffman. This proposal used the SMTP greeting banner to specify
367 that unsolicited bulk email is prohibited on a particular system
368 through the use of the "NO UCE" keyword [Levine]. As the authors
369 note, their proposal has the potential of overloading the
370 semantics of the greeting banner, which may also be used for other
371 purposes (see, e.g., [Malamud]).
3732.2. Solicitation Class Keywords
375 The "NO-SOLICITING" service extension uses solicitation class
376 keywords to signify classes of solicitations that are not accepted.
377 Solicitation class keywords are separated by commas.
379 There is no default solicitation class keyword for the service. In
380 other words, the following example is a "no-op":
382 R : 250-NO-SOLICITING
384 While the above example is a "no-op" it is useful for an MTA that
385 wishes to pass along all messages, but would also like to pass along
386 "SOLICIT=" parameters on a message-by-message basis. The above
387 example invokes the use of the extension but does not signal any
388 restrictions by class of message.
394Malamud Standards Track [Page 7]
396RFC 3865 No Soliciting September 2004
399 The initial set of solicitation class keywords all begin with a
400 domain name with the labels reversed, followed by a colon. For
401 example, the domain name "example.com" could be used to form the
402 beginning of a solicitation class keyword of "com.example:". The
403 solicitation class keyword is then followed by an arbitrary set of
404 characters drawn from the following construct:
406 Solicitation-keywords = word
408 ; length of this string is limited
409 ; to <= 1000 characters
410 word = ALPHA 0*(wordchar)
411 wordchar = ("." / "-" / "_" / ":" / ALPHA / DIGIT)
413 A solicitation class keyword MUST be less than 1000 characters. Note
414 however that a set of keywords used in the operations defined in this
415 document must also be less than 1000 characters. Implementors are
416 thus advised to keep their solicitation class keywords brief.
418 Any registrant of a domain name may define a solicitation class
419 keyword. Discovery of solicitation class keywords is outside the
420 scope of this document. However, those registrants defining keywords
421 are advised to place a definition of their solicitation class
422 keywords on a prominent URL under their control such that search
423 engines and other discovery mechanisms can find them.
425 While this document defines solicitation class keywords as beginning
426 with a reversed domain name followed by a colon (":"), future RFCs
427 may define additional mechanisms that do not conflict with this
4302.2.1. Note on Choice of Solicitation Class Keywords
432 This document does not specify which solicitation class keywords
433 shall or shall not be used on a particular message. The requirement
434 to use a particular keyword is a policy decision well outside the
435 scope of this document. It is expected that relevant policy bodies
436 (e.g., governments, ISPs, developers, or others) will specify
437 appropriate keywords, the definition of the meaning of those
438 keywords, and any other policy requirements, such as a requirement to
439 use or not use this extension in particular circumstances.
441 During discussions of this proposal, there were several suggestions
442 to do away with the solicitation class keywords altogether and
443 replace the mechanism with a simple boolean (e.g., "NO-SOLICITING
444 YES" or "ADV" or "UBE"). Under a boolean mechanism, this extension
445 would have to adopt a single definition of what "YES" or other label
450Malamud Standards Track [Page 8]
452RFC 3865 No Soliciting September 2004
455 means. By using the solicitation class keywords approach, the mail
456 infrastructure remains a neutral mechanism, allowing different
457 definitions to co-exist.
4592.3. The MAIL FROM Command
461 "SOLICIT" is defined as a parameter for the "MAIL FROM" command. The
462 "SOLICIT" parameter is followed by an equal sign and a comma
463 separated list of solicitation class keywords. The syntax for this
466 Mail-From-Solicit-Parameter = "SOLICIT"
467 "=" Solicitation-keywords
468 ; Solicitation-keywords, when used in MAIL FROM command
469 ; MUST be identical to those in the Solicitation: header.
471 Note that white space is not permitted in this production.
473 As an informational message, the "550" or "250" replies to the "RCPT
474 TO" command may also contain the "SOLICIT" parameter. If a message
475 is being rejected due to a solicitation class keyword match,
476 implementations SHOULD echo which solicitation classes are in effect.
477 See Section 2.4 for more on error reporting.
479 The receiving system may decide on a per-message basis the
480 appropriate disposition of messages:
482 R: <wait for connection on TCP port 25>
483 S: <open connection to server>
484 R: 220 trusted.example.com SMTP service ready
485 S: EHLO untrusted.example.com
486 R: 250-trusted.example.com says hello
487 R: 250-NO-SOLICITING net.example:ADV
488 S: MAIL FROM:<save@example.com> SOLICIT=org.example:ADV:ADLT
489 S: RCPT TO:<coupon_clipper@moonlink.example.com>
490 R: 250 <coupon_clipper@moonlink.example.com>... Recipient ok
491 S: RCPT TO:<grumpy_old_boy@example.net>
492 R: 550 <grumpy_old_boy@example.net> SOLICIT=org.example:ADV:ADLT
494 In the previous example, the receiving MTA returned a "550" status
495 code, indicating that one message was being rejected. The
496 implementation also echoes back the currently set keywords for that
497 user on the "550" status message. The solicitation class keyword
498 which is echoed back is "org.example:ADV:ADLT" which illustrates how
499 this per-recipient solicitation class keyword has supplemented the
500 base "net.example:ADV" class declared in the "EHLO" exchange.
506Malamud Standards Track [Page 9]
508RFC 3865 No Soliciting September 2004
511 It is the responsibility of a receiving MTA to maintain a consistent
512 policy. If the receiving MTA will reject a message because of
513 solicitation class keywords, the MTA SHOULD declare those keywords
514 either in the initial "EHLO" exchange or on a per-recipient basis.
515 Likewise, a receiving MTA SHOULD NOT deliver a message where the
516 "Solicitation:" matches a solicitation class keyword that was
517 presented during the initial "EHLO" exchange or on a per-recipient
520 Developers should also note that the source of the solicitation class
521 keywords used in the "MAIL FROM" command MUST be the "Solicitation:"
522 header described in Section 2.5 and MUST NOT be supplemented by
523 additional solicitation class keywords derived from the "Received:"
524 header trace fields which are described in Section 2.6.
5262.4. Error Reporting and Enhanced Mail Status Codes
528 If a session between two MTAs is using both the "NO-SOLICITING"
529 extension and the Enhanced Mail Status Codes as defined in [RFC3463]
530 and a message is rejected based on the presence of a "SOLICIT"
531 parameter, the correct error message to return will usually be
532 "5.7.1", defined as "the sender is not authorized to send to the
533 destination... (because) of per-host or per-recipient filtering."
535 Other codes, including temporary status codes, may be more
536 appropriate in some circumstances and developers should look to
537 [RFC3463] on this subject. An example of such a situation might be
538 the use of quotas or size restrictions on messages by class. An
539 implementation MAY impose limits such as message size restrictions
540 based on solicitation classes, and when such limits are exceed they
541 SHOULD be reported using whatever status code is appropriate for that
544 In all cases, an implementation SHOULD include a "Mail-From-Solicit-
545 Parameter" on a "550" or other reply that rejects message delivery.
546 The parameter SHOULD includes the solicitation class keyword(s) that
547 matched. In addition to the solicitation class keyword(s) that
548 matched, an implementation MAY include additional solicitation class
549 keywords that are in effect.
5512.5. Solicitation Mail Header
553 Per [RFC2822], a new "Solicitation:" header field is defined which
554 contains one or more solicitation class keywords.
556 Solicitation-header = "Solicitation:" 1*SP Solicitation-keywords
562Malamud Standards Track [Page 10]
564RFC 3865 No Soliciting September 2004
567 An example of this header follows:
569 To: Coupon Clipper <coupon_clipper@moonlink.example.com>
570 From: Spam King <save@burntmail.example.com>
571 Solicitation: net.example:ADV,org.example:ADV:ADLT
573 Several proposals, particularly legal ones, have suggested requiring
574 the use of keywords in the "Subject:" header. While embedding
575 information in the "Subject:" header may provide visual cues to end
576 users, it does not provide a straightforward set of cues for computer
577 programs such as mail transfer agents. As with embedding a "no
578 solicitation" message in a greeting banner, this overloads the
579 semantics of the "Subject:" header. Of course, there is no reason
580 why both mechanisms can't be used, and in any case the
581 "Solicitation:" header could be automatically inserted by the
582 sender's Mail User Agent (MUA) based on the contents of the subject
5852.6. Insertion of Solicitation Keywords in Trace Fields
587 The "Solicitation:" mail header is only available to the sending
588 client. RFCs 2821 and 2822 are quite specific that intermediate MTAs
589 shall not change message headers, with the sole exception of the
590 "Received:" trace field. Since many current systems use an
591 intermediate relay to detect unsolicited mail, an addition to the
592 "Received:" header is described.
594 [RFC2821] documents the following productions for the "Received:"
595 header in a mail message:
598 With = "WITH" FWS Protocol CFWS
599 Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
601 Additionally, [RFC2822] defines a comment field as follows:
604 comment = "(" *([FWS] ccontent) [FWS] ")"
605 ccontent = ctext / quoted-pair / comment
607 The "Mail-From-Solicit-Parameter" defined in Section 2.3 above is a
608 restricted form of ctext, yielding the following production:
610 With-Solicit = "WITH" FWS Protocol
611 "(" [FWS] comment [FWS] ")"
612 comment = "(" *([FWS] ccontent) [FWS] ")"
613 ccontent = ctext / quoted-pair /
614 comment / Mail-From-Solicit-Parameter
618Malamud Standards Track [Page 11]
620RFC 3865 No Soliciting September 2004
623 ; The Mail-From-Solicit-Parameter
624 ; is a restricted form of ctext
626 An example of a Received: header from a conforming MTA is as follows:
628 Received: by foo-mta.example.com with
629 ESMTP (SOLICIT=net.example:ADV,org.example:ADV:ADLT) ;
630 Sat, 9 Aug 2003 16:54:42 -0700 (PDT)
632 It should be noted that keywords presented in trace fields may not
633 agree with those found in the "Solicitation:" header and trace fields
634 may exist even if the header is not present. When determining which
635 keywords are applicable to a particular exchange of messages,
636 implementors SHOULD examine any keywords found in the "Solicitation:"
637 header. Implementors MAY examine other keywords found in the trace
6402.7. Relay of Messages
642 The "NO-SOLICITING" service extension, if present, applies to all
643 messages handled by the receiving Message Transfer Agent (MTA),
644 including those messages intended to be relayed to another system.
646 Solicitation class keywords supplied by a client on a "SOLICIT"
647 parameter on a "MAIL FROM" command SHOULD be obtained from the
648 "Solicitation:" field in the message header. An SMTP client SHOULD,
649 however, verify that the list of solicitation class keywords obtained
650 from the "Solicitation:" field uses valid syntax before conveying its
651 contents. An SMTP server SHOULD set this parameter after detecting
652 the presence of the "Solicitation:" header field when receiving a
653 message from a non-conforming MTA.
6552.8. No Default Solicitation Class
657 Implementations of "NO-SOLICITING" service extension SHOULD NOT
658 enable specific solicitation class keywords as a default in their
659 software. There are some indications that some policy makers may
660 view a default filtering in software as a prior restraint on
661 commercial speech. In other words, because the person installing and
662 using the software did not make an explicit choice to enable a
663 certain type of filtering, some might argue that such filtering was
666 Likewise, it is recommended that a system administrator installing
667 software SHOULD NOT enable additional per-recipient filtering by
668 default for a user. Again, individual users should specifically
669 request any additional solicitation class keywords.
674Malamud Standards Track [Page 12]
676RFC 3865 No Soliciting September 2004
679 The mechanism for an individual user to communicate their desire to
680 enable certain types of filtering is outside the scope of this
6833. Security Considerations
685 This extension does not provide authentication of senders or other
686 measures intended to promote security measures during the message
689 In particular, this document does not address the circumstances under
690 which a sender of electronic mail should or should not use this
691 extension and does not address the issues of whether consent to send
692 mail has been granted.
694 This might lead to a scenario in which a sender of electronic mail
695 begins to use this extension well before the majority of end users
696 have begun to use it. In this scenario, the sender might wish to use
697 the absence of the extension on the receiving MTA as an implication
698 of consent to receive mail. Non-use of the "NO-SOLICITING" extension
699 by a receiving MTA SHALL NOT indicate consent.
7014. IANA Considerations
703 There are three IANA considerations presented in this document:
705 1. Addition of the "NO-SOLICITING" service extension to the Mail
708 2. Documentation of the use of comments in trace fields.
710 3. Creation of a "Solicitation:" mail header.
7124.1. The Mail Parameters Registry
714 The IANA Mail Parameters registry documents SMTP service extensions.
715 The "NO-SOLICITATION" service extension has been added to this
718 Keywords Description Reference
719 ------------ ------------------------------ ---------
720 NO-SOLICITING Notification of no soliciting. RFC3865
722 The parameters subregistry would need to be modified as follows:
724 Service Ext EHLO Keyword Parameters Reference
725 ----------- ------------ ----------- ---------
726 No Soliciting NO-SOLICITING Solicitation-keywords RFC3865
730Malamud Standards Track [Page 13]
732RFC 3865 No Soliciting September 2004
735 The maximum length of Solicitation-keywords is 1000 characters. The
736 "SOLICIT=" parameter is defined for use on the MAIL FROM command.
737 The potential length of the MAIL FROM command is thus increased by
742 The Mail Parameters registry would need to be modified to note the
743 use of the comment facility in trace fields to indicate Solicitation
7464.3. The Solicitation Mail Header
748 Per [RFC3864], the "Solicitation:" header field is added to the IANA
749 Permanent Message Header Field Registry. The following is the
750 registration template:
752 o Header field name: Solicitation
753 o Applicable protocol: mail
755 o Author/Change controller: IETF
756 o Specification document(s): RFC3865
757 o Related information:
7595. Author's Acknowledgements
761 The author would like to thank Rebecca Malamud for many discussions
762 and ideas that led to this proposal and to John C. Klensin and
763 Marshall T. Rose for their extensive input on how it could be
764 properly implemented in SMTP. Eric Allman, Harald Alvestrand, Steven
765 M. Bellovin, Doug Barton, Kent Crispin, Dave Crocker, Ned Freed,
766 Curtis Generous, Arnt Gulbrandsen, John Levine, Keith Moore, Hector
767 Santos, Ted Hardie, Paul Vixie, and Pindar Wong kindly provided
768 reviews of the document and/or suggestions for improvement.
769 Information about soliciting outside the U.S. was received from Rob
770 Blokzijl, Jon Crowcroft, Christian Huitema, Geoff Huston, and Pindar
771 Wong. John Levine pointed out the contrast between this proposal and
772 "do not spam" lists. As always, all errors and omissions are the
773 responsibility of the author.
786Malamud Standards Track [Page 14]
788RFC 3865 No Soliciting September 2004
7936.1. Normative References
795 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
796 Requirement Levels", BCP 14, RFC 2119, March 1997.
798 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
799 Syntax Specifications: ABNF", RFC 2234, November 1997.
801 [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
804 [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
807 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
810 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
811 Procedures for Message Header Fields", BCP 90, RFC 3864,
8146.2. Informative References
816 [Assassin] Mason, J., "Spamassassin - Mail Filter to Identify Spam
817 Using Text Analysis", Version 2.55, May 2003,
818 <http://www.mirror.ac.uk/sites/spamassassin.taint.org/
819 spamassassin.org/doc/spamassassin.html>
821 [CNET] CNET News.Com, "AOL touts spam-fighting prowess", April
822 2003, <http://news.com.com/2100-1025-998944.html>.
824 [Cantwell] U.S. Supreme Court, "Cantwell v. State of Connecticut",
825 310 U.S. 296 (1940), May 1940,
826 <http://caselaw.lp.findlaw.com/scripts/
827 getcase.pl?court=US&vol=310&invol=296>
829 [FTC] Federal Trade Commission, "Federal, State, Local Law
830 Enforcers Target Deceptive Spam and Internet Scams",
832 <http://www.ftc.gov/opa/2002/11/nenetforcema.htm>.
834 [FTC.TSR] Federal Trade Commission, "Telemarketing Sales Rule",
835 Federal Register Vol. 68, No. 19, January 2003,
836 <http://www.ftc.gov/os/2002/12/tsrfinalrule.pdf>.
842Malamud Standards Track [Page 15]
844RFC 3865 No Soliciting September 2004
847 [Ferris] Associated Press, "Study: Spam costs businesses $13
848 billion", January 2003,
849 <http://www.cnn.com/2003/TECH/biztech/01/03/
850 spam.costs.ap/index.html>
852 [Habeas] Habeas, Inc., "Habeas Compliance Message", 2004,
853 <http://www.habeas.com/servicesComplianceStds.html>
855 [crocker-spam-techconsider]
856 Crocker, D., "Technical Considerations for Spam Control
857 Mechanisms", Work in Progress, February 2004.
860 Crouzet, B., "Authenticated Mail Transfer Protocol",
861 Work in Progress, May 2004.
863 [daboo-sieve-spamtest]
864 Daboo, C., "SIEVE Spamtest and Virustest Extensions",
865 Work in Progress, October 2003.
867 [danisch-dns-rr-smtp]
868 Danisch, H., "The RMX DNS RR and method for lightweight
869 SMTP sender authorization", Work in Progress, August
872 [Levine] Levine, J. and P. Hoffman, "Anti-UBE and Anti-UCE
873 Keywords in SMTP Banners", Revision 1.1, March 1999,
874 <http://www.cauce.org/proposal/smtp-banner-rfc.shtml>.
876 [Malamud] Malamud, C., "An Internet Prayer Wheel", Mappa.Mundi
877 Magazine, August 1999,
878 <http://mappa.mundi.net/cartography/Wheel/>.
880 [Martin] U.S. Supreme Court, "Martin v. City of Struthers, Ohio",
881 319 U.S. 141 (1943), May 1943,
882 <http://caselaw.lp.findlaw.com/scripts/
883 getcase.pl?court=US&vol=319&invol=141>
885 [Newbury] The Town of West Newbury, Massachusetts, "Soliciting/
886 Canvassing By-Law", Chapter 18 Section 10, March 2002,
887 <http://www.town.west-newbury.ma.us/Public_Documents/
888 WestNewburyMA_Bylaws/000A1547-70E903AC>
890 [Perry] U.S. Supreme Court, "Perry Education Association v.
891 Perry Local Educators' Association", 460 U.S. 37 (1983),
892 February 1983, <http://caselaw.lp.findlaw.com/scripts/
893 getcase.pl?court=US&vol=460&invol=37>
898Malamud Standards Track [Page 16]
900RFC 3865 No Soliciting September 2004
903 [RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs",
904 BCP 30, RFC 2505, February 1999.
906 [ROKSO] Spamhaus.Org, "Register of Known Spam Operations",
908 <http://www.spamhaus.org/rokso/index.lasso>.
910 [Schumer] Charles, C., "Schumer, Christian Coalition Team Up to
911 Crack Down on Email Spam Pornography", June 2003,
913 www.senate.gov/~schumer/SchumerWebsite/pressroom/
914 press_releases/PR01782.html>.
916 [Watchtower] U.S. Supreme Court, "Watchtower Bible & Tract Society of
917 New York, Inc., et al. v. Village of Stratton et al.",
918 122 S.Ct. 2080 (2002), June 2002,
919 <http://caselaw.lp.findlaw.com/scripts/
920 getcase.pl?court=US&vol=000&invol=00-1737>
954Malamud Standards Track [Page 17]
956RFC 3865 No Soliciting September 2004
959Appendix A. Collected ABNF Descriptions (Normative)
961 Solicitation-keywords = word
963 ; length of this string is limited
964 ; to <= 1000 characters
965 word = ALPHA 0*(wordchar)
966 wordchar = ("." / "-" / "_" / ":" / ALPHA / DIGIT)
968 ; used in the initial EHLO exchange
969 No-Soliciting-Service = "NO-SOLICITING"
970 [ SP Solicitation-keywords ]
972 ; used on the Solicitation: message header
973 Solicitation-header = "Solicitation:" 1*SP Solicitation-keywords
975 ; used on the MAIL FROM command and replies,
976 ; and on Received: headers.
977 Mail-From-Solicit-Parameter =
978 "SOLICIT" "=" Solicitation-keywords
979 ; Solicitation-keywords, when used in
980 ; the MAIL FROM command MUST be identical
981 ; to those in the Solicitation: header.
983 ; Used on Received: headers
984 With-Solicit = "WITH" FWS Protocol
985 "(" [FWS] comment [FWS] ")"
987 comment = "(" *([FWS] ccontent) [FWS] ")"
988 ccontent = ctext / quoted-pair /
989 comment / Mail-From-Solicit-Parameter
990 ; The Mail-From-Solicit-Parameter
991 ; is a restricted form of ctext
993 With = "WITH" FWS Protocol CFWS
994 Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
995 Attdl-Protocol = Atom
1005 EMail: carl@media.org
1010Malamud Standards Track [Page 18]
1012RFC 3865 No Soliciting September 2004
1015Full Copyright Statement
1017 Copyright (C) The Internet Society (2004). This document is subject
1018 to the rights, licenses and restrictions contained in BCP 78, and
1019 except as set forth therein, the authors retain all their rights.
1021 This document and the information contained herein are provided on an
1022 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1023 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1024 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1025 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1026 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1027 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1029Intellectual Property
1031 The IETF takes no position regarding the validity or scope of any
1032 Intellectual Property Rights or other rights that might be claimed to
1033 pertain to the implementation or use of the technology described in
1034 this document or the extent to which any license under such rights
1035 might or might not be available; nor does it represent that it has
1036 made any independent effort to identify any such rights. Information
1037 on the procedures with respect to rights in RFC documents can be
1038 found in BCP 78 and BCP 79.
1040 Copies of IPR disclosures made to the IETF Secretariat and any
1041 assurances of licenses to be made available, or the result of an
1042 attempt made to obtain a general license or permission for the use of
1043 such proprietary rights by implementers or users of this
1044 specification can be obtained from the IETF on-line IPR repository at
1045 http://www.ietf.org/ipr.
1047 The IETF invites any interested party to bring to its attention any
1048 copyrights, patents or patent applications, or other proprietary
1049 rights that may cover technology that may be required to implement
1050 this standard. Please address the information to the IETF at ietf-
1055 Funding for the RFC Editor function is currently provided by the
1066Malamud Standards Track [Page 19]