You should have a Nagios Core 4.0 or newer server with at least one host configured already. We'll use the example of troy.example.net, a host defined in its own file. You should also understand the basics of how hosts and services relate, which is covered in the recipes in Chapter 1, Understanding Hosts, Services, and Contacts.

Checking the connectivity for the required services on the target server is also a good idea to ensure that the automated connections the monitoring server will be making on the appropriate protocols and ports will actually work as expected. For the plain unencrypted mail services, this could be done via Telnet to the appropriate ports. For SMTP:

$ telnet marathon.example.net 25
Trying 192.0.2.34...
Connected to marathon.example.net.
Escape character is '^]'.
220 marathon.example.net ESMTP Postfix

For POP:

$ telnet marathon.example.net 110
Trying 192.0.2.34...
Connected to marathon.example.net.
Escape character is '^]'.
+OK Hello there.

And for IMAP:

$ telnet marathon.example.net 143
Trying 192.0.2.34...
Connected to marathon.example.net.
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE...

For secure services, one possibility for checking is by using the openssl(1) client. For SMTPS on its classic port number 465:

$ openssl s_client -connect marathon.example.net:465
CONNECTED(00000003)
...
220 marathon.example.net ESMTP Postfix

For POPS:

$ openssl s_client -connect marathon.example.net:995
CONNECTED(00000003)
...
+OK Hello there.

And for IMAPS:

$ openssl s_client -connect marathon.example.net:993
CONNECTED(00000003)
...
* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE...

If you prefer, you could instead use a network scanner such as Nmap to test if the ports are open and responsive.

Once we've verified connectivity for the mail services that we need and the host itself is being configured and checked in Nagios Core, then we can add the appropriate service checks.

We can add unencrypted mail service checks for SMTP, POP, and IMAP services on our host as follows:

With this done, three new service checks will start taking place, with the appropriate contacts and contact groups being notified when an attempt to connect to any of the services fails. Details for these services will also become available in the Services section of the web interface.

The preceding configuration adds three new service checks to the existing marathon.example.net host:

In all three cases, the connectivity and responsiveness of the service is checked and determined to be OK if it returns appropriate values within an acceptable time frame.

It's important to note that this configuration that we just defined doesn't actually send or receive any e-mail messages; it merely checks the basic connectivity of the service and whether it answers simple requests. Therefore, just because the status is OK, it does not necessarily mean that e-mail messages are being delivered correctly—it just means that the services are responding.

If it's necessary to check the secure SSL/TLS versions of each of these services, the configuration is very similar, but it requires a little extra setup beforehand. This is because, although plugins to check them are included in the Nagios Plugins setup, they are not configured to be used as commands. Note that this may well change in future versions of Nagios Core.

To add the appropriate commands, the following stanzas could be added to the commands configuration file, normally /usr/local/nagios/etc/commands.cfg:

define command {
    command_name  check_ssmtp
    command_line  $USER1$/check_ssmtp $ARG1$ -H $HOSTADDRESS$
}
define command {
    command_name  check_spop
    command_line  $USER1$/check_spop $ARG1$ -H $HOSTADDRESS$
}
define command {
    command_name  check_simap
    command_line  $USER1$/check_simap $ARG1$ -H $HOSTADDRESS$
}

With this done, the following service definitions can then be added to the appropriate host, either replacing or supplementing the checks for the unsecured services. They are just the same as the unsecured versions, except an s is added to the service_description and to the check_command:

define service {
    use                  generic-service
    host_name            marathon.example.net
    service_description  SSMTP
    check_command        check_ssmtp
}
define service {
    use                  generic-service
    host_name            marathon.example.net
    service_description  SPOP
    check_command        check_spop
}
define service {
    use                  generic-service
    host_name            marathon.example.net
    service_description  SIMAP
    check_command        check_simap
}

Finally, note that if you are managing more than one mail server running one or more of these services, it's good practice to apply the service to a hostgroup containing all the applicable hosts, rather than creating new service definitions for each one. See the recipe Running a service on all hosts in a group in Chapter 1, Understanding Hosts, Services, and Contacts, to learn how to do this.