Alright, I actually think I might have solved it. Earlier, I sent an email from this account to both of my server accounts at the same time and tracked down the log entries for them. Here was my postfix log:
Jan 02 23:13:15 example.com postfix/local[10106]: 79078120D26: to=<user@example.com>, relay=local, delay=0.12, delays=0.08/0/0/0.03, dsn=2.0.0, status=sent (delivered to command: /usr/lib/dovecot/deliver)
...
Jan 02 23:13:15 example.com postfix/virtual[10134]: 89786120D23: to=<user@example.net>, relay=virtual, delay=0.1, delays=0.09/0/0/0, dsn=2.0.0, status=sent (delivered to maildir)
This is when I realized the reason these two accounts have been acting so differently is because postfix has an alternate transport for virtual accounts that needs to be set up apparently. Dovecot had this documentation which finally helped me put the final pieces together:
<https://doc.dovecot.org/2.4.2/howto/lda.html>
In my /etc/postfix/master.cf I had:
spamassassin unix - n n - - pipe
user=debian-spamd argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
So I added this to the end of my /etc/postfix/main.cf:
virtual_transport = spamassassin
dovecot_destination_recipient_limit = 1
After reloading, this seemed to finally allow for both accounts to receive mail through dovecot properly, which then allows me to read it from Thunderbird.
Jan 03 01:24:11 example.com postfix/local[12072]: 759EE120DBF: to=<goblin@example.com>, relay=local, delay=0.09, delays=0.05/0.01/0/0.03, dsn=2.0.0, status=sent (delivered to command: /usr/lib/dovecot/deliver)
...
Jan 03 01:24:12 example.com postfix/pipe[12067]: D517E120D9D: to=<user@example.net>, relay=spamassassin, delay=1.2, delays=0.23/0.01/0/0.99, dsn=2.0.0, status=sent (delivered via spamassassin service)
The docs also give advice on how to transport it to dovecot-lda or dovecot-lmtp. I'm not sure what the optimal setup here, a lot of my starting point was this setup script:
<https://github.com/LukeSmithxyz/emailwiz/blob/master/emailwiz.sh>
Which has a lot of the basics lined out, but is unfortunately old enough that a lot of the features it uses were depricated when the API changed. Plus it does not use virtual mailboxes or aliases in its example, opting instead to only use linux users. I'm sure that my configuration is sort of slapped together though, but it still manages to work somehow?
I would be interested if anybody has insight about my configuration or how to optimize it. For my purposes, this definitely seems like good enough though. Hopefully the question helps someone else later, there seems to be a lack of info on this topic (at least collated together in a more helpful way). Will probably aspire to write a guide on my setup once the server is complete and secured.
~ Ethan Merrill
On Friday, January 2nd, 2026 at 6:41 PM, animerrill--- via dovecot <dovecot@dovecot.org> wrote:
Thank you David and Chris, I appreciate your replies. Fortunately, I did actually manage to solve this virtual user authentication issue. However, it seems there is still some issue that prevents Thunderbird from being able to download mail from imap.
First the matter of the multiple database authentication issue. My
doveconfremains the same as when I last reported it. The major changes were in my postfix login map and my passwd-file for the virtual mailbox. In/etc/postfix/main.cfI havesmtpd_sender_login_maps = pcre:/etc/postfix/login_maps.pcre. In that file, I previously only had the first line for my main domain and I had to add a second for the hosted domain:
/^(.*)@example\\.com$/ ${1} /^(.*)@example\\.net$/ ${1}@example.netFor some reason this is required to get postfix to recognize that accounts from
example.netare valid, or to otherwise be handed off to authentication properly. The other mistake was in my passwd-file at/etc/dovecot/passwd/example.netwhere I did not properly specify the password format:
user@example.net:{crypt}...long..hash...::/var/postfix/virtual/example.net/user::With these changes, I am able to login to Thunderbird as
user@example.net. I can send mail fromuser@example.net, and allegedly look at my mailboxes on the server for this user. However, due to some weird quirk I cannot actually collect mail from my inbox on the server.For
user@example.com, who is a linux user with a home directory, this is seemingly no problem and their mailbox is set up according to the configuration:
/home/user/ Mail/ Inbox/ mailboxes/ ...indexes and logs...However our virtual mailbox for
user@example.netlooks like this:
/var/postfix/virtual/example.net/user/ Mail/ Inbox/ mailboxes/ ...indexes and logs... cur/ mailboxes/ new/ tmp/ subscriptions ...indexes and logs...Clearly dovecot is trying it's best to make the Mail directory as defined in the conf for the virtual user in their defined home. However, the mail is instead delivered to the
newdirectory which is not configured to be there. This confirms this user is actually recieving all mail sent to it, but because the inbox is not configured correctly (somehow) it is not possible to actually read it in Thunderbird.From what I've read this pattern (cur, new, and tmp directories) is associated with Maildir, which is confusing because the mail_driver is explicitly set to
sdbox. I am not sure how to resolve this, or where exactly the issue is being caused.
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org