lmtp userdb can't resolve users
Hello,
I use postfix with dovecot as an lmtp LDA with unix users and multiple domain names and mailboxes in Maildir format placed in domain directory like:
/home/mainuser/homes/user@domain.tld/Maildir or /home/mainuser/domains/domain2.tld/homes/user@domain2.tld/Maildir
which have the main user as a group and user@domain.tld/user@domain2.tld as owner
Postfix have virtual_alias_maps = hash:/etc/postfix/virtual
there in virtual file there is map like:
user@domain.tld user-domain@domain.tld
and in /etc/passwd
there are actually 2 users with the same home dir and same UID/GID (only the username is different)
and in postfix mailbox_transport = lmtp:unix:private/dovecot-lmtp
The issue is that when postfix passes the email for local delivery to dovecot lmtp it sends the username as user-domain.tld@serverhostname.tld but dovecot is configured with !include auth-system.conf.ext
can't resolve this username thus fails to deliver.
I've found a workaround in the net to use custom userdb just for lmtp like this:
protocol lmtp { mail_plugins = $mail_plugins sieve userdb {
driver = passwd-file
args = username_format=%n /etc/passwd
} }
which works but produce some warnings because there is the root user (ID 0) and actually is a dirty workaround
Is there more elegant solution??
Question are you using a db like postgresql or mysql etc
when running virtual mailboxes it is just simply a better solution
my setup is as follows
i use a django project to drive it
here are the basic's
in the dovecot.conf :
passdb { args = /usr/local/etc/dovecot/dovecot-pgsql.conf driver = sql }
mail_plugins = " virtual notify replication fts fts_lucene "
service lmtp { process_limit=1000 vsz_limit = 512m client_limit=1 unix_listener /usr/home/postfix.local/private/dovecot-lmtp { group = postfix mode = 0600 user = postfix } }
mail_location = maildir:~/
&
# cat dovecot-pgsql.conf driver = pgsql connect = host=localhost port=5433 dbname=scom_billing user=pgsql password=xxxxxxx default_pass_scheme = PLAIN
password_query = SELECT username as user, password FROM email_users WHERE username = '%u' and password <> 'alias' and status = True and destination = '%u'
user_query = SELECT home, uid, gid FROM email_users WHERE username = '%u' and password <> 'alias' and status = True and destination = '%u'
#iterate_query = SELECT user, password FROM email_users WHERE username = '%u' and password <> 'alias' and status = True and destination = '%u'
iterate_query = SELECT "username" as user, domain FROM email_users WHERE status = True and alias_flag = False
Happy Friday !!! Thanks - paul
Paul Kudla
Scom.ca Internet Services http://www.scom.ca 004-1009 Byron Street South Whitby, Ontario - Canada L1N 4S3
Toronto 416.642.7266 Main 1.866.411.7266 Fax 1.888.892.7266 Email paul@scom.ca
On 10/21/2022 3:18 AM, George Asenov wrote:
Hello,
I use postfix with dovecot as an lmtp LDA with unix users and multiple domain names and mailboxes in Maildir format placed in domain directory like:
/home/mainuser/homes/user@domain.tld/Maildir or /home/mainuser/domains/domain2.tld/homes/user@domain2.tld/Maildir
which have the main user as a group and user@domain.tld/user@domain2.tld as owner
Postfix have virtual_alias_maps = hash:/etc/postfix/virtual
there in virtual file there is map like:
user@domain.tld user-domain@domain.tld
and in /etc/passwd
there are actually 2 users with the same home dir and same UID/GID (only the username is different)
and in postfix mailbox_transport = lmtp:unix:private/dovecot-lmtp
The issue is that when postfix passes the email for local delivery to dovecot lmtp it sends the username as user-domain.tld@serverhostname.tld but dovecot is configured with !include auth-system.conf.ext
can't resolve this username thus fails to deliver.
I've found a workaround in the net to use custom userdb just for lmtp like this:
protocol lmtp { mail_plugins = $mail_plugins sieve userdb {
driver = passwd-file args = username_format=%n /etc/passwd } }
which works but produce some warnings because there is the root user (ID 0) and actually is a dirty workaround
Is there more elegant solution??
participants (2)
-
George Asenov
-
Paul Kudla