Re: verifying per site TLS policy -- maps override?
On Tue, Aug 22, 2017, at 10:19 AM, Viktor Dukhovni wrote: > > So that looks like it should work. > > Yes, but what security goal does this achieve? Just what I said above. To help working with specific senders if only to debug, etc. I'm not looking for a policy or a philosphy, I'm just looking for a tool. rob0's approach does it for me for now.
Re: verifying per site TLS policy -- maps override?
> On Aug 22, 2017, at 12:52 PM, yodel...@yepmail.net wrote: > > Based on your comment I found > > > http://postfix.1071664.n5.nabble.com/Server-equivilent-of-smtp-tls-policy-maps-td26112.html > > that provides the concrete example > > smtpd_client_restrictions = >check_client_access lmdb:/etc/postfix/require_crypt > > # require_crypt.lmdb > example.com reject_plaintext_session > > So that looks like it should work. Yes, but what security goal does this achieve? Firstly listing the client domain name there works unreliably, because the PTR lookup or the forward address lookup may tempfail, and then the client will be able to send in the clear. It is generally unwise to use "reject_unknown_client_hostname" to insist that all clients have working FCrDNS, so this check is fragile. You also have no assurance that the client verified the server certificate, so the connection might be via an MiTM attacker's system. The only protection this gets you is from passive attacks, when there are no DNS hiccups. A CIDR table (policy by client IP) is more reliable, but still leaves room for active attacks, and tracking client IPs is often difficult. My advice for mandatory inbound TLS on port 25 public MX hosts is "don't bother". -- Viktor.
Re: verifying per site TLS policy -- maps override?
On Tue, Aug 22, 2017, at 09:36 AM, /dev/rob0 wrote: > See reject_plaintext_session, and in the case as you described, > check_client_access: > > http://www.postfix.org/postconf.5.html#reject_plaintext_session > http://www.postfix.org/postconf.5.html#check_client_access > http://www.postfix.org/access.5.html Ok, didn't know about reject_plaintext_session so thanks! Based on your comment I found http://postfix.1071664.n5.nabble.com/Server-equivilent-of-smtp-tls-policy-maps-td26112.html that provides the concrete example smtpd_client_restrictions = check_client_access lmdb:/etc/postfix/require_crypt # require_crypt.lmdb example.com reject_plaintext_session So that looks like it should work.
Re: verifying per site TLS policy -- maps override?
On Tue, Aug 22, 2017 at 09:21:33AM -0700, yodel...@yepmail.net wrote: > The reason that I'm asking is that I'd like to set my inbound > policy =may by default, but for specific servers (that I may > be working or warring with) sending email to me I want to > force policy =encrypt. > > For infrequent one offs like that, even if I could specify a > few sending hosts, by hostname &/or even IP, to force inbound > TLS =encrypt policy it'd be useful. See reject_plaintext_session, and in the case as you described, check_client_access: http://www.postfix.org/postconf.5.html#reject_plaintext_session http://www.postfix.org/postconf.5.html#check_client_access http://www.postfix.org/access.5.html -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: verifying per site TLS policy -- maps override?
On Tue, Aug 22, 2017, at 09:13 AM, Viktor Dukhovni wrote: > > Is there an inbound per-domain TLS policy map? > > http://www.postfix.org/TLS_README.html#client_tls_limits Thanks. Okay I get that. But that reads like policy to me. It doesn't sound like it's impossible. The reason that I'm asking is that I'd like to set my inbound policy =may by default, but for specific servers (that I may be working or warring with) sending email to me I want to force policy =encrypt. For infrequent one offs like that, even if I could specify a few sending hosts, by hostname &/or even IP, to force inbound TLS =encrypt policy it'd be useful. But if it can't be done, ok it can't. I get that.
Re: verifying per site TLS policy -- maps override?
> On Aug 22, 2017, at 12:08 PM, yodel...@yepmail.net wrote: > > Is there an inbound per-domain TLS policy map? http://www.postfix.org/TLS_README.html#client_tls_limits One may be tempted to try enforcing TLS for mail from specific sending organizations, but this, too, runs into obstacles. One such obstacle is that we don't know who is (allegedly) sending mail until we see the "MAIL FROM:" SMTP command, and at that point, if TLS is not already in use, a potentially sensitive sender address (and with SMTP PIPELINING one or more of the recipients) has (have) already been leaked in the clear. Another obstacle is that mail from the sender to the recipient may be forwarded, and the forwarding organization may not have any security arrangements with the final destination. Bounces also need to be protected. These can only be identified by the IP address and HELO name of the connecting client, and it is difficult to keep track of all the potential IP addresses or HELO names of the outbound email servers of the sending organization. Consequently, TLS security for mail delivery to public MX hosts is almost entirely the client's responsibility. The server is largely a passive enabler of TLS security, the rest is up to the client. While the server has a greater opportunity to mandate client security policy when it is a dedicated MSA that only handles outbound mail from trusted clients, below we focus on the client security policy. > Are they named differently, or not available because of the way the handshake > happens? See above. -- Viktor.
Re: verifying per site TLS policy -- maps override?
On Tue, Aug 22, 2017, at 09:00 AM, Viktor Dukhovni wrote: > The global security level set via "smtp_tls_security_level" is > optionally preëmpted by the per-destination policy table (which > can also override selected additional TLS settings). Yeah I see the option to set the additional TLS params. That's exactly what I'm looking for. > > In other words, the DEFAULT policy will =may, and will be OVERRIDDEN by > > matches in tls_policy_outbound? > > Yes. Perfect. Thanks. For *INBOUND*, either @ postscreen or @ the after-postscreen smtpd handoff I can set -o postscreen_tls_security_level= or -o smtpd_tls_security_level= respectively. Is there an inbound per-domain TLS policy map? I looked for both smtpd_tls_policy_maps postscreen_tls_policy_maps but didn't see anything in the docs. Are they named differently, or not available because of the way the handshake happens?
Re: verifying per site TLS policy -- maps override?
> On Aug 22, 2017, at 11:52 AM, yodel...@yepmail.net wrote: > > I just want to make sure I understand per-site domain policy maps' priority. > > If I set up an outbound postfix instance with > > -o smtp_tls_security_level=may > -o smtp_tls_policy_maps=lmdb:/etc/postfix/tls_policy_outbound > > the way that works is that both are used, right? The global security level set via "smtp_tls_security_level" is optionally preëmpted by the per-destination policy table (which can also override selected additional TLS settings). > In other words, the DEFAULT policy will =may, and will be OVERRIDDEN by > matches in tls_policy_outbound? Yes. -- Viktor.
verifying per site TLS policy -- maps override?
Hi I just want to make sure I understand per-site domain policy maps' priority. If I set up an outbound postfix instance with -o smtp_tls_security_level=may -o smtp_tls_policy_maps=lmdb:/etc/postfix/tls_policy_outbound the way that works is that both are used, right? In other words, the DEFAULT policy will =may, and will be OVERRIDDEN by matches in tls_policy_outbound? Thanks
