On Mon, 19 Jun 2006, Steven W. Orr wrote:
> And this is my point. SA *DOESN'T* work on messages after they have been
> received. Since I use spamass-milter, SA sees the messages before
> reception is completed. (You're free to do otherwise.) Then when SA
> decides that the message doesn't conform to its high standards, the report
> of that fact goes back to spamass-milter which then returns status back to
> sendmail. The current result is a reject 5xx status. So all we need is for
> SA to manage one extra table and to allow some sort of reportage that
> spamass-milter could be mucked to understand.
>
> Is this making sense?
Yes, but IMHO you are trying to use the wrong tool for the job.
greylisting is a relativly lightweight task and can be done quickly
(IE no DNS/network lookups needed, only need envelope-from, envelope-to,
sending host IP addr, no need to absorb the whole message body,
very small CPU load ,etc) so it should be done -before- you waste
resources running a full SA scan.
I would suggest sendmail milter configured so that first you run the
greylisting milter, then the virus-scan milter and finally the SA
milter.
I can see your argument for needing some kind of persistant table
backend for greylisting but that looks like an arugment for building
a MySQL backend for greylisting, not trying to mung greylisting into SA.
The only reason that I can see for trying to combine greylisting & SA
is to have an adaptive greylist, one that only kicks in if the message
has a high-enough score (but still lower than spam-tagging threshold).
However you would loose the load reduction benefit of the previously
mentioned config.
Dave
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
