best practice - integrating spamassassin/clamav in postfix - amavis yes/no?

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

best practice - integrating spamassassin/clamav in postfix - amavis yes/no?

Stefan Bauer-2
Dear Users,

I'm building a simple pair of front MX-servers to get rid of our cisco ironports. For spam and virus-scanning i'd like to have spamassassin and clamav doing pre-filtering during smtp-dialog rejecting bad mails and forwarding good mails to internal mail-farm.

Is it best practice to use amavis in between postfix and clamd/spamasassin? i would like to keep the setup as simple as possible and not having another component in place (amavis) when this can be avoided. I see the internet is full of setups with amavis but i dont see the reason for having another software running.

What is your opinion?

thank you.

Stefan
Reply | Threaded
Open this post in threaded view
|

Re: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?

Olivier Nicole-2
Hi,

> I'm building a simple pair of front MX-servers to get rid of our cisco ironports. For spam and
> virus-scanning i'd like to have spamassassin and clamav doing pre-filtering during smtp-dialog
> rejecting bad mails and forwarding good mails to internal mail-farm.

While for virus you may argue that there is a clear cut between clean
and infected message, it is far from being as clear for spam. What you
consider spam and would reject may be completly valid for another user.

So, rejecting spam during smtp-dialog is risky, that is why most resolve
to some sort of quarantine, and that is when amavis comes handy.

Best regards,

Olivier
Reply | Threaded
Open this post in threaded view
|

Re: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?

Stefan Bauer-2
Thank you for your feedback. Seems like smtpd_milters are also used before any other check_*_access and rbl checks/header checks etc., so it's expensive this way, to pipe every mail through virus scan.
I'm just testing if i could plug in clamav by check_policy_service.

Am Fr., 19. Okt. 2018 um 05:57 Uhr schrieb Olivier <[hidden email]>:
Hi,

> I'm building a simple pair of front MX-servers to get rid of our cisco ironports. For spam and
> virus-scanning i'd like to have spamassassin and clamav doing pre-filtering during smtp-dialog
> rejecting bad mails and forwarding good mails to internal mail-farm.

While for virus you may argue that there is a clear cut between clean
and infected message, it is far from being as clear for spam. What you
consider spam and would reject may be completly valid for another user.

So, rejecting spam during smtp-dialog is risky, that is why most resolve
to some sort of quarantine, and that is when amavis comes handy.

Best regards,

Olivier
Reply | Threaded
Open this post in threaded view
|

Re: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?

Carsten Rosenberg
Hi,

smtp_milters and restrictions are working at the same time.
smtpd_recipient_restriction will be evaluated at the same as the Milter
RCPT stage.

So a ClamAV Milter should run at EOM milter stage. Anything else is
useless ;)

And in my opinion quarantine is sooo 2010. Reject (pre-queue) or
deliver, so it's clear for sender and recipient.

Have a look to amavis-milter (+spamassassin+clamav) or even rspamd.


Carsten

On 19.10.18 07:15, Stefan Bauer wrote:

> Thank you for your feedback. Seems like smtpd_milters are also used
> before any other check_*_access and rbl checks/header checks etc., so
> it's expensive this way, to pipe every mail through virus scan.
> I'm just testing if i could plug in clamav by check_policy_service.
>
> Am Fr., 19. Okt. 2018 um 05:57 Uhr schrieb Olivier
> <[hidden email] <mailto:[hidden email]>>:
>
>     Hi,
>
>     > I'm building a simple pair of front MX-servers to get rid of our
>     cisco ironports. For spam and
>     > virus-scanning i'd like to have spamassassin and clamav doing
>     pre-filtering during smtp-dialog
>     > rejecting bad mails and forwarding good mails to internal mail-farm.
>
>     While for virus you may argue that there is a clear cut between clean
>     and infected message, it is far from being as clear for spam. What you
>     consider spam and would reject may be completly valid for another user.
>
>     So, rejecting spam during smtp-dialog is risky, that is why most resolve
>     to some sort of quarantine, and that is when amavis comes handy.
>
>     Best regards,
>
>     Olivier
>
Reply | Threaded
Open this post in threaded view
|

Re: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?

Stefan Bauer-2
Is there documentation available, at which smtp-state a milter is kicking in?
I don't see a way to define at which state a milter should take action.

i would lke to make sure that

smtpd_milters = unix:/clamav/clamav-milter.ctl

will only get triggered after

smtpd_recipient_restrictions =
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,

is checked.

amavis-milter seems dead.


Am Fr., 19. Okt. 2018 um 08:33 Uhr schrieb Carsten Rosenberg <[hidden email]>:
Hi,

smtp_milters and restrictions are working at the same time.
smtpd_recipient_restriction will be evaluated at the same as the Milter
RCPT stage.

So a ClamAV Milter should run at EOM milter stage. Anything else is
useless ;)

And in my opinion quarantine is sooo 2010. Reject (pre-queue) or
deliver, so it's clear for sender and recipient.

Have a look to amavis-milter (+spamassassin+clamav) or even rspamd.


Carsten

On 19.10.18 07:15, Stefan Bauer wrote:
> Thank you for your feedback. Seems like smtpd_milters are also used
> before any other check_*_access and rbl checks/header checks etc., so
> it's expensive this way, to pipe every mail through virus scan.
> I'm just testing if i could plug in clamav by check_policy_service.
>
> Am Fr., 19. Okt. 2018 um 05:57 Uhr schrieb Olivier
> <[hidden email] <mailto:[hidden email]>>:
>
>     Hi,
>
>     > I'm building a simple pair of front MX-servers to get rid of our
>     cisco ironports. For spam and
>     > virus-scanning i'd like to have spamassassin and clamav doing
>     pre-filtering during smtp-dialog
>     > rejecting bad mails and forwarding good mails to internal mail-farm.
>
>     While for virus you may argue that there is a clear cut between clean
>     and infected message, it is far from being as clear for spam. What you
>     consider spam and would reject may be completly valid for another user.
>
>     So, rejecting spam during smtp-dialog is risky, that is why most resolve
>     to some sort of quarantine, and that is when amavis comes handy.
>
>     Best regards,
>
>     Olivier
>
Reply | Threaded
Open this post in threaded view
|

Re: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?

Carsten Rosenberg
Have a look here:

https://msg.wikidoc.info/index.php/Milter_operation

Milter Protocol starts when a client connects. So you have the open
connection to clamav-milter before smtpd_recipient_restrictions is
triggered. But ClamAV can't do anything before the content is
transfered. So the performance impact should be insignificant.

amavis-milter is just a wrapper script from milter to amavis protocol.
As long amavis is not dead this is fine.

Carsten


On 19.10.18 08:59, Stefan Bauer wrote:

> Is there documentation available, at which smtp-state a milter is
> kicking in?
> I don't see a way to define at which state a milter should take action.
>
> i would lke to make sure that
>
> smtpd_milters = unix:/clamav/clamav-milter.ctl
>
> will only get triggered *after *
>
> smtpd_recipient_restrictions =
> reject_non_fqdn_sender,
> reject_non_fqdn_recipient,
> reject_unknown_sender_domain,
> reject_unknown_recipient_domain,
>
> is checked.
>
> amavis-milter seems dead.
>
>
> Am Fr., 19. Okt. 2018 um 08:33 Uhr schrieb Carsten Rosenberg <[hidden email]
> <mailto:[hidden email]>>:
>
>     Hi,
>
>     smtp_milters and restrictions are working at the same time.
>     smtpd_recipient_restriction will be evaluated at the same as the Milter
>     RCPT stage.
>
>     So a ClamAV Milter should run at EOM milter stage. Anything else is
>     useless ;)
>
>     And in my opinion quarantine is sooo 2010. Reject (pre-queue) or
>     deliver, so it's clear for sender and recipient.
>
>     Have a look to amavis-milter (+spamassassin+clamav) or even rspamd.
>
>
>     Carsten
>
>     On 19.10.18 07:15, Stefan Bauer wrote:
>     > Thank you for your feedback. Seems like smtpd_milters are also used
>     > before any other check_*_access and rbl checks/header checks etc., so
>     > it's expensive this way, to pipe every mail through virus scan.
>     > I'm just testing if i could plug in clamav by check_policy_service.
>     >
>     > Am Fr., 19. Okt. 2018 um 05:57 Uhr schrieb Olivier
>     > <[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>>:
>     >
>     >     Hi,
>     >
>     >     > I'm building a simple pair of front MX-servers to get rid of our
>     >     cisco ironports. For spam and
>     >     > virus-scanning i'd like to have spamassassin and clamav doing
>     >     pre-filtering during smtp-dialog
>     >     > rejecting bad mails and forwarding good mails to internal
>     mail-farm.
>     >
>     >     While for virus you may argue that there is a clear cut
>     between clean
>     >     and infected message, it is far from being as clear for spam.
>     What you
>     >     consider spam and would reject may be completly valid for
>     another user.
>     >
>     >     So, rejecting spam during smtp-dialog is risky, that is why
>     most resolve
>     >     to some sort of quarantine, and that is when amavis comes handy.
>     >
>     >     Best regards,
>     >
>     >     Olivier
>     >
>
Reply | Threaded
Open this post in threaded view
|

Re: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?

Stefan Bauer-2
Thank you. So it makes sense to have all smtpd_recipient_restrictions in place, and _only if_ the client passes all checks, clamav or spamasassin is having data available to do a check. If the client fails a check, clamav/spamasassin have nothing to process. Did i get it correctly? :)

Stefan

Am Fr., 19. Okt. 2018 um 09:17 Uhr schrieb Carsten Rosenberg <[hidden email]>:
Have a look here:

https://msg.wikidoc.info/index.php/Milter_operation

Milter Protocol starts when a client connects. So you have the open
connection to clamav-milter before smtpd_recipient_restrictions is
triggered. But ClamAV can't do anything before the content is
transfered. So the performance impact should be insignificant.

amavis-milter is just a wrapper script from milter to amavis protocol.
As long amavis is not dead this is fine.

Carsten


On 19.10.18 08:59, Stefan Bauer wrote:
> Is there documentation available, at which smtp-state a milter is
> kicking in?
> I don't see a way to define at which state a milter should take action.
>
> i would lke to make sure that
>
> smtpd_milters = unix:/clamav/clamav-milter.ctl
>
> will only get triggered *after *
>
> smtpd_recipient_restrictions =
> reject_non_fqdn_sender,
> reject_non_fqdn_recipient,
> reject_unknown_sender_domain,
> reject_unknown_recipient_domain,
>
> is checked.
>
> amavis-milter seems dead.
>
>
> Am Fr., 19. Okt. 2018 um 08:33 Uhr schrieb Carsten Rosenberg <[hidden email]
> <mailto:[hidden email]>>:
>
>     Hi,
>
>     smtp_milters and restrictions are working at the same time.
>     smtpd_recipient_restriction will be evaluated at the same as the Milter
>     RCPT stage.
>
>     So a ClamAV Milter should run at EOM milter stage. Anything else is
>     useless ;)
>
>     And in my opinion quarantine is sooo 2010. Reject (pre-queue) or
>     deliver, so it's clear for sender and recipient.
>
>     Have a look to amavis-milter (+spamassassin+clamav) or even rspamd.
>
>
>     Carsten
>
>     On 19.10.18 07:15, Stefan Bauer wrote:
>     > Thank you for your feedback. Seems like smtpd_milters are also used
>     > before any other check_*_access and rbl checks/header checks etc., so
>     > it's expensive this way, to pipe every mail through virus scan.
>     > I'm just testing if i could plug in clamav by check_policy_service.
>     >
>     > Am Fr., 19. Okt. 2018 um 05:57 Uhr schrieb Olivier
>     > <[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>>:
>     >
>     >     Hi,
>     >
>     >     > I'm building a simple pair of front MX-servers to get rid of our
>     >     cisco ironports. For spam and
>     >     > virus-scanning i'd like to have spamassassin and clamav doing
>     >     pre-filtering during smtp-dialog
>     >     > rejecting bad mails and forwarding good mails to internal
>     mail-farm.
>     >
>     >     While for virus you may argue that there is a clear cut
>     between clean
>     >     and infected message, it is far from being as clear for spam.
>     What you
>     >     consider spam and would reject may be completly valid for
>     another user.
>     >
>     >     So, rejecting spam during smtp-dialog is risky, that is why
>     most resolve
>     >     to some sort of quarantine, and that is when amavis comes handy.
>     >
>     >     Best regards,
>     >
>     >     Olivier
>     >
>
Reply | Threaded
Open this post in threaded view
|

Re: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?

Andreas Schamanek
In reply to this post by Olivier Nicole-2

On Fri, 19 Oct 2018, at 10:57, Olivier wrote:

> So, rejecting spam during smtp-dialog is risky, that is why most
> resolve to some sort of quarantine, and that is when amavis comes
> handy.

I agree with the 1st part but that's why I ditched Amavis! If your
mail delivery setup includes anything anywhere that can call your spam
filter you may not need Amavis. In my case I happen to have Procmail
anyway. The filter of my choice is SpamAssassin. So, no need for
anything in between.

My recommendation is to use Postfix with postscreen including a
reasonable set of dnsbls, plus a spam filter as far as possible at the
end of the processing chain so that it gets called only on mail that
is neither clearly ham nor spam.

Postscreen alone allowed me to ditch ClamAV. After evaluating logs of
1 year the hit rate was about 1 of 2k messages of which 100% were
flagged by SpamAssassin. Hit rate increased somewhat with the use of
third-party signatures, but these detected pratically only scams and
phishing attempts which IMHO need to be distinguished from the
classical type of viruses. Indeed, they also caused a number of false
positives.

Again, note that my findings are based on the fact that Postfix with
postscreen itself blocks the by far largest part of malicious mail.

Of course, YMMV,

--
-- Andreas

     :-)

Reply | Threaded
Open this post in threaded view
|

Re: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?

Carsten Rosenberg
In reply to this post by Stefan Bauer-2
yes

On 19.10.18 09:29, Stefan Bauer wrote:

> Thank you. So it makes sense to have all smtpd_recipient_restrictions in
> place, and _only if_ the client passes all checks, clamav or spamasassin
> is having data available to do a check. If the client fails a check,
> clamav/spamasassin have nothing to process. Did i get it correctly? :)
>
> Stefan
>
> Am Fr., 19. Okt. 2018 um 09:17 Uhr schrieb Carsten Rosenberg <[hidden email]
> <mailto:[hidden email]>>:
>
>     Have a look here:
>
>     https://msg.wikidoc.info/index.php/Milter_operation
>
>     Milter Protocol starts when a client connects. So you have the open
>     connection to clamav-milter before smtpd_recipient_restrictions is
>     triggered. But ClamAV can't do anything before the content is
>     transfered. So the performance impact should be insignificant.
>
>     amavis-milter is just a wrapper script from milter to amavis protocol.
>     As long amavis is not dead this is fine.
>
>     Carsten
>
>
>     On 19.10.18 08:59, Stefan Bauer wrote:
>     > Is there documentation available, at which smtp-state a milter is
>     > kicking in?
>     > I don't see a way to define at which state a milter should take
>     action.
>     >
>     > i would lke to make sure that
>     >
>     > smtpd_milters = unix:/clamav/clamav-milter.ctl
>     >
>     > will only get triggered *after *
>     >
>     > smtpd_recipient_restrictions =
>     > reject_non_fqdn_sender,
>     > reject_non_fqdn_recipient,
>     > reject_unknown_sender_domain,
>     > reject_unknown_recipient_domain,
>     >
>     > is checked.
>     >
>     > amavis-milter seems dead.
>     >
>     >
>     > Am Fr., 19. Okt. 2018 um 08:33 Uhr schrieb Carsten Rosenberg
>     <[hidden email] <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>>:
>     >
>     >     Hi,
>     >
>     >     smtp_milters and restrictions are working at the same time.
>     >     smtpd_recipient_restriction will be evaluated at the same as
>     the Milter
>     >     RCPT stage.
>     >
>     >     So a ClamAV Milter should run at EOM milter stage. Anything
>     else is
>     >     useless ;)
>     >
>     >     And in my opinion quarantine is sooo 2010. Reject (pre-queue) or
>     >     deliver, so it's clear for sender and recipient.
>     >
>     >     Have a look to amavis-milter (+spamassassin+clamav) or even
>     rspamd.
>     >
>     >
>     >     Carsten
>     >
>     >     On 19.10.18 07:15, Stefan Bauer wrote:
>     >     > Thank you for your feedback. Seems like smtpd_milters are
>     also used
>     >     > before any other check_*_access and rbl checks/header checks
>     etc., so
>     >     > it's expensive this way, to pipe every mail through virus scan.
>     >     > I'm just testing if i could plug in clamav by
>     check_policy_service.
>     >     >
>     >     > Am Fr., 19. Okt. 2018 um 05:57 Uhr schrieb Olivier
>     >     > <[hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     >     <mailto:[hidden email]
>     <mailto:[hidden email]>
>     >     <mailto:[hidden email]
>     <mailto:[hidden email]>>>>:
>     >     >
>     >     >     Hi,
>     >     >
>     >     >     > I'm building a simple pair of front MX-servers to get
>     rid of our
>     >     >     cisco ironports. For spam and
>     >     >     > virus-scanning i'd like to have spamassassin and
>     clamav doing
>     >     >     pre-filtering during smtp-dialog
>     >     >     > rejecting bad mails and forwarding good mails to internal
>     >     mail-farm.
>     >     >
>     >     >     While for virus you may argue that there is a clear cut
>     >     between clean
>     >     >     and infected message, it is far from being as clear for
>     spam.
>     >     What you
>     >     >     consider spam and would reject may be completly valid for
>     >     another user.
>     >     >
>     >     >     So, rejecting spam during smtp-dialog is risky, that is why
>     >     most resolve
>     >     >     to some sort of quarantine, and that is when amavis
>     comes handy.
>     >     >
>     >     >     Best regards,
>     >     >
>     >     >     Olivier
>     >     >
>     >
>
Reply | Threaded
Open this post in threaded view
|

Re: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?

Curtis Maurand
In reply to this post by Carsten Rosenberg
October 19 2018 3:17 AM, "Carsten Rosenberg" <[hidden email]> wrote:
> amavis-milter is just a wrapper script from milter to amavis protocol.
> As long amavis is not dead this is fine.
>

This is off-topic a bit, but amavis just got an update to 2.11.1 and the project has been transferred to a new group for management from the author.  This happened within the last couple of weeks.  I'm on that mailing list, too.  They're working on getting the changes into the package repos.  Amavis just received a new lease on life.

Back to the discussion at hand,

--Curtis
Reply | Threaded
Open this post in threaded view
|

Re: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?

Ralph Seichter
In reply to this post by Stefan Bauer-2
On 19.10.18 05:39, Stefan Bauer wrote:

> Is it best practice to use amavis in between postfix and
> clamd/spamasassin?

It is certainly a well proven approach to use amavis as the glue that
binds Postfix, Spam- and Virus-Checkers together. Even DKIM-signing and
-verification are supported. I like amavis for that.

-Ralph
Reply | Threaded
Open this post in threaded view
|

Re: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?

Matus UHLAR - fantomas
In reply to this post by Olivier Nicole-2
>> I'm building a simple pair of front MX-servers to get rid of our cisco ironports. For spam and
>> virus-scanning i'd like to have spamassassin and clamav doing pre-filtering during smtp-dialog
>> rejecting bad mails and forwarding good mails to internal mail-farm.

On 19.10.18 10:57, Olivier wrote:
>While for virus you may argue that there is a clear cut between clean
>and infected message,

not even - clamav, especially third party signatures, tend to block phish
messages, which (surprise) can be interesting for some.

> it is far from being as clear for spam. What you
>consider spam and would reject may be completly valid for another user.
>
>So, rejecting spam during smtp-dialog is risky, that is why most resolve
>to some sort of quarantine, and that is when amavis comes handy.

both spamass-milter and amavisd-milter have ways only to reject spam scoring
over some threshold.
Will pass some possible spam, but rejects much od it.

I don't trust in quarantines much, someone must take care of them and not
forget/miss anything.


--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Honk if you love peace and quiet.
Reply | Threaded
Open this post in threaded view
|

Re: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?

Bill Cole-3
In reply to this post by Stefan Bauer-2
On 18 Oct 2018, at 23:39, Stefan Bauer wrote:

> Dear Users,
>
> I'm building a simple pair of front MX-servers to get rid of our cisco
> ironports. For spam and virus-scanning i'd like to have spamassassin
> and
> clamav doing pre-filtering during smtp-dialog rejecting bad mails and
> forwarding good mails to internal mail-farm.
>
> Is it best practice to use amavis in between postfix and
> clamd/spamasassin?

It is common and useful.

An alternative to Amavis is MIMEDefang, a milter that supports a variety
of AV tools, SpamAssassin, robust MIME-aware message modification, and
doing anything with or to mail that you can write the Perl for.

It is noteworthy that 2 such robust message filtering tools that act as
hubs for integrating other tools exist. The architectural model is
useful because it helps keep the Postfix config simpler and adds
functionality such as the ability to define an order in which filters
operate without resorting to layered smtpd's or after-queue filtering.

> i would like to keep the setup as simple as possible and not having
> another
> component in place (amavis) when this can be avoided. I see the
> internet is
> full of setups with amavis but i dont see the reason for having
> another
> software running.
>
> What is your opinion?

I use MIMEDefang, not because Amavis is bad (it's not) but because I
prefer to have *all* of my message filtering & manipulation handled in
one place and I've been using MD longer than Postfix. Postfix is NOT a
robust message manipulation tool, it is a robust mail routing &
transport tool. Having all work with message content isolated outside of
Postfix proper makes the whole system more comprehensible &
maintainable.

--
Bill Cole
Reply | Threaded
Open this post in threaded view
|

Re: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?

Bill Cole-3
In reply to this post by Stefan Bauer-2
On 19 Oct 2018, at 1:15, Stefan Bauer wrote:

> Seems like smtpd_milters are also used before
> any other check_*_access and rbl checks/header checks etc.,

Incorrect.

All of the smtpd restriction lists (except for the rarely-used
smtpd_end_of_data_restrictions) operate before any message data is seen
by Postfix. Milters *can* operate at any step of the SMTP transaction on
whatever information is available at those times, but message data
filtering can obviously only work at end-of-data time.

--
Bill Cole
Reply | Threaded
Open this post in threaded view
|

Re: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?

Stefan Bauer-2
In reply to this post by Andreas Schamanek
Hi Andreas,

i really like postscreen. There are quite some nice tricks buikd in so thanks again for pushing me in this direction.

i just bundled it now with clamav-milter so the expensive checks are only triggered when a client survives postscreen and all my additional sender/recipient checks and finally a recipient verification.

i'm happy now - looks like a sane setup. Cant wait to see first spammers ;)

Stefan

Am Freitag, 19. Oktober 2018 schrieb Andreas Schamanek :

>
> On Fri, 19 Oct 2018, at 10:57, Olivier wrote:
>
>> So, rejecting spam during smtp-dialog is risky, that is why most resolve to some sort of quarantine, and that is when amavis comes handy.
>
> I agree with the 1st part but that's why I ditched Amavis! If your mail delivery setup includes anything anywhere that can call your spam filter you may not need Amavis. In my case I happen to have Procmail anyway. The filter of my choice is SpamAssassin. So, no need for anything in between.
>
> My recommendation is to use Postfix with postscreen including a reasonable set of dnsbls, plus a spam filter as far as possible at the end of the processing chain so that it gets called only on mail that is neither clearly ham nor spam.
>
> Postscreen alone allowed me to ditch ClamAV. After evaluating logs of 1 year the hit rate was about 1 of 2k messages of which 100% were flagged by SpamAssassin. Hit rate increased somewhat with the use of third-party signatures, but these detected pratically only scams and phishing attempts which IMHO need to be distinguished from the classical type of viruses. Indeed, they also caused a number of false positives.
>
> Again, note that my findings are based on the fact that Postfix with postscreen itself blocks the by far largest part of malicious mail.
>
> Of course, YMMV,
>
> --
> -- Andreas
>
>     :-)
>
>
Reply | Threaded
Open this post in threaded view
|

Re: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?

pg151
In reply to this post by Bill Cole-3


On Fri, Oct 19, 2018, at 8:37 AM, Bill Cole wrote:
> I use MIMEDefang, not because Amavis is bad (it's not) but because I
> prefer to have *all* of my message filtering & manipulation handled in
> one place and I've been using MD longer than Postfix. Postfix is NOT a
> robust message manipulation tool, it is a robust mail routing &
> transport tool. Having all work with message content isolated outside of
> Postfix proper makes the whole system more comprehensible &
> maintainable.

I've read numerous references to MIMEDefang, including yours of course.

Never used it personally, yet, but iiuc, it's been around a long while.

Is there any particular significance to the complete lack of its mention on:

  http://www.postfix.org/addon.html

which _seems_ to list 'everything else' out there ... or, for that matter, anywhere else on the site.
Reply | Threaded
Open this post in threaded view
|

Re: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?

Wietse Venema
[hidden email]:

>
>
> On Fri, Oct 19, 2018, at 8:37 AM, Bill Cole wrote:
> > I use MIMEDefang, not because Amavis is bad (it's not) but because I
> > prefer to have *all* of my message filtering & manipulation handled in
> > one place and I've been using MD longer than Postfix. Postfix is NOT a
> > robust message manipulation tool, it is a robust mail routing &
> > transport tool. Having all work with message content isolated outside of
> > Postfix proper makes the whole system more comprehensible &
> > maintainable.
>
> I've read numerous references to MIMEDefang, including yours of course.
>
> Never used it personally, yet, but iiuc, it's been around a long while.
>
> Is there any particular significance to the complete lack of its mention on:
>
>   http://www.postfix.org/addon.html
>
> which _seems_ to list 'everything else' out there ... or, for that matter, anywhere else on the site.

The page is not actively maintained, only when someone sends an update.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?

Bill Cole-3
In reply to this post by pg151
On 19 Oct 2018, at 12:54, [hidden email] wrote:

> On Fri, Oct 19, 2018, at 8:37 AM, Bill Cole wrote:
>> I use MIMEDefang, not because Amavis is bad (it's not) but because I
>> prefer to have *all* of my message filtering & manipulation handled
>> in
>> one place and I've been using MD longer than Postfix. Postfix is NOT
>> a
>> robust message manipulation tool, it is a robust mail routing &
>> transport tool. Having all work with message content isolated outside
>> of
>> Postfix proper makes the whole system more comprehensible &
>> maintainable.
>
> I've read numerous references to MIMEDefang, including yours of
> course.
>
> Never used it personally, yet, but iiuc, it's been around a long
> while.

Since 2000, if I recall correctly.

> Is there any particular significance to the complete lack of its
> mention on:
>
>   http://www.postfix.org/addon.html

Certainly. It is very strong evidence that no one has ever bothered
emailing Dr. Venema to ask for its inclusion there.

> which _seems_ to list 'everything else' out there ... or, for that
> matter, anywhere else on the site.

I think that overstates how comprehensive that list is.
Reply | Threaded
Open this post in threaded view
|

Re: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?

pg151


On Fri, Oct 19, 2018, at 10:31 AM, Bill Cole wrote:

> > Is there any particular significance to the complete lack of its
> > mention on:
> >
> >   http://www.postfix.org/addon.html
>
> Certainly. It is very strong evidence that no one has ever bothered
> emailing Dr. Venema to ask for its inclusion there.

That option struck me as improbable, but ok.

> > which _seems_ to list 'everything else' out there ... or, for that
> > matter, anywhere else on the site.
>
> I think that overstates how comprehensive that list is.

Hence the _underscore_ & 'quote' :-)

Thx for the comments!
Reply | Threaded
Open this post in threaded view
|

RE: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?

Kevin Miller
In reply to this post by Stefan Bauer-2

If you’re only going to use clamAV, look into the sanesecurity unofficial signatures to augment the default clamAV signatures.  Your detection rate will be much better.  Using an additional AV may be a good idea as well, although that’s probably a “bring money” proposition.  Much cheaper than cleaning up an infected network however!

 

...Kevin

--

Kevin Miller

Network/email Administrator, CBJ MIS Dept.

155 South Seward Street

Juneau, Alaska 99801

Phone: (907) 586-0242, Fax: (907) 586-4588 Registered Linux User No: 307357

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Stefan Bauer
Sent: Thursday, October 18, 2018 7:40 PM
To: Postfix users
Subject: best practice - integrating spamassassin/clamav in postfix - amavis yes/no?

 

Dear Users,

 

I'm building a simple pair of front MX-servers to get rid of our cisco ironports. For spam and virus-scanning i'd like to have spamassassin and clamav doing pre-filtering during smtp-dialog rejecting bad mails and forwarding good mails to internal mail-farm.

 

Is it best practice to use amavis in between postfix and clamd/spamasassin? i would like to keep the setup as simple as possible and not having another component in place (amavis) when this can be avoided. I see the internet is full of setups with amavis but i dont see the reason for having another software running.

 

What is your opinion?

 

thank you.

 

Stefan