User unknown in virtual mailbox table

Hello all,

I need some help with my fresh installed YunoHost-Server.

My YunoHost server

Hardware: VPS bought online
YunoHost version: 11.2.14 (stable)
I have access to my server : Through SSH and through the webadmin
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : NO
If yes, please explain: NO

Description of my issue

I have a freshly installed YNH server. The first two users have been created. The admin and a first test user. When I send a test mail to these addresses from a completely different mail account, I get an error message:

Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

The diagnosis does not return any error messages. There is also nothing unusual under Tools > Logs. I have also restarted the server. And all packages are up to date. The switches for the e-mail services are also activated under the domain.

What could be the reason for this? Where else can I look for errors?
Does anyone have any tips?

Thanks
Tinder

Do you find any traces of the attempt to receive the incoming email on your yunohost in /var/log/mail*?

Oh, darn, I didn’t notice your reply :frowning: Thanks! Yes, I looked in the log file. The following can be found there:

postfix/smtpd[1246728]: connect from the-mail-gateway.com[1.2.3.4]

postfix/smtpd[1246728]: Anonymous TLS connection established from 
the-mail-gateway.com[1.2.3.4]: TLSv1.3 with cipher
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 
server-signature RSA-PSS (3072 bits) server-digest SHA256

postfix/smtpd[1246728]: NOQUEUE: reject: RCPT from the-mail-
gateway.com[1.2.3.4]: 550 5.1.1 <user@test-domain.com>: Recipient 
address rejected: User unknown in virtual mailbox table; 
from=<user@my-domain.com> to=<user@test-domain.com> 
proto=ESMTP helo=<the-mail-gateway.com>

postfix/smtpd[1246728]: disconnect from the-mail-
gateway.com[1.2.3.4] ehlo=2 starttls=1 mail=1 rcpt=0/1 data=0/1 
rset=1 quit=1 commands=6/8

Unfortunately this does not help me much.
Does anyone else have an idea?

In /etc/postfix/main.cf you can find

# Virtual Domains Control
virtual_mailbox_domains = ldap:/etc/postfix/ldap-domains.cf
virtual_mailbox_maps = ldap:/etc/postfix/ldap-accounts.cf
virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf,ldap:/etc/postfix/ldap-groups.cf

This part describes which email addresses can be reached on your mail server:

  • which domains are configured to receive email
  • which mailboxes (local_parts as in <local_part>@<domain>) exist
  • which aliases exist - pointing some local_part not being an actual mailbox (the place to store email for local users) to one or more mailboxes

The files referenced contain the ldap information to query the yunohost internal ldap server.

For an email to be reachable from outside

  • the domain must be configured for email (there’s a switch in the config panel)
  • the local_part must either be found as a local user mailbox
  • or as an alias

The local user mailbox needs to be active for the receiving domain: if you look at the user account in the yunohost webgui there should be the full email address listed.

It’s might not be enough to enable email for and then create as an account to be able to receive <user>@<domain>. If you have multiple domains the automatically generated email address for a new account will always be <account>@<main domain> and will not enable reception of emails to <account>@<other domain with email enabled>.

@ChriChri Many, many thanks for this detailed description!
Yes, I have found the main.cf and the ldap-*.cf. The lines there are exactly as you wrote them. That seems fine so far.

The switches for incoming mails and outgoing mails are switched on in all domains. Thats ok.

For each “local_part” there is a direct, local mailbox or an alias.

Yes, I can see the complete e-mail addresses in Yunohost’s Webgui. I even copied them from there and pasted them into my mail programme when sending my testmails.

I have set up several domains, but at the moment I am only testing accounts on the main domain.

Nevertheless, the mail arrives on the server, as the log file shows, but is somehow rejected. I have a vague suspicion that the LDAP system could be stuck. It doesn’t seem to answer the requests that come via postfix > the main.cf > and then the various ldap-*.cf correctly at the end.

It’s all a bit strange at the moment. The exciting thing is that this is my third YunoHostServer and I haven’t had any problems with the others.

You could try to query the ldap database from cli to check whether that works. The ldap-files for postfix contain the queries and I can use them like this:

root@localhost:~# cat /etc/postfix/ldap-domains.cf
server_host = localhost
server_port = 389
search_base = ou=domains,dc=yunohost,dc=org
query_filter = (&(objectClass=mailDomain)(virtualdomain=%s))
result_attribute = virtualdomain

root@localhost:~# ldapsearch -x -b "ou=domains,dc=yunohost,dc=org" '(&(objectClass=mailDomain)(virtualdomain=my.mail.doma.in))'
# extended LDIF
#
# LDAPv3
# base <ou=domains,dc=yunohost,dc=org> with scope subtree
# filter: (&(objectClass=mailDomain)(virtualdomain=my.mail.doma.in))
# requesting: ALL
#

# my.mail.doma.in, domains, yunohost.org
dn: virtualdomain=my.mail.doma.in,ou=domains,dc=yunohost,dc=org
objectClass: mailDomain
objectClass: top
virtualdomain: my.mail.doma.in

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

From the postfix ldap-*.cf file take the search_base and the query_filter and use them in for ldapsearch. Replace the %s in the query_filter by the string you’re searching for.

I can’t remember if I had to change ldap permissions to be able to query from the cli, but I think that these queries from 127.0.0.1 should be allowed by default.

You could also try to get a report by postfix what went wrong when trying to deliver to an address: Postfix Debugging Howto

If this works for locally generated email it is a data point, too.

@ChriChri ldapsearch ran perfectly. I did not have to assign any special rights. The output with my main domain was also completely fine. It all looks very good.

I then ventured into debugging.

In one terminal I ran tail -f /var/log/mail.info and in another I ran the command sendmail -bv me@mydomain.com. (Note: mydomain.com is the main domain of the Yunohost server and me@mydomain.com is my Yunohost admin)

The following output appeared in the log file:

postfix/pickup[1297398]: C18FC602B19: uid=0 from=<root>
postsrsd[1298323]: srs_forward: <root@mydomain.com> not rewritten: Domain excluded by policy
postfix/cleanup[1298321]: C18FC602B19: message-id=<20240702193627.C18FC602B19@mydomain.com>
postfix/qmgr[1253983]: C18FC602B19: from=<root@mydomain.com>, size=244, nrcpt=1 (queue active)
postfix/pipe[1298325]: C18FC602B19: to=<me@mydomain.com>, relay=dovecot, delay=2.9, delays=2.8/0/0/0.03, dsn=5.1.1, status=bounced (user unknown)
postsrsd[1298323]: srs_forward: <""> not rewritten: No at sign in sender address
postfix/cleanup[1298321]: CA725602B39: message-id=<20240702193627.CA725602B39@mydomain.com>
postfix/bounce[1298330]: C18FC602B19: sender non-delivery notification: CA725602B39
postfix/qmgr[1253983]: CA725602B39: from=<>, size=1935, nrcpt=1 (queue active)
postsrsd[1298323]: srs_forward: <""> not rewritten: No at sign in sender address
postfix/cleanup[1298321]: CBBC0602B16: message-id=<20240702193627.CBBC0602B16@mydomain.com>
postfix/bounce[1298327]: C18FC602B19: sender delivery status notification: CBBC0602B16
postfix/qmgr[1253983]: CBBC0602B16: from=<>, size=1699, nrcpt=1 (queue active)
postfix/qmgr[1253983]: C18FC602B19: removed

I assume this is the interesting line:

postfix/pipe[1298325]: C18FC602B19: to=<me@mydomain.com>, relay=dovecot, delay=2.9, delays=2.8/0/0/0.03, dsn=5.1.1, status=bounced (user unknown)

But this said nothing new.

A mail to root was not delivered.

I then added the following to /etc/postfix/main.cf:
debug_peer_list = mydomain.com
And reload postfix with

postfix reload

But that didn’t help either.

One more note: when I want to create an e-mail mailbox with this (or another) user using Thunderbird, the Thunderbird test recognises the server settings (port, etc.), but it does not recognise the user/password. The connection can therefore not be established. (I have looked up the necessary steps and settings again in the Yunohost documentation).

Sending from the console via sendmail me@otherdomain.com to an external mail server works, by the way.

What now?

So, I’ve now spent many, many hours reading on the Internet, tried various things and in the end, unfortunately, have had no success. It seems to be completely jinxed. Everything seems to be configured correctly, but mails are not arriving at the YunoHost.
I have now quickly backed up the APPs and rebuilt the server. That was quicker than spending hours searching for the error. And the great thing is that everything works now :slight_smile:

Thanks for the help so far :slight_smile:

Hello, I have the same problem. I manage a server with about 100 accounts. Everything is up to date, and I am hosting on a Hetzner VPS. I have Nextcloud and Wordpress installed.
A lot, but not all accounts, trigger this error. It happens when using group mail aliases, as well as with individual mails.

I followed the commands suggested by @ChriChri but it didn’t help me find the origin of the problem.

Do you have any other suggestion to find the issue ? I would prefer not to rebuild the server…
Like, is there a way to read the virtual mailbox table ?

So a bit of brainstorming and I found the problem.

So you can look into the LDAP data thanks to the phpLDAPadmin app. Very useful. :+1:
I noticed that in the /etc/postfix/ldap-accounts.cf that one of the filter was “permission=cn=mail.main”. And in this table I only had a few accounts, corresponding to the high-level members of my association.

And then I remembered that I deactivated the mail permission in the webGUI for normal users. :sweat_smile: I thought this would prevent them from sending mails or using the local mailboxes, not from receiving then transferring the mails (I got their personal mails linked to their local accounts).
So it was all my fault for a misunderstanding in configuring the group rights. Everything seems to work now.

2 Likes

Oh, now that you mention it … I had also played with the rights a bit. More on the side and without being able to fully concentrate on the task at hand. It may indeed be that I have withdrawn the mail rights from the normal users. Unfortunately I can’t check it anymore, the server is new now :wink: But for next time … you don’t always have an “empty” server. Thanks for the tip!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.