IMAP Office 365: host not reachable


  • Used Zammad version: 3.3.0
  • Used Zammad installation source: debian package
  • Operating system: debian 10
  • Browser + version: chrome latest

I cannot connect my office365 mail address at imap although the same credentials and settings are working at Thunderbird. SMTP is working, but imap won´t connect: host not reachable. I´ve searched a lot, but found no solution at all. It seems that zammad can´t communicate with with office365 via imap. I´ve searched at my production log and only found:

I, [2020-05-04T13:38:01.686300 #5306-46964496063320] INFO -- : Started GET "/api/v1/channels_email?_=1588591880172" for at 2020-05-04 13:38:01 +0200 I, [2020-05-04T13:38:01.694621 #5306-46964496063320] INFO -- : Processing by ChannelsEmailController#index as JSON I, [2020-05-04T13:38:01.694717 #5306-46964496063320] INFO -- : Parameters: {"_"=>"1588591880172"} I, [2020-05-04T13:38:01.714946 #5306-46964496063320] INFO -- : Completed 200 OK in 20ms (Views: 2.0ms | ActiveRecord: 3.5ms) I, [2020-05-04T13:38:21.919373 #5306-46964480090720] INFO -- : Started POST "/api/v1/channels_email_inbound" for 91.114.xx.xx at 2020-05-04 13:38:21 +0200 I, [2020-05-04T13:38:21.929267 #5306-46964480090720] INFO -- : Processing by ChannelsEmailController#inbound as JSON I, [2020-05-04T13:38:21.929497 #5306-46964480090720] INFO -- : Parameters: {"adapter"=>"imap", "options"=>{"host"=>"", "user"=>"support@xxx", "password"=>"[FILTERED]", "ssl"=>true, "port"=>"993", "folder"=>"", "keep_on_server"=>false}} I, [2020-05-04T13:38:21.941617 #5306-46964480090720] INFO -- : fetching imap ( port=993,ssl=true,starttls=false,folder=INBOX,keep_on_server=false) I, [2020-05-04T13:38:26.239638 #5303-46927973229020] INFO -- : execute Channel.fetch (try_count 0)... I, [2020-05-04T13:38:26.242644 #5303-46927973229020] INFO -- : ended Channel.fetch took: 0.008268229 seconds. I, [2020-05-04T13:38:27.948832 #5306-46964480090720] INFO -- : Completed 200 OK in 6019ms (Views: 0.7ms | ActiveRecord: 3.4ms)

Any suggestions? It is not a shared mailbox!

I´ve tested the integration at nextcloud mail, which runs on the same server and it works. Seems to be bug or any configuration / handling problem at zammad (fresh install), which is not documented. Can I post any debug log?

Looks like your firewall is blocking network traffic outgoing to at least port 993.
Ensure that your can:

  • resolve the dns entry from the host Zammad runs on
  • you can talk to the server in question via e.g. telnet
  • your firewall rules allow outgoing traffic to port 993/tcp

Keep in mind that this will most likely also affect traffic for SMTP then.
Your machine might create log entries within syslog or so that it has blocked traffic.


thanks. It is no firewall problem. The same problem occurs, when the firewall is completely disabled. telnet on 993 works great. He seems to search ipv6 connections first. SMTP works great.

I figured out, what causes the problem: zammad can´t work with offce365 imap, when the system has ipv6 enabled.

Just disable ipv6 via net.ipv6.conf.all.disable_ipv6 = 1 - see

Sorry but what you’re saying is not true.
Just to double tab I installed a Zammad instance on a IPv6 host only (to ensure no IPv4 might fallback here).

Fetching and sending mail from and to Office365 via an IPv6 connection works just fine in Zammad:

My guess is that the overall communication via IPv6 might not have been working when you’ve been trying. As you have IPv4 most of the connections will just “silently” fall back when ever possible.

Especially with IPv6 configurations that might be incomplete or have faulty routes implemented, it might take too long to timeout or run into routing errors. Zammad might be faster than your OS in this case. In my opinion this isn’t necessarily an software based error.

Above mentioned routing issues occur on e.g. Contabo based virtual machines by default. This is the reason I’m very sure this is the original issue you had faced.

Sorry I’ve taken so long to double check.

This is how it would look like if Zammad can’t reach the network before timing out:

Thanks for clarifying. I´m hosting my vm at a bigger german hosting company with their preconfigured debian os - I think it should not be related to their kvm virtualisation as their service runs very great. I think, it should be mentioned at the documentation that ipv6 enabled communication could lead to problems like this. My error was “host not reachable” and when I tried telnet it lasts about 5 seconds till the communication was successfull at ipv4 at the given port.

But I think my workaround could be very helpful for some other users.

No offense, but the goal of the documentation is not to fix configuration related issues.
The test installation I have been running is KVM based as well at one of the biggest german hosters.

As my vm had IPv6 only I could ensure that routing is working as expected and without issues.

If we’d put all 0,01% maybe cases in the documentation, you’d not find the stuff you’re looking for.
In short: an absolute mess (and it already is one).

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.