Today's Deep-Dive: Exim Internet Mailer

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.

We'll catch you next time.

We'll catch you next time.