Network Working Group C. Malamud Internet-Draft Memory Palace Press Expires: August 2, 2005 January 29, 2005 Labels in Subject Headers Considered Ineffective At Best draft-malamud-subject-line-00.txt Status of this Memo 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 become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 2, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This Internet-Draft discusses policies that require certain labels to be inserted in the "Subject:" header of a mail message. Such policies are difficult to specify accurately while remaining compliant with key RFCs and are likely to be ineffective at best. This Internet-Draft discusses an alternate, standards-compliant approach that is significantly simpler to specify and is somewhat less likely to be ineffective. Malamud Expires August 2, 2005 [Page 1] draft-malamud-subject-line Subject Line Labeling January 2005 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119]. Table of Contents 1. Labeling Requirements . . . . . . . . . . . . . . . . . . . . 3 2. Subject Line Encoding . . . . . . . . . . . . . . . . . . . . 4 3. Implementing a Labeling Requirement . . . . . . . . . . . . . 5 4. Subjects are For Humans, Not Labels . . . . . . . . . . . . . 7 5. Solicitation Class Keywords . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Author's Acknowledgements . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1 Informative References . . . . . . . . . . . . . . . . . . 9 9.2 Normative References . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 A. Intended Status and Discussion (TO BE REMOVED UPON PUBLICATION) . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 12 Malamud Expires August 2, 2005 [Page 2] draft-malamud-subject-line Subject Line Labeling January 2005 1. Labeling Requirements The U.S. Congress has signed and the U.S. President has signed the Controlling the Assault of Non-Solicited Pornography and Marketing Act of 2003 (CAN-SPAM Act of 2003) [US], which requires in Section 11(2) that the Federal Trade Commission: "[transmit to the Congress] a report, within 18 months after the date of enactment of this Act, that sets forth a plan for requiring commercial electronic mail to be identifiable from its subject line, by means of compliance with Internet Engineering Task Force Standards, the use of the characters "ADV" in the subject line, or other comparable identifier, or an explanation of any concerns the Commission has that cause the Commission to recommend against this plan." The Korean Government has enacted the Act on Promotion of Information and Communication and Communications Network Utilization and Information Protection of 2001 . As explained by the Korea Information Security Agency, the government body with enforcement authority under the act, Korean law makes it mandatory as of June, 2003 to: "include the '@' (at) symbol in the title portion (right-side) of any commercial e-mail address, in addition to the words '(Advertisement)' or '(Adult Advertisement)' as applicable. The inclusion of the '@' symbol, as proposed by the Korean government, is intended to indicate an e-mail advertisement. Because e-mails easily cross international borders, the '@' symbol may be used as a symbol for filtering advertisement mails."[KISA] The State of Colorado has enacted the Colorado Junk Email Law, which states: "It shall be a violation of this article for any person that sends an unsolicited commercial electronic mail message to fail to use the exact characters "ADV:" (the capital letters "A", "D", and "V", in that order, followed immediately by a colon) as the first four characters in the subject line of an unsolicited commercial electronic mail message." [Colorado] The Rules of Professional Conduct of the Florida Bar require, in Rule 4-7.6(c)(3) states: "A lawyer shall not send, or knowingly permit to be sent, on the lawyer's behalf or on behalf of the lawyer's firm or partner, an associate, or any other lawyer affiliated with the lawyer or the lawyer's firm, an unsolicited electronic mail communication directly or indirectly to a prospective client for the purpose of obtaining professional employment unless ... the subject line of the communication states 'legal advertisement.'" [Florida] Malamud Expires August 2, 2005 [Page 3] draft-malamud-subject-line Subject Line Labeling January 2005 A subject line that complies with the above requirements might read as follows: Subject: ADV: @ (Advertisement) legal advertisement A more comprehensive survey of applicable laws would no doubt lengthen the above example considerably. 2. Subject Line Encoding The basic definition of the "Subject:" of an electronic mail message is contained in [RFC2822]. The the normative requirements that apply to all headers are: o The maximum length of the header field is 998 characters. o Each line must be no longer than 78 characters. A multi-line subject field is indicated by the presence of a carriage return and white space as follows: Subject: This is a test On the subject of the three unstructured fields ( "Subject:", "Comments:", and "Keywords:"), the standard indicates that these are "intended to have only human-readable content with information about the message." In addition, on the specific subject of the "Subject:" field, the standard states: The "Subject:" field is the most common and contains a short string identifying the topic of the message. When used in a reply, the field body MAY start with the string "Re: " (from the Latin "res", in the matter of) followed by the contents of the "Subject:" field body of the original message. If this is done, only one instance of the literal string "Re: " ought to be used since use of other strings or more than one instance can lead to undesirable consequences. Further guidance on the structure of the "Subject:" field is contained in [RFC2047], which species the mechanisms for character set encoding in mail headers. [RFC2978] specifies a mechanism for registering different character sets with the IANA.[IANA] In addition to choosing a character set, [RFC2047] uses two algorithms, known as "Base64 Encoding" and "Quoted Printable", which are two different methods for encoding characters that fall outside of the basic 7-bit ASCII requirements that are specified in the core electronic mail standards. An encoded piece of text thus consists of the following components: Malamud Expires August 2, 2005 [Page 4] draft-malamud-subject-line Subject Line Labeling January 2005 o The string "=?", which signifies the beginning of encoded text. o A valid character set indicator. o The string "?", which is a delimiter. o The string "b" if "Base64 Encoding" is used or the string "q" if "Quoted Printable" encoding is used. o The string "?", which is a delimiter. o The text, which has been properly encoded. o The string "?=", which signifies the ending of the encoded text. A simple example would be to use the popular [8859-1] character set, which has accents and other characters not found in the ASCII character set: o "Subject: This is an ADV:" is an unencoded header. o "Subject: =?iso-8859-1?b?VGhpcyBpcyBhbiBBRFY6?=" is encoded using Base64. o "Subject: =?iso-8859-1?q?This=20is=20an=20ADV:?=" is encoded using Quoted Printable. o "Subject: =?iso-8859-1?q?This=20is=20an=20=41=44=56=3A?=" is also encoded using Quoted Printable, but instead the last four characters are encoded with their hexadecimal representations. When a message is read, the "Subject:" field is decoded, with appropriate characters from the character set displayed to the user. However, there is no requirement for every system to have every character set, and mail readers that are unable to display a particular set of characters resort to a variety of strategies, including silently ignoring the unknown text, or generating an error or warning message. Two characteristics of many common Message User Agents (MUAs) (e.g., mail readers) are worth noting: o Although the subject line is in theory of unlimited lengths, many mail readers only show the reader only the first few dozen characters. o Electronic mail is often transmitted through gateways, reaching pagers or cell phones with SMS capability. Those systems typically require short subject lines. 3. Implementing a Labeling Requirement In this section, we posit a hypothetical situation with two key players: o John Doe[Doe] is an attorney at the firm of Dewey, Cheatem & Howe, LLC.[Stooges] o The Federal Trust Commission (FTC) has been entrusted with implementing a recent labeling requirement promulgated by the Sovereign Government of Freedonia.[Duck] Specifically, the Amalgamated Parliament of Freedonia has directed the FTC to "make Malamud Expires August 2, 2005 [Page 5] draft-malamud-subject-line Subject Line Labeling January 2005 sure that anybody spamming folks get the symbol 'SPAM:' really visible in the subject line and that they obey any other laws or shoot them (if you can find them)." Based on this directive, the FTC promulgated a very simple regulation which read: "Please obey the law." John Doe, being a lawyer, read the law, and promptly proceeded to spam everybody using a fairly obvious loophole: he made sure his subject line was really long, and he shoved all the stuff like "SPAM:" and the "@" symbol and other verbiage near the end of the 998 allowed characters. He was complying with the law, but of course, nobody saw the labels in their reader. Based on a monthly review, the FTC decided to be more specific, and re-promulgated their regulation as follows: "If you send SPAM, put 'SPAM:' at the beginning of the subject line." The Freedonian FTC promptly received a visit from the U.S. Ambassador to Freedonia, who complained that he had received an urgent wire from his State Department, who said the Freedonian law conflicted with the American law and this transgression would be taken into account the next time trade sanctions were considered. The re-promulgation of the regulation was rescinded, some experts were called in, and a new regulation was issued: "Put it as close to the beginning of the subject line as you can, modulo any requirements by other governments." John Doe looked at this, scratched his head a bit, and decided to use a clever little hack: he picked the ISO [8859-8] character set for Hebrew, duly spelling out the letters ":" Mem Alef Pe Samech. Subject: =?iso-8859-8?q?=f1=f4=e0=ee=3a?= Some receivers of this message get an error message because they don't have Hebrew installed on their systems. Others get some cryptic indicator of a missing character set, such as "[?iso-8859-8?]". The FTC called a summit of leading thinkers, and the regulation was amended to read "but don't use funny languages like Hebrew and stuff." Needless to say, the reaction from the Freedonian Jewish Defense League killed that proposed regulation really quickly. The commission continued the cycle of re-promulgation and refinement, but ultimately, the regulations always contained either a loophole, some objectionable requirements, or were simply violations of the relevant RFCs. Malamud Expires August 2, 2005 [Page 6] draft-malamud-subject-line Subject Line Labeling January 2005 4. Subjects are For Humans, Not Labels The use of an unknown character set, or of a very, very long subject line are just two examples of how people can try to get around labeling requirements. In order to specify a regulation without ambiguity, it would need to be extremely complex to avoid loopholes such as these. Drafting of regulations is one issue, but there is another. Subject lines are used by humans to specify, as [RFC2822] says, a "short string identifying the topic of the message." Any regulation thus has to compete with the other words in the subject, and this mixing of purposes makes it very difficult for a machine to filter out messages at the direction of the user. For example, if one looks for the "@" symbol, per the Korean law, checks have to be made that this symbol is not a legitimate part of a legitimate message. Not only do multiple labeling requirements compete with legitimate subject lines, there is no easy way for the sender of a legitimate message to effectively insert _other_ labels that indicate to the recipient that, although the message may have a required label, it is actually a message the user might want to see based on, for example, a prior relationship. The difficulty of implementing subject line labeling as a solution without taking additional steps has been noted by several other commentators, including [Moore], [Lessig], and [Levine]. Even if one considers just the sender of the message, it is very difficult to specify a loophole-free way of putting a specific label in a specific place. And, even if we could control what the sender does, it is an unfortunate fact of life that other agents may also alter the subject line. For example, mailing list management software and even personal email filtering systems will often "munge" the subject line to add information such as the name of a mailing list, or the fact that a message comes from a certain group of people. Such transformations have long been generally accepted as being potentially harmful,[RFC0886] but the practice exists nevertheless. The "Subject:" field is currently overloaded: it has become a handy place for a variety of agents to attempt to insert information. Because of that overloading, it is a poor location for specifying mandatory use of a label, since it is unlikely that label will "rise to the top" and become apparent to the reader of a message or even to the mail filtering software that examines the mail before the user. Malamud Expires August 2, 2005 [Page 7] draft-malamud-subject-line Subject Line Labeling January 2005 5. Solicitation Class Keywords [RFC3865] defines the concept of a "solicitation class keyword", which is an arbitrary string or label which can be associated with an electronic mail message and transported by the ESMTP mail service as defined in [RFC2821] and related documents. Solicitation class keywords are formatted like domain names, but reversed. For example, the registrant of "example.com" might specify a particular solicitation class keyword such as "com.example.adv" that could be inserted in a "No-Solicit:" header or in a trace field. Anybody with a domain name can specify a solicitation class keyword, and anybody sending a message can use any solicitation class keyword that has been defined, by themselves or by other people. This Internet-Draft argues that the "No-Solicit:" approach is either a superior alternative or a necessary complement to "Subject:" labeling requirements because: o Authorities can specify very precisely what a label should be and where it should go using the "No-Solicit:" header, which is designed specifically for this purpose. o The sender of a message can add additional solicitation class keywords to help distinguish the message. For example, if the "Good Spammers of America Association" wished to form a voluntary consortium of direct marketers who subscribe to certain practices, they could specify a keyword (e.g., org.example.good.spam) and educate the public to set their filters to receive these types of messages. o The SMTP Service Extension specified in [RFC3865] allows Message Transfer Agents (MTAs) to employ solicitation class keywords in the "received:" trace fields, thus providing additional tools for recipients to use for filtering messages. o A recipient can also define a solicitation class keyword, a tool that allows them to give friends and correspondents a "pass key" so the recipient's mail filtering software always passes through messages containing that keyword. As can be seen, the solicitation class keyword approach allows for both positive and negative labeling, and is flexible enough that it can serve as a tool for not only governments-mandated labeling, but for other purposes as well. Most modern email software gives users a variety of filtering tools. For example, the popular Eudora program allows a user to specify the name of a message header, the desired match (e.g., a wild card or regular expression, or simply a phrase to match), and an action to take (e.g., moving the message to a particular folder, or sounding an alarm, or even deleting messages with harmful content such as viruses automatically). There is one popular email reader which only allows Malamud Expires August 2, 2005 [Page 8] draft-malamud-subject-line Subject Line Labeling January 2005 filtering on selected fields, such as "To:", "From:", or "Subject:", but that program is the exception to the rule. In summary, for senders and receivers of email, use of the "No-Solicit:" mechanism would be simply to understand and use. For policy makers, it would be extremely simply to specify the format and placement of the solicitation class keyword. (Needless to say, the issue of how to define what classes of messages are subject to such a requirement and how to enforce it are beyond the scope of this discussion.) 6. IANA Considerations There are no IANA Considerations in this document. 7. Security Considerations There are no security considerations in this document. 8. Author's Acknowledgements The author would like to thank the following for their helpful suggestions and reviews of this draft: Harald Alvestrand. 9. References 9.1 Informative References [8859-1] International Organization for Standardization, "Information technology - 8-bit single byte coded graphic - character sets - Part 1: Latin alphabet No. 1, JTC1/SC2", ISO Standard 8859-1, 1987. [8859-8] International Organization for Standardization, "Information Processing - 8-bit Single-Byte Coded Graphic Character Sets, Part 8: Latin/Hebrew alphabet", ISO Standard 8859-8, 1988. [Colorado] Sixty-Second General Assembly of the State of Colorado, "Colorado Junk Email Law", House Bill 1309, June 2000, . [Doe] Frank Capra (Director), "Meet John Doe", IMDB Movie No. 0033891, 1941, . [Duck] The Mark Brothers, "Duck Soup", IMDB Movie No. 0023969, 1933, . Malamud Expires August 2, 2005 [Page 9] draft-malamud-subject-line Subject Line Labeling January 2005 [Florida] The Florida Bar, "Rules of Professional Conduct", 2005, . [KISA] Korea Information Security Agency, "Korea Spam Response Center -- Legislation for Anti-Spam Regulations: Mandatory Indication of Advertisement", 2003, . [Korea] National Assembly of the Republic of Korea, "Act on Promotion of Information and Communication and Communications Network Utilization and Information Protection of 2001", 2001, . [Lessig] Lessig, L., "How to unspam the Internet", The Philadelphia Inquirer, May 2003, . [Levine] Levine, J., "Comments In the Matter of: REPORT TO CONGRESS PURSUANT TO CAN-SPAM ACT", Federal Trade Commission, Matter No. PO44405, February 2004, . [Moore] Moore, K., "Individual Comment of Dr. Keith Moore Re: Label for E-mail Messages", Federal Trade Commission of the U.S., NPRM Comment RIN 3084-AA96, February 2004, . [RFC0886] Rose, M., "Proposed standard for message header munging", RFC 886, December 1983. [Stooges] The Three Stooges, "Heavenly Daze", IMDB Movie No. 0040429, 1948, . [US] United States Congress, "The Controlling the Assault of Non-Solicited Pornography and Marketing Act of 2003 (CAN-SPAM Act of 2003)", Public Law 108-187, 117 STAT. 2699, 15 USC 7701, December 2003, . 9.2 Normative References [IANA] IANA, "Registry of Official Names for Character Sets That Malamud Expires August 2, 2005 [Page 10] draft-malamud-subject-line Subject Line Labeling January 2005 May Be Used on the Internet", February 2004, . [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000. [RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension", RFC 3865, September 2004. Author's Address Carl Malamud Memory Palace Press PO Box 300 Sixes, OR 97476 US Email: carl@media.org Appendix A. Intended Status and Discussion (TO BE REMOVED UPON PUBLICATION) This draft is being submitted to the RFC Editor as an individual submission with an intended publication as a Best Current Practice (BCP) or an Informational RFC. Discussion of this draft should take place on the mailing list ( to subscribe). The source and alternative transformations for this draft may be found at . Malamud Expires August 2, 2005 [Page 11] draft-malamud-subject-line Subject Line Labeling January 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Malamud Expires August 2, 2005 [Page 12]