Right now, almost every conversation in technology seems to circle back to AI. New models, new agents, new workflows, new ways to automate things, and honestly, I enjoy that rabbit hole too. But for this post, I wanted to take a small break from the AI noise and talk about something older, quieter, and still extremely important: email.
For some people, email is just communication. It is one of those boring parts of the internet that quietly sits in the background while newer tools get all the attention. Chat apps feel faster, dashboards feel more modern, AI tools feel more exciting, and collaboration platforms look cleaner. Email, by comparison, often feels like plumbing. But after spending six years around managed email services in Nepal, I stopped seeing it that way.
For many organizations, a single email is not just a message. It can be a medical report someone is waiting for, a financial transaction confirmation, a document needed for travel, or information required before someone can board a flight. When that email is delayed, blocked, spoofed, or used as part of a phishing attempt, the problem is no longer just technical. It becomes operational. Sometimes it becomes personal.
That realization stayed with me while I was completing my Master's Degree in Information Technology. For the thesis component, I worked on a study titled "Real-Time Analysis and Automated Mitigation of Spam/Phishing Attacks." On paper, that sounds like a cybersecurity thesis. In reality, it came from years of watching email security problems show up in very practical, very human ways. This post is not just about the system I built for that thesis. It is about what managed email taught me first, and how those lessons shaped the system I eventually built.
Six Years Around Managed Email in Nepal
I spent around six years working at a service provider in Nepal where managed email was one of the services we handled. On the surface, email service sounds simple enough: create accounts, keep the mail flowing, make sure users can send and receive messages, and fix things when something breaks. In practice, it was never that clean. Email security was always somewhere in the middle of the work, showing up through spam floods, phishing links, compromised accounts, blacklist issues, false positives, and customer complaints.
Sometimes the problem was obvious, like an account suddenly sending a suspicious amount of mail. Sometimes it was subtle, like a customer insisting an important message was missing while the logs told a more complicated story. The harder part was that many customers were not deeply technical, and honestly, they should not have needed to be. A hospital, travel agency, school, or small business does not want a lecture about headers, reputation scores, DNSBLs, or mail queues when something goes wrong. They just want their mail to work, and they want to know whether they are safe.
That made the job more than just operating mail servers. It became a mix of troubleshooting, tuning, explaining, and sometimes translating security problems into normal human language. Over time, I started seeing email security less as a single tool or feature and more as an operational responsibility.
When Email Became the Main Road
In Nepal, email was not always treated as the first communication method for every organization. It existed, it mattered, and businesses used it, but in many places it was not always the center of daily operations. Then COVID-19 happened, and the way people worked changed almost overnight. Offices moved into homes, teams became distributed, and organizations that previously depended more on in-person communication, phone calls, or informal channels suddenly needed email to carry a much larger share of their work.
That shift changed the pressure around email. When more communication started flowing through inboxes, the value of those inboxes increased too. Attackers follow attention, and spam and phishing started becoming more visible and more painful. A phishing email was no longer just some random suspicious message that an employee might ignore. It could land in the middle of an approval process, a finance workflow, a travel plan, or a customer conversation. The same email system that helped organizations continue working remotely also became a bigger attack surface.
This is where the local context matters. In countries with larger budgets, the default answer is often to buy a commercial security product, integrate it, and move on. For many organizations in Nepal, that is not always realistic. Cost is one of the biggest constraints. The need for security is real, but the budget does not always match the pricing model of enterprise tools built for much larger markets. So the question becomes more practical: how do you improve email security when you cannot simply buy your way out of the problem?
The Cost Problem Became an Integration Problem
In practice, the answer was usually a mix of open-source tools, freemium tools, and a lot of tuning. Tools like Proxmox Mail Gateway, SpamAssassin, and Rspamd were useful because they gave us control and flexibility without immediately forcing everything into an expensive commercial product. But they were not magic boxes. They needed constant adjustment, testing, and sometimes a good amount of patience before they behaved the way we wanted in a real customer environment.
The bigger challenge was that no single affordable tool gave us everything in one place. One tool might be better at filtering, another might expose useful logs, another might be easier to tune, and another might help with a specific kind of detection. So the work became less about finding one perfect product and more about stitching useful pieces together. We used multiple tools for multiple things, built custom utilities where there were gaps, and slowly shaped the system around the problems we were actually seeing.
That experience changed how I thought about security tooling. A feature checklist is nice, but in real operations the important question is whether the system can be understood, tuned, observed, and improved. If a tool blocks mail but no one can explain why, it creates another support problem. If a tool detects something but the signal is buried in logs no one watches, it does not help quickly enough. If a tool is powerful but too expensive for the organizations that need it, then it remains more of an aspiration than a practical solution.
Visibility Was the Missing Piece
One of the biggest frustrations in managed email was poor visibility. Filtering tools could tell us that something looked suspicious, but day-to-day operations needed more than that. We needed to know when an account was behaving differently, when outgoing mail volume suddenly increased, when a sender might be compromised, and when a customer complaint was part of a bigger pattern instead of an isolated issue. Without that visibility, email security felt reactive. You waited for a complaint, checked logs, guessed what happened, tuned something, and hoped the same issue would not come back tomorrow.
That is why we ended up building our own small tools around the systems we already had. One example was monitoring the amount of mail being sent so we could identify accounts that might have been compromised. Another was writing custom parsers for logs, because the information existed somewhere, but not always in a form that was easy to search, understand, or act on quickly. A lot of the work was not glamorous. It was parsing, counting, correlating, and tuning. But that boring work mattered because it turned vague suspicion into something we could actually investigate.
Over time, I started trusting visibility as much as filtering. A filter can stop a message, but visibility helps you understand why it was stopped, what else is related to it, and whether the same pattern is spreading. That distinction became important later when I worked on my thesis. I did not want to build only another spam detection setup. I wanted the system to detect, score, act, and also leave behind enough evidence for someone to understand what happened.
How Those Lessons Shaped My Thesis
When it came time to choose and complete my thesis for the Master's Degree in Information Technology, I already had a problem space that felt real to me. I did not have to search too far for a topic that looked good only on paper. Email security had been sitting in front of me for years, not as an abstract cybersecurity category, but as a daily operational problem involving customers, support teams, limited budgets, imperfect tools, and real consequences when things went wrong.
That is how the thesis topic, "Real-Time Analysis and Automated Mitigation of Spam/Phishing Attacks," started making sense. The goal was not to invent a completely new theory of phishing detection. It was to explore whether open-source tools could be connected into a practical workflow that could detect suspicious email indicators, assign risk in real time, take action automatically, and still provide enough visibility for analysis. In other words, it was a formal research version of a question I had already been asking in practice: can we build something useful, affordable, and understandable without depending entirely on expensive vendor products?
The thesis also gave me a way to think about the problem more systematically. In day-to-day operations, you often solve the immediate issue first because the customer needs an answer now. Research forces you to slow down and ask why the issue exists, what signals matter, how the components should connect, and how you would measure whether the approach is working. That shift was useful. It helped turn years of operational frustration into a clearer architecture and a more testable idea.
What I Built
The system I built for the thesis was an open-source email security pipeline using Rspamd, a custom scoring API, and the ELK Stack. The idea was simple: when an email comes in, Rspamd extracts useful indicators like the sender IP address, sender domain, and URLs inside the message. Those indicators are then sent to a custom API built with Python and FastAPI. The API checks them against multiple blacklist and threat-intelligence sources, applies weighted scoring, and returns a risk score that Rspamd can use to decide what should happen next.
That decision could be different depending on the score and the mode of operation. A low-risk email might pass normally. A suspicious email could be tagged or monitored. A high-risk email could be quarantined or rejected before reaching the user. This was important to me because a detection system that only says "this looks bad" is incomplete. In real operations, the useful part is connecting detection to action, but doing it carefully enough that false positives do not create a new problem.
The other major part was visibility, which is where ELK came in. Elasticsearch, Logstash, and Kibana were used to collect, parse, store, and visualize the events coming from the system. Instead of treating each email as an isolated event, the logs could show patterns: which senders were triggering detections, which IPs or domains appeared repeatedly, and whether suspicious activity was increasing. I also tested correlation-style alerts, like detecting a single sender sending too many emails in an hour, a single IP flooding the system, or one sender appearing across many different IPs.
For testing, I used real-world datasets like OpenPhish and The Blocklist Project, along with controlled test cases in a virtualized environment. The system was not perfect, and I do not want to pretend it was a production-ready commercial security product. But the results were encouraging for a thesis prototype: the mixed test case showed 86% accuracy, 92.31% specificity, and an F1 score of 0.8443. More importantly, it proved the core idea that open-source tools could be connected into a working detect-score-act-observe pipeline.
What I Learned
The biggest lesson for me was that affordable security is possible, but it is rarely plug-and-play. Open-source tools can be extremely powerful, especially when they are flexible enough to be adapted to local needs. But flexibility also means responsibility. Someone has to understand the tools, tune them, connect them, monitor them, and keep improving them as the environment changes. That is not a weakness of open-source. That is the trade-off you accept when you choose control over convenience.
I also learned that visibility matters as much as detection. It is tempting to think of email security only in terms of whether a message was blocked or allowed, but real operations are more complicated than that. You need to know why something happened, whether it is part of a pattern, whether the same sender or IP appears elsewhere, and whether the system is creating false positives that hurt legitimate communication. A security system that cannot explain itself becomes difficult to trust, especially when the people affected by it are not technical.
The other lesson is that local context matters. A solution that makes sense for a large company in a high-budget market may not fit a school, NGO, travel agency, small business, or local organization in Nepal. That does not mean those organizations need weaker security. It means the solution has to be practical for their reality. Cost, technical literacy, support effort, and operational visibility all matter. Security that nobody can afford, operate, or understand is not really security for that environment.
Final Thoughts: Underestimated Until It Breaks
Email security is easy to underestimate because most of the time, good email infrastructure is invisible. If everything works, nobody thinks about the filters, queues, logs, reputation systems, or blacklists sitting behind the scenes. The mail arrives, people reply, business continues, and the system disappears into the background. That is exactly why it is so easy to treat it as "just email."
But the moment something goes wrong, email suddenly becomes very visible. A phishing message reaches the wrong person. A legitimate message gets blocked. A compromised account starts sending spam. A domain reputation issue affects delivery. A customer waits for a document that never arrives. These are the moments that remind you that email is not just old internet plumbing. It is still part of the trust layer many organizations quietly depend on every day.
My thesis was one attempt to explore a practical answer to that problem. It was not perfect, and it was not meant to replace every commercial security product. But it showed me that there is real value in building systems that are affordable, observable, tunable, and grounded in the context where they will actually be used. For countries and organizations where cost matters, that kind of practical open-source approach is not just a compromise. Sometimes it is the only realistic path forward.
For some people, it is just email. For many organizations, it is the message that keeps a process moving, a transaction trusted, a patient informed, or a traveler ready to go. That is why email security still matters, even when it is not the newest or most exciting thing in technology. Maybe especially then.
