Those who watched 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's telephone systems. Many vendors use the term "unified communications" because of this. Honestly, we never understood what this term stands for, so we 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 system messages. Every email reset the client, and he or she could start all over again. We had the email client run in its own thread, so things like timeouts and connects could be easily programmed.

There were problems with this approach, however. 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. That wasn’t even the biggest problem, as we got the email client working pretty stable. A bigger problem was that in a multi-tenant environment, every domain might use its own email server. When that email server was down, all other domains were also affected. Email would still eventually go out, but it could take a long time before it happened. This was against the rule that every tenant should be working independently from anyone else.

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

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