On Thursday, December 7 at 08:37 PM, quoth Donald Nash:
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."
Do you know of any that do that?
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.
HEH. Been there, been that guy. It's pretty easy to figure out. If all
my messages magically get delivered by serialmail but qmail has
trouble, I know exactly what's going on.
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.
HEH. I guess I've been in the batch computing world for too long. When
you want serious computing done, there's *never* anyone else (there
are papers written about how problematic "OS Noise" is in high
performance computing).
But fair enough. The point is, though, even if there is someone else,
is it that important? I mean, in most cases, I don't have any
particular domains that are significantly more important that others.
With the exception of spam, I don't have any domains that are time
critical. If I really had a message that was important to transmit, I
would say that SMTP is probably a bad method of transmitting that
message, given that the protocol makes *no* guarantees about
timeliness. Granted, some people do expect this, but that doesn't mean
that SMTP is a good protocol for notifying me of high-priority
information.
Per-IP connection limits are the most obvious such policy. A limit
on the number of messages per unit time is another.
THAT is something that *really* burns me up. I had this problem with a
university that many of my mail clients use. One of the domains I'm
responsible for has several mailing lists that were running into
problems because the university had set up a "no more than 50 mails
per hour" policy. Better still, all messages over the limit got 5xx
errors. Sending 1 message on the mailing list triggered more than 200
messages all at once, and the 5xx errors rendered the mailing list
effectively truncated. I finally got the university to whitelist my
server (the mailing lists affected were, among others, the "Alumni of
Philadelphia" mailing list), but even so, the policy is ridiculous.
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.
Well, we're really talking about two different things here. On the one
hand we're talking about 4xx greetings (which I have no serious
objection to, even though I think they're kinda silly) and arbitrary
connection/message limits.
~Kyle
--
The whole art of government consists in the art of being honest.
-- Thomas Jefferson: Rights of British America, 1774
pgpef1en8TeAO.pgp
Description: PGP signature
|