It can be intimidating. There are all of these terms, POP3, IMAP, SMTP, not to mention DNS, MX/A/SPF/PTR/SOA records, then even deeper all the issues revolving around TCP/IP and the "internet".
In the beginning, as with most things, it was simpler.
Most people had never used a "computer", and those that did didn't use "personal computers". The words "personal" and "computer" was laughable since computers took up entire rooms at that point. What people did have though were terminals that connected to a computer, or a "mainframe". These terminals allowed the user to log in the the mainframe and use all of it's capacity, but over a basic network. This was the computing environment when email was born.
Back then, email addresses were literally username@servername. Those of you familiar with the shell prompt on *nix systems will recognize this format immediately. DNS also did not exist yet, and each server had a "hosts" file which translated the server names into their IP addresses so the servers could communicate.
Gradually, things became more complicated. Networks became interconnected, ultimately turning into the Internet as we know it. "Hosts" files (although still supported by most OSes) became too large and cumbersome for every single computer to keep locally. Nowadays, even copies of the root zone for all the ".com"s in the world take up several gigabytes of data, imagine if you had to update the hostname/IP address of every single server in the world on a fairly routine basis. DNS was born out of necessity. DNS allowed for different servers to be responsible for keeping their own hosts file, and be queried when necessary. DNS's role expanded past the hosts file (nowadays an "A record lookup) to include other record types as well.
As email became more and more prevalent, more and more record types became involved in their delivery. Especially as spam went from being a nuisance to being a insurmountable obstacle, as well as a vehicle for threats, it became more and more necessary to authenticate servers, and then decide if you want to accept their email at all. PTR records and A records came into play as a means of verifying that a server is sending as it says it is, ultimately tying together to create Forward Confirmed reverse DNS.
Beyond distributing the work routing email between servers, there also became the issue of distributed computing. The personal computer meant that users now weren't connecting to a central server to do all of their work. Most work was done locally, with only some connections out to the server when necessary. This meant that email also had to have protocols put in place to retrieve email from the mail server. POP3 initially was the mainstay for this function. PCs, although prevalent, had not reached saturation to the point that one person might work at many different computers. Smartphones were something out of a James Bond movie, and the likelihood that users wanted to receive their work email at home was non-existent. POP3 allowed users to connect in to the mail server and download their email to their local computer. Since the resources of local PCs were mostly under utilized, and the resources on the server could be taxed, this made the most sense.
As we became more connected and less tied down to single PCs, IMAP became the protocol of choice. This protocol allowed users to leave the email on the server, and only download enough information locally to display basic information like the sender, subject, etc. until the message was actually viewed. Even once the message was viewed it still remained on the server so it would be accessible later from other locations. POP3 later introduced an option to leave the messages on the server, but IMAP still is commonly accepted as the protocol of choice for syncing to a server's email store.
So, there you have it. Email didn't just get created as it is now. A lot has changed since RFC 821 (released in 1982!) and it didn't all change at once. Hopefully if you understand step by step the issues we faced and what protocols were instituted or used to remedy those issues it won't just be a ton of buzz words and confusing acronyms, but a fundamental understanding of what solution fits what problem, even today.
--TEA
