----- Original Message -----
From: "Bruce Lilly" <blilly(_at_)erols(_dot_)com>
Subject: Re: spamops-04 (was: Bounce/System Notification Address
Verification)
What's a "lock step relay"[...]?
We hope the sender doesn't time out while waiting for the lock-step
relay initiation. SMTP minimum timeout values (2821):
First, I think it should be made clear these are recommended values and the
system has the ultimate decision base on best performance, efficiency and
scalability decisions to hand load requirements. A server can wait 5
minutes. Well go to Yahoo.Com and see how long it will wait for you to type
in a command. So these are recommended values only.
greeting: 300 seconds (5 minutes)
HELO: unspecified!!! (JCK please note)
I would think the last sentence in section 4.5.3.2 Timeouts suggest what the
default values area in both directions. But it should be clarified in
2821bis.
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.
This is why you have 35 second per command. Exim uses 30 seconds.
CONNECT 30-35
HELO 30-35
MAIL FROM: 30-35
RCPT TO: 30-35
120-140 wait time for the remote.
You can not use the RFC x821 defined values for a sink. And if you insist,
you need to use a 1xy continuation response codes to keep the waiting sender
alive. This may be required for OPES. The CBV is a example of OPES smtp
implementation.
4.2.1 Reply Code Severities and Theory
....
1yz Positive Preliminary reply
The command has been accepted, but the requested action is being
held in abeyance, pending confirmation of the information in this
reply. The SMTP client should send another command specifying
whether to continue or abort the action. Note: unextended SMTP
does not have any commands that allow this type of reply, and so
does not have continue or abort commands.
Read this link in the OPES working group where I show proof of concept.
http://www.imc.org/ietf-openproxy/mail-archive/msg03282.html
...
In theory, there could be multiple levels of lock-step, but the
timeout issue becomes progressively more critical.
Bruce, I think you theory is 100% correct, but it isn't the real world, not
exhibited in practice simply because it defies logic for proper operations.
See RFC 2821 4.5.4.1 Sending Strategy
Lets take the worst case situation, a sender issues
Sender:
MAIL FROM:<return-path>
RCPT TO:<forward-path>
The server now begins the CBV back to the return-path host. The sender will
wait 5 minutes, so you assume. But this is the recommendation. Do you
really want to wait 5 minutes?
Divide 5 minutes by 4 (for each state) and we have 75 seconds wait time per
CBV state.
This is the worst case and also the "theoretical" maximum value for each CBV
state:
CONNECT 75
HELO 75
MAIL FROM: 75
RCPT TO: 75
Total 300 seconds (5 minutes)
But that is cutting too close, the better value is between:
Default Socket Timeout <= Timeout < 75 seconds
I chose 35 seconds. Exim chose 30 seconds, which for me, is low for Windows
implementations. You can't go higher than 75 seconds because this will
break your expectation of the compliant sender timeout value.
Now whether the timeout was 20, 35, 75 or 300 seconds (5 minutes) to comply
with SMTP values, you have:
20 x 4 = 80 second
35 x 4 = 140
75 x 4 = 300
300 x 4 = 1200 seconds
The question you have to ask regardless of the amount is how this play in
the real world implementation where performance is major consideration.
The specs says the sender should wait atleast 5 minutes. You are assuming
that all senders will wait 5 minutes. This a false assumption. Some will
not. See RFC 2821 4.5.4.1 Sending Strategy. So if one is going to explore
the CBV, they need to keep the TIMEOUT per command as low as possible.
If one says anything less 50% like Keith suggest, exhibit slows downs, then
CBV is no good. Guess what? If it anything close to 5%, then to me, CBV is
no good. Get the hammer. Squash it. Don't even think about it any more.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com