1
00:00:00,000 --> 00:00:05,840
Welcome to the deep dive. Today we're going past the browser window, way down into

2
00:00:05,840 --> 00:00:06,000
the

3
00:00:06,000 --> 00:00:10,400
foundational infrastructure that keeps the world's email running. Yep. We've

4
00:00:10,400 --> 00:00:11,440
gathered a really deep

5
00:00:11,440 --> 00:00:16,250
stack of sources for this one. Technical security docs, open source mailing list

6
00:00:16,250 --> 00:00:16,640
protocols going

7
00:00:16,640 --> 00:00:21,620
back decades, and some high-level corporate product pages. And our mission here is

8
00:00:21,620 --> 00:00:22,080
really

9
00:00:22,080 --> 00:00:28,000
to demystify this whole enterprise email stack. We're diving into a veteran mail

10
00:00:28,000 --> 00:00:29,040
transfer agent,

11
00:00:29,040 --> 00:00:33,440
an MTA called Sendmail. Right. And this isn't just about how an email gets from A

12
00:00:33,440 --> 00:00:34,240
to B. It's about

13
00:00:34,240 --> 00:00:38,620
how these massive organizations, the ones that handling billions of dollars of data,

14
00:00:38,620 --> 00:00:38,880
make sure

15
00:00:38,880 --> 00:00:42,620
they can absolutely trust the software they run. And not just the software, but the

16
00:00:42,620 --> 00:00:43,040
messages

17
00:00:43,040 --> 00:00:46,470
themselves. We're going to break down these cryptographic tools, things like PGP

18
00:00:46,470 --> 00:00:47,120
and Decum,

19
00:00:47,120 --> 00:00:52,480
and they're not some exotic defense. They're essential, completely non-negotiable

20
00:00:52,480 --> 00:00:52,800
building

21
00:00:52,800 --> 00:00:57,170
blocks for trust. So if you've ever wondered what really separates your standard

22
00:00:57,170 --> 00:00:58,000
email service

23
00:00:58,000 --> 00:01:02,700
from the backbone of global commerce, well, you're about to find out. We're giving

24
00:01:02,700 --> 00:01:02,880
you a

25
00:01:02,880 --> 00:01:07,690
shortcut into this high stakes world. Our goal is to give you a clear structured

26
00:01:07,690 --> 00:01:08,640
intro to all this

27
00:01:08,640 --> 00:01:12,610
so that even if you're new to infrastructure security, you'll walk away with some

28
00:01:12,610 --> 00:01:12,880
real

29
00:01:12,880 --> 00:01:17,440
insights into the systems you use every single day. And before we get started, this

30
00:01:17,440 --> 00:01:17,920
deep dive

31
00:01:17,920 --> 00:01:22,300
is proudly supported by Safe Server. Safe Server handles the crucial hosting of

32
00:01:22,300 --> 00:01:23,600
this kind of complex

33
00:01:23,600 --> 00:01:28,560
software, and they assist clients worldwide with their digital transformation roadmaps.

34
00:01:28,560 --> 00:01:32,400
They really make these huge infrastructure transitions manageable. You can find out

35
00:01:32,400 --> 00:01:32,640
more

36
00:01:32,640 --> 00:01:39,680
at www.safeserver.de. Okay, let's unpack this. We're talking about SendMail, a name

37
00:01:39,680 --> 00:01:40,000
that's,

38
00:01:40,000 --> 00:01:43,680
I mean, it's pretty much synonymous with open source email. It is. But our sources

39
00:01:43,680 --> 00:01:44,240
really focus

40
00:01:44,240 --> 00:01:48,640
on the commercial version, the Sentrion platform. Why is that one specifically

41
00:01:48,640 --> 00:01:49,280
called that as being,

42
00:01:49,280 --> 00:01:54,090
and this is a quote, not for everyone? That phrase, not for everyone, is. It's the

43
00:01:54,090 --> 00:01:54,960
clearest signal

44
00:01:54,960 --> 00:01:59,840
of who it's for, organizations with just gargantuan messaging needs. Okay. SendMail

45
00:01:59,840 --> 00:02:00,960
itself is an open

46
00:02:00,960 --> 00:02:05,790
source platform, but Sentrion is the hardened, scaled-up enterprise engine. It's

47
00:02:05,790 --> 00:02:06,560
built for these

48
00:02:06,560 --> 00:02:12,010
huge complex environments. So if a company has, say, 100,000 employees or they're a

49
00:02:12,010 --> 00:02:12,880
global bank,

50
00:02:12,880 --> 00:02:17,690
they can't just run a basic server. They absolutely cannot. No way. They're facing

51
00:02:17,690 --> 00:02:18,560
these huge

52
00:02:18,560 --> 00:02:24,300
long-term technical challenges. They need a platform built to handle a messaging

53
00:02:24,300 --> 00:02:24,880
roadmap

54
00:02:24,880 --> 00:02:29,440
that might last a decade. Wow. We're talking about supporting critical tasks like

55
00:02:29,440 --> 00:02:30,160
virtualization,

56
00:02:30,160 --> 00:02:36,240
which is running multiple servers on fewer physical machines, or consolidation. Merging

57
00:02:36,240 --> 00:02:40,240
a bunch of smaller systems into one big one. Exactly. Maging numerous regional

58
00:02:40,240 --> 00:02:40,880
systems into

59
00:02:40,880 --> 00:02:46,880
one secure global entity. And of course, the big one today, cloud migration. Sentrion

60
00:02:46,880 --> 00:02:47,520
is just designed

61
00:02:47,520 --> 00:02:52,560
to sustain that kind of scale and evolution without failing. It's the industrial-grade

62
00:02:52,560 --> 00:02:56,170
workhorse. And just for context, the sources are really clear about the pedigree

63
00:02:56,170 --> 00:02:56,640
here.

64
00:02:56,640 --> 00:03:02,320
The current open-source core, the engine that powers even Sentrion, is sendmail 8.1.8.2.

65
00:03:02,320 --> 00:03:02,800
Right.

66
00:03:02,800 --> 00:03:08,320
And you can download it as a zipped tar file right from FTP.sendmail.org. And even

67
00:03:08,320 --> 00:03:08,720
the way it's

68
00:03:08,720 --> 00:03:12,340
distributed tells you something, right? It's a raw package. It implies that the

69
00:03:12,340 --> 00:03:13,120
people running it

70
00:03:13,120 --> 00:03:17,120
aren't using some simple installer. No point-and-click setup here. Not at all. They

71
00:03:17,120 --> 00:03:17,920
are building mission

72
00:03:17,920 --> 00:03:21,480
critical infrastructure from the ground up, and that requires some serious

73
00:03:21,480 --> 00:03:22,720
technical diligence from

74
00:03:22,720 --> 00:03:27,100
the engineers. Which brings us to the first huge security challenge, trusting the

75
00:03:27,100 --> 00:03:28,960
source. If you're

76
00:03:28,960 --> 00:03:32,500
downloading a raw package that's going to handle every sensitive piece of data in

77
00:03:32,500 --> 00:03:33,520
your multi-billion

78
00:03:33,520 --> 00:03:37,250
dollar company, how do you know it hasn't been, I don't know, intercepted and

79
00:03:37,250 --> 00:03:39,120
messed with? This is

80
00:03:39,120 --> 00:03:43,940
where we stop relying on human trust and start relying on pure mathematics. The

81
00:03:43,940 --> 00:03:44,560
solution is

82
00:03:44,560 --> 00:03:51,320
cryptographic integrity, specifically using PGP signing keys. Every single send

83
00:03:51,320 --> 00:03:52,640
mail distribution

84
00:03:52,640 --> 00:03:57,600
is digitally signed. This signature is created with a private key, and you verify

85
00:03:57,600 --> 00:03:58,000
it against

86
00:03:58,000 --> 00:04:02,480
their public key, which is named something like Send Mail Signing Key 2026. And

87
00:04:02,480 --> 00:04:03,440
this isn't optional,

88
00:04:03,440 --> 00:04:06,880
is it? It's a mandatory check. The source material uses some very sharp language on

89
00:04:06,880 --> 00:04:07,760
this. They do.

90
00:04:07,760 --> 00:04:12,080
The documentation explicitly warns, and this is a direct quote, if the signature

91
00:04:12,080 --> 00:04:12,880
does not match

92
00:04:12,880 --> 00:04:17,680
any of these keys, you may have a forgery. The forgery. That is the single non-negotiable

93
00:04:17,680 --> 00:04:22,490
threshold. If that signature doesn't match the public key you expect, you just, you

94
00:04:22,490 --> 00:04:23,040
cannot install

95
00:04:23,040 --> 00:04:28,390
that software. It could be anything. Malware. A backdoor. You just don't know. What

96
00:04:28,390 --> 00:04:28,880
I found

97
00:04:28,880 --> 00:04:33,280
fascinating is the history here. They list the current key fingerprint, but they

98
00:04:33,280 --> 00:04:34,160
also document

99
00:04:34,160 --> 00:04:38,500
this continuous traceable chain of trust that goes back for decades. All the way to

100
00:04:38,500 --> 00:04:40,080
1997. Right. And

101
00:04:40,080 --> 00:04:43,920
they even reference the key used by Eric Allman, one of the original developers,

102
00:04:43,920 --> 00:04:44,720
before version

103
00:04:44,720 --> 00:04:49,830
8.8.6. Why does an organization today care about a key fingerprint from 25 years

104
00:04:49,830 --> 00:04:50,320
ago?

105
00:04:50,320 --> 00:04:55,680
That's the core of enterprise longevity and compliance. Trust isn't just about the

106
00:04:55,680 --> 00:04:56,000
newest

107
00:04:56,000 --> 00:04:59,760
version. It's about the entire historical timeline. Oh. Because a company runs a

108
00:04:59,760 --> 00:05:01,200
system for 15 years,

109
00:05:01,200 --> 00:05:05,040
and an auditor comes in and asks them to verify the integrity of the code they used

110
00:05:05,040 --> 00:05:06,160
a decade ago,

111
00:05:06,160 --> 00:05:10,230
they have to be able to trace that cryptographic signature. This historical record

112
00:05:10,230 --> 00:05:10,960
of fingerprints

113
00:05:10,960 --> 00:05:16,710
like the 2025 key, starting with Aero 32312C7, establishes that continuity. So they

114
00:05:16,710 --> 00:05:17,440
can prove,

115
00:05:17,440 --> 00:05:22,250
years later, that everything was authentic. Precisely. They can prove every

116
00:05:22,250 --> 00:05:22,640
component of

117
00:05:22,640 --> 00:05:27,480
their system was authentically sourced from the trusted vendor. So the PGP key is

118
00:05:27,480 --> 00:05:28,560
basically the

119
00:05:28,560 --> 00:05:33,370
software's cryptographic passport. It verifies its identity and integrity across

120
00:05:33,370 --> 00:05:34,000
time. That's

121
00:05:34,000 --> 00:05:38,150
a great way to put it. Okay, so we have a trusted server, but that server sends out

122
00:05:38,150 --> 00:05:38,960
millions of

123
00:05:38,960 --> 00:05:42,480
messages. How do we make sure that those messages are equally trustworthy? The

124
00:05:42,480 --> 00:05:43,440
trust has to shift

125
00:05:43,440 --> 00:05:48,270
from the code to the payload, right? Exactly. Trusting the server is step one. But

126
00:05:48,270 --> 00:05:49,200
what happens

127
00:05:49,200 --> 00:05:54,020
when a message leaves the organization? Or what if a bad actor compromises just one

128
00:05:54,020 --> 00:05:54,400
account and

129
00:05:54,400 --> 00:05:59,210
starts sending things? PGP on the server won't help you then. So what does? That's

130
00:05:59,210 --> 00:05:59,440
where we

131
00:05:59,440 --> 00:06:03,790
transition to DKIM, or Domain Keys Identified Mail. For our listener who might be

132
00:06:03,790 --> 00:06:04,720
hearing DKIM

133
00:06:04,720 --> 00:06:09,550
for the first time, how should they visualize this? If PGP is the software's

134
00:06:09,550 --> 00:06:10,320
passport,

135
00:06:10,320 --> 00:06:16,000
what's DKIM? DKIM is the official, unforgeable, wax seal on the envelope of the

136
00:06:16,000 --> 00:06:16,960
message.

137
00:06:16,960 --> 00:06:22,720
It's an internet standard, RFC 4871, to be specific, that lets the sending domain

138
00:06:22,720 --> 00:06:26,480
digitally sign their messages. And that signature is embedded right in the email

139
00:06:26,480 --> 00:06:27,040
header. Right in

140
00:06:27,040 --> 00:06:33,240
the header. And what two core security promises does that digital signature make to

141
00:06:33,240 --> 00:06:33,760
the person

142
00:06:33,760 --> 00:06:38,980
receiving it? It delivers two things instantly. First, authentication. The receiver

143
00:06:38,980 --> 00:06:39,600
can verify

144
00:06:39,600 --> 00:06:43,670
the message genuinely came from the domain it says it came from, so no more address

145
00:06:43,670 --> 00:06:44,080
spoofing.

146
00:06:44,080 --> 00:06:49,040
That's huge. And the second. Integrity. The receiver can mathematically verify that

147
00:06:49,040 --> 00:06:49,200
the

148
00:06:49,200 --> 00:06:53,610
message content, the headers, and the body has not been altered since it left the

149
00:06:53,610 --> 00:06:54,800
signing server.

150
00:06:54,800 --> 00:06:58,720
This is critical for stopping those man in the middle attacks where someone changes

151
00:06:58,720 --> 00:06:59,840
banking info

152
00:06:59,840 --> 00:07:04,160
or a delivery address. It's just a fundamental defense against phishing. I also

153
00:07:04,160 --> 00:07:04,560
love that the

154
00:07:04,560 --> 00:07:08,450
sources point out this wasn't a solo effort. No, it was a recognition of an

155
00:07:08,450 --> 00:07:10,320
industry-wide problem.

156
00:07:10,320 --> 00:07:15,280
DKIM was developed through cooperation between Sendmail, Cisco Systems, and Yahoo.

157
00:07:15,280 --> 00:07:15,760
That's quite

158
00:07:15,760 --> 00:07:20,000
a team. It is, and it shows how early these major players realized that message

159
00:07:20,000 --> 00:07:20,960
verification needed

160
00:07:20,960 --> 00:07:24,960
to be a universal standard to maintain trust in email as a whole. And the open

161
00:07:24,960 --> 00:07:26,000
source community

162
00:07:26,000 --> 00:07:31,120
kept that ball rolling. The sources mentioned the OpenDKIM project. They did. After

163
00:07:31,120 --> 00:07:31,600
the standard

164
00:07:31,600 --> 00:07:36,160
was adopted, the OpenDKIM project started. It's a community effort that produces a

165
00:07:36,160 --> 00:07:36,960
C library

166
00:07:36,960 --> 00:07:41,770
and an open source mail filter, a milter. A milter. It's like a plug-in that

167
00:07:41,770 --> 00:07:42,960
processes email traffic.

168
00:07:42,960 --> 00:07:47,520
Sort of, yeah. Think of it as a modular tool that filters email at key points. And

169
00:07:47,520 --> 00:07:48,000
OpenDKIM

170
00:07:48,000 --> 00:07:52,220
provides this capability. What's interesting is it started as a code fork of an

171
00:07:52,220 --> 00:07:53,120
older sendmail

172
00:07:53,120 --> 00:07:58,020
developed package. And now, it's the standard DKIM implementation that ships with

173
00:07:58,020 --> 00:07:58,720
the Sentry

174
00:07:58,720 --> 00:08:02,720
and Message Processing Engine. Okay, so we've secured the foundation with sendmail

175
00:08:02,720 --> 00:08:03,840
and PGP,

176
00:08:03,840 --> 00:08:08,880
and we've secured the content with DKIM. Let's zoom out to the broader context. All

177
00:08:08,880 --> 00:08:09,520
of this exists

178
00:08:09,520 --> 00:08:14,160
within a larger corporate environment, often managed by security companies like Proofpoint.

179
00:08:14,160 --> 00:08:18,480
What are the modern concerns in that ecosystem? Well, the modern shift is huge.

180
00:08:18,480 --> 00:08:19,120
Historically,

181
00:08:19,120 --> 00:08:22,860
security was all about the perimeter firewalls, filters, that sort of thing. The

182
00:08:22,860 --> 00:08:23,520
castle walls.

183
00:08:23,520 --> 00:08:28,060
The castle walls, exactly. Today, the focus is squarely on the people aspect. The

184
00:08:28,060 --> 00:08:28,320
industry

185
00:08:28,320 --> 00:08:31,650
calls it human resilience. Human resilience, acknowledging that the employee

186
00:08:31,650 --> 00:08:32,880
clicking the wrong

187
00:08:32,880 --> 00:08:37,710
link is your weakest point. Yeah, precisely. The sources detail things like threat

188
00:08:37,710 --> 00:08:38,320
protection and

189
00:08:38,320 --> 00:08:44,070
data security. But human resilience is the key. It's about driving behavior change,

190
00:08:44,070 --> 00:08:44,880
increasing risk

191
00:08:44,880 --> 00:08:50,880
visibility. They realize that no amount of PGP or DCAM can stop someone from giving

192
00:08:50,880 --> 00:08:51,360
away their

193
00:08:51,360 --> 00:08:55,370
password in a sophisticated social engineering attack. So tools like ZenGuide,

194
00:08:55,370 --> 00:08:56,320
which the sources

195
00:08:56,320 --> 00:08:59,930
mention, aren't just about those annoying annual security videos we all have to

196
00:08:59,930 --> 00:09:01,040
watch. No, they're

197
00:09:01,040 --> 00:09:06,380
actively measuring and trying to modify employee risk behavior. Yeah. They aim to

198
00:09:06,380 --> 00:09:07,360
move the needle

199
00:09:07,360 --> 00:09:12,180
on human vulnerability. Instead of trying to block every single threat, which is

200
00:09:12,180 --> 00:09:12,800
impossible,

201
00:09:12,800 --> 00:09:17,200
they focus on minimizing the impact of the threat that inevitably gets through.

202
00:09:17,200 --> 00:09:20,520
They're modeling risk scores based on who clicks on phishing tests, who reports

203
00:09:20,520 --> 00:09:20,960
them.

204
00:09:20,960 --> 00:09:25,030
It's a huge philosophical shift. That really is. Okay, shifting back to the nuts

205
00:09:25,030 --> 00:09:25,600
and bolts of the

206
00:09:25,600 --> 00:09:28,820
send mail community itself, let's talk about the rules of engagement. Even this

207
00:09:28,820 --> 00:09:29,680
highly technical

208
00:09:29,680 --> 00:09:34,770
world has these rigid, almost ancient protocols for reporting security issues. What

209
00:09:34,770 --> 00:09:35,600
happens if

210
00:09:35,600 --> 00:09:39,360
a server admin finds a zero-day flaw? They can't just send a quick email. The

211
00:09:39,360 --> 00:09:40,480
procedure is deliberately

212
00:09:40,480 --> 00:09:45,310
slow and secure. First, official advisories are issued globally by organizations

213
00:09:45,310 --> 00:09:46,000
like Cert.

214
00:09:46,000 --> 00:09:50,820
Okay. Second, server-related security problems have to be reported to a dedicated

215
00:09:50,820 --> 00:09:51,200
confidential

216
00:09:51,200 --> 00:09:59,040
email address, sendmailsecurity-yyyy at support.sendmail.org. And the crucial part,

217
00:09:59,040 --> 00:10:03,860
you have to secure your own message. Absolutely. Security reports must use PGP

218
00:10:03,860 --> 00:10:04,800
encryption. It

219
00:10:04,800 --> 00:10:08,800
ensures confidentiality so vulnerability details don't leak while a patch is being

220
00:10:08,800 --> 00:10:09,440
developed.

221
00:10:09,440 --> 00:10:13,040
They simply will not process an unencrypted critical report.

222
00:10:13,040 --> 00:10:16,720
And that's a hard line between that and just general support questions, right? You

223
00:10:16,720 --> 00:10:17,120
can't mix

224
00:10:17,120 --> 00:10:21,120
those up. No, you can't. Non-security questions like setup advice or how to avoid

225
00:10:21,120 --> 00:10:22,080
spam are strictly

226
00:10:22,080 --> 00:10:26,890
sent to the public Usenet group, comp.mail.sendmail. It keeps the security channel

227
00:10:26,890 --> 00:10:27,600
clear for actual

228
00:10:27,600 --> 00:10:32,160
threats. And if you look at their communication rules, they are incredibly strict.

229
00:10:32,160 --> 00:10:33,120
No HTML,

230
00:10:33,120 --> 00:10:38,340
no proprietary formats, plaintext only. Why the insistence on these, I mean, legacy

231
00:10:38,340 --> 00:10:39,120
standards?

232
00:10:39,120 --> 00:10:43,950
It links directly back to stability and backward compatibility. The systems

233
00:10:43,950 --> 00:10:44,960
reviewing these patches

234
00:10:44,960 --> 00:10:50,700
are often ancient, stable, non-chewo systems. Modern conveniences just introduce

235
00:10:50,700 --> 00:10:51,760
fragility.

236
00:10:51,760 --> 00:10:52,640
They break things.

237
00:10:52,640 --> 00:10:57,680
They break things. By enforcing plaintext and 7-bit ASCII in the subject line,

238
00:10:57,680 --> 00:11:01,920
you eliminate the risk of encoding errors that could mask a malicious payload or

239
00:11:01,920 --> 00:11:02,480
just break

240
00:11:02,480 --> 00:11:04,640
the parsing script on their end.

241
00:11:04,640 --> 00:11:09,050
So if your fancy email client adds one little HTML tag, your crucial security

242
00:11:09,050 --> 00:11:09,920
report just gets

243
00:11:09,920 --> 00:11:11,680
trashed before a human even sees it.

244
00:11:11,680 --> 00:11:16,490
Exactly. And it goes even further. They do what they call strict RFC checks. They'll

245
00:11:16,490 --> 00:11:16,720
actively

246
00:11:16,720 --> 00:11:21,440
reject mail if a domain's MX record points to an IP address instead of a hostname.

247
00:11:21,440 --> 00:11:23,600
Which might work sometimes, but it's not the rule.

248
00:11:23,600 --> 00:11:27,760
It's not the rule. The protocol demands a hostname. If you deviate, your message is

249
00:11:27,760 --> 00:11:32,320
blocked because that deviation could signal a misconfigured, untrustworthy sender.

250
00:11:32,320 --> 00:11:36,560
In this world, conformity to decades-old standards is everything.

251
00:11:36,560 --> 00:11:40,640
It really reinforces that idea that true security often relies on stripping away

252
00:11:40,640 --> 00:11:43,600
layers of complexity that modern software keeps adding.

253
00:11:43,600 --> 00:11:49,040
Absolutely. Simplicity, defined by strict protocol, is the ultimate security

254
00:11:49,040 --> 00:11:50,880
feature in this ecosystem.

255
00:11:50,880 --> 00:11:55,600
That brings us to our synthesis. We've done a deep dive into Send Mail Sentrion,

256
00:11:55,600 --> 00:12:00,410
the workhorse of enterprise email. We detailed the two pillars of cryptographic

257
00:12:00,410 --> 00:12:00,480
trust.

258
00:12:01,120 --> 00:12:06,400
PGP keys to verify the software itself. And D-A-M-M, the standard that verifies

259
00:12:06,400 --> 00:12:10,320
the message content and the sender. And finally, we saw how enterprise

260
00:12:10,320 --> 00:12:14,280
security has pivoted to address the human element through what they call human

261
00:12:14,280 --> 00:12:15,120
resilience.

262
00:12:15,120 --> 00:12:19,120
The takeaway, really, is that security isn't a single product. It's a layered

263
00:12:19,120 --> 00:12:19,840
architecture,

264
00:12:19,840 --> 00:12:24,540
built on non-negotiable standards and decades of diligent tracking. It's a world

265
00:12:24,540 --> 00:12:25,280
where continuous

266
00:12:25,280 --> 00:12:28,720
cryptographic verification is the only way to establish trust.

267
00:12:29,280 --> 00:12:33,120
And for a final thought for you to mull over, consider those strict communication

268
00:12:33,120 --> 00:12:33,680
rules again.

269
00:12:33,680 --> 00:12:38,000
Plain text, no challenge response systems, strict RFC checks. These are the

270
00:12:38,000 --> 00:12:38,480
communities

271
00:12:38,480 --> 00:12:42,240
that literally keep the internet's core communication flowing. So why must they

272
00:12:42,240 --> 00:12:46,790
rely on such rigid, seemingly simple standards just to communicate? It highlights

273
00:12:46,790 --> 00:12:47,040
that when

274
00:12:47,040 --> 00:12:50,650
the stakes are highest, precision and stability will trump every single modern

275
00:12:50,650 --> 00:12:51,440
convenience.

276
00:12:51,440 --> 00:12:53,760
Indeed. It's a powerful lesson.

277
00:12:53,760 --> 00:12:56,000
And finally, a big thank you again to our sponsor.

278
00:12:57,040 --> 00:13:01,040
This deep dive was made possible by SafeServer. They handle the hosting of complex

279
00:13:01,040 --> 00:13:01,680
software like

280
00:13:01,680 --> 00:13:05,500
Sendmail and support your digital transformation initiatives. You can learn more

281
00:13:05,500 --> 00:13:06,320
and find resources

282
00:13:06,320 --> 00:13:10,880
at www.safeserver.de. Join us next time for another deep dive.