Kai,
both are running simultaneously. So at smtpd_recipient_restriction stat
the milter will also get the recipients. As far as I have seen the
postfix restriction react faster.
So if you reject somebody with an access_map, you won't see any scan
result in rspamd. Only the milter connect, because rspamd starts to work
at the end_of_data_restrictions.
Do you have any problems with this situation?
--
Carsten
On 07.11.18 16:10, Kai Schaetzl wrote:
> I'm having trouble with access_maps kicking in after an upgrade from a
> Postfix 2.something to Postfix 3.1. on Ubuntu 14.06 and using postscreen
> and rspamd milter.
>
> After some testing I'm not sure yet, but it looks like the recommended
> smtpd_delay_reject = yes in connection with having the access_map checks
> listed in the smtpd_recipient_restrictions is the cause of this. It allows
> the milter to kick in, so that the access_check (almost?) never happens.
>
> After changing to
> smtpd_delay_reject = no
> and moving the client access_maps to smtpd_client_restrictions they seem
> to be working again.
>
> rspamd is used as a milter (as specified in the rspamd docs) and not as a
> policy service (which would allow putting it at the end of restrictions).
>
> # rspamd
> smtpd_milters = inet:localhost:11332
> milter_protocol = 6
> milter_mail_macros = i {mail_addr} {client_addr} {client_name}
> {auth_authen}
> milter_default_action = accept
>
>
> Is this a known problem? Other workarounds? Can I specify to use the
> milter only after the restrictions? (Maybe doesn't make sense?)
> Or am I misinterpreting something?
>
> Thanks!
>
> Kai
>
>
