dovecot - Apr 2014 - About the "nologin" extra field

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