On Sat, Jun 13, 2020 at 08:29:20PM +0200, Ján Máté wrote:
> 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 ')
Yes, that should do the trick.
> > 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 ...
In retrospect my comment doesn't quite apply to the way that MTA-STS is
integrated into Postfix. It is either a NOOP or mapped to "strict", so
the only downgrade risk is DNSSEC -> WebPKI, and while in my view that's
is a downgrade, obtaining unauthorised certs for the target MX is not
going to be a common attack vector for most senders to worry about.
--
Viktor.
