2012-02-05 1 views
14

Я пишу сценарий для анализа моего почтового ящика и хочу периодически проверять наличие новых сообщений. Критерии поиска: дать мне UID для всех писем с UID больше X, где X - это UID последнего обработанного мной письма.IMAP: Поиск сообщений с UID больше X (или вообще после моего последнего поиска)

Или, в более общем плане, я ищу способ видеть сообщения только со времени моего последнего поиска.

Обратите внимание, что я не ищу видимые/невидимые сообщения; сценарий открывает почтовый ящик как доступный только для чтения, и я бы хотел, чтобы он не мешал моим флагам и т. д.

Я знаю, что я могу указать дату в поиске IMAP, но зернистость этого, по-видимому, день, поэтому не совсем то, что мне нужно.

Я начинаю с Gmail как IMAP-сервер, но в будущем буду поддерживать общие IMAP-серверы.

Есть ли способ поиска писем с UID больше, чем X? Или другое средство для указания всех сообщений с момента сообщения X?

ответ

16

Вы можете использовать IMAP SEARCH для UID. Предполагая, что ваша последний раз неправдоподобной UID в 1999, я думаю, что вы могли бы сделать:

SEARCH UID 2000:*

+0

Подтверждено на Courier-IMAP – Joril

+1

Должен быть принят ответ. Также не уверен, что я четко понял RFC: уверены ли мы на 100%, что данный UID никогда не будет использоваться снова со временем? (удаление электронной почты и т. д.) – lajarre

+1

@lajarre, это не то, что я достаточно понимаю, чтобы ответить полностью. Если вы спросите, что в качестве отдельного вопроса в StackOverflow вы можете получить лучший ответ. Согласно разделу 2.3.1.1 RFC 3501, UID «НЕ ДОЛЖЕН изменяться во время сеанса и НЕ ДОЛЖЕН меняться между сеансами» и изменениями в UID «ДОЛЖЕН быть обнаружен с использованием механизма UIDVALIDITY» – SimonMayer

1

Почему бы не использовать IMAP IDLE для этого?

с IMAP IDLE, сервер предупреждает вас каждый раз, когда новое сообщение приходит

+0

, потому что не поддерживается широко. и вы должны оставаться на связи? – benchpresser

+0

@ benchpresser путь для восстановления старого потока :) - в любом случае это правда, все, что вы говорите, но до 1-го пункта я говорю «вот почему я спросил, есть ли причина не использовать в конкретном случае OP», а что касается второго, если вы не подключены, вы не можете действительно искать почтовый ящик – 537mfb

+0

Но если вы вчера были связаны и снова подключались, вы были подключены, и вы снова, но не можете использовать IDLE. Кроме того, если ваше приложение должно быть устойчивым к прерывистым перебоям в сети, вам необходимо отслеживать клиентскую сторону. Поэтому да, если вы можете поддерживать IDLE, поддерживайте IDLE, если это имеет смысл для вас, но это не решает проблему в общем случае; и часто вам необходимо поддерживать общий случай, даже если вы хотите использовать IDLE, когда сможете. – tripleee