@Bluejanis could you please open another issue? This way we might be able to spot the issue faster (by looking at your configuration). They may have been in a regression somewhere (although I cannot think of a PR that may have introduced the regression). Nevertheless, worth investigating.

I don’t know, I’ve never tried that. That’s not how it should be used (technical possible, of course).

@casperklein

Disagree. Different distros suggest a single label hostname, while others suggest the full FQDN.

hostname -s will provide you the single label (short hostname) should you need it, hostname the value of /proc/sys/kernel/hostname, and hostname -f the response from querying the hostname to /etc/hosts or if failing external DNS.

Where it matters is how any software may interact with such. I know Postfix can use this implicitly (along with domainname I think), but it can also be explicitly configured instead.

Do you have any resource that says that’s not how it should be used? I’ve got resources that say the hostname can effectively be an FQDN, and that domainname is intended for legacy NIS domain usage, not DNS domain.

I did a quick test, and there is no difference in the generated /etc/hosts file, when using a FQDN as hostname and omitting domainname. However hostname and /proc/sys/kernel/hostname are returning a FQDN then.

/etc/hosts will be given an entry (provided not using host network mode), that concatenates /proc/sys/kernel/{hostname,domainname} together (if domainname isn’t (none)), and the hostname -s (1st label) from hostname as an alias. In most cases that should result in an FQDN that you’d expect and hostname -f will return that, hostname -d will also return that same value minus the 1st label. See response below to @georglauterbach for more details.

While that FQDN in /etc/hosts may not change, it does change behaviour in hostname used to query. This can cause problems when hostname is multi-label but a domainname also exists, and especially weird in the case of example.com being assigned to both. Both of those kinds of config are unlikely used in practice though (with the earlier mentioned exception).

---

Ah - but … attempts to resolve mydomain.ca from inside the container result in my external IP address - that still seems to make sense to me as mail.mydomain.ca and mydomain.ca should be allowed to be different machines.

@andrewlow

While I don’t disagree, if you have a mail-server that uses mail.mydomain.ca but sends emails with headers mydomain.ca (mail label stripped), could docker-mailserver upon interacting with either handle them differently, even if it’s responsible for both?

mail and mail.mydomain.ca will resolve as the local container IP, and services should therefore know in the container that it’s local. But any mydomain.ca query will fail to match in /etc/hosts without that alias, thus query public DNS for IP. Is that the expected outcome or could that be a potential issue?

---

# AFAIK the next two commands are expected to show '(none)'

@georglauterbach they both reflect the domainname that the Docker CLI or docker-compose.yml can set. @andrewlow has this set as our docs generally advise this setup, but I’m also of the understanding that it’s probably not what we want.

Regarding hostname, dnsdomainname and domainname commands. Each has specific default output, but the -s, -d, -f options for all of them will output the same value.

• domainname default output is not the same as any -d output, it maps to /proc/sys/kernel/domainname.
• dnsdomainname has nothing of value to offer to my knowledge.
• hostname -s at least on Debian actually can differ vs the other two commands, and output the 1st label from /proc/sys/kernel/hostname directly instead, not the 1st label of the returned entry (after IP) from a match in /etc/hosts which the other two commands do.
• The -d and -f options on all three commands also operate on /etc/hosts like this (with the value of /proc/sys/kernel/hostname), unless they fail to match and instead attempt to do an external DNS query.
• So if you change that first value in the /etc/hosts to be completely unrelated to your actual FQDN, you’ll find -d outputs that value minus the first label, and -f outputs that FQDN, all that was required was a match on the hostname via alias (if you only set hostname and not domainname however, this isn’t likely to match now as the FQDN is missing, add it to the /etc/hosts line as a separate alias and you’ll see it return/operate on that 1st unrelated FQDN).

This was all covered in findings noted here. Of which maintainers have probably read me repeat multiple variations of 😅 (just repeating in this issue for context)

So you’re using hostname: mail and domainname: example.com?

yes

Would there be any issues with using hostname: mail.example.com?

I don’t know, I’ve never tried that. That’s not how it should be used (technical possible, of course). I did a quick test, and there is no difference in the generated /etc/hosts file, when using a FQDN as hostname and omitting domainname. However hostname and /proc/sys/kernel/hostname are returning a FQDN then.

@NorseGaud for example has been using the same value for hostname and domainname

That makes no sense.

Nice Blogpost! - I see you encountered issues whilst setting up relay with SES. Feel free to provide a documentation update! @docker-mailserver/maintainers what about a section in docs linking blog posts and tutorials?

I’m still poking at this - no conclusions yet.

I modified my setup to have additional dovecot logging

I added to /etc/dovecot/dovecot.conf

auth_debug = yes
auth_verbose = yes

This results in additional dovecot logging - it’s not really a different story than previously, but it does provide some insight into where dovecot is triggered. Maybe I need more debug logs from smtpd

The first log from dovecot

Jul 23 15:45:06 mail dovecot: auth: Debug: auth client connected (pid=0)

The bad lookup starts here

Jul 23 15:45:08 mail dovecot: auth: Debug: master in: USER#0112#011postmaster@mydomain.com#011service=quota-status

The first time we see the alias mapped

Jul 23 15:45:12 mail amavis[3644]: (03644-01) Passed CLEAN {RelayedInbound}, [209.85.208.175]:35636 [209.85.208.175 myusername@gmail.com> -> <user@mydomain.com>, Queue-ID: 35CC314CC83, Message-ID: 

Jul 23 15:45:06 mail postfix/postscreen[4725]: CONNECT from [209.85.208.175]:35636 to [172.17.0.5]:25
Jul 23 15:45:06 mail postfix/dnsblog[4729]: addr 209.85.208.175 listed by domain list.dnswl.org as 127.0.5.0
Jul 23 15:45:06 mail postfix/dnsblog[4731]: addr 209.85.208.175 listed by domain dnsbl.sorbs.net as 127.0.0.6
Jul 23 15:45:06 mail postfix/postscreen[4725]: PASS OLD [209.85.208.175]:35636
Jul 23 15:45:06 mail postfix/smtpd[4737]: connect from mail-lj1-f175.google.com[209.85.208.175]
Jul 23 15:45:06 mail dovecot: auth: Debug: auth client connected (pid=0)
Jul 23 15:45:07 mail postfix/smtpd[4737]: Anonymous TLS connection established from mail-lj1-f175.google.com[209.85.208.175]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
Jul 23 15:45:08 mail policyd-spf[4742]: prepend Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.208.175; helo=mail-lj1-f175.google.com; envelope-from=myusername@gmail.com; receiver=<UNKNOWN>
Jul 23 15:45:08 mail dovecot: auth: Debug: master in: USER#0112#011postmaster@mydomain.com#011service=quota-status
Jul 23 15:45:08 mail dovecot: auth: Debug: passwd-file(postmaster@mydomain.com): lookup: user=postmaster@mydomain.com file=/etc/dovecot/userdb
Jul 23 15:45:08 mail dovecot: auth: passwd-file(postmaster@mydomain.com): unknown user
Jul 23 15:45:08 mail dovecot: auth: Debug: userdb out: NOTFOUND#0112
Jul 23 15:45:08 mail postfix/smtpd[4737]: 35CC314CC83: client=mail-lj1-f175.google.com[209.85.208.175]
Jul 23 15:45:08 mail postfix/cleanup[4743]: 35CC314CC83: message-id=<CAAd3qRu7mfMbmO1ZuHSv1d_Cdnt8CSOPB0Yu5VL5WjQUZkAHVg@mail.gmail.com>
Jul 23 15:45:08 mail opendkim[2911]: 35CC314CC83: mail-lj1-f175.google.com [209.85.208.175] not internal
Jul 23 15:45:08 mail opendkim[2911]: 35CC314CC83: not authenticated
Jul 23 15:45:08 mail opendkim[2911]: 35CC314CC83: DKIM verification successful
Jul 23 15:45:08 mail opendkim[2911]: 35CC314CC83: s=20161025 d=gmail.com SSL
Jul 23 15:45:08 mail opendmarc[2921]: 35CC314CC83 ignoring Authentication-Results at 1 from mail.mydomain.com
Jul 23 15:45:08 mail opendmarc[2921]: 35CC314CC83: gmail.com pass
Jul 23 15:45:08 mail postfix/qmgr[3639]: 35CC314CC83: from=<myusernameame@gmail.com>, size=2710, nrcpt=1 (queue active)
Jul 23 15:45:08 mail postfix/smtpd[4737]: disconnect from mail-lj1-f175.google.com[209.85.208.175] ehlo=2 starttls=1 mail=1 rcpt=1 bdat=1 quit=1 commands=7
Jul 23 15:45:12 mail postfix/smtpd[4772]: connect from localhost[127.0.0.1]
Jul 23 15:45:12 mail dovecot: auth: Debug: auth client connected (pid=0)
Jul 23 15:45:12 mail postfix/smtpd[4772]: BC39614CC87: client=localhost[127.0.0.1]
Jul 23 15:45:12 mail postfix/cleanup[4743]: BC39614CC87: message-id=<CAAd3qRu7mfMbmO1ZuHSv1d_Cdnt8CSOPB0Yu5VL5WjQUZkAHVg@mail.gmail.com>
Jul 23 15:45:12 mail postfix/qmgr[3639]: BC39614CC87: from <myusernamelow@gmail.com>, size=3154, nrcpt=1 (queue active)
Jul 23 15:45:12 mail amavis[3644]: (03644-01) Passed CLEAN {RelayedInbound}, [209.85.208.175]:35636 [209.85.208.175 myusername@gmail.com> -> <user@mydomain.com>, Queue-ID: 35CC314CC83, Message-ID: <CAAd3qRu7mfMbmO1ZuHSv1d_Cdnt8CSOPB0Yu5VL5WjQUZkAHVg@mail.gmail.com>, mail_id: amsKS6kMj5RO, Hits: -0.199, size: 2930, queued_as: BC39614CC87, 4368 ms
Jul 23 15:45:12 mail postfix/smtp[4744]: 35CC314CC83: to=<user@mydomain.com>, orig_to=<postmaster@mydomain.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=4.9, delays=0.51/0.01/0.01/4.4, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as BC39614CC87)
Jul 23 15:45:12 mail postfix/qmgr[3639]: 35CC314CC83: removed
Jul 23 15:45:12 mail dovecot: lmtp(4774): Connect from local
Jul 23 15:45:12 mail dovecot: auth: Debug: master in: USER#0111#011user@mydomain.com#011service=lmtp
Jul 23 15:45:12 mail dovecot: auth: Debug: passwd-file(user@mydomain.com): lookup: user=user@mydomain.com file=/etc/dovecot/userdb
Jul 23 15:45:12 mail dovecot: auth: Debug: userdb out: USER#0111#011user@mydomain.com#011uid=5000#011gid=5000#011home=/var/mail/mydomain.com/user
Jul 23 15:45:13 mail dovecot: lmtp(user@mydomain.com)<4774><B9kkMUgc+2CmEgAAJmGFMg>: sieve: msgid=<CAAd3qRu7mfMbmO1ZuHSv1d_Cdnt8CSOPB0Yu5VL5WjQUZkAHVg@mail.gmail.com>: stored mail into mailbox 'INBOX'
Jul 23 15:45:13 mail postfix/lmtp[4773]: BC39614CC87: to=<user@mydomain.com>, relay=mail.mydomain.com[/var/run/dovecot/lmtp], delay=0.28, delays=0.01/0.03/0.02/0.22, dsn=2.0.0, status=sent (250 2.0.0 <user@mydomain.com> B9kkMUgc+2CmEgAAJmGFMg Saved)
Jul 23 15:45:13 mail dovecot: lmtp(4774): Disconnect from local: Client has quit the connection (state=READY)
Jul 23 15:45:13 mail postfix/qmgr[3639]: BC39614CC87: removed```

Mails are delivered, so this seems only a small cosmetic issue. Possibly, it’s just an option wrongly set somewhere. Before knowing the cause, I can’t decide if the code is not clean (and needs a re-write). In best case, only a small bugfix is needed 😉

I can confirm the problem. I see the same Jul 21 11:41:40 mail dovecot: auth: passwd-file(foo@exmaple): unknown user message in my setup, when receiving an email for an alias.

I never noticed that before 😕

There is certainly something about the postfix-aliases.cf - I map a ./config file into the /tmp/docker-mailserver as part of the container deployment. That file was created on my behalf by docker-mailserver. It is normally empty.

Interesting. you’re right indeed. The file is processed:

https://github.com/docker-mailserver/docker-mailserver/blob/fb77d3f7210ff4501f454020809a72704a350d48/target/scripts/startup/setup-stack.sh#L728-L734

But I’m uncertain as to how we proceed later with it. As you said, the e-mail bounced. I’d go with postfix-virtual.cf under config/ instead.

The bounce makes me think that the patch you’re putting together @georglauterbach will probably fix this - but it also means that you’re right that this is a bit of a mess.

I really don’t think so, because I’m going through postfix-virtual.cf, not postfix-aliases.cf. This just goes to show that our code-base could use some improvements in this regard:)

I do appreciate you pointing me (and others) at the location to start investigating how we might improve upon the alias handling in docker-mailsever. I will try to take a look, but this is probably a bit beyond my current email knowledge.

You’re welcome 😃

From an external DNS point of view - both mail.mydomain.ca and mydomain.ca need to resolve to the external IP you have.

Might be a slight misunderstanding in what I was saying there.

Some services like Postfix to my knowledge can treat a local host differently than an external one. I don’t know when that is the case, so it’s just an assumption that when this applies, if an external DNS request is made when it would have been intended to match /etc/hosts, then that local host (not localhost) behaviour would not occur and it may instead treat it as if handling an external connection (imagine two separate servers you control).

I would think that many users of docker-mailserver would have the same issue. Thus if this is a potential issue, I think it’s something many people will have.

Yeah probably, so it might only apply to niche features that most users don’t use or niche / invalid configurations.

From @georglauterbach:

/etc/aliases - which I think is created using /tmp/docker-mailserver/postfix-aliases.cf - but I’m not certain of that.

I haven’t found anything on that considering our documentation on extra configuration files. AFAIK /etc/aliases really actually is a mess, not by default, just in the way we use it I guess, because it is sometimes used, sometimes not. This section would actually need cleanup. We had issues addressing this problem in the past.

There is certainly something about the postfix-aliases.cf - I map a ./config file into the /tmp/docker-mailserver as part of the container deployment. That file was created on my behalf by docker-mailserver. It is normally empty.

root@mail:/# ls -l /tmp/docker-mailserver/postfix-aliases.cf 
-rw-r--r-- 1 root root 0 Jul 11 15:51 /tmp/docker-mailserver/postfix-aliases.cf

I thought, why not add a ‘local’ alias there? So I did. Changing that file to look like this:

root@mail:/# cat /tmp/docker-mailserver/postfix-aliases.cf 
foobar: roo

This resulted in this appearing in /etc/aliases

root@mail:/# cat /etc/aliases
root: postmaster@mydomain.ca
foobar: roo

Cool I thought - but tried to send email from gmail -> mydomain.ca and it bounced…

Oct 14 17:54:13 mail postfix/postscreen[5966]: CONNECT from [209.85.128.45]:35431 to [172.17.0.2]:25
Oct 14 17:54:13 mail postfix/dnsblog[5970]: addr 209.85.128.45 listed by domain list.dnswl.org as 127.0.5.0
Oct 14 17:54:13 mail postfix/dnsblog[5972]: addr 209.85.128.45 listed by domain dnsbl.sorbs.net as 127.0.0.6
Oct 14 17:54:13 mail postfix/postscreen[5966]: PASS NEW [209.85.128.45]:35431
Oct 14 17:54:13 mail postfix/smtpd[5974]: connect from mail-wm1-f45.google.com[209.85.128.45]
Oct 14 17:54:13 mail postfix/smtpd[5974]: Anonymous TLS connection established from mail-wm1-f45.google.com[209.85.128.45]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
Oct 14 17:54:14 mail policyd-spf[5984]: prepend Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.128.45; helo=mail-wm1-f45.google.com; envelope-from=myaccount@gmail.com; receiver=<UNKNOWN> 
Oct 14 17:54:14 mail dovecot: auth: passwd-file(foobar@mydomain.ca): unknown user 
Oct 14 17:54:14 mail postfix/smtpd[5974]: NOQUEUE: reject: RCPT from mail-wm1-f45.google.com[209.85.128.45]: 550 5.1.1 <foobar@mydomain.ca>: Recipient address rejected: User unknown in virtual mailbox table; from=<myaccount@gmail.com> to=<foobar@mydomain.ca> proto=ESMTP helo=<mail-wm1-f45.google.com>
Oct 14 17:54:14 mail postfix/smtpd[5974]: disconnect from mail-wm1-f45.google.com[209.85.128.45] ehlo=2 starttls=1 mail=1 rcpt=0/1 bdat=0/1 quit=1 commands=5/7

The bounce makes me think that the patch you’re putting together @georglauterbach will probably fix this - but it also means that you’re right that this is a bit of a mess.

I do appreciate you pointing me (and others) at the location to start investigating how we might improve upon the alias handling in docker-mailsever. I will try to take a look, but this is probably a bit beyond my current email knowledge.

From @polarathene :

While I don’t disagree, if you have a mail-server that uses mail.mydomain.ca but sends emails with headers mydomain.ca (mail label stripped), could docker-mailserver upon interacting with either handle them differently, even if it’s responsible for both?

mail and mail.mydomain.ca will resolve as the local container IP, and services should therefore know in the container that it’s local. But any mydomain.ca query will fail to match in /etc/hosts without that alias, thus query public DNS for IP. Is that the expected outcome or could that be a potential issue?

This is certainly something to consider. I would think that many users of docker-mailserver would have the same issue. From an external DNS point of view - both mail.mydomain.ca and mydomain.ca need to resolve to the external IP you have. Thus if this is a potential issue, I think it’s something many people will have.

/etc/aliases - which I think is created using /tmp/docker-mailserver/postfix-aliases.cf - but I’m not certain of that.

I haven’t found anything on that considering our documentation on extra configuration files. AFAIK /etc/aliases really actually is a mess, not by default, just in the way we use it I guess, because it is sometimes used, sometimes not. This section would actually need cleanup. We had issues addressing this problem in the past.

But from I can read here:

In my old (pre-docker-mailserver) mail system - I exclusively used /etc/aliases to manage all of my aliases. I’m not saying using the virtual aliases is wrong - but I wonder if it causes problems here.

It seems we should do a proper cleanup of the scripts and make use of /etc/aliases is a proper way. This would be very much fine with me. The confusion at the moment stems from the fact that aliases are scattered all over the place, and my PR does not do a very good job at improving on the situation other than curing symptoms. But at the same time, I simply don’t have the time anymore to go through the scripts and solve this problem of cleaning up the code. Until someone addresses this issue, my PR could be a solution for the time being.

@andrewlow I would love to see some work being done on the aliases. All users would profit from these changes. If you wan’t to try it, I’d suggest having a look here:

https://github.com/docker-mailserver/docker-mailserver/blob/fb77d3f7210ff4501f454020809a72704a350d48/target/scripts/startup/setup-stack.sh#L683-L736

and here

https://github.com/docker-mailserver/docker-mailserver/blob/fb77d3f7210ff4501f454020809a72704a350d48/target/scripts/check-for-changes.sh#L81-L87

On the topic of Dovecot issues:

/etc/dovecot/userdb

I don’t understand WHY we would add anything for virtual aliases into this file - unless there is something ‘not quite virtual’ about an alias that is specified as alias@example.com user@example.com because they both share the same domain and thus should be local.

All along it’s felt like dovecot shouldn’t get a shot at looking at the email until we’ve decided who the email is supposed to be for. My logic says that the alias mappings should happen before we attempt local delivery.

I also question why config/postfix_aliases.cf is empty, shouldn’t we be specifying local aliases there? My setup uses virtual aliases because that’s what the doc points me at.

Of course – this suggest I should try adding some new aliases to my configuration in config/postfix_aliases.cf to see if this helps remedy the problem for those new aliases.

If the tone of this is wrong - please forgive me. I just am eager to understand how this is supposed to work.

DNS First

I would like to provide my DNS setup here too, just to give a K8s example that works.

root@mail:/$ cat /etc/hostname  # I mounted this file into the container myself
mail

root@mail:/$ cat /etc/hosts     # I mounted this file into the container myself
# IP              FQDN (CANONICAL_HOSTNAME)    ALIASES
# --------------  ---------------------------  -----------------------

127.0.0.1         localhost
127.0.1.1         mail.example.com             mail

root@mail:/$ hostname
mail

root@mail:/$ hostname -f
mail.example.com

root@mail:/$ hostname -d
example.com

root@mail:/$ hostname -s
mail

root@mail:$ echo "${HOSTNAME}"
mail

root@mail:/$ dnsdomainname
example.com

root@mail:/$ echo "${OVERRIDE_HOSTNAME}"
mail.example.com

root@mail:/$ cat /proc/sys/kernel/hostname
mail

# AFAIK the next two commands are expected
# to show `(none)`, see
# https://unix.stackexchange.com/questions/239920/how-to-set-the-fully-qualified-hostname-on-centos-7-0
root@mail:/$ domainname
(none)

root@mail:/$ cat /proc/sys/kernel/domainname
(none)

Now Dovecot’s Issues

The Dovecot issue has (at least to my knowledge) nothing to do with DNS / hostnames. The issue is rather simple: Dovecot tries to look up users in /etc/dovecot/userdb, and because we never add aliases there, Dovecot cannot find them and shows dovecot: auth: passwd-file(...): unknown user . I’m currently working towards adding these users to the Dovecot userdb with the correct directories of the account the alias points to. Tests seem to indicate that there are still some problems. I found target/dovecot/auth-passwdfile.inc to be misconfigured as well. I will fix this too.

Dear lord I think I’m up to something… will post soon again. False alarm, damn it.

So, I can finally present a solution. I’ll have something to eat beforehand, and provide a PR so all of you can have a look.

cat /etc/hosts | grep mydomain

Is the output your containers IP, followed by it’s FQDN and the 1st label? (eg mail, or mydomain, the left most value before the first .).

Does cat /proc/sys/kernel/hostname, hostname, hostname -f and echo "${HOSTNAME}" all equate to the same value? Does it match the single label alias in the /etc/hosts output?

If any of those do not match it may be contributing to the problem.

@polarathene I will try to adjust my K8s setup too to see whether this helps! I currently have an old value under /etc/hostname which, as you said, may contribute to the problem.

run repeat_until_success_or_timeout 20 sh -c "docker logs mail_alisa | grep 'THIS WILL FAIL'"

There is a typo. mail_alisa should be mail_alias.

Time certainly seems to be zooming along here.

I am also not that familiar as I want with postfix & dovecot. That’s why I chose initially this project as my mail setup (to get it working, without knowing each configuration detail in advance) 😄

The good thing however with that issue is, beside the log entrys, there seems no other negative impact.

possible bug in Dovecot (we’ll be upgrading to Debian Bullseye in the image soon for newer software versions)

At least, the newest dovecot version which I am running does not fix it. Or did you mean postfix? I couldn’t find big changes in the changelog, between the postfix versions in debian buster (3.4.14) and bullseye (3.5.6) . Most of them are TLS fixes.

Do any of you have a reliable way to setup and reproduce the problem?

My particular configuration has always exhibited this problem - reference the top post in this issue

I also documented my setup here: https://lowtek.ca/roo/2021/installing-docker-mailserver/

Or can one container be spun up, configured with aliases and connected to interact with the functionality that triggers the problem?

A single container should work - I have not tried to create a test bed environment, but that would be a very good idea.

What is weird - from my (naive) digging into this - is that is appears dovecot is invoked too early in the process. Like - why does the mail system try ‘local’ mail delivery of the email, before mapping the email via the aliases?

It is also a little suspicious - that while I’m hosting a single domain - (mydomain.ca) I am using virtual aliases to configure email aliases (foo@mydomain.ca -> reallyme@mydomain.ca). In my past setups (not using this project) - I used the /etc/aliases file and didn’t need to specify the domains in my alias file. I’m not sure that this isn’t a factor.

Do any of you have a reliable way to setup and reproduce the problem?

As of yet, no.

Does it require more than one instance of docker-mailserver to simulate a reproduction? Or can one container be spun up, configured with aliases and connected to interact with the functionality that triggers the problem?

No, it seems to appear with Docker, Docker Compose and K8s, platform independent. One container suffices. You’ll need to have aliases set up.

---

I wonder if this is specific to the dovecot version we use. I wouldn’t be surprised if it’s a bug.

I thought about this too. But then, maybe Dovecot has aliases like Postfix too? We’re not generating them if they’re needed… which could be the problem.

Anyone have ideas on how to track down what is happening here?

Unfortunately not. But I am also very interested to track that down / fix that issue. If there is anything I can test etc., just let me know.

Actually @georglauterbach please assign #2108 to me, this one - I still don’t know how to solve.

However - once more people have correctly configured logwatch – they will start seeing the alias/dovecot login failures every day.

I think I figured out what is wrong with logwatch https://github.com/docker-mailserver/docker-mailserver/issues/2108

I just recently started using aliases (three days ago) and haven’t since looked back at the logs. I will raise the priority of this issue. Since it does not seem to affect operation, medium priority suffices.

However, this goes to show that the alias code is not as clean as we‘d like, and a re-write is actually necessary. @andrewlow would you be willing to help us tackle this? @casperklein @wernerfred @polarathene do you agree that aliases need a code overhaul / rewrite?