Re: Office 365 "BAD Command received in Invalid state."

[Ken Gunderson <kgunders@teamcool.net>]

At Wed, 05 Feb 2014 12:18:38 +0000,
Richard Lewis wrote:
> 
> Hi there,
> 
> My employer recently sold out their email provision to Microsoft using
> that company's Office 365 'cloud' offering. This service provides an
> IMAP implementation with which I'm having some problems.
> 
> I regularly find that I can't establish a connection when I first try;
> it takes up to 10s of attempts over several minutes before Wanderlust
> successfully manages to retrieve new message headers. For as long as
> the connection is left open it works fine. Each of the failed attempts
> results in this error message:
> 
> "BAD Command received in Invalid state."
> 
> I have IMAP debugging enabled and have pasted the full log below.
> 
> The Web seems to suggest that this could be a password encryption
> setting problem on the server side. (My employer has not been very
> helpful in attempting to debug this; they (understandly) argue that
> they don't support Wanderlust.) However, it seems from the
> 'capability' response that only PLAIN is supported, so I can't really
> experiment further in that direction. I've also tried switching been
> SSL on port 993 and STARTTLS on port 143; doesn't make any difference.
> 
> Any suggestions what might be going on here?

Nope.  However, M$ is infamous for "proprietizing" standards via their
"embrace and extend" policy so as to make "competitions" software
appear to be "broken".  Lookout and Exchange are famous for this
amongst *nix mail server administrators.

It's been a while since I've debugged IMAP connections from the
command line so I no longer have the commands off the tip of my
fingers, but check IMAP4 rfc's for reference.  Then you may want to
try and see if you can debug via a telnet session & see if you can get
more meaningful information, e.g.:

$ telnet imapserver.somewhere.dom 143

and see if you can issue imap commands manually and get a login.  Can
substitute 993 as port if necessary.  Else manually try to initiate
start TLS via imap commands via your telnet client.

Based on prior experience as mail server admin, however, I suspect M$
is once again up to their dirty tricks, because, well, history tends
to repeat itself and that's to be expected.

You may also try digging down to the packet level and capturing an
elmo login attempt with a tool such as Wireshark, but that may be too
much info to decode unless you're pretty into such things.  I'm not
sure it will do you any good, but that's the kind of stuff one has to
resort to when groping around on the dark side of proprietary
commercial software....

Good luck-- Ken