On Fri July 1 2005 03:13, Frank Ellermann wrote:
the MX could start a lock-step relay during RCPT TO rather
than store-and-forward, [...]
What's a "lock step relay"[...]?
Normal relay:
Sender Relay Destination
<- 220
HELO ->
<- 250
MAIL FROM ->
<- 250
RCPT TO ->
<- 250
DATA ->
<- 354
.CRLF ->
<- 250
QUIT ->
<- 221
<- 220
HELO ->
<- 250
MAIL FROM ->
<- 250
RCPT TO ->
<- 5xx
QUIT ->
<- 221
Bounce <-
Lock-step relay:
Sender Relay Destination
<- 220
HELO ->
<- 250
MAIL FROM ->
<- 250
RCPT TO -> Connect ->
<- 220
HELO ->
<- 250
MAIL FROM ->
<- 250
RCPT TO ->
<- 5xx
<- 5xx
QUIT -> QUIT ->
<- 221
<- 221
We hope the sender doesn't time out while waiting for the lock-step
relay initiation. SMTP minimum timeout values (2821):
greeting: 300 seconds (5 minutes)
HELO: unspecified!!! (JCK please note)
MAIL TO: 300 seconds (5 minutes)
RCPT TO: 300 seconds (5 minutes)
While the sender is counting down its 300 seconds, the relay might
experience 299+?+299+299 seconds of delay. Guess what -- that could
be more than 300 seconds. The relay and destination servers had better
be responsive (even under load) in such a setup, because the sender
timeout isn't under the control of the administrative entity running
the relay and destination. "Strategies" involving intentionally
delayed server responses compound the problem. If the sender times
out and goes away, the relay->destination session had better be
closed gracefully.
One hopes that all RCPT TO (in case of multiple recipients) resolve
to exactly the same destination host; otherwise this gets messy (data
copying as well as timeout issues) and it will still require a
bounce if one (or more, but not all) deliver{y,ies} fail after DATA
(can't return an error reply code; that would cause duplicate
delivery to successful recipients on retry).
In theory, there could be multiple levels of lock-step, but the
timeout issue becomes progressively more critical.