5 ms·

In this case, Courier is following the standard and it's failing, and it's the "fault" of the software. Courier is breaking (the aptly named) Postel's Law: "Be

In this case, Courier is following the standard and it's failing, and it's the "fault" of the software. Courier is breaking (the aptly named) Postel's Law: "Be liberal in what you accept, and conservative in what you send." Courier is failing to be liberal in input-handling.

corndoge 6y ago
Postel's law was a good rule of thumb in the early wild west internet. In modern times I think it's largely anachronistic. Being liberal in what you accept leads to security problems, erosion of standards, growth of edge cases, etc.
- young_unixer 6y ago
  I don't think anachronistic is the right description, but I agree that in some contexts Postel's law should not be followed. Postel's law is a good rule of thumb if you're writing a JSON library, but not if you're writing anything that has to do with security.
  - yjftsjthsd-h 6y ago
    JSON libraries are security-sensitive, though; they tend to get used on content coming from 3rd parties over the internet.
  - woodruffw 6y ago
    > Postel's law is a good rule of thumb if you're writing a JSON library, but not if you're writing anything that has to do with security. I'm a big fan of Postel's law in the context of UNIX tools, but I think that JSON is exactly the wrong example: JSON parsing is a security/format boundary, and I don't want my JSON (or any other parser) trying to suss structure out of something that's under- or unspecified. That way lies input confusion vulnerabilities.
    - DaiPlusPlus 6y ago
      Well, one example is having a JSON object property that is nominally typed as `number` but a JSON parser/library would also accept a number-in-a-string, so both `{ "foo": "123" }` and `{ "foo": 123 }` would be accepted. Storing numbers inside strings can be necessary if you're encountering JavaScript's 2^56 limit on integers, for example.
      - woodruffw 6y ago
        > Well, one example is having a JSON object property that is nominally typed as `number` but a JSON parser/library would also accept a number-in-a-string, so both `{ "foo": "123" }` and `{ "foo": 123 }` would be accepted. This is a great example of "paving over bad behavior with worse behavior." If JSON is specified to only represent numbers that fit within a JavaScript double, then a correct parser must fail on numeric literals that don't fit into that type. It's up to me as a consumer to interpret strings that represent larger numbers. I've had this exact kind of "helpful" behavior cause potentially exploitable bugs in programs before: a complex system was using more than one JSON parser, and parser Foo would accept numeric inputs that parser Bar would silently fail on (mangling large numbers into garbage). The result was a potential arbitrary read primitive.
        deathanatos 6y ago
        > If JSON is specified to only represent numbers that fit within a JavaScript double, It isn't / doesn't make that restriction. For example, 10000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000 is a valid JSON value. Python will decode it to an integer with the equivalent value; JavaScript will decode it to "Infinity", as it exceeds the limits of Number. (Despite nowadays having a bigint type that could represent it.) It is possible to write a JSON parser in JavaScript that would handle decoding large numbers to BigInts. Most people just don't bother, as it's pretty rare to need to go above the 2 * 53 limit of JS's number.
  - jeff-davis 6y ago
    Everything has to do with security. Especially message formats like JSON. Accepting a non-conforming message could easily lead to injection.
  - josefx 6y ago
    I prefer not having to maintain code that is overly flexible with its input. Last time I ran into half a page of workarounds for bad input I spend a day tracking down all affected files and making sure I could either ignore or fix them. The result was a neat little string comparison that didn't have half a dozen unpredictable edge cases.
- mytailorisrich 6y ago
  It's important to consider each decision. Sometimes it is not fine to be liberal, sometimes it is. In this case, I'd say that an MX record containing an IP address is not a big deal versus an MX pointing to an A record that contains an IP address, so one may consider that it makes sense to favour successful delivery of emails over strict enforcement of the standard and to accept it. That's pretty much what Postel's law is about and why many servers do accept it (though it also makes sense for a server to refuse to be configured that way even if it accepts it externally for robustness). Postel's law is not an anachronistic concept. This sort of design consideration applies everywhere in the real world.
hannob 6y ago
I thought about adding that, I should've... It's widely believed these days that postel's law was a mistake.
chrisseaton 6y ago
Do you want to send people email? Then you'll need to be liberal in what you accept.
- tedunangst 6y ago
  Why can't the other party be conservative in what they send?
  - chokeartist 6y ago
    Go back to reddit. RFCs are standards but real life requires acceptance of divergence from the exact letter of the law.
  - chrisseaton 6y ago
    > Why can't the other party be conservative in what they send? Because they don't want to be? Because they don't know that they should be? Because they don't know how? Because they think they are but they're mistaken? Because the specification is ambiguous? Any number of reasons. But you can't control what they do. You can only control what you do. If you want to send an email to them, you need to be compatible with their email server.
jeff-davis 6y ago
I think there's some nuance here. Being liberal in what you accept is good for the growth and connectedness of a network. It's so powerful that it's not so much a suggestion as an inevitability -- if you're trying to be perfectly strict, then you will be excluded from the network and other people will find a way to be included. A party will always be bigger when you are less strict about the invitation/rsvp protocol. But it has obvious downsides. One is that the protocol keeps evolving, because people find novel ways to be non-conforming senders. This means an implementation is never "done". Another is that it becomes so hard to create a new implementation that accounts for all the non-conforming behavior, that the "standard" essentially becomes defined by a few of the big implementations.
JdeBP 6y ago
It is important to remember what Marc Crispin had to say about this: > Actually, Postel's principle is misstated. I knew Jon personally. He never advocated forcing implementations to accept bogus protocol, and it is a perverson of Jon's legacy to claim otherwise. > "Be liberal in what you accept" referred to accepting a wide range of valid protocol, as opposed to accepting only the most common form. If you consider the early protocols, such as Telnet and FTP, it was all too easy to create two compliant and non-interoperable implementations due to each implementation choosing a different subset. -- https://groups.google.com/g/alt.comp.mail.qmail/c/dcwx0Wc7ypU/m/--E_3AQB5QcJ https://groups.google.com/g/alt.comp.mail.qmail/c/dcwx0Wc7yp... > This statement is based upon a terrible misunderstand of Postel's robustness principle. I knew Jon Postel. He was quite unhappy with how his robustness principle was abused to cover up non-compliant behavior, and to criticize compliant software. -- https://groups.google.com/g/comp.mail.pine/c/E5ojND1L4u8/m/iYunDY6h_xMJ https://groups.google.com/g/comp.mail.pine/c/E5ojND1L4u8/m/i...
- chrisseaton 6y ago
  > "Be liberal in what you accept" referred to accepting a wide range of valid protocol Have you considered that after some point you need to accept the de facto protocol as a valid protocol? If everyone else is using unnamed but extant protocol X, why fight that? What do you gain from it?
- DonHopkins 6y ago
  Marc "MM Is Not At Fault" Crispin was also the author of the "infamous" RFC 748: Telnet Randomly-Lose Option. https://en.wikipedia.org/wiki/Mark_Crispin https://en.wikipedia.org/wiki/Mark_Crispin https://tools.ietf.org/html/rfc748 https://tools.ietf.org/html/rfc748 4. Motivation for the option. Several hosts appear to provide random lossage, such as system crashes, lost data, incorrectly functioning programs, etc., as part of their services. These services are often undocumented and are in general quite confusing to the novice user. A general means is needed to allow the user to disable these features.

corndoge 6y ago

Postel's law was a good rule of thumb in the early wild west internet. In modern times I think it's largely anachronistic. Being liberal in what you accept leads to security problems, erosion of standards, growth of edge cases, etc.

young_unixer 6y ago
I don't think anachronistic is the right description, but I agree that in some contexts Postel's law should not be followed. Postel's law is a good rule of thumb if you're writing a JSON library, but not if you're writing anything that has to do with security.
- yjftsjthsd-h 6y ago
  JSON libraries are security-sensitive, though; they tend to get used on content coming from 3rd parties over the internet.
- woodruffw 6y ago
  > Postel's law is a good rule of thumb if you're writing a JSON library, but not if you're writing anything that has to do with security. I'm a big fan of Postel's law in the context of UNIX tools, but I think that JSON is exactly the wrong example: JSON parsing is a security/format boundary, and I don't want my JSON (or any other parser) trying to suss structure out of something that's under- or unspecified. That way lies input confusion vulnerabilities.
  - DaiPlusPlus 6y ago
    Well, one example is having a JSON object property that is nominally typed as `number` but a JSON parser/library would also accept a number-in-a-string, so both `{ "foo": "123" }` and `{ "foo": 123 }` would be accepted. Storing numbers inside strings can be necessary if you're encountering JavaScript's 2^56 limit on integers, for example.
    - woodruffw 6y ago
      > Well, one example is having a JSON object property that is nominally typed as `number` but a JSON parser/library would also accept a number-in-a-string, so both `{ "foo": "123" }` and `{ "foo": 123 }` would be accepted. This is a great example of "paving over bad behavior with worse behavior." If JSON is specified to only represent numbers that fit within a JavaScript double, then a correct parser must fail on numeric literals that don't fit into that type. It's up to me as a consumer to interpret strings that represent larger numbers. I've had this exact kind of "helpful" behavior cause potentially exploitable bugs in programs before: a complex system was using more than one JSON parser, and parser Foo would accept numeric inputs that parser Bar would silently fail on (mangling large numbers into garbage). The result was a potential arbitrary read primitive.
      - deathanatos 6y ago
        > If JSON is specified to only represent numbers that fit within a JavaScript double, It isn't / doesn't make that restriction. For example, 10000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000 is a valid JSON value. Python will decode it to an integer with the equivalent value; JavaScript will decode it to "Infinity", as it exceeds the limits of Number. (Despite nowadays having a bigint type that could represent it.) It is possible to write a JSON parser in JavaScript that would handle decoding large numbers to BigInts. Most people just don't bother, as it's pretty rare to need to go above the 2 * 53 limit of JS's number.
- jeff-davis 6y ago
  Everything has to do with security. Especially message formats like JSON. Accepting a non-conforming message could easily lead to injection.
- josefx 6y ago
  I prefer not having to maintain code that is overly flexible with its input. Last time I ran into half a page of workarounds for bad input I spend a day tracking down all affected files and making sure I could either ignore or fix them. The result was a neat little string comparison that didn't have half a dozen unpredictable edge cases.
mytailorisrich 6y ago
It's important to consider each decision. Sometimes it is not fine to be liberal, sometimes it is. In this case, I'd say that an MX record containing an IP address is not a big deal versus an MX pointing to an A record that contains an IP address, so one may consider that it makes sense to favour successful delivery of emails over strict enforcement of the standard and to accept it. That's pretty much what Postel's law is about and why many servers do accept it (though it also makes sense for a server to refuse to be configured that way even if it accepts it externally for robustness). Postel's law is not an anachronistic concept. This sort of design consideration applies everywhere in the real world.

hannob 6y ago

I thought about adding that, I should've... It's widely believed these days that postel's law was a mistake.

chrisseaton 6y ago

Do you want to send people email? Then you'll need to be liberal in what you accept.

tedunangst 6y ago
Why can't the other party be conservative in what they send?
- chokeartist 6y ago
  Go back to reddit. RFCs are standards but real life requires acceptance of divergence from the exact letter of the law.
- chrisseaton 6y ago
  > Why can't the other party be conservative in what they send? Because they don't want to be? Because they don't know that they should be? Because they don't know how? Because they think they are but they're mistaken? Because the specification is ambiguous? Any number of reasons. But you can't control what they do. You can only control what you do. If you want to send an email to them, you need to be compatible with their email server.

jeff-davis 6y ago

I think there's some nuance here. Being liberal in what you accept is good for the growth and connectedness of a network. It's so powerful that it's not so much a suggestion as an inevitability -- if you're trying to be perfectly strict, then you will be excluded from the network and other people will find a way to be included. A party will always be bigger when you are less strict about the invitation/rsvp protocol. But it has obvious downsides. One is that the protocol keeps evolving, because people find novel ways to be non-conforming senders. This means an implementation is never "done". Another is that it becomes so hard to create a new implementation that accounts for all the non-conforming behavior, that the "standard" essentially becomes defined by a few of the big implementations.

JdeBP 6y ago

It is important to remember what Marc Crispin had to say about this: > Actually, Postel's principle is misstated. I knew Jon personally. He never advocated forcing implementations to accept bogus protocol, and it is a perverson of Jon's legacy to claim otherwise. > "Be liberal in what you accept" referred to accepting a wide range of valid protocol, as opposed to accepting only the most common form. If you consider the early protocols, such as Telnet and FTP, it was all too easy to create two compliant and non-interoperable implementations due to each implementation choosing a different subset. -- https://groups.google.com/g/alt.comp.mail.qmail/c/dcwx0Wc7ypU/m/--E_3AQB5QcJ https://groups.google.com/g/alt.comp.mail.qmail/c/dcwx0Wc7yp... > This statement is based upon a terrible misunderstand of Postel's robustness principle. I knew Jon Postel. He was quite unhappy with how his robustness principle was abused to cover up non-compliant behavior, and to criticize compliant software. -- https://groups.google.com/g/comp.mail.pine/c/E5ojND1L4u8/m/iYunDY6h_xMJ https://groups.google.com/g/comp.mail.pine/c/E5ojND1L4u8/m/i...

chrisseaton 6y ago
> "Be liberal in what you accept" referred to accepting a wide range of valid protocol Have you considered that after some point you need to accept the de facto protocol as a valid protocol? If everyone else is using unnamed but extant protocol X, why fight that? What do you gain from it?
DonHopkins 6y ago
Marc "MM Is Not At Fault" Crispin was also the author of the "infamous" RFC 748: Telnet Randomly-Lose Option. https://en.wikipedia.org/wiki/Mark_Crispin https://en.wikipedia.org/wiki/Mark_Crispin https://tools.ietf.org/html/rfc748 https://tools.ietf.org/html/rfc748 4. Motivation for the option. Several hosts appear to provide random lossage, such as system crashes, lost data, incorrectly functioning programs, etc., as part of their services. These services are often undocumented and are in general quite confusing to the novice user. A general means is needed to allow the user to disable these features.