Re: [Asrg] C/R Interworking Framework

Yakov Shafranovich <research@solidmatrix.com> Sun, 25 May 2003 04:53 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12047 for <asrg-archive@odin.ietf.org>; Sun, 25 May 2003 00:53:14 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4P4r7223119 for asrg-archive@odin.ietf.org; Sun, 25 May 2003 00:53:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4P4r7B23116 for <asrg-web-archive@optimus.ietf.org>; Sun, 25 May 2003 00:53:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12043; Sun, 25 May 2003 00:52:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JnTZ-0003kU-00; Sun, 25 May 2003 00:51:17 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19JnTY-0003kR-00; Sun, 25 May 2003 00:51:16 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4P4g6B22917; Sun, 25 May 2003 00:42:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4P4fLB22891 for <asrg@optimus.ietf.org>; Sun, 25 May 2003 00:41:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11950 for <asrg@ietf.org>; Sun, 25 May 2003 00:40:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JnIB-0003jC-00 for asrg@ietf.org; Sun, 25 May 2003 00:39:31 -0400
Received: from 000-248-924.area7.spcsdns.net ([68.27.212.5] helo=68.27.212.5) by ietf-mx with smtp (Exim 4.12) id 19JnI9-0003j9-00 for asrg@ietf.org; Sun, 25 May 2003 00:39:30 -0400
Message-Id: <5.2.0.9.2.20030525003321.00b58828@std5.imagineis.com>
X-Sender: research@solidmatrix.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
To: Eric Dean <eric@purespeed.com>, asrg@ietf.org
From: Yakov Shafranovich <research@solidmatrix.com>
Subject: Re: [Asrg] C/R Interworking Framework
In-Reply-To: <MBEKIIAKLDHKMLNFJODBKEMBFDAA.eric@purespeed.com>
References: <5.2.0.9.2.20030515115340.00bafae8@std5.imagineis.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-MimeHeaders-Plugin-Info: v2.03.00
X-GCMulti: 1
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/asrg/>
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
>problem..
>
>-Eric

 >[...]
 >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 
interworking:
 >
 >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

---------------------------------------------------------------------------------------------------
Yakov Shafranovich / <research@solidmatrix.com>
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
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg