[지디넷코리아]현재 대부분 웹 서비스의 기본은 이메일에서 시작된다. 이메일 시스템이 장애를 일으키면 지인들과의 의사소통은 물론 기업 경영에도 치명적인 영향을 준다. 이번 호에는 윈도우 이메일 시스템에서 주로 발생하는 이메일 관련 장애의 증상과 대처법을 살펴본다.

필자는 호스팅 전문 회사에서만 근 5년 가까이 근무하면서 각양각색의 기술지원을 해왔다. 그런데 지금까지 기술지원을 해온 자료들을 분석해 본 결과 가장 많은 사람들이 장애를 호소한 부분은 바로 이메일이었다. 조금 과장하면 하루도 빠짐없이 꼬박꼬박 다양한 종류의 메일에 대한 문의가 빗발쳤으며 메일링 문제, 이메일 수신이 안됩니다, 메일을 받지 못합니다, 메일발송이 되지 않습니다 등 수많은 질문들이 실시간으로 접수됐다. 이번 호에는 윈도우 플랫폼 기반에서 발생할 수 있는 다양한 이메일 관련 장애 가운데 대표적인 사례 몇 가지를 살펴보자

웹에서 메일 발송이 안돼요!
일반적으로 인터넷을 사용하는 사람이라면 여러 종류의 웹 사이트를 방문하고 또 필요에 따라 회원가입을 하게 된다. 이 때 회원가입을 마치면 반드시 받게 되는 것이 바로 이메일이다. 이메일은 쇼핑몰에서 물건을 구매했을 때도 가장 먼저 피드백이 오고 입금확인, 배송확인, 공지 등 거의 모든 인터넷 기반 서비스의 기본이다. 그렇다면 자신이 관리하는 웹 사이트에서 이렇게 중요한 이메일이 발송되지 않는다면 무엇부터 점검을 해야 할까. 먼저 구체적인 증상을 살펴보기에 앞서 윈도우의 이메일 시스템 폴더 구성부터 살펴보자.

일반적으로 윈도우에서 IIS 웹 서버를 운영하면 자동메일 발송기능을 위해서 SMTP를 함께 설치한다. 이 경우 IIS MMC에서‘기본 SMTP 가상 서버’라는 항목이 나타나고 그 등록정보를 보면 mailroot 폴더 경로가 C:\inetpub\mailroot라는 것을 알 수 있다. SMTP를 통해 메일을 발송하면 이메일은 Pickup 폴더에 거쳐 받는 사람 메일서버로 발송된다. 그런데 여기서 받는 사람 메일 서버나, 보내는 서버 즉 IIS 서버에서 1차 시도시 메일 발송이 되지 않을 경우 <화면 1>의 Queue 폴더에 메일이 쌓이게 된다. Queue의 메일은 SMTP 가상 서버의 배달 탭에서 설정한 다시 시도 간격과 만료시간에 따라 처리된다.

<화면 1> mailroot 경로

한편 여러 가지 이유로 메일을 보낼 수 없을 경우 보내는 사람 이메일 주소로 배달하지 못하는 이유를 발송하게 되는데, 이 배달 못함 보고서(NDR)를 보내는 사람에게 발송하지 못할 경우 Badmail 폴더에 쌓이게 된다. Badmail에 메시지가 많이 쌓이면 SMTP의 성능이 저하될 수 있으므로 메일 서버 관리자는 주기적으로 Badmail 하위의 파일들을 삭제해 주는 것이 좋다. 또한 메일 형식이 잘못된 경우에는 Drop 폴더에 메일이 쌓이게 된다.

SMTP는 제 기능을 하고 있는가
우선 웹 페이지에서 메일이 발송이 되지 않는다면 SMTP 서버가 제대로 기능하고 있는지 파악해야 한다. 기본적으로 SMTP는 TCP 25번 포트를 사용한다.

따라서 Netstat -na 명령 또는 Telnet localhost 25 명령으로 25번 포트가 정상적으로 Listen되어 있는지 확인해야 한다. SMTP 연결에 문제가 있다면 SMTP 서비스가 정상구동 중인지도 확인하는 것이 좋다. 메일이 발송되는지 수동으로 체크하는 방법은 마이크로소프트 웹 사이트(support.microsoft.com/ default.aspx?scid=kb;ko;286421)를 참고하기 바란다.

이 밖에도 <화면 2>와 같은 메일 형식으로 텍스트 파일을 작성한후 해당 텍스트 파일을 Pickup 폴더에 붙여넣기 해보자. 메일 발송 테스트를 하는 동안 SMTP 로그와 이벤트 뷰어를 확인해보면 메일이 발송되지 못하는 이유가 로그에 남게 된다.

<화면 2> 메일 형식으로 SMTP 동작 확인

혹시 DNS의 문제?
윈도우 SMTP를 운영하면서 쉽게 지나치는 부분이 DNS이다. 서버로컬에 설정된 참조 DNS IP가 문제가 되는 것이다. 주로 메일 서버를 이전했을 때 DNS 캐시가 오래도록 남아있어서 메일을 제대로 발송할 수 없는 경우인데 이럴 때는 서버에서 nslookup 명령으로 MX 레코드가 정상적으로 응답하는 지를 체크해야 한다. 또한 DNS의 TTL 값이 큰 경우에는 그만큼 캐시를 많이 가지고 있으므로 가급적이면 TTL 값이 짧은 DNS 서버의 IP를 웹 서버에 설정하는 것이 좋다.

<화면 3> Nslookup을 통한 MX 레코드 검색결과

포탈의 메일 주소로 받을 수가 없어요!
메일 발송에 대한 문제 중 상당 부분을 차지하는 것이 각 포탈 사이트로 메일이 발송되지 않는다는 것이다. 이는 각 포탈 사이트들마다 각기 다른 스팸메일 정책을 가지고 있기 때문인데 그마저도 나날이 강화되고 있는 추세이다. 대부분의 포탈에서는 한 IP에서 대량 메일을 발송할 경우 해당 IP가 자동으로 차단된다. 야후의 경우 10통 이상만 발송해도 대량 메일로 간주한다. 또한 메일을 보내는 서버와 보내는 메일 주소의 메일 서버가 일치하지 않거나 Reverse DNS(DNS와 반대로 IP로 해당 DNS를 검색하는 것)가 등록되어 있지 않을 경우에도 메일을 발송할 수 없다.

이 밖에도 해당 IP가 스팸 데이터베이스에 등재된 경우에도 해당 IP로 메일을 발송하기 어려움이 있을 것이다. 자신의 서버 IP 상태에 대한 검색은 DNSSTUFF 웹 사이트(www.dnsstuff.com)에서 확인할 수 있다. 또한 발신전용 메일이라 할지라도 실제 존재하지 않는 메일을 보내는 메일 주소로 사용할 경우 메일을 수신할 수 없는 경우도 있다.

mailroot 폴더의 권한 설정은 확인했나요?
윈도우 2003에서는 거의 일어나지 않지만 윈도우 2000의 경우 Mailroot 폴더의 권한설정이 변경돼 메일이 발송되지 않는 경우도 종종 있다. 윈도우 2003의 보안 구성이 변경된 것도 한 이유지만 윈도우 2000에서는 기본적으로 시스템 드라이브(대부분의 C 드라이브)가 Everyone에 대해 모든 권한이었다. 이 취약한 권한을 수정하기 위해 C 드라이브의 폴더 권한을 최소화하면 메일을 발송하는데 문제가 발생하는 것이다. 이 때는 <화면 4>처럼 Anonymous가 접근할 수 있도록 권한을 부여해야 한다.

<화면 4> Mailroot 폴더의 권한 설정

SMTP 사용자라면 기본, Relay 설정
Relay는 메일 서버에서 가장 문제가 되는 부분 가운데 하나다. SMTP Relay가 열려 있다면 아무리 관리자가 서버에서 메일 또는 스팸 메일을 발송하지 않았더라도 Relay 서버로 악용되는 것은 당연한 일이다. 현재 메일 서버 즉 SMTP가 설치되어 있다면 반드시 처리해야 하는 부분이 Relay에 대한 권한 설정이다. Relay 설정 또한 MMC에서 할 수 있는데 여기서는 웹 서버 즉 로컬에서만 메일을 발송하기 때문에 자신의 IP만 Relay를 허용하고 다른 사용자에게 Relay를 허용해 줄 필요는 없다.

<화면 5> 릴레이 제한

<화면 5>에서‘위 목록과 상관없이 성공적으로 인증한 모든 컴퓨터에 릴레이 가능’옵션은 SMTP 전용 서버를 구축하거나 IP를 기준으로 릴레이를 제한할 수 없을 때 인증받은 사용자만 메일을 발송할 수 있도록 설정하는 것이다. 이 기능을 사용하려면 다음과 같이 하면 된다.

<화면 6> 모니터링 툴인 netmon(클릭시 확대)

메일이 발송되는 패킷을 모니터링하자!
한편 윈도우 기반의 시스템에서 이메일 관련된 문제가 발생했을 때 이를 모니터링할 수 있는 유용한 툴이 있다. netmon이라는 프로그램으로, ‘프로그램 추가/제거｜Windows 구성 요소 추가/제거｜관리및 모니터링 도구｜네트워크 모니터 도구’를 설치하면 사용할 수 있다. 이를 이용하면 메일 수/발신시 Connection 경로를 확인할 수 있으며 주기적으로 모니터링해 외부로부터 공격이 있는 것은 아닌지 확인할 수 있다.@

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.