In our previous post we discussed the e-mail round-trip monitoring level as the best solution for prevention of e-mail outages. Today we will dig a little deeper and see the possible scenarios which the e-mail round-trip can follow.
Let me clarify what the e-mail round-trip service actually does:
First, our monitoring agent connects to the SMTP server that you have specified or retrieved automatically through the MX records and sends a test message. By doing this, our system verifies that your SMTP server is working properly. Next, the agent will try to log into the POP3/IMAP server and retrieve the message. If the message is received, the test will be considered successful and the message will be deleted. If, on the other hand, the message is not found in the mailbox after a certain period, which is configurable and usually between 5 and 15 minutes, the check will be considered a failure and you will be alerted.
Depending on your system and your goals there can be different scenarios.
Default configuration
In this case the goal of the monitoring is clear – you want to keep an eye on the usual mail receiving procedure. For this purpose the monitoring agent communicates with your SMTP and POP3/IMAP clients directly.
But what if you cannot grant or don’t have access to the POP3/IMAP from the outside? Our suggestion – use a WebSitePulse mailbox. Here is how this will look:
This is the best option for monitoring the whole send-receive process if you have a Microsoft Exchange Server or don’t want to open your IMAP/POP3 to the outside.
The difference in the setup here is that when the test message goes to the POP3/IMAP mailbox on your end it should be automatically forwarded to a WebSitePulse mailbox. The latter is then checked by our monitoring agent and if the message is received, the test is considered OK.
If your goal is to monitor authenticated SMTP servers and forwarders (relays), pay attention to round-trip scenario 3:
You can see that in this scenario the second SMTP server (SMTP 2), NOT the first SMTP, is responsible for the domain of the POP3/IMAP. So, the transaction starts by sending a message to the first SMTP server which is then forwarded to SMTP 2. From there the test e-mail is dispatched to the POP3/IMAP mailbox and our monitoring agent tries to retrieve it to verify the success of the check.
And what if you don’t want to monitor your own SMTP directly?
In this case our system communicates with your POP3/IMAP only. Our monitoring agent sends the message via the local mail-sending program. The message goes to the WebSitePulse mail server (WSP SMTP) and from there it is sent to SMTP2 (responsible for the client’s domain). As in the previous scenario the test e-mail is sent to the POP3/IMAP mailbox and our monitoring agent tries to retrieve it and thus complete the transaction.
The final scenario shows the case where you do not want to directly monitor the SMTP and/or the POP3/IMAP servers.
As you can see, in this case the monitoring agent communicates with the WebSitePulse POP3/IMAP only. However, while this type of monitoring setup can still guarantee that your e-mail process is working, the procedure itself is not monitored and the response times of your servers cannot be recorded.
So, now that you know how e-mail round-trip works, why don’t you give it a try here?
