LWN: Comments on "Book review: Run Your Own Mail Server"

Virtualmin

pschneider1968 — Sun, 03 Aug 2025 14:30:51 +0000

I realize I'm a bit late to chime in here, but I want to do it nevertheless.

I do some hosting of web and mail domains for myself, for a couple of friends, and for my local chess club. I have the domains with IONOS, and the Debian server VMs with Strato for some 6-11€/month. I do use Postfix, Dovecot and Roundcube on the servers.

To configure all this on a bare Debian installation is way too much work, and error-prone, too. You need some good hosting software to make this easier and manageable. From my point of view, there are basically two viable software packages ("Admin Panels") that do this: one is Plesk, which is commercial, very good, but not cheap if it's not included with your hosting plan. The other one, and this is the one I'd really reommend, is Virtualmin. It's even better than Plesk (I think) and it's FOSS and free (as in "free beer") to use, with a subscription-based paid variant with some additional but non-essential features available, too.

https://www.virtualmin.com/

You can install it with either Apache or with Nginx as the webserver. I prefer Nginx, because it makes redirection to Docker containers really simple. With Virtualmin as the Admin panel, virtual domain hosting is really made easy. It does all the hard and complicated configuration work for you, but in a very transparent way. You can always override any setting manually by editing the individual components config file directly, but through the Web GUI.

The only things regarding the mail server I had to do fully manually was incorporating the free Spamhaus.org data query service (i.e. their free block list subscription) into the Spamassassin config, and the addition of OpenSRS (implementation of sender rewriting) to Postfix, because I do a lot of mail forwarding, as not all of my users want a mailbox; some prefer having their domain's mails forwarded to their private mail account.

Rspamd I looked into, but figured that at that point in time, it was serious overkill for what I needed. My setup was been working fine with Spamassassin for some years now. Virtualmin also allows for easy integration of mailbox virus scanning with ClamAV. And you can, albeit a lot more complicated than the basic setup, use LDAP for sender and mailbox accounts.

For securing your mail setup, the Email Hardening Guide is a very good read (short of reading THIS book) which can be found here:

https://www.mailhardener.com/kb/email-hardening-guide

It explains SPF, DKIM, DMarc and MTA-STS for mere mortals, and is helpful if you have some basic understanding of how DNS and SMTP work and relate to each other. You have to set this up correctly to get mails delivered to most of the big mail providers. Additionally, for some mail providers you have to go through some additional hops... For Google/Gmail, you have to have a Google account and register your mail server in the Google Postmaster tools, and then add a DNS TXT record to your domain with the Google verification code. In Germany, in order to be able to deliver to T-Online mail accounts, you have to contact the T-Online Mail admin team and ask that they add your mail server IP to their whitelist, which requires that you have to setup a web page for the mail domain with a legally required Imprint, satisfying German and EU law Imprint requirements.

With all setup correctly, I never had a problem delivering mails to Gmail, T-Online, web.de, gmx.de/org/net, yahoo, outlook.com/de etc.

And with the help of this great book, you can even gain some more deep understanding of these setup and security topics. But honestly, with a basic understanding AND the ability to read the Virtualmin documentation AND the Email Hardening Guide above, you are good to go!

Invalid recommendations

Curan — Sat, 30 Nov 2024 16:53:33 +0000

That is probably correct, but it doesn't help me, does it? My spam levels haven't dropped with SPF/DKIM, so it is, from my POV, just pointless. But we can of course argue semantics here. And obviously I would never be able to prove, that the situation wouldn't be worse, if we didn't have these.

Invalid recommendations

farnz — Sat, 30 Nov 2024 15:31:59 +0000

OK then; if SPF/DKIM didn't help me, what exactly did reduce the load? I went from approximately 2 backscatter mails caused by spam with my address forged on it in a month, to typically 10,000 in a day, and the thing that caused it to go back down to approximately 2 in a month was implementing DKIM, SPF and a DMARC policy.

Further, having done this, I could see from the DMARC reports that for about 3 months after I set this up, big hosts like mail.ru, fastmail.com, Outlook.com, and Google were seeing typically 20,000 hosts not compliant with my DMARC policy in a day. That has now dropped to zero.

If it wasn't DKIM, SPF and a DMARC policy that helped, what was it?

Invalid recommendations

pizza — Sat, 30 Nov 2024 13:48:56 +0000

>> There is a (comparatively) small amount of e-mails that would be caught by SPF and/or DKIM.
> Might this, perhaps, be *because* they are enforced?

Yes, exactly this.

This discussion reminds me of Y2K, afterwards, laypeople (and many that should know better!) were going "what was the big deal, the world didn't end, we're not going to believe the next so-called panic" completely missing the fact that it was a non-event only because obscene amounts of effort went into fixing everything up (barely) in advance.

Invalid recommendations

mathstuf — Sat, 30 Nov 2024 13:24:14 +0000

> There is a (comparatively) small amount of e-mails that would be caught by SPF and/or DKIM.

Might this, perhaps, be *because* they are enforced? That is, they've been required long enough that what they prevent has indeed been extinguished, but it is still cheap enough even with these being required to churn out junk email that it *appears* nothing has changed? Short of charging per email exchanged or much higher registration fees…what is actually going to increase costs for these operators?

Invalid recommendations

pizza — Sat, 30 Nov 2024 13:03:22 +0000

> I am really sorry, you saw an increase in spam, but I will contest, that SPF/DKIM actually helped you

Contest it all you want, but you're going to need a more reasoned argument than "I don't believe you" and quoting wikipedia definitions.

(BTW: I've been self-hosting my own email for over 25 years. The combination of SPF, DKIM, and DMARC made a *huge* difference on the domains I control)

> Today my most common spam sending e-mail domains are `gmail.com` and `hotmail.com` (ie.: Google & Microsoft, who have been pushing the hardest for SPF/DKIM).

You sound like the person who points at snow on the ground claiming that as proof that global warming isn't real.

> It just is not in mine and there is no automated way to prevent that e-mail from being processed by my local filters

Uh, nobody has ever prevented you from running your own client-side filters. (Except perhaps your employer, but that's their problem, not yours)

Invalid recommendations

Cyberax — Sat, 30 Nov 2024 07:20:25 +0000

> On the other hand I have actual and obvious spam in troves, that meets SPF/DKIM requirements.

FWIW, spammers don't even bother with forging the 'from' field anymore because they assume that SPF/DKIM is everywhere.

Invalid recommendations

Curan — Sat, 30 Nov 2024 06:01:19 +0000

I will assume, that you run a private MTA, because your numbers make no sense on a larger base.

I am really sorry, you saw an increase in spam, but I will contest, that SPF/DKIM actually helped you. I will agree, that those technologies will have helped you to paper over existing issues, but in the end it won't matter. Today my most common spam sending e-mail domains are `gmail.com` and `hotmail.com` (ie.: Google & Microsoft, who have been pushing the hardest for SPF/DKIM).

And, TBH, it is in their interest to have these accounts. It just is not in mine and there is no automated way to prevent that e-mail from being processed by my local filters. Those catch the spam and sort it accordingly, but that also means I have to expend far more resources than I want to.

Invalid recommendations

Curan — Sat, 30 Nov 2024 05:33:39 +0000

> When I receive email from my customers (for whom my company has set up SPF, DKIM, DMARC in the past) I can rely on two things

No you can't, because this still assumes honest players. Really, I am running MTAs for very large organisations and my experience is: a lot of legitimate e-mails would be filtered if I enforce SPF/ DKIM. On the other hand I have actual and obvious spam in troves, that meets SPF/DKIM requirements.

In my personal experience: the best way to verify a sender is OpenPGP. That being said: that is a negligible amount of traffic here.

But since you insist on the "not about spam" line: that is not how it is sold. And not how it is promoted. See eg. https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail where it says in the first line

> DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect forged sender addresses in email (email spoofing), a technique often used in phishing and email spam.

Or in https://en.wikipedia.org/wiki/Sender_Policy_Framework

> Sender Policy Framework (SPF) is an email authentication method which ensures the sending mail server is authorized to originate mail from the email sender's domain.[1][2] [...] Forgery of this address is known as email spoofing,[3] and is often used in phishing and email spam.

And I know Wikipedia is not the best source, but if you are honest you will find, the RFCs and other industry sources agree.

---

That being said: I do not think us discussing this issue over text in a comment section is going to help us, because this is a very poor communication channel. If you are at FOSDEM, let me know and we can meet up in person and discuss this better. Probably over a beer or two. ;-)

Invalid recommendations

dskoll — Fri, 29 Nov 2024 21:15:00 +0000

I expect that it's no longer the case [that SPF "pass" is a mild spam indicator] because the standard is old and most people have caught up.

Invalid recommendations

mbunkus — Fri, 29 Nov 2024 19:47:22 +0000

> And just like that you told me, that SPF is pointless.

You're wrong insofar as you're only thinking about fighting spam. But as Diane said, SPF & DKIM are supposed to establish authenticity. When I receive email from my customers (for whom my company has set up SPF, DKIM, DMARC in the past) I can rely on two things:

1. The email does indeed come from my customer & not from a malicious third party.
2. No malicious third party has modified the most important headers while in transit.

These particular technologies are not about fighting spam. They addressed different shortcomings of the SMTP protocol itself:

1. No way to verify that a sender (both in the sense of the program creating the mail & the server relaying the mail) is allowed to send mail for a certain domain. This is what SPF addresses.
2. No way to validate that email headers haven't been modified after having been sent by the sender. This is what DKIM addresses.[1]
3. DMARC as the third part finally tells the recipient that both SPF & DKIM are actually supposed to be used by all mail originating by a domain, and what the domain's owner wants the recipient to do if one of both or them are invalid or missing.

Again, this is _not about spam_.

[1] Before DKIM there had only been a way to protect email bodies from malicious modifications by sending cryptographically signed emails (GPG, S/MIME). Those didn't do anything for the headers, though.

Invalid recommendations

farnz — Fri, 29 Nov 2024 19:05:29 +0000

It wasn't my experience, until spammers started forging my address as the "From" address of their spam. At that point, backscatter went from "something I see once or twice a month" to 5% of my incoming mail. I implemented the entire set of DMARC measures more or less out of desperation, and it basically reduced backscatter to nil. It also, as far as I can tell from the DMARC reports, had a significant impact on the amount of spam that other people got with my address forged onto it.

Invalid recommendations

Curan — Fri, 29 Nov 2024 18:56:50 +0000

> Neither SPF nor DKIM are anti-spam measures.

You should really tell this to various government bodies. Because they list this as requirements to combat spam...

Bud I do understand your position, it is just not, what is implemented in the world by big providers and required by government bodies.

> Back when I ran an email security company (so 2000-2018) we found that an SPF "pass" was a slight spam indicator, because spammers were more diligent about maintaining correct SPF records than non-spammers.

And just like that you told me, that SPF is pointless.

> Google et. al. demand SPF/DKIM/DMARC not to reduce spam, but to be able to hold senders accountable... if a piece of spam passes DKIM and SPF, we can generally know who (as in which domain or which MTA) was responsible for letting it out onto the Internet.

Oh come on, that is not helping anybody. Unless you try to tell me it is hard to get a domain. Which it is not, I must say. And if we assume getting a domain is easy: what does anybody gain by knowing "who" it was? The spammers will just change the domain.

Anyway, in my experience most spam comes from „legitimate“ domains like `gmail.com` and such. Making the whole endeavour circular at least.

Invalid recommendations

Curan — Fri, 29 Nov 2024 18:45:54 +0000

Your response relies on the premise, that „modern“ spammers are still rely on faked sending addresses. In my experience spam comes from two sources:
- barely secured domains (the spammers got a "legitimate" account, even though the operator would say "not an actual user")
- domains created for spamming

There is a (comparatively) small amount of e-mails that would be caught by SPF and/or DKIM.

Invalid recommendations

Curan — Fri, 29 Nov 2024 18:41:41 +0000

OK, that is not my experience on my rather high-volume MTAs. But if it helps you, then my experience might be skewed.

Invalid recommendations

dskoll — Fri, 29 Nov 2024 18:38:04 +0000

Neither SPF nor DKIM are anti-spam measures. They are designed to make it harder for someone to fake mail from your domain. Back when I ran an email security company (so 2000-2018) we found that an SPF "pass" was a slight spam indicator, because spammers were more diligent about maintaining correct SPF records than non-spammers.

Google et. al. demand SPF/DKIM/DMARC not to reduce spam, but to be able to hold senders accountable... if a piece of spam passes DKIM and SPF, we can generally know who (as in which domain or which MTA) was responsible for letting it out onto the Internet.

I agree that telling people not to run their own MTA is very harmful and is damaging to the integrity of the Internet. We cannot let an open and useful protocol slip out of the hands of the community and into the hands of a few powerful multinationals.

Invalid recommendations

pizza — Fri, 29 Nov 2024 18:28:55 +0000

> It is just bullshit compliance theatre, imposed by organisations like CISA/BSI/ENISA/… (in my humble opinion).

SPF/DKIM only attests that the sender is allowed to send on behalf of their domain. That by itself has *significantly* cut down on the amount of outright fradulent or malicious stuff landing in folks' inboxes -- think phising or worse, where the sender is actively trying to hide the origin of their messages.

The latter used to _heavily_ rely on spoofing legitimate domains via open relays or compromised systems; now those folks have to rely on stolen credentials, with a narrow window before the provider shuts it down.

Of course DKIM/SFP does nothing for "legitimate" [1] UCE, but then it's not supposed to.

[1] "unsolicited commercial email" where the sender is who they claim they are, aka what we traditionally referred to as "spam"

Invalid recommendations

farnz — Fri, 29 Nov 2024 18:16:23 +0000

My incoming mail volumes reduced by about 5% when I implemented both DKIM and SPF; I was facing a significant amount of backscatter (due to other people's badly configured MTAs accepting spam with my address as the "From", then sending a delivery report my way when they couldn't deliver it). On some days, backscatter was more than 50% of my total incoming mail.

Implementing DKIM and SPF removed virtually all of that; I can see from DMARC reports that people are still trying to forge my e-mail address as the reply target, but their mail is no longer being accepted. And the rate of forgery has nosedived; when I first implemented it, DMARC reports from the big players (Google, Outlook.com, mail.ru) showed that they were rejecting around 99% of mail that claimed to be from me. Now, they're not reporting any.

Invalid recommendations

Curan — Fri, 29 Nov 2024 18:00:59 +0000

Well, in the end it is about me, isn't it? If I follow the example of big e-mail providers, I will reject anybody who doesn't have SPF/DKIM. It's just, that in my experience: that doesn't help. Actual spam e-mails have those valid headers most of the time. So my improvement is in the point zero-zero-x range, once I add SPF/DKIM in- and outbound.

But you are correct in the basic statement. Directly only my outbound e-mails would be affected. And to be honest: I never saw the reason why a MTA could accept my e-mails today, but not the next day, because I didn't have DKIM/SPF. It is just bullshit compliance theatre, imposed by organisations like CISA/BSI/ENISA/… (in my humble opinion).

Invalid recommendations

mpr22 — Fri, 29 Nov 2024 17:48:49 +0000

I thought the point of SPF and DKIM was to reduce the amount of spam other people receive in their mailboxes whose headers allege that it's from you, not the amount of spam received by you.

Invalid recommendations

Curan — Fri, 29 Nov 2024 17:46:48 +0000

Having a recommendation of "don't run your own MTA" is so very invalid on so very many levels, that I am wondering, why even LWN is repeating such half-thought-out statements. Giving up our infrastructure is never going to be an option.

We should rather point out bullshit and snakeoil requirements in the existing system. Has anybody ever received less spam after adding SPF and/or DKIM? I don't think so. It is just "bullshit compliance" required by big e-mail service providers to keep individuals out of the game (which rarely are the real issue). My personal best option to prevent spam, was blacklisting certain IP ranges. Ever since I did that, my spam level dropped to basically "no longer measurable". But that is, I have to admit, not a politically convenient option. And probably not something you can do like this all around the world, probably not even in most cases.

I can only recommend that everybody runs their own MTA (and makes sure it is secured, of course, but that was an issue from the beginning anyway).

Who is this book for?

Cyberax — Fri, 22 Nov 2024 22:02:29 +0000

> I don't think a change like that would be instant, but just like the large providers deprecating username/passwords in favor of OAuth or insisting on TLS, if they published a new mail submission and mail transfer protocol the smaller services would update or outsource if they want to keep talking to their customers and suppliers on MS/Google email

This is not similar. Very few companies use OAuth exclusively, most support logins/passwords.

> I think we are in agreement, you can self-host the data (bluesky-pds) on an RPi but you can't easily self-host the feed generator/relay/app/moderation provided by the Bluesky app

Uhm. You can, it's not even complicated technically. The fundamental issue is that if you want to do moderation, then you actually have to do moderation.

Who is this book for?

raven667 — Fri, 22 Nov 2024 15:08:12 +0000

>> but if MS and Google agreed and coordinated with the top 100 (maybe even top 20) email services

> email is one service that needs to work with all kinds of clients. Corporations that run in-house email servers will be pissed if you stop receiving their emails.

I don't think a change like that would be instant, but just like the large providers deprecating username/passwords in favor of OAuth or insisting on TLS, if they published a new mail submission and mail transfer protocol the smaller services would update or outsource if they want to keep talking to their customers and suppliers on MS/Google email, and the incentive is for the hosting providers to make outsourcing the easier option, even if that is by making self-hosting more complicated and expensive (costs a larger provider can absorb but a smaller one may not).

>> where you can in theory host your own data [on Bluesky/AT] but the indexing/search/feed/app services have a huge footprint

> No, they're not. I'm self-hosting them on my system. Granted, the setup right now is a pain, but if you just want to follow people and let others follow you, then even an RPi can host it.
> If you want to ingest the whole firehose, then it's a different story.

I think we are in agreement, you can self-host the data (bluesky-pds) on an RPi but you can't easily self-host the feed generator/relay/app/moderation provided by the Bluesky app, even with the code on the bluesky-social github you don't have a full independent service without relying on bsky.app infrastructure, it's designed by people whose relevant experience is managing a firehose of data processing using VC capital, it might not scale down in the way that personal email as described in RYOMS can. At least that's my understanding, I'm not an expert in AT, but I have read a few whitepapers about its design.

Sounds familiar

dilinger — Fri, 22 Nov 2024 01:38:26 +0000

A selling point of JMAP for me is the "over HTTP" bit. It's frustrating when you're at a coffee shop or a doctor's waiting room and their wifi is filtering various SMTP-related ports, so you can't actually send the email you just wrote. Same reason I want XMPP over HTTP..

Who is this book for?

dankamongmen — Thu, 21 Nov 2024 22:17:29 +0000

and yet the kickstarter pulled in $76,883, a figure which made my jaw drop. it is not easy to sell books. it is still less easy to presell them, and doing so via kickstarter is hard indeed.

Sounds useful

mbunkus — Thu, 21 Nov 2024 15:22:17 +0000

I second Diane's experience. The thing is that the amount of stuff to learn & get right is a lot, that's true, but once it's been set up it's definitely _not_ a full-time job per 50 mailboxes. I've been running my own mail server both for myself & my company of ~50 people for years now, and the amount of time I have to spend with mail-server related issues averages to single-digit minutes per day, if that.

The huge timesink is, unfortunately, the very start where you have to learn about everything & get everything right, otherwise you'll fight issues such as non-delivery, landing on anti-spam blocklists etc. for a long time. The initial barrier is huge, the ongoing maintenance very low.

Sounds useful

smoogen — Thu, 21 Nov 2024 14:07:25 +0000

I was probably too harsh having spent too many times lately trying to help people with 'why isn't my email system getting/sending any email' and finding that it is DKIM, SPF, DMARC, SSL certs or some other item which was slightly broken for them... but wasn't easy to figure out. The ones who are using 'black boxes' find that they are usually not kept up or ghost ware. The usual 'howtos' people are pointing to seem to be written from the early 2000's at the latest when the most you had to deal with was procmail/mimedefang spamassassin type things to deal with garbage.

In the end, I expect that for people who have worked in email for a while, there is a lot of hidden knowledge which allows you to miss a lot of minefields other people seem to walk into over and over again.

Sounds useful

dskoll — Thu, 21 Nov 2024 13:38:48 +0000

I think you overstate the difficulty. I ran self-hosted mail for my small company of 12 people for about 18 years, and it really wasn't much work once it was set up. I've been running my own personal email for about 8 years, and again... once the initial setup was done, tending it has been almost no work.

DKIM, DMARC, and SPF haven't changed in years, and neither has SMTP.

Sounds useful

smoogen — Thu, 21 Nov 2024 12:34:55 +0000

The main problem with any 'blackbox' is that it takes a lot of work to keep up. When JZB mentions that this is like a 'garden', it really is. It takes a lot of time and resources to keep up with the 'game' of stopping spam and malware. You think you got all the weeds only to come back tomorrow to find a whole new set come in.. and you have to get to them THEN because they have roots which will kill your crops if they get too big.

At the moment I can only see email being done in the following forms:
1. Full time job of 1 admin for every 50->100 mailboxes with lots of ways for the service to go down daily still.
2. Outsourced job to some company which deals with millions of mailboxes
3. A local gardening job to let someone who likes to dabble in things learn how the internet changes regularly.
4. One of the above but poorly resourced and over burdened.

The problem tends to be that a lot of companies were doing 1 but not staffing appropriately.. so they went to 2. Various companies which did email as a service also didn't staff appropriately and there was 'market' consolidation where 60-90% of the market ends up with 3 vendors.

that leaves people like me who were trying 3 for years but finally ended up being in 4.

Sounds useful

intelfx — Thu, 21 Nov 2024 12:18:05 +0000

> Are there any other such projects?

Mail-in-a-box, for instance. Although it's deliberately designed to be non-customizable (and takes an entire host for itself, also by deliberate design).

Sounds useful

knewt — Thu, 21 Nov 2024 11:33:51 +0000

> Are there any other such projects?

Although I haven't tried it at this point (nor docker-mail server), there is also mailcow, which in complete coincidence I started investigating recently!

Sounds familiar

jond — Thu, 21 Nov 2024 11:16:38 +0000

the aerc client (featured on LWN recently) supports JMAP, although I've not used it.

Sounds useful

NRArnot — Thu, 21 Nov 2024 10:22:44 +0000

I was going to comment that somebody ought to virtualize this stuff into a "black box" that was safe to use straight away while customizable later if the need arose. Looks as if somebody already has.

Are there any other such projects? Also who is maintaining docker-mailserver (because from bitter experience if there are any exploitable weaknesses in a mail server setup, some slimy spammer will exploit them). Hopefully some relatively large and permanent organisation, rather than "one guy working without reward from his bedroom in Nebraska" (XKCD, maybe mutated through my memory)

Bitter experience drove my employer into the arms of Google many moons ago, but I always wonder what we would do if Google turned evil?

Sounds useful

ranger207 — Thu, 21 Nov 2024 04:34:42 +0000

This looks like a very useful book. I host my own email with docker-mailserver which is basically a prepackaged collection of Postfix etc, and it's good for being comprehensive enough to be usable immediately while open enough that you can learn more about standard email setups when you need or want to. This book looks like the perfect companion for me in that it's a overall look at why each part is the way it is, which is not readily provided by the RFCs

Who is this book for?

Cyberax — Wed, 20 Nov 2024 19:30:33 +0000

> I had a half-formed thought before that keeping organizations invested in SMTP allows small independent services to exist, like a personal domain, but if MS and Google agreed and coordinated with the top 100 (maybe even top 20) email services

email is one service that needs to work with all kinds of clients. Corporations that run in-house email servers will be pissed if you stop receiving their emails.

> where you can in theory host your own data but the indexing/search/feed/app services have a huge footprint

No, they're not. I'm self-hosting them on my system. Granted, the setup right now is a pain, but if you just want to follow people and let others follow you, then even an RPi can host it.

If you want to ingest the whole firehose, then it's a different story.

Book reviews

corbet — Wed, 20 Nov 2024 16:10:31 +0000

Occasional book reviews are a longstanding tradition here, though, going back to 1999.

Sounds familiar

smoogen — Wed, 20 Nov 2024 15:45:58 +0000

And thank you for that software.. I ran sendmail way too many years because it made it usable on the Internet in the 00's and early 10's.

Cheers and (un)expectations

daroc — Wed, 20 Nov 2024 15:40:36 +0000

We don't do too many book reviews, but we also covered Practical Julia back in April. So it's the kind of article we run sporadically.

Cheers and (un)expectations

Kamiccolo — Wed, 20 Nov 2024 15:36:19 +0000

Woa, for me articles like book reviews weren't the thing I was ever expecting on LWN. But, I must admit, I've enjoyed this detailed review and run-through a lot! The consistency and the format in general makes it really pleasant to read and get familiar what to expect from the book (which do seem like just a book to get!). Thanks a lot!

Btw, the cover of the book (created by Eddie Sharam?) made me burst into laugh, I believe in this kind of work, right joke is a virtue :}

Btw, currently Lucas do seem to be running a Kikcstarter for his next book (or rather collection of FreeBSD Journal Letters Column Entries).

Who is this book for?

raven667 — Wed, 20 Nov 2024 14:21:03 +0000

I had a half-formed thought before that keeping organizations invested in SMTP allows small independent services to exist, like a personal domain, but if MS and Google agreed and coordinated with the top 100 (maybe even top 20) email services they could define a new private protocol between themselves, that might have great technical and security benefits, which would be too difficult for small personal servers to effectively use, even if it is officially "open". In some ways that reminds me of Mastodon/ActivityPub vs Bluesky/AT where you can host your own personal Mastodon instance just like email (but then have to deal with substantial administrivia and performance issues such that paid hosting services exist to help automate server management) or Bluesky where you can in theory host your own data but the indexing/search/feed/app services have a huge footprint that can really only be provided by a big tech company, it's infeasible/impossible to host the app on your own. I could see email moving to an AT-like situation.