Интернет-магазин продуктов · 1С-Битрикс · кейс под NDA
Письма с сайта перестали доходить. Причин было три
Две недели покупатели оформляли заказы и не получали ни одного письма. Магазин работал, оплаты проходили, а подтверждения не доходили — и никто не понимал почему. Причин оказалось три, и каждая закрывала собой следующую.
Кейс закрыт соглашением о неразглашении: под плашками — домены, адреса и адрес сервера. Всё техническое оставлено как есть.
Что мешало найти причину
- Рассылки уходили нормально, а подтверждения заказов — нет. Это сбивало с толку сильнее всего
- Почтовый сервер был жив, очередь росла молча: письма копились с ошибкой «истекло время ожидания»
- Хостинг сообщил, что порт открыл, — по факту он остался закрыт
- С сервера письма отправлялись руками и доходили, а с сайта — нет
- Изменений в коде и настройках почты не было с позапрошлого года
Слой первый: исходящий порт молча закрыт
Письма копились в очереди с ошибкой соединения. Самое старое зависшее письмо было датировано днём, который совпал с началом жалоб — и с перезагрузкой сервера. Похоже на новое правило файрвола, вступившее в силу при перезапуске.
Чтобы не спорить с хостингом словами, собрали доказательства: трассировка по 25-му порту глохла на первом же узле провайдера, а по 443-му проходила насквозь; сетевой дамп показывал запрос на соединение без единого ответа — тихое отбрасывание пакетов вышестоящей сетью. Локального файрвола на сервере не было.
После первого ответа «мы открыли» проверили тем же способом — порт оставался закрыт. Отправили повторное обращение со свежим логом, конкретным адресом сервера и уточнением, что речь об исходящем трафике. После этого порты открыли по-настоящему.
Слой второй: письма пошли, но их резали как спам
Очередь начала разгребаться, и тут же проявилась вторая проблема, которую мы предсказали заранее: почта домена обслуживается внешним сервисом, а письма уходили напрямую с адреса сервера сайта. Принимающая сторона отвечала отказом «сообщение распознано как спам».
- В запись SPF добавили адрес сервера, с которого реально идёт отправка
- Подняли подпись DKIM: свой ключ на 2048 бит и фильтр в почтовом сервере
- Подпись подключили именно для писем, идущих не по SMTP: сайт отдаёт их локальной командой отправки, и на обычном SMTP-фильтре они бы прошли неподписанными
- Переписали адрес в конверте письма: заголовок был верный, а конверт — технический, и проверка SPF шла именно по нему
Слой третий: сайт и сервер отправляли письма по-разному
Заказы всё равно не уходили: в журнале событий сайта отправка помечалась неуспешной, и письмо не доходило даже до почтового сервера. При этом та же отправка из командной строки работала.
Причина оказалась в том, где задан путь к программе отправки. Для сайта он был прописан не в конфигурации PHP, а в настройках веб-сервера — и указывал на другой почтовый клиент, который авторизовался у почтового провайдера. Провайдер этот доступ отклонял: на тарифе ящика SMTP-доступ был отключён.
Свели оба пути к одному: и сайт, и командная строка теперь отправляют через тот же почтовый сервер, что и всё остальное.
Что стало
Письма приходят во «Входящие», а не в спам. Проверено не тестовым скриптом, а штатным механизмом магазина и реальным заказом — тем же путём, которым идут уведомления покупателям. Настройки переживают перезагрузку, все правки с резервными копиями, порядок восстановления описан отдельным документом.
Чему это научило
Когда чинишь почту, легко остановиться на первой найденной причине — она выглядит достаточной. Здесь каждая из трёх полностью объясняла симптом и при этом была не единственной. Отсюда правило: проверять не «стало ли лучше», а тем же способом, которым пользуется живой сайт. И держать в голове, что путь отправки у веб-сервера и у командной строки может различаться — это различие не видно ни в одном логе, пока не начнёшь искать его специально.
Похожая ситуация
Если письма с сайта не доходят, а причина не находится — расскажите, что происходит. Начнём с разбора: где именно теряются письма и на чьей стороне.