Re: [Asrg] C/R Interworking Framework

Yakov Shafranovich <> Sun, 25 May 2003 04:53 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id AAA12047 for <>; Sun, 25 May 2003 00:53:14 -0400 (EDT)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id h4P4r7223119 for; Sun, 25 May 2003 00:53:07 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h4P4r7B23116 for <>; Sun, 25 May 2003 00:53:07 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id AAA12043; Sun, 25 May 2003 00:52:43 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19JnTZ-0003kU-00; Sun, 25 May 2003 00:51:17 -0400
Received: from ([] by ietf-mx with esmtp (Exim 4.12) id 19JnTY-0003kR-00; Sun, 25 May 2003 00:51:16 -0400
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h4P4g6B22917; Sun, 25 May 2003 00:42:06 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h4P4fLB22891 for <>; Sun, 25 May 2003 00:41:21 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id AAA11950 for <>; Sun, 25 May 2003 00:40:58 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19JnIB-0003jC-00 for; Sun, 25 May 2003 00:39:31 -0400
Received: from ([] helo= by ietf-mx with smtp (Exim 4.12) id 19JnI9-0003j9-00 for; Sun, 25 May 2003 00:39:30 -0400
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
To: Eric Dean <>,
From: Yakov Shafranovich <>
Subject: Re: [Asrg] C/R Interworking 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: Sun, 25 May 2003 00:40:38 -0400

At 01:13 PM 5/19/2003 -0400, Eric Dean wrote:

>Ok, this is still a framework document..not to be considered a proposed
>draft...just a tumbleweed.  If this initiative progresses, then I'll format
>it and discuss with the chair about proposing it as a draft.  Until then,
>it's intentionally left in it's current unambiguous form.
>The scope keeps narrowing down from a C/R system model to a C/R system
>interworking model.  I'm happy with that.  In fact, I believe there is still
>more fat to trim..but we'll get there.  In the spirit of Kee Hinckley's
>signature quote, less is more.
>I am not interested in placing restrictions on C/R systems...I am interested
>in having them interoperate..and even more so in having them interoperate
>automatically. If vendors can't find smart ways to implement systems using
>the guidelines we propose then they won't be vendors for long.
>There were some questions about the size of recipient email addresses:
>RFC2821 says 64 char for username, 256 char for domain and 512 for the
>command line is 512 chars..though MIME doesn't have such
>restrictions..except 1000 chars for line...regardless..there isn't a

 >This document identifies MIME experimental content-type values for 
allowing automated C/R system interworking.

Aren't we using headers?

 >The following MIME experimental content-type values are required for C/R 
 >X-CM:'Recipient','Response String'
 >The X-CM values are defined as follows:
 >Recipient: Identifies the original recipient of the message that is 
issuing the challenge message.
 >Response String: Identifies an authentication string unique to that 
sender-recipient pair that ensures the challenge response is from >the 
original sender.

Is there room in the specifications for the following:
1. Tag or certification systems which will send their seal or certificate 
as a response.
2. Economic systems which will use the cryptographics or some other methods 
like hashcash to add costs to email.

 >Loop avoidance
 >C/R systems should not issue challenge messages when C/R headers are 
present.  In order to maintain compatibility with non-C/R >interworking 
systems, it is recommended that each C/R system remain stateful in 
monitoring challenge message sent to original >senders.  For C/R systems 
that issue challenge messages, it is also recommended that each C/R system 
use a local user 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 standard 
double-bounce methods where appropriate.  For client-based C/R software, 
loop >avoidance may be handled using additonal stateful means of tracking 
outgoing mail.

What will stop a spammer from putting X-CM headers into the message and 
what happens in that case - is there message let through or the C/R system 
responds to it, thus validating the receiver's email?


Yakov Shafranovich / <>
SolidMatrix Research, a division of SolidMatrix Technologies, Inc.
"One who watches the wind will never sow, and one who keeps his eyes on
the clouds will never reap" (Ecclesiastes 11:4)

Asrg mailing list