POP3 is a very popular protocol for retrieving e-mail messages from an e-mail client application. It uses TCP port 110 for unencrypted connections and port 995 for SSL encrypted connections. Nagios offers means to verify both unencrypted and encrypted POP3 connections that can be made. Even though POP3 is the most popular e-mail retrieving protocol, another protocol is also very common. IMAP is a protocol that is used to access e-mails on remote servers rather than download them to the user's computer. It uses TCP port 143 for standard connections and port 993 for encrypted connections over SSL. The following plugins are based on check_tcp (and are actually symbolic links to check_tcp). The syntax is identical to the original plugin:

check_pop|check_imap -H host -p port [-w <warning time>] 
         [-c <critical time>] [-s <send string>] 
         [-e <expect string>] [-q <quit string>] 
         [-m <maximum bytes>] [-d <delay>] 
         [-t <timeout seconds>] [-r <refuse state>] 
         [-M <mismatch state>] [-v] [-4|-6] [-j] 
         [-D <warn days cert expire>[,<crit days cert expire>]] 
         [-S <use SSL>] [-E] 

The only difference between this plugin and the standard command is that the port parameter can be omitted for this plugin, and in this case, a default value for both non-SSL and SSL variants is chosen. In order to enable connection over SSL, either pass the --ssl option, or invoke the command as check_spop instead of check_pop and check_simap instead of check_imap.

The following are sample command definitions that check for a daemon listening on a specified host and verify that a valid POP3 and IMAP welcome message can be retrieved:

  define command 
  { 
    command_name  check_pop 
    command_line  $USER1$/check_pop -H $HOSTADDRESS$ 
  } 
  define command 
  { 
    command_name  check_imap 
    command_line  $USER1$/check_imap -H $HOSTADDRESS$ 
  } 

However, it seems more useful to verify the actual functionality of the server. It is, therefore, reasonable to also verify that a predefined username and password is accepted by our POP3 daemon. In order to do that, the example uses -E to escape newline characters, -s to send commands that authenticate, and -e to verify that the user has actually been logged in. In addition, the -d option is passed to indicate that the command should wait a couple of seconds before analyzing the output. If this option is not passed, the command will return after the first line. The following examples should work with any POP3/IMAP server, but it may be necessary to customize the response for your particular environment:

  define command 
  { 
    command_name  check_pop3login 
    command_line  $USER1$/check_pop -H $HOSTADDRESS$ -E -s 
      "USER    $ARG1$
PASS $ARG2$
" -d 5 -e "logged in" 
  } 
  define command 
  { 
    command_name  check_imaplogin 
    command_line  $USER1$/check_imap -H $HOSTADDRESS$ -E -s 
       "pr01  LOGIN $ARG1 $ARG2$
" -d 5 -e "pr01 OK" 
  } 

The value that is passed in the -s option is a string with two lines for POP3 and one line for IMAP4. Each line ends with a newline character ( ) that are sent as newline characters because of using the -E option.

For POP3, these lines are the standard protocol commands to log in to an account. The POP3 server should then issue a response stating that the user is authenticated, and this is what the command is expecting to receive,because of the -e option. In addition, $ARG1$ and $ARG2$ will be replaced with a username and a password that is supplied in a service check definition, which allows different usernames and passwords to be specified for different checks.

With IMAP4, there is only a slight difference in the protocol dialect. IMAP requires the sending of only a single LOGIN command in order to authenticate. As for POP3, $ARG1$ and $ARG2$ will be replaced with a username and password. In this way, it is possible to set up checks for different users and passwords with a single command definition. The pr01 string can be replaced by any other text without spaces. It is necessary with the IMAP4 protocol to bind requests with answers provided by the server.

SMTP is a protocol for sending e-mails—both from a client application as well as between email servers. Therefore, monitoring it is also very important from the point of view of availability.

Nagios standard plugins offer a command to check whether an SMTP server is listening. Unlike checks for POP3 and IMAP, the command is available only for this particular protocol and therefore, the options are a bit different:

check_smtp -H host [-p port] [-4|-6] [-e expect] [-C command]
               [-R response] [-f from addr] 
               [-A authtype -U authuser -P authpass] [-w warn] 
               [-c crit] [-t timeout] [-q] [-F fqdn] [-S] 
               [-D warn days cert expire[,crit days cert expire]] [-v]
  

The plugin accepts most of the standard options. Additional ones are as follows:

The port can be omitted and defaults to 25. In this case, the -S option also behaves a bit differently and uses the STARTTLS function of SMTP servers instead of connecting directly over SSL. A basic SMTP check command definition looks like this:

  define command 
  { 
    command_name  check_smtp 
    command_line  $USER1$/check_smtp -H $HOSTADDRESS$ 
  } 

Most of these options are similar to the standard send/expect parameters in the way they work. Therefore, it is quite easy to create a more complex definition that verifies the sending of e-mails to a specific address:

  define command 
  { 
    command_name  check_smtpsend 
    command_line  $USER1$/check_smtp -H $HOSTADDRESS$ -f 
        "$ARG1$" - C "RCPT TO:<$ARG2$>" -R "250" 
  } 

This check will attempt to send an e-mail from $ARG1$ to $ARG2$, which will be passed from a check definition, and expects to receive the return code 250, which indicates that no error has occurred.