Exim Mail-Server with Microsoft (Office) 365 and TLS errors

By | 2020-05-08

In the last days I got several calls, that I cannot receive emails from NetApp. After some debugging I found out, that my exim mailserver seems to refuse mails from NetApp which are received via some *.outlook.com domains:

2020-05-08 15:34:00 TLS error on connection from mail-db8eur05olkn2014.outbound.protection.outlook.com (EUR05-DB8-obe.outbound.protection.outlook.com) [40.92.89.14] (recv): Error in the pull function.
2020-05-08 15:34:00 unexpected disconnection while reading SMTP command from mail-db8eur05olkn2014.outbound.protection.outlook.com (EUR05-DB8-obe.outbound.protection.outlook.com) [40.92.89.14] D=5m1s

About 100 tries later, I found a solutions for this problem: disable StartTLS in your exim.conf for these outlook.com domains:

tls_advertise_hosts = !*.protection.outlook.com : *

After a restart, it’s working correctly:

2020-05-08 15:41:54 1jX3GE-000EKN-Qj Virus_checked
2020-05-08 15:41:57 1jX3GE-000EKN-Qj Spam_checked (Score: 2.1)
2020-05-08 15:41:57 1jX3GE-000EKN-Qj <= xxxx.xxxr@netapp.com H=mail-co1nam11on2089.outbound.protection.outlook.com (NAM11-CO1-obe.outbound.protection.outlook.com) [40.107.220.89] P=esmtp K S=9422 DKIM=netapp.onmicrosoft.com id=6D1A8049-3865-4766-8080-0420443EB300@netapp.com
2020-05-08 15:41:57 1jX3GE-000EKN-Qj => alex <xxx> R=dovecot T=dovecot_lmtp_transport C=”250 2.0.0 <xxx> aMTXHqVhtV7/1gAAKkMkSg Saved”
2020-05-08 15:41:57 1jX3GE-000EKN-Qj Completed

4 thoughts on “Exim Mail-Server with Microsoft (Office) 365 and TLS errors

  1. Daniel

    I have exactly the same issue after I migrated my Debian/Exim based email server to a new VM using Debian Buster. By now I’ve spend hours of researching and reading through mailing lists, but nothing resolved the root cause by now.

    While I agree that stop advertising TLS for Microsoft 365 email services is a quick way to get things going again, this cannot be the right solution on the long run.

    When starting Exim from the command line via “/usr/sbin/exim4 -bd -d+all” I can see that everything looks find up until the point where my side response with “250 Accepted” to the “RCPT TO”. The Microsoft servers just do not continue with sending the DATA command as expected and thus the SMTP session times our after five minutes.

    I recorded the TCP session across all involved servers and their network interfaces (LXC host & container, no NAT), but everything looks perfect in this regard. I even could reproduce the issue using the original Debian Exim config on a new container. I wonder why there are not more reports about this particular issue on the Internet.

    So if you or anyone else makes some progress, it would be great to hear about it. I keep on researching and should I come across a decent solution will give you an update.

    Reply
  2. Chris

    Thanks — that fix works for me, and explains why I missed some important emails recently.

    Reply
  3. Joaquin Ferrero

    This solution has a problem: it rejects connections from mail servers from which it is capable of obtaining a reverse resolution. That is, if a server is connected from an IP, and it is not possible to know what name it corresponds to, Exim cannot know if it corresponds to *.protection.outlook.com, so the rule fails and cuts the connection.

    To solve this, Exim must be told to admit the rule even if it is not capable of doing that resolution:

    tls_advertise_hosts = +include_unknown : !*.protection.outlook.com : *

    But this brings a new problem: a line like this will appear in the logs for each connection attempt without resolution:

    2021-03-10 01:22:52 failed to find host name for 61.128.172.202: accepted by +include_unknown

    So in the end the logs are flooded with activity notices …

    Reply
  4. Dopasc

    It is “solved” in 4.94. Or more precise, the problem persists at MS, but exim will only log it and deliver message…

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.