[xg15]

I think the point here is that the "lenient" behaviour actually is a lot more complex than one would expect - a compliant mail server would need some special logic to detect hostnames that kinda look like IP addresses and handle them in a special way - without this behaviour being in any way standardized.

E.g., the lenient server would have to treat the value "10.0.0.254" like an IP address but "10.0.0.256" like a hostname that requires DNS resolution.

[abiogenesis]

This is a solved problem and not very complicated. For starters the last DNS label of a hostname cannot be all numbers: https://tools.ietf.org/html/rfc1123#page-13

[garaetjjte]

But name stored in MX doesn't have to be FQDN. I can set up A record with real server IP at 1.2.3.4.example.com, then set 1.2.3.4 in MX for example.com, and it would be perfectly standard compliant record, while it probably would be misinterpreted by servers trying to be "lenient".

[teddyh]

> But name stored in MX doesn't have to be FQDN.

On the contrary, an MX record can only contain a FQDN. If you type “foo” as your target in an MX record in your domain “yourdomain.example”, what actually gets stored in the MX record is “foo.yourdomain.example.”; a perfectly normal FQDN.

[abiogenesis]

That doesn't sound right. A "tcpdump -n -s0 -x -X port 53" shows that the server simply returns "outlook-com.olc.protection", not a FQDN, for "dig mx outlook.com".

[eknshow]

MX records are one of the few records that can contain name compression. I think you'll find you're looking at the labels for "outlook-com.olc.protection" followed by a pointer to "outlook.com." earlier in the message.

EDIT: Yep, wireshark shows the byte sequence c00c following "protection". c00c is a compression pointer to "outlook.com." in the question section of the message.

[teddyh]

I cannot reproduce this behavior; I see the complete FQDN in the reply when I run the commands you specify.

I do, however, note that, in the -X part of the tcpdump output, the periods between labels are not really ASCII period characters, but simply displayed that way by tcpdump; these are in fact byte counts for the label lengths, which, since all the individual labels are below 32 characters in length, makes these bytes ASCII non-printing control characters, which tcpdump then displays as periods.

In another comment, eknshow writes¹ that DNS labels can either be specified inline with a byte count (as described above), or can be a pointer to another set of bytes. Could this be what you are seeing? That is, could the domain part be present, but specified as pointers and therefore not be obvious in the tcpdump output? One would have to carefully examine the raw bytes to be sure.

1. https://news.ycombinator.com/item?id=26217913

[garaetjjte]

Thanks for the correction. Curious if these misconfigured MXs store 1.2.3.4. or 1.2.3.4.example.com.

[abiogenesis]

Fair point. I just tested using tcpdump and the IP address in the response doesn't in fact end with a dot.