◈ 리턴 메시지 예시
아래의 사유로 메일 전송에 실패했습니다.
수신측 서버와의 통신 중 지정된 시간 내에 응답을 받지 못했습니다. 나중에 다시 시도해 보세요.
→ 904 check response : (수신 IP) no read data/connection closed
「번역」 904 확인 응답 : (수신 IP) 읽은 데이터가 없습니다/연결이 닫혔습니다.
위와 같은 상당히 난해한 리턴 메시지이며, 실제로도 자주 접하는 유형은 아닙니다. 일반적으로 수신 측에서 메일 수신을 거부하는 경우에는 리턴 메시지에 수신 서버의 IP 주소보다는 발송 서버의 IP 주소와 함께 차단 사유가 안내됩니다.
예를 들어 수신자 계정이 존재하지 않는 경우에는 "550 User Unknown, No such User"와 같은 메시지가 반환되며, 서버에 일시적인 문제가 발생한 경우에는 "451 Temporary error" 형태의 오류를 확인할 수 있습니다. 그런데 이번 사례처럼 SMTP 단계에서 9XX 번대 리턴 코드가 나타나는 경우는 매우 드뭅니다. 정확히는 사용되지 않는 코드라기보다는 SMTP 통신 특성상 이러한 응답이 발생할 상황 자체가 많지 않기 때문입니다.
그렇다면 왜 이러한 리턴 메시지가 발생했는지 순차적으로 분석해 보겠습니다.
① 904 리턴 코드 의미
전 세계적으로 가장 많이 사용되는 메일 서비스 중 하나인 구글 Gmail(Workspace)의 SMTP 오류 코드 안내 문서(링크 참고)를 확인해 보아도, 일반적인 SMTP 4xx/5xx 오류 코드에 대한 설명만 제공하고 있습니다. 반면 900번대 오류 코드는 SMTP 표준 규격에 포함된 코드가 아니기 때문에 관련 설명을 찾아볼 수 없습니다.
따라서 SMTP 로그에서 900번대 오류 코드(예: 901~904)를 확인했다면, 이는 SMTP 프로토콜 자체의 응답 코드가 아니라 메일 솔루션, 보안 장비 또는 네트워크 장비에서 자체적으로 정의한 내부 오류 코드일 가능성이 높습니다. 특히 SMTP 연결은 정상적으로 수립하였으나 세션 진행 중 연결이 비정상적으로 종료되는 경우, 일부 시스템에서는 904와 같은 내부 오류 코드를 반환하기도 합니다.
예를 들어 다음과 같은 환경에서 발생할 수 있습니다.
→ 네트워크 불안정, 패킷 손실(Packet Loss), 대역폭 부족 또는 네트워크 혼잡, 방화벽(Firewall) 정책에 의한 연결 차단, IPS/IDS(침입방지시스템)의 세션 차단, 클라우드 보안 정책(Security Group, Network ACL 등), 로드밸런스 또는 SMTP 프록시 장비의 세션 종료등
이제 위 내용을 참고하여 "904 check response : no read data / connection closed" 리턴 코드를 해석하면 발신 서버가 상대 서버의 응답을 기다리는 과정에서 응답 데이터를 수신하지 못한 채 연결이 종료되었음을 의미하는 것을 알 수 있게 됩니다. 다만 900번대 오류가 반드시 네트워크 장애만을 의미하는 것은 아닐 수 있기 때문에 다양한 관점에서 접근을 해야겠지만, 특정 수신 측으로 보낼 때만 위와 같이 발생한다면 네트워크 및 보안 장비 관점(수신 스팸 솔루션, IPS, 웹방화벽)에서 접근하여 원인을 분석하는 것이 효과적입니다.
② SMTP단계에서 보는 명령어(Command) 순서 예시
수신 서버 응답 시 코드
[2XX] 정상 응답, [3XX] 정상 응답(중립), [4XX] 일시적 거부, [5XX] 영구적인 거부(or 차단)
| 명령어(Command) ■ 직접 입력할 부분 | 설명 |
| CMD#> telnet 수신서버MX 호스트(or IP) 25 | 수신서버호스트(or IP) SMTP 25번 포트 접근 |
| 220 서버 호스트 이름 ESMTP MAIL Service → 적어도 수신측에서 SMTP 연결(220) 응답을 받았다면, RBL(실시간 블랙리스트)나 IP 제한에 의한 차단은 아니라는 뜻 |
코드[220] 정상 응답, 일반적으로 서버(호스트 이름)이나 메일 소프트웨어 사용 프로그램 이름 정보가 나옵니다. |
| helo foxytestmail.co.kr (송신 도메인주소) 250 서버 호스트 이름 Hello [IP] |
접속한 SMTP 서버에 자신의 도메인 호스트 주소를 알립니다. 코드[250] 정상 응답 |
| mail from:<foxydog@foxytestmail.co.kr> 250 2.1.0 OK |
송신자의 메일 주소를 알립니다. 코드[250] 정상 응답 |
| rcpt to:<A@gmail.com> 250 2.1.5 OK |
수신자의 메일 주소를 알립니다. 코드[250] 정상 응답 |
| data 354 Go ahead (or Start mail input 등) → 해당 단계에서 응답 데이터를 받아야하나, 수신측 네트워크 장애 및 보안 장비에서 연결이 끊어짐 |
본문 내용(body)을 적기 위한 시작 명령어 → 실패, 리턴 코드 반환 또는 자체 솔루션 판단 "904 check response : no read data / connection closed" 발송자는 위와 같은 리턴 메시지를 받음 |
| ↓ 정상 통과 시 아래와 같은 패턴으로 진행 from:foxydog@foxytestmail.co.kr (송신자 메일 주소) to:A@gmail.com (수신자 메일 주소) subject:testmail (메일 제목) testmail (본문 내용 입력) |
헤더 영역, 웹메일(메일쓰기)생각하시면 됩니다. 송신자/수신자/메일 제목/본문 내용 입력 SMTP 통신 내부에서는 사이에 공백이 있으면 안됩니다. |
| ※ 정상 패턴 . 250 2.0.0 OK |
끝마침(을 해야 최종 발송 시도를 합니다.) 코드[250] 정상 응답 및 발송 완료 |
| quit 221 2.0.0 Bye Connection closed by foreign host. |
SMTP 연결 종료 |
일반 사용자 눈에 보이지는 않지만 SMTP는 위와 같은 흐름을 따라 동작합니다. 이렇게 보면 HELO / MAIL FROM / RCPT TO / DATA 중 어떤 단계에서 실패했는지를 좀 더 명확하게 구분할 수 있습니다.
Telnet을 통해 SMTP 연결이 성공하였다면 RBL(실시간 블랙리스트) 등록이나 IP제한에 의한 즉시 차단은 아닌 것으로 볼 수 있으며, DATA를 주고받는 과정에서 중간 네트워크 장비 장애 또는 보안 장비의 간섭으로 인해 연결이 끊어진 상황으로 추측할 수 있습니다.
◇ 실 서버 테스트 예시
이러한 현상이 어느 순간 동시다발적으로 발생하였습니다. 수신측 도메인은 서로 달랐지만, 메일 서비스를 이용하는 호스트 메일 주소가 비슷하거나 동일한 국가인 경우가 많았습니다. 주로 영국, 유럽, 미국 등 해외 지역에서 발생하였으며, 발생 시각도 비슷했습니다. 오후 5시경부터 약 2시간 정도 계속 연결 실패가 발생하다가 오후 7시 이후에는 다시 정상적으로 연결이 처리되었습니다.
이 정도 상황이라면 중간 네트워크나 보안 장비에 의한 간섭을 받았을 가능성이 더욱 높아집니다. 이렇듯 메일 관리자는 SMTP의 흐름만 파악해도 약 80% 정도는 발송측에서도 간단하게 원인을 추정할 수 있습니다. 물론 반드시 네트워크 문제라고 단정할 수는 없습니다. DNS(네임서버) 문제일 수도 있고, 국가 단위의 네트워크 장애나 GEO IP 정책에 의한 영향일 수도 있기 때문입니다.
따라서 이러한 장애는 발송측뿐만 아니라 수신측 메일 서버 관리자 역시 함께 로그를 확인하며 원인을 분석할 필요가 있습니다.
마무리하며...
사용자들이 가장 많이 착각하는 부분 중 하나가 특정 수신처로만 메일 발송이 되지 않는 상황을 보고, 본인이 이용 중인 메일 서비스 자체에 장애가 발생한 것처럼 지적하는 경우가 의외로 많다는 점입니다.
하지만 실제 메일 송수신 과정은 생각보다 훨씬 복잡합니다. 세상에는 다양한 메일 솔루션이 존재하며, 국가별 네트워크 환경, 보안 장비, 그리고 서버를 찾아가도록 안내하는 DNS(네임서버) 등 수많은 요소가 정상적으로 동작해야만 메일 수발신이 이루어질 수 있습니다. 즉, 이 과정에서 단 한 곳이라도 문제가 발생하면 메일 전송에 영향을 줄 수 있습니다.
물론 이러한 부분을 점검하고 관리하는 메일 서버 관리자가 존재하지만, 전 세계에 걸쳐 있는 방대한 네트워크 흐름을 일일이 실시간으로 확인하는 것은 사실상 불가능합니다. 그렇기 때문에 시스템은 SMTP 표준에서 정의한 4xx, 5xx 계열의 리턴 코드와 오류 메시지를 사용자에게 전달하며, 일반 사용자도 어느 정도 원인을 파악할 수 있도록 정보를 제공합니다.
좀 더 유연하게 대처하고 싶다면 단순히 "메일이 안 간다"라고 판단하기보다는, 리턴 코드와 리턴 메시지에 포함된 사유를 먼저 확인해 보는 것이 좋습니다. 해당 정보를 분석하다 보면 메일이 어떤 단계에서 실패했는지 파악하는 데 도움이 되며, 결과적으로 메일 흐름을 이해하는 데도 큰 도움이 될 수 있습니다.