Network  Working  Group                                 Eric Dean
draft-irtf-asrg-cri-00.txt                      Crystal Ball Inc.
                                               Yakov Shafranovich
Expires: <03-2004>                 SolidMatrix Technologies, Inc.




      Challenge / Response Interworking (CRI) Framework
              for Challenge / Response Email Systems

    A working document of the Anti Spam Research Group (ASRG) of
            the Internet Research Task Force (IRTF)





Status of this Memo

     This document is an Internet-Draft and is subject to 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/1id-abstracts.html

     The list of Internet-Draft Shadow Directories can be
     accessed at http://www.ietf.org/shadow.html

     Copyright (C) The Internet Society (2003). All Rights
     Reserved.

     This Internet-Draft will expire in March of 2004.




Abstract

     SMTP was designed simply to deliver email messages without
     authenticating sources or senders of email messages. In an
     effort to reduce spam on the Internet, Challenge/Response
     ("C/R") email systems were developed to provide a method
     for validating message origination for an intended recipient.
     This document defines a Challenge / Response Interworking
     ("CRI") protocol by proposing the use of SMTP extensions and
     MIME headers for interoperability of C/R systems. This
     document also defines a set of guidelines for continued
     use with existing non-CRI mail systems and clients.




Table of Contents

        1. INTRODUCTION. . . . . . . . . . . . . . . . . . . . . .
        1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . .
        1.2. CRI and Consent . . . . . . . . . . . . . . . . . . .
        1.3. Definitions . . . . . . . . . . . . . . . . . . . . .
        2. CHALLENGE / RESPONSE INTERNETWORKING MODEL. . . . . . .
        2.1. CRI Model Illustration. . . . . . . . . . . . . . . .
        2.2. Levels of C/R . . . . . . . . . . . . . . . . . . . .
        3. DIFFERENT METHODS FOR CRI . . . . . . . . . . . . . . .
        3.1. Using MIME for CRI. . . . . . . . . . . . . . . . . .
        3.1.1. Using "multipart/report" MIME Type. . . . . . . . .
        3.1.2. Defining a New "multipart/cri" MIME Type. . . . . .
        3.2. MIME Headers for CRI. . . . . . . . . . . . . . . . .
        3.2.1. Headers in the Initial Message. . . . . . . . . . .
        3.2.2. Headers in the Challenge Message. . . . . . . . . .
        3.2.3. Headers in the Response Message . . . . . . . . . .
        3.3. CRI ESMTP Extension . . . . . . . . . . . . . . . . .
        3.4. Examples of CRI . . . . . . . . . . . . . . . . . . .
        3.4.1. MIME Example. . . . . . . . . . . . . . . . . . . .
        3.4.2. CRI ESMTP Examples. . . . . . . . . . . . . . . . .
        4. INTEROPERABILITY CONSIDERATIONS . . . . . . . . . . . .
        4.1. Loop Avoidance. . . . . . . . . . . . . . . . . . . .
        4.2. Mailing Lists . . . . . . . . . . . . . . . . . . . .
        5. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . .
        6. PRIVACY CONSIDERATIONS. . . . . . . . . . . . . . . . .
        7. IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . .
        8. ADDITIONAL INFORMATION. . . . . . . . . . . . . . . . .
        8.1. References  . . . . . . . . . . . . . . . . . . . . .
        8.1.1. Normative References. . . . . . . . . . . . . . . .
        8.1.2. Informative References. . . . . . . . . . . . . . .
        8.2. Acknowledgements. . . . . . . . . . . . . . . . . . .
        8.3. IPR Information . . . . . . . . . . . . . . . . . . .
        8.4. Author(s) Addresses . . . . . . . . . . . . . . . . .
        8.5. Full Copyright Statement. . . . . . . . . . . . . . .
        8.6. Document History. . . . . . . . . . . . . . . . . . .


. INTRODUCTION.

        Challenge response systems attempt to authenticate
        senders and determine if each sender originated a message to
        an intended recipient. This document defines MIME headers and
        a SMTP extension for an interworking of challenge response
        systems while providing loose guidelines for user
        intervention.

        There are various opportunities for a CRI protocol to possibly
        operate: via MIME headers, via DSNs as defined in [RFC-3464],
        via SMTP/ESMTP, and via the Message Tracking Protocol
        defined by the MSTRK WG. This note will address and define
        various approaches to CRI via these methods.

        NOTE: This document is intended to evolve, based on comments
              from the Anti-Spam Research Group (ASRG) mailing list.
              It is certain that the current draft is incomplete and
              entirely possible that it is inaccurate. Hence, comments
              are eagerly sought, preferably in the form of suggested
              text changes, and preferably on the ASRG mailing list,
              at <asrg@ietf.org>.

        NOTE: This protocol is experimental and is not suitable for
                wide spread deployment or production use.


1.1. Purpose.

        This document proposes specific CRI methods intended to
        achieve the following objectives:

        o Interoperability between CRI capable systems methods using
          MIME and SMTP while remaining transparent and non-conflicting
          to non-CRI capable systems.

        o A messaging protocol method using defined headers for
          automatically handling challenge messages and responses

        o Loop avoidance methods that prevent CRI systems from
          challenging challenge messages

        o Exception handling for mailing lists or other systems so
          that lists do not receive challenge messages

        o Guidelines for supporting software systems incompatible with
          CRI so that email is not disrupted and therefore CRI can be
          realistically deployed

        NOTE: CRI is not an authentication method for email delivery
              nor security protocol.


1.2. CRI and Consent.

        In [CHARTER] the spam problem is approached as one of consent:

        "The definition of spam messages is not clear and is not
        consistent across different individuals or organizations.
        Therefore, we generalize the problem into "consent-based
        communication". This means that an individual or organization
        should be able to express consent or lack of consent for
        certain communication and have the architecture support
        those desires."

        [CONSENT] further expands on this idea to define a full model
        for consent communications. Within the consent model
        (section 2.5, #2) a need is expressed for having "protocols
        for sharing CONSENT TOKENS". The CRI protocol is one such
        protocol which allows CRI systems to exchange CONSENT TOKENS.
        It is possible that the CRI protocol when further developed
        will become part of a full-fledged consent token exchange
        protocol. Therefore the CRI protocol should be treated as
        an experimental protocol not suitable for production use.


1.3. Definitions.

        MTA     - Mail Transfer Agent, usually an SMTP server
        MUA     - Mai User Agent, usually a client-side email program




. CHALLENGE / RESPONSE INTERNETWORKING MODEL.

        The challenge response model is based upon the following
        method:
        a) The original sender sends a message to a recipient's MTA
           via SMTP.
        b) Either the recipient's MTA or MUA produces a challenge
           message.
        c) The resultant challenge message is sent to the original
           sender via SMTP.
        d) If the sender's MTA supports CRI, then it may automatically
           respond to the challenge message. Otherwise, the challenge
           message will be forwarded to the original senderÆs MUA.
        e) If the original sender's MUA supports CRI methods,
            then it may automatically respond to the challenge message.
        f) In the event that neither the MTA or MUA that the sender is
           using support CRI, the challenge message should contain
           clear and legible instructions to the original sender
           instructing how to appropriately respond to the challenge
           request manually.
        g) If the recipient's C/R system receives a response from the
           sender or his MTA/MUA, then the sender is considered valid
           and the message is delivered. If no response is received
           within a pre-defined period of time, then the original
           message is disposed of in a implementation specific way.


2.1. CRI Model Illustration.

     ----------------------------------------
    |                                       |
    |                                       v
    v       +----------+                +----------+
+------+    |          |                |          |    +------+
| User |<-->|          |                |          |<-->| User |
+------+    |  Sender- |  CRI Messages  | Receiver-|    +------+
+------+    |SMTP/HTTP |<-------------->|SMTP/HTTP |C/R +------+
|Client|<-->|          |                |          |<-->|Client|
|System|    |          |                |          |    |System|
+------+    +----------+                +----------+    +------+


             Sender-SMTP                Receiver-SMTP

                       Figure 1. CRI Model.


2.2. Levels of C/R.

        There are three basic levels of C/R systems, each one building
        upon the prior:
        1. Sender verification - Attempt to verify whether the original
           sender's address is valid.
        2. Message verification - Attempts to verify whether the
           original sender actually sent the original message.
        3. Turing test - Attempts to verify whether the original sender
           is human or a machine.

        Level 1 addresses an inherent loophole within SMTP that allows
        delivery of messages with invalid sender addresses. This level
        seeks to verify whether the sender's email address is valid.
        HOWEVER, there are several disadvantages with this approach
        outlines in [EMAIL-PATH]:
                o A spammer can use a valid email address that belongs
                  to someone else
                o A spammer can use a valid domain name and set it to
                  answer "yes" to all verification requests (but
                  a valid domain name makes it easier to track down
                  the spammers)
                o Can be abused by spammer to gather list of valid
                  email addresses

        Level 2 addresses some of these issues. With C/R systems,
        the intent is that sender will only respond to a C/R message
        if they in fact sent that specific message. HOWEVER, there are
        several disadvantages to this approach outlined
        in [EMAIL-PATH]:
                o Message can not be rejected at SMTP level so entire
                  message HAS to be received and challenged, requiring
                  more storage space
                o Roaming users are unable to send email directly
                  because they use their own disconnected mail server
                  and message tracking information is not sent to
                  centralized system for the domain
                o This requires mail servers to have unified index of
                  all messages that came through any of them

        Level 3 ensures that the sender is actually a human being and
        not an automated spam system. This is done by a pseudo-Turing
        test usually involves having the sender respond to a puzzle
        that cannot be processed by a computer. However, since each of
        these kind of challenges must be responded to by a human being,
        no automatic system can be provided for responding to such
        challenges, unless the sender's system is trusted by the
        recipient to possess accurate information about the sender.

        NOTE: Care must be taken designing pseudo-Turing tests so they
              support use by disabled individuals. For example,
              displaying a picture as a Turing test will shut out any
              blind individual.


. DIFFERENT METHODS FOR CRI.

        There are various methods available for CRI: RFC 822/2822
        headers, Delivery Status Notification (DNS) messages, MIME
        headers, SMTP extension, and Message Tracking Protocol defined
        by the MSTRK WG. Here we will explain the advantages and
        disadvantages of different approaches.

                o Using RFC 822/2822 headers would be the simplest
                  approach. However, headers have a length limit
                  and extending CRI to include digital signatures
                  and certificates would be problematic. Therefore,
                  RFC 822/2822 headers are not used except in
                  conjunction with MIME.

                o In [EMAIL-PATH] it is proposed to extend the message
                  tracking protocol defined by the MSGTRK WG for the
                  use of email path verification. However, since that
                  protocol is not currently being used, this approach
                  it not looked at. It is possible that future draft
                  of the CRI proposal may include this approach.

                o In [RFC-3464] a MIME format is defined for Delivery
                  Status Notifications (DSNs) that are intended to
                  notify the sender of a message of any of several
                  conditions: failed delivery, delayed delivery,
                  successful delivery, or the gatewaying of a message
                  into an environment that may not support DSNs. In our
                  case, C/R falls under delayed delivery. However, one
                  major issue that has been raised with using DSNs, is
                  that they are intended for one-way notification and
                  do no anticipate a response unlike C/R systems. Also,
                  current systems often handle DSNs in a specific way
                  and using CRI inside DSNs might break those
                  assumptions. Therefore we are not considering the use
                  of DSNs for CRI.

        The remaining two methods are the ones that are defined in this
        document for CRI use. They are MIME headers and an SMTP
        extension. The reason for defining the SMTP extension is in
        order to reduce the storage space required for email by
        allowing CRI exchange to occur at SMTP level. However, the main
        method for CRI is defined in MIME headers, with the ESMTP
        method for use in systems that want to reduce storage space.


3.1. Using MIME for CRI.

        This section discusses which MIME type and MIME headers will be
        used for CRI.

3.1.1. Using "multipart/report" MIME Type.

        [RFC-3462] defines a MIME type called multipart/report to be
        used for reporting of mail system administrative messages and
        as a general "family" or "container" type for electronic mail
        reports of any kind. This MIME type defines three parts for
        every multipart/report message as follows:

        1. First part provides a human readable message which is
        intended for humans only. In the CRI model, this would possibly
        contain the original message along with the instructions to the
        user for non-CRI compatible systems.  This instruction should
        include a brief explanation of C/R and a hyperlink or an
        instruction for an acknowledgement or reply.

        2. Second part provides a message to be used for CRI compatible
        machines with additional details for human beings. In the CRI
        model, this would contain the CRI MIME headers plus any
        additional information such as digital certificates,
        signatures, hashcash codes, etc.

        3. Third part contains either the entire original message or
        portions of it such as headers.

        There are several issues when using the multipart/report MIME
        type. First, not all email systems and clients handle this
        type. Second, it is intended for one way communications such
        as delivery failure notifications by the receiver's SMTP server
        and not necessarily intended for CRI. Third, if two C/R systems
        are communicating in regards to multiple users and messages,
        more than one machine readable part might be needed.


3.1.2. Defining a New "multipart/cri" MIME Type.

        Another alternative would be defining a custom MIME type called
        such as "multipart/cri" patterned after the "multipart/report"
        MIME type which would provide the same three parts. It should be
        defined as follows:

              MIME type name: multipart
              MIME subtype name: cri
              Required parameters: boundary
              Optional parameters: none
              Encoding considerations: 7bit should always be adequate
              Security considerations: see section 5 of this memo

        This MIME type would contain the following:
        1. (required) A single human readable body with C/R
           instructions.
        2. (required) Multiple machine-readable bodies (MIME type of
           message/cri).
        3. (optional) Multiple optional bodies containing the original
           messages (either message/rfc822 or text/rfc822)

        Multiple bodies are defined to allow C/R systems to communicate
        multiple challenges and responses in a single message.

        The following MIME type, message/cri, will be defined for
        carrying CRI information:

              MIME type name: message
              MIME subtype name: cri
              Optional parameters: none
              Encoding considerations: 7bit should always be adequate
              Security considerations: see section 5 of this memo

        NOTE: Since CRI may become part of a larger consent protocol,
              it may use the MIME type defined for such protocol. In
              that case, this section will be deprecated.


3.2. MIME Headers for CRI.

        This section will define various MIME headers that are used for
        CRI. We need to pass the following information:
                o Sender's  email address
                o Receiver's email address
                o Type of C/R message: challenge, response or
                  informational
                o C/R level desired:  1-sender, 2-message, or
                  3-turing test
                o Challenge and response tokens
                o Identification of the C/R systems
                o How much time does the sender have to respond to the
                  challenge
                o If responded, how long the address will stay in the
                  white list until challenged again
                o Extensions

        There are three different situations where headers are used:
                o By the sender with the main message headers to
                  indicate CRI parameters that can be used by the C/R
                  system for the challenge. The CRI MIME is not used.
                o By the C/R system in the challenge message with the
                  CRI MIME type
                o By the sender in the response message with the CRI
                  MIME type

        NOTE: Different token types may reference additional
              information that will be included in the body of
              the "message/cri" section.

        Additional extension headers maybe defined by using the
        "X-" headers as per [RFC-2822].


3.2.1. Headers in the Initial Message.

        CRI MIME Type is not used, the following required headers are
        passed:
        o CRI-Message-Type: normally maybe either "challenge",
          "response" or "informational", here MUST BE set to
           "informational".
        o CRI-Sender-Accept-Token: - lists types of token types the
          sender will accept

        The following optional headers are passed:
        o CRI-Sender-Agent: identifies the sender's C/R system
        o CRI-Sender-Exempt: identifies that the sender desires to not
          receive a CRI message. i.e. mailing list


3.2.2. Headers in the Challenge Message.

        The CRI MIME type IS used. There are two types of headers.
        Global headers are included as RFC 822/2822 headers with the
        main message headers. Sender specific headers are included
        inside the "message/cri" message body.

        The following headers are defined global for the entire C/R
        message and are required:
        o CRI-Reply-Until: how much time is given for response reply
        o CRI-Recipient-Accept-Token: lists types of tokens the
          recipient will accept

        The following global headers are optional:
        o CRI-Recipient-Agent: identifies the receiver's C/R system
        o CRI-Whitelist-Until: until when will the sender will stay on
          the whitelist for

        The following headers are specific per each sender and are
        required for each "message/cri" body:
        o CRI-Sender: the original sender of the original message,
          usually the RFC 822/2822 sender
        o CRI-Recipient: the original receiver of the message, usually
          the RFC 822/2822 receiver
        o CRI-Verification-Level: at the least must be "1" - sender,
          maybe also "2" - message, and  "3" - human
        o CRI-Message-Type: maybe either "challenge",  "response" or
          "informational", here set to either "challenge" or
           "informational".
        o CRI-Recipient-Accept-Type: lists types of tokens the
          recipient will accept
        o CRI-Token-Type: consists of token-type, same for ESMTP and
          MIME, see IANA section below
        o CRI-Token: - consists of the actual CRI token


3.2.3. Headers in the Response Message.

        The CRI MIME type is used. The following optional global
        headers are passed as part of the main message headers:
        o CRI-Sender-Agent: identifies the sender's C/R system

        The following headers are specific per each sender and are\
        required for each "message/cri" body:
        o CRI-Sender: the original sender of the original message,
          usually the RFC 822/2822 sender
        o CRI-Recipient: the original receiver of the message, usually
          the RFC 822/2822 receiver
        o CRI-Verification-Level: at the least must be "1" - sender,
          maybe also "2" - message, and  "3" - human
        o CRI-Message-Type: maybe either "challenge",  "response" or
          "informational", here set to either "response" or
          "informational".
        o CRI-Token-Type: consists of token-type, same for ESMTP and
          MIME, see IANA section below
        o CRI-Token: - consists of the actual CRI token


3.3. CRI ESMTP EXTENSION.

        SMTP Extensions are defined in [RFC-1869] and [RFC-2821]. The
        following service extension is hereby defined:
        1) The name of the CRI ESMTP extension is "CRI".
        2) The EHLO keyword value associated with this extension is
           "CRI".
        3) Several optional parameters are allows with this EHLO
           keyword value. The first parameter is the verification level
           supported and is defined as follows:

           cri-level = SENDER / MESSAGE / HUMAN SP

           If no verification level is specified, then SENDER level is
           assumed. This is followed by a list of CRI extensions
           supported by the receiver's system separated by spaces
           as follows:

           cri-ext = EXT SP EXT SP EXT SP ....  EXT = [ALPHA]

           If extensions are specified, then the level must be specified
           as well. Examples of extensions are digital signatures,
           hashcash, etc. An IANA registry will be established for
           registering CRI extensions. The CRI extension list is
           limited in line length in accordance with existing
           guidelines.
        4) There are not additional verbs associated with this
           extension
        5) New parameters are defined for the RCPT-TO and VRFY
           commands:

           CRI-TOKEN-TYPE=type; REQUIRED CRI-TOKEN=token; OPTIONAL
           For the DATA command: CRI-TOKEN-TYPE=type; OPTIONAL

           The CRI Token Type defines the token type, and the CRI token
           parameter carries the actual token. An IANA registry will be
           established for registering CRI extensions. Each token type
           will define whether it is carried in the CRI-TOKEN field or
           in the message body.

           One token is defined:
                Token Type:     plain
                Token field used: YES
        6) The following behavior changes are being made:
        a. For the RCPT TO command, a 452 error code is defined which
           indicates that a challenge is being issued.
        b. For the VRFY command, a requirement is added that it is
           issued after the MAIL FROM command when used in CRI.
        c. For the VRFY command, after challenge is issued and
           successfully accepted, the QUIT command is used to end the
           SMTP session.
        d. For the VRFY command, the DATA command is used for transfer
           of very large tokens inside the message body.


3.4. Examples of CRI.

        This section has some examples of how CRI would be used. They
are for illustration purposes only.

3.4.1. MIME Example.

Sample CRI message from sender to the recipient with
both systems supporting CRI:
....
From: research@solidmatrix.com
To: asrg@irtf.org
Subject: test message
CRI-Message-Type: informational
CRI-Sender-Accept-Token: plain
CRI-Sender-Agent: CRI Tester 0.1
......


Sample CRI challenge message:
.....
From: challenger@irtf.org
To: research@solidmatrix.com
Subject: Challenge message
CRI-Reply-Until: Mon, 22 Sep 2003 15:16:26 -0400
CRI-Recipient-Accept-Token: plain
CRI-Recipient-Agent: CRI Tester 0.1
CRI-Whitelist-Until: Mon, 22 Sep 2003 15:16:26 -0400
Content-Type: multipart/cri; boundary="opopo54545/irtf.org"

--opopo54545/irtf.org

This is a challenge message. To verify, please go here:

www.irtf.org/asrg/verify/

--opopo54545/irtf.org
Content-Type: message/cri
CRI-Sender: research@solidmatrix.com
CRI-Recipient: asrg@irtf.org
CRI-Verification-Level: 1
CRI-Message-Type: challenge
CRI-Recipient-Accept-Type: plain
CRI-Token-Type: plain
CRI-Token: this is a challenge token

--opopo54545/irtf.org
....


Sample CRI response message:
.....
From: research@solidmatrix.com
To: challenger@irtf.org
Subject: Re: Challenge message
CRI-Sender-Agent: CRI Tester 0.1
Content-Type: multipart/cri; boundary="opopo54545/solidmatrix.com"

--opopo54545/irtf.org

This is a response message. The C/R token is: this is a challenge token

--opopo54545/solidmatrix.com
Content-Type: message/cri
CRI-Sender: research@solidmatrix.com
CRI-Recipient: asrg@irtf.org
CRI-Verification-Level: 1
CRI-Message-Type: response
CRI-Token-Type: plain
CRI-Token: this is a challenge token

--opopo54545/solidmatrix.com
.....


3.4.2. CRI ESMTP Examples.

Sample CRI ESMTP conversation from sender to the recipient with
both systems supporting CRI:
S: <wait for connection on TCP port 25>
C: <open connection to server>
S: 220 mail.ietf.org -- Welcome
C: EHLO solidmatrix.com
S: 250-mail.ietf.org
S: 250-HELP
S: 250 CRI SENDER PKI HASHCASH
C: MAIL FROM:<research@solidmatrix.com>
S: 250 OK.
C: RCPT TO:<asrg@irtf.org>
S: 250 asrg@irtf.org OK
C: RCPT TO: <someone@irtf.org>
S: 452 Unverified sender, issuing challenge, retry with CRI
token
.....
.....recipient connects to sender's MTA and issues challenge
.....
S: RCPT TO: <someone@irtf.org> CRI-TOKEN-TYPE=plain;
CRI-TOKEN=token;
C: 250 Sender approved for <someone@irtf.org>
C: DATA
S: 354 Send message, ending in CRLF.CRLF.
 ...
C: .
S: 250 OK
C: QUIT
S: 221 Goodbye

Recipient's MTA issuing a challenge with both systems supporting
CRI:
S: <wait for connection on TCP port 25>
C: <open connection to server>
S: 220 mail.solidmatrix.com -- Welcome
C: EHLO mail.irtf.org
S: 250-mail.solidmatrix.com
S: 250-HELP
S: 250 CRI SENDER PKI HASHCASH
C: MAIL FROM:<someone@irtf.org>
S: 250 OK.
C: VRFY:<research@solidmatrix.com> CRI-TOKEN-TYPE=plain;
CRI-TOKEN: token;
S: 250 CRI challenge accepted for <research@solidmatrix.com> OK
C: VRFY:<someone@solidmatrix.com> CRI-TOKEN-TYPE=plain;
CRI-TOKEN: token;
S: 550 Mailbox not found
C: QUIT
S: 221 Goodbye

Recipient's MTA issuing a challenge with both systems supporting
CRI and token carried in message body:
S: <wait for connection on TCP port 25>
C: <open connection to server>
S: 220 mail.solidmatrix.com -- Welcome
C: EHLO mail.irtf.org
S: 250-mail.solidmatrix.com
S: 250-HELP
S: 250 CRI SENDER PKI HASHCASH
C: MAIL FROM:<someone@irtf.org>
S: 250 OK.
C: VRFY:<research@solidmatrix.com> CRI-TOKEN-TYPE=big;
S: 250 CRI challenge accepted for <research@solidmatrix.com> OK
C: DATA CRI-TOKEN-TYPE=big;
S: Send data followed by Ÿ.÷
C: ... data ...
S: 250 Challenge token accepted for <research@solidmatrix.com>
C: QUIT
S: 221 Goodbye

Recipient's MTA issuing a challenge with sender's system not
supporting CRI:
S: <wait for connection on TCP port 25>
C: <open connection to server>
S: 220 mail.solidmatrix.com -- Welcome
C: EHLO mail.irtf.org
S: 250-mail.solidmatrix.com
S: 250-HELP
C: MAIL FROM:<someone@irtf.org>
S: 250 OK.
C: RCPT TO: <research@solidmatrix.com>
S: 250 OK
C: DATA
S: 354 Send mail data followed by CRLF
C: ...sends email challenge message ...
S: 250 Message accepted for delivery
C: QUIT
S: 221 Goodbye

. Interoperability Considerations.

4.1. Loop Avoidance.

        CRI systems should not issue challenge messages when C/R
        headers are present.  CRI systems should not challenge
        messages with CRI-Message-Type: response or challenge.
        In order to maintain compatibility with non-CRI systems, it is
        recommended that each CRI system maintain stateful monitoring
        of challenge messages sent to original senders.  For CRI
        systems that issue challenge messages, it is also recommended
        that each CRI system use a local systemwide user, such as
        cri@foo.com, for issuing challenges rather than preserving
        the original sender's email address as the sender of the
        challenge message.  Doing so, allows for loop avoidance to
        be handled using double-bounce methods where appropriate.
        For client-based CRI software, loop avoidance may be handled
        using additional stateful means of tracking outgoing mail.

4.2. Mailing Lists.

        Mailing lists may include CRI-Sender-Exempt headers to indicate
        that challenge messages should not be posted to the mailing
        list. Most mailing lists supply various headers to indicate
        that the messages has been sent from a mailing list. Such
        mailing list detection methods should result in suppressed
        challenge messages.



. SECURITY CONSIDERATIONS.

        CRI is not an authentication method for email delivery or
        security protocol. However, since certain methods of CRI may
        allow for address harvesting, care must be taken when CRI is
        used.




. PRIVACY CONSIDERATIONS.

        Since C/R systems keep track of the senders email addresses,
        this raises privacy issues. In systems that use C/R level 2,
        copies of messages may be stored as well. Use of cryptography
        and checksums is encouraged.




. IANA CONSIDERATIONS.

        One IANA registry will be established for registering CRI token
        types. All additions to this registry require IESG approval. The
        following token type is defined in this note in the registry:
        o Token Type: plain
        o ESMTP Field use: Yes
        o Description: plain text token
        o Syntax: plain text [ALPHA]
        o Additional Information: this is a plain text token which
          needs to be returned as is in the response message

        The following application should be used when applying for a new
        CRI token type (send to <iana@iana.org>):
        o Proposed token type name
        o Whether the token is passed via the ESMTP CRI extension
        o Token syntax
        o Token description
        o Any additional information that is needed to process this token
          by a C/R system

        A second IANA registry will be define for registering ESMTP CRI
        extensions. All additions will require IESG approval. The
        following application should be used when applying for a new
        CRI ESMTP extension (send to <iana@iana.org>):
        o Proposed extension name
        o Information as to how this extension works
        o Whether and how this extension changes the CRI protocol



. ADDITIONAL INFORMATION.
8.1. References.
8.1.1. Normative References.

[RFC-821]  Postel, J.; "Simple Mail Transfer Protocol"; STD 10,
           RFC 821; ISI/USC; August 1982

[RFC-822]  Crocker, D.; "Standard For The Format Of ARPA Internet
           Text Messages"; STD 11, RFC 822; University of Delaware;
           August, 1982

[RFC-1049] Sirbu, M.; "Content-Type Header Field for Internet
           Messages"; STD 11, RFC 1049; CMU; March 1988.

[RFC-1869] Klensin, J., Freed, N., Rose, M., Stefferud, E. and
           Crocker, D.; "SMTP Service Extensions"; RFC 1869; MCI,
           Innosoft, Dover Beach Consulting, Network Management
           Associates, Brandenburg Consulting; November 1995

[RFC-2045] Borenstein, N., and Freed, N.; "Multipurpose Internet Mail
           Extensions (MIME) Part One: Format of Internet Message
           Bodies"; RFC 1341; Innosoft, First Virtual; Nov 1996.

[RFC-2821] Klensin, J.; "Simple Mail Transfer Protocol"; RFC 2821;
           AT&T Laboratories; April, 2001.

[RFC-2822] Resnick, P.; "Internet Message Format"; RFC 2822;
           QUALCOMM Incorporated; April 2001.


8.1.2. Informative References.
[CHARTER]  "Anti-Spam Research Group (ASRG) Charter",
           [http://www.irtf.org/charters/asrg.html], March 2003

[CONSENT]  Shafranovich, Y,; "Consent Framework for Fighting Spam",
           SolidMatrix Technologies, Inc.; Version 0.0.2, July, 2003
[http://www.solidmatrix.com/research/asrg/asrg-consent-framework.html]

[EMAIL-PATH] Leibzon, W.; "Email Path Verification", March 2003
[http://www.elan.net/~william/asrg-emailpathverification-presentation.pdf]

[IPR]      Shafranovich, Y.; "Intellectual Property Rights in
           Anti-Spam Technologies", SolidMatrix Technologies, Inc.;
           July 2003
[http://www.solidmatrix.com/research/asrg/asrg-ipr.html]

[RFC-3462] Vaudreuil, G; "The Multipart/Report Content Type for the
           Reporting of Mail System Administrative Messages";
           Lucent Technologies; January 2003

[RFC-3464] Moore, K. and Vaudreuil, G; "An Extensible Message Format
           for Delivery Status Notifications"; University of
           Tennessee, Lucent Technologies; January 2003


8.2. Acknowledgements.

     A lot of information in this note has been based on the
     discussions on the Anti-Spam Research Group (ASRG) mailing
     list. The authors would like to acknowledge the contributions
     of all members of the group.


8.3. IPR Information.

A list of IPR disclosures and related information may be found
in [IPR]. The following IPR information is relevant to this document:

        o In June of 2003 MailBlocks, Inc. disclosed to the ASRG that
          they may be in possession of IPR applicable to C/R systems.
          These constitute US Patents # 6,199,102 and # 6,112,227.
          MailBlocks, Inc. has stated that a licensing declaration
          will be provided later on.
        o In June of 2003, TitanKey, Inc. disclosed to the ASRG that
          they may be in possession of IPR applicable to the CRI SMTP
          extension. These constitute multiple US and international
          patent applications. TitanKey, Inc. has stated that
          a licensing declaration will be provided later on.

8.4. Author(s) Addresses.

     Eric Dean
     Crystal Ball Inc.
     eric@crystalballinc.com

     Yakov Shafranovich
     SolidMatrix Technologies, Inc.
     research@solidmatrix.com
     www.shaftek.org




8.5. 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.



8.6. Document History.

v0.0.3 / YS / 07-23-2003 / Some editing and cleanup
v0.0.4 / YS / 09-22-2003 / Re-did the document, re-formatted, removed DSN
       section, expanded on IANA, security and privacy sections, added
       more references, added a section on consent, expanded the levels
       section, added a section on different approaches, section on MIME
       is expanded and required/optional parameters are added,
       renumbered sections, added IPR notices for MailBlocks and
       TitanKey