Friday, 20200410 12:04-0600, Bob Beck wrote: > > So doing a little digging: > > obtuse1# dig hostedmail.com mx > ; <<>> dig 9.10.8-P1 <<>> hostedmail.com mx > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36649 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;hostedmail.com. IN MX > > ;; ANSWER SECTION: > hostedmail.com. 82314 IN MX 0 > mx.hostedmail.com.cust.hostedemail.com. > > ;; Query time: 1 msec > ;; SERVER: 192.168.20.1#53(192.168.20.1) > ;; WHEN: Fri Apr 10 11:58:02 MDT 2020 > ;; MSG SIZE rcvd: 94 > obtuse1# > > and adding a wee debug line to smtpd shows: > Apr 10 11:54:03 obtuse1 smtpd[90752]: 104c7ed103dfebaf mta ssl_check_name: no > match for 'mx.hostedmail.c\ > om.cust.hostedemail.com' in cert > Apr 10 11:54:03 obtuse1 smtpd[90752]: 104c7ed103dfebaf mta error reason=SSL > certificate check failed > > So I would contend that is expected behaviour and smtpd is doing it > correctly. > > *.hostedemail.com isn't supposed to match > mx.blah.woof.yakk.hurl.sparkle.fucknuts.hostedemail.com > > You should suggest to them that they fix their DNS.
I very much appreciate the help! But I'm still a bit confused, and the fact that "hostedmail.com" (mail) has MX pointing to "hostedemail.com" (email) is probably confounding matters. === $ dig mx hostedemail.com ; <<>> dig 9.10.8-P1 <<>> mx hostedemail.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6001 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ;; QUESTION SECTION: ;hostedemail.com. IN MX ;; ANSWER SECTION: hostedemail.com. 13 IN MX 10 mx.hostedemail.com. ;; ADDITIONAL SECTION: mx.hostedemail.com. 24 IN A 216.40.42.4 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Apr 10 14:15:23 EDT 2020 ;; MSG SIZE rcvd: 79 $ $ dig mx.hostedemail.com ; <<>> dig 9.10.8-P1 <<>> mx.hostedemail.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1008 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ;; QUESTION SECTION: ;mx.hostedemail.com. IN A ;; ANSWER SECTION: mx.hostedemail.com. 13 IN A 216.40.42.4 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Apr 10 14:15:34 EDT 2020 ;; MSG SIZE rcvd: 63 === The DNS for "hostedmail.com" (mail) seems wrong, but "hostedemail.com" (email) does look right to me. Another MX which I'd previously reported, but which appears to be in the same boat, is "mx.zohomail.com" (e.g. postmas...@mx.zohomail.com), which curiously also features a wildcard certificate. (That MX appears to reject mail to @mx.zohomail.com with 553 Unauthorized, tested with postfix on CentOS 7, but my primary machine doesn't get that far and instead fails in TLS verification.) > And I'd also suggest to you that the world probably isn't ready for > real certificate validation on SMTP connections for reasons like this, > so you might want to reconsider your choice of mandatory tls on relays > unless you just like tossing away mail. I do monitor my outbound queue and alert admins when I see something misconfigured, which isn't terribly often, although I wouldn't enable global mandatory validation on my company's server, I agree. :) That's actually how I noticed this - I was about to report the cert error to a friend (said friend is in tech and wouldn't have minded) when I realized I couldn't find anything wrong with the certificate when I manually inspected it. > (I probably will suggest my patch to get that debug line tho :) > > Cheers > > -Bob
