On 2007/02/21 11:39, stuartv wrote:
> I have FINALLY been allowed to schedule time to replace the
> aging mail server.  Currently, it is running OpenBSD 3.7, 
> with sendmail, smtp-vilter, and clamav.  This is our internal
> mail server and it uses fetchmail to get our email off of 
> the public server and sends our email out using a smart relay
> host provided by our ISP.  When I originally set this server
> up I was also running spamassassin but had to remove it
> because it was causing the system to time out and stop getting
> mail for some reason that I never figured out.  The boss where
> I work has NO sense of humor about not getting her email, and
> doesn't seem to get enough spam that it bothered her so I
> did the "better part of valor" thing and just axed the 
> spamassassin.  Lately, we have been receiving emails with 
> larger and larger attachments which has been causing the
> clamav to take to long scanning them and thus a time-out and 
> again, no more email until I get it straitened out.  

You can prevent timeouts by getting scanning out of the SMTP
transaction. There are a number of options; one that works with
Sendmail is MailScanner, it's a "split queue" method that works
in batches, moving files from one queue to another.

If you move to Postfix you can use various software as an "after
queue content filter" and feed it without a batching delay (though
to be fair, you can set the delay short enough that it's not a
real problem).

There are probably plenty of other options too.

That said, senders following RFC2821 recommendations should wait
a minimum of 10 minutes after finishing transmission for the 250 OK
back from the server...

Also, look at getting rid of the POP/IMAP feed by fetchmail.
Have mail delivered by SMTP, either via the ISP or direct to the
server. Either way, you can then accept a second message while a
huge one is being transferred and processed. Even if you don't
have lengthy virus scanning, this is a big improvement when you
know you have large attachments to deal with, since that 66MB
email containing a 50MB file could be blocking a number of
important small emails.

Reply via email to