The Email They Shouldn't Have Read

Summary

Author's Note: Before we begin, an important clarification. What follows is a horror story based on real events from my career. However, to protect the privacy of the people and companies involved, I have deliberately mixed things up: technologies, contexts, and specific details have been modified or merged with other experiences. I therefore invite you to read this story not as a strict chronicle of a single event, but as an archetype of a widespread problem in the IT world: vendor lock-in and predatory business practices. Any attempt to identify the specific company or software described would lead to an incorrect conclusion.When the phone rang, I was in a meeting - so I didn’t answer. But I recognized the number and sent a quick message: "I’m with a client right now. If it’s not urgent, please send me an email - otherwise I’ll call you ASAP".The reply, via SMS, left me speechless: "That’s exactly the problem. I can’t send you an email. Call me as soon as you can".From that moment on, my perception of a certain kind of world changed forever.A few years earlier, a major public institution - let’s call it Agency A - was still running an ancient Exchange mail server. It hadn’t received security updates for ages, the anti-spam was completely ineffective, and the new regulations were clear: embrace Open Source solutions whenever possible.They had already received a proposal - expensive but seemingly reasonable - for a managed service, hosted by an external provider, built on an open source mail stack. The company offered a managed version with its own proprietary additions and enterprise support. The catch? The price was absurd, and Agency A already had solid infrastructure - reputable IP classes, redundant datacenters, everything working fine. We had built and maintained that environment for years, and it was still running perfectly.The request was simple: “Evaluate this solution, and if it’s suitable, we’ll migrate.”. About 500 active mailboxes, roughly the same numb...