Exchange Queue & A보안 전자 메일 프로토콜, 알 수 없는 스팸 등
Nino Bilic and Scott Landry
이 칼럼은 부분적으로 Windows Server 2008 시험판 버전을 기준으로 작성되었으며 여기서 설명하는 내용은 변경될 수 있습니다.
Q: 보안 SMTP를 사용하고 싶은데 Exchange Server가 포트 465에서 SMTP를 수신하도록 하려면 어떻게 합니까?
A: 유감이지만 그건 불가능합니다. 포트 465에서 수신하는 SMTP 가상 서버나 수신 커넥터를 만들 수 있지만 그렇게 한다고 해도 보안 SMTP(SMTPS)라는 목적은 달성되지 않습니다.
이유를 간단히 살펴보겠습니다. SSL에는 명시적 SSL과 암시적 SSL이라는 두 가지 종류가 있습니다. 초기에는 대부분의 SSL이 암시적이었으므로, SSL 전용 포트가 사용되었습니다. 예를 들어 HTTP는 기본적으로 포트 80을 사용하지만 HTTPS(SSL 기능이 있는 HTTP)는 포트 443을 사용합니다. 하지만, 몇 년 전에 인터넷 커뮤니티는 SSL 전용 포트가 필요 없다고 결정했습니다. 따라서 명시적 SSL이 탄생했습니다.
Netscape에서는 이미 465를 SMTPS 포트로 선택했지만 Exchange Server의 SMTP에는 SSL 기능이 없었습니다. 하지만 Exchange 팀은 명시적 SSL의 장점, 즉 클라이언트와 서버가 동등하게 사용할 수 있다는 것에 주목하고 SMTP에 대해 명시적 SSL을 지원하기로 결정했습니다.
SMTP의 경우 명시적 SSL은 기존 소켓에 보안을 적용하기 직전에 STARTTLS ESMTP 명령을 사용하여 이를 알립니다. 대부분의 다른 SMTP 서버 및 클라이언트 공급업체에서 STARTTLS 명령도 구현했으므로 어차피 공식 인터넷 표준이 아닌 포트 465를 지원할 필요가 거의 없었습니다.
현재까지 SMTP에 대해 암시적 SSL을 지원하는 Exchange Server 버전은 없습니다. Exchange 수신 커넥터나 SMTP 가상 서버에 포트 465에서 수신하라고 지시한다고 해도 이 사실은 바뀌지 않습니다. 따라서 포트 25에서 STARTTLS를 지원하는 클라이언트를 사용해야 합니다. 포트 25를 사용할 수 없는 경우에는 클라이언트 SMTP 제출용 표준 포트인 587을 선택하는 것이 좋습니다. 포트 25에서 STARTTLS를 지원하지 않는 최신 클라이언트가 별로 없으므로 암시적 SSL에 대한 지원을 추가할 필요가 없었습니다.
그런데 Exchange POP3 프로토콜과 IMAP4 프로토콜은 항상 암시적 SSL을 지원했습니다. 그러나 Exchange Server 2007에서는 이 두 프로토콜에 대해서도 명시적 SSL에 대한 지원이 추가되어 있습니다. 하지만 이 최신 표준을 지원하는 클라이언트가 아직 많지 않으므로 앞으로 얼마인지 알 수 없지만 당분간은 암시적 SSL이 계속해서 사용될 것입니다.
Q: 엄청난 수의 메일이 여러 도메인의 큐에서 대기 중인데 우리 사용자가 보낸 메일이 아닙니다. 어찌된 일이고 이를 방지하려면 어떻게 해야 합니까?
A: 여러분만 그런 게 아닙니다. 인터넷 서버가 있는 사람이라면 누구든지 이 문제를 겪을 수 있습니다. 기본적으로 두 가지의 가능한 원인이 있습니다. 첫 번째는, 어떤 이유로 사용자의 서버가 릴레이용으로 열린 것입니다(support.microsoft.com/kb/304897 참조). 물론 의도한 것은 아닐 것입니다. Exchange Server 2000 이후부터 오픈 릴레이는 기본적으로 사용되지 않기 때문에 배달 못 함 보고서(NDR) 스팸이라는 현상이 나타날 가능성이 높아졌습니다. 스패머가 UCE(원치 않는 상업용 전자 메일)를 보내는 과정에서 사용자의 도메인에 존재하지 않는 주소로 보내는 경우가 많습니다. 서버에서는 스패머에게 해당 사용자가 존재하지 않음을 알리려고 하지만 스패머는 반송 주소도 스푸핑합니다. 스패머가 잘못된 주소를 스푸핑하고 있거나(이 경우 시간이 초과될 때까지 얼마 동안 NDR이 나타남), 서버로 하여금 스패머 자신을 대신하여 서버에서 생성한 NDR의 첨부 파일로 다른 도메인에 스팸을 보내도록 하려고 시도하고 있을 수 있습니다.
NDR을 사용하지 않도록 설정할 수 있지만 이 경우 합법적인 사용자가 실수로 주소를 잘못 입력한 경우에도 서버가 해당 사용자에게 전자 메일을 보내지 않았다는 것을 알리지 않으므로 중요한 메시지가 손실될 수 있습니다. 더 나은 솔루션이 있습니다.
먼저 서버를 릴레이용으로 열지 말아야 합니다. 그런 다음 IMF(지능형 메시지 필터)나 Exchange Server 2007 콘텐츠 필터와 같은 몇 가지 종류의 스팸 방지 필터링 기능과 일부 RBL(실시간 차단 목록)을 설정하십시오. 이러한 기능을 Edge 전송 역할이나 Hub 전송 역할에 설정할 수 있지만, 메일 양의 90% 이상이 스팸인 경향이 있고 이런 정크 메일을 처리하는 것 때문에 서버 사용량이 늘어나는 것은 바람직하지 않으므로 맨 처음 홉에서 기능을 설정해야 합니다.
마지막으로 해당 환경에 메일을 받아들이는 첫 번째 Exchange Server에서 받는 사람 필터링을 사용하도록 설정하십시오. 이렇게 하면 메시지가 네트워크에 들어오기 전에 서버에서 거부할 수 있습니다. 실수로 주소를 잘못 입력해도 여전히 NDR이 수신되지만 이 NDR은 보낸 사람의 서버에서 생성된 것입니다.
Q: 각각 인터넷으로 메일을 성공적으로 보내고 있는 Exchange Server 2000 서버와 Exchange Server 2003 서버가 한 대씩 있는데 Exchange Server 2007을 설치하자 이제 각 서버의 사서함에서 메일을 보낼 수 없습니다.
A: 이전에 Exchange Server가 한 대밖에 없었다면 커넥터라는 개념을 잘 모를 것입니다. Exchange 커넥터는 전자 메일을 보낼 위치를 Exchange에 알려 주는 논리 라우팅 구성 개체입니다. 기존 조직에 Exchange Server 2007을 도입할 때 메일을 라우팅하려면 반드시 라우팅 그룹 커넥터와 SMTP 커넥터가 있어야 합니다.
두 개의 라우팅 그룹 커넥터, 즉 Exchange Server 2007 라우팅 그룹에서 Exchange Server 2003 라우팅 그룹으로 향하는 라우팅 그룹 커넥터와 Exchange Server 2003 라우팅 그룹에서 Exchange Server 2007 라우팅 그룹으로 향하는 라우팅 그룹 커넥터가 필요합니다. 이것은 설치 과정의 일부로 설정할 수 있지만 시기를 놓쳤거나 확실하지 않은 경우 Exchange 관리 셸을 통해 검사하여 문제를 해결할 수 있습니다. 그렇지 않으면 서버 간에 메일을 보낼 수 없게 되고 메시지가 결과적으로 대상에 연결할 수 없는 메시지 큐에서 대기하게 됩니다.
인터넷 메일을 라우팅하려면 Exchange Server 2007에서 송신 커넥터라고도 하는 SMTP 커넥터가 하나만 있으면 됩니다. Exchange Server 2000과 Exchange Server 2003에 하나가 있지만 모르고 지나쳤을 수 있습니다. 주소 공간은 모든 도메인에 대해 SMTP:*여야 하며 메일 배달에 스마트 호스트나 DNS를 사용하도록 지정할 수 있습니다. 보내는 인터넷 메일을 Exchange Server 2007 서버에서 처리하도록 할지 이전 버전의 서버에서 처리하도록 할지 선택합니다. 보내는 인터넷 메일을 각 서버에서 자체적으로 처리하도록 할 경우에는 두 라우팅 그룹 모두에 하나씩 만들 수 있습니다. Edge 전송 서버 역할을 설치한 경우 이들 중 하나를 Edgesync 프로세스의 일부로 만들 수도 있습니다.
스마트 호스트를 SMTP 가상 서버에 설치했다면 지금 제거하는 것이 좋습니다. 스마트 호스트가 가상 서버에 있어서는 안 되며 SMTP 커넥터에만 있어야 합니다. 그렇지 않으면 라우팅 그룹 커넥터가 손상됩니다.
인바운드 전자 메일이 MX 레코드나 방화벽이 전달하고 있는 IP로 제어된다는 것도 알아야 합니다. Exchange 쪽에서는 구성할 것이 별로 없지만 그래도 문제가 발생할 경우 msexchangeteam.com/archive/2006/11/17/431555.aspx 문서를 참조하면 도움이 됩니다.
Q: Exchange Server 2007에서 같은 메시지에 대해 여러 저널 보고서가 수신되는 이유는 무엇입니까?
A: Exchange Server 2007 전송 저널링 에이전트는 분류 후 메시지를 저널링합니다. 분류기는 메시지를 두 부분으로 나누어, 메시지 본문을 복사하고 복사본마다 다른 봉투 받는 사람을 넣는데 여기에는 많은 이유가 있습니다. 예를 들어, 이제 저널링에는 메시지 송신 당시의 메일 그룹 멤버 자격을 알려 주는 기능이 있으므로 메일 그룹이 중첩된 경우 여러 보고서가 수신될 수 있습니다.
이 풍부한 추가 보고 기능은 같은 메시지에 대해 제각기 고유한 보고서가 있는 복사본이 여러 개 수신될 수 있음을 의미합니다. 한 메시지에 대해 모든 보고서가 도달했는지 알 수 있는 보장된 방법은 없지만 보관을 할 경우 해당 아카이브 공급업체와 협력하여 변경 내용을 인식하고 있는지 확인해야 합니다.
Q: Exchange Server 2007에서는 확인되지 않은 메시지를 호스트에 전달하는 기능이 어디로 갔습니까? 이제 어떻게 하죠?
A: 개가 먹어버렸습니다.
실제로 Exchange Server가 둘 이상이면 이 특정 기능이 그다지 잘 작동하지 않습니다. Exchange에 이미 같은 일을 완료하는 다른 방법이 있으며 이 방법이 훨씬 더 강력합니다. 특히 개별 SMTP 도메인을 다른 시스템과 공유하는 기능이 있습니다. 따라서 "확인되지 않은 메시지를 전달하는" 기능이 삭제되었고 공유 도메인 개념이 향상되어 단순화되었습니다. Exchange Server 2007에서 조직 | Hub 전송 | 허용 도메인으로 이동하고 도메인 종류를 신뢰할 수 있음에서 인터넷 릴레이로 변경하면 됩니다. 실제로 일부 환경의 경우 이보다 약간 더 복잡하며 설명서의 일부를 업데이트하는 작업이 진행되고 있습니다. 그러나 한동안은 이렇게 해도 도움이 됩니다.
Q: Exchange Server 2007 설치에 사용할 루트 도메인을 준비하려고 합니다. Exchange Server 2007 설치 프로그램을 실행하려고 하는 서버에 Exchange Server 2003 ESM(Exchange 시스템 관리자)이 설치되어 있는데 설치가 실패하고 있습니다. 무엇이 문제일까요?
A: Exchange Server 2000 또는 2003 구성 요소가 설치되어 있는 시스템에서 Exchange Server 2007 설치 프로그램의 일부를 실행하는 것은 지원되지 않습니다. Exchange Server 2003 ESM이 설치되어 있으면 Exchange Server 2007 설치 프로그램에서 해당 사실을 확인하기 때문에, 설치 프로그램 필수 구성 요소 검사가 실패하면서 "이 컴퓨터에는 이전 버전의 Exchange Server가 이미 설치되어 있습니다. 다른 컴퓨터에서 Exchange Server 2007 설치 프로그램을 실행하거나 이전 버전의 Exchange Server를 제거하십시오."라는 메시지가 표시됩니다.
아마도 이 문제를 가장 쉽게 해결하는 방법은 루트 도메인의 다른 서버에서 Exchange Server 2007 설치 프로그램을 실행하고 이에 맞게 도메인을 준비하는 것입니다. 이 방법을 실행할 수 없으면 Exchange Server 2003 구성 요소를 제거하고 Exchange Server 2007 설치 프로그램을 계속 실행할 수 있습니다.
32비트 버전의 Exchange Server 2007을 사용하여 도메인을 준비할 수 있으므로 일반적으로 루트 도메인에 있는 임의의 32비트 서버를 사용하면 충분합니다. 이 주제에 대한 자세한 내용은 technet.microsoft.com/library/bb232170.aspx를 참조하십시오.
이것은 Exchange Server 2003과 Exchange Server 2007 관리 도구가 같은 시스템에 공존하는 것이 지원되지 않기 때문에 Exchange Server 2003 ESM과 Exchange Server 2007 Exchange 관리 콘솔을 설치할 수 없음을 의미합니다. Exchange Server 2000 또는 Exchange Server 2003 구성 요소가 설치되어 있는 시스템에 Exchange Server 2007을 설치하려고 하면 설치 프로그램이 중단됩니다.
마지막으로, Exchange Server 2007 관리 도구를 먼저 설치한 다음 같은 시스템에 Exchange Server 2003 도구를 설치해서는 안 됩니다. 이렇게 하면 테스트되지 않은 구성이 만들어지고 서버를 관리하려고 할 때 예상치 않은 결과가 발생할 수 있습니다. 단일 시스템에서 두 서버 버전을 모두 관리해야 할 경우에는 원격 데스크톱을 사용하여 한 버전에 연결하거나 가상 시스템을 사용하여 격리된 환경에서 관리 도구의 다른 버전을 호스팅할 수 있습니다.
Q: 언제가 되어야 내 Windows Vista® 워크스테이션에서 Exchange Server 2007 관리 도구를 실행할 수 있을까요?
A: Exchange Server 2007 관리 도구에 대한 Windows Vista 공식 지원은 Exchange Server 2007 SP1 릴리스와 함께 제공될 예정입니다. Exchange Server 2007 SP1 관리 도구가 포함된 패키지는 Exchange Server 2007 SP1이 출시된 후에 다운로드할 수 있습니다.
Q: Windows Vista나 Windows Server 2008의 Exchange Server 2003 ESM은 어떻습니까? 역시 실행할 수 있을까요?
A: 아니오, 불행히도 그럴 수 없습니다. Exchange Server 2007 SP1 이전의 모든 Exchange Server 버전에 대한 관리 도구는 Windows Vista나 Windows Server 2008에서 지원되지 않습니다. 즉, Windows Server 2008이 출시된 후에도 Windows Vista나 Windows Server 2008에 Exchange Server 2003 ESM을 설치하는 것은 지원되지 않습니다. Exchange Server 2003 서버의 관리는 Windows Server 2003이나 Windows XP 워크스테이션에서 수행해야 합니다. 또는 임의의 OS에서 원격 데스크톱 연결을 사용할 수 있습니다.
Q: 내 도메인에서 여러 대의 Exchange Server 2003 서버가 실행되고 있는데 내 도메인 컨트롤러를 Windows Server 2008 도메인 컨트롤러로 업그레이드할 수 있을까요?
A: 예, Windows Server 2008 도메인 컨트롤러가 있는 도메인에서 Exchange Server 2003 SP2를 실행하는 것은 지원됩니다. Exchange Server는 Windows Server 2008 RODC(읽기 전용 도메인 컨트롤러)나 ROGC(읽기 전용 글로벌 카탈로그 서버)를 사용할 수 없습니다. Windows Server 2008 RODC/ROGC를 사용하도록 Exchange Server를 수동으로 지정(하드코딩)하면 예상치 않은 결과가 발생할 수 있습니다.
Nino Bilic은 Exchange Server 팀의 지원 기능 프로그램 관리자로, 잠자리에 들기 전까지 엄청난 양의 Netmon 추적을 읽으면서 서버 간 통신의 아름다움을 발견하는 것이 취미입니다.
Scott Landry는 Exchange Server 팀의 지원 향상 엔지니어로, 수건, 안내서와 믿음직한 Windows Mobile 전화 없이는 어디에도 가지 않습니다.
© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..