Anti Spam Research Group R. Brand Internet-Draft Procinct Security Corporation Expires: Mmmmmmm D, YYYY E. Williams Information Brokers, Inc. May 29, 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 Mmmmmmm dd, yyyy. Copyright Notice Copyright (C) The Internet Society (2003). 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 May 29, 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 6 1.3.9 Domain Name System (DNS) 6 1.3.10 E-mail 6 1.3.11 False Negative 6 1.3.12 False Positive 6 1.3.13 Legitimate Messaging 6 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 7 1.3.18 Message Header Forgery 7 1.3.19 Message Origination 7 1.3.20 Message Originator 7 1.3.21 Message Transfer Agent 7 1.3.22 Message Transfer System 7 1.3.23 Message User Agent 7 1.3.24 Message Store/Message Storage Agent 8 1.3.25 Non Consent Based Communication (spam) 8 1.3.26 Open Relay MTA 8 1.3.27 Opt-In 8 1.3.28 Opt-Out 8 1.3.29 Recipient/Receiver 8 1.3.30 Sender 8 1.3.31 Spammer 8 1.3.32 Relay MTA 8 1.3.33 Selective Relay MTA 9 1.3.34 Reverse DNS 9 1.3.35 Transport Protocol 9 1.3.36 Unsolicited Bulk E-Mail 9 1.3.37 Unsolicited Commercial E-Mail 9 1.4 Anti Spam Technical Framework 9 1.5 Organization of Requirements 10 2. Requirements 10 2.1 Use of existing RFCs 10 2.1.1 Rationale: 10 2.2 Inexpensive 10 2.2.1 Rational: 10 Brand & Williams Expires: Mmmmmmm D, YYYY [Page 2] Internet-Draft Requirements May 29, 2003 2.3 Ease of Use 11 2.3.1 Rationale: 11 2.4 Ease of Deployment 11 2.4.1 Rational: 11 2.5 Interoperable 11 2.5.1 Rational: 11 2.6 Highly Effective 12 2.6.1 Rationale: 12 2.7 Persistently Effective 12 2.7.1 Rational: 12 2.8 Doesn't Interfere With The Delivery Of Legitimate Mail 12 2.8.1 Rationale: 12 2.9 Gola Oriented Solution 12 2.9.1 Rationale: 12 2.10 Technical Rather Than Legislative 13 2.10.1 Rationale: 13 2.11 Complexity 13 2.11.1 Rationale: 13 2.12 Implement ability 13 2.12.1 Rationale: 13 2.13 Other Platforms 14 2.13.1 Rationale: 14 2.14 Accountability and Anonymity 14 2.14.1 Rationale: 14 3. Security Considerations 14 Informative References 15 Authors' Addresses 15 Full Copyright Statement 16 Acknowledgements 16 Brand & Williams Expires: Mmmmmmm D, YYYY [Page 3] Internet-Draft Requirements May 29, 2003 1. Introduction This is an unordered simple listing of possible criteria for ASRG to evaluate anti-spam solutions. The ASRG should solicit 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: Mmmmmmm D, YYYY [Page 4] Internet-Draft Requirements May 29, 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 [TBD]. 1.3.1 Anti-spam (Requires consensus definition - RCD) 1.3.2 Bulk E-mail (RCD) 1.3.3 Caller (RCD) 1.3.4 Callback (RCD) 1.3.5 Challenge/Response System (RCD) 1.3.6 Consent (RCD) 1.3.7 Consent Based Communications (RCD) Brand & Williams Expires: Mmmmmmm D, YYYY [Page 5] Internet-Draft Requirements May 29, 2003 1.3.8 Commercial E-mail (RCD) 1.3.9 Domain Name System (DNS) A system for associating character based names with numerically based internet protocol addresses [3]. The DNS works with in the framework of internetwork communications to provide names (called domain names) to zones of authority. The DNS is a facility for mapping user friendly names to transactional end point identifiers (IP addresses). The DNS is heavily utilized by messaging systems to determine end point identifiers for message relays and message termination points[8]. A full definition of the operation of the DNS is outside of the scope of this document. 1.3.10 E-mail The term commonly used to describe a system of messaging based in a network of distributed systems and acted on by computer software and human actors. E-mail is a method of communications used in Internet for multiple purposes too numerous to list in this definition. 1.3.11 False Negative In the context of this paper, a false negative is as defined in [7] and is determined after a message filter test. A False Negative (FN) is where a "Message fails to match the test criteria, but the criteria are not sufficiently strong." 1.3.12 False Positive In the context of this paper, a false positive is as defined in [7] and is determined after a message filter test. A False Positive (FP) is where a "Message matches test criteria but the criteria are too aggressive." 1.3.13 Legitimate Messaging (RCD) 1.3.14 Message Content That part of a messaging transaction that contains data as described by [4],[9]. Message content consists of RFC2822/RFC822 compliant data. 1.3.15 Message Envelope Forgery (RCD) 1.3.16 Message Envelope Protocol The protocol used during message transfer to insert message content into the message transfer system. The primary envelope protocol used in Internet is defined in [5]. The message envelope protocol precedes the transfer of message content and Brand & Williams Expires: Mmmmmmm D, YYYY [Page 6] Internet-Draft Requirements May 29, 2003 terminates message content transfer. 1.3.17 Message Header That part of message content that precedes the message body and/or dictates the methodology for parsing the message into message body parts as defined in [4],[6]. 1.3.18 Message Header Forgery (RCD) 1.3.19 Message Origination The process of inserting an original or revised message into the message transfer system by an MUA, a human actor or any system in the network of systems that comprise the message transfer system. 1.3.20 Message Originator An actor, human or machine, that causes the insertion of an original or revised message into the message transfer system. 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 Originators. 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 +---> MTA <-> MTA <-> MTA <----+ | | | | | V V | MUA <-> MS MS <-> MUA The MTS also exhibits control points as described in [7] for addressing [spam]. 1.3.23 Message User Agent A program or user interface that provides access for a human actor to the MTS and/or messages stored in a message store. A message user agent (MUA) provides the human friendly interface, if needed, for sending and receiving message transactions. It may also supply an user-level programming interface, for programmatic access to user functionality. An MUA may also provide capabilities for editing, deleting, filtering, sorting and storing messages. MUA features vary across platforms and implementations. Brand & Williams Expires: Mmmmmmm D, YYYY [Page 7] Internet-Draft Requirements May 29, 2003 1.3.24 Message Store/Message Storage Agent A system that provides storage for messages, the system usually is acting on behalf of a human actor, but this is not required. An MUA may act on a local message store or may provide access to a remote message storage system, or both. In the latter sense the term message storage agent is typically used. The term message store (MS) is usually, though not exclusively associated with a system where messages are stored prior to retrieval by an MUA. 1.3.25 Non Consent Based Communication (spam) (RCD) 1.3.26 Open Relay MTA An MTA which is configured to relay mail for local domains and foreign domains not associated with the MTA, without restricting access to the relay functions. In essence an Open Relay MTA typically relays messages for known and unknown domains because of improper configuration. 1.3.27 Opt-In (RCD) 1.3.28 Opt-Out (RCD) 1.3.29 Recipient/Receiver A computer system, application or process that is the final, terminating end of a messaging transmission sequence. A receiver is engaged in the activity of receiving final delivery of a message comprising an message envelope and optional content. A receiver usually is acting on behalf of a human actor, but this is not required. 1.3.30 Sender A computer system, application or process that is the origin, terminating end of a messaging transmission sequence. A sender is engaged in the activity of initial posting of a message comprising an message envelope and optional content. A sender usually is acting on behalf of a human actor, but this is not required. Sender may also be a message header field [4]. 1.3.31 Spammer (RCD) 1.3.32 Relay MTA An MTA configured to participate in a store-and-forward sequence between a sender's MTA and a receiver's MTA. The term Relay MTA is meant to apply to MTA systems that do not transact with MUAs, but only with other MTAs. Brand & Williams Expires: Mmmmmmm D, YYYY [Page 8] Internet-Draft Requirements May 29, 2003 1.3.33 Selective Relay MTA An MTA configured to recognize and participate in a store-and-forward sequence between a sender's MTA and a receiver's MTA but only for messages that are originated from known domains[8]. A Selective Relay MTA is distinguished from other Relay MTAs by performing authentication and/or origination checks before relaying a message. The term Selective Relay MTA may apply to MTA systems that transact with MUAs, and with other MTAs. 1.3.34 Reverse DNS Term used to describe the process of using the DNS to query for a mapping from numeric end point identifier (IP address) to character based user friendly name (domain name). 1.3.35 Message Transfer Protocol For purposes of this document a Message Transfer Protocol describes a communications protocol used to communicate information between computer systems for the purpose of performing the exchange of application message data. The protocol may provide reliable or unreliable communications. The Transfer Protocol is independent of message content, although it may impose other communications constraints. 1.3.36 Unsolicited Bulk E-Mail (RCD) 1.3.37 Unsolicited Commercial E-Mail (RCD) 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 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. 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. Brand & Williams Expires: Mmmmmmm D, YYYY [Page 9] Internet-Draft Requirements May 29, 2003 1.5 Organization of 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 will at a minimum meet the requirements laid out in this document. However, this document should only 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. 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. Brand & Williams Expires: Mmmmmmm D, YYYY [Page 10] Internet-Draft Requirements May 29, 2003 2.3 Ease of Use The approach SHALL consider the ease of use for message system managers, senders and recipients in all messaging situations. 2.3.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.4 Ease of Deployment The proposal SHOULD consider deployment on any basis and take into account existing systems deployed and operating in the MTS. 2.4.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. 2.5 Interoperable Proposals MUST be interoperable with existing MTS uses. 2.5.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 access to MS and delivery to MTA relays, etc. Additionally, the platforms that manage messaging applications are also heterogeneous, 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. Brand & Williams Expires: Mmmmmmm D, YYYY [Page 11] Internet-Draft Requirements May 29, 2003 2.6 Highly Effective The proposal MUST provide an effective solution and identify the subset of [spam] it will be effective against with Assumptions. 2.6.1 Rationale: Although proposals may differ in approach all proposals will be evaluated using an appropriate application of the assumptions presented and the solution set described. This will provide a consistent basis and measures for evaluation of the approach. 2.7 Persistently Effective The proposal SHOULD provide more than a step in an environment of escalating countermeasures. 2.7.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 threat analysis with the threat(s) being addressed, protection goals, possible countermeasures and defenses against those countermeasures over the longest period possible or that provably work forever. 2.8 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. 2.8.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 an optimal proposal will impact only [spam] and not [legitimate] messaging traffic. 2.9 Goal Oriented Solution The proposal SHOULD provide a carefully drafted scope of its goals and its effectiveness at addressing those goals. Systems SHOULD consider how they interoperate with other [anti-spam] systems. 2.9.1 Rationale: A single solution that will work for all people is the optimum Brand & Williams Expires: Mmmmmmm D, YYYY [Page 12] Internet-Draft Requirements May 29, 2003 solution. However, designers should provide documentation that carefully scopes out the goals and effectively addresses them. Interoperation of [anti-spam] solutions may benefit the overall solution. A solution that is optimal also impacts all of the problems associated with [spam], such as [list of problem terms]. Approaches that impact a sub-domain of problems should be designed to leverage that approach with other approaches to broaden the overall solution. 2.10 Legislative and Policy Considerations The proposal SHOULD consider how laws and policies affect, support or constrain the technology. 2.10.1 Rationale: A proposal should consider how legal and policy issues affect, support, or constrain the technology. If a solution supports or is supported by particular legislation, then this should be explicitly stated. We encourage authors to understand the relationship between the technology and the legislation and effects of a solution on enforcement of legislation as it relates to aiding in enforcement. 2.11 Complexity The proposal SHOULD strive for simplicity versus complexity. 2.11.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. 2.12 Implement ability Proposals MUST represent a methodology or technology that it is possible to implement. 2.12.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 Brand & Williams Expires: Mmmmmmm D, YYYY [Page 13] Internet-Draft Requirements May 29, 2003 implementation difficulties, existing implementations, reference implementations, and/or interoperable implementations have been addressed. 2.13 Other Platforms Proposals MAY consider methodologies that are effective on platforms and system alternatives to the traditional MTS. 2.13.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.14 Accountability and Anonymity Proposals MUST address issues of accountability and anonymity of MTS users, specifically message senders. 2.14.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. 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 must be considered while developing a solution which deals with public and private correspondence. Security considerations should be established by the ASRG but are not presently included. Brand & Williams Expires: Mmmmmmm D, YYYY [Page 14] Internet-Draft Requirements May 29, 2003 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] Mockapetris, P., "Domain Name System", STD 13, RFC 1034 and RFC 1035, November 1987. [4] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001. [5] Klensin, J. "Simple Mail Transfer Protocol", RFC 2821, April 2001. [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [7] Crocker, D. "Technical Considerations for Spam Control Mechanisms", work in progress, Internet-Draft draft-crocker-spam-techconsider-00.txt, April 2003. [8] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, January 1986. [9] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, August 1982. Authors' Addresses Rusell L. Brand Procinct Security Corporation 870 Market Street, Suite 1105 San Francisco, CA 94102 US EMail: Brand(_at_)responsible(_dot_)com URI: http://www.procinct.com/ Eric D. Williams Information Brokers, Inc. 1309 S Street, SE Washington, DC 20020 US EMail: eric(_at_)infobro(_dot_)com URI: http://www.infobro.com/ Brand & Williams Expires: Mmmmmmm D, YYYY [Page 15] Internet-Draft Requirements May 29, 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). 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. The following individuals contributed substantially to this document and should be recognized for their efforts. This document would not exist without their help: Dave Crocker John Kyme [william-at-elan.net] Alan DeKok J C Lawrence Phillip Hallam-Baker Steven F Siirila Jason Hihn Brad Templeton Paul Judge Jim Youll Brand & Williams Expires: Mmmmmmm D, YYYY [Page 16]