Почта в SuiteCRM 8: интерфейс, планировщик и процессы
- Успешное тестовое письмо из администрирования проверяет прежде всего интерактивный путь, но не обязательно тот же путь, что у планировщика или процесса.
- После минорных обновлений меняются требования к очередям, сохранённым SMTP-данным и выполнению задач; многочисленные сообщения на форумах зависят от версии.
- Стабильная почта — результат эксплуатации: настройки CRM, системный Cron, лимиты провайдера и бизнес-логика процессов.
Отправка как чёрный ящик
Очередь, статус, диагностика
Лимиты провайдера и массовая отправка
Многие SMTP-провайдеры ограничивают скорость или блокируют после определённых квот. Без очереди и обработки ошибок оставшаяся отправка прерывается или создаёт трудно восстанавливаемые пробелы. Числа и лимиты зависят от провайдера — смотрите его документацию и собственный мониторинг.
В SuiteCRM почта — не отдельная функция, а стык интерфейса, фоновой обработки и внешнего провайдера. Поэтому повседневные сообщения об ошибках часто противоречат друг другу: Вручную работает, автоматически — нет.
1. Три пути, которые команды смешивают
| Путь | Запуск | Зависимости | Типичное заблуждение |
|---|---|---|---|
| Интерфейс / создание письма / тест администратора | Человек нажимает сейчас | Сессия, права, текущий исходящий аккаунт | «SMTP в целом исправен» |
| Планировщик | Cron / запланированные задачи | Системный Cron, статус задач, пользователь CLI, очередь | «Cron работает, значит почта тоже» |
| Рабочий процесс | При сохранении или по расписанию | Момент запуска, условия, почтовое действие в процессе | «Процесс активен, значит отправляет» |
2. Исходящий аккаунт как единый источник путаницы
Во многих установках есть несколько исходящих записей, старые системные аккаунты и личные отправители. После обновлений администраторы иногда сообщают об успешных тестах интерфейса при неработающих сохранённых данных в фоне, например после перехода на длинные SMTP-пароли или несогласованности исходящих таблиц. Надёжный ответ — не двадцать раз вводить пароль, а выяснить:
- Какой аккаунт предназначен для системных писем и задач?
- Именно этот аккаунт указан в контексте задачи?
- Был ли аккаунт после обновления осознанно сохранён заново и проверен?
- Различаются ли ошибки интерфейса и временного окна задачи?
3. Планировщик: тихий отказ
Если Cron завис на уровне ОС, задачи завершены без результата или права веб-сервера отличаются от CLI, первыми перестают работать напоминания и письма процессов, а не ручная отправка. Проверки:
- Crontab / таймер Systemd документирован и назначен правильному пользователю
- Администрирование → Планировщик: критические задачи активны, последний запуск правдоподобен
- После обновления: новые требования, например Messenger или обработчик по выпуску, прочитаны и выполнены
4. Письма процессов: сначала логика, затем SMTP
Прежде чем обвинять провайдера, проверьте: не запускается ли процесс до привязки связанных контактов? Не зависит ли условие от поля, заполняемого позже в интерфейсе? Не остаётся ли экземпляр в работе, пока другие действия выполняются? Это ошибки проектирования процесса — SMTP-тесты администрирования их не выявляют.
5. Практический порядок диагностики
- Воспроизвести: контролируемая карточка, известный получатель с внутренним адресом.
- Тестовое письмо из предусмотренного системного аккаунта.
- Запустить ту же отправку через задачу или рабочий процесс.
- Проверить журналы за этот период: CRM и MTA или провайдер, если доступны.
- Только затем провайдер, межсетевой экран, SPF/DKIM — иначе оптимизируется не тот слой.
SuiteSMTP в AgenticUltimate нацелен на прослеживаемую отправку и лучшую видимость в CRM. Он не заменяет системный Cron и корректное моделирование процессов. Для команд с множеством автоматических писем видимость часто важнее очередного круга перенастройки SMTP.
SuiteSMTP ↗Рассматривайте почту как три системы под одним названием. Знать только тест администратора — не значит знать систему.