On Tue, Aug 26, 2025 at 07:43:47AM +0200, Florian Piekert via Postfix-users
wrote:
> I found this in my logfile this morning and was wondering (at least) two
> things.
> (1.) is the ".pue.de" entry at error, since it is not specifying a fully
> qualified host name?
No, it is not an error, see the documentation of the "match" TLS policy
parameter at the "secure" level. Mind you the pattern is "redundant",
with ".pue.de" in the match list, there's no need for "mail.pue.de".
And specifying an IP address in the match list is very unexpected, most
servers will not have both DNS names and IP address SANs in the same
certificate, you probably DO NOT want to verify both!
> (2.) is due to the (assumed) error of (1.) the delivery to the
> "mout.kundenserver.de" (and 212.114.86.56) not performed?
>
> Or is the reason simply because of the IP address mismatch error below?
The latter.
> Aug 26 07:29:00 butterfly postfix-tlspol[194692]: INFO Evaluated policy for
> "pue.de": secure match=mail.pue.de:.pue.de:mout.kundenserver.de:212.114.86.56
> servername=hostname (from cache, 700h38m56s remaining)
This policy looks unwise.
> Aug 26 07:30:02 butterfly postfix/smtp[4095459]: looking for session
> smtp&pue.de&firewall.pue.de&93.240.123.73&8&&2D8F853B5C9F2BBAABE2B29D1D85F0F141539CD986896D100E138494A652F90A
> in smtp cache
> Aug 26 07:30:02 butterfly postfix/smtp[4095459]: reloaded session
> smtp&pue.de&firewall.pue.de&93.240.123.73&8&&2D8F853B5C9F2BBAABE2B29D1D85F0F141539CD986896D100E138494A652F90A
> from smtp cache
The SMTP client found a cached TLS session.
> Aug 26 07:30:02 butterfly postfix/smtp[4095459]: SSL_connect:before SSL
> initialization
> Aug 26 07:30:02 butterfly postfix/smtp[4095459]: SSL_connect:SSLv3/TLS write
> client hello
> Aug 26 07:30:02 butterfly postfix/smtp[4095459]: SSL_connect:SSLv3/TLS read
> server hello
> Aug 26 07:30:02 butterfly postfix/smtp[4095459]:
> firewall.pue.de[93.240.123.73]:25: depth=0 verify=0 subject=/CN=*.pue.de
> Aug 26 07:30:02 butterfly postfix/smtp[4095459]:
> firewall.pue.de[93.240.123.73]:25: depth=2 verify=1 subject=/C=GB/O=Sectigo
> Limited/CN=Sectigo Public Server Authentication Root R46
> Aug 26 07:30:02 butterfly postfix/smtp[4095459]:
> firewall.pue.de[93.240.123.73]:25: depth=1 verify=1 subject=/C=GB/O=Sectigo
> Limited/CN=Sectigo Public Server Authentication CA DV R36
> Aug 26 07:30:02 butterfly postfix/smtp[4095459]:
> firewall.pue.de[93.240.123.73]:25: depth=0 verify=1 subject=/CN=*.pue.de
> Aug 26 07:30:02 butterfly postfix/smtp[4095459]: SSL_connect:SSLv3/TLS read
> server certificate
> Aug 26 07:30:02 butterfly postfix/smtp[4095459]: SSL_connect:SSLv3/TLS read
> server key exchange
> Aug 26 07:30:02 butterfly postfix/smtp[4095459]: SSL_connect:SSLv3/TLS read
> server done
But the server declined resumption, and performed a full handshake instead.
> Aug 26 07:30:02 butterfly postfix/smtp[4095459]: server certificate
> verification failed for firewall.pue.de[93.240.123.73]:25: num=64:IP address
> mismatch
As expected when specifying a match setting with names *and* an IP address.
The MX RRset for that domain is just:
pue.de. IN MX 10 firewall.pue.de.
which is noticeably different from the cached policy. The problem is
unsurprisingly with the remote MTA-STS policy:
$ curl -sLo - https://mta-sts.pue.de/.well-known/mta-sts.txt
version: STSv1
mode: enforce
max_age: 15552000
mx: mail.pue.de
mx: *.pue.de
mx: mout.kundenserver.de
mx: 212.114.86.56
This mistakenly lists an IP address along with mostly the wrong names,
but your MTA-STS policy plugin fails to ignore the IP address, and
passes it through verbatim to Postfix, which then passes it to OpenSSL,
which infers that BOTH name checks and an IP check are to take place.
The MTA-STS plugin should filter out any misguided IP addresses found in
the "mx" list.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
