We all think of email as something that just pops up in our mail client (Outlook, Thunderbird etc.) and indeed that is true to a certain extent. But it is important to understand that the transition and structure of emails, is a complex process and there’s always a little more to it at a technical level so we are going to use some analogies to explain the entire process.
Please consider how you would usually formulate a letter, that you would normally take to the post office/mail office or put in a post-box/mailbox.
Writing a letter
Initially a human grabs a piece of paper and begins writing the letter. Most letter writing standards stipulate that when writing a letter, you should write your own name and address on the right-hand side of the letter and the intended recipient on the left-hand side: much like the below
You then continue with the letter and once finished, the letter is placed into an envelope.
You seal the envelope, and then write the intended recipients address on the front of the envelope so the postman knows where the letter is to be sent.
Another thing that a lot of people do, is to write their own sending address on the back or elsewhere on the envelope so that if for some reason, the mailman/postman can’t find the person at the recipients address? The post office will know who to send the envelope back to.
That’s it, believe it or not, that’s the exact same way emails are structured
- We compose the email in our mail client (Paper and Pen) this is called MIME data (Multipurpose Internet Mail Extensions)
- Your mail server puts the email into an envelope with the recipients address on the front of the envelope and the original sender on the back or elsewhere on the envelope and this is called envelope data
Part 2 – Delivery
EveryCloud's Mail man analogy
The next part is how the envelope is delivered to the recipient defined on the front of the envelope. As the mail company needs to find the best route to the recipient addressed on the envelope.
- The mail company looks up the correct route to take to the recipient’s address
- The mail man finds the recipients address but can’t find a mailbox, so knocks on the door
- A person answers the door and the mail man says “I got an envelope for this address; do you want it”
- The person standing at the door says “That depends on who sent it first”
- The mail man looks at the details on the back of the envelope and says “Some company called EveryCloud Technologies LLC and it looks like EveryCloud LLC sending address is, EveryCloud Technologies 300 111 North Market Street, San Jose, CA 95113, United States”
- The person at the door says, “That’s fine, I know EveryCloud Technologies LLC and yes that’s their sending address”
- The person standing at the door then says “Who is the envelope addressed to”
- The mail man looks at the front of the envelope and says “Ms Joan Brown”
- The person at the door says, “OK that’s cool, Joan does live here and the person who answered the door takes the envelope for Joan and signs the mail man’s receipt
So now you know how email transmission works, its virtually the same as the mail man analogy.
Once you have composed your email and your mail server puts the email into an envelope its ready to be delivered this is called the SMTP protocol connection
- Your mail server looks up the correct route to take to the recipient’s address by looking in a global address book database called DNS
- Your mail server finds the correct recipient server but the recipient server doesn’t have an open-door policy and won’t just accept all emails, so the recipient server asks who sent the envelope
- The sending server tells the recipient who the sender is by looking at the envelope and the recipient mail server says “yes I know that EveryCloud Technologies LLC exists at that sending address, that’s fine”
- The recipient server asks who the envelope is addressed to and if the recipient server is happy it accepts the envelope details and says be sure that the letter is inside the envelope
- This is the end of the envelope data and now the sending server is free to send the contents of the letter contained within the envelope and once finished the recipient server provides the sending mail server with a receipt
Exceptions to delivery
- Sometimes the recipient server can say that they looked up the envelope sender and the envelope sender does not reside at the address specified on the back of the envelope and the real envelope sender has also left a global note, that anyone sending envelopes on behalf of the sender should only be sending from the correct address and nowhere else, so all recipients should reject envelopes from the sender that do not match the correct address, so the recipient mail server should stop all further correspondence and tell the mail man / sending server to send the email back to the original envelope sender, this is called envelope sender TXT / SPF checking
- Sometimes the recipient mail server can say that the intended recipient defined on the envelope doesn’t live/exist at the address anymore, maybe because they moved on/no longer work there and the recipient server will tell the sending server to return the envelope back to the envelope sender (return to sender)
There are many reasons why a recipient mail server decides not to accept the details provided from an envelope. But if any recipient mail server refuses to accept the envelope details? The recipient mail server must provide the sending server with a reason why and instruct the sending server to return the envelope back to the original sender with a basic reason for rejection. Much like if your mail is returned to you from the mail man.
All the above happens just by inspecting the envelope details, without looking inside the envelope at the email/letters content. It is only when the envelope details are accepted by a recipient server does the sending server transmit the data contained within the envelope; if the envelope data is refused the sending server never transmits the full contents of the letter contained within the envelope.