Notification SMTP channel does not automatically recover after transient Net::OpenTimeout

Technical assistance
1

Title: Notification SMTP channel does not automatically recover after transient Net::OpenTimeout

Hi,

We are currently testing/using Zammad in production and we are experiencing an issue with the SMTP channel used for agent email notifications.

The SMTP server itself can occasionally be temporarily unreachable for a few seconds. This is not necessarily a Zammad issue by itself. However, after one of these temporary SMTP connection failures, Zammad seems to put the notification channel into an error state and it does not recover automatically, even once the SMTP server is reachable again.

Environment

  • Zammad: 7.1.3-0014
  • Deployment: Docker
  • Hosting: OVH VPS
  • SMTP relay: Google Workspace SMTP Relay
  • SMTP host: smtp-relay.gmail.com
  • Port: 587
  • TLS/STARTTLS enabled
  • Authentication: Google Workspace SMTP Relay authorized by the VPS public IP
  • Sender domain: oremis.fr

The notification channel normally works correctly.

Error

When the problem occurs, we see the following errors in the zammad-scheduler container:

E, [2026-09-26T15:28:41.537032#7-90856] ERROR -- : Smtp: Network connection to smtp-relay.gmail.com timed out: execution expired (Net::OpenTimeout)

E, [2026-09-26T15:28:41.537145#7-90856] ERROR -- : Network connection to smtp-relay.gmail.com timed out: execution expired (Net::OpenTimeout)

app/models/channel/driver/smtp.rb:47:in 'Channel::Driver::Smtp#deliver'

E, [2026-09-26T15:28:41.549897#7-90856] ERROR -- : Unable to send ticket email notification to xxxxx@oremis.fr: Smtp: Network connection to smtp-relay.gmail.com timed out: execution expired (Net::OpenTimeout)

It then happened again for other notifications:

2026-09-26 15:30:07
Unable to send ticket email notification to xxxxxx@oremis.fr:
Smtp: Network connection to smtp-relay.gmail.com timed out:
execution expired (Net::OpenTimeout)

2026-09-26 15:35:08
Unable to send ticket email notification to xxxxx@oremis.fr:
Smtp: Network connection to smtp-relay.gmail.com timed out:
execution expired (Net::OpenTimeout)

And again:

2026-09-26 15:46:05
Unable to send ticket email notification to xxxxx@oremis.fr:
Smtp: Network connection to smtp-relay.gmail.com timed out:
execution expired (Net::OpenTimeout)

What happens afterwards

The important part is what happens after the temporary timeout.

The network connection to Google starts working again, but the Zammad notification SMTP channel remains in an error state.

To restore it, I currently have to go to the notification email configuration, edit/re-open the SMTP configuration and validate/save it again.

After doing that, the channel works again immediately.

So the issue is not really the temporary SMTP failure itself. The issue is that the notification channel does not seem to automatically recover from a transient Net::OpenTimeout.

Network tests

We ran several tests directly from the zammad-scheduler container.

DNS resolution works:

getent ahosts smtp-relay.gmail.com

Result:

XXX.XXX.XX.XX   STREAM smtp-relay.gmail.com
XXX.XXX.XX.XX   DGRAM
XXX.XXX.XX.XX   RAW

A basic TCP connection to port 587 normally works:

timeout 10 bash -c '</dev/tcp/smtp-relay.gmail.com/587' \
  && echo "TCP 587 OK" \
  || echo "TCP 587 FAIL"

Result:

TCP 587 OK

We then performed 50 consecutive TCP connection tests from the same zammad-scheduler container:

for i in $(seq 1 50); do
  printf '%s  ' "$(date '+%H:%M:%S')"

  IP=$(getent ahostsv4 smtp-relay.gmail.com | awk 'NR==1{print $1}')
  printf '%s  ' "$IP"

  timeout 5 bash -c "</dev/tcp/$IP/587" \
    && echo OK \
    || echo FAIL

  sleep 2
done

Result:

15:48:57  XXX.XXX.XX.XX  OK
15:49:00  XXX.XXX.XX.XX  OK
...
15:50:24  XXX.XXX.XX.XX OK
15:50:26  XXX.XXX.XX.XX OK
15:50:28  XXX.XXX.XX.XX  FAIL
15:50:35  XXX.XXX.XX.XX OK
15:50:37  XXX.XXX.XX.XX OK
...
15:50:43  172.217.76.28  OK

So we did reproduce one temporary TCP failure independently of Zammad:

49/50 TCP connections succeeded
1/50 failed

SMTP/STARTTLS test

We also tested actual SMTP/STARTTLS connections directly from the same container, forcing IPv4 and connecting to the same Google IP:

for i in $(seq 1 30); do
  printf '%s [%02d] ' "$(date '+%H:%M:%S')" "$i"

  timeout 10 openssl s_client \
    -4 \
    -starttls smtp \
    -connect 172.217.76.28:587 \
    -servername smtp-relay.gmail.com \
    </dev/null >/dev/null 2>&1 \
    && echo OK \
    || echo FAIL

  sleep 2
done

Result:

15:51:58 [01] OK
15:52:00 [02] OK
15:52:02 [03] OK
15:52:05 [04] OK
15:52:07 [05] OK
15:52:09 [06] OK
15:52:11 [07] OK
15:52:13 [08] FAIL
15:52:25 [09] OK
15:52:27 [10] OK
15:52:30 [11] OK
15:52:32 [12] OK
15:52:34 [13] OK
15:52:36 [14] OK
15:52:38 [15] OK
15:52:40 [16] OK
15:52:43 [17] OK
15:52:45 [18] OK
15:52:47 [19] FAIL
15:52:59 [20] OK
15:53:01 [21] OK
...
15:53:21 [30] OK

So:

28/30 SMTP STARTTLS connections succeeded
2/30 failed

This confirms that there can indeed be very short-lived connection failures between the VPS and the Google SMTP relay.

IPv6

We also investigated IPv6 because the Google Workspace SMTP Relay configuration can authorize both IPv4 and IPv6 addresses.

However, in our container, smtp-relay.gmail.com was resolving to:

XXX.XXX.XX.XX

and our tests above explicitly forced IPv4.

So the failures reproduced above are not caused by an unauthorized IPv6 address.

We nevertheless added the server IPv6 address to the Google Workspace SMTP Relay allowed IPs, but the Zammad Net::OpenTimeout issue still occurred afterwards.

What I believe is the actual issue

I completely understand that a temporary network timeout is outside Zammad’s control.

What seems problematic is the recovery behavior.

I would expect something like:

SMTP connection
        ↓
temporary timeout
        ↓
notification fails / is retried later
        ↓
SMTP becomes available again
        ↓
Zammad automatically resumes sending notifications

Instead, what we currently observe is:

SMTP connection
        ↓
temporary Net::OpenTimeout
        ↓
notification SMTP channel enters an error state
        ↓
SMTP becomes available again
        ↓
channel does not seem to recover
        ↓
manual validation/save of the SMTP channel is required

Expected behavior

A transient SMTP connection error such as Net::OpenTimeout should not permanently disable the notification SMTP channel.

Zammad should ideally retry later and automatically recover once the SMTP server becomes reachable again.

Actual behavior

After a transient Net::OpenTimeout, the notification SMTP channel appears to remain unavailable until it is manually revalidated from the administration interface.

Once it is manually validated again, SMTP works normally.

Question

Is this expected behavior?

Should the notification SMTP channel automatically recover after a temporary Net::OpenTimeout, or is there currently an issue in the retry/error handling of Channel::Driver::Smtp / notification delivery?

I found another community discussion that seems to describe a very similar behavior:

“Outbound notification email gets stuck and never recovers if the email server is temporarily unavailable”

Our case seems very similar: the SMTP outage itself is temporary, but Zammad appears not to recover automatically afterwards.

I can provide additional scheduler logs or run further tests if needed.

2

All Zammad channels are self-healing. Channels however are not constantly “pinging” e.g. SMTP servers. Every successful operation will reset the error state. This means: The next successful notification email being sent is such an operation.

3

Ok, the issue here is :

image
image1833×479 25.3 KB

We need to manually edit and click on done to reset. And all failed job are lost.
The solution proposed by our IT dep is add postifx to manage retry.

Did you have any other information?

Thanks MrGeneration!

4

Then there was not notification mail send during the poeriod or it was not functional in that moment as well. IPv6 routing if not available should be disabled on docker stacks, this is a classic issue on these stacks.

5

Thank you for your time!