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(_at_)solidmatrix(_dot_)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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg