* * * * *

                  It's amazing that email even works at all

> In general, an implementation should be conservative in its sending
> behavior, and liberal in its receiving behavior. That is, it should be
> careful to send well-formed datagrams, but should accept any datagram that
> it can interpret (e.g., not object to technical errors where the meaning is
> still clear).
>
> “RFC- 760 [1]”
>

That is otherwise known as Postel's Law [2] and I contend that Law (which
really isn't a “law-law” per se but more of a suggestion) has caused more
bugs and interroperability issues than it prevented.

Obligatory Sidebar Links

* Quetzalcoatal: Why email is hard, part 1: architecture [3]
* Quetzalcoa tal: Why email is hard, part 2: internationalization [4]
* Quetzalcoatal: Why email is hard, part 3: MIME [5]
* Quetzalcoatal: Why email is hard, part 4: Email addresses [6]
* Quetzalcoatal: Why email is hard, part 5: mail headers [7]
* Quetzalcoatal: Why email is hard, part 6: today's email security [8]
* Quetzalcoatal: Why email is hard, part 7: email security and trust [9]
* Quetzalcoatal: Why email is hard, part 8: why email security failed [10]


If you read the linked aritlcles (and yes, it's quite a lot of read) it
becomes apparent (to me) that a lot of the issues causing issues can be
directly laid at the feet of Postel's Law (and the rest to the insane design
of Internet headers that came out of the “we want theoretical mathematical
purity and complete flexibility in what we allow in our parsers!” school of
thought popular in the 60s and 70s—which is why The Dragon Book [11] is so
hard to understand and why parsers are thought of as “things mere programmers
are not meant to write” but I digress). Parsing email (heck, parsing email
addresses) is difficult because the early standards were too hard to follow,
and because of that, most programs were too liberal in what was accepted to
the point where it may be impossible to have a properly formed email message
[12] that follows all the relevant RFC (Request For Comments) [13]s.

I'm also reminded of a conversation I had with my manager at The Ft.
Lauderdale Office of the Corporation. As I was writing “Project: Sippy-Cup
[14]” my manager kept telling me to stop being so pedantic in parsing SIP
(Session Initiation Protocol) [15] messages because it was causing issues
with The Monopolistic Phone Company. Even though technically we were right
and following the specifications, we were dealing with The Monopolistic Phone
Company (motto: “We don't have to care!”) where what they do is right (specs
be damned!). I kept complaining about it (“What's the point of a
specification if no one follows it?”) but nope—I had to be more liberal in
what I accepted (specs be damned!).

> 4.5 Robustness
>
> A well-designed protocol is robust.
>
> Robustness and efficiency are often at odds. For example, although defaults
> are useful to reduce packet sizes and processing time, they tend to
> encourage implementation errors.
>
> Counter-intuitively, Postel's robustness principle ("be conservative in
> what you send, liberal in what you accept") often leads to deployment
> problems. Why? When a new implementation is initially fielded, it is likely
> that it will encounter only a subset of existing implementations. If those
> implementations follow the robustness principle, then errors in the new
> implementation will likely go undetected. The new implementation then sees
> some, but not widespread deployment. This process repeats for several new
> implementations. Eventually, the not-quite-correct implementations run into
> other implementations that are less liberal than the initial set of
> implementations. The reader should be able to figure out what happens next.
>
> Accordingly, explicit consistency checks in a protocol are very useful,
> even if they impose implementation overhead.
>

“RFC-3117: On the Design of Application Protocols [16]”

And yet, when I wrote SPCDNS [17], I was very strict in what I accepted back,
to the point of sending an error if the one last reserved bit in the DNS
(Domain Name Service) header isn't zero [18]. And a funny thing about that—
again, at The Ft. Lauderdale Office of the Corporation, such strictness found
implementation issues in other components that didn't use SPCDNS.

Go figure.

The email specifications have been tightened up over the years, but they
still require the ability to handle older emails. But given that RFC-724 [19]
(the RFC (Request for Comments) that started us down the crazy parsing rules
for email) was thirty-eight years ago, you'd think that some of the crazier
parsing rules would be dropped. But no, Postel's Law and all that.

Sigh.

[1] https://www.ietf.org/rfc/rfc760.txt
[2] https://en.wikipedia.org/wiki/Robustness_principle
[3] http://quetzalcoatal.blogspot.com/2013/09/why
[4] http://quetzalcoatal.blogspot.com/2013_10_01_archive.html
[5] http://quetzalcoatal.blogspot.com/2013/11/why
[6] http://quetzalcoatal.blogspot.com/2013/12/why
[7] http://quetzalcoatal.blogspot.com/2014/01/why
[8] http://quetzalcoatal.blogspot.com/2014/05/why
[9] http://quetzalcoatal.blogspot.com/2014/08/why
[10] http://quetzalcoatal.blogspot.com/2015/01/why
[11] https://www.amazon.com/exec/obidos/ASIN/0321486811/conmanlaborat-20
[12] https://www.youtube.com/watch?v=JENdgiAPD6c
[13] https://en.wikipedia.org/wiki/Request_for_Comments
[14] gopher://gopher.conman.org/0Phlog:2014/03/05.1
[15] https://en.wikipedia.org/wiki/Session_Initiation_Protocol
[16] https://www.ietf.org/rfc/rfc3117.txt
[17] https://github.com/spc476/SPCDNS
[18] https://github.com/spc476/SPCDNS/blob/1c4e2ab1e6ba7f5d499ffca20b5b548e7
[19] https://www.ietf.org/rfc/rfc724.txt

Email author at [email protected]

You are viewing proxied material from gopher.conman.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.