idnits 2.17.1 draft-malamud-no-soliciting-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 852. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 836. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 842. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 858), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 34. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 608 has weird spacing: '...r field is...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (March 21, 2004) is 7335 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'FWS' is mentioned on line 495, but not defined == Unused Reference: 'Cantwell' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'Martin' is defined on line 699, but no explicit reference was found in the text == Unused Reference: 'Newbury' is defined on line 704, but no explicit reference was found in the text == Unused Reference: 'Perry' is defined on line 709, but no explicit reference was found in the text == Unused Reference: 'Watchtower' is defined on line 726, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 747, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-danisch-dns-rr-smtp-03 ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) Summary: 13 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Malamud 3 Internet-Draft Memory Palace Press 4 Expires: September 19, 2004 March 21, 2004 6 A No Soliciting SMTP Service Extension 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3667. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on September 19, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This Internet-Draft proposes an extension to SMTP for an electronic 39 mail equivalent to the real-world "No Soliciting" sign. In addition 40 to the service extension, a new message header and extensions to the 41 existing "received" message header are described. 43 Terminology 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in BCP 14, [RFC2119]. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 The Spam Pandemic . . . . . . . . . . . . . . . . . . . . . 3 53 1.2 No Soliciting in the Real World . . . . . . . . . . . . . . 3 54 1.3 No Soliciting and Electronic Mail . . . . . . . . . . . . . 5 55 2. The No-Soliciting SMTP Service Extension . . . . . . . . . . 7 56 2.1 The EHLO Exchange . . . . . . . . . . . . . . . . . . . . . 7 57 2.2 Solicitation Class Keywords . . . . . . . . . . . . . . . . 8 58 2.2.1 Note on Choice of Solicitation Class Keywords . . . . . . . 9 59 2.3 The MAIL FROM Command . . . . . . . . . . . . . . . . . . . 9 60 2.4 Error Reporting and Enhanced Mail Status Codes . . . . . . . 10 61 2.5 Solicitation Mail Header . . . . . . . . . . . . . . . . . . 11 62 2.6 Insertion of Solicitation Keywords in Trace Fields . . . . . 11 63 2.7 Relay of Messages . . . . . . . . . . . . . . . . . . . . . 12 64 2.8 No Default Solicitation Class . . . . . . . . . . . . . . . 13 65 3. Security Considerations . . . . . . . . . . . . . . . . . . 14 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 67 4.1 The Mail Parameters Registry . . . . . . . . . . . . . . . . 15 68 4.2 Trace Fields . . . . . . . . . . . . . . . . . . . . . . . . 15 69 4.3 The Solicitation Mail Header . . . . . . . . . . . . . . . . 15 70 5. Author's Acknowledgements . . . . . . . . . . . . . . . . . 17 71 Informative References . . . . . . . . . . . . . . . . . . . 18 72 Normative References . . . . . . . . . . . . . . . . . . . . 20 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . 20 74 A. Collected ABNF Descriptions (Normative) . . . . . . . . . . 21 75 B. Status of This Document [To Be Removed Upon Publication] . . 22 76 B.1 RFC Category . . . . . . . . . . . . . . . . . . . . . . . . 22 77 B.2 Document Repository . . . . . . . . . . . . . . . . . . . . 22 78 Intellectual Property and Copyright Statements . . . . . . . 23 80 1. Introduction 82 1.1 The Spam Pandemic 84 Unsolicited Bulk Email (UBE), otherwise known as spam, has become as 85 one of the most pressing issues on the Internet. One oft-quoted 86 study estimated that spam would cost businesses $13 billion in 87 2003.[Ferris] In April 2003, AOL reported that it had blocked 2.37 88 billion pieces of UBE in a single day.[CNET] And, in a sure sign that 89 UBE has become of pressing concern, numerous politicians have begun 90 to issue pronouncements and prescriptions for fighting this 91 epidemic.[Schumer][FTC] 93 A variety of mechanisms from the technical community have been 94 proposed and/or implemented to fight UBE: 96 o Whitelists are lists of known non-spammers. For example, Habeas, 97 Inc. maintains a Habeas User List (HUL) of people who have agreed 98 to not spam. By including a haiku in email headers and enforcing 99 copyright on that ditty, they enforce their anti-spamming terms of 100 service.[Habeas] 102 o Blacklists are lists of known spammers or ISPs that allow 103 spam.[ROKSO] 105 o Spam filters run client-side or server-side to filter out spam 106 based on whitelists, blacklists, and textual and header 107 analysis.[Assassin] 109 o A large number of documents address the overall technical 110 considerations for the control of 111 UBE[I-D.crocker-spam-techconsider], operational considerations for 112 SMTP agents[RFC2505], and various extensions to the protocols to 113 support UBE identification and filtering. 114 [I-D.danisch-dns-rr-smtp][I-D.daboo-sieve-spamtest][I-D.crouzet-amtp] 116 o Various proposals have been advanced for "do not spam" lists, akin 117 to the Federal Trade Commission's "Do Not Call" list for 118 telemarketers.[FTC.TSR] 120 1.2 No Soliciting in the Real World 122 Municipalities frequently require solicitors to register with the 123 town government. And, in many cases, the municipalities prohibit 124 soliciting in residences where the occupant has posted a sign. The 125 town of West Newbury, Massachusetts, for example, requires: 127 "It shall be unlawful for any canvasser or solicitor to enter the 128 premises of a resident or business who has displayed a 'No 129 Trespassing' or 'No Soliciting' sign or poster. Further, it shall 130 be unlawful for canvassers or solicitors to ignore a resident or 131 business person's no solicitation directive or remain on private 132 property after its owner has indicated that the canvasser or 133 solicitor is not welcome."[Newbury] 135 Registration requirements for solicitors, particularly those 136 soliciting for political or religious reasons, have been the subject 137 of a long string of court cases. However, the courts have generally 138 recognized that individuals may post "No Soliciting" signs and the 139 government may enforce the citizen's desire. In a recent case where 140 Jehovah's Witnesses challenged a registration requirement in the city 141 of Stratton, Connecticut, saying they derived their authority from 142 the Scriptures, not the city. However, the court noted: 144 "A section of the ordinance that petitioners do not challenge 145 establishes a procedure by which a resident may prohibit 146 solicitation even by holders of permits. If the resident files a 147 'No Solicitation Registration Form' with the mayor, and also posts 148 a 'No Solicitation' sign on his property, no uninvited canvassers 149 may enter his property ..."[Watchtower] 151 Even government, which has a duty to promote free expression, may 152 restrict the use of soliciting on government property. In one case, 153 for example, a school district was allowed to give access to its 154 internal electronic mail system to the union that was representing 155 teachers, but was not required to do so to a rival union that was 156 attempting to gain the right to represent the teachers. The court 157 held that where property is not a traditional public forum "and the 158 Government has not dedicated its property to First Amendment 159 activity, such regulation is examined only for 160 reasonableness."[Perry] 162 The courts have consistently held that the state has a compelling 163 public safety reason for regulating solicitation. In Cantwell v. 164 Connecticut, the Supreme Court held that "a State may protect its 165 citizens from fraudulent solicitation by requiring a stranger in the 166 community, before permitting him publicly to solicit funds for any 167 purpose, to establish his identity and his authority to act for the 168 cause which he purports to represent."[Cantwell] And, in Martin v. 169 City of Struthers, the court noted that "burglars frequently pose as 170 canvassers, either in order that they may have a pretense to discover 171 whether a house is empty and hence ripe for burglary, or for the 172 purpose of spying out the premises in order that they may return 173 later."[Martin] The public safety issue applies very much to email, 174 where viruses can easily be delivered, in contrast to telephone 175 solicitations where public safety is not nearly as much an issue. 177 This analysis is U.S.-centric, which is partly due to the background 178 of the author. However, the concept of prohibiting unwanted 179 solicitation does carry over to other countries: 181 o In Hong Kong, offices frequently post "no soliciting" signs. 183 o In the United Kingdom, where door-to-door peddlers are fairly 184 common, "no soliciting" signs are also common. 186 o In Australia, where door-to-door does not appear to be a pressing 187 social problem, there was legislation passed which outlawed the 188 practice of placing ads under wipers of parked cars. 190 o In France, which has a long tradition of door-to-door 191 solicitation, apartment buildings often use trespass laws to 192 enforce "no solicitation" policies. 194 o In the Netherlands, where door-to-door solicitation is not a 195 pressing issue, there is a practice of depositing free 196 publications in mailboxes. The postal equivalent of "no spam" 197 signs are quite prevalent and serve notice that the publications 198 are not desired. 200 1.3 No Soliciting and Electronic Mail 202 Many of the anti-spam proposals that have been advanced have great 203 merit, however none of them give notice to an SMTP agent in the 204 process of delivering mail that the receiver does not wish to receive 205 solicitations. Such a virtual sign would serve two purposes: 207 o It would allow the receiving system to "serve notice" that a 208 certain class of electronic mail is not desired. 210 o If a message is properly identified as belonging to a certain 211 class and that class of messages is not desired, transfer of the 212 message can be eliminated. Rather than filtering after delivery, 213 elimination of the message transfer can save network bandwidth, 214 disk space, and processing power. 216 This memo details a series of extensions to SMTP that have the 217 following characteristics: 219 o A service extension is described that allows a receiving Mail 220 Transport Agent (MTA) to signal the sending MTA that no soliciting 221 is in effect. 223 o A header field for the sender of the message is defined that 224 allows the sender to flag a message as conforming to a certain 225 class. 227 o Trace fields for intermediate MTAs are extended to allow the 228 intermediate MTA to signal that a message is in a certain class. 230 Allowing the sender of a message to tag a message as being, for 231 example, unsolicited commercial email with adult content, allows 232 "good" spammers to conform to legal content labelling requirements by 233 governmental authorities, license agreements with service providers, 234 or conventions imposed by "whitelist" services. For senders of mail 235 who choose not to abide by these conventions, the intermediate trace 236 fields defined here allow the destination MTAs to perform appropriate 237 dispositions on the received message. 239 This extension provides a simple mean for senders, MTAs, and 240 receivers to assert keywords drawn from a common registry. This 241 extension does not deal with any issues of authentication or consent. 243 2. The No-Soliciting SMTP Service Extension 245 Per [RFC2821], a "NO-SOLICITING" SMTP service extension is defined. 246 The service extension is declared during the initial "EHLO" SMTP 247 exchange. The extension has one optional parameter, consisting of 248 zero or more solicitation class keywords. Using the notation as 249 described in the Augmented BNF[RFC2234], the syntax is: 251 No-Soliciting-Service = "NO-SOLICITING" 252 [ SP Solicitation-keywords ] 254 As will be further described below, the "Solicitation-keywords" 255 construct is used to indicate which classes of messages are not 256 desired. A keyword that is presented during the initial "EHLO" 257 exchange applies to all messages exchanged in this session. As will 258 also be further described below, additional keywords may be specified 259 on a per-recipient basis as part of the response to a "RCPT TO" 260 command. 262 2.1 The EHLO Exchange 264 Keywords presented during the initial exchange indicate that no 265 soliciting in the named classes is in effect for all messages 266 delivered to this system. It is equivalent to the sign on the door 267 of an office building announcing a company-wide policy. For example: 269 R: 270 S: 271 R: 220 trusted.example.com SMTP service ready 272 S: EHLO untrusted.example.com 273 R: 250-trusted.example.com says hello 274 R: 250-ENHANCEDSTATUSCODES 275 R: 250-NO-SOLICITING net.example:ADV 276 R: 250 SIZE 20480000 278 The "net.example:ADV" parameter to the "NO-SOLICITING" extension is 279 an example of a solicitation class keyword, the syntax of which is 280 described in the following section. 282 Historical Note: 284 A similar proposal was advanced in 1999 by John Levine and Paul 285 Hoffman. This proposal used the SMTP greeting banner to specify 286 that unsolicited bulk email is prohibited on a particular system 287 through the use of the "NO UCE" keyword.[Levine] As the authors 288 note, their proposal has the potential of overloading the 289 semantics of the greeting banner, which may also be used for other 290 purposes (see, e.g., [Malamud]). 292 2.2 Solicitation Class Keywords 294 The "NO-SOLICITING" service extension uses solicitation class 295 keywords to signify classes of solicitations that are not accepted. 296 Solicitation class keywords are separated by commas. 298 There is no default solicitation class keyword for the service. In 299 other words, the following example is a "no-op": 301 R: 250-NO-SOLICITING 303 While the above example is a "no-op" it is useful for an MTA that 304 wishes to pass along all messages, but would also like to pass along 305 "SOLICIT=" parameters on a message-by-message basis. The above 306 example invokes the use of the extension but does not signal any 307 restrictions by class of message. 309 The initial set of solicitation class keywords all begin with a 310 domain name with the labels reversed, followed by a colon. For 311 example, the domain name "example.com" could be used to form the 312 beginning of a solicitation class keyword of "com.example:". The 313 solicitation class keyword is then followed by an arbitrary set of 314 characters drawn from the following construct: 316 Solicitation-keywords = word 317 0*("," word) 318 ; length of this string is limited 319 ; to <= 1000 characters 320 word = ALPHA 0*(wordchar) 321 wordchar = ("." / "-" / "_" / ":" / ALPHA / DIGIT) 323 A solicitation class keyword MUST be less than 1000 characters. Note 324 however that a set of keywords used in the operations defined in this 325 draft must also be less than 1000 characters. Implementors are thus 326 advised to keep their solicitation class keywords brief. 328 Any registrant of a domain name may define a solicitation class 329 keyword. Discovery of solicitation class keywords is outside the 330 scope of this document. However, those registrants defining keywords 331 are advised to place a definition of their solicitation class 332 keywords on a prominent URL under their control such that search 333 engines and other discovery mechanisms can find them. 335 While this draft defines solicitation class keywords as beginning 336 with a reversed domain name followed by a colon (":"), future RFCs 337 may define additional mechanisms that do not conflict with this 338 naming scheme. 340 2.2.1 Note on Choice of Solicitation Class Keywords 342 This document does not specify which solicitation class keywords 343 shall or shall not be used on a particular message. The requirement 344 to use a particular keyword is a policy decision well outside the 345 scope of this document. It is expected that relevant policy bodies 346 (e.g., governments, ISPs, developers, or others) will specify 347 appropriate keywords, the definition of the meaning of those 348 keywords, and any other policy requirements, such as a requirement to 349 use or not use this extension in particular circumstances. 351 During discussions of this proposal, there were several several 352 suggestions to do away with the solicitation class keywords 353 altogether and replace the mechanism with a simple boolean (e.g., 354 "NO-SOLICITING YES" or "ADV" or "UBE"). Under a boolean mechanism, 355 this extension would have to adopt a single definition of what "YES" 356 or other label means. By using the solicitation class keywords 357 approach, the mail infrastructure remains a neutral mechanism, 358 allowing different definitions to co-exist. 360 2.3 The MAIL FROM Command 362 "SOLICIT" is defined as a parameter for the "MAIL FROM" command. The 363 "SOLICIT" parameter is followed by an equal sign and a comma 364 separated list of solicitation class keywords. The syntax for this 365 parameter is: 367 Mail-From-Solicit-Parameter = "SOLICIT" 368 "=" Solicitation-keywords 369 ; Solicitation-keywords, when used in MAIL FROM command 370 ; MUST be identical to those in the Solicitation: header. 372 Note that white space is not permitted in this production. 374 As an informational message, the "550" or "250" replies to the "RCPT 375 TO" command may also contain the "SOLICIT" parameter. If a message is 376 being rejected due to a solicitation class keyword match, 377 implementations SHOULD echo which solicitation classes are in effect. 378 See Section 2.4 for more on error reporting. 380 The receiving system may decide on a per-message basis the 381 appropriate disposition of messages: 383 R: 384 S: 385 R: 220 trusted.example.com SMTP service ready 386 S: EHLO untrusted.example.com 387 R: 250-trusted.example.com says hello 388 R: 250-NO-SOLICITING net.example:ADV 389 S: MAIL FROM: SOLICIT=org.example:ADV:ADLT 390 S: RCPT TO: 391 R: 250 ... Recipient ok 392 S: RCPT TO: 393 R: 550 SOLICIT=org.example:ADV:ADLT 395 In the previous example, the receiving MTA returned a "550" status 396 code, indicating that one message was being rejected. The 397 implementation also echoes back the currently set keywords for that 398 user on the "550" status message. The solicitation class keyword 399 which is echoed back is "org.example:ADV:ADLT" which illustrates how 400 this per-recipient solicitation class keyword has supplemented the 401 base "net.example:ADV" class declared in the "EHLO" exchange. 403 It is the responsibility of a receiving MTA to maintain a consistent 404 policy. If the receiving MTA will reject a message because of 405 solicitation class keywords, the MTA SHOULD declare those keywords 406 either in the initial "EHLO" exchange or on a per-recipient basis. 407 Likewise, a receiving MTA SHOULD NOT deliver a message where the 408 "Solicitation:" matches a solicitation class keyword that was 409 presented during the initial "EHLO" exchange or on a per-recipient 410 basis. 412 Developers should also note that the source of the solicitation class 413 keywords used in the "MAIL FROM" command MUST be the "Solicitation:" 414 header described in Section 2.5 and MUST NOT be supplemented by 415 additional solicitation class keywords derived from the "Received:" 416 header trace fields which are described in Section 2.6. 418 2.4 Error Reporting and Enhanced Mail Status Codes 420 If a session between two MTAs is using both the "NO-SOLICITING" 421 extension and the Enhanced Mail Status Codes as defined in [RFC3463] 422 and a message is rejected based on the presence of a "SOLICIT" 423 parameter, the correct error message to return will usually be 424 "5.7.1", defined as "the sender is not authorized to send to the 425 destination ... [because] of per-host or per-recipient filtering." 427 Other codes, including temporary status codes, may be more 428 appropriate in some circumstances and developers should look to 429 [RFC3463] on this subject. An example of such a situation might be 430 the use of quotas or size restrictions on messages by class. An 431 implementation MAY impose limits such as message size restrictions 432 based on solicitation classes, and when such limits are exceed they 433 SHOULD be reported using whatever status code is appropriate for that 434 limit. 436 In all cases, an implementation SHOULD include a 437 "Mail-From-Solicit-Parameter" on a "550" or other reply that rejects 438 message delivery. The parameter SHOULD includes the solicitation 439 class keyword(s) that matched. In addition to the solicitation class 440 keyword(s) that matched, an implementation MAY include additional 441 solicitation class keywords that are in effect. 443 2.5 Solicitation Mail Header 445 Per [RFC2822], a new "Solicitation:" header field is defined which 446 contains one or more solicitation class keywords. 448 Solicitation-header = "Solicitation:" 1*SP Solicitation-keywords 450 An example of this header follows: 452 To: Coupon Clipper 453 From: Spam King 454 Solicitation: net.example:ADV,org.example:ADV:ADLT 456 Several proposals, particularly legal ones, have suggested requiring 457 the use of keywords in the "Subject:" header. While embedding 458 information in the "Subject:" header may provide visual cues to end 459 users, it does not provide a straightforward set of cues for computer 460 programs such as mail transfer agents. As with embedding a "no 461 solicitation" message in a greeting banner, this overloads the 462 semantics of the "Subject:" header. Of course, there is no reason 463 why both mechanisms can't be used, and in any case the 464 "Solicitation:" header could be automatically inserted by the 465 sender's Mail User Agent (MUA) based on the contents of the subject 466 line. 468 2.6 Insertion of Solicitation Keywords in Trace Fields 470 The "Solicitation:" mail header is only available to the sending 471 client. RFCs 2821 and 2822 are quite specific that intermediate MTAs 472 shall not change message headers, with the sole exception of the 473 "Received:" trace field. Since many current systems use an 474 intermediate relay to detect unsolicited mail, an addition to the 475 "Received:" header is described. 477 [RFC2821] documents the following productions for the "Received:" 478 header in a mail message: 480 ; From RFC 2821 481 With = "WITH" FWS Protocol CFWS 482 Protocol = "ESMTP" / "SMTP" / Attdl-Protocol 484 Additionally, [RFC2822] defines a comment field as follows: 486 ; From RFC 2822 487 comment = "(" *([FWS] ccontent) [FWS] ")" 488 ccontent = ctext / quoted-pair / comment 490 The "Mail-From-Solicit-Parameter" defined in Section 2.3 above is a 491 restricted form of ctext, yielding the following production: 493 With-Solicit = "WITH" FWS Protocol 494 "(" [FWS] comment [FWS] ")" 495 comment = "(" *([FWS] ccontent) [FWS] ")" 496 ccontent = ctext / quoted-pair / 497 comment / Mail-From-Solicit-Parameter 498 ; The Mail-From-Solicit-Parameter 499 ; is a restricted form of ctext 501 An example of a Received: header from a conforming MTA is as follows: 503 Received: by foo-mta.example.com with 504 ESMTP (SOLICIT=net.example:ADV,org.example:ADV:ADLT) ; 505 Sat, 9 Aug 2003 16:54:42 -0700 (PDT) 507 It should be noted that keywords presented in trace fields may not 508 agree with those found in the "Solicitation:" header and trace fields 509 may exist even if the header is not present. When determing which 510 keywords are applicable to a particular exchange of messages, 511 implementors SHOULD examine any keywords found in the "Solicitation:" 512 header. Implementors MAY examine other keywords found in the trace 513 fields. 515 2.7 Relay of Messages 517 The "NO-SOLICITING" service extension, if present, applies to all 518 messages handled by the receiving Message Transfer Agent (MTA), 519 including those messages intended to be relayed to another system. 521 Solicitation class keywords supplied by a client on a "SOLICIT" 522 parameter on a "MAIL FROM" command SHOULD be obtained from the 523 "Solicitation:" field in the message header. An SMTP client SHOULD, 524 however, verify that the list of solicitation class keywords obtained 525 from the "Solicitation:" field uses valid syntax before conveying its 526 contents. An SMTP server SHOULD set this parameter after detecting 527 the presence of the "Solicitation:" header field when receiving a 528 message from a non-conforming MTA. 530 2.8 No Default Solicitation Class 532 Implementations of "NO-SOLICITING" service extension SHOULD NOT 533 enable specific solicitation class keywords as a default in their 534 software. There are some indications that some policy makers may 535 view a default filtering in software as a prior restraint on 536 commercial speech. In other words, because the person installing and 537 using the software did not make an explicit choice to enable a 538 certain type of filtering, some might argue that such filtering was 539 not desired. 541 Likewise, it is recommended that a system administrator installing 542 software SHOULD NOT enable additional per-recipient filtering by 543 default for a user. Again, individual users should specifically 544 request any additional solicitation class keywords. 546 The mechanism for an individual user to communicate their desire to 547 enable certain types of filtering is outside the scope of this 548 document. 550 3. Security Considerations 552 This extension does not provide authentication of senders or other 553 measures intended to promote security measures during the message 554 exchange process. 556 In particular, this document does not address the circumstances under 557 which a sender of electronic mail should or should not use this 558 extension and does not address the issues of whether consent to send 559 mail has been granted. 561 This might lead to a scenario in which a sender of electronic mail 562 begins to use this extension well before the majority of end users 563 have begun to use it. In this scenario, the sender might wish to use 564 the absence of the extension on the receiving MTA as an implication 565 of consent to receive mail. Non-use of the "NO-SOLICITING" extension 566 by a receiving MTA SHALL NOT indicate consent. 568 4. IANA Considerations 570 There are three IANA considerations presented in this draft: 572 1. Addition of the "NO-SOLICITING" service extension to the Mail 573 Parameters registry. 575 2. Documentation of the use of comments in trace fields. 577 3. Creation of a "Solicitation:" mail header. 579 4.1 The Mail Parameters Registry 581 The IANA Mail Parameters registry documents SMTP service extensions. 582 The "NO-SOLICITATION" service extension would need to be added to 583 this registry as follows. 585 Keywords Description Reference 586 ------------ ------------------------------ --------- 587 NO-SOLICITING Notification of no soliciting. RFCXXXX 589 The parameters subregistry would need to be modified as follows: 591 Service Ext EHLO Keyword Parameters Reference 592 ----------- ------------ ----------- --------- 593 No Soliciting NO-SOLICITING Solicitation-keywords RFCXXXX 595 The maximum length of Solicitation-keywords is 1000 characters. The 596 "SOLICIT=" parameter is defined for use on the MAIL FROM command. The 597 potential length of the MAIL FROM command is thus increased by 1007 598 characters. 600 4.2 Trace Fields 602 The Mail Parameters registry would need to be modified to note the 603 use of the comment facility in trace fields to indicate Solicitation 604 Class Keywords. 606 4.3 The Solicitation Mail Header 608 Per [I-D.klyne-msghdr-registry], the "Solicitation:" header field is 609 added to the IANA Permanent Message Header Field Registry. The 610 following is the registration template: 612 o Header field name: Solicitation 614 o Applicable protocol: mail 615 o Status: standard 617 o Author/Change controller: IETF 619 o Specification document(s): RFCXXXX 621 o Related information: 623 5. Author's Acknowledgements 625 The author would like to thank Rebecca Malamud for many discussions 626 and ideas that led to this proposal and to John C. Klensin and 627 Marshall T. Rose for their extensive input on how it could be 628 properly implemented in SMTP. Eric Allman, Harald Alvestrand, Steven 629 M. Bellovin, Doug Barton, Kent Crispin, Dave Crocker, Ned Freed, 630 Curtis Generous, Arnt Gulbrandsen, John Levine, Keith Moore, Hector 631 Santos, Ted Hardie, Paul Vixie, and Pindar Wong kindly provided 632 reviews of the draft and/or suggestions for improvement. Information 633 about soliciting outside the U.S. was received from Rob Blokzijl, Jon 634 Crowcroft, Christian Huitema, Geoff Huston, and Pindar Wong. John 635 Levine pointed out the contrast between this proposal and "do not 636 spam" lists. As always, all errors and omissions are the 637 responsibility of the author. 639 Informative References 641 [Assassin] 642 Mason, J., "Spamassassin - Mail Filter to Identify Spam 643 Using Text Analysis", Version 2.55, May 2003, . 647 [CNET] CNET News.Com, "AOL touts spam-fighting prowess", April 648 2003, . 650 [Cantwell] 651 U.S. Supreme Court, "Cantwell v. State of Connecticut", 652 310 U.S. 296 (1940), May 1940, . 656 [FTC] Federal Trade Commission, "Federal, State, Local Law 657 Enforcers Target Deceptive Spam and Internet Scams", 658 November 2002, . 661 [FTC.TSR] Federal Trade Commission, "Telemarketing Sales Rule", 662 Federal Register Vol. 68, No. 19, January 2003, . 665 [Ferris] Associated Press, "Study: Spam costs businesses $13 666 billion", January 2003, . 669 [Habeas] Habeas, Inc., "Habeas Compliant Message", April 2003, 670 . 672 [I-D.crocker-spam-techconsider] 673 Crocker, D., "Technical Considerations for Spam Control 674 Mechanisms", draft-crocker-spam-techconsider-02 (work in 675 progress), May 2003. 677 [I-D.crouzet-amtp] 678 Crouzet, B., "Authenticated Mail Transfer Protocol", 679 draft-crouzet-amtp-01 (work in progress), October 2003. 681 [I-D.daboo-sieve-spamtest] 682 Daboo, C., "SIEVE Spamtest and Virustest Extensions", 683 draft-daboo-sieve-spamtest-04 (work in progress), October 684 2003. 686 [I-D.danisch-dns-rr-smtp] 687 Danisch, H., "A DNS RR for simple SMTP sender 688 authentication", draft-danisch-dns-rr-smtp-03 (work in 689 progress), October 2003. 691 [Levine] Levine, J. and P. Hoffman, "Anti-UBE and Anti-UCE Keywords 692 in SMTP Banners", Revision 1.1, March 1999, . 695 [Malamud] Malamud, C., "An Internet Prayer Wheel", Mappa.Mundi 696 Magazine, August 1999, . 699 [Martin] U.S. Supreme Court, "Martin v. City of Struthers, Ohio", 700 319 U.S. 141 (1943), May 1943, . 704 [Newbury] The Town of West Newbury, Massachusetts, "Soliciting/ 705 Canvassing By-Law", Chapter 18 Section 10, March 2002, 706 . 709 [Perry] U.S. Supreme Court, "Perry Education Association v. Perry 710 Local Educators' Association", 460 U.S. 37 (1983), 711 February 1983, . 714 [RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", 715 BCP 30, RFC 2505, February 1999. 717 [ROKSO] Spamhaus.Org, "Register of Known Spam Operations", 718 November 2003, . 721 [Schumer] Charles, C., "Schumer, Christian Coalition Team Up to 722 Crack Down on Email Spam Pornography", June 2003, . 726 [Watchtower] 727 U.S. Supreme Court, "Watchtower Bible & Tract Society of 728 New York, Inc., et al. v. Village of Stratton et al.", 122 729 S.Ct. 2080 (2002), June 2002, . 733 Normative References 735 [I-D.klyne-msghdr-registry] 736 Klyne, G., Nottingham, M. and J. Mogul, "Registration 737 procedures for message header fields", 738 draft-klyne-msghdr-registry-07 (work in progress), October 739 2003. 741 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 742 Requirement Levels", BCP 14, RFC 2119, March 1997. 744 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 745 Specifications: ABNF", RFC 2234, November 1997. 747 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 748 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 749 October 1998. 751 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 752 April 2001. 754 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 755 2001. 757 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 758 3463, January 2003. 760 Author's Address 762 Carl Malamud 763 Memory Palace Press 764 PO Box 300 765 Sixes, OR 97476 766 US 768 EMail: carl@media.org 770 Appendix A. Collected ABNF Descriptions (Normative) 772 Solicitation-keywords = word 773 0*("," word) 774 ; length of this string is limited 775 ; to <= 1000 characters 776 word = ALPHA 0*(wordchar) 777 wordchar = ("." / "-" / "_" / ":" / ALPHA / DIGIT) 779 ; used in the initial EHLO exchange 780 No-Soliciting-Service = "NO-SOLICITING" 781 [ SP Solicitation-keywords ] 783 ; used on the Solicitation: message header 784 Solicitation-header = "Solicitation:" 1*SP Solicitation-keywords 786 ; used on the MAIL FROM command and replies, 787 ; and on Received: headers. 788 Mail-From-Solicit-Parameter = 789 "SOLICIT" "=" Solicitation-keywords 790 ; Solicitation-keywords, when used in 791 ; the MAIL FROM command MUST be identical 792 ; to those in the Solicitation: header. 794 ; Used on Received: headers 795 With-Solicit = "WITH" FWS Protocol 796 "(" [FWS] comment [FWS] ")" 797 ; From RFC 2822 798 comment = "(" *([FWS] ccontent) [FWS] ")" 799 ccontent = ctext / quoted-pair / 800 comment / Mail-From-Solicit-Parameter 801 ; The Mail-From-Solicit-Parameter 802 ; is a restricted form of ctext 803 ; From RFC 2821 804 With = "WITH" FWS Protocol CFWS 805 Protocol = "ESMTP" / "SMTP" / Attdl-Protocol 806 Attdl-Protocol = Atom 808 Appendix B. Status of This Document [To Be Removed Upon Publication] 810 B.1 RFC Category 812 This document is being submitted for publication as a Proposed 813 Standard. 815 B.2 Document Repository 817 The source for this document can be found at . 820 Intellectual Property Statement 822 The IETF takes no position regarding the validity or scope of any 823 Intellectual Property Rights or other rights that might be claimed to 824 pertain to the implementation or use of the technology described in 825 this document or the extent to which any license under such rights 826 might or might not be available; nor does it represent that it has 827 made any independent effort to identify any such rights. Information 828 on the IETF's procedures with respect to rights in IETF Documents can 829 be found in BCP 78 and BCP 79. 831 Copies of IPR disclosures made to the IETF Secretariat and any 832 assurances of licenses to be made available, or the result of an 833 attempt made to obtain a general license or permission for the use of 834 such proprietary rights by implementers or users of this 835 specification can be obtained from the IETF on-line IPR repository at 836 http://www.ietf.org/ipr. 838 The IETF invites any interested party to bring to its attention any 839 copyrights, patents or patent applications, or other proprietary 840 rights that may cover technology that may be required to implement 841 this standard. Please address the information to the IETF at 842 ietf-ipr@ietf.org. 844 Disclaimer of Validity 846 This document and the information contained herein are provided on an 847 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 848 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 849 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 850 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 851 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 852 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 854 Copyright Statement 856 Copyright (C) The Internet Society (2004). This document is subject 857 to the rights, licenses and restrictions contained in BCP 78, and 858 except as set forth therein, the authors retain all their rights. 860 Acknowledgment 862 Funding for the RFC Editor function is currently provided by the 863 Internet Society.