Monitoring e-mail servers using Nagios

Making sure that all e-mail-related services are working correctly is something that each hosting company and intranet administrator needs to perform on a daily basis. In order to do this, Nagios can watch these servers and make sure things are working as expected. This can be done by a remote machine to make sure that the services are accessible or can be monitored by the same server that offers these services.

Nagios can make sure that the processes are running and waiting for connections. It is also easy to verify whether a predefined user/password pair is working properly to make sure that a custom authorization system is working properly.

This section describes the commands that check e-mail servers using network connectivity. Plugins that verify specific processes on a server can be used to make sure a particular daemon is up and running as well.

Checking POP3 and IMAP servers

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$\r\nPASS $ARG2$\r\n" -d 5 -e "logged 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 IMAP4. Each line ends with a newline character (\r\n) 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.

Testing SMTP protocol

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:

Option

Description

-C, --command

SMTP command to execute on the server (option might be repeated)

-R, --response

Response to expect from the server (option might be repeated)

-f, --from

Attempt to set from where the e-mail is originating

-F, --fqdn

Fully-qualified domain name to send during SMTP greeting (defaults to the local hostname if not specified)

-S, --starttls

Use STARTTLS to initialize connection over SMTP

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.

Related Articles

How to add swap space on Ubuntu 21.04 Operating System

How to add swap space on Ubuntu 21.04 Operating System

The swap space is a unique space on the disk that is used by the system when Physical RAM is full. When a Linux machine runout the RAM it use swap space to move inactive pages from RAM. Swap space can be created into Linux system in two ways, one we can create a...

read more

Lorem ipsum dolor sit amet consectetur

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

five + 12 =