Как правильно обрабатывать изменение идентификаторов электронной почты по сравнению с предыдущими сеансами?

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

Загруженные сообщения (почти все, кроме их тела и вложений) сохраняются в базе данных, поэтому даже их UID и они могут быть получены каждый раз, когда клиент хочет, ссылаясь на них по их UID.

К сожалению, я «только что» обнаружил, что почтовые серверы могут перенумеровывать некоторые или, возможно, все свои сообщения, так что перенумерация делает недействительными все мои UIDS, которые ранее сохранялись в базе данных.

Я не понимаю, какие действия я должен предпринять, чтобы преодолеть это поведение, эту перенумерацию, что я могу сделать, чтобы перехватить эту перенумерацию и что я могу сделать, чтобы перенумеровать мои сообщения, часть их или все?

Я понял механизм UIDValidity, но не понимаю, что именно делать, когда обнаруживаю его изменение.

Я думал:

  1. Для каждого сообщения на почтовом сервере
  2. Найдите его в моей базе данных, сопоставив его тему, дату и идентификатор сообщения.
  3. Если найдено, обновите сообщение в БД с его новым UID

С наилучшими пожеланиями


uid jakarta-mail imap
person Gamby    schedule 09.01.2018    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Вы действительно ничего не можете сделать. Как только сервер IMAP сообщит вам, что UIDVALIDITY изменился, единственное стандартное, надежное и безопасное действие — удалить все из вашего локального кеша.

Есть несколько нестандартных расширений, которые могут вам помочь. GMail, например, имеет собственный X-GM-MSGID, но он не указывает, становятся ли они недействительными при изменении UIDVALIDITY.

Сопровождающие Courier и Dovecot предприняли некоторые попытки стандартизировать расширение DIGEST для вычисления криптографических хэшей отдельных сообщений. Это будет именно то, что вы ищете. Однако я не думаю, что они когда-либо были стандартизированы. Кроме того, имейте в виду, что стандарт MIME допускает несколько эквивалентных представлений любого данного сообщения (подумайте о различных схемах 8-битного кодирования). Любое переваривание тела прерывается после изменения структуры MIME.

Я бы на вашем месте не пытался использовать Message-Id. Его значение контролируется пользователем.

person Jan Kundrát    schedule 09.01.2018
comment
Спасибо, Ян, мне интересно найти все возможные причины таких событий, @Max написал некоторые из них, но я хотел бы знать, есть ли еще, знаете ли вы? В моем сценарии я совершенно уверен, что мои папки не были переименованы, поэтому их сообщения всегда такие же, как я ранее загрузил. По этой причине я бы реализовал решение, которое ищет сохраненные сообщения, используя ‹messageid, дату, тему› сообщений, только что прочитанных с почтового сервера, и если находит их, устанавливает новый UID. Я хотел бы знать, если вы думаете, что это глупость, спасибо - person Gamby; 10.01.2018
comment
Это плохая идея, потому что все эти поля контролируются отправителем; также вполне допустимо иметь дубликаты в папке (например, копию). - person Max; 10.01.2018
comment
@Gamby, если вам нужен какой-то локальный уникальный идентификатор, то ваш единственный достаточно безопасный метод - это вычисление криптографического хэша содержимого электронной почты. Однако это не предотвратит возможное дублирование сообщений; Совершенно нормально иметь два сообщения, которые отличаются только небольшими техническими деталями их транспортной сериализации (например, MIME). - person Jan Kundrát; 15.01.2018

arrow_upward
1
arrow_downward

Обычно UIDVALIDITY не должно меняться. Если это так, вам следует выполнить полную повторную синхронизацию этой папки (удалить все и синхронизировать с нуля).

Если он изменится, это может означать, что это на самом деле другая папка. Например, удалите папку и переименуйте другую папку в имя старой папки. Либо удалите папку, либо заново создайте новую с тем же именем. То же имя, другая папка, разные UIDVALIDITY.

person Max    schedule 09.01.2018