POP3 and IMAP Checks

POP3 is the most popular protocol for retrieving email messages from an email 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 email retrieving protocol, another protocol is also very common. IMAP is a protocol that is used to access emails 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>] [-c <critical >]
          [-s <send string>] [-e <expect string>] [-q <quit string>]
          [-A] [-m <maximum bytes>] [-d <delay>]
          [-t <timeout seconds>] [-r <refuse state>]
          [-M <mismatch state>] [-v] [-4|-6] [-j] 
          [-D <days to cert expiry>] [-S] [-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$\r\nPASS $ARG2$\r\n" -d 5 
                  -e "ogged in"
  }
  define command
  {
    command_name  check_imaplogin
    command_line  $USER1$/check_imap -H $HOSTADDRESS$ -E
                  -s "pr01 LOGIN $ARG1 $ARG2$\r\n" -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 POP4. Each line ends with a newline character (\r\n) that are sent as newline characters due to using the -E option.

For POP3, these lines are standard protocol commands to log into 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 IMAP protocol to bind requests with answers provided by the server.

To be able to determine exactly what is sent to and received from the server, the -v option can be used.

SMTP Daemon Testing

SMTP is a protocol for sending emails—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] [-C command] [-R response] [-f from addr]
           [-F hostname] [-A authtype –U authuser –P authpass]
           [-w <warning time>] [-c <critical time>] [-t timeout]
           [-S] [-D days] [-n] [-4|-6]

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 emails 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 email from $ARG1$ to $ARG2$, which will be passed from a check definition, and expects to receive a return code 250, which indicates that no error has occurred.