Today's Deep-Dive: Stalwart

If you look back at how a mid-sized company handled its internal server room even

just

a decade ago, the reality was just incredibly grim.

Oh, absolutely grim.

The IT administrator usually spent their days just desperately trying to stitch

together

a dozen completely different pieces of software, and all that just to ensure an

email could

travel from one desk to another.

Right.

Just basic functionality.

Exactly.

You had one application responsible solely for routing the mail, a totally separate

database

for storing it, and then, you know, a third clunky module bolted onto the side just

to

guess if a message was spam.

And none of them were actually designed to talk to each other.

No, not at all.

It was this operational nightmare of like duct tape and really fragile code.

The friction in those legacy systems was monumental.

I mean, the seams where those discrete applications interacted, those were the

primary fault lines.

That's where things broke down.

Always.

That's where the system would inevitably crash under a heavy load or even worse,

where massive

security vulnerabilities would just open up.

And for years, the industry just accepted this disjointed approach, you know,

because

hosting your own communications was just inherently complex.

There simply wasn't a streamlined alternative out there.

And because building that system yourself was such a massive headache, the default

alternative

just became, well, surrendering entirely.

Right.

Yeah.

Organizations just handed all their internal data over to a massive tech giant.

But before we dive into how that paradigm is completely shifting today, I want to

welcome

you to the deep dive and introduce our supporter for today, SafeServer.

It's a really fitting sponsor for this topic, obviously.

No.

It perfectly aligns.

SafeServer's entire mission is centered on organizations taking back control of

their

infrastructure.

They specialize in helping organizations use modern open source tools to completely

replace

expensive proprietary services from giants like Microsoft or Google.

And often at a fraction of the recurring cost.

Oh, a huge fraction.

But it's not just the money.

No.

The compliance context is arguably even more critical here.

Yeah.

Explain that a bit for the listener.

Well, when an organization is subject to strict legal and regulatory requirements,

things

like mandatory email retention policies, rigid data protection laws, financial

record keeping,

or maintaining immutable audit trails, data sovereignty is just paramount.

Because you need to know exactly where your data is.

Exactly.

You cannot afford to rely on a vendor's black box, you know, storing your highly

sensitive

data in jurisdictions where you have absolutely no control over it.

Keeping your data on your own terms is a regulatory necessity.

And Safe Server facilitates exactly that.

They help organizations find and implement the exact right open source solution for

these

specific needs.

From start to finish.

Right.

Handling everything from the initial consulting phase all the way through to

actively operating

the software on highly secure German servers.

You can find more information on how they do this at www.safeserver.de.

Highly recommend checking them out.

So okay, let's unpack this.

Our mission today is to explore a piece of software called Stalwart.

It's an all-in-one mail and collaboration server.

And we really want to dissect the mechanics of how it actually works, even if you,

you

know, don't spend your days writing server configurations.

Exactly.

Because as we established, the old way of setting up an email server was this

fragile jigsaw

puzzle of outdated components.

But Stalwart claims to throw out that entire legacy playbook.

It really does.

It fundamentally re-architects the whole approach.

Instead of running a separate mail transfer agent and a separate message store and

standalone

calendar servers, Stalwart just compiles all of those functions into a single

unified software

binary.

Which is wild to think about.

It operates from one centralized configuration file.

So for an administrator, instead of learning the bizarre configuration languages of

five

different legacy tools, you are managing one cohesive system.

The operational overhead just drops dramatically.

Exactly.

I'm trying to visualize this difference in architecture.

The legacy setup feels a bit like early computing, where you had a massive

motherboard and you

had to slot in a separate sound card, a separate graphics card, and a separate

network card

and just pray the drivers didn't conflict.

Oh, yeah, the driver conflicts were the worst.

Right.

But Solward sounds more like a modern system on a chip, like the processor in your

smartphone,

where the CPU, the graphics, and the memory controller are all just fabricated onto

one

unified piece of silicon.

That's a great analogy.

They share the same logic inherently.

But wait, I have to push back on this a little bit.

Sure, go ahead.

In software, if a single tool tries to handle the mail routing and the calendar syncing

and the contact management and all the security protocols, doesn't an all-in-one

tool risk

being a jack-of-all-trades, master of none?

That is the classic fear, yeah.

Because usually, massive, monolithic applications just suffer from severe

performance bottlenecks.

Right, but what's fascinating here is that stalwart bypasses those traditional

bottlenecks

completely, and the primary reason lies in its underlying architecture.

Okay, how so?

Software is written entirely in a modern programming language called Rust.

Rust.

Now, for anyone outside the immediate software development sphere, the choice of

programming

language might just sound like a minor detail, but Rust is famous across the entire

industry

for a very specific architectural guarantee.

Which is?

It's known as memory safety.

Memory safety.

I've seen that term floating around a lot in cybersecurity discussions lately.

Does that just mean it prevents the software from crashing when the server gets too

busy?

Oh, it goes much deeper than just handling a heavy workload.

Okay.

In older programming languages like C or C++, which, by the way, the vast majority

of legacy

mail servers were built upon, the human developer has to manually write

instructions for how

the computer allocates and frees up its short-term memory, its RAM.

Which leaves a lot of room for human error.

Exactly.

If a developer makes a tiny mathematical error in that manual allocation, they

leave behind

what's called a dangling pointer, or they allow data to spill over its assigned

boundary.

Oh, like a buffer overflow.

Precisely.

That is a buffer overflow.

And malicious actors actively hunt for those mathematical errors.

They exploit them by sneaking their own executable malicious code into those poorly

managed memory

spaces.

Ah, so it's not just a stability issue.

It's literally an open door for a hacker to take over the machine.

Precisely the opposite of what you want in a public-facing communications server.

Yeah, that sounds terrifying.

Well, Rust approaches this entirely differently.

It uses a strict ownership model that the compiler actually checks before the

software

is ever allowed to run.

It physically won't run if it's broken.

Right.

It mathematically proves that the memory will be managed correctly.

It simply will not allow a developer to compile code that contains those

traditional memory

vulnerabilities.

Wow.

So inherently, stalwart's foundation is immune to entire classes of bugs that have

plagued

email infrastructure for the last 30 years.

Okay.

So because Rust guarantees that the server itself won't spontaneously crash or get

hijacked

through memory bugs, the next logical vulnerability an attacker will target is the

data itself,

right?

Exactly.

If they can't break the server, they go for the payload.

They will try to intercept the emails while they're sitting on the disk or moving

across

the web.

In looking at the technical audits, the developers seem hyper aware of this.

They definitely are.

The documentation outlines encryption at rest using SIME or OpenPGP, and then

automated

TLS certificate provisioning through something called ACME.

Let's break those down a bit.

Sure.

Encryption at rest makes sense.

Intuitively, you basically scramble the data on the hard drive.

But how do SMIME and OpenPGP actually achieve that?

So ACME and OpenPGP both utilize asymmetric cryptography.

When an email arrives and is stored on the stalwart server, it isn't just sitting

there

as plain readable text.

It is actively encrypted using a public key.

And the crucial mechanism here is that only the user with the corresponding private

mathematical

key, which is usually stored securely on their local device, can actually decipher

that text.

So even if someone breaks in?

Even if a bad actor physically steals the server's hard drives from the data center,

the data they extract is mathematically indistinguishable from random noise.

That's incredible.

So that covers the data sitting still.

But what about the ACME protocol for TLS certificates?

Oh, yeah.

TLS.

Because I know TLS is what gives websites that little secure padlock icon, right?

Ensuring the connection between my laptop and the server is encrypted.

But the documentation emphasizes that stalwart automates this with ACME.

Why is that automation so critical?

Because human error is the silent killer of secure systems.

Oh, absolutely.

I mean, think about it.

An IT administrator forgets to manually renew a cryptographic certificate, it expires

over

a holiday weekend, and suddenly the entire organization's email just stops working.

Or worse, it defaults to an unencrypted connection.

Which is a massive compliance violation.

Exactly.

So ACME stands for Automated Certificate Management Environment.

It's a protocol where the stalwart server autonomously talks to a certificate

authority

like, let's encrypt.

The server automatically solves a cryptographic challenge, essentially proving to

the authority,

hey, yes, I mathematically control this domain.

And once proven, it issues and installs its own fresh certificates before the old

ones

ever expire.

So it entirely removes the human memory component from the security perimeter.

It's like a self-healing cryptographic layer.

That's exactly what it is.

And this robust layer seems necessary given the breadth of ways devices want to

communicate

today.

Because the sources highlight that stalwart fluently speaks IMAP and POP3 for

legacy clients.

But it heavily pushes a protocol called JMAP.

JMAP is really the future here.

So how does JMAP change the mechanical relationship between, say, my smartphone and

the server?

Well, think about how IMAP functions.

It relies on a polling mechanism.

Your smartphone has to repeatedly ping the server every few minutes asking, you

know,

do I have new mail?

Do I have new mail?

Like a kid in the backseat asking, are we there yet?

Yes.

And it's incredibly inefficient for both the device's battery and the network

bandwidth.

JMAP, which stands for JSON Meta Application Protocol, operates on modern web

technologies,

specifically web sockets.

So instead of constantly knocking on the door, it leaves a dedicated, secure phone

line open

between the device and the server.

That is an excellent way to conceptualize it.

It establishes a persistent two-way connection.

When a new email arrives at the server, the server instantly pushes that state

change

down that open web socket to your phone, your laptop, and your tablet

simultaneously.

Instantly.

Instantly.

When you swipe to delete an email on your phone, that action is reflected

everywhere

without delay.

It completely eliminates the polling overhead, which makes the entire collaboration

suite

mail, calendars via call dev, contacts via car dev, even files over web dev, it all

just

feels instantaneous.

Wow.

So the server is physically secure, the data is encrypted via semi on the disk, the

transit

is locked down with automated TLS, and the devices are syncing instantly over web

sockets.

A pretty solid foundation.

Very solid.

But here's where it gets really interesting.

What if the malicious payload doesn't try to break through the encryption?

What if it is willingly invited through the front door?

Because it looks exactly like a legitimate email from your CEO.

Ah, social engineering.

Yeah.

How does a modern server deal with the sheer volume of highly sophisticated,

socially engineered

spam because traditional filters just feel completely outmatched these days?

They are outmatched.

If we connect this to the bigger picture, the arms race between spam filters and spammers

has shifted dramatically in the last few years.

Right.

Legacy filters relied on static rules blocking known bad IP addresses or looking

for specific

trigger words in the subject line like Viagra or lottery.

Because it's easy to spot.

Exactly.

But modern spammers are using dynamic automated tools to generate unique varied

text for every

single message.

So to counter that, stalwart integrates LLM driven filtering.

Wait, it's actually using large language models to read the inbound mail.

Like AI.

Yes.

It leverages advanced natural language processing instead of just looking for

simple keywords.

The server uses statistical classifiers that understand the semantic context and

the actual

intent of the message.

That is wild.

It is.

And it pairs this advanced analysis with collaborative digest based filtering, like

the Pizer network,

along with things like spam traps, basically decoy addresses designed to catch spammers.

I read about Pizer in the GitHub blogs, actually, but the mechanics weren't

entirely clear

to me.

How does a collaborative digest actually catch spam?

So Pizer utilizes a cryptographic hashing mechanism.

When an email hits a server running Pizer, the software strips away all the

formatting

and runs the core text through an algorithm.

This generates a unique short string of characters, a hash.

It then queries a massive decentralized database.

If 10,000 other mail servers around the world just reported receiving an email that

generates

that exact same mathematical hash and they flagged it as spam.

Then your stalwart server instantly drops the message before it ever reaches your

inbox.

So it's essentially a real time global immune system.

It doesn't even need to understand the spam, it just needs to recognize its

mathematical

fingerprint.

But what about targeted phishing?

Because the sources bring up a defense mechanism against homographic URL attacks,

which just

sounds incredibly sinister.

It is one of the most effective visual spoofing techniques used today.

So the domain name system supports international characters, right?

It's known as PUNY code.

A sophisticated attacker will register a domain that looks visually identical to

your bank's

website, but they will substitute a standard English A with a Cyrillic A.

Oh wow.

To the human eye, reading the email, the link looks perfectly legitimate.

But internally, the browser routes you to a completely different malicious server.

That's terrifying.

So how does stalwart stop that?

Stalwart's active defense mechanisms specifically analyze the underlying unicode

structure of

the links in incoming mail.

It detects when characters from different alphabets are being mixed to deceive the

user, and it

flags the email as highly dangerous.

That level of inspection is impressive.

But what if the attacker isn't spoofing a link, but spoofing the sender entirely?

How does the server verify that an email claiming to be from my company's billing

department

actually originated from there?

That relies on a trinity of authentication protocols built natively right into stalwart,

SBF, DCAM, and DMRC.

Okay, let's break those down.

So SBF, or Sender Policy Framework, allows a domain owner to publish a public list

in

their DNS records.

It specifies exactly which IP addresses are authorized to send mail on their behalf.

So if an email arrives from an IP not on that list, stalwart knows it's an imposter

right

away.

Exactly.

And what about DCAM?

How does that add to the verification?

DCAM, which is Domain Keys Identified Mail, utilizes that asymmetric cryptography

we discussed

earlier, but for verification rather than encryption.

Oh, interesting.

The sending server uses a private key to generate a hidden digital signature based

on the contents

of the email header and body.

When stalwart receives the message, it fetches the sender's public key from the

internet

and verifies the signature.

So if the math checks out?

It proves two vital things.

The email definitively came from that domain, and the contents were not altered in

transit.

That makes a lot of sense.

And DMRC?

DMRC simply acts as the overarching policy.

It tells the receiving server exactly what to do, whether to reject or quarantine

if

an email fails those SPF or DCAM checks.

By natively handling these complex validations, stalwart neutralizes sender spoofing

right

at the perimeter.

So we have a system that is impervious to memory leaks, it encrypts data

continuously,

it instantly syncs data across devices, and it actively participates in a global

network

to neutralize AI-generated spam and cryptographic spoofing.

It's quite the list.

And a formidable architecture.

But let's look at the operational reality of deploying this.

Because a highly secure system is totally useless if it collapses under the weight

of

enterprise traffic.

Very true.

How does stalwart manage the physical storage of potentially millions of mailboxes?

Because looking at the documentation, it lists support for an array of backends.

RoxaDB, FoundationDB, PostgrescoLite, S3 object storage, I mean, for a beginner,

why does

it matter what database is running under the hood as long as the emails arrive?

Why decouple the database from the mail server to this degree?

To understand the necessity of that decoupling, we really have to look at how

traditional

storage fails at scale.

The legacy standard for storing email is a format called MailDeer.

Mechanically, MailDeer operates by saving every single email as a discrete

individual

text file inside a folder on a physical hard drive.

Which sounds incredibly simple and reliable, honestly.

If you want to read an email, the server just opens a text file.

It is simple until you need to scale.

Every file system has a hard limit on the number of individual files it can track,

which

are known as inodes.

When you have a massive enterprise with millions of messages, you hit those

hardware limits

incredibly fast.

I can imagine.

But more critically, MailDeer inextricably ties a user's inbox to one specific

physical

server blade.

If the hard drive on that specific blade fails, or if the compute load on that

machine just

spikes, that specific group of users experiences an outage.

And migrating those millions of files to balance the load must be a painstakingly

slow manual

process.

It's terrible.

It essentially creates massive architectural choke points.

If one piece of hardware goes down, a whole segment of the company goes dark.

Exactly.

The blast radius of a failure is huge.

Stallwork completely eliminates this by decoupling the compute nodes, the servers

actively processing

the incoming mail and running the spam filters from the storage nodes holding the

data.

Okay.

So how does that look in practice?

Well, when you pair Stallwork with a modern distributed database like Foundation EB,

you

achieve true enterprise scale.

Foundation EB operates kind of like a hive mind.

It automatically shards and replicates the email data across dozens of different

physical

servers.

So if a Stallwork compute node physically catches fire in the data center, the

overarching

system doesn't even care.

Nope.

Another compute node simply picks up the processing, queries the distributed

Foundation EB cluster,

and the user never even notices a hiccup in their web socket connection.

That is the essence of full tolerance.

It really is.

FoundationDB is explicitly designed to handle complex network partitions.

Basically scenarios where parts of the data center lose connection with each other.

It survives network partitions and hardware failures without complex coordinators

or proxies.

Wow.

So a small five-person design agency could run Stallwork backed by a simple squallet

file while a massive multinational corporation can run the exact same compiled

Stallwork

binary backed by a sprawling FoundationDB cluster.

It's built to grow seamlessly.

The software literally scales to the infrastructure.

Exactly.

So what does this all mean?

If we step back and synthesize the sources, Stallwork has crossed a major

developmental

threshold.

The project is officially feature complete and it is marching toward a stable

version

1.0 release.

A huge milestone.

It's a system that requires minimal configuration.

It natively supports the bleeding edge of secure protocols and fundamentally it

cannot

be compromised by the memory bugs that plague legacy software.

And we shouldn't forget the licensing model either.

Right.

It operates on a dual-license model, uses the AGPL 3.0 license, making it fully

open

source and free for the community, while also offering the Enterprise SLV1 license

for organizations

requiring commercial support directly from the developers.

It's really a tool actively democratizing access to secure enterprise-grade

communications.

This raises an important question, though.

We've discussed how stalwart is memory-safe, highly scalable, and how it really

lowers

the barrier to entry for self-hosting your infrastructure.

Absolutely.

With open-source tools like stalwart making self-hosting so robust and reliable,

are we

nearing the end of the era where we have to hand over all our communication data to

two

or three massive tech conglomerates?

Oh, that's a fascinating point.

Right.

If hosting your own infrastructure is no longer this Frankenstein nightmare of duct

tape and

fragile code, how might that change the future of digital privacy entirely?

It totally changes the calculus for organizations.

It's no longer just a trade-off between privacy and convenience.

You can actually have both.

Exactly.

And that profound shift in what an organization can actively control brings us

right back

to our sponsor, Safe Server.

We've just spent the last 15 minutes unpacking how incredibly potent modern open-source

architecture

like stalwart has become.

That's a game changer.

By transitioning to these robust open-source solutions, organizations, whether they

are

mid-sized businesses, associations, or other groups, gain something invaluable,

absolute

sovereignty over their data.

It allows an organization to fully escape the trap of proprietary vendor lock-in.

Yes.

You are no longer subject to the arbitrary price hikes.

Sudden service deprecations or opaque privacy policy changes mandated by a massive

cloud

provider.

And you shed those bloated recurring licensing costs while actually upgrading your

security,

posture, and compliance capabilities.

And crucially, taking back that control doesn't mean you have to figure out

distributed databases

and memory safe compilation alone.

No, not at all.

SafeServer can be commissioned to provide expert consulting and map out your entire

transition.

Whether the exact right architectural fit for your organization is stalwart or

another

highly capable open-source alternative, they manage the heavy lifting.

From the initial setup to the daily operations.

Break down to hosting it securely on their servers in Germany, ensuring your data

remains

firmly under your jurisdiction.

You can explore how to deploy these solutions and take back your infrastructure by

visiting

www.safeserver.de.

It really represents a fundamental shift in technical independence.

It absolutely does.

So the next time you envision an internal server room, you don't have to picture a

fragile,

stitched together monstrosity constantly on the verge of collapse.

The tools to build something resilient, secure, and sovereign are already here.

Keep questioning the defaults and we'll see you next time.

Keep questioning the defaults and we'll see you next time.