We need to defeat this bizzare cognative dissonance people face when they have to re-evaluate the place email holds in their mind. It's not some useless relic of the last generation to cast off in the course of chasing the shiny new.


- Federated
- Decentralized
- Built with open standards
- Fault tolerant
- Enjoys a wide variety of open-source clients & servers
- Has widely available implementations for almost every programming language
- Already being used for software development at scales greater than GitHub-style development has ever dreamed of

"Email? Yuck"

Screw that noise. Set aside your preconceptions and look at email for what it is. The things that make you "yuck" about email are more related to the bastardization of email *software* by corporate interests like Google and Microsoft, and have next to nothing to do with email itself.

>- Fault tolerant

Only until you introduce spam filters.

Spam filters does not break fault tolerance of the protocol. They are also configurable and can behave pretty much as you like them to.
Unless you are talking about spam filters at some hosted provider. When someone else runs your email environment, well... Then they run your email environment and how they configure their spam filters are up to them.

Partial disclosure: a few years back I switched assignment and now runs all SMTP gateways and SPAM filters for a multinational corporation so my views of what is "easy" and "doable" is severely warped.


@qrsbrwn @sir
do your spam filters:
- reject the spam during the SMTP transaction, returning an error code?
- reject the spam asynchronously, long after the SMTP transaction, returning a bounce
- silently drop spam asynchronously, long after the SMTP transaction

That very much depends on how certain I am about classification.

I'm sorry but I can't be specific. Obvious spam is dropped, questionable emails are either flagged or quarantined depending on certainty.
Apart from that there isn't much I able to discuss about the actual implementation.


@qrsbrwn @sir damn, I was hoping you could make a tutorial for us noobs, or sth.

My experience is mostly with spam filters of free ema providers, and they tend to have very annoying false-positives. Even when they don't drop such an email outright, it may arrive with a whole day of delay.
And then you have some providers who don't work with mailing lists because of a too strict SPF policy.

@wolf480pl @qrsbrwn @sir

Yeah.. good luck self hosting if you get one little config wrong. SPF, PTR, DMARC.. insta-spam on hotmail/gmail

Oh look DNS strikes again 😂

@idanoo @qrsbrwn @sir
DNS is your friend, you just need to be patient. PTR is easy too.

SPF, DKIM, DMARC - yeah, this is a bit of a mess, with multiple conflicting approaches to authenticity checking.
And then the big players will feed that into a machine learning black box anyway.

@wolf480pl @idanoo @sir SPF, DKIM and DMARC aren't that complex. It's daunting at first but then you get the hang of it.
If you're uncertain you just get a Gmail account to test shoot against. They will tell you why they won't accept your mail and just getting it wrong won't get you blacklisted.
Email only seems hard because it is from another era and new things has been added over time.
I rather like mail but that could be because for the last 3 or 4 years I have been working mostly with SMTP stuff :)

@qrsbrwn @sir @idanoo
oh, it's not "how does SPF work" and stuff. It's "should I use SPF? DKIM? DMARC? Which of those should I validate on incoming email?" And if you get that wrong you break mailing lists and .forward.

@wolf480pl @sir @idanoo the correct answer is to validate all of them and then assign a score. Both spamassassin and rspamd will do this for you :)
@wolf480pl @sir @idanoo yes but right answer on what to check is everything ;)
How you weight the results is a different matter which takes both a collective effort and a soft touch.

@qrsbrwn @sir @idanoo
My point is, if it's a heuristic, it will act unpredictably. A sender can't be sure what conditions are enough to guarantee you will receive their email.

@wolf480pl @sir @idanoo true but false positives is generally only a problem for marketing and HR departments. You know, the departments that sends email that can't be distinguished from spam.
Even then what is spam and what is ham is retroactively decided by the recipient which means that unless you have mind-reading capabilities in your spam filter there will be the occasional false positive.
My general advice to people who gets caught by spam filters is "stop sending spam"

@qrsbrwn @sir @idanoo
From my experience, most false-positives are account activation mails. Tell those to stop sending spam...

Anyway, I guess I would prefer the server to only protect against sender spoofing and such, and let actual content-based spam filtering to be done by the MUA.
I know many people can't do that because they have noob customers, but if I were to host email just for myself, it'd be preferable. The question is, how to do it reliably.

@wolf480pl @sir @idanoo I think you underestimate how large percentage of emails which are spam.
You do not want to do that MUA side because it would start fires and you would waste very very much resources routing and storing spam.

With email, you could even get your patches over the radio with something like Winlink. Well, as long as you don't mind no encryption and a prohibition on commercial use...

@sir that’s a good point. Thanks for sharing this!

@sir also email:

-A pain in the ass to setup properly (the server)
-Centralized blacklists
-30% overhead in attachments
-A few corps control a lot of email accounts
-Encryption? What?
-E2E fails to provide some interesting properties (metadata leaks, anonymity)
-Best effort, not guarantee to reach the recipient
-Lots of spammers
-Unicode hacks

It has its limitations as well, but I still love email. I would like to improve some things *without* losing the nice features.

@sir Lots of great stuff about e-mail except:
- Lack of useful encryption/privacy
- Lack of verifiable identity, which enables spam, phishing, and other bad stuff
- PGP doesn't encrypt metadata, to the NSA's delight

<shameless_plug> Working on building a worthwhile replacement, too. </shameless_plug>


Agreed, fuck HTML. Not relevant for patches (okay, a little relevant, but it's bad mail clients that are at fault, software built on email could do it without HTML and users would be none the wiser).

- Lack of encryption/privacy

Not relevant for patches, PGP signatures are sufficient if desired

- Lack of identity

Mainly fixed with DKIM, but also not really relevant for patches.

- More encryption

See above

- Shameless plug

Interesting, email me if you want more feedback

@sir Not quite ready for feedback yet, but getting closer. I'll definitely check in when I feel more ready.

@sir I just wish the protocols would get a major upgrade. Especially MIME is just full of old cruft like Mime-Version and 7bit encoding.

@sir I mean, yes, email as most people know and use it is kind of an old relic of the last generation mainly because IM is now so big.

However, Email in terms of protocols is not nearly as outdated as one may think, if anything, it has stood up against time quite well when you think of it.
I mean, I used to have a school project with some former classmates where we managed to create an IM based on email.

Though, back then, none of us cared about federation and decentralization or anything.

@finlaydag33k isn't that #DeltaChat? 🤔 wait, don't tell me you invented Delat Chat before them and didn't even realize its potential


@sir I am agreeing with you but not following how Microsoft did anything to email other than champion it. Mailspring is my current preferred email client but outlook is still a very powerful email client and I've yet to find its equivalent in software.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!