정크메일의 제거
소개 (Introducing)
어떤 ISP의 메일 시스템 관리자에게 사용자와 고객의 불만 사항 중에 첫 번째 원인이 무엇인가를 질문하여 본다면, 모든 대답은 당연히 스팸(spam) 때문이라고 말할 것이다. 온라인 사회로 빠르게 확산되고 있는 환경에서 원치 않는 정크 e-mail(스팸)은 2가지 중요한 점에서 ISP에 특히 곤란한 문제를 제기한다:
월드 와이드 웹의 상업화 증가에 따른 피할 수 없는 부산물인 정크 메일러(Junk emailers)는 합법적인 e-mail 로부터 스팸을 제거하기 어렵도록 인터넷 공개 표준 및 프로토콜을 침해하고 있다. 스팸을 완전히 제거하기 위한 기술이 존재하지 않는 동안, 전략과 기술은 일반적인 스팸 침투의 원천을 방어하고 그것이 발생되었을 때 시스템 운영에서 스팸의 충격을 최소화하도록 관리자를 돕기 위해서만 존재한다고 볼 수 있다.
ISP 들의 독특한 메시징 요구사항을 완벽히 성공적으로 이행하는 단 하나의 회사로서, Software.com 은 스팸에 관련된 이슈들을 광범위하게 연구하였고, 산업 선도 메시징 서버로서 효과적인 방어가 가능하도록 통합해 왔다 :
이런 전문적인 기술과 다음의 토론은 증가하는 병충해의 분류와 기초적인 원천(직접적인 스팸 공격, 메일 릴레이)을 검토하기 위한 것이며 이것들에 대한 효과적인 증명된 전략을 확인해 보고자 하는 것이다. 이들 고려사항과 전략은 향후 구축할 메일 서버를 평가하는데 사용될 수 있다.
스팸 블락킹 및 필터링 (Spam Blocking and Filtering)
사용자의 메일박스 계정을 어지럽히는 스팸의 괴로움으로부터 내부 사용자를 보호하는 것은 메일 시스템 관리자의 중요한 책임이다. 메일 방어의 목적은 내부 메일 도메인 사용자에게 전송되는 메시지의 전달을 거절하기 위한 것이다. 즉, 내부 사용자에게 불필요한 정크 메일의 전송을 보호하는 것이다.
스팸 방어 전략 (Spam Blocking Strategies)
효과적인 메일 방어 능력은 발신자의 이름이나, 도메인, 완전한 주소로 지정된 발신자의 "블랙리스트" 기준에서 서버가 접속을 끊거나 메일을 거절하도록 만드는 것이다. 그리고 이상적으로는 필터링의 각각을 수정할 수 있어야 한다 : 특정한 도메인에 있는 발신자에서 개별 계정에 이르기까지.
메일 방어는 지정된 IP 주소와 IP 네트워크로부터 모든 네트워크의 접속을 거절할 수 있어야 한다. 또한, 이러한 블랙리스트 시스템으로부터 메일의 허락을 방지하는 것이다. 이것은 관리자가 다른 시스템으로부터 접속을 거절할 목적으로 시스템에서 많은 SMTP 접속을 열기위한 악의 있는 "서비스 거부(denial of service)" 공격을 방어하기 위한 것이다.
메일 방어(blocking)는 차단된 시스템과/또는 사용자로부터 합법적인 메일을 포함한 모든 메시지의 전송을 막기 때문에, 이들 특징은 알려진 공격자에 대항하기 위한 특수한 경우에 사용하는 것을 추천한다.
메일서버에서의 스팸 방어 (Spam Blocking)
메일서버는 블랙리스트를 위한 발신자 주소를 지정할 수 있는 유연성 있는 분류 옵션을 제공한다. 특정한 발신자 주소(주소를 통한 SMTP 메일)는 메시지의 거절이나 접속 해제를 하기 위하여 블락킹 규칙과 정확한 일치 여부를 비교한다.
메일서버는 메일을 차단하기 위한 4 가지 다른 분류의 사용을 허락한다: IP 주소, e-mail 주소, 도메인, 사용자 이름. 이들 옵션은 메일 시스템 관리자가 반-스팸 차단을 위해 각각의 내용을 조정할 수 있다.
메일 릴레이 예방 (Mail Relay Prevention)
메일 릴레이는 내부 메일 도메인의 하나에 주소가 없는 메시지가 메일 서버로 전송될 때 발생한다. 이것은 메일 서버의 가장 일반적인 행동이며, 사용자가 어떤 e-mail을 원거리 메일 도메인에 있는 사용자에게 보낼 때마다 발생된다. 그러나, 원거리 서버를 통한 릴레이 메일은 정크 메일을 배포하는 사람에 의해 일반적 전술로 사용되며 목표 메일 서버의 처리능력을 저하시키는 원인을 제공한다.
메일 릴레이는 SMTP 프로토콜의 개방 표준에 의해 만들어 질 수 있다. 설계에 의해, SMTP 서버는 메일 클라이언트로부터의 네트워크 접속, 네트워크(또는 인터넷)상의 어디에서의 메dlf 서버의 접속, 그리고 접속 시스템으로부터 e-mail 메시지를 수신하는 것을 허락한다. 만약 이런 메시지들이 내부 사용자 주소로 보내진다면, 서버는 정확히 그들을 배달할 것이다.
(예를 들면, POP3 메일박스로) 그러나, 메시지가 내부 사용자가 아닌 사람에게 전송된다면(수신 메일 서버에 의해 관리되지 않는 도메인에서) 전송을 위해 적합한 메일 서버로 메시지를 반드시 재전송(릴레이)할 것이다.
이 처리과정은 다른 인터넷 호스트 사이에서의 모든 e-mail 트래픽을 처리하는 백본(backbone) 이라고 할 수 있다. 예로써, Bob 의 메일 클라이언트를 메라크와 같은 시스템 메일 서버로 운영하는 myisp.com 호스트 SMTP 서버 (outgoing mail)로 사용할 때 무엇이 일어날지 생각해보자. 만약 Bob 이 mary@otherisp.com 의 Mary 에게 e-mail 을 보낸다면, 그의 메일 클라이언트는 라우팅 헤더를 검사하기 위해 myisp.com 에 SMTP 접속을 열어 메시지가 다른 otherisp.com 으로 가야할지를 결정하고, 그런 후 그 메시지를 보내기 위한 호스트로 접속을 열게 된다. Myisp.com 에 사용자의 주소가 지정되지 않았기 때문에, 그 호스트 상에 있는 Post.Office 는 마지막 행선지에 메시지를 간단히 릴레이 한다; 만약 갖고 있지 않다면, Bob 의 e-mail 은 Mary 에게 전혀 배달되지 않는다.
메일 릴레이가 메일 서버의 운영에서 필수적이고, 가장 일반적이고 대부분이 사용하지만, 이런 기능이 악용된다면 ISP 에 큰 문제를 발생시킬 것이다. 가장 일반적인 악용의 형태는 도메인 밖으로부터 사용자가 그들의 SMTP 서버를 도메인 메일서버로 사용하여 벌크 메시지를 릴이할 때 발생된다.
릴레이 예방 전략 (Relay Prevention Strategies)
강한 메일 서버는 특별한 시스템이나 도메인으로부터 메일 릴레이를 제한할 수 있을 뿐만 아니라 예외적인 시스템이나 도메인을 제외한 모든 릴레이를 허락하지 않는 반-릴레이 시설을 갖고 있어야 한다. 또한 이상적으로는 메일 시스템의 관리자가 제한된 릴레이 메일을 전송할 수 있도록 환경 설정을 정의할 수 있어야 한다.
이런 규칙에 있어서의 예외는 IP 주소(특정 호스트의 릴레이 허락이나 제한)와 도메인(특정도메인에 있는 모든 사용자의 릴레이 허락이나 제한)에 의해 정해질 수 있다. 어떤 도메인을 포함한 메일 클라이언트의 반송 메일 주소를 사용자가 쉽게 수정할 수 있기 때문에, IP 주소로 릴레이를 제한하는 것은 일반적으로 더욱 정확한 전략이다.
제한은 반드시 예방(prevent)을 의미하는 것은 아니라는 것을 명심하기 바란다. 최대의 유연성을 위해, 위 규칙을 가진 릴레이 메일의 제한은 처리와 전송을 위해 허락된 상태를 계속해서 유지하여야 한다. 릴레이 예방과 관련한 두 번째 규칙 조합은 제한된 릴레이 메일을 수신하는데 있어 도메인을 정하기 위해 필요하다. (예를 들면, 다른 도메인을 위한 백업으로서 메일서버가 사용되는 경우에서).
소개 (Introducing)
어떤 ISP의 메일 시스템 관리자에게 사용자와 고객의 불만 사항 중에 첫 번째 원인이 무엇인가를 질문하여 본다면, 모든 대답은 당연히 스팸(spam) 때문이라고 말할 것이다. 온라인 사회로 빠르게 확산되고 있는 환경에서 원치 않는 정크 e-mail(스팸)은 2가지 중요한 점에서 ISP에 특히 곤란한 문제를 제기한다:
· 고객 불만족
정크 e-mail 을 반복적으로 수신하여 성가시거나 화가 나는 고객들은 그들의 메일박스를 쉽게 취소하거나 때때로 메일을 사용하기 위해 ISP 를 바꾸기도 한다. 가입자의 혜택을 못 받는 결과 때문에.
· 시스템 전체비용(System overhead)의 증가
계속해서 증가하는 벌크 메일(bulk e-mail)의 수를 처리하는 것은 수용 가능한 서비스를 유지하기 위해, ISP 메일 시스템의 자원상에 아주 큰 부담을 주어 단순하게는 시스템 추가 비용을 요구하도록 한다. 이것은 격렬하게 경쟁하는 시장에서 그들의 하드웨어 예산을 가장 효과적으로 사용하여야 하는 중소형 ISP 에게는 심각한 위협이 된다.
정크 e-mail 을 반복적으로 수신하여 성가시거나 화가 나는 고객들은 그들의 메일박스를 쉽게 취소하거나 때때로 메일을 사용하기 위해 ISP 를 바꾸기도 한다. 가입자의 혜택을 못 받는 결과 때문에.
· 시스템 전체비용(System overhead)의 증가
계속해서 증가하는 벌크 메일(bulk e-mail)의 수를 처리하는 것은 수용 가능한 서비스를 유지하기 위해, ISP 메일 시스템의 자원상에 아주 큰 부담을 주어 단순하게는 시스템 추가 비용을 요구하도록 한다. 이것은 격렬하게 경쟁하는 시장에서 그들의 하드웨어 예산을 가장 효과적으로 사용하여야 하는 중소형 ISP 에게는 심각한 위협이 된다.
월드 와이드 웹의 상업화 증가에 따른 피할 수 없는 부산물인 정크 메일러(Junk emailers)는 합법적인 e-mail 로부터 스팸을 제거하기 어렵도록 인터넷 공개 표준 및 프로토콜을 침해하고 있다. 스팸을 완전히 제거하기 위한 기술이 존재하지 않는 동안, 전략과 기술은 일반적인 스팸 침투의 원천을 방어하고 그것이 발생되었을 때 시스템 운영에서 스팸의 충격을 최소화하도록 관리자를 돕기 위해서만 존재한다고 볼 수 있다.
ISP 들의 독특한 메시징 요구사항을 완벽히 성공적으로 이행하는 단 하나의 회사로서, Software.com 은 스팸에 관련된 이슈들을 광범위하게 연구하였고, 산업 선도 메시징 서버로서 효과적인 방어가 가능하도록 통합해 왔다 :
· 인트라넷과 중소형 ISP를 위한 메일서버
· 대규모 ISP와 통신업체를 위한 대규모 통신사용을 위한 메일서버
· 대규모 ISP와 통신업체를 위한 대규모 통신사용을 위한 메일서버
이런 전문적인 기술과 다음의 토론은 증가하는 병충해의 분류와 기초적인 원천(직접적인 스팸 공격, 메일 릴레이)을 검토하기 위한 것이며 이것들에 대한 효과적인 증명된 전략을 확인해 보고자 하는 것이다. 이들 고려사항과 전략은 향후 구축할 메일 서버를 평가하는데 사용될 수 있다.
스팸 블락킹 및 필터링 (Spam Blocking and Filtering)
사용자의 메일박스 계정을 어지럽히는 스팸의 괴로움으로부터 내부 사용자를 보호하는 것은 메일 시스템 관리자의 중요한 책임이다. 메일 방어의 목적은 내부 메일 도메인 사용자에게 전송되는 메시지의 전달을 거절하기 위한 것이다. 즉, 내부 사용자에게 불필요한 정크 메일의 전송을 보호하는 것이다.
스팸 방어 전략 (Spam Blocking Strategies)
효과적인 메일 방어 능력은 발신자의 이름이나, 도메인, 완전한 주소로 지정된 발신자의 "블랙리스트" 기준에서 서버가 접속을 끊거나 메일을 거절하도록 만드는 것이다. 그리고 이상적으로는 필터링의 각각을 수정할 수 있어야 한다 : 특정한 도메인에 있는 발신자에서 개별 계정에 이르기까지.
메일 방어는 지정된 IP 주소와 IP 네트워크로부터 모든 네트워크의 접속을 거절할 수 있어야 한다. 또한, 이러한 블랙리스트 시스템으로부터 메일의 허락을 방지하는 것이다. 이것은 관리자가 다른 시스템으로부터 접속을 거절할 목적으로 시스템에서 많은 SMTP 접속을 열기위한 악의 있는 "서비스 거부(denial of service)" 공격을 방어하기 위한 것이다.
메일 방어(blocking)는 차단된 시스템과/또는 사용자로부터 합법적인 메일을 포함한 모든 메시지의 전송을 막기 때문에, 이들 특징은 알려진 공격자에 대항하기 위한 특수한 경우에 사용하는 것을 추천한다.
메일서버에서의 스팸 방어 (Spam Blocking)
메일서버는 블랙리스트를 위한 발신자 주소를 지정할 수 있는 유연성 있는 분류 옵션을 제공한다. 특정한 발신자 주소(주소를 통한 SMTP 메일)는 메시지의 거절이나 접속 해제를 하기 위하여 블락킹 규칙과 정확한 일치 여부를 비교한다.
메일서버는 메일을 차단하기 위한 4 가지 다른 분류의 사용을 허락한다: IP 주소, e-mail 주소, 도메인, 사용자 이름. 이들 옵션은 메일 시스템 관리자가 반-스팸 차단을 위해 각각의 내용을 조정할 수 있다.
· IP 주소에 의한 방어.
IP 주소로 정의된 특정 컴퓨터나 네트워크로부터 메라크에 모든 SMTP 네트워크 접속을 방어하도록 허락한다. 네트워크 접속이 인정될 때, 메라크는 이 필드에 있는 트정 IP 주소 목록에서 접속 시스템의 IP를 검사한다. 만약 접속 시스템의 IP 주소가 목록에 있다면, Post.Office는 접속을 거절한다. 합법적인 사용자 접속을 저해하기 위한 ISP 서버에 공개된 많은 SMTP 접속을 하는 "서비스 거절 (Denial of Service)"의 공격을 방어하는데 유용하다.
· E-mail 주소에 의한 방어.
회신 주소로 설정되어 있는 수신 메일(incoming mail)의 차단을 허락한다. 메시지를 수신할 때, 메라크는 블랙리스트에 있는 e-mail 주소의 목록에서 각각의 메시지 에 붙어 있는 회신 주소를 검사한다; 만약 회신 주소가 목록에 있다면, 메라크는 메시지의 수신 주소가 존재하지 않는다는 것으로 발신자 시스템에 경고를 알려주고 그 메시지를 거절한다.
· 도메인에 의한 방어.
회신 주소로 동봉된 도메인에 근거한 수신 메일차단을 허락한다. 메시지를 수신할 때, 메라크는 블랙리스트 도메인의 목록에서 각각의 메시지 상에 있는 회신 주소 도메인을 검사한다; 만약 회신 주소의 도메인이 목록에 있다면, 메라크는 메시지를 거절하고 보낸 메일이 최종 주소에 보내지는 것이 허락되지 않았다고 발신자에게 알려준다.
· 사용자 이름에 의한 방어.
한 개 이상의 특정한 사용자 이름(사용자 이름은 e-mail 주소의 @ 심볼 왼쪽에 있는
부분)을 포함한 e-mail 주소로 메일 수신을 차단하는 것을 허락한다. 머 사이에 일반적인 스팸 발신 연습을 위해 다른 여러 개의 도메인에서 사용하여 메시지를 발신하는 정크 메일을 배포하는 사람들로부터 유용하다. 메시지를 수신할 때, 메라크는 블랙리스트 사용자의 메시지의 회신 주소 사용자 이름이 있는지를 검사한다; 만약 이름이 목록에 있다면, 메라크는 메시지를 거절하고 보낸 보내지는 것이 허락되지 않았다고 발신자에게 알려준다.
IP 주소로 정의된 특정 컴퓨터나 네트워크로부터 메라크에 모든 SMTP 네트워크 접속을 방어하도록 허락한다. 네트워크 접속이 인정될 때, 메라크는 이 필드에 있는 트정 IP 주소 목록에서 접속 시스템의 IP를 검사한다. 만약 접속 시스템의 IP 주소가 목록에 있다면, Post.Office는 접속을 거절한다. 합법적인 사용자 접속을 저해하기 위한 ISP 서버에 공개된 많은 SMTP 접속을 하는 "서비스 거절 (Denial of Service)"의 공격을 방어하는데 유용하다.
· E-mail 주소에 의한 방어.
회신 주소로 설정되어 있는 수신 메일(incoming mail)의 차단을 허락한다. 메시지를 수신할 때, 메라크는 블랙리스트에 있는 e-mail 주소의 목록에서 각각의 메시지 에 붙어 있는 회신 주소를 검사한다; 만약 회신 주소가 목록에 있다면, 메라크는 메시지의 수신 주소가 존재하지 않는다는 것으로 발신자 시스템에 경고를 알려주고 그 메시지를 거절한다.
· 도메인에 의한 방어.
회신 주소로 동봉된 도메인에 근거한 수신 메일차단을 허락한다. 메시지를 수신할 때, 메라크는 블랙리스트 도메인의 목록에서 각각의 메시지 상에 있는 회신 주소 도메인을 검사한다; 만약 회신 주소의 도메인이 목록에 있다면, 메라크는 메시지를 거절하고 보낸 메일이 최종 주소에 보내지는 것이 허락되지 않았다고 발신자에게 알려준다.
· 사용자 이름에 의한 방어.
한 개 이상의 특정한 사용자 이름(사용자 이름은 e-mail 주소의 @ 심볼 왼쪽에 있는
부분)을 포함한 e-mail 주소로 메일 수신을 차단하는 것을 허락한다. 머 사이에 일반적인 스팸 발신 연습을 위해 다른 여러 개의 도메인에서 사용하여 메시지를 발신하는 정크 메일을 배포하는 사람들로부터 유용하다. 메시지를 수신할 때, 메라크는 블랙리스트 사용자의 메시지의 회신 주소 사용자 이름이 있는지를 검사한다; 만약 이름이 목록에 있다면, 메라크는 메시지를 거절하고 보낸 보내지는 것이 허락되지 않았다고 발신자에게 알려준다.
메일 릴레이 예방 (Mail Relay Prevention)
메일 릴레이는 내부 메일 도메인의 하나에 주소가 없는 메시지가 메일 서버로 전송될 때 발생한다. 이것은 메일 서버의 가장 일반적인 행동이며, 사용자가 어떤 e-mail을 원거리 메일 도메인에 있는 사용자에게 보낼 때마다 발생된다. 그러나, 원거리 서버를 통한 릴레이 메일은 정크 메일을 배포하는 사람에 의해 일반적 전술로 사용되며 목표 메일 서버의 처리능력을 저하시키는 원인을 제공한다.
메일 릴레이는 SMTP 프로토콜의 개방 표준에 의해 만들어 질 수 있다. 설계에 의해, SMTP 서버는 메일 클라이언트로부터의 네트워크 접속, 네트워크(또는 인터넷)상의 어디에서의 메dlf 서버의 접속, 그리고 접속 시스템으로부터 e-mail 메시지를 수신하는 것을 허락한다. 만약 이런 메시지들이 내부 사용자 주소로 보내진다면, 서버는 정확히 그들을 배달할 것이다.
(예를 들면, POP3 메일박스로) 그러나, 메시지가 내부 사용자가 아닌 사람에게 전송된다면(수신 메일 서버에 의해 관리되지 않는 도메인에서) 전송을 위해 적합한 메일 서버로 메시지를 반드시 재전송(릴레이)할 것이다.
이 처리과정은 다른 인터넷 호스트 사이에서의 모든 e-mail 트래픽을 처리하는 백본(backbone) 이라고 할 수 있다. 예로써, Bob 의 메일 클라이언트를 메라크와 같은 시스템 메일 서버로 운영하는 myisp.com 호스트 SMTP 서버 (outgoing mail)로 사용할 때 무엇이 일어날지 생각해보자. 만약 Bob 이 mary@otherisp.com 의 Mary 에게 e-mail 을 보낸다면, 그의 메일 클라이언트는 라우팅 헤더를 검사하기 위해 myisp.com 에 SMTP 접속을 열어 메시지가 다른 otherisp.com 으로 가야할지를 결정하고, 그런 후 그 메시지를 보내기 위한 호스트로 접속을 열게 된다. Myisp.com 에 사용자의 주소가 지정되지 않았기 때문에, 그 호스트 상에 있는 Post.Office 는 마지막 행선지에 메시지를 간단히 릴레이 한다; 만약 갖고 있지 않다면, Bob 의 e-mail 은 Mary 에게 전혀 배달되지 않는다.
메일 릴레이가 메일 서버의 운영에서 필수적이고, 가장 일반적이고 대부분이 사용하지만, 이런 기능이 악용된다면 ISP 에 큰 문제를 발생시킬 것이다. 가장 일반적인 악용의 형태는 도메인 밖으로부터 사용자가 그들의 SMTP 서버를 도메인 메일서버로 사용하여 벌크 메시지를 릴이할 때 발생된다.
· 모욕적인 내용을 가진 릴레이는 순수한 사용자에게 쉽게 전송될 수 있고 메시지의 원본 추적을 종종 어렵게 할 수도 있다. 2가지 방법에서 목표된 메일 서버에 반대의 영향을 줄 수도 있다 : 메일 서버는 반드시 모든 스팸 메시지(수 천건)를 재전송하고 처리 하기 때문에, 그들의 e-mail을 위한 이 서버에 의존적인 사용자들 의 메시지를 전송하거나 수신하기 위해 일시적으로 사용이 불가능 해질 수도 있다.
· 릴레이 메일 서버는 결과적으로 인터넷 사회에서 받을 가치가 없는 나쁜 광고의 스팸으로 인해 실수를 하게 될 수도 있다. 그러므로 메일 릴레이를 제한하는 것은 스팸을 방지하기 위한 메일 시스템 관리자에게 있어 매우 중요한 이슈가 된다.
· 릴레이 메일 서버는 결과적으로 인터넷 사회에서 받을 가치가 없는 나쁜 광고의 스팸으로 인해 실수를 하게 될 수도 있다. 그러므로 메일 릴레이를 제한하는 것은 스팸을 방지하기 위한 메일 시스템 관리자에게 있어 매우 중요한 이슈가 된다.
릴레이 예방 전략 (Relay Prevention Strategies)
강한 메일 서버는 특별한 시스템이나 도메인으로부터 메일 릴레이를 제한할 수 있을 뿐만 아니라 예외적인 시스템이나 도메인을 제외한 모든 릴레이를 허락하지 않는 반-릴레이 시설을 갖고 있어야 한다. 또한 이상적으로는 메일 시스템의 관리자가 제한된 릴레이 메일을 전송할 수 있도록 환경 설정을 정의할 수 있어야 한다.
이런 규칙에 있어서의 예외는 IP 주소(특정 호스트의 릴레이 허락이나 제한)와 도메인(특정도메인에 있는 모든 사용자의 릴레이 허락이나 제한)에 의해 정해질 수 있다. 어떤 도메인을 포함한 메일 클라이언트의 반송 메일 주소를 사용자가 쉽게 수정할 수 있기 때문에, IP 주소로 릴레이를 제한하는 것은 일반적으로 더욱 정확한 전략이다.
제한은 반드시 예방(prevent)을 의미하는 것은 아니라는 것을 명심하기 바란다. 최대의 유연성을 위해, 위 규칙을 가진 릴레이 메일의 제한은 처리와 전송을 위해 허락된 상태를 계속해서 유지하여야 한다. 릴레이 예방과 관련한 두 번째 규칙 조합은 제한된 릴레이 메일을 수신하는데 있어 도메인을 정하기 위해 필요하다. (예를 들면, 다른 도메인을 위한 백업으로서 메일서버가 사용되는 경우에서).