KR20120090905A - 보안상 안전한 송신자 리스트를 이용하는 메시지 커뮤니케이션 방법 및 매체 - Google Patents

Abstract

보안상 안전한 송신자 리스트(secure safe sender list)가 설명된다. 일 구현에서, 방법은 복수의 계층구조적 레벨들 중 어느 것이 네트워크를 통해 수신된 메시지에 대응하는지를 판정하는 단계를 포함한다. 각각의 계층구조적 레벨은 메시지의 송신자를 식별하기 위한 메커니즘에 의해 정의된다. 메시지는 계층구조적 레벨들 중 대응하는 하나에 따라 라우팅된다.

Description

보안상 안전한 송신자 리스트를 이용하는 메시지 커뮤니케이션 방법 및 매체{SECURE SAFE SENDER LIST}

본 발명은 일반적으로 메시지 커뮤니케이션 분야에 관한 것이며, 보다 구체적으로 보안상 안전한 송신자 리스트를 채용할 수 있는 메시지 커뮤니케이션에 관한 것이다.

메시지를 이용하는 커뮤니케이션은 데스크탑 컴퓨터, 무선 전화 등의 컴퓨팅 장치들의 광범위한 향상된 기능을 사용자들에게 제공해왔다. 예를 들어, 사용자들은 이메일(즉, 전자 메일)을 이용하여 서로 커뮤니케이션할 수 있다. 이메일은 어드레싱(addressing) 및 라우팅(routing)하기 위한 표준 및 조약을 채용하여, 이메일이 복수의 장치들을 이용해 인터넷과 같은 네트워크를 거쳐 커뮤니케이션될 수 있게 한다. 이 방식으로, 이메일은 인트라넷을 통해 회사 내에서, 또는 인터넷을 사용하여 전세계를 거쳐 전송될 수 있다.

이메일의 이용은 사용자에게 수많은 이점을 제공해왔다. 예를 들어, 이메일은 대부분 순간적으로 커뮤니케이션될 수 있지만, 이메일이 즉각적인 응답을 제공하도록 수신될 때, 그 이메일은 수신자의 일정에 따라, 예를 들어 사용자가 메시지에 대답하기에 충분한 자료를 가진 후 등과 같은 때에 처리될 수 있다. 또한, 사용자에 의해 수신된 하나 이상의 특정한 이메일들에 응답하고자 할 때와 같은 때에, 이메일은 사용자가 메시지에 우선권을 주게 할 수 있다. 이러한 이점 및 그외의 이점들 때문에, 이메일이 계속 널리 보급되어, 이제는 이메일이 가정 및 전형적인 비지니스(business) 모두에서의 매일의 삶에서 없어서는 안 될 부분으로 고려되고 있다.

또 다른 예에서, 사용자들은 인스턴트 메시징을 이용하여 서로 커뮤니케이션할 수 있다. 예를 들어, 두 명의 사용자가 동시에 온라인상에 있을 때, 인스턴트 메시지들은 두 사용자들 사이에 실시간으로 교환될 수 있다. 이 예에서, 인스턴트 메시지는, 두 사용자가 전형적인 구두 대화에 참여하는 방법과 흡사한 방식으로 두 사용자 간의 텍스트 대화를 지원하는 데 이용될 수 있다.

그러나 불행하게도, 메시징을 송신하기 위한 이러한 기술이 계속 널리 보급될수록, 사용자가 수신하는 "스팸(spam)"의 양도 또한 계속 증가한다. 스팸은 전형적으로 제품 또는 서비스를 판촉하기 위한 것과 같은, 수많은 수신자들에게 송신되는 이메일이라고 생각된다. 일반적으로 송신자는 이메일을 송신할 때 비용을 거의 들이지 않거나 아예 들이지 않기 때문에, "스패머(spammer)"들은 정크 메일(junk mail)과 같은 것을 알아낼 수 있는 한 많은 사용자들에게 송신할 수 있는 것을 개발해왔다. 실제로 수신자들 중 극히 일부만이 스팸에 설명된 제품 또는 서비스를 원할 수 있지만, 이러한 극히 일부만으로도 스팸을 송신하는 최소한의 비용을 보충하기에 충분할 수 있다. 결과적으로, 수많은 스패머들은 수많은 원하지 않으며 관련성 없는 이메일들을 커뮤니케이션할 수 있다. 그러므로, 전형적인 사용자는 수많은 이러한 관련성 없는 이메일들을 수신할 수 있으며, 이에 따라 관련성 있는 이메일들과 사용자와의 상호작용이 방해받는다. 몇몇 예에서, 예를 들어, 사용자는, 사용자가 수신한 이메일들 중 어느 것이 실제로 관심 있는 것인지를 판정하기 위해 원하지 않는 이메일들 각각과 상호작용하기 위해 상당한 시간을 보내야 할 수 있다.

그러므로, 네트워크를 통해 커뮤니케이션되는 원하지 않는 메시지들을 제한하기 위해 채용될 수 있는 기술이 계속 요구된다.

원하지 않는 메시지들을 제한하기 위해 이용될 수 있는 보안상 안전한 송신자 리스트(secure safe sender list)가 설명된다. 이메일 구현에서, 예를 들어, 보안상 안전한 송신자 리스트는, 이메일 주소, 제삼자 증명서, 자가 서명된 증명서(self-signed certificate), 금전적 첨부물[예를 들어, "이스탬프(e-stamp)"] 등의 이메일이 "진짜(genuine)"(즉, 바람직한 송신자로부터의 것임)인지를 판정하기 위해 이용될 수 있는 복수의 식별 메커니즘을 참조할 수 있다. 그러므로, 이 구현에서, 보안상 안전한 송신자 리스트는 이메일이 믿을 수 있는 소스(source)로부터의 것인지를 판정하여, 믿을 수 있는 소스로부터의 것이면, 사용자에게 보여지도록 라우팅하고, 믿을 수 있는 소스들로부터의 것이 아닌 이메일들은 관련성 있는 이메일들과 사용자와의 상호작용을 방해하지 못하게 하는 데 이용될 수 있다.

보안상 안전한 송신자 리스트는 또한 메시지에 연관된 보안 레벨에 따른 메시지들의 측정가능한 처리를 제공한다. 예를 들어, 식별 기술은(단독 또는 상이한 조합으로) 몇몇의 상이한 레벨(즉, 계층구조)의 보안을 제공한다. 메시지들은 어떤 상이한 레벨들의 보안이 메시지에 의해 만족되는지에 기초하여 라우팅될 수 있다. 예를 들어, 특정한 이메일 주소로부터의 이메일이 보안상 안전한 송신자 리스트에 의해 지정된 것과 같은 "고레벨" 보안 요구사항(예를 들어, 제삼자 증명서 포함)에 따르면, 이메일은 사용자의 인박스(inbox)로 라우팅될 수 있다. 그러나, 이메일이 단지 "저레벨" 보안 요구사항만을 만족하면, 이메일은 다른 프로세싱("spam" 필터에 의한 것과 같음)을 위해 라우팅되고, 전용 "스팸"으로 라우팅 등이 될 수 있다.

또한, 보안상 안전한 송신자 리스트는 사용자 인터페이스를 이용하여 동적으로 구성될 수 있다. 예를 들어, 이메일은 어느 식별 메커니즘(만약 있다면)이 송신자의 신분을 검증하는 데 채용될 수 있는지를 판정하기 위해 검사될 수 있다. 이메일이 믿을 수 있는 소스로부터 송신됐을 우도(likelihood)를 나타내는 식별 메커니즘을 포함하고 있으면, 사용자는 자신으로부터의 이메일들이 향후 라우팅에 이용하기 위해 그 송신자의 이메일 주소를 보안상 안전한 송신자 리스트에 추가하도록 프롬프팅(prompting)될 수 있다. 이외에, 보안상 안전한 송신자 리스트는 또한 사용자에게 보여질 송신자로부터의 향후 이메일들을 라우팅하는 데 채용될 수 있는 하나 이상의 식별 메커니즘(예를 들어, 제삼자 증명서)을 참조할 수 있다.

본 발명은 원하지 않는 메시지들을 제한하기 위해 이용될 수 있는 보안상 안전한 송신자 리스트를 채용할 수 있는 메시지 전송방법 및 매체를 제공한다.

도 1은 네트워크를 통해 이메일, 인스턴트 메시지(instant message) 등의 메시지들을 커뮤니케이션(communication)하도록 동작할 수 있는 환경을 예시하는 도면.
도 2는 도 1의 복수의 클라이언트들 및 복수의 서버들을 더욱 상세하게 나타내는, 예시적인 구현 내의 시스템을 나타내는 도면.
도 3은 이메일로 구성된 메시지가 복수의 식별 메커니즘을 이용하여 처리되는, 예시적인 구현 내의 절차를 나타내는 흐름도.
도 4는 메시지가 복수의 식별 메커니즘들을 이용하여 처리되고, 그 결과가 향후 메시지의 처리를 위해 필터 모듈(filter module)에 커뮤니케이션되는, 예시적인 구현 내의 절차를 나타내는 흐름도.
도 5는 보안상 안전한 송신자 리스트가 파퓰레이트(populate)되는, 예시적인 구현 내의 절차를 나타내는 흐름도.

본 설명의 예에서 같은 구조 및 컴포넌트들을 참조하기 위해 동일한 참조 번호가 이용된다.

도 1은 네트워크를 통해 메시지들을 커뮤니케이션하도록 동작할 수 있는 환경(100)을 예시한다. 환경(100)은 네트워크(104)를 통해 커뮤니케이션적으로 서로 연결된 복수의 클라이언트[102(1),...,102(n),...,102(N)]들을 포함하는 것으로 예시된다. 복수의 클라이언트[102(1)-102(N)]들은 다양한 방식으로 구성될 수 있다. 예를 들어, 하나 이상의 클라이언트[102(1)-102(N)]들은 네트워트(104)를 통해 커뮤니케이션할 수 있는, 디스플레이 장치, 무선 전화 등에 커뮤니케이션적으로 연결된 데스크탑 컴퓨터, 모바일 스테이션, 게임 콘솔, 오락 기기, 셋 탑 박스와 같은 컴퓨터로 구성될 수 있다. 클라이언트[102(1)-102(N)]는 상당한 메모리 및 프로세서 자원을 갖는 최고 자원 장치(full resource device)(예를 들어, 개인용 컴퓨터, 하드 디스크를 구비한 텔레비전 녹화기)에서부터 제한된 메모리 및/또는 프로세싱 자원을 갖는 낮은 자원 장치(low-resource device)(예를 들어, 통상적인 셋 탑 박스)까지의 범위일 수 있다. 다음의 설명에서, 클라이언트[102(1)-102(N)]는 클라이언트를 동작시키는 사람 및/또는 엔티티(entity)에 관련된 것일 수 있다. 즉, 클라이언트[102(1)-102(N)]는 사용자 및/또는 기기를 포함하는 논리적인 클라이언트를 나타낼 수 있다.

이외에, 네트워크(104)가 인터넷으로 예시되어 있지만, 네트워크는 광범위한 구성이라고 가정될 수 있다. 예를 들어, 네트워크(104)는 WAN, LAN, 무선 네트워크, 공중 전화 네트워크, 인트라넷 등을 포함할 수 있다. 또한, 단일 네트워크(104)가 나타나 있지만, 네트워크(104)는 복수의 네트워크들을 포함하도록 구성될 수 있다. 예를 들어, 클라이언트[102(1), 102(n)]는 커뮤니케이션하기 위해 점대점 네트워크를 통해 커뮤니케이션적으로 연결될 수 있다. 각각의 클라이언트[102(1), 102(n)]는 또한 인터넷을 통해 서로 클라이언트[102(N)]에 커뮤니케이션적으로 연결될 수 있다. 또 다른 예에서, 클라이언트[102(1), 102(n)]는 커뮤니케이션하기 위해 인트라넷을 통해 서로 커뮤니케이션적으로 연결된다. 이 다른 예에서의 클라이언트[102(1), 102(n)] 각각은 또한 인터넷을 통해 클라이언트[102(N)]에 액세스하기 위해 게이트웨이(gateway)를 통해 커뮤니케이션적으로 연결된다.

복수의 클라이언트[102(1)-102(N)]들 각각은 복수의 커뮤니케이션 모듈[106(1),...,106(n),...,106(N)]들 중 각각 하나씩을 포함하는 것으로 예시된다. 예시된 구현에서, 복수의 커뮤니케이션 모듈[106(1)-106(N)] 각각은 복수의 클라이언트[102(1)-102(N)]들 중 각각에서 메시지를 송신 및 수신하도록 실행된다. 예를 들어, 하나 이상의 커뮤니케이션 모듈[106(1)-106(N)]은 이메일을 송신 및 수신하도록 구성될 수 있다. 전술된 바와 같이, 이메일은 어드레싱 및 라우팅에 대한 표준 및 조약을 채용하여, 이메일이 라우터, 다른 컴퓨팅 장치(예를 들어, 이메일 서버) 등과 같은 복수의 장치들을 이용해 네트워크(104)를 거쳐 전달될 수 있게 한다. 이 방식으로, 이메일은 인트라넷을 통해 회사 내에서, 인터넷 등을 이용하여 전세계에 걸쳐 전송될 수 있다. 예를 들어, 이메일은 헤더(header), 텍스트, 및 문서와 같은 첨부물, 컴퓨터 실행가능 파일 등을 포함할 수 있다. 헤더는 소스에 대한 기술적 정보를 포함하며, 종종 메시지가 송신자로부터 수신자에게로 커뮤니케이션되는 라우트를 설명할 수 있다.

또 다른 예에서, 하나 이상의 커뮤니케이션 모듈[106(1)-106(N)]은 인스턴트 메시지들을 송신 및 수신하도록 구성될 수 있다. 인스턴트 메시징은, 각각의 클라이언트[102(1)-102(N)]들이 인스턴트 메시징 세션에 참여해 있을 때 서로에게 텍스트 메시지를 송신할 수 있게 하기 위한 메커니즘을 제공한다. 클라이언트[102(1)-102(N)]들 중 하나가 이용할 수 없을 때(예를 들어, 오프라인) 텍스트 메시지를 로깅(logging)하는 것에 의한 것과 같이, 지연된 커뮤니케이션도 또한 이용될 수 있지만, 인스턴트 메시지들은 전형적으로 실시간으로 커뮤니케이션된다. 그러므로, 인스턴트 메시징은 메시지 교환을 지원하고 양방향 라이브 채팅(two-way live chating)를 위해 설계된다는 점에서 이메일과 인터넷 채팅의 조합으로서 간주될 수 있다. 그러므로, 인스턴트 메시징은 동기화 커뮤니케이션을 위해 이용될 수 있다. 음성 통화와 마찬가지로, 인스턴트 메시징 세션은, 각각의 사용자가 인스턴트 메시지들이 수신될 때 사용자 서로에게 응답할 수 있도록 실시간으로 수행된다.

일 구현에서, 커뮤니케이션 모듈[106(1)-106(N)]은 서버 클러스터(server cluster, 108)를 이용하여 서로 커뮤니케이션한다. 서버 클러스터(108)는 복수의 서버[110(m)]를 포함하는데, 여기서 "m"은 1부터 "M"까지 중 임의의 정수일 수 있다. 서버 클러스터(108)는 로드 밸런싱(load balancing) 및 시스템 대체 작동(failover)과 같은 광범위한 기능을 제공하도록 구성될 수 있다. 서버 클러스터(108) 내의 복수의 서버[110(m)]들 중 하나 이상은 복수의 클라이언트[102(1)-102(N)]들 사이에 커뮤니케이션할 복수의 메시지[114(h)]들을 저장하기 위한 각각의 데이터베이스[112(m)]를 포함할 수 있는데, 여기서 "h"는 1에서부터 "H"까지 중 임의의 정수일 수 있다.

예를 들어, 서버[110(m)]는 커뮤니케이션 모듈[106(1)-106(N)] 간에 인스턴트 메시지들을 라우팅하기 위해 그것 상에서 실행될 수 있는 커뮤니케이션 관리자 모듈[116(m)](본원에서는 "관리 모듈")을 포함할 수 있다. 예를 들어, 클라이언트[102(1)]는 커뮤니케이션 모듈[106(1)]이 클라이언트[102(n)]에게 커뮤니케이션할 인스턴트 메시지를 형성하게 할 수 있다. 커뮤니케이션 모듈[106(1)]은 서버[110(m)]에게 인스턴트 메시지를 커뮤니케이션하도록 실행되며, 그 후 서버[110(m)]는 관리자 모듈[116(m)]이 네트워크(104)를 통해 클라이언트[102(n)]에게 인스턴트 메시지를 라우팅하도록 실행시킨다. 클라이언트[102(n)]는 인스턴트 메시지를 수신하고, 인스턴트 메시지를 각각의 사용자에게 디스플레이하도록 각각의 커뮤니케이션 모듈[106(n)]을 실행시킨다. 또 다른 예에서, 클라이언트[102(1), 102(n)]들이 커뮤니케이션적으로 서로 (예를 들어, 점대점 네트워크를 통해) 직접적으로 연결되어 있으면, 인스턴트 메시지들은 서버 클러스터(108)를 이용하지 않고서도 커뮤니케이션된다.

또 다른 예에서, 서버 클러스터(108)는 이메일 공급자와 같은 구성 등을 통해, 이메일을 저장 및 라우팅하도록 구성될 수 있다. 예를 들어, 상기 예와 같이, 클라이언트[102(1)]는 커뮤니케이션 모듈[106(1)]이 클라이언트[102(n)]에게 커뮤니케이션할 이메일을 형성하도록 실행시킬 수 있다. 커뮤니케이션 모듈[106(1)]은, 서버[110(m)]에 이메일을 커뮤니케이션하고, 그 후 이메일은 복수의 메시지[114(h)]들 중 하나로서 저장된다. 이메일을 검색하기 위해, 클라이언트[102(n)]는 서버 클러스터(108)에 (예를 들어, 사용자 신분 및 비밀번호를 제공함으로써) "로그 온(log on)"하고, 각각의 사용자 계정으로부터 이메일을 검색한다. 이 예에서, 사용자는 네트워크(104)를 통해 서버 클러스터(108)에 커뮤니케이션적으로 연결된 복수의 클라이언트[102(1)-102(N)]들 중 하나 이상으로부터 대응하는 이메일을 검색할 수 있다. 이메일 및 인스턴트 메시지로 구성된 메시지들이 설명되었지만, 다양한 텍스트 메시지 및 텍스트가 아닌 메시지(예를 들어, 그래픽 메시지, 오디오 메시지 등)들도 본 발명의 취지 및 영역을 벗어나지 않으면서 환경(100)을 통해 커뮤니케이션될 수 있다. 이외에, SSSL은 사용자가 VOIP(voice-over IP) 콜을 수용할지 또는 콜을 음성 메일에 라우팅할지를 판정하기 위한 것과 같은 다양한 다른 커뮤니케이션 기술을 위해 이용된다.

전술된 바와 같이, 환경(100)의 효율성으로 인해 "스팸"이라 불리는 원하지 않는 메시지들까지도 커뮤니케이션되게 되었다. 스팸은 통상적으로 제품 또는 서비스의 판촉 등을 위해 수많은 수신자들에게 송신되는 이메일을 통해 제공된다. 그러므로, 스팸은 전자 형태의 "정크" 메일로 간주될 수 있다. 수많은 이메일들이 적은 비용으로 또는 비용을 들이지 않고 환경(100)을 통해 송신자에게 커뮤니케이션될 수 있기 때문에, 수많은 스패머들은 수많은 원하지 않으며 관련성 없는 메시지들을 커뮤니케이션할 수 있다. 그러므로, 복수의 클라이언트[102(1)-102(N)] 각각은 수많은 이러한 관련성 없는 메시지들을 수신하고, 이에 따라 실제로 관심 있는 이메일들과 클라이언트와의 상호작용이 방해된다.

원하지 않는 메시지들의 커뮤니케이션을 막기 위해 이용될 수 있는 하나의 기술은 "안전한 송신자" 리스트를 이용하는 것이다. 예를 들어, 안전한 송신자 리스트는 이메일 사용자가 기꺼이 이메일을 수신하고자하는 이메일 주소(예를 들어, 이메일을 송신하기 위해 이용되는 엔티티의 주소)들을 지정할 수 있게 한다. 예를 들어, 안전한 송신자 리스트는, 사용자의 인박스 내의 저장을 위해 클라이언트에 의해 채용되는 임의의 스팸 필터링을 통해 지정된 주소로부터의 이메일에 "안전한 통행권"을 주는 데 이용될 수 있다. 그러나 불행하게도, 안전한 송신자 리스트의 몇몇 구현은 "스푸핑(spoofing)"될 수 있다. 예를 들어, 공격자가 사용자의 안전한 송신자 리스트에 포함된 이메일 주소들을 발견하면, 공격자는 SMTP 커뮤니케이션 내의 "FROM" 라인을 스푸핑하는 것과 같은 것으로 이러한 주소들 중 하나가 나타내는 엔티티인 채 할 수 있다. 그 결과, 공격자의 메시지는 수신자의 인박스에 직접적으로 전달될 것이다. 공격자는 안전한 송신자 리스트의 콘텐츠를 획득하기 위해 수신자의 홈페이지 상의 (또는 수신자의 홈페이지에 링크되거나 그것으로부터 링크된 페이지들 상의) 다른 주소들에 대한 웹을 해킹, 추측, 크롤링(crawling)하는 등의 다양한 기술을 이용할 수 있다.

스푸핑 및 다른 신분 공격으로부터 보호하기 위해, 환경(100)은 복수의 보안상 안전한 송신자 리스트[118(1),...,118(n),...,118(N)](이후 "SSSL")를 통합할 수 있다. SSSL[118(1)-118(N)]은 메시지가 실제로 그 메시지가 나타내는 송신자로부터 전송된 것인지를 검증하기 위해 다양한 식별 메커니즘을 조합하도록 구성될 수 있다. 예를 들어, SSSL[118(n)]은, 사용자가 스푸핑하기 어려운 정보(예를 들어, 식별 메커니즘)를 이메일 주소와 조합하여, 보다 더 공격하기 어려운 조합을 형성할 수 있게 해주도록 구성될 수 있다. 예를 들어, SSSL은 이메일 주소 "test@test.com" 및 제삼자 증명서를 포함하는 조합을 참조할 수 있다. 이에 따라, 참조된 제삼자 증명서로 서명된 test@test.com으로부터의 클라이언트[102(n)]에의 수신된 메시지는 클라이언트의 인박스에 전달된다. 그러나, 제삼자 증명서를 포함하지 않는 test@test.com으로부터의 또 다른 메시지는 SSSL[118(n)] 상에 없는 것처럼 취급될 수 있다. 그러므로, 공격자가 "test@test.com"가 사용자의 안전한 송신자 리스트 상에 있다고 추측하더라도, 공격자는 대응하는 제삼자 증명서로 이메일에 서명할 수 없는 한 정보를 이용할 수 없으며, 이에 따라 스팸에 대한 추가적인 보호가 제공된다.

SSSL[118(1)-118(N)]은 환경(100)에서 다양한 방식으로 제공될 수 있다. 도 1의 예시된 예에서, 예를 들어, 복수의 클라이언트[102(1)-102(N)] 각각은 이메일의 송신자를 검증하는 데 이용될 수 있는 특정한 식별 메커니즘들을 참조하는 복수의 SSSL[118(1)-118(N)] 중 각각의 하나를 포함한다. 또한 도 1에 예시된 바와 같이, 복수의 SSSL[118(k)]은 서버 클러스터(108)에 저장될 수 있으며, 여기서 "k"는 1에서부터 "K"까지 중 임의의 정수일 수 있다. 예를 들어, 서버[110(m)]는 복수의 SSSL[118(k)]을 저장하도록 구성된 데이터베이스(120)를 포함할 수 있다. 예를 들어, 복수의 SSSL[118(k)]은 복수의 클라이언트[102(1)-102(N)]로부터의 SSSL[118(1)-118(N)]들의 복사본일 수 있다. 그러므로, 서버[110(m)]는 메시지를 처리하기 위해 SSSL[118(1)-118(N)]이 채용되는 방법과 유사한 방식으로 SSSL[118(1)-118(N)]을 이용할 수 있다. 그러나, 서버 클러스터(108)에서 메시지의 프로세싱을 수행함으로써, 프로세싱 기능은, 전술된 바와 같이 "씬(thin)" 클라이언트에게 이 기능을 제공하는 데 이용될 수 있는 복수의 클라이언트[102(1)-102(N)]들 상의 자원들을 택싱(taxing)하지 않고서도 채용될 수 있다. 이외에, 사용자는 다른 클라이언트를 이용하여 로그온할 때도 똑같이 대응하는 단일 SSSL의 이점을 취할 수 있다. 복수의 SSSL[118(1)-118(N)]에 의해 참조 및 채용될 수 있는 식별 메커니즘은 도 2를 참조하여 더욱 설명될 수 있다.

일 구현에서, SSSL[118(1)-118(N)]에 포함된 식별 메커니즘들 중 하나 이상은 공격 및 스푸핑에 대한 상이한 레벨의 보안을 제공한다. 그러므로, 이 구현에서, SSSL[118(1)-118(N)] 내의 각각의 엔트리들은 사용자의 인박스와 같은 것에 상이한 레벨의 액세스를 제공하도록 이용될 수 있다. 즉, SSSL[118(1)]은, 하나의 엔트리가 하나 이상의 상이한 식별 메커니즘들을 참조하는 또 다른 엔트리에 의해 수행되는 검증보다 유효한 신분을 나타낼 확률이 큰 하나 이상의 식별 메커니즘을 설명하는 신분 검증의 계층구조를 설명할 수 있다. 예를 들어, 이메일 주소와 자가 서명된 유효한 증명서를 조합한 엔트리는 송신자의 신분에 대한 강력한 "힌트"는 제공하되 배달은 보증하지 않는 한편, 이메일 주소와 매우 신뢰적인 제삼자 증명서로부터의 제삼자 증명서를 조합한 SSSL[118(1)] 엔트리는 메시지에 최대 가능한 부스트(boost)(예를 들어, 사용자의 인박스로의 보증된 배달)를 제공할 수 있다.

계층 구조는 다양한 방식으로 채용 및 유지될 수 있다. 예를 들어, 계층구조는 사용자에 의해 제공되고, 안티 스팸 웹 서비스 등으로부터 동적으로 전개 및 갱신되는 SSSL[118(1)-118(N)] 내에 (예를 들어, 손수 만든 규칙, 기기 학습 등으로) 구축될 수 있다. 예를 들어, SSSL이 커뮤니케이션을 보증하기 위해 안전한 제삼자 증명서를 이용하면, 이것은, 사용자가 수신된 각각의 메시지가 유효하다는 것을, 예를 들어, "스푸핑"되지 않았다는 것을 확신할 수 있는 폐쇄된 이메일 시스템을 생성할 수 있다. 메시지를 처리하기 위하여 SSSL 및 그 관련 식별 메커니즘을 이용하는 것에 대한 설명이 도 3 및 도 4에 관련하여 더 제공될 수 있다.

이외에, SSSL[118(1)-118(N)]은 다양한 방식으로 유지될 수 있다. 예를 들어, 하나 이상의 커뮤니케이션 모듈[106(1)-106(N)]은 SSSL[118(1)-118(N)] 내의 엔트리들에 대한 액세스 레벨 및 식별 메커니즘을 지정할 때 사용자를 돕기 위한 사용자 인터페이스를 제공하도록 실행될 수 있다. 사용자 인터페이스에 대한 설명이 도 5에 관련하여 더 제공될 수 있다.

일반적으로, 본원에 설명된 임의의 기능들은 소프트웨어, 펌웨어(예를 들어, 고정된 논리 회로), 매뉴얼 프로세싱, 또는 이 구현들의 조합을 이용하여 구현될 수 있다. 본원에 이용된 "모듈", "기능" 및 "논리"란 용어는 일반적으로 소프트웨어, 펌웨어 또는 소프트웨어와 펌웨어의 조합을 나타낸다. 소프트웨어 구현의 경우에, 모듈, 기능 또는 논리는 프로세서(예를 들어, 하나의 CPU 또는 CPU들) 상에서 실행될 때 지정된 태스크들을 수행하는 프로그램 코드를 나타낸다. 프로그램 코드는 하나 이상의 컴퓨터 판독가능 메모리 장치에 저장될 수 있으며, 이에 대한 설명은 도 2에 관련하여 더욱 인식될 수 있다. 후술된 SSSL 전략(SSSL strategy)의 특징은 플랫폼 독립적이라는 것이며, 이것은 전략이 다양한 프로세서들을 갖는 다양한 상업성 컴퓨팅 플랫폼 상에 구현될 수 있다는 것을 의미한다.

도 2는 예시적인 구현에서 도 1의 복수의 클라이언트[102(n)] 및 복수의 서버[110(m)]들을 보다 상세하게 나타내는 시스템(200)의 예시이다. 도 2의 복수의 클라이언트[102(n)] 각각은 각각의 프로세서[202(n)] 및 메모리[204(n)]를 포함하는 것으로 예시된다. 이와 마찬가지로, 복수의 서버[110(m)] 각각은 각각의 프로세서[206(m)] 및 메모리[208(m)]를 포함하는 것으로 예시된다. 프로세서는 그들이 형성된 물질 또는 본원에 채용된 프로세싱 메커니즘에 의해 제한되지 않는다. 예를 들어, 프로세서는 반도체(들) 및/또는 트랜지스터[예를 들어, 전자 집적 회로(IC)]로 구성될 수 있다. 이러한 문맥에서, 프로세서 실행가능 명령어는 전자적으로 실행가능한 명령어일 수 있다. 이외에, 프로세서의 또는 그에 대한 메커니즘, 및 이에 따라 컴퓨팅 장치의 또는 그에 대한 메커니즘은 양자 컴퓨팅(quantum computing), 광학 컴퓨팅, 메커니즘 컴퓨팅(예를 들어, 나노기술 이용) 등을 포함할 수 있지만, 이에 한정되지 않는다. 이외에, 각각의 클라이언트[102(n)]에 대해서 단일 메모리[204(n)]가 도시되고, 각각의 서버[110(m)]에 대해서 단일 메모리[208(m)]가 도시되어 있지만, RAM, 하드 디스크 메모리, 분리형 매체 메모리 등과 같은 광범위한 유형 및 조합의 메모리가 채용될 수 있다.

클라이언트[102(n)]는 메모리[204(n)] 내에 저장가능한 프로세서[202(n)] 상에서 커뮤니케이션 모듈[106(n)]을 실행시키는 것으로 예시된다. 실행시에 커뮤니케이션 모듈[106(n)]은 메모리[204(n)]에 저장된 것으로 예시된 각각의 SSSL[118(n)]을 이용하는 클라이언트[102(n)]에 의해 수신된 메시지를 처리하는 데 이용될 수 있다. SSSL[118(n)]은 송신자 신분을 검증하는 데 이용될 수 있는 복수의 식별 메커니즘[210(x)]을 참조하며, 여기서 "x"는 1부터 "X"까지 중 임의의 정수일 수 있다. 일 구현에서, SSSL[118(n)]은 (만약 있다면) SSSL[118(n)]의 엔트리(예를 들어, 식별 메커니즘, 식별 메커니즘의 조합 등)들 중 어느 것이 메시지에 의해 만족되는지에 기초하여 하나 이상의 식별 메커니즘[210(x)] 및 SSSL 상의 액션을 조합한다. 그러므로, 사용자가 메시지를 수신할 때, 커뮤니케이션 모듈[106(n)] 및/또는 관리자 모듈[116(n)]은 하나 이상의 응용가능한 식별 메커니즘[210(n)]들을 이용하여 메시지를 모으고 검증한다. 예를 들어, 식별 메커니즘[210(m)]은 메시지의 부분이 특정한 비밀 키로 서명되어 있는지를 체크하는 것에 관한 것일 수 있으며, 여기서 메시지는 지정된 도메인에 대해서 송신자 신분을 통해 승인된 기기로부터 송신된 것이다. 다양한 식별 메커니즘[210(x)] 및 그들의 조합이 SSSL[118(n)]에 채용될 수 있으며, 이에 대한 예가 다음에 설명된다.

이메일 주소[210(1)]

이메일 주소[210(1)]는 안전한 송신자 리스트 상에서 이용되는 표준 신분 형태이며, 이에 따라 SSSL[118(n)]은 상속되는 안전한 송신자 리스트(legacy safe sender list)를 지원하고 그것 상에 구축될 수 있다. 이메일 주소[210(1)]는 메시지의 헤더 내의 'FROM' 라인을 살펴봄으로써 체크될 수 있다. 전술된 바와 같이 이메일 주소[210(1)]가 특히 공격에 취약할 수 있지만, 이메일 주소[210(1)]와 또 다른 하나의 식별 메커니즘[210(x)]의 조합은 견고한 보호를 생성할 수 있다.

제삼자 증명서[210(2)]

제삼자 증명서[210(2)]는 제삼 증명자를 추적할 수 있는 증명서로 메시지의 일부분에 서명하는 것에 관한 것일 수 있다. 이 서명은, 예를 들어 서명을 포함하는 헤더를 메시지에 포함시키는 안전한/다목적 인터넷 메일 확장(S/MIME) 기술을 통하는 것과 같은 다양한 기술을 이용하여 첨부될 수 있다. 이 예에서, SSSL[118(n)]은 또한 메시지의 인증을 더욱 검증하기 위해 검증될 수 있는 제삼 증명자의 신분을 포함할 수도 있다. 이 기술에 의해 제공되는 보안의 레벨은 또한 제삼 증명자의 명성, 증명서 유형(예를 들어, 몇몇 증명자들은 몇몇 레벨의 점차적으로 안전한 증명서를 제공함), 및 서명된 메시지의 양(더 많은 메시지를 서명하는 것이 아마 보다 더 안전함)에 기초할 수 있다. 그러므로, SSSL[210(x)] 상에서 이 유형의 식별 메커니즘에 기초하여 수행되는 액션은 이러한 정보 조각에 기초하여 선택될 수 있다. 예를 들어, 액션(예를 들어, 보증 커뮤니케이션)은 특정한 제삼 증명자에 의해 서명된 메시지들 상에서 수행될 수 있지만, 다른 제삼 증명자에 의해 서명된 메시지들은 메시지가 믿을 수 있는 소스로부터의 것인지, 스팸인지 등을 판정하기 위해 더욱 처리될 수 있다.

자가 서명된 증명서[210(3)]

자가 서명된 증명서는 송신자가 생성한 증명서로 메시지의 일부분에 서명하는 것에 관련된 것이다. 제삼자 증명서[210(2)]와 같이, 이 식별 메커니즘은, 예를 들어 메시지 내에 서명을 포함하는 헤더를 포함시키는 S/MIME 기술을 통하는 것과 같은 다양한 기술을 이용하여 첨부될 수 있다. 일 구현에서, 자가 서명된 증명서의 이용은 송신자가 공개/비밀 키 쌍을 생성하는 것, 비밀키로 메시지의 부분에 서명하는 것, 메시지 내에 (또는 다른 표준 방법들을 통해) 공개 키를 분배하는 것에 관련된 것이다. 이 방법에 의해 제공되는 보안 레벨은 서명된 메시지의 양에 기초하며, 이에 따라 SSSL 상의 이 신분 유형에 관련된 액션은 전술된 바와 같이 이 정보에 기초하여 또한 선택될 수 있다.

패스코드[210(4)]

패스코드[210(4)] 식별 메커니즘은 연관된 비밀 키로 메시지의 임의의 일부분에 서명하지는 않지만 메시지 내에 공개 키를 포함시키는 것에 의한 것과 같이 메시지 내에서의 패스코드의 이용에 관련된다. 이 식별 메커니즘은 전송시에 메시지를 수정하고 서명이 검증되지 않도록 서명의 암호 속성을 파괴하는 메일 전송 에이전트(mail transfer agent)를 가진 사용자에게 유용할 수 있다. 이 식별 메커니즘은 신분 형태를 구축하기 위한 가벼운 방식으로서 유용하다. 패스코드[210(4)]가 여전히 잠재적으로 스푸프가능하지만, 패스코드[210(4)]는 다른 식별 메커니즘과 함께 이용되어, 검증(즉, 송신자 신분의 인증)의 향상된 우도를 제공한다. 일 구현에서, 패스코드[210(4)]가 단독으로 이용되면, 연관된 액션은 필터 모듈[212(n)]에 대한 힌트로서 구성될 수 있다.

예를 들어, 필터 모듈[212(n)]은 메시지 내의 텍스트 및 텍스트 패턴을 살펴보는 것과 같은 것으로 메시지가 스팸인지를 판정하기 위해 메시지를 필터링하도록 실행될 수 있는 복수의 스팸 필터들을 채용할 수 있다. 식별 메커니즘[210(x)][예를 들어, 패스코드(210(4))]은 송신자의 신분을 검증하기 위해 이용될 수 있으며, 검증이 성공적이면, 메시지의 향후 처리를 위해 필터 모듈[212(n)]에 힌트를 제공한다. 그러므로, SSSL[118(n)]은 다양한 새로운 및/또는 기존 필터들을 이용하여, 추가적인 스팸 필터링 기능을 제공할 수 있다. 클라이언트[102(n)] 상에서의 스팸 모듈[212(n)]의 실행이 설명되었지만, 서버[110(m)]는 유사한 기능을 제공하도록 실행될 수 있는 것으로 예시된 필터 모듈[212(m)]을 채용할 수도 있다.

계산적 증명[computational proof, 210(5)]

계산적 증명 식별 메커니즘은 메시지에 계산적 증명을 첨부하는 것에 관련된다. 예를 들어, 송신자는 메시지 상의 소정 레벨에 이미 해결된 계산을 첨부할 수 있다. 전술된 바와 같이 요청된 양의 계산은 이 식별 메커니즘을 따라 액션을 선택하는 것에 대한 기초로 동작할 수 있다.

IP 주소[210(6)]

IP 주소[210(6)] 식별 메커니즘은 메시지가 특정한 IP 주소 또는 IP 주소 범위(예를 들어, IP/24 범위 204.200.100.*)로부터 송신된 것인지를 검증하는 것에 관련된다. 일 구현에서, 이 식별 방법은 IP 주소/범위가 메시지의 "수신된" 헤더 라인들 중 임의의 것에 나타날 수 있는 덜 안전한 모드를 지원할 수 있다. 전술된 바와 같이, IP 주소 또는 범위가 메시지 내에 위치될 수 있는 경우에, 특정한 IP 주소, IP 주소 범위는 어느 액션이 메시지에 대해서 수행되어야 하는지를 선택하기 위한 기초로 이용될 수 있다.

유효한 송신자 ID[210(7)]

유효한 송신자 ID[210(7)] 식별 메커니즘은, 메시지가 송신자 ID를 통해 특정한 도메인에 대해서 메시지들을 송신하도록 인증된 컴퓨터로부터 송신된 것인지를 검증하는 것에 관련된다. 예를 들어, 이 시나리오에 대한 SSSL[118(n)] 엔트리는 믿을 수 있는 도메인에의 참조를 포함할 수 있다. 예를 들어, "test@test.com"은 주소이며, "test.com"은 도메인이다. 도메인은 정확하게 매치될 필요는 없으며, 예를 들어, 도메인은 foo.test.com처럼 포매팅될 수도 있다는 것을 유념해야 한다. 이 주소로부터 메시지가 수신되면, 커뮤니케이션 모듈[106(n)]은 "test.com" 도메인에 대해서 송신자 ID 테스트를 수행할 수 있으며, 메시지가 엔트리에 매치하면, 그것은 유효한 것이다. 이 식별 메커니즘은 또한 클라이언트의 IP 주소를 탐지하는 것에 대한 알고리즘, 에지 서버(edge server)로부터의 IP 주소를 커뮤니케이션하는 것에 대한 임의의 근사 표준, 에지 서버로부터의 송신자 ID 체크 결과를 커뮤니케이션하는 것에 대한 표준 등에 영향을 줄 수 있다. 이외에, 송신자 ID 테스트는 임의의 특정한 송신자 식별 기술 또는 프레임워크[예를 들어, 송신자 정책 프레임워크(SPF), 마이크로소프트사(마이크로소프트는 워싱턴주 레드몬드시의 마이크로소프트 코포레이션의 상표임)의 송신자 ID 프레임워크 등]에 제한되지는 않지만, 사용자 또는 도메인을 인증하는 임의의 메커니즘을 포함할 수 있다는 것을 인식해야 한다.

금전적 첨부물[210(8)]

금전적 첨부물[210(8)] 식별 메커니즘은 송신할 메시지에 "전자우표(e-stamp)"와 같은 것을 의미할 수 있는 금전적 가치(monetary amount)를 포함시키는 것에 관련된다. 예를 들어, 메시지의 송신자는 수신자가 부담하는 금전적 가치를 메시지에 첨부할 수 있다. 최소한의 금전적 가치를 첨부하는 것만으로도, 스패머가 다량의 이러한 메시지들을 송신할 우도를 줄일 수 있으며, 이에 따라 송신자가 스패머가 아닐 확률이 증가한다. 또한 메시지 증명을 책임지고 있는 인터넷 상의 중앙 정보교환소를 통한 것과 같은 다양한 다른 기술들이 금전적 첨부물[210(8)]에 대해 채용될 수 있다. 그러므로, 메시지에 포함된 증명서는 송신자가 메시지를 송신하기 위해 거금을 지불하는 증명 형태로 동작할 수 있다. 다양한 식별 메커니즘[210(1)-210(8)]이 설명되었지만, 다양한 다른 식별 메커니즘[210(X)]들도 본 발명의 취지 및 영역을 벗어나지 않으면서 채용될 수 있다.

전술된 바와 같이, SSSL[118(n)]은 하나 이상의 어느 식별 메커니즘[210(x)]이 메시지에 의해 만족되는지에 기초하여 취해지는 액션 및 식별 메커니즘[210(x)]을 참조할 수 있다. 예를 들어, 커뮤니케이션 모듈[106(n)]은 메시지로부터의 데이터를 식별 메커니즘[210(x)]들과 비교하고, 임의의 연관된 액션이 수행될지를 판정할 수 있다. 그 후 보증된 전달을 이뤄낼 수 있는 이러한 액션이 행해지며, 메시지는 메시지가 스팸이 아니라는 힌트와 함께 필터 모듈[214(n)]에 커뮤니케이션된다. 다양한 다른 액션들도 또한 취해질 수 있으며, 그 예들이 다음에 설명된다.

메시지가 SSSL[118(n)] 내의 엔트리에 따를 때, 예를 들어, 연관된 액션이 취해진다. 예를 들어, SSSL[118(n)] 내의 참조된 하나의 이러한 액션은 메시지가 다른 필터링 없이 사용자의 인박스에 커뮤니케이션되어야 한다는 것을 지정할 수 있다. 이에 따라, 이 예에서, 필터 모듈[212(n)]은 보장 커뮤니케이션을 우회하게 된다.

또 다른 예에서, 메시지는 필터 모듈[212(n)]에 의해 더욱 필터링될 수 있지만, 필터링에 응답하여 필터 모듈[212(n)]에 의해 수행될 수 있는 액션은 제한된다. 이 방식에서, SSSL은 필터 모듈[214(n)]이 메시지에 대해서 수행할 수 있는 액션들을 "제한(bound)"하는 데 이용될 수 있다. 예를 들어, 필터 모듈[212(n)]에 의한 메시지 프로세싱의 결과에 상관없이, SSSL[118(n)] 엔트리는 특정한 식별 메커니즘[210(x)]을 만족하는 메시지가 삭제되지 않아야 한다는 것을 지정할 수 있다. 이러한 예에서, 필터 모듈[214(n)]에 의해 수행될 수 있는 액션들에는 메시지를 검역하는 것, 메시지를 스팸 필터로 라우팅하는 것 등이 포함된다.

다른 예에서, 액션은 필터 모듈[212(n)]에의 "힌트"로서 구성될 수 있다. 예를 들어, 필터 모듈[212(n)]에 의해 처리될 때, 힌트의 형태 및 크기는 메시지가 "스팸"으로 고려될 확률을 증가 또는 감소시키는 데 이용될 수 있다. 예를 들어, 힌트는 선형 모델을 이용하여 확률 계산에 추가하기 위한 가중치, 메시지에 할당된 확률의 절대 감소값(absolute reduction), 필터링 임계치의 수정(예를 들어, 덜 공격적이 되도록), 결정 프로세스에 포함되는 추가적인 특성 등의 형태를 취할 수 있다.

일 구현에서, 각각의 식별 메커니즘[210(x)][또는 식별 메커니즘(210(x))들의 조합]은 SSSL[118(n)] 내에 디폴트 액션을 가질 것이다. 예를 들어, 사용자가 자가 서명된 증명서[212(3)]를 참조하는 SSSL[118(n)]에 엔트리를 추가하면, 커뮤니케이션 모듈[106(n)]은 식별 메커니즘[210(x)]의 현재 보안에 대해 이해를 반영하는 액션을 제안할 수 있다. 시간이 지나면서, 증명된 메일과 SSSL이 보다 널리 보급되고 이메일 및 다른 유형의 메시징에 중요해질수록, 공격자는 SSSL를 공격하도록 더욱 동기 부여될 수 있다. 이런 일이 일어날수록, 다양한 식별 메커니즘[210(x)]에 대한 디폴트 액션은 이메일 공급자가 획득하는 피드백(feedback)에 기초하는 것 등에 의해 수정될 수 있다. 디폴트 액션은 사용자에 의해 수동적으로, 기기 학습을 이용하여 다양한 방식으로 선택될 수 있으며, 안티 스팸 웹 서비스 등을 통해 소프트웨어 갱신을 통해 분배될 수 있다.

액션은 또한 식별 메커니즘[210(x)]에 의해 제공되는 다양한 확실도(degree of certainty)를 처리하는 계층구조를 구현하도록 구성될 수 있다. 예를 들어, 관리자 모듈[116(m)]은 메시지에 의해 만족되는 식별 메커니즘에 기초하여 복수의 폴더[214(1),...,214(y),...,214(Y)] 중 하나 내에 도 1의 메시지[114(h)]를 저장하도록 서버[110(m)] 상에서 실행될 수 있다. 복수의 폴더[214(1)-214(Y)]는 식별 메커니즘이 메시지 송신자의 실제 신분을 나타낼 각각의 우도를 나타내는 "확률이 높음"에서부터 "확률이 낮음"까지의 계층구조(216)를 형성하는 것으로 예시된다. 예를 들어, 관리자 모듈[116(m)]은 전술된 식별 메커니즘[210(1)-210(8)] 각각을 만족하는 제1 메시지를 수신할 수 있다. 이에 따라, 이러한 메시지는 메시지 송신자의 신분을 올바르게 식별할 확률이 매우 높으므로, 이에 따라 사용자의 인박스로 구성될 수 있는 "확률이 높음" 폴더[214(1)]로 라우팅된다. 그러나, 또 다른 메시지는 식별 메커니즘[210(1)-210(8)] 중 어느 것도 만족시키지 못할 수 있으므로, 이에 따라 "스팸" 폴더로 구성될 수 있는 "확률이 낮음" 폴더[214(Y)]로 라우팅된다. 다른 메시지는 이메일 주소[210(1)]와 자가 서명된 증명서[210(3)] 식별 메커니즘을 만족할 수 있다. 이러한 메시지는 이메일 구현에서 "검역(quarantine)" 폴더로 구성될 수 있는 "중간매체" 폴더[214(y)]로 라우팅될 수 있다. 다양한 다른 계층구조적 식별 메커니즘 및 대응하는 액션들도 채용될 수 있으며, 이에 대한 다른 설명들이 도 3에 관련하여 더욱 인식될 수 있다.

클라이언트[102(n)] 상에서의 SSSL[118(n)]의 이용이 후술될 것이지만, SSSL[118(n)]과 SSSL[118(k)]은 클라이언트[102(n)]와 서버[110(m)] 상에서 각각 유사하게 동작하도록 구성될 수 있다. 그러나, SSSL[118(n), 118(k)]이 어떻게 저장되는지는 다를 수 있다. 예를 들어, 클라이언트[102(n)] 상의 SSSL[118(n)]은 분리된 파일 내의 레지스트리(registry) 내에 이진 포맷 등으로 저장될 수 있다. (다음의 설명에서 보다 상세하게 설명될) 증명서는 SSSL에 저장될 수 있으며, 운영 시스템의 "증명서 저장소"(예를 들어, "my Certificates") 등에 안전하게 저장될 수 있다. 예를 들어, 증명서의 저장 및 관리는 구성 애플리케이션 프로그래밍 인터페이스(CAPI)에 의해 수행될 수 있다. 증명서에의 참조/색인은 레지스트리/파일 내의 SSSL 내에 송신자의 이메일 주소에 따라 저장된다. 서버에 대해서, SSSL은 클라이언트[102(n)]에 대한 개별 계정 정보(per-account information)의 부분으로 서버[110(m)] 상에 저장될 수 있다.

예시적인 절차

다음은 전술된 시스템 및 장치를 이용하여 구현될 수 있는 SSSL 기술을 설명한다. 각 절차의 양태는 하드웨어, 펌웨어, 소프트웨어, 또는 이들의 조합으로 구현될 수 있다. 절차는 하나 이상의 장치들에 의해 수행되는 동작들을 나타내는 블럭들의 세트로 나타나있지만, 각각의 블럭에 의한 동작을 수행하도록 나타낸 순서에 제한될 필요는 없다. 다음의 예시적인 절차들은 본 발명의 취지 및 영역을 벗어나지 않고 다양한 다른 환경들 내에 구현될 수 있다는 것도 명심해야 한다.

도 3은 예시적인 구현에서 이메일로 구성된 메시지가 복수의 식별 메커니즘을 이용하여 처리되는 절차(300)를 나타내는 흐름도이다. 클라이언트[102(n)]는 네트워크(104)를 통해 또 다른 클라이언트[102(1)]로부터 이메일(302)을 수신한다. 예를 들어, 클라이언트[102(1)]는 이메일을 네트워크(104)를 통해 도 1의 서버[110(m)]로 커뮤니케이션할 수 있다. 그 후 이메일(302)은 커뮤니케이션 모듈[106(n)]의 실행을 통해 클라이언트[102(n)]에 의해 검색될 수 있다.

커뮤니케이션 모듈[106(n)]은, 클라이언트[102(n)] 상에서 실행될 때, 이메일(302)을 검증하기 위해 어느 식별 메커니즘(만약 있다면)이 채용되는지를 탐지한다. 예를 들어, 커뮤니케이션 모듈[106(n)]은, 도 2의 복수의 식별 메커니즘[210(1)-210(X)]들 중 임의의 것이 송신자 신분을 검증하는 데 이용될 수 있는지를 판정하기 위해, 이메일(302)을 검사할 수 있다. 예를 들어, 커뮤니케이션 모듈[106(n)]은, 이메일(302)이 송신된 이메일 주소(308)를 판정하기 위해 이메일(302) 내의 헤더 정보를 검사할 수 있다. 커뮤니케이션 모듈[106(n)]은 또한 제삼자 증명서(310)를 배치하기 위해 이메일(302)을 검사할 수 있다.

그 후 커뮤니케이션 모듈[106(n)]은 탐지한 식별 메커니즘[210(x)]을 이용하여 이메일(302)을 검증하고 SSSL[118(n)]로부터 적절한 액션을 판정하도록 실행된다[블럭(312)]. 예를 들어, 커뮤니케이션 모듈[106(n)]은 도 1의 증명서 공급자[114(1)]를 질의하여, 제삼자 증명서(310)가 유효한지를 판정한다. 검증이 성공적으로 수행되면(예를 들어, 제삼자 증명서가 유효하다고 검증되면), 그 후 커뮤니케이션 모듈[106(n)]은 SSSL[118(n)]로부터 어느 액션이 이메일(302) 상에서 수행되어야 하는지를 판정할 수 있다. 예를 들어, SSSL[118(n)]은 식별 메커니즘[210(x)]과 대응하는 액션들의 조합을 참조하는 복수의 엔트리를 가질 수 있다. 그러므로, 커뮤니케이션 모듈[106(n)]은 SSSL[118(n)]을 검사함으로써, 이메일(302)이 지정된 이메일 주소(308) 및 검증된 제삼자 증명서(310)를 갖는다고 검증될 때 어느 액션이 수행되어야 하는지를 판정할 수 있다. SSSL[118(n)]은 또한 하나 이상의 식별 메커니즘[210(x)]이 실패할 때 수행되어야 하는 액션들도 참조할 수 있다. 예를 들어, 제삼자 증명서(310)를 위조하는, 도 1의 증명서 공급자[114(1)]의 이용불가능성과 같이, 이메일(302)에 포함된 제삼자 증명서(310)는 검증되지 못할 수 있다.

이러한 액션의 일 예는 검증에 기초하여 이메일(302)을 라우팅하는 것이다[블럭(314)]. 예를 들어, 클라이언트[102(n)]는 복수의 폴더[316(1),...,316(a),...,316(A)]를 포함할 수 있다. 이 예에서, 복수의 폴더[316(1), 316(A)] 각각은 이메일(302)이 나타내는 송신자가 송신한 것이라는 확실성의 계층구조적 레벨에 대응하도록 구성되며, 이 계층구조적 레벨은 가장 확실하지 않음[예를 들어, 폴더(316(A))]으로부터 가장 확실함[예를 들어, 폴더(316(1))]으로 진행된다. 그러므로, SSSL[118(n)]에 포함된 이메일 주소(308) 및 검증된 제삼자 증명서(310)를 갖는 이메일(302)은 송신자가 유효하다는 것(즉, 그들이 말하는 자들이 그들임)에 대한 매우 높은 확실성을 제공할 수 있으며, 따라서 클라이언트의 인박스와 같은 폴더[316(1)]에 라우팅된다. 한편, 제삼자 증명서(310)의 검증은 실패하지만 이메일 주소(308)는 SSSL[118(n)] 내의 이메일 주소와 매치하면, 이메일(302)은 검역 폴더와 같은 중간매체 폴더[316(a)]에 라우팅될 수 있다. 다양한 다른 라우팅 기술 및 다른 액션들이 필터 모듈[212(n)]에 검증 결과에 관한 "힌트"를 포함하고 향후 프로세싱을 위해 도 2의 필터 모듈[212(n)]에 라우팅하는 것과 같이 이메일(302)의 검증 결과에 기초하여 수행될 수 있으며, 다음의 설명은 도면들에 관련하여 더욱 인식될 수 있다.

도 4는 예시적인 구현에서 메시지가 복수의 식별 메커니즘들을 이용하여 처리하고 그 결과가 메시지의 향후 프로세싱을 위해 필터 모듈에 커뮤니케이션되는 절차(400)를 나타내는 흐름도이다. 메시지는 네트워크를 통해 수신된다[블럭(402)]. 제1 예에서, 메시지는 인터넷을 통해 커뮤니케이션된 이메일 메시지이다. 또 다른 예에서, 메시지는 인스턴트 메시지이다.

전술된 바와 같이, 커뮤니케이션 모듈은 복수의 식별 메커니즘들 중 어느 것이 메시지를 검증하는 데 이용될 수 있는지를 탐지하도록 실행된다[블럭(404)]. 예를 들어, 메시지는 그것이 송신자의 주소(예를 들어, 이메일 주소), 제삼자 증명서, 자가 서명된 증명서, 패스코드, 계산적 증명, IP 주소, 송신자 신분, 금전적 첨부물 등을 포함하는지를 판정하도록 검사될 수 있다. 그 후 커뮤니케이션 모듈은 하나 이상의 탐지된 메커니즘을 이용하여 메시지를 검증한다[블럭(406)]. 예를 들어, 커뮤니케이션 모듈은 메시지가 송신자의 주소를 포함하는지를 판정한 후, 송신자의 주소가 SSSL에 포함되어 있는지를 검증할 수 있다. 그 후 커뮤니케이션 모듈은 또 다른 식별 메커니즘이 이용가능한지를 판정하고[결정 블럭(408)], 이용가능하면, 탐지된 식별 메커니즘을 이용하여 메시지를 검증할 수 있다[블럭(406)]. 상기 예에 계속하여, 커뮤니케이션 모듈은 메시지가 계산적 증명의 결과를 포함한다고 판정하고 그 후 결과가 올바른지를 검증할 수 있다.

일단 더 이상 이용가능한 식별 메커니즘이 없으면[결정 블럭(408)], 검증 결과 및 메시지 모두는 향후 프로세싱을 위해 필터 모듈에 커뮤니케이션된다[블럭(410)]. 예를 들어, 결과는 메시지를 처리할 때 필터 모듈을 고려하여 어느 식별 메커니즘이 이용됐는지를 나타낼 수 있다. 또 다른 예에서, 결과는 메시지가 믿을 수 있는 송신자로부터 송신되었다는 것에 대한 상대적인 우도를 나타내는 값일 수 있다. 예를 들어, 값은 송신자가 스패머가 아닐 것에 대한 우도 점수로 구성될 수 있다.

그 후 필터 모듈은 전술된 바와 같이 복수의 필터 및 결과들을 이용하여 메시지를 처리할 수 있다[단계(412)]. 예를 들어, 결과는 선형 모델을 이용하여 확률 계산에 추가하기 위한 가중치, 메시지에 할당된 확률의 절대 감소값, 필터링 임계치의 수정(예를 들어, 덜 공격적이 되도록), 결정 프로세스에 포함되는 추가적인 특성 등의, 향후 프로세싱을 위해 하나 이상의 스팸 필터와 함께 이용할 필터 모듈에의 "힌트"로 동작할 수 있다. 그러므로, SSSL은 메시지를 처리하기 위해 다른 스팸 필터에 채용될 수 있다.

도 5는 예시적인 구현에서 보안상 안전한 송신자 리스트가 파퓰레이트되는 절차(500)를 나타내는 흐름도이다. 일 구현에서, SSSL 리스트에 엔트리를 추가하는 것은 종래의 안전한 송신자 리스트에 엔트리를 추가하는 것보다 약간 더 복잡한데, 이는 하나 이상의 식별 메커니즘 및 액션이 지정되기 때문이다. 예를 들어, 도 4의 절차(400)를 통한 것과 같이 커뮤니케이션 모듈은 복수의 식별 메커니즘을 이용하는 메시지를 처리할 수 있다[블럭(502)]. 다음으로, 메시지의 향후 프로세싱을 위해 복수의 식별 메커니즘 중 어느 것이 SSSL에 포함되어야 하는지가 판정된다[블럭(504)]. 커뮤니케이션 모듈이 엔티티가 추가되어야 한다는 것 등을 제안했기 때문에, 사용자가 엔티티를 추가해야 한다고 명시적으로 나타내는 것에 응답하는 것과 같이, 새로운 엔티티를 SSSL에 추가하기 위해 채용될 수 있는 다양한 모드가 존재한다.

"사용자 유도" 모드에서, 예를 들어, 선택할 식별 메커니즘들의 리스트가 사용자에게 나타내진다[블럭(506)]. 일 구현에서, 사용자에의 식별 메커니즘들 출력은 메시지 내에 나타내지는 것들이다. 예를 들어, 커뮤니케이션 모듈은 복수의 식별 메커니즘[210(x)]들 중 어느 것이 메시지에 의해 만족되는지를, 메뉴 내에 단지 그러한 만족되는 식별 메커니즘들을 포함시키거나 강조하는 것 등에 의해 나타낼 수 있다. 그 후 사용자는, 사용자가 메일 전송 에이전트(MTA)가 때로 서명을 파괴했을 경우 자가 서명된 증명서를 포함하지 않기와 같은, SSSL에 추가될 메소드를 선택할 수 있다.

"소프트웨어 유도" 모드에서, 커뮤니케이션 모듈은 안전하다고 생각되는 메시지에 의해 만족되는 각각의 식별 메커니즘을 선택하도록 실행된다[블럭(508)]. 예를 들어, 전술된 바와 같이, 커뮤니케이션 모듈은 도 2의 복수의 식별 메커니즘[210(x)] 중 어느 것이 안전한지를 나타내는 구성 파일을 포함할 수 있다. 구성 파일은 사용자에 의해 구성되는 안티 스팸 웹 서비스, 소프트웨어 갱신 등을 통해 수정될 수 있다.

"가장 안전한" 모드에서, 커뮤니케이션 모듈은 송신자의 신분을 검증하기 위한 "가장 안전한" 식별 메커니즘(또는 그들의 조합)을 선택하도록 실행된다[블럭(510)]. 식별 메커니즘의 상대적 보안은 구성 파일에 포함될 수 있으며, 사용자 구성에 의해 안티 스팸 웹 서비스, 소프트웨어 갱신 등을 통해 수정될 수 있다.

그 후 선택된 식별 메커니즘(들) 및 대응하는 액션은 SSSL에 추가된다[블럭(512)]. 이에 따라, 또 다른 이메일도 SSSL에 나타날 때, 식별된 선택 메커니즘 및 대응하는 액션을 이용하여 처리될 수 있다[블럭(514)]. 일 구현에서, 새로운 엔트리가 SSSL에 만들어지면, 보다 덜 안전한 식별 메커니즘을 갖는 특정한 송신자에 대한 엔트리가 존재하는지에 대해서 사용자를 프롬프팅하는 것처럼, 커뮤니케이션 모듈은 임의의 덜 안전한 엔트리가 있는지를 체크하고 이러한 엔트리를 제거하도록 실행된다.

또 다른 구현에서, 커뮤니케이션 모듈은 사용자를 SSSL에 추가할 때 다양한 추가적인 고려사항(즉, 사용자의 주소 및 또 다른 식별 메커니즘)들을 이용할 수 있다. 예를 들어, 사용자가 특정한 송신자로부터 하나 이상의 메시지를 수신 및 판독했으면, 커뮤니케이션 모듈은 송신자를 추가할 수 있다. 이것을 제안하는 기준은 전술된 식별 메커니즘의 존재에 영향을 받을 수도 있다. 예를 들어, 제삼자 증명서의 존재는 송신자로부터의 메시지가 판독되는지를 두 번 프롬프팅할 수 있는 반면, 동반되는 계산적 증명을 갖는 메시지는 사용자가 송신자를 SSSL에 추가하는 것을 즉각적으로 제안할 수 있다. 일반적으로, SSSL에 송신자를 제안하는 데 이용되는 기준은 (또는 자동으로 추가됨) 전술된 식별 메커니즘의 임의의 것의 존재 또는 없음에 따라 좀 더 용이하거나 엄격해질 수 있다.

결론

본 발명이 구조적 특징 및/또는 방법론적 활동에 특정적인 언어로 설명되었지만, 본 발명은 설명된 특정한 특징 및 활동에 제한될 필요는 없으며 첨부된 청구항으로 정의됨을 이해해야 한다. 오히려, 특정한 특징 및 활동은 주장된 본 발명을 구현하는 예시적인 구현으로서 공개된다.

Claims (13)

1. 식별 메커니즘들 중 어느 것이 송신자의 신분을 검증하는데 이용가능한지를 판정하기 위하여 네트워크를 통해 상기 송신자로부터 수신된 메시지를 검사하는 단계;
   하나 이상의 이용가능한 식별 메커니즘들이 상기 신분을 검증하는 데 충분하다고 여겨지는지를 판정하는 단계;
   하나 이상의 이용가능한 식별 메커니즘들이 상기 신분을 검증하는 데 충분하다고 여겨지는 것으로 판정한 것에 응답하여, 상기 신분의 기재(description) 및 상기 하나 이상의 이용가능한 식별 메커니즘들과 이메일 주소의 기재를 안전한 송신자 리스트에 추가하는 단계;
   상기 메시지에 할당된 확률 계산에 절대 감소값(absolute reduction)을 추가하기 위한 가중치 형태를 택함으로써 상기 메시지를 필터링하는 단계;
   상기 메시지가 스팸으로 고려될 확률을 증가시키거나 감소시킴으로써 상기 필터링의 형태 및 크기에 기초하여 상기 메시지의 상기 필터링을 프로세싱하는 단계;
   이용가능한 식별 메커니즘과 상기 이메일 주소의 조합을 포함하는 상기 안전한 송신자 리스트에 액세스하는 단계 - 상기 이용가능한 식별 메커니즘은 제삼자 증명서를 포함함 - ; 및
   상기 제삼자 증명서로 서명된, 상기 이메일 주소의 조합으로부터의 상기 메시지를 검증하는 단계 - 검증되면, 상기 메시지는 인박스로 라우팅됨 -
   을 포함하며,
   상기 이용가능한 식별 메커니즘들은, 리스트 내에서 식별되는 상기 하나 이상의 식별 메커니즘들과의 비교를 통해 충분하다고 여겨지고, 상기 하나 이상의 이용 가능한 식별 메커니즘들은 상기 송신자의 주소를 활용하지 않고 상기 송신자의 신분을 확인하고(confirm),
   상기 리스트는 상기 하나 이상의 식별 메커니즘들 및 또 다른 식별 메커니즘의 조합을 참조하는, 방법.
   
2. 제1항에 있어서,
   상기 추가하는 단계는 사용자에게 사용자 인터페이스를 통해 상기 기재들을 추가하도록 프롬프팅(prompting)하는 단계를 포함하는, 방법.
   
3. 제1항에 있어서,
   상기 추가하는 단계는 자동으로 그리고 사용자 개입 없이 수행되는, 방법.
   
4. 제1항에 있어서,
   하나의 상기 식별 메커니즘은 그것만으로는 상기 송신자의 신분을 검증하기에 충분하다고 여겨지지 않고,
   자가 서명된 증명서(self-signed certificate);
   패스코드(passcode);
   수학적 증명(mathematical proof)의 결과; 및
   상기 메시지에 첨부된 금전적 가치(monetary amount)
   중 적어도 하나를 포함하는 또 다른 이용가능한 식별 메커니즘을 식별하는, 방법.
   
5. 제1항에 있어서,
   상기 제삼자 증명서는 제삼 증명자(a third-party certifier)에게로 추적되는 증명서를 이용한 상기 메시지의 일부에 대한 서명을 포함하고, 상기 방법은,
   서명을 포함하는 헤더를 상기 메시지 내에 포함함으로써 상기 메시지에 상기 서명을 첨부하는 단계; 및
   상기 제삼 증명자의 명성, 증명서 유형, 또는 상기 서명된 메시지의 양 중 적어도 하나를 포함하는 상기 제삼자 증명서에 대한 보안 레벨을 판정하는 단계
   를 더 포함하는 방법.
   
6. 제1항에 있어서,
   상기 추가하는 단계는 상기 하나 이상의 이용가능한 식별 메커니즘을 만족시키는 메시지 상에서 수행될 액션을 추가하는 단계를 더 포함하는 방법.
   
7. 식별 메커니즘들 중 어느 것이 송신자의 신분을 검증하는데 이용가능한지를 판정하기 위하여 네트워크를 통해 상기 송신자로부터 수신된 메시지를 검사하는 단계;
   하나 이상의 이용가능한 식별 메커니즘들이 상기 신분을 검증하는 데 충분하다고 여겨지는지를 판정하는 단계;
   하나 이상의 이용가능한 식별 메커니즘들이 상기 신분을 검증하는 데 충분하다고 여겨지는 것으로 판정한 것에 응답하여, 상기 신분의 기재(description) 및 상기 하나 이상의 이용가능한 식별 메커니즘들과 이메일 주소의 기재(description)를 안전한 송신자 리스트에 추가하는 단계 - 상기 이용가능한 식별 메커니즘들은, 리스트 내에서 식별된 상기 하나 이상의 식별 메커니즘들과의 비교를 통해 충분하다고 여겨지며, 상기 하나 이상의 이용가능한 식별 메커니즘들은 상기 송신자의 주소를 활용하지 않고 상기 송신자의 신분을 확인(confirm)하며, 상기 리스트는 상기 하나 이상의 식별 메커니즘들 및 또 다른 식별 메커니즘의 조합을 참조함 - ;
   상기 메시지의 상기 송신자의 신분을 검증하는 단계;
   하나 이상의 스팸 필터들을 활용하는 프로세싱을 위한 필터 모듈로 상기 검증의 결과 및 상기 메시지를 전달하는 단계;
   절대 감소값(absolute reduction)을 상기 메시지에 할당된 확률 계산에 추가하기 위한 가중치의 형태를 택함으로써 상기 메시지를 필터링하는 단계;
   상기 메시지가 스팸으로 고려될 확률을 증가시키거나 감소시킴으로써 상기 필터링의 형태 및 크기에 기초하여 상기 메시지의 상기 필터링을 프로세싱하는 단계;
   제삼자 증명서를 포함하는 안전한 송신자 리스트에 액세스하는 단계; 및
   상기 제삼자 증명서에 기초하여 상기 송신자의 신분을 검증하는 단계 - 검증되면, 상기 메시지는 인박스로 라우팅됨 -
   을 포함하는 방법.
   
8. 제7항에 있어서,
   상기 결과는 상기 메시지를 프로세싱하기 위한 적어도 하나의 상기 필터를 구성하도록 활용되는, 방법.
   
9. 제7항에 있어서,
   상기 결과에 기초하여 상기 필터들의 서브세트를 선택하는 단계; 및
   상기 필터들의 서브세트를 활용하여 상기 메시지를 프로세싱하는 단계
   를 더 포함하는 방법.
   
10. 프로세서 상에서 실행될 때 상기 프로세서가 제7항의 방법을 수행하게 하는 컴퓨터 실행가능 명령어들을 포함하는 착탈식 매체 메모리.
    
11. 메모리;
    상기 메모리에 연결된 프로세서;
    네트워크를 통해 통신되는 메시지의 송신자의 신분을 검증하도록 상기 프로세서 상에서 실행가능한 제1 모듈;
    하나 이상의 스팸 필터들 및 상기 제1 모듈로부터 상기 검증의 결과를 활용하여 상기 메시지를 프로세싱하도록 상기 프로세서 상에서 실행가능한 제2 모듈; 및
    상기 메시지에 할당된 확률 계산에 절대 감소값을 추가하기 위한 가중치의 형태를 택함으로써 상기 메시지를 필터링하도록 상기 프로세서 상에서 실행가능한 필터 모듈
    을 포함하고,
    상기 필터 모듈은 상기 메시지가 스팸으로 고려될 확률을 증가시키거나 감소시킴으로써 상기 필터링의 형태 및 크기에 기초하여 상기 메시지를 필터링하고,
    상기 제1 모듈은 상기 메시지에 포함된 제삼자 증명서에 대해 체크하고, 상기 제삼자 증명서는 제삼 증명자에게로 추적된 증명서를 이용한 상기 메시지의 일부에 대한 서명을 포함하며,
    상기 제1 모듈은 상기 제삼 증명자의 명성, 증명서 유형, 및 서명된 상기 메시지의 양 중 적어도 하나를 포함하는 상기 제삼자 증명서에 대한 보안 레벨을 판정함으로써 상기 송신자의 신분을 검증하고,
    상기 제1 모듈은 상기 송신자의 주소를 활용하지 않고 상기 송신자의 신분을 확인하는데 적절한 복수의 식별 메커니즘들을 활용하고,
    상기 제1 모듈은 복수의 식별 메커니즘 조합을 기술하는 리스트를 이용하며, 상기 복수의 식별 메커니즘 조합은, 만족될 때, 상기 송신자의 신분을 검증하는, 시스템.
    
12. 제11항에 있어서,
    상기 결과는 상기 메시지를 프로세싱하기 위한 적어도 하나의 상기 필터를 구성하도록 활용되는, 시스템.
    
13. 제11항에 있어서,
    상기 시스템은,
    상기 결과에 기초하여 상기 필터의 서브세트를 선택하고,
    상기 필터들의 서브세트를 활용하여 상기 메시지를 프로세싱하는, 시스템.

Images