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 <c...@ncxs.de > <mailto:c...@ncxs.de>>: > > 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 > <c...@ncxs.de <mailto:c...@ncxs.de> > > <mailto:c...@ncxs.de <mailto:c...@ncxs.de>>>: > > > > 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 > > > <olivier.nic...@cs.ait.ac.th > <mailto:olivier.nic...@cs.ait.ac.th> > <mailto:olivier.nic...@cs.ait.ac.th > <mailto:olivier.nic...@cs.ait.ac.th>> > > <mailto:olivier.nic...@cs.ait.ac.th > <mailto:olivier.nic...@cs.ait.ac.th> > > <mailto:olivier.nic...@cs.ait.ac.th > <mailto:olivier.nic...@cs.ait.ac.th>>>>: > > > > > > 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 > > > > > >
