сижу думаю

Реализация IMAP в iPhone Mail прекрасный повод задуматься о. Вот анализ сеанса:

S: * OK server ready. Unauthorized Access Prohibited.
C: 1 LOGIN user password
S: 1 OK LOGIN completed
C: 2 CAPABILITY
S: * CAPABILITY IMAP4REV1 IDLE QUOTA NAMESPACE ACL LITERAL+ SORT
     UNSELECT WITHIN ENABLE AUTH=DIGEST-MD5 AUTH=PLAIN AUTH=CRAM-MD5
S: 2 OK CAPABILITY completed 
C: 3 LIST "" "*" 
S: * LIST () "/" "Documents"
S: * LIST () "/" "INBOX"
S: * LIST () "/" "Public Documents"
S: * LIST () "/" "Sent"
S: 3 OK LIST completed
C: 4 SELECT INBOX
S: * 71 EXISTS
S: * 0 RECENT
S: * OK [UIDVALIDITY 1] UID validity status
S: * OK [UIDNEXT 66] Predicted next UID
S: * FLAGS (\Seen \Deleted \Answered $Forwarded \Flagged \Draft $MDNSent \*)
S: * OK [PERMANENTFLAGS (\Seen \Deleted \Answered $Forwarded
        \Flagged \Draft $MDNSent \*)] Permanent flags
S: 4 OK [READ-WRITE] SELECT completed
C: 5 NOOP
S: 5 OK NOOP completed
C: 6 UID SEARCH 47:* NOT DELETED
S: * SEARCH 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134
     135 136 137 138 139 140 141 142 143
S: 6 OK UID SEARCH completed
C: 7 UID FETCH 119:143 (INTERNALDATE UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS
    (date subject from content-type to cc bcc message-id in-reply-to references)])
S: * 47 FETCH (INTERNALDATE "25-Nov-2008 23:35:48 -0800" UID 119 RFC822.SIZE 820
     FLAGS (\Seen \Answered \Recent) BODY[HEADER.FIELDS ("date" "subject" "from"
     "content-type" "to" "cc" "bcc" "message-id" "in-reply-to" "references")] {415}
S: Date: Wed, 26 Nov 2008 00:35:48 -0800 (PST)
S: * 48 FETCH (INTERNALDATE "05-Feb-2009 21:36:44 -0800" UID 120 RFC822.SIZE 814
     FLAGS (\Seen \Recent) BODY[HEADER.FIELDS ("date" "subject" "from"
     "content-type" "to" "cc" "bcc" "message-id" "in-reply-to" "references")] {278}
S: Date: Thu, 05 Feb 2009 22:36:44 -0800
[ вырезано ]
S: * 71 FETCH (INTERNALDATE "17-Nov-2008 08:05:49 -0800" UID 143 RFC822.SIZE 534
     FLAGS (\Seen \Recent) BODY[HEADER.FIELDS ("date" "subject" "from"
     "content-type" "to" "cc" "bcc" "message-id" "in-reply-to" "references")] {286}
S: Date: Mon, 17 Nov 2008 09:05:49 -0800
S: 7 OK UID FETCH completed
C: 8 UID SEARCH 1:* DELETED
S: * SEARCH
S: 8 OK UID SEARCH completed
C: 9 UID FETCH 119 (BODY.PEEK[HEADER] BODY.PEEK[TEXT])
S: * 47 FETCH (BODY[HEADER] {579}
S: MIME-Version: 1.0
S: Message-ID: <4b4a07be-ab44-4d36-9861-a7457f1227aa@default>
[ вырезано ]
C: 10 STATUS INBOX (UNSEEN)
S: * STATUS "INBOX" (UNSEEN 3)
S: 10 OK STATUS completed
[ здесь отсоединился, но я думаю это vpn отпал ]
C: 3 SELECT INBOX
S: * 71 EXISTS
S: * 71 RECENT
S: * OK [UIDVALIDITY 1] UID validity status
S: * OK [UIDNEXT 144] Predicted next UID
S: * FLAGS (\Seen \Deleted \Answered $Forwarded \Flagged \Draft $MDNSent \*)
S: * OK [PERMANENTFLAGS (\Seen \Deleted \Answered $Forwarded \Flagged \Draft
     $MDNSent \*)] Permanent flags
S: 3 OK [READ-WRITE] SELECT completed
C: 4 UID FETCH 120 (BODY.PEEK[HEADER] BODY.PEEK[TEXT])
S: * 48 FETCH (BODY[HEADER] {523}
S: Message-ID: <498bdac7.3040302@domain.com>
[ вырезано ]
C: 34 UID FETCH 143 (BODY.PEEK[HEADER] BODY.PEEK[TEXT])
S: * 71 FETCH (BODY[HEADER] {530}
S: Message-ID: <4921a4d6.8070306@domain.com>
[ вырезано ]
C: 37 UID SEARCH 22:46 NOT DELETED
S: * SEARCH 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112
   113 114 115 116 117 118
S: 37 OK UID SEARCH completed
C: 38 UID FETCH 94:118 (INTERNALDATE UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS
   (date subject from content-type to cc bcc message-id in-reply-to references)])
S: * 22 FETCH (INTERNALDATE "30-Jan-2009 13:46:30 -0800" UID 94 RFC822.SIZE 995
   FLAGS (\Seen \Recent) BODY[HEADER.FIELDS ("date" "subject" "from" "content-type"
   "to" "cc" "bcc" "message-id" "in-reply-to" "references")] {305}
S: Date: Fri, 30 Jan 2009 14:46:30 -0800
[ вырезано ]

Вопросы на сто рублей, а именно, зачем здесь:

• NOOP. Теория в том, что это просто сделано так. Видимо, какая-та библиотека, которой разработчики пользуются, где-то у себя в дебрях NOOP шлет.

• UID SEARCH 1:* DELETED. А это загадка. Самое большое окно сообщений, которые iPhone показывает может быть установлено в 200 (я поставил в 25, для экспериментов). Т.е. если клиент показывает 200 последних отсортированных согласно последовательности появления в папке сообщений (by IMAP seq number) и при этом, у меня в папке 2000 сообщений, то 1:* не имеет смысла, я не увижу ничего меньше чем 1800. Т.е. для того чтобы убрать сообщения, помеченный как удаленный из своего представления, клиенту нужно запросить сообщения с номером последовательности минимального увиденного сообщения. Есть подозрение что никто об этом, конечно не задумывался и это также скрыто в какой-то библиотеке, как и NOOP.

Сижу. Озадачен.