[ On Saturday, July 5, 2003 at 22:54:55 (+0530), Suresh Ramasubramanian wrote: ]
> Subject: Re: [Exim] Brain Dead ISP's?
>
> I have actually. So has a guy called Alan Brown (the chap who used to
> run ORBS). Alan posted some pretty good stats on this on the
> spam-l@??? list - archives are limited to members only,
> but you can sign on and then grep the archives for Alan Brown delay_checks.
I don't need to look any one else's stats. Unless they measured using a
recent NetBSD implementation then they are meaningless. With NetBSD I
know full well _exactly_ what the overhead is.
I also know from several years of direct experience that in the real
world this issue is not anywhere near so much of the big deal you're
trying to make it out as being.
I've yet to see a system that can handle normal peak loads without
slowing down which can't also handle at least a 60-second error response
delay for all SMTP errors. Furthermore note that the tuning needed to
make the system behave optimally under such loads is trivial (just add a
bit more RAM and increase the number of simultaneous connections you
allow). Meanwhile the behaviour of all but the most improperly tuned
systems is graceful, not fatal, and won't cause any permanent problems
or loss of e-mail.
> Yes, you do have a point there - but that open connection is a bit more
> resource than something that looks for such IPs and nullroutes them
> somewhere upstream of the box.
Well, that may not be true either, especially not if you continue to
look at the whole picture and not just the micro-view you seem to like
to take of this issue.
Null routes, IP filters, or whatever, need maintenance and cleanup and
they completely block all connectivity, which might be fine if you're
fighting a spammer but it's a pretty stupid thing to do if all you're
trying to do is stop an otherwise normal SMTP peer from hammering your
machine with unwanted connections.
Error rate limiting penalizes only the clients which make mistakes, but
cannot affect any client which just delivers normal e-mail using the
proper SMTP protocol and parameters, not even accidentally. It requires
no additional software and no additional privileges and no additional
training or management.
--
Greg A. Woods
+1 416 218-0098; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
