Re: [Asrg] C/R Framework

Yakov Shafranovich <> Thu, 15 May 2003 15:52 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id LAA13027 for <>; Thu, 15 May 2003 11:52:24 -0400 (EDT)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id h4FFJSx09929 for; Thu, 15 May 2003 11:19:28 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h4FFJSB09926 for <>; Thu, 15 May 2003 11:19:28 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id LAA13013; Thu, 15 May 2003 11:51:53 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19GL3E-0000HY-00; Thu, 15 May 2003 11:53:48 -0400
Received: from ([] by ietf-mx with esmtp (Exim 4.12) id 19GL3D-0000HV-00; Thu, 15 May 2003 11:53:47 -0400
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h4FFF4B09686; Thu, 15 May 2003 11:15:04 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h4FFERB09644 for <>; Thu, 15 May 2003 11:14:27 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id LAA12901 for <>; Thu, 15 May 2003 11:46:53 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19GKyN-0000Fe-00 for; Thu, 15 May 2003 11:48:47 -0400
Received: from ([] helo= ident=trilluser) by ietf-mx with smtp (Exim 4.12) id 19GKyG-0000FY-00 for; Thu, 15 May 2003 11:48:41 -0400
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
From: Yakov Shafranovich <>
Subject: Re: [Asrg] C/R Framework
In-Reply-To: <>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-MimeHeaders-Plugin-Info: v2.03.00
X-GCMulti: 1
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
List-Archive: <>
Date: Thu, 15 May 2003 11:49:33 -0400

At 10:23 PM 5/14/2003 -0400, Eric Dean wrote:

>Attached, you'll find a proposed framework I have put together for a C/R
>discussion.  Please excuse the formating..I'll groff it soon..assuming it
>I have attempted to capture some of the key areas and concerns that have
>been discussed over the past couple of weeks as well as incorporate some of
>my own ideas.  My intent is to throw something down on the table that's at
>least wrong and allow for an exchange of ideas regarding how to proceed if
>at all.

Below is a copy of some of the comments on this proposal that I previously 
emailed to Eric. He agreed that they should be posted to the entire list.


>RFC821 was not designed to authenticate sources or senders of email 
>messages.  In an effort to reduce spam on the Internet, this document 
>defines a method by which email senders may be authenticated and 
>determined if that sender originated a message to a designated recipient.

In the purposes section, we state that this is "-Not an authentication 
method for email delivery or security protocol". Is our intent to make sure 
that the sender's email address is valid but not to authenticate the actual 
identity of the sender? I am not readily understanding the different 
between this statement and the conflicting statement in the purposes 
section. Is making sure that the original sender exists called 
"authentication" or perhaps a different term should be used?

Also, I came across an interesting quote in section 7.1 of RFC 2821:

    "Efforts to make it more difficult for users to set envelope return
    path and header "From" fields to point to valid addresses other than
    their own are largely misguided: they frustrate legitimate
    applications in which mail is sent by one user on behalf of another
    or in which error (or normal) replies should be directed to a special
    address.  (Systems that provide convenient ways for users to alter
    these fields on a per-message basis should attempt to establish a
    primary and permanent mailbox address for the user so that Sender
    fields within the message data can be generated sensibly.)
    This specification does not further address the authentication issues
    associated with SMTP other than to advocate that useful functionality
    not be disabled in the hope of providing some small margin of
    protection against an ignorant user who is trying to fake mail."

>   This document proposes the use of MIME experimental content-type values 
> for automated C/R control.

We need to define more precisely exactly which header we are using. We ARE 
NOT using the "Message-Context" defined in RFC3458 since that is 
presentation logic, and not the "Content Disposition" header either (RFC 
2183) for the same reason. So are we using the "Content-Type:" header 
defined in RFC 2045? If so should we be suggesting a custom type starting 
with "X-" or should we specify a new type: probably something like 
"message/challenge" (see for current 
assignments in the "message" category)? The "message" type is defined in 
RFC 2046.

In general the purpose of MIME as outline in RFC 2045 is:

"This set of documents, collectively called the Multipurpose Internet Mail 
Extensions, or MIME, redefines the format of messages to allow for
     (1)   textual message bodies in character sets other than US-ASCII,
     (2)   an extensible set of different formats for non-textual message 
     (3)   multi-part message bodies, and
     (4)   textual header information in character sets other than US-ASCII."

All of these do not apply in our case, all of our information is stored in 
headers only (for the automatic protocol, the manual protocol includes 
links in the message body. Headers are defined in sections 2.1 and 2.2 of 
RFC 2822 and we must decide if we are going to define standard headers or 
extension headers ("CM: or X-CM"). If we are using custom headers, then 
reference to sections 4.7.4 and 4.7.5 of RFC 822 should be made.

>   In addition, this document proposes a manual C/R method that interworks 
> with existing mail systems and clients.

Its more like guidelines then a method. We cannot enforce implementation 

>This document identifies a MIME experimental content-type that may be used 
>by a message as well as a user interaction method for authenticating 
>sender identity and determining whether a sender originated a message to a 

Same as above - we need to define more precisely - are we using a MIME 
type, custom headers, etc. And we are not giving a method, just suggesting 
some guidelines. Do we authenticate or determine sender - we need a better 
definition here.

>   A Challenge/Response system can be used to determine whether a sender 
> exists and whether that sender intended to send a message to a designated 
> recipient.

We need a more clear view - there are two things being defined in this 
document - one is an automated protocol for machines and two - a set of 
guidelines for manual systems. An automated protocol will only allow 
machines to check is the sender exists, whether he wanted to send a message 
or not, is not really for us to decide unless you intend on using the 
"X-CM-Recipient:" header field for that purpose. However in that case the 
sender's system would have to keep track of all the people he sent mail to 
and then check that against the "X-CM-Recipient:" field in the challenged. 
I do not know if this should part of the protocol - may be more of an 
optional feature.

>  A C/R system or client software supporting the C/R MIME experimental 
> content-type values would have the option of automatically responding to 
> the challenge message or forwarding to the original sender to perform the 
> action.

What does "forwarding" to original sender mean? That only applies to the 
case of an MTA doing handling the C/R, not the user client. We need to make 
this paragraph more clear - a system or MTA would have such option, the 
client software would either responde automatically or do nothing.

>  This document identifies the C/R MIME experimental content-type values 
> for possible automated C/R systems as well as provides guidelines for a 
> manual user C/R method.

Good, we probably should split the document into two parts -one to 
automatic protocol and second for manual guidelines.

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

Again - sender being real and sender sending the message are different 
goals. We need to make that more clear. And also, "some implementations"? I 
am not getting that - aren't we defining guidelines for all implementation. 
Rather we should list required features and optional features of the protocol.

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

We should move the implementation details from the purposes section - 
things like "what C/R system does in case A", are not a purpose - they are 
the solution.

>-Not an authentication method for email delivery or security protocol

As mentioned above, we need to clarify this.

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

Perhaps we should check if the original's sender's domain actually exists, 
before sending the message? Also, if that happens do we drop the message 

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

This line bothers me - restricting to SMTP. Who will implement 
challenge/response - the incoming SMTP server or system that is actually 
storing the mail? The incoming SMTP server might not possess a list of all 
the recipients and may not be able to automatically decide if the " 
X-CM-Recipient" matches someone that the sender sent mail to (if we are 
doing that).

>   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 describing how to appropriately 
> respond to the challenge request.


>        ----------------------------------------
>        |                                       |
>        |                                       v
>        v       +----------+                +----------+
>    +------+    |          |                |          |    +------+
>    | User |<-->|          |       C/R      |          |<-->| User |
>    +------+    |  Sender- |Commands/Replies| Receiver-|    +------+
>    +------+    |SMTP/HTTP |<-------------->|SMTP/HTTP |    +------+
>    |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.

What format, is this in a standard email address format? Then the relevant 
section of RFC 822 or 2822 should be referenced here.

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

What format? Is this simply a URI? or some kind of code? Or implementation 
specific? Should we be naming it "URI" if it is not.

>If an original sender sends to multiple recipients on the same C/R server, 
>then the server can issue the challenge message with each X-CM-Recipient 
>listed with corresponding URIs.
>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.

The reply-to ability MUST BE present - not everyone who has email, 
necessarily has HTTP. Also, for the same reason, the challenge message 
should not be MIME encoded, or in some form of HTML format - just simple text.

As someone mentioned on the mailing list, there should be an email address 
of the recipient's administrator included just in case. That address SHOULD 
NOT issue challenges. Perhaps we also need a custom header or use a 
standard one defined somewhere like "Errors-To" for this.

>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 
>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: U=X-CM-URI  This C/R header is sent to the originating C/R 
>system to invalidate 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 "U=" to signify that the 
>original sender did not intend to deliver a message to the recipient.

What's V and U stand for? We need to rethink this a bit - maybe we should 
have "X-CR-Challenge" and "X-CR-Response" fields? The sender will add the 
response field. Should there be a standard token format? What about 
possible support for hashcash type systems via these tokens?

>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:
>"precedence: bulk",
>"precedence: list",

More research into this is needed, I think some RFCs provide guidelines on 

>Challenge messages should not be sent to mailing lists.

Why not? If we have an automated protocol and the mailing list supports 
C/R, then it should be able to detect the incoming challenge. This is not 
so simple, we need more work on this.

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

Perhaps using "X-Been-There" header or something like that. This is also 
interesting - section 6.2 of RFC 2821:

"6.2 Loop Detection.

    Simple counting of the number of "Received:" headers in a message has
    proven to be an effective, although rarely optimal, method of
    detecting loops in mail systems.  SMTP servers using this technique
    SHOULD use a large rejection threshold, normally at least 100
    Received entries.  Whatever mechanisms are used, servers MUST contain
    provisions for detecting and stopping trivial loops."

>URI length to prevent brute force attacks

Also how to prevent spammers from spoofing an address on the white list. If 
the sender checks the "X-CR-Receipient" field against the list of people he 
sent email to, that might be avoided.

>-Data Collection

There are plenty of messages on that in the list. Legal issues must be left 
aside, although we may mention them. Like I mentioned perhaps some form of 
a checksum should be used, to avoid storing real email addresses in the 
database. Also, perhaps the "X-CR-Recipient" header above should be a 
checksum (MD5?) instead of the real email address.

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

These were supplemented by RFCs 2821 and 2822.

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

What are we getting from RFC-934 or is this is here just in case for the 

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

These was obsoleted by RFC 1521, which in turn was obsoleted by RFC 2045 
which I think is current. We should probably reference the most recent one. 
Also take a look at the whole MIME series of RFCs: 2045 through 2049 (2047 
is not relevant to us, it deals with non-ASCII text,

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

Asrg mailing list