On 17.11.2016 10:49, Adrian POPA wrote:
On 17.11.2016 10:30, Arkadiusz Miśkiewicz wrote:
On Thursday 17 of November 2016, Aki Tuomi wrote:
On 17.11.2016 10:14, Arkadiusz Miśkiewicz wrote:
Hello.
dovecot 2.2.26.0
When testing nopassword extra field (http://wiki2.dovecot.org/PasswordDatabase/ExtraFields) with CRAM-MD5 dovecot doesn't allow any password (while it should) and returns
" Authentication failed"
while in logs:
Nov 17 08:22:34 auth-worker(1551): Info: sql(pepe,127.0.0.1,
): Requested CRAM-MD5 scheme, but we have a NULL password NULL is there because our sql query returns empty password just like wiki says "nopassword: you want to allow all passwords, use an empty password and this field. "
If password is returned in sql query then it fails, too:
Nov 17 09:00:49 auth-worker(2206): Error: sql(pepe,127.0.0.1,
): nopassword set but password is non- empty So looks to be a bug. It's not a bug. CRAM-MD5 does in fact require *some* password to work, Provide fake/random one for nopassword internally.
you can either store it with doveadm pw -S CRAM-MD5 or as plain text password. Then I get
sql(pepe,127.0.0.1,
): nopassword set but password is non- empty So that doesn't help btw. doveadm pw -S is not documented, so no idea what it does
Aki Sorry to bump into your conversation but Aki is defending too hard something that is realy a bug. I have signaled myself this issue in the "very old" version 2.2.9(!) nopassword means ANY password (including none). One cannot store something like ANY with doveadm, SQL or anything. So with "nopassword" the query should simply ignore the password field (missing, NULL or set to anything else). Why would an user login with nopassword? This is an administrator decision and is not subject for comments. My problem was with LDA who refuses to store mail in INBOX if the user is not properly authenticated (nopassword) so you cannot receive mails for "hidden" users that cannot login, maybe to redirect mails later or do some other things with.
Adrian
You can also, if you are using nopassword flag, abstain from actually returning any field called 'password' from your SQL database. The reason this check is done is to ensure that you know what you are doing. We do not want to prevent you from logging in w/o password, that's fine for us and it will work just as you want as long as you do not return 'password' attribute from your database.
Aki