Alias Emails not recognized on Server restart

Issues
1

Issue Description

After a server restart, users cannot authenticate with an address that exists only through a domain alias. Logging in with the account’s primary address works, and after one successful login with the primary address, the alias address also works until the next restart.

Setup:

  • Domain: PRIMARY ([email protected])
  • Aliases (on the domain object): ALIAS ([email protected])
  • Accounts are created with only the primary address (user@PRIMARY).
  • Clients log in with user@ALIAS (the alias-domain address).

It looks like alias-domain resolution during authentication depends on the account already being cached.

Expected Behavior

An address that resolves through a domain alias (user@ALIAS → user@PRIMARY) should be accepted for authentication (IMAP, SMTP submission, JMAP) right after a restart, the same way it is accepted for mail delivery, without first logging in with the primary address.

Actual Behavior

Right after a restart:

  • Login as user@ALIAS fails (authentication failed / invalid credentials).
  • Login as user@PRIMARY succeeds.
  • After that, login as user@ALIAS also succeeds, until the next restart.

The password is correct in every case; only the login address differs.

Reproduction Steps

  1. Create domain PRIMARY with alias domain ALIAS.
  2. Create an account with only the address user@PRIMARY (no explicit alias-domain address).
  3. Restart Stalwart.
  4. Log in over IMAP or SMTP submission as user@ALIAS with the correct password → fails.
  5. Log in as user@PRIMARY → succeeds.
  6. Log in as user@ALIAS again → now succeeds.
  7. Restart Stalwart → step 4 fails again.

Workaround: adding user@ALIAS explicitly as an address on the account makes it work right after a restart.

Stalwart Version

v0.16.x

Installation Method

Binary (Windows)

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

Internal

Additional Context

  • Clients tested: [e.g. Outlook for Windows, Thunderbird]
  • Server behind NAT with port forwarding, no reverse proxy.
  • The domain has “Allow relaying” enabled (split-delivery setup with another mail server). This shouldn’t affect authentication but is mentioned for completeness.

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

Because of the 2 link limit, I had to use placeholders

3

I found a close match for this exact failure pattern in the changelog. Stalwart previously had a caching bug matching this description:

“Mail addressed to a domain alias is rejected with 550 Relay not allowed, unless the domain’s primary name happened to be resolved earlier and is still cached.”

That was fixed in 0.16.18. It’s the same underlying class of problem you’re describing for authentication: a domain alias’s local-part/email indexes aren’t resolvable from the registry until the domain itself (or an account under it) has been resolved and cached once, so a cold server rejects the alias address until something else “warms” the cache.

If you are running a version earlier than 0.16.18, I’d recommend upgrading first, since this type of alias-resolution-on-cold-cache issue has specifically been patched. If you are already on 0.16.18 or later and still seeing the problem specifically for IMAP/SMTP/JMAP authentication (as opposed to mail delivery), that particular manifestation does not appear to be documented as fixed yet, so I can’t confirm it’s covered.

Can you confirm your exact patch version (v0.16.17 vs v0.16.18+ etc.)? That will help determine whether this is the same bug recurring in the auth path or a distinct one.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

4

Which version are you running? Before 0.16.18 an alias domain could only be resolved from a cache that gets filled when the primary domain is looked up, which matches what you describe exactly: after a restart nothing knows the alias until someone logs in with the primary address. With “Allow relaying” on, the same problem wouldn’t show up for inbound mail.

If you’re on 0.16.18 or later and the alias was added before you upgraded, it has no entry in the alias index that release introduced, because existing aliases weren’t indexed on upgrade (same thing as **Domain alias rejected with 550 Relay not allowed on cold cache (LDAP directory backend), still reproducible on v0.16.23**). Remove the alias from the domain and save, then add it back and save. After that, alias logins should keep working across restarts.

5

I am running the 0.16.24, I have removed and re-added the aliases and it works as far as I can tell