I'm replying to several messages here (see References), but I'm not
going to bother attributing each quote.
>> >qmail will always be faster than sendmail [unless you send one message
>> >to a large number of addresses on the same remote host].
>>
>> No, qmail will usually win here, too, because sendmail serializes.
>> Sendmail only wins when the message is huge.
>
>Sendmail will win if you use multiple rcpt-to's.
No, SMTP requires too many round trips per recipient.
>> >qmail will always be faster than sendmail [unless you send one message
>> >to a large number of addresses on the same remote host].
>>
>> No, qmail will usually win here, too, because sendmail serializes.
>> Sendmail only wins when the message is huge.
>
>Actually, if you are unfortunate enough to have a list of addresses sorted
>by the right side of the @, qmail can be a big loser here. This is
>because it will completely overload many remote hosts if there are a bunch
>of recipients. eg. concurrencyremote = 120, you have 200 users
>@somedomain, qmail will sit there with 120 connections to somedomain's
>mailserver open while they all crawl along because somedomain can't handle
>120 connections at once.
somedomain is poorly configured. Should qmail assume all sites are
poorly configured? Should properly configured sites suffer because
some sites are poorly run?
>qmail is great that way at inflicting remote DoS attacks against other
>mailers.
That's loaded language. If you want constructive debate, you might
want to avoid that.
>I don't know? Why does "qmail" accept connections that it cannot handle?
Mine doesn't. I restrict it via tcpserver to an acceptable,
conservative number of connections that, in my experience, the system
will be able to handle in most foreseeable circumstances.
>This is great in theory. In practice, does your tcpserver setup
>automatically start refusing connections when you're low on queue space or
>when you know the load will be too high? I bet it doesn't.
No, but my tcpserver connection limit is sufficiently conservative
that it can almost always handle a full compliment of SMTP clients. If
it can't, so what? Chances are, a few too many SMTP connections when
the system is hosed are the least of my worries.
>The reason why it doesn't isn't because it's poorly designed. It's
>because it's hard to do this. You have to be partially psychic in order
>to always catch it.
It's hard (impossible?) to dynamically determine if the system has
sufficient resources to handle a request before accepting the
connection, but, in practice, I've never found it necessary to do
that. Even on a mail server, setting the connection limit
conservatively has always worked fine.
>> Only if they are silly enough to accept more connections than they can
>> handle. :) One of the things a sys admin is "supposed" to do is tune his
>> machines for performance. If you cannot limit the number of connections
>> you will accept to something your system can handle, you need to re-think
>> your setup.
>
>Erm... you just described a classic DoS attack. You put a limit of x
>connections in. One remote system uses all or nearly all of them. No one
>else can connect.
I would call this inadvertant, temporary denial of service, at
worst. It's not an attack, IMO, unless it's intentional and
sustained. Since qmail only sends one message per connection, other
senders are going to have plenty of opportunities to grab
connections. And many of them (e.g., sendmail) will hold onto their
connection until they've dumped their entire load. Enough of them, and
they'll be "denying service" to any other senders.
>> 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.
>
>The point is that, in a lot of cases, they aren't needed.
>
>If you have 500000 messages to go out with 100 messages to each of 5000
>hosts, the claim that it is necessary to open 100 connections at once to
>any single remote server is obviously wrong.
The claim that qmail forces you to do that is also obviously wrong. IF
you don't want that to happen, don't sort your list by MX.
>Heck, even if you had 500000 messages to go to 1 host that doesn't mean
>you have to open 500000 connections (well, bounded only by your local
>configuration and qmail's limits) to the remote host.
Of course not. What's your point? 256 is << 500000. If I've got 500000
different messages to deliver to a single site, I sure as hell want to
use as many simultaneous connections as I can. I assume the receiving
site will behave responsibly and only accept as many as it can handle.
If the don't, that's their problem.
-Dave
