At 11:43 PM 5/30/2003 -0400, Eric Dean wrote:
Let's look at this:
a) I am a sender with a CRI system and send a message to a recipient with a
CRI system. My CRI system remembers I sent a message to a particular
recipient.
b) The recipient receives my message and holds it. The recipient sends me a
challange message with CRI headers.
If we were using some form of SMTP-model, then the recipient would not
actually accept the message. Instead his system would issue some form of
SMTP error code back, something like "450 Need to verify sender". This will
force the sender's system to hold on to the message until the C/R process
runs its gamut.
c) My system responds to the challenge message using CRI headers.
The sender's system will respond to the header and reattempt delivery.
d) The message is released and sent to the recipient.
I'm not sure how SMTP headers would benefit us over RFC822 X- headers. The
message still has to be temporarily stored by the C/R system. In addition,
we do not find that our C/R system cache gets overly large. We drop a lot
of spam just by having the challenge bounce.
The only difference in the SMTP system would be that the burden of storing
the message would be on the sender's system instead of receiver's which
might have practical advantages.
However, another possibility is that the actual negotiation would take
place via SMTP via an ESMTP extension, as follows:
A. Sender tries to deliver the message to the recipient. A "3xx" code is
issued by the receiver's system which according to RFC 2821 is defined as:
"The command has been accepted, but the requested action is being held in
abeyance, pending receipt of further information."
This would make the sender's system wait until the C/R process is being
done. Usually that will not take that long.
B. The receiver's system initiates an SMTP transaction to the sender's
system SEPARATE from this transaction just like used for sending email.
C. Receiver's system issues a C/R challenge via an SMTP extension. Some
token is passed on to the sender's system.
D. The sender's system passes the token via SMTP to the receiver's system
via the original transaction.
This second possibility is just a bundle of thoughts right now. More work
is definitely needed on it.
> What I meant is something that I mentioned in a prior post - ability for
> C/R systems to interoperate at the SMTP level not just mail
> messages level.
> This would save a lot of bandwidth and storage space.
---------------------------------------------------------------------------------------------------
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