[Imaplib2-devel] HEUREKA, Missing mails log snippet (found it)
Sebastian Spaeth
Sebastian at SSpaeth.de
Wed Jun 8 17:33:09 BST 2011
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
-------------- 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/20110608/1435c9f2/attachment-0001.sig>
More information about the OfflineIMAP-project
mailing list