I am not using DSM with a bare domain setup as described in your FAQ. My setup is as follows:

DMS runs as
hostname mail.mydomain.org

The email accounts are
user1@otherdomain1.xyz
user1@otherdomain2.xyz
user2@otherdomain1.xyz

So I run DMS as a mail service for 2 of my domains. The MX records work fine, IMAP and SMTP all good. Its just that error message that DSM is reporting as loop-back.

Maybe take a look at these:

# Should not have example.com here, only mail domains from accounts you add
cat /etc/postfix/vhost

# May contain an alias for root to [email protected]
# If so, set a POSTMASTER_ADDRESS ENV
cat /etc/aliases

# Should be mail.example.com
postconf myhostname
# Should be example.com
postconf mydomain

It's possible that the postmaster address default is used, but since you don't have a @mydomain.com mail domain managed, this wouldn't be able to deliver. It possibly also might contribtue to an addition in /etc/postfix/vhost, I'd have to look through source 😅

There's some logic IIRC that tries to be helpful by assuming if you use mail.example.com that you'd have mail accounts managed for @example.com. In your case that would be a bad assumption.

cat /etc/postfix/vhost shows all 3 domains, so the DMS domain and the 2 domains I have set up accounts for.

cat /etc/aliases shows root:[email protected] but I have added 3 aliases via the setup alias... command to forward all 3 postmaster@domainname to an external email address.

Both postconf are correct as you say above they should be.

Should I change POSTMASTER_ADDRESS ENV to what?

cat /etc/postfix/vhost shows all 3 domains, so the DMS domain

Hmmm... I don't think you want mydomain.org there, probably should be mail.mydomain.org 🤔 . It might be part of the problem and a bug we'd need to address.

cat /etc/aliases shows root:[email protected]

This is what I was expecting, and it probably contributes towards the /etc/postfix/vhost (EDIT: Nope), but the main issue here is that you don't have a mydomain.org account setup, so mail being sent to that address obviously won't work.

I have added 3 aliases via the setup alias... command to forward all 3 postmaster@domainname to an external email address.

Let's start with a clean slate reproduction example? 😅

# Start a DMS container instance:
$ docker run --rm -it -d \
  --hostname mail.example.test \
  --name dms \
  mailserver/docker-mailserver:13.2

# Shell into container and add an account
$ docker exec -it dms bash
$ setup email add [email protected] bad-password

# Only the hosted domain DMS manages is listed here:
$ cat /etc/postfix/vhost
other.test

# Likewise for virtual mailboxes:
cat /etc/postfix/vmailbox
# WARNING: this file is auto-generated. Modify /tmp/docker-mailserver/postfix-accounts.cf to edit the user list.
[email protected] other.test/hello/

# Internal/system aliases (not related to `setup alias add ...`, which is virtual aliases)
# This is intended for local system accounts like root and amavis, it represents mail destined to the configured DMS hostname
# Default behaviour at startup generates an alias for root to POSTMASTER_ADDRESS, which assumes a hosted domain without the subdomain is used
$ cat /etc/aliases
root: [email protected]

$ postconf mydomain
mydomain = example.test
$ postconf myhostname
myhostname = mail.example.test
$ postconf myorigin
myorigin = $myhostname
$ postconf mydestination
mydestination = $myhostname, localhost.$mydomain, localhost

# Add an alias:
$ setup alias add [email protected] [email protected]
# It's been added to Postfix virtual alias config:
$ cat /etc/postfix/virtual
[email protected] [email protected]
# Which has also added the domain-part to the vhost list:
$ cat /etc/postfix/vhost
other.test
mail.example.test

Ok, so there is no example.test in /etc/postfix/vhost:

• If you made a postmaster alias like I did above, you'll see it was for the DMS hostname domain-part and that's what we get.
• If you made it for @example.test, that will match the current implicit postmaster address configured at DMS startup in /etc/aliases, unless you adjusted it via the POSTMASTER_ADDRESS ENV.

In your situation, [email protected] is only necessary since one was configured implicitly and you want to redirect that to a different address. However, you'll probably find [email protected] would receive mail too, and would need an alias for that.. So just configure POSTMASTER_ADDRESS=admin@somewhere-else 👍

Presently that won't be sufficient though. it's only a local alias for mail sent to the root system user. We should add a postmaster alias here too. In the meantime you can do this with postfix-aliases.cf in the DMS config volume (this config file is poorly communicated in docs, with only a brief mention in a FAQ entry). This will merge with the always added root: ${POSTMASTER_ADDRESS} alias:

mailserver-report

This is related to the DMS ENV REPORT_SENDER (sender of reports), with a related REPORT_RECIPIENT (who receives the reports) which defaults to the POSTMASTER_ADDRESS.

We can see this covered here:

• ${HOSTNAME} => A system ENV that matches the configured container hostname.
• ${DOMAINNAME} => An internal-only DMS ENV that strips out the subdomain (1st DNS label, unless a bare-domain)

Technically it should be fine to omit the ${HOSTNAME} for the REPORT_SENDER ENV as Postfix will append $myorigin (aka $myhostname currently) when it encounters this.

Since you don't have mail for @mail.example.com managed (most don't), but we have Postfix acknowledging it via mydestination (main.cf setting), it will look at the local-part (mailserver-report) and see if a unix account exists (no), or if any /etc/aliases / /etc/postfix/virtual aliases match, otherwise it'll reject the mail as "unknown user" as you found.

That wouldn't happen just from REPORT_SENDER as that's the sender address. However since REPORT_RECIPIENT was for [email protected] and this was not handled? That would fail to be delivered and bounce back to the sender [email protected], which also didn't exist.

One could setup a catch-all alias / regexp alias to redirect that mail, but Postfix won't be happy about that if it's still configured in mydestination, you'd get error logs (like the bare-domain FAQ entry details).

So you'd either:

• Handle explicitly any specific known local-part matching in /etc/aliases (via our postfix-aliases.cf)
• Follow the FAQ advice and opt-out of receiving system mail. This is not encouraged, since the mail will still be attempted to deliver to @hostname (Unless you configure virtual aliases (setup alias add ...), or a wildcard @mail.example.com / postfix-regexp.cf to handle mail delivered to the hostname / system).
• Use our postfix-main.cf add a catch-all fallback with luser_relay = $local@somewhere-else. This won't be used for existing system accounts or /etc/aliases matches, those would need to be handled separately. You must remove the existing account restriction with local_recipient_maps=, which will no longer reject mail when the recipient address does not have an existing account to deliver to (redirect to luser_relay address).

NOTE: The last two bullet points with wildcard / catchall approach would prevent rejecting mail for users that don't exist. That may make it easier for spam to slip through, but then again postmaster@ is expected as a mandatory address, so that concern may be moot.

mail for MYDOMAIN loops back to myself

Postfix probably recognized the loop when sending mail to itself, failing and avoiding a ping-pong loop? 🤷‍♂️

If the account did exist (as the case for amavis), you will find that delivered to /var/mail by the local delivery agent, which is not to any storage Dovecot manages (for accounts within mail domain folders under /var/mail). So you may have mail there that you're not aware of too.

These issues should all be resolved with:

• ENV POSTMASTER_ADDRESS=user@somewhere-else (your preferred address to redirect this mail to instead)
• Add a postfix-main.cf:

# The local-part (eg: mailserver-report) is redirected to the new domain-part address.
# If you don't want to retain the local-part you can instead change `$local` to a fixed value: [email protected]
# Or alternatively to a fixed account, but with the original local-part retained with recipient delimiter feature: [email protected]
# https://docker-mailserver.github.io/docker-mailserver/v13.2/config/user-management/#address-tags-extension-delimiters-as-an-alternative-to-aliases
# More info, see other tokens: https://www.postfix.org/postconf.5.html#luser_relay
luser_relay = $local@somewhere-else

# Unset to avoid matching local-part of address to unix accounts + /etc/aliases (the upstream default lookups for this setting).
# This should force all mail delivered to the DMS hostname (domain-part) that arrives on the `local` delivery agent
# to go through the `luser_relay` redirect configured above since there is no longer a restriction expecting an existing recipient.
# NOTE: Without the luser_relay above, mail arrives without being rejected early for no valid recipient (no mailbox to deliver to), which results in sending a bounce, and would make you a backscatter spam source.
local_recipient_maps =

# NOTE: Aliases at /etc/aliases is still configured for the local transport via `alias_maps` setting,
# thus your `root` / `postmaster` aliases will resolve to an address before considering luser_relay.

The local_recipient_maps default should normally fail with Recipient address rejected: User unknown in local recipient table, but with the config above instead it should not perform any lookups and deliver straight to the luser_relay address.

If you do want to test local_recipient_maps with a custom set of users, you can create a table like texthash:/path/to/table or inline type:

local_recipient_maps = inline:{user_localpart_as_key_here=value_is_required_but_irrelevant}

Sorry if that's a bit much, low on time to investigate further but the above should help understand the situation better an what your options are to resolve it.

**0 0 21 0.0 s 38.5 h otenet.gr**

I think for this one with the 21 defers you could try running postqueue -p in the container. If these are still stuck in the deferred queue, you could inspect them with the postcat command as I detail here.

That will let you see plenty of information about the mail contents that should better explain why that happened, along with a Queue ID that you could query your logs against.

NOTE: A misleading auth attempt/failure can appear in logs when the user doesn't exist on Dovecots UserDB:

dovecot: auth: passwd-file([email protected]): unknown user

This is due to the Postfix check policy contacting Dovecot to check an accounts quota (which we've had to implement a workaround with for aliases to support via dummy accounts).

It is configured for Postfix here smtpd_recipient_restrictions with check_policy_service inet:localhost:65265 and has nothing to do with general auth (via SASL) or user lookup for any other purpose.