Postel's Law

postels_law.md

The biggest mistake is treating Postel's Law as a suggestion. It's a law, just like Moore's Law, Hyrum's Law, Goodhart's Law, and the Law of Diminishing Returns.

In an ecosystem of interoperating implementations, accepting sloppy input and emitting strict output is the locally-optimal strategy to avoid your implementation being seen as the direct cause of problems. This is contingent on two "facts":

• The upside to accepting sloppy input is immediate, while the downside is far away and diffuse.
• Accepting sloppy input is a one-way ratchet. It's easy to add, sometimes, if it happens to be easy to do it with your current implementation strategy. But, once people start relying on it, it's very painful to remove.

This is a collective action problem, because, in an ecosystem where every other implementation is strict on both emitting and consuming input, the locally-optimal strategy is still Postel's Law, as long as bugs that are easy to work around exist. Advising individual development teams that "Postel's Law is Bad" won't help—their users will abandon them in favor of competitors that Just Work.

Postel's Law causes long-term issues, but that's small comfort if the market stays irrational longer than you stay solvent.

Fixing it requires fixing one of the two "facts". Either:

• Accepting sloppy input needs to cause immediate downsides. For example, mail servers validate HELO lines because (in the past) it works against spammers. Some forms of certification can also require you to reject sloppy input.
• Or breaking changes need to be tolerable. For example, Signal can deploy "breaking changes" to their protocol whenever they need to because they retain centralized control over the whole system. Migration-script upgrades like Abseil and cargo fix also make breaking changes less painful.

See also: https://datatracker.ietf.org/doc/html/rfc9413

https://en.wikipedia.org/wiki/Bitsquatting

EM interference can, sometimes, reach the internet protocol level.

However, that sort of thing is usually dealt with by making it stricter, especially with checksumming, not by making it more tolerant.