On 06.03.2012 16:57, Viktor Dukhovni wrote:
>> It's just that its CN does not match the server name, but that
>> should be ok when using "verify" (and not when using "secure").
> Considering that Postfix documentation does not say this, and
> clearly states the opposite, you're just overloading your wishful
> interpretation of these words with total disregard for the
> documentation.
Ouch. I may have deserved that. :-)
After reading a bit more about smtp_tls_verify_cert_match and
smtp_tls_secure_cert_match let's see if I understand better now:
Default strategy for "verify": ask DNS about MX, then check if the
servers CN matches. Check if the trust chain is valid.
Default strategy for "secure": accept any CN presented by the server if
that is the domain or a subdomain of the recipient address or the
canonized hostname from the transport table. Do not add MX names looked
up in DNS to the list of feasible CNs. Check if the trust chain is valid.
Both can be overridden in tls_policy with the match attribute.
Real world example: two organizations agree upon mandatory TLS. A list
of domains requiring TLS and a list of MX hosts are transmitted. Each
side configures:
/etc/postfix/tls_policy:
first-otherdomain XXX match=mx1:mx2
.first-otherdomain XXX match=mx1:mx2
second-otherdomain XXX match=mx1:mx2
.second-otherdomain XXX match=mx1:mx2
XXX may be "verify" or "secure", it is overridden by "match" anyway.
Regards,
Robert
