Subject: RE: [Asrg] TitanKey and "white lies"... (Faking SMTP hard errors "improves" C/R utility?)

From: Yakov Shafranovich <[email-masked]>
Date: Sat, 31 May 2003 22:22:03 -0400

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

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 31 May 2003 21:24:45 -0600 (MDT)

> From: Yakov Shafranovich <[email-masked]>

> ...
> ...

SMTP clients that merely follow RFC 2821 without knowledge of your
CRI system will retry the message on their normal schedule.
See section 4.5.4.1 of RFC 2821.

You are surely not assuming that all SMTP clients in the Internet will
be replaced before you turn on your CRI system.  So you must be assuming
that SMTP servers can recognize retransmissions of the same message
or same sender and not challenge a second time.  Have you considered
the practical difficulties of that?

By the way, how do you handle MX secondaries?  What if the SMTP client
happens to choose different MX servers for its attempts to send the
message?  How do you avoid sending a challenge from each MX server,
in practice and not merely theory?

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg