You know, whenever you sit down on your laptop,
type out a quick message, and hit send on an email,
there is this immediate expectation of magic.
Oh, absolutely.
You click the button, there's that little swoosh sound,
and instantly, someone halfway across the world
gets a notification on their phone.
We don't even think about it.
Right, it feels completely frictionless,
like instant teleportation of your thoughts.
Exactly, but beneath that frictionless surface,
there is this massive industrial scale machinery
working frantically.
Yeah, I mean, it has to figure out
where that message actually needs to go,
how it's going to get there, and whether it's
safe to deliver at all.
And the most fascinating part of that machinery
is who actually owns it, because it isn't usually
the big tech companies whose logos are on your screen.
No, not at all.
The invisible infrastructure running our daily communications
is often built, maintained, and fiercely protected
by independent volunteer communities.
Right, and recently, some of those communities
have been making drastic moves to guarantee
they don't get swallowed up by tech monopolies.
They are actively migrating away from corporate platforms
to ensure the internet's core infrastructure remains
independent.
Which is actually the perfect entry point
to talk about the supporter of today's deep dive safe server.
Because just like we take the routing of our email
for granted, a lot of organizations
take their expensive proprietary software for granted.
Oh, definitely.
They just accept the massive licensing fees
for things like Microsoft Exchange or Google Workspace
as an unavoidable cost of doing business.
Right.
But safe server steps in and says,
you actually have much better options.
They help organizations replace those expensive proprietary
email and workspace tools with incredibly powerful open source
solutions.
And we are talking massive cost savings here.
Huge savings.
But beyond the budget, it really comes down to data sovereignty.
If your business or association deals
with legal, regulatory, or compliance requirements,
think strict email retention policies, data protection laws,
financial records, or rock solid audit trails,
you cannot afford to lose control of your information.
You need to know exactly where your data lives
and who holds the keys.
Exactly.
And safe server guides you from the very first consulting
meeting all the way through to full operation
on highly secure German servers.
So to take back control of your digital infrastructure,
head over to safeserver.de, that's www.safeserver.de.
Taking control of the underlying infrastructure
is exactly what we are dissecting today.
Yes, welcome to the deep dive.
Today we are exploring a piece of software
that practically runs the internet,
even if you've never heard its name.
It's called the Exum Internet Mailer.
It's a true hidden giant.
It really is.
And we've got a fascinating stack of sources
today pulling directly from Exum's official website
and their master source code repository.
There's a lot to unpack there.
Definitely.
Our mission for this deep dive is
to give you, especially if you're a beginner,
the network architecture a clear, easy entry
point into what this foundational piece of software
is, how it actually works under the hood,
and why it just recently made a massive rebellious shift
in how it's developed.
So to understand what Exum is, we first
have to separate the program you use to write your email
from the program that actually moves it.
Right, the front end versus the back end.
Exactly.
The software on your phone or laptop, like Apple Mail
or Outlook, that's called a Mail User Agent, or MUA.
But Exum operates a layer deeper.
The documentation defines Exum as a message transfer agent,
or an MTA.
It was originally developed at the University of Cambridge
for use on Unix systems connected to the internet.
So let me put a picture to this for you.
Think of Exum as a massive digital postal sorting
facility.
OK, I like that analogy.
Right, it doesn't write the letters for you.
It certainly doesn't read them out loud to you.
It's the invisible infrastructure.
Yeah, you drop your envelope in the blue mailbox,
and Exum is the facility that takes over.
Exactly, it looks at the zip code,
figures out if the package needs to go by truck or by plane,
checks to make sure the envelope isn't
leaking any hazardous materials, and routes it
to the exact right local post office.
That is the perfect way to visualize the logistics layer.
You know, when Exum was created, there was another famous tool
doing this job called SendMail.
Right, SendMail was the big one back in the day.
SendMail was the dominant force, yeah.
But it was notoriously difficult to configure,
so Exum was designed so it could be
installed in place of SendMail.
Ah, a drop-in replacement.
Exactly.
The documentation notes it's similar in style
to an even older mailer called Smail3,
but vastly more general.
And the reason Exum became such a cornerstone
of internet communication is its flexibility.
Because it can handle complex routing.
Yes.
It offers incredibly flexible routing capabilities
and extensive facilities for checking incoming mail.
And given the sheer volume of spam, fishing attempts,
and malicious traffic on the internet today,
those incoming checks are totally non-negotiable.
Oh, absolutely.
You essentially need a highly-trained bouncer
at the loading dock of your sorting facility.
And the best part is this bouncer is completely free.
Exum is available under the GNU general public license.
Which is a huge deal in the open source world.
It is.
That specific license is important,
because it doesn't just mean the software is free of charge.
It means the source can is completely open,
and anyone is legally guaranteed the right to study it, modify it,
and distribute it.
So anyone can look at the blueprints of the sorting
facility.
Exactly.
And for anyone who really wants to get into the weeds
and master how it all connects, the original author, Philip
Hazel, actually wrote a definitive book called
The Exum SMTP Mail Server.
But the sources do make a very clear recommendation
for the average user, right?
They do.
If you are running a standard Linux or Unix system,
you shouldn't try to download the raw code
and build this thing from scratch like a giant Lego set.
No, definitely not.
Unless you have highly specialized requirements,
they strongly advise using the prepackaged versions provided
by your operating system.
Yeah, let the package maintainers
do the heavy lifting.
I mean, compiling raw code into a functioning program
requires configuring it for the exact quirks
of your hardware and operating system.
Which sounds like a headache.
It is.
The volunteers who maintain Linux distributions
have already done that tuning for you.
And when we look under the hood of Exum,
you begin to understand why compiling and testing
this software is such a monumental task.
The scale of the project is just staggering.
When you look at their source repository,
there are 6,890 commits.
That's a massive history of updates.
Yeah, commit is basically a logged individual update
or fixed to the code over time, almost 7,000 of those.
But looking at the stats for how this is built,
I have to stop you and push back on something.
OK, what is it?
We are talking about the backbone of internet
communication, right?
Right.
And the code base is overwhelmingly written
in the C programming language.
Like, 92.3% of it is C.
Yeah, it's heavily reliant on C.
The rest is a mix, 4.4% Perl, 1.9% Shell,
and a tiny 0.4% fraction of Elixir.
But 92% C, that is a language from the 1970s.
It is an older language, yes.
And it requires the programmer to manually manage
computer memory.
Manual memory management is where so many catastrophic software
bugs come from.
So why hold on to this ancient architecture?
It's a fair question.
Why wouldn't a community-driven project
just rewrite it in a safer, modern language like Rust?
Well, that is the ultimate debate in system-level
programming right now.
Why stick with C?
For one, you are dealing with a project that has been actively
developed for decades.
Rewriting millions of lines of foundational, tested logic
from scratch is just an operational nightmare.
OK, so it's a momentum thing.
Partly.
But more importantly, C is incredibly fast.
It operates very close to the hardware at what developers
call bare metal.
When your server is processing millions of emails an hour,
tearing apart headers, checking them
against global blacklists, and routing them
down different network pipes, you cannot afford software
bloat or translation layer.
This just need pure speed.
Exactly.
You need raw, high-performance, low-level system interactions.
Still, requiring volunteer programmers
to manually allocate and free up memory
for every single operation feels like walking
a tightrope without a net.
It can be risky, yeah.
I mean, one wrong step, one forgotten line of code,
and the program crashes.
Or worse, it creates a massive security hole.
Which brings us to how a project like this actually survives.
Rigorous, continuous, automated testing.
Ah, okay.
You mentioned the other languages in the repository,
the Perl, the Shell scripts, the Elixir.
While C handles the heavy lifting of routing the mail,
those other languages are largely used
for scripting, tooling,
and running the testing infrastructure.
But a community project doesn't have a corporate mega-budget
to buy warehouses full of servers
for all this testing, right?
No, they don't.
They rely on organizational sponsors,
and the sources explicitly highlight them.
Yeah, a company called Mythic Beasts
provides a virtual machine,
which is essentially a simulated computer
running on a larger server,
specifically for their test suite build farm.
Right, and a build farm is exactly what it sounds like.
It's a dedicated environment
whose only job is to automatically download
the latest version of the code, compile it,
and run thousands of simulated emails
and scenarios through it.
Just to see if anything breaks
before it gets released to the public.
Exactly.
They also get help from McStadium,
who provides a Mac mini for their build farm.
And that is a crucial detail.
Testing on a Mac mini ensures the code functions correctly
across Apple specific Unix architecture,
not just standard Linux servers.
You need to know the code works everywhere.
You do.
Furthermore, an organization called Schlitterman
handles the hosting and administration
of the entire Exum.org infrastructure.
And Mike Cardwell designed the website.
Right.
It really takes a village to run the internet.
You have these separate independent companies
donating server power and hardware
just so the Exum developers can constantly run their code
through the ringer.
They have to be absolutely certain that 92% C code base
doesn't have a typo that breaks global email.
Because when a typo or a logic error
does slip into a C program that sits on the open internet,
the consequences are immediate and severe.
Very severe.
Which leads directly into the security documentation
we reviewed and the very real danger of obsolescence.
Yes, this is critical.
According to the official site, the current version of XM
is 4.99.1.
And this isn't a fun feature update
with a fresh coat of paint.
No, not at all.
This is a strict security release.
The release notes are highly specific about this.
Version 4.99.1 was pushed out to address
what is called a remote heap corruption vulnerability.
Blikes.
Yeah.
The official tracking designation for this
is CVE 202567896 or internally as XM security 202512-09.1.
OK, remote heap corruption sounds highly technical.
If we go back to our sorting facility analogy,
how does this actually compromise the system?
Well, the heap is the massive warehouse floor
where workers temporarily place packages while they
figure out where they go.
OK, temporary storage.
Exactly.
In a C program, the heap is a pool of memory
used for dynamic temporary storage.
A remote vulnerability means a bad actor somewhere out
on the internet can trigger this without needing
a password or internal access.
Wow.
So they're just sending a bad package into the facility.
Right.
Imagine a bad actor sending a package through your facility.
But instead of writing a normal destination,
they write an address that is so overwhelmingly long,
it physically spills off the edges of the envelope.
Oh, I see.
It spills over and literally covers the digital instruction
manual of the sorting machine itself.
Because the programmer didn't set a hard limit
on how long that address could be in the memory.
Exactly, that manual memory management issue we discussed.
The machine gets confused.
When the machine tries to read its next operational command,
it's actually reading the malicious text
the attacker wrote in the address line.
That is wild.
So they are tricking the mail server
into running malicious code instead of just routing emails.
Yes.
They could potentially take over the entire program.
It is one of the most critical types
of vulnerabilities a network facing service can have.
Once they control the sorting machine,
they can intercept mail, use your server
to blast out millions of spam messages,
or pivot further into your network.
And the Exim project takes an incredibly hard line
on this in their documentation.
They do.
The sources state that all versions prior to 4.99.1
are now completely obsolete, period.
They even specifically call out the old 3.x releases,
the last of which was 3.36.
They point out the version 3.36 is 20 years obsolete
and should absolutely not be used.
It is rare to see official documentation be that blunt.
Usually software developers use softer language
like unsupported or deprecated.
Right, they try to be polite about it.
Exactly.
But calling it 20 years obsolete is a blaring warning siren.
If you are running version 3.36 today,
you aren't just out of date.
You are actively inviting attackers into your network.
And this brings up the core responsibility
of running internet infrastructure.
The EXIM developers offer maintenance releases
primarily for those package maintainers
we mentioned earlier.
And they offer beta versions and a specific testing directory
for administrators willing to test unreleased code
at their own risk.
But the developers cannot force you to update your server.
They can't just remotely push a patch to your specific machine.
No.
If you set up an EXIM server five years ago,
got it working, and just forgot about it.
You are a sitting duck.
You are a danger to your own organization
and honestly to the rest of the network
if your server gets hijacked.
The hard line on obsolescence is a cultural marker.
How so?
It's the project declaring that they provide
this incredibly powerful tool for free,
but the cost of entry is your constant vigilance.
I love that.
And that strong sense of culture, boundary setting,
and responsibility perfectly contextualizes
the biggest piece of news we found in the source repository.
The migration.
Exactly.
When you understand how fiercely independent this team
has to be to maintain the software,
their recent migration makes perfect sense.
The Exum project is undertaking a massive move
to gain total independence from big tech.
And this is a profound shift that
reflects a growing movement in how open source
projects operate today.
OK.
So here are the facts directly from the repository's
RiaDME file.
As of December 26, 2025, the Exum project
officially stopped using GitHub.
Which is huge.
They are no longer pushing any updates
to the world's most popular code hosting platform.
Instead, the master repository is now entirely
self-hosted.
Taking it all in-house.
Yeah.
It's running on their own instance
of a platform called Forgejo, located at code.exum.org.
You know, to understand the magnitude of this decision,
you have to look at the landscape of software
development.
For the last decade, GitHub, which is owned by Microsoft,
has been the absolute center of gravity
for open source software.
It's where almost everyone collaborates, tracks issues,
and publishes code.
I mean, when GitHub goes down, half the internet's
developers suddenly can't work.
Exactly.
Leaving GitHub is not a casual decision.
It is an enormous operational burden.
So what is Forgeo, then?
Forgeo is a lightweight, community-managed software
forge.
It does what GitHub does, hosting code, tracking changes,
managing collaboration.
But you can install it on your own server.
So Exum's is taking the entire postal service infrastructure
and moving it out of the corporate landlord's building
into a facility they own themselves.
That's exactly it.
And if we connect this to the ethos of open source
that we've been discussing, the GNU license,
the volunteer community, the donated hardware
for the build farm, it aligns perfectly.
It's all about independence.
Right.
When you rely on a centralized, corporate-owned platform
to host your code, you are fundamentally
renting your digital home.
You are subject to their changing terms of service,
their algorithms, their AI data-scraping policies,
and their potential downtime.
For a project that literally acts
as the foundational infrastructure
of the open internet, being beholden
to a single corporate entity is a massive vulnerability.
It's a huge risk.
They are treating reliance on Microsoft's GitHub
the same way they treat a memory leak in their C code
as a risk that needs to be mitigated.
Total sovereignty over the tools that build the tool.
By hosting their own code on Fortjose,
they guarantee that no corporate entity can ever
pull the plug on their repository
or change the rules of access.
Wow.
Furthermore, the documentation outlines
their entire decentralized workflow.
Their bug tracking is currently handled
through an independent instance of a tool called Bugzilla
located at bugs.exim.org.
Though the notes mentioned they will soon migrate
that bug tracking directly into the new
for JoJo repositories issues section, right?
To centralize everything in their own system.
And they aren't relying
on corporate communication tools either.
They aren't setting up a slap workspace or a discord server.
No, not at all.
Development discussions happen the old fashioned
decentralized way on the EximDev mailing list.
General help and community troubleshooting
happen on the Exim user's mailing list.
They're using email to build email.
Right, it is a complete ecosystem
built on the very email protocols they champion.
They are literally eating their own cooking.
It is a strong statement that the open web is still viable.
You don't have to surrender your workflow,
your data or your community to a tech giant
just for the sake of convenience.
But it takes a staggering amount of work
to pack up your digital house
and move your entire community to a self-hosted platform.
It's exhausting just thinking about it.
But the freedom on the other side
is clearly worth it to this team.
And this brings us to a crucial realization
about the internet as a whole.
We assume the internet just works.
We assume emails arrive, websites load
and data routes correctly.
But it's actually held together
by incredibly dedicated communities
writing complex code and running test farms
on donated servers.
Exactly. Exim's move to self-host on Forgeo
guarantees their independence for now.
But it does introduce a new provocative question
that every foundational open source project
will eventually have to face.
The succession problem.
Right.
Break that down for you, Yumi.
What exactly is this succession problem?
Well, consider the demographics.
Many of these foundational protocols
like the mail systems we rely on
were built by volunteers decades ago.
As the original architects and maintainers
age out or retire,
who inherits the keys to the internet's post office?
That's a scary thought.
It really is.
Will the next generation of developers
who are largely trained on modern languages
and centralized corporate platforms
be willing to learn manual memory management in C?
Let alone maintain self-hosted bug trackers.
Exactly.
Achieving digital sovereignty from big tech
is a massive victory today,
but the true test is whether this independent,
volunteer-driven model
can survive a generational handover.
That is a question every organization relying
on digital infrastructure needs to ponder.
Who holds the keys to your systems?
It's the most important question you can ask.
Which, frankly, brings us right back to our sponsor,
Safe Server.
Safe Server is entirely built around solving
that exact problem for your organization.
Because you really don't have to rent space
in a corporate walled garden
and just hope they don't change the rules
or hike the prices.
Exactly.
By switching to open source solutions
implemented by Safe Server, businesses, associations,
and other groups, gain massive cost savings
compared to those expensive proprietary software licenses
from Google or Microsoft.
And beyond the cost, just like the Exum project,
you take back your data sovereignty.
Yes.
You control your infrastructure,
which is vital for compliance, legal audits,
and protecting your communications.
Whether you need a direct replacement
for your workspace tools,
or you just need specialized consulting
to figure out if a comparable alternative
is the right fit for your specific organizational needs,
Safe Server is there to help.
They make the transition manageable.
They really do.
So reclaim your infrastructure
by visiting www.safeserver.de.
It's all about understanding how the machinery works
so you can make it work for your specific needs
on your own terms.
Beautifully said.
So next time you type out an email
and click that send button,
take a second before you assume it's just magic.
Picture that massive digital sorting facility.
Think of the 92% C code.
The rigorous automated testing running on donated Mac minis
and the fiercely independent community
ensuring that your message finds its way through the dark.
The magic isn't in the button you click.
It's in the invisible open source infrastructure
that catches it.
Thanks for joining us on this deep dive.
We'll catch you next time.