Re: [Asrg] C/R Interworking Framework

[Yakov Shafranovich <[e-mail]>]

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 / <[e-mail]>
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
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg