Hi Viktor,
thank you very much!
Tested and confirmed ... it looks like there is a lot of untested software
today, or I use all the special edge cases :-)
I will report the bug to postfix-mta-sts-resolver developer - the patch is
rather simple:
root@collegemate:/usr/lib/python3/dist-packages/postfix_mta_sts_resolver# diff
-u responder.py-orig responder.py
--- responder.py-orig 2020-04-11 22:40:55.000000000 +0200
+++ responder.py 2020-06-13 20:15:00.377112967 +0200
@@ -219,7 +219,7 @@
else:
assert cached.pol_body['mx'], "Empty MX list for restrictive
policy!"
mxlist = [mx.lstrip('*') for mx in set(cached.pol_body['mx'])]
- resp = "OK secure match=" + ":".join(mxlist)
+ resp = "OK secure servername=hostname match=" +
":".join(mxlist)
return netstring.encode(resp.encode('utf-8'))
else:
return netstring.encode(b'NOTFOUND ')
And related to:
> If the MTA-STS policy table service overrides DANE policy in the
> presence of TLSA records for the domain, then it is broken. If however,
> DANE records are not present, then the MTA-STS service MUST instead
> return one of ...
I don't know what is the correct answer if the destination server uses both
DANE and MTA-STS ... which one should be used, DANE or MTA-STS? The current
behaviour is that MTA-STS is used, because "smtp_tls_policy_maps" overwrites
the default "smtp_tls_security_level = dane".
Cheers,
JM
> On 13 Jun 2020, at 20:09, Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:
>
> On Sat, Jun 13, 2020 at 01:44:18PM -0400, Viktor Dukhovni wrote:
>
>> ... the MTA-STS service MUST instead return one of:
>>
>> verify servername=hostname
>> or
>> secure servername=hostname match=hostname
>
> I should have written:
>
> secure servername=hostname
> match=mx1.example
> match=mx2.example
> ...
>
> where the list of match values is per the MTA-STS policy. With
> "match=hostname" you lose the MTA-STS out-of-band (i.e. HTTPS)
> validation of the list of allowed MX hosts.
>
> The explict list names is not strictly the same as MTA-STS, since it
> will allow matching of "mx2" while trying to connect to (and logging
> delivery via) "mx1", but should not be a concern, an MiTM can always
> force connections to a given MX host by blocking access to the rest, and
> can redirect TCP traffic, ... so the only effect is somewhat imprecise
> logging.
>
> --
> Viktor.
