ietf-smtp
[Top] [All Lists]

Re: Mail Data termination

2011-08-22 02:15:26

Murray S. Kucherawy wrote:
-----Original Message-----
From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org 
[mailto:owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Hector 
Santos
Sent: Sunday, August 21, 2011 6:59 PM
To: ietf-smtp(_at_)imc(_dot_)org
Subject: Re: Mail Data termination

Is there a loading limit in your arsenal against DoS attacks?  Is
there such a thing as resource limits even for a Modern OS?  And is it
reasonable for the CS client to pass the cost burden on the receiver
to solve what is only a client problem?

I think you're ignoring the points others have made that a connection cache benefits both sides, since establishing a connection is a (relatively) expensive action at both ends, especially if SMTP AUTH or STARTTLS are in use. It doesn't strictly benefit the sender.

You didn't answer the questions above. You can't state this without answering the above.

I ignored it because they are common factors on both ends and ones that a receiver can control. Its part of the SMTP client/server design process and the tweaking is already in place which may include disabling STARTTLS, AUTH or any other common factor.

We are taking about pure science:

       INPUT = OUTPUT

and a new timing factor that is out of the receiver control that alters the entire balance of the system. Its impossible to maintain steady state with a factor the client owns and the receiver has no control. There is only one way for the receiver to get back control - break the SMTP spec and drop the client after the 250 EOD response.

No impact on the client because he will finally solve its problem by waiting 5 seconds to get more mail for the destination host before starting its expensive trip. It could even afford to wait 10, 30 seconds or even 1 minute to increase the odds of getting more mail and then send it as fast as possible and none of this will have any impact on the receiver other than more transactions which is an acceptable SMTP concept.

--
Sincerely

Hector Santos
http://www.santronics.com


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