I was wondering if this was a good use case for the creation of a user without a dedicated home directory.

The user will not be able to 'log in' in the traditional way, but they would have an entry in /etc/passwd. Then you would only need to create a link from /home/user into your selected location (in your instance /var/postfix/virtual/example.net/[user <http://example.net/user>Name] ).

please note : this isn't something that I have done, but I'm sure there are other more experienced admins on this list that will pipe up if this is not a good solution, and explain why its not, and propose alternatives.

Le mer. 31 déc. 2025 à 09:55, animerrill--- via dovecot <dovecot@dovecot.org> a écrit :

...

I simply define my virtual domains in Postfix:

VIRTUAL DOMAINS

virtual_alias_domains = new.domain virtual_alias_maps = hash:/etc/postfix/virtual Then, in /etc/postfix/virtual, I add the alias: newuser@new.domain newuser And that’s it. Could you share your doveconf -n?

That set up is different than what I am trying to achieve. You have a virtual alias set up, which redirects mail from an email address to an arbitrary linux user. I am trying to avoid creating linux users for every email account, which is why I need to be able to use dovecot's multiple authentication database feature to facilitate virtual mailboxes. Here is that section from my /etc/postfix/main.cf:

virtual_mailbox_domains = example.net
virtual_uid_maps = static:1001
virtual_gid_maps = static:1001
virtual_mailbox_base = /var/postfix/virtual
virtual_mailbox_maps = hash:/etc/postfix/virtual/recipients
virtual_alias_maps = hash:/etc/postfix/virtual/aliases
virtual_alias_domains = hash:/etc/postfix/virtual/domains

Then the mailbox is defined in /etc/postfix/virtual/recipients:

user@example.net    example.net/user

Which means that rather than being set up as a linux user with a /home directory, user@example.net should have a virtual mailbox in /var/postfix/virtual/example.net/user. This actually works as far as postfix is concerned, and as the root user I can peek in that folder to see a message sent to it from my personal email account. Then here is doveconf -n:

# 2.4.1-4 (7d8c0e5759): /etc/dovecot/dovecot.conf
# Pigeonhole version 2.4.1-4 (0a86619f)
# OS: Linux 6.12.57+deb13-amd64 x86_64 Debian 13.2
# Hostname: example.com
dovecot_config_version = 2.4.1
auth_mechanisms = plain login
auth_username_format = %{user}
dovecot_storage_version = 2.4.1
mail_driver = sdbox
mail_inbox_path = ~/Mail/Inbox
mail_path = ~/Mail
protocols = imap
ssl = required
ssl_server {
  cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
  dh_file = /usr/share/dovecot/dh.pem
  key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
  prefer_ciphers = server
}
userdb passwd-file {
  passwd_file_path = /etc/dovecot/passwd/%{user | domain}
}
userdb passwd {
}
passdb passwd-file {
  passwd_file_path = /etc/dovecot/passwd/%{user | domain}
}
passdb pam {
}
namespace inbox {
  inbox = yes
  mailbox Drafts {
    auto = subscribe
    special_use = "\\Drafts"
  }
  mailbox Junk {
    auto = subscribe
    autoexpunge = 30d
    special_use = "\\Junk"
  }
  mailbox Sent {
    auto = subscribe
    special_use = "\\Sent"
  }
  mailbox Trash {
    special_use = "\\Trash"
  }
  mailbox Archive {
    special_use = "\\Archive"
  }
}
service auth {
  unix_listener /var/spool/postfix/private/auth {
    group = postfix
    mode = 0660
    user = postfix
  }
}
protocol lda {
  mail_plugins = sieve
}
protocol lmtp {
  mail_plugins = sieve
}
protocol pop3 {
  pop3_no_flag_updates = yes
  pop3_uidl_format = UID%{uid}-%{uidvalidity}
}
sieve_script default {
}

Basically the problem is that this virtual mailbox user has a mailbox that receives mail, but the user cannot log onto their account with an email client. My guess is that I either have misconfigured the userdb and/or passdb entries in the dovecot.conf file, or the passwd-file at /etc/dovecot/passwd/example.net I created is not formatted correctly, because the ultimate problem is that the system cannot authenticate the user when they attempt to connect via imap/smtp. From all of the documentation and help threads referenced in my first message, I cannot tell what I've done wrong and I'm at a total loss.

Thanks for the prompt reply. This is my first time using one of these mail lists, so I did not see you responded right away.

---

dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org

I was wondering if this was a good use case for the creation of a user without a dedicated home directory. The user will not be able to 'log in' in the traditional way, but they would have an entry in /etc/passwd. Then you would only need to create a link from /home/user into your selected location (in your instance /var/postfix/virtual/[1]example.net/[userName] ). please note : this isn't something that I have done, but I'm sure there are other more experienced admins on this list that will pipe up if this is not a good solution, and explain why its not, and propose alternatives.

Le mer. 31 dec. 2025 `a 09:55, animerrill--- via dovecot <[2]dovecot@dovecot.org> a ecrit :

 > I simply define my virtual domains in Postfix:
 > ==============================
 > VIRTUAL DOMAINS
 > ==============================
 >
 > virtual_alias_domains = new.domain
 > virtual_alias_maps = hash:/etc/postfix/virtual
 > Then, in /etc/postfix/virtual, I add the alias:
 > newuser@new.domain   newuser
 > And that's it.
 > Could you share your doveconf -n?

 That set up is different than what I am trying to achieve. You have a
 virtual alias set up, which redirects mail from an email address to an
 arbitrary linux user. I am trying to avoid creating linux users for
 every email account, which is why I need to be able to use dovecot's
 multiple authentication database feature to facilitate virtual
 mailboxes. Here is that section from my /etc/postfix/[3]main.cf:

 ```
 virtual_mailbox_domains = [4]example.net
 virtual_uid_maps = static:1001
 virtual_gid_maps = static:1001
 virtual_mailbox_base = /var/postfix/virtual
 virtual_mailbox_maps = hash:/etc/postfix/virtual/recipients
 virtual_alias_maps = hash:/etc/postfix/virtual/aliases
 virtual_alias_domains = hash:/etc/postfix/virtual/domains
 ```

 Then the mailbox is defined in /etc/postfix/virtual/recipients:

 ```
 [5]user@example.net    [6]example.net/user
 ```

 Which means that rather than being set up as a linux user with a /home
 directory, [7]user@example.net should have a virtual mailbox in
 /var/postfix/virtual/[8]example.net/user. This actually works as far as
 postfix is concerned, and as the root user I can peek in that folder to
 see a message sent to it from my personal email account. Then here is
 `doveconf -n`:

 ```
 # 2.4.1-4 (7d8c0e5759): /etc/dovecot/dovecot.conf
 # Pigeonhole version 2.4.1-4 (0a86619f)
 # OS: Linux 6.12.57+deb13-amd64 x86_64 Debian 13.2
 # Hostname: [9]example.com
 dovecot_config_version = 2.4.1
 auth_mechanisms = plain login
 auth_username_format = %{user}
 dovecot_storage_version = 2.4.1
 mail_driver = sdbox
 mail_inbox_path = ~/Mail/Inbox
 mail_path = ~/Mail
 protocols = imap
 ssl = required
 ssl_server {
   cert_file = /etc/letsencrypt/live/[10]mail.example.com/fullchain.pem
   dh_file = /usr/share/dovecot/dh.pem
   key_file = /etc/letsencrypt/live/[11]mail.example.com/privkey.pem
   prefer_ciphers = server
 }
 userdb passwd-file {
   passwd_file_path = /etc/dovecot/passwd/%{user | domain}
 }
 userdb passwd {
 }
 passdb passwd-file {
   passwd_file_path = /etc/dovecot/passwd/%{user | domain}
 }
 passdb pam {
 }
 namespace inbox {
   inbox = yes
   mailbox Drafts {
     auto = subscribe
     special_use = "\\Drafts"
   }
   mailbox Junk {
     auto = subscribe
     autoexpunge = 30d
     special_use = "\\Junk"
   }
   mailbox Sent {
     auto = subscribe
     special_use = "\\Sent"
   }
   mailbox Trash {
     special_use = "\\Trash"
   }
   mailbox Archive {
     special_use = "\\Archive"
   }
 }
 service auth {
   unix_listener /var/spool/postfix/private/auth {
     group = postfix
     mode = 0660
     user = postfix
   }
 }
 protocol lda {
   mail_plugins = sieve
 }
 protocol lmtp {
   mail_plugins = sieve
 }
 protocol pop3 {
   pop3_no_flag_updates = yes
   pop3_uidl_format = UID%{uid}-%{uidvalidity}
 }
 sieve_script default {
 }
 ```

 Basically the problem is that this virtual mailbox user has a mailbox
 that receives mail, but the user cannot log onto their account with an
 email client. My guess is that I either have misconfigured the `userdb`
 and/or `passdb` entries in the dovecot.conf file, or the passwd-file at
 /etc/dovecot/passwd/[12]example.net I created is not formatted
 correctly, because the ultimate problem is that the system cannot
 authenticate the user when they attempt to connect via imap/smtp. From
 all of the documentation and help threads referenced in my first
 message, I cannot tell what I've done wrong and I'm at a total loss.

 Thanks for the prompt reply. This is my first time using one of these
 mail lists, so I did not see you responded right away.
 _______________________________________________
 dovecot mailing list -- [13]dovecot@dovecot.org
 To unsubscribe send an email to [14]dovecot-leave@dovecot.org

References

Visible links

1. http://example.net/user
2. mailto:dovecot@dovecot.org
3. http://main.cf/
4. http://example.net/
5. mailto:user@example.net
6. http://example.net/user
7. mailto:user@example.net
8. http://example.net/user
9. http://example.com/
10. http://mail.example.com/fullchain.pem
11. http://mail.example.com/privkey.pem
12. http://example.net/
13. mailto:dovecot@dovecot.org
14. mailto:dovecot-leave@dovecot.org

Yes I had thought of that idea too ... but I have a preference for creating the home then adding in a link to the required location.

It creates the opportunity for creating an 'actual' home in the future if required.

Le ven. 2 janv. 2026 à 22:12, Chris Twinn <chris@twinn.co.uk> a écrit :

Would that not be akin to a nologin shell?

Set the user home to /var/postfix/virtual/example.net/usename on creation.

useradd -d /var/postfix/virtual/example.net/username -s /sbin/nologin username

Personally I prefer /home/example.net/username but.

Bypassing creating a link from /home/username to the /var....

User can then be verfied by the system for mails but can't actually access the system. Dovecot/postfix reads the home dir and delivers mail where required.

Again I'm sure there are other more experienced admins.....

On 2 January 2026 19:35:39 GMT, David Myers via dovecot < dovecot@dovecot.org> wrote:

...

I was wondering if this was a good use case for the creation of a user without a dedicated home directory.

The user will not be able to 'log in' in the traditional way, but they would have an entry in /etc/passwd. Then you would only need to create a link from /home/user into your selected location (in your instance /var/postfix/virtual/example.net/[user <http://example.net/%5Buser> <http://example.net/user>Name] ).

please note : this isn't something that I have done, but I'm sure there are other more experienced admins on this list that will pipe up if this is not a good solution, and explain why its not, and propose alternatives.

Le mer. 31 déc. 2025 à 09:55, animerrill--- via dovecot <dovecot@dovecot.org> a écrit :

I simply define my virtual domains in Postfix:

...

...

---

VIRTUAL DOMAINS

virtual_alias_domains = new.domain virtual_alias_maps = hash:/etc/postfix/virtual Then, in /etc/postfix/virtual, I add the alias: newuser@new.domain newuser And that’s it. Could you share your doveconf -n?

That set up is different than what I am trying to achieve. You have a virtual alias set up, which redirects mail from an email address to an arbitrary linux user. I am trying to avoid creating linux users for every email account, which is why I need to be able to use dovecot's multiple authentication database feature to facilitate virtual mailboxes. Here is that section from my /etc/postfix/main.cf:

virtual_mailbox_domains = example.net
virtual_uid_maps = static:1001
virtual_gid_maps = static:1001
virtual_mailbox_base = /var/postfix/virtual
virtual_mailbox_maps = hash:/etc/postfix/virtual/recipients
virtual_alias_maps = hash:/etc/postfix/virtual/aliases
virtual_alias_domains = hash:/etc/postfix/virtual/domains

Then the mailbox is defined in /etc/postfix/virtual/recipients:

user@example.net    example.net/user

Which means that rather than being set up as a linux user with a /home directory, user@example.net should have a virtual mailbox in /var/postfix/virtual/example.net/user. This actually works as far as postfix is concerned, and as the root user I can peek in that folder to see a message sent to it from my personal email account. Then here is doveconf -n:

# 2.4.1-4 (7d8c0e5759): /etc/dovecot/dovecot.conf
# Pigeonhole version 2.4.1-4 (0a86619f)
# OS: Linux 6.12.57+deb13-amd64 x86_64 Debian 13.2
# Hostname: example.com
dovecot_config_version = 2.4.1
auth_mechanisms = plain login
auth_username_format = %{user}
dovecot_storage_version = 2.4.1
mail_driver = sdbox
mail_inbox_path = ~/Mail/Inbox
mail_path = ~/Mail
protocols = imap
ssl = required
ssl_server {
  cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
  dh_file = /usr/share/dovecot/dh.pem
  key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
  prefer_ciphers = server
}
userdb passwd-file {
  passwd_file_path = /etc/dovecot/passwd/%{user | domain}
}
userdb passwd {
}
passdb passwd-file {
  passwd_file_path = /etc/dovecot/passwd/%{user | domain}
}
passdb pam {
}
namespace inbox {
  inbox = yes
  mailbox Drafts {
    auto = subscribe
    special_use = "\\Drafts"
  }
  mailbox Junk {
    auto = subscribe
    autoexpunge = 30d
    special_use = "\\Junk"
  }
  mailbox Sent {
    auto = subscribe
    special_use = "\\Sent"
  }
  mailbox Trash {
    special_use = "\\Trash"
  }
  mailbox Archive {
    special_use = "\\Archive"
  }
}
service auth {
  unix_listener /var/spool/postfix/private/auth {
    group = postfix
    mode = 0660
    user = postfix
  }
}
protocol lda {
  mail_plugins = sieve
}
protocol lmtp {
  mail_plugins = sieve
}
protocol pop3 {
  pop3_no_flag_updates = yes
  pop3_uidl_format = UID%{uid}-%{uidvalidity}
}
sieve_script default {
}

Basically the problem is that this virtual mailbox user has a mailbox that receives mail, but the user cannot log onto their account with an email client. My guess is that I either have misconfigured the userdb and/or passdb entries in the dovecot.conf file, or the passwd-file at /etc/dovecot/passwd/example.net I created is not formatted correctly, because the ultimate problem is that the system cannot authenticate the user when they attempt to connect via imap/smtp. From all of the documentation and help threads referenced in my first message, I cannot tell what I've done wrong and I'm at a total loss.

Thanks for the prompt reply. This is my first time using one of these mail lists, so I did not see you responded right away.

dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org

Yes I had thought of that idea too ... but I have a preference for creating the home then adding in a link to the required location. It creates the opportunity for creating an 'actual' home in the future if required. Le ven. 2 janv. 2026 `a 22:12, Chris Twinn <[1]chris@twinn.co.uk> a ecrit :

 Would that not be akin to a nologin shell?

 Set the user home to /var/postfix/virtual/[2]example.net/usename on
 creation.

 useradd -d  /var/postfix/virtual/[3]example.net/username -s
 /sbin/nologin username

 Personally I prefer /home/[4]example.net/username but.

 Bypassing creating a link from /home/username to the /var....

 User can then be verfied by the system for mails but can't actually
 access the system. Dovecot/postfix reads the home dir and delivers mail
 where required.

 Again I'm sure there are
 other more experienced admins.....

 On 2 January 2026 19:35:39 GMT, David Myers via dovecot
 <[5]dovecot@dovecot.org> wrote:

I was wondering if this was a good use case for the creation of a user without a dedicated home directory.

The user will not be able to 'log in' in the traditional way, but they would have an entry in /etc/passwd. Then you would only need to create a link from /home/user into your selected location (in your instance /var/postfix/virtual/[6]example.net/[user <[7]http://example.net/user>Name] ).

please note : this isn't something that I have done, but I'm sure there are other more experienced admins on this list that will pipe up if this is not a good solution, and explain why its not, and propose alternatives.

Le mer. 31 dec. 2025 `a 09:55, animerrill--- via dovecot <[8]dovecot@dovecot.org> a ecrit :

I simply define my virtual domains in Postfix:

VIRTUAL DOMAINS

virtual_alias_domains = new.domain virtual_alias_maps = hash:/etc/postfix/virtual Then, in /etc/postfix/virtual, I add the alias: newuser@new.domain newuser And that's it. Could you share your doveconf -n?

That set up is different than what I am trying to achieve. You have a virtual alias set up, which redirects mail from an email address to an arbitrary linux user. I am trying to avoid creating linux users for every email account, which is why I need to be able to use dovecot's multiple authentication database feature to facilitate virtual mailboxes. Here is that section from my /etc/postfix/[9]main.cf:

virtual_mailbox_domains = [10]example.net
virtual_uid_maps = static:1001
virtual_gid_maps = static:1001
virtual_mailbox_base = /var/postfix/virtual
virtual_mailbox_maps = hash:/etc/postfix/virtual/recipients
virtual_alias_maps = hash:/etc/postfix/virtual/aliases
virtual_alias_domains = hash:/etc/postfix/virtual/domains

Then the mailbox is defined in /etc/postfix/virtual/recipients:

[11]user@example.net    [12]example.net/user

Which means that rather than being set up as a linux user with a /home directory, [13]user@example.net should have a virtual mailbox in /var/postfix/virtual/[14]example.net/user. This actually works as far as postfix is concerned, and as the root user I can peek in that folder to see a message sent to it from my personal email account. Then here is doveconf -n:

# 2.4.1-4 (7d8c0e5759): /etc/dovecot/dovecot.conf
# Pigeonhole version 2.4.1-4 (0a86619f)
# OS: Linux 6.12.57+deb13-amd64 x86_64 Debian 13.2
# Hostname: [15]example.com
dovecot_config_version = 2.4.1
auth_mechanisms = plain login
auth_username_format = %{user}
dovecot_storage_version = 2.4.1
mail_driver = sdbox
mail_inbox_path = ~/Mail/Inbox
mail_path = ~/Mail
protocols = imap
ssl = required
ssl_server {
  cert_file = /etc/letsencrypt/live/[16]mail.example.com/fullchain.pem
  dh_file = /usr/share/dovecot/dh.pem
  key_file = /etc/letsencrypt/live/[17]mail.example.com/privkey.pem
  prefer_ciphers = server
}
userdb passwd-file {
  passwd_file_path = /etc/dovecot/passwd/%{user | domain}
}
userdb passwd {
}
passdb passwd-file {
  passwd_file_path = /etc/dovecot/passwd/%{user | domain}
}
passdb pam {
}
namespace inbox {
  inbox = yes
  mailbox Drafts {
    auto = subscribe
    special_use = "\\Drafts"
  }
  mailbox Junk {
    auto = subscribe
    autoexpunge = 30d
    special_use = "\\Junk"
  }
  mailbox Sent {
    auto = subscribe
    special_use = "\\Sent"
  }
  mailbox Trash {
    special_use = "\\Trash"
  }
  mailbox Archive {
    special_use = "\\Archive"
  }
}
service auth {
  unix_listener /var/spool/postfix/private/auth {
    group = postfix
    mode = 0660
    user = postfix
  }
}
protocol lda {
  mail_plugins = sieve
}
protocol lmtp {
  mail_plugins = sieve
}
protocol pop3 {
  pop3_no_flag_updates = yes
  pop3_uidl_format = UID%{uid}-%{uidvalidity}
}
sieve_script default {
}

Basically the problem is that this virtual mailbox user has a mailbox that receives mail, but the user cannot log onto their account with an email client. My guess is that I either have misconfigured the userdb and/or passdb entries in the dovecot.conf file, or the passwd-file at /etc/dovecot/passwd/[18]example.net I created is not formatted correctly, because the ultimate problem is that the system cannot authenticate the user when they attempt to connect via imap/smtp. From all of the documentation and help threads referenced in my first message, I cannot tell what I've done wrong and I'm at a total loss.

Thanks for the prompt reply. This is my first time using one of these mail lists, so I did not see you responded right away.

dovecot mailing list -- [19]dovecot@dovecot.org To unsubscribe send an email to [20]dovecot-leave@dovecot.org

References

Visible links

1. mailto:chris@twinn.co.uk
2. http://example.net/usename
3. http://example.net/username
4. http://example.net/username
5. mailto:dovecot@dovecot.org
6. http://example.net/%5Buser
7. http://example.net/user
8. mailto:dovecot@dovecot.org
9. http://main.cf/
10. http://example.net/
11. mailto:user@example.net
12. http://example.net/user
13. mailto:user@example.net
14. http://example.net/user
15. http://example.com/
16. http://mail.example.com/fullchain.pem
17. http://mail.example.com/privkey.pem
18. http://example.net/
19. mailto:dovecot@dovecot.org
20. mailto:dovecot-leave@dovecot.org

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 doveconf remains 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.cf I have smtpd_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.net

For some reason this is required to get postfix to recognize that accounts from example.net are valid, or to otherwise be handed off to authentication properly. The other mistake was in my passwd-file at /etc/dovecot/passwd/example.net where 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 from user@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.net looks 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 new directory 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

These ended up all being pretty good tips, so thanks for the advice. I had indeed already set up SASL but the other two ended up being the key to getting all the features I wanted.

It's always rewarding but baffling how good open source software can be and how all these separate programs controlling single functions can dance in harmony. But at the same time, confusing docs and places like StackOverflow can make it hard to find all the answers you need sometimes... at least for beginners and everyone is a beginner at some point with every piece of software.

Gonna get my whole website config setup, then I will probably try to convert a lot of these notes into a guide. Thanks everyone for the help~!

~ Ethan Merrill

On Saturday, January 3rd, 2026 at 4:51 PM, Nick Tait via dovecot <dovecot@dovecot.org> wrote:

On 03/01/2026 19:50, Ethan Merrill via dovecot wrote:

...

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.

Hi Ethan.

It sounds like in the process of getting this working you're getting a good understanding of the mechanics of how Dovecot and Postfix work! :-)

Here are some ideas to consider as next steps:

• You've probably done this already, but if not, it would be worth setting up SASL authentication between Postfix and Dovecot, so that Postfix can get Dovecot to authenticate users submitting emails. https://doc.dovecot.org/2.4.2/howto/sasl/postfix.html
• You could set up Dovecot to do LMTP, and use that as your 'virtual' transport in Postfix/SpamAssassin. The advantages of doing this is that you no longer need to configure a custom transport ("dovecot") in Postfix, and you can deliver an email to more than one recipient in a single LMTP conversation (instead of launching a separate 'dovecot-lda' process for each recipient). https://doc.dovecot.org/2.4.2/howto/lmtp/postfix.html
• You could vastly simplify your Postfix configuration, by getting rid of your 'local' transport completely, and have all emails delivered via your 'virtual' transport. The idea here is that Postfix uses Dovecot to authenticate users and deliver emails, so it shouldn't need to concern itself with whether a user is a 'system' user or a 'virtual' user.

Nick. On 03/01/2026 19:50, Ethan Merrill via dovecot wrote:

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.

Hi Ethan.

It sounds like in the process of getting this working you're getting a good understanding of the mechanics of how Dovecot and Postfix work! :-)

Here are some ideas to consider as next steps:

o You've probably done this already, but if not, it would be worth setting up SASL authentication between Postfix and Dovecot, so that Postfix can get Dovecot to authenticate users submitting emails. [1]https://doc.dovecot.org/2.4.2/howto/sasl/postfix.html o You could set up Dovecot to do LMTP, and use that as your 'virtual' transport in Postfix/SpamAssassin. The advantages of doing this is that you no longer need to configure a custom transport ("dovecot") in Postfix, and you can deliver an email to more than one recipient in a single LMTP conversation (instead of launching a separate 'dovecot-lda' process for each recipient). [2]https://doc.dovecot.org/2.4.2/howto/lmtp/postfix.html o You could vastly simplify your Postfix configuration, by getting rid of your 'local' transport completely, and have all emails delivered via your 'virtual' transport. The idea here is that Postfix uses Dovecot to authenticate users and deliver emails, so it shouldn't need to concern itself with whether a user is a 'system' user or a 'virtual' user.

Nick.

References

Visible links

1. https://doc.dovecot.org/2.4.2/howto/sasl/postfix.html
2. https://doc.dovecot.org/2.4.2/howto/lmtp/postfix.html

---

dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org