Отправка почты в BitrixVM: настройка и проверка
Портал и сайт отправляют письма обычной функцией PHP, а дальше письмо передаётся почтовому агенту сервера. В девятой версии машины это msmtp, в старых использовался Postfix — поэтому инструкции из интернета часто не совпадают с тем, что у вас.
Сначала: где именно встало
Письмо проходит три участка, и чинить нужно тот, на котором остановилось.
- Сайт поставил письмо в очередь. Почтовые события копятся в таблице
b_event: пока агент их не обработал, поле времени отправки пустое. - PHP передал письмо агенту. Проверяется отправкой из командной PHP-строки в административной части.
- Агент отдал письмо почтовому серверу. Это видно в журнале
/home/bitrix/.msmtp.log.
Самая частая ошибка разбора — чинить настройки msmtp, когда письма вообще не доходят до него: события лежат в очереди, потому что не выполняются агенты. Тогда смотреть нужно не почту, а расписание.
Проверка по шагам
tail -n 20 /home/bitrix/.msmtp.logСтроки журнала содержат всё нужное: хост, был ли TLS, была ли авторизация, отправителя, получателей и текст ошибки от сервера. Если журнала нет вовсе — почта ни разу не отправлялась через msmtp, и дело не в его настройках.
Что умеет почтовый сервер, показывает отдельная команда:
msmtp --serverinfo --host=smtp.example.ru --port=587Она отвечает, поддерживает ли сервер шифрование и какие способы авторизации принимает, — это снимает половину вопросов до правки конфигурации.
Сообщения и что они значат
| Сообщение | Причина |
|---|---|
the server does not support TLS via the STARTTLS command | Включён tls_starttls, а сервер его не поддерживает: обычно это порт 465 с прямым TLS |
unexpected TLS packet was received | Наоборот: прямой TLS там, где нужен STARTTLS (порт 587) |
cannot use a secure authentication method | Шифрование выключено, а сервер требует защищённую авторизацию |
cannot connect to ..., port 25: Connection refused | Порт закрыт: файрвол сервера или ограничения хостинга |
552 5.3.4 Error: message file too big | Письмо с вложением больше лимита почтового сервера |
exitcode=EX_TEMPFAIL | Временная ошибка: сервер недоступен или отказал, стоит повторить |
Пары «порт — шифрование» в девяти случаях из десяти и есть причина: 465 — прямой TLS без STARTTLS, 587 — STARTTLS включён. Перебирать наугад не нужно, достаточно спросить у сервера его возможности командой выше.
Отдельный случай: почтовый агент не назначен
На свежей девятой машине встречается ситуация, когда почта не работает вовсе, хотя настройки верные: в системе не выбран msmtp в качестве агента отправки. Проверяется и выставляется системной командой выбора альтернатив для mta. Признак — письма не уходят ниоткуда, и журнал msmtp пуст.
Где лежит конфигурация
/home/bitrix/.msmtprc— настройки для пользователя сайта, основной вариант;/etc/msmtprc— общесистемный, используется, когда отправляют другие пользователи.
Файл должен принадлежать тому пользователю, от имени которого работает сайт, и быть закрыт от чужих глаз: в нём лежит пароль от почтового ящика. Если прав слишком много, msmtp откажется его читать — и это тоже выглядит как «почта не работает».
Из консоли уходит, из портала нет
Частая и запутанная картина: из терминала письмо отправляется, из командной PHP-строки тоже, а из почтовика портала или из карточки лида — нет. Это значит, что проблема не в msmtp: портал отправляет такие письма другим механизмом, через свои настройки почтовых ящиков. Смотреть нужно настройки ящика в портале, а не конфигурацию сервера.
Несколько сайтов на одном сервере
Если сайтов несколько, у каждого свой пользователь и своя конфигурация. Типичный симптом — с одного сайта письма уходят, с другого нет. Проверьте, что файл настроек есть у нужного пользователя и что сайт работает именно от его имени.
Чего не починит настройка сервера
Доставка зависит не только от отправки. Чтобы письма не падали в спам, нужны записи в DNS домена: SPF разрешает вашему серверу отправлять письма от имени домена, DKIM подписывает их, DMARC говорит получателю, что делать с неподписанными. Без них идеально настроенный сервер будет аккуратно складывать письма в папку «Спам».
Отдельно проверьте адрес отправителя: многие почтовые сервисы запрещают отправлять от имени адреса, который не принадлежит аккаунту. В настройках сайта он должен совпадать с ящиком, через который отправляете.
Что проверять, когда письма с сайта не доходят до получателя, разобрано в отдельной инструкции.
Частые вопросы
Письма не уходят, а журнал msmtp пустой.
Значит до агента они не дошли. Либо в системе не выбран msmtp как агент отправки, либо письма лежат в очереди портала и их не разбирает агент. Проверьте выполнение агентов и заданий cron, прежде чем править настройки почты.
Как понять, какое шифрование нужно почтовому серверу?
Спросить у него: команда msmtp --serverinfo с адресом и портом покажет, поддерживает ли он STARTTLS и какие способы авторизации принимает. Это быстрее, чем перебирать настройки наугад.
Ошибка «the server does not support TLS via the STARTTLS command».
Включён STARTTLS там, где сервер ждёт прямой TLS. Обычно это значит порт 465 с tls on и выключенным tls_starttls. Обратная ошибка про unexpected TLS packet означает ровно наоборот — нужен порт 587 со STARTTLS.
Из консоли письмо отправляется, из портала нет.
Значит msmtp ни при чём: портал отправляет такие письма через свои настройки почтовых ящиков, а не через системный агент. Смотрите настройки ящика в портале.
С одного сайта письма уходят, с другого нет.
У каждого сайта свой пользователь и своя конфигурация msmtp. Проверьте, что файл настроек лежит у нужного пользователя, принадлежит ему и что сайт работает от его имени.
Письма уходят, но попадают в спам.
Это не про сервер, а про репутацию домена: нужны записи SPF, DKIM и DMARC, а адрес отправителя должен принадлежать вашему домену. Без них даже идеально настроенная отправка складывается в «Спам».
Ошибка 552 message file too big.
Письмо с вложением больше лимита почтового сервера. Уменьшайте вложения или отправляйте ссылку на файл вместо самого файла — лимит задаётся на стороне почтового сервиса, и обойти его с сайта нельзя.
