Как устранить ошибку SMTP 421 и разрыв соединения при отправке почты из 1С через Office 365

← На главную

При интеграции систем 1С с современными облачными почтовыми сервисами, такими как Microsoft Office 365, разработчики часто сталкиваются с ситуацией, когда стандартный код отправки почты, годами работавший стабильно, начинает выдавать ошибку: Ошибка при вызове метода контекста (Послать): Сервис отключен с разрывом канала (SMTP error code 421 421 SMTP connection broken). Особенно загадочно эта проблема выглядит, когда в одной базе (например, «Бухгалтерия») почта уходит успешно, а в другой (например, «Управление торговлей»), расположенной на том же сервере, возникает критический сбой.

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

Анализ исходной ситуации и программного кода

Рассмотрим типовой сценарий: используется платформа 1С версии 8.3.10. Для отправки писем применяется объект ИнтернетПочта. Настройка профиля выполняется стандартным образом через ИнтернетПочтовыйПрофиль. Проанализируем пример кода, который часто используется для тестирования соединения:


Процедура ОтправитьТестПисьмо()
    ПараметрыПочты = новый ИнтернетПочтовыйПрофиль;
    ПараметрыПочты.АдресСервераSMTP = "smtp.office365.com";
    ПараметрыПочты.АутентификацияSMTP = СпособSMTPАутентификации.ПоУмолчанию;
    ПараметрыПочты.ПользовательSMTP = "your_login@domain.com";
    ПараметрыПочты.ПарольSMTP = "your_password";
    ПараметрыПочты.ПортSMTP = 587;
    ПараметрыПочты.ИспользоватьSSLSMTP = Ложь; // Важный момент для порта 587
    ПараметрыПочты.Таймаут = 600;

    Письмо = новый ИнтернетПочтовоеСообщение;
    Письмо.Тема = "Тест электронной почты";
    Письмо.Отправитель = "your_login@domain.com";
    Письмо.Получатели.Добавить("recipient@domain.com");
    Письмо.Тексты.Добавить("Проверка связи через Office 365");

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

В данной ситуации характерно то, что метод Подключиться() отрабатывает без ошибок, но выполнение метода Послать() приводит к немедленному разрыву соединения сервером. Это происходит из-за того, что Office 365 требует обязательного использования протокола STARTTLS на порту 587. Если клиент (1С) не инициирует безопасное соединение должным образом сразу после команды HELO/EHLO, сервер обрывает сессию.

Причина №1: Режим совместимости конфигурации

Выясним, почему одна база отправляет письма, а другая — нет, при идентичном коде. Ключ к разгадке часто кроется в свойстве конфигурации Режим совместимости. Если в одной базе установлен режим 8.3.1 или выше, а в другой — 8.2.13, платформа использует разные внутренние библиотеки для работы с защищенными соединениями.

В старых режимах совместимости (например, 8.2.13) 1С использует устаревшие алгоритмы и наборы шифров (Cipher Suites), которые Office 365 считает небезопасными. Microsoft постепенно отключает поддержку TLS 1.0 и TLS 1.1, требуя как минимум TLS 1.2. При установке современного режима совместимости платформа начинает использовать актуальные системные библиотеки Windows для работы с сетью, что позволяет успешно пройти этап рукопожатия (handshake) TLS.

Важное предупреждение: Изменение режима совместимости в рабочей базе — это серьезная операция. Как показывает практика, это может привести к неработоспособности самописных отчетов, использующих виртуальные таблицы (ОстаткиИОбороты), из-за изменений в механизмах генерации SQL-запросов. Поэтому, прежде чем менять этот параметр, необходимо провести полное тестирование системы.

Причина №2: Использование защищенного соединения (STARTTLS)

Проанализируем требования Office 365 к шифрованию. Для порта 587 характерно использование «явного SSL» (Explicit SSL), также известного как STARTTLS. В 1С это настраивается сочетанием порта и флага использования SSL.

Разберем, как правильно настроить параметры в современных версиях платформы:

Установите ПараметрыПочты.ПортSMTP = 587;.
Установите ПараметрыПочты.ИспользоватьSSLSMTP = Истина;.
Если платформа позволяет, используйте объект ЗащищенноеСоединениеOpenSSL.

Если вы используете версию платформы ниже 8.3.12, объект ИнтернетПочтовыйПрофиль может некорректно обрабатывать STARTTLS на некоторых конфигурациях. В этом случае сервер возвращает ошибку 451 5.7.3 STARTTLS is required to send mail или просто разрывает соединение.

Причина №3: Настройки на стороне Office 365 (SMTP AUTH)

Даже при идеально написанном коде в 1С, отправка может блокироваться на стороне облачного сервиса. Рассмотрим действия, которые должен выполнить системный администратор в панели управления Microsoft 365 Admin Center:

Разрешение SMTP AUTH: Перейдите в раздел «Активные пользователи», выберите нужный почтовый ящик, перейдите на вкладку «Почта» -> «Управление почтовыми приложениями» и убедитесь, что флажок «Проверка подлинности SMTP» (Authenticated SMTP) включен.
Security Defaults: Если в организации включены «Настройки безопасности по умолчанию» (Azure AD Security Defaults), использование базовой аутентификации (логин и пароль) может быть полностью заблокировано. В этом случае потребуется настройка исключений или использование OAuth 2.0 (доступно в 1С с версии 8.3.18).
Пароли приложений: Если для учетной записи включена многофакторная аутентификация (MFA), обычный пароль от почты не подойдет. Нужно создать специальный «Пароль приложения» в личном кабинете пользователя Microsoft.

Альтернативное решение: Использование локального SMTP-реле

Если изменение режима совместимости в 1С невозможно из-за риска поломки отчетов, а почту отправлять необходимо, проанализируем вариант с использованием промежуточного звена. Можно настроить локальный почтовый прокси-сервер (например, stunnel или встроенный компонент SMTP Server в Windows Server).

Схема работы будет выглядеть так:

1С отправляет письмо на localhost (127.0.0.1) по порту 25 без шифрования и авторизации.
Локальное реле принимает письмо.
Реле само авторизуется в Office 365, используя современный TLS 1.2 и правильные учетные данные, и пересылает письмо в облако.

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

Выясним причины разного поведения баз на одном ПК

Если одна база работает, а другая — нет, проверьте следующие моменты:

Разрядность клиента: 32-битный и 64-битный клиенты 1С могут обращаться к разным веткам реестра и использовать разные настройки безопасности Windows.
Настройки прокси в 1С: Проверьте, не заданы ли в «проблемной» базе системные настройки прокси-сервера (Параметры системы -> Прокси), которые могут перехватывать трафик 1С и мешать установке SSL-соединения.
Таймауты: Office 365 очень чувствителен к задержкам. Убедитесь, что перед вызовом Подключиться() письмо уже полностью сформировано. Если формирование вложений занимает много времени после вызова Подключиться(), сервер может разорвать соединение по таймауту.

Подводя итог, можно сказать, что наиболее эффективным решением для современных конфигураций является обновление режима совместимости до 8.3.1 и выше, а для критически важных старых систем — использование SMTP-реле или внешних библиотек для отправки почты.

← На главную