Mark Delany wrote:
>
> 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.
Delivery order depends on DNS servicing smtp servicing and the
exact code you are using to inject emails into qmail-pmpqc.
>
> > 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.
Your delivery order depends on your remote concurrency limitations,
the availablity of dns results and your disk IO.
Why are you so concerned about delivery order?
What is your ultimate goal?
Why is delivery order such a concern?
>
> > 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.
You are wondering how you can spread your out going smtp deliveries
across multiple recipient smtp servers. Why? What kind of email
load are you imposing on the internet?
Are you perhaps a person who has long lists of email accounts?
Perhaps they are all sorted based on host name? Perhaps alot of
the host names are yahoo.com?
So.. You sit back.. and launch your spam list on the internet,
and you wonder why.. when it gets to the yahoo.com list...
it stalls with 255 remote deliveries, and they all take a long
time to complete. And you are upset because you can't get your
spam list delivered?
Just what kind of email are you delivering?
Your questions smack of spam problems.
Ken Jones
