Criteria for Proposed Techniques for the management of Spam
draft-irtf-asrg-criteria-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

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 May 5, 2007.

Copyright Notice

Copyright © The IETF Trust (2006).

Abstract

The Internet Research Task Force Anti-Spam Research Group (ASRG) is frequently presented with proposals for techniques for managing spam from authors who wish to elicit an expert critique of their proposals. In many cases proposals fall foul of issues and risks which are well known and understood by members of the ASRG. This Internet Draft is intended to enumerate and explain a number of the more important of the criteria which tend to be applied. This document will then serve as a normative checklist for anyone wishing to present a technique to the ASRG.

Table of Contents

1.  Terminology
    1.1.  Message
        1.1.1.  Spam
        1.1.2.  Content Type
    1.2.  Proposed Technique
        1.2.1.  Complete Technique
        1.2.2.  Partial Technique
    1.3.  Process Endpoints
        1.3.1.  Sender
        1.3.2.  Recipient
    1.4.  Transport System
        1.4.1.  Mail Agents
        1.4.2.  External System
        1.4.3.  Upstream
        1.4.4.  Downstream
2.  Key characteristics for Proposed Techniques
    2.1.  Need 1: Reduce the costs incurred in the transport and processing of Spam.
        2.1.1.  Direct costs in proportion to benefit
        2.1.2.  Indirect cost benefit
        2.1.3.  Reduce the introduction of unwanted mail
        2.1.4.  Predictable in operation
    2.2.  Need 2: Reduce the effort of managing spam by recipients.
        2.2.1.  Usability
        2.2.2.  Efficacy
    2.3.  Need 3: Do not alter the defining characteristics of email.
        2.3.1.  Allow new participants
        2.3.2.  Avoid arbitrary charging
        2.3.3.  Don't re-invent identity and trust models
        2.3.4.  Use open standards
        2.3.5.  Avoid central administration
        2.3.6.  Don't impose commercial administration
        2.3.7.  Support multi-hop transport
        2.3.8.  Support legacy Message formats
        2.3.9.  Voluntary participation
3.  Security Considerations
4.  Normative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [2]

1.1.  Message

As defined in RFC2821 (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.) [1], section 2.3.1 "mail object" .

1.1.1.  Spam

Any Message or Messages of the class of Messages which the Recipient wishes to prevent from ever being presented with. It is implicit in this definition that it is unnecessary to ever transport Spam. Spam in this context can also be defined as Messages which it is never necessary to transport. It is not in the scope of this document to attempt to distinguish or justify any more detailed definition of this term. Nor is it in the scope of this document to analyse the reasons why the Recipient wishes not to be presented with the Message or Messages. The term Spam is both the singular and plural form.

1.1.2.  Content Type

As defined in RFC1049 (Sirbu, M., “Content-type header field for Internet messages,” March 1988.) [3] and subsequently enhanced in RFC2045 (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.) [5].

1.2.  Proposed Technique

Any process, device, or method which is being considered for the purpose of managing Spam. A Proposed Technique MAY be either a Complete Technique or a Partial Technique.

1.2.1.  Complete Technique

A complete Technique MUST comply with Section 2.1 (Need 1: Reduce the costs incurred in the transport and processing of Spam.), Section 2.2 (Need 2: Reduce the effort of managing spam by recipients. ), and Section 2.3 (Need 3: Do not alter the defining characteristics of email.) .

1.2.2.  Partial Technique

A Partial Technique MUST comply with one of Section 2.1 (Need 1: Reduce the costs incurred in the transport and processing of Spam.) or Section 2.2 (Need 2: Reduce the effort of managing spam by recipients. ) and MUST comply with Section 2.3 (Need 3: Do not alter the defining characteristics of email.)

1.3.  Process Endpoints

The delivery of Messages is normally a linear process, it is useful to define the endpoints of the process in order to discuss the behaviour of the Proposed Technique from each of those two perspectives

1.3.1.  Sender

The person, automated system or group responsible for the creation and initial entry of a Message into the Transport System. The sender SHOULD be identified in accordance with RFC2821 (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.) [1]

1.3.2.  Recipient

The person, group, or system for which a Message is destined. This definition is taken to mean the actual destination and should be contrasted with any apparent "intended" recipient which might be misleadingly indicated in the Message headers or the transport envelope. For instance a bogus address in a "To:" header does not identify a Recipient whereas a valid address listed in an SMTP "RCPT TO" command does whether an account exists for the recipient or not. Where the recipient account does not exist the system which discards the undeliverable Message is the Recipient. While this definition includes systems it does not include intermediate Mail Agents and only refers to hosts which are final destinations for Messages, this definition would include hosts which automatically consume Messages as part of a system function, but exclude Mail User Agents in which case the user of the MUA is the Recipient.

1.4.  Transport System

The whole collection of interoperating components of all kinds which are directly and indirectly involved in the sucessful transport of a Message from a Sender to a Recipient. It is useful to define certain logical subsets of the Transport System in order to contextualise the component under discussion with the perspective which the author is considering.

1.4.1.  Mail Agents

The use here of the terms MTA and MUA should be taken to be equivalent to their use in RFC2821 (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.) [1].

1.4.2.  External System

Any part of the Transport System which is not under the control of an operator of all or part of the Proposed Technique. From the Sender's point of view the External System might include all downstream Mail Agents and components upon which transport depends, such as firewalls and DNS outwith the boundary of the Senders immediate system. From the Recipient's point of view it might include all upstream Mail Agents, Mail User Agents and firewalls, but not the firewall of the Recipient's system nor any Mail Agents or other components within the boundary of the Recipient's system.

1.4.3.  Upstream

A Mail Agent which initiates contact and delivers messages into the system being considered.

1.4.4.  Downstream

A Mail Agent which is contacted by the system under consideration and into which that system delivers messages.

2.  Key characteristics for Proposed Techniques

It is important to understand what the idealised goal for managing spam might be. Understanding this "business need" is the key to reaching the criteria by which we can judge Proposed Techniques. It is clear to the author from an examination of Techniques proposed to the ASRG and from a survey of existing techniques that three needs exist. It is not the purpose of this document to discuss the validity of these, merely to document them in order to analyse the requirements they imply. This document contends that the three characteristics of the idealised Technique are:

2.1.  Need 1: Reduce the costs incurred in the transport and processing of Spam.

The author believes that in order for a Proposed Technique to reduce the cost imposed by the transport of Spam on operators of components of the Transport System the following requirements are relevant:

2.1.1.  Direct costs in proportion to benefit

Operating the Proposed Technique SHOULD NOT have direct operational costs which rise in inverse proportion to the benefit it confers. The cost SHOULD be unrelated to the volume of Messages or SHOULD rise and fall as the number of Spam messages presented rises or falls or SHOULD rise and fall as the total number of Messages handled rises or falls, and MUST NOT rise as the number of Spam messages falls.

2.1.1.1.  Reduce unnecessary processing

Proposed Technique SHOULD allow decisions which have been made by recipients' systems to be propagated into the Transport System to allow external systems to avoid unnecessary further processing of messages which would have been identified as spam had they been delivered.

2.1.2.  Indirect cost benefit

Proposed Technique SHOULD have a net costs which reduce as the technique becomes effective.

2.1.2.1.  Avoid imposing inequitable loads.

Proposed Techniques for removing or blocking messages SHOULD NOT significantly increase in the long term directly or indirectly the overall cost of operating External Systems as a result of processing Messages by the Proposed Technique. Proposals which aim to prevent the insertion of additional SPAM Messages MAY impose additional loads on specified components if the net effect of their use is to decrease the overall resource requirements for the transport of Messages by reducing the cost associated with transporting, processing, and storing Spam. In other words any Proposed Technique MUST NOT achieve its end at the expense of offloading the burden of cost onto External Systems without also passing on any benefit to External Systems. In any Proposed Technique any components involved with identifying and removing unwanted Messages SHOULD, when operating successfully, create conditions in which resource consumption should tend to reduce in all components as a consequence of removing Spam.

2.1.3.  Reduce the introduction of unwanted mail

Proposed Technique SHOULD aim to reduce the insertion of unwanted mail into the Transport System.

2.1.4.  Predictable in operation

Resource requirements for components identifying and removing unwanted messages from the system SHOULD be designed to be predictable and based upon measurable attributes of the traffic. Any Proposed Technique which is likely to be acceptable to operators of systems SHOULD allow operators to predict and plan their resource requirements based on measurements of past events, comparison with other operators and predictions based upon expert knowledge.

2.2.  Need 2: Reduce the effort of managing spam by recipients.

Proposed Techniques SHOULD reduce the effort or complexity of managing Spam by Recipients. Whilst this is similar to the requirement to reduce the Downstream costs it is more specifically intended that the quality of a Proposed Technique for satisfying this need be judged in terms of the usability, efficacy and/or complexity of managing the Recipient's burden of Spam.

2.2.1.  Usability

Proposed Techniques SHOULD NOT mandate the use of other communication channels, e.g. http. Proposed Techniques SHOULD NOT mandate the use of specialised Content Types for all Messages, but MAY propose the use of specialised Content Types for well defined special uses, on the understanding that not all MUA's will support them, and not all Recipients will be able to access the content.

2.2.2.  Efficacy

Proposed Techniques SHOULD be effective in reducing the Recipient's burden of Spam.

2.3.  Need 3: Do not alter the defining characteristics of email.

This goal contends that any Proposed Technique which alters the defining characteristics of email is not a solution, in some degree or other it would represent a replacement of email with a new form of message transport, and therefore is quite simply outside of the scope of this document.

2.3.1.  Allow new participants

Proposed technique MUST allow for new Senders and Recipients to interoperate without prior knowledge.

2.3.2.  Avoid arbitrary charging

Proposed technique MUST NOT levy a charge for transport, either directly, or indirectly through subscription or the purchase of tokens or any other form of registration fees, or by imposing arbitrary loads on Upstream External Systems or Mail Agents.

2.3.3.  Don't re-invent identity and trust models

Proposed Techniques MUST NOT reinvent existing identity and/or trust mechanisms, we believe that trust and identity mechanisms already exist in this and other domains which are more than capable of satisfying any requirement in this domain.

2.3.4.  Use open standards

Proposed technique MUST use open standards for identity and/or trust. Prpopsed techniques MUST be unencumbered by intellectual property constraints which might have the effect of passing control over email to any single person or organisation.

2.3.5.  Avoid central administration

Proposed technique SHOULD NOT require a centralized register, practical considerations of scaleability and operation as well as the cost of administration suggest that a distributed scheme is desirable in most if not all cases.

2.3.6.  Don't impose commercial administration

Proposed techniques MUST NOT require a commercial register. Proposed techniques MAY include the non-exclusive provision of a commercially operated register so long as there is no bar to the provision of non commercial alternatives. Any scheme including a register MUST publish an unencumbered interoperability standard where appropriate for the register itself to permit alternative operators to be established.

2.3.7.  Support multi-hop transport

Proposed techniques SHOULD NOT prohibit multi-hop transport. Whilst Multi hop transport in many systems is restricted to trusted systems or senders, because this characteristic of email is insecure at this point in time, any proposal for managing spam MUST recognise that there is a need for multi hop transport which MUST be satisfied in some way.

2.3.8.  Support legacy Message formats

Enhancements and updates subsequent to the original ARPA standard RFC0733 (Crocker, D., Vittal, J., Pogran, K., and D. Henderson, “Standard for the format of ARPA network text messages,” November 1977.) [4] , and possibly earlier variants, allow older Message formats and Mail Agents to continue to interoperate with systems built to newer standards. Many systems are still in use today which do not support newer or optional aspects of these subsequent enhancements, for example systems exist which cannot handle rich content types. Proposed Techniques MUST consider the impact of their adoption on the backwards compatibility of email systems.

2.3.9.  Voluntary participation

Participation in Proposed Techniques should be voluntary, authors of proposed techniques SHOULD assume that there will be early adopters, and those who's adoption lags behind. It SHOULD be assumed that operators of end-of-life legacy or highly specialised systems will not have the capability or capacity to adopt the proposed technique in the short or medium term. There MUST NOT be a flag day required (being a date after which the Transport System is incompatible with the Transoprt System as it existed before). It SHOULD be assumed that the pattern of uptake of the proposed system will be that of operators trying to achieve the benefits of the Proposed Technique and not through compulsion or altuism.

3.  Security Considerations

This memo raises no security issues.

4. Normative References

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2006).

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.

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, THE IETF TRUST 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.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgment

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).