Postfix mapping fails if configured `monitor_hostname` does not match actual hostname

[cfm]

Description

If the monitor_hostname value configured in site-specific does not match the Monitor Server's actual hostname, the configured Postfix mapping will not apply, and outbound OSSEC alerts will not be delivered via an SMTP relay that authenticates the From header.

Steps to Reproduce

As encountered during https://github.com/freedomofpress/securedrop/issues/6103#issuecomment-938341940:

1. Provision production VMs via molecule create -s libvirt-prod-focal, yielding VM with the following hostnames:
   • app-prod
   • mon-prod
2. ./securedrop sdconfig, including an authenticated SMTP relay, leaving the following settings lazily at their defaults:
   • app_hostname: app
   • monitor_hostname: mon
3. ./securedrop-admin install
4. From the Journalist Interface's /admin/config, under Alerts, select Send a Test Alert.

Expected Behavior

If step (3) did not error, step (4) should deliver an OSSEC alert to the configured SMTP relay.

Actual Behavior

Observe Postfix delivery failure indicating that no mapping was performed against the Monitor Server's actual hostname:

amnesia@amnesia:~/Persistent/securedrop$ ssh mon
vagrant@mon-prod:~$ sudo journalctl -f
[...]
Oct 06 16:59:35 mon-prod postfix/smtp[138189]: AF6B41609A6: host mail.riseup.net[198.252.153.63] said: 450 4.1.2 <ossec@mon-prod>: Recipient address rejected: Domain not found (in reply to RCPT TO command)

Comments

More work: #3603. In other words, #5924 uses the configured or given, not the actual, hostnames.

Less work: In Ansible role prepare-servers, error if configured {app,monitor}_hostname values do not match actual hostnames.

[zenmonkeykstop]

There is the (poorly documented) ossec_from_address https://docs.securedrop.org/en/stable/ossec_alerts.html#not-receiving-emails which is supposed to address this case - this error is coming from mail.riseup.net in the case above, as mon-prod isn't a valid domain. In cases where the remote SMTP server needs a valid domain (and/or one that it will relay for), you can set this variable in site_specific to override the default choice of the local hostname.

[cfm]

Yes, absolutely, @zenmonkeykstop. But it looks like ossec_from_address (or at least its documentation) predates #5924's work to support Focal's use of ossec@${hostname} rather than ossec@ossec.server, and it's that hostname-based rewriting that I mean to flag here as fragile in this case. But I concede that this may be less of a bug and more just new evidence in support of #3603, and I'll downgrade the tags accordingly. :-)

Let me know, of course, if I'm missing something else in my interpretation here....