Those who watched the release 5.2.3 closely might wonder what was going on with the email client. The first build had major problems with Linux operating systems. A second build was necessary to get it working again with popular email services.

Email has become an essential component in today telephone systems. Many vendors use the term unified communications because of this. Honestly we never understood what that term stands for and avoided the buzzword. Notwithstanding, the good old SMTP protocol delivers notifications and messages that are available on a telephone system fast and reliably across a very large range of devices.

The old email client was using a single loop for all messages of the system. Every email reset the client, and let him start all over again. We had the email client run in its own thread, so that things like timeouts and connects could be programmed in an easy way.

However there were problems with this approach. First of all, multithreaded tasks are always a source for trouble. If problems occur, they occur on a random basis; some of them occur only sometimes, and those are the hardest to fix. Anyway, that wasn’t even the biggest problem as we got the email client working pretty stable. What was a bigger problem was that in a multi-tenant environment, every domain may use their own email server. When that email server was down, all other domains were also affected by the problem. Email would still eventually go out; but it could take a long time before that happens. This was against the rule that every tenant should be working independent from anyone else.

When we changed the client to be multi-tenant of course we tried to preserve the proven logic from the single loop client. However, thanks to the fact that most email servers support a dynamic switching from unencrypted to encrypted traffic using the STARTTLS command, our new client got into trouble when the second email was sent out right after the first one. The TLS context was still the same, and what the PBX essentially did was a CONTINUETLS command. Unfortunately, no email server supports that. That was the reason why we needed to come up with another build that also fixes that problem.

If you have upgraded to 5.2.3 before June 28, we recommend to repeat the upgrade to make sure that you got those last-minute email patches. Then you can enjoy fast and reliable email like never before.