On Thu, Jun 18, 2015 at 04:06:41PM -0700, Kevin J. McCarthy wrote: > Oswald Buddenhagen wrote: > > On Thu, Jun 18, 2015 at 01:19:33PM -0700, Kevin J. McCarthy wrote: > > > I'm attaching a patch that does this. > > > > > It keeps the NONULL check in imap_auth_sasl, because it still seems > > > possible this could be called without capstr being set. > > > > > this seems plain wrong. it would most probably indicate a bug in the > > code preceding it. the server SHOULD send an unsolicited CAPABILITY > > response when the connection is established, > actually, it's just MAY. http://tools.ietf.org/html/rfc3501#section-7.2.1 (last paragraph)
> > and failing that, the client is expected to issue a CAPABILITY > > command. > > I'm really not that familiar with IMAP or the imap code in Mutt, however > it does look like that's what mutt is doing. After opening the socket, > mutt runs imap_cmd_step() which should handle the server responses. > > Then below, it double checks the buffer to see if a CAPABILITY header > was sent back, and if not, calls imap_check_capabilities(). > > However, currently Mutt will *always* run the authenticators, regardless > if the capability is sucessfully set, > that's wrong. when the CAPABILITY command fails to produce a capability set, something is seriously wrong with the server. mutt should definitely drop the connection in this case. > Additionally, further down in imap_auth_sasl() there are a couple > checks for whether method is NULL, so the NONULL check is not > inconsistent inside the function. > i didn't look at that code, but the method could be plausibly null for legitimate reasons (when the legacy LOGIN is the only supported method, for example).
