Eric S. Raymond (esr(_at_)thyrsus(_dot_)com) wrote:
Adam Spiers <adam(_at_)spiers(_dot_)net>:
A typical server reply for this error condition is something like:
fetchmail: IMAP< A0005 NO EXAMINE failed: Can't open mailbox
mail/inboxes/foo: no such mailbox
Surely it wouldn't be dangerous to add a simple pattern match for
errors like this, while leaving the behaviour for unrecognised errors
as it is currently?
Relying on IMAP behavior not specifired in the RFCs is a recipe for grief,
heartburn, subtle bugs, and endless flamage. Been there, done that, have
the scars to show for it, and don't want to do it again.
I guessed you'd say that, and in 99% of cases I'd totally agree with
that mindset. I don't fully agree in this case, but that's become
irrelevant since further thought has lead me to suspecting that there
is a more profound issue involved here:
AFAICS, the RFC doesn't give any reason why an IMAP client should
abort all operations and LOGOUT on receipt of a NO EXAMINE, or indeed
of any NO response. Of course, it makes perfect sense for a client to
close the connection on receipt of a BAD response, but to give up
after a NO response seems to me to be accepting defeat too easily,
given that NO responses (or NO EXAMINE responses, at least) are not in
any way unexpected. Hence I find it quite surprising that imap_ok()
does not distinguish between BAD and NO responses, returning PS_ERROR
in both cases despite the fact that the RFC clearly states that NO
indicates failure, whereas BAD indicates protocol error (2.2.2). What
is the reasoning behind this rather curious design decision?
Adam