Zimbra 발신 메일 지연 오류 해결: "포트 25 연결 시간 초과"

Zimbra에서 오류 메시지가 표시되면 connect to mx.example.net[203.0.113.25]:25: Connection timed out일반적으로 메시지가 Zimbra 메일 큐에 도달했지만 서버가 수신자 도메인의 메일 교환기와 TCP 연결을 완료하지 못한 것입니다. 먼저 큐, DNS 및 아웃바운드 네트워크 경로를 확인하십시오. 연결을 차단하는 홉을 파악하기 전까지는 Postfix 타임아웃을 변경하거나 큐를 반복적으로 비우지 마십시오.

타임아웃은 SMTP 거부와는 다릅니다. "550"과 같은 거부는 원격 서버에서 메시지에 응답했지만 수신을 거부했음을 의미하며, "연결 시간 초과"는 연결 시도가 적시에 응답을 받지 못했음을 의미합니다. 원인은 로컬 방화벽, 클라우드 또는 호스팅 제공업체의 아웃바운드 메일 정책, 라우팅, 연결할 수 없는 대상, 또는 드물게 DNS/주소 패밀리 문제일 수 있습니다.

Zimbra에서 "Connection timed out port 25" 오류는 무엇을 의미하나요?

Zimbra는 MTA(메일 전송 에이전트)를 사용하여 발신 메시지를 라우팅합니다. 수신자가 조직 외부인 경우, MTA는 해당 도메인의 메일 교환기를 조회하고 SMTP를 사용하여 연결합니다. Zimbra의 최신 Daffodil 관리자 가이드에서는 배달에 실패한 메시지가 지연 큐로 이동하며, 여기서 배달이 재시도된다고 설명합니다. 큐 항목과 메일 로그에는 수신자와 오류가 기록되므로, 이를 통해 문제 해결을 위한 최적의 단서를 얻을 수 있습니다.

일반적인 메일 흐름에서 공용 메일 서버는 TCP 포트 25를 통해 서로 이메일을 교환합니다. 인증된 메일 클라이언트는 일반적으로 포트 587을 사용하여 발신 릴레이 서버로 메시지를 전송합니다. Zimbra의 릴레이 경로를 포트 587로 변경하는 것은 해당 목적으로 구성된 승인된 릴레이 서비스가 있는 경우에만 가능하며, 포트 25를 통한 인터넷 메일 수신을 대체하는 일반적인 방법은 아닙니다.

1. 문제가 모든 수신자에게 영향을 미치는 것입니까, 아니면 특정 도메인에만 영향을 미치는 것입니까?

변경하기 전에 지연 대기열을 확인하십시오. Zimbra MTA 호스트에서 다음 zimbra계정으로 관리자 명령을 실행하십시오.

su - zimbra
postqueue -p

반복되는 시간 초과 메시지를 찾아 수신자 도메인, 대상 MX 호스트 이름 및 확인된 IP 주소를 기록해 두십시오. Zimbra 관리 콘솔에서 모니터 → 메일 큐를 열고 오류 유형 및 수신자 도메인별로 지연 큐를 검사하십시오. 정확한 메뉴 이름은 Zimbra 릴리스 및 에디션에 따라 다를 수 있습니다.

오류가 특정 수신자 도메인이나 MX 주소에 집중되는 경우, 대상에 일시적으로 연결할 수 없거나 서버에서 나가는 연결을 차단하고 있을 수 있습니다. 여러 도메인에서 동일한 포트 25 타임아웃 오류가 발생하는 경우, 먼저 Zimbra 호스트의 송신 경로, 공급자 정책 또는 방화벽을 의심해 보십시오. 타임스탬프와 몇 가지 대표적인 대상 도메인의 정보를 기록해 두십시오. 도움을 요청할 때는 메시지 본문이나 자격 증명을 게시하지 마십시오.

2. DNS가 수신자 도메인을 접속 가능한 메일 서버로 확인합니까?

Zimbra 서버에서 수신자 도메인의 MX 레코드를 조회합니다. example.net오류가 발생하는 도메인으로 바꿔주세요.

dig MX example.net +short

반환된 MX 호스트 이름을 사용하여 해당 주소를 조회합니다.

dig A mx.example.net +short
dig AAAA mx.example.net +short

도메인에는 여러 개의 MX 호스트가 있을 수 있습니다. 수신자의 웹 서버가 메일을 수신한다고 가정하지 말고 DNS에서 표시되는 실제 호스트 이름을 테스트하십시오. DNS에서 사용 가능한 MX 대상이 반환되지 않으면 해당 수신자 도메인의 권한 있는 DNS 구성을 검사하십시오. Zimbra 서버에 임의로 만든 MX 레코드를 추가하지 마십시오.

다음으로 TCP 연결을 테스트합니다. nc설치되어 있다면 다음 명령어를 사용하세요.

nc -vz -w 10 mx.example.net 25

또는 telnet mx.example.net 25가능하다면 해당 방법을 사용하십시오. TCP 연결이 성공하면 연결 성공 메시지가 표시되고, SMTP 서버는 인사말을 표시할 수 있습니다. 타임아웃은 TCP 핸드셰이크가 완료되지 않았음을 나타냅니다. "연결 거부"는 이와는 다른 결과입니다. 원격 호스트가 응답은 했지만 해당 주소와 포트에서의 연결을 수락하지 않았습니다.

각 MX 대상에 대해 테스트를 반복하고, 가능한 경우 IPv4 및 IPv6 경로 모두를 테스트하십시오. 호스트 이름이 IPv6 주소로 확인되지만 서버에 작동하는 IPv6 경로가 없는 경우 IPv4는 성공하지만 IPv6 시도는 실패할 수 있습니다. Postfix 주소 패밀리 설정을 변경하기 전에 경로와 로그를 확인하십시오. 이러한 변경 사항은 버전 및 배포 환경에 따라 달라져야 합니다.

3. 방화벽이나 호스팅 제공업체가 아웃바운드 SMTP를 차단하고 있습니까?

먼저 방화벽 정책을 변경하지 않고 서버 방화벽 정책을 확인하십시오. UFW를 사용하는 시스템의 경우:

sudo ufw status verbose

UFW는 인바운드 트래픽뿐만 아니라 아웃바운드 트래픽도 관리할 수 있습니다. 아웃바운드 정책이 제한적인 경우, 번호가 매겨진 규칙을 검토하여 원격 포트 25에 대한 TCP 연결이 거부되는지 확인하십시오. 보안 정책과 일치하고 서버가 메일을 직접 보낼 수 있도록 승인된 경우에만 범위가 좁은 아웃바운드 허용 규칙을 추가하십시오.

호스트 방화벽은 연결을 허용할 수 있지만 상위 방화벽, 클라우드 보안 제어, 네트워크 ACL 또는 호스팅 제공업체 정책으로 인해 차단될 수 있습니다. 해당 인스턴스에 대해 아웃바운드 TCP/25 연결이 허용되는지, 계정 수준의 제한이 적용되는지, 그리고 해제 또는 검토 프로세스가 있는지 제공업체에 문의하십시오. 정책은 제공업체, 계정, 지역 및 제품에 따라 다르므로 로컬 방화벽 검사가 성공했다고 해서 인터넷 경로가 열려 있다는 것을 보장하는 것은 아닙니다.

네트워크 방화벽을 관리하는 경우, Zimbra 서버의 출발지 IP, 도착지 MX IP, 프로토콜 TCP, 도착지 포트 25에 대한 송신 규칙과 로그를 확인하십시오. 숙련된 관리자는 패킷 캡처를 통해 응답 없는 SYN 패킷과 반환 경로에서 차단된 응답을 구분할 수 있지만, 관련 헤더만 캡처하고 운영 데이터는 보호해야 합니다. 송신 타임아웃 문제를 해결하기 위해 수신 포트 25를 열지 마십시오. 이 두 가지 트래픽 방향은 별개입니다.

4. 25번 항구로의 직송이 불가능한 경우 어떻게 해야 합니까?

서비스 제공업체에서 직접 SMTP 발신을 허용하지 않는 경우, 승인된 스마트호스트 또는 아웃바운드 릴레이를 사용하십시오. 릴레이 운영자로부터 릴레이 호스트 이름, 포트, TLS 요구 사항, 인증 방법, 허용된 발신자 도메인 및 IP 허용 목록 요구 사항을 확인하십시오. 사용 중인 Zimbra 버전에 맞는 지원되는 Zimbra 관리 방법을 통해 릴레이를 구성하거나, 조직의 Zimbra 변경 프로세스를 따르십시오. Zimbra 관리자 가이드에 따르면 DNS 기반 전송이 활성화되지 않은 경우 릴레이 호스트를 구성해야 합니다.

많은 서비스 제공업체가 STARTTLS를 사용하여 587번 포트에서 인증된 제출을 제공하지만, 릴레이 제공업체의 문서가 가장 중요합니다. 릴레이 제공업체에 따라 465번 포트, IP 주소 허용 목록 또는 제공업체별 커넥터가 필요할 수 있습니다. 587번 포트가 열려 있거나 모든 공용 SMTP 서버를 릴레이로 사용할 수 있다고 가정하지 마십시오. 자격 증명은 지원되는 보호 구성에 보관하고, 읽을 수 있는 사용자를 제한하며, 릴레이 암호를 지원 티켓이나 셸 기록에 절대 저장하지 마십시오.

릴레이를 구성한 후 관리하는 사서함으로 테스트 메시지를 전송합니다. Zimbra 메일 로그에서 연결이 릴레이 호스트와 예상 포트로 이루어지고, 필요한 경우 TLS/인증이 성공하며, 릴레이가 메시지를 수락하는지 확인합니다. SMTP 오류가 반환되는 경우, 해당 응답이 포트 25 타임아웃이 아닌 인증, 발신자 정책, TLS 또는 릴레이 권한 문제인지 확인하고 문제를 해결합니다.

지연된 큐를 언제 다시 시도해야 합니까?

근본 원인이 수정되고 목적지 또는 릴레이에 대한 직접 테스트가 성공하면 큐 재시도를 요청하십시오. Zimbra 계정에서 postqueue -fPostfix에 큐에 있는 메시지에 대한 전송을 시도하도록 요청합니다.

su - zimbra
postqueue -f

이 작업은 여러 메시지에 대한 배달 시도를 유발할 수 있으므로 장애 발생 시 반복적으로 실행하지 마십시오. 관리 콘솔에서 큐 제어 기능을 사용할 수도 있습니다. Zimbra 문서에 따르면 큐를 비우면 지연 큐, 수신 큐 및 활성 큐에 있는 메시지에 대한 배달 시도가 발생합니다. 이후 몇 개의 메시지를 확인하여 지연 큐의 메시지 수가 감소하고 로그에 성공적인 배달 또는 새로운 SMTP 응답이 표시되는지 확인하십시오.

빠른 결정 가이드

어떻게 수정 사항을 확인할 수 있나요?

간략한 검증 절차를 사용하십시오. 먼저 DNS가 의도한 MX 레코드 또는 릴레이를 반환하는지 확인하고, 구성된 호스트 및 포트로의 TCP 연결이 성공하는지 확인합니다. 그런 다음 제어된 테스트 메시지를 전송하고, 원격 서버 또는 릴레이에서 해당 메시지를 수락했는지 확인합니다. 마지막으로 지연 큐와 로그에서 원래 메시지를 검사합니다. 연결 테스트가 성공했다고 해서 수신자가 메시지를 수락했다는 것을 보장할 수 없으며, 릴레이 핸드오프가 성공했다고 해서 수신함에 제대로 도착했다는 것을 보장할 수도 없습니다.

Postfix의 연결 시간 제한을 늘려서 시간 초과 문제를 해결하지 마십시오. Postfix smtp_connect_timeout설정은 SMTP 클라이언트가 TCP 연결을 완료하기 위해 기다리는 시간을 제어합니다. 이 시간을 연장한다고 해서 차단된 경로가 작동하는 것은 아니며, 오히려 배달 시도가 더 오래 기다려야 할 수 있습니다. 또한, 증상을 숨기기 위해 대기 중인 메시지를 삭제하거나 대기열 수명을 변경하지 마십시오. 메시지가 구성된 반송 수명에 가까워지면 영향을 받는 사용자에게 배달이 지연되고 있음을 알리고 경로를 복원하는 동안 대기열 증거를 보존하십시오.

공식 참고 자료

• Zimbra Daffodil(v10) 관리자 가이드: 메일 흐름 및 큐
• Zimbra Daffodil(v10) 단일 서버 설치 가이드: 포트 매핑
• Postfix postconf(5): smtp_connect_timeout
• Ubuntu 서버 설명서: 방화벽 및 UFW 상태