From: Thomas Duterme <[EMAIL PROTECTED]>
>Well, I'm based out of China actually, and a large majority of our users
are
>using
>email servers which are based in China...
Yeah.. I suppose that makes it worst, right? I think I can assume that
connectivity to China should be much lower than to the US...
>hmmm.... we had a problem once when we set concurrency to 240...one time
all of
>our
>mail bounced back and we found that many of the Chinese ISPs blocked us
since
>we had
>ended up flooding their servers...that's why we scaled back to the modest
20
That might have to do with ... huh... the great firewall of China . :)
Seriously, tough, sew below.
>oohh, I think I understand. Call qmail-inject directly to bypass the local
>SMTP step
>we've been doing, right? Just on a sidenote, opening so many local ports
like
>I've been
>doing....what adverse effects would this have on tha mailout.
There is no problem with that many ports, assuming the OS is correctly
setup.
>Also, would you advise changing the qmail-inject source directly to sort
which
>queue the mail is
>injected in? Yes, this qmail server only acts as a sender and doesn't
recieve
>any mail or bounces.
Not exactly. To operate multiple qmail queues, you in fact have multiple
qmail installations. For example,
/var/qmail1/...
/var/qmail2/..
/var/qmail3/..
To direct a mail to a specific queue, you call the specific qmail-inject:
/var/qmail2/bin/qmail-inject
Now, there is a trick in all of this: your Java proggie must me changed so
as to call the various qmail-injects, *and* to avoid sending to the same
destination domain from the same queue. Note, I say -avoid-, not prevent.
The advantage of this approach comparing it to something like the big
concurrency patch is that slower domains do not clog the queue. In your
case, you can even fine tune the system, for example directing the mail for
specific servers to a queue with a limited concurrency:
/var/qmail-20concurrency/...
/var/qmail-100concurrency/..
Armando
