Обнаружение исключенных сообщений с помощью IMAP

Question

Итак, у IMAP есть функция, где, когда я посмотрю на почтовый ящик, я могу эффективно искать любые новые сообщения, задавая ему любые новые UID, которые я еще не видел.

Но как я могу найти опубликовано сообщений? Я еще не нашел никаких команд для этого; мой единственный вариант - получить полный список UID почтового ящика и искать недостающие. Это довольно субоптимально.

У меня есть почтовые ящики с 25000 + сообщениями. Сканирование одного из этих почтовых ящиков занимает мегабайт трафика только для выполнения команды UID SEARCH, поэтому я бы хотел этого избежать. Есть ли что-то скрытое в глубинах протокола IMAP, которое мне не хватает?

Answer 1

Хорошо, для использования в автономном режиме, это может работать:

Поскольку большие почтовые ящики, как правило, становятся большими, имея добавило много сообщений и несколько удалены, вы можете оптимизировать там быть большими неизменные части сообщений. Если ваш клиентский магазин содержит 10000 сообщений, вы можете отправить 'x UID SEARCH 2000,4000,6000,8000,10000`, который вернет пять UID в одном ответе ПОИСКА. В зависимости от того, какие из них были изменены, вы знаете, были ли какие-либо исключения в каждой пятой почтового ящика, поэтому, если почтовый ящик не изменился, вы проверили это очень дешево. Если конкретная пятая изменилась, вы можете получить в ней все UID 2000.

QRESYNC/CONDSTORE гораздо приятнее, но, кроме того, позволяет вам пересканировать состояние флага.

Answer 2

Единственный эффективный ответ, который я знаю, это изменить проблему.

Вместо того, чтобы узнать, какое из 25000 сообщений было удалено, клиент может узнать, какое из сообщений в его кеше было удалено и какие из них все еще существуют, и это можно сделать достаточно эффективно. Один из подходов состоит в том, чтобы сохранить в клиенте «сообщение для каждого сообщения», «это сообщение, как было обнаружено, существует в этом соединении IMAP», и когда вы получаете доступ к кэшированному сообщению, для которого флаг не установлен, вы отправляете «x UID SEARCH UID y ", который вернет UID сообщения, если сообщение существует, и пустой результат, если нет. Аргументы QRESYNC SELECT обеспечивают естественное улучшение этой техники.

Проблемы, конечно, связаны с тем, что с сервером, не являющимся QRESYNC, клиент будет кэшировать сообщения дольше, чем это необходимо, и что в зависимости от того, как вы его реализуете, клиент может мерцать или иметь неприятные задержки.