Hello,

While experimenting with the "nologin" extra field, I met a possibly overlooked behavior.

Let's suppose the user database has those two columns:

enabled: the user may/may not login (account active/not active)
nologin: NULL if the mailbox is available, '!' if it is
	currently suspended (for maintenance reasons)

The password_query:

password_query =
	SELECT
		password,
		nologin,
		'Maintenance' || nologin AS reason,
		[...]
	FROM
		[...]
	WHERE
		[...]
		AND enabled
		[...]

Let's then experiment with pop connections.

With: enabled set to false, nologin set to '!' the right password provided, following reply is emitted after an authentication failure delay:

-ERR [AUTH] Authentication failed.

So, as expected, the nologin value behaves as a "don't care" one.

With: enabled set to true, nologin set to '!', the right password provided, following output is immediately emitted:

-ERR [AUTH] Maintenance!

Again, this is the kind of behavior I was expecting.

With: enabled set to true, nologin set to '!', an incorrect password provided, there's the failure delay but the output still is:

-ERR [AUTH] Maintenance!

Here, I'm a bit dubitative... ;-) The delay seems to make the code's intent clear: to act as in the case of an authentication failure. But, notwithstanding the somewhat misleading explanation provided to a legitimate user with such a reply, isn't one unduly disclosing information about an account existence?

Is this supposed to behave that way? If yes, what's the rationale?

TIA, Axel