On Sun, Jul 08, 2001 at 10:57:08AM +0200, Andreas Grip wrote:
> Nope, I'm not misstaken. An infected mail is not rejected while my smtp
> server is receiving the mail, it turn of the connection with an ok. No
> bounce at this time. And then it sends an bounce to the sender with
> virus warning message.
Absolutely right. I cannot send a SMTP error back during the DATA phase
otherwise the sending SMTP server just bounces the Email message with little
or no reason. SMTP error messages aren't any good when you're wanting to
convey an elaborate reason why it bounced (e.g. "it was the KAK worm virus")
and in several languages :-)
OTOH it is still real-time. An original design decisions behind
Qmail-Scanner - which I am still happy with - was that I wasn't going to
re-invent the wheel and do post-scanning, and I would then have to design my
own queuing system, retries, etc. The way it is designed means all such
issues are taken care of by standard SMTP.
10-20 minutes is the standard maximum time a SMTP server expects to be
sitting in DATA phase, if a mail message takes longer than that to be
scanned by whatever virus scanner you have chosen (that will be where the
bottleneck is - not with Q-S), then you seriously have to look at:
a> your choice of scanner
b> upgrading your hardware.
I have seen thrown around the "fact" that to run a real-time SMTP virus
scanner requires around 10x the amount of hardware that not scanning would.
Sounds about right. That isn't as bad as it sounds as we all over-spec SMTP
relay servers these days anyway. We run two different virus scanners over
each piece of Email entering and leaving our network via Qmail-Scanner. The
load on these boxes has increased from a load average of 0.02 to 0.06, and
climbs to 30+ when we have hour+ network outages. The sudden onslaught of
mail after an outage is the killer.
Always spec for outages...
Also, don't forget, disk IO is most important for SMTP servers. When you
start virus scanning, you must add CPU and RAM to that as well. i.e. Big AV
mail servers need lots of RAM, lots of CPU as well as fast disks.
--
Cheers
Jason Haar
Unix/Special Projects, Trimble NZ
Phone: +64 3 9635 377 Fax: +64 3 9635 417
