Problem fixed! The problem was related to severely crippled
downstream because of a switch misconfiguration that resulted in
packet collisions, and very poor performance. it is my guess that
simscan simply gave up waiting on downloading of messages with fairly
large attachments . Thank you everyone.
The only question now is how do I deal with those messages that are
still stuck in /var/qmail/simcan? There is about 12mb of undelivered
messages in that location. I dont think simscan tries to redeliver.
Thank you.
On Apr 5, 2007, at 10:53 AM, Tom Collins wrote:
On Apr 4, 2007, at 11:34 PM, Bill D'Anjou wrote:
For me, the problem seemed to arise when we were under a spam attack.
It appears as though simscan could not keep up under the load (or is
spamassassin the problem?). Are there faster, more robust
alternatives
to consider? FYI, I am running greylisting which seems to hold up
under
any load & considerably reduces the amount of spam (& viruses)
that get
thru.
Here's a tcpserver patch I installed a while ago that has helped me
out quite a bit:
http://linux.voyager.hr/ucspi-tcp/
It allows you to limit concurrent connections per IP address or
class C, and can also temporarily stop accepting connections if
server load gets too high.
Stopping connections at high load prevents SA from getting swamped
-- it kind of smooths things out a bit. Of course, if you install
the patch and your server is constantly under high load, then you
need more ram and/or a faster server.
I also configured my port 587 for SMTP to not have the same limits,
and to require authentication, so my authenticated customers can
always send (which is OK since their email doesn't go through
SpamAssassin.
--
Tom Collins - [EMAIL PROTECTED]
Vpopmail - virtual domains for qmail: http://vpopmail.sf.net/
QmailAdmin - web interface for Vpopmail: http://qmailadmin.sf.net/
