We have Zammad using Office 365 and OAUTH 2, with multiple groups. On occasion, there can be an issue communicating with Microsoft’s SMTP server, be it a local issue or not (or, it could be Zammad itself or the VM it runs on - but when it happens the web UI works fine).
Whenever that happens when an agent tries to send a reply, an error is logged in the ticket itself, but it doesn’t seem like Zammad queues up the email for retries?
That’s objectively quite bad, it requires the agent to realize it is a permanent failure and it also requires them to try to re-write or re-send the reply later, and remember to do that.
Every email server/handler ever made has a queue function where something gets stored once you send it, and it is then active for some days trying to resend if the first send fails.
Zammad needs something similar, in my opinion. A notification that sending failed, but that Zammad will keep trying would be a lot nicer than “connection failed, sucks to be you”.
Ok, but over how long a period of time? When mail sending fails, the agent gets that failure notification basically immediately and the system doesn’t seem to indicate it’s planning to try sending again later. Maybe it’s a case of how the system messages about the failure, if the system queues the mail for sending and retries later.
But at least as fart as the user experience goes, the failure happens quite rapidly and there’s no indication the system plans to retry sending.
That highly depends on how loaded your system is.
Within an hour. I’m not aware of specific timely pausing in between.
Usually most users want a fairly immediate feedback or don’t monitor their Zammad well enough anyway.
Especially the last point becomes an issue when you’re not aware that your sendout is broken at some point.
The way Zammad currently behaves your agents will notice on a fairly timely manner.
Maybe ramping up timings slightly would help (that would be the feature request part)