Почему не работает почта в клиент-серверном варианте 1С и как это исправить?

Системный администратор 1С v8.3 (Управляемые формы) 1С:Комплексная автоматизация IT и автоматизация бизнеса
← На главную

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

Разберем разницу между файловым и клиент-серверным режимами

Чтобы понять корень проблемы, давайте посмотрим на архитектуру работы 1С в разных режимах. В файловом режиме получение и отправка почты происходят от имени того пользователя Windows, под которым открыта сама программа 1С. У интерактивного пользователя (например, администратора или бухгалтера), как правило, уже корректно настроены доступы к сети, установлены необходимые сертификаты, а также правильно заданы системные параметры прокси-сервера.

В клиент-серверном варианте все ресурсоемкие операции, включая DNS-запросы и сетевые подключения по протоколам POP3/SMTP/IMAP, выполняет сервер 1С. Эти процессы запускаются в фоновом режиме от имени пользователя операционной системы, под которым работает служба Агента сервера 1С. По умолчанию при установке платформы создается локальный пользователь USR1CV8. Именно у этой служебной учетной записи по умолчанию сильно ограничены сетевые и системные права.

Проанализируем ошибку подключения к почтовому серверу

В процессе диагностики работы почты (например, при попытке подключиться к pop.gmail.com) может возникать следующая ошибка:


Произошла ошибка при работе с POP3. Код ошибки: 6. Ответ сервера: malformed command c15mb9795749ltr
При обращении по URL: pop.gmail.com
Подключение проводится на сервере 1С:Предприятие.
Выполнено обращение к несуществующему ресурсу на сервере pop.gmail.com
или возникли неполадки на удаленном сервере.

На первый взгляд, сервер доступен (команда ping проходит успешно), однако 1С не может корректно обменяться данными с почтовым сервисом. Рассмотрим основные причины такого поведения:

  1. Проблемы с защищенным соединением (SSL/TLS): Ошибка malformed command при обращении к серверам Google чаще всего связана с неудачной попыткой установить защищенное соединение. У пользователя службы 1С может не быть доступа к системному хранилищу сертификатов.
  2. Устаревшие методы авторизации: Почтовые сервисы, в частности Google, давно запретили авторизацию сторонних приложений по обычному паролю от ящика. Для корректной работы необходимо в настройках безопасности аккаунта Google сгенерировать «Пароль приложения» (App Password) и указать его в настройках учетной записи в 1С.
  3. Ошибки платформы: В некоторых релизах платформы (например, 8.3.22 и 8.3.23) существует официально зарегистрированный баг, который ломает работу почты с серверами Google именно из-за ошибки установки защищенного соединения. В таких случаях рекомендуем обновить платформу.

Влияние настроек прокси-сервера

Обратим внимание на важную строчку в журнале диагностики: «Параметры прокси-сервера в ИБ не указаны (используются системные настройки прокси)». Системные настройки прокси в ОС Windows привязываются к профилю конкретного пользователя.

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

Решение проблемы: правильная настройка прав для USR1CV8

Часто администраторы прибегают к быстрому, но опасному решению — выдают пользователю USR1CV8 полные права Администратора. Это действительно решает проблему, так как снимает все ограничения на доступ к системным папкам, хранилищу сертификатов и обходит локальные политики безопасности. Однако использовать такой подход на постоянной основе категорически не рекомендуется из соображений безопасности сервера.

Разберем по шагам, какие права действительно необходимо выдать служебной учетной записи:

  1. Права на каталоги: Предоставьте пользователю USR1CV8 полные права на чтение и запись в папку с настройками кластера серверов 1С (обычно это C:\Program Files\1cv8\srvinfo\), а также в папку временных файлов (Temp) профиля самого пользователя USR1CV8.
  2. Сетевые разрешения: В системном брандмауэре (Windows Firewall) необходимо создать разрешающие правила на исходящие сетевые подключения для рабочих процессов 1С (файлы ragent.exe, rmngr.exe и rphost.exe). Обязательно разрешите трафик по стандартным почтовым портам (25, 110, 143, 465, 587, 993, 995).
  3. Локальные политики: В оснастке локальных политик безопасности (Local Security Policy) учетная запись службы обязательно должна иметь право «Вход в качестве службы» (Log on as a service).
  4. Доменные политики (опционально): Если вы запускаете службу Агента сервера от имени доменной учетной записи (чтобы избежать проблем с авторизацией в SQL или доступом к сетевым папкам), убедитесь, что этой доменной учетке разрешены DNS-запросы и выход во внешнюю сеть через прокси-сервер компании.

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

← На главную