Почему не отправляется почта из ЗУП 3.1, хотя из ЗУП 2.5 на той же платформе все работает?

← На главную

При переходе с устаревших конфигураций (например, 1С:Зарплата и Управление Персоналом ред. 2.5) на современные редакции (ЗУП 3.1) технические специалисты часто сталкиваются со странным поведением системы: почтовая рассылка расчетных листков или отправка печатных форм, которая годами без сбоев работала в старой базе, наотрез отказывается функционировать в новой. При этом обе базы могут быть файловыми, запускаться на одном и том же физическом компьютере под управлением абсолютно одинаковой версии платформы 1С:Предприятие, а параметры подключения к почтовому ящику (сервер, порт, логин и пароль) совпадают вплоть до каждого символа.

При попытке выполнить отправку из современной базы ЗУП 3.1 система выбрасывает критическое исключение:


ОбщийМодуль.РаботаСПочтовымиСообщениямиСлужебный.Модуль(571)}: Ошибка при вызове метода контекста (Подключиться)
            Соединение.Подключиться(Профиль);
по причине:
Аутентификация не прошла (SMTP error code 535 5.7.3 Authentication unsuccessful)

В этой статье мы подробно разберем, почему возникает эта проблема, проанализируем внутренние механизмы платформы 1С:Предприятие и рассмотрим по шагам несколько надежных способов устранения данной ошибки при работе с почтовыми серверами (в особенности с Microsoft Exchange и Office 365).

---

Выясняем глубинную причину: смена режима совместимости и почтовых библиотек

Для того чтобы понять природу этой мистической ошибки, нам необходимо заглянуть «под капот» платформы 1С:Предприятие. Главный секрет кроется в свойстве конфигурации Режим совместимости.

Конфигурация ЗУП 2.5 разрабатывалась очень давно и работает в режиме совместимости с версиями 8.3.5 или ниже (а зачастую и вовсе 8.2.13). Современная же ЗУП 3.1 требует актуальных возможностей платформы и функционирует в режиме совместимости 8.3.12, 8.3.14 или выше.

Согласно официальной документации «1С:Предприятие», начиная с режима совместимости 8.3.6, разработчики платформы кардинально изменили внутреннюю архитектуру работы с почтовыми протоколами:

В режиме совместимости 8.3.5 и младше (наш случай с ЗУП 2.5) для реализации объекта встроенного языка ИнтернетПочта платформа использовала старую библиотеку imaplib (UW IMAP toolkit). Это проверенная временем, но технологически устаревшая библиотека.
В режимах совместимости 8.3.6 и старше (наш случай с ЗУП 3.1) использование библиотеки imaplib прекращено. Вместо нее платформа переведена на более современную и безопасную кроссплатформенную библиотеку libetpan.

Эта смена внутренних библиотек полностью меняет логику первоначального диалога (handshake) и согласования протоколов авторизации между клиентом 1С и вашим корпоративным почтовым сервером Microsoft Exchange.

---

Почему новая библиотека вызывает ошибку SMTP 535 на Exchange?

Когда вы настраиваете почтовый профиль ИнтернетПочтовыйПрофиль, вы, как правило, указываете свойство АутентификацияSMTP в значение СпособSMTPАутентификации.ПоУмолчанию. Именно здесь и кроется ловушка:

Старая библиотека (ЗУП 2.5): При значении ПоУмолчанию 1С сразу отправляет серверу простые и прямолинейные запросы авторизации (методы LOGIN или PLAIN), передавая учетные данные в формате Base64. Почтовый сервер без лишних вопросов принимает эти данные и осуществляет отправку.
Новая библиотека libetpan (ЗУП 3.1): Алгоритм работы стал намного более строгим и ориентированным на безопасность. При установке аутентификации «По умолчанию» 1С сначала запрашивает у сервера список всех поддерживаемых им методов шифрования и авторизации. Почтовый сервер Microsoft Exchange в ответ на команду EHLO сообщает, что поддерживает защищенную доменную авторизацию Windows — NTLM и GSSAPI.

Получив этот список, новая библиотека 1С пытается проявить «интеллект» и выбирает наиболее безопасный из предложенных вариантов — встроенную Windows-авторизацию (NTLM). Однако для прохождения NTLM-авторизации серверу требуется доменное имя пользователя, в то время как в настройках 1С прописан простой логин почтового ящика. Происходит сбой авторизации на стороне Exchange, и сервер возвращает клиенту ошибку: SMTP error code 535 5.7.3 Authentication unsuccessful.

Кроме того, современные стандарты безопасности Exchange часто требуют обязательного шифрования сессии (STARTTLS) перед тем, как клиент сможет передать пароль в открытом виде. Новая библиотека строго соблюдает это правило и блокирует незащищенную передачу данных, в то время как старая библиотека игнорировала требования безопасности сервера и отправляла логин с паролем по открытому порту 25.

---

Разберем решения проблемы по шагам

Поскольку поведение системы изменилось на уровне платформы, нам придется скорректировать параметры подключения. Рассмотрим подробнее несколько способов решения проблемы, начиная с самых простых настроек в пользовательском режиме 1С и заканчивая системным администрированием почтового сервера.

---

Решение 1. Явное переопределение метода аутентификации в коде

Если у вас есть возможность вносить изменения в конфигурацию (например, через расширение) или вы пишете собственную обработку отправки писем, откажитесь от автоматического определения метода авторизации. Вместо свойства СпособSMTPАутентификации.ПоУмолчанию принудительно укажите базовый метод авторизации.

Проанализируем пример кода инициализации профиля:


Профиль = Новый ИнтернетПочтовыйПрофиль;

// Задаем стандартные настройки сервера
Профиль.АдресСервераSMTP = "mail.yourcompany.ru";
Профиль.ПортSMTP = 25;

// Указываем учетные данные
Профиль.ПользовательSMTP = "shopp@yourcompany.ru";
Профиль.ПарольSMTP = "v@ry_Str0ng_P@ssword";

// КРИТИЧЕСКИ ВАЖНАЯ СТРОКА: явно задаем способ аутентификации!
// Вместо СпособSMTPАутентификации.ПоУмолчанию используем Login или Plain
Профиль.АутентификацияSMTP = СпособSMTPАутентификации.Login; 

ИнтернетПочта = Новый ИнтернетПочта;
Попытка
    ИнтернетПочта.Подключиться(Профиль);
    // Отправка письма...
    ИнтернетПочта.Отключиться();
Исключение
    Сообщить("Возникла ошибка подключения: " + ОписаниеОшибки());
КонецПопытки;

Установка значения СпособSMTPАутентификации.Login заставит новую библиотеку платформы проигнорировать сложные протоколы NTLM/GSSAPI и сразу передать серверу связку логина и пароля по стандартной схеме, аналогично тому, как это делала старая библиотека в ЗУП 2.5.

---

Решение 2. Корректировка формата логина для NTLM-авторизации

Если корпоративный почтовый сервер Microsoft Exchange настроен на обязательную доменную авторизацию сотрудников, вы можете оставить способ авторизации по умолчанию, но привести имя пользователя к правильному формату, который устроит NTLM-протокол.

Попробуйте изменить формат заполнения поля Пользователь SMTP в настройках учетной записи 1С:

Укажите логин с указанием вашего внутреннего AD-домена: DOMAIN\username (где DOMAIN — имя вашего локального домена Active Directory, а username — имя учетной записи Windows).
Или попробуйте указать полный почтовый адрес (User Principal Name): username@yourcompany.ru.

Очень часто простое добавление имени домена перед логином полностью решает проблему прохождения авторизации по современному протоколу.

---

Решение 3. Включение SSL/TLS шифрования

Современные версии Exchange Server запрещают передачу паролей без шифрования соединения. Если ваш сисадмин настроил требования безопасности по современным стандартам, отправка почты по незащищенному 25-му порту из ЗУП 3.1 работать не будет.

Посмотрим на пример правильной настройки защищенного соединения в 1С:


Профиль = Новый ИнтернетПочтовыйПрофиль;
Профиль.АдресСервераSMTP = "mail.yourcompany.ru";

// Переключаемся на защищенный порт (стандартно 587 для TLS или 465 для SSL)
Профиль.ПортSMTP = 587; 

// Включаем использование защищенного протокола шифрования
Профиль.ИспользоватьSSLSMTP = Истина;

// Отключаем требование только защищенной аутентификации, если сервер допускает разные варианты
Профиль.ТолькоЗащищеннаяАутентификацияSMTP = Ложь;

Профиль.ПользовательSMTP = "shopp@yourcompany.ru";
Профиль.ПарольSMTP = "v@ry_Str0ng_P@ssword";
Профиль.АутентификацияSMTP = СпособSMTPАутентификации.Login;

В пользовательском интерфейсе ЗУП 3.1 эти настройки можно выполнить без программирования. Для этого перейдите в раздел Администрирование — Органайзер — Настройка системной учетной записи, установите флажок «Использовать безопасное соединение (SSL)» и укажите соответствующий порт.

---

Решение 4. Настройка анонимного релея на стороне почтового сервера (Рекомендуется)

Если база 1С:Зарплата и Управление Персоналом и сервер Microsoft Exchange находятся внутри одной закрытой локальной сети предприятия, лучшим решением для массовых автоматических рассылок (например, расчетных листков сотрудникам) станет настройка анонимного коннектора получения (Anonymous Receive Connector) на стороне Exchange.

Попросите вашего системного администратора выполнить следующие действия на почтовом сервере:

Создать новый выделенный коннектор получения (Receive Connector) на сервере Exchange.
В настройках области действия (Scoping) жестко ограничить список разрешенных IP-адресов, прописав туда исключительно IP-адрес сервера 1С (или компьютера, с которого запускается файловая база). Это исключит возможность несанкционированной отправки спама посторонними лицами.
В параметрах безопасности коннектора включить группу разрешений Anonymous users (Анонимные пользователи).

После этого в настройках почтового профиля в 1С ЗУП 3.1 вы можете полностью отключить авторизацию:

Профиль.АутентификацияSMTP = СпособSMTPАутентификации.БезАутентификации;

Это самый стабильный, быстрый и безопасный способ организации рассылки внутри компании. 1С будет мгновенно отдавать письма почтовому серверу по IP без необходимости передавать и регулярно обновлять пароли пользователей в базе данных.

---

Решение 5. Особенности работы с Microsoft Office 365 (облачный Exchange)

Если ваша корпоративная почта расположена в облаке Microsoft 365, вы можете столкнуться с глобальной политикой Microsoft по полному отключению устаревшей базовой проверки подлинности (Basic Authentication). В этом случае обычные логин и пароль работать перестанут.

Чтобы восстановить работоспособность учетной записи:

Администратор вашей организации в панели управления Microsoft 365 Admin Center должен зайти в свойства активного пользователя (от имени которого отправляется почта из 1С).
Перейти на вкладку Почта (Mail) и выбрать пункт Управление почтовыми приложениями (Manage email apps).
Убедиться, что флажок Проверка подлинности SMTP (Authenticated SMTP) установлен. Без этой галочки облако будет отклонять любые попытки авторизации со стороны 1С.
Если флажок уже установлен, но отправка все равно выдает ошибку 535, снимите его, сохраните изменения, подождите 5-10 минут и установите его заново. Это принудительно обновит политики безопасности для данного ящика на серверах Microsoft.

Подводя итог, отметим, что переход на новые режимы совместимости в платформе 1С приносит не только новые возможности, но и повышает требования к качеству настройки сетевой безопасности. Понимание различий в поведении старой библиотеки imaplib и новой libetpan позволит вам быстро локализовать и устранять подобные сетевые проблемы при любом обновлении конфигураций.