ietf-smtp
[Top] [All Lists]

Re: Mail Data termination

2011-08-22 04:05:30

On 21/08/2011 21:12, John C Klensin wrote:

--On Sunday, August 21, 2011 14:54 +0200 Paul Smith
<paul(_at_)pscs(_dot_)co(_dot_)uk>  wrote:

...

If the receiver does load limiting by restricting the number
of open connections, then it is selfish for the sender to
presume that it can keep hold of one of these connections for
longer than necessary.

I agree that a few seconds is probably not significant, but if
5 seconds grows to 15 seconds, then 60 seconds etc, then it
could become a big issue for some servers. OK, so the senders
are also having larger numbers of open connections, but this
is under their control, not the receiver's.

The sender also has the privilege of being able to decide when
and what to send, whereas the receiver has to respond in a
timely manner to the sender's requests - thus the sender is
under much less pressure than the receiver. The sender can
keep 1000 connections open and know that it will only send to
one at once, but if the receiver has 1000 connections open it
has to be able to respond to all of them quickly, even if all
1000 decide to send a message at the same time. The receiver
has to respond quickly, to stop the sender (which generally
use very short timeouts, regardless of what 5321 says) from
timing out prematurely and retrying unnecessarily.
...
Paul,

First, no one has really suggested "grows to 15 seconds, then 60
seconds etc.".  As far as I can tell from this thread, there is
general agreement that deliberately waiting a minute or more
would be abusive.
In this thread - yes, but not in any published document that I know of.

5321 says the server should wait at least 5 minutes for the next command. Some client writers may take this as permission to hold an idle connection that long.

This is _not_ a standards problem, at least IMO.

Well, I have issues with the timeout suggestions in 5321, which I do think need more discussion. I appreciate that the 'SHOULD' means you are allowed to ignore that suggestion if there are 'valid reasons' to do so, but it is not clear at all what implications may be.

To be honest, I'd never thought any major sender would use connection caching when sending mail as it is (to my viewpoint) a very antisocial thing to do. So, until this discussion, it had never entered my mind that we needed to do anything about it. We do have to fight against 'DoS' attacks, which might, in fact, turn out to be 'legitimate' connection caching, but because we've been treating it as attacks, we've been handling it differently than if it was a legitimate, but unwanted, behaviour.

Maybe an info or BCP document would be useful


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