When a mail client connects to ImprovMX’s servers, we run a complex set of checks in order to validate the sender, the email “envelope” and its content.
In order to be fully transparent, we share here all the verifications, tests and checks we apply for each email we receive and what are the actions that result.
You can also read about which error codes are returned by our servers, and what do we log for a deeper understanding of our architecture.
This description of what happens will be split by each command run as the SMTP standard. We won’t talk about Extended SMTP because commands like STARTTLS are standard and we don’t do more than what is recommended in the RFC.
The first thing that occurs is a connection to our server. When this occurs, we initiate the session for that specific connection and already assign the IP of the client along with a timer to calculate the overall duration of the exchange. Not much more is done at this point.
Upon receiving the “HELO/EHLO” commands, we start to check the client’s quality by running a few verifications that are pretty standard:
454 4.7.1 Your IP ({0}) has been banned for {1} minutes. Please try again later.) and stop the connection.550 5.7.25 Your IP does not match your hostname..550 5.7.25 IP name lookup failed. No valid PTR record found for the given IP address.The email provided at this point has many names: Return-path, 5321.MailFrom, Bounce email, Envelope from, etc. This section of Wikipedia explains them very well.
As a matter of consistency, we’ll use the name “return-path” when mentioning this value.
At ImprovMX, we don’t run any checks for the Return-path at this step, they will be done at the DATA level.
The Return-path value is used to send back a notification when the delivery of the email fails later. But it’s worth noting that in some cases, that value can be “<>”. This is often used when sending back a bounce delivery notification, since the sender – the mail server – doesn’t expect a response back.
As a Mail client sending an email, it’s possible to send multiple emails at once. This is often the case when you send an email with CC/BCC that have the same destination server.
When we receive an RCPT command, we check that the email is valid and standard.
We verify that this bounce is legitimate by ensuring it really came from us. This is done by checking the hash placed by our service in the return-path email used when sending the original email.
This guarantee that we forward bounces that are legitimate, and protect us from backscatter issues.
We’ll consider that the email is being sent. In that case, we will allow up to 50 recipients for that same email and will run a few tests:
550 5.1.9 Relay not permitted. (#id-5.9.2).550 5.2.1 The email account you are using is disabled. (#id-5.9.2b)552 5.2.2 You reached your daily sending quota. Please try again tomorrow.In that case, we will allow for up to three recipients max. After that, the server will return the following error:
451 4.5.3 Too many recipients.
The recipients will have to be on the same domain (right part of the @). If that’s not the case, the server will return the following error:
451 4.1.2 Please RCPT to the same domain.
Then, the following tests will be run on the destination domain:
550 5.1.9 Relay not permitted. (#id-5.9.2)550 5.2.1 The email account that you tried to reach is disabled. (#id-5.9.2b) 552 5.2.2 The recipient you are trying to contact is over daily incoming mail quota. Please try again later.550 5.1.1 The email account that you tried to reach does not exist. Please try double-checking the recipient's email address for typos or unnecessary spaces.With the list of forwarding email loaded for a specific alias, and for each destination emails
Note that if you send an email to more than three persons that have their domains managed by ImprovMX, your email client should be able to handle this case and will do one session per domain.
This is the core of ImprovMX, where all the most important work happens.
It makes sense because, at this point, we have the complete elements in hand. We have the envelope (as its name describe, this is the wrapper of the actual email, which include the sender, the recipient, and who is delivering it to us), and the email’s content (which include the message but also the headers).
The first thing we check is if the email is a bounce or a delivery report. These need special handling so we process them specially, first.
Then, we verify that the headers of the email contains the From field. This is not required per se, and some email service accepts emails without a From field, but following the new DMARC system, a From header is important for domain alignment (a specification of DMARC).
Moreover, we verify that the From header is present AND valid as per the RFC standard.
Note: The From in the email’s header can (and often is) different from the Return-path.
That’s also the reason why we don’t check the “MAIL FROM” command before: Doing the check in the DATA section allows us to have a treat the right From and verify domain alignment.
Next, we ensure that this email was not forwarded too many times. For instance, if your mail client connects to a server, that then connects to a server which then deliver to the recipient, that’s alright. But if one server connects to another, that connect to another, and on and on and on, the email could transit forever.
This can be easily the case in our own service if someone setup to alias that redirects to the other: infinite loop (yay!). In this case, the email will be dropped after a few forwards.
After that, we check for any attachments and reject the email if one of the attachment is in the list of refused extensions.
Now, we verify that the recipient is both at ImprovMX and not over quota.
File size, based on plan
SPF
DKIM
DMARC
We append a few headers (X-Forwading-Service, etc)
We sign the email with DKIM
SpamAssassin
Check that the forwarding email has valid MX records
Queue the email