[Imaplib2-devel] HEUREKA, Missing mails log snippet (found it)

Piers Lauder piers at janeelix.com
Thu Jun 9 02:04:48 BST 2011


On Wed, 08 Jun 2011 18:33:09 +0200, Sebastian Spaeth wrote:
  > 
  > On Wed, 08 Jun 2011 17:25:37 +0200, Sebastian Spaeth <Sebastian at SSpaeth.de> wrote:
  > > On Wed, 08 Jun 2011 16:38:37 +0200, Christoph Höger wrote:
  > > > great Work! Is this behaviour specified in some RFC or is it the
  > > > mailservers fault?
  > > 
  > > Well, the RFCs are certainly fuzzy enough to not specify it precisely,
  > > although my interpretation of the FETCH description on page 53 of
  > > http://www.networksorcery.com/enp/rfc/rfc3501.txt and the example given
  > > therein does not seem to allow interspersed replies.
  > 
  > After re-reading specs, I stand corrected. RFC 3501 specifies 2 types of
  > server replies, untagged, and tagged and we need to cope with it. This
  > is not the servers fault... The relevant part is:
  > 
  >    The client MUST be prepared to accept any response at all times.
  > 
  >    Status responses can be tagged or untagged.  Tagged status responses
  >    indicate the completion result (OK, NO, or BAD status) of a client
  >    command, and have a tag matching the command.
  > 
  >    Some status responses, and all server data, are untagged.  An
  >    untagged response is indicated by the token "*" instead of a tag.
  >    Untagged status responses indicate server greeting, or server status
  >    that does not indicate the completion of a command (for example, an
  >    impending system shutdown alert).  For historical reasons, untagged
  >    server data responses are also called "unsolicited data", although
  >    strictly speaking, only unilateral server data is truly
  >    "unsolicited".
  > 
  > Sebastian

Ouch, Ok I stand corrected. Mea culpa.

Suggested patch is now a _legal_ fix :-)

Piers.






More information about the OfflineIMAP-project mailing list