Draft-irtf-asrg-cr-**.txt 					Authors: Eric Dean et.al

Abstract
RFC821 was designed simply deliver email messages but not to authenticate sources or senders of email messages.  In an effort to reduce sources of spam on the Internet, this document defines a Challenge Response "C/R" method for authenticating email senders and determining if the sender originated a message to a designated recipient.  This document proposes the use of MIME experimental content-type values for automated C/R control at either the server or client software level.  In addition, this document proposes a C/R method that requires user manual intervention with existing mail systems and clients that may not be compatible with automated C/R methods.

Introduction
Challenge Response systems intend to authenticate a sender's identity and determine if a sender originated a message to a particular recipient.  This document identifies MIME experimental content-type values that may be sent with a message for automating C/R.  In addition, this document proposes a manual user intervention C/R model.  A C/R system may be used to determine whether a sender actually is a valid email address and whether that sender originally sent a message to a designated recipient.  A C/R email system or client software supporting the C/R MIME experimental content-type values would have the option of automatically responding to a challenge message or forwarding the challenge message to the original sender for further action.  This document identifies the C/R MIME experimental content-type values for possible automated C/R systems as well as provides guidelines for a user manual intervention C/R method.

Purposes
-Used to dynamically build user whitelists.  In some implementations, the C/R system is used to determine is a sender is real and allow for that sender to verify that he intended to send a message to the recipient.  Upon responding to the challenge, the sender will then get added to the user's personal whitelist.
-Reduce spam from spoofed senders.  In the event that a challenge message is without an response for an extended period of time, 
-Reduce spam from invalid senders.  In the event that a challenge message rejects or bounces via one or more SMTP errors, some C/R implementations will automatically drop the message.
-Not an authentication method for email delivery or security protocol

Challenge Response Model
The C/R model is based upon an approach whereby a sender sends a message to a recipient's SMTP server.  The recipient's SMTP server either produces a challenge message or forwards the original message to a recipient's client system that produces a challenge message.  The resulting challenge message is sent to the original sender.  If the sender's C/R SMTP server supports C/R methods, then the original sender's SMTP server may automatically respond to the challenge request.  Otherwise, the original sender's server should forward the message to the original sender.  If the original sender's client system supports C/R methods, then the original sender's client software may automatically respond to the challenge message.  In the event that neither the server nor client software are C/R compatible, the C/R message should contain clear instructions to the original sender instructing how to appropriately respond to the challenge request.


-------------------------------------------------------------


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

                Sender-SMTP                Receiver-SMTP

                           Model for C/R Use

                                Figure 1

     -------------------------------------------------------------


Challenge Message
The Challenge Message should contain both the MIME experimental content-type values defined herein.  The following MIME experimental content-type values are required for C/R interoperability:
X-CM-Recipient: This C/R header should identify the original recipient of the message that is issuing the challenge.
X-CM-URI: This C/R header identifies an authentication string unique to that sender-recipient pair that ensures that the challenge response is from the original sender.

If an original sender sends to multiple recipients on the same C/R server, then the server can issue the challenge message with a pair of each X-CM-Recipient listed with corresponding X-CM-URI:. Multiple recipient<->URI pairs can be included in a single challenge message.

The sender of the C/R message must be a valid sender address.  In the event that a server-based mail system is performing C/R, then the challenge should be sent with an email address local to that server.  If multiple servers are used, then the challenge message can be forwarded to peer servers if other synchronization mechanisms are not in place.  

If client software is performing the C/R, then the challenge should be sent with an email address local to that email client.  If neither the original sender's server or client software support C/R interoperability, then the challenge message should contain as well as a message that clearly instructs the user how to perform a manual challenge response.  Typically, clicking on an embedded HREF or a simple reply-to is sufficient for the original sender to manually reply.

Challenge Response
For C/R compatible systems that support the MIME experimental content-type values, the challenge response mechanism could be automated.  The following MIME experimental content-type values are required for C/R interoperability:

X-CR-URI: V='X-CM-URI'  This C/R header is sent to the originating C/R system to validate that the original sender had sent a message to the X-CM-Recipient.  The X-CM-URI authentication string that was supplied with the challenge message is sent along with a key "V=" to signify that the original sender is intending on delivering a message to the recipient.
X-CR-URI: I='X-CM-URI'  This C/R header is sent to the originating C/R system to invalidate that the original sender had not sent a message to the X-CM-Recipient.  The X-CM-URI authentication string that was supplied with the challenge message is sent along with a key "I=" to signify that the original sender did not intend to deliver a message to the recipient.

Multiple X-CR-URI headers can be sent in a single challenge response.

Mail Lists
Proper identification and handling of user subscribed mailing lists is essential for C/R deployment.  While no standard exists for identifying lists, many common methods include using the following headers:

"sender:",
"X-BeenThere:",
"mailing-list:",
"list-help:",
"list-unsubscribe:",
"precedence: bulk",
"precedence: list",

Challenge messages should not be sent to mailing lists.  Precise methods of detecting mailing lists are to follow.

Loop avoidance
C/R systems should use a local address on the C/R system or an actual email address within client software.  In either case, the C/R system should remain stateful in monitoring outstanding Challenge Messages and should not continue issuing challenge messages when an existing request is outstanding.  Additional methods used for double-bounces and vacation responders would also be appropriate.

Security
The URI length should be long enough using a significant code base to prevent brute force attacks.

Privacy
Concerns exist regarding data collection of correspondences between certain senders and recipients however such information is available in most mailing systems

References

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

   [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
   Messages", STD 11, RFC 822, UDEL, August 1982.

   [RFC-934] Rose, M., and E. Stefferud, "Proposed Standard for Message
   Encapsulation", RFC 934, Delaware and NMA, January 1985.

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

   [RFC-1341] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet
   Mail Extensions): Mechanisms for Specifying and Describing the Format
   of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, June 1992.


   [RFC-1344] Borenstein, N., "Implications of MIME for Internet
   Mail Gateways", RFC 1344, Bellcore, June 1992.

Contact