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. . . . . . . . . . . . . . . . . . . 1. 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 . 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 2. 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. 3. 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: C: 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: S: 250 OK. C: RCPT TO: S: 250 asrg@irtf.org OK C: RCPT TO: S: 452 Unverified sender, issuing challenge, retry with CRI token ..... .....recipient connects to sender's MTA and issues challenge ..... S: RCPT TO: CRI-TOKEN-TYPE=plain; CRI-TOKEN=token; C: 250 Sender approved for 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: C: 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: S: 250 OK. C: VRFY: CRI-TOKEN-TYPE=plain; CRI-TOKEN: token; S: 250 CRI challenge accepted for OK C: VRFY: 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: C: 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: S: 250 OK. C: VRFY: CRI-TOKEN-TYPE=big; S: 250 CRI challenge accepted for OK C: DATA CRI-TOKEN-TYPE=big; S: Send data followed by Ÿ.÷ C: ... data ... S: 250 Challenge token accepted for C: QUIT S: 221 Goodbye Recipient's MTA issuing a challenge with sender's system not supporting CRI: S: C: S: 220 mail.solidmatrix.com -- Welcome C: EHLO mail.irtf.org S: 250-mail.solidmatrix.com S: 250-HELP C: MAIL FROM: S: 250 OK. C: RCPT TO: 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 4. 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. 5. 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. 6. 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. 7. 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 ): 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 ): o Proposed extension name o Information as to how this extension works o Whether and how this extension changes the CRI protocol 8. 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