Как восстановить отправку писем из 1С после обновления

Если после обновления 1С перестала отправлять письма, не перезапускайте всё подряд: сначала выясните, где рвётся цепочка — в конфигурации 1С, SMTP-подключении или почтовом сервере. Я покажу, как проверить каждый участок и подтвердить восстановление тестовым письмом.

Сначала выясните, что именно перестало работать

Почта в 1С — не всегда отдельная служба на сервере. Платформа умеет отправлять и получать письма через встроенный механизм, а может обращаться к почтовому клиенту, установленному на компьютере. Встроенный сценарий использует настройки почтовых протоколов; в конкретной конфигурации путь может отличаться. Поэтому не начинайте с поиска абстрактного «почтового агента 1С». Сначала определите, из какого раздела и под какой учётной записью отправляется письмо, где выполняется отправка — на рабочем месте или на сервере — и кто принимает соединение: корпоративный шлюз или внешний сервис. Если вашей организации нужна стабильная корпоративная почта, её настройки тоже надо сверять с реальным способом отправки из 1С.

Затем сузьте область сбоя. Не уходят письма у всех сотрудников или только у одного? Не отправляются все сообщения или только письма с вложениями? Ошибка появляется при нажатии «Отправить», при регламентной рассылке или после сохранения документа? Отдельно проверьте, работает ли приём, если он вообще настроен в этой базе: отправка и получение могут идти разными путями. Эти ответы не заменяют журнал событий или ответ SMTP, но помогают выбрать правильный узел для проверки. Если сбой только у одной учётной записи, перезапуск сервера 1С вряд ли объяснит, почему остальные отправляют нормально.

В условном кейсе сети «Ясень-Сервис» после обновления типовой конфигурации отправка остановилась. При проверке выяснилось, что в настройке остался внутренний адрес вместо адреса почтового шлюза. Это пример конкретной ошибки, а не правило о том, что обновление 1С сбрасывает почту. Совпадение по времени — повод сравнить настройки до и после изменения, но само по себе оно не доказывает причину. Я записываю симптом и проверяю фактический адрес, прежде чем менять пароль, перезапускать службы или обвинять обновление.

Для начала зафиксируйте короткую карточку сбоя: пользователь и база, примерное время, операция, полный текст ошибки и что менялось перед её появлением. Пароль и содержимое письма в карточку не включайте. Не запускайте массовую повторную отправку, пока не выяснили, попали ли предыдущие сообщения на сервер: иначе вместе с восстановлением можно получить дубли документов и уведомлений. Тут полезна скучная точность. Она дешевле, чем разбирать последствия «нажал ещё раз — вдруг дойдёт».

Когда симптом зафиксирован, сверяйте его с проверкой параметров в используемой конфигурации 1С и с журналом того компонента, который действительно выполняет отправку. Названия разделов и доступные диагностические функции зависят от прикладного решения; инструкция к одной конфигурации не обязана совпадать с меню другой. В документации 1С описаны и встроенная отправка, и работа через установленный почтовый клиент. Значит, универсального пути по меню и универсальной службы для всех установок нет. Я бы насторожился, если инструкция обещает починить любую 1С одним переключателем.

Если после обновления не запускается сама информационная база или пользователь не может в неё войти, это уже отдельная неисправность сервера 1С. Сначала восстановите доступ к приложению, затем проверяйте отправку. Не смешивайте два инцидента: работоспособность службы 1С не доказывает исправность SMTP, а ошибка отправки почты не доказывает отказ сервера 1С. Такое разделение экономит время и не даёт чинить исправный компонент.

• Определите, у кого и когда появился сбой.
• Разделите отправку и получение писем.
• Уточните, где выполняется отправка из 1С.

Проверьте настройки учётной записи 1С

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

Сверьте не только значение каждого поля, но и то, какой профиль реально использует нужная операция. В базе могут быть отдельные учётные записи для уведомлений и для ручной отправки; документ или обработка может использовать собственную настройку. Проверьте адрес отправителя, если сервер ограничивает отправку от имени чужого ящика. Ищите признаки недавней смены пароля или политики аутентификации, но не меняйте пароль «на всякий случай»: это добавит второй фактор сбоя и может отключить другие интеграции. Я сначала сопоставляю профиль в 1С с настройкой на стороне почты, а уже потом исправляю конкретное расхождение.

Защищённое соединение тоже проверяйте парами: выбранный в 1С режим должен соответствовать режиму, который принимает SMTP-сервер. SSL/TLS и STARTTLS — не декоративные галочки и не взаимозаменяемые названия. Если соединение обрывается на этапе согласования защиты, полезен точный текст ошибки и запись почтового сервера о той же попытке. Не переключайте защиту на незашифрованную «для проверки». Такой эксперимент меняет безопасность канала и не отвечает на вопрос, почему согласование не сработало. Запросите у владельца почтового сервиса актуальные параметры и верните только их.

Если конфигурация предлагает отдельную проверку настроек почты, выполните её после сверки профиля и сохраните результат. Затем отправьте одно контролируемое сообщение на адрес, к которому у вас есть доступ. Проверяйте именно тот сценарий, который сломался: если не проходит рассылка из документа, тест из другого раздела не подтверждает её работу. Успешное тестовое письмо — полезный признак, но ещё не доказательство, что все регламентные задания и вложения работают так же. Поэтому я проверяю конкретную операцию, а не ставлю отметку «почта исправлена» по одному зелёному индикатору.

Если обновлялась прикладная конфигурация, сравните её текущие настройки с сохранённой копией или документацией вашей установки. Если обновлялась только платформа, проверьте, что конфигурация по-прежнему использует ожидаемый профиль и совместимый механизм соединения. Не делайте вывод, что параметры обязательно сбросились: это надо увидеть в самой настройке. Бывает, что обновление просто совпало с истечением пароля, изменением политики сервиса или правкой шлюза. В разборе важна проверяемая разница, а не удобная история о том, что «после обновления всегда так».

После исправления одного поля повторите тот же тест и сравните результат. Если изменили сразу адрес, пароль, порт и шифрование, вы не узнаете, какое расхождение было причиной, и осложните откат. Зафиксируйте новые значения, кроме секрета: пароль в открытом документе не храните. Если входящие письма также перестали обрабатываться, проверьте их отдельные настройки протокола и учётной записи; исходящий SMTP-профиль сам по себе ничего не говорит о приёме.

• Сверьте SMTP-сервер и имя учётной записи.
• Проверьте пароль и режим соединения.
• Повторите именно сломавшуюся операцию.

Сопоставьте ошибку 1С с ответом SMTP

Проверьте, что сообщает 1С и что зафиксировал сервер, который принимает отправку. Ищите запись по времени теста, адресу отправителя или получателя и идентификатору сообщения, если он доступен. Не всякая конфигурация записывает подробный результат в один и тот же журнал, поэтому отсутствие строки в журнале регистрации не доказывает, что «виновата сеть». Если журнал 1С показывает лишь общий отказ, ответ ищут на SMTP-шлюзе; если шлюз ничего не видел, проверяют тот клиент или сервер 1С, откуда должно было уйти соединение. Точка проверки должна совпадать с местом выполнения отправки, иначе можно успешно проверить не тот маршрут.

Ответ сервера помогает разделить причины. Отказ аутентификации направляет проверку к учётной записи и политике входа; отказ соединения — к адресу, порту, маршруту и согласованию защищённого канала; отказ конкретному получателю — к его адресу, ограничениям доставки или политике сервера. Это направления диагностики, а не готовые диагнозы: один и тот же общий текст в интерфейсе может скрывать разные ответы. Сохраните полный текст серверного ответа и сопоставьте его с документацией именно вашего сервиса. Если сервер принял письмо, но адресат его не видит, расследование уже не заканчивается на форме 1С.

Отправка из веб-интерфейса или обычного почтового клиента — полезный сравнительный тест, но он не копирует путь 1С. Клиент может использовать другие настройки, способ входа и серверный маршрут. Если письмо из клиента ушло, вы подтвердили, что учётная запись в целом доступна этим способом; параметры SMTP в 1С ещё надо проверить отдельно. Если не ушло и там, ищите проблему в почтовом сервисе или учётной записи до того, как менять настройки базы. Умение различать похожие тесты — не занудство, а защита от ложного вывода.

Проверяйте DNS и сетевые правила только по фактическому адресу сервера, который использует профиль. Сначала выясните, может ли узел 1С разрешить имя и установить соединение по разрешённому маршруту; если нет доступа к таким данным, запросите журналы у сетевого администратора. Не отключайте межсетевой экран и фильтрацию целиком, чтобы «посмотреть, заработает ли». Это не локализует правило и временно снимает защиту со всего потока. При подтверждённой блокировке корректируют конкретное правило с владельцем сети и повторяют исходный тест.

Если сервер отклоняет письмо из-за политики отправки или репутации, не подменяйте это настройкой пароля в 1С. Зафиксируйте отправителя, получателя, полный ответ сервера и время. Отдельно разбираю такие случаи в материале об ошибке 550 в SMTP: там важно читать формулировку отказа и выяснять, кто именно его вернул. Сам по себе код без текста ответа и контекста не объясняет причину.

В условном случае с «Ясень-Сервис» проблема оказалась именно в адресе шлюза, а не в очереди и не в праве на папку. Такой пример помогает выбрать первый тест, но не позволяет заключить, что все сбои после обновления вызваны адресом SMTP. В другом окружении отправку может выполнять внешний клиент или отдельный серверный процесс. Я проверяю цепочку от фактического места отправки до первого узла, который принял или отверг соединение.

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

Проверьте очередь только на почтовом сервере

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

Не считайте произвольный размер очереди аварией. Допустимый объём зависит от системы и обычной нагрузки; порог предупреждения задают по реальной работе конкретного сервера. Число из чужого скрипта или статьи нельзя объявить нормой для вашей почты. Важнее динамика очереди, возраст сообщений и причина повторных попыток доставки. Если очередь растёт, сначала прочитайте статус одного-двух сообщений и журналы, а не удаляйте их пачкой. Ручная очистка может потерять ожидающие письма и не устранит неверный пароль, недоступный сервер или отказ получателя.

Если конфигурация Postfix действительно менялась, его документация предписывает перечитать настройки работающей системы командой postfix reload. Выполняйте её на почтовом сервере после проверки внесённых изменений и по процедуре доступа, принятой в вашей установке. Эта команда перечитывает конфигурацию Postfix; она не перезагружает весь сервер и не исправляет профиль 1С. Не запускайте её на компьютере пользователя, где Postfix не установлен, и не переносите команду на другой почтовый продукт. Для нестандартной или контейнерной установки проверьте документацию именно этого окружения.

Если шлюз принял сообщение, но получатель не увидел его, проверьте дальнейший статус доставки и папку нежелательной почты у адресата. Не просите адресата массово переносить письма и не отключайте антиспам: сначала выясните причину фильтрации. Если сервер возвращает отказ по отправителю или маршруту, нужны параметры политики на стороне шлюза. Для схем, где Postfix выбирает SMTP-учётные данные в зависимости от отправителя, полезен отдельный разбор SMTP-аутентификации Postfix. Это серверная настройка, не универсальное поле в 1С.

Повторную отправку начинайте после того, как понятно, были ли предыдущие сообщения приняты. Сверьте очередь и журнал с адресатом, а не только с кнопкой отправки в 1С. Если письмо уже ушло дальше по маршруту, повтор может создать дубль; если оно осталось на сервере, второй клик не уберёт первопричину. Я не очищаю очередь и не перезапускаю почтовую службу как первый шаг. Сначала подтверждаю статус сообщения, затем исправляю тот параметр, на который указывает журнал.

При очереди на управляемом провайдером сервере не следует искать её на локальной машине и тем более менять локальные службы. Запросите у администратора сервиса идентификатор сообщения, результат доставки и объяснение отказа или задержки. При собственном Postfix сохраните относящиеся к тесту строки журнала перед изменениями. Такая последовательность оставляет след для проверки и позволяет понять, помогла ли конкретная правка. «Снесли очередь, стало пусто» — это отчёт об удалении писем, не о восстановлении доставки.

• Уточните, есть ли в схеме очередь сервера.
• Сверьте статус сообщения и причину задержки.
• Не удаляйте сообщения до разбора.

Подтвердите исправление и не повторяйте сбой

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

Запишите, что именно исправили: профиль, адрес сервера, режим соединения или настройку шлюза. Зафиксируйте дату изменения и владельца настройки, но не сохраняйте пароль в журнале работ. Если подключение зависит от учётной записи, договоритесь, кто отслеживает её изменение и кому сообщать об отказах. Для почтового сервера сохраните текущую конфигурацию до правки и опишите способ возврата. Бэкап настроек полезен, когда известно, что в нём лежит и как безопасно восстановить значения; копия без проверки восстановления — спокойствие на бумаге.

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

Настройте наблюдение за отказами и возрастом сообщений на том узле, где действительно существует почтовая очередь. Порог выбирайте по обычному объёму и времени доставки вашей системы, а не по универсальной цифре. Для прямой отправки из 1С отслеживайте результат самой операции или сообщения об ошибках; не ждите, что очередь Postfix покажет то, чего в этой схеме нет. Проверяйте, что уведомление о сбое доходит ответственному человеку и что у него есть доступ к нужным журналам. Мониторинг, который никто не читает, украшает панель, но почту не чинит.

В нашем условном кейсе исправление внутреннего SMTP-адреса вернуло отправку после контрольной проверки. Этот итог относится только к описанной конфигурации «Ясень-Сервис». Если у вас после теста сервер принимает письмо, а адресат его не получает, продолжайте разбор по журналу доставки; если 1С не устанавливает соединение, вернитесь к профилю и сетевому пути. Разные симптомы требуют разных действий. Универсальная кнопка «перезапустить всё» существует только в плохих инструкциях.

Если в работе почты участвуют разные подрядчики, передайте каждому точное время теста, адреса без паролей, текст ответа и идентификатор сообщения. Так администратор 1С проверит свою часть, а владелец почтового сервера — свою, не споря по кругу, у кого «всё зелёное». После локализации внесите одну правку, повторите тот же тест и запишите результат. Восстановление считается завершённым, когда подтверждён путь письма и понятен следующий шаг при повторном отказе, а не когда исчезло красное окно.

Если не хочется разбирать эти журналы самостоятельно, мы в «АйТи-Фреш» сверим профиль 1С, SMTP-ответ и статус доставки на почтовом сервере. Для почты под ключ до 15 ящиков цена начинается от 25 000 ₽. На выходе вы получите проверенную отправку и зафиксированные настройки, по которым можно диагностировать следующий сбой.

• Проверьте путь письма до адресата.
• Запишите результат и безопасный порядок отката.
• Настройте контроль по своей схеме.

Частые вопросы