[CentOS] Re: Kind of OT: internal imap server
alex at milivojevic.org
Fri Sep 1 16:33:34 UTC 2006
Quoting Feizhou <feizhou at graffiti.net>:
> So you are saying that mimedefang is not reliable if not provided
> enough resources. What happens to the mail then? temporary reject or
> let through?
Whatever way you configure Sendmail and MIMEDefang.
In Sendmail, you can configure it to either permanently reject,
temporary reject or just pass through in case of filter failure and/or
if filter gets stuck (there's configurable timeout). These are
per-filter settings, so if you for example have AV scan in one filter,
and spam scan in another filter, you can configure Sendmail to
temp-fail if AV filter fails, and to pass through if spam filter fails.
MIMEDefang also comes with its own set of configuartion direcitves.
You can configure maximum number of slaves, the minimum number of
slaves to keep around, and what to do if the slave misbehaves (for
example, doesn't return in configurable amount of time). And of
course, in your filter script (the Perl code you are supposed to
write) you can take whatever action you like in case your script
detects an error condition.
Some of this settings you need to coordinate a bit. For example,
there is no point in telling MIMEDefang to wait 1 minute for a slave
to finish processing, and than telling Sendmail to wait only 10
seconds for MIMEDefang (you want timeout in Sendmail to be longer than
timeout in MIMEDefang).
Another word of warnning if using SpamAssassin from MIMEDefang (or
from anything else). MIMEDefang alone is relatively lightweight and
fast (for a Perl thingie). However, SpamAssassin is a memory pig.
Very fat pig (to put it politely). The kind of a pig you would take
to a farm show. Like any other fat boy, it can't run fast either.
Even if you are scanning only small emails with it (never attempt to
pass something larger than 100-200k through SpamAssassin).
SpamAssassin can easily take anywhere between 10 to 20 megs of memory
just to process relatively small message (or even more, depending how
large are emails that you pass through it). When calculating how many
slaves you allow MIMEDefang to start, keep this in mind and make sure
you don't exceed the amount of physical memory in your server. You do
not want SpamAssassin processes fighting for memory. It can kill your
email server. Imagine ten really fat pigs (the real live pigs, flash
and blood, curly tails, covered in mud and flies, burping, farting and
everything) stacked on your server. You've got an idea. If running
on a slower machine, you'll also want to adjust timeouts in Sendmail
and MIMEDefang to give SpamAssassin enough time to chew the message.
If using SpamAssassin from MIMEDefang, I usually set maximum number of
requests per slave in MIMEDefang low. Even if SpamAssassin allocates
too much memory in some slave when processing some nasty email, the
slave will be replaced by a new one relatively quickly and memory will
be released back to the system. It is kind of a tradeoff setting.
You don't want slaves being terminated and resetarted too often. And
you don't want fat ones lingering around for too long either.
You'd also tell MIMEDefang to use embeded Perl, so the Perl
initializes only once. This can help performance dramatically.
When using SpamAssassin, you might also want to look into Sendmail's
throttle and alike option(s). What it does is that it controlls the
maximum number of connections per second. If the number is exceeded,
it will simply postpone the processing of incomming connection (it
will not reject anything, just postpone the handling of incomming
connection). However, when using this option, if you experience the
storm of incomming connections, the postponing might cause the clients
to time out (howerver, if it gets that bad that clients start timing
out, you are most likely under the DoS attack anyhow). Older
Sendmails have only global throttle option, and you can specify only
integer amount of connections per second. Newer Sendmails can do it
per-IP address (which helps if you are dealing with only single bad
host), and you can specify number of messages per time interval (so
you'r more flexible here too). This might help prevent having too
many SpamAssassin scans occuring simultaniously and fighting for CPU
NOTICE: If you are not intended recipient, you are hereby notified
that by reading this message you agreed not to disturb frogs during
mating season. For more info, visit http://www.8-P.ca/
More information about the CentOS