Today's Deep-Dive: E-MailRelay

This deep dive is supported by Safe Server.

And expensive proprietary email and cloud services

from vendors like Microsoft or Google,

they can really, really eat into an organization's budget.

Oh, absolutely.

It's a massive line item for most places.

Right.

But it turns out many of these expensive services

can actually be replaced by open source solutions,

like the one we're discussing today,

which can result in just massive cost savings.

Yeah, and cost isn't even the only factor here, right?

Exactly.

When you're dealing with legal, regulatory, or compliance

requirements, things like strict email retention, data

protection, financial records, audit trails, data sovereignty

is just absolutely critical.

Right.

You need total control over your data.

You do.

You need to know exactly where it lives.

Not just cross your fingers and hope

it's safe on some tech giant server farm out

in the desert somewhere.

Yeah, hoping is exactly a great security strategy.

No, it's really not.

And that's where Safe Server comes in.

They help organizations find and implement

the right open source solution for their exact needs,

taking you from initial consulting

all the way through to operation on highly secure German

servers.

Which is a huge piece of mind.

Totally.

So you can find more information and get started

at www.safeserver.de.

Highly recommend checking them out.

So OK, let's unpack a scenario that

is probably happening in an office building near you

right this very second.

Oh, I bet I know where this is going.

Right.

So picture this.

Deep in a server closet, there's this reliable, incredibly

expensive piece of hardware.

Maybe it's a heavy duty legacy scanner or a massive APC

network switch.

Built like a tank, right?

Exactly.

And for a decade, it has worked flawlessly.

Just silently doing its job, shooting off

an automated email alert to the IT department

whenever something needs attention.

A low tone or warning for a temperature spike, yeah.

Yeah, exactly.

Then today, it just goes dark.

The email's completely stopped.

Just out of nowhere.

Yeah, right.

And the machine isn't broken.

The network isn't down.

It has simply been locked out of the modern internet.

Yeah, and I mean, we see this exact frustration playing out

all over the user reviews we pulled from SourceForge

for today's Deep Dive.

It's everywhere.

It really is.

People are just pulling their hair out

because a $10,000 piece of infrastructure

suddenly can't send a simple PDF or a basic warning message.

And the culprit is usually just a policy change

at a major cloud provider, right?

Exactly, which is exactly what our mission is today.

We are taking a stack of sources,

a highly detailed technical user guide,

and those real-world SourceForge reviews

to basically demystify a tool called Email Relay.

Email Relay, OK.

Yeah, the documentation calls it a lightweight store

and forward mail server and proxy.

Store and forward.

OK, so our goal today is to translate that

into plain English to explain why you might desperately need it

without even realizing it and explore how it actually

works under the hood.

Right, because if we look at why that scanner in the closet

went dark, it really comes down to how email fundamentally

works.

OK, break that down for us.

So in the old days, devices used a protocol

called Simple Mail Transfer Protocol, SMTP.

Right, SMTT.

Still hear that a lot.

Yeah, and back then, they would just

shoot an unauthenticated message onto the network.

It was basically like dropping a postcard in a mailbox

without a return address.

Just trusting the system to deliver it.

Exactly.

But today, because of the massive volume of spam

and security threats out there, big providers

like Microsoft 365 or Google Workspace,

they're actively blocking that kind of traffic.

Oh, wow.

So they just reject the postcard entirely.

Yep, they demand modern authentication.

They demand secure encrypted connections.

OK, so the legacy device is standing there

trying to hand over a plain, handwritten postcard.

And Microsoft 365 is just standing like a bouncer,

demanding a government ID and a retina scan.

That's a great way to put it, yeah.

The old hardware just doesn't speak

that modern security language.

It literally cannot provide the credentials

the cloud provider is asking for.

Which leaves IT departments with a pretty terrible choice,

right?

Oh, the worst.

You either replace perfectly good, incredibly expensive

hardware just to get email alerts working again,

or you somehow bridge the gap.

Bridge the gap.

Yeah, and that is where Email Relay comes in

as the sort of middleman.

You just install it quietly on a local Windows or Linux machine

inside your own network.

I like to think of it as a highly

efficient bilingual courier.

Oh, I like that.

Right, because you tell your old scanner, hey,

don't try to talk to Microsoft anymore.

You're just going to confuse them.

Just hand your simple, unauthenticated postcard

to Email Relay right here on the local network.

Exactly.

And then Email Relay takes that basic message,

packages it up into a highly secure envelope,

stamps it with all the proper modern credentials.

Applies the right encryption.

Yes, applies the encryption, and then it turns around

and hands it off to the strict upstream provider.

And because it sits locally, your legacy device

never even has to navigate the open internet.

Never.

Email Relay catches those local emails,

holds onto them, or spools them, as they

say if the internet happens to be down,

and securely relays them when the connection is open.

It just completely solves the authentication problem.

It really does.

It's so elegant.

But here is where it gets really interesting for me, though.

If you're running a busy office, or like a hospital,

or a massive warehouse, you might

have hundreds of these legacy devices sending

thousands of alerts a day.

Oh, easily.

Thousands.

So if Email Relay is the sole middleman for all that traffic,

you'd probably assume it has to be this loaded, resource heavy

monster of a program.

You'd need a dedicated server just to keep up.

Right.

That would be the assumption.

But the manual spends a lot of time

emphasizing how incredibly lightweight it is.

So how is it moving all this traffic

without just melting the RAM on whatever computer is running it?

Well, it all comes down to the architecture.

The documentation details that Email Relay

runs as a single process using what's

called a non-blocking I slash O model.

OK, wait.

Non-blocking IO.

That is exactly one of those phrases

that makes beginners want to run for the hills.

I know.

I know.

It sounds super technical.

What does that actually look like in practice?

OK, think of a traditional blocking server,

like a cashier at a grocery store.

OK, cashier.

The cashier takes one customer, scans their items,

waits for them to pay, and hands them their receipt.

The entire line behind them is blocked,

waiting for that single transaction to finish.

Right.

And if that customer takes five minutes

to dig around for their credit card,

everyone else just stands there glaring.

Exactly, which is incredibly inefficient

if you have 1,000 people trying to check out at once.

OK, so that's a blocking model.

Right.

A non-blocking model is more like a master chess player

walking down a line of 50 different games.

Oh, like a grandmaster doing a simultaneous exhibition.

Yes.

They look at board one, make a move,

and instantly walk to board two.

They don't stand there waiting for the first opponent to think.

Right, they just keep moving.

They continuously cycle through, handling

whichever connection is ready for the next step.

An email relay uses this exact same architecture.

That makes so much sense.

And it's actually the same model used

by massive enterprise-grade web tools like Nginx,

which handle millions of simultaneous website visitors.

Wow.

So it's juggling all these incoming alerts

and outgoing cloud connections concurrently

without ever pausing the whole system

to wait for one slow email to send.

Exactly.

And to make it even more efficient,

it's written entirely in C++.

OK, and for anyone unfamiliar, C++

is a programming language that's famous for its speed, right?

Its speed and its incredibly low memory footprint.

It interacts very, very closely with the computer's hardware.

Which translates to a massive human benefit here.

You don't need to go out and buy a $5,000 server

to run this middleman.

Oh, not at all.

You could probably run it on a dusty 10-year-old laptop

sitting in the corner of the office,

and it wouldn't even break a sweat.

Yeah.

You absolutely could.

It's that efficient.

But that minimalist approach also

leads to a design philosophy that catches

a lot of new users off guard.

Yes.

OK, I want to push back on this, because it honestly

threw me for a loop when I was reading the user guide.

The policy-free thing.

Yes.

The manual proudly states that email relay is entirely

policy-free.

And to a beginner setting up network infrastructure,

policy-free sounds like a very polite way of saying,

we built an empty shell that does absolutely nothing out

of the box, good luck.

It really does sound like that, doesn't it?

Downloading a blank slate, actually a good thing.

I completely understand why that sounds daunting.

We're so used to software holding our hands these days.

Very true.

But think about your typical experience

with heavy enterprise software.

Or honestly, even just setting up a new smart TV.

Don't get me started.

Right.

You spend the first three hours digging through menus,

trying to turn off the motion smoothing,

disabling all the pop-up notifications.

Fighting the built-in hard-coded rules

that the developer just assumed you wanted.

Exactly.

You are always fighting the default settings

just to get the tool to do the one specific task you bought

it for.

That is painfully relatable.

Well, with email relay, you don't

have to fight the defaults, because there are no defaults.

That policy-free design is actually its superpower.

It handles the core mechanics, the secure receiving

and sending of data flawlessly.

But you dictate the logic.

You decide how many times a failed message

should retry before giving up.

You decide how balanced emails are handled,

how local deliveries are routed.

So it adapts to you.

Yes.

It is designed to adapt to the unique quirks

of your specific network, rather than forcing you

to change your network to accommodate the software.

OK, I see the appeal of not having to fight the developer's

assumptions.

But I mean, if it's truly a blank slate just sitting there

waiting for me to tell it what to do,

how do we actually give it instructions?

Right, you need a way to interface with it.

Yeah, we have to tell the software how to route

these messages somehow.

And that brings us to the core mechanism

of the software, the filter system.

The filters.

OK, when I was reading the section

on how these filters operate via the command line,

I kept picturing the email relay spool directory,

where it holds all the messages, as this massive factory

conveyor belt.

I love that visual.

Yeah, the emails are the packages.

And they are just moving steadily

along this belt, from the incoming dock to the outgoing

dock.

And the filters act as the workers along that line.

Better yet, robotic arms.

Robotic arms.

You can just plug these robotic arms

into the side of the conveyor belt.

You tell the arm to watch the packages pass by.

And you program it to intercept specific ones.

It can stamp a package with a new label,

reroute it to a completely different belt,

open it up, and edit the contents.

Or if it recognizes a dangerous package,

just pick it up and throw it in the incinerator.

That captures the mechanics of the hyphen filter command

perfectly.

Oh, awesome.

And the beauty of this system is its flexibility.

If you want to build a highly complex robotic arm,

you don't need to learn C++ or modify the core software.

Oh, thank goodness.

Right.

Email Relay allows you to use simple external scripts.

So if you're running it on a Windows machine,

you can write a filter using standard JavaScript.

Just normal JavaScript.

Yep.

Or if you're on a Linux server, a basic shell script

works perfectly.

Wait, what actually happens between the software

and the script, practically speaking?

So as the email moves down the conveyor belt,

Email Relay pauses it and passes the file

to your external script.

OK.

Your script wakes up, examines the email headers or the body,

makes whatever changes it needs to make,

and then passes an exit code back to Email Relay.

Oh, I see.

And that exit code is the instruction.

It tells Email Relay to, for the message, drop it or bounce it

back.

But let's say I don't want to write my own scripts.

I'm a beginner.

I just want to route some mail.

Are there pre-built robotic arms ready to go in the box?

Absolutely.

The manual outlines several really powerful built-in

filters that require zero programming.

Nice.

There's the copy filter, which just duplicates messages,

which is great for creating an audit trail.

Very useful for compliance.

Exactly.

There's the deliver filter, which routes specific messages

to local mailboxes on the machine.

And I noticed the split filter, which seems incredibly

powerful for businesses.

Oh, the split filter is fantastic.

If I understand it correctly, you can tell the system, hey,

if an outgoing email is addressed to our billing

department's domain, route it through this highly

secure specialized server.

But if it's just a general email to a public domain,

send it out the normal way.

Precisely.

It physically divides the traffic flow based

on the rules you set.

That's so smart.

It is.

But any time we talk about a blank slate mail server

that automatically routes traffic,

we really have to address the elephant in the room.

Spam.

Spam.

Yeah, because if you aren't careful,

an open middleman server sounds like a spammers absolute dream.

Oh, a botnet would love it.

Right.

If a botnet finds your email relay server

and realizes it will forward literally anything you hand it,

they could pump millions of junk emails

through your IP address.

Which gets your company blacklisted from the internet.

Exactly.

So how does a policy-free tool protect against that?

It tackles this by integrating seamlessly

with existing industry standard tools.

Specifically, Spam Assassin.

Oh, OK.

Spam Assassin is huge.

Yeah.

You can plug in the built-in spam or spam edit filters.

So as the messages come down the conveyor belt,

Spam Assassin scans them for malicious patterns.

And if it catches something?

If it flags a message as junk, the filter intercepts it

and drops it before it ever gets relayed to the cloud.

Nice.

And it also has a mechanism to stop bad emails before they

even get on the conveyor belt in the first place, right?

Using address verifiers?

Yes.

The address verifier is a crucial first line of defense.

Think of it like a bouncer standing

outside the factory doors.

Checking the guest list.

Exactly.

The manual outlines the account built-in verifier.

How does that one work?

Well, if a botnet tries to send an email

to a fake or randomized address on your system,

just trying to guess employee names.

Which they do constantly.

Constantly.

The verifier checks that incoming address

against the actual system account.

And if the user doesn't exist, the bouncer

rejects the connection right at the door.

The email is never accepted, it never

enters the school directory, and it never

wastes your server's processing power.

OK, so we've covered how it routes the mail,

how it filters the mail, and how it keeps the spam out.

Yep.

But let's bring this back to the bigger picture for a second.

If an organization is pulling away from proprietary vendors

to take sovereignty over their own data,

they need to know the underlying infrastructure is rock solid.

Absolutely.

Security is everything.

Right.

If a business owner is relying on email relay

to handle sensitive automated reports or financial audit

trails, how secure is this data while it's actually moving?

Well, the documentation is very rigorous regarding security

protocols.

To ensure data isn't moving across the network in plain text,

email relay fully supports negotiated TLS encryption

for both incoming and outgoing connections.

OK, let's break TLS down for a second for our beginners.

Transport layer security.

Think of it as an armored truck.

An armored truck.

Yeah.

Even if someone intercepts the truck

while it's driving down the highway,

they can't see or access what's inside.

The data is locked in the cryptographic vault

while in transit.

That's a great visual.

And what about controlling who actually gets

to access the server itself?

So if you're running email relay on a Linux machine,

it integrates with PAM authentication.

PAM.

PAM stands for Plugable Authentication Modules.

Essentially, instead of email relay

trying to manage its own list of passwords,

it hands that job off to the core operating system.

Oh, so the Linux VIP list decides who gets in.

Exactly.

I also noticed a fascinating feature

in the manual regarding extreme privacy.

It mentioned connection tunneling.

Yes.

This is a standout feature for organizations

with high security or anonymity requirements.

Like who?

Maybe a journalistic outfit protecting sources,

or like a corporate whistleblower system.

Email relay can be configured to route your mail traffic

through a SOKS proxy, or even directly

through the Tor network.

Wait.

Tor?

Really?

Yeah.

It completely cloaks the origin of the traffic,

adding a massive layer of operational security.

That is wild for such a small program.

And just to add one more layer of utility,

it doesn't just push mail out.

It can actually function as a PMC server.

Which means it acts like a secure post office box.

Right.

End users can open up their standard email

client on their laptop, securely connect the email relay,

and retrieve their spooled messages directly.

OK, the manual clearly proves it has the technical chops.

But, you know, manuals are written by the developer.

Of course.

They always sound great on paper.

What happens when this hits the real world?

Can you actually trust a lightweight, free piece

of software to run your business infrastructure?

This is where we have to look at those SourceForge reviews.

Right, the real users.

And the validation there is incredibly compelling.

Out of all the users rating it, email relay

holds a 4.9 out of 5 star rating.

That's great.

That is almost unheard of for network infrastructure

software.

I know.

Usually this stuff just makes IT professionals miserable.

The reviews were genuinely surprising to read.

People aren't just using this for a weekend hobby

project in their basement.

It's not at all.

There's one review from a user named Sean2k

that really highlights the stability.

He calls the software absolutely bulletproof.

Bulletproof.

Yeah.

He explains that his organization has relied on it

to relay mail from various devices across their network.

And email relay has run continuously

for over six years without a single crash or incident.

Six years without a crash.

I guarantee every person listening to this deep dive

right now can think of an enterprise tool

their company pays thousands of dollars a month for

that can't boast six months of uptime, let alone six years.

Oh, 100%.

And it's not just stable under light loads, either.

Another user, Unusual Ildoram, reported

that they use email relay in a Windows environment,

and it successfully pushes over 300,000 emails a day.

300,000 emails a day.

A day.

That is not just a few scanner alerts.

That is a massive volume of automated receipts,

notifications, or system logs.

It really proves the fundamental philosophy of the software.

By keeping the core program incredibly lightweight,

relying on the speed of C++ Sare,

and using that non-blocking architecture we talked about.

The grandmaster playing chess.

Exactly.

A tool built by a single developer

can absolutely rival massive enterprise systems

in both stability and sheer volume.

It just does exactly what it's designed to do,

without the bloat.

Which, you know, brings us full circle

to exactly why we started this deep dive with Safe Server.

Right.

When you realize that an open source tool like Email Relay

can flawlessly process 300,000 emails a day

and just sit quietly on a local server for six years

without a single crash,

the business case becomes glaringly obvious.

Why pay for the bloat?

Exactly.

Why are organizations paying exorbitant monthly fees

to proprietary vendors like Microsoft or Google

for basic routing setups?

The cost savings of switching to an open source solution

are just immense.

And beyond the budget, it's about data control.

Your infrastructure stays inside your walls.

Your data remains yours.

It's about removing dependencies on external platforms

that can change their policies on a whim

and break your legacy hardware.

Break your $1,000 scanner.

Yeah.

And remember, you don't have to figure all this out alone.

Safe Server can be commissioned for consulting

to help you make this exact transition.

They are great at this.

Whether the absolute perfect fit for your specific network

is email relay or a comparable open source alternative,

they will guide you from planning to operation.

You can learn how to take control of your infrastructure

at www.safeserver.de.

Definitely go check them out.

Well, we've covered a lot of ground today,

from the frustration of broken legacy scanners

to the elegance of a non-blocking architecture.

It's been a fun one.

It is a fascinating look at the hidden mechanics

of how our data actually moves from point A to point B.

But before we sign off,

I wanna leave you with a final thought to ponder

as you log into your work computer tomorrow.

Ooh, all right.

If a free, lightweight, policy-free tool

built by a single developer can flawlessly

route 300,000 emails a day for a business

without crashing for six years,

in your current tech stack is completely unnecessary?

in your current tech stack is completely unnecessary?