On Fri, Apr 10, 2020 at 02:41:22PM -0400, David Goerger wrote: > 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.
Indeed, and sending mail to "hostedemail.com" which has the mx record same as the names in the cert it happily works with my config like yours: Apr 10 13:07:26 obtuse1 smtpd[15187]: a5d4c3a00f2c6d1b mta server-cert-check result="success" Apr 10 13:07:26 obtuse1 smtpd[15187]: debug: mta-routing: route [] <-> 216.40.42.4 (mx.hostedemail.com) is now valid. Apr 10 13:07:26 obtuse1 smtpd[15187]: debug: mta: connecting with [connector:[]->[relay:hostedemail.com,smtp+tls,heloname=foad.obtuse.com],0x20000] So the issue here is mail to "hostedmail.com" and "hostedemail.com" go to the same place (216.40.42.4), via two different MX's pointing to two different A records. hostedemail.com validates correctly because the mx record points to mx.hostedemail.com, which matches the cert wildcard. hostedmail does not validate correctly, because the mx points to mx.hostedmail.com.cust.hostedemail.com which does not match the cert wildcard. I suspect you send mail to "hostedmail.com" and hit the failure.. "hostedemail.com" works fine. I suggest we take this conversation off bugs@ since it attachemnts are frowned upon and I can't post Dog typing on keyboard running DNS memes. > > === > $ 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 >
