Как сохранить отправку из 1С и МФУ при переезде почты

Чтобы сохранить отправку из 1С и МФУ при переезде почты, я проверяю их SMTP отдельно от входящих писем. Смена MX не меняет сохранённый сервер отправки. До переключения нужно собрать список отправителей, проверить совместимость и доставку документов, а затем повторить проверки на новой площадке.

Почему смена MX не перенастраивает 1С и сканер

Я сначала разделяю два маршрута. По MX внешние почтовые серверы находят, куда доставлять письма для нашего домена. А 1С и МФУ обычно подключаются к SMTP-серверу, записанному в их настройках. Этот адрес, порт и пароль смена MX не переписывает. Поэтому при переносе корпоративной почты я отдельно проверяю входящие ящики и отдельно — все источники исходящих сообщений. Работает один маршрут — ещё не значит, что работает второй.

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

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

Как найти все почтовые настройки в 1С и МФУ

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

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

Затем я проверяю, кто фактически отправляет документы: пользователь из своего сеанса, серверное задание, внешняя обработка или отдельная интеграция. Для каждого сценария запускаю его обычное действие. Подстановка нового пароля в личную карточку не поможет заданию, которое читает другую настройку. Отдельно спрашиваю про расписания и редкие рассылки: ежедневный отчёт легко проверить сразу, а уведомление по событию нужно вызвать на тестовых данных. Редкая отправка остаётся частью системы, даже если о ней вспомнили последней.

У МФУ я проверяю встроенную адресную книгу, профили сканирования, SMTP-настройки и доступный журнал заданий. У сайта или CRM выясняю, используется ли внешний SMTP, локальный почтовый сервис или собственная интеграция. Дальше связываю источник с конкретным адресом отправителя и контролируемым адресом для возвратов. Учётная запись без ответственного быстро превращается в загадку для следующего администратора. Учётная запись с известным назначением позволяет менять доступ и проверять последствия без гадания. Подробности настройки самого устройства — в разборе сканирования с МФУ в почту.

• Для каждой базы 1С записать учётную запись и сценарии отправки.
• Для каждого МФУ проверить модель, прошивку и режим защищённого соединения.
• Найти фоновые задания, сайты, CRM и внешние обработки.
• Назначить ответственного за служебный адрес и уведомления об ошибках.
• Зафиксировать пробную доставку для каждой строки реестра.

Когда подключаться напрямую, а когда нужен SMTP-релей

Если программа или устройство поддерживает требования нового сервера, я подключаю его напрямую. Имя SMTP беру из документации выбранной площадки: оно не обязано совпадать с нашим почтовым доменом. Для клиентской отправки распространены порт 465 с TLS сразу после подключения и порт 587 с переходом на TLS через STARTTLS. Это разные режимы установления соединения. Я выбираю поддерживаемую сервером и клиентом пару «порт — режим» и требую защищённое соединение до передачи учётных данных.

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

Если старое МФУ не умеет нужный режим TLS или способ входа, я рассматриваю локальный SMTP-релей. Он принимает письмо от разрешённого устройства и передаёт дальше по согласованному маршруту, например через сервер отправки площадки. Приём без пароля допускаю только на изолированном участке сети с ограничением доступа конкретными устройствами. Один список разрешённых IP не делает схему безопасной: нужны сетевые ограничения, защита самой сети и проверка правил пересылки. Доверить всю офисную сеть ради одного сканера — щедрость за чужой счёт.

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

Как проверить отправку и отличить приём от доставки

До смены MX я отправляю из каждого источника письмо во внутренний и внешний тестовые ящики, которыми мы управляем. Проверяю короткое сообщение и типичное рабочее вложение: документ из 1С, многостраничный скан с МФУ. Пустое письмо не проверяет ограничения на размер и обработку файлов. Для каждого теста сохраняю время, источник, получателя и тему, чтобы найти его в журналах. Набор данных беру тестовый: для проверки транспорта настоящие счета и персональные документы не нужны.

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

При отказе я сохраняю полный ответ сервера и этап, на котором он получен. SMTP-коды класса 4xx обозначают временный отказ, при котором предусмотрена повторная попытка; класс 5xx — постоянный отказ для этого запроса. После 5xx бессмысленно бесконечно повторять ту же отправку без исправления причины. Возможность автоматического повтора у конкретной программы или МФУ я проверяю отдельно: наличие очереди на центральном сервере не создаёт очередь внутри устройства. При неоднозначном результате сначала ищу письмо в журнале, чтобы повторной отправкой не наделать дублей.

Для доставленного письма проверяю адрес отправителя, вложение и результаты проверки домена на принимающей стороне. SPF должен учитывать фактический источник отправки. Для DKIM недостаточно добавить запись в DNS: исходящий узел должен подписывать письма, а публичный ключ позволяет проверять подпись. DMARC связывает проверку SPF или DKIM с доменом в видимом адресе отправителя. Успех этих проверок не гарантирует попадания во входящие: остаются репутация и правила получателя. Если письмо принято, но оказалось в спаме, это отдельный результат теста, а не повод объявить миграцию завершённой.

• Проверить ручную отправку из каждой базы 1С.
• Запустить штатное фоновое задание с тестовыми данными.
• Отправить скан через используемый сотрудниками профиль МФУ.
• Найти каждое письмо у получателя и проверить вложение.
• Проверить отказ и уведомление об ошибке на контролируемом тесте.

Когда переключать MX и отключать старую площадку

Новый сервер, ящики и выбранные маршруты отправки я готовлю до переключения входящего потока. Затем согласую окно работ и порядок изменения источников: какие можно перевести заранее, какие требуют общего переключения. При необходимости заранее уменьшаю TTL записи MX и учитываю прежний TTL: уже закэшированная запись не станет новой только потому, что я изменил срок её хранения сейчас. Сама смена MX не переносит историю ящиков. Доставку новых писем и перенос накопленной почты принимаю как разные части работы.

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

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

Универсальной недели ожидания я не назначаю. Решение об отключении принимаю по прежнему TTL, журналам поступлений, состоянию очередей, завершённой синхронизации и проверке всех известных расписаний отправки. До этого момента храню старые параметры и согласованный порядок отката. Если не работает только МФУ, сначала возвращаю его маршрут отправки; откат MX затронет входящие письма всей компании. Если возвращать приходится входящий поток, сначала оцениваю новые поступления на обеих площадках и способ их сверки. Иначе вместо восстановления получится разъезд почты по двум ящикам.

Условный разбор: салон оптики «Ясный взгляд»

Возьму заданный условный офис: московский салон оптики «Ясный взгляд», 11 рабочих мест. Для разбора сохраню из исходного сценария одну базу 1С и одно МФУ. Это учебный пример проверки маршрутов, без заявления о реальном обслуживании салона и измеренном простое. Количество рабочих мест здесь не равно количеству почтовых ящиков. Я начинаю с двух известных источников документов и спрашиваю ответственного, какие ещё системы отправляют уведомления от домена.

В сценарии у 1С остаётся адрес старого сервера отправки, а у МФУ — прежняя точка подключения. Смена MX сама эти настройки не сломала; ошибка проявится, когда старый маршрут станет недоступен или перестанет разрешать отправку. На этапе подготовки я проверяю прямое подключение 1С к новому SMTP. Для примера выбираю 587 с STARTTLS только при подтверждённой поддержке с обеих сторон. Если такой совместимости нет, меняю решение по результату проверки, а не переставляю флажки шифрования наугад.

Для МФУ моделирую вариант, в котором прямое защищённое подключение к новой площадке недоступно. Тогда готовлю локальный релей с доступом только от устройства и проверяю дальнейшую защищённую отправку. До окна переключения выполняю отправку документа из 1С и скана, затем проверяю штатное задание, если оно используется. После перевода повторяю проверки. Длительность наблюдения определяю по DNS, очередям и реальным расписаниям; обещать этому сценарию один день или две недели без обследования было бы выдумкой.

Итог такого разбора — заполненный реестр, проверенный маршрут каждого источника, найденные у получателей тестовые документы и понятный порядок реакции на отказ. В рабочем проекте я приложил бы результаты тестов и выписку из журналов без секретов. Сам факт настройки SPF и DKIM не позволяет написать «ноль потерь», как и отсутствие жалоб не доказывает доставку. Я считаю задачу принятой, когда ответственный может повторить проверку, найти ошибку и понять, кто её исправляет. Остальное слишком похоже на сдачу ремонта по фотографии отвёртки.

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