* Mike Schleif <
mi...@mdsresource.net>:
> Centos: 7.2.1511 (Core)
> postfix: 2.10.1
> amavisd-new: 2.10.1
>
> This postfix server was designed to run as follows, which it has done for
> several months without incident:
>
> Original filter-only:
>
master.cf:
> smtp inet n - n - - smtpd
> -o content_filter=filter:dummy
>
> filter unix - n n - 10 pipe
> flags=Rq user=filter null_sender=
> argv=/var/spool/filter/bin/filter.sh -f ${sender} -- ${recipient}
>
>
> Now, I'm tasked with retrofitting spamassassin on same host, which works
> using
> following configuration:
>
> Spamassassin-only:
>
master.cf:
> smtp inet n - n - - smtpd
> -o content_filter=spamassassin
>
> spamassassin unix - n n - - pipe
> user=spamd argv=/usr/bin/spamc -f -e
> /usr/sbin/sendmail -oi -f ${sender} ${recipient}
>
>
> Our problem is using _both_ spamassassin and filter, preferably in that
> order.
amavis seems a little over if all you need is spamassassin. You might get away
with less, if you hook spamassassin into Postfix via the spamassassin MILTER
program "spamass-milter".
Using spamass-milter you will be able to pre-queue scan messages. Spamassassin
can classify the messages and add a score. Then the message will be accepted,
written to the queue and sent of to your filter.sh script.
In pseudo-code:
smtp inet n - n - - smtpd
-o smtpd_milters=inet:
127.0.0.1:20025
-o content_filter=spamassassin
spamassassin unix - n n - - pipe
user=spamd argv=/usr/bin/spamc -f -e
/usr/sbin/sendmail -oi -f ${sender} ${recipient}
inet:
127.0.0.1:20025 would be where the spamass-milter listens for incoming
connections. It would pass on the message via spamc to spamd. The scan result
would be handed back in reverse order.
p@rick