KR20000050631A

KR20000050631A - 인터넷 전자우편 부가 서비스 시스템

Info

Publication number: KR20000050631A
Application number: KR1019990000638A
Authority: KR
Inventors: 이수복
Original assignee: 이수복
Priority date: 1999-01-13
Filing date: 1999-01-13
Publication date: 2000-08-05
Also published as: ATE264031T1; DE60009679D1; WO2000042747A1; EP1157507A1; CN1166135C; KR100285122B1; JP2002540647A; US6963929B1; CN1354941A; EP1157507A4; EP1157507B1; JP3766966B2; DE60009679T2

Abstract

본 발명의 인터넷 전자우편 부가 서비스 시스템(internet email add-on service system )은, 도메인 접미어 전자우편 주소 표기 체계 (domain suffix email address representation system) 와 메타 도메인 네임 시스템 ( meta domain name system ) 그리고 렐레이 모드 부가 서비스 메일 서버 (relay mode add-on service mail server)의 3가지 요소로 구성되며, 보편화된 인터넷 전자우편 인프라스트럭쳐와 병립이 가능하여, 송신자 및 수신자측의 소프트웨어 교체없이도, 세계적인 동시 서비스를 가능하게 하는 점이 특징이다.

본 발명은, 상기의 시스템에 종속된 발명으로서, 전자 우편 수신 확인 서비스, 전자 우편 복권 서비스, 전자 우편 엽서 서비스 및 메시지 번역 서비스 시스템을 포함한다.

Description

인터넷 전자우편 부가 서비스 시스템 {internet email add-on service system}

본원에서 언급하는 전자 우편 부가 서비스 (Email Add-On Service) 는, 인터넷 전자우편과 관련한 서비스들 가운데, 보편적인 전자 우편 기본 기능으로 간주되지 않는 서비스로 정의하자. 이러한 서비스에는, 메시지의 다른 자연 언어로의 번역, 전자우편 수신 확인 통보 서비스, 복권 메일 발송 서비스, 또는 성탄절 그림 카드 전송 서비스 등을 들 수 있겠다.

전자 우편 수신 확인 서비스는, IETF에 의해 국제 표준(RFC2298)이 이미 마련되었으나, 이 표준을 지원하는 메일 클라이언트 소프트웨어를 송신자 및 수신자측이 함께 사용하고 있을 때에만 사용할 수 있기때문에, 그 사용률이 아직 저조한 편이다. 복권 메일 보내기 또는 성탄절 그림 엽서 메일 보내기 서비스처럼, 표준화의 필요성이 없거나 표준화가 불가능하여, 메일 클라이언트 소프트웨어나 서버 소프트웨어에 기본 기능으로 탑재될 전망이 없는 것도 있다. 성탄절 그림 엽서 보내기의 경우는, 웹(WWW) 서비스에 의해 흔히 제공된다.

관리 권한의 분산을 특징으로 하고 있는 인터넷 상에서, 특정 전자우편 부가 서비스의 전세계적인 제공을 위해, 송신자 및 수신자측의 메일 서버 소프트웨어 및 메일 클라이언트 소프트웨어의 교체를 강요할 수 있는 권한은, 어떠한 서비스 주체에게도 존재하지 않는다.

본 발명이 이루고자 하는 과제는, 인터넷을 구성하고 있는 보편화된 전자 우편 인프라스트럭쳐와 병립이 가능하며, 이와의 상호 연동을 통하여, 송신자가 지정한 특정 부가 기능을 인터넷 전체에 걸쳐 서비스할 수 있는, 독립된 전자 우편 부가 서비스 시스템을 구축하는 것이다.

이미 많은 시간과 돈이 투자되어 있고 그 관리 권한마저 분산되어 있는 전자우편 클라이언트 소프트웨어 및 서버 소프트웨어의 전세계적인 인프라스트럭쳐의 교체를 필요로 하지 않아야 한다는 조건은, 어느 한 서비스 주체가 독립적으로 전세계적인 동시 서비스를 제공할 수 있기 위한 필요 충분 조건이기도 하다.

이 조건을 만족시킬 수 있는 방법으로서, 본 발명은, 송신자측 메일 서버와 수신자측 메일 서버 사이의 중간 전송 경로에 삽입되어, 부가 서비스에 필요한 메시지 처리를 수행할 릴레이 모드 메일 서버 ( relay-mode mail server )를 사용한다.

일반적으로 송신자가 메일 클라이언트를 사용하여 전송한 메시지는, SMTP 프로토콜을 통해서, 메일 클라이언트 설치시 지정한 송신자측 메일 전송 서버(SMTP Server)내의 전송 대기 행렬(queue)에 저장되며, 그 다음 이 서버는 메시지 내에 지정된 수신자 주소 USERID@DOMAIN 의 DOMAIN 부분을 기초로 하여, 메시지를 어느 인터넷 호스트로 전송해야 할 것인지를 결정한다. (IETF의 RFC822, RFC821 참조)

바로 이 부분이 부가 서비스 처리를 수행할 릴레이 모드 메일 서버가, 기존의 메일 전송 경로 가운데에 삽입될 수 있는 유일한 지점이며, 송신자가 수신자 메일 주소의 DOMAIN 부분을, 상기의 릴레이 모드 메일 서버가 설치된 인터넷 호스트명 DOMAIN-NEW 로 대치한 새로운 수신자 메일 주소를 사용함으로써만, 삽입 가능하다. 또한 DOMAIN-NEW는 원래의 수신자 메일 주소의 DOMAIN 부분을 어떻게든 명확히 구분될 수 있는 형태로 포함함으로써, 부가 서비스 처리된 메시지가 원래의 수신자 메일 서버로 전달(relay)될 수 있는 최소한의 정보를 유지하여야 한다.

이를 위하여, 본 발명은 부가 서비스 및 그 옵션에 따라 도메인 접미어 ( Domain Suffix, 이하 .suffix 로 축약 표기 )를 정의하고, 이를 수신자 메일 주소의 DOMAIN 뒤에 덧붙여, DOMAIN 부분을 그 앞부분에 온전히 포함하고 있는 DOMAIN.suffix 를 만들고, 이 DOMAIN.suffix를 릴레이 모드 메일 서버의 인터넷 호스트명으로 삼는 방식을 채택하였다.

이 아이디어를 토대로 하여, 전자 우편 부가 서비스 시스템의 체계적 구축 방법을 아래 [발명의 구성]에서 설명한다.

제 1도는 송신자가 USERID@DOMAIN 으로 편지를 보낼 때의 전자우편 흐름과, USERID @ DOMAIN.suffix 로 보낼 때의 전자우편 흐름을 비교하여 나타내는 도면.

제 2도는 전자우편 수신 확인 서비스 시스템의 구성 요소인, 메타 도메인 네임 서버와 부가 서비스 메일 서버 그리고 웹서버의 상호 작용을 나타내는 흐름도

제 3도는 전자우편 수신 확인 서비스 시스템에서, 수신 확인 통보가 송신자에게 보내지는 과정의 흐름도.

본 발명의 전자우편 부가 서비스 시스템은 다음 3가지 요소로 구성된다.

[요소. 1] 부가 서비스별 도메인 접미어가 덧붙여진, USERID @ DOMAIN.suffix 형식의 메일 주소의 구문 구조와 그 의미에 대한 일련의 정의로 구성되며, 도메인 접미어를 덧붙임으로써 부가 서비스의 종류의 명시와 그 처리를 담당할 서비스 호스트의 지정의 두가지 목표를 동시에 이루는 것을 목적으로 하는 도메인 접미어 전자우편 주소 표기 체계 (domain suffix email address representation system)

[요소. 2] 수신자 주소가 USERID@DOMAIN.suffix로 된 메일 메시지를 수신하여, .suffix 가 지정하는 부가 서비스 종류 및 옵션에 따라, 전자 우편 메시지를 가공한 후, 원래의 수신자 주소 USERID@DOMAIN 으로 재전송해주는 메시지 수정형 (message modifying)의 릴레이 모드 부가 서비스 메일 서버 (relay mode add-on service mail server )

[요소. 3] 상기의 DOMAIN.suffix 를, DOMAIN 에 대한 부가 서비스를 담당하는 릴레이 모드 메일 서버 호스트의 인터넷 IP 주소로 대응시켜주는, 메타 도메인 네임 시스템 (meta domain name system)

다음의 내용은, 상기의 각 3가지 발명 요소에 대한 상세 설명과 함께, 이 범용 시스템의 서브시스템 (subsystem)으로서 구현될 수 있는 4가지의 특화된 인터넷 부가 서비스 서브시스템 각각에 대한 서술이다.

[1. 도메인 접미어 메일 주소 표기 체계 ]

[요소 1.]에서 상술한 바와 같이, 본 주소 표기 체제는 수신자 전자우편 주소뒤에 도메인 접미어를 덧붙이는 것을 특징으로 하며, 부가 서비스의 종류의 명시와 그 처리를 담당할 서비스 호스트의 지정의 두가지 목표를 동시에 이룰 수 있는 점이 그 핵심이다.

부가 서비스의 사용자들의 관점에서는, 이 표기법은 전자우편 부가 서비스 사용법과 동일하게 인식된다.

부가 서비스별 도메인 접미어는 항상 주 도메인 접미어 (root domain suffix ) 와 보조 도메인 접미어 (suplimentary domain suffix)로 부분으로 이루어진다. 주 도메인 접미어는 반드시 인터넷 상에서 공식 등록된 하나의 독립된 도메인이거나, 그 도메인의 하위 도메인이어야 한다.

이해를 돕기 위해, 메일 수신 확인 부가 서비스를 위한 주 도메인 접미어를 .confirm.to 로 하고, .add 로 시작하는 보조 도메인 접미어 구문을 사용하는 실례를 2개 들어보자. 먼저, apple.com.add.startec.advertizement.confirm.to 의 경우를 살펴보면, apple.com 이 DOMAIN 부분이고, add.startec.advertizement 가 보조 도메인 접미어이며, .confirm.to 가 주 도메인 접미어이다. 다음으로, apple.com.confirm.to 의 경우에는, 보조 도메인 접미어가 공백 문자열( null string)값을 갖고 있는 것으로 간주한다. 참고로, .confirm.to 의 .to 도메인은 통가 왕국 ( the kingdom of Tonga)의 국가 최상위 도메인(country top-level domain) 으로서, .com, .net 과 같이 국제적으로 등록이 가능하다.

보조 도메인 접미어는 주 도메인 접미어와 원래의 메일 주소 도메인명 사이에 붙어, 부가 서비스의 기능을 수식하거나 제한한다. 보조 도메인 접미어가 가질 수 있는 문자열 값의 범위는 부가 서비스별로 다르게 정의될 수 있으며, 가변적인 인수(variable parameter)를 포함하는 구문 구조(syntax)를 갖는 보조 도메인 접미어의 경우, 무한개의 문자열 값을 가질 수 있다.

microsoft.com.add.*.photo.post-card.to. INA 202.30.244.18

[2. 릴레이 모드 부가 서비스 메일 서버 ]

수신자 주소가 USERID@DOMAIN.suffix로 된 메일 메시지를 수신하여 처리할 서버로서, 그 구성에 있어서, 다음 3가지 특징을 가진다.

첫째, 도메인 네임이 DOMAIN.suffix 유형인 인터넷 호스트상에 설치된다.

둘째, 송신자 메일 서버에서 수신자 메일 서버로의 메일 메시지 전송 과정중에 삽입되어 메시지를 처리후 전달(relay)함으로써, 두 메일 서버를 대신하여, 부가 서비스를 적용하는 릴레이 모드 (relay mode) 작동의 특징

셋째, 수신자 주소 USERID @ DOMAIN.suffix 에 명기된 주 도메인 접미어와 보조 도메인 접미어의 내용을 토대로, 해당 부가 서비스가 필요로 하는 메시지 변형을 가하는 메시지 수정형 (message modifying) 메일 서버 작동의 특징

[2.가. 릴레이 모드 부가 서비스 메일 서버 구조의 장점 ]

첫째 장점은, 기존의 송수신자 메일 서버의 교체가 불필요하다는 점이다. 송신자 메일 서버 및 수신자 메일 서버 사이의 전송 경로에 삽입되어, 두 메일 서버의 기능을 자연스럽게 확장시킬 수 있다.

둘째 장점은, 부가 서비스 릴레이 서버는 송수신자 메일 DOMAIN의 메일 서버들과 운영,소류 및 관리에 있어서 독립적이므로, DOMAIN 관리자측의 협조없이도, 부가 서비스측의 준비만으로 독자적인 전세계적인 동시 서비스 시행이 가능하다.

셋째 장점은, DOMAIN.suffix 서버를 1차 메일 수신 서버로 명시적으로 지정한 것은 송신자이므로, DOMAIN 을 담당하는 관리자로부터 아무런 간섭이나 법적 제약없이도, DOMAIN 내의 사용자를 수신자로 하는 메일 부가 서비스 제공이 가능하다.

넷째 장점은,모든 DOMAIN 에 대하여, DOMAIN.suffix 가 하나의 릴레이 서버 머신의 IP 주소로 대응되도록, 메타 도메인 네임 시스템을 구성하면, 하나의 서버로도 전세계적 동시 서비스가 가능하다. 릴레이 메일 서버는 수신된 메시지의 수신자 주소 DOMAIN.suffix 의 DOMAIN의 범위값에 상관없이, .suffix에 기초하여 요구된 처리를 수행한 다음, DOMAIN 측 수신 메일 서버로 최종 메시지를 전달할 수 있도록 셋업할 수 있다. 또한 부하 분산 차원 또는 보안 관리 목적 차원에서, 도메인의 각 계층 단위로 전담 릴레이 서버의 곁가지 치기식의 점진적 설치가 가능하다.

[2.나. 메시지 부가 서비스 처리 과정 설명]

송신자가 USERID@DOMAIN 으로 편지를 보낼 때의 전자우편 흐름과, USERID @ DOMAIN.suffix 로 보낼 때의 전자우편 흐름을 비교하여 나타내는 도면이 [도 1]로 첨부되어 있으며, 그 도면의 각 세부 과정에 대한 해설은 다음과 같다.

우선, 송신자가 어떤 수신자 주소를 지정하든지, 그 메일 메시지는 일단은 송신차측 메일 서버의 대기 행렬에 추가되어, 실제 외부로의 전송을 기다린다 ( [도 1]의 과정 1).

그 메시지가 처리될 차례가 되면, 메일 서버는, DOMAIN.suffix 의 IP 주소를 알아내기 위해, .suffix 도메인의 주 도메인 네임 서버 ( ns.suffix 로 표기하자, 메타 도메인 네임 서버 ) 에 질의를 보낸다 ( [도 1]의 과정 2 ) .

DOMAIN.suffix 서버에 대응되는 IP 주소로, SMTP 프로토콜을 사용하여 메시지를 전달하고 ( [도 1]의 과정 3), 이 메시지를 받은 DOMAIN.suffix 서버는 부가 서비스의 특성에 따라 메시지의 내용을 변경 또는 추가하여, 새로운 메시지를 만든다. ( [도 1]의 과정 4 ).

수신자 전자 우편 주소 USERID@DOMAIN.suffix 에서 원래의 수신자 주소 USERID@DOMAIN와 도메인 접미어인 .suffix 부분을 일단 분리한 후, 도메인 접미어 는 다시, 주 도메인 접미어 부분과 및 보조 도메인 접미어 부분으로 나누어, 송신자가 의도하였던 부가 서비스 유형과 그 내용을 결정하는데 사용된다.

부가 서비스를 메시지에 적용되어,변형된 새로운 메시지를 만들면서, 부가 서비스가 필요로 한다면, 각 메시지별로 상태 정보 데이타 레코드를 서버 내의 데이타베이스에 기록하며, 이를 위해, 각 메시지마다 고유 일련 번호를 생성하여 메시지 ID를 부여한다.

원래의 수신자 전자 우편 주소 USERID@DOMAIN 을 최종 수신자로 하여 새 메시지를 전송한다.([도 1]의 과정 5)

수신자가 수신자측 전자 우편 서버에 저장된 자신의 편지를 메일 클라이언트를 사용하여 자신의 PC로 읽어들인다 ( [도 1]의 과정 6)

[2.다. 메시지 수정형 서버의 메시지 데이타베이스 ]

부가 서비스와 관련한 메일 메시지별 상태 정보는 DOMAIN.suffix 호스트내에 저장될 수 있는데, 이는 단순히 서비스 처리의 기록 남기기를 목적으로 하거나, 또는 수신자 메일 클라이언트와의 상호 작용을 통해, 부가 서비스의 특정 목적을 달성하기 위함이다.

수신자가 메일을 수신한 후, DOMAIN.suffix 서버와 인터넷을 통한 일련의 상호 작용을 통하여, 부가 서비스가 비로소 실현되는 상호작용형 부가 서비스 ( interactive add-on service) 유형이 있는데, 이 경우에는, 상태 정보 데이타베이스 레코드의 키가 되는 메시지 ID에 대한 정보가 어떠한 형식으로든지, 수신자에게 최종 전달된 메일 메시지 본문 또는 메일 헤더에 사용자에게 보이게 또는 보이지 않게 부가 서비스 목적에 부합되는 방식으로 부가되어야 한다.

[3. 메타 도메인 네임 시스템 (Meta Domain Name System) 상세 설명]

[3.가. 배경 설명]

도메인 네임(domain name)이란 인터넷의 계층적인 이름 공간(hierarchical name space) 안에서의 호스트나 네트워크 이름(identifier)으로 구성된 각 계층의 고유 이름들을 최상위 계층에서 최하위 계층까지 . (period) 로 구분하여 우측에서 좌측 방향으로 차례대로 표기한 이름이다. 즉, www.microsoft.com, netscape.net, www.nic.go.kr 등이 그 예이다. 여기서, .com, .net, .kr 등은 최상위 도메인(top-level domain, 줄여서 TLD라고 표기) 이라 부르고, micrsoft.com, netscape.net, go.kr 은 차상위 도메인(second-level domain) 이라 부른다.

도메인 네임 시스템(Domain Name System, DNS 라 표기 )은 바로, 이 도메인 네임들을 그 IP주소와 대응시켜주기 위한, 전세계적인 분산된 데이타베이스 시스템 으로서, 인터넷 도메인 네임과 IP 주소 사이의 대응 관계 데이타베이스 (A-type 레코드로 구성)및 인터넷 전자 우편 전송 경로 데이타베이스(MX type 레코드로 구성)로 구성되어 있으며, 모든 인터넷 tcp/ip 통신을 포함하여, 전자 우편의 송신자측로부터 수신자측으로의 전자 우편 전송의 흐름과 경로를 결정하는 데 중요한 역할을 한다. ( 관련문서 IETF 의 RFC1034, RFC1035)

도메인 네임의 각 계층별로 주 도메인 네임 서버(primary domain name server) 가 지정되어 있어, 각 도메인 및 그 하위 도메인에 대한 IP주소 대응을 담당하고 있다. 예를들어, www.cs.uiuc.edu 의 경우, 최상위 도메인인 .edu 도메인은 ns.internic.net 가, uiuc.edu 는 ns.uiuc.edu (일리노이 대학)가 주 도메인 네임 서버로 지정되어 있다. 이러한 역할 분담은, ns.internic.net 의 도메인 네임 데이타베이스에 uiuc.edu 에 대한 주 도메인 네임 서버 관리 권한을 ns.uiuc.edu 에 위임(delegation)하는 내용(NS type 레코드라고 함)을 추가함으로써 이루어진다.

cs.uiuc.edu 와 www.cs.uiuc.edu 가 각각의 하위 도메인에 대한 온전한 주 도메인 네임 서버 권한을 갖는가의 여부는, ns.uiuc.edu 관리자가 결정한다.

이제 본론으로 돌아와, DOMAIN.suffix 도 역시 .suffix 이라는 특정 도메인의 하위 도메인명이므로, .suffix 의 주 도메인 네임 서버 구축이 필요하다. 그런데, 도메인 네임의 생성과 삭제가 다이나믹하게 일어나는 인터넷상에 있어서, 가능한 모든 DOMAIN 에 대하여. DOMAIN.suffix 에 대한 데이타베이스 레코드를 만드는 것은 인터넷의 분산 관리의 특성과 그 규모로 보아 불가능하다. 특히, 그 가변 인수를 포함하는 보조 도메인 접미어를 포함하는 경우에 있어서는 더욱 그러하다.

본 발명의 메타 도메인 네임 시스템 ( Meta Domain Name System )은 바로, 이러한 특징을 가지고 있는 DOMAIN.suffix 유형의 도메인 네임 관리를 위해 특별한 데이타베이스 (이를 메타 도메인 데이타베이스라 부르자) 구성 방법를 가지고 있는 도메인 네임 시스템를 가리키며, 이 시스템은 주 도메인 접미어의 독립 도메인명을 관할하는 주 도메인 네임 서버 (primary domain name server) 호스트 상에 우선 구축되어 한다. 이 메타 도메인 네임 데이타베이스를 서비스하는 서버 소프트웨어를 메타 도메인 네임 서버로 칭하자.

[3.나. 메타 도메인 네임 시스템의 특징 ]

메타 도메인 네임 서버는 외부와의 DNS 프로토콜 상호작용에 있어 일반적인 도메인 네임 서버와 동일하게 동작하나 ( 관련문서 IETF 의 RFC1034, RFC1035) , 그 데이타베이스 구성에 있어서 다음과 같은 3가지 특징을 가지고 있다.

첫째, 메타 도메인 네임 서버가 관리하는 모든 도메인 네임 데이타베이스의 리소스 레코드(Resource Record)는 기본적으로 와일드 카드 속성( Wildcard attribute ) 를 가진다.

둘째, 리소스 레코드들중에, 보다 더 명시적(specific)한 것이 IP주소 질의 결과 선정 과정에서 우선 순위를 갖고 사용된다..

셋째, 인수화된 (parameterized) 보조 도메인 접미어를 사용하는 부가 서비스의 경우, 가변의 인수항(parameter) 표현을 포함하는 리소스 레코드의 해석을 도메인 네임 데이타베이스가 지원한다.

메타 도메인 네임 서버의 핵심은 바로 이 데이타베이스 구성 방법에 있으며, 도메인 네임 서버 소프트웨어는, 단지 이 데이타베이스를 서비스하기 위한 수단으로서, 이미 널리 공지되어 사용되고 있는 최신의 네임 서버 소프트웨어들이 대부분 이러한 유형의 데이타베이스 구축을 직접적으로 혹은 간접적으로 지원한다.

[3.다. 각 특징별 해설 ]

첫째 특징의 의미를 예시하기 위해 예를 들면, 주 도메인 접미어가 .confirm.to 인 경우, 도메인 네임 데이타베이스 리소스 레코드 (resource record)는 apple.com.confirm.to 에 대하여 다음과 같은 형태를 갖는다고 하자. ( 실제 데이타베이스 레코드 입력 내용이 이와 동일할 필요는 없으며, 이는 사용하는 도메인 네임 서버 소프트웨어에 따라 다르다. )

apple.com.confirm.to.INA202.30.244.15

이 때, apple.com.confirm.to 레코드가 wildcard 속성을 갖는다함은 apple.com 하위 도메인 모두는 그 앞에 어떠한 문자열값이 오더라도, 항상 apple.com.confirm.to 의 IP 주소와 동일한 값이 대응된다는 것이다. 즉, UNIX 쉘 명령의 와일드카드 문자 *(asterisk)가 앞에 생략되어 있는 것처럼 (*.apple.com. confirm.to ) 간주하는 방식이다. 따라서, host1.marketing.apple. com.confirm.to 와 host2.korea.international.apple.com.confirm.to 는 모두 동일한 *.apple.com. confirm.to 에 부합(match)될 수 있으므로, apple.com.confirm.to 처럼 202.30.244.15의 IP 주소 값을 대응받는다.

둘째 특징의 의미의 예시를 위해, usa.apple.com.confirm.to 와 그 하위 도메인만을 위한 별도의 릴레이 모드 메일 서버가 필요해, 리소스 레코드를 분리해야 할 필요가 있다고 가정하자. 이에 대비해 다음과 같이 리소스 레코드를 명시할 수 있게 한다.

usa.apple.com.confirm.to.INA202.30.244.16

apple.com.confirm.to.INA202.30.244.15

이 때, usa.apple.com 이 apple.com 의 것보다 우선 순위를 가져야 의미가 있을 것이다. 둘 다 앞에 * 가 생략되어 있는 것으로 간주되기에, 형식상 *.usa.apple.com 이 *.apple.com 에 포함되어 있는 것으로 간주될 수 있는 모호성이 존재한다. 이의 해결을 위해, 임의 도메인 네임 질의에 대하여, 두 리소스 레코드중 어느 것을 우선 적용할 것인지를 분명히 해야하는 것이다.

이 때, usa.apple.com.confirm.to 가 apple.com.confirm.to 보다는 더 명시적(specific)이다고 정의하며, 이 더 명시적인 리소스 레코드에 의한 IP주소 질의 결과가 우선 순위를 갖도록, 메타 도메인 네임 서버를 구축한다.

한편, 부가 서비스 초기에, 모든 DOMAIN 에 대한 부가 서비스를 오직 하나의 릴레이 메일 서버 호스트에서 처리한다면, 다음의 하나의 리소스 레코드로도 충분할 것이다.

confirm.to.INA202.30.244.15

셋째 특징의 예시를 위해, 인수화된 (parameterized) 보조 도메인 접미어를 사용하는 성탄절 우편 엽서 메일 보내기 부가 서비스를 가정해보자. 주 도메인 접미어는 .post-card.to 로 하고, 보조 도메인 접미어의 BNF 구문은 add.*. ( midi | photo ) 로 하자. * 부분은 실제 문자열 "*"이 아니고, 송신자가 임의로 단어를 선택하여 대치할 있는 가변 인수(parameter)를 표현한 것이라 약속해 두자.

1) bill@microsoft.com.post-card.to ,

2) bill@microsoft.com.add.yosemite.park.photo.post-card.to ,

3) bill@microsoft.com.add.christmas.carol.song.midi.post-card.to

이렇게 3가지 메일 수신자 주소에 대하여, 1) 번처럼, 송신자가 보조 도메인 접미어를 공백문자열로 하면 (즉, 지정하지 않으면) 서버가 임의로 지정한 내용이 선택되어 엽서로 보내어질 수 있을 것이다. 2)번은 yosemite.park.photo 가 가변 인수가 되며, 3)번에서는 christmas.carol.song.midi 가 가변 인수가 된다.

결국, 메타 도메인 네임 데이타베이스는 인수화된 보조 도메인 접미어를 포함하는 리소스 레코드릴 지원해야 한다함은 다음과 같은 리소스 레코드를 데이타베이스에서 지정할 수 있어야 함을 의미한다.

microsoft.com.add.*.midi.post-card.to. IN7A 202.30.244.15

microsoft.com.add.*.girl.photo.post-card.to. INA 202.30.244.16

microsoft.com.add.*.park.photo.post-card.to. INA 202.30.244.17

[4. 전자우편 수신 확인 부가 서비스 시스템]

[4.가. 배경 설명]

인터넷 전자우편 수신 확인 서비스(Mail Read Confirmation Notification Service) 는, 인터넷 전자 우편을 수신자측이 수신하여 읽은 사실을 송신자측에 회신해 주는 서비스로서, 그 방법과 절차가, IETF 에 의하여 표준 ( RFC2298, http://www.imc.org/rfc2298 )화 되어있으나, 송수신자측의 전자 우편 서버 및 클라이언트 소프트웨어의 교체를 필요로 하여 서비스의 확산이 지체되고 있으며, 전세계적인 예외없이 동시적으로 서비스하기에는 무리가 있다.

본 발명의 인터넷 전자우편 부가 서비스 시스템의 한 특화된 발명으로 구축되는 이 전자우편 수신 확인 부가 서비스는, 상기의 인터넷의 표준과 무관하게, 모든 인터넷 송신자들이, 단지, 수신자의 전자우편 주소 뒤에, .confirm.to 또는 .confirm.cc 의 도메인 접미어를 붙여 송신함으로써, 수신 확인 부가 서비스 사용을 지시할 수 있게 한 점에 그 특징이 있다.

[4.나. 전자우편 수신 확인 부가 서비스 시스템의 구성 ]

과정 1) 본 발명의 [요소 .1]의 부가 서비스 메타 메일 주소 표기 체제의 틀에 의거하여, 전자우편 수신 확인 부가 서비스를 위한 주 도메인 접미어로, to와 .cc를 최상위 도메인으로 하는 동일명의 2차 도메인 한쌍을 선택하여, 공식 인터넷 2차 도메인으로 등록하여 확보한다.

예를 들어, "confirm.to" 와 "confirm.cc" 라는 인터넷 도메인명을 확보하였다면, 각 도메인 접미어에 대한 부가 서비스의 의미를 다음과 같이 정한다. .confirm.to 도메인 접미어를 메일 주소뒤에 붙여 송신하면, 전자 우편 수신시 송신자에게만 수신 확인 통보가 전달되고, 수신자가 둘 이상의 일 때는, .confirm.cc 를 붙일 수 있는데, 수신시 송신자뿐만 아니라, 타 수신자들에게도 (만약 있다면) , 수신 통보 사실이 전달되게 한다. .confirm. 대신에 receipt, notice 등의 다른 도메인도 확보가능하다면 대체할 수 있다.

to는 전자 우편의 송신자를 가리키는 표준화된 메일 헤더 이름이므로, 쉽게 사용자들에게 인식될 수 있으며, cc (carbon copy, 복사본이라는 뜻임)도 역시 표준화된 메일 헤더 이름으로서, 송신자에게 보낼 수신 확인 통보의 복사본을 타 수신자에게 보낸다는 의미를 직관적으로 전달할 수 있다. .to.는 통가 왕국(the kingdom of Tonga)의 국가 최상위 도메인(country top-level domain)이며, .cc는 코커스 킬링 군도(The island of Cocus Keeling) 의 국가 최상위 도메인이다.

과정 2) 본 발명의 [요소 .3]의 메타 도메인 네임 시스템의 구축 틀에 의거하여, 상기의 두 도메인명을 각각 주 도메인 접미어로 하는, 2개의 메타 도메인 네임 데이타베이스를 구축한다. DOMAIN.confirm.to와 DOMAIN.confirm.cc 유형의 도메인 네임에 대하여, 서비스를 담당할 메일 호스트 머신들을 확보한 후, 그 IP주소를 등록한다.

과정 3) 본 발명의 [요소. 2]의 릴레이 모드 부가 서비스 메일 서버 구축 틀에 의거하여, 수신 확인 부가 서비스를 구현할 메시지 수정형 전자우편 릴레이 서버 시스템를 구축한다. 전자우편 수신 확인 서비스는 수신자 메일 클라이언트와 릴레이 서버와 상호 작용이 필요한 서비스이므로, 이를 위해, 메지시 처리시 릴레이 서버에 메시지별 수신 상태 데이타 베이스 레코드를 함께 생성 관리하며, 수정된 메시지에는, 수신자가 메일을 열어 읽을 때, 자동적으로 수신 상황 보고를 위한 http 요구가 릴레이 서버로 전달되도록 적절한 HTML 태그가 본문에 삽입되도록 처리한다. 이 서버 시스템을 과정 2)에서 데이타베이스에 등록된 각 릴레이 메일 서버 호스트 머신에 설치한다.

과정 4) 수신자 메일 클라이언트와 릴레이 서버와 상호 작용을 통해, 전자 우편 수신 확인 서비스가 구현될 수 있도록,릴레이 서버내에 웹서버를 설치하고, 수신자의 메일 클라이언트로부터 오는 수신 상황 보고 http 요구를 받아, 메시지별 수신 상황 데이타베이스에 반영하고, 수신 확인 통지를 수령 대상자들에게 전송하게 한다.

송신자가 .confirm.to 도메인 접미어를 붙여 송신하고 난 후, 최종 수신자에게, 부가 서비스 처리된 변형된 전자 우편이 도착하기 까지의 과정에서, 메타 도메인 네임 서버와 부가 서비스 메일 서버 그리고 웹서버가 어떻게 상호 작용하는지를 예시하는 흐름도가 [도 2]로 첨부되어 있다.

첨부된 도면 [도 3] 는 수신자가 온라인 상태에서 상기의 과정을 거쳐 받은 메일을읽을 때, [도 2] 의 과정 4에서 추가된 HTML 태그에 의하여, 릴레이 서버내의 웹서버와 상호 작용을 통하여, 수신 확인 통보가 송신자에게 보내지는 과정의 흐름을 나타내는 도면이다.

이때, 수신지 메일 클라이언트는 인터넷에 온라인 연결되어 있는 상태이고, 동시에 HTML 태그를 화면에 나타낼 수 있는 보편적인 기능을 가지고 있는 것으로 가정한다. (예를 들면, Microsoft 사의 Outlook Express, Netscape 사의 Netscape Messenger, Eudora의 Eudora Pro 등)

[4.다. 부가 서비스를 위한 메시지 변환 과정 상세 설명 ]

각 전자 우편 메시지마다 고유 일련 번호를 부여하고, 이 일련 번호를 키로 하는, 수신 상황 데이타를 저장할 수 있는 수신 상태 데이타베이스 레코드를 생성한다. 메시지 본문의 HTML 버전에, 위에서 발급한 고유 일련 번호와 수신자 전자 우편 주소등의 정보를 함축하고 있는 URL 을 포함하고 있는, HTML 문서를 삽입한다.

최종 수신자가 동 메시지를 수신하여, 화면 상에 디스플레이할 때, 삽입된 HTML 태그에 의하여 자동적으로 또는 수신자의 인지된 행동에 의해, 그 URL 이 릴레이 서버의 웹서버와 HTTP 프로토콜에 의한 상호 작용을 일으켜, 수신 확인 상태 데이타베이스에 반영될 수 있도록, 적절한 HTML 태그를 선택한다.

예를 들어, ＜img src=http://microsoft.com.confirm.to /read /MESSAGE_ID / bill@microsoft.com width=1 height=1＞ 와 같은 태그를 본문 뒤에 삽입할 수 있다. 가로와 세로의 크기가 각각 1도트인 이미지 태그로서, 수신자 눈에 잘 띄지 않으면서도, 수신자가 메일을 열어 읽는 순간, http 요구가 지정된 릴레이 서버내의 웹서버로 수신 상황 정보를 포함하는 URL 요구를 보내게 되어, 상태 데이타베이스를 갱신할 수 있게 할 수 있다.

HTML 태그의 본문 추가를 위해서는, 메일 메시지 본문이 HTML 유형이어야 하므로, 메시지 변환 단계에서, 본문이 일반 텍스트(MIME 유형이 text/plain)로만 되어 있는 경우, HTML 형식으로 자동 변환시킨 후 HTML 태그를 추가시킨다.

웹서버는 수신 사실을 해당 데이타베이스 레코드에 반영하고, 레코드안에 기록되어 있는 원 송신자 주소로 수신 확인 통보 메시지를 생성하여 전송한다. 수신자 주소에 .confirm.cc 가 도메인 접미어로 붙었었다면, 송신자뿐 아니라, 전자 우편 메시지에 명시된 타 수신자에게도 확인 메시지를 전송한다.

[5. 복권 메일 송신 부가 서비스 시스템 ]

본 발명의 인터넷 전자우편 부가 서비스 시스템의 한 특화된 발명으로 구축되는 이 복권 메일 송신 부가 서비스의 구축 과정은 다음과 같다.

과정 1) 본 발명의 [요소 .1]의 부가 서비스 메일 주소 표기 체제 틀에 의거하여, 복권 메일 송신 부가 서비스를 위한 주 도메인 접미어로, 인터넷에 공식적으로 등록된 2차 도메인을 선택하여 등록하여 확보한다.

이를 위하여, "loto.to" 라는 인터넷 도메인명을 확보하였다면, 부가 서비스의 의미를 다음과 같이 정한다. .loto.to 도메인 접미어를 메일 주소뒤에 붙여 송신하면, 수신자를 위해 발급된 온라인 복권이 메시지에 부가하여 전달되게 한다. .loto.to. 대신에 다른 도메인도 확보가능하다면 대체할 수 있다. 보조 도메인 접미어를 지정할 수 도 있는데, 이 때 구문 형식은 add.*. 로 하면, *(asterisk)에 들어갈 내용은 미리 송신자들에게 공지된 복권의 종류에 대한 기호가 들어갈 수 있게 한다. 예들들어, apple.com.add.motorola.loto.to 같은 도메인이 가능하다.

과정 2) 본 발명의 [요소 .3]의 메타 도메인 네임 시스템의 구축 틀에 의거하여, .loto.to 를 주 도메인 접미어로 하고, 상기의 보조 도메인 접미어 구문을 지원하는 메타 도메인 네임 데이타베이스를 구축한다. DOMAIN.loto.to 에 대하여, 서비스를 담당할 메일 호스트 머신들을 확보한 후, 그 IP주소를 등록한다.

과정 3) 본 발명의 [요소. 2]의 릴레이형 부가 서비스 메일 서버 구축 틀에 의거하여, 복권 송신 부가 서비스를 구현할 메시지 수정형 전자 우편 릴레이 서버 시스템를 구축한다. 당첨된 복권 수신자에 대한 상태 정보 데이타베이스 관리가 필요한 서비스이므로, 이를 위해, 메지시 처리시 릴레이 서버에 메시지별 복권 당첨 상태 데이타 베이스 레코드를 함께 생성 관리하며, 수신자가 메일을 열어 읽을 때, 자신에게 발급된 온라인 복권에 대한 정보를 알 수 있도록, 수정된 메시지에 HTML 태그들이 삽입되도록 처리한다. 이 서버 시스템을 과정 2)에서 데이타베이스에 등록된 각 릴레이 메일 서버 호스트 머신에 설치한다.

[6. 그림 엽서 송신 부가 서비스 시스템 ]

본 발명의 인터넷 전자우편 부가 서비스 시스템의 한 특화된 발명으로 구축되는 이 그림 엽서 송신 부가 서비스의 구축 과정은 다음과 같다.

과정 1) 본 발명의 [요소 .1]의 부가 서비스 메일 주소 표기 체제 틀에 의거하여, 인터넷에 공식적으로 등록된 2차 도메인을 선택하여 등록하여 확보한다.

이를 위하여, "post-card.to" 라는 인터넷 도메인명을 확보하였다면, 부가 서비스의 의미를 다음과 같이 정한다. .post-card.to 도메인 접미어를 메일 주소뒤에 붙여 송신하면, 그림 엽서가 메시지 본문의 배경을 장식한 HTML 유형의 메시지가 전달되게 한다. .post-card.to. 대신에 다른 도메인도 확보가능하다면 대체할 수 있다. 보조 도메인 접미어를 지정할 수 도 있는데, 이 때 구문 형식은 add.*. 로 하며, * (asterisk)에는 송신자들에게 공지된 그림 엽서의 종류에 대한 기호가 들어갈 수 있게 한다. 예들들어, apple.com.add.yosemite-park.post-card.to 같은 보조 도메인 접미어가 붙은 주소가 가능하다.

과정 2) 본 발명의 [요소 .3]의 메타 도메인 네임 시스템의 구축 틀에 의거하여, .post-card.to 를 도메인 접미어로 하는, 상기의 보조 도메인 접미어 구문을 지원하는 메타 도메인 네임 데이타베이스를 구축한다. DOMAIN.post-card.to 에 대하여, 서비스를 담당할 메일 호스트 머신들을 확보한 후, 그 IP주소를 등록한다.

과정 3) 본 발명의 [요소. 2]의 릴레이형 부가 서비스 메일 서버 구축 틀에 의거하여, 그림 엽서 송신 부가 서비스를 구현할 메시지 수정형 전자 우편 릴레이 서버 시스템를 구축한다. 릴레이 서버는 그림 엽서의 기호와 그 내용을 담은 데이타베이스를 가지고 있어야 하며, 보조 접미어 도메인에 명시된 그림 엽서의 종류를 분석하여, 수정된 메시지의 본문 배경에 그림 엽서가 들어갈 수 있도록, HTML 태그들을 삽입한다. 이 서버 시스템을 과정 2)에서 데이타베이스에 등록된 각 릴레이 메일 서버 호스트 머신에 설치한다.

[7. 메일 번역 송신 부가 서비스 시스템 ]

본 발명의 인터넷 전자우편 부가 서비스 시스템의 한 특화된 발명으로 구축되는 이 메일 번역 송신 부가 서비스의 구축 과정은 다음과 같다.

이를 위하여, "interpret.to" 라는 인터넷 도메인명을 확보하였다면, 부가 서비스의 의미를 다음과 같이 정한다. .interpret.to 도메인 접미어와 .from.LANG1.to.LANG2 와 같은 유형의 보조 도메인 접미어를 함께 메일 주소뒤에 붙여 송신하면, 메시지에 대한 지정한 언어로의 번역 작업을 거친 새로운 메시지가 수신자에게 보내지는 서비스이다. .interpret.to. 대신에 다른 도메인도 확보가능하다면 대체할 수 있다. 보조 도메인 접미어의 구문 형식은 from.*.to.* 로 하며, * (asterisk)에는 송신자들에게 공지된 번역 서비스의 종류에 따른 언어에 대한 기호들이 들어갈 수 있게 한다. 예들들어, apple.com.from.english.to.french .interpret.to 같은 보조 도메인 접미어가 붙은 주소가 가능하다.

과정 2) 본 발명의 [요소 .3]의 메타 도메인 네임 시스템의 구축 틀에 의거하여, .interpret.to 를 도메인 접미어로 하는, 상기의 보조 도메인 접미어 구문을 지원하는 메타 도메인 네임 데이타베이스를 구축한다. DOMAIN.interpret.to 에 대하여, 서비스를 담당할 메일 호스트 머신들을 확보한 후, 그 IP주소를 등록한다.

과정 3) 본 발명의 [요소. 2]의 릴레이형 부가 서비스 메일 서버 구축 틀에 의거하여, 언어 번역 송신 부가 서비스를 구현할 메시지 수정형 전자 우편 릴레이 서버 시스템를 구축한다. 이 서버 시스템을 과정 2)에서 데이타베이스에 등록된 각 릴레이 메일 서버 호스트 머신에 설치한다.

본 발명의 인터넷 전자우편 부가 서비스 시스템을 사용하면, 송신자는 단지 수신자 전자우편 주소뒤에 부가 서비스별 도메인 접미어를 붙여 우편을 발송하면 되며, 부가 서비스 주체측의 한개 혹은 2개 이상의 서비스 호스트에 의해, 도메인 접미어에 지정된 부가 서비스가 자동 수행된다.

따라서, 송신자측 전자 우편 서버 및 클라이언트 소프트웨어의 교체가 필요없이도, 서비스 주체측의 준비만으로 전세계적인 동시 서비스가 가능해, 다양한 전자 우편 부가 서비스들이 신규 등장하여, 빠르게 전세계로 확산시키는데 유리하다. 이는 인터넷 전자 우편 서비스의 새로운 등장과 상호간의 경쟁 및 혁신 (innovation)을 유도할 것이다.

Claims

(1) 특정 전자우편 부가 서비스를 위하여 선택된 도메인 접미어 (.suffix)가 덧붙여진, USERID @ DOMAIN.suffix 형식의 수신자 메일 주소의 구문 구조와 그 의미에 대한 일련의 정의로 구성되며, 상기의 도메인 접미어는, 인터넷에 공식 등록된 도메인명에서 선택된 주 도메인 접미어와 주 도메인 접미어가 대표하는 부가 서비스를 수식하여 한정하는 보조 도메인 접미어의 두 요소로 구성되는 것을 특징으로 하는 도메인 접미어 전자우편 주소 표기 체계 (domain suffix email address representation system) 와;

(2) 도메인 네임이 DOMAIN.suffix 유형인 인터넷 호스트상에 설치되는 것과 전자우편 수신자 주소가 USERID @ DOMAIN.suffix 유형인 메시지를 수신하여, 도메인 접미어 .suffix에 명기된 주 도메인 접미어와 보조 도메인 접미어의 내용에 따라는 상기의 (1)에서 정의된 부가 서비스 처리 및 그 옵션 사항을 상기의 메시지에 적용하여 새 메시지를 만든 다음, 원래의 수신자 주소 USERID@DOMAIN 으로 재전송 (relay)하는 것을 특징으로 하는 릴레이 모드 부가 서비스 메일 서버 (relay mode add-on service mail server ) 와 ;

(3) DOMAIN.suffix 유형의 도메인명과, 이 DOMAIN 영역에 대하여 .suffix 가 지정하는 특정 부가 서비스를 담당하는 릴레이 모드 메일 서버 호스트의 IP 주소와의 대응관계를 나타내는 메타 도메인 네임 데이타베이스와 이를 서비스하기 위한 도메인 네임 서버 소프트웨어로 구성되는 메타 도메인 네임 시스템 (meta domain name system) 으로

구성되는 전자우편 부가 서비스 시스템.
제 1항에 있어서,

(1) 보조 도메인 접미어가 부가 서비스의 옵션 사항을 수식하기 위해, 가변 인수(variable parameter)를 포함하는 구문 구조를 가지는 것을 특징으로 하는 도메인 접미어 전자우편 주소 표기법과;

(2) 가변 인수 구문 구조를 포함하는 메타 도메인 네임 데이타베이스와 이를 서비스하기 위한 메타 도메인 네임 서버로 구성되는 메타 도메인 네임 시스템을

특징으로 하는, 전자 우편 부가 서비스 시스템
제 1항에 있어서,

1) .to와 .cc를 최상위 도메인으로 하는 동일명의 2차 도메인 한쌍을 주 도메인 접미어로 사용하고, 이가운데, .to를 포함하는 주 도메인 접미어는 송신자에게만 수신 확인 통보를 전달하는 서비스를 대표하고, .cc를 포함하는 주 도메인 접미어는 송신자 및 수신자를 제외한 타 수신자에게 수신 확인 통보가 전달하는 서비스를 대표하는 것으로 정의하는 도메인 접미어 전자우편 주소 표기법과;

2) 상기의 한쌍의 도메인 접미어에 대한 각각 메타 도메인 네임 시스템과;

3) 수신자측 메일 클라이언트로부터 수신 상황의 보고가 가능토록, HTML 태그를 메시지 본문에 추가하고 메일 메시지별 수신 상황 데이타베이스를 유지하는 메시지 수정형 릴레이 모드 메일 서버와;

4) 상기의 HTML태그가 유발하는 수신자측 메일 클라이언트로부터의 수신 상황의 보고 HTTP 트랜잭션를 처리하여, 수신 확인 통지를 수령 대상자에게 전송하는 웹서버를

특징으로 하는 메일 수신 확인 부가 서비스 시스템
제 1항에 있어서,

1) 수신자에게 발행되었거나 발행될 복권에 대한 정보를 담은 HTML 태그를 메시지 본문에 추가하고 메일 메시지별 복권 당첨 상황 데이타베이스를 유지하는 메시지 수정형 릴레이 모드 메일 서버를

특징으로 하는 복권 메일 송신 부가 서비스 시스템
제 1항에 있어서,

1) 송신자가 수신자 주소뒤에 덧붙인 도메인 접미어에 의해 지정된 그립 엽서 양식을 선택하여, 메일 메시지에의 엽서 양식 적용을 주 메시지 변형 작업으로 하는 메시지 수정형 릴레이 모드 메일 서버를

특징으로 하는 그림 엽서 송신 부가 서비스 시스템
제 1항에 있어서,

1) 송신자가 수신자 주소뒤에 덧붙인 도메인 접미어에 의해 지정된 언어 번역 지시에 의거하여, 메일 메시지를 번역하여 다시 쓰는 것을 주 메시지 변형 작업으로 하는 메시지 수정형 릴레이 모드 메일 서버를

특징으로 하는 번역 송신 부가 서비스 시스템