DevHeads.net

smtp_tls_policy_maps on a per tls user basis

Hi,

is there a way to specify on a per user basis (sasl authenticated user) if
TLS should be none or may or encrypted for a specific recipient domain?

I would like to have the user to decide if his mail to a specific domain
should be TLS encrypted and then maybe bounce back but let other users
mails to same destination domain go ahead with a may or none.

Comments

Re: smtp_tls_policy_maps on a per tls user basis

By Wietse Venema at 09/09/2018 - 09:27

Stefan Bauer:
There is no "per-recipient map" version for Postfix SMTP client
parameters (or most other parameters). It does not make sense,
because
- One message may have multiple recipients.
- One connection may deliver multiple messages.
- TLS is a connection property, not a recipient property.

Instead, you can use transport_maps to choose between different
Postfix SMTP clients (with different configurations) based on the
recipient address or domain.

You can use the access map or header/body_checks FILTER action
("FILTER name-of-transport:", without a domain after the ":") to
choose delivery methods based on other message properties, with
some loss of elegance.

That should be possible: use the transport_maps to choose between
one Postfix SMTP client that requires TLS, and one Postfix SMTP
client that does not. This should even work when an encrypted
connection is reused (smtp_tls_connection_reuse = yes).

Wietse

Re: smtp_tls_policy_maps on a per tls user basis

By Stefan Bauer at 09/09/2018 - 14:39

Am Sonntag, 9. September 2018 schrieb Wietse Venema :
I see no way to combine both. I want to enforce tls for sender1 to
google.com but not for sender2 to google.com.

Re: smtp_tls_policy_maps on a per tls user basis

By Andreas Schulze at 09/10/2018 - 01:25

Stefan Bauer:

you may route messages from sender1 to a second postfix instance
and configure that instance to enforce tls to $destination for _any_ sender

Andreas

Re: smtp_tls_policy_maps on a per tls user basis

By Viktor Dukhovni at 09/10/2018 - 09:39

So far, it looks like a single instance with per-sender-class
transports will suffice.

Re: smtp_tls_policy_maps on a per tls user basis

By Patrick Ben Koetter at 09/09/2018 - 15:01

* Stefan Bauer < ... at googlemail dot com>:
Use two Postfix instances to deal with it. Single messages out first, then
route them as desired:

The first instance accepts the message and uses a ?_destination_recipient_limit
of 1 to hand the message over to the second instance.

In the second instance create (at least) a second smtp service (e.g.
mandatorytls), which enforces TLS to any destination.

Use a suited map type, search for a sender or recipient and let the query
result "FILTER mandatorytls". It will tell Postfix to use the TLS only smtp
service.

p@rick

Re: smtp_tls_policy_maps on a per tls user basis

By Viktor Dukhovni at 09/09/2018 - 14:51

I assume you don't literally mean "google.com", since they support
TLS, and you can just enforce TLS to "google.com" for both and be
done.

For domains where you're less certain of ongoing TLS support, you
can try to deal with this by choosing different transports for
mail from sender1 vs. mail from sender2, via
sender_default_transport_maps. In sender1's instance of the
smtp(8) transport, the TLS policy will be mandatory for
"example.com" recipients, while in sender2'd instance of
the smtp(8) transport it will be opportunistic.

Re: smtp_tls_policy_maps on a per tls user basis

By Stefan Bauer at 09/10/2018 - 00:58

So each sender's instance is an own smtp-line in master.cf ? If so - does
it work like this?

src_domain1 unix - - n - - smtp
-o smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
-o syslog_name=src_domain1

tls_policy:

domain-that-does-not-support-tls.tld none

and in main.cf

sender_dependent_default_transport_maps = hash:/etc/postfix/sender_transport

sender_transport:
@src_domain1 src_domain1:

Is that correct?

If so - will all settings from main.cf be used as well for additional
smtp-instances?

like smtp_tls_security_level encrypt ?

Am So., 9. Sep. 2018 um 21:51 Uhr schrieb Viktor Dukhovni <
postfix- ... at dukhovni dot org>:

Re: smtp_tls_policy_maps on a per tls user basis

By Viktor Dukhovni at 09/10/2018 - 09:38

Yes, one for each sender "class".

Almost, you need to remove the whitespace around the "=" sign in master.cf
option overrides (or use "-o { option = value }" in sufficiently recent
Postfix versions. <a href="http://www.postfix.org/master.5.html" title="http://www.postfix.org/master.5.html">http://www.postfix.org/master.5.html</a>).

Yes.

Anything you don't override applies to the custom transports also.
The only "exception" is concurrency settings, which are really
queue manager parameters not transport parameters, and have names
of the form "<transportname>_...", e.g. smtp_destination_concurrency_limit,
... those need to be set per-transport, or else you get e.g.
"default_destination_concurrency_limit", ...

Re: smtp_tls_policy_maps on a per tls user basis

By Viktor Dukhovni at 09/09/2018 - 15:03

I should mention that this only scales when senders fall into
a *small* number of broad "classes", with each "class" having
a dedicated default transport and associated TLS policy.

sender (many) ->
sender class (a few) ->
transport + TLS policy (for many recipient domains)

What does not scale in Postfix is a large ad-hoc set of
(sender, recipient domain, TLS policy) triples.

You can class your users into three types:

* Delivery at all costs: no expectation of security
* Normal delivery: some tolerance for delays when security fails
* Secure delivery: strong preference for security, mandatory TLS
for many domains where opportunistic is observed
to generally work.

Re: smtp_tls_policy_maps on a per tls user basis

By Stefan Bauer at 09/09/2018 - 10:32

Thank you. Before diving deeper into this, you're saying it is possible
with postfix to setup a static routing (with maps / tables) in the form:

mails from Domain-A or specific SASL-user to DOMAIN Z with enforced TLS
mails from Domain-B or specific SASL-user to DOMAIN Z with none TLS

Is that correct?

Am So., 9. Sep. 2018 um 16:28 Uhr schrieb Wietse Venema <
... at porcupine dot org>: