Why not fix Courier? Seems easier than trying to convince others to change how they configure their DNS. Be forgiving in what you accept and disciplined in what you send.
If you don’t follow the standards things might fail. That’s not someone else’s fault, it’s your fault.
"Be liberal in what you accept, and conservative in what you send."
Courier is failing to be liberal in input-handling.
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.
Storing numbers inside strings can be necessary if you're encountering JavaScript's 2^56 limit on integers, for example.
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.
It isn't / doesn't make that restriction. For example,
10000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000
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.
The actual RFC language[1]:
> This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision.
Accepting a non-conforming message could easily lead to injection.
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.
> 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/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/i...
https://en.wikipedia.org/wiki/Mark_Crispin
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.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?
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.
It's widely believed these days that postel's law was a mistake.
Then you'll need to be liberal in what you accept.
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.
Because they can't send email when they follow the standard?
What are you trying to achieve? Following a standard for the sake of it, or are you actually trying to send email?
And what's the point or use of a standard that people aren't following? What's the point of following such a standard?
What the point is of the standard requiring you to use a name instead of an IP address is a reasonable question but not the same question as whether you should follow the standards.
Note this is a standard made by people who knew what they were doing and it has stood for 35 years. There’s always room for improvement but it would be a bit silly to think you can just handwave it away with arguments you can come up with in a few seconds. There is bound to be a catch.
In this case the catch of course is that there are more address types than IPv4 addresses, so the system requires you to specify what kind of address you are talking about. The mechanism for that is the A record, which only holds IPv4 addresses.
In DNS, there is actually a single record type that should hold a physical address, for each supported protocol address. We have A records for IPv4, and AAAA records for IPv6. Anything else should be a domain name.
Adding both IPv4 and IPv6 support to every other record type would be a waste.
Note: ignoring other protocol addresses above to keep it focused on what is currently is large scale use.
https://tools.ietf.org/html/rfc974 (Page 3)
In general, we expect systems to be forgiving.
It's the author's "fault" they can't send mail to those destinations when others can.
When you see an MX record with the value 1::8, how should you interpret it? Is it a malformed value? Is it an IPv6? Is it some other protocol that you don't know about?
DNS clients shouldn't have to guess. Instead, the MX record should point to a domain name, and the client should look up the corresponding address record for the protocols it knows how to speak (A or AAAA or whatever else will exist).
https://en.wikipedia.org/wiki/No_true_Scotsman
To be precise instead of tautological (which you should be when arguing the pedantic nuances of networking protocols), when you use a word like "physically", you're implying that it has something to do with the "Physical Layer", and that there could not exist another networking protocol in the same universe that DID allow IP addresses in MX records, because it's forbidden by the physical laws of nature, not by the logical laws of networking protocols.
It's literally like using the word "literally" to mean "figuratively". (And I mean "literally" literally, not figuratively.)
Obviously it's not physically impossible, because sometimes people do it, and sometimes it even works.
I will agree that it's unwise and scandalous and logically impossible, just not "physically" impossible, and that a better explanation is needed. That's probably why the first reply to your comment was "Out of curiosity though: why is it like this?"
A networking protocol that operates faster than the speed of light, or sends information backwards in time, could be physically impossible, according to the currently known laws of physics.
Although it would be super cool and convenient if you could specify a "Date:" field in the past or the future to send email at the specified time.
A series of statements needs to be lies in order to qualify for that term, and you totally refused to provide any evidence and failed to prove anything I said was not true, but it was. The fact that Eric S Raymond has provably and publicly said so many many many racists things over the more than three and a half decades that I've personally known him does not make me or WikiQuotes literally quoting a few of them a "Gish Gallop".
https://en.wikiquote.org/wiki/Eric_S._Raymond
Those were all actual ESR quotes, despite your denials and overconfident claims that I was lying and that you could rationalize and explain away them all. Please, in the future, chose your words and heros more carefully, and stick to the facts, instead of making stuff up, and please stop lying and white-knighting in the defense of a virulent racist (and sexist Harvey Weinstein defender) and linking to his personal fundraising page.
Nobody "canceled" you -- quite the opposite: I tried to engage you in a conversation, gave you the facts and citations, asked you to explain yourself, and prove what you claimed, and YOU decided to refuse, despite the fact that you glibly brushed off all his racist statements and wrongly called me a liar by saying "I’m sure all your claims can be either explained as inconsequential or disproven as false" in his defense.
When you lie down with dogs, you get up with fleas.
It's nice that it's the other person's fault. Still doesn't make your mail arrive.
Instead of trying to parse the address and guess what protocol it might be, DNS tries to make that unambiguous: you ask it for the A or AAAA records for a domain name you are interested in, and you know for sure that you are getting an IPv4 or IPv6 address respectively.
The only clean alternative would have been to make an MXMXMXMX record type to hold a domain name OR an IPv6 address.
It isn't "broken".
> I did a quick scan of the Alexa Top 1 Million list. Currently around 0,06 % are affected
Only affects a small minority of mailservers, and even then only 0.06% of domains.