Microsoft 365 SMTP: Can't use Channel::Driver::Smtp: #<Net::OpenTimeout: execution expired>"

Infos:

Hi All, we have been using Microsoft 365 SMTP (Exchange Online) SMTP very successfully the past year we have been using Zammad. It seems since we have changed authentication to OAuth (which is required by Microsoft since a few months), we regularly get Time out errors when reply-ing to a ticket, not sure if the change to Oauth is actually related:

Can’t use Channel::Driver::Smtp: #<Net::OpenTimeout: execution expired>"

Is there a way to increase this time-out maybe?

  • Used Zammad version: 5.3.1-1673546521.f2c640c5.focal
  • Used Zammad installation type: Ubuntu APT package
  • Operating system: Ubuntu 20.04
  • Browser + version: Safari, Chrome

Expected behavior:

Send an e-mail every time I reply to a ticket, not randomly time-out

Actual behavior:

Zammad SMTP connection regularly time-outs when sending a reply on a ticket.

Steps to reproduce the behavior:

Reply to a ticket → Russian Roulette → SMTP Time out or e-mail gets send.

1 Like

Updated this morning to version 5.3.1-1673969095.e2363550.focal. But the issue still persists and it seem to getting more frequent.

Help is greatly appreciated!

Haven’t run into this before, but here’s a few things I’d check.

First off I should mention we maintain an SMTP relay in our LAN, and have our M365 tenant configured to accept SMTP from our dedicated IP, which might explain why we haven’t run into any latency issues yet.

Hi Thanks for your reply, But I think I have tackled the issue. I found this solution on a Ruby forum somewhere (cant exactly find where anymore). But I have disabled IPv6 on the server running Zammad and this seem to have resolved the timeout issue.

I think the problem isnt specific Zammad related but more a Ruby error / bug?

1 Like

That’s wild. I guess timeouts would make sense if the server is attempting to send via IPv6. Thanks for the update :+1:

Huh, this may explain why I posted about Zammad’s handling of emails being shaky, whenever mail sending via OAUTH fails somehow it seems Zammad just gives up and spits out and error and never retries, which means the agent has to pay attention and not close the case before they manually cut and paste the answer in later and try to resend… It would have been helpful with more info about the actual solve, just disable IPV6?

Right now it’s a real pain in the ass when Microsoft is having issues, and today they’re having issues. Just had a call from a guy who was seeing more failed replies than successes, so he has to stockpile the open cases until tomorrow and do another round of manual send attempts.

2 Likes

I had the same issue here and now I am switching back to sending emails via an SMTP relay server but this really is ugly. It would be a great enhancement if Zammad would signal the sending status of an email (banner telling “not delivered yet”) but keep retrying for a longer (configurable?) amount of time. This applies to all ways of sending emails.

OpenTimeout indicates a connectivity issue. Most likely caused outgoing by a firewall blocking specific ports. In this case, outgoing, would be Port 587. You may have used 465 before hand which may explain the issue.

IPv6 or not should not make a difference as long as your system is able to speak ipv6. This also wouldn’t be a ruby specific issue.

That would be a feature request

Well, since we’ve disabled ipv6 on our Ubuntu VPS, the problem hasn’t occurred any more.

I think the issue is trying to connect to Microsoft 365 / exchange online is not supported over ipv6.

It’s not firewalling, because we don’t block any outgoing traffic on that VPS.

I can assure you that Microsoft 365 Mail-Servers client sided (so Port 993 and 587) can be reached via IPv6 without any issues. SaaS would other wise have degrations it doens’t have.

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