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.
+1.
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.
--
Sincerely
Hector Santos
http://www.santronics.com