KR20030053136A

KR20030053136A - 인터넷 상에서의 전자우편 전송 시스템 및 그 방법

Info

Publication number: KR20030053136A
Application number: KR1020010083181A
Authority: KR
Inventors: 이경운
Original assignee: (주)와이즈패킷
Priority date: 2001-12-22
Filing date: 2001-12-22
Publication date: 2003-06-28

Abstract

본 발명은 협대역 통신망을 경유하는 인터넷 상에서의 전자우편 전송 시스템 및 그 방법에 관한 것으로, 일반적인 전자우편 전송 시스템에 구비된 클라이언트, 메일 서버 환경에 로컬 게이트웨이와 메일 게이트웨이를 더 설치하여 전자우편의 송수신 시에 압축을 수행하고, 메일 게이트웨이가 첨부 파일을 별도의 파일 서버에 저장하고, 저장된 첨부 파일의 URL을 전자우편의 내용에 추가하는 한편, 전자우편의 내용에서 첨부 파일을 비롯한 일부의 내용을 삭제하는 변형을 수행하여 전자우편 전송량을 대폭적으로 절감하는 것을 특징으로 한다. 또한, 본 발명에 의한 전자우편 전송 시스템에서는 전자우편 압축시에 HTML 표현상 불필요한 내용을 삭제하여 최적화하고, 사전기반으로 HTML 키워드들을 대응하는 토큰값으로 변환한 후 압축을 수행하는 것을 특징으로 한다.

본 발명에 의하면, 무선 인터넷과 같은 협대역 통신망을 경유하는 인터넷 상에서 메시지의 변환 및 압축 기능을 지원함으로써 사용자의 통신비용을 획기적으로 절감시킬 수 있다.

Description

인터넷 상에서의 전자우편 전송 시스템 및 그 방법{E-mail transfer system on Internet and method thereof}

본 발명은 인터넷 환경에서의 전자우편 전송 시스템에 관한 것으로, 보다 상세하게는 협대역 통신망을 경유하는 인터넷 상에서의 전자우편 전송 시스템 및 그 방법에 관한 것이다.

일반적으로, 인터넷상에서 클라이언트가 전자우편을 송신하는 경우 SMTP(Simple Mail Transfer Protocol)을 사용하고, 전자우편을 수신하는 경우 POP3(Post Office Protocol 3)나 IMAP(Internet Message Access Protocol)을 사용하고, 그 편지의 내용은 RFC822(Request for Comments #822) 표준으로 규정된다.

여기서, SMTP는 전자우편을 보내고 받는데 사용되는 TCP/IP(Transmission Control Protocol/Internet Protocol) 프로토콜로서, 메인프레임급 컴퓨터에서 단말기 수준의 디바이스에 이르기까지 다양한 종류의 디바이스를 지원하므로 ASCII(American Standard Code for Information Interchange) 7비트 문자열만 사용하기를 권고하고 있다. 따라서, 한국어와 같은 DBCS(double-byte character set)를 사용하여 문자를 표현하거나, 이미지 파일과 같은 이진 코드의 파일을 사용할 때에는 ASCII 문자열로 인코딩하여 전송하여야 한다.

실례로, 대표적인 전자우편 프로그램인 아웃룩 익스프레스로 다음과 같은 내용을 전송하고자 한다고 가정하자.

안녕! 이 우편은 테스트 프로그램입니다.

이 내용에 담긴 정보량은 38 바이트이다. 하지만, 아웃룩 익스프레스는 이 정보를 원문 그대로인 Plain Text로 전송하지 않고, 그 기본 설정값인 HTML(Hypertext Markup Language)로 다음과 같이 변환하여 전송한다.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

</HEAD>

<DIV><SPAN

style="FONT-SIZE: 10pt; FONT-FAMILY: 바탕; mso-bidi-font-size: 12.0pt; mso-hansi-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: KO; mso-bidi-language: AR-SA">안녕<SPAN

lang=EN-US>! 이 우편은 테스트 프로그램입니다</SPAN></SPAN></DIV></BODY></HTML>

따라서, 38 바이트에 담긴 정보는 619 바이트로 변환되게 되며, 또한 이 내용에는 ASCII문자 이외에 DBCS가 포함되어 있기 때문에 다음과 같이 base64로 인코딩되어 전송된다.

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS41MC40ODA3LjIzMDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ILnZxcE7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj6+yLPnPFNQQU4gDQpsYW5nPUVOLVVTPiEgwMwgv+zG7cC6IMXXvbrGriDHwbfOsde3pcDUtM+02TwvU1BBTj48L1NQQU4+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg==

결국, 최종적으로는 752 바이트에 해당하는 전자우편 내용이 전송되는데, 이와 같은 전자우편의 내용에 전자우편 헤더정보가 포함되어 전송되는 전체 바이트 수는 1599 바이트이다. 이와 같이 38 바이트의 내용을 전송하기 위하여 1599 바이트가 소비된다는 것은 네트워크 대역폭의 비용이 매우 큰 환경에서는 상당한 문제점이 될 수 있다.

일반적으로, 충분한 대역폭이 확보된 초고속 인터넷 환경에서는 전자우편이 압축된 상태에서 전송되거나 압축되지 않은 상태에서 전송되는 것이 사용자에게는 큰 차이점을 보이지 않는다. 이는 전자우편 내용의 크기가 초고속 인터넷 환경에서 전송되는 동영상 자료나 음악 자료의 크기에 비하여 무시해도 될 만큼 적은 분량이기 때문이다. 하지만, 인터넷 접속기기가 일반전화망에서 56K 모뎀을 사용하여 PPP(Point-to-Point Protocol) 방식으로 인터넷에 접속하는 경우에는, 압축 여부에 따라 통신 시간의 차이가 상당히 크다. 따라서, 모뎀에서는 V.42bis와 같은 하드웨어 압축 프로토콜을 사용하여 자료를 압축하여 송수신하고 있다.

이에 비하여, 인터넷 접속기기가 CDMA(code-division multiple access)망을 통한 무선 인터넷을 이용하는 경우에도 PPP 방식으로 인터넷에 접속하지만, 일반 유선전화망과는 달리 V.42bis 압축을 하지 않은 상태에서 자료를 송수신한다. 특히, CDMA2000-1X 데이터 통신망에서는 이동통신사들이 패킷의 자료량에 의거하여 과금을 하기 때문에(예를 들어, 2001년 12월 현재 과금체계에 의하면 512 바이트당 2.5원), 압축 여부가 사용자에게 매우 의미가 크다고 할 수 있다.

또한, POP3 프로토콜을 사용하여 전자우편을 수신하는 경우, 전자우편의 사용자는 첨부 파일을 포함한 모든 메시지를 다운로드 받아야 한다. 일반적으로, 전자우편의 사용자가 먼저 관심을 갖는 것은 메시지 중 HTML 파일이고, 첨부 파일은 HTML 파일 내용을 확인한 후 사용자의 선택에 따라 다운로드 여부를 결정하도록 하는 것이 바람직하다. 그러나, 종래의 POP3 프로토콜에 따르면, 이와 같은 선택적 다운로드 기능을 제공하지 않아 불필요한 첨부 파일까지 다운로드 받아야 하므로,사용자의 통신요금에 대한 부담을 가중시킨다.

본 발명은 상기의 문제점을 해결하기 위하여 창안된 것으로, 무선 인터넷과 같은 협대역 통신망을 경유하는 인터넷 상에서 메시지의 변환 및 압축 기능을 지원함으로써 사용자의 통신비용을 절감시킬 수 있는 인터넷 상에서의 전자우편 전송 시스템 및 그 방법을 제공함을 목적으로 한다.

도 1은 본 발명에 의한 인터넷 상에서의 전자우편 전송 시스템의 전체적인 구성을 도시한 블록도이다.

도 2a 내지 도 2c는 각각 본 발명에 따라 수정된 SMTP, POP3, IMAP 프로토콜을 예시적으로 도시한 것이다.

도 3a는 본 발명에 의한 전자우편 전송 시스템에 의해 제1 클라이언트가 메일 서버로 전자우편을 송신하는 과정을 도시한 것이다.

도 3b는 본 발명에 의한 전자우편 전송 시스템에 의해 제2 클라이언트가 메일 서버로부터 전자우편을 수신하는 과정을 도시한 것이다.

도 4는 본 발명에 의한 전자우편 압축부에 적용된 전자우편 압축 과정을 도시한 흐름도이다.

도 5는 본 발명에 의한 전자우편 압축해제부에 적용된 전자우편 압축해제 과정을 도시한 흐름도이다.

도 6a 내지 도 6d는 각각 샘플 HTML 문서, 노드 트리, 최적화된 노드 트리, 압축해제된 HTML 문서를 도시한 것이다.

상기의 목적을 달성하기 위하여, 본 발명에 의한 인터넷 상에서의 전자우편 전송 시스템은 전자우편 서비스를 요청하는 다수의 클라이언트; 클라이언트에 접속하여 클라이언트가 송신하는 전자우편을 압축하고 클라이언트로 수신되는 전자우편을 압축해제하는 다수의 로컬 게이트웨이; 협대역 통신망을 경유하는 인터넷; 전자우편 서비스를 제공하는 메일 서버; 전자우편에 포함된 첨부 파일을 저장하는 파일 서버; 및 클라이언트가 전송한 전자우편을 압축해제하여 메일 서버로 전달하는 전자우편 압축해제부, 메일 서버가 클라이언트로 전송하는 전자우편을 전달받아 그 내용을 분석하는 전자우편 분석부, 전자우편 분석부에 의해 분석된 전자우편에 첨부 파일이 포함되어 있는 경우 그 첨부 파일을 파일 서버에 저장하는 첨부파일 저장부, 첨부파일 저장부에 의해 저장된 첨부 파일의 URL을 HTML 링크로서 전자우편의 내용에 추가하여 전자우편 분석부에 의해 분석된 전자우편을 재구성하는 전자우편 재구성부 및 전자우편 재구성부에 의해 재구성된 전자우편을 압축하여 로컬 게이트웨이를 거쳐 클라이언트로 전송하는 전자우편 압축부를 구비하는 메일 게이트웨이를 포함하여 구성된다.

상기의 다른 목적을 달성하기 위하여, 본 발명에 의한 협대역 통신망을 경유하는 인터넷 상에서의 전자우편 전송 시스템에 의해 전자우편을 송수신하는 방법은 (a) 제1 클라이언트가 메일 서버로 송신하는 전자우편을 제1 로컬 게이트웨이에서 압축하여 메일 게이트웨이로 인터넷을 통해 전송하는 단계; (b) 메일 게이트웨이가 제1 로컬 게이트웨이에서 압축된 전자우편을 압축해제하여 메일 서버로 전달하는 단계; (c) 제2 클라이언트가 제2 로컬 게이트웨이 및 메일 게이트웨이를 통해 메일 서버로 전자우편을 요청하는 단계; (d) 메일 서버가 제2 클라이언트로 송신하는 전자우편 메시지를 메일 게이트웨이가 분석하는 단계; (e) 분석된 전자우편에 첨부 파일이 포함되어 있는 경우, 메일 게이트웨이가 그 첨부 파일을 파일 서버에 저장하는 단계; (f) 메일 게이트웨이가 분석된 전자우편 내용에 파일 서버에 저장된 첨부 파일의 URL을 추가하여 전자우편의 내용을 재구성하고, 압축하여 제2 로컬 게이트웨이로 전송하는 단계; 및 (g) 제2 로컬 게이트웨이가 메일 게이트웨이에서 압축된 전자우편을 압축해제하여 제2 클라이언트로 전달하는 단계를 포함하여 구성된다.

이하에서 첨부된 도면을 참조하여 본 발명의 바람직한 실시예를 상세히 설명하기로 한다.

도 1에 의하면, 본 발명에 의한 인터넷 상에서의 전자우편 전송 시스템은 클라이언트(60), 클라이언트(60)에 접속된 로컬 게이트웨이(50), 인터넷(40), 메일 서버(10), 메일 서버(10)에 접속된 메일 게이트웨이(30), 파일 서버(20)를 포함하여 구성된다.

클라이언트(60)는 메일 서버(10)가 제공하는 전자우편 서비스를 사용자가 이용할 수 있도록 사용자 단말기(도시되지 않음) 상에서 동작하는 전자우편 프로그램을 의미한다. 여기서, 사용자 단말기는 개인용 컴퓨터, 휴대폰, PDA 등을 포함하는 포괄적인 의미로 사용되고, 사용자는 사용자 단말기 상에서 전자우편 프로그램을 실행시켜 자신의 전자우편을 편집하여 인터넷(40)을 통해 타 사용자에게 송신하고, 타 사용자로부터의 전자우편을 인터넷(40)을 통해 수신하여 확인할 수 있다. 본 발명의 바람직한 일실시예에서, 클라이언트(60)는 SMTP에 의해 전자우편을 송신하고, POP3 또는 IMAP에 의해 전자우편을 수신하며, 전자우편 메시지는 RFC822에 의해 규정된다고 가정한다.

로컬 게이트웨이(50)는 대응하는 클라이언트(60)가 메일 서버(10)로 송신하는 전자우편을 압축하고, 대응하는 클라이언트(60)로 수신되는 전자우편을 압축해제하는 기능을 수행한다. 로컬 게이트웨이(50)는 LZ77, LZ78, BWT와 같은 일반적인 비손실 압축 알고리즘을 이용할 수 있으나, HTML 압축의 특성을 고려할 때 사전기반의 압축 알고리즘을 이용하는 것이 바람직하다.

인터넷(40)이라 함은 TCP/IP(Transmission Control Protocol/Internet Protocol) 프로토콜을 사용하는 전세계를 연결하는 컴퓨터 통신망으로, 여기서는 CDMA망을 통한 무선 인터넷과 같은 협대역 통신망을 경유하는 인터넷이라 가정한다.

메일 게이트웨이(30)는 메일 서버(10)가 송수신하는 전자우편을 변형, 압축,압축해제하는데, 전자우편 압축해제부(310), 전자우편 분석부(320), 첨부파일 저장부(330), 전자우편 재구성부(340) 및 전자우편 압축부(350)를 구비한다.

전자우편 압축해제부(310)는 클라이언트(60)가 전송한 전자우편이 로컬 게이트웨이(50)에 의해 압축되어 있는 경우, 이를 압축해제하여 메일 서버(10)로 전달한다. 따라서, 전자우편 압축해제부(310)는 로컬 게이트웨이(50)의 압축 방식에 대응한 압축해제 방식이 채택하여야 한다.

전자우편 분석부(320)는 메일 서버(10)가 클라이언트(60)로 전송하는 전자우편을 전달받아 그 내용을 분석한다. 메일 서버(10)가 클라이언트(60)로 전송하는 전자우편은 그 속성으로 multipart/mixed와 multipart/alternative가 혼합된 복잡한 구조가 될 수도 있다. 따라서, 전자우편 분석부(320)는 RFC822 타입의 전자우편을 RFC822 파서를 이용하여 분석하고, 다음과 같이 분류한다.

헤더 정보

문서 본문 {속성,

Plain Text 파일,

HTML 파일,

첨부 파일 1,

첨부 파일 2,

....}

이와 같이 분류된 전자우편에서 사용자가 가장 관심을 갖는 내용은 HTML 파일이라고 할 수 있다. 첨부 파일을 확인하는 것은 사용자가 HTML 파일을 확인한 후의 판단에 따라 수행되는 것이 바람직하다. 이를 위해, 첨부파일 저장부(330)는 전자우편 분석부(320)에 의해 분석된 전자우편에 첨부 파일이 포함되어 있는 경우 그 첨부 파일을 별도의 파일 서버(20)에 저장하여 둔다. 또한, 전자우편 재구성부(340)는 사용자에게 첨부 파일이 존재한다는 사실을 알려주고 첨부 파일을 별도로 다운로드받을 수 있는 방법을 제공하기 위하여, 첨부파일 저장부(330)에 의해 파일 서버(20)에 저장된 첨부 파일의 URL(Uniform Resource Locator)을 HTML 링크로서 전자우편의 본문에 추가한다. 따라서, 전자우편의 본문에서 첨부 파일은 삭제될 수 있다.

한편, 모든 형태의 전자우편 프로그램이 HTML을 지원하는 것은 아니므로, multipart/alternative 속성이 규정되는 경우 HTML 파일과 더불어 Plain Text 파일이 전자우편에 포함된다. 그러나, 본 발명에서 사용되는 사용자 단말기에 탑재된 모든 형태의 전자우편 프로그램, 즉 클라이언트(60)가 HTML을 지원한다고 가정한다면, multipart/alternative 속성과 Plain Text 파일은 전자우편의 내용 중에서 삭제될 수 있다. 이와 같이, 전자우편 재구성부(340)는 전자우편 분석부(310)에 의해 분석된 전자우편에서 첨부 파일의 URL을 HTML 링크로서 추가하고, 속성, Plain Text 파일 및 첨부 파일을 삭제하여 전자우편의 본문을 다음과 같이 재구성한다.

헤더 정보

문서 본문 {HTML 파일( + 첨부파일정보 삽입)}

전자우편 압축부(350)는 전자우편 재구성부(340)에 의해 재구성된 전자우편을 압축하여 로컬 게이트웨이(50)를 거쳐 클라이언트(60)로 전송한다. 이때, 전자우편 압축부(350)에 의한 압축 방식은 로컬 게이트웨이(50)에서의 압축 방식과 동일하다.

압축된 전자우편은 일반적인 송수신 프로토콜에 의해 송수신될 수 없으므로, 다음과 같은 부가적인 프로토콜이 필요하다.

SMTP 프로토콜에 의해 클라이언트(60)에서 메일 서버(10)로 전자우편을 송신하는 경우, 클라이언트(60)는 DATA 라는 명령어로 일반적인 전자우편의 전송을 알려준다. 이에 비하여, 본 발명에서는 도 2a에 예시적으로 도시된 바와 같이 로컬 게이트웨이(50)가 클라이언트(60)로부터의 DATA 명령어를 XDATA 라는 새로운 명령어로 변환하여 메일 게이트웨이(30)를 전송한 다음, 클라이언트(60)로부터 전달받은 전자우편을 압축하여 메일 게이트웨이(30)로 전송한다. 따라서, 메일 게이트웨이(30)는 XDATA 라는 명령어를 전달받은 경우 DATA 라는 명령어로 변환하여 메일 서버(10)로 전달한 다음, 전송된 전자우편은 압축해제하여 메일 서버(10)로 전송한다.

POP3 프로토콜에 의해 클라이언트(60)가 메일 서버(10)로부터 전자우편을 수신하는 경우, 메일 서버(10)는 RETR 이라는 명령어로 일반적인 전자우편의 전송을 알려준다. 이에 비하여, 본 발명에서는 도 2b에 예시적으로 도시된 바와 같이 메일 게이트웨이(30)가 메일 서버(10)로부터의 RETR 명령어를 XTETR 라는 새로운 명령어로 변환하여 로컬 게이트웨이(50)를 전송한 다음, 메일 서버(10)로부터 전달받은 전자우편을 변형하여 로컬 게이트웨이(50)로 전송한다. 따라서, 로컬 게이트웨이(50)는 XRETR 이라는 명령어를 전달받은 경우 RETR 이라는 명령어로 변환하여 클라이언트(60)로 전달한 다음, 전송된 전자우편은 압축해제하여 클라이언트(60)로 전송한다.

IMAP4 프로토콜에 의해 클라이언트(60)가 메일 서버(10)로부터 전자우편을 수신하는 경우, 메일 서버(10)는 FETCH 라는 명령어로 일반적인 전자우편의 전송을 알려준다. 이에 비하여, 본 발명에서는 도 2c에 예시적으로 도시된 바와 같이 메일 게이트웨이(30)가 메일 서버(10)로부터의 FETCH 명령어를 XFETCH 라는 새로운 명령어로 변환하여 로컬 게이트웨이(50)를 전송한 다음, 메일 서버(10)로부터 전달받은 전자우편을 변형하여 로컬 게이트웨이(50)로 전송한다. 따라서, 로컬 게이트웨이(50)는 XFETCH 라는 명령어를 전달받은 경우 FETCH 라는 명령어로 변환하여 클라이언트(60)로 전달한 다음, 전송된 전자우편은 압축해제하여 클라이언트(60)로 전송한다.

이하에서는 도 3a 및 도 3b를 참조하여 협대역 통신망을 경유하는 인터넷 상에서의 전자우편 전송 시스템에 의해 전자우편을 송수신하는 과정에 대하여 상세히 설명한다. 여기에서, 전자우편을 송신하는 클라이언트를 제1 클라이언트(60a)라 하고, 제1 클라이언트(60a)가 송신한 전자우편을 수신하는 클라이언트를 제2 클라이언트라(60b) 한다. 또한, 제1 클라이언트(60a)와 연결된 로컬 게이트웨이를 제1로컬 게이트웨이(50a)라 하고, 제2 클라이언트(60b)와 연결된 로컬 게이트웨이를 제2 로컬 게이트웨이(50b)라 한다.

먼저, 도 3a를 참조하여, 제1 클라이언트(60a)에서 메일 서버(10)로 전자우편을 송신하는 과정을 설명하기로 한다.

제1 클라이언트(60a)가 DATA 명령어를 제1 로컬 게이트웨이(50a)로 보내면, 제1 로컬 게이트웨이(50a)는 DATA 명령어 대신 XDATA 명령어를 인터넷을 통해 메일 게이트웨이(30)로 송신하고, XDATA 명령어를 전송받은 메일 게이트웨이(30)는 이후에 전송되는 전자우편이 압축된 전자우편이란 것을 인식한 다음 XDATA 명령어 대신 DATA 명령어를 메일 서버(10)로 전달한다. 이후, 제1 로컬 게이트웨이(50a)는 제1 클라이언트(60a)가 송신하는 전자우편을 압축하여 인터넷을 통해 메일 게이트웨이(30)로 전송하고(S100, S110, S120), 메일 게이트웨이(30)는 전송된 전자우편을 압축 해제하여 메일 서버(10)로 전달한다(S130, S140). 이와 같은 과정을 통하여, 제1 클라이언트(60a)와 메일 서버(10) 사이에서는 전자우편의 압축 및 압축 해제 과정과는 전혀 상관없이 전자우편이 전송된다.

다음으로, 도 3b를 참조하여, 제2 클라이언트(60b)가 메일 서버(10)로부터 전자우편을 수신하는 과정을 설명하기로 한다.

제2 클라이언트(60b)는 제2 로컬 게이트웨이(50b) 및 메일 게이트웨이(30)를 통해 메일 서버(10)로 전자우편을 요청한다(S200, S210, S220). 이에 따라, 메일 서버(10)가 RETR 또는 FETCH 명령어를 메일 게이트웨이(30)로 보내면, 메일 게이트웨이(30)는 RETR 또는 FETCH 명령어 대신 XRETR 또는 XFETCH 명령어를 인터넷을 통해 제2 로컬 게이트웨이(50b)로 송신하고, XRETR 또는 XFETCH 명령어를 전송받은 제2 로컬 게이트웨이(50b)는 이후에 전송되는 전자우편이 압축된 전자우편이란 것을 인식한 다음 XRETR 또는 XFETCH 명령어 대신 RETR 또는 FETCH 명령어를 제2 클라이언트(60b)로 전달한다. 이후, 메일 게이트웨이(30)는 메일 서버(10)가 송신하는 전자우편을 분석하고(S230, S240), 분석된 전자우편에 첨부 파일이 포함되어 있는 경우 그 첨부 파일을 파일 서버(20)에 저장하고(S250), 저장된 첨부 파일의 URL을 분석된 전자우편의 내용에 추가하여 재구성하고(S260), 재구성된 전자우편을 압축하여 제2 로컬 게이트웨이(50b)로 인터넷을 통해 전송한다(S270, S280). 그러면, 제2 로컬 게이트웨이(50b)는 전송된 전자우편을 압축 해제하여 제2 클라이언트(60b)로 전달하고(S290, S300), 제2 클라이언트(60b)는 압축 해제된 전자우편의 내용을 확인하게 된다(S310). 이후, 제2 클라이언트(60b)가 전자우편에 첨부된 첨부 파일의 내용을 확인하고자 하는 경우에는, 전자우편의 본문에 포함된 첨부 파일의 URL을 통해 파일 서버(20)에 저장된 첨부 파일의 내용을 직접 액세스할 수 있다(S320). 이와 같은 과정을 통하여, 제2 클라이언트(60b)와 메일 서버(10) 사이에서는 전자우편의 변형, 압축 및 압축 해제 과정과는 전혀 상관없이 전자우편이 전송될 수 있다.

이하에서는 본 발명의 로컬 게이트웨이 및 메일 게이트웨이에서 사용되는 사전기반의 압축 알고리즘에 대하여 보다 상세히 설명하고자 한다.

데이터 압축은 정보원에 대한 모델링과 부호화 과정을 통해 이루어진다. 일반적으로, 정보원의 성질에 대한 사전 지식을 알고 있는 경우 최적의 모델을 구축할 수 있고, 이 모델에 의해 효율적인 부호화를 수행할 수 있다. 하지만, 현재 가장 널리 사용되는 LZ77, LZ78, BWT와 같은 비손실 압축기법의 경우, 입력되는 기호열의 통계적 성질에 관계없이 어떤 정보원으로부터 생성된 기호열에 대하여 부호화하는 기법으로 유니버셜 부호화라고 부른다. 따라서, 텍스트 자료의 압축에 있어서도 LZ77, LZ78, BWT는 우열을 가리기 힘든 압축률, 압축속도 및 신장속도를 보이고 있으므로, 상용 압축 프로그램은 표 1에서 보여지는 바와 같이 각각의 목적에 맞추어 이러한 압축 알고리즘들을 취사 선택하여 사용하고 있다.

HTML 문서도 텍스트 문서이므로 유니버셜 부호화를 통해 압축할 수 있다. 그러나, 각각의 알고리즘에 따른 압축률의 차이가 별로 크지 않고, 이들 알고리즘을 취사 선택하는 것만으로는 압축률을 획기적으로 높이기는 쉽지 아니하다. 그러나, HTML 문서가 갖는 다음과 같은 특성을 이용하면, 압축률을 획기적으로 개선하는 것이 가능하다.

유니버셜 부호화의 경우 입력된 기호열의 크기가 충분히 클 경우에만 이상적인 압축률을 실현할 수 있다, 그런데, HTML 문서의 경우, 그 크기가 통상적으로 수십 KByte에 불과하여 유니버셜 부호화에 의해서는 충분한 압축률을 기대하기는 힘들다. 그러나, HTML 문서는 양식화된 문법을 가지고 있기 때문에, 기호열의 통계적 특성치가 분명하고 모델링이 간단하다. 따라서, 입력되는 기호열에 대한 통계적 특성에 의한 사전 모델링을 수행할 경우 유니버셜 부호화에 비하여 압축률을 획기적으로 높일 수 있을 것이다.

일반적으로 비손실 정보 압축의 경우 정보는 전혀 손상되지 않아야 함을 그 기본 전제로 하고 있다. 그러나, HTML은 표현하고자 하는 정보와 그 정보를 사용자 단말기의 화면에 표현하는 방식을 구성하는 문법으로 구성되어 있다. 이 경우, 그 표현 문법이 다소 바뀌더라도 동일하게 화면에 표시될 수 있다면 실질적인 정보가 전혀 손상되지 않은 것으로 볼 수도 있다. 따라서, 표현문법을 최적화한다면 전체적인 정보량은 대폭 감소하게 된다.

이상과 같은 전제 조건 하에서 HTML 키워드(예를 들면, tag name, attribute, method 등)의 빈출도에 따른 사전을 다음에 예시하는 바와 같이 미리 구축하여야 한다.

HTML01

HEAD02

BODY03

이와 같이, 구축된 사전은 전자우편 압축부 및 전자우편 압축해제부에서 동일하게 관리하여야 하는데, 이를 위해 로컬 게이트웨이는 메일 게이트웨이로부터 항상 최신 버젼의 사전을 다운로드받아 관리하는 것이 바람직하다.

이하에서, 도 4를 참조하여 본 발명에 의한 로컬 게이트웨이 또는 메일 게이트웨이에 구비된 전자우편 압축부가 도 6a에 도시된 바와 같은 샘플 HTML 문서를 압축하는 과정에 대하여 설명한다.

먼저, 전자우편 압축부는 HTML 파서를 통해 도 6a에 도시된 바와 같은 HTML 문서를 구문분석하고(S400), 구문분석된 결과를 가지고 최적화를 위해 도 6b에 도시된 바와 같은 노드 트리를 구축한다(S410).

다음, 전자우편 압축부는 노드 트리에서 HTML 표현에 영향을 미치지 않는 부분(예를 들어, Comment, 공백문자, Newline문자, 등)을 제거하여, 노드 트리를 최적화한다(S420). 따라서, 도 6b에 도시된 바와 같은 노드 트리는 최적화 과정을 통해 도 6c에 도시된 바와 같은 노드 트리로 수정된다.

그 다음, 전자우편 압축부는 미리 구축된 사전을 참조하여 최적화된 노드 트리를 트래버스(Traverse)하면서 키워드들을 대응하는 토큰값으로 치환하여 문서를 재구성한다(S430).

<01><02>Hello!</02></01>

이후, 전자우편 압축부는 LZ77, LZ78, BWT 등과 같은 부호화 알고리즘들 중 미리 선택된 부호화 알고리즘에 의해 재구성된 문서를 압축한다(S440).

이하에서, 도 5를 참조하여 본 발명에 의한 전자우편 압축해제부가 도 5에 도시된 과정을 통해 압축된 문서를 압축해제하는 과정에 대하여 설명한다.

먼저, 전자우편 압축해제부는 LZ77, LZ78, BWT 등과 같은 부호화 알고리즘들 중 미리 선택된 부호화 알고리즘(압축과정에서 선택된 부호화 알고리즘과 동일한 알고리즘)을 이용하여 압축된 문서를 압축해제한다(S500).

<01><02>Hello!</02></01>

이후, 전자우편 압축해제부는 압축해제된 문서를 처음부터 끝까지 스캔하면서 미리 구축된 사전을 참조하여 토큰값들을 원래의 문자열로 치환하여 전자우편의 내용을 도 6d에 도시된 바와 같이 복원한다(S510).

이렇게 복원된 문서(도 6d에 도시된 문서)는 HTML을 채택한 전자우편 프로그램에 의해 사용자 단말기의 화면 상에서 송신된 전자우편 내용(도 6a에 도시된 문서)과 동일하게 표현된다.

이상과 같은 압축 방식에 의한 압축할 경우, 일반적인 Winzip이나 Gzip의 압축 방식에 비하여 40% 이상 좋은 압축률을 산출할 수 있다.

이제까지 본 발명에 대하여 그 바람직한 실시예를 중심으로 살펴보았다. 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명이 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다. 그러므로 개시된 실시예는 한정적인 관점이 아니라 설명적인 관점에서 고려되어야 한다. 본 발명의 범위는 전술한 설명이 아니라 특허청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 발명에 포함된 것으로 해석되어야 할 것이다.

본 출원인의 실험에 의하면, 전자우편 헤더정보를 포함하여 822,151 바이트의 전자우편에 대하여 본 발명에 의한 변형과 압축을 적용한 메시지 크기는 12,919 바이트가 되어, 원래 크기의 약 1.6%로 압축되었다. 따라서, 512 바이트당 통신비용이 2.5원인 경우 4015원에서 64원으로 절감되는 효과를 얻을 수 있다.

Claims

전자우편 서비스를 요청하는 다수의 클라이언트;

클라이언트에 접속하여 클라이언트가 송신하는 전자우편을 압축하고 클라이언트로 수신되는 전자우편을 압축해제하는 다수의 로컬 게이트웨이;

협대역 통신망을 경유하는 인터넷;

전자우편 서비스를 제공하는 메일 서버;

전자우편에 포함된 첨부 파일을 저장하는 파일 서버; 및

클라이언트가 전송한 전자우편을 압축해제하여 메일 서버로 전달하는 전자우편 압축해제부, 메일 서버가 클라이언트로 전송하는 전자우편을 전달받아 그 내용을 분석하는 전자우편 분석부, 전자우편 분석부에 의해 분석된 전자우편에 첨부 파일이 포함되어 있는 경우 그 첨부 파일을 파일 서버에 저장하는 첨부파일 저장부, 첨부파일 저장부에 의해 저장된 첨부 파일의 URL을 HTML 링크로서 전자우편의 내용에 추가하여 전자우편 분석부에 의해 분석된 전자우편을 재구성하는 전자우편 재구성부 및 전자우편 재구성부에 의해 재구성된 전자우편을 압축하여 로컬 게이트웨이를 거쳐 클라이언트로 전송하는 전자우편 압축부를 구비하는 메일 게이트웨이를 포함함을 특징으로 하는 인터넷 상에서의 전자우편 전송 시스템.
전자우편 서비스를 요청하는 다수의 클라이언트, 클라이언트에 접속하여 클라이언트가 송신하는 전자우편을 압축하고 클라이언트로 수신되는 전자우편을 압축해제하는 다수의 로컬 게이트웨이, 협대역 통신망을 경유하는 인터넷, 전자우편 서비스를 제공하는 메일 서버, 메일 서버에 접속된 메일 게이트웨이, 메일 게이트웨이에 접속된 파일 서버를 포함하여 구성된 인터넷 상에서의 전자우편 전송 시스템에 구비된 메일 게이트웨이에 있어서,

클라이언트가 전송한 전자우편을 압축해제하여 메일 서버로 전달하는 전자우편 압축해제부;

메일 서버가 클라이언트로 전송하는 전자우편을 전달받아 그 내용을 분석하는 전자우편 분석부;

전자우편 분석부에 의해 분석된 전자우편에 첨부 파일이 포함되어 있는 경우, 그 첨부 파일을 파일 서버에 저장하는 첨부파일 저장부;

첨부파일 저장부에 의해 저장된 첨부 파일의 URL을 HTML 링크로서 전자우편 내용에 추가하여 전자우편 분석부에 의해 분석된 전자우편을 재구성하는 전자우편 재구성부; 및

전자우편 재구성부에 의해 재구성된 전자우편을 압축하여 로컬 게이트웨이를 거쳐 클라이언트로 전송하는 전자우편 압축부를 포함함을 특징으로 하는 메일 게이트웨이.
제2항에 있어서, 상기 전자우편 압축부 및 상기 전자우편 압축해제부는

사전기반을 압축 알고리즘을 이용함을 특징으로 하는 메일 게이트웨이.
제2항에 있어서, 상기 전자우편 재구성부는

전자우편 분석부에 의해 분석된 전자우편 내용에서 첨부 파일의 URL을 HTML 링크로서 추가하고, 속성, Plain Text 파일 및 첨부 파일을 삭제하여 재구성하는 것을 특징으로 하는 메일 게이트웨이.
협대역 통신망을 경유하는 인터넷 상에서의 전자우편 전송 시스템에 의해 전자우편을 송수신하는 방법에 있어서,

(a) 제1 클라이언트가 메일 서버로 송신하는 전자우편을 제1 로컬 게이트웨이에서 압축하여 메일 게이트웨이로 인터넷을 통해 전송하는 단계;

(b) 메일 게이트웨이가 제1 로컬 게이트웨이에서 압축된 전자우편을 압축해제하여 메일 서버로 전달하는 단계;

(c) 제2 클라이언트가 제2 로컬 게이트웨이 및 메일 게이트웨이를 통해 메일 서버로 전자우편을 요청하는 단계;

(d) 메일 서버가 제2 클라이언트로 송신하는 전자우편 메시지를 메일 게이트웨이가 분석하는 단계;

(e) 분석된 전자우편에 첨부 파일이 포함되어 있는 경우, 메일 게이트웨이가 그 첨부 파일을 파일 서버에 저장하는 단계;

(f) 메일 게이트웨이가 분석된 전자우편 내용에 파일 서버에 저장된 첨부 파일의 URL을 추가하여 전자우편의 내용을 재구성하고, 압축하여 제2 로컬 게이트웨이로 전송하는 단계; 및

(g) 제2 로컬 게이트웨이가 메일 게이트웨이에서 압축된 전자우편을 압축해제하여 제2 클라이언트로 전달하는 단계를 포함함을 특징으로 하는 전자우편 송수신 방법.
제5항에 있어서,

(h) 전자우편 수신자로부터 첨부 파일 확인을 요청받은 경우, 제2 클라이언트가 첨부 파일의 URL을 이용하여 파일 서버에 저장된 첨부 파일을 액세스하는 단계를 더 포함함을 특징으로 하는 전자우편 송수신 방법.
제5항 또는 제6항에 있어서, 상기 (a) 단계 및 (f) 단계에서의 압축은

(a1) HTML 파서를 통해 전자우편 내용을 구문분석하는 단계;

(a2) 구문분석된 결과를 이용하여 노드 트리를 구축하는 단계;

(a3) 구축된 노드 트리를 최적화하는 단계;

(a4) 최적화된 노드 트리를 트래버스하면서 미리 구축된 사전을 참조하여 키워드들을 대응하는 토큰값으로 치환하여 전자우편 내용을 재구성하는 단계; 및

(a5) 소정의 부호화 알고리즘에 의해 재구성된 전자우편 내용을 압축하는 단계를 포함하여 이루어지고,

상기 (b) 단계 및 (g) 단계에서의 압축해제는

(b1) 압축된 전자우편 내용을 (a5) 단계의 부호화 알고리즘에 의해 압축해제하는 단계; 및

(b2) 압축해제된 전자우편 내용을 차례로 스캔하면서 미리 구축된 사전을 참조하여 토큰값을 대응하는 키워드로 치환하여 전자우편 내용을 복원하는 단계를 포함하여 이루어짐을 특징으로 하는 전자우편 송수신 방법.
제5항 또는 제6항에 있어서, 상기 (f) 단계의 전자우편 재구성은

전자우편 분석부에 의해 분석된 전자우편 내용에서 첨부 파일의 URL을 HTML 링크로서 추가하고, 속성, Plain Text 파일 및 첨부 파일을 삭제하여 재구성하는 것을 특징으로 하는 전자우편 송수신 방법.