Silver CHEN <[EMAIL PROTECTED]> wrote:
>
> Someone said that qmail is weaker if I send many 'RCPT TO:' in one SMTP
> transactions than sendmail. Well, I don't know the inside story, but I
> do worry about that statement.
Don't worry. There are very rare situations in which sendmail can be
faster than qmail, but in 99+% of actual usage, qmail is *much*
faster than sendmail.
> Usually the newsletter (or big mailing list) admin. will use 'bulk' mail
> to distribute their message, i.e. one message with 'many' recipients.
> And they will sort the recipient lists before sending to MTA too.
It's probably better *not* to sort the lists with qmail because it
will pound on the receiving systems. If you randomize the recipients,
qmail's impact on receiving systems will be spread out.
> I think this flow is ok, but I don't know if this kind of behavior (one
> message w/ many recipients, and sorted lists) is suitable for qmail?
One message with many recipients is good. Sorted lists--at least,
sorted by domain or MX--is not *bad*, but may subject pooorly run
sites to more load than they can handle.
> Will qmail spwans a lot of processes for 'one' such SMTP transaction?
Yes, it'll spawn up to `concurrencyremote' processes, assuming
negligable local recipients. This is the big reason that qmail is
faster than sendmail: with sendmail, one process delivers to all
recipients, and only one connection is ever open to a remote
site. qmail, on the other hand, uses up to conncurrencyremote
(default: 20) processes, up to conncurrencyremote of which may be
connected to any given remote site at one time.
> I choose 100 as the # of 'RCPT TO:' in one outgoing SMTP bulk, so there
> will be more than 4000 such bulks sending to qmail-smtpd for a 400K
> recipient list. What would happen there? I don't know now, but I'll
> try recently.
That would put 4000 messages in the queue. If you increase the number
of recipients per message, qmail will be more efficient.
-Dave
