> I happen to use a mail server that is less forgiving (Courier), and every now and then I cannot send a mail due to this. It’s rare, but it does happen. If your mail server has such a configuration you may not receive some legitimate e-mails.
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.
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.
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.
> 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.
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.
> 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.
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.
You're absolutely right about that, and that's even worse than I had remembered! Not only can two parsers not be trusted to have equivalent acceptance contracts (in the absence of bugs), but they can correctly disagree on the acceptance of a single input!
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.
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.
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.
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.
> 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.
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.
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.
> 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.
No, it’s the other way around. You can’t receive mail from standards-compliant servers if you don’t follow the 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.
Domain names and IP addresses are interchangeable almost everywhere else right? There already is a standard here and the spec is breaking it, not the other way around.
Because most dns server software doesn’t accept it. There is no reason to put an IP address in a CNAME record, it’s not easier or more convenient, you just need to change the CNAME record type to ‘IN A’.
DNS records are statically typed. An “A” record can only contain an IPv4 address, just like a variable of type “int” in the C programming language only can contain an integer. An MX record, just like CNAME, SRV, and others, can only contain a domain name, not an IP address of any kind. You can input a domain name which looks like an IPv4 address, but this is simply a syntax overlap; it happens to be that the normal textual representation of IPv4 addresses are also valid syntax for an unrelated domain name. Tellingly, the syntax for IPv6 addresses does not overlap with domain names, so you cannot make this error with IPv6 addresses.
So an A record should also hold domain names? Or IPv6 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.
There's a de jure standard (the RFC) and a de facto standard (the real world). The question then becomes whether you want to be right or whether you want to be able to send mail.
>> There is one other special case. If the response contains an answer
which is a CNAME RR, it indicates that REMOTE is actually an alias
for some other domain name. The query should be repeated with the
canonical domain name.
Because DNS works with many kinds of addresses, not just IPv4, and you shouldn't have to guess what type of address a record holds based on format.
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).
That is the best most irrefutable answer for why it's impossible I've seen so far. Better than "because it's physically impossible". (Is it electrically prevented at the Physical Layer, otherwise the router would catch fire if you tried to do that?)
To be precise, it’s logically impossible, since MX records are defined by the relevant standards to consist of a number of bytes which are to be interpreted as a priority integer followed by a series of DNS domain name labels. There is no defined way for an MX record to contain an IP address. You could make up some such way, but then it wouldn’t be an MX record as commonly defined, it would be your private extension of the standards.
"The standard definition tells you not to" isn't as deep and complete and useful an explanation as "the standard definition tells you not to, because networking protocols should not have ambiguities or make guesses".
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.
So was the term "Gish Gallop" that you wrongfully accused me of, so you still owe me a "mea culpa" for that too.
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".
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.
You're missing something: IPv4 is not the only type of physical address supported by DNS. There is also IPv6, and historically there were others.
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.
You are missing a lot, including the fact mentioned several times in this discussion that the data portion of an MX resource record simply is not an IP address. The data structure is a wire-format domain name (plus an integer). Even in BIND's "zone" file format, a human-format IP address isn't a fully qualified human-format domain name. But yes, the DNS RFCs are not as good as they could have been. However, you have reached that conclusion by the wrong route. (-:
I’d make the same argument, especially when it concerns smtp or dns as both standards are full of contradictions, caveats, and errata and there are plenty of real world implementations that deviate from the specs.
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.