
В корпоративной среде у нас есть почтовый сервер, на котором доступны только порты 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.