Anti Spam Research Group R. Brand Internet-Draft Procinct Security Corporation Expires: October 9, 2003 E. Williams Information Brokers, Inc. April 9, 2003 Anti Spam Research Group Requirements draft-irtf-asrg-requirements-xx Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 April 22, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract The purpose of the Anti Spam Research Group (ASRG) is to investigate the spam problem (loosely defined as ‘non consent- based communications’) as a large-scale network problem, understand the problem and collectively propose and evaluate solutions to the problem. This Internet-Draft describes the high-level requirements for proposed methodologies for addressing the problem, including the rationale for those requirements where clarification is needed. Scenarios are used to illustrate some requirements. Internet-Draft Requirements April 9, 2003 Table of Contents 1. Introduction 4 1.1 Conventions Used In This Document 4 1.2 Reasons for the ASRG Proposal Requirements 4 1.3 Terminology 5 1.3.1 Anti-spam 5 1.3.2 Bulk E-mail 5 1.3.3 Caller 5 1.3.4 Callback 5 1.3.5 Challenge/Response System 5 1.3.6 Consent 5 1.3.7 Consent Based Communications 5 1.3.8 Commercial E-mail 5 1.3.9 Domain Name System (DNS) 5 1.3.10 E-mail 5 1.3.11 False Negative 5 1.3.12 False Positive 5 1.3.13 Legitimate Messaging 5 1.3.14 Message Content 6 1.3.15 Message Envelope Forgery 6 1.3.16 Message Envelope Protocol 6 1.3.17 Message Header 6 1.3.18 Message Header Forgery 6 1.3.19 Message Origination 6 1.3.20 Message Originator 6 1.3.21 Message Transfer Agent 6 1.3.22 Message Transfer System 6 1.3.23 Message User Agent 6 1.3.24 Message Store/Message Storage Agent 6 1.3.25 Non Consent Based Communication (spam) 6 1.3.26 Open Relay MTA 6 1.3.27 Opt-In 6 1.3.28 Opt-Out 6 1.3.29 Recipient 6 1.3.30 Receiver 6 1.3.31 Sender 6 1.3.32 Spammer 6 1.3.33 Relay MTA 6 1.3.34 Reverse DNS 6 1.3.35 Transport Protocol 6 1.3.36 Unsolicited Bulk E-Mail 6 1.3.37 Unsolicited Commercial E-Mail 6 1.4 Anti Spam Technical Framework 6 1.5 Organization of Requirements 6 2. Requirements 7 2.1 Use of existing RFCs 7 2.1.1 Rationale: 7 2.2 Inexpensive 7 2.2.1 Rational: 7 2.3 Unencumbered 8 Brand & Williams Expires: October 9, 2003 [Page 2] Internet-Draft Requirements April 9, 2003 2.3.1 Rationale: 8 2.4 Ease of Use 8 2.4.1 Rationale: 8 2.5 Ease of Deployment 8 2.5.1 Rational: 8 2.6 Interoperable 8 2.6.1 Rational: 8 2.7 Highly Effective 9 2.7.1 Rationale: 9 2.8 Persistently Effective 9 2.8.1 Rational: 9 2.9 Doesn't Interfere With The Delivery Of Legitimate Mail 9 2.9.1 Rationale: 9 2.10 Single Solution 10 2.10.1 Rationale: 10 2.11 Technical Rather Than Legislative 10 2.11.1 Rationale: 10 2.12 Complexity 10 2.12.1 Rationale: 10 2.13 Implement ability 11 2.13.1 Rationale: 11 2.14 Other Platforms 11 2.14.1 Rationale: 11 2.15 Accountability and Anonymity 11 2.15.1 Rationale: 11 3. Security Considerations 12 Informative References 12 Authors' Addresses 12 Full Copyright Statement 13 Acknowledgements 13 Brand & Williams Expires: October 9, 2003 [Page 3] Internet-Draft Requirements April 9, 2003 1. Introduction This is an unordered simple listing of possible criteria for ASRG to evaluate anti-spam solutions. I am actively soliciting both additional criteria and also argumentation/analysis as to which criteria are appropriate and important and which are not. 1.1 Conventions Used In This Document This is not an IETF standards track document[1]. As it is not such a document the keywords MUST, MUST NOT, SHOULD, and MAY are NOT as in [2], but rather: o MUST: This word, or the terms "REQUIRED" or "SHALL", means that the described behavior or characteristic is an absolute requirement for a proposed ASRG specification. o MUST NOT: This phrase, or the phrase "SHALL NOT", means that the described behavior or characteristic is an absolute prohibition of a proposed ASRG specification. o SHOULD: This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in particular circumstances for a proposed ASRG specification to ignore described behavior or characteristics. o MAY: This word, or the adjective "OPTIONAL", means that described behavior or characteristics are truly optional for a proposed ASRG specification. One proposed specification may choose to include the described behavior or characteristic while another proposed specification may omit the same behavior or characteristic. 1.2 Reasons for the ASRG Proposal Requirements The reasons for development this set of requirements for ASRG proposals are derived from the ASRG charter. The charter states: “The purpose of the ASRG is to understand the problem and collectively propose and evaluate solutions to the problem. While some techniques focus on local text classification approaches, many traditional and evolving techniques include approaches that involve new network architectures or changes to the existing applications and protocols. ASRG will investigate the spam problem as a large-scale network problem. The ASRG will begin its work by developing a taxonomy of the problem and the proposed solutions. This taxonomy should involve casting the spam problem into different perspectives, such as examining the similarities between spam and denial-of- Brand & Williams Expires: October 9, 2003 [Page 4] Internet-Draft Requirements April 9, 2003 service; spam and intrusion detection/prevention; and spam and authentication, authorization, and accounting. ASRG will consider the issues of deployment for proposed solutions, emphasizing the investigation of methods that have a realistic chance of wide-scale deployment. The work of the ASRG will also include investigating techniques to evaluate the usefulness and cost of proposed solutions. Usefulness is described by the effectiveness, accuracy, and incentive structure of the system. The cost of the system refers to the burden imposed on users and operators of the communications system. These costs include any changes to the normal use of the system or actual changes in the monetary costs of using the system. The group will investigate evaluation infrastructures such as public trace data archives and research tools to measure and analyze the problem and the solutions. ASRG will not pursue research into legal issues of spam, other than the extent to which these issues affect, support, or constrain the technology.” This scope provides the basis framework for the development and evaluation of proposals. This document provides the core requirements applied by the research group for evaluation of ASRG proposals. 1.3 Terminology In an effort to develop a common reference point for the evaluation of proposals and solutions we have compiled the following list of commonly used terms relating to anti-spam technology and efforts. The terms are presented in the sections that follow in alphabetical order. In addition some specific applications/examples of techniques described are presented in Appendix #. 1.3.1 Anti-spam 1.3.2 Bulk E-mail 1.3.3 Caller 1.3.4 Callback 1.3.5 Challenge/Response System 1.3.6 Consent 1.3.7 Consent Based Communications 1.3.8 Commercial E-mail 1.3.9 Domain Name System (DNS) 1.3.10 E-mail 1.3.11 False Negative 1.3.12 False Positive 1.3.13 Legitimate Messaging Brand & Williams Expires: October 9, 2003 [Page 5] Internet-Draft Requirements April 9, 2003 1.3.14 Message Content 1.3.15 Message Envelope Forgery 1.3.16 Message Envelope Protocol 1.3.17 Message Header 1.3.18 Message Header Forgery 1.3.19 Message Origination 1.3.20 Message Originator 1.3.21 Message Transfer Agent A Message Transfer Agent (MTA) is a system within the Message Transfer System that participates in message transport on the behalf of Message User Agents, or other MTA. 1.3.22 Message Transfer System The definition of the Message Transfer System (MTS) is described by the following and associates elements in the MTS as follows: Message Transfer System +-----------------------------------+ | | | MUA <-> MTA/MS <-> MTA/MS <-> MUA | | | +-----------------------------------+ 1.3.23 Message User Agent 1.3.24 Message Store/Message Storage Agent 1.3.25 Non Consent Based Communication (spam) 1.3.26 Open Relay MTA 1.3.27 Opt-In 1.3.28 Opt-Out 1.3.29 Recipient 1.3.30 Receiver 1.3.31 Sender 1.3.32 Spammer 1.3.33 Relay MTA 1.3.34 Reverse DNS 1.3.35 Transport Protocol 1.3.36 Unsolicited Bulk E-Mail 1.3.37 Unsolicited Commercial E-Mail 1.4 Anti Spam Technical Framework This document assumes the technical framework for anti-spam proposals using the terminology defined in Section 1.3, we assume the MTS is the primary means for transferring messages among senders and recipients. The MTS consists of at least two MTAs, MUAs and MTA/MS systems. The MTS relies on the DNS to locate network information about relevant systems. The MTS uses various transport, envelope and message technologies that are well known to [spammers] and MTS applications. Brand & Williams Expires: October 9, 2003 [Page 6] Internet-Draft Requirements April 9, 2003 These are the only assumptions we make concerning approaches to proposals that will be evaluated. Using that logic the following should not matter… o Whether MTA, MUA, the MTS or some MTS component, e.g. MS; is the platform for the proposed solution. o Whether the proposed solution is the specification of protocol extensions or an entirely new protocol. o Whether the proposed solution uses existing technologies or leverages existing technology. 1.5 Organization of Requirements [My experience with developing requirements documents for IETF consumption indicates to me a format change may help us better foster the research and engineering processes for a solution. In this regard I would characterize each of these subsections of 2.0 as a separate high level requirement. Each of those high level requirements will reflect the subordinate requirements.] The requirements outlined in this document reflect the high level aspects for operational deployment of a solution. For each requirement we will state the requirement as clearly as possible without attempting to dictate a specific idea. Then the rationale for stating the requirement and its importance will be given along with its relative usefulness to a proposal or specification. Optionally, we will provide an operational scenario describing how such a feature may be used in the environment being considered. Scenario’s are only illustrative of actions a feature might enable. It is expected that proposals with at a minimum meet the requirements laid out in this document. However, this document should be used generally as a single criteria among others used to evaluate a proposal. The ASRG may use additional metrics for evaluation of proposals of competing designs. 2. Requirements 2.1 Use of existing RFCs ASRG proposals SHALL reference and use previously published RFCs where possible. 2.1.1 Rationale: The IETF has already completed a great deal of research and work into the areas of authentication, identification, authorization, messaging and messaging communications and other related protocols. In order to facilitate the work of this group and its search for a solution it is wise to consider defined and accepted standards. Brand & Williams Expires: October 9, 2003 [Page 7] Internet-Draft Requirements April 9, 2003 2.2 Inexpensive The proposal MUST consider the computational and storage expense for users and technologies within the MTS utilizing the proposed approach. 2.2.1 Rational: Any additional overhead imposed on systems in the operating environment may influence the level of deployment of the proposed approach. To enhance deployment opportunities it is smart to consider the impact of the approach on computational and human resources. 2.3 Unencumbered Any work that is presented for consideration MUST NOT be encumbered by rights, licensing or patents that limit the free deployment of a proposed solution. 2.3.1 Rationale: Work presented to the ASRG [standard IETF/IRTF rights/patent language here]. 2.4 Ease of Use The approach SHALL consider the ease of use for message system managers, senders and recipients in all messaging situations. 2.4.1 Rationale: For successful adoption by the user community proposals must provide support for typical and atypical messaging situations involving two or more parties. Many different correspondent scenarios exist in the MTS a proposal which limits the ease of messaging in existing scenarios will limit adoption. 2.5 Ease of Deployment The proposal SHOULD consider deployment on any basis and take into account existing systems deployed and operating in the MTS. 2.5.1 Rational: Any solution to the problems with ‘spam’ should be easily deployed to facilitate either incremental or wide-spread adoption. Existing systems will likely continue to be used, thus a solution that leverages existing technology or MTS ‘anti- spam’ implementations will also speed introduction. A proposal that relies on non-existent infrastructure or technology is not likely to be deployed. Brand & Williams Expires: October 9, 2003 [Page 8] Internet-Draft Requirements April 9, 2003 2.6 Interoperable Proposals MUST be interoperable with existing MTS uses. 2.6.1 Rational: In order to be widely deployed and functional in the existing environment the proposal must consider interoperation with legacy protocols and systems. The existing MTS environment consists of web based messaging client, offline MUAs, MUAs that support direct delivery to MTA/MS and MTA relays. Additionally, the platforms that manage messaging applications are also heterogenous, designers must consider the practicality of operation using multiple operating systems and technologies. Proposals must not be specific to a single operating system or system platform. 2.7 Highly Effective The proposal MUST provide an effective solution as determined by the [TBD] algorithm. That blocks all appropriate messaging. 2.7.1 Rationale: Although proposals may differ in approach all proposals will be evaluated using an appropriate application of the [TBD] algorithm or one of its derivatives. The [TBD] algorithm provides a standard and objective measure for evaluation of the approach. 2.8 Persistently Effective The proposal SHOULD provide more than a step in an environment of escalating countermeasures. 2.8.1 Rational: Authors should consider the status quo concerning the development and deployment of stop-gap measures a failure. Solutions or research into the problem should present a solution that does not maintain the status quo of deployment/countermeasure. Solutions should be designed to work over the longest period possible or should provably work forever. 2.9 Doesn't Interfere With The Delivery Of Legitimate Mail The proposal MUST consider, address and keep at a minimum impacts on [legitimate] messaging traffic within the MTS. Brand & Williams Expires: October 9, 2003 [Page 9] Internet-Draft Requirements April 9, 2003 2.9.1 Rationale: Proposals must consider the reasons for successful widespread deployment of the current MTS: low latency, high deliverability, scalability, functionality for multiple content types, etc. Authors should develop proposals that minimize impact in these critical areas for [legitimate] MTS uses. Thus a successful proposal will impact only [spam] and not [legitimate] messaging traffic. 2.10 Single Solution The proposal SHOULD provide a comprehensive solution that impacts the greatest number of problems caused by [spam], and usable or accessible by the greatest number of MTS users. 2.10.1 Rationale: A single solution that will work for all people is the optimum solution, designers should strongly consider methodologies or approaches that impact the largest number of MTS users. A solution that is optimal will also impact all of the problems associated with [spam], such as [list of problem terms]. 2.11 Technical Rather Than Legislative The proposal MUST be functional without external enforcement measures such as legislation. 2.11.1 Rationale: Proposals may consider the effect of legislation but must not rely on legislative measures to be functional. A particular solution will be deployed in an international setting and cannot effectively be deployed under the legislative auspices of any particular jurisdiction. Designers should consider effects of a solution on enforcement of legislation only as it relates to aiding in enforcement. 2.12 Complexity The proposal SHOULD strive for simplicity versus complexity. 2.12.1 Rationale: Any technical solution that meets the criteria described for success should remain as simple as possible within the constraints of the methodology. Regardless of the method used to address the problems of [spam], the proposal should be easily understood or described using simple terms. The less complex the solution or a description of its functioning, the more likely the adoption by a wide audience. Brand & Williams Expires: October 9, 2003 [Page 10] Internet-Draft Requirements April 9, 2003 2.13 Implement ability Proposals MUST represent a methodology or technology that it is possible to implement. 2.13.1 Rationale: While many theories for addressing and eradicating the problems being addressed exist only a sub-set of the possible universe of theories can be developed into a solution that can be successfully implemented. In order to preserve the resources for evaluation of proposals and limit discussion of non- workable proposals, designers must present proposals where the consideration of ease of implementation, perceived implementation difficulties, existing implementations, reference implementations, and/or interoperable implementations have been addressed. 2.14 Other Platforms Proposals MAY consider methodologies that are effective on platforms and system alternatives to the traditional MTS. 2.14.1 Rationale: Technologies are emerging and available as alternative messaging environments to the traditional MTS. Designers may consider including specific or general methodologies that will interoperate with or integrate with these emerging and alternative technologies. Methods that work with instant messengers, receive-only alphanumeric pagers, two-way alphanumeric pagers, and/or SMS/phone text messaging are some of the technologies that are considered good candidates for evaluation. 2.15 Accountability and Anonymity Proposals MUST address issues of accountability and anonymity of MTS users, specifically message senders. 2.15.1 Rationale: One of the most pernicious issues involving [spam] are related to accountability of the [spammers] who provide invalid or simulated information in order to “game the system” provided by the current MTS. Designers MUST describe the issues of accountability addressed by their proposal. Message origination and message formatting forgery must be considered in designs, an optimal design would allow tracing of messages to the sending person, organization and/or system. Brand & Williams Expires: October 9, 2003 [Page 11] Internet-Draft Requirements April 9, 2003 Additionally, there is just cause for preserving sender anonymity and supporting the use of appropriate ‘anonymization’ services that currently exist. Designers must consider the impact of accountability by a proposal on these systems and address the issues related to preserving anonymity for [legitimate] uses. 3. Security Considerations This document does not address security matters. However, security and privacy are important concerns that should be considered while developing a solution which deals with public and private coorespondence. Security considerations may be established by the ASRG but are not presently included. Informative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Crocker, D. "Technical Considerations for Spam Control Mechanisms", work in progress, Internet-Draft draft-crocker-spam-techconsider-00.txt, April 2003. Authors' Addresses Rusell L. Brand Procinct Security Corporation 870 Market Street, Suite 1105 San Francisco, CA 94102 US EMail: Brand@responsible.com URI: http://www.procinct.com/ Eric D. Williams Information Brokers, Inc. 1309 S Street, SE Washington, DC 20020 US EMail: eric@infobro.com URI: http://www.infobro.com/ Brand & Williams Expires: October 9, 2003 [Page 12] Internet-Draft Requirements April 9, 2003 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgements Funding for the RFC Editor function is currently provided by the Internet Society. Brand & Williams Expires: October 9, 2003 [Page 13]