KR100871581B1

KR100871581B1 - Ｅ-메일 관리 서비스들

Info

Publication number: KR100871581B1
Application number: KR1020047012925A
Authority: KR
Inventors: 스콧 마이클 페트리; 쉰야 액쿼민; 피터 케빈 런드; 프레드 콕스; 마이클 존 오스웰
Original assignee: 포스티니 코포레이션
Priority date: 2002-02-19
Filing date: 2003-02-19
Publication date: 2008-12-02
Also published as: EP2068516B1; JP2005518173A; DE60326938D1; EP1476819A2; US20050182959A1; EP1476819A4; US20070156830A1; AU2003215276A1; WO2003071390B1; EP1476819B1; ATE427608T1; US20050182960A1; US6941348B2; JP4593926B2; US8725889B2; WO2003071390A2; EP2068516A1; KR20040103943A; US20030158905A1; CA2476349A1

Abstract

본 발명은 실시간 루프를 포함하는 전자 메시지 관리 시스템(EMS)을 제공하고, 여기서 데이터는 인입 접속 시도, 아웃고잉 전달 시도, 및 메시지 내용 분석중 전자 메시지로부터 수집되고, 중앙 데이터 매트릭스에 기록된다. 각각의 프로세스는 데이터 매트릭스를 액세스하고 그 데이터의 트랜드를 분석한다. 검출된 데이터 트랜드 또는 행위는 수신인에 대한 구성 파라미터들에 기초한다. 이들 결정에 기초하여, 상기 프로세스는 EMS의 성분들을 허용, 전송, 거절, 변경, 연기, 또는 접속 요구의 배치, 전달 시도, 또는 메시지를 지시할 수 있다. 전자 메시지들의 전송을 관리하기 위한 관련된 방법들은 또한 논의되었다.

트래픽 모니터, 전자 메시지 관리 시스템, 데이터 매트릭스, 접속 관리 모듈

Description

Ｅ-메일 관리 서비스들 {E-MAIL MANAGEMENT SERVICES}

본 출원은, 본 발명과 함께 일반적으로 양도되고 본 명세서의 참조되어 포함되는 2002년 2월 19일 출원된 발명의 명칭이 "이메일 관리 서비스들(e-mail management services)"인 미국 가출원 번호 60/357,893의 권익을 청구한다.

여기에 개시된 실시예들은 이메일 관리 시스템들, 특히 트래픽 모니터링 및 관리를 사용하고, 트래픽 모니터링 및 관리에 기초하여 전자 메시지들을 관리 및 필터링하는 이메일 관리 시스템들(EMSs)에 관한 것이다.

이메일 관리는 일반적으로 이메일 사용자들을 고용한 회사 또는 사용자/가입자들을 가진 ISP들에 의해 조정된다. 이메일 관리의 일부는 스팸의 필터링 또는 바이러스 제어를 포함하지만, 상기 이메일 관리가 ISP 또는 회사 서버 위치에서 수행되는 경우, 소중한 통신 대역폭 및 계산 리소스들이 의사 이메일 트래픽의 다른 조정, 라우팅, 및 분석에 소모된다. 현재 이메일 관리 시스템들은 또한, 실시간 모니터링, 피드백, 및 이메일 트래픽이나 SMTP 접속 상황들에 관한 룰들의 업데이트의 부족을 특징으로 한다. 이메일 트래픽 상황들의 관리 및 모니터링은 일반적으로 사람의 개입을 통하여 조정된다.

스팸 또는 바이러스들을 차단하기 위한 다른 현재 시스템들은, 스팸 컬렉터들(spam collectors)로 동작하는 교란 이메일 주소들을 인터넷 주변에 거주(populate)시키는 시스템들을 포함한다. 사람인 편집자들은 그 후, 수신된 메시지들을 검토하고, 상기 메시지들을 분류하며, 정크 메일 메시지들의 데이터베이스 및 그것의 체크섬들(checksum)을 생성한다. 그 후, 생성된 데이터베이스는 서비스의 가입자들에게 보급되고, 고객 댁내(customer premise)에서 수신된 각각의 메시지는 바이러스/스팸 데이터베이스에 대하여 검사된다. 또한, 상기 예에서, 새로운 바이러스 및 스팸 메시지에 대한 인터넷의 검출 및 모니터링은 실시간이 아니고, 고객 댁내 메일 서버는 모든 의사 이메일들을 여전히 수신하고, 그 후 데이터베이스에 매칭하는지를 보기 위하여 인입 이메일들 모두를 분석한다.

종래 기술의 상기된 결함을 처리하기 위하여, 본 발명의 일측면에서 송신 메일 서버들로부터 수신 메일 서버들로의 전자 메시지들의 전송 관리시 컴퓨터 프로세스에 사용하기 위한 트래픽 모니터를 제공하고, 송신 메일 서버들로부터 송신된 메시지들은 송신 메일 서버들과 연관된 소스 데이터 및 수신 메일 서버들과 연관된 목적지 데이터를 포함한다. 일실시예에서, 트래픽 모니터는 복수의 인입 전자 메시지들에 대한 소스 데이터 및 목적지 데이터를 저장하는 데이터 매트릭스, 및 상기 매트릭스에 결합된 인터페이스를 포함한다. 상기 실시예에서, 인터페이스는, 컴퓨터 프로세스에 의해 제공되고 복수의 전자 메시지들에 기초하는 메타데이터를 소스 데이터 및 목적지 데이터에 보충하는 것을 가능하게 하고, 복수의 전자 메시지들의 처리시 사용하기 위한 소스 데이터, 목적지 데이터 및 메타데이터에 대한 액세스를 가능하게 하도록 구성된다.

다른 측면에서, 본 발명은 송신 메일 서버들로부터 수신 메일 서버들로의 전자 메시지들의 전송 관리시 컴퓨터 프로세스에 사용하기 위한 방법을 제공하고, 송신 메일 서버들로부터 송신된 메시지들은 송신 메일 서버들과 연관된 소스 데이터 및 수신 메일 서버들과 연관된 목적지 데이터를 포함한다. 일실시예에서, 상기 방법은 접속 프로세스를 완료하지 않고 복수의 인입 전자 메시지들에 대한 소스 데이터 및 목적지 데이터를 실시간으로 수집 및 저장하고, 컴퓨터 프로세스에 의해 제공되고 복수의 전자 메시지들에 기초하는 메타데이터를 소스 데이터 및 목적지 데이터에 보충하는 것을 포함한다. 게다가, 상기 방법은 소스 데이터, 목적지 데이터 및 메타데이터에 기초하여 복수의 전자 메시지들을 컴퓨터 프로세스로 분석 및 처리하는 것을 포함한다.

다른 측면에서, 본 발명은 송신 메일 서버들로부터 수신 메일 서버들로의 전자 메시지들의 전송 관리시 사용하기 위한 전자 메시지 관리 시스템(EMS)을 제공하고, 송신 메일 서버들로부터 송신된 메시지들은 송신 메일 서버들과 연관된 소스 데이터 및 수신 메일 서버들과 연관된 목적지 데이터를 포함한다. 일실시예에서, EMS는 복수의 인입 전자 메시지들에 대한 소스 데이터 및 목적지 데이터를 저장하는 데이터 매트릭스를 가진 트래픽 모니터, 및 상기 데이터 매트릭스에 대한 액세스를 가능하게 하기 위한 인터페이스를 포함한다. 또한, EMS는, 인터페이스에 결합되고 복수의 전자 메시지들로부터 외삽된 메타데이터를 소스 데이터 및 목적지 데이터에 보충하도록 구성된 메시지 조정 프로세스를 포함한다. 이 실시예에서, EMS는, 인터페이스에 결합되고, 처리 명령들을 생성하기 위하여 소스 데이터, 목적지 데이터 및 메타데이터에 액세스하여, 그에 기초하여 구성된 해석기 프로세스를 더 포함한다. 상기 실시예에서, 메시지 조정 프로세스는 처리 명령들에 기초하여 복수의 전자 메시지들을 처리하도록 또한 구성된다.

다른 측면에서, 본 발명은 송신 메일 서버들로부터 수신 메일 서버들로의 전자 메시지들의 전송을 관리하는 방법을 제공하고, 송신 메일 서버들로부터 송신된 메시지들은 송신 메일 서버들과 연관된 소스 데이터 및 수신 메일 서버들과 연관된 목적지 데이터를 포함한다. 일실시예에서, 상기 방법은 복수의 인입 전자 메시지들에 대한 소스 데이터 및 목적지 데이터를 데이터 매트릭스에 저장하고, 복수의 전자 메시지들로부터 메타데이터를 외삽하는 것을 포함한다. 게다가, 상기 방법은 메타데이터를 소스 데이터 및 목적지 데이터에 보충하고, 인터페이스를 통하여 소스 데이터, 목적지 데이터, 및 메타데이터를 액세스하는 것을 포함한다. 상기 방법은 또한 소스 데이터, 목적지 데이터 및 메타데이터에 기초한 처리 명령들을 생성하고, 처리 명령들에 기초하여 복수의 전자 메시지들을 처리하는 것을 포함한다.

다른 실시예에서, 본 발명은 송신 메일 서버들로부터 수신 메일 서버들로의 전자 메시지들의 전송을 관리하는데 사용하기 위한 EMS를 제공한다. 일실시예에서, EMS는 복수의 인입 전자 메시지들로부터 송신 메일 서버들과 연관된 소스 데이터 및 수신 메일 서버들과 연관된 목적지 데이터를 추출하도록 구성된 접속 관리 모듈을 포함한다. 게다가, EMS는 소스 데이터 및 목적지 데이터를 저장하는 데이터 매트릭스, 및 상기 데이터 매트릭스와 접속 관리 모듈 사이에 결합된 인터페이스를 포함한다. 상기 실시예에서, 인터페이스는 복수의 인입 전자 메시지들로부터 외삽된 메타데이터를 소스 데이터 및 목적지 데이터에 보충하는 것을 가능하게 하고, 소스 데이터, 목적지 데이터 및 메타데이터에 대한 액세스를 가능하게 하도록 구성된다. 상기 실시예에서, 접속 관리 모듈은 소스 데이터, 목적지 데이터 및 메타데이터에 기초하여 송신 메일 서버들로부터 복수의 인입 전자 메시지들 중 임의의 것을 수용하도록 또한 구성된다.

다른 실시예에서, 본 발명은 송신 메일 서버들로부터 수신 메일 서버들로의 전자 메시지들의 전송을 관리하기 위한 방법을 제공한다. 일실시예에서, 상기 방법은 복수의 인입 전자 메시지들로부터 송신 메일 서버들과 연관된 소스 데이터 및 수신 메일 서버들과 연관된 목적지 데이터를 추출하는 것을 포함한다. 상기 방법은 또한 복수의 전자 메시지들로부터 외삽된 메타데이터를 소스 데이터 및 목적지 데이터에 보충하고, 소스 데이터, 목적지 데이터 및 메타데이터에 기초하여 송신 메일 서버들로부터 복수의 전자 메시지들 중 임의의 것을 수신하는 것을 포함한다.

다른 실시예에서, 본 발명은 송신 메일 서버들로부터 수신 메일 서버들로의 전자 메시지들의 전송을 관리하는데 사용하기 위한 EMS를 제공한다. 일실시예에서, EMS는 복수의 인입 전자 메시지들에 대하여 송신 메일 서버들과 연관된 소스 데이터 및 수신 메일 서버들과 연관된 목적지 데이터를 저장하기 위한 데이터 매트릭스를 포함한다. 또한 EMS는, 데이터 매트릭스에 결합되고, 복수의 전자 메시지들로부터 외삽된 메타데이터를 소스 데이터 및 목적지 데이터에 보충하고, 소스 데이터, 목적지 데이터 및 메타데이터에 대한 액세스를 가능하게 하도록 구성된 인터페이스를 포함한다. 이 실시예에서, EMS는 상기 인터페이스에 결합되고, 소스 데이터, 목적지 데이터 및 메타데이터에 기초하여 복수의 인입 전자 메시지들 중 임의의 것을 수신 메일 서버들로 전달하도록 구성된 전달 관리 모듈을 더 포함한다.

다른 실시예에서, 본 발명은 송신 메일 서버들로부터 수신 메일 서버들로의 전자 메시지들의 전송을 관리하기 위한 방법을 제공한다. 일실시예에서, 상기 방법은 복수의 인입 전자 메시지들 중에서 송신 메일 서버들과 연관된 소스 데이터 및 수신 메일 서버들과 연관된 목적지 데이터를 저장하는 것을 포함한다. 상기 방법은 또한 복수의 전자 메시지들로부터 외삽된 메타데이터를 소스 데이터 및 목적지 데이터에 보충하는 것을 포함한다. 상기 실시예에서, 상기 방법은 소스 데이터, 목적지 데이터 및 메타데이터에 기초하여 복수의 전자 메시지들 중 임의의 것을 수신 메일 서버들에게 전달하는 것을 더 포함한다.

상기한 것은 본 발명의 바람직하고 선택적인 특징들을 기술하였고, 당업자는 다음에 기술되는 본 발명의 상세한 설명을 보다 잘 이해할 수 있다. 본 발명의 청구항의 주제를 형성하는 본 발명의 부가적인 특징들은 이후에 기술될 것이다. 당업자는 본 발명과 동일한 목적을 위하여 수행하기 위한 다른 구조들을 설계 또는 변형하기 위한 기초로서 이하에 개시된 개념 및 특정 실시예들을 쉽게 사용하는 것을 이해한다. 당업자는 또한 본 발명의 사상 및 범위로부터 벗어나지 않고 동일한 구성들을 실현한다.

본 발명의 보다 완전한 이해를 위하여, 첨부 도면들과 관련하여 얻어진 다음 상세한 설명에 대해 참조가 이루어진다. 다양한 형상들이 비례적으로 도시되지 않을 수 있다는 것이 강조된다. 실제로, 다양한 형상들의 크기들은 논의의 명확화를 위하여 임의적으로 증가 또는 감소된다. 게다가, 몇몇 부품들은 논의의 명확화를 위하여 도시되지 않을 수 있다는 것이 강조된다. 첨부 도면들과 관련하여 얻어진 상세한 설명을 참조한다.

도 1은 인터넷을 통한 이메일(e-mail) 전달을 일반적으로 기술하는 일반적인 블록도.

도 2는 인터넷 이메일 전달 경로에서 이메일 관리 시스템의 가능한 배치들을 도시하는 블록도.

도 3은 전자 메시지 이메일 관리 시스템의 이메일 전달 네트워크에서 아키텍쳐 및 배치를 보다 상세히 도시하는 블록도.

도 4는 메시지 조정 컴퓨터 프로세스, EMS 일부 엘리먼트들의 집중, 및 EMS를 통한 이메일 메시지들의 가능한 라우팅을 도시하는 보다 상세한 블록도.

도 5는 다중 메시지 조정 컴퓨터 프로세스들이 단일 트래픽 모니터 및 그와 관련된 해석기 프로세스에 접속된 EMS의 개략도.

도 6은 여기에 논의된 원리들에 따라 구성된 EMS로 관리될 수 있는 IP 주소를 지정하기 위하여 제공될 이메일 관리 기능들의 계층적 분할의 일실시예를 도시하는 블록도.

도 7은 소정 계층과 관련하여 이벤트들 상에서 동작하도록 접속 관리자에 의해 사용될 수 있는 접속 관리 테이블을 형성하는 데이터베이스 구조.

도 8은 EMS의 성분들에 데이터를 기록하고 명령들을 수신하는 것을 포함하는 전자 메시지들의 전송을 관리하기 위한 방법을 도시하는 흐름도.

도 9는 송신 IP 주소, 및 EMS에 의해 관리되는 구성 계층에서 특정 수신자를 위한 구성 파라미터들에 기초하여 제어 명령들을 할당하기 위한 흐름도.

도 10은 EMS내의 해석기 프로세스 리소스에 대한 프로세스 흐름을 도시하는 흐름도.

도 11은 실시간 트래픽 모니터링을 위하여 상기된 실시예들에서 사용될 수 있는 데이터 구조를 도시한 도.

도 12는 상기된 실시예들에 대한 스풀 전달 리소스에 대한 프로세스 흐름을 도시하는 흐름도.

도 13은 본 발명에 따른 EMS로 사용하기 위한 행정 콘솔용 예시적인 액세스 페이지의 스크린 샷.

도 14는 본 발명에 따른 EMS에 사용된 접속 관리자를 모니터링하고 구성하기 위한 예시적인 페이지의 스크린 샷.

도 15는 EMS에 사용된 접속 관리자에 대한 다른 예시적인 페이지의 스크린 샷.

도 16은 본 발명에 따른 EMS에 사용된 전달 관리자를 모니터링하고 구성하는 예시적인 페이지의 스크린샷.

도 17은 EMS에 사용된 전달 관리자에 대한 다른 예시적인 페이지의 스크린 샷.

우선 도 1을 참조하면, 인터넷(101) 또는 다른 컴퓨터 네트워크를 통하여 이메일 메시지들의 전달을 위한 종래의 시스템(100)이 도시된다. 송신 메일 서버들(102a, 102b)(연관된 소스 인터넷 프로토콜(IP) 어드레스를 가짐) 및 수신 메일 서버들(102c, 102d)(연관된 목적지 IP 어드레스를 가짐), 또는 다른 메시지 게이트웨이들은, 전자 메일들(또는 "이-메일들(e-mails)") 같은 전자 메시지들이 송신 클라이언트 머신들(104a-104d)에 및 상기 머신들로부터 수신 클라이언트 머신들(104c-104h), 또는 셀 폰들, 페이저들 및/또는 핸드헬드 컴퓨터들에 전달되게 한다. 종래 시스템들에 따라, 이메일들의 전송 방향은 또한 역방향으로 될 수 있고, 여기서 송신 머신들 및 서버들은 수신 머신들 및 서버들이 되고 그 반대도 된다.

이메일 메시지들은 통상적으로 클라이언트 머신(104)에서 실행하는 애플리케이션에 의해 구성된다. 메시지의 구성이 완료될 때, 사용자는 완료된 메시지를 메일 서버(102)에 업로드한다. 일실시예에서, 메일 서버(102)는 인터넷 서비스 제공자(ISP) 또는 사용자가 일하는 개인 회사에 의해 소유된다. 사용자 클라이언트 머신(104)은 다이얼 업, 디지탈 가입자 루프(DSL), 케이블 인터넷, 또는 다른 적절한 수단을 통해 메일 서버(102)에 접속한다. 이메일 포맷들에 대한 한가지 표준은 RFC2822에 의해 쓰이지 않는 RFC822에 의해 기술되고, 상기 표준은 각각 인터넷 엔지니어링 태스크 포스(Internet Engineering Task Force)("IETF")에 의해 보급되는 표준 및 제안된 표준이다. 이메일 메시지들이 송신 메일 서버(102)로부터 수신 메일 서버(102)로 전송되는 프로토콜은 또한 각각 IETF의 표준이고 제안된 표준인 RFC2821에 의해 사용되지 않는 RFC821에 의해 기술된다. 이들 표준들은 www.ietf.org에서 발견될 수 있다. 본 개시내용은 여기에 참조로써 RFC821 및 RFC822 및 RFC2821 및 RFC2822 제안 표준들의 내용을 통합한다. 만약 제안된 표준들이 2001년 4월에 공개된 버젼으로부터 업데이트되면, 여기에 참조로써 통합된 이들 제안 표준들의 2001년 4월 버젼들의 내용이다. RFC821 및 RFC2821 문서들은 이메일 메시지들이 통상적으로 인터넷을 통하여 트랜스포팅되는 프로토콜인 심플 메일 트랜스포팅 프로토콜(Simple Mail Transport Protocol)("SMTP")을 기술한다.

SMTP 서버들 및 SMTP 클라이언트들(SMTP 클라이언트들은 네트워크 컴퓨터들이고, 클라이언트 머신들(104)과 혼동하면 안된다)은 메일 트랜스포트 서비스를 제공하고, 그러므로 메일 트랜스퍼 에이전트들(Mail Transfer Agents)("MTAs")로서 동작한다. 메일 사용자 에이전트들(Mail User Agents)("MUAs" 또는 "UA")은 메일의 소스 및 타겟들로서 일반적으로 생각된다. 소스에서, MUA는 사용자로부터 전송될 메일을 수집하고 그것을 네트워크(101)내의 MTA로 핸드오프하는 소스 메일 서버(102a, 102b)일 수 있다. 최종("전달(delivery)") MTA는 사용자의 인박스 내 사용자의 메일을 홀딩하는 목적지 메일 서버(102c, 102d)일 수 있는 MUA에 메일을 핸드오프하는 것을 조절하는 것으로서 생각될 수 있다.

SMTP 메일 트랜스포트 프로토콜은 이메일의 송신기로부터 수신자로 메시지들을 라우팅하기 위하여 도메인 이름들을 사용한다. 특정 도메인 이름들에 해당하는 TCP/IP 어드레스들의 분배된 데이터베이스는 도메인 이름 서버들(Domain Name Servers)("DNS")(108)에서 인터넷(101)을 통해 유지된다. 따라서, 이메일을 목적지로 라우팅하기 위하여, 소스 메일 서버들(102a, 102b)은 일반적으로 송신 사용자에 의해 지정된 어드레스를 얻고 특정 어드레스 도메인 이름에 할당된 IP 어드레스를 DNS 서버(108)에게 질문한다. 이런 설명에서 사용된 바와 같이, "어드레스(address)"는 메일이 누구에게 송신되는지, 메일을 송신하는 사용자 또는 소스, 또는 메일이 배치될 위치를 사용자가 식별하는 문자열이다. 용어 "메일박스(mailbox)"는 그 보관소이다. 만약 메일이 배치되는 위치(메일박스)와 그것에 대한 참조(어드레스) 사이의 구별이 중요하지 않다면, 두 개의 용어들은 상호 교환 가능하게 사용된다. 어드레스는 일반적으로 사용자 및 도메인 스펙들로 구성되지만; 어드레스들은 어드레스 타입 및 용도에 따라 다른 형태들을 가질 수 있다. 표준 메일박스 네이밍 전환(standard mailbox naming conversion)은 "local-part@domain"으로 정의되고; 현대의 용도는 간단한 "사용자 이름들(user names)"보다 넓은 애플리케이션들의 세트를 허용한다. 어드레스의 로컬 파트는 통상적으로 어드레스의 도메인 파트에 지정된 호스에 의해서만 의미가 해석 및 할당된다. 반대로, 표준 인터넷 프로토콜(IP) 어드레스는 통상적으로 소스 또는 목적지 서버를 식별하는 특정한 숫자열이다.

소스 메일 서버(102a, 102b)가, 이메일이 처리를 위하여 전달되는 도메인을 어휘적으로 식별하면, DNS 서버(108)를 통한 DNS 룩업(lookup)은 도메인 이름을 분석하기 위하여 수행된다. 그 후, 이메일(110)은 인터넷(101)을 통하여 소스 메일 서버(102a, 10b)로부터 식별된 도메인으로 송신된다.

이제 도 2를 참조하면, 액티브 전자 메시지(즉, 이메일) 관리 시스템(EMS)(203)이 인터넷(101)과 수신 메일 서버(202) 사이에 제공되는 실시예의 블록도(200)를 도시한다. 본 발명의 EMS(203)는 관리 프로세스의 다양한 단계들에서 인간 중재를 필요로 하지 않고 전자 메시지들의 시도된 전송들을 일정하게 관리하기 때문에 "액티브(active)"이고 자동적이다. 이런 의미에서, 여기에 개시된 원리들에 따른 EMS(203)는 자동화되고, 실시간으로 메시지 전달을 관리하도록 구성된다. EMS 시스템은 조건들을 해석하고, 패턴들을 분석하고, 송신자와 수신자 사이의 각 SMTP 접속이 처리될 때 처리 단계들을 수행함으로써 수신 서버(202)로의 데이터 전달을 관리할 수 있다. 종래 이메일 서버들은 일반적으로 분석을 수행하기 전에 메시지 데이터를 수용하고 상기 메시지를 디스크에 기록할 것이다. EMS(203)는 보안 및 관리를 제공하면서 목적지 서버(202)상에 충격을 최소화하도록, SMTP 트랜잭션의 각 스테이지에서 관리 단계들을 수행할 수 있다. 메일 서버(202)에 의도된 메일, 및 수신 클라이언트의 단말(204)이 EMS(203)를 통하여 라우팅되도록, 타겟 메일 서버(202)의 도메인 이름과 연관된 DNS(108)의 수치 IP 어드레스는 EMS(203)의 수치 어드레스를 반영하도록 업데이트된다. 예를 들어, 메일 서버(202)의 도메인 이름이 "anywhere.com"이고 메일 서버(202) 및 EMS(203)에 대한 수치 IP 어드레스들이 각각 "1234.5678.9876.5432" 및 "9876.5432.1234.5768"인 것을 가정한다. 그 다음 "anywhere.com"에 대한 분배된 DNS 데이터베이스(108)의 기록들은 "1234.5678.9876.5432"보다는 EMS 수치 어드레스 "9876.5432.1234.5768"를 반영하도록 업데이트될 것이다.

비록 이 도면이 메일 서버(202)에 물리적으로 인접한 EMS(203)를 도시하지만, 상기 배치는 단지 예시를 위한 것이다. EMS(203)는 인터넷(101)상 어느 곳에든 위치될 수 있다. 방화벽(210)의 선택적 배치, 위치 "A"(방화벽 외측) 또는 "B"(방화벽 내측)로 도시된 바와 같이, 방화벽(210)과 연관된 메일 서버(202) 내 또는 외측에 배치될 수 있다. 대안적으로, EMS(203)는 메일 서버(202)와 동일한 물리적 머신상에서 가능하게 동작할 수 있다.

이제 도 3을 참조하면, EMS(203)의 블록도(300)를 포함하는 보다 상세한 다이어그램이 도시된다. 행정 콘솔 웹 페이지(administrative console web page;316)(그 행정 모듈(318)을 포함함)는, EMS(203)가 인입 전자 메시지들을 처리하는 방법을 구성하는데 도움을 주도록 행정 액세스 툴을 제공하기 위한 실제 EMS 시스템(203)과 동일한 특정 서버 머신에 배치될 수 있다. EMS(203) 및 메일 서버들(102a, 102c) 사이의 접속들은 인터넷 또는 SMTP 접속들을 통하여 형성될 수 있다. 상기된 바와 같이, EMS(203)는 메일 서버들(102a, 102c)중 하나를 가지거나 가지지 않고 특정 방화벽 내측 또는 외측에 존재할 수 있다.

일반적으로, 도 3에 도시된 시스템은 "송신(sending)" 메일 서버(102a)로부터의 메일을 조정한다. "송신자(sender)"로서 하나의 메일 서버 및 "수신자(receiver)"로서 다른 메일 서버의 지정은 임의적이다. 특히, 양쪽 메일 서버들(102a, 102c)은 일반적으로 클라이언트들(104a, 104e)을 송신 및 수신하는 메일 서버들(102a, 102c)로부터 및 상기 서버들로 전자 메시지들의 송신자 및 수신자 모두로서 동작할 것이다. 도시된 실시예에서, 적어도 하나의 메일 서버들(102a, 102c) 도메인 이름들은 DNS 분배 데이터베이스 및 서버들(108)의 EMS(203)와 연관될 것이다. 행정 콘솔(316)을 사용하는 실시예들에서, 콘솔(316)은 의심되는 바이러스들 및 스팸 이메일들, 디렉토리 하비스트 공격들, 또는 사용자나 사용자들에게 송신된 원하지 않는 컨텐트나 전달 시도들에 관한 정보 같이, 특정 사용자들 또는 사용자 그룹들에 인입하는 전자 메시지들의 타입에 관한 정보를 EMS(203)으로부터 수신한다. 사용자 또는 단체에 대하여 EMS(203)에 의해 적용되는 필터링 파라미터들을 구성하기 위하여 사용된 행정 콘솔(316)이 있다. 행정 콘솔(316)은 임의의 도메인 또는 다른 의심되는 트래픽 패턴들로부터 보내지는 과도한 수의 이메일들과 같은 시스템상의 트래픽 패턴들에 관한 정보를 EMS(203)으로부터 수신한다. 행정 콘솔(316)은 웹 서버 또는 EMS(203)와 동일한 중간 플랫폼상에서 실행하는 "행정(admin)" 소프트웨어 모듈(318)을 가진 웹 기반 애플리케이션일 수 있다.

EMS(203)는 복수의 상호접속된 소프트웨어 모듈들을 가진 메시지 조정 컴퓨터 프로세스(320)를 포함하는 것으로서 도 3에 도시된다. 메시지 조정 프로세스(320)의 이들 다양한 소프트웨어 모듈들의 레이아웃은 이들 소프트웨어 모듈들을 실행하는 머신에서 임의의 특정한 물리적 구조를 가리키지 않는다. 상기 프로세스(320) 내에 포함된 하나의 모듈은 접속 관리 모듈, 또는 간단히 접속 관리자(322)이다. 접속 관리자(322)는 UA/메일 서버들(102a)(또는 메일 트랜스퍼 에이전트들)로부터 인입 SMTP 접속들을 설정하고 모니터링할 책임이 있다. 접속 관리자(322)는 EMS(203)에 대한 엔트리 포인트이고, 인입 SMTP 접속 시도들 및 이메일 메시지들을 모니터링한다. 상기 프로세스(320)는 또한 인입 SMTP 접속 데이터, 메시지 메타데이터 및 메시지 전달 정보를 수집하는 트래픽 모니터(340)에 접속된다.

소프트웨어 데몬(software daemon)의 특정 형태일 수 있는 해석기 프로세스(350)가 또한 제공된다. 해석기 프로세스(350)는 동작될 수 있는 메시지들의 트래픽 내의 메시지 패턴들을 인식하기 위하여 트래픽 모니터(340)의 데이터와 상호작용한다. 특히, 상기 프로세스(320)의 부분들을 모두 포함하는 접속 관리자(322), 이메일 조정자(326), 애플리케이션들(332) 및 전달 관리 모듈(또는 간단히 전달 관리자(324))는 인입 메시지들의 처리 동안 트래픽 모니터(340)에 메타데이터뿐만 아니라 소스 데이터 및 목적지 데이터를 기록한다. 소스 데이터 및 목적지 데이터는 송신 메일 서버(102a)와 연관된 소스 데이터, 및 수신 메일 서버(104c)와 연관된 목적지 데이터로 구성된다. 메타데이터는 컨텐트 타입 또는 크기에 의해 정의되는 특정 메시지들과 같은 원하지 않는 메시지들을 검출하기 위한 프로그램 스레드들(threads)인 애플리케이션들(332)을 사용하여 상기 프로세스(320)에 의해 전자 메시지들로부터 외삽된다. 테이블 1은 EMS(203)에 의해 생성된 메타데이터의 보다 상세한 예들을 나열하지만, 리스트는 배타적이 되도록 의도되지 않는다.

frontConnections	소스 IP 어드레스들이 최종 60초에서 타겟 구성에 접속되는 시간
openFrontConnections	IP 어드레스로부터 현재 개방된 구성으로의 접속수
backConnections	EMS가 최종 60초에서 이런 소스 IP 어드레스 대신 구성을 위하여 메일서버에 접속되는 시간
openBackConnections	오픈프론트 접속들과 같음
backendFailed	백 접속과 같지만, 결함 접속 시도(다운 메일 서버를 검출하기 위하여 사용됨) 수를 기록한다
numMessages	이런 구성에서 소스 IP 어드레스로부터 사용자들에게 전송된 메시지들의 수
numSpam	상기와 같지만, 스팸으로서 격리된 수
numVirus	상기와 같지만, 바이러스로서 격리된 수
conBlock, conBlackhole, conSpool, conQtine	블록(바운스), 백홀, 스풀, 및 격리를 공동 배치하는 메시지들의 수는 소스 IP 어드레스/구성 쌍에 대해 적용된다
size	바이트들의 메시지 크기; 평균 및 표준 편차
frontDuration	인바운드 접속 기간; 평균 및 표준 편차
backDuration	아웃바운드 접속 기간; 평균 및 표준 편차
numRecipients	메시지들 상 수신자의 수; 평균 및 표준 편차
Error4	소스 IP 어드레스/구성 사이의 400 등급 에러들
Error5	소스 IP 어드레스/구성 사이의 500 등급 에러들
summary per org	모든 인바운드 IP 어드레스로부터 트래픽의 합
summary record per org/mailhost	각각의 목적지 메일호스트들이 전할 때의 기록
numAttachment	원하지 않는 부착을 가진 소스 IP 어드레스로부터의 메시지들의 수
numContent	원하지 않는 내용을 가진 소스 IP 어드레스로부터의 메시지의 수
numDeferred	목적지 IP 어드레스로부터의 일시적인 지연 에러들의 수
numUnknown	목적지 IP 어드레스로부터의 알려지지 않은 사용자 에러들의 수

테이블 1

전자 메시지들, 또는 심지어 메시지들을 송신하는 사용자의 행동을 가진 패턴들을 결정하기 위하여, 해석기 프로세스(350)는 트래픽 모니터(340)에 기록된 메타데이터, 소스 데이터 및 목적지 데이터 모두를 분석한다. 예를 들어, 복수의 메시지들이 동일한 외부 UA 메일 서버(102a)로부터 인입할 때, 이것은 스팸 공격 또는 다른 서비스 또는 원하지 않는 전달 행동의 거부를 가리킬 수 있다. 해석기 프로세스(350)는 트래픽 모니터(340)에 저장된 소스 데이터, 목적지 데이터 및 메타데이터의 패턴들을 통한 경향을 통지할 수 있고, 성가신 이메일들을 차단하기 위하여 메일 조정기(326)의 액션들을 시작한다. 바람직한 실시예에서, 해석기 프로세스(350)는 상기 태스크를 위하여 생성된 특정 소프트웨어 데몬이지만, 본 발명은 임의의 특정 실시예로 제한되지 않는다. 해석기 프로세스(350)가 소스 데이터, 목적지 데이터 및 메타데이터에 기초하여 검출할 수 있는 다른 패턴들 또는 조건들의 실시예들은 다음을 포함하지만, 이에 제한되지는 않는다:

- 디렉토리 하비스트 공격 검출, 여기서 전달 시도들의 통계적으로 중요한 퍼센트는 서버상 유효 어드레스들 리스트를 컴파일하는 의지를 가진 무효 사용자들에게 지시된다.

- 이메일 폭탄 검출, 여기서 동일하거나 유사한 메시지는 동일한 사용자 또는 사용자 그룹에 반복적으로 전달된다.

- 스팸 공격, 여기서 소스 IP 어드레스로부터 전송된 데이터의 대부분은 스팸이거나 원하지 않은 이메일들이다.

- 바이러스 공격, 여기서 소스 IP 어드레스로부터 전송되는 데이터의 대부분은 바이러스 감염된다.

- 서비스 접속 요구들의 거부, 여기서 전송 IP 어드레스는 접속 개방 또는 비전달 의미 데이터를 반복적으로 접속 및 홀딩한다.

- 비응답 고객 서버들, 여기서 접속 시도 실패 및 메시지들은 리다이렉트되거나 스풀링되어야 한다.

- 용량 고객 서버들, 여기서 고객 서버는 임계 용량이고 부가적인 메시지들을 수신하지 않는다.

- 공전 고객 서버들, 여기서 공전 고객 서버들은 사용되지 않은 용량을 가지며 보다 많은 메시지들을 수용할 수 있다.

- 다음 서버, 여기서 수신자 서버들의 할당된 회전시 다음 이메일 서버는 다음 메시지를 수신하여야 한다.

- 비지(busy) 고객 서버들, 여기서 고객 서버는 요구들을 처리할 수 없는 지연 에러 요구를 리턴한다.

데이터베이스(360)는 이 실시예에서 해석기 프로세스(350)의 액션들 및/또는 필터된 이메일에 관한 정보를 로그하고, 트래픽 모니터(340)에 인식된 패턴들에 기초하여 메시지 처리 액션들을 제공하기 위한 구성 파라미터들을 저장하기 위하여 제공된다. 행정 콘솔(316)은 데이터베이스(360)에 액세스하고, 해석기 프로세스(350)에 액세스하여야 하고, 그것에 의해 액션들은 검토되고 시스템은 임의의 형태의 환경들에서 취해질 액션들을 고려하여 구성될 수 있다.

개념적으로, 다른 측면에서 프로세스(320)는 EMS(203)가 메시지를 전달하는 수신 UA 메일 서버들(102c)의 상태를 실시간을 알기 위한 능력을 가진 전달 관리자(324)이다. 접속 관리자(322) 및 전달 관리자(324)는 EMS(203)내의 전체 처리를 관리하는 메일 조정기(326)이다. 메일 조정자(326)는 개념적으로 다목적 인터넷 메일 확장부(MIME) 디코더(328) 및 애플리케이션 인터페이스(330)에 접속된다. 애플리케이션 인터페이스(330)는 트래픽 모니터(340)에 정보를 기록하고, 메타데이터에 기초하는 메일 조정기(326) 및 애플리케이션들(332) 사이의 인터페이스를 제공한다.

데이터베이스(360)에 저장된 룰들에 의해 형성된 구성 다음, 해석기 프로세스(350)는 상기된 바와 같이 트래픽 모니터(340)에 저장된 데이터의 패턴들을 해석할 것이고, 접속 관리 테이블(콘맨(conman) 테이블)(370)의 기록을 업데이트한다. 콘맨 테이블(370)은 이 메시지 처리 정보를 통상적으로 배치 명령 형태로 저장하고, 인입 메시지와 특정 소스 IP 어드레스에 대한 접속 및 전달이 처리되는 방법을 조절한다. 콘맨 테이블(370)의 기록들에서 배치 플래그들의 방식으로 나타나는 배치 명령들의 예들은 다음과 같지만, 제한되지는 않는다:

- 메시지 수용

- 메시지 거절

- 메시지 차단

- 메시지 스풀

- 메시지 지연

- 메시지 조절

- 메시지 리다이렉트

- 블랙홀

일실시예에서, 만약 하나의 특정 어드레스가 스팸으로 알려지거나, 바람직하지 않은 메시지들을 전송하면, 하나의 특정 고객, 접속 관리 기록(콘맨 기록)은 SMTP 접속들 거절 또는 조절하기 위하여 콘맨 테이블(370)에 기록되고, 구성을 보호한다. 따라서, 패턴들 및 행위들은 소스 데이터, 목적지 데이터 및 메타데이터에 기초하여 식별될 수 있고, 접속 관리 기록들은 전체 고객 베이스를 모으고 제공할 수 있다. 일단 위반 조건은 전달 메시지들에 대한 추후 유사한 요구들에서 식별되고, 접속 관리자(322)는 만약 전송 IP 어드레스로부터 요구를 조정하는 중에 특정 명령들이 있다는 것을 결정하기 위하여 콘맨 테이블(370)에게 질문한다. 만약 배치 플래그들이 존재하면, 접속 관리자(322)는 메시지를 적당하게 배치하거나 제 1 장소에서 전송 메일 서버(102a)에 의한 접속을 방지하기 위하여 콘맨 테이블(370)의 배치 명령들을 사용한다. 의도된 사용자에게 메시지 전송을 방지하는 조건에 따라, 비록 접속 관리자(322)에 의한 접속이 허용될지라도, 전달 관리자(324)는 해석기 프로세스(350)에 의해 전달 메시지 테이블(380)을 통하여 메시지를 적당하게 배치하도록 명령받을 수 있다. 전달 관리자 테이블(380)은 해석기 프로세스(350) 또는 각각의 EMS 프로세스(203)가 트래픽 모니터(340)에 저장된 데이터에 기초하여 테이블(380)에 메시지 처리 명령들을 기록하는 콘맨 테이블(370)과 유사하다. 전달 관리자 테이블(380)에 나타날 수 있는 배치 명령들은 콘맨 테이블(370)과 달리 하기를 포함하지만, 제한되지는 않는다:

- 메시지 전달

- 메시지 지연

- 메시지 거절

- 메시지 리다이렉트.

메시지 조정기(326)의 몇몇 부품들의 보다 상세한 설명뿐 아니라, 그 기능은 도 4를 참조하여 하기된다.

도 4를 참조하여, 메시지 조정 컴퓨터 프로세스(320)의 보다 상세한 소프트웨어 모듈 블록도(400)가 도시된다. 이 실시예에서 메일 조정기(326)는 빠르고, 무상태의(stateless) 메일 조정기로 설계된 메시지 처리 서버(MPS)(426)를 포함한다. MPS(426)는 인입 이메일 메시지(110)를 얻고 메시지(110)의 전달을 지연하지 않고 진행함으로써 메시지(110)로부터 정보를 "모음(scrape)" 또는 추출할 수 있다. MPS(426)는 또한 해석기 프로세스(350)(도 3 참조)로부터의 명령에 따라 전달 관리자(324)를 통하여 조건적으로 메시지들을 전달할 수 있다. 예를들어, 만약 공통 소스 IP 어드레스로부터 접속 시도 또는 그룹 접속 시도가 하비스트 공격인 것을 해석기 프로세스(350)가 트래픽 모니터(340)의 데이터로부터 결정하면, 해석기 프로세스(350)는 접속 관리자(322)에게 접속을 거부하는 것을 명령하기 위하여 콘맨 테이블(370)을 업데이트한다. 선택적으로, 해석기 프로세스(350)는 그렇지 않으면 메시지를 배치하도록 전달 관리자(324)에게 명령하기 위하여 전달 관리자 테이블(380)을 업데이트한다. 만약 스팸 검출 애플리케이션(332) 같은 애플리케이션이 스팸인 메시지의 값을 리턴하면, 해석기 프로세스(350)에 관련하여 MPS(426)는 격리 웹사이트에 상기 스팸을 라우팅하도록 메시지의 전달을 구성할 수 있다. 전자 메시지들이 통과, 전달, 지연 등이 될지의 결정들은 부분적으로 인입 메시지들의 영역에서 생성된 메타데이터, 및 EMS(203)가 행정 콘솔(316) 및 메시지들을 처리하기 위하여 선택된 애플리케이션들(332)에 기초하여 이루어진다.

부가적인 서브 모듈들은 도 4에 도시된다. 이 실시예에서, EMS(203)에 진입하는 전자 메시지들로부터 데이터를 수집하고 트래픽 모니터(340)에 정보를 제공하는 도 3의 실시예에 관련하여 기술된 기능들을 수행하는 메타데이터 수집기 서브모듈(430) 및 이벤트 전송 서브모듈(432)이 제공된다. 비록 이들 서브모듈들이 MPS(426)와 연관되어 도시되었지만, 상기 모듈들은 메타데이터 수집기(430)와 연관될 수 있거나 독립된 소프트웨어 모듈들일 수 있다. 애플리케이션들(332)이 콘맨 테이블(370)에 기록되지 않는 동안, 상기 애플리케이션들은 애플리케이션 인터페이스(330)를 통하여, a) 메시지를 처리하고, b) 처리 결과들에 기초하여 배치 플래그들을 업데이트하고, c) 메타데이터를 트래픽 모니터(340)에 전달하도록 구성된다.

도 3-4에 기술된 실시예들의 부가적인 특징은 목적지 UA 이메일 서버(102c)에 로딩에 따라 이메일들의 전달을 재단하기 위한 능력이다. 전달 관리자(324)는 예를들어 이전 이메일 메시지들의 수신을 알 때 서버(102c)에 의한 지연에 의하여 목적지 UA 이메일 서버(102c)의 로딩 이슈들을 검출할 수 있다. 따라서, 버퍼 릴레이(440) 및 스풀 릴레이(442)의 출력은 목적지 UA 이메일 서버(102c)의 검출된 로딩 이슈들에 기초하여 아웃고잉 메시지들을 스풀링하기 위하여 사용한다.

도 5를 참조하여, 두개 이상의 메시지 조정 컴퓨터 프로세스들(320a, 320b)이 독립적으로 각각 동작하지만, 단일 트래픽 모니터(340) 및 공통 테이블(370)에 접속되는 실시예를 도시하는 블록도(500)가 도시된다. 각각의 프로세스(320a-n)는 수신 서버와 현재 개방 접속들과 관련한 데이터를 공유한다. 이 공유된 전달 관리자 테이블(380)은 수신 서버에 전송시 모든 메시지들의 임의의 때에 현재 상태를 포함한다. 트래픽 모니터(340)는 프로세스들(320a-320b)의 이벤트 송신기들(432a, 432b)에 대한 통신 인터페이스인 이벤트 청취자(502)를 가진다. 이 실시예에서 트래픽 모니터(340) 및 해석기 프로세스(350)는 도시된 바와 같이 전자 메시지들의 다중 인입 스트림들에 대한 다중 프로세스들(320a, 320b)을 모니터 및 제어한다.

트래픽 모니터(340)내의 몇몇 데이터의 구성의 예로서, 데이터 테이블(504) 형태의 예시적인 데이터 매트릭스가 도시된다. 이런 데이터 테이블(504)에서, 다중 소스들로부터 다중 목적지들로 이메일의 발생들(incidences)은, 특정 소스들로부터의 메시지들은 로우를 따라 맵핑하고 특정 목적지들로의 메시지들은 컬럼들에 따라 맵핑하는 테이블로서 배열된다. 잠재적인 스팸은 테이블(504)에 도시되고, 예와 같이 여기서 대부분의 목적지 퍼센트들은 특정 소스로부터 수신된 메시지를 가지며, 이에 따라 테이블(504)에 거의 완전히 로우로서 나타난다. 해석기 프로세스(350)는 데이터베이스(360)로 턴하고 해석기 프로세스(350)가 행정 콘솔(316)을 통하여 상기 룰의 구성을 통하여 동작하도록 명령 받는 데이터베이스(360)의 룰들을 수행한다.

따라서 사용자는 데이터베이스(360)를 통하여 해석기 프로세스(350)를 구성한다. 예시적인 룰들은 스팸 공격(예를들어, 100 또는 단일 IP 어드레스들로부터 메시지들의 몇몇 다른 수)의 한정, 및 상기 IP 어드레스로부터 모든 인입 이메일들을 삭제하거나 IP 어드레스에 허용된 접속수를 제한하는 것 같은 스팸 공격을 위한 액션을 포함한다. 다른 메시지 조정 룰들의 생성을 촉진하는 상황들의 예들은 상기된 바와 같이 바이러스 공격, 디렉토리 하비스트 공격, 이메일 폭탄 등이다. 일단 룰들이 데이터베이스(360)에 저장되면, 데이터베이스(360)와 연관된 모든 접속 관리자들(322a, 322b) 및 전달 관리자들(324a, 324b)은 목적지 IP 어드레스에 기초하여 데이터베이스(360)의 구성 정보 및 각각의 메시지 트랜잭션상 콘맨 테이블(370)을 사용하여, 그것들이 가장 최근 룰들 세트하에서 동작하는 것을 보장한다. 상기된 접속 관리자들(322a, 322b)은 이런 처리 동안 트래픽 모니터(340)에 이벤트 정보를 제공한다.

트래픽 모니터(340)를 모니터하는 해석기 프로세스(350)는 특정 룰들을 위반하는 트래픽 모니터(340)의 검출된 패턴들에 기초하여 콘맨 테이블(370)을 차례로 업데이트할 수 있다. 컴퓨터 프로세스들(320a, 320b)은 각각의 메시지 트랜잭션상에서 데이터베이스(360), 콘맨 테이블(370) 및 트래픽 모니터(340)와 접속하여 가장 현재의 구성을 수신하고 전달 메시지 테이블(380)을 가지거나 룰들에 의해 설정된 제한들을 액세스하고, 현재 상태들에 기초하여 목적지 서버에 전달 명령을 얻는다. 따라서, 시스템은 가장 최근 접속 및 전달 명령을 가지게 항상 업데이트하고 이에 따라 실시간으로 인간 검토 또는 중재없이 전자 메시지 트래픽의 로드들을 변화시키지 않고 적용할 수 있다. 해석기 프로세스(350)는 MPS(426a, 426b) 모두에서 모든 접속 관리자들(322a, 322b)에 의해 질문되어, 룰들에서 공급된 필요한 활동을 모두 동시에 안다.

만약 다중 전달 관리자들(324a, 324b) 및/또는 접속 관리자들(322a, 322b)이 서로 통신하여, 예를들어 만약 목적지 메일 서버가 느리다는 것을 전달 관리자들(324a, 324b)들 중 하나가 통지하면, 전달 관리자(324a, 324b)는 특정 목적지 서버에 메시지 전달을 지연하거나 느리게 하기 위하여 모든 다른 전달 관리자들(324a, 324b)에게 통지한다.

모든 트랜잭션 데이터는 로그(506)에 저장된다. 로드(506)는 모든 메시지 트랜잭션들 및 파라미터들의 기록을 유지할 것이다. 예시적인 실시예에서, 상세한 기록들(508)들은 서버들이 어떤 목적지 어드레스에 무엇을 보내는지를 매일 생성한다. 상기 실시예에서, 이런 데이터는 그래픽 웹 기반 포맷으로 제공되거나, 사용자에 의해 오리지널 데이터로서 다운로드될 수 있다. 기록들(508)이 생성될 수 있는 정보는 소스 IP 어드레스, 메시지 내용 타입, 메시지 체적, 수신자 정보 등을 포함하지만, 이것으로 제한되지 않는다.

경고부들(510)은 그들의 시스템과 관련한 조건들의 행정기를 알리기 위하여 구성될 수 있다. 예를들어, 만약 EMS(203)가 디렉토리 하비스트 공격을 검출하면, 해석기 프로세스(350)는 콘맨 테이블(370)을 업데이트하고 특정 수신자에 대한 경고를 생성한다. 다른 실시예에서, 만약 메일 서버가 전해지면, 해석기 프로세스(350)는 특정 수신자를 스풀링하고 특정 수신자에 대한 경고를 생성하기 위하여 콘맨 테이블(370)의 배치 플래그를 업데이트할 것이다. 이와 같이, 경고부(510)는 해석기 프로세스(350)가 식별하는 모든 조건들에 기초하여 생성될 수 있다.

일실시예에서, 도 6에 따라, 사용자 데이터베이스 계층부(600)는 다른 이벤트들이 계층부(600)내의 사용자 위치에 따라 재단될 수 있을 뿐 아니라, 접속부들을 관리하고 메시지 데이터를 스캐닝하는 식별 및 배치를 위한 파라미터들을 형성한다. 시스템내의 모든 사용자들은 계층부 내의 상부 레벨(602) 아래에 속하고, 따라서 시스템에 속하는 모든 사용자들에 대한 임의의 룰들이 형성될 것이다.

상부 레벨(602) 아래에, 사용자들은 상부 레벨(602) 행정기에 고객들(604a-604b)인 보조 구성들에 속할 수 있다. 예를들어, Acme Corporation에서 사용자는 이메일 어드레스 user1@acme.com을 가질 수 있고, 여기서 acme.com 어드레스는 분산된 DNS 데이터베이스 서버들(108)의 Acme과 연관된 상부 레벨(602) 도메인 서버 어드레스이다. 이메일은 상부 레벨(602) 룰들에 따라 작동된다. 부가적으로, acme.com의 특정 룰들은 계층에서 "customer#1"(604a)로서 사용자1이 특정 요구들을 나타내기 때문에, 상기 사용자들에 적용된다. 사용자1의 특정 요구는 "customer#2"(605b) 또는 "customer#3"(604c)와 연관된 사용자 그룹들에 적용되지 않는다.

게다가, 때때로 구성들은 보조 구조들(606a, 606b)을 가져서, corp.acme.com 및 usa,acme.com 같은 다른 도메인 이름을 유발한다. 여기에 기술된 실시예들은 비록 개인화가 가능하지만 고객 룰들이 각각의 사용자에 대한 개인화된 룰들의 완전한 세트를 수행할 필요없이 성공적으로 하부 계층 레벨들에 적용되게 한다.

도 7을 참조하여, 도 6의 계층과 관련하여 이벤트들 상에서 작동하도록 접속 관리자에 의해 사용될 수 있는 데이터베이스 구조(700)가 도시된다. 이런 데이터베이스 구조(700)에 따라, 콘맨 테이블(370)에 사용하기 위한 콘맨 기록들(710)은 내부 식별자("IID")(710a)에 의해 구성되고, 이것은 구성 파라미터들이 설정되는 것뿐 아니라, 수신자가 계층부(600)에 잔류하는 기록이다. 또한 메시지들의 IP 어드레스들을 시작하기 위한 시작 IP 어드레스들(710b) 및 끝 어드레스(710c)를 위한 콘맨 기록들(710)에 포함될 수 있는 부가적인 필드들이 도시된다. 다른 예시적인 필드들은 콘맨 기록(710)에 대한 만료 시간(710d)뿐 아니라, 특정 접속 요구들에 응답하여 접속 관리자(322)에 의해 얻어질 액션인 콘맨 테이블(370)의 배치 플래그(710e)이다.

이 실시예에서, 이것은 구성 계층(600)내의 사용자들에 대해 셋업되는 룰들에 따라 콘맨 기록들(710)을 생성하는 해석기 처리부(350)이다. 선택적으로, 콘맨 기록(710)들은 행정 콘솔(316)을 통하여 수동으로 생성될 수 있다. 이들 기록들(710)들은 접속 관리자(322)에 의해 액세스 가능한 데이터베이스(360) 또는 다른 데이터베이스에 저장될 수 있다. 단일 IID는 다중 기록들(710)을 가질 수 있다. 이들 기록들(710)은 만약 메시지 작업들이 제거되지 않으면 제한없이 적법한 송신기들로서 상태를 유지하기 위하여 차단, 조절, 또는 전송 메일 서버들이 제어되게 하는 만료 값(710d)을 포함한다. 일단 만료값(710d)에 도달되면, 접속 관리자(322) 및 MPS(426)는 송신기로부터의 각각의 메시지들을 처리할 것이다. 만약 그것들이 계속 바이러스들을 전송하면, 콘맨 테이블(370)에 새로운 기록(710)이 형성될 것이다. 이런 처리는 송신기의 조건들이 변화하고 적법한 이메일 메시지들이 보내지기 시작할 때까지 반복될 것이다.

또한 도 7에는 콘맨 테이블(370)내의 가능한 배치 플래그들(710e)의 상세한 기록(720a-i)이 도시된다. 도시된 실시예들은 메시지 수신부(720a), 메시지 거절부(720b), 메시지 격리부(720c), 메시지 스풀(720d), 메시지 지연부(720e), 메시지 조절부(720f), 메시지 리다이렉트부(720g), 접속 거절부(720h), 및 블랙홀(720i)이고; 물론, 본 발명은 이들 특정 배치 플래그들(710e)로 제한되지 않는다.

도 8을 참조하여, 동작 흐름을 통하여 MPS의 동작의 일실시예가 도시된다. 도면에 지시된 바와 같이, 전체 프로세스에 따라 프로세스로부터 발생한 데이터는 상기에 더 상세히 논의된 바와 같이 EMS의 MPS의 다양한 구성요소들을 사용하여 트래픽 모니터에 기록된다. 그 다음 상기 데이터는 전달 관리 모듈에 의해 사용된 전달 관리 테이블에서뿐 아니라, 접속 관리모듈에 의해 사용된 콘맨 테이블에서 정보를 업데이트하기 위하여 해석기 프로세스에 의해 사용될 수 있다. 상기 프로세스는 시작 단계에서 시작하고, 그 다음 단계(800)로 이동하고, 여기서 송신기는 이메일 같은 전자 메시지를 전송하기 위한 시도시 송신기 메일 서버를 통하여 수신 메일 서버에 접속된 타겟 사용자에게 접속을 개방한다. 단계(802)에서, 여기에 기술된 원리에 따라 구성된 EMS는 송신기에 의한 접속 시도를 해석하고, SMTP 정보(예를들어, 송신기의 IP 주소) 같은 송신기로부터의 정보를 수신한다.

단계(804)에서, EMS는 메시지의 의도된 수신자와 관련하여 SMTP 정보(예를들어, 수신자의 이메일 어드레스) 같은 유사한 정보를 수신한다. 일단 데이터의 양쪽 세트들이 EMS에 의해 수신되면, 상기 프로세스는 단계(806)로 이동하고, 이 데이터는 접속 관리(콘맨) 테이블의 기록과 비교된다. 상기된 바와 같이, 테이블의 기록들은 트래픽 모니터의 데이터 매트릭스에 홀딩된 정보에 기초하여 해석기 프로세스에 의해 업데이트될 수 있다. 만약 전송기로부터의 임의의 전송 블록들이 구성되면, 네가티브 응답이 단계(806)에서 제공되고 전송 시도는 거절된다. 선택적으로, 만약 특정 송신기로부터의 모든 메시지들이 허용되지 않는 것을 EMS가 설정하면, 상기 프로세스는 단계(802)로 이동될 수 있고, 여기서 송신기의 SMTP 정보는 EMS에 의해 수신되고, 단계(806)로 이동될 수 있고, 여기서 송신기의 IP 어드레스는 콘맨 테이블의 잠재적인 배치 플래그들과 비교된다. 이 경우, 송신기에 의한 전송 시도는 단계(804)에서 수신자들 SMTP 정보를 수신할 필요없이 거절된다.

단계(806)에서, 만약 송신기에 대한 블록들이 콘맨 테이블에서 발견되지 않으면, 긍정적인 응답이 주어지고 상기 프로세스는 단계(808)로 이동한다. 단계(808)에서, 의도된 수신자의 정보는 사용자 데이터베이스 또는 디렉토리뿐 아니라, 목적지 서버 디렉토리의 사용자 리스트에서 사용자들의 리스트에 대해 유효화된다. 만약 시도된 전송이 유효한 수신 정보를 포함하지 않으면, 부정적인 응답이 단계(808)에서 제공되고 전송은 거절된다. 또한, 비록 유효한 수신자가 사용자 데이터베이스에서 발견되더라도, 만약 수신자 정보가 목적지 서버 데이터베이스의 사용자 리스트에 대해 유효화되지 못하면, 전송은 거절된다. 만약 사용자 데이터베이스 및 목적지 서버 데이터베이스 모두로부터 유효화가 얻어지면, 긍정적인 응답이 주어지고 상기 프로세스는 단계(810)로 이동한다.

단계(810)에서, 전달 관리자 테이블은 의도된 메시지가 목적지 서버로 전달될 수 있는지를 결정하기 위하여 질문된다. 예를들어, 전달 관리자 테이블은 목적지 서버가 전송을 수신할 수 있고 그 로드 제한에 도달되었는지를 결정하기 위하여 질문될 수 있다. 만약 목적지 서버가 메시지를 수신하기 위하여 판독하지 않는다면, 긍정적인 응답은 단계(810)에서 제공되고 전송 시도는 추후 전달을 위하여 지연되고, 일단 목적지 서버는 메시지를 수신할 준비를 한다. 만약 목적지 서버가 메시지를 수신할 수 있으면, 부정적인 응답이 단계(810)에서 제공되고 상기 프로세스는 단계(812)로 진행한다. 도면에서 도시된 바와 같이, 송신기 및 수신자에 관한 데이터는 이 프로세스를 통하여 트래픽 모니터에 기록된다.

단계(812)에서, 시도된 전송의 모든 데이터는 헤더 또는 다른 라우팅 정보뿐 아니라, 전달될 의도된 전자 메시지를 형성하는 데이터를 포함하는 EMS에 의해 수신된다. 상기 프로세스는 단계(814)로 이동하고, 여기서 사용자 또는 구성을 위한 구성 세팅에 의해 나타난 룰들에 의해 형성된 상기 구성 프로파일은 메시지를 처리하는 방법을 결정하기 위하여 판독된다. 단계(816)에서, 애플리케이션들은 원하지 않거나, 방지되거나 손상된 메시지들을 식별하기 위하여 메시지 데이터의 분석을 수행하기 위해 사용된다. 이런 프로세스의 결과와 연관된 메타데이터는 트래픽 모니터에 기록되고 접속 및 전달 가이드라인들을 형성하기 위하여 사용된 패턴들 또는 조건들을 결정하기 위하여 해석기 프로세스에 의해 사용된다. 애플리케이션들을 사용함으로써 생성된 메타데이터의 실시예들은 테이블 1에 설정된다.

일단 애플리케이션들이 상기 분석을 완료하면, 상기 프로세스는 단계(818)로 이동하고, 여기서 애플리케이션 처리 결과들은 구성 데이터베이스의 내용들에 대해 비교된다. 만약 애플리케이션 처리 결과들이 메시지에 현재 이용할 수 있는 것과 다른 배치 플래그를 제안하면, 새로운 배치 플래그는 삽입된다. 단계(820)에서, 단계(818)로부터의 결과들은 콘맨 테이블에서 설정된 바와 같이 메시지에 할당된 임의의 증착 플래그들과 비교된다. 만약 단계(820)에서, 시도된 전송을 가리키는 배치 플래그가 이런 시기에 허용되지 않으면, 상기 프로세스는 콘맨 테이블의 종래 배치 플래그에 대응하는 적당한 단계로 이동한다. 특히, 만약 메시지가 스풀링되면, 프로세스는 단계(822)로 이동한다. 만약 메시지가 격리되면, 프로세스는 단계(824)로 이동한다. 만약 메시지가, "블랙홀(blackhole)"로 전송되면, 프로세스는 단계(826)로 이동한다. 만약 메시지가 지연되면, 프로세스는 단계(828)로 이동한다. 만약 메시지가 리다이렉트되면, 프로세스는 단계(830)로 이동한다.

그러나, 만약 단계(820)에서, 전송이 허용되는 것을 콘맨 테이블의 기록들이 형성하면, 프로세스는 단계(832)로 이동한다. 단계(832)에서, 메시지는 의도된 목적지 서버로 전송된다. 단계(834)에서, 메시지는 목적지 서버에 의해 수신된다. 단계(836)에서, 목적지 서버는 EMS의 전달 관리자로부터 메시지의 수신을 알리기 위하여 EMS로 다시 메시지("ACK")의 수신의 받음을 전송한다. 마지막으로, 단계(838)에서, EMS는 메시지가 타겟 사용자로 전송되는 것을 사용자에게 알리기 위하여 메시지의 본래 송신기로 다시 전송의 ACK를 전송한다. 상기 프로세스는 그 다음 끝난다.

당업자는 제안된 프로세스가 도 8에 도시된 특정 단계들로 제한되지 않는다는 것을 이해할 것이다. 따라서, 보다 많거나 적은 수의 단계들은 사용된다. 선택적으로, 도 8에 도시된 것보다 크거나 작은 단계들은 바람직하게 사용될 수 있다.

도 9를 참조하여, 인입 전자 메시지들을 관리하는데 사용하기 위한 접속 관리자(322)에 의해 사용된 과정의 일실시예를 나타내는 흐름도(900)가 도시된다. 특히, 도면(900)은 전송 IP 어드레스, 및 EMS(203)에 의해 관리된 구성 계층부에서 특정 수신자에 관한 구성 파라미터들에 기초하여 제어 명령들을 할당하는 것을 도시한다. 접속 관리자(322)는 MPS(426)에 의해 동작을 시작하고, 각각의 시간에 MPS(426)는 트래픽 스트림에서 새로운 수신자를 식별하는 새로운 "RCPT" 명령을 검출한다. 접속 관리자(322)의 초기 동작 조건은 단계(902)에서 도(900)에 도시된다. 단계(904)에서, 접속 관리자(322)는 새로운 수신자에 대응하는 IID를 가진 기록들에 대해 콘맨 테이블(370)에 질문한다. 만약 결정 블록(906)에서, 콘맨 테이블(370)이 특정 IID에 대한 엔트리를 포함하는 것을 결정하면, 제어는 각각의 IID 기록이 판독되고(단계 908), 여전히 액티브한지 만료되었는지를 보기 위하여 시험되고(단계 910), 작동되는(단계 912) 제 2 제어 루프로 통과된다. 단일 IID는 다중 기록들을 가질 수 있고, 그래서 상기 단계들(908-912)에서 상기 액션들은 결정 블록(914)에서 반영된 바와같은 IID에 대한 부가적인 기록들이 있는 한 다이어그램(900)에 도시된 바와 같이 반복된다.

도 9에 도시된 바와 같이, 특정 수신자는 계층부내의 임의의 레벨에서 적합하게 될 수 있고, 특정 접속 액션들은 이들 계층 레벨들 각각에 따른 방법으로 재단될 수 있다. 따라서, 단계(916)에서, 특정 IID는 다음 보다 높은 계층 레벨에서 맴버쉽에 대하여 시험된다. 만약 이런 계층 레벨에서 특정 IID와 연관된 콘맨 테이블(370)에 접속 관리자(322) 기록들이 있다면, 결정 단계(918)에 대한 프로세스의 흐름에 따라, 루프의 액션들, 단계들(908-914)은 보다 높은 레벨에서 IID와 연관된 모든 액션들에 대해 반복된다. 이전과 같이, 일단 이런 계층 레벨에서 주어진 IID와 연관된 모든 액션들이 수행되면, 제어는 결정 단계(920)로 리턴하고, 그후 계층 레벨들에 관한 IID는 상부 계층 레벨이 도달되었는지를 보기 위하여 시험된다. 만약 가장 높은 계층 레벨이 도달되면, 접속 관리자(322)는 MPS(426)로 제어를 리턴한다.

접속들은 한쌍의 엔드포인트들을 특징으로 한다 - 송신기 및 수신자. 접속들은 전송기/수신기 쌍에 기초하여 관리되거나, 수신 식별기만에 기초하여 관리된다. IP 어드레스 범위들은 송신기들 및/또는 수신자들을 지정하기 위하여 사용되고, 식별 위치에 따라, 상기 범위들 또는 식별은 특정 IP 어드레스가 계층부내에 속하는 경우를 지정하기 위하여 사용될 수 있다. 임의의 IP 어드레스 범위들에 의해 한정된 IP 어드레스의 맴버쉽은 어드레스의 계층 구성 맴버쉽들을 한정하기 위하여 사용될 수 있다.

접속 관리 기록들은 계층 내의 단위 구성상에 삽입될 수 있고, 상기 기록들은 높은 레벨의 구성들로부터 낮은 레벨의 구성들로 전달될 수 있다. 도 9의 프로세스 흐름에 관련하여 상기된 바와 같이, 기록들은 특정 구성으로부터 루트 구성으로 일반인 방식으로 처리될 수 있다. 다중 기록들이 단일 구성에 제공될 때, 상기 기록들은 만료 시간 순서로 처리되고, 가장 최근 일에 만료하는 것들이 가장 먼저 시험된다. 선택적으로, 상기 기록들은 프로세스가 한정되는 방법에 따라 다른 순서로 처리된다.

비록 상기된 바와 같이 요구된 접속들에 기초하여 얻어질 수 있는 액션들 또는 배치들의 형태들이 많이 잇지만, 몇몇 공통들은 다음과 같다:

- 에러; 에러 메시지는 지정되고 송신기에게 다시 통과된다(예를 들어, "에러 501-미지의 사용자(Error 501-unknown user)").

- 차단: 이 메시지는 지정된 이유하에서 격리될 것이다(예를들어, 부재, 포르노그래픽, 또는 바이러스 감염).

- 블랙홀; 이 메시지는 전달될 것이지만(즉, 전달 확인은 송신기에게 보내진다), 실제로 어딘가로 갈지 모른다. 만약 추가의 변형들이 이루어지면, 다른 애플리케이션은 메시지가 격리되게 할 수 있다.

- 허용; 이 메시지는 허용되고 목적지 서버로 보내진다. 만약 추가의 변형이 이루어지면, 다른 애플리케이션은 이 메시지를 차단할 것이다.

- 스풀; IID에 대응하는 이 이메일은 응답하지 않고, 그러므로 메시지는 스풀러에 기록되어야 한다.

상기된 바와 같이, 접속 관리자(322)는 전자 메시지 트랜잭션들의 요구된 접속들의 허용 및 형성을 조정한다. 상기된 배치는 행정 콘솔(316)을 통하여 수동 구성에 의해 접속 관리자(322)에 의해 실행될 수 있거나, 해석기 프로세스(350) 또는 다른 소프트웨어 모듈에 의해 자동으로 실행될 수 있다. 도 8의 프로세스와 같이, 도 9에 도시된 프로세스의 실제는 여기에 기재된 특정 단계들로 제한되지 않는다. 따라서, 보다 많거나 적은 수의 단계들은 사용될 수 있다. 부가적으로, 도 9에 도시된 것보다 보다 많거나 적은 것들을 가진 단계들은 바람직하게 사용될 수 있다.

도 10을 참조하여, 텍스트 첨부 도 3-4에 기술된 해석기 프로세스(350)의 동작 흐름도(1000)가 도시된다. 해석기 프로세스(360)의 프로세스 흐름 실행은 단계(1002)에서 시작하고, 이것은 프로세스를 위한 잠자는 상태이다. 임의의 시간의 기간후, 예를들어 15초후, 프로그램 흐름의 실행은 단계(1004)로 진행한다. 단계(1004)에서, EMS(203) 구성은 EMS(203)가 응답하는 모든 구성에 대해 업데이트된다. 이런 프로세스는 "동기화(synchronization)"라 한다. 단계(1006)에서, 해석기 프로세스(350)는 단계(1004)에서 식별된 각각의 구성을 위해 발생하는 트래픽 이벤트들을 분석하기 시작한다. 이런 액션의 일부로서, EMS(203)는 트래픽 모니터(340)에 저장된 데이터에서 반영된 바와 같이 발생하는 트래픽 이벤트들을 계산한다.

단계(1010)에서 상기 프로세스 흐름이 계속되고, 여기서 EMS(203)는 고려후 구성에 대한 특정 EMS(203) 이벤트 룰에 대한 이벤트 조건들을 평가한다. 결정 단계(1012)에서, 해석기 프로세스(350) 소프트웨어는 특정 룰이 액티브한지를 질문한다. 만약 룰이 액티브하지 않으면, 프로세스 흐름은 결정 단계(1014)로 진행하고, 이후 소프트웨어는 특정 구성에 대해 처리될 보다 많은 EMS(203) 이벤트 룰들이 있는지 질문한다. 만약 특정 구성에 대한 추가 EMS(203) 이벤트 룰들이 없다면, 프로세스는 결정 단계(1016)로 진행하고, 여기에서 소프트웨어 모듈은 EMS(203) 이벤트들이 처리되는 추가의 EMS(203) 구성이 있는지를 질문한다. 만약 처리하기 위한 추가의 EMS(203) 구성이 없다면, 소프트웨어 모듈은 단계(1002)에서 잠자는 모드로 동작을 리턴하고, 상기 단계는 이런 프로세스 흐름의 시작이다. 그러나, 만약 EMS(203) 이벤트 룰들을 가진 추가의 EMS(203) 구성들이 있다면, 동작은 단계(1006)로 리턴하고, 상기에서 소프트웨어 모듈은 다시 이런 다른 구성을 위한 EMS(203) 이벤트 룰들에 대한 EMS(203) 트래픽을 평가는 과정을 다시 시작한다.

단계(1010)에서 다시, 이벤트 평가들은 EMS(203) 이벤트 룰 각각에 대해 평가된다. 이 경우, 만약 결정 단계(1012)에서 룰이 액티브하면, 소프트웨어 흐름은 단계(1020)로 진행한다. 단계(1020)에서, 해석기 프로세스(350)는 각각의 트래픽 셀을 평가하고, 여기서 트래픽 셀은 소스 및 목적지부 사이의 단일 접속이고, 데이터 테이블(504)의 단일 셀에 의해 트래픽 모니터(340)에 제공된다. 결정 단계(1022)에서, 만약 단계(1020)의 특정 트래픽 셀의 평가의 포지티브 결과가 포지티브이면("1보다 큰 결과(result greater than one)"), 해석기 프로세스(350) 알고리듬의 실행은 결정 단계(1024)로 계속된다. 결정 단계(1024)에서, 룰 상태는 이전에 트리거되었는지를 보기 위하여 평가된다. 단계(1026)에서 만약 가지지 않았다면, 이벤트 평가는 시작된다. 만약 룰 상태가 이미 트리거되었다면, 이벤트의 실행은 단계(1028)에서 시작될 것이다. 단계(1030)에서 어느 경우나 동작은 계속되고, 이때 프로세스는 특정 이벤트 상태들과 연관된 액션들을 "파이어링(firing)" 하기 위하여 시작된다.

결정 단계(1032)에서, 해석기 프로세스(350)는 이벤트와 연관된 특정 액션이 프로세스 실행시 그것과 연관된 상태를 이미 갖는 것을 질문한다. 만약 없다면, 해석기 프로세스(350)는 특정 액션이 결정 단계(1034)에서 지연되어야 하는 것을 질문한다. 만약 액션이 지연되지 않으면, 특정 액션은 "파이어(fire)"되고 상태는 상기 액션의 활성화를 가리키도록 설정된다. 다음, 결정 단계(1038)에서, 해석기 프로세스(350)는 파이어하기 위한 부가적인 액션이 있는지 질문한다. 만약 있다면, 실행은 단계(1030)로 진행하고; 이 루프에서, 단계들(1030 내지 1039)은 특정 이벤트와 연관된 모든 액션들이 처리될 때까지 계속된다. 일단 단계(1038)에서 "파이어(fire)"하기 위한 액션들이 없다면, 해석시 프로세스(350) 소프트웨어는 평가될 트래픽 셀들이 많은지 심사한다. 만약 평가하기 위한 부가적인 트래픽 셀들이 있다면, 프로세스는 단계(1020)로 리턴한다. 만약 평가하기 위한 트래픽 셀들이 없다면, 프로세스는 결정 단계(1014)로 리턴하고, 여기에서 처리될 부가적인 EMS(203)가 있는지 결정된다. 이런 결정에 기초하여, 상기 프로세스는 이전에 기술된 단계들(1010 또는 1016)에서 계속될 수 있다.

다시 단계(1020)에서 트래픽 셀들을 평가하여, 만약 결정 단계(1022)에서 포지티브 결과 없다면, 프로세스는 단계(1050)로 진행하고, 여기에서 해석기 프로세스(350)는 특정 룰 상태가 이미 ON인지를 질문한다. 만약 아니라면, 이런 룰 상태에 대해 취해질 특정 액션은 없고, 트래픽 셀들의 프로세스는 결정 단계(1040)에서 계속될 수 있다. 그러나, 만약 룰 상태가 이전에 ON이지만, 지금 결정 단계(1050)에서 포지티브 결과에 의해 지시된 상황인 OFF이면, 프로세스는 단계(1052)로 진행하여 특정 룰 상태에 대한 종료 과정을 평가한다. 만약 포지티브 결과가 결정 단계(1054)에서 발생하면, 특정 룰 상태에 대한 이벤트 종료는 단계(1056)에서 처리된다. 그러나, 만약 결정 단계(1054)에서 네가티브 결과에 의해 표시된 바와 같이 실행하기 위한 종료 과정이 없다면, 해석기 프로세스(350)의 알고리듬은 계속 결정 단계(1040) 및 추후 브랜치들을 통하여 부가적인 트래픽 셀들을 처리할 것이다.

도 11을 참조하여, 트래픽 모니터(340)에서 트래픽의 실시간 모니터링을 위하여 EMS(203)의 실시예에 사용될 수 있는 데이터 구조들이 도시될 수 있다. 도 5에 도시된 바와 같이, 몇몇 실시예들에서, 다중 메시지 조정 컴퓨터 프로세스들(320a, 320b)은 사용되어, 단일 트래픽 모니터(340) 및 해석기 프로세스(350)에 대한 다중 접속들은 병렬로 처리된다. 도 11은 궁극적으로 단일 트래픽 모니터에 대한 이런 실시예에서 데이터를 제공한 단일 링 버퍼(1102)에 접속된 다중 상기 컴퓨터 프로세스(320a, 320b)의 MPS(426a-426d)를 도시한다. MPS(426a-426d)는 작은 비동기 데이터 블록들에서 링 버퍼(1102)에 그 들의 데이터를 전송한다. 데이터는 각각의 예에서 하나의 시간 및 세션 IID로 트리거된다. 예를들어, 데이터의 각각의 블록은 헤더로 트리거되고, "SIID8, 00:02는 세션 IID가 세션 번호 8인 것을 가리키고, 데이터의 수신 시간은 00:02인 것을 가리킨다. 이 실시예에서 도시된 세션 IID 및 시간들은 단순히 예시적이고, 수백 또는 수천의 세션 IID들은 사용될 수 있다. 게다가, 가능한 한 수천초 또는 그 이하의 정밀한 시간 지시기들은 사용될 수 있다.

링 버퍼(1102)는 접속 관리자들(322)에 의해 생성된 모든 데이터를 홀딩하고, 관리자들(324), MPS(426a-426d)에 전달하고, 이 실시예에서 데이터를 SIID 순서로 분류하고, 이것은 추후 중간 포맷에 삽입 동안 검색 오버헤드를 감소시키고 데이터를 링 버퍼(1102)에 저장할 때 효율성을 제공할 수 있다. 링 버퍼(1102)로부터, 트래픽 모니터링 데이터는 중간 데이터 구조(1110)로 저장된다. 이런 중간 데이터 구조(1110)에서, 데이터는 세션 IID와 연관된 그룹들(1120)에 배치되고, 여기서 상기 그룹들(1120)은 각각의 접속을 통하여 전송된 각각의 접속(CA, C2...CN) 및 각각의 메시지(M1, M2, M3...)에 대한 기록들을 가진다. 이런 데이터는 링 버퍼(1102)로부터 새로운 데이터로 계속하여 업데이트되고, 데이터가 실제 트래픽 모니터 데이터 매트릭스(1130)에 저장된 데이터보다 오래된 데이터일 때 계속하여 리프레시된다.

데이터 매트릭스(1130)의 구조는 트래픽 모니터 데이터 매트릭스(1130)에 대한 예시적인 포맷이고, 해석기 프로세스(350)에 의해 액세스하기 위하여 유지된다. 중간 데이터 구조(1110)의 사용은 보다 콤팩트한 트래픽 모니터 데이터 매트릭스(1130)를 허용하고, 이것은 비어있는 셀들을 가지지 않도록 구성될 수 있다. 데이터 매트릭스(1130)는 각각의 로우내의 여러 칼럼들과 같은 여러 로우들 및 여러 소스 IPS(SIP 또는 소스들)을 차지하는 여러 IID(목적지부)와 정렬된다. 개별적으로 SIP에 대한 독립적인 컬럼 엔트리들을 가진 각각의 로우를 구성함으로써, 비어있지 않은 셀들을 가진 도 11에 도시된 것과 같은 데이터 테이블 또는 매트릭스(1130)를 형성하는 것을 가능하게 한다. 그 다음, 각각의 셀 내에, 여러 통계치들이 제공되고, 해석기 프로세스(350)는 이들 셀들에 저장된 정보에 기초하여 임의의 활동성을 인식할 수 있을 것이다.

해석기 프로세스(350) 및 다른 리소스들이 트래픽 모니터 데이터 매트릭스(1130)에 액세스하도록 하는 것이 바람직할 수 있다. 적어도 두개의 다른 메카니즘은 데이터 매트릭스(1130)의 내용들에 액세스하도록 제공된다 - 직접 및 투표로. 직접적인 액세스를 통하여, 해석기 프로세스(350)는 실시간으로 셀의 데이터를 판독하기 위하여 데이터 매트릭스(1130)의 주어진 셀을 로킹한다. 투표 액세스를 통하여, 프로세스는 네트워크를 통하여 데이터 매트릭스(1130)의 데이터에 대한 액세스를 요구하기 위하여 다중 리소스들이 제공될 수 있다. 데이터 매트릭스(1130), 또는 데이터 매트릭스(1130)와 연관된 프로세스는 상기 요구들을 중재하고, 임의의 기간에 데이터 매트릭스(1130)의 요구된 데이터를 로킹하고 그 데이터를 요구 리소스들에게 전송한다. 상기 데이터는 오리지널 데이터, 요약 데이터로서 요구되거나, 고객 메일호스트에 의해 요구될 수 있다.

따라서, 현재 기술된 시스템은 모든 인입 요구들 및 요구된 목적지들, 모든 관련 메시지 파라미터들(스팸, 바이러스, 수신자들, 접속 시간, 데이터 크기, 목적지 서버 리턴 코드 등)을 데이터 매트릭스에서 실시간으로 맵핑하고, 수신자 이메일 어드레스들의 임의의 수에 대하여, 또는 다중 고객들에 대한 메일 서버들에 대하여 실시간으로 접속/목적지 매트릭스를 모니터하고, 즉각적으로 트래픽 모니터 데이터 매트릭스(1130)의 상태의 실시간 모니터링에 기초하여 자동으로 즉각적으로 액션을 시작하기 위한 능력을 가진다. 상기된 실시예들에서 처리된 다른 시스템 능력들은 실시간으로 수신자 메일 시스템에 대한 접속을 요구하지만 필수적으로 단일 서버가 아닌 모든 SMTP 접속들을 인식하기 위한 능력들을 포함한다. 상기된 EMS는 또한 다른 것에 대한 액션들을 변형하기 위하여 하나의 고객/수신자로부터 매트릭스 데이터를 사용할 수 있다. 예를 들어, 만약 EMS가 하나의 고객 그룹 쪽으로 액션들에 기초하여 "스패머(spammer)"를 인식하면, EMS는 또한 상기 소스로부터의 스팸이 다른 목적지에 도달하는 것을 방지할 수 있다.

따라서, 여기에 기술된 EMS는 실시간으로 많은 인입 접속들에 대하여 조정, 필터링 및 모니터 및 반응된다. EMS는 또한 서버 또는 다른 조건들에서 로딩하는 것에 기초하여 목적지 이메일 서버에 메시지의 전달을 조절하도록 동작한다. 복수의 목적지 서버들 중에서 스풀 인입 메시지들을 제어된 방식으로 복수의 목적지 서버들에 로딩하는 것을 밸런스할 수 있고, 조건적으로 여러 조건들에 기초하여 목적지 서버들에 메시지들을 전달할 수 있다.

도 12를 참조하여, 하기된 바와 같이 3개의 MPS를 포함하는 스풀 메시지 관리자가 도시된다. 스풀 전달 관리자는 EMS의 메시지 조정 컴퓨터 프로세스에서 동작하는 플러그 인 MPS에 의해 호출되고, 메시지가 스풀링되어야 하는지 스풀링되지 말아야 하는지를 결정하기 위하여 접속 관리자와 조화하여 작업한다. 도 12를 참조하여, 스풀 전달 관리자는 다음과 같이 기능한다:

1) 만약 구성 메일 서버가 도달할 수 없는 것을 결정하면, 스풀링을 시작하기 위하여, 스풀 접속 관리 기록은 구성을 위하여 UI를 통하여 수동으로 또는 해석기 프로세스에 의해 자동으로 삽입되어야 한다.

2) 접속 관리자는 콘맨 테이블에 스풀 접속 관리 기록이 존재하는 구성에 전송된 각각의 메시지에 스풀 태그를 할당한다.

3) 스풀 전달 관리자는 "스풀(Spool)" 태그에 대한 각각의 인입 메시지를 시험한다.

4) 만약 스풀 태그가 메시지에 존재하면, 스풀 전달 관리자는 메시지가 전달된 것을 차단하고, 대신 상기 메시지를 스풀러를 사용하여 스풀 서버에 릴레이한다.

스풀러는 스풀 전달 관리자로부터 메시지를 수신하고, 그것들을 스풀 보관소에 저장하는 스풀 서버에서 작동하는 변형된 MPS 애플리케이션이다. 도 12를 참조하여, 스풀러는 다음과 같은 기능을 한다:

1) 스풀러는 스풀 전달 관리자로부터 SMTP 접속 요구를 기다린다.

2) 오리지널 메시지 데이터를 포함하는 각각의 인입 SMTP 명령은 구성(즉, 보관자의) 스풀 보관소에 저장된다.

3) 만약 스풀 크기가 몇몇 소정 스풀 크기 검사포인트들 중 하나에 도달하면(예를 들어, 75%의 능력), 경고 통지가 생성된다.

4) 만약 메시지를 저장후, 스풀 크기가 구성에 대한 최대 할당 스풀 크기를 초과하면, 경고 표시가 생성되고, 스풀 접속 관리 기록은 제거되어, 추후 메시지들이 스풀링되는 것을 방지한다.

5) 만약 스풀 태그가 메시지에 존재하면, 스풀 전달 관리자는 메시지가 전달되는 것을 방지하고, 대시 SMTP 접속을 사용하여 스풀 서버에 메시지를 릴레이한 다.

디스풀러는 스풀 전달 관리자로부터 메시지들을 하용하고, 극서들을 스풀 보관소에 저장하는 스풀 서버에서 동작하는 변형된 MPS 애플리케이션이다. 이런 목적을 위하여, 디스풀러는 다음과 같이 기능한다.

1) 디스풀러는 스풀 전달 관리자로부터 SMTP 접속 요구를 기다린다.

2) 오리지널 메시지 데이터를 포함하는 각각의 인입 SMTP 명령은 트래픽 모니터에 저장된다.

3) 스풀 전달 관리자는 구성에 대한 적당한 접속 제한을 유지한다.

4) 만약 메시지가 구성에 의해 거절되면, 디스풀러는 메시지를 본래 송신기에게 되돌린다.

5) 만약 메시지가 성공적으로 전달되면, 스풀 보관소에 "전달됨(delivered)"을 태그한다.

단계들 2-5는 스풀 보관소의 모든 메시지들이 전달될때까지 반복된다.

도 13을 참조하여, 본 발명에 따른 EMS에 사용하기 위한 행정 콘솔용 예시적인 액세스 페이지의 스크린 샷(1300)이 도시된다. 도시된 바와 같이 액세스 페이지는 사용자들 및/또는 시스템 관리자들이 전자 메시지 네트워크에서 발생하는 통계 및 알람을 이용할 수 있게 한다. 게다가, 액세스 페이지는 사용자들 및/또는 시스템 관리자들이 전자 메시지들의 전송을 관리하기 위한 EMS에 의해 사용된 룰들의 구성을 위하여 사용될 수 있다. 특히 도시된 액세스 페이지는 "접속 Mgr(Connection Mgr)", "전달 Mgr(Delivery Mgr)", "스풀 Mgr(Spool Mgr)", "경고(Alerts)" 및 "기록들(Reports)"을 포함하는 다중 액세스 탭들을 포함한다. EMS의 이들 개별 성분들의 액세스 외에, 도 13의 액세스 페이지는 각각의 부품들의 상태뿐 아니라, 전자 메시지들의 시스템 쪽으로 흐름의 개요를 제공한다.

도 14를 참조하여, 본 발명에 따른 EMS에 사용된 접속 관리자를 모니터링 및 구성하기 위한 실시예의 스크린 샷(1400)이 도시된다. 도시된 바와 같이, 이런 액세스 페이지는 EMS의 접속 관리자 상태를 디스플레이할 뿐 아니라, 발생된 특정 전송 위반들의 통계들을 제공한다. 비록 도시된 특정 위반 활동들이 디렉토리 하비스트 공격들, 바이러스 발발, 이메일 폭탄들 및 스팸 공격들만이지만, 액세스 페이지는 제한없이 다른 형태의 위반 행동들의 통계를 도시하도록 구성된다.

도 15는 본 발명의 EMS에 사용된 접속 관리자에 대한 다른 예시적인 액세스 페이지의 스크린샷(1500)을 도시한다. 도시된 바와 같이, 이런 액세스 페이지는 필요성이 발생할 때 EMS를 구성하는데 사용자에게 도움을 주도록 인입 전자 메시지들의 특정 위반 액션들에 대한 한정을 제공한다. 게다가, 이런 액세스 페이지는 다양한 검출 및 보호 선택들을 포함하고, 사용자들이 인입 전자 메시지들의 관리를 위한 보다 넓은 선택 범위를 허용한다.

도 16은 본 발명에 따른 EMS에 사용된 전달 관리자를 모니터링하고 구성하는 예시적인 페이지의 스크린 샷(1600)을 도시한다. 이 액세스 페이지는 인입들의 위반 활동들에 응답하여 EMS에 의해 얻어진 특정 전달(또는 비전달) 액션들의 통계치뿐 아니라, EMS의 전달 관리 상태를 디스플레이한다. 게다가, 이런 액세스 페이지는 상기 목적지 서버들의 자유로운 능력을 결정하기 위하여 구별되는 목적지 서버들의 상태를 사용자들이 모니터하도록 한다.

도 17은 EMS에 사용된 전달 관리자에 대한 다른 예시적인 페이지의 스크린 샷을 도시한다. 도시된 바와 같이, 이런 액세스 페이지는 도 16에 도시된 각각의 목적지 서버들의 특정 상세한 것들을 사용자가 구성하도록 한다. 이런 액세스 페이지를 통하여 변경될 수 있는 구성 파라미터들은 접속 능력들뿐 아니라, 본 발명에 의해 제공된 보호를 누리기 위하여 EMS에 새로운 목적지 서버들을 부가하는 것뿐 아니라 접속 능력들을 포함한다.

여기에 개시된 본 원리들 및 EMS의 특정 부품들에 따라 구성된 EMS의 다양한 실시예들은 상기되었고, 예시적인 방법으로써 제공되고, 제한되지 않는다는 것이 이해되어야 한다. 따라서, 본 발명의 범위는 상기된 예시적인 실시예들의 임의의 것에 의해 제한되어서는 안되고, 다음 청구항들 및 그것의 등가물들에 따라서만 제한되어야 한다.

Claims

송신 메일 서버들(102a)로부터 수신 메일 서버들(102c)로의 전자 메시지들(110)의 전송 관리시 컴퓨터 프로세스에 사용하기 위한 메시지 트래픽 관리 시스템으로서, 상기 송신 메일 서버들(102a)로부터 송신된 메시지들(110)은 상기 송신 메일 서버들(102a)과 연관된 소스 데이터 및 상기 수신 메일 서버들(102c)과 연관된 목적지 데이터를 포함하는, 상기 메시지 트래픽 관리 시스템에 있어서,

복수의 인입 전자 메시지들(110)에 대한 상기 소스 데이터를 저장하는 데이터 구조(504)를 갖는 트래픽 모니터(340); 및

상기 데이터 구조(504)에 결합되어, 상기 컴퓨터 프로세스와 연관된 프로그램 스레드들(332)에 의해 결정되는 메타데이터를 상기 소스 데이터에 보충하고 상기 복수의 전자 메시지들(110)과 연관된 특징들을 분석하는 것을 가능하게 하고, 상기 복수의 전자 메시지들(110)의 처리시에 사용하기 위해 상기 소스 데이터 및 상기 메타데이터에 대한 액세스를 가능하게 하도록 구성되는 해석기 프로세스(350)를 포함하는, 메시지 트래픽 관리 시스템.
제 1 항에 있어서,

상기 해석기 프로세스(350)는 상기 복수의 전자 메시지들(110)을 처리하는 처리 명령들(710e)의 생성시에 사용하기 위해 상기 소스 데이터 및 상기 메타데이터에 대한 액세스를 가능하게 하도록 구성되고, 상기 메시지들(110)의 처리는 상기 복수의 전자 메시지들(110) 중 적어도 하나가 도착할 때 SMTP 접속들 중 적어도 하나를 조절(throttling)하는 것을 포함하는, 메시지 트래픽 관리 시스템.
제 1 항에 있어서,

상기 해석기 프로세스(350)는 상기 복수의 전자 메시지들(110)을 처리하는 처리 명령들(710e)의 생성시에 사용하기 위해 상기 소스 데이터 및 상기 메타데이터에 대한 액세스를 가능하게 하도록 구성되고, 상기 메시지들(110)의 처리는 상기 복수의 전자 메시지들(110) 중 적어도 하나의 전달을 지연하는 것을 포함하는, 메시지 트래픽 관리 시스템.
제 1 항에 있어서,

상기 데이터 구조(504)는 상기 복수의 전자 메시지들(110)에 대한 소스 데이터를 상기 복수의 전자 메시지들(110)에 대한 목적지 데이터에 맵핑하는 데이터 테이블(504)을 포함하는, 메시지 트래픽 관리 시스템.
제 1 항에 있어서,

상기 복수의 전자 메시지들(110)의 처리는 상기 복수의 전자 메시지들(110)의 전송을 관리하는 것을 포함하는, 메시지 트래픽 관리 시스템.
제 1 항에 있어서,

상기 복수의 전자 메시지들(110)의 분석에 기초하여 상기 프로그램 스레드들(332)에 의해 결정되는 메타데이터는:

소스 IP 어드레스로부터의 접속 시도들의 카운트;

소스 IP 어드레스로부터의 현재 개방 접속들의 카운트;

소스 IP 어드레스로부터의 접속들의 지속 기간;

소스 IP 어드레스로부터의 메시지들(110)의 카운트;

메시지 크기;

메시지들(110)의 수신들의 카운트;

소스 IP 어드레스로부터의 스팸 메시지들(110)의 카운트;

소스 IP 어드레스로부터의 바이러스 감염 메시지들(110)의 카운트;

원하지 않는 이진이 첨부된 소스 IP 어드레스로부터의 메시지들(110)의 카운트;

원하지 않는 컨텐트를 갖는 소스 IP 어드레스로부터의 메시지들(110)의 카운트; 및

조치 옵션(disposition option)이 차단(block), 블랙홀(black-hole), 스풀(spool), 또는 격리(quarantine)되었던 소스 IP 어드레스로부터의 메시지들(110)의 카운트로 구성되는 그룹으로부터 선택되는, 메시지 트래픽 관리 시스템.
송신 메일 서버들(102a)로부터 수신 메일 서버들(102c)로의 전자 메시지들(110)의 전송 관리시 컴퓨터 프로세스에 사용하는 방법으로서, 상기 송신 메일 서버들(102a)로부터 송신된 메시지들(110)은 상기 송신 메일 서버들(102a)과 연관된 소스 데이터 및 상기 수신 메일 서버들(102c)과 연관된 목적지 데이터를 포함하는, 상기 전자 메시지들(110)의 전송 관리시 컴퓨터 프로세스에 사용하는 방법에 있어서,

복수의 인입 전자 메시지들(110)에 대한 상기 소스 데이터를 저장하는 단계;

상기 컴퓨터 프로세스와 연관된 프로그램 스레드들(332)에 의해 결정되는 메타데이터를 상기 소스 데이터에 보충하고 상기 복수의 전자 메시지들(110)과 연관된 특징들을 분석하는 단계;

상기 복수의 전자 메시지들(110)의 특징들의 분석에 기초하여 상기 컴퓨터 프로세스에 의해 결정되는 메타데이터를 상기 소스 데이터에 보충하는 단계; 및

상기 소스 데이터 및 상기 메타데이터에 기초하여 상기 복수의 전자 메시지들(110)을 상기 컴퓨터 프로세스로 처리하는 단계를 포함하는, 전자 메시지들(110)의 전송 관리시 컴퓨터 프로세스에 사용하는 방법.
제 7 항에 있어서,

상기 처리하는 단계는 상기 복수의 전자 메시지들(110)의 처리시에 사용하기 위해 상기 소스 데이터 및 상기 메타데이터에 기초하여 처리 명령들(710e)을 생성하는 단계를 포함하고, 상기 메시지들(110)의 처리는 상기 복수의 전자 메시지들(110) 중 적어도 하나가 도착할 때 SMTP 접속들 중 적어도 하나를 조절하는 것을 포함하는, 전자 메시지들(110)의 전송 관리시 컴퓨터 프로세스에 사용하는 방법.
제 7 항에 있어서,

상기 처리하는 단계는 상기 복수의 전자 메시지들(110)의 처리시에 사용하기 위해 상기 소스 데이터 및 상기 메타데이터에 기초하여 처리 명령들(710e)을 생성하는 단계를 포함하고, 상기 메시지들(110)의 처리는 상기 복수의 전자 메시지들(110) 중 적어도 하나의 전달을 지연하는 것을 포함하는, 전자 메시지들(110)의 전송 관리시 컴퓨터 프로세스에 사용하는 방법.
제 7 항에 있어서,

상기 보충하는 단계는:

소스 IP 어드레스로부터의 접속 시도들의 카운트;

소스 IP 어드레스로부터의 현재 개방 접속들의 카운트;

소스 IP 어드레스로부터의 접속들의 지속 기간;

소스 IP 어드레스로부터의 메시지들(110)의 카운트;

메시지 크기;

메시지들(110)의 수신들의 카운트;

소스 IP 어드레스로부터의 스팸 메시지들(110)의 카운트;

소스 IP 어드레스로부터의 바이러스 감염 메시지들(110)의 카운트;

원하지 않는 이진이 첨부된 소스 IP 어드레스로부터의 메시지들(110)의 카운트;

원하지 않는 컨텐트를 갖는 소스 IP 어드레스로부터의 메시지들(110)의 카운트; 및

조치 옵션이 차단, 블랙홀, 스풀, 또는 격리되었던 소스 IP 어드레스로부터의 메시지들(110)의 카운트로 구성되는 그룹으로부터 선택된 상기 복수의 전자 메시지들(110)의 분석에 기초하여 상기 프로그램 스레드들(332)에 의해 결정되는 메타데이터를 상기 소스 데이터에 보충하는 단계를 더 포함하는, 전자 메시지들(110)의 전송 관리시 컴퓨터 프로세스에 사용하는 방법.
송신 메일 서버들(102a)로부터 수신 메일 서버들(102c)로의 전자 메시지들(110)의 전송 관리시에 사용하기 위한 전자 메시지 관리 시스템(203)으로서, 상기 송신 메일 서버들(102a)로부터 송신된 메시지들(110)은 상기 송신 메일 서버들(102a)과 연관된 소스 데이터 및 상기 수신 메일 서버들(102c)과 연관된 목적지 데이터를 포함하는, 상기 전자 메시지 관리 시스템(203)에 있어서,

복수의 인입 전자 메시지들(110)에 대한 상기 소스 및 목적지 데이터를 저장하는 데이터 매트릭스(1130)를 구비한 트래픽 모니터(340);

상기 트래픽 모니터에 결합되어, 상기 복수의 전자 메시지들(110)로부터 도출된 메타데이터를 상기 소스 및 목적지 데이터에 보충하도록 구성되는 메시지 조정 프로세스(320); 및

상기 트래픽 모니터에 인터페이스를 제공하여, 상기 소스 및 목적지 데이터와 상기 메타데이터에 액세스하고 그에 기초하여 처리 명령들(710e)을 생성하도록 구성되는 해석기 프로세스(350)를 포함하고,

상기 메시지 조정 프로세스(320)는 상기 처리 명령들(710e)에 기초하여 상기 복수의 전자 메시지들(110)의 전송을 관리하도록 또한 구성되는, 전자 메시지 관리 시스템(203).
제 11 항에 있어서,

상기 메시지 조정 프로세스(320)는 상기 소스 및 목적지 데이터를 추출하고, 상기 처리 명령들(710e)에 기초하여 상기 송신 메일 서버들(102a)로부터 상기 복수의 전자 메시지들(110)을 수용하도록 구성되는 접속 관리 모듈(322)을 포함하는, 전자 메시지 관리 시스템(203).
제 11 항에 있어서,

상기 메시지 조정 프로세스(320)는 상기 처리 명령들(710e)에 기초하여 상기 복수의 전자 메시지들(110)을 상기 수신 메일 서버들(102c)에 전달하도록 구성되는 전달 모듈(324)을 포함하는, 전자 메시지 관리 시스템(203).
제 11 항에 있어서,

상기 목적지 데이터는 상기 수신 메일 서버들(102c)의 오리지널 전달 어드레스들을 포함하고, 상기 메시지 조정 프로세스(320)는 상기 전자 메시지 관리 시스템(203)의 전달 어드레스를 상기 오리지널 전달 어드레스들과 연관시킴으로써 상기 복수의 전자 메시들(110)을 인터셉트하도록 또한 구성되는, 전자 메시지 관리 시스템(203).
복수의 전자 메시지들(110)을 전송하기 위한 전자 메시징 네트워크와 연관된 데이터 구조(504)가 기록된 컴퓨터 판독 가능한 기록 매체로서, 상기 네트워크는 적어도 송신 메일 서버(102a) 및 수신 메일 서버(102c)를 포함하고, 상기 데이터 구조(504)는:

상기 복수의 전자 메시지들(110)로부터 추출된 소스 데이터를 포함하도록 구성된 소스 데이터 필드들로서, 상기 소스 데이터는 적어도 상기 송신 메일 서버(102a)와 연관된 데이터를 포함하는, 상기 소스 데이터 필드들;

상기 복수의 전자 메시지들(110)로부터 추출된 목적지 데이터를 포함하도록 구성된 목적지 데이터 필드들로서, 상기 목적지 데이터는 적어도 상기 수신 메일 서버(102c)와 연관된 데이터를 포함하는, 상기 목적지 데이터 필드들; 및

상기 복수의 전자 메시지들(110)의 전송을 관리하기 위해 메시지-처리 데이터를 포함하도록 구성된 처리 필드들로서, 상기 메시지 처리 데이터는 상기 복수의 전자 메시지들(110)로부터 도출된 메타데이터와 상기 소스 및 목적지 데이터에 기초하는, 상기 처리 필드들을 포함하는, 데이터 구조(504)가 기록된 컴퓨터 판독 가능한 기록 매체.
제 15 항에 있어서,

상기 메시지 처리 데이터는 상기 복수의 전자 메시지들(110)을 처리하는 메시지 조치 명령들(710e)을 포함하는, 데이터 구조(504)가 기록된 컴퓨터 판독 가능한 기록 매체.
제 15 항에 있어서,

상기 메타데이터는 원하지 않는 전자 메시지들(110) 및 원하지 않는 전자 메시지 전달 시도들을 검출하기 위해 프로그램 스레드들(332)을 사용하여 상기 복수의 전자 메시지들(110)로부터 도출되는, 데이터 구조(504)가 기록된 컴퓨터 판독 가능한 기록 매체.
제 15 항에 있어서,

상기 소스 데이터 필드들 및 목적지 데이터 필드들은 데이터 매트릭스(1130)를 포함하는, 데이터 구조(504)가 기록된 컴퓨터 판독 가능한 기록 매체.
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제