[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