auth/tls combinations sanity check

[Michael Fox]

I have a possibly unusual AUTH/TLS combination requirement. As a newbie, I
could use a sanity check.

Requirements:
* All virtual mail clients will use SASL AUTH
* Virtual mail clients on specific internal networks MUST NOT be offered
TLS. This is to satisfy FCC requirements prohibiting the use of encryption
on certain radio frequencies.
* Other virtual mail clients on internal networks may choose to use TLS or
not. (Some simple network appliances don't support TLS at all, or don't
support STARTTLS)
* Virtual mail clients from external networks (outside the firewall) MUST
use TLS.


So, I'm thinking I need three submission ports:
* one for AUTH but no TLS
* one for AUTH with opportunistic TLS
* one for AUTH with enforced TLS

So, I'm thinking:

/etc/postfix/master.cf:

# Submission for internal, radio clients; access controlled by IP address
in iptables
2525 inet ...
-o smtpd_tls_security_level=none
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
...

# Submission for internal, non-radio clients
submission inet ...
-o smtpd_tls_security_level=may
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
...

# Submission for external clients
smtps inet ...
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
...

Does that make sense?
Is there a better way?
Is there anything I should keep in mind?

All comments and suggestions would be helpful.

Thanks,
Michael

[Viktor Dukhovni]

Post by Michael Fox
* one for AUTH but no TLS
* one for AUTH with opportunistic TLS
* one for AUTH with enforced TLS

You can combine these into just one service by using:

main.cf:
mua_discard_ehlo_keyword_address_maps = cidr:${config_directory}/ehlo.cidr

master.cf:
submission inet ... smtpd
-o smtpd_discard_ehlo_keyword_address_maps=$mua_discard_ehlo_keyword_address_maps

ehlo.cidr:
192.0.2.1/32 starttls,silent-discard

to suppress TLS for some clients, and:

main.cf:
mua_sender_restrictions =
check_client_access cidr:${config_directory}/tlsclient.cidr

master.cf:
submission inet ... smtpd
-o smtpd_sender_restrictions=$mua_sender_restrictions

tlsclient.cidr:
192.0.2.0/24 DUNNO
0.0.0.0 reject_plaintext_session

[Viktor Dukhovni]

Post by Viktor Dukhovni
192.0.2.0/24 DUNNO
0.0.0.0 reject_plaintext_session

That would be 0.0.0.0/0 of course.

[Michael Fox]

Post by Viktor Dukhovni

Post by Michael Fox
* one for AUTH but no TLS
* one for AUTH with opportunistic TLS
* one for AUTH with enforced TLS

mua_discard_ehlo_keyword_address_maps =
cidr:${config_directory}/ehlo.cidr
submission inet ... smtpd
-o
smtpd_discard_ehlo_keyword_address_maps=$mua_discard_ehlo_keyword_address_
maps
192.0.2.1/32 starttls,silent-discard
mua_sender_restrictions =
check_client_access cidr:${config_directory}/tlsclient.cidr
submission inet ... smtpd
-o smtpd_sender_restrictions=$mua_sender_restrictions
192.0.2.0/24 DUNNO
0.0.0.0/0 reject_plaintext_session
--
Viktor.

Wow. Thank you! That looks elegant and powerful. It will take me some
time for me to absorb.

But looking at http://www.postfix.org/postconf.5.html, I don't find
mua_discard_ehlo_keyword_address_maps or mua_sender_restrictions. Are those
literal names? Where can I find documentation?

Thanks,
Michael

[Benny Pedersen]

Post by Michael Fox
But looking at http://www.postfix.org/postconf.5.html, I don't find
mua_discard_ehlo_keyword_address_maps or mua_sender_restrictions. Are
those
literal names? Where can I find documentation?

trick here is that we only ask for postconf -n, this will not display
postconf -Mf :=)

with the above config its not needed to provide both

and its more readeble to see what happends when one edit main.cf, and
not needing edit master.cf eath day

[Michael Fox]

Post by Benny Pedersen

Post by Michael Fox
But looking at http://www.postfix.org/postconf.5.html, I don't find
mua_discard_ehlo_keyword_address_maps or mua_sender_restrictions. Are
those
literal names? Where can I find documentation?

trick here is that we only ask for postconf -n, this will not display
postconf -Mf :=)
with the above config its not needed to provide both
and its more readeble to see what happends when one edit main.cf, and
not needing edit master.cf eath day

I'm not sure I understand you Benny.

Are you saying I can make up any variable name I want and assign a value to
it main.cf, and then reference its value in main.cf and master.cf?

If so, is that capability documented somewhere? (When I couldn't find mua_*
in http://www.postfix.org/postconf.5.html, I looked for a statement to that
effect on http://www.postfix.org/ but could not find any indication that
that was allowed.)

Thanks,
Michael

[Viktor Dukhovni]

Post by Michael Fox
I can make up any variable name I want and assign a value to
it main.cf, and then reference its value in main.cf and master.cf?

Yes.

[Benny Pedersen]

Post by Michael Fox
Are you saying I can make up any variable name I want and assign a
value to
it main.cf, and then reference its value in main.cf and master.cf?

indeed yes

[Michael Fox]

Post by Viktor Dukhovni

Post by Michael Fox
I can make up any variable name I want and assign a value to
it main.cf, and then reference its value in main.cf and master.cf?

Yes.
--
Viktor.

Ah. That is indeed powerful.

And now I understand your suggested solution, Viktor. It even solves a
problem I didn't mention in that it allows me to offer both STARTTLS (with
enforced TLS for external clients) on port 457 and wrapper mode on port 465
(for internal or external clients that don't speak STARTTLS).

Brilliant. Thanks much!

Michael