As background, the RELEASE_NOTES for 3.8 mention:...>>
postfix/psint/smtpd[27820]:
esa.hc2802-61.iphmx.com[139.138.32.157]: TLS cipher list
"aNULL:-aNULL:HIGH:MEDIUM:!SEED:!IDEA:!3DES:!RC2:!RC4:!RC5:!kDH:!kECDH:!aDSS:!MD5:+RC4:@STRENGTH:!aNULL"
yep
Which is most of the above, but you also disable aNULL, which though
unrelated to the problem, is counter-productive. Let the checklists
give you a lower score for this, they're all wrong:
https://datatracker.ietf.org/doc/html/rfc7672#section-8.2
I've no idea in this case why aNULL is explicitly ref'd; for my own configs I
don't call it out, rather stick with the default
and, TBH, don't get what's happening here
"aNULL:-aNULL:...!aNULL"
is remove-all of those aNULL instnces in the cipher list what's advised by
section-8.2?
Less verbose logging
well, that's at least where I started
PCAP capture of an attempted TLS handshake would have been more useful.
I've just been reading up on tcpdump'ing TLS -- and trying to figure out
extracting cipher types; seems a useful add'l tool to have at hand.
latest naive attempt,
tcpdump -i eth0 "tcp port 25 and (tcp[((tcp[12] & 0xf0) >> 2)] = 0x16)"
is still unhelpful.
My money is on an ECDSA server certificate
on the receiving server's end, right?
which is still a bit too "exotic" for some older SMTP clients.
here, checking
postconf -n smtpd_tls_key_file smtpd_tls_cert_file
smtpd_tls_key_file =
/etc/sec/ssl/LE/deploy/${var_DOM_CMX0024}/priv.rsa.key smtpd_tls_cert_file =
/etc/sec/ssl/LE/deploy/${var_DOM_CMX0024}/fullchain.rsa.crt.pem
that's ... odd
(hm. i don't see any postfix errors in startup; `postfix check` returns OK, too)
checking further
grep smtpd_tls main.cf | grep file
smtpd_tls_dh1024_param_file=${config_directory}/dh4096.pem
smtpd_tls_eckey_file =
/etc/sec/ssl/LE/deploy/${var_DOM_CMX0024}/priv.ec.key
smtpd_tls_eccert_file =
/etc/sec/ssl/LE/deploy/${var_DOM_CMX0024}/fullchain.ec.crt.pem
smtpd_tls_key_file =
/etc/sec/ssl/LE/deploy/${var_DOM_CMX0024}/priv.rsa.key
smtpd_tls_cert_file =
/etc/sec/ssl/LE/deploy/${var_DOM_CMX0024}/fullchain.rsa.crt.pem
and
cat main.cf
...
smtpd_tls_key_file =
/etc/sec/ssl/LE/deploy/${var_DOM_CMX0024}/priv.rsa.key
smtpd_tls_cert_file =
/etc/sec/ssl/LE/deploy/${var_DOM_CMX0024}/fullchain.rsa.crt.pem
...
note the errant leading-space.
sigh. a continuation line.
which, iiuc, would lead to the ec cert being offered, but NOT the 'continued'
rsa cert spec
and, indeed, rm'ing the space cures the problem.
not where i was looking. i wouldn't have caught anytime soon(ish) without the
hint. thx!
digging through this server's logs, the *vast* majority of these errors
originate from 3 senders
*.iphmx.com (healthcare org)
*.jpmchase.com (finance org)
*.comcast.net (evil empire)
each numbering in the 1000s; many others by ones & twos as well ...
one'd hope that banks and hospitals might be a bit more up-to-date on their end.
currently / so far, this server's config is
...
Though not relevant for the SMTP server, just stick with the defaults,
the above hodge-podge just leads to more email going out in the clear.
time to clean up some legacy bad habits! i certainly carried such baggage
around for way too long myself ...
thx agn!
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
