How can I include the subdomain for an account email-address?

[dabziuebu4egh2]

Hello,

I migrated from another mail server to this server. I had user@mail.example.org as my email-address and right now I'm stuck with user@example.org, while the latter looks nicer, I'm currently having the problem that all my logins and contacts know my e-mail-address with the subdomain.

Is there a way I can easily change this or use both?
Thanks in advance!

[polarathene]

Short-version:

• View our docs FAQ for bare domain config, this will disable internal use of mail.example.org (with some caveats).
• View our docs for account config with virtual aliases, there should be a section on wildcard/catch-all config. Set that up for @mail.example.org => @example.org.

---

The default setup for DMS will make some assumptions, such as hostname: mail.example.org will treat @mail.example.org domain-part of email addresses as to/from the internal system users, which is for example bounce mail or sending notifications from DMS integrated services like Amavis to the postmaster address (which IIRC presently when that address is not configured it'll assume postmaster@example.org).

You can look at the FAQ page of our docs and there is a "bare domain" entry with advice on how to configure Postfix to not handle mail.example.org itself, just be aware that Postfix would fail to receive mail delivered internally, you'd need the equivalent accounts or virtual aliases (setup alias add ...) configured IIRC. I don't have a list of these for you as it's not something I've had to think about in some time. So there might be some caveats if you experience any issues.

After making that change, you can add a wildcard / catch-all virtual alias (postfix-virtual.cf, see our docs for advice on this) to route mail for @mail.example.org to @example.org, you only need the equivalent local-part (the user of the email domain address) to have an account (or virtual alias) at @example.org then.

If you'd like to avoid the bare domain caveat, you can also have DMS run for a different domain, in addition to your example.org (account via setup email add) + mail.example.org (catch-all via postfix-virtual.cf). That just requires a separate domain to configure as the hostname of the DMS container, and you'd have your example.org DNS updated to the DMS specific domain (which you can have forward any system mail to your own admin account at example.org via the postmaster address).

You could also technically have DMS Postfix configured to use @localhost for it's internal mail I think, I know there was a rather verbose discussion on that, but it'd appear in mail clients with a sender address of root@localhost or amavis@localhost for example which might make any other users than yourself suspicious and IIRC would also be used for any outbound mail from DMS (like bounces) but as localhost isn't public DNS domain, that'd get rejected quite quickly.

[dabziuebu4egh2]

Thank you very much for your time, I've found the solution.

I had a postfix-virtual.cf already, but I mounted it to the wrong place inside the container.
I was able to pinpoint the problem after I did setup alias list, which returned that the file doesn't exist.

I've set the bind correctly to ./postfix-virtual.cf:/tmp/docker-mailserver/postfix-virtual.cf and now I can receive mails delivered to @mail.domain.org.

[dabziuebu4egh2]

While looking for regexp virtual aliases, I remembered that I mounted the file above to the path as stated here:
https://docker-mailserver.github.io/docker-mailserver/latest/config/account-management/provisioner/file/#aliases
docker-data/dms/config/postfix-virtual.cf

Why is that wrong?

[polarathene]

I've set the bind correctly to ./postfix-virtual.cf:/tmp/docker-mailserver/postfix-virtual.cf

Generally you want to avoid file mounts. I don't think any changes made in the container via our setup CLI tool would persist back to disk with that, and it can also prevent changes on the host system becoming available too.

You should prefer to bind mount directories, in our docs we do cover that /tmp/docker-mailserver is intended as a config volume mount for the whole directory.

docker-data/dms/config/postfix-virtual.cf

Why is that wrong?

That's probably the fault of our docs, it's a bit ambiguous with that "config file" path:

If you scroll up to the parent section it refers to each config file as belonging to the DMS Config Volume which links you to this overview of content/structure in the volume, and the actual mount info at the top of that page:

As a user how might we make that slip up less likely? I know the docs aren't in the best shape, I try to improve them where I can.

Perhaps the config file path you pointed out should refer to the location within the container instead?

[dabziuebu4egh2]

Generally you want to avoid file mounts. I don't think any changes made in the container via our setup CLI tool would persist back to disk with that, and it can also prevent changes on the host system becoming available too.

I don't know about the internals but shouldn't be this logically just symlinks?

What would be the difference if I reference a file on my host twice within my docker-compose.yml while I have a file mounted directly and indirectly because of the parent directory - as long as the permissions are fine.

[polarathene]

I don't know about the internals but shouldn't be this logically just symlinks?

It's the same as doing a bind mount outside of containers, so no not like symlinks. You mount the inode to another part of the filesystem.

With a file, if you can edit it without altering that inode, the change is sync'd IIRC. Some programs do atomic writes where they write to a separate temporary file and then basically mv command that over the original file which would replace the inode since it's a new file entirely.

When that happens, on the host system the old inode is still mounted into the container, so you don't see the updated file. If the change was attempted from the container, then it's either forbidden or won't affect the original file either because inode must not change.

With a bind mount on a folder however, so long as that folders inode doesn't change, any of the file contents are fine to change their inodes, and all is well.

What would be the difference if I reference a file on my host twice within my docker-compose.yml while I have a file mounted directly and indirectly because of the parent directory - as long as the permissions are fine.

I imagine that the direct file mount over any equivalent file in the folder mount would be overlayed, so the file from the folder mount would be masked/hidden, and whatever file you have directly mounted at that location would still have the same issues as described above due to inode tracking.