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.