idnits 2.17.1 draft-malamud-subject-line-05.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.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 658. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 665. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 671. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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 uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 5, 2005) is 6954 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) == Unused Reference: 'RFC2045' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'KISA' is defined on line 536, but no explicit reference was found in the text == Unused Reference: 'Korea' is defined on line 545, but no explicit reference was found in the text == Unused Reference: 'RFC0886' is defined on line 571, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group C. Malamud 2 Internet-Draft Memory Palace Press 3 Expires: October 7, 2005 April 5, 2005 5 Policy-Mandated Labels Such as "Adv:" in Email Subject Headers 6 Considered Ineffective At Best 7 draft-malamud-subject-line-05 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 7, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This memo discusses policies that require certain labels to be 43 inserted in the "Subject:" header of a mail message. Such policies 44 are difficult to specify accurately while remaining compliant with 45 key RFCs and are likely to be ineffective at best. This memo 46 discusses an alternate, standards-compliant approach that is 47 significantly simpler to specify and is somewhat less likely to be 48 ineffective. 50 Table of Contents 52 1. Labeling Requirements . . . . . . . . . . . . . . . . . . . 3 53 2. Subject Line Encoding . . . . . . . . . . . . . . . . . . . 4 54 3. Implementing a Labeling Requirement . . . . . . . . . . . . 6 55 4. Subjects are For Humans, Not Labels . . . . . . . . . . . . 7 56 5. Solicitation Class Keywords . . . . . . . . . . . . . . . . 9 57 6. Security Considerations . . . . . . . . . . . . . . . . . . 10 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 59 8. Recommendations . . . . . . . . . . . . . . . . . . . . . . 10 60 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 10.1 Normative References . . . . . . . . . . . . . . . . . . 11 63 10.2 Informative References . . . . . . . . . . . . . . . . . 12 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . 13 65 A. Intended Status and Discussion (TO BE REMOVED UPON 66 PUBLICATION) . . . . . . . . . . . . . . . . . . . . . . . . 14 67 B. Changes From Previous Versions (TO BE REMOVED UPON 68 PUBLICATION) . . . . . . . . . . . . . . . . . . . . . . . . 14 69 Intellectual Property and Copyright Statements . . . . . . . 15 71 1. Labeling Requirements 73 The U.S. Congress has signed and the U.S. President has signed the 74 Controlling the Assault of Non-Solicited Pornography and Marketing 75 Act of 2003 (CAN-SPAM Act of 2003) [US], which requires in Section 76 11(2) that the Federal Trade Commission: 78 "[transmit to the Congress] a report, within 18 months after the 79 date of enactment of this Act, that sets forth a plan for 80 requiring commercial electronic mail to be identifiable from its 81 subject line, by means of compliance with Internet Engineering 82 Task Force Standards, the use of the characters "ADV" in the 83 subject line, or other comparable identifier, or an explanation of 84 any concerns the Commission has that cause the Commission to 85 recommend against this plan." 87 The Korean Government has enacted the Act on Promotion of Information 88 and Communication and Communications Network Utilization and 89 Information Protection of 2001 . As explained by the Korea 90 Information Security Agency, the government body with enforcement 91 authority under the act, Korean law makes it mandatory as of June, 92 2003 to: 94 "include the '@' (at) symbol in the title portion (right-side) of 95 any commercial e-mail address, in addition to the words 96 '(Advertisement)' or '(Adult Advertisement)' as applicable. The 97 inclusion of the '@' symbol, as proposed by the Korean government, 98 is intended to indicate an e-mail advertisement. Because e-mails 99 easily cross international borders, the '@' symbol may be used as 100 a symbol for filtering advertisement mails."[KISA] 102 The State of Colorado has enacted the Colorado Junk Email Law, which 103 states: 105 "It shall be a violation of this article for any person that sends 106 an unsolicited commercial electronic mail message to fail to use 107 the exact characters "ADV:" (the capital letters "A", "D", and 108 "V", in that order, followed immediately by a colon) as the first 109 four characters in the subject line of an unsolicited commercial 110 electronic mail message." [Colorado] 112 The Rules of Professional Conduct of the Florida Bar require, in Rule 113 4-7.6(c)(3) states: 115 "A lawyer shall not send, or knowingly permit to be sent, on the 116 lawyer's behalf or on behalf of the lawyer's firm or partner, an 117 associate, or any other lawyer affiliated with the lawyer or the 118 lawyer's firm, an unsolicited electronic mail communication 119 directly or indirectly to a prospective client for the purpose of 120 obtaining professional employment unless ... the subject line of 121 the communication states 'legal advertisement.'" [Florida] 123 A subject line that complies with the above requirements might read 124 as follows: 126 Subject: ADV: @ (Advertisement) legal advertisement 128 A more comprehensive survey of applicable laws would no doubt 129 lengthen the above example considerably. 131 2. Subject Line Encoding 133 The basic definition of the "Subject:" of an electronic mail message 134 is contained in [RFC2822]. The normative requirements that apply to 135 all headers are: 137 o The maximum length of the header field is 998 characters. 138 o Each line must be no longer than 78 characters. 140 A multi-line subject field is indicated by the presence of a carriage 141 return and white space as follows: 143 Subject: This 144 is a test 146 On the subject of the three unstructured fields ( "Subject:", 147 "Comments:", and "Keywords:"), the standard indicates that these are 148 "intended to have only human-readable content with information about 149 the message." In addition, on the specific subject of the "Subject:" 150 field, the standard states: 152 The "Subject:" field is the most common and contains a short 153 string identifying the topic of the message. When used in a 154 reply, the field body MAY start with the string "Re: " (from the 155 Latin "res", in the matter of) followed by the contents of the 156 "Subject:" field body of the original message. If this is done, 157 only one instance of the literal string "Re: " ought to be used 158 since use of other strings or more than one instance can lead to 159 undesirable consequences. 161 Further guidance on the structure of the "Subject:" field is 162 contained in [RFC2047], which species the mechanisms for character 163 set encoding in mail headers. [RFC2978] specifies a mechanism for 164 registering different character sets with the [IANA]. 166 In addition to choosing a character set, [RFC2047] uses two 167 algorithms, known as "Base64 Encoding" and "Quoted Printable", which 168 are two different methods for encoding characters that fall outside 169 of the basic 7-bit ASCII requirements that are specified in the core 170 electronic mail standards. 172 An encoded piece of text thus consists of the following components: 174 o The string "=?", which signifies the beginning of encoded text. 175 o A valid character set indicator. 176 o The string "?", which is a delimiter. 177 o The string "b" if "Base64 Encoding" is used or the string "q" if 178 "Quoted Printable" encoding is used. 179 o The string "?", which is a delimiter. 180 o The text, which has been properly encoded. 181 o The string "?=", which signifies the ending of the encoded text. 183 A simple example would be to use the popular [8859-1] character set, 184 which has accents and other characters not found in the ASCII 185 character set: 187 o "Subject: This is an ADV:" is an unencoded header. 188 o "Subject: =?iso-8859-1?b?VGhpcyBpcyBhbiBBRFY6?=" is encoded using 189 Base64. 190 o "Subject: =?iso-8859-1?q?This=20is=20an=20ADV:?=" is encoded using 191 Quoted Printable. 192 o "Subject: =?iso-8859-1?q?This=20is=20an=20=41=44=56=3A?=" is also 193 encoded using Quoted Printable, but instead the last four 194 characters are encoded with their hexadecimal representations. 196 Note that both character set and encoding indicators are case 197 insensitive. Additional complexity can be introduced by appending a 198 language specification to the character set indication, as specified 199 in [RFC2231] and [RFC3066]. This language specification consists of 200 the string "*" followed by a valid language indicator. For example, 201 "US-ASCII*EN" indicates the "US-ASCII" character set and the English 202 language. 204 When a message is read, the "Subject:" field is decoded, with 205 appropriate characters from the character set displayed to the user. 206 Section 7 (Conformance) of [RFC2047] specifies that a conforming mail 207 reading program must perform the following tasks: 209 "The program must be able to display the unencoded text if the 210 character set is "US-ASCII". For the ISO-8859-* character sets, 211 the mail reading program must at least be able to display the 212 characters which are also in the ASCII set." 214 However, there is no requirement for every system to have every 215 character set, and mail readers that are unable to display a 216 particular set of characters resort to a variety of strategies, 217 including silently ignoring the unknown text, or generating an error 218 or warning message. 220 Two characteristics of many common Message User Agents (MUAs) (e.g., 221 mail readers) are worth noting: 223 o Although the subject line is in theory of unlimited length, many 224 mail readers only show the reader only the first few dozen 225 characters. 226 o Electronic mail is often transmitted through gateways, reaching 227 pagers or cell phones with SMS capability. Those systems 228 typically require short subject lines. 230 3. Implementing a Labeling Requirement 232 In this section, we posit a hypothetical situation with two key 233 players: 235 o John Doe[Doe] is an attorney at the firm of Dewey, Cheatem & Howe, 236 LLC.[Stooges] 237 o The Federal Trust Commission (FTC) has been entrusted with 238 implementing a recent labeling requirement promulgated by the 239 Sovereign Government of Freedonia.[Duck] Specifically, President 240 Firefly directed the FTC to "make sure that anybody spamming folks 241 get the symbol 'spam:' in the subject line and or shoot them, if 242 you can find them." 244 Based on this directive, the FTC promulgated a very simple regulation 245 which read: "Please obey the law." John Doe, being a lawyer, read the 246 law, and promptly proceeded to spam everybody using a fairly obvious 247 loophole: he made sure his subject line was really long, and he 248 shoved all the stuff like "spam:" and the "@" symbol and other 249 verbiage near the end of the 998 allowed characters. He was 250 complying with the law, but of course, nobody saw the labels in their 251 reader. 253 Based on a periodic review, the FTC decided to be more specific, and 254 re-promulgated their regulation as follows: "If you send spam, put 255 'spam:' at the _beginning_ of the subject line." The Freedonian FTC 256 promptly received a visit from the Sylvanian Ambassador, who 257 complained that this conflicted with his country's requirements under 258 the Marx Doctrine to place the string "WATCH OUT! THE CONTENTS OF 259 THIS MESSAGE ARE SUSPECT!" at the beginning of the subject line. 261 The re-promulgation of the regulation was rescinded, some more 262 experts were called in, and a new regulation was issued: "Put it as 263 close to the beginning of the subject line as you can, modulo any 264 requirements by other governments." John Doe looked at this, 265 scratched his head, and applied a clever little hack, picking the ISO 266 [8859-8] character set for Hebrew, and duly spelling out the letters 267 ":" Mem Alef Pe Samech. 269 Subject: =?iso-8859-8?q?=f1=f4=e0=ee=3a?= 271 Some receivers of this message get an error message because they 272 don't have Hebrew installed on their systems. Others get some 273 cryptic indicator of a missing character set, such as 274 "[?iso-8859-8?]". 276 The FTC called a summit of leading thinkers, and the regulation was 277 amended to read "but don't use languages that go from right to left 278 or up and down instead of plain old left to right." Needless to say, 279 the reaction from the Freedonian League for the Defense of Linguistic 280 Diversity killed that proposed regulation really quickly. 282 The commission continued the cycle of re-promulgation and refinement, 283 but ultimately, the regulations always contained either a loophole, 284 some objectionable requirements, or were simply violations of the 285 relevant RFCs. 287 4. Subjects are For Humans, Not Labels 289 The use of an unknown character set, or of a very, very long subject 290 line are just two examples of how people can try to get around 291 labeling requirements. In order to specify a regulation without 292 ambiguity, it would need to be extremely complex to avoid loopholes 293 such as these. 295 Drafting of regulations is one issue, but there is another. Subject 296 lines are used to specify, as [RFC2822] says, a "short string 297 identifying the topic of the message." 299 Any regulation has to compete with the other words in the subject, 300 and this mixing of purposes makes it very difficult for a machine to 301 filter out messages at the direction of the user. For example, if 302 one looks for the "@" symbol, per the Korean law, checks have to be 303 made that this symbol is not a legitimate part of a legitimate 304 message. 306 Not only do multiple labeling requirements compete with legitimate 307 subject lines, there is no easy way for the sender of a legitimate 308 message to effectively insert _other_ labels that indicate to the 309 recipient that, although the message may have a required label, it is 310 actually a message the user might want to see based on, for example, 311 a prior relationship. 313 Even if one considers just the sender of the message, it is very 314 difficult to specify a loophole-free way of putting a specific label 315 in a specific place. And, even if we could control what the sender 316 does, it is an unfortunate fact of life that other agents may also 317 alter the subject line. For example, mailing list management 318 software and even personal email filtering systems will often "munge" 319 the subject line to add information such as the name of a mailing 320 list, or the fact that a message comes from a certain group of 321 people. Such transformations have long been generally accepted as 322 being potentially harmful,[RFC0886] and are the subject of continued 323 discussion which are outside the scope of the present document (see 324 [Koch] and [RFC3834]). 326 The "Subject:" field is currently overloaded: it has become a handy 327 place for a variety of agents to attempt to insert information. 328 Because of that overloading, it is a poor location for specifying 329 mandatory use of a label, since it is unlikely that label will "rise 330 to the top" and become apparent to the reader of a message or even to 331 the mail filtering software that examines the mail before the user. 332 The difficulty of implementing subject line labeling without taking 333 additional steps has been noted by several other commentators, 334 including [Moore-1], [Lessig], and [Levine]. Indeed, the problem is 335 a general one. Keith Moore has pointed out seven good reasons why 336 tags of any sort in the "Subject:" field have potential problems: 337 1. The "Subject:" field space is not strictly limited and long 338 fields can be folded. 339 2. PDAs, phones, and other devices and software have only a limited 340 space to display the "Subject:" field. 341 3. A variety of different kinds of labels such as "ADV:" and 342 "[Mailing List Name]" compete for scarce display space. 343 4. There are conflicting legal requirements from different 344 jurisdictions. 345 5. There is a conflict between human use of the "Subject:" field and 346 use of that field such as filtering and filing: 347 * Machine-readable tokens interfere with human readability. 348 * Representation of human-readable text was not designed with 349 machine interpretation in mind and thus does not have a 350 canonical form. 351 6. Lack of support in a few existing mail readers for displaying 352 information from elsewhere in the message header (e.g., from 353 newly-defined fields), along with familiarity, motivates 354 additional uses of the "Subject:", further compounding the 355 problem. 356 7. Any text-based tags added or imposed by outside parties (i.e., 357 those that are not the sender or recipient of the message) will 358 not be reliably meaningful in the recipient's language. 360 Source: [Moore-2]. 362 5. Solicitation Class Keywords 364 [RFC3865] defines the "solicitation class keyword", an arbitrary 365 label which can be associated with an electronic mail message and 366 transported by the ESMTP mail service as defined in [RFC2821] and 367 related documents. Solicitation class keywords are formatted like 368 domain names, but reversed. For example, the registrant of 369 "example.com" might specify a particular solicitation class keyword 370 such as "com.example.adv" that could be inserted in a "No-Solicit:" 371 header or in a trace field. Anybody with a domain name can specify a 372 solicitation class keyword, and anybody sending a message can use any 373 solicitation class keyword that has been defined by themselves or by 374 others. 376 This memo argues that the "No-Solicit:" approach is either a superior 377 alternative or a necessary complement to "Subject:" field labeling 378 requirements because: 380 o One can specify very precisely what a label should be and where it 381 should go using the "No-Solicit:" header, which is designed 382 specifically for this purpose. 383 o The sender of a message can add additional solicitation class 384 keywords to help distinguish the message. For example, if the 385 "Freedonian Direct Marketing Council" wished to form a voluntary 386 consortium of direct marketers who subscribe to certain practices, 387 they could specify a keyword (e.g., 388 "org.example.freedonia.good.spam") and educate the public to set 389 their filters to receive these types of messages. 390 o Message Transfer Agents (MTAs) may insert solicitation class 391 keywords in the "received:" trace fields, thus providing 392 additional tools for recipients to use for filtering messages. 393 o A recipient can also define a solicitation class keyword, a tool 394 that allows them to give friends and correspondents a "pass key" 395 so the recipient's mail filtering software always passes through 396 messages containing that keyword. 398 As can be seen, the solicitation class keyword approach is flexible 399 enough to serve as a tool for government-mandated labeling and for 400 other purposes as well. 402 Most modern email software gives users a variety of filtering tools. 403 For example, the popular Eudora program allows a user to specify the 404 name of a message header, the desired match (e.g., a wild card or 405 regular expression, or simply a phrase to match), and an action to 406 take (e.g., moving the message to a particular folder, sounding an 407 alarm, or even deleting messages with harmful content such as viruses 408 automatically). There is one popular email reader which only allows 409 filtering on selected fields, such as "To:", "From:", or "Subject:", 410 but that program is the exception to the rule. 412 In summary, for senders and receivers of email, use of the 413 "No-Solicit:" mechanism would be simple to understand and use. For 414 policy makers, it would be extremely simple to specify the format and 415 placement of the solicitation class keyword. (Needless to say, the 416 issue of how to define what classes of messages are subject to such a 417 requirement and how to enforce it are beyond the scope of this 418 discussion.) 420 6. Security Considerations 422 The use of labels in the "Subject:" field gives users and policy 423 makers an unwarranted illusion that certain classes of messages will 424 be "flagged" correctly by the MUA of the recipient. The difficulty 425 in specifying requirements for labels in the "Subject:" field in a 426 precise, unambiguous manner makes it difficult for the MUA to 427 systematically identify messages that are labeled, leading to both 428 false positive and false negative indications. 430 In addition, conflicting labeling requirements by policy makers, as 431 well as other current practices that use the "Subject:" for a variety 432 of purposes make that field "overloaded." In order to meet these 433 conflicting requirements, software designers and bulk mail senders 434 resort to a variety of tactics, some of which may violate fundamental 435 requirements of the mail standards, such as the practice of an 436 intermediate MTA inserting various labels into the "Subject:" field. 437 Such practices increase the likelihood of non-compliant mail messages 438 and thus threaten interoperability between implementations. 440 7. IANA Considerations 442 There are no IANA Considerations in this document. 444 8. Recommendations 446 This document makes three recommendations: 448 1. There is widespread skepticism in the technical community that 449 labels of any sort will be effective and such labels should 450 probably be avoided as ineffective at best. 451 2. Despite the widespread skepticism expressed in point 1, over 36 452 states in the U.S. and 27 countries have passed anti-spam 453 measures, many of which require labels.[Sorkin] If such labels 454 are to be used, despite the widespread skepticism expressed in 455 point 1, there is a fairly broad consensus in the technical 456 community that such labels should not be put in the "Subject:" 457 field and should go in a designated header field. 458 3. If, despite points 1 and 2, a policy is adopted of mandating 459 labels in the "Subject:" field is adopted, a complementary 460 requirement to use the "No-Solicit:" should also be added. 462 9. Acknowledgements 464 The author would like to thank the following for their helpful 465 suggestions and reviews of this draft: Joe Abley, Harald Alvestrand, 466 Elwyn Davies, Alain Durand, Frank Ellermann, Ted Hardie, Tony Hansen, 467 Scott Hollenbeck, Peter Koch, Bruce Lilly, Keith Moore, Pekka Savola 468 and Mark Townsley. 470 10. References 472 10.1 Normative References 474 [IANA] IANA, "Registry of Official Names for Character Sets That 475 May Be Used on the Internet", February 2004, 476 . 478 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 479 Extensions (MIME) Part One: Format of Internet Message 480 Bodies", RFC 2045, November 1996. 482 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 483 Part Three: Message Header Extensions for Non-ASCII Text", 484 RFC 2047, November 1996. 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, March 1997. 489 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 490 Word Extensions: Character Sets, Languages, and 491 Continuations", RFC 2231, November 1997. 493 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 494 April 2001. 496 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 497 2001. 499 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration 500 Procedures", BCP 19, RFC 2978, October 2000. 502 [RFC3066] Alvestrand, H., "Tags for the Identification of 503 Languages", BCP 47, RFC 3066, January 2001. 505 [RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer 506 Protocol (SMTP) Service Extension", RFC 3865, September 507 2004. 509 10.2 Informative References 511 [8859-1] International Organization for Standardization, 512 "Information technology - 8-bit single byte coded graphic 513 - character sets - Part 1: Latin alphabet No. 1, 514 JTC1/SC2", ISO Standard 8859-1, 1987. 516 [8859-8] International Organization for Standardization, 517 "Information Processing - 8-bit Single-Byte Coded Graphic 518 Character Sets, Part 8: Latin/Hebrew alphabet", 519 ISO Standard 8859-8, 1988. 521 [Colorado] 522 Sixty-Second General Assembly of the State of Colorado, 523 "Colorado Junk Email Law", House Bill 1309, June 2000, 524 . 526 [Doe] Frank Capra (Director), "Meet John Doe", IMDB Movie 527 No. 0033891, 1941, . 529 [Duck] The Mark Brothers, "Duck Soup", IMDB Movie No. 0023969, 530 1933, . 532 [Florida] The Florida Bar, "Rules of Professional Conduct", 2005, 533 . 536 [KISA] Korea Information Security Agency, "Korea Spam Response 537 Center -- Legislation for Anti-Spam Regulations: Mandatory 538 Indication of Advertisement", 2003, 539 . 541 [Koch] Koch, P., "Subject: [tags] Considered Harmful", 542 Internet-Draft draft-koch-subject-tags-considered-00, 543 November 2004. 545 [Korea] National Assembly of the Republic of Korea, "Act on 546 Promotion of Information and Communication and 547 Communications Network Utilization and Information 548 Protection of 2001", 2001, 549 . 551 [Lessig] Lessig, L., "How to unspam the Internet", The 552 Philadelphia Inquirer, May 2003, 553 . 556 [Levine] Levine, J., "Comments In the Matter of: REPORT TO CONGRESS 557 PURSUANT TO CAN-SPAM ACT", Federal Trade Commission, 558 Matter No. PO44405, February 2004, 559 . 562 [Moore-1] Moore, K., "Individual Comment of Mr. Keith Moore Re: 563 Label for E-mail Messages", Federal Trade Commission of 564 the U.S., NPRM Comment RIN 3084-AA96, February 2004, 565 . 568 [Moore-2] Moore, K., "E-mail Message to the Author and the IESG", 569 March 2005. 571 [RFC0886] Rose, M., "Proposed standard for message header munging", 572 RFC 886, December 1983. 574 [RFC3834] Moore, K., "Recommendations for Automatic Responses to 575 Electronic Mail", RFC 3834, August 2004. 577 [Sorkin] Sorkin, D., "http://www.spamlaws.com/", 2005, 578 . 580 [Stooges] The Three Stooges, "Heavenly Daze", IMDB Movie 581 No. 0040429, 1948, . 583 [US] United States Congress, "The Controlling the Assault of 584 Non-Solicited Pornography and Marketing Act of 2003 585 (CAN-SPAM Act of 2003)", Public Law 108-187, 117 586 STAT. 2699, 15 USC 7701, December 2003, 587 . 590 Author's Address 592 Carl Malamud 593 Memory Palace Press 594 PO Box 300 595 Sixes, OR 97476 596 US 598 Email: carl@media.org 600 Appendix A. Intended Status and Discussion (TO BE REMOVED UPON 601 PUBLICATION) 603 This draft is being submitted as an individual submission with an 604 intended publication as a an Informational RFC. Discussion of this 605 draft should take place on the mailing 606 list ( to subscribe). The source 607 and alternative transformations for this draft may be found at 608 . 610 Appendix B. Changes From Previous Versions (TO BE REMOVED UPON 611 PUBLICATION) 613 The following changes were made from draft-malamud-subject-line-03 to 614 draft-malamud-subject-line-04: 616 o Terminology section removed. 617 o Changed "SHOULD" to "should". 618 o Changed "France" to "Sylvania". 619 o Changed "Freedonian Jewish Defense League" to "Freedonian League 620 for the Defense of Linguistic Diversity". 622 The following changes were made from draft-malamud-subject-line-02 to 623 draft-malamud-subject-line-03: 625 o Grammatical fixes to French examples. 626 o Change in title to indicate that the specific topic of this draft 627 is policy-mandated labeling. 628 o Addition of a third recommendation that recognizes that inertia 629 may lead to continued used of the "Subject:" field. 630 o Addition of a list of reasons why this is a bad idea furnished by 631 Keith Moore. 633 The following changes were made from draft-malamud-subject-line-01 to 634 draft-malamud-subject-line-02: 636 o Security considerations were added. 637 o Clarification of intended publication status. 639 The following changes were made from draft-malamud-subject-line-00 to 640 draft-malamud-subject-line-01: 642 o Added a concluding section containing 2 recommendations. 643 o Discussion of language identifiers per [RFC2231] added. 644 o Mention of limitations on conforming mail reader actions per 645 [RFC2047], Section 7 added. 646 o Discussion of prior work on mailing list identifiers per [Koch] 647 added. 649 Intellectual Property Statement 651 The IETF takes no position regarding the validity or scope of any 652 Intellectual Property Rights or other rights that might be claimed to 653 pertain to the implementation or use of the technology described in 654 this document or the extent to which any license under such rights 655 might or might not be available; nor does it represent that it has 656 made any independent effort to identify any such rights. Information 657 on the procedures with respect to rights in RFC documents can be 658 found in BCP 78 and BCP 79. 660 Copies of IPR disclosures made to the IETF Secretariat and any 661 assurances of licenses to be made available, or the result of an 662 attempt made to obtain a general license or permission for the use of 663 such proprietary rights by implementers or users of this 664 specification can be obtained from the IETF on-line IPR repository at 665 http://www.ietf.org/ipr. 667 The IETF invites any interested party to bring to its attention any 668 copyrights, patents or patent applications, or other proprietary 669 rights that may cover technology that may be required to implement 670 this standard. Please address the information to the IETF at 671 ietf-ipr@ietf.org. 673 Disclaimer of Validity 675 This document and the information contained herein are provided on an 676 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 677 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 678 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 679 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 680 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 681 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 683 Copyright Statement 685 Copyright (C) The Internet Society (2005). This document is subject 686 to the rights, licenses and restrictions contained in BCP 78, and 687 except as set forth therein, the authors retain all their rights. 689 Acknowledgment 691 Funding for the RFC Editor function is currently provided by the 692 Internet Society.