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>
|
- Re: productivity?, (continued)
- Re: productivity?, Hector Santos
- Re: productivity?, Peter J. Holzer
- Re: productivity?, Hector Santos
- RE: productivity?, Murray S. Kucherawy
- Re: productivity?, Peter J. Holzer
- Re: productivity?, Hector Santos
- RE: productivity?, Murray S. Kucherawy
- Re: productivity?, Hector Santos
- Re: productivity?,
Paul Smith <=
- Re: productivity?, Hector Santos
- Improving Timeouts, Hector Santos
- Re: productivity?, Carl S. Gutekunst
- Re: productivity?, Hector Santos
- Re: productivity?, Carl S. Gutekunst
- Re: productivity?, Hector Santos
- Re: productivity?, Peter J. Holzer
- Re: productivity?, Hector Santos
- Re: productivity?, Hector Santos
- RE: productivity?, Murray S. Kucherawy
|
|
|