ietf-smtp
[Top] [All Lists]

Re: productivity?

2011-08-24 04:49:39

On 23/08/2011 20:05, Murray S. Kucherawy wrote:
So we're only talking about "law-abiding citizens" here, and I don't think MTAs implementing connection caching have any reckless or malicious intent behind those designs, but rather are trying to improve the throughput on both sides
Well, there are two parts to an SMTP implementation - the software and the configuration.

While I agree that law abiding SMTP software implementations won't have malicious intent, I think that you are very likely to find law abiding MTA configators have a disregard for other people - either through selfishness or ignorance. We see this frequently, especially with the big mail providers who think everyone has to bow to their needs, and with small ISPs (and some big ones) who don't know what they are doing. The software is OK, but the configuration is very bad. Possibly the software authors never thought the configuration would be made so bad...

So, while an MTA may cache connections by default for (say) 1-5 seconds (which is bad IMHO, but not too bad ATM), if it allows the configurator to change that to 5+ minutes, then you can bet that someone will do it at some point. (Just as I guess most MTAs have default timeouts over 1 minute, but we often see timeouts of 10 seconds or less - someone has configured that, not realising the implications).

Thus, notes for the software implementer may be useful as it may give them ideas about limits they may want to impose on configurable settings. Also, it may help them realise that, even though they are concentrating on optimising sending, their optimisations may adversely impact the remote receiver.

, and probably did some testing of the idea before rolling it out. So far the industry as a whole hasn't found it to be a problem (which to me means it's possibly even a benefit).
Well, spam wasn't considered a problem 15 years ago, and things like the % redirector and open relays were considered a benefit then as well.

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.

I would like to see what testing any mail sender has done with regards to connection caching from a large number of senders to a few receivers. Sending from their particular sender to lots of receivers it probably has a huge benefit, but going the other way around, it potentially causes huge problems.

Caching connections to or from a small company's mail server is going to be a waste of their resources 99.99% of the time, as it is extremely unlikely that there'll be two messages soon after each other between the same two MTAs. It's a different matter if you're talking about Gmail sending to Hotmail where connection caching could be a huge benefit, but most mail servers aren't in that situation. In my view connection caching should always be disabled by default, and allow the admins to set up cached connections to other specific domains (or automate it based on how many times a cached connection would have been useful). Having a default of always caching connections is just wrong.

I do realise that there are people here who think connection caching is good 100% of the time, so I'm probably flogging a dead horse. Maybe because I'm coming at it from the viewpoint of companies with 5-50 users, rather than from ISPs or big companies I have a different viewpoint.

(PS - for the discussion about ephemeral ports, reusing connections is only useful if you can. If you hold a connection open for 5 seconds longer than necessary and don't reuse it, then that's 5 seconds longer before that port number can be reused - so ephemeral port limits can be an argument against connection caching as well)

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