Frozen emails to [email protected] and /etc/aliases not used

Has anyone else run into this problem with the Hestia Exim configuration? I have several emails frozen in the exim queue that were sent by cron to [email protected]. The following messages appear in the log when this happens:

<= [email protected] U=root P=local S=773
remote host address is the local host: host.domain.com
[email protected] R=dnslookup defer (-1): remote host address is the local host

Obviously, the “host.domain.com” domain is not in any of the files in /etc/exim4/domains/. So I created a /etc/localdomains with the host’s FQDN in it and that seems to have helped that error.

But now those emails are failing because /etc/aliases is not being read:

failed to expand condition "${lookup{$local_part}lsearch{/etc/exim4/domains/$domain/passwd}{true}{false}}" for localuser router: failed to open /etc/exim4/domains/host.domain.com/passwd for linear search: No such file or directory
failed to expand condition "${lookup{$local_part@$domain}lsearch{/etc/exim4/domains/$domain/aliases}{true}{false}}" for terminate_alias router: failed to open /etc/exim4/domains/host.domain.com/aliases for linear search: No such file or directory
** [email protected]: Unrouteable address

Forgive me if this is obvious. I’ve been using Postfix for over 20 years and am unfamiliar with Exim’s config. I’ve been reading through the Exim documentation, but so far have not been able to figure out how to alleviate this problem.

Thanks!
–Dan

Hello @fluidmindorg,

Can you please share the contents of your below files:
/etc/hosts
/etc/hostname
/etc/mailname
/etc/aliases

You may hide your external IPs.

Hey @fluidmindorg ,

I know this might come across as rude but I promise I don’t mean it that way. But just verifying that you actually have a mailbox for [email protected] ready to receive mail? I had similar errors awhile back and found they weren’t being delivered because there was nowhere to deliver them to.

If that’s the case, you can either create the mailbox in hestia, or you can setup a forward for the root user. Like this:

echo "[email protected]" > /root/.forward
4 Likes

Hahaha. Thanks @cmstew. No worries. That’s a perfectly reasonable question. But it does, however, turn out to be a more complicated question than it seems. I’ll explain.

That’s a good idea, adding /root/.forward, and it’s part of the solution. But it has several serious limitations:

(1) Hestia’s default Exim configuration does not include the FQDN of the host system in Exim’s “local_domains” variable. Without that, delivery to [email protected] doesn’t work at all, and /root/.forward is never read.

(2) This method can only forward to addresses that are not local system accounts, because Hestia’s default Exim configuration is missing the router and transport for standard, traditional delivery to system accounts. So, for example, if I wanted emails to root to forward to the local “sysadmin” account that I created during the installation of Debian, it fails with the following error:

[email protected] <[email protected]>: Unrouteable address

(3) All the aliases in /etc/aliases are still invalid because Hestia’s default Exim configuration is missing the router that reads that file. So a system email sent to [email protected] gives the following error.

[email protected]: Unrouteable address

After drudging through all the Exim config documentation from top to bottom, I finally figured out how to alleviate all these issues. I’ll explain below. But first, let me explain why I wanted to come up with a more complete solution for this. One of the things I love about Hestia is that it’s not obtrusive, it doesn’t get in the way of other server processes and other parts of the operating system. I can have other, non-Hestia controlled websites configured in nginx and other server application running, and Hestia doesn’t stomp all over the other things I have set up on the system. The one area I’ve come across where Hestia does trample on the normal operations of the Linux system is with email. By leaving out configuration to handle /etc/aliases and delivery to normal Linux system users on the host, it disables what to me is an important part of the system. If I want to have other local system users that are not part of Hestia, email to them won’t work.

To use the terminology from the Dovecot documentation: “mail users can be categorized as either system users (in /etc/passwd) or virtual users (not in /etc/passwd).” Hestia, obviously, has system users for the main account logins, and virtual users for email addresses. So my goal was to have Exim continue to deliver to Hestia’s virtual users but still allow Exim to handle email to system users (and aliases) in the normal, traditional way (delivering to mbox files in /var/mail).

So, to address the issues:

(1) To deal with the fact that Hestia’s Exim config does not include the host system’s FQDN (e.g., host.domain.com) in the “local_domains” variable in Exim, you can manually place the FQDN into a file at /etc/localdomains. But rather than adding such a manual process, I think it’s cleaner to add Exim’s auto-generated $primary_hostname variable to the local_domains declaration:

domainlist local_domains = @ : localhost : $primary_hostname : dsearch;/etc/exim4/domains/

With that added, we no longer get the “remote host address is the local host” error if an email is sent to a local system user with the host’s FQDN. Unless manually set to something else, $primary_hostname always contains the hosts’s FQDN.

(2) To deliver to system users in the traditional way, the original router and transport that come in the default exim config had to be restored. But I had to add a condition to use that router only for email addressed to the system host’s FQDN.

So, after the “userforward:” router, add the following router:

system_user:
  driver = accept
  domains = $primary_hostname
  check_local_user
  transport = system_user_delivery

Then, down in the transports section, add the following so that emails sent to local system users can be delivered in the traditional way to an mbox file in /var/mail:

system_user_delivery:
  driver = appendfile
  file = /var/mail/$local_part
  delivery_date_add
  envelope_to_add
  return_path_add
  group = mail
  mode = 0660

(3) To restore use of the normal /etc/aliases file, add the following router before the “userforward:” router:

system_aliases:
  driver = redirect
  domains = $primary_hostname
  allow_fail
  allow_defer
  data = ${lookup{$local_part}lsearch{/etc/aliases}}
  file_transport = address_file
  pipe_transport = address_pipe

With all of those modifications in place, standard Linux system account email operations are back to functioning as normal. If I want to read system notification emails with mutt or alpine from a terminal, I can do that. Or if I want them to go to some other address, I can always add a .forward file in the home directory of the system user those notifications are being sent to.

One final note: Exim is designed in such a way that it does not allow email delivery to the root user—period. The restriction is actually hard-coded into the C source code. So the Exim documentation recommends using /etc/aliases to set root to be delivered to some other system account. Since Debian/Ubuntu has you create an alternate administrator account right when you install the OS, it automatically sets an alias for root to go to that initial admin account, so no need to address the no-email-to-root issue there. CentOS, however, (and I presume RedHat as well) does not have you create an initial non-root administrator account during installation. Consequently, it does not, by default, have an alias for email to root to be sent to a different system user. Instead, it has the following lines at the bottom of /etc/aliases:

# Person who should get root's mail
#root:          marc

So if you’re not using Debian/Ubuntu, since you’re using Exim you’ll need to edit /etc/aliases and tell it a different system user for emails sent to root.

Cheers
–Dan

5 Likes

Hey Dan,

That’s great news that you figured it out! I guess I just didn’t understand that you were trying to get mail to deliver in a literal sense to a local user account. As you’ve figured out, Hestia is not inherently designed that way. I’m not sure if that was necessarily by design or by oversight. But if you are interested in creating a pull request on github, the team might consider merging this into the actual project.

I guess I’ve just never found myself in a place where this was ever a need of mine. Typically the way I deal with this is just creating a mailbox in Hestia, and then use the forwarding feature in Hestia to send it wherever else I want it to go.

On a side note, am I reading that correctly that you’re using CentOS? Technically that’s an unsupported system of Hestia’s. So just be wary if that’s the case because I suppose your mileage may vary.

1 Like

No, no. I’m using Debian 10. I just made that last comment to point out a difference with RedHat/CentOS that affects the root alias when using Exim.

1 Like

Oh good, you scared me for a sec. :joy:

Then, down in the transports section, add the following so that emails sent to local system users can be delivered in the traditional way to an mbox file in /var/mail:

We’re not running mbox on hestiacp, it’s all Maildir format.

And why on earth is this config not default for hestia? All hestia installs will get those unroutable root mail errors in their logs, and heaps of frozen mails in queue etc. Plus no important system warnings!

# exim -bt root
[email protected] is undeliverable: Unrouteable address

See, this is why I dislike exim. With postfix this is a no-brainer. Never one issue. Receives system emails by default.