Почему при отправке писем из 1С через MS Exchange по протоколу IMAP возникает ошибка через каждые 10 сообщений?

← На главную

В процессе эксплуатации высоконагруженных систем обмена сообщениями между 1С:Предприятие и Microsoft Exchange 2019 разработчики часто сталкиваются со специфическим поведением протокола IMAP. Типичная ситуация: регламентное задание успешно отправляет первые несколько писем, после чего стабильно падает с ошибкой The specified message set is invalid (Код ошибки: 4). Проанализируем, почему это происходит и как решить проблему, не прибегая к радикальным изменениям конфигурации.

Разбор технической ситуации и анализ логов

Рассмотрим ситуацию: при использовании типовых механизмов 1С для отправки почты через IMAP, платформа выполняет последовательность действий. Сначала письмо отправляется по SMTP или помещается в папку «Отправленные» с помощью команды APPEND, а затем 1С пытается установить флаг \Seen (Прочитано) для этого сообщения. Проанализируем фрагмент кода, который вызывает исключение:


Если ПротоколПолученияПочты = ПротоколИнтернетПочты.IMAP Тогда
    Соединение.Послать(Письмо, ОбрабатыватьТексты, ПротоколИнтернетПочты.IMAP);
    РезультатОтправкиПисьма.Вставить("ИдентификаторПисьмаIMAP", Письмо.ИдентификаторСообщения);
    ФлагиПисьма = Новый ФлагиИнтернетПочтовогоСообщения;
    ФлагиПисьма.Прочитанное = Истина;
    ФлагиПисем = Новый Соответствие;
    ФлагиПисем.Вставить(Письмо.ИдентификаторСообщения, ФлагиПисьма);
    Соединение.УстановитьФлагиСообщений(ФлагиПисем);
КонецЕсли;

При изучении логов почтового сервера Exchange выясняется, что команда APPEND проходит успешно, но следующая за ней команда STORE возвращает ошибку:

LOG: store * +FLAGS.SILENT (\Seen) -> R="11 BAD The specified message set is invalid."

Выясним причину: символ * в протоколе IMAP является указателем на «максимальный порядковый номер сообщения в папке». Ошибка возникает из-за того, что в рамках одной сессии Exchange не всегда успевает обновить индекс папки сразу после добавления нового объекта. Когда 1С запрашивает изменение флага для «последнего» сообщения, сервер считает этот указатель невалидным, так как внутренний счетчик сессии еще не синхронизирован.

Почему ошибка возникает именно после 10 писем?

Разберем, почему система работает некоторое время, а затем дает сбой. Это связано с механизмами Throttling Policy (политики регулирования) в Microsoft Exchange и особенностями реализации почтового клиента в платформе 1С версии 8.3.27 и выше. Проанализируем основные факторы:

Задержка индексации: При интенсивной отправке писем (в цикле регламентного задания) сервер накапливает операции записи. На 11-м сообщении задержка обновления индекса превышает допустимый порог ожидания клиента, и команда STORE * отклоняется.
Лимиты сессии (ImapMaxBurst): В настройках Exchange существует параметр ImapMaxBurst, который определяет количество команд, которые пользователь может отправить «всплеском». Часто этот лимит настроен таким образом, что после 10-15 быстрых операций сервер начинает требовать паузу или выдает BAD на операции управления метаданными.
Особенности платформы 8.3.27: В новых релизах 1С изменен алгоритм работы с идентификаторами сообщений. Платформа пытается оптимизировать запросы, используя групповые операции, но в случае с IMAP и Exchange это приводит к рассинхронизации UID.

Вариант решения №1: Изменение логики работы в 1С (Патч)

Если мы имеем возможность вносить изменения в код, самым простым и надежным способом будет отказ от принудительной установки флага «Прочитано» сразу после отправки. Рассмотрим, как это влияет на процесс: когда 1С не вызывает метод УстановитьФлагиСообщений, команда STORE * не отправляется на сервер, и цепочка APPEND продолжается без ошибок.

Проанализируем ситуацию: письмо, помещенное в папку «Отправленные» через APPEND, по умолчанию может иметь флаг «Непрочитанное» (зависит от настроек сервера). Если для бизнес-логики это не критично, просто закомментируем строки, отвечающие за ФлагиПисьма.Прочитанное.

Вариант решения №2: Настройка Microsoft Exchange

Если патчить код конфигурации нежелательно (например, в случае множества распределенных баз), необходимо скорректировать поведение почтового сервера. Выясним, какие параметры стоит проверить:

Создание отдельной политики регулирования: Для учетной записи, под которой работает робот 1С (например, 1c.robot), следует создать персональную ThrottlingPolicy.
Снятие ограничений на количество команд: Выполним в PowerShell команду для настройки политики, чтобы сервер не ограничивал частоту выполнения команд управления сообщениями:
```
Set-ThrottlingPolicy -Identity "1C_Robot_Policy" -IMAPMaxConcurrency Unlimited -IMAPMaxBurst Unlimited -MessageRateLimit Unlimited
Set-Mailbox -Identity "1c.robot" -ThrottlingPolicy "1C_Robot_Policy"
```
Параметр EnableExactRPC: В некоторых случаях помогает активация более точной синхронизации через реестр сервера Exchange, что заставляет индекс обновляться мгновенно после команды APPEND.

Вариант решения №3: Использование транспортных правил

Рассмотрим альтернативный архитектурный подход. Вместо того чтобы заставлять 1С копировать письмо в папку «Отправленные» через IMAP (что является тяжелой операцией), можно использовать возможности SMTP-транспорта.

Разберем шаги реализации:

В 1С при настройке почтового профиля снимем галочку «Сохранять копии исходящих писем».
На стороне Exchange настроим Транспортное правило (Journaling или BCC): если письмо отправлено от адреса 1c.robot, сервер должен автоматически копировать его в определенную папку.
Этот метод полностью исключает использование протокола IMAP для записи данных, оставляя за ним только функцию чтения (если это необходимо). Это самый производительный вариант, исключающий любые ошибки синхронизации индексов.