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.
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.
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,
what other bloated, expensive, proprietary software
in your current tech stack is completely unnecessary?