spamassassin 2.53 & MailScanner
adkinss at OHIO.EDU
Fri May 9 14:28:26 IST 2003
<5C0296D26910694BB9A9BBFC577E7AB0011752B6 at pascal.priv.bmrb.co.uk>
<22.214.171.124.2.20030509083619.03497038 at imap.ecs.soton.ac.uk>
X-Mailer: Mulberry/3.0.3 (Win32)
Content-Type: multipart/signed; micalg=pgp-sha1;
Content-Type: text/plain; charset=us-ascii; format=flowed
--On Friday, May 09, 2003 8:38 AM +0100 Julian Field=20
<mailscanner at ECS.SOTON.AC.UK> wrote:
> At 08:06 09/05/2003, you wrote:
>> IMHO using RBLS directly within
>> MailScanner is only useful if you don't have SA installed.
> I would probably agree with you there. If I had come across SpamAssassin
> when I wrote the MailScanner RBL code, I doubt I would have bothered
> writing it.
> I still find it comes in useful sometimes though, as otherwise I would
> probably have to tweak the SpamAssassin scores for the RBLs I use high
> enough to always trap messages.
> Julian Field
> MailScanner thanks transtec Computers for their support
Well, I don't know if I fully agree with you guys. I see the following
reasons for using RBL's at the sendmail/mailscanner/spamassassin levels:
1) Putting the RBL's at Sendmail level rejects spam immediately, saving
lots of cycles in preventing those messages from hitting MailScanner
and going through the virus checks and spam marking.
2) Putting RBL's at MailScanner level means that you probably have a
policy to not reject email, but only mark it. Virus scanning of the
messages still occur, but if one of the RBL's flag it as spam, then
you still save a lot of cycles by not pushing the message through
Spam Assassin, which IMHO, is the biggest hitter on machine cycles.
3) Putting RBL's at the Spam Assassin level means that you have pleanty
of horse power to handle any message that comes through and you want
to rely on the scoring aspect to classify spam and not relying on the
RBL's along to write a message off as spam.
Of course, a lot of admins may use a combination of the above. We don't
use RBL's at the sendmail level, but we do immitate it by populating our
access.db file with RBL like information. We actually don't use RBL's at
any point in the system. We receive easily a half-million messages a day
to our system, and we are very cautious about introducing additional side
affects where a network will slow down or go away, adding to the time it
takes to process email. We can't afford to have mail back up, as it gets
us in trouble (politically, for sure) every time.
On top of that, our environment seems pushed to the brink a lot of times
to handle the email load that comes in... on busy days, we may end up
processing a million messages before it is all said and done. Add in the
virus scanning and spam marking, as well as the delivery of email to the
Cyrus server (running on the same cluster)... well, let's say we kind of
watch the system pretty carefully. So, if we decide to add RBL's, it
will most likely be at the sendmail level to prevent messages from going
through the expensive virus scanning/spam marking route.
We are seriously thinking about moving the virus scanning/spam marking to
a seperate set of machines, either a bank of Linux boxes, or more likely
a blade server that can be easily expanded, and offload all of that from
our main email environment. If we do this, then I can easily see us
putting the RBL checks at the Spam Assassin level, as we can just add
more blades or machines to the environment if we start getting pushed for
But I do see reasons why you would want it at the MailScanner level...
especially if you don't want to reject emails but need to save cycles
wherever you can...
Scott W. Adkins http://www.cns.ohiou.edu/~sadkins/
UNIX Systems Engineer mailto:adkinss at ohio.edu
ICQ 7626282 Work (740)593-9478 Fax (740)593-1944
PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/
-----BEGIN PGP SIGNATURE-----
Version: Mulberry PGP Plugin v2.0
Comment: processed by Mulberry PGP Plugin
-----END PGP SIGNATURE-----
More information about the MailScanner