On Thu, Dec 07, 2000 at 11:15:45AM +0800, Wayne Chu wrote:
> Am Mittwoch, 6. Dezember 2000 22:04 schrieb Thomas Duterme:
> > > How about increasing your concurrencyremote to something
> > > like 100? you most likely are hitting your limits.
> >
> > Good point. Will try that tonight. I've gotten some
> > problems before from ISP's blocking us
> > when I went up to 240...I'm not quite sure what the highest
> > polite limit on this should be.
>
> My newsletter program calls qmail-qmqpc directly.
> Does qmail send mails to recpt in the order I write the address
> to qmail-qmqpc?
It surely does. But that's ultimately just a queuing order and it
doesn't necessarily mean a delivery order.
> For example, if I wrote addresses A, B, C to qmail-qmqpc.
> Will qmail first invokes qmail-remote to send mail to A
> And then (concurrently, before the first qmail-remote finishes)
> invokes another qmail-remote to B, and then to C?
As it happens, yes. I don't believe that it is gauranteed in any
documentation, therefore relying on this current behaviour may be
risky.
> If so, maybe I can sort my subscriber list first, that subscribers
> in the same mail server will be distrubuted among the whole list
> evenly. So I can minimize the chance of overflooding a certain server?
Sounds like it might help, but consider the case of a particular
domain that is not accepting mail. At the time of the first retry,
perhaps the only recipients left are to that domain in which case it
may well get hit with the full concurrency of your server.
My point is that this *may* help in some circumstances, but it's by no
means bullet-proof.
Regards.
