if the newsletters are all the same, you could pre-process
the list, organizing by recipent domain and starting qmail-remote
processes with a few dozen recipients, and only give qmail
the ones that don't go through on the first attempt, and even then
after some back-off time. That way you won't clog up all incoming
channels somewhere, denying service, and getting barred.
Some perl code that can work with qmail-remote is available
at http://www.davidnicol.com/qmail.html
You could open one channel per recipent domain by inserting
fork and next;
right after the for(keys %Recipients) line. Adding a random
backoff timer, something like
sleep(rand 3600)
before invoking qmail-inject might ease things too, as long as
your machine has enough swap space to have all these forked perls
sitting around sleeping.
YMMV.
Henning Brauer 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.
>
> Hmm, even with 20 concurrent connections our servers was blocked by some
> braindead freemailer's servers when one of our customers sent out a
> newsletter...
> I don't think there is a common "highest polite limit", you have to figure it
> out for your country, even for your typical recipients.
>
> Greetings
>
> Henning
>
> --
>
> Henning Brauer | BS Web Services
> Hostmaster BSWS | Roedingsmarkt 14
> [EMAIL PROTECTED] | 20459 Hamburg
> www.bsws.de | Germany
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
<i>damfino</i>
