--On December 7, 2006 4:08:50 PM -0500 Kyle Wheeler
<kyle-qmail@memoryhole.net> wrote:
I suppose the other reason one might limit the connections of a given
host is to prevent that host from monopolizing your server
That's what I had in mind. It's the same reason that modern flavors of
Unix limit a single UID to having only a limited number of processes: to
prevent one person from filling up the process table and thus preventing
anyone else from using the system.
it makes it possible to monopolize your server for a short amount of
time (the amount of time necessary to send the "go away, you talk too
much" message
Unless the sending SMTP is smart enough to keep a count of the number of
simultaneous outbound connections it has to a particular server, and can
interpret the 4xx greeting to mean "N connections are OK, but N+1 aren't."
And if the sending SMTP isn't that smart, then the receiving SMTP can be
smart enough to switch from, "I'm trying to be nice and let you know
there's a problem" mode to "Take a hike you ignorant lamer" mode and simply
start refusing connections.
it asserts that receiving desired email from multiple hosts is more
important than receiving desired email from a single host.
This could very well be a legitimate policy. If one server is a source of
a large volume of relatively unimportant e-mail, and another server is a
source of important e-mail, then I would want to take steps to ensure that
the important e-mail could get through as expeditiously as possible. I can
do that right now without the 4xx greeting banner, of course. But the
sysadmin of the high-volume, low-importance server might appreciate knowing
that he's being connection-limited, especially if his mail queue starts
backing up.
Just to illustrate what I'm talking about, say host A wants to send you
10 messages, and host B wants to send you 5 messages,
Your example assumes that A and B send mail of equal importance. I'm not
saying that A's messages are expendable, just that I want to make sure that
B's messages aren't impeded by A monopolizing all my inbound connections.
If that means some of A's messages get to wait, then that's OK.
Also, in the case where there is no B, just A, imposing per-host limits
delays messages unnecessarily. Half of A's messages will be delayed even
though, technically, you *could* have received them, you just chose not
to.
If I happen to be the only person logged in to a Unix timesharing system,
then what harm would there be in me filling up the entire proc table with
my own processes? The answer is, there's *always* someone else. It might
be cron jobs, it might be incoming FTP or HTTP connections, whatever. In
other words, there are situations in which B always exists. Even if it
isn't trying to send you mail right now, you can't predict when it might
try. And if B's mail is more important that A's, then you need to make
sure that A doesn't keep it from getting through.
Are there reasons other than per-client-IP connection limits that would
make a host temporarily reject a connection and want to send a message
explaining why you can't talk to a given host at the moment?
I was thinking specifically about policy violations rather than routine
transient technical problems, which are already handled adequately by
existing mechanisms. As you say, why would you want to tell anyone that
you're having hardware problems? Per-IP connection limits are the most
obvious such policy. A limit on the number of messages per unit time is
another. You can implement that now by rejecting the MAIL FROM, but why
even allow the connection to get that far if you're not going to accept any
messages?
Don't get me wrong, I'm not saying, "Oh my gosh, SMTP is so *totally* lame
without this feature!!!11!!1" I'm just saying it could prove handy in
certain circumstances, and doesn't have to cost anyone anything if they
don't want to implement it.
--
Donald L. Nash, <D.Nash@its.utexas.edu>
Information Technology Services, The University of Texas at Austin
|