Network Working Group C. Malamud Internet-Draft Memory Palace Press Expires: September 22, 2004 March 24, 2004 Addressing FTC DIARRUCA Concerns draft-malamud-diarruca-concerns-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3667. 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 September 22, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The U.S. Congress, having hit a home run with the do-not-call list, has decided that since computers are like telephones, a do-not-email list ought to win them the pennant. You have an opportunity to block that metaphor. The FTC has issued an Advanced Notice of Proposed Rulemaking and has given the public until March 31, 2004 to respond. This document tells you how and explains the issues. Terminology The key words "Good Thing(TM)", "Bad Thing(TM)", "Feature(c)", and "Bug(c)" in this document are to be interpreted as described in [FOLDOC]. Malamud Expires September 22, 2004 [Page 1] draft-malamud-diarruca-concerns FTC DIARRUCA March 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. How to Submit Comments . . . . . . . . . . . . . . . . . . . . 4 3. No-Soliciting in a Nutshell . . . . . . . . . . . . . . . . . 6 4. Background on the Centralized Do-Not-Email Registry . . . . . 8 5. Background on Labels . . . . . . . . . . . . . . . . . . . . . 12 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 A. FOIA Request for Responses to Do-Not-Email Contractor Solicitations . . . . . . . . . . . . . . . . . . . . . . . . 17 B. Document Repository . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 20 Malamud Expires September 22, 2004 [Page 2] draft-malamud-diarruca-concerns FTC DIARRUCA March 2004 1. Introduction The U.S. Federal Trade Commission (FTC) has issued an Advanced Notice of Proposed Rulemaking (ANPR), which is a formal agency action of notice and comment prior to rulemaking pursuant to the U.S. Administrative Procedures Act [USC] and is in response to the passage of the CAN-SPAM Act of 2003 [CAN-SPAM] The ANPR is entitled "Definitions, Implementation, and Reporting Requirements Under the CAN-SPAM Act." [DIARRUCA] The request for public comment lists a variety of issues pertaining to implementation and reporting requirements of the CAN-SPAM Act of 2003. This document only addresses a subset of the issues raised, including: o Section 9(a) and sec. 9(b) of the CAN-SPAM Act of 2003 mandates that the Commission submit a report "setting forth a plan and timetable for establishing a nationwide marketing Do Not E-mail Registry." In response, the Commission has already issue a pre-procurement call for contractors to build this Do Not E-mail Database and operate that system on behalf of the Commission.[FTC-RFI] The Commission has solicited comments from the public on "practical, technical, security, privacy, enforceability and other concerns" with respect to establishment of such a registry. o Section 6(I) of the DIARRUCA requests comments from the public on the use of an "ADV" label in the subject line of non-adult commercial messages and further inquires whether senders could add additional information such as "ADV:Automobiles." o Additionally sec. 6(H)(3) and sec. (4) of the DIARRUCA request commentary on the issues of "analysis and recommendations concerning how to address commercial email that originates in or is transmitted through or to facilities or computers in other nations." and "options for protecting consumers, including children from the receipt and viewing of commercial email that is obscene or pornographic." Malamud Expires September 22, 2004 [Page 3] draft-malamud-diarruca-concerns FTC DIARRUCA March 2004 2. How to Submit Comments Congress thinks the Do-Not-Mail list is great. Senator Schumer calls the list the last hope for consumers. The Chairman of the FTC has said this is your basic Bad Idea.(TM) [CBS] To submit your comment electronically, go here: You then have to scroll down to get to CAN-SPAM, then click on "Submit a Comment." That leads you to a snazzy form to fill out. You can skip the survey if you want and enter your comments directly in the text area, or you can attach a document. Note: The author apologizes for not furnishing a direct link to the relevant proceeding. That is actually a Feature(c) not a Bug(c) at , the "e-gov" (sic) operation that the FTC outsources these functions to. There is no permanent URL for a given comment action and the search forms only support "method=POST". The reason for this appears to be because regulations.gov is further outsourcing the comment sub-function to facilities located on the other shore at CommentWorks(TM).com. Perhaps "regulations.gov" is taking the "customer" analogy a bit too far, attempting to force consumers through the front door so they view all the pretty merchandise available. After all, somebody hurrying in to comment on some mundane trade regulation, might well succumb to an "impulse buy" and take the time to comment on a forthcoming environmental ruling. In your comments, make sure to identify who you are and why your comments are relevant. For example: o *Tell them who you are:* "I am the author of several Internet RFC's including [RFC1149], 'A Standard for the Transmission of IP Datagrams on Avian Carriers' which defines the fundamental characteristics used for electronic mail when transported over an infrastructure composed of avian carriers." o *Tell them about any Bad Things(TM):* "I believe a centralized do-not-email registry poses a significant security and privacy threat to consumers. I do not believe that mechanisms such as SHA-1-based one-way hash will provide adequate security for a centralized database and the non-standard use of labels in messages violates some key assumptions about the mail architecture as detailed in [RFC2821] and [RFC2822]." Malamud Expires September 22, 2004 [Page 4] draft-malamud-diarruca-concerns FTC DIARRUCA March 2004 o *Tell them about any Good Things(TM):* "I believe a decentralized approach, such as that outlined in the IETF No-Soliciting Proposed Standard will provide greater benefit to consumers and provides a much better solution for the international environment in which electronic mail, particularly spam, functions." Needless to say, use the language you feel is appropriate to express the views you hold. Just remember, you are speaking to a non-technical audience which is under a full-court press from some very eager contractors and is very anxious to be shown to be "doing something" about the problem. Malamud Expires September 22, 2004 [Page 5] draft-malamud-diarruca-concerns FTC DIARRUCA March 2004 3. No-Soliciting in a Nutshell The No Soliciting SMTP Service Extension[No-Solicit], a Proposed Standard, is being advanced by the author as an alternative to centralized, non-standardized approaches such as the do-not-email list and the use of labels on the subject line of a message. The extension does the following: o Anybody can define a solicitation class keywords and attach meaning to them. Solicitation class keywords begin with your domain name in reverse order, followed by a colon, followed by arbitrary text. For example: "org.media:ADV:ADLT". Solicitation class keywords can be up to 1000 characters long although, as with many things in life, brevity is better. o A "Solicitation:" header is defined, which is available to the sender of a message to insert a solicitation class keyword. o The "received:" header may be used by an Message Transfer Agent (MTA) to insert solicitation class keywords while the message is in transit. o The "MAIL FROM" command in SMTP and responses may include solicitation class keywords. o As a message recipient, you can filter on solicitation class keywords at either your message reader or your MTA, taking actions you feel are appropriate. If the FTC wished to used this extension: o They would define their solicitation class keywords. For example: "gov.ftc:SEXUALLY-EXPLICIT-CONTENT". o The FTC could still require a label on the subject line if they feel that is necessary as a visual clue or for political reasons. But, with this extension they have choices and could instead/also require that information to be present in the body of the message as part of the "Brown Bag" requirement adopted by the Congress. o The FTC might require any sender of a particular class of mail to use a "Solicitation:" header with the appropriate solicitation class keyword inserted. o The FTC might also require high-volume senders of a particular class of mail to use the SMTP service extension. o The FTC could concentrate on enforcement of violations instead of Malamud Expires September 22, 2004 [Page 6] draft-malamud-diarruca-concerns FTC DIARRUCA March 2004 having to manage yet another large MIS project. Malamud Expires September 22, 2004 [Page 7] draft-malamud-diarruca-concerns FTC DIARRUCA March 2004 4. Background on the Centralized Do-Not-Email Registry Metaphors can be as powerful as a herd of cattle upwind in late spring, but inappropriate metaphors can tempt lawmakers into using policies as mismatched to the problems they are trying to solve as a NASA Metro Map.[Tufte] In response to a public perception of widespread abuses by the telemarketing industry, the U.S. Congress passed legislation requiring the FTC and FCC to coordinate the establishment of a do-not-call list.[NOCALL-LAW] The FTC and FCC both issued regulations [NOCALL-FTC][NOCALL-FCC] and those regulations were upheld by the U.S. Court of Appeals.[NOCALL-CASE] The do-not-call program proved to be immensely popular, drawing a record number of registrants. Consumer surveys indicate that the program has been highly effective, reducing the number of unwanted calls dramatically. For example, a poll by Harris Interactive showed that "more than half of all adults (57%) say they have signed up and most of these people say they have either received no telemarketing calls since then (25%) or far less than before (53%).[HARRIS] The analogy between one highly successful program, the Do-Not-Call list, and the pressing public concern over spam was just too easy to make. If it works for telephone, why not for spam? The analogy is flawed. The technologies are different. A simple illustration of the difference is the economics of what happens if the list gets out into the wild and some violator wishes to reach the people on the list. Assume a do-no-call list of 50 million numbers and an equivalent do-not-email list of electronic mail addresses: o To reach the 50 million telephone consumers, a substantial investment in telemarketing equipment, personnel, and time is needed. Even if the average amount of time to reach a consumer and attempt to conduct a transaction is just one minute, the do-not-call list would require 833,333 hours of personnel time and telecommunications charges. At $5/hour for people that's $4,166,166 for labor. At $0.05/minute for telecommunications, that's $2,500,000 in telephone charges. And, these are only the variable costs. o In sharp contrast, reaching 50 million consumers by electronic mail can be done in minutes, requires no capital investment, and there are numerous service providers who will send mail at a cost of approximately $50 per million messages. The variable costs for reaching everybody on the do-not-spam list is $2500, less than 1/ 5000th of the cost for the do-not-call list. Malamud Expires September 22, 2004 [Page 8] draft-malamud-diarruca-concerns FTC DIARRUCA March 2004 The economics is simple: this is a large financial disincentive to violate the do-not-call list. The returns would have to be very large to justify the risk. Spamming the do-not-spam list, on the other hand, has a low entry cost, requires a neglible return, and has low risk. A do-not-email list would be impossible to secure. The list must be consulted by all legitimate marketeers. And, as we've seen with DVDs distributed to members of the Academy of Motion Picture Arts and Sciences, distribution of secrets to a large population, no matter how august that population, is an inherently insecure activity. The FTC, as part of the rule-making process, has issued a "Request for Information" (RFI) [FTC-RFI] in which contractors no doubt expended significant energy responding how they would protect the security of such a database. Unfortunately, requests for copies of those proposals by prospective contractors have not been released for public scrutiny due to "concerns about proprietary information," so it is not possible to point out the security flaws in any specific proposal (but see Appendix A). In the RFI, the FTC expressed interest in a variety of proposals. The core do-not-email database was specified as having a capacity of 300 million electronic mail messages, and vendors had to price out solutions of up to 450 million entries. Three of the variants solicited by the FTC are noteworthy: o A list that only has domain names and not individual electronic mail addresses. Such a list might work well for sophisticated users with their own domains, but would disenfranchise those users who use large Internet Service Providers such as Time Warner's AOL or Microsoft's MSN. o A list that includes the addresses of telemarketers, flipping the onus to register from those who do not want email to those who sent the unwanted email. While this idea may seem clever, just imagine the burden this places on millions of individual mail users who would have to download the list frequently, and install mail filters to match each of the addresses. o One idea that has caught the imagination of some members of the press is the proposal by UNSPAM(R), LLC (), which bills itself as the "the no-spam registry experts" who are "paving the way towards a spam-free future." Their approach uses a one-way hash based on SHA-1. Their schtick is that means you can't read the list, but can only use it to verify an email address. There is a fundamental problem here. Finding email addresses is easy: you can uses Google, build your own scraper, Malamud Expires September 22, 2004 [Page 9] draft-malamud-diarruca-concerns FTC DIARRUCA March 2004 buy a list, or do a dictionary attack. The key to the global "spamonomy"--a term coined by noted author Danny Goodman in his forthcoming book analyzing spam, how it works, and how you can try to stop it[Goodman]--is verifying that an email address is real and active. Wouldn't it be handy to have a single source you could use to scrub your lists to find out which addresses are valid? This is a really Bad Idea(TM). We should note in passing that the RFI also includes provisions for charging consumers for the privilege of being included on the list. A do-not-email list is not practical to secure, nor is it practical to run. It is a highly centralized solution requiring intense government supervision and large contracts to the private sector to operate the computers. Most importantly, the centralized database does not take into account our international world. Most spam, even that originating from U.S. citizens, goes through facilities in many countries. It is hard to imagine the European Union and the U.S. agreeing how to merge separate do-not-email databases to provide a unified solution, let alone agree on what privacy standards should be are posed by such a large collection of individual information aggregated in one place. In contrast, it is very possible to imagine both entities imposing labeling requirements that can coexist in a common header, much as food that crosses national boundary has labeling requirements imposed by multiple jurisdictions. Why should a private citizen have to register with the federal government in order to be left alone? A large centralized database is a security threat, a privacy threat, and will do little to solve the problem. In contrast, a decentralized solution stands a chance of being adopted by different jurisdictions and is flexible enough to handle the wide variety of people who use electronic mail. Finally, John Klensin has pointed out that even if the list was successful for the classes of mail it attempts to regulate, such a large volume of mail falls outside of those classes that any unilateral centralized solution is bound to fail: "It might perhaps also be worth pointing out that, unlike the pre-'do-not-call' telemarketing situation, there is a high volume of nuisance spam today, traffic that has no obvious commercial purpose, since it does not contain any solicitation in any characters or language that the recipient can read. Whether that traffic is deliberate or accidental remains a matter of debate, but it almost all originates from offshore servers and would Malamud Expires September 22, 2004 [Page 10] draft-malamud-diarruca-concerns FTC DIARRUCA March 2004 almost certainly be insensitive to 'do-not-email' lists." Malamud Expires September 22, 2004 [Page 11] draft-malamud-diarruca-concerns FTC DIARRUCA March 2004 5. Background on Labels Section 5(d) of the CAN-SPAM Act [CAN-SPAM] directs the FTC, within 120 days of the promulgation of the act, to "prescribe ... clearly identifiable marks or notices to be included in or association with commercial e-mail that contains sexually explicit material." In a notice of rulemaking on this subject,[FTC-PORN] the mechanism proposed for such identification would be the insertion of the phrase "SEXUALLY-EXPLICIT-CONTENT:" as "the first 27 letters in the subject line." In addition, in the DIARRUCA ANPR, the FTC solicited public comment on the use of "ADV", "ADV:ADLT" or similar marks in subject lines, which is the practice adopted by over a dozen state laws previous to the passage of the Can-Spam Act of 2003. Placing marks on the subject line is a visual clue for a human being, but unfortunately the process is highly error-prone for computers. Even with a human being, the process is ambiguous: o For a computer, embedding a label in the subject line makes it extremely difficulty to reliably filter out unwanted mail. Even with a long label such as SEXUALLY-EXPLICIT-CONTENT, there will be collisions. The problem is that the subject line is overloaded: it has to do several different things including the primary task which is conveying the subject of the message in the sender's own words. o For a consumer, the label is ambiguous. A long label can be confused with real content. And, the definition of short labels are extremely overloaded. For example, over a dozen states passed laws requiring "ADV" in the subject line. Which definition of "ADV" should we think applies to this message? And, what happens when, for example, Korea requires that the Han-gul equivalent be inserted at the beginning of a subject line? o The purpose of a subject line is for a human being to enter words that convey the subject of the message. Using this for machine-based filtering is silly. A separate header makes much more sense. An added bonus of using a special "Solicitation:" header is that the same format for solicitation class keywords can be used on on the "received:" headers which are inserted by the Message Transfer Agent. So, if spammers ignore the law about putting in solicitation headers, perhaps your MTA can help compensate by inserting the missing information in a trace field. Of course, it is up to you and your mail reader to decide if you trust that MTA's trace field and what Malamud Expires September 22, 2004 [Page 12] draft-malamud-diarruca-concerns FTC DIARRUCA March 2004 actions to take. Littering our mail headers with ad-hoc solutions destroys the integrity of the mail system. A more systematic solution will be both more flexible and more effective. Malamud Expires September 22, 2004 [Page 13] draft-malamud-diarruca-concerns FTC DIARRUCA March 2004 References [CAN-SPAM] 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, . [CBS] CBS News, "FTC: Canning Spam A Tough Chore", March 2004, . [DIARRUCA] US Federal Trade Commission, "Definitions, Implementation, and Reporting Requirements Under the CAN-SPAM Act", Advance Notice of Proposed Rulemaking, Project No. R4110008, RIN 3084-AA96, Billing Code 6750-01-P, March 2004, . [FOIA] United States Congress, "The Freedom of Information Act As Amended By the Electronic Freedom of Information Act Amendments of 1996", Public Law 104-231, 110 STAT. 3048, 5 USC 552, October 1996, . [FOLDOC] Howe, D., Ed., "Free On-Line Dictionary of Computing", October 2003, . [FTC-PORN] US Federal Communications Commission, "Notice of Proposed Rulemaking: Label for E-mail Messages Containing Sexually Oriented Material", RIN 3084-AA96, 16 CFR Part 316, January 2004, . [FTC-RFI] US Federal Trade Commission, "Request for Information: Federal Trade Commission's Plan for Establishing a National Do Not E-mail Registry", February 2004, . [Goodman] Goodman, D., "Be Efraid, Be Very Efraid", SelectBooks (forthcoming), ISBN 1-59079-063-4, 2004. Malamud Expires September 22, 2004 [Page 14] draft-malamud-diarruca-concerns FTC DIARRUCA March 2004 [HARRIS] The Harris Poll, "Do Not Call Registry Is Working Well", ISSN 0895-7983, February 2004, . [NOCALL-CASE] U.S. Court of Appeals, Tenth Circuit, "Mainstream Marketing v. Federal Trade Commission", No. 03-1429, February 2004, . [NOCALL-FCC] US Federal Communications Commission, "Rules and Regulations Implementing the Telephone Consumer Protection Act of 1991", FCC 03-153, June 2003, . [NOCALL-FTC] US Federal Trade Commission, "Telemarketing Sales Rule", 16 CFR 310, January 2003, . [NOCALL-LAW] United States Congress, "The Do-Not-Call Implementation Act", Public Law 108-10, 117 STAT. 557, March 2003. [No-Solicit] Malamud, C., "A No Soliciting SMTP Service Extension", draft-malamud-no-solicit-07 (work in progress), March 2004, . [RFC1149] Waitzman, D., "Standard for the transmission of IP datagrams on avian carriers", RFC 1149, April 1990. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [Tufte] Tufte, E., "Block That Metaphor! The NASA Space Exploration Map", June 2003, . [USC] United States Congress, "US Administrative Procedures Act, Section 553: Rule Making", 15 U.S.C. 553, 1946, . Malamud Expires September 22, 2004 [Page 15] draft-malamud-diarruca-concerns FTC DIARRUCA March 2004 [2] [3] [4] Author's Address Carl Malamud Memory Palace Press PO Box 300 Sixes, OR 97476 US EMail: carl@media.org Malamud Expires September 22, 2004 [Page 16] draft-malamud-diarruca-concerns FTC DIARRUCA March 2004 Appendix A. FOIA Request for Responses to Do-Not-Email Contractor Solicitations This FOIA request was submitted at [Wed Mar 17 14:10:25 PST 2004] to [2]. March 21, 2004 Freedom of Information Act Request Office of General Counsel Federal Trade Commission 600 Pennsylvania Avenue, N.W. Washington, D.C. 20580 Dear Sir/Madam: This is a request under the Freedom of Information Act. I request that a copy of the following document(s) be provided to me: Copies of documents submitted in response to the February 23, 2004 Request For Information: Federal Trade Commission's Plan for Establishing a National Do Not E-mail Registry. The responses were sent to the attention of Mr. Daniel Salsburg, Federal Trade Commission, Division of Marketing Practices, 600 Pennsylvania Avenue N.W., Washington, D.C. 20580. In order to help determine fees, you should know that I am an individual. I am willing to pay fees up to $200. If you expect the fees will exceed this, please contact me before proceeding. I request a waiver of all fees for this request. Disclosure of the requested information to me is in the public interest because it is likely to contribute significantly to public understanding of the operations or activities of the government and is not primarily in my commercial interest. Specifically, a national do-not-email registry is a matter of national policy and any proposed contractor-based implementations of such a registry raise numerous issues that the public should be able to examine, particularly in order to be able to submit comments requested by the FTC as part of the Advance Notice of Proposed Rulemaking, Project No. R411008, Definitions, Implementation, and Reporting Requirements Under the CAN-SPAM Act. If you need to discuss this request, I can be reached at at [3]. Thank you for your consideration of my request. Sincerely, Malamud Expires September 22, 2004 [Page 17] draft-malamud-diarruca-concerns FTC DIARRUCA March 2004 Carl Malamud PO Box 300 Sixes, Oregon 97476 Malamud Expires September 22, 2004 [Page 18] draft-malamud-diarruca-concerns FTC DIARRUCA March 2004 Appendix B. Document Repository The source for this document may be found at the following URL: [4] Malamud Expires September 22, 2004 [Page 19] draft-malamud-diarruca-concerns FTC DIARRUCA March 2004 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 IETF's procedures with respect to rights in IETF 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 (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Malamud Expires September 22, 2004 [Page 20]