> I think DJB has given a mathematically rigorous proof that "program
> which is vulnerable to DoS" is one definition of "server". When a
> server is serving all it can, it will refuse to serve any more. QED
this is accurate for a single function server. in a multifunction
server, it would be smart for the administrators to construct
it in such a fashion such that one function can't seriously degrade
other offered functionality.
> > ...the root problem is qmail's rudeness in this area.
>
> You may have a point here. Is there a well-defined rubric within which
> we can assert, "It is ill-mannered to consume all available
> connections to a remote server, just because those services are
> needed?" Could be, I suppose--that's a question for admins.
i would add ineffient as well as ill-mannered. consider the system
overhead requred to fork processes/threads on both servers combined with
the network and application startup time for the connections, and it
becomes obvious that when delivering a statistically large amount of mail
to a single recipient server, it makes more sense to pipeline the mail.
of course, we all knew this to begin with. OTOH, qmail works because in
non-bulk sending mode (hint to folks) there is a reasonably random
distribution of domain names which really only sees problems upon
death/unreachability of a specific target. As for those bulk senders, a
relatively painless solution is to randomize the order of the domains
and/or pull out the top 5 and serially send those. Your
tools *do* talk smtp, don't they?
> Given that all service requests were legitimate, I would not mind my
> server being pegged with connections from one host. When such
> conditions become routine, from particular hosts, taking appropriate
> action is why Sys Admins get paid. Of course, that's just MHO.
better pegged from legit mail than pegged by script kiddies ;)
-- craig
