spamassassin 2.53 & MailScanner

[Scott Adkins]

 <5C0296D26910694BB9A9BBFC577E7AB0011752B6 at pascal.priv.bmrb.co.uk>
 <5.2.0.9.2.20030509083619.03497038 at imap.ecs.soton.ac.uk>
X-Mailer: Mulberry/3.0.3 (Win32)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="==========1278479627=========="

--==========1278479627==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

--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
> www.MailScanner.info
> 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
CPU cycles.

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
--=20
 +-----------------------------------------------------------------------+
      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/
--==========1278479627==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: Mulberry PGP Plugin v2.0
Comment: processed by Mulberry PGP Plugin

iQA/AwUBPrus+6YtNXY159L9EQKskACcCbZGB4CZq4oNWZLk4M7aKdGXC34An33k
2Cj5Qfrgzs+/aVwKniGg99r0
=R24f
-----END PGP SIGNATURE-----

--==========1278479627==========--