Hmmm, I think the premise of the blog post is incorrect.
It is positing that the correct behaviour is to interpret 010 as octal and so is the value 8.
This is not correct. The octal behaviour comes from the original BSD inet_aton function which explicitly defines and allows Octal (and hex) notation in IPv4 dotted quad notation.
https://man7.org/linux/man-pages/man3/inet_aton.3.html
3.1 IPv4 Dotted Octet Format
A 32-bit IPv4 address is divided into four octets. Each octet is represented numerically in decimal, using the minimum possible number of digits (leading zeroes are not used, except in the case of 0 itself).
I would argue that the Perl functions noted treating 010 as 10 (and not 8) are arguably correct.
But of course, now I have to go audit our use of them.
The simple thing to do, anywhere we permit customers to enter IP addresses, is to block use of leading zeros.
you mean like Skype. There's nothing specially 'email' about this other than it is a bad mix up of a P2P communication app and a supposedly 'trusted' version of SMTP.
took me way too long to find out that the T in TMTP stood for Trusted.
I was looking for protocol descriptions in how this could work. Author said people would be more impressed by code - but I think a protocol spec along with a reference implementation would be useful.
So... what in this proposal isn't fulfilled by a private walled message platform such as Whatsapp, or Signal, or Facebook Messenger?
Nothing here needs this to be 'email'.
And if you're into adding trusted layers with revocation to email, well we have DKIM, client certs, encryption. You can do the 'trusted' enforceability at the application level over the untrusted SMTP network level.
dig txt @vps7.pgregg.com artofwar.pgregg.com |sed 's/" "//g' |sed 's/`n/\n/g' |less