Отладка «невозможно подключиться к серверу sendmail»

Отладка «невозможно подключиться к серверу sendmail»

В корпоративной среде у нас есть почтовый сервер, на котором доступны только порты 25/tcp и 587/tcp.

Когда мы используем скрипты Perl (используя HTML::Mail) для отправки сотен легитимных писем, время от времени происходит сбой с сообщением «Не удалось подключиться к почтовому серверу».

Мы считаем, что большая нагрузка на сервер sendmail заставляет его отклонять соединение или даже не отвечать на первоначальный запрос.

Теперь команда, которой принадлежит почтовый сервер, не желает сотрудничать и требует доказательств того, что сервер отклоняет соединение.

Вопрос: Какую информацию можно собрать со стороны клиента в случае сбоя, предполагая, что проблема на стороне сервера? Как доказать, что проблема на стороне сервера, при условии, что это действительно так?

[[ Я не уверен, уместен ли этот вопрос здесь; я не могу просить о помощи в решении проблемы, если сама проблема не ясна; я прошу краткий список советов и рекомендаций, которые помогут отладить эту проблему; я даже был бы открыт для предложений по обходным путям]]

решение1

Решение заключается в том, чтобы команда sendmail проверила свой файл «/etc/mail/sendmail.mc»:

dnl #
dnl # The following limits the number of processes sendmail can fork to accept 
dnl # incoming messages or process its message queues to 20.) sendmail refuses 
dnl # to accept connections once it has reached its quota of child processes.
dnl #
dnl define(`confMAX_DAEMON_CHILDREN', `20')dnl
dnl #
dnl # Limits the number of new connections per second. This caps the overhead 
dnl # incurred due to forking new sendmail processes. May be useful against 
dnl # DoS attacks or barrages of spam. (As mentioned below, a per-IP address 
dnl # limit would be useful but is not available as an option at this writing.)
dnl #
dnl define(`confCONNECTION_RATE_THROTTLE', `3')dnl

(Treat "dnl" as a comment leadin string.)

Если вы просто рассылаете электронные письма, вам, вероятно, следует ограничить их скорость.

решение2

Записывайте сообщения об ошибках и ТОЧНОЕ время возникновения проблем. Это должно помочь администраторам sendmail точно определить проблемы в файлах журналов.

При массовой рассылке вам следует:
а) повторно использовать SMTP-соединение для отправки большого количества писем (например, 50)
б) ограничить количество сообщений, отправляемых в секунду (например, 20-50)

Другие меры, которые я мог бы предложить, касались только sendmail и требовали сотрудничества с администраторами sendmail.

Связанный контент