Whenever one wants to ascertain whether a certain web site is online, the procedure is simple: send an HTTP request to the server, look at the result and, provided you get something reasonably sensical, you can assume all is well. This, of course, can be easily automated, even if only with a bit of curl and cat magic, which jumpstarted the creation of many, many web sites monitoring services on the web.
Of course, there can be a lot more to it, including geographically redundant testing servers, comparison of strings, of downloaded pages, etc… The fundamentals, though, will always be the same: poll the server and see whether it replies.
When it comes to e-mail monitoring, though, the same does not hold true. After all, telneting into a mail server onto a specified port is easy and, much like with sites, allows to quickly ascertain that the server is online.
There is however a fundamental difference: e-mail is a much more complex service and many issues can happen between between the point a message reaches a server and the point it is delivered: the server can be misconfigured, spool messages wrongly, permissions of the various mailboxes can be set wrong, a malformed message can wreck havoc with a user’s client… Merely knowing that my sever is ready to swallow mails tells me very little as to whether I, ultimately, will see what arrives into my local inbox or webmail interface.
Not too long ago, a weird PayPal e-mail caused Mail.app to go bonkers and poof, users were not seeing e-mail coming in any more. Nothing was deleted but it sure was invisible until one cleared the PayPal offender through some web interface or another client. (Whether that was Mail.app’s fault or PayPal’s or the interaction of the two former with some some servers I do not know and, actually, that doesn’t change much.)
So, how would you go and test your inbox?