mailing list archives

The question has come up about possible extensions to what may optionally 
be reported by the server due to authentication conditions.  Obviously, 
there is substantial security sensitivity here.

The conditions in question are:
  . password will expire at such-and-such future time (or interval)
  . password has expired
  . account will expire at such-and-such future time (or interval)
  . account has expired
  . account has been disabled

It is desired to include a URL that will provide more information.

Currently, the only way to do this is with ALERT, but perhaps it would be 
useful if the client could know about some of these.

Example (with both ALERT for compatibility and new response code)

* NO [EXPIRED http://imap.example.com/expired]
tag NO [ALERT] Your account has expired, contact the help desk

Comments?

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

On Tue Apr  4 22:15:01 2006, Mark Crispin wrote:
> The conditions in question are:
>  . password will expire at such-and-such future time (or interval)
>  . password has expired
>  . account will expire at such-and-such future time (or interval)
>  . account has expired
>  . account has been disabled
> 
> 
That last is definitely a security issue, isn't it?

It'd be useful to be able to signal all the SASL codes that are in 
ACAP - TRANSITION-NEEDED, for instance, or AUTH-TOO-WEAK.

> Example (with both ALERT for compatibility and new response code)
> 
> * NO [EXPIRED http://imap.example.com/expired]
> tag NO [ALERT] Your account has expired, contact the help desk
> 
> Comments?

I'm not convinced all clients will understand untagged responses 
inside an AUTHENTICATE command - I think Alexey and Corby abandoned 
that syntax style for the RECONNECT work a while back at least partly 
due to that concern.

Also, I don't think that the alert is needed here - clients typically 
report the text of the error after a failure, so I suspect you're 
safe using the terminal response:

tag NO [EXPIRED http://imap.example.com/expired] Your account has 
expired, contact the help desk.

However, the better alternative would be to combine this proposal 
with an update to the AUTHENTICATE command which both explicitly 
added untagged responses during its execution, and supported both 
initial response and final success SASL data from the server. You 
could make it use literal8 instead of base64, too

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw