[Top] [All Lists]

Re: spamops-04 (was: Bounce/System Notification Address Verification)

2005-07-01 09:36:30

----- Original Message -----
From: "Bruce Lilly" <blilly(_at_)erols(_dot_)com>

Subject: Re: spamops-04 (was: Bounce/System Notification Address

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 Timeouts suggest what the
default values area in both directions. But it should be clarified in

  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

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.

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 Sending Strategy

Lets take the worst case situation, a sender issues

      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

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

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