No this is not a show on the Discovery Channel for you "How it works" fanatics nor is this a slap in the face to those who know how to type and hit send in a simple email client. This is more of a behind the scenes look at the inter-workings of email itself. I had originally hoped that my good friend and colleague, Greg Kraios, was going to have the time to partner with me on this topic, but was sad to find out that he can no longer participate due to some other pressing issues. I do want however to give him credit for helping me flush this idea out and writing the first post of what I hope to be a good/quick series.
As some of you know, I have been in email now for around fifteen (15) years and have some great expediences and understandings of email. Please be patient with me in this series, but feel free to post suggestions/comments for other posts and also corrections as you see fit or if you want to take a topic on let me know and I will post it for you. Also understand that I am not trying to overload the audience with all the mundane details of email. I know some of these posts are short…
At first, I wanted to discuss bounces and then we realized that there is too much information to cram into one (1) post. Therefore, we decided to break it into four (4) sections:
- How MTAs (Mail/Message Transfer Agents) Communicate
- What is a “Bounce?”
- How MTAs Handle Bounces
- How Bounces Can Affect a Subscriber’s Status
With that said, let’s start with how MTAs communicate. MTAs communicate and have “conversations” similar to human beings. For example, let’s say that you and I meet in a public place. We might shake hands or hug, one person says hi, the other says hi in return, we ask how the family is doing, the other person says GREAT, etc. (it’s a back and forth conversation or interaction). It's usually sane and polite, but sometimes it also can be met with "resistance" or a level of "cautiousness".
Much like regular postal mail, email has 2 distinct parts – the “envelope” headers and the “message” headers. The envelope headers are used to distinguish where the message should be delivered. Let’s make a visual comparison:
123 Main St.
Dallas, TX 12345
.com = 12345 (or the zip code)
domain = Dallas, TX (city and state)
jsmith = John Smith (the recipient’s name or identity)
*If the domain (or portion after the @ sign) was subdomain.domain.com, the subdomain portion would equal 123 Main St. (or the street address); however, you will likely not see many email addresses which exist in this format.
As you can see, these parts of an email address are used to tell the MTA where to send the message (which happens behind the scenes). The MTA will use DNS (Domain Name Service) to determine:
- Does the domain exist?
- If so, who handles its mail (it might be handled internally, it might be handled by their ISP, it might be routed to their anti-spam provider, etc.)?
- If not, what do I do with this message (depending on the error code or bounce returned)?
- Am I allowed to deliver the message addressed to this user/subscriber/person?
The message headers are actually rolled into the actual message and include items such as From, To, Subject, etc. Based on standards and formatting, our email client knows how to parse (or separate) these headers from the message body (much like if we received a letter in which the salutation, message body, etc. were all rolled together, we would know where things should be separated).
Getting back to the actual communication, the main difference between human and MTA conversations is that MTAs communicate in the form of numerical codes which are (primarily) composed of 3 types:
- 2xx – Accepted
- 4xx – Temporary Failure
- 5xx – Permanent Failure
*It is important to note that these are 3 digit codes. The “xx” portion is used to designate the other digits in the code. These numbers are designated to provide more granular information; however, we are only concerned with the 1st digit of the code at this time.
These codes serve to ensure the synchronization of requests and actions between the email client and the MTA/s. Every request or command MUST generate exactly one reply. The 1st digit of the 3 digit response code will determine the next action taken by the MTA. In the next article, I will expand on these codes, additional codes that can sometimes be used and how industry experts are collaborating on making things better to reflect situations that are common occurrence in today’s email environment.
Don't Just Send, Deliver!