Marc Slemko <[EMAIL PROTECTED]> writes on 12 April 1999 at 13:24:34 -0700
> On Mon, 12 Apr 1999, Keith Burdis wrote:
>
> > > qmail is great that way at inflicting remote DoS attacks against other
> > > mailers.
> >
> > Well, the obvious question is why do mailers accept connections that they
> > cannot handle? If the remote host accepts the mail it should be prepared to
> > deal with it.
>
> blah blah blah.
>
> I don't know? Why does "qmail" accept connections that it cannot handle?
Because it's not intended to run as a standalone daemon; it runs
either under inetd or tcpserver or whatever, and load-based decisions
about accepting connections should be implemented at that level?
> It is a pretty simple concept: even if a mailer can "handle" it, if you
> send 1 simultaneous bit of mail to 1 machine, while using all your other
> slots for sending to other machines, you will get x% of each machine's
> resources. If you send 120 simultaneous messages, then you only get y% of
> the machine's resources, where y is between a little (eg. if the machine
> normally has 10000 incoming connections) to a huge amount (eg. if the
> machine normally has 2 incoming connections) less than x.
The other pretty simple concept is that carefully sorting the queue
out by the IP that will actually handle the connection, either to
aggregate connections OR to deliberately spread out the load, is
*very* expensive (DNS queries), and tends to swamp any benefit to be
gained (at least on the aggregation side; the other side, deliberately
spreading the load, hasn't to my knowledge been studied as carefully).
> Because of somewhat nonsensical hard coded limits, when sending a lot of
> outbound mail with qmail, the number of simultaneous connections open
> total often is a big limitation. Because of that, the fastest way to send
> mail is to ensure you aren't overloading any remote machine more than
> necessary at any given time, so that each connection to that machine takes
> the least time possible, even if that involves more seialization.
I think I can guess what your on about here, and I agree that a byte
isn't an appropriate size for the counter on outstanding
qmail-remote's. Doesn't affect me personally, but people with heavy
mail hubs might well be.
Remember, when initially coded this was such a great step up in
concurrency that nobody noticed the funny limit.
Is this number (either the current count, or perhaps as an id number
for a particular task) ever passed through a pipe? I wonder if the
limit really comes from simplifying that?
> Trying to blame the remote mailer for qmail's less than great behaviour in
> this area is silly.
I don't think you've made much of a case for "less than great
behaviour", personally.
--
David Dyer-Bennet [EMAIL PROTECTED]
http://www.ddb.com/~ddb (photos, sf) Minicon: http://www.mnstf.org/minicon
http://ouroboros.demesne.com/ The Ouroboros Bookworms
Join the 20th century before it's too late!
