기업 환경에는 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 관리자가 로그 파일의 문제를 정확히 찾아내는 데 도움이 될 것입니다.
대량 메일 발송 시 다음을 수행해야 합니다.
a) 많은 이메일을 보내기 위해 SMTP 연결을 재사용합니다(예: 50)
b) 초당 제출되는 메시지 수를 제한합니다(예: 20-50).
제가 제안할 수 있는 다른 조치는 sendmail에만 해당되며 sendmail 관리자의 협력이 필요합니다.