When icinga2 sends out emails, it sets the environment variable HOSTNAME. The same environment variable is used by nullmailer but with different semantics. This breaks email sending…

The environment variable HOSTNAME is usually set by your NotificationCommand definition for email notfications by icinga. HOSTNAME contains the name of the host that was the source of the notification.

When icinga2 wants to send a notification it will then execute the defined command, which by default is the script /etc//icinga2/scripts/mail-host-notification.sh.

That script calls the mail executable, which in turn will call the sendmail command which can be picked up by nullmailer (in which case sendmail is usually a symlink to nullmailer).

Now unfortunately nullmailer understands the same environment variable HOSTNAME as meaning “please set the mail domain of the sender” to the contents of HOSTNAME.

So if HOSTNAME contains loadbalancer.europe.example.org then nullmailer will probably set the enveloppe sender to nagios@loadbalancer.europe.example.org, nagios being the user as which the icinga2 process is running.

The result in /var/log/mail.log looks like this:

Nov 27 16:49:05 monserver nullmailer[8850]: smtp: Failed: 550-Verification failed for <nagios@loadbalancer.europe.example.org>#012550-Unrouteable address#012550 Sender verification failed

There are various ways to work around this problem. One is to set the MAILFROM environment variable in your NotificationCommand definition. However for some reason (maybe the dispatching logic for the mail command in the mail-host-notification.sh script), this wouldn’t work.

So in the end I set the NULLMAILER_HOST environment variable inside the NotificationCommand definition, which, for nullmailer, has a higher precedence than the HOSTNAME variable and thus overrides it.