Don’t get me wrong: having written enough email-stuff myself, I can fully sympathize with Linus.
That said: Just like the worldwide web is quickly turning into whatever Google pushes through Chrome and their web assets, internet email now slowly seems to become whatever Gmail does or supports. Which is terrible.
90% of the programming guides for various languages and libraries now are not “This is how you send an internet email using SMTP from $X”, they are “This is how you send a Gmail from $X”.
And all that’s because of one single thing only: Market-share.
Get off Gmail. Get off Chrome. And help others do that too. Help bring down that market-share, and you may help restore balance to the internet.
I've been hosting my own mail for more, than a decade.
It pays off; eg. I can access it even in China, unlike gmail.
Despite the myths, it's not _that_ hard to set it up, but you do need your clean own ipv4 address for everything to go smooth - I mean go around and get it off blacklists before you actually start using it as mail server.
Test it here: https://mxtoolbox.com/blacklists.aspx
Once that's done, things like SPF, DKIM, DMARC are time consuming to set up, but not particularly hard or tricky, and there are tonnes of good guides out there.
Actually you need to clean /24 your address belongs to. Some people use blacklists which assign reputation to the whole /24 and unless you control that, you're going to have a bad day.
(Yes, it's a really silly idea to use those lists, but some people do. And you want their users to get your emails.)
I had my own mail service. I switched to gmail when it first came out because the spam filtering was much much better than anything than available to the public. Kind of like why I switched from altavista to google search.
What's the spam filtering picture like for DIY these days?
It is so sad. Isn't email meant to be decentralized and distributed? Instead people go to Gmail although it's full of ads and Google is abusing their privacy. The death of Google Inbox (which used to have a strong fan group) could have been an opportunity for many users instead of using Gmail switching to another email provider, instead they just install another client and continue using Gmail. I really hope Gmail is going to implement harder restrictions against those clients, so that people finally understand that Gmail is bad and look for other options.
Doing my part. I've been an Inbox user ever since it was released, and liked it due to how much simpler it was to keep the inbox clean, and a much improved layout and usability over regular Gmail (centered, cleaner layout, grouping by day / age etc). But lack of attention to the product for smallest basic things (e.g. number of unread messages in tab title) for years, and eventually announcement of shutdown, with simultaneous missteps with Chrome, really did it for me. Looking at a garbled mess that is Gmail UI on a larger resolution was not an option. Aqua Mail is amazingly customizable for Android, Postbox works nicely on OSX, and Firefox is better than ever and much easier to go back to than I expected. Not looking back for sure. If only I could get rid of my Gmail address as well, but that's significantly harder...
I have thought about using something else than gmail, but it seems hard to find something reliable enough, free, that will still be there in 10 years, which a good enough spam filter, with customizable filters and labels.
Changing one's email address is not a trivial task, I would not do it if I would be sure it's worth it.
I totally understand the political issues of privacy and monopolies, but fighting those by not using gmail is not going to improve things that much.
Everybody knows privacy is an issue, but switching to a privacy-oriented mail provider will also make somebody rich over some paranoia, and it won't necessarily make things more secure.
> it seems hard to find something reliable enough, free
I’m sure if you decide that your privacy and the health of the Internet holds value to you (as in, you’re willing to put your money where your mouth is), finding good options will be much easier.
Personally I use a paid FastMail-account which I’m super-happy about, but I’ve heard there are other good options out there too.
But if you don’t want to pay for a core service you use every day, for everything, you can’t complain about that service degrading, now can you?
Because you might not like where Google takes Gmail or Chrome in the future. Like when we had a decade of zero progress in web technology because Microsoft was holding everyone back with their virtual Internet Explorer monopoly.
Or more graciously, it's an example of how most or all of us prioritize what is convenient today over the very real risk of negative things tomorrow. Harm to others in the future doesn't weigh as heavily as as immediate harm to myself now.
We don't usually realize we're doing it, but I think we all do this. Using Google products is a very common example.
It's invalid only if Google could never be dangerous. That's why I referred to "the very real risk of negative things tomorrow" rather than "harm to others today."
Have the entire world change their implementation rather than the one company which is doing it wrong?
This is not how RFCs work. There's a reason RFCs came about, and it was to prevent this exact type of situation. Just because a company has a large market share, doesn't mean RFCs should be changed to suit it.
So instead of a non opinionated RFC that most clients and servers mostly follows you now have an opinionated RFC that nobody follows and is useless. I'm not sure what the gain is there.
It's tempting to pile on Gmail and its monopoly and use this as an example of them "taking over" email but at the same time this type of ossification for long-used protocols is fairly common in my experience. In practice everybody ends up relying on a safe subset of the spec that everybody is expected to understand correctly.
Try implementing a fuzzer for HTTP, SMTP, NTP, USB-C, CD-ROM or, say, TLS that tests every obscure corner case of the spec and see how many implementations fail to conform.
Given that I wasn't aware of this issue before reading this email shows that it's probably not much of an issue in practice. I can imagine that whoever implemented this at Google took a shortcut originally, adding a "// XXX maybe we should allow arbitrary order for headers?" comment and it never turned out to be an issue in practice (better yet, it might help them discard bogus emails early in the pipeline).
Still, I can empathize with Linus's frustration, it's always annoying when you write technically correct code and it doesn't work because a third party didn't do it right.
Would it help to shuffle the order of the headers in new protocols so software is forced to deal with it actually being optional? Either the order is fixed, or you have to actually experience variety so code in the wild is written to deal with it.
> (better yet, it might help them discard bogus emails early in the pipeline).
I wouldn’t expect it to be deliberate, but at the same time it wouldn’t surprise me if it was in fact deliberate. SpamAssassin certainly has various rules around precise unusual patterns in headers, penalising things that are perfectly legal, but close to never seen on legitimate email.
The main reason I wouldn’t expect it to be deliberate is actually that it’s too helpful: they tell you they’re rejecting it, whereas Gmail’s regular spam filtering is a black box that discloses nothing. I could imagine them black-holing emails like this deliberately as part of a spam-filter, but rejecting them isn’t their style.
> this type of ossification for long-used protocols is fairly common in my experience
Agreed HTTP (and all it's intermadiary like proxy and cache servers), FTP, IRC, SMTP, ... When you take a peek at what the incumbent actually do and support it's a real wonders that anything works at all.
Everyone has their own specific thingy and they own way to understand this or that part. Are they wrong ? Yes, probably, but at the end of the day it's just like this case: the question is not is gmail right or wrong, it's do you want your mails to go through gmail or not.
I don't understand how that applies to what I was saying. I was commenting that it's not an issue that crops up often in practice, which is probably why the engineers at GMail made the assumption that it could reasonably be ignored.
I'm not saying that it can never be an issue (this it obviously is in this case), I'm saying that it's not necessarily a bad engineering decision. Adding code to handle weird corner cases of a standard means adding code that won't be used 99.999% of the time (a number I pulled freshly out of my buttocks, but wouldn't be surprised if it was close to the truth in this case), that's more likely to rot, be poorly tested and become a maintenance liability.
I'm not saying people never find $20 bills on the ground, I'm saying that if most people routinely found $20 bills on the ground every other day we'd probably have heard about it by now. The fact that it only came to my attention in this email (and I hosts my own email server and have written SMTP clients and server code in the past) tells me that it's probably not such a widespread problem. If GMail started routinely bouncing incoming mail because they didn't support the standards correctly I'm sure we'd see an article or ten pop up on the front page of HN.
I'm more disappointed about the RFC than gmail... Publishing a specific syntax which uses specific ordering and just leaving a note that it's actually incorrect is a really bad way of writing specifications. RFCs should be really clear and explicit in things like that.
Sure, that's the theory. The practice is that people won't, and you either have to accept the bad implementations or make sure that everything is as explicit as possible. (And that you don't contradict yourself) If people implemented specs 100% correctly, we wouldn't have bugs.
Even without malice or incompetence, people will make mistakes.
It has a light color scheme, if your browser supports the media query `screen AND (prefers-color-scheme:light)`. Currently that’s Safari 12.1, and Firefox beta channel or later.
(I run Nightly, so I was initially puzzled by your comment, since I was seeing it light.)
As an aside, this is a superbly professional e-mail, with clear references to the applicable standards, and the disapproval of the broken service stated firmly, but using clean language.
Does anybody really think that Linus' (hopefully) past practice of starting with a foul mouthed rant, and only drilling down into the technical detail three pages in was a more effective way of communicating?
It wasn't "past practice". Linus' rants were a rare event, in case of major "sins" commited by core contributors. They are what made it out in the open, but a lot of Linus' messages in the mailing lists is actually a sane, technical discussion.
I recall Linus calling some filesystem brain-dead (-damaged?). Could be [1] or [2], but I'm getting a cloudflare error when I try to visit the links. Not as bombastic as some of his rants, but this email is much more professional.
It was more entertaining, and also working to figure out others' mistakes is more rewarding if you get to berate them in public, so not being allowed to rant reduces the incentive to do the work and thus makes more likely that mistakes will remain unnoticed.
I'm sure Linus used clean language 99.999% of the time. He sends dozens of mails daily, so his rate of swearing is not out of the ordinary. The media made it to be something newsworthy, when it was not.
Well, there may be some selective reporting, but I'm pretty sure you could go through the public writings of other prolific open source contributors (e.g. Larry Wall) without even digging up ONE instance of public profanity.
51 comments
[ 6.3 ms ] story [ 108 ms ] threadDon’t get me wrong: having written enough email-stuff myself, I can fully sympathize with Linus.
That said: Just like the worldwide web is quickly turning into whatever Google pushes through Chrome and their web assets, internet email now slowly seems to become whatever Gmail does or supports. Which is terrible.
90% of the programming guides for various languages and libraries now are not “This is how you send an internet email using SMTP from $X”, they are “This is how you send a Gmail from $X”.
And all that’s because of one single thing only: Market-share.
Get off Gmail. Get off Chrome. And help others do that too. Help bring down that market-share, and you may help restore balance to the internet.
Despite the myths, it's not _that_ hard to set it up, but you do need your clean own ipv4 address for everything to go smooth - I mean go around and get it off blacklists before you actually start using it as mail server. Test it here: https://mxtoolbox.com/blacklists.aspx
Once that's done, things like SPF, DKIM, DMARC are time consuming to set up, but not particularly hard or tricky, and there are tonnes of good guides out there.
Actually you need to clean /24 your address belongs to. Some people use blacklists which assign reputation to the whole /24 and unless you control that, you're going to have a bad day.
(Yes, it's a really silly idea to use those lists, but some people do. And you want their users to get your emails.)
What's the spam filtering picture like for DIY these days?
Changing one's email address is not a trivial task, I would not do it if I would be sure it's worth it.
I totally understand the political issues of privacy and monopolies, but fighting those by not using gmail is not going to improve things that much.
Everybody knows privacy is an issue, but switching to a privacy-oriented mail provider will also make somebody rich over some paranoia, and it won't necessarily make things more secure.
I’m sure if you decide that your privacy and the health of the Internet holds value to you (as in, you’re willing to put your money where your mouth is), finding good options will be much easier.
Personally I use a paid FastMail-account which I’m super-happy about, but I’ve heard there are other good options out there too.
But if you don’t want to pay for a core service you use every day, for everything, you can’t complain about that service degrading, now can you?
Why would I sacrifice my productivity for some abstract over-arching notion of "balance"?
We don't usually realize we're doing it, but I think we all do this. Using Google products is a very common example.
Third option: Update the RFC so that it's more opinionated and makes the ordering of the headers a mandatory part of the spec.
This is not how RFCs work. There's a reason RFCs came about, and it was to prevent this exact type of situation. Just because a company has a large market share, doesn't mean RFCs should be changed to suit it.
Try implementing a fuzzer for HTTP, SMTP, NTP, USB-C, CD-ROM or, say, TLS that tests every obscure corner case of the spec and see how many implementations fail to conform.
Given that I wasn't aware of this issue before reading this email shows that it's probably not much of an issue in practice. I can imagine that whoever implemented this at Google took a shortcut originally, adding a "// XXX maybe we should allow arbitrary order for headers?" comment and it never turned out to be an issue in practice (better yet, it might help them discard bogus emails early in the pipeline).
Still, I can empathize with Linus's frustration, it's always annoying when you write technically correct code and it doesn't work because a third party didn't do it right.
I wouldn’t expect it to be deliberate, but at the same time it wouldn’t surprise me if it was in fact deliberate. SpamAssassin certainly has various rules around precise unusual patterns in headers, penalising things that are perfectly legal, but close to never seen on legitimate email.
The main reason I wouldn’t expect it to be deliberate is actually that it’s too helpful: they tell you they’re rejecting it, whereas Gmail’s regular spam filtering is a black box that discloses nothing. I could imagine them black-holing emails like this deliberately as part of a spam-filter, but rejecting them isn’t their style.
Agreed HTTP (and all it's intermadiary like proxy and cache servers), FTP, IRC, SMTP, ... When you take a peek at what the incumbent actually do and support it's a real wonders that anything works at all.
Everyone has their own specific thingy and they own way to understand this or that part. Are they wrong ? Yes, probably, but at the end of the day it's just like this case: the question is not is gmail right or wrong, it's do you want your mails to go through gmail or not.
Two economists walk down a road. One of them says, "look, a $20 bill on the ground."
The other one says, "that's impossible, if there was money on the ground, someone would have picked it up already."
I'm not saying that it can never be an issue (this it obviously is in this case), I'm saying that it's not necessarily a bad engineering decision. Adding code to handle weird corner cases of a standard means adding code that won't be used 99.999% of the time (a number I pulled freshly out of my buttocks, but wouldn't be surprised if it was close to the truth in this case), that's more likely to rot, be poorly tested and become a maintenance liability.
I'm not saying people never find $20 bills on the ground, I'm saying that if most people routinely found $20 bills on the ground every other day we'd probably have heard about it by now. The fact that it only came to my attention in this email (and I hosts my own email server and have written SMTP clients and server code in the past) tells me that it's probably not such a widespread problem. If GMail started routinely bouncing incoming mail because they didn't support the standards correctly I'm sure we'd see an article or ten pop up on the front page of HN.
Even without malice or incompetence, people will make mistakes.
(I run Nightly, so I was initially puzzled by your comment, since I was seeing it light.)
[1] http://thread.gmane.org/gmane.comp.version-control.git/70688...
[2] http://article.gmane.org/gmane.comp.version-control.git/7076...