ietf-asrg
[Top] [All Lists]

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

2003-05-31 22:30:30
At 09:24 PM 5/31/2003 -0600, Vernon Schryver wrote:

> From: Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>

> ...
> >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.
> ...

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?

I was thinking of defining such SMTP protocol not for general use, but rather as an alternative for cases where both the sender and receiver have C/R systems and want to shift the storage of messages to the sender. This would be accomplished by defining an ESMTP extension that is following these guidelines, NOT via general SMTP traffic. All existing clients and SMTP servers, would use the general CRI protocol as defined by Eric. Any C/R systems that are capable of performing C/R via ESMTP, would agree to use it with an option to fallback to the general CRI protocol. As for the re-transmissions, the unique C/R token can only be used once and would stop the message from being re-transmitted more than once.

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?

Any C/R system at least on the receiver's end would have to keep state in order for C/R to work. However, my understanding that in a general C/R system the MX servers are not required to keep that state information but rather that can be offloaded to the the back-end system, with the MX servers just accepting the transmissions. In practice I do not know what existing C/R systems do for state information - whether its kept on MX level or back end (perhaps some of the C/R people on the list can provide information on that).

In this system that I proposed, such state information would have to be shared among all the MX servers and the obvious problem with that would be that such sharing requirement would be hard to implement in large systems. I am not advocating this specific approach, just using it as an example of how the entire C/R handshaking process can be done via some direct protocol instead of having the receiver's system accept and parse the message before sending a challenge. Some form of a direct C/R-to-C/R protocol would help interopable C/R systems save on storage costs and perhaps it should be something we add to the draft CRI specification.

Yakov
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>