Hi Armando,
Thanks very much for your helpful reply.
>
> *But* you're using SMTP, and many sites (hotmail.com for one) take enormous
> time to handle SMTP. This in fact reduces the usable bandwidth (again for
> hotmail.com, around 600kb/s on a good day from Europe, in my experience).
> You can increase parallelism (concurrencyremote) to try to send more mails
> at the same time and optimize the bandwidth, but this only goes so far.
Well, I'm based out of China actually, and a large majority of our users are
using
email servers which are based in China...
>
> 1) Setup additional qmail-queues in the same machine (using different disks
> for each queue, so as to minimize seek time). All of those set to 240
> concurrency local (requires trivial change on compiling qmail)
>
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
concurrent connections.
Have you had any of the same thing happen? I've done this at 120 concurrent
connections,
but I don't want to push it too much.
>
> 2) Change the dynamic Java thing to send to each queue in turn, and use
> qmail-inject instead of SMTP (this avoids having to create as many SMTP
> ports)
>
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.
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.
>
> 3) All bounces would be handled by a single qmail, of course
>
yup. I'm with you on this one.
>
> Note that your gain would still be limited by the bandwidth: 1 M messages of
> that size a day requires more bandwidth or smaller messages.
