Exim not finding system accounts

Willis

Verified User
Joined
Dec 31, 2005
Messages
38
Cross-posting from https://forum.directadmin.com/threa...s-returning-550-no-such-recipient-here.59446/ as I was not getting any responses there, and everything I'm seeing related to configuration says the configurations are correct, so I can only assume this is CentOS 8 specific at this point.

This is from users imported from CentOS 7 (but likely effects newly created domain users in the same way).

Permissions on the Maildir appear correct, /etc/virtual/domains and /etc/virtual/domainowners are correct, as is /etc/virtual/domain.ext/aliases. /etc/virtual/domain.ext/passwd is not relevant to system user accounts as far as I am aware.

Dovecot/IMAP works without issue, able to read all folders and imported mail.
Roundcube can log in, view, and even send (I can only assume it bypasses Exim auth as localhost).
All virtual domain email addresses work correctly, it is only the system level user that fails.

Exim reports "550 no such recipient here" for all incoming mail to these system accounts.
Outgoing from the account (via SMTP using Thunderbird) reports:
Code:
Verification failed for <[email protected]>
Sender verify failed.

Any thoughts on what else I can check?

Configuration is Exim w/ SpamAssassin, Easy Spam Fighter & blockcracking enabled, but the same issue happens when they are not enabled.
All config files are done through CustomBuild 2.0 rewrite exim configs with no modifications.
 
Did old system use https://www.directadmin.com/features.php?id=2164 ? You may try enabling it on the new one and check if that solves your problems :) Just:

Code:
/usr/local/directadmin/directadmin set system_user_to_virtual_passwd 1 restart
echo "action=rewrite&value=email_passwd" >> /usr/local/directadmin/data/task.queue
/usr/local/directadmin/dataskq d
 
No, that is not a feature I was previously using, as the logins were always just the basic usernames without the domains.

Before I try that, is the reverse process the same just swapping the variable?
 
Reverse would be change of the variable to 0 and rewriting email passwd files then Anyway, it's pretty safe and it'd let main accounts to login using [email protected] and user, instad of just user :)
 
I'm not quite convinced to try that option just yet, when the current configuration is what has always worked. There is something else at play here, as Exim is rejecting incoming email being unable to locate the account, and the virtual pwd file shouldn't matter for that. Virtual aliases file does list the system account correctly as a non-virtual format of systemuser: systemuser
 
Since there have been no other suggestions, I tried the command to duplicate system users to virtual users via passwd file, and I still get a 550 no such recipient here event when sending to that user when the user exists in the virtual domain passwd file. I did verify logging in with [email protected] was working as expected in that case.

Edit:
Additionally,
Code:
/usr/local/directadmin/directadmin set system_user_to_virtual_passwd 0 restart
echo "action=rewrite&value=email_passwd" >> /usr/local/directadmin/data/task.queue
/usr/local/directadmin/dataskq d

to undo this does not remove the system users from the passwd file, so it must only take effect for newly created users.
 
This has been resolved. The hostname was erroneously added (by me) as a domain in attempt to generate SSL certificates, but it resulted in hostname confusion, so local accounts were rejected because they didn't exist under the server host domain.

Solution is to remove the domain that matches the hostname, and make sure it exists in /etc/virtual/domains but NOT in /etc/virtual/domainowners

Just posting in case anyone else runs into such an issue.

Thank you @smtalk for the assistance in tracking down this issue.
 
Back
Top