--On December 9, 2006 1:24:17 AM -0500 Kyle Wheeler
<kyle-qmail@memoryhole.net> wrote:
Well, strictly speaking, greetings are unnecessary for an SMTP deliverer
to "learn" the maximum allowed concurrency for a given recipient server.
If we take a "connection could not be made" as an implicit "4xx, try
later", we *could* arrive at the same result.
I was thinking in particular of a greeting which meant "too many
connections _from you_" (or whatever the policy was that you broke), rather
than just "too many connections". This could be done either with a
specific 4xx greeting just for that, or more likely a general 4xx to be
used in all greetings and an enhanced status code to indicate the specific
reason. As you correctly point out, a simple "4xx try again" doesn't tell
you any more than a refused connection does, and so you can't tell the
difference between "too many total connections" and "too many connections
from your address". These two are quite different, and should be treated
differently by a client trying to make intelligent choices. As you say,
guessing about what the other side might be trying to tell you is a recipe
for frustration. _If_ you want to have a smarter SMTP client, then the
server needs to be able to communicate the necessary information to it
rather than expecting it to guess.
If I was reworking the SMTP protocol to allow for this sort of thing, I'd
encode the maximum concurrency into the SMTP greeting.
Maximum total concurrency or maximum concurrency from the client's address?
Only the latter is useful to the client; but yes, that would be an equally
useful way to tell the client how many connections it can have to this
server. The only downside is that for dumb clients which ignore the
information (meaning all SMTP clients today), it makes for somewhat more
difficult troubleshooting by the remote sysadmin because the information
telling him why his connections are being refused is possibly far removed
from the error. On the other hand, "4xx too many connections from your IP
address" is pretty unequivocal.
The client wouldn't have to store data about every single destination,
It wouldn't regardless. It _would_ have to store data about all servers to
which it has open connections, but it would only need that for the duration
of the connections. And it would need to store it regardless of how it
discovered it: via the concurrency value in the greeting or by getting "4xx
too many connections from your IP address".
The problem here is that you're trying to justify a general-purpose limit
by citing corner cases.
That could very well be the case. It was merely an off the cuff example,
and yes, separate servers would solve the problem.
What if hotmail changed their policy, and all outbound email messages
appeared to be coming from a single IP address?
You talk about me propping up my argument with edge cases...! :-)
I guess, put another way, I have difficulty imagining a situation where
that particular "tool" can be applied in a way that does not open the
door to unintentional abuse.
As I've said in an earlier message, we've been using recipients-per-hour
rate limiting for over two years without a single complaint (until a recent
rule-tightening caused some), because the rules for applying the rate
limits take a many factors into account. They're not static, "everyone
gets this much" limits. They are more like "Hmmm, I have my doubts about
you, so I'm going to rate-limit you."
--
Donald L. Nash, <D.Nash@its.utexas.edu>
Information Technology Services, The University of Texas at Austin
|