I got notified by one of my users that they were unable to send mail suddenly. after checking the logs I determined that MIMEDefang was timing out and returning errors. the cause for this was very unclear (which is why i'm sharing my findings with all of you)...
After digging around (and some assistance from David Skoll on the MIMEDefang list) I was able to determine that the problem was caused by SpamAssassin not being able to connect to the database server where the bayes database is stored. (using MySQL on a remote host)
I've modified my mimedefang-filter file so that mail from internal IP addresses and mail sent via SMTP-AUTH ("trusted" mail) is not sent through SpamAssassin.
In general, SMTP is very resistant to delays (it just stores the message and tries again later). The sole exception is the connection from the MUA to the initial MTA; the MUA can't hang around forever retrying so the user gets an eror message. The more subsystems we add to our mail servers (spam and virus checking, for example) the more "random" delays we'll get. If you bypass the checking for mail sent from "trusted" machines then you reduce the chance of delays.
Now, in my case, I can trust my users not to send spam and viruses. If you can't, then you can set up a different machine for outgoing mail than for incoming mail. Have the outgoing mailer *always* accept mail from internal or authenticated hosts, queue it, then scan the queue. This way mail is still always scanned but if you have SpamAssassin-caused delays your users probably won't notice.
Of course, the ideal solution is for SpamAssassin to never cause delays. Unfortunately this isn't realistic, so the next best solution is to have mail continue to work even when SpamAssassin isn't working.
-Kevin
pgpQ2I9vuBWwh.pgp
Description: PGP signature
