The support for mixing virtual users, with fully-qualified email addresses, and system users could be simpler. Assuming it doesn’t mess up other stuff in the code base, of course 😊.

You can define multiple passdb's not?

The problem appears to be that the PAM passwd module requires just user names without a domain

I am not even sure this is true, but the idea behind PAM (pluggable authentication module) you create your own or add any you like. Can't imagine there is nothing that takes an email address.

(which makes sense given that they’re system users) but does not, so far as I can see, support the username_format argument. In my setup, the default structure of 10-auth.conf demonstrates this:

auth_username_format = %n

So do not change it? Leave it as how people enter it.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

Hi,

I do have a solution for this - one which you probably don't want to hear ... I keep all email separate from system accounts, for any system accounts that are going to generate, or receive email I alias them.

On Sat, 2022-03-26 at 17:32 +0000, Mark Olbert wrote:

The support for mixing virtual users, with fully-qualified email addresses, and system users could be simpler. Assuming it doesn’t mess up other stuff in the code base, of course 😊.

Question you are mixing virtual, and system users for domain "A" - is this the only domain hosted on the server? If so then there is probably an easy way to do this. Assuming you MTA is Postfix are you mixing Virtual Mailbox Domains, Virtual Alias Domains? Virtual Alias Domains can mix virtual accounts with UNIX system accounts: (https://www.postfix.org/VIRTUAL_README.html#virtual_alias)

The problem appears to be that the PAM passwd module requires just user names without a domain (which makes sense given that they’re system users) but does not, so far as I can see, support the username_format argument. In my setup, the default structure of 10- auth.conf demonstrates this:

I see that someone else has answered this in another post - I would refer you to them.

My approach of making all the domains I host completely virtual does have benefits:

1. Adding a user system account doesn't mean they get an email   acccount
2. Migrating email service from one machine to another is trivial  since all information regarding email account is kept in an external source (in my case LDAP, but could be another database or flat files)
3. If you want the option to create mail accounts with system accounts then all you need to do is augment the solution you use for adding system accounts so that the appropriate entries get added where need be - LDAP is good for this since it can also be used to auth your system accounts, and with the correct additions to the schema you can easily flag accounts as being able to receive email or not. (When I met Wietse at a conference in 2006 I asked him about Postfix LDAP schema - he advised me to write my own, which is what I have done. The resulting LDAP search that Postfix carries out before handing messages off to Dovecot for delivery includes a check to see if the account is allowed to receive email at all, or if it is aliased to a different address). The search Dovecot runs is similarly enabled.

In this day and age it is odd that a system would be hosting email for a domain for delivery to system users - normally your system users have different email addresses for email delivery.

Nikolai Lusan nikolai@lusan.id.au -----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAmJC87sACgkQ4ZaDRV2V L6S2zw/+JepsnV9nrVQa8q67QNgaLuH9u5fVUlFK2LxDqb0B2r7AoOi289+u8Pqu ZBnF73bPR5WzDDc4wRV+nnW47hnck+oWsxXaqV/ogkBckflg5U7l9QtXtngFOluM EAPQyUH4vIDxrsfkXA2T4mS1qen9dyWnH6fUaQVwQuwZFpK0ety9rDPEK5bvX/M/ 0PeG/6j/ibmZ4MjY/fadLAJwegBYb92QkTgI1W8s42AojF+G13pg2Yd1Kim6xfta JVvpTDzRfy82BHGMOy9snTUJrNndqSD6++n3EuXwzt3WuuNiZWoMUDM8pkhupKty A0zpCqAH1oKKbo3O6c0WlbtW2SVJCwO357TyxeYizww102O9E98PgqJQo70S2jur XgsP6mM0CgolFUt5ATF9ZmiEfsnXWahHsaKq/sucpIx+DPrqlviSv9tcB0Bxunar 2IZKm63gIJ9yEtO1uVwtyekK8AQja/3GxULOZLnb7/iRVnY/rl2aoPj+QVF2qlH/ H8H4u3e7u9mLBO365lPsm0DepF9hQX64XSzbG6mfnZDXKgF7tOxebXQLe+PraPEE h8hjel/EJwKwGbJVlbY+MQ8RSlfYAYjNygqgOYTv2bKQfS+x+j7ujlPNKPKN7Zlv GeAcZ8S/NhISX/6Xq1CHco16Qg9n6ynt4wTg+a/J0cUm1jebs6E= =qTQQ -----END PGP SIGNATURE-----