On Mon, Aug 07, 2017 at 09:31:09PM +0200, Bastian Blank wrote:

> On Mon, Aug 07, 2017 at 06:59:52PM +0000, Rosenbaum, Larry M. wrote:
> > However, when they connect to another Postfix box, it's logged as Anonymous:
> > Aug  7 04:42:37 emgwy1 postfix/smtp[9798]: Anonymous TLS connection 
> > established to email.ornl.gov[160.91.4.92]:25: TLSv1.2 with cipher 
> > AECDH-AES256-SHA (256/256 bits)
> > Is this a problem? If so, how do I fix it?
> 
> No, this is no problem.  Remember, you did not ask Postfix to verify the
> peer, so Postfix decided to not try at all.

Correct.  See:

    http://www.postfix.org/FORWARD_SECRECY_README.html#status

> > # Outgoing TLS
> > smtp_tls_security_level = may
> 
> Here.  Use "verify", and it will obey.

No, the "verify" level is vulnerable to DNS MiTM, because it defaults
to verifying the insecurely obtained MX hostname.  It was a mistake
on my part to provide both "verify" and "secure" that differ only
in the default "match" criteria.  

The "verify" level should be deprecated in some future version of
Postfix.  Perhaps at the next "compatibility level" we can set the
default match criteria for "verify" to be the same as "secure",
making the two levels synonymous.

A option would be for both "verify" and "secure" to trust the MX
hostname when it is DNSSEC validated (which requires the Postfix
administrator to also set "smtp_dns_support_level = dnssec", but
we'd be trusting that the /etc/resolv.conf has been set correctly
to only list loopback addresses for nameservers.

Another option is to use the "res_ninit/res_nsearch" API when
available, which makes it possible to specify the nameserver list
explicitly and bypass the namerver list in /etc/resolv.conf.

-- 
        Viktor.

Reply via email to