[Top] [All Lists]

Re: Mail Data termination

2011-08-22 08:27:20

On 22/08/2011 13:46, John C Klensin wrote:
worse. When I resist changing the 5321 limits, I do so both because I am generally concerned about the procedural implications of protocol changes at this state but also because there are still environments around the world with lower-performance clients and/or servers, lower bandwidth than the big server farms, or even intermittent connections. Servers with intermittent or flaky connections make strategies like "once you determine that you can open a connection and get a message through to a host, gather up everything you can find and send it as part of the same connection and, especially if the connection took several tries to establish, maybe keep it open for short while to see if anything else can be pushed through it" really sensible. Our colleagues in the DTN business would probably suggest that "around the world" should be expanded to "around the solar system" (at least) and point out that the same sorts of strategies are even more important for them.
I wasn't actually suggesting that the timeout suggestions be simply lowered, just that I'd like more stuff about why they are that big, why they may need to be shorter, what the implications are etc.

FWIW - I'd have thought having an MX server on an intermittent/flaky connection would be a "bad thing"... Anyone who wants to get email should have a reasonably reliable connection to their MX server, even if then the final delivery server is on a flaky connection.

I still think that 'pre-queuing' rather than 'post-waiting' is more community spirited - pushing everything you can through once you have a connection is eminently sensible - hanging around just in case more comes along might stop other people getting messages through to this flaky connection which has just had its few seconds of connectivity for the day.

In that environment, the strategy is not only not antisocial, it is hugely beneficial, not just to the sender but to the receiver and the users/mailboxes it supports.
Not if it prevents other senders getting their messages through while the first sender was sitting with an idle connection using up the connection quota.

Keeping connections open 'too long' is fine if you assume that the receiver has an unlimited number of connections available. Once you accept that this is a limited resource in many cases, then it becomes a much nastier thing to do. If there's an unlimited number of connections, then an idle connection costs the receiver nothing. If the receiver is limited to, say, 10 simultaneous connections, then the idle connection costs the receiver 10% of its capacity.

My sense is that there have been some very careful discussions and analyses in this thread (along with the inevitable small amount of complete noise). Probably a good foundation for such a document could be to simply draw that material together, eliminate the noise, and organize it coherently. Because of differences among environments I think it would actually be most useful as a discussion of the issues and analysis of what might make sense than as any sort of normative specification

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