On Thu, Feb 28, 2019 at 11:56:29AM -0800, Alice Wonder wrote:
> I gather from
> http://www.postfix.org/postconf.5.html#smtp_tls_policy_maps that the
> match: directive really only has application to a policy of secure.
>
> If I read right, it applies to the certificate validation.
Yes, but, for the record, also "verify", though the two actually
the same when "match" is specified explicitly.
> I'm wondering if there is something similar but applies to MX hosts.
No.
> When an MTA-STS policy has a mode of "testing" then certificate
> validation should not be done because the RFC says to send it anyway
> even if validation fails, so for those domains I want to use a policy of
> 'encrypt' instead of 'secure' but I also want the policy map to enforce
> validation of the MX host policy.
In MTA-STS, testing is not just about the TLS handshake, you're supposed
to also use the MX host list from DNS without policy filtering. The
only effect of MTA-STS "testing" is that reports are generated when
delivery does not match the published policy. If you're enforcing the
MX host with "testing", you're not doing MTA-STS correctly.
> Also, I want to do a similar thing with domains that I know have MX
> servers with DANE support, but the zone with the MX record is NOT signed
> with DNSSEC. I would like to set a 'dane-only' policy for them, but
> since the MX record can't be trusted, put a list in the policy file that
> MX host MUST match against.
There's no such feature. For Postfix 3.5, I may implement optional
trust in answers in which the "aa" (rather just the "ad") bit is
set. Then you could configure your resolver to return authoritative
answers for some domains, and these would be treated just like
DNSSEC-validated answers. For example, if I configure unbound with:
server:
local-data: "nic.goog. MX 0 mx1.smtp.goog."
local-data: "nic.goog. MX 0 mx2.smtp.goog."
local-data: "nic.goog. MX 0 mx3.smtp.goog."
local-data: "nic.goog. MX 0 mx4.smtp.goog."
then MX lookups for "nic.goog" return answers with the "aa" (authoritative
answer) bit set:
$ dig +noall +comment +ans -t mx nic.goog
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48733
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 8192
;; ANSWER SECTION:
nic.goog. 3600 IN MX 0 mx1.smtp.goog.
nic.goog. 3600 IN MX 0 mx2.smtp.goog.
nic.goog. 3600 IN MX 0 mx3.smtp.goog.
nic.goog. 3600 IN MX 0 mx4.smtp.goog.
then if these DNSSEC-signed MX hosts also published TLSA records,
I'd DANE-validated delivery to "nic.goog", even though Google's
published MX records (equivalent names for the same underlying SMTP
servers) are in non-DNSSEC domains:
$ dig +noall +comment +ans -t mx nic.goog
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30221
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 8192
;; ANSWER SECTION:
nic.goog. 600 IN MX 10 aspmx.l.google.com.
nic.goog. 600 IN MX 20 alt1.aspmx.l.google.com.
nic.goog. 600 IN MX 30 alt2.aspmx.l.google.com.
nic.goog. 600 IN MX 40 alt3.aspmx.l.google.com.
nic.goog. 600 IN MX 50 alt4.aspmx.l.google.com.
> Is there something similar to the match directive but applies to the MX
> hostname rather than the TLS certificate?
No.
--
Viktor.
