[Imaplib2-devel] raise self.error(self.welcome) error: None

[Sebastian Spaeth]

On Thu, 16 Jun 2011 11:16:42 +1000, Piers Lauder <piers at janeelix.com> wrote:
>   > > http://pastebin.com/ZHCwTgiS

> The problem here is a malformed command continuation request from the server.
> 
> imaplib2 expects continutation requests in the form
>   "+[<space><optional data>]"
> but the server is sending "+OK..." - ie: no space.
> 
> Normally the first response from a server is an "* OK ..." untagged response.
> 
> On re-reading RFC2060, I can't see any example where there isn't a space
> after the '+', but I also can't see where is is mandated,

DOH, I see. (By the way RFC2060 is superseded by RC 3501 ;))

Actually looking at the formal definitions, a SPACE seems to be
required, so the server is definitly wrong here...

RFC3501 has this to say:

  response        = *(continue-req / response-data) response-done

  response-data   = "*" SP (resp-cond-state / resp-cond-bye /
                  mailbox-data / message-data / capability-data) CRLF

  continue-req    = "+" SP (resp-text / base64) CRLF

  In all cases, SP refers to exactly one space.  It is NOT permitted to
  substitute TAB, insert additional spaces, or otherwise treat SP as
  being equivalent to LWSP.

I filed a cyrus bug with this information
(http://bugzilla.cyrusimap.org/show_bug.cgi?id=3483) and I am puzzled
how something like this can happen to a mature implementation of an IMAP
server :-(.

> fix I'd suggest changing the regular expression to match a continuation
> request to be:
> 
>     continuation_cre = re.compile(r'\+ ?(?P<data>.*)')
> 
> There are other places where a space is expected, such as in untagged
> responses which are expecting "* <data>", so if this server is going
> instead to send "*<data>" then we may need to fix other matchers.

Right, the specs also mandate a space in untagged responses...
 
> My gut feeling is that this is a bad idea, as data is sent via
> continuation responses, and if the space is optional, how is one to
> know whether it is part of the data or not?
> 
> What do you think?

My gut feeling is usually to be as lenient as possible if it doesn't
cause trouble. But if this runs danger that we misinterpret data from
the server as a continuation response, I think we should rather stick to
the RFCs here.

One way would be to ignore a valid welcome messages rather than
currently do:
                raise self.error(self.welcome)

But then, I feel a little uneasy about this too. self.welcome is "None"
in this case, and perhaps we should allow "None" as a valid response?

I am a bit split about how to handle this and what level of brokeness we
are prepared to take from IMAP servers.

Sebastian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20110616/8b05a671/attachment-0001.sig>