Назад | Перейти на главную страницу

Как SendMail определяет, какие подключения кэшируются?

CentOS 5.x | SendMail 8.14.4

Я пытаюсь понять, как работает кэширование подключений в Sendmail.

У меня возникают проблемы с подключением к некоторым удаленным почтовым узлам, с которыми мы часто общаемся, и мы наблюдаем такие ошибки, как:

dsn=4.0.0 stat=Deferred: Connection timed out with <FQDN>

В рамках процесса устранения неполадок мой специалист по брандмауэру хотел бы знать, использует ли мой сервер SendMail только соединение с отслеживанием состояния.

Сначала я думал, что это не так ... но потом вспомнил о функции кэширования подключений. Я проверил /etc/mail/sendmail.cf и подтвердил, что присутствуют следующие параметры:

O ConnectionCacheSize=2
O ConnectionCacheTimeout=5m

Для меня это означает, что SendMail будет поддерживать до 2 SMTP-соединений открытыми (по 5 минут каждое) на случай, если туда потребуется больше сообщений.

У меня вопрос: как SendMail определяет, какие соединения кэшируются? Это чисто первая отправка, первое кэширование? Или за механизмом кеширования стоит более сложная логика?

AFAIK В типичной конфигурации sendmail кеш соединения не используется для начальной / первой попытки доставки (может быть, кроме случаев, когда сообщение слишком большому количеству получателей разбивается на множество сообщений). В таких конфигурациях он используется, когда sendmail повторяет доставку сообщений из очереди.

IMHO На типичном сайте электронной почты с небольшой нагрузкой более 95% исходящих сообщений могут быть доставлены с помощью первоначальной попытки доставки «сразу».


ИМХО более крупные почтовые сайты могут рассмотреть возможность использования отдельных групп очередей для самых верхних исходящих пунктов назначения и избежания начальной попытки доставки «сразу» (обычно он отправляет одно электронное письмо через одно соединение SMTP.

  • Постоянные обработчики очереди могут уменьшить задержки в таких конфигурациях «отказ от немедленной доставки».
  • пользовательские определения почтовой программы могут пропускать попытки доставки "сразу" (F = e дорогой флаг) и ограничивать количество сообщений, отправляемых через одно соединение smtp (m =)

Группы очередей (V8.12 и выше)