Exchange anti-spam 관련 정보
Exchange anti-spam에 대하여 궁금해하시는 부분이 정리가 되어 본사 Exchange 서버 Blog에 기재가 되었습니다.
https://msexchangeteam.com/archive/2009/11/13/453205.aspx
해당 내용에 대해 담당자의 의견을 반영하여 아래와 같이 정보를 제공해 드립니다.
Exchange anti-spam 관련하여 작업을 진행하시는데 많은 도움이 되었으면 합니다.
***********************************************************************************************************************
궁금한 내용 1: Hub의 Transport rule에다 SCL을 올리면 SCLDeleteThreshold 와 SCLRejectThreshold 에 영향을 줄꺼다
Hub에는 default로 안티 스팸 에이전트가 설치되지 않습니다. 해서, 보통 powershell script로 안티 스팸 에이전트를 올리곤 합니다. 하지만 Hub에 설치된 안티 스팸은 SCL 등급을 매기고 콘텐트를 제거/반송/격리 시킬수 있도록 하는 것은 아닙니다.
왜? 이것은 Hub가 안티 스팸 에이전트 실행되는 시점 자체가 *Content Filtering Agent( 이하 CFA)라고 하는 실질적인 메일의 삭제/반송 액션을 취하는 에이전트 * 이후에 일어나기 때문입니다. Hub에 안티 스팸 에이전트를 올리면 Transport Rule에 설치됩니다. 한번 확인해 보면, 아래처럼 Get-TransportPipeline 를 실행하게 되면 CFA는 OnEndOfData 이벤트에서 일어나는 것을 보실 수 있습니다. 반면에 Transport rule은 OnRoutedMessage 이벤트에서 일어납니다.
여기서 생겨나는 궁금한 내용이 또 있을 수 있겠습니다.
궁금한 내용 1-가: 그럼 Edge rule에다가 SCL 값을 지정하도록 에이전트를 설치하면 콘텐트 필터가 일어나기 전에 이루어져서 SCL 등급이 제대로 매겨지겠네?
Hub와는 다르게 Edge는 별도로 스팸 에이전트를 설치하지 않아도 이미 올라가 있기 때문에 바로 이용하실 수 있습니다. 그렇다면 실행되는 위치는? 동일하게 Get-TransportPipeline 을 실행시켜 보면 아래와 같이 콘텐트 필터링이 일어나기 * 전에 * 일어나는 것을 볼 수 있습니다.
이러한 이유로, Edge에서는 default 값을 그대로 두면, CFA가 메시지를 받기 전에 Edge rule에서 스팸 에이전트가 동작하여 스팸 여부 판단 후 CFA로 메시지를 넘겨주기 때문에 CFA가 거기에 기반하여 메시지를 처리할 수 있습니다.
자, 그렇다면 여기까지의 결론은
콘텐트 필터링은 Edge 역할과 Hub 역할의 Transport Rules에 사용하는 것입니다. (몰론 Edge가 있을 경우에 말입니다)
궁금한 내용 2: 아이템을 정크 폴더로 옮기기 위해서는 CFA가 필요하다
아.. 굉장히 많은 오해가 있는 것 중에 하나입니다. SCLDeleteThreshold와 SCLRjectThreshold, SCLJunkThreshold 는 store 설정입니다. SCLJunkThreshold 는 몇 SCL 등급 이상이면 정크메일 폴더로 보내어 스팸처리 하겠다고 설정하는 값입니다. 이는 숨겨진 설정/값들도 함께 작동이 되는데 AD의 mailbox object 혹은 OrganizationConfig 에 있는 SCLJunkThreshold 값들에 의해 정크메일 폴더로 옮길지에 대해 결정합니다.
여기서 CFA가 하는 역할은 SCL 등급(rating)을 stamping처리하는 것과 그에 따라 액션을 취하는 것입니다.
SCLJunkThreshold 는 두 군데에서 지정할 수 있습니다. (mailbox object via set-mailbox)메일박스 객체에서 하거나 (Set-OrganizationConfig) OrganizationConfig 객체에서 할 수 있습니다.
궁금한 내용 2-가: Edge 서버 역할에서 SCLJunkThreshold on the OrganizationConfig object 의 설정을 바꾸면 정크 메일 액션에 영향을 미친다
결론부타 말씀드리자면, 이 수행은 전혀 영향이 없습니다. 왜냐면 Edge 서버는 exchange org(굳이 조직이라고 안한 이유는.. 시스템상에서 묶여 있다는 느낌을 드리기 위해)와 완벽히 분리되어 있기 때문이죠.
궁금한 내용 3: Exchange/아웃룩 정크 메일 필터링은 모두 한곳에서 설정되고 관리되고 수행된다.
제가 Forefront BMT 시에 가장 애 먹는 부분 중 하나입니다. 왜냐하면 각 조직의 Exchange 구성이 모두 다른데다가 박스마다 어디서 무엇을 어떻게 설정하는지에 따라 결과도 다르거니와 모니터링도 하기 힘들기 때문입니다.
왜? 이것은 Exchange의 역할에 따른 스팸 필터링 기능이 따로 놓여져 있는 것도 있지만 아웃룩과의 상호 호환성 때문이기도 합니다. 아웃룩은 아웃룩 자체의 스팸 필터링 기술이 있습니다. Rich Client의 일환? 여하튼 이것이 바로 SmartScreen 필터링 기술입니다. 100%까지는 아니지만 대부분 Exchange에서 보내져 오는 스팸 기술과는 독립적으로 수행됩니다. 100%는 아니라고 말하는 것은, Exchange에서 보내져 오는 메일 중 스팸일 확률이 가장 낮다 라고 얘기하는 SCL -1 등급에 대해서는 아웃룩의 스팸 필터링 에이전트도 적극 수용합니다.
여기서 부터 조금 어려워집니다. 서버 side인 Exchange Store에서 정크 메일 폴더로 옮기는 두 가지 부분이 있습니다. 아래 두 가지 부분에서 SCL 정의 값 (SCL 몇 이상이면 정크메일 폴더로 옮겨라)을 확인하고 옮깁니다.
1. 메일 박스에서의 설정
2. OrganizationConfig object 에 있는 설정
하지만 실제로 정크메일 폴더로 옮겨지기 위해서는 숨겨진 inbox rule이 활성화 되어 있어야 합니다.
이 부분을 활성화하기 위해서는 Outlook의 cached mode 혹은 OWA의 옵션에서 정크 메일 필터링 옵션을 켜는 것입니다.
여기서 부터 많이 헷갈리는 부분입니다. 자, 그렇다면 Outlook에서는 꺼 놓고 OWA에서는 켜 놓고, 뭐 이러면 어떻게 되는거죠? 이렇게 되면 Exchange 서버에서의 스팸 필터링만 이루어지게 됩니다. 즉 smartscreen 필터링이나 사용자가 지정된 허용/차단 목록 등은 당연히 작동이 되지 않겠죠.
그래서 사실 기술지원부에서 문제를 해결하고자 할때는 Outlook OWA 모두 스팸 필터링을 꺼 놓고 테스트 한답니다.
궁금한 내용 3-가: Set-OWAVirtualDirectory -JunkEmailEnabled $True/False 를 수행하면 서버 side 필터링이 켜지거나 꺼진다
이것은 거짓입니다. 그럼 위와 같이 실행하면 무엇이 어떻게 변하는가?
영향을 미치는 것은 OWA의 정크 메일 관리에 관한 설정만 변합니다. 서버 side에서는 아무런 영향을 주지 않습니다.
궁금한 내용 4: SAFE LIST Aggregation을 이용하기 위해서는 Edge 서버가 필요하다
우선 Safe list aggregation이란 무엇인지 좀 알아보고 진행해 볼까요. Exchange 2007의 안티 스팸 기능 중 하나인 safe list aggregation은 특정 메일 사서함에 update-safelist cmdlet 을 실행시켜 msExchangeSafeSenderHash attribute 의 값을 업데이트 시킵니다. 이 값은 안전한 보낸이 목록 (safe senders list)로 AD의 메일 박스 객체에 쓰여집니다. 이 기능은 안티스팸 에이전트에 의해 발생될 수 있는 오탐율을 줄이기 위한 좋은 방법입니다.
자, 그럼 다시 본론으로 들어가, Edge가 필요한가? 아닙니다. 꼭 필요한 것은 아닙니다. Hub에 스팸 에이전트를 설치하면 이용하실 수 있습니다. CFA가 AD로부터 해당 값을 읽어 들여 수행하기 때문입니다.
아래 링크에 보다 자세히 Safe list aggregation에 대해 나와 있습니다. 참고로 공식적으로 Safe list aggregation는 * 수신 허용 목록 집계 *라고 부릅니다.
https://technet.microsoft.com/ko-kr/library/bb125168.aspx
궁금한 내용 5: TransportConfig 객체의 InternalSMTPServers 목록에 서버 IP와 IP 허용 리스트를 입력하는 것은 좋은 생각이다
별로 좋은 생각이 아닙니다.
Exchange 관리 콘솔 상에서 혹은 파워쉘 Add-IPAllowListEntry cmdlet 으로 IP 허용 리스트를 입력하게 되면 해당 IP로 들어오는 모든 connection (연결)에 대해 허용하게 되며 스팸 필터링 에이전트를 전혀 거치지 않습니다. (단 필터 sender/recipient 예외) IP 허용 리스트에 있는 IP에서 메일이 들어오게 되면 SCL을 -1로 찍어 보내게 됩니다.
InternalSMTPServers 의 용도는 무엇인가? 이 목록의 용도는 해당 IP들은 DMZ에 있는 서버들로 SenderID/IP BlockList provider/IP block list agents 들을 아무런 제약없이 통과하기 위함입니다. 안티 스팸 에이전트 마저 통과하기 위해 설계 된 목록이 아닙니다.
자, 그렇다면 왜 내부 SMTP 서버의 IP 를 허용 리스트에 넣으면 안 좋은가? 동일한 메일을 각각 IP 허용 리스트(예시1) 그리고 InternalSMTPServers 의 목록(예시2)과 함께 넣은 경우의 결과를 살펴보겠습니다.
예시 1: IP 허용 리스트에 추가된 메일의 헤더
예시 2: IP 허용 리스트에도 추가되고 InternalSMTPServers 목록에도 추가된 메일의 헤더
보시다시피, 두 결과 값은 완전히 다릅니다. InternalSMTPServers attribute에 대해 더 살펴보고자 하신다면 아래 링크를 참고하시기 바랍니다.
https://msexchangeteam.com/archive/2008/06/23/449070.aspx
궁금한 내용 6: Enable-AntispamUpdates 을 실행시키면 모든 Exchange 서버의 윈도우 업데이트를 받는다
Exchange 서버의 안티 스팸 업데이트는 Windows 자동 업데이트 API를 사용하고 있기는 합니다만, (그리고 윈도우 업데이트를 활성화 시키시기는 해야겠지만) 윈도우 업데이트를 모두 받는 것은 압니다. 또 자동 업데이트 주기를 따르고 있지도 않습니다. 아래 링크를 보시면 아시겠지만, 자체적으로 업데이트 주기 시간을 가지고 지속적으로 윈도우 업데이트와는 무관하게 업데이트를 받습니다.
https://msexchangeteam.com/archive/2007/01/03/432050.aspx
Edge 서버나 Hub 서버(안티 스팸 에이전트가 설치되어 있는)에서 cmdlet를 사용하시게 되면 MicrosoftUpdate parameter 에 RequestNotifyDownload 를 설정하실 수 있습니다.