Workflow

What happens when you’re sent an email

When a mail client connects to Primmer’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 verification, tests and checks we apply to each email routed through our server.

Everything below occurs in less than 45seconds.

$> telnet mx1.primmer.co 25

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.

$> HELO server_name

Upon receiving the “HELO/EHLO” commands, we start to check the client’s quality by running a few verification that are pretty standard:

  • We check that the IP is not blocked. This can happen when the same IP connects too many times on our server in a short period of time, or when the same IP got too many 500 errors in a short period of time.
    If that IP is blocked, we display an error message (454 4.7.1 Your IP ({0}) has been banned for {1} minutes. Please try again later.) and stop the connection.
  • Then, we check the server_name value given. If it’s an IP, it must match the IP of the client. If it’s a hostname, it must point to the IP of the client. If this fails, we return the error 550 5.7.25 Your IP does not match your hostname..
  • After that, we check that the reverse name for the IP of the client exists, and matches the given hostname. If the reverse (also called PTR) does not match, we refuse the connection with the following message: 550 5.7.25 IP name lookup failed. No valid PTR record found for the given IP address.
  • Finally, we check that the IP from the client is not listed on any DNSBL. We initially were checking for Spamhaus only, but we now also check at Sorbs and Spamcop too.

$> MAIL FROM user@sender.com

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 Primmer, 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.

$> RCPT TO recipient@destination.com

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.

If the email is a bounce

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.

If the sender is connected

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:

  1. We will load the user’s details. If we can’t find it, we will respond with a 550 5.1.9 Relay not permitted. (#id-5.9.2).
  2. If the account is banned, we will respond with a 550 5.2.1 The email account you are using is disabled. (#id-5.9.2b)

Otherwise, the email is to be forwarded.

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:

  1. We will ensure that the domain does exist in our database (to know where to redirect the email to). If we can’t find it, we will return the following error:
    550 5.1.9 Relay not permitted. (#id-5.9.2)
  2. We will then ensure that the destination account is not banned. If that happens, the server will return the following error:
    550 5.2.1 The email account that you tried to reach is disabled. (#id-5.9.2b)
  3. Finally, if no aliases were found to redirect the email to, the following message will be returned to the client:
    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.

$> DATA

This is the core of Primmer, 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 and most likely on a malware distribution spree.

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. Our refused extensions consists of the most adopted extensions used in distributing trojan horses, malwares and spywares.

We do not reject spam messages, rather we label them so you could distinguish them from the legitimate mails.

Now, we verify that the recipient has an active status at Primmer.

We sign the email and check that the forwarding email has valid MX records.

Queue the email, encrypt with AES, then forward to your primary email.

Again, all in 45seconds.

has been added to the cart. View Cart