Hi, after going throught the list archives (and finding many helpful
posts), I was unable to find a close enough match to solve this
problem.
I have a qmail complex behind a localdirector that solves a problem with
an email outsourcer (full detail below).
The box in question (eek.quepasa.com) is a uniproc Pentium II 350, single
IDE drive, 128Megs of ram with a late kernel built for allowing IP
aliasing and serial console:
Linux version 2.2.15 (root@eek) (gcc version egcs-2.91.66
19990314/Linux (egcs-1.1.2 release)) #3 Tue May 30 11:16:40 MST
2000
Qmail 1.3 details:
] big-todo patch applied
] conf-split is set to 83.
] installed to the letter of Lifewith Qmail
] there is a separate partition for /var/qmail, _not_ mounted sync. It is
~5gig, with 2gig free. The file system was created with 1:1 inodes to
blocks, block size 1024 bytes.
Problem, short version:
All inbound mail to .quepasa.com goes to one machine (eek.quepasa.com)
for sorting, and then is delivered somewhere else. We had a scheduled
newsletter go to our users (opt in only) of around 250,000 pieces of
mail. this was two nights ago.
after 2 days qmail-qstat shows:
messages in queue: 153944
messages in queue but not yet preprocessed: 38282
When I look at the log I am seeing a fraction of the utilization I expect:
typical: 2000-07-13 10:49:43.032796500 status: local 1/10 remote 2/120
I have checked the trigger file via "make check", it was ok, however I
did run "make setup", for good measure.
I read that there can be problems with file handles in Linux, checking
/proc/sys/fs/file-nr shows:
1785 1434 4096
If I understand the Linux doc correctly, this means I have not run
into a filehandle problem.
I have seen eek's remote delivery go as high as 6/120, this is usually
near startup of qmail. after about 50 sec. it drops down and runs at 0-2,
once in a while spiking to 6 ( < 4% of the time). Local typically runs
from 0-2. a qmail-tcpok, ALRM to qmail-send does not seem to increase the
delivery rate.
At this point i am delivering about 100 mail/min local and l00
mails/min remote.
I know this machine should be able to clear this queue in less than 3
hours.
Virtually all the delivers from eek go to another qmail box connected
at 100M, that box (pair.quepasa.com) shows no load, it's qmail-smtpd
connections corresponds with the remote connections on eek
(i.e. qmail-smptd is at 2-3/400).
I'm hoping for some ideas on other things to check.
=================== background on install =================
quepasa.com Email system:
NOTE: The reference to "foo.fake" below is a literal reference, I use
"foo.fake" for a strictly internal virtualhost/smtproute setup.
Principle problems (background for problem above only):
] we have outsourced our web customer email system, so
[EMAIL PROTECTED] is a customer, and has to be delivered to
criticalpath.net (cp.net).
] we have also propagated [EMAIL PROTECTED] as employees email
addresses, which should be delivered locally.
] when you out-source with cp.net they want you to point your domain MX
record at them:
quepasa.com. IN MX 10 inbound.quepasa.com.criticalpath.net.
I was not willing to do that for several reasons:
] if cp is down, external email does not come through.
] I did not want to have to configure filters and forwards at
cp.net so all employee mail did the right thing.
] as a business continuity measure, I wanted to control the
mail flow. If we needed/wanted to change email providers, I
can make the routing change in one qmail file.
] when delivering to cp.net the mail *MUST* be to [EMAIL PROTECTED]
(cp's restriction not mine). I learned the hard way that:
[EMAIL PROTECTED]
will not work.
The solution is obvious, accept mail at a central box
(mailx.quepasa.com) for [EMAIL PROTECTED], if:
a.] the mail user is an employee, send it along to a bastion host
for delivery inside quepasa.com.
b.] if not send it off to [EMAIL PROTECTED] at cp.net. (i.e. SMTP
connect is to inbound.quepasa.com.criticalpath.net,
RCPT To:<[EMAIL PROTECTED]>)
The problem comes up at b. the mail has already been delivered to
quepasa.com, if you attempt a forward like.
|forward $[EMAIL PROTECTED]
with a smtproute entry like:
quepasa.com:inbound.quepasa.com.criticalpath.net
The smtproute never seems (???) to be consulted, and it fails as a looping
mail.
I tried fooling around with virtual domains and header rewriting, but
it came down to this, (AFAIK) a qmail machine that receives mail
addressed to [EMAIL PROTECTED], will never again deliver it to
[EMAIL PROTECTED]
That left me with one solution another instance of qmail. I did not
want to run it on the same machine, different port. I loaded another box.
Brief description of mail flow:
] mail for [EMAIL PROTECTED] comes in to mailx.quepasa.com,
if
jane is an employee, deliver mail according to fastforward based
/etc/aliases rule.
else
forward mail to "[EMAIL PROTECTED]"
done
There is a smtproute for foo.fake to pair.quepasa.com.
pair.quepasa.com accepts the mail for virtual domain foo.fake, then
forwards it [EMAIL PROTECTED] pair.quepasa.com had a smtproute that
sends all quepasa.com mail to inbound.quepasa.com.criticalpath.net.
Pair's entire function is to change mail that comes in as
[EMAIL PROTECTED], back to a clean quepasa.com address.
--
Tony Hansmann ([EMAIL PROTECTED])
Director of Technical Services
Quepasa.com, INC.
602-716-0100
