Dear Community,
We needed an email address (and an email inbox) for specific email inboxes. So, we created a user: Username: “mail_mailname”
Since Netserver 8, email addresses other than the username can be specified directly during creation. “mailname@domain.tld” was stored as such an “optional email address.”
As a little “gimmick,” the email address was used as the display name. I mention this because I initially thought it was the cause of the error described above.
The above-mentioned user could actually be created this way, and it was also possible to log in to Thunderbird and SOGo with it. The stored email address “mailname@domain.tld” was also correctly considered and evaluated during creation, as it was displayed correctly in SOGo (top left, the first list entry).
However, the email account could not receive emails to this address – and could not send emails to this address itself from either SOGo or Thunderbird (error message: not deliverable, address lookup failed).
External emails to this address were also not delivered – for external users – but were not rejected either. They were not visible in SOGo, and Thunderbird received nothing either. Internal senders received a message that the address did not exist (error message: not deliverable, address lookup failed).
The first thing I did was check under Mail / Addresses to see if the desired email address already existed as a pseudonym for another mailbox. That wasn’t the case. But the address wasn’t there either. It was only found there because it was stored as a display name.
I then corrected the user entry in AD (using the NetServer 8 GUI). I removed the email address from the Display Name field AND also from the “Email Address Optional” field. While making the correction, I noticed that the GUI in the AD area wasn’t responding very well – and the Save button wasn’t clickable at first. Could this have something to do with the unusual @ entry? After 2-3 attempts (leaving and re-entering this area), the correction was applied.
I then created the desired address as a pseudonym in the “Mail” section and assigned it to the “mal_mailname” account. The account then worked and received and sent emails as expected.
Question: Was this due to the unusual entry in the “Display Name” field? Hard to say, I probably wasn’t systematic enough.
So today I tried to recreate the problem. The same name and entries as above, because that was just an example so far: “mail_mailname” as the username, “mailname@domain.tld” as the optional email address, and again “mailname@domain.tld” as the display name.
The account was created, but like yesterday, it didn’t receive any emails. “mailname@domain.tld” wasn’t displayed under “Mail Addresses” either.
So I created another user, “mail_mailname2,” with the optional address “mailname2@domain.tld” – but this time with a “normal” display name: “mail_mailname2” (not the email address).
But this user also received no emails, and even internal senders couldn’t send to it (error message again: not deliverable, address lookup failed).
That means the @ in the display name was NOT the cause. The email addresses stored in AD under “Optional Email Address” are probably simply not being used.
This appears to be a bug, because on another NetServer 8, the addresses stored there are being used correctly – but the option “Add user addresses from the user domain” is NOT enabled there either.
Now I added the missing address “mailname2@domain.tld” under Mail / Addresses and assigned it to “mail_mailname2.” Mail delivery to this address then worked.
However, I was surprised that I could (re)add the address as a pseudonym, since this address was already used or assigned in the AD domain – albeit to the same user. Is this intended?
So, as a test, I added “mailname@domain.tld” to the user “mail_mailname2” as a pseudonym. This also saved (was accepted) – even though this address had already been assigned to “mail_mailname” in the AD domain.
After creating the pseudonym, emails could also be sent to this address (it took a few minutes until this was allowed, so take this into account when re-creating it). However, the emails were only delivered to the destination of this pseudonym – not to the user who “inherited” this address via AD.
I suspect that the “Email address optional” field is not evaluated if the “Add user addresses from the user domain” option is enabled. However, this isn’t clear when creating users.
Locking the field wouldn’t be a good idea either, because if you wanted to disable the above option, you would no longer have the option to create users’ email addresses in advance.
If the behavior described is a bug, this would be my bug report up to this point.
If the behavior is correct, however, it is misleading and should be explained somehow in the creation field.
Regards, Yummiweb
Addendum:
The Mail app is currently at version 1.6.4.
Unfortunately, the core version can no longer be read because a core update is pending (clicking on the three dots and “Core Module” only shows a reduced page with an update notice). It’s likely the most recent version BEFORE the major core update.
