Subject: RE: Short-term versus Long-term focus: A bit of economics ( was: RE: [Asrg] TitanKey and "white lies"... (..."improves" C/R utility?))

From: "Eric D. Williams" <[email-masked]>
Date: Mon, 2 Jun 2003 22:50:35 -0400

I strongly suggest that the group review the proposed (draft-draft) 
requirements <attached> and see if they meet the goals of this group.

-e

On Monday, June 02, 2003 12:23 AM, Barry Shein [SMTP:[email-masked]] wrote:
>
> On the other hand, spam has been around for almost 10 years, and has
> certainly been a major concern at public sites since at least 1997,
> almost seven years ago.
>
> So, although a quick solution of some magnitude is almost mandatory
> just to stop something major kicking over the entire chessboard (death
> of the net and all that), let's not completely rule out so-called
> long-term, slow adoption approaches with 5-10 year horizons or even
> longer.
8<...>8

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 Single 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: [email-masked]
 URI:   http://www.procinct.com/
 
 Eric D. Williams
 Information Brokers, Inc.
 1309 S Street, SE
 Washington, DC 20020
 US
 
 EMail: [email-masked]
 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]

---

From: "Eric D. Williams" <[email-masked]>
Date: Mon, 2 Jun 2003 23:16:04 -0400

In the earlier drafts of the draft-asrg-requirements-xx.txt output there was a 
consideration of a methodology for considering effectiveness.  This was dropped 
because many (or few) assumptions may be described that constrain the solution 
in some.  Thus this type of methodology was dropped in favor of proposals that 
enumerate the assumptions of the proposed solution (and the set of 'spam' 
problems that are being addressed) and the solution set described.

-e

P.S. I do think that the following is a valid approach to a basis set of 
assumption axes, though there may be other dimensions that could be considered.

On Monday, June 02, 2003 7:42 PM, Barry Shein [SMTP:[email-masked]] wrote:
>
> Well, we could propose a simple, three-dimensional model for any spam
> solution whose axes would be:
>
> 	 1. Adoption (perhaps percentage of servers or clients.)
> 	 2. Spam reduction (percentage of spam)
> 	 3. Time (years or whatever.)
>
> and try to judge the merit of a proposal on that basis.
>
> Obviously one can't predict such a curve with any great accuracy but
> at least we'd be estimating the same parameters for discussions' sake.
>
> As an example, I think RMX would have a fairly steeply rising curve
> over time for Adoption, particularly if # of servers was weighted by
> the number of clients they represent (e.g., if AOL adopts it then
> that's a big jump), and then adoption would probably slow down a lot
> (i.e., early adopters adopt early and everyone else ignores it
> mostly), and the (measurable) spam reduction would be small to zero
> because I don't think it's a spam-reducer.
>
> Others no doubt have another opinion, but if accepted this might be
> some grounds for a common criteria.
>
> I'll dub it the "Effectiveness Axes" or E-Axes for short.
>
> --
>         -Barry Shein
>
> Software Tool & Die    | [email-masked]           | http://www.TheWorld.com
> Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
> The World              | Public Access Internet     | Since 1989     *oo*
> _______________________________________________
> Asrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Peter Kay" <[email-masked]>
Date: Mon, 2 Jun 2003 20:52:49 -1000

I think the proposal requirements are very good. I also think it will be
vitally important to clearly define:

1. what is spam.

2. what are the "subsets" of spam that will be addressed per 2.6

3. what is "legitimate" email per 2.8.

While we are looking into the eye of the storm with the above
definitions, I feel it will be vital that this group come to some
consensus as to what is spam and what is not.  If we can't clearly
define the problem we cannot hope to clearly define the solution, nor
can we clearly evaluate proposals.

Peter Kay
www.titankey.com
The only technology that stops spam BEFORE it is sent

> -----Original Message-----
> From: Eric D. Williams [mailto:[email-masked]]
> Sent: Monday, June 02, 2003 4:51 PM
> To: 'Barry Shein'; [email-masked]
> Cc: 'John Fenley'; [email-masked]
> Subject: RE: Short-term versus Long-term focus: A bit of economics (
was: RE:
> [Asrg] TitanKey and "white lies"... (..."improves" C/R utility?))
> 
> On Monday, June 02, 2003 12:23 AM, Barry Shein
[SMTP:[email-masked]]
> wrote:

---

From: "Eric D. Williams" <[email-masked]>
Date: Tue, 3 Jun 2003 22:53:33 -0400

> vitally important to clearly define:

A good question.

> 2. what are the "subsets" of spam that will be addressed per 2.6

A suggestion from some months back.

On Monday, March 31, 2003 10:35 PM, Brad Templeton [SMTP:[email-masked]] 
wrote:
8<...>8
> As noted, the 4 problems caused by spam are server overload, ruination of
> mailbox S/N, creation of fear of putting your email address out, and dealing
> with both real and bogus complaints.

> 3. what is "legitimate" email per 2.8.

Yes another good question.

> can we clearly evaluate proposals.

Agreed.

-e