great idea, but recipient verification is not something, remote servers like.really like.
Am Freitag, 4. Januar 2019 schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: >> On Jan 4, 2019, at 9:10 AM, Matus UHLAR - fantomas <uh...@fantomas.sk> wrote: >> >> this looks to me that you search for connection between smtpd_recipient_restrictions >> and smtp_tls_policy_maps, and there is none. >> >> the "check_policy_service private/policy" communicates via unix socket >> private/policy (apparetly in postfix directory) to external program that >> tells smtpd what to do. >> >> if you want your policy server to return dunno for sending domain >> "remote-site.de", your policy server must look to the /etc/postfix/tls/finance >> table for the remote-site.de domain. >> >> the policy server doesn't look to your "smtp_tls_policy_maps" settings, >> usually it does not read postfix configuration at all. > > This is where recipient verification has an advantage over a policy > service. For SASL authenticated users, who can relay outbound, the > OP could replace the policy service with a recipient verification > callout: > > smtpd_relay_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > reject_unauth_destination > > smtpd_recipient_restrictions > permit_auth_destination, > reject_unverified_recipient > > This *is* sensitive to outbound TLS policy, because recipient > verification uses outbound SMTP connections to probe for TLS > support, and will fail where TLS is mandated and not available. > > Of course static configuration that are reflected in both the > policy service and the SMTP TLS policy yield more predictable, > if not always up to date behaviour. > > -- > Viktor. > >
