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 at fakedomain.com): Error: lmtp-server: conn 212.183.164.212:34642 [4]: rcpt fakeusername at 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 at 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 at fakedomain.com): Error: lmtp-server: conn 212.183.164.212:34642 > [4]: rcpt fakeusername at 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 SpAHi! Don't return password from userdb lookup (remove password field for user query). Aki