Item — HN Reader

> processed by either Google or Microsoft

Let's first clear up why this is: spam control. Google along with the rest of the industry has essentially killed email spam through the many additions to classical email standards. From reputation based delivery, to spam databases, crypto signatures and more. This isn't just to reduce an eye sore in your inbox. Spam does real damage, financial and otherwise.

Despite the complexity needed to run a reliable email system, it's still possible to do and many do. It also allows for innovation without a lot of capital (e.g. licensing fees paid to walled garden owners). Without open interoperability, it's either impossible (e.g. general iMessage), limiting (e.g. iMessage, WhatsApp for business) or expensive to do.

1 comments

> Let's first clear up why this is: spam control.

I'm running my own mail server. The problem with regards to spam is not that it's hard for me not to be inundated by spam: I'm just running spamassassin and qpsmtpd with mostly standard configuration and my account on my own server is rather better at catching spam and not ham than my Gmail account. The problem I've always been fighting with (it's better lately) is that Google (and to a lesser degree Yahoo and Microsoft) tends to put my mails into the recipients' spam folders.

It's understandable that a minimal level of centralisation is necessary with email so as to build up server reputation. I think that level is already satisfied with just a few dozen or maybe hundreds of emails sent per day. If there are many installations of that size, companies like Google are forced to accept mails from them, and there's no need for further centralisation.

> Google along with the rest of the industry has essentially killed email spam through the many additions to classical email standards. From reputation based delivery, to spam databases, crypto signatures and more.

I don't see Google having had an exceptional role in "killing" email spam that way. Spam databases (both server reputation as well as content fingerprints) existed before Gmail started, DomainKeys was designed by Yahoo[1], the DKIM (the current way to add cryptographic signatures) RFC[2] does not list anyone from Google as its authors, bayesian learning was published by PG[3] in 2002. Gmail launched 2004[4]. Giving reputation much weight was something easy for them to do and it does tend to come at the cost of small legit servers.

They had a solid implementation early on (both the spam filter and, for the time, a top notch HTML UI), had of course a good name, and were free, so they were a default choice for anyone who was with an email provider that didn't do well (like many (most?) ISPs). There are reasons for people to flock to a strong, large company, that's not different here, but I contest that spam necessitated this.

That said, any new protocol would do well to take the problem of handling spam seriously and learn from and improve upon the past.

TL,DR: my argument is that spam is (somewhat) easier to handle in a centralised way, just like most problems are, but handling spam doesn't inherently require centralisation.

[1] https://en.wikipedia.org/wiki/DomainKeys [2] https://www.rfc-editor.org/rfc/rfc6376.txt [3] http://paulgraham.com/spam.html [4] https://en.wikipedia.org/wiki/Gmail