2.3. Атрибуты сообщения
Кроме текста каждое сообщение содержит набор связанных с ним атрибутов. Эти атрибуты можно отыскивать вместе с текстом сообщения или независимо от него.
2.3.1. Номера сообщений
Доступ к сообщениям IMAP4rev1 обеспечивается по одному из двух номеров — идентификатору сообщения или уникальному идентификатору.
2.3.1.1. Уникальный идентификатор сообщения (UID)
32-битовый идентификатор, присваиваемый каждому сообщению и совместно с уникальным идентификатором корректности (см. ниже) образующий 64-битовое значение, для которого гарантируется уникальность в масштабе почтового ящика. Уникальные номера для каждого почтового ящика выделяются строго по нарастанию — каждое новое сообщение имеет значение UID, превышающее идентификаторы добавленных ранее сообщений. В отличие от порядковых номеров уникальные идентификаторы не обязаны следовать непрерывно и сохраняются только в течение одного сеанса. Это позволяет клиенту ресинхронизировать свое состояние по отношению к предыдущему сеансу (например, для отключенных или сеансовых клиентов). Вопросы синхронизации обсуждаются в работе [IMAPDISC].
С каждым почтовым ящиком связывается уникальный идентификатор корректности, который передается в коде UIDVALIDITY неотмеченных откликов OK при выборе почтового ящика. Если уникальные идентификаторы из предыдущего сеанса не могут использоваться в данной сессии, новое значение уникального идентификатора корректности должно быть больше, чем использованное в предыдущем сеансе значение.
Note: Значения уникальных идентификаторов для почтового ящика ДОЛЖНЫ строго возрастать. Если физически сообщения сохраняются агентом, отличным от IMAP, в ином порядке или неупорядочены, это требует регенерации уникальных идентификаторов для почтового ящика, поскольку прежние уникальные идентификаторы не будут идти строго по возрастанию в результате изменения порядка. Другим случаем регенерации уникальных идентификаторов являются системы, в которых при хранении сообщений не поддерживается механизм уникальной идентификации. Признавая, что это может быть неприемлемо для некоторых серверных сред, настоящая спецификация настоятельно рекомендует использовать системы хранения сообщений, позволяющие избежать этой проблемы.
Другой причиной невозможности использования прежних идентификаторов является случай, когда почтовый ящик удаляется и вместо него позднее создается новый ящик с таким же именем. Поскольку имена ящиков совпадают, клиент может не знать о том, что это новый ящик, если уникальные идентификаторы корректности не отличаются. Эффективным выходом будет использование в качестве уникальных идентификаторов корректности 32-битовое представление даты и времени создания почтовых ящиков. Можно использовать и константы (например, 1), если обеспечивается невозможность их повторного использования даже в случаях удалением или переименования почтовых ящиков с последующим созданием ящика с прежним именем.
Уникальный идентификатор сообщения НЕДОПУСТИМО изменять в течение сеанса и не следует менять между сессиями. Однако, если для следующего сеанса сохранение уникального идентификатора невозможно, новое значение должно быть больше предыдущего.