Hi list!
I've recently updated a small dovecot cluster from 2.2.29 to 2.3.10. I've found an issue with variable expansion. My user/password database is on a mysql table, with password saved in plain text field.
The cluster receives mail via lmpt and users fetch them via imap. On the 2.2.29 version, no issues.
After the upgrade, I've found some lines in the log:
Apr 14 14:36:05 archive-front1 dovecot: lmtp(19671, fakeusername@fakedomain.com): Error: lmtp-server: conn 212.183.164.212:34642 [4]: rcpt fakeusername@fakedomain.com: Failed to initialize user: Failed to expand plugin setting password = 'sd78F6aS9%Lggxf': Unknown variable '%g'
(I've faked /some/ information for obvious reasons, but I've kept the password after the '%' sign).
Apparently, dovecot 2.3.10 is trying to expand some variables IN the password field. I'm trying to fool him expanding the '%' into '%%' on the password query, but without luck... I can also contact the user and make him choose a different password, without '%'.
Anyway, I feel that this behaviour should be seen as a bug. Am I missing something?
-- Simone Lazzaris QCom SpA
On 14/04/2020 15:56 Simone Lazzaris <s.lazzaris@interactive.eu> wrote:
Hi list!
I've recently updated a small dovecot cluster from 2.2.29 to 2.3.10. I've found an issue with variable expansion. My user/password database is on a mysql table, with password saved in plain text field.
The cluster receives mail via lmpt and users fetch them via imap. On the 2.2.29 version, no issues.
After the upgrade, I've found some lines in the log:
Apr 14 14:36:05 archive-front1 dovecot: lmtp(19671, fakeusername@fakedomain.com): Error: lmtp-server: conn 212.183.164.212:34642 [4]: rcpt fakeusername@fakedomain.com: Failed to initialize user: Failed to expand plugin setting password = 'sd78F6aS9%Lggxf': Unknown variable '%g'
(I've faked /some/ information for obvious reasons, but I've kept the password after the '%' sign).
Apparently, dovecot 2.3.10 is trying to expand some variables IN the password field. I'm trying to fool him expanding the '%' into '%%' on the password query, but without luck... I can also contact the user and make him choose a different password, without '%'.
Anyway, I feel that this behaviour should be seen as a bug. Am I missing something?
-- Simone Lazzaris QCom SpA
Hi!
Don't return password from userdb lookup (remove password field for user query).
Aki
participants (2)
-
Aki Tuomi
-
Simone Lazzaris