Root user email not getting redirected

W

webbasica

Verified User
Joined
Feb 21, 2005
Messages
85
While troubleshooting a clients' issue, I stumbled on this little problem. My Mail queue shows a bunch of frozen emails intended for the root user. This is the message I picked up from the Exim mainlog

Code: 
2025-07-25 15:12:53 cwd=/root/ 4 args: send-mail -i -- [email protected]
2025-07-25 15:12:53 1ufPin-00000008RHH-0SKu <= [email protected] U=root P=local S=532 T="test" from <[email protected]> for [email protected]
2025-07-25 15:12:53 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1ufPin-00000008RHH-0SKu
2025-07-25 15:12:53 1ufPin-00000008RHH-0SKu ** [email protected] F=<[email protected]> R=virtual_aliases:
2025-07-25 15:12:53 cwd=/var/spool/exim 7 args: /usr/sbin/exim -t -oem -oi -f <> -E1ufPin-00000008RHH-0SKu
2025-07-25 15:12:53 1ufPin-00000008RHM-0bh6 <= <> R=1ufPin-00000008RHH-0SKu U=mail P=local S=1862 T="Mail delivery failed: returning message to sender" from <> for [email protected]
2025-07-25 15:12:53 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1ufPin-00000008RHM-0bh6
2025-07-25 15:12:53 1ufPin-00000008RHH-0SKu Completed
2025-07-25 15:12:53 1ufPin-00000008RHM-0bh6 ** [email protected] F=<> R=virtual_aliases:
2025-07-25 15:12:53 1ufPin-00000008RHM-0bh6 Frozen (delivery error message)

I already added/created a forward using /root/.forward and I edited the file at /etc/aliases, but nothing works.
 
You don't still use the xx-xx-xx.da.direct as hostname right? If yes, you need to change that.

Root should be sending from the hostname something like [email protected] (and not use the -da.direct domain just to be clear. But I guess you do have a decent hostname.

This issue might be also caused by the sender spoofing protection I answered in your other thread. Fix that first and then see if root mails still get stuck.
 
I just found out Directadmin creates a default hostname using the server's IP. And no, I didn't use that at the beginning. I've been through a few subdomains and landed on "da.domain.com" a few months back. Should I change it back to something else? Is it because it's easy to guess, or something else?

The fix you suggested didn't solve the issue. And it makes sense, I never have received mail from the root user, so I'm sure it's not related to the latest update.
 
Last edited:
webbasica said:
Is it because it's easy to guess, or something else?
Click to expand...
No it's becasue the ip-ad-ress.da.direct hostname is not owned by the license holder but by Directadmin.
So at a certain moment, this will cause some odd issues or problems, mostly with sending mail as we experienced and sometimes also with certificates. At least that is what we've seen happening fairly often here.
As a host you should use your own FQDN hostname anyway. DA only provided the ip-ad-ress.da.direct hostname so users could easily access DA and setup stuff.

However, if domain.com is a (masked) domain of yourself and you just use da.domain.com as a hostname, then that is perfectly fine, no need to change that.
Only change if you're still using the da.direct hostname.

Now to the root mails problem. That is most likely caused by the hostname changes. I wonder if you have a seperate DNS entry for the hostname. It's best that you put not that da hostname record in your domain.com dns but create a seperate entry for da.domain.com as admin in DNS administration itself, so not under a user.
If you did (or going to) then the hostname directory must be present in /etc/virtual for you to be able to get the root mails through (local mail).

I made a manual that you can check, for the hostname, where the put the hostname record and to check owner and permissions (and if required create) the hostname directory in the /etc/virtual directory.

Check and compare here: https://forum.directadmin.com/threa...e-your-servers-hostname-in-directadmin.70371/

I'm almost sure if the hostname is set correctly and it can send local mail, you will also start seeing your root mail.
 
Well, now I feel dumb. As soon as I added the root: [email protected] line to the aliases file in /etc/virtual/da.domain.com, messages started pouring in. I'm getting a few issues because of the PTR record, but that's secondary, we can call this issue officially fixed.

Thanks a lot!
 
webbasica said:
we can call this issue officially fixed.
Click to expand...
Well in fact no. You created a workaround. :)

If you have a /etc/virtual/da.domain.com directory, then you created the da.domain.com under a domain name, which is not what I wrote. I wrote to not create that da.domain.com under an account, but only in DNS administration as admin.
This way real root e-mails from [email protected] (might be send from firewall) still get a timeout. Or you could run into other odd issues in the future, maybe not, but one never knows.

So I would suggest to remove that domain name under the account you created it in, and then create this record as suggested.

In DNS adminstration, you will have 4 fields to fill in yourself, nothing more.
1.) domain name = da.domain.com
2.) ip address = your server ip
3.) nameserver 1, for example ns1.domain.com or ns1.da.domain.com depending on what you use
4.) namserver 2. Similar.
And that's it.

After that, check the existance of /etc/virtual/da.domain.com and if not create it like shown in the manual I linked to.

After that you can also create dkim for your domain name and ssl record too as shown in the manual too.

Only thing you need is to put your address in the /etc/aliases file like:
root: [email protected]
and restart exim and it works and then also [email protected] send by for example firewall will be send and not delayed.

As for the PTR record, that is an easy fix. Go to the panel of your vps/server provider and change the PTR/rDNS ip to your hostname and ready. If you also use ipv6 then do the same for ipv6.

Ofcourse, it's a suggestion, feel free to do what you think is best.
 
Well, I can't remember how or when did I create the user "admin". But I'm pretty sure I never combined it with the user that owns domain.com.

I understand what you mean by creating the DNS record using the "DNS Administration" page as the admin user. However, I'm not sure how should I "remove that domain name under the account you created it in". Should I delete the whole zone or go in edit and remove all the records?

For reference, these are the records in that zone:

Code: 
A records for:
da.domain.com.
ftp
mail
pop
smtp
www

Nameservers:
ns1.domain.com.
ns2.domain.com.

MX:
mail.da.domain.com.

TXT:
"v=spf1 a mx ip4:xxx.xxx.xx.xxx ~all"

Also, this domain is actually managed by Cloudflare DNS. So, do I enter the Cloudflare nameservers or use the default nameservers (ns1.domain.com and ns2.domain.com)? Is there something else I should do in Cloudflare afterwards?
 
webbasica said:
But I'm pretty sure I never combined it with the user that owns domain.com.
Click to expand...
Doesn't need to be the user that owns domain.com, but if you have content in that directory like passwed and alias file then it's done via some user account and not via DNS administration. Because then you would not have alias and other files in that directory. ;)

webbasica said:
Should I delete the whole zone or go in edit and remove all the records?
Click to expand...
First I would look under which account it's present at the moment. Then remove it from there, everything.
The same DNS zone with those contents will be re-created if you create the hostname again via the DNS adminstration.

Once created, it should look like this in DNS administration:
1753565113873.png
if you see a NO NO here, then that means you have to create the da.domain.com directory manually like stated in the manual.

When afterwards you open da.domain.com in DNS administration again, then you will see it will have the same records as shown in your reference above.

As for nameservers, just use the ones which are used on the DA server, because the DA server needs to know what to do locally. So ns1.domain.com and ns2.domain.com are fine.

However, you can not create a seperate DNS record for the server in Cloudflare like you can do in Directadmin.
So for da.domain.com you have to copy the SPF record for the "subdomain" da in DNS for domain.com. Unless it's the same record, then it doesn't need.

If you plan to use DKIM for domain.com then it would be wise to either copy your dkim record for domain.com to your /etc/virtual/da.domain.com directory too or create a DKIM for your hostname da.domain.com and then add x._da.domain.com. next to x._domain.com. in Cloudflare's DNS.
Might be easier to copy your domain.com dkim.private.key and public.key to your hostname in DA itself, less work. ;)
 
Richard G said:
First I would look under which account it's present at the moment. Then remove it from there, everything.
The same DNS zone with those contents will be re-created if you create the hostname again via the DNS adminstration.
Click to expand...
This is where I'm stuck. This is what I did:

1- On the DNS Administration page, I selected the da.domain.com domain and clicked in Delete.
2- On the server, using the command line, I deleted the directory /etc/virtual/da.domain.com
3- Now, back in the DNS Administration page, I recreated the da.domain.com zone, following your guide.

This is what I get:
1753632637610.png
 
Hmmz.. odd. I don't understand why you get that YES on Local Data, never seen that before.

Does the /etc/virtual/da.domain.com exist again, and does it have the same entries as before?
Otherwise if yes, then change the alias again so root mails can be send and then we could look if issues will occur.
As long as you also can receive firewall mails from root and the rDNS/PTR is fine, might work this way too.
 
The directory /etc/virtual/da.domain.com doesn't get recreated. If I recreate it (chown and chmod) and recreate the aliases file inside it, this is the new message I get (emails are not getting delivered):
Code: 
Received from [email protected] U=root P=local S=532 T="test"
[email protected] R=uservacation defer (-1): local_parts check lookup or other defer
 
webbasica said:
The directory /etc/virtual/da.domain.com doesn't get recreated.
Click to expand...
An then you did not follow the manual.
Because that's what the manual also said. And then you have to create it manually, give right owner and permission as shown in the manual.
After that, the directory should be empty and you shoud see NO and YES like in the screenshot.

So do not create aliases file in there. Delete it from there and then you should be able to send mail as root.

Also check these files
/etc/virtual/domainowners -> should -not- contain da.domain.com
/etc/virtual/domains -> should contain da.domain.com
 
That did the trick. No error message, it shows → Local Data, no and Local Mail, yes.
And messages are getting sent. Now I guess everything is properly configured.

Thanks a lot!
 
You're welcome, glad it works great.
If you run into any issues like SPF or DKIM for hostname, just let me know and we fix that instantly.
 
Thanks, again.

I don't really mind for the root mail, but I would like to know how to properly setup SPF and DKIM for the other accounts, using Cloudflare for DNS and Gmail for sending mail. Do you have a guide?
 
I don't have a guide but I know that for SPF and DKIM records in Cloudflare it's the same as using external DNS.
So you just copy the SPF and DKIM records into Cloudflare.
1.) Do not proxy the "mail" like mail.domain.com record
2.) Copy the SPF record as TXT record in Cloudflare as DNS only
3.) Copy the DKIM record as TXT record in Cloudflare as DNS only

If I'm not mistaken.
I've found a guide for you, pity you just can't enlarge the images by clicking on it.
But these are instructions for SPF: https://easydmarc.com/blog/how-to-add-spf-record-to-cloudflare/
 
Thanks, you are too kind!

I noticed an error with the da.domain.com user, I have a backup task everyday at night, and yesterday got this error:

Code: 
Unable to read /etc/virtual/da.domain.com/passwd : Unable to open /etc/virtual/da.domain.com/passwd for reading.
No such file or directory

Which makes sense, since I've deleted that file. Now I'm wondering if I should remove the user admin altogether from the "Show all users" page. It's the one that owns da.domain.com, but it's also the one I use to manage Direct Admin.
 
webbasica said:
I noticed an error with the da.domain.com user
Click to expand...
You should not have a da.domain.com user, because the da.domain.com is generated via DNS administration, not under a user account.
If you see da.domain.com under "show all users" then it means you setup da.domain.com as subdomain under the admin user previously.
So just remove the subdomain from the admin user.

I would strongly suggest to never remove the admin user anyway.
 
Additionally... doublecheck after removing the subdomain from the admin user, if the /etc/virtual/da.domain.com directory is not deleted by this action. ;)
 
You must log in or register to reply here.
Back
Top