[Top] [All Lists]

Improving Timeouts

2011-08-25 08:11:08

Hector Santos wrote:

Paul Smith wrote:

Just because something isn't seen as an immediate problem doesn't mean it may not become so in the future. Hopefully we've learned from the previous things that have become abusive that it's better to strike early rather than leave it until it's too late.


We don't even now if the bad guys took the idea a step further already - you don't need to wait after the 1st transaction, just wait after each state, 5 seconds at each state perhaps.

Just consider what is the maximum allowed SMTP session time is by SMTP standards using the minimum commands:

    EHLO   5 mins
    MAIL   5 mins
    RCPT   5 mins * N  where N is total recipients (default 1)
    DATA   5 mins
    EOD   10 mins
    QUIT   5 mins

  SMTP Standard Allowed Time = 30 + 5*N

With N=1, SMTP by technical standards, a client is allowed to use 35 minutes and still be 100% compliant!

There is also a potential for a 10 mins "time hole" when first connecting:

   Server 5 mins to send a 220
   Server 5 mins for Client to send the first command. i.e. EHLO

So if the server is holding connected clients in a load session queue, and the client has not disconnect yet, once the server issue 220, the client can still wait 5 minutes to send its first command.

This is one area where the SMTP spec can be improved to set the idle time to:

    5 mins - minus the time it took to send the 220

So if it held the client for 3 minutes, the server should only need set an idle timeout of 2 mins for the client to send its first command.

The client has its own 5 mins timer and if it hasn't disconnected waiting for the 220, then most likely it will send the first command immediately after seeing it 220. The server does not need to set a 5 minutes idle time if its has already delayed the client.


Hector Santos

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