KR20150038459A

KR20150038459A - 다이렉트 전자 메일

Info

Publication number: KR20150038459A
Application number: KR1020157005147A
Authority: KR
Inventors: 이고르 페인버그; 후이-란 루; 프랑소와 코스쿠어
Original assignee: 알까뗄 루슨트
Priority date: 2012-08-28
Filing date: 2013-08-15
Publication date: 2015-04-08
Also published as: CN104604188A; WO2014035674A1; US20140067962A1; US9338119B2; KR101642665B1; JP2018101424A; JP2015534668A

Abstract

통신 네트워크에서의 향상된 전자 메일 처리를 가능하게 하는 기술이 개시된다. 예를 들어, 전자 메일 시스템에서 전자 메일 메시지를 처리하는 방법은 다음의 단계를 포함한다. 전자 메일 시스템에서 메시지 송신자의 클라이언트와 메시지 수신자의 서버 사이의 안전한 접속이 설정된다. 메시지 송신자의 클라이언트의 ID를 검증하기 위해 인증 교환이 이용된다. 메시지 송신자의 클라이언트의 ID의 성공적인 검증 시에 메시지 송신자는 메시지 수신자의 서버에 전자 메일 메시지를 맡긴다.

Description

다이렉트 전자 메일{DIRECT ELECTRONIC MAIL}

본 발명은 일반적으로 통신 네트워크에 관한 것이고, 더 구체적으로는, 이러한 통신 네트워크에서 향상된 전자 메일 프로세싱을 가능하게 하는 기술에 관한 것이다.

월드 와이드 웹(World Wide Web) 내에서 이용되는 기존 전자 메일(이메일) 시스템은 "SMTP(Simple Mail Trasfer Protocol)"라는 명칭의 IETF(Internet Engineering Task Force) RFC(Request for Comment) 5321 및 "인터넷 메시지 포맷"이라는 명칭의 RFC 5322에서 설명되고, 이들의 개시는 그 전체가 본원에 참조로써 통합된다.

통상적으로, 이메일은 이메일 클라이언트 애플리케이션을 통해 송신자에 의해 생성되고 수신자로의 이메일 송신을 처리하기 위해 SMTP 서버에 제공된다. SMTP 서버는 이메일을 전달하기 위해 다른 SMTP 서버와 통신할 수 있다. 더 구체적으로는, 이메일 클라이언트 애플리케이션은 SMTP 서버에게 송신자의 어드레스 및 수신자의 어드레스를 통지하고, 메시지의 바디를 제공한다. 이메일이 외부 도메인으로 전달되어질 경우에, 발신 SMTP 서버는 DNS(a domain name server)와 통신하여, 외부(목적지) 도메인에 대해 SMTP 서버를 위한 하나 이상의 IP(Internet Protocol) 어드레스로서 회신한다. 발신 SMTP 서버는 목적지 SMTP 서버 중 하나와 통신하고 이메일을 목적지 SMTP 서버에 제공한다. SMTP 서버는 서버 대 서버(server-to-server) 프로토콜을 통해 통신한다.

다양한 서버 대 서버 프로토콜에 대한 필요성뿐만 아니라, 기존 이메일 시스템의 다른 주요한 단점은 피싱(phising)(즉, 전자 통신에서 신뢰할 수 있는 엔티티로 가장함으로써 정보를 얻는 시도) 및 바이러스 배포와 같은 악성 형태를 포함하는 원치않는 메일(또는 "스팸")의 존재이다.

본 발명의 실시예는 통신 네트워크에서 향상된 전자 메일 처리를 가능하게 하는 기술을 제공한다.

예를 들어, 일 실시예에서, 전자 메일 시스템에서 전자 메일 메시지를 처리하는 방법은 다음의 단계를 포함한다. 전자 메일 시스템에서 메시지 송신자의 클라이언트와 메시지 수신자의 서버 사이의 안전한 접속이 설정된다. 메시지 송신자의 클라이언트의 ID(identity)를 검증하기 위해 인증 교환이 이용된다. 메시지 송신자의 클라이언트의 ID의 성공적인 검증 시에 메시지 송신자의 클라이언트는 메시지 수신자의 서버에 전자 메일 메시지를 보관한다.

다른 실시예에서, 전자 메일 시스템에서 전자 메일 메시지를 처리하는 방법은 다음의 단계를 포함한다. 전자 메일 시스템에서 메시지 송신자의 클라이언트와 메시지 수신자의 서버 사이의 안전한 접속이 설정된다. 메시지 송신자의 클라이언트의 ID를 검증하기 위해 인증 교환이 이용된다. 메시지 송신자의 클라이언트의 ID의 성공적인 검증 시에 메시지 수신자의 서버는 메시지 송신자의 클라이언트에 의해 송신된 전자 메일 메시지를 수신한다.

또 다른 실시예에서, 전자 메일 시스템에서 전자 메일 메시지를 처리하는 장치는 메모리에 연결되고 주어진 방법에 대해 위에서 언급된 단계들을 수행하게 클라이언트 또는 서버를 실행시키도록 구성되는 프로세서를 포함한다.

추가 실시예에서, 제조 물품은 프로세서에 의해 실행될 때 주어진 방법에 대해 위에서 언급된 단계들을 수행하는 하나 이상의 소프트웨어를 저장한 프로세서 판독가능 저장 매체를 포함한다.

유리하게, 본 발명의 예시적인 실시예는 송신자 인증을 제공함으로써 원치않는 메일을 감소시키거나 제거하고, 기존 이메일 메시지 시스템에서 이메일 메시지를 전달할 필요가 있는 서버 대 서버 프로토콜을 감소시키거나 제거한다.

본 발명의 여러 특징 및 장점은 첨부한 도면 및 다음의 상세한 설명으로부터 더 명백해질 것이다.

도 1은 본 발명의 일 실시예에 따라, 다이렉트 전자 메일 시스템을 도시하는 도면이다.
도 2는 본 발명의 일 실시예에 따라, 다이렉트 전자 메일 시스템에서 클라이언트와 서버 사이의 안전한 접속의 설정을 도시하는 도면이다.
도 3은 본 발명의 실시예에 따라, 다이렉트 전자 메일 클라이언트에 의해 수행되는 방법을 도시하는 도면이다.
도 4는 본 발명의 실시예에 따라, 다이렉트 전자 메일 시스템에서의 인증 동작을 위한 메시지 플로우를 도시하는 도면이다.
도 5는 본 발명의 다른 실시예에 따라, 다이렉트 전자 메일 시스템에서의 인증 동작을 위한 메시지 플로우를 도시하는 도면이다.
도 6은 본 발명의 또 다른 실시예에 따라, 다이렉트 전자 메일 시스템에서의 인증 동작을 위한 메시지 플로우를 도시하는 도면이다.
도 7은 본 발명의 실시예에 따라, 다이렉트 전자 메일 시스템을 구현하기에 적합한 통신 네트워크의 컴퓨팅 아키텍쳐를 도시하는 도면이다.

예시의 통신 프로토콜의 콘텍스트에서 본 발명의 실시예가 이하에서 설명될 것이다. 하지만, 본 발명의 실시예는 임의의 특정 통신 프로토콜에 제한되는 것이 아님이 이해될 것이다. 오히려, 본 발명의 실시에는 향상된 전자 메일 처리를 제공하는 것이 바람직한 임의의 적합한 통신 환경에 적용가능하다.

본원에서 사용되는 것과 같은 "통신 네트워크"라는 문구는 일반적으로, 텍스트 기반 데이터, 그래픽 기반 데이터, 음성 기반 데이터 및 비디오 기반 데이터를 포함하지만 이에 제한되지않는, 하나 이상의 타입의 미디어를 전달하는 것이 가능한 임의의 통신 네트워크 또는 시스템으로서 정의된다. 이러한 통신 네트워크를 거쳐 구현되는 전자 메일 시스템의 경우에, 통상적으로 전자 메일 시스템을 통해 전송되는 메시지(이메일)는 텍스트 기반 메시지이다. 하지만, 이들 텍스트 기반 메시지는 다른 타입의 미디어(예를 들어, 비디오, 이미지, 오디오, 그래픽, 및 텍스트 등)를 포함하는 첨부물을 가질 수 있다.

본원에서 사용되는 것과 같은 "안전한 접속"이라는 문구는 일반적으로 개입된 엔티티의 인증에 기초하여 암호화 수단에 의해 비밀 또는 무결성(또는 둘 다)이 보호되는 통신 접속으로서 정의된다. 또한, 통상적으로, 안전한 접속을 통해 전달된 메시지는 재생될 수 없다.

또한, 본원에서 사용되는 것과 같은, "서버"는 일반적으로, 통신 네트워크, 클라이언트 및/또는 다른 서버로부터의 요청시에 하나 이상의 기능을 수행하는, 하나 이상의 컴퓨팅 디바이스 및/또는 하나 이상의 소프트웨어 프로그램으로서 정의된다. 따라서, 예를 들어, "이메일 서버"는 하나 이상의 이메일 전달 기능을 수행한다. 본 발명의 예시적인 실시예에서 이용되는 서버는 웹 서버가 되는 것으로 가정된다(즉, 이들은 HTTP(HyperText Transfer Protocol) 표준을 지원하는 것으로 가정된다).

본원에서 사용되는 것과 같은, "클라이언트"는 일반적으로, 통신 네트워크, 서버 및/또는 다른 클라이언트로부터 하나 이상의 기능을 요청하는, 하나 이상의 컴퓨팅 디바이스 및/또는 하나 이상의 소프트웨어 프로그램으로서 정의된다. 클라이언트와 연관된 디바이스의 예시는, 셀룰러 폰, 스마트 폰, 태블릿, 데스크탑 폰, 개인용 디지털 보조장치, 랩탑 컴퓨터, 개인용 컴퓨터 등을 포함하지만, 이에 제한되지 않는다. 또한, 컴퓨팅 디바이스 또는 소프트웨어 프로그램은 하나의 목적을 위한 서버 및 다른 목적을 위한 클라이언트가 될 수 있고, 키 정의 요소는 HTTP 프로토콜과 관련한 개별적인 기능이 된다.

따라서, 일례에서 "이메일 클라이언트"는 "이메일 서버"로부터 하나 이상의 이메일 전달 기능을 요청한다. 이메일 클라이언트는 또한 사용자에게 그중에서도 이메일을 판독하고 이메일을 생성하는 기능을 제공한다.

위의 기존 이메일 시스템의 논의로 돌아가면, 인증이 기존 이메일 시스템에서 어려운 주요 원인은 시스템이 상호 서버 프로토콜 교환 및 다양한 액세스 프로토콜과 함께 다수의 메일 서버를 이용하기 때문이다. 기존 이메일 시스템이 갖는 주요 문제점은 격세적(atavistic)(즉, 1970년대에 설계되고 이전 웹 인프라스트럭쳐를 반영함)이라는 것이다. 그 때, 네트워킹은 신뢰할 수 없어서 클라이언트와 원격 서버 사이의 직접 실시간 동기화 통신은 고려되지 못했다. 오늘날, 서버에서의 로드 밸런싱 및 전세계적인 접속으로 인해, 상황이 대폭적으로 변화하였다. 이에 제한되는 것은 아니지만, 본 발명의 예시적인 실시예는 웹 활용에서의 최신기술에 의존한다.

따라서, 본원에서 전세계적인 서버 발견 및 클라이언트 대 서버 접속의 발전으로, 기존 이메일 시스템은 상당히 단순화될 수 있음이 인식된다. 따라서, 본 발명의 하나 이상의 실시예에서, 우리는 메시지의 수신자 및 송신자가 개별 서버를 갖는 기준 이메일 인프라스트럭쳐를 변경하여서, 이메일의 수신자에 대해 단일 서버가 이용된다. 즉, 수신자는 이메일이 전달되도록 하기 위해 이와 연관된 다수의 서버를 갖지 않는다. 송신자는 이메일을 전달하도록 단순히 단일 수신자 서버에 접속되어야해서, 임의의 서버 대 서버 프로토콜에 대한 필요성을 제거한다.

이 서버 대 서버 프로토콜은 전세계적인 접속 및 "주문형(on-demand)" 연산력에서 불필요하게 복잡해지는 것뿐만 아니라 인증 특징이 빠져있기 때문에, 본 발명의 실시예는 이러한 문제점들을 함께 제거한다. 더 구체적으로는, 본 발명의 실시예는 송신자가 이메일을 직접(다이렉트 이메일) 수신자의 서버에 보관하는 것을 제공하고 수신자의 필요에 따라 서버가 송신자를 인증하는 것을 가능하게 한다.

따라서, 다이렉트 이메일(본원에서 "디메일(dmail)"로서 지칭함)은 기존 이메일 시스템 인프라스트럭쳐를 상당히 단순화시키고 또한 인증되지 않은 포스팅을 방지한다. 일례에서, "다이렉트"라는 용어는 이메일 클라이언트 및 이메일 서버가 IP(Internet Protocol)의 애플리케이션 레이어의 관점에서 종단점이 되는 것을 지칭한다. 알려진 바와 같이, TCP/IP(Transmission Control Protocol/Internet Protocol) 프로토콜 군(suite)에서 애플리케이션 레이어는 IP 네트워크를 통한 프로세스 대 프로세스 통신의 카테고리에 속하는 프로토콜 및 방법을 포함한다. 컴퓨팅 네트워킹의 OSI 모델(Open Systems Interconnection model)은 또한 이름 애플리케이션 레이어에 의해 식별된 프로토콜 및 방법의 그룹을 특정한다. 따라서, 이메일 송신자의 클라이언트 및 이메일 수신자의 서버가 애플리케이션 레이어에서 일대일로 통신한다는 점에서 이메일 송신자의 클라이언트와 메시지 수신자의 서버 사이의 통신(여기서, 예를 들어, 메시지 수신자는 다른 이메일 클라이언트 또는 목적지 이메일 클라이언트이다)은 직접적이다. 이는 이메일 메시지가 이메일 클라이언트와 이메일 서버를 구현하는 디바이스들 사이에 존재하는 매개 디바이스/서버(예를 들어, 프록시, 파이어월, 라우터, 및 스위치)를 통과할 수 없음을 의미하지는 않지만 매개 디바이스/서버의 존재는 디메일 전달과는 무관함이 이해될 것이다.

하나 이상의 실시예에서, 다이렉트 메일 개념은, HTTP(설명된 바와 같이, 예를 들어, IETF RFC 2616에서, 이의 개시는 본원에서 참조로서 그 전체가 통합된다), 웹소켓 프로토콜(설명된 바와 같이, IETF RFC 6544에서, 이의 개시는 본원에서 참조로서 그 전체가 통합된다), 및 HTML5(HyperText Markup Language Version 5)(W3C(World Wide Web Consortium)에 의해 개발됨)을 포함하는 브라우저 기술에 기초한다. HTML 5는 통상적으로 클라이언트 측 프로그래밍 문제에 적용한다는 것이 이해될 것이다.

일 실시예에서, 디메일 클라이언트는 고유하게 구현되거나 브라우저 프로그램을 통해 액세스되는 웹 애플리케이션으로서 구현될 수 있다. 유리하게, 디메일 시스템은 이전 웹 이메일 릴레이 인프라스트럭쳐를 수신자의 메일 서버로의 인스턴트 통신으로 교체한다. 하지만, 새로운 방법/프로토콜은, 특히 수신 측 상에서 기존 SMTP 메일 서버 기능과 쉽게 공존할 수 있다.

도 1은 본 발명의 일실시예에 따른, 다이렉트 전자 메일(디메일) 시스템을 도시하는 도면이다. 더 구체적으로는, 도면은 디메일 클라이언트와 디메일 서버 사이의 인터페이스가 HTTP에 기초하는 실시예를 도시한다.

도시된 바와 같이, 디메일 시스템(100)은 ID 제공자(102), 디메일 클라이언트(104), DNS 서버(106) 및 디메일 서버(110)를 포함한다. 디메일 서버(110)는 웹 액세스 모듈(112), 메일 저장부(114) 및 디렉토리(116)를 포함한다.

ID 제공자(102)는 엔티티에 대한 ID 정보를 생성, 유지, 및 관리하고 통신 네트워크 내에서 다른 서비스 제공자로 엔티티 인증을 제공하는 제공자 엔티티이다.

디메일 클라이언트(104)는, 위에서 언급된 바와 같이, 엔티티에 대한 전자 메시지를 관리하는 하나 이상의 컴퓨팅 디바이스 및/또는 하나 이상의 소프트웨어 프로그램이 될 수 있다. 디메일 클라이언트와 연관된 디바이스의 예시는 셀룰러 폰, 스마트 폰, 태블릿, 데스크탑 폰, 개인용 디지털 보조장치, 랩탑 컴퓨터, 개인용 컴퓨터 등을 포함하지만, 이에 제한되지 않는다. 따라서, 클라이언트는 하나 이상의 이들 디바이스 및/또는 이러한 디바이스와 연관된 하나 이상의 소프트웨어 프로그램을 고려할 수 있다.

DNS 서버(106)는 요청시에 디메일 클라이언트(104)에게 의도된 메시지 수신자와 연관된 디메일 서버의 IP 어드레스를 제공하는 도메일 이름 서버이다.

웹 액세스 모듈(112)은 HTTP 프로토콜의 서버 측을 구현하는 이메일 서버에서의 모듈이다.

디렉토리(116)는 이메일 서버(110)의 파일 시스템과 연관된 디렉토리이다.

메일 저장부(114)는 이메일 클라이언트에 의해 보관된 디메일 메시지가 저장되는 메모리이다.

도 2는 본 발명의 일 실시예에 따라, 다이렉트 전자 메일 시스템에서 클라이언트와 서버 사이의 안전한 접속의 설정을 도시하는 도면이다. 즉, 메시지를 보관하거나 검색하기 위해, 도 2에서 도시된 바와 같이, 디메일 클라이언트는 디메일 서버와의 안전한 접속을 설정한다.

도시된 바와 같이, 디메일 클라리언트(202)는 디메일 서버(204-1, 204-2 및 204-3)와 통신 중이다. 유리하게, 애플리케이션 레이어에서, 위에서 설명된 바와 같이, 디메일 클라이언트는 디메일 서버와의 직접 통신 중이다. 따라서, 이메일 송신자가 이메일 메시지를 보관하기 위해 통신해야만 하는 애플리케이션 레벨, 즉, 이메일 수신자의 서버에서 오직 하나의 서버만이 존재하기 때문에, 전통적인 SMTP 이메일 시스템과 연관된 임의의 서버 대 서버 프로토콜에 대한 필요성이 존재하지 않는다.

각각의 디메일 서버는 하나 이상의 주어진 디메일 클라이언트에 대한 디메일 서버이다. 예를 들어, 디메일 서버(204-1)는 디메일 클라이언트(206-1)의 디메일 서버이고, 디메일 서버(204-2)는 디메일 클라이언트(206-2)의 디메일 서버이고, 디메일 서버(204-3)은 디메일 클라이언트(206-3)의 디메일 서버이다. 이 예시의 시나리오에서, 디메일 클라이언트(202)는 디메일 "송신자" 또는 디메일 소스이고 따라서 하나 이상의 디메일 서버(204-1, 204-2 및 204-3)에 하나 이상의 이메일 메시지를 보관하고, 반면 하나 이상의 디메일 클라이언트(206-1, 206-2 및 206-3)는 디메일 "수신자" 또는 디메일 목적지이고 따라서 하나 이상의 디메일 서버(204-1, 204-2 및 204-3)로부터 하나 이상의 보관된 이메일 메시지를 검색한다. 당연히, 디메일 클라이언트(202)는 또한 다른 이메일의 수신자가 될 수 있는 반면, 디메일 클라이언트(206-1, 206-2 및 206-3) 중 어느 하나 이상은 또한 다른 이메일의 송신자가 될 수 있다.

안전한 접속(208)은 디메일 클라이언트(202)와 디메일 서버(204-1, 204-3 및 204-3) 사이에 각각 설정되는 반면, 안전한 접속(210)은 디메일 클라이언트(206-1, 206-2 및 206-3)와 디메일 서버(204-1, 204-3 및 204-3) 사이에 각각 설정된다. 이러한 안전한 접속의 예시는 이하에서 더 설명될 것이다.

도 3은 디메일 클라이언트에 의해 디메일 서버에 이메일 메시지를 보관하기 위한 방법(300)을 도시한다(예를 들어, 도 2에서 디메일 서버(204-1, 204-3 및 204-3)에 대한 디메일 클라이언트(202)).

단계(302)에서, 디메일 클라이언트는 수신자의 인터넷 식별자 또는 URI(예를 들어, dmail://igor.faynberg@alcatel-lucent.com)에 기초하여 대상 디메일 서버의 IP 어드레스를 DNS 서버(예를 들어, 도 1의 DNS 서버(106))를 통해 발견한다. 따라서, 도 2를 다시 참조하면, 디메일 클라이언트(206-3)와 연관된 이메일 수신자의 URI가 dmail://igor.faynberg@alcatel-lucent.com이면, 그 다음 송신 디메일 클라이언트(202)는 DNS 서버로부터 디메일 수신자의 디메일 서버, 이 경우에 디메일 서버(204-3)의 IP 어드레스를 획득한다.

단계(304)에서, 디메일 클라이언트는 수신자의 디메일 서버와 직접 안전한 세션(예를 들어, 도 2에서의 안전한 접속(208))을 설정한다. 송신자 인증이 획득되고 특정한 타입의 첨부물이 이메일 제공자의 정책 또는 수신자의 선호도 또는 둘 다에 따라서 금지될 수 있다.

접속 실패의 경우에, 기존 이메일 표준 프로시져의 경우에서처럼, 디메일 클라이언트는 접속이 설정될 때까지 자체 소유의 저장부를 사용하여, 설정가능한 파라미터에 따라, 재시도를 구현할 책임이 있다. 이메일 소프트웨어로 현재 실시되는 것처럼, 클라이언트 소유의 저장부는 당연히 접속이 없는 경우에, 오프라인으로 작동하기 위해 사용될 수 있다.

단계(306)에서, 디메일 클라이언트는 임의의 허용된 첨부물과 함께, 송신자의 메시지를 보관한다.

단계(308)에서, 디메일 클라이언트는 전달 수신확인을 획득한다. 일례에서, 수신확인은 이 수신의 날짜와 시각과 함께 메시지의 서명된 해시(a signed hash)가 될 수 있다.

단계(304)를 통해 본 발명의 예시적인 실시예에 따라 이메일 보안 향상이 달성됨에 유의해야한다. 예시로서, 도 4는 안전한 세션 설정의 일례를 포함하는 디메일 클라이언트-디메일 서버 인터랙션을 더 설명한다.

도 4는 본 발명의 실시예에 따라, 다이렉트 전자 메일 시스템에서의 인증 동작을 위한 메시지 플로우를 도시하는 도면이다. 더 구체적으로, 도 4는 디메일 클라이언트(402)와 디메일 서버(404) 사이의 프로토콜(400)을 도시한다. 디메일 서버(404)는 특정 메시지 수신자(도시되지 않음)의 디메일 서버이다.

도시된 바와 같이, 단계(406)에서, 이메일의 작성자가 메시지를 생성하는 동안 디메일 클라이언트는 이메일 메시지를 주기적으로 저장한다.

단계(408)에서 프로토콜(400)은 디메일 클라이언트(402)와 디메일 서버(404)와 함께 TLS(Transport Layer Security) 접속을 설정하는 것을 시작한다. 알려진 바와 같이, TLS는 인터넷을 통한 보안을 제공하는 암호화 프로토콜이고 "TLS(Transport Layer Security) 프로토콜," 버전 1.2이라는 명칭의 IEFT RFC 5246에서 정의되며, 이의 개시는 본원에서 참조로써 그 전체가 통합된다. TLS 접속은 디메일 클라이언트와 디메일 서버 사이의 통신을 보호한다. TLS 접속은 또한 디메일 클라이언트와 ID 제공자 사이의 접속을 보호할 수 있으며 이하에서 더 언급된다. ID 제공자가 동일한 인트라넷 내에서 디메일 클라이언트로서 존재한다면, 통상적으로 TLS 접속은 활용되지 않을 것이다.

단계(410)에서, 디메일 세션 설정 요청이 디메일 클라이언트(402)로부터 디메일 서버(404)로 송신된다. 단계(412)에서, 디메일 클라이언트(402)가 인증되지 않았다면, 디메일 서버(404)는 디메일 클라이언트에게 리턴 인증 요청을 송신한다. 단계(414)에서, 디메일 클라이언트(402)는 자신의 ID를 증명하는 대상인, ID 제공자(415)와 인터랙션한다. 그 결과로서, 디메일 클라이언트(402)는 토큰(token) 또는 단언(assertion)(ID 정보)을 수신하여 이것이 무엇/누구가 된다고 주장하는지를 증명하기 위해 디메일 서버(404)에게 제시될 수 있다.

단계(416)에서 디메일 클라이언트(402)는 HTTP 포스트(POST) 요청을 통해 디메일 서버(404)로 ID 정보를 송신한다. 단계(418)에서, 디메일 서버(404)는 인정 정보를 검증한다. 이를 위해, 디메일 서버는 ID 제공자(415)와 구분적으로 통신할 수 있지만, 이는 적합하게 서명된 토큰이 존재하면 스킵될 수 있다. 이 경우에, ID 제공자(415)는 오직 서버의 서명을 검증하는 것만이 필요하다.

단계(420)에서, 디메일 클라이언트(402)가 검증된다면, 디메일 서버(404)는 확인응답 메시지(HTTP RETRUN 200 OK 메시지)를 디메일 클라이언트(402)로 송신한다.

한번 인증된다면, 단계(422)에서, 디메일 클라이언트(402)는 HTTP 포스트(POST) 요청을 통해 디메일 서버(404)에 이메일 메시지를 보관한다. 단계(424)에 도시된 바와 같이, (단계(422)에서의) 메시지의 송신자가 인증된 ID(즉, 단계(418)에서 검증되어진 엔티티)와 정합할 경우 디메일 서버(404)는 이메일 메시지를 처리하는 것을 진행한다. 그렇다면, 디메일 서버(404)는 URI를 포스팅된 메시지에 저장하고 할당한다.

단계(426)에서, 디메일 서버(404)는 HTTP 리다이렉트(Redirect) 명령을 디메일 클라이언트(402)에 송신한다. 응답으로, 단계(428)에서, 디메일 클라이언트(402)는 리다이렉트된 URI(즉, 디메일 서버(404)에 의해 단계(424)에서 이메일 메시지에 할당된 URI)를 획득하기 위해 HTTP 획득(GET) 요청을 디메일 서버(404)에 발행한다. 이 포스트-리다이렉트-획득(Post-Redirect-Get) 프로시져는, REST 프레임워크(Representational State Transfer framework), 즉, 월드 와이드 웹(World Wide Web)과 같은 분산된 통신 네트워크에서 사용되는 웹 서비스 설계 모델에서 일반적이다. 서버가 통상적으로 상태를 갖지 않기 때문에 PRG가 사용되며, 세 가지 방법(PRG)의 조합은 클라이언트가 리소스를 보게하는 것을 가능하게 한다. 예를 들어, 당신이 웹 상에서 주문을 하기 위해 양식을 기입할 때, 이를 클릭하여 송신하면 이를 볼 수 없게 될 것이다. 당신이 리턴할 수 있는 리소스 생성을 야기하는 것이 PRG이다. 따라서, 동일한 PRG 프로시져는 클라이언트가 보관한 이메일 메시지에 액세스하는 것을 가능하게 하여 이제 디메일 서버 상에 저장된다.

단계(430)에서, 디메일 서버(404)는 디메일 서버(404)에 의해 서명된 확인응답 메시지를 디메일 클라이언트(402)에 송신하여 디메일 클라이언트(402)에 의해 보관된 이메일 메시지가 메시지 수신자(도시되지 않음)에게 송신된다.

단계(432)에서, 디메일 클라이언트(402)는 디메일 세션 및 TLS 접속을 해체하기 위해 디메일 서버(404)로 요청을 송신한다. 단계(434)에서, 확인응답 메시지(HTTP Return 200 OK)는 디메일 서버(404)에 의해 디메일 클라이언트(402)로 송신된다. 메시지 수신자(다른 디메일 클라이언트)는 디메일 서버(404)로부터 요청할 때 보관된 이메일 메시지를 수신할 것임에 유의한다. 메시지 수신자의 디메일 클라이언트는 새롭게 보관된 이메일을 신속하게 확인할 수 있다.

예시적인 실시예에서, 디메일 클라이언트(402), 디메일 서버(404)와 ID 제공자(415) 사이의 인터랙션은 ID 연계(identity federation) 또는 OAuth 2.0 프로토콜 또는 유사한 것을 통할 수 있다. 알려진 바와 같이, "ID 연계"는 다수의 ID를 관련시키기 위한 프로토콜로서 이질적인 시스템이 인터랙션할 수 있으며, OAuth 2.0은 인증을 위한 공개 표준이고 2012년 7월 15일자 "The Oauth 2.0 Authourization Framework draft-ieft-oauth-v2-30"이라는 명칭의 IETF 인터넷 드래프트에서 정의되고, 이의 개시는 본원에서 참조로써 그 전체가 통합된다.

도 5는 본 발명의 다른 실시예에 따라, 다이렉트 전자 메일 시스템에서의 인증 동작을 위한 메시지 플로우를 도시하는 도면이다. 더 구체적으로, 도 5는 ID 연계를 통한 인터랙션을 도시한다.

도시된 바와 같이, 프로토콜(500)은 디메일 클라이언트(502), 디메일 서버(504), 및 ID 제공자(506) 사이에서 수행된다. 도 5에서 단계(508) 내지 (522)는 도 4의 단계(412) 내지 (418)에 대응한다는 것에 유의한다.

단계(508)에서, 디메일 서버(504)는 인증 요청을 디메일 클라이언트(502)에게 송신한다. 응답으로, 단계(510)에서, 디메일 클라이언트(502)의 브라우저 프로그램은 ID 제공자(506)에게 리다이렉트된다. 그 다음 단계(512)에서, 인증 요청이 디메일 클라이언트(502)로부터 ID 제공자(506)로 송신된다.

단계(514)에서는, 디메일 클라이언트(502)와 ID 제공자(506) 사이의 인증 교환이 존재한다. 이 교환은 방법 특수적(method-specific)이고, 이 방법은 ID 연계 환경, 예를 들어, 기본 HTTP 다이제스트(Basic HTTP Digest), 공용 키 인프라스트럭쳐(Public Key Infrastructure), 커버로스(Kerberos), 오픈ID, 오픈ID 접속, 또는 SAML(Security Assertion Markup Language)에서 이용되는 임의의 기존 인증 방법이 될 수 있다.

인증 교환의 결과로서, 단계(516)에서, ID 제공자(506)는 디메일 클라이언트(502)에게 인증 정보(예를 들어, 단언)를 제공한다. 단계(518)에서, 디메일 클라이언트(502)의 브라우저는 디메일 서버(506)로 다시 리다이렉트된다. 그 다음 단계(520)에서, 인증 정보가 디메일 클라이언트(502)에 의해 디메일 서버(504)로 제공된다. 그 다음 단계(522)에서, 디메일 서버(506)는 서명을 확인하는 것을 통해 또는 ID 제공자(506)와의 직접 통신을 통해 단언(assertion)을 검증한다.

도 6은 본 발명의 또 다른 실시예에 따라, 다이렉트 전자 메일 시스템에서의 인증 동작을 위한 메시지 플로우를 도시하는 도면이다. 더 구체적으로, 도 6은 OUuth 2.0을 통한 상호작용을 도시한다.

도시된 바와 같이, 프로토콜(600)은 디메일 클라이언트(602), 디메일 서버(604), 및 ID 제공자(606) 사이에서 수행된다. 도 6에서 단계(608) 내지 (628)는 도 4의 단계(412) 내지 (418)에 대응한다는 것에 유의한다.

단계(608)에서, 디메일 서버(604)는 인증 요청을 디메일 클라이언트(602)에게 송신한다. 응답으로, 단계(610)에서, 디메일 클라이언트(602)의 브라우저 프로그램은 ID 제공자(606)에게 리다이렉트된다. 그 다음 단계(612)에서, 인증 요청이 디메일 클라이언트(602)로부터 ID 제공자(606)로 송신된다.

단계(614)에서는, 디메일 클라이언트(602)와 ID 제공자(606) 사이의 인증 교환이 존재한다. 이 교환은 방법 특수적(method-specific)이고, 이 방법은 공개 표준 인증 환경, 예를 들어, HTTP 기본(HTTP basic), 커버로스(Kerberos)에서 이용되는 또는 X.509 인증서 체인에 의해 보충되는 개인 키 서명을 통한 임의의 기존 인증 방법이 될 수 있다.

인증 교환의 결과로서, 단계(616)에서, ID 제공자(506)는 디메일 클라이언트(502)에게 인증 확인응답(예를 들어, 허가 코드)를 제공한다. 단계(618)에서, 디메일 클라이언트(602)의 브라우저는 디메일 서버(606)로 다시 리다이렉트된다. 그 다음 단계(620)에서, 인증 확인응답이 디메일 클라이언트(602)에 의해 디메일 서버(604)로 제공된다. 그 다음 단계(622)에서, 디메일 서버(606)는 허가 코드를 검증한다. 단계(624)에서, ID 제공자(606)는 디메일 서버(604)로부터 허가 토큰을 요청한다. 단계(626)에서, 디메일 서버(604)는 사용자 정보 요청(예를 들어, 액세스 토큰)을 ID 제공자(606)에게 제공한다. 응답으로, ID 제공자(606)는 디메일 서버(604)에게 송신자(디메일 클라이언트(602)) 정보를 제공하여서 디메일 서버(604)가 디메일 클라이언트(602)의 ID를 검증하는 것을 가능하게 한다.

디메일 서버에 보관된 이메일 메시지를 검색하기 위해, 검색하는 사용자(도 5 및 도 6에 도시되지 않은 다른 디메일 클라이언트)는 또한 인증될 필요가 있다는 것이 더 이해될 것이다. 하나 이상의 예시적인 실시예에서, 메시지 수신자의 이메일 클라이언트에 대한 인증 플로우는 도 5 및 도 6에서 각각 도시된 메시지 플로우와 유사하고, 따라서 당업자에 의해 본원의 상세한 설명으로부터 간단한 방식으로 구현될 것이다.

마지막으로, 도 7은 본 발명의 하나 이상의 실시예에 따라, 인증 프로시져를 포함하는 다이렉트 전자 메일을 구현하기에 적합한 통신 네트워크(700)의 컴퓨팅 아키텍쳐를 도시한다.

도시된 바와 같이, 컴퓨팅 디바이스(710)(예를 들어, 디메일 클라이언트에 대응함), 컴퓨팅 디바이스(720)(예를 들어, 디메일 서버에 대응함), 및 컴퓨팅 디바이스(730)(예를 들어, ID 제공자에 대응함)는 통신 네트워크 매체(740)를 통해 동작가능하게 연결된다. 네트워크 매체는 컴퓨팅 디바이스가 통신하도록 동작가능한 임의의 네트워크 매체가 될 수 있다. 예시의 방식으로, 네트워크 매체는 월드 와이드 웹의 부분인 임의의 매체가 될 수 있다. 하지만, 본 발명의 실시예는 특정 타입의 네트워크 매체에 제한되지 않는다.

당업자에게 쉽게 명백해지는 바와 같이, 서버, 클라이언트, 및 다른 컴퓨팅 디바이스는 컴퓨터 프로그램 코드의 제어하에 동작하는 프로그래밍된 컴퓨터로서 구현될 수 있다. 컴퓨터 프로그램 코드는 비 일시적 컴퓨터(또는 프로세서 또는 머신) 판독가능 저장 매체(예를 들어, 메모리)에 저장되는 것이고 코드는 컴퓨터의 프로세서에 의해 실행될 것이다. 본 발명의 다양한 예시적인 실시예의 본 개시를 고려하여, 당업자는 본원에 설명된 프로토콜을 구현하기 위해 적합한 컴퓨터 프로그램 코드를 용이하게 생산할 수 있을 것이다.

그렇더라도, 도 7은 일반적으로 네트워크 매체를 통해 통신하는 각 디바이스에 대한 예시의 아키텍쳐를 도시한다. 도시된 바와 같이, 디메일 클라이언트 디바이스(710)는 I/O 디바이스(712), 프로세서(714), 및 메모리(716)를 포함한다. 디메일 서버 디바이스(720)는 I/O 디바이스(722), 프로세서(724), 및 메모리(726)를 포함한다. ID 제공자 디바이스(730)는 I/O 디바이스(732), 프로세서(734), 및 메모리(736)를 포함한다.

본원에서 사용되는 것과 같은 "프로세서"라는 용어는, CPU(a central processing unit) 또는 하나 이상의 신호 프로세서, 하나 이상의 집적 회로, 및 유사한 것을 포함하지만 이에 제한되지않는 다른 프로세싱 회로를 포함하는, 하나 이상의 프로세싱 디바이스를 포함하도록 의도되는 것임이 이해될 것이다. 또한, 본원에서 사용되는 것과 같은 "메모리"라는 용어는, RAM, ROM, 고정 메모리 디바이스(예를 들어, 하드 드라이브), 또는 제거가능한 메모리 디바이스(예를 들어, 디스켓 또는 CDROM)과 같은, 프로세서 또는 CPU와 연관된 메모리를 포함하도록 의도된다. 또한, 본원에서 사용되는 것과 같은 "I/O 디바이스"라는 용어는, 프로세싱 유닛으로 데이터를 입력하기 위한 하나 이상의 입력 디바이스(예를 들어, 키보드, 마우스)뿐만 아니라, 프로세싱 유닛과 연관된 결과를 제공하기 위한 하나 이상의 출력 디바이스(예를 들어, 컴퓨터 디스플레이)를 포함하도록 의도된다.

따라서, 본원에서 설명된, 본 발명의 방법을 수행하기 위한 소프트웨어 명령어 또는 코드는 하나 이상의 연관된 메모리 디바이스,예를 들어, ROM, 고정 또는 제거가능한 메모리에 저장될 수 있고, 이용될 준비가 되었을 때, RAM으로 로딩되고 CPU에 의해 실행될 수 있다. 즉, 도 7에 도시된 각각의 컴퓨팅 디바이스(710, 720, 및 730)는 도 3 및 도 6에 도시된 방법 및 프로토콜의 이들 각각의 단계를 수행하도록 개별적으로 프로그래밍 될 수 있다.

유리하게, 본 발명의 실시예는 현재의(구식의) 이메일 시스템을 단순화시키며, 송신자 인증을 위한 간단한 매커니즘 및 스팸을 제거하기 위한 콘텐츠 제어를 제공한다. 더 구체적으로, 실시예는 이메일 송신자의 인증을 제공한다. 결과로서, 송신자 위장을 통한 스팸은 완전하게 제거될 수 있다. 또한, 실시예는 메시지 송신자의 클라이언트에 의해, 메시지 수신자의 이메일 서버에 이메일 메시지를 직접 보관하는 것을 가능하게 함으로써, 전체 이메일 전달 인프라스트럭쳐를 단순화시킬 수 있고, 시스템 전반에 복사된 메시지의 수를 감소시킨다(따라서, 이메일 시스템에 메일 프록시에서 메시지의 복사는 회피된다). 실시예는 또한 웹 서비스에 적용가능하다. 즉, 이메일 클라이언트에 의해 수행되는 단계/동작은 하나 이상의 독립형 애플리케이션 또는 클라이언트 브라우저 내에서 실행되는 자바스크립트 애플릿(a Javascript applet) 중 하나, 또는 HTML5로 작성된 페이지에 의해서도 실행될 수 있다.

비록 본 발명의 예시적인 실시예가 첨부한 도면을 참조하여 본원에서 설명되었지만, 본 발명의 이들 정확한 실시예에 제한되지 않고, 다양한 다른 변경 및 수정이 본 발명의 범위 또는 사상으로부터 벗어남이 없이 당업자에 의해 수행될 수 있음이 이해될 것이다.

Claims

전자 메일 시스템에서 전자 메일 메시지를 처리하는 방법에 있어서,
상기 전자 메일 시스템에서 메시지 송신자의 클라이언트와 메시지 수신자의 서버 사이에서 안전한 접속을 설정하는 단계와,
상기 메시지 송신자의 클라이언트의 ID(identity)를 검증하기 위해 인증 교환에 참여하는 단계와,
상기 메시지 송신자의 클라이언트의 ID를 성공적으로 검증할 시에, 상기 메시지 송신자의 클라이언트는 상기 메시지 수신자의 서버에 전자 메일 메시지를 보관하는(depositing) 단계를 포함하는
전자 메일 메시지 처리 방법.
제 1 항에 있어서,
상기 메시지 송신자의 클라이언트에서, 상기 전자 메일 메시지가 상기 메시지 수신자의 서버로 전달되었다는 확인응답(an acknowledgment)을 수신하는 단계를 더 포함하는
전자 메일 메시지 처리 방법.
제 1 항에 있어서,
상기 메시지 송신자의 클라이언트가 상기 전자 메일 메시지가 전달될 어드레스를 획득하는 단계를 더 포함하는
전자 메일 메시지 처리 방법.
제 1 항에 있어서,
상기 인증 교환은 또한 ID 제공자를 수반하는
전자 메일 메시지 처리 방법.
제 1 항에 있어서,
상기 인증 교환은 ID 연계 프로토콜(an identity federation protocol)에 따라 수행되는
전자 메일 메시지 처리 방법.
제 1 항에 있어서,
상기 인증 교환은 공개 표준 인증 프로토콜(an open standard authentication protocol)에 따라 수행되는
전자 메일 메시지 처리 방법.
제 1 항에 있어서,
상기 메시지 송신자의 클라이언트와 상기 메시지 수신자의 서버 사이의 통신 중 적어도 일부는 HTTP(HyperText Transport Protocol)을 이용하는
전자 메일 메시지 처리 방법.
전자 메일 시스템에서 전자 메일 메시지를 처리하는 장치에 있어서,
메모리와,
상기 메모리에 연결되고 메시지 송신자의 클라이언트를 실행시키도록 구성된 프로세서를 포함하되, 상기 클라이언트는 실행될 시에,
상기 메시지 송신자의 클라이언트와 메시지 수신자의 서버 사이에서 안전한 접속을 설정하고,
상기 클라이언트의 ID를 검증하기 위해 인증 교환에 참여하고,
상기 클라이언트의 ID를 성공적으로 검증할 시에, 상기 메시지 수신자의 서버에 전자 메일 메시지를 보관하는
전자 메일 메시지 처리 장치.
전자 메일 시스템에서 전자 메일 메시지를 처리하는 방법에 있어서,
상기 전자 메일 시스템에서 메시지 송신자의 클라이언트와 메시지 수신자의 서버 사이에서 안전한 접속을 설정하는 단계와,
상기 메시지 송신자의 클라이언트의 ID를 검증하기 위해 인증 교환에 참여하는 단계와,
상기 메시지 송신자의 클라이언트의 ID를 성공적으로 검증할 시에, 상기 메시지 수신자의 서버는 상기 메시지 송신자의 클라이언트에 의해 송신된 전자 메일 메시지를 수신하는 단계를 포함하는
전자 메일 메시지 처리 방법.
전자 메일 시스템에서 전자 메일 메시지를 처리하는 장치에 있어서,
메모리와,
상기 메모리에 연결되고 메시지 수신자의 서버를 실행시키도록 구성된 프로세서를 포함하되, 상기 서버는 실행될 시에,
메시지 송신자의 클라이언트와 상기 메시지 수신자의 서버 사이에서 안전한 접속을 설정하고,
상기 메시지 송신자의 클라이언트의 ID를 검증하기 위해 인증 교환에 참여하고,
상기 메시지 송신자의 클라이언트의 ID를 성공적으로 검증할 시에, 상기 메시지 송신자의 클라이언트에 의해 송신된 전자 메일 메시지를 수신하는
전자 메일 메시지 처리 장치.