Update, policy, country and compromise settings live on their own pages, beside the things they govern.

Behind the hostname identity — system mail here is expected; a customer's script here should be sending as its own domain instead:

Currently in force: user@demo-host (no rewrite — native behaviour) — read from the generated Exim configuration, not from a stored preference. A mailer that already sends as its own domain is never touched; the rewrite only applies to mail that would have left as user@demo-host.

A forwarder re-sends a message somebody else wrote. By default this server keeps their envelope sender, so the receiving side sees this server sending as a domain that never listed it, fails the sender check, and refuses — usually recorded as spam, because that is the bucket refusals land in. The message was fine; the identity on it was not this server's to use.

Rewriting replaces only the envelope sender with a local, reversible address. The From: header and the reply button still show whoever wrote the message, and bounces come back here and are decoded to the original sender.

No forwarders are configured on this server, so nothing here applies until one is.

Currently in force: original sender kept — read back from the generated Exim configuration, not from a stored preference. Mail this server originates is never touched; this applies only to what it forwards.

A restore writes back every file the snapshot holds and removes any this product manages that the snapshot did not have — otherwise a rule added afterwards would stay in force and the restore would report success while being partial. The state you leave is saved first, so a restore is itself reversible; the checksums are verified before a byte is written; and if Exim refuses the restored configuration it is undone and the previous one rebuilt.

Snapshots live in /opt/mailguard/var/exim-backups and are readable without this interface, which matters on the day the interface is what broke. 10 are kept, plus the first one permanently.