smtp_tls_policy_maps on a per tls user basis

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

smtp_tls_policy_maps on a per tls user basis

Stefan Bauer-2
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.
Reply | Threaded
Open this post in threaded view
|

Re: smtp_tls_policy_maps on a per tls user basis

Wietse Venema
Stefan Bauer:
> 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?

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.

> 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.

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
Reply | Threaded
Open this post in threaded view
|

Re: smtp_tls_policy_maps on a per tls user basis

Stefan Bauer-2
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 <[hidden email]>:
Stefan Bauer:
> 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?

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.

> 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.

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
Reply | Threaded
Open this post in threaded view
|

Re: smtp_tls_policy_maps on a per tls user basis

Stefan Bauer-2
In reply to this post by Wietse Venema
Am Sonntag, 9. September 2018 schrieb Wietse Venema :
> 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.

I see no way to combine both. I want to enforce tls for sender1 to google.com but not for sender2 to google.com.
Reply | Threaded
Open this post in threaded view
|

Re: smtp_tls_policy_maps on a per tls user basis

Viktor Dukhovni


> On Sep 9, 2018, at 3:39 PM, Stefan Bauer <[hidden email]> wrote:
>
> I see no way to combine both. I want to enforce tls for sender1 to google.com but not for sender2 to google.com.

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.

--
--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: smtp_tls_policy_maps on a per tls user basis

Patrick Ben Koetter-2
In reply to this post by Stefan Bauer-2
* Stefan Bauer <[hidden email]>:

> Am Sonntag, 9. September 2018 schrieb Wietse Venema :
> > 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.
>
> I see no way to combine both. I want to enforce tls for sender1 to
> google.com but not for sender2 to google.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

--
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein
 
Reply | Threaded
Open this post in threaded view
|

Re: smtp_tls_policy_maps on a per tls user basis

Viktor Dukhovni
In reply to this post by Viktor Dukhovni


> On Sep 9, 2018, at 3:51 PM, Viktor Dukhovni <[hidden email]> wrote:
>
> 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.

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.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: smtp_tls_policy_maps on a per tls user basis

Stefan Bauer-2
In reply to this post by Viktor Dukhovni
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 <[hidden email]>:


> On Sep 9, 2018, at 3:39 PM, Stefan Bauer <[hidden email]> wrote:
>
> I see no way to combine both. I want to enforce tls for sender1 to google.com but not for sender2 to google.com.

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.

--
--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: smtp_tls_policy_maps on a per tls user basis

A. Schulze
In reply to this post by Stefan Bauer-2

Stefan Bauer:

> Am Sonntag, 9. September 2018 schrieb Wietse Venema :
>> 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.
>
> I see no way to combine both. I want to enforce tls for sender1 to
> google.com but not for sender2 to google.com.


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

Andreas


Reply | Threaded
Open this post in threaded view
|

Re: smtp_tls_policy_maps on a per tls user basis

Viktor Dukhovni
In reply to this post by Stefan Bauer-2


> On Sep 10, 2018, at 1:58 AM, Stefan Bauer <[hidden email]> wrote:
>
> So each sender's instance is an own smtp-line in master.cf ?

Yes, one for each sender "class".

> 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

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. http://www.postfix.org/master.5.html).

> 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?

Yes.

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

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", ...

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: smtp_tls_policy_maps on a per tls user basis

Viktor Dukhovni
In reply to this post by A. Schulze


> On Sep 10, 2018, at 2:25 AM, A. Schulze <[hidden email]> wrote:
>
> you may route messages from sender1 to a second postfix instance
> and configure that instance to enforce tls to $destination for _any_ sender

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

--
        Viktor.