[SAtalk] New Postfix & SpamAssassin Step-By-Step Guide

[Jeffrey Posluns (List Address)]

Hi all,

I've just posted a new guide in my series of Postfix Anti-Spam
documents. This one is a step-by-step guide to getting Postfix working
with SpamAssassin as per the configuration that I like using.

Comments and constructive criticism are welcome.

The guide can be found here:
http://www.securitysage.com/guides/postfix_uce_steps.html

Regards,
_______________
Jeffrey Posluns, CISA, CISSP, SSCP, CCNP, CCDA, GSEC
Information Security Management Consultant
SecuritySage Inc.
Tel: (514) 995-4987
http://www.securitysage.com

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Spamassassin-talk mailing list
Spamassa...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk

[Victor....@morganstanley.com]

On Sun, 12 Oct 2003, Jeffrey Posluns wrote:

> The guide can be found here:
> http://www.securitysage.com/guides/postfix_uce_steps.html
>

You do not state which version of Postfix is covered, but the details are
in fact version specific. It is better to direct the user to FILTER_README
for their particular Postfix release.

The data flow is highly sub-optimal. Instead of having filters directly
chained:

Postfix -> Filter1 -> Filter2 -> Postfix

You appear to recommend:

Postfix -> Filter1 -> Postfix -> Filter2 -> Postfix

The extra hop through Postfix adds substantial I/O cost and latency.

The only possible motivation for such a design would be if Filter1 and
Filter2 had vastly different CPU/latency characteristics requiring a high
concurrency through the high latency low CPU cost filter and a low
concurrency through the low latency high CPU cost filter. In such an
unlikey case the Postfix queue would provide a buffer to smooth out the
"impedance mismatch" between the two filters. It doubt that this is going
to be common enough to justify recomending it by default, the extra I/O
penaly (3 queue trips instead of 2) can substantially lower system
throughput.

Compilation instructions for Postfix do not belong on the SA integration
page, just because one wants SA, one does not necessarily also want SASL,
...

The SA configuration file is provided with no discusion of the chosen
parameters. What makes those particular values magic?

Finally, consider recommending much smaller (~ 100 fold)
header_checks/body_checks files, especially one SA is installed. The
scoring system in SA is much less crude than header and body checks, and
tagging allows each user to make suitable decisions downstream.

By the way does the SA configuration you describe block mail or tag it?
How aggressive is it? ...

--
Viktor.