4 ms·

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-u

by simias 8y ago

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.

ancarda 8y ago
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.
chrismorgan 8y ago
> (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.
nolok 8y ago
> 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.
ses1984 8y ago
>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 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."
- simias 8y ago
  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.
  - ses1984 8y ago
    Maybe you're right. I just like that joke.
mikl 8y ago
Making errors while producing software is natural. Deciding to ignore complaints and refuse to fix your errors is not. It's just Google arrogance.

by simias 8y ago

ancarda 8y ago

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.

chrismorgan 8y ago

> (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.

nolok 8y ago

> 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.

ses1984 8y ago

>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 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."

simias 8y ago
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.
- ses1984 8y ago
  Maybe you're right. I just like that joke.

mikl 8y ago

Making errors while producing software is natural. Deciding to ignore complaints and refuse to fix your errors is not. It's just Google arrogance.