> On Fri, Jun 19, 2015, at 07:56 AM, Viktor Dukhovni wrote: Thanks for digging into this.
> As soon as I saw this, I said to myself "it'll loop". Not > surprisingly, it does. I'll trust the stmt, and need to stare at the flow more closely to be able to come to the same immediate conclusion. > DO NOT attempt to use the transport table to route spam into filter > scripts by recipient address, after the mail is filtered, it will > again be sent to the filter, ad nauseam. Removed, thanks. > Instead you'll need FILTER overrides via smtpd access(5) or > cleanup header/body checks, that are added in front of the filter, > and NOT added by post-filter re-injection. > > http://www.postfix.org/FILTER_README.html In applying the filter, the docs suggest "You can do this in smtpd access maps as well as the cleanup server's header/body_checks." I'm selecting to use an smtpd access map. Reconfig to /main.cf ... - transport_maps = lmdb:/usr/local/etc/postfix/salearn_transport - static:relay-vpn:[internal.mail-backend.DDDD.com]:12345 + transport_maps = static:relay-vpn:[internal.mail-backend.DDDD.com]:12345 ... smtpd_relay_restrictions = + check_sender_access lmdb:/usr/local/etc/postfix/salearn_filter permit_mynetworks reject_unauth_destination reject_unverified_recipient check_policy_service unix:private/policyd-spf ... /salearn_filter spam.1...@dddd.com FILTER sa-spam ham.1...@dddd.com FILTER sa-ham However, on send to 'ham.1...@dddd.com', it's still routing to the relay transport, relay-vpn:, Jun 19 09:01:12 mailhost postfix/relay-vpn/smtp[21748]: 615BD6450F: to=<ham.1...@mail.dddd.com>, relay=internal.mail-backend.DDDD.com[10.2.1.16]:25, delay=0.29, delays=0/0/0.24/0.04, dsn=5.7.1, status=undeliverable (host internal.mail-backend.DDDD.com[10.2.1.16] said: 554 5.7.1 <ham.1...@mail.dddd.com>: Relay access denied (in reply to RCPT TO command)) IIUC from an earlier post, the EXECUTION ORDER in Postfix is postscreen, smtpd_mumble_restrictions, milter SMTP command inspection, smtpd_proxy_filter, header/body_checks, milter header/body inspection, content_filter so my mumble restriction should be applied ealiest. Is the problem here that the precedence of "transport_maps" > "smtpd_relay_restrictions=check_sender_access ..."? if not in smtpd_relay_restrictions, how/where should the smtpd access mapping be defined for these two addresses to get properly piped? I suspect I may need to add a mumble restriction directly into master.cf?
