E-mail receive problem from one sender

[lr]

Strange situation: Trying to use an automated web-based scheduling system at a well-known medical provider in the Bay Area, and it doesn't work: can't get any confirmation e-mails from them at my regular e-mail ralph@lr.los-gatos.ca.us (which is hosted by Sonic). Call them on the phone, they look: Their logs show TLS errors (!) sending to that e-mail. To help debug it, I simply change my e-mail system on their servers, to <user>@sonic.net: same problem. Change it to <user>@gmail.com, and everything works. Oops, this seems bad; this would indicate the root cause really is some misconfiguration that's specific to Sonic overall, not just to my domain.

Anyway, that's really weird, because I otherwise my regular e-mail works great, and I haven't heard any complaints from any other senders that they can't get through. Now it gets weirder: The tech support person at that medical provider is able to send e-mails to ralph@lr.los-gatos.ca.us and receive replies, and that works fabulously well. Let me summarize this (and I'm using a fake domain name for the company's name for privacy)

• From <automated>@medical.example.com to ralph@lr.los-gatos.ca.us: BROKEN
• From <automated>@medical.example.com to <user>@sonic.net: BROKEN
• From <automated>@medical.example.com to <user>@gmail.com: works
• From <support>@medical.example.com to ralph@lr.los-gatos.ca.us: works

So the problem only occurs with the combination of their automated system and Sonic, but seems independent of whether Sonic's MX is receiving the e-mail with an @sonic.net address or on behalf of my domain. So the problem is not a general misconfiguration at Sonic (which would be really unexpected), but some bizarre incompatibility.

Anyone have a good idea how to debug it? Question for the Sonic tech people watching this: is there a point to opening a trouble ticket with Sonic, and asking them to look at their inbound mail logs to see any failed attempts from @medical.example.com (obviously I'll give you the real name)? Are there even logs of failed inbound attempts?

Obviously, this is not critical or urgent, otherwise I would have opened a trouble ticket right away.

[kgc]

Ralph, it would be very helpful if you could provide a date/time when a message was sent, even better if you could supply the hostname and/or IP address that originated it. I'm not sure why they'd be having a TLS failure sending mail to us, it's not a very common problem to run into. I've only ever seen it from our side when trying to send to completely broken MX servers. I've always viewed this as an "opportunistic encryption" and we have failed over to resending mail in the clear for nearly as long as we supported trying to initiate TLS in the first place.

[lr]

Kelsey: E-mail rough guess at times and IP address sent to you, via support. Tagged it so its gets sent to you.

[kgc]

Ralph, thanks for the bringing this to our attention and getting the information over that made it easy to find in our logs. It turns out this was a local problem, of sorts, and that some senders are starting to require that MX server certificate verify. This is unexpected but also comes as no surprise with the other mail server rules and expectations that have been slowing changing.

I was able to reissue all of the certs for the servers in the MX cluster so they now have aliases for all of the possible names a remote server might be using to talk to them.