E-Mail accepted by smtp.comcast.net, but never delivered

If you figure it out, please post here and I'll do the same.

Thanks

I definately will do. This make take some time to figure out. It sure would be nice if Comcast was helpful for problems like this :-).  I think there are just one or two guys/gals in Comcast who know the answer to our problem.

I wonder if the fact that it happened so close to 1/1/2020 is significant? You noticed it on 12/31, but that could just be due to GMT offset.

Yes. I noticed the exact same issue at the exact same time as you did. Comcast definately changed something. I have noticed in the past that Comcast would "eat" email that didn't pass SPF. SPF is all set up, so that isn't the issue here. It sure would be nice if Comcast would bounce the email if they had a problem with it rather than just accepting it, but not delivering it.

I have  program that monitors my generator on a Raspberry Pi. That also sends email to Comcast on port 587, but for some reason that is still working. It's just my sendmail that is broken as of today.

Yes. Exactly. Since all of the exhange is encrypted, Wireshark isn't of any help in undestanding the difference between the working and broken examples. I did force the smtp transaction to IPv4, but that didn't make any difference.

I'd say it probably did start at midnight on 1/1... not sure what timezone, but I didn't get some logs that usually roll out at 2am Eastern.

I have similar monitoring set up.  I can send e-mail from Thunderbird, just not from Senmail on my Linux box.  I'm sure they've started rejecting it for some reason, but I can't tell why.  There is no error message from Comcast's SMTP server, it just accepts the message like normal and then dumps it, apparently.

My TLS certificate was expired. I generated a new self-signed one, but that didn't fix it. Is it possible that Comcast no longer likes self-signed certs? Are you using a self-signed cert?

A new self-signed certificate fixed it for me! Thanks for the pointer.

What's weird is that it wasn't just that my cert expired, my sendmail config wasn't even set up to point to a certificate... all lines in the config that pointed to a cert were commented out.  However, TLS had been working. I guess its possible it still could have been looking at the default location for certs in /etc/pki/tls/certs, but there wasn't anything in the config pointing it there.

I just created some new certs in /etc/mail/certs, pointed sendmail.mc/cf at them, and restarted sendmail and it worked.

I re-made my certificate and key. This time I went from SHA256 to SHA512 and RSA2048 to RSA4096 and it worked!

openssl req -newkey rsa:4096 -nodes -sha512 -x509 -days 3650 -nodes -out /etc/pki/tls/certs/mailserver2020cert.pem -keyout /etc/pki/tls/mailserver2020key.pem

I'm glad your's is working as well!

Hello,

Probably some clarification might help.  We won't mark outbound messages as spam just on the basis of SPF or SSL/TLS certificates.  We will even add a DKIM signature for messages that are not "comcast.net" senders, using a third domain so that receiving systems can know it came from our platform.  We know that there won't be alignment, but it does show ownership.

It looks like in both your cases, the system believed that your Sendmail headers had been forged in some way, and flagged the messages as spam.  We do not (currently) forward messages flagged as spam when going to an external destination.  If the recipient is comcast.net, and they have elected to receive spam in their Inbox/Junk folder (https://www.xfinity.com/support/articles/spam-filters-and-email-blocking-new-experience) , we will forward those messages to them and the system will put them in the Inbox/Junk as specified by the user.

I suspect the timing of the certificate creation was a coincidence.  I would have to see samples of the before/after messages to be certain.  If you'd like us to do further inspection, send me a PM (click on my name).