티스토리 뷰
초창기 인터넷의 전자 우편은 US-ASCII 문자로 이루어진 메시지의 교환만으로 구성되었다. US-ASCII는 문자열이 오직 7bit만이 필요했기 때문에, SMTP (Simple Mail Transport Protocol : 인터넷을 통하여 메시지를 교환하는 프로토콜)는 7bit의 길이만 통과가 허용되도록 구성되었다. 그러나, 인터넷의 사용이 증가하면서, 일반 프로그램이나, 워드프로세서, 스프레드시트 등 응용 프로그램으로 만들어진 문서에 대한 교환의 필요성이 대두되었는데, 이러한 파일은 각 문자열이 7bit의 길이를 가진 텍스트와는 반대로 8bit를 모두 사용하며 이를 바이너리 파일이라고 부른다. 또한 인터넷의 국제화가 추진되면서, US-ASCII이외의 다른 나라 문자로 이루어진 텍스트 문자열에 대한 전송의 필요성이 생기게 되었다. 영어 이외의 문자는 8번째 최상위 비트(MSB)를 사용하여 표현이 되며, 따라서 8bit의 전송이 필요하다. 우리 나라의 한글의 경우에도 2 byte로 구성되었으며, 1byte내의 MSB가 1로 설정되어야 한다.
8bit문자나 바이너리 파일을 SMTP에 의하여 MSB가 잘리지 않고 안전하게 배달되기 위해서 SMTP를 확장하여, 8bit도 전송할 수 있도록 SMTP를 수정한 ESMTP(Extended Simple Mail Transport Protocol)가 제안1)되기도 하였으나, OSI, X.400등 다른 네트워크와의 파일 교환을 위해서도 또한 네트워크 내의 메일 서버를 바꾸지 않고서도 가능하도록 8bit를 7bit 영문 ASCII코드로 표현하는 방법(encode)과 이를 다시 8bit로 바꾸는 방법(decode)이 고안되었다. 따라서 사용자는 전자 우편으로 파일을 보내기 앞서 인코딩을 시키고, 수신자는 이를 다시 디코딩 하는 방법을 알아야 한다. 그러나 최근의 전자 우편을 다루는 대개의 응용 프로그램은 이러한 인코딩 및 디코딩 방법을 자체적으로 내장하고 있어서 사용자가 굳이 인코딩이나 디코딩 프로그램을 사용하지 않아도 바이너리 파일과 한글 문자를 보낼 수 있다. 이 글은 현재 윈도용으로 나와 있으며, 많은 사람들이 사용하고 있는 E-mail 프로그램에 대하여 분석하고 문제점을 밝힘과 아울러, 이러한 프로그램만으로 지원되지 않을 수도 있는 인코딩 된 메시지를 복원하는 유틸리티에 대하여 다루고자 한다.
한가지 용어에 대한 개념을 추가로 설명하고자 한다. MTA(Mail Transport Agent)는 메일 서버에서 SMTP를 구현하는 프로그램을 지칭하는 용어로, Sendmail, Smail등이 있다. UA 또는 MUA(Mail User Agent)는 사용자가 직접 전자 우편을 다루는 데 이용하는 프로그램을 지칭하는 용어이다.
1. 바이너리 파일의 인코딩 및 디코딩
1) 바이너리 인코딩의 종류
바이너리 파일을 인코딩 하는 방법은 여러 가지가 있다. 대표적인 경우가 UNIX나 DOS에서 많이 쓰였던 uuencode가 있으며, Macintosh 컴퓨터에서는 이들의 특수한 파일을 전송하기 위한 BinHex가 많이 쓰여 왔다. 그러나 불행히도 이들 인코딩 방식은 ASCII코드에 의존적이어서 IBM 메인 프레임에서 쓰이고 있는 EBCDIC코드와 호환이 안되는 일부 문자열을 인코딩에 사용하는 한계를 가지고 있다. 이러한 한계를 극복하고, 모든 시스템에 호환이 되도록 설계한 인코딩 방식이 Base64이다. Base64는 일반 텍스트 이외에 화상, 음성, 동화상 등의 멀티미디어 데이터의 교환과 다국어 지원을 포괄적으로 규정하고 있는 MIME (Multipurpose Internet Mail Extensions)2)에서 정의하고 있는 방식이다.
Base64는 EBCDIC나 ASCII를 포함하여 모든 플랫폼에서 표현되는 International Alphabet IA5를 이용하며, 아래와 같이 64개의 문자와 특수한 기능(pad)을 수행하는 부호인 "="을 같이 사용한다. 또한 각 문자마다 코드와 독립적인 값을 부여하여 시스템의 특성을 타지 않는다.
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
Base64인코딩의 원리는 다음과 같다. 어떤 시스템에서도 통용되는 위의 알파벳 문자 64개가 순서대로, ASCII코드순과는 관계없이 0부터 63까지의 값을 의미한다. 즉 각각 6비트의 값을 의미하는 이들 문자 4개로서 8비트 3개(3 byte)를 표현한다. 바꾸어 말하면, 8비트 3개를 6비트 4개로 나누어, 여기에 해당하는 값을 가진 문자에 대응을 시켜 인코딩하는 것이다. 인코딩된 문장의 끝에 오는 "="기호는 6비트씩 할당하고 남은 나머지를 6비트의 값으로 표현하기 위하여 비트열의 뒷부분에 채워넣는데 사용되는 부호이다. 따라서 어떠한 시스템에서도 코드 순과는 무관한 값으로 비트열을 대응시킬 수 있게 한 방식임을 알 수 있다.
uuencode는 전통적으로 많이 쓰여 온 인코딩 방식이지만, uuencode에서 사용하는 일부 문자가 EBCDIC와 같은 코드를 사용하는 시스템에서 손상을 입게 되는 단점이 있다. uuencode된 메시지는 헤더와 테일러를 가지고 있으며, 헤더와 테일러 이외의 문자는 디코딩에서 제외된다. 헤더는 begin으로 시작하며, 8진수의 모드와 원 파일명으로 구성되어 있다. 인코딩 된 본문은 공백 문자를 가진 라인으로 끝나며, end라는 테일러 라인을 가지고 있다. uuencode에서 인코딩에 쓰이는 64개의 문자는 아래와 같다. uuencode된 파일의 기본 확장자는 .uue 또는 .uu등이 쓰인다.
'!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[^_
uuencode의 원리는 8비트 3쌍을 6비트 4개로 나누는 것은 Base64와 동일하지만 여기에 32(스페이스 코드)를 더하여, 위와 같이 문자로서 표현가능한 ASCII영역에 순서대로 값을 대응 시키는 방식이다. 즉, 인코딩된 문자 값 자체가 ASCII코드값에 의존적이며, 다른 코드시스템에 대응되지 못하는 문자가 존재한다. 인코딩된 본체의 각 라인의 처음 1개의 인코딩된 문자는 라인의 나머지 문자들의 Byte 수를 표시하며, 마지막의 여분 처리 역시 이 문자에 의하여 조절된다. uuencode는 메일에서는 권장되지 않지만, 전통적으로 뉴스그룹에서 주로 쓰이는 방식이다.
BinHex는 매킨토시 시스템의 특수한 파일 구조를 가진 바이너리 데이터를 전송하기 위하여 고안된 인코딩 방식이다. 매킨토시의 파일은 Resource folk라고 부르는 부분과 Data folk라고 하는 부분으로 나뉘어져 있는데, Data folk가 실제 파일의 데이터를 구성하는 부분이며, Resource folk는 맥 시스템 OS와 관련이 있는 아이콘, 변수, Program Segment등에 관한 정보가 들어 있다. 그러나 BinHex도 uuencode와 마찬가지로 시스템에 따라서 왜곡될 수 있는 문자를 포함하고 있으므로 RFC1740에 의하여 제안된 AppleSingle과 AppleDouble의 2가지 Base64 인코딩 방식 중 Resource folk와 Data folk가 별도로 인코딩 된 AppleDouble방식이 권장되고 있다. 그 이유는 수신자가 PC나 UNIX시스템 사용자일 경우에 필요한 Data folk만을 쉽게 추출이 가능하며, 수신자가 매킨토시를 사용하는 경우에도 두 가지 파일 구성 요소를 모두 사용 가능하기 때문이다. BinHex 역시 RFC1741에 의하여 MIME의 한 규격으로 제안되고 있으나, 안전성을 보장할 수는 없다. 이 RFC의 의미는 지금까지 쓰여온 방식에 대한 고육책으로 나온 것이며, 앞으로는 쓰지 않는 것이 좋다는 의미를 내포하고 있다. BinHex의 기본 확장자는 .hqx이며, 다음과 같은 헤더와 64개의 문자를 인코딩에 사용한다. 또한 본문은 :기호로 시작하여 :기호로 끝난다.
(This file must be converted with BinHex 4.0)
!"#$%&'()*+,-012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr
기타 BTOA, USR, XXencode등 여러 가지 인코딩 방식이 존재하지만, 위의 3가지 인코딩이 가장 많이 쓰이고 있다.
2) 바이너리 파일의 인코딩과 디코딩 방법
POP(Post Office Protocol : MTA에 수신된 메일을 원격지에서 찾아 올 수 있도록 설계된 프로토콜)을 구현하는 소프트웨어가 설치된 서버로부터 메일을 받아서 처리하는 많은 윈도용 MUA프로그램이 개발되었다. 그 중 대표적인 몇 가지의 경우를 예로서 인코딩과 디코딩 사용 방법을 소개하고자 한다.
Qualcomm의 Eudora는 공개용 light-version과 상용 version으로 나뉘지만, 메일 송수신에 필요한 기능은 크게 차이가 없다. Eudora가 지원하는 바이너리 파일의 인/디코딩 방식은 MIME(Base64), uuencode, BinHex를 모두 지원한다. 매킨토시용 Eudora의 경우에는 Apple Single과 Apple Double, BinHex, uuencode data folk를 지원하므로 바이너리 파일에 관한 한 대표적인 인코딩 방식을 모두 지원하는 프로그램이라고 할 수 있다. Eudora에서 옵션 설정 부분에서 Attachment항목에 기본 인코딩을 설정하면, 기본 값으로 설정된 인코딩 방식에 의하여 바이너리 파일을 보낼 수 있다. 물론, 새 메시지를 보내는 상태에서 인코딩 방식을 자유롭게 바꾸어 보낼 수 도 있는 장점이 있다. 새 메시지를 보내는 상태에서는 아이콘 바에서 인코딩 방식과 Attach File 아이콘 버튼 또는 Message의 Attach File 메뉴를 실행하여, 적당한 파일을 선택하면 된다. 위의 3가지 인코딩 된 방식의 파일을 받게 되면, 그림1에서 보는 바와 같이 사용자가 지정한 특정 디렉토리에 파일이 저장되며, 본문에 저장된 위치 정보가 표시된다. 모든 메시지는 MIME형태의 헤더와 본문을 가지는데, 약간 규정에 안맞는 것은 uuencode된 파일을 보낼 경우 다음과 같은 헤더로 MIME 메시지를 내 보낸다. 물론 헤더에 x-를 붙이는 경우는 불가피한 경우에 비표준형임을 표시하는 것이다. 그러나 규정에도 없으며, 3번이나 중복된 파일 이름 지정자를 가진 메시지를 보내는 결과를 나타내므로 가능한 한 uuencode를 안쓰는 것이 좋다.
Content-Type: application/octet-stream; name="mytest.bmp"
Content-Transfer-Encoding: x-uuencode
Content-Disposition: attachment; filename="mytest.bmp"
Netscape Communication의 Navigator는 브라우저와 전자 우편, 뉴스 그룹 리더가 모두 포함되어 있어 많은 사용자가 사용하고 있는 프로그램이다. 그러나 Netscape 메일은 바이너리 파일 인코딩에 있어서 MIME규격인 Base64만을 지원한다. 그러나 디코딩에 있어서는 Base64와 uudecode를 모두 지원한다. Netscape 뉴스를 사용하다 보면, jpeg화상이 uuencode되어 있을 때, 본문 가운데, 그림이 디코딩되어 보이는 것을 보았을 것이다. 이것은 Netscape가 MIME의 형태에서 지원한 포맷가운데, Image형식 중 JPEG과 GIF의 경우에 한해서 브라우저 내에 보여주는 것이 선행되기 때문이다. 넷스케이프의 General Preference의 Helpers를 보면, 여러 가지 MIME의 형태와 이에 따른 행위의 종류를 볼 수 있다. MIME규격에 없는 포맷의 경우에는 x-라는 것이 붙어 있는데, 이는 전술한 바와 같이 비표준형임을 뜻한다. 일반적인 바이너리 파일 (응용프로그램이나 워드프로세서 문서 등)은 MIME 규격 중에 application/octet-stream으로 지정되어 있다. 이 경우에는 행위가 Save로 되어 있다. 위의 Eudora의 헤더를 살펴 보면, 같은 경우이지만, 비표준형 x-uuencode로 되어 있는 application/octet-stream 형태이기 때문에 그림 2와 같은 형태가 되며, 디코딩과 저장이 이루어 진다. 그러나, 일반 uuencode된 파일은 image나 기타의 규정이 있을 경우, 예컨데, image/jpeg의 규정이 우선하고, 비록 이를 지정한 Content-Type 헤더가 없을 지라도 이의 확장자가 jpg, jpeg등인 경우에 한해서 브라우저로서 내부 이미지로 보여 주는 것이다. 만일에 뉴스그룹에서 쓰이는 MIME 형태가 아닌 일반 uuencode된 메일이 올 경우에는 디코딩이 이루어지지 않고, 인코딩된 형태의 원문 자체를 그대로 보여 줄 것이다. 유사한 경우가 application/mac-binhex40인 경우이다. Binhex는 포맷 자체안에 파일이름 지정자가 없다. 따라서 RFC 1741에 의하여 권장은 하지 않아도 MIME형태를 규정한 것이며, 이미 파일 이름 지정자가 있고 형태의 종류도 다양한 uuencode에는 이런 식의 MIME 형태규정이 없는 이유이기도 하다. BinHex인 경우에도 저장은 되지만 플러그-인을 구할 것을 물어보는 메시지가 뜬다. 이것은 넷스케이프가 BinHex를 지원하지 않기 때문이다. 여하튼 Base64가 표준적인 인코딩 방식임에는 틀림없다. 메시지 송신에 파일을 첨가할 경우에는 Attachment 버튼을 누르고 Attach File을 선택하면 된다. Attach 방법은 As Is를 선택하여야 한다. 수신된 Base64인코딩 된 파일은 그림2처럼, 마치 HTML의 URL link처럼 보이며, 이 부분을 Click하였을 때, 저장할 위치를 묻는 대화상자가 뜨고, 디코딩과 파일 저장이 이루어진다.
Microsoft Exchange는 당초 FAX서비스와 MSN 등의 온라인 메일, 마이크로소프트 네트워크 메일을 위한 부분만이 윈도95에 포함되어 나왔으나, 플러스 팩 또는 인터넷 익스플로러 2.0과 함께 인터넷 메일을 사용할 수 있는 애드온이 추가되었다. Microsoft Exchange의 인터넷 메일의 설정은 제어판의 "편지와 팩스" 애플릿의 인터넷 메일의 등록 정보 중 "메시지 형식"에서 첨부될 바이너리 인코딩 방식을 선택할 수 있다. 그림 3에서 보는 바와 같이 메시지 보낼 때 MIME사용을 체크하면, 보내는 바이너리 파일은 Base64로 인코딩이 되며, 체크를 하지 않을 경우에는 uuencode가 사용된다. 주의할 것은 Microsoft 메일 프로그램에서의 uuencode는 바이너리 파일에 국한되며, 한글과 같은 8 bit를 사용하는 문자가 uuencode되는 것은 아니다. 이 경우의 텍스트 포맷은 MIME규격이 아닌 헤더가 없는 메시지를 뜻한다. 바이너리 파일을 보낼 때는 익스체인지에서 클립 모양의 파일 삽입 아이콘을 누르던가, 탐색기에서 보낼 파일에 대하여, 파일 보내기 명령을 수행할 때, 편지 수신자를 선택하면 된다. 송신 전의 메시지나 수신 시의 메시지 상에는 첨부한 바이너리 파일이 파일 형태에 대응하는 윈도 아이콘으로 첨부되어 있다.
최근의 인터넷 익스플로러 3.0의 애드온 형태로 공개된 Microsoft Internet Mail에서도 바이너리 파일을 주고받을 수 있는 기능이 있다. 그림 4에서 보는 바와 같이 "서식"에서 설정하며, Base64(MIME)와 uuencode를 지원한다. 덧붙인 파일은 "미리 보기 창"의 "머릿글 정보"에서 클립 모양의 부분을 선택하여 파일을 실행하던가 "별도의 창"을 열어 새 이름으로 저장 등의 행동이 가능하다. 동일한 인터페이스를 가진 Microsoft Internet News에서도 같은 방법이 사용된다. 큰 파일의 경우 uuencode의 경우에 인코더에 따라 여러 개의 메시지로 분할되어 배달이 되는데, 이 경우에는 해당 메시지를 모두 선택하고 오른 쪽 마우스 버튼을 눌러 "합쳐서 디코딩"을 실행하고 순서를 설정한 후 디코딩 하면 된다.
그러나 전술했듯이 메일 프로그램이 모든 바이너리 파일의 인코딩과 디코딩을 지원하지는 않는다. 메일 프로그램과는 달리 인코딩과 디코딩만을 지원하는 프로그램들이 많이 나와 있다. 대표적인 경우가 Wincode(그림 5)이다. Wincode는 Base64와 uuencode, BinHex, BTOA, USR, XXencode등 거의 모든 인코딩과 디코딩을 지원하므로 위에서 언급한 메일 프로그램들의 보조 수단으로 사용하면 좋다. Wincode는 http://www.global2000.net/users/snappy/snappy/wincode.html에서 공개용으로 배포하고 있다. 기타, 윈도용 압축 유틸리티의 하나인 Winzip의 최신 버전은 Base64와 uuencode, BinHex를 지원하므로 이를 이용하여도 될 것이다. Winzip은 http://www.winzip.com/에서 구할 수 있다.
도스용 유틸리티에도 여러 가지가 있지만 MIME을 지원하는 대표적 프로그램으로 mpack과 munpack을 들 수 있다. mpack은 Base64 인코딩을 하는 프로그램이며 munpack은 도스용의 경우 Base64 및 uuencode를 디코딩 하며, 이 두 프로그램은 매킨토시용과 Unix용으로도 나와 있다. 매킨토시용 munpack은 BinHex도 지원한다.
이들 프로그램은 ftp://ftp.andrew.cmu.edu/pub/mpack/에서 구할 수 있으며, 인코딩 방법과 디코딩 방법은 다음과 같다.
C:\>mpack -o OutputFile SourceFile
C:\>munpack EncodedFile
POP이 지원되지 않는 서버의 사용자나, PC통신의 온라인 메일을 사용하는 경우에는 화면 갈무리나 다운(업)로드를 이용하여 Wincode등의 유틸리티로 인터넷 메일을 사용하면 되지만, 다음과 같이 온라인 상에서도 사용 가능한 방법이 있다. UNIX시스템 상에서의 uuencode는 기본적으로 시스템 OS에 채용되어 있다. 물론 Emacs나 Pine, Elm등 MIME규격을 지원하는 Unix용 MUA를 사용하여도 되지만 여기서는 간단한 시스템 OS에서 제공하는 기본 메일 프로그램을 이용하여 uuencode프로그램과 Base64의 인/디코더인 mmencode의 사용법을 소개하고자 한다. 다만 mmencode는 시스템에서 제공하지 않을 수도 있다. 먼저 파일을 인코딩 하는 방법은 아래와 같다.
%mmencode -b SourceFile -o OutputFile
%uuencode SourceFile RemoteFile > OutputFile
mmencode의 -b 옵션은 Base64인코딩을 의미하며, uuencode의 RemoteFile은 전송 시에 사용할 파일명을 지정하는 것이다. SourceFile과 같은 파일명을 주는 것이 일반적이다. 이를 메일로 보내고자 할 때는 다음과 같이 한다.
%mail user@server < OutputFile
또는 인코딩과 메일을 같이 사용하여, 다음과 같이 사용할 수도 있다.
%mmencode -b SourceFile | mail user@server
%uuencode SourceFile RemoteFile | mail user@server
UNIX상에서 이러한 인코딩 된 메일을 처리하는 경우에는 우선 받은 메시지를 s Filename과 같은 명령어로 임의의 이름으로 저장한 후 그 파일을 디코딩 한다.
%mmencode -u Filename
%uudecode Filename
2. 인터넷 메일에서의 한글 인/디코딩과 문제점.
1) RFC1557 - 한글 메일 인코딩 규격
8bit의 한글은 KSC 5601 표준으로 제정되어 있으며, 메일에서의 문자 집합 명칭으로는 EUC-KR로 표시한다. 그러나 바이너리 파일과 마찬가지로 한글은 MSB를 사용하며, 2 byte 즉 16bit로서 한 글자를 표현하기 때문에 7bit만 통과시키도록 규정된 SMTP를 통과할 경우에 최상위 비트가 잘리게 되어 수신자는 한글을 읽을 수가 없게 된다. 또한 바이너리 파일과 달리 리턴 문자와 공백 문자 등이 포함된 텍스트이기 때문에, 바이너리 인코딩 방식을 그대로 사용하기도 곤란하다.3) 이에 따라 한글 메일의 특수한 인코딩 방식으로 7bit의 ISO-2022-KR 인코딩 표준안이 RFC 1557로서 제안되었다. 일본이나 중국의 경우에도 ISO-2022-JP (RFC 1468), ISO-2022-CN (RFC 1922)이 제안되어 있다. 그러나 현재 윈도 환경에서 널리 쓰이고 있는 외국의 메일 프로그램은 이러한 특수 문자를 사용하는 국가를 전혀 고려하지 않으며 ISO-8859-*의 문자 집합만을 지원하므로 한글 메일의 문제는 현재 우리 나라의 정보화 문제 상 중요한 걸림돌 중의 하나가 되고 있다.
ISO-8859-*는 다음과 같은 국가의 문자 규격이다.
8859-1 Europe, Latin America, Caribbean, Canada, Africa
8859-2 Eastern Europe
8859-3 SE Europe/miscellaneous (Esperanto, Maltese, etc.)
8859-4 Scandinavia/Baltic (mostly covered by 8859-1 also)
8859-5 Cyrillic
8859-6 Arabic
8859-7 Greek
8859-8 Hebrew
8859-9 Latin5, same as 8859-1 except for Turkish instead of Icelandic
8859-10 Latin6, for Lappish/Nordic/Eskimo languages
따라서 많은 메일 프로그램에서 지원하는 ISO-8859-1 문자 집합은 모든 나라의 언어를 포함하는 것이 아니다. 이는 주로 MSB를 사용하는 Accented Character가 있는 나라의 문자 집합을 의미하며, 이를 MIME에서 표현하기 위하여, Quoted Printable(QP)이라는 인코딩 방식이 제안되어 사용하고 있다. QP의 원리는 특수 기호인 "="과 그 문자의 16진 코드를 사용하여 인코딩을 한다. 가령 "M nchen"이라는 문자를 QP인코딩을 하면 "M=FCnchen"이 되는 것과 같다. 그러나 한글 메일에서 QP인코딩을 사용하게 되면 최고 3배까지 전송 용량이 늘어나는 문제점이 있다. 예를 들면, "가나다"를 QP 인코딩을 할 경우에 "=B0=A1=B3=AA=B4=D9"가 된다. 따라서 QP인코딩은 한글 메일의 경우에 비효율적인 인코딩 방식이다.
RFC 1557에서 규정하는 ISO-2022-KR 한글 인코딩의 원리는 한글 인코딩의 시작을 의미하는 Designator로서 ESC$)C를 문 두에 두며, 한글이 발생하는 0x21에서 0x7E까지의 94개 문자 범위의 앞에 SO (0x0E)를 두고 한글이 종료되는 시점에 SI (0x0F)를 두도록 하고 있다. 즉, SO의 역할은 한글이 시작된다는 선언 부호이며, SI는 한글 종료를 뜻하는 부호이다. 디코딩을 할 경우에 SO를 만나면 94개 문자의 범위에 해당하는 문자에 MSB (이진수 10000000) 즉 0x80을 더하는 연산을 수행하여 한글이 깨지지 않도록 하는 것이다. 다만 헤더 제목 줄의 인코딩은 RFC 1522에 따라, Base64(B)나 QP인코딩(Q)을 하며, 제목 줄에 사용되는 문자 집합 명칭으로 EUC-KR을 사용한다. 그러나 Q인코딩을 이용할 경우 제목 줄의 길이가 허용 한도를 넘어 갈 우려가 있으므로 실제로는 B인코딩이 주로 사용되고 있다. RFC 1557을 구현한 헤더는 다음과 같다.
MIME-Version: 1.0
Subject: =?EUC-KR?B?vsa4p7TZv+4gx9Gx2w==?=
Content-Type: text/plain; charset=iso-2022-kr
Content-Transfer-Encoding: 7bit
아래는 MSB가 잘려 나간 한글과 ISO-2022-KR인코딩 형태이다.
원래의 한글 : 아름다운 한글
MSB가 잘려진 형태 : >F8'4Y?n GQ1[
ISO-2022-KR : ←$)C♬>F8'4Y?n¤ ♬GQ1[¤
(특수 기호는 워드프로세서로 구현이 곤란한 점이 있어 유사한 모양의 Character를 사용하였음을 양해하기 바란다. ←: ESC(0x1B) ♬: SO(0x0E) ¤: SI(0x0F) )
2) 인터넷 메일 프로그램에서의 한글 처리와 문제점
현재 윈도 환경의 인터넷 사용자가 많이 사용하고 있는 Eudora나 Netscape Navigator는 RFC 1557을 지원하지 않으며, 헤더에 있어서도 MIME 표준규격인 RFC 1522에도 부합되지 않는 헤더를 내보내는 문제가 있다. 따라서 한글 메일의 사용에 이들 프로그램은 적합하지 않다. 다만 RFC 1557의 저자 중 한 사람인 최우형씨가 개발한 한글 Sendmail이라는 프로그램이 메일 서버에 MTA로서 존재하여야만 이들 프로그램의 한계를 어느 정도 극복할 수 있다. 그러나 한글 Sendmail 역시 RFC 1557에 배치되는 측면이 많으며, 여러 MUA의 헤더에 대한 표준 위반을 수용하지 못하는 많은 문제점을 가지고 있다. 국내 인터넷 환경 변화와 관련하여, 또 다른 문제는 영문 Sendmail의 버전이 업그레이드되고 있는데 반하여, 한글 Sendmail은 버전이 낮아 보안성 문제가 제기되고 있으며, 윈도NT등을 서버로 쓰는 경우에는 MTA차원의 한글 메일 지원의 대책이 전무하다.4) 또한 외국에 거주하는 사람들의 경우 MTA 차원에서의 한글 메일의 지원은 서버를 소유하고 있는 경우가 아니면, 대책이 없다. 따라서 가장 바람직한 것은 사용자가 직접 사용하는 MUA프로그램 상에서 RFC 1557의 인/디코딩 규격을 지원하는 것이라 할 수 있다. 그러나 국내 대다수의 ISP(Internet Service Provider)의 메일 서버에는 한글 Sendmail이 설치되어 있으며5), 넷스케이프와 유도라의 경우에 이를 기준으로 설명하고자 한다. 그전에 정상적인 경우의 한글 Sendmail이 수행하는 헤더 변환과 인 디코딩의 메커니즘은 아래와 같다. MUA가 RFC 1557을 지원하지 않은 경우의 헤더와 본문은 다음과 같아야 한다.
MIME-Version: 1.0
Subject: 아름다운 한글
Content-Type: text/plain; charset=euc-kr
Content-Transfer-Encoding: 8bit
아름다운 한글
이를 받은 한글 Sendmail은 아래와 같이 헤더와 내용을 변환하여 수신 측에 전송한다.
MIME-Version: 1.0
Subject: =?EUC-KR?B?vsa4p7TZv+4=?= =?EUC-KR?B?x9Gx2w==?=
Content-Type: text/plain; charset=iso-2022-kr
Content-Transfer-Encoding: 7bit
←$)C
♬>F8'4Y?n GQ1[¤
만일에 수신 측의 서버에 한글 Sendmail이 설치되어 있을 경우에는 다시 원래의 헤더와 내용으로 복구되며, 수신 측 사용자의 E-mail프로그램 상에는 제목과 본문의 한글이 깨지지 않고 배달될 것이다. 여기서 필자가 재현한 한글 Sendmail의 문제점을 눈여겨보기 바란다. 먼저 제목 줄의 인코딩이 어절마다, B인코딩이 되고 있어 제목 라인이 길어지며, 본문 중 한글 발생 코드 영역인 94문자의 영역밖에 있는 한글 다음의 공백 문자(0x20)에 대하여, SI가 발생하지 않고 있다.
Qualcomm의 Eudora는 US-ASCII이외에 지원하는 문자는 오로지 ISO-8859-1뿐이다. 뿐만 아니라 헤더에 있어서도 표준 위반을 보이고 있어 문제가 되고 있다. 유도라의 QP옵션을 끄고 송신된 메일의 헤더는 다음과 같다.
Mime-Version: 1.0
Subject: 아름다운 한글
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
여기서 Mime-Version은 MIME-Version이 되어야 하며6), charset 항목에도 " "가 없어야 되고 (RFC 1522위반), 한글 Sendmail이 헤더 변환 작업을 수행하기 위해서는 charset=euc-kr 또는 EUC-KR이 되어야 헤더 변환이 일어난다. 그러나 한글 Sendmail은 헤더를 바꾸지 않은 경우에도 제목과 본문의 인코딩이 수행되어 결과적으로 헤더와 인코딩이 일치하지 않는 이상한 메일이 되고 만다. 이러한 문제점은 Qualcomm에서 수정하여 주는 것이 바람직하지만, 그렇지 못하므로 사용자는 Eudora.ini파일에 다음과 같은 한 라인을 추가하여, 한글 Sendmail이 올바로 헤더 변환을 할 수 있도록 도와주어야 한다.
[Settings]
ExtraHeaders=MIME-Version: 1.0\r\nContent-Type: text/plain; charset=euc-kr
그러나 이렇게 하여도 위의 잘못된 헤더는 없어지지 않으며, 텍스트와 바이너리 파일을 같이 보내는 경우의 헤더는 위의 텍스트만의 헤더와 달라서 이 방법도 소용이 없다. 따라서 한글과 바이너리 파일을 같이 보내지 말아야 한다. 그 외 유도라의 한글 문제로는 한글로 된 제목 라인을 수신자에게 보여 줄 때, 절반 정도 깨져서 보이지 않게 하는 문제가 있다.
넷스케이프의 경우에는 비록 RFC 1557을 지원하지 않지만 EUC-KR의 8bit 한글을 지원하므로 상황은 유도라보다는 낳은 편이다. 그러나 이 경우에도 서버에 한글 Sendmail이 설치되어야 함은 물론이다. 넷스케이프의 Mail & News Preferences의 Composition에서 Allow 8bit를 선택하고, Options 메뉴의 Document Encoding을 Korean으로 세팅하고, General Preferences의 Fonts에서 Korean을 선택하여, Proportional Font를 굴림, Fixed Font를 굴림체 등으로 선택하고 Options메뉴의 Save Option을 하도록 한다. 이렇게 하여 보내는 메일은 다음과 같은 헤더를 가지고 있다.
MIME-Version: 1.0
Subject: =?euc-kr?B?vsa4p7TZv+4gx9Gx2w==?=
Content-Type: text/plain; charset=euc-kr
Content-Transfer-Encoding: 8bit
위에서 보는 바와 같이 넷스케이프는 제목 줄을 미리 euc-kr문자의 B인코딩을 수행한다. 한글 Sendmail은 위와 같은 경우에 제목을 제외한 나머지 부분에서 헤더 변환을 제대로 수행하지만, 제목은 건드리지 않고 전달하며, 수신 측이 한글 Sendmail일 경우에 제목을 디코딩 하지 않는다. 즉, 한글 Sendmail은 RFC 1522와 RFC 1557의 규정대로 대문자 EUC-KR이 제목 줄 헤더에 오는 경우에만 디코딩을 수행하는 것이다. 그 결과 수신자가 한글MTA에 유도라 사용자 등의 경우나 온라인으로 메일을 보는 경우에 제목이 디코딩 된 채로 배달되어 보이지 않는 결과를 낳는다.
한글 Sendmail이 서버에 존재하지 않는다면, 결코 Eudora나 Netscape에서 전송하는 한글 메시지는 안전성을 보장할 수 없다. 공개용으로 많이 사용되는 또 다른 E-mail프로그램인 Pegasus는 8bit 전송을 허용하더라도 제목이 ISO-8859-1의 Q인코딩이 되기 때문에 더욱 심각하다. 따라서 넷스케이프나 유도라의 정식 사용자의 경우에는 적극적으로 이의 시정을 촉구하는 일이 무엇보다 중요하다. 가까운 일본의 경우에 사용자의 이러한 요구는 일본어판 유도라가 나오게끔 한 사실을 상기할 필요가 있다.7) 뿐만 아니라 넷스케이프를 번들로 판매하는 컴퓨터 판매 업자나, 소프트웨어 제조 업체, 온라인 서비스 업체에서는 메뉴만 한글화 할 것이 아니라, 내용에 있어서도 한글이 지원되도록 플러그인 등을 개발하거나 넷스케이프사에 당당히 시정을 요구하여야 한다.
RFC 1557을 지원하는 윈도 기반의 최초의 한글 MUA프로그램은 Exchange의 한글 인터넷 메일 애드온이다. 익스체인지에서 ISO-2022-KR 인코딩을 사용하기 위해서는 제어판의 "편지와 팩스" 애플릿의 인터넷 등록 정보에서 "메시지 형식" 중 "문자 집합"을 선택하고 "한글"로 설정하도록 한다. 다음은 익스플로러에서 보내는 메시지 헤더와 인코딩 형식이다.
Subject: =?EUC-KR?B?vsa4p7TZv+4gx9Gx2w==?=
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-KR"
Content-Transfer-Encoding: 7bit
←$)C¤ABCD♬>F8'4Y?n¤ ♬GQ1[¤¤
문장의 내용은 "ABCD아름다운 한글"이라는 글이다. 즉, 규정대로 라면, 헤더의 charset에서 " "가 없어야 하며, designator 다음의 상태를 ASCII상태로 두어야 함에도 불구하고, 한글 상태로 인식하는 문제가 있어서 필요 없는 SI 코드가 문 두의 영문 앞에 존재한다. 또한 라인의 끝에 SI코드를 하나 더 첨가하는 문제가 있어서 RFC 1557을 위반하고 있다. 디코딩 시에는 보다 심각해서 한글 Sendmail을 경유하여, 전달된 메시지는 designator다음에 리턴 문자가 오는데, (물론 RFC 1557에 따르면, 리턴이 오던 안 오던 상관은 없다) 문장의 상태를 한글로 하고 있어서 첫 번째, 리턴 캐릭터에 0x80을 더하여 깨뜨릴 뿐 아니라, 공백 문자 즉 스페이스에 한글 Sendmail의 위반 사항인 SI가 오지 않는 경우에도, 0x80을 더하여 주변의 영문도 같이 깨뜨리는 오류를 범하고 있다. 물론 SI가 나오지 않았어도 SO와 SI 사이에 공백문자(0x20)와 같이 한글이 발생하는 94개의 문자 범위 밖의 경우에 한해서는 이미 보편화한 한글 Sendmail과의 호환성을 고려하여 디코딩 시 0x80을 더하지 말아야 한다. 그 결과 익스체인지로 메일을 사용할 경우에는 오직 익스체인지 사용자 상호간의 메일만이 안전하게 배달되는 문제가 발생하게 되었다. 물론 이 경우에도 보장을 할 수 없는 경우가 있는데, 익스체인지 사용자가 한글 Sendmail을 서버로 사용하고 있는 경우이다. 한글 Sendmail의 또 다른 문제는 익스체인지나 기타 RFC 1557을 지원하는 메일에서 인코딩 되어 온 메시지를 외부에 넘겨주기 전에 디코딩을 하며, 외부에 넘길 경우에 다시 인코딩을 수행하는 문제이다. 이렇게 되면 수신 측 MTA가 영문인 경우의 익스체인지 사용자는 같은 익스체인지로 보낸 메일의 경우에도 한글 Sendmail과 익스체인지의 비호환성으로 인한 문제로 깨어진 메일을 전송 받게 된다. 익스체인지의 이러한 여러 가지 문제는 최근의 뉴스 그룹을 통하여 필자를 비롯하여 여러 사람이 지적한 결과 Microsoft측 관계자로부터 수정을 하겠다는 답신을 들었으며, 현재 수정이 진행되고 있다고 한다.
그러나 전혀 희망이 없는 것은 아니다. 최근에 나온 MS Internet Mail은 비교적 양호하게 RFC 1557을 지원하며, 익스체인지와 달리, 한글 다음의 공백 앞에 SI가 나오지 않아도 메시지를 깨뜨리지 않는다. 다만 인코딩 시에 다음과 같이 헤더 중 Content-Transfer-Encoding을 8bit로 하는 문제가 있으나 실제 한글 메시지의 교환에 크게 영향을 주는 부분은 아니다.
MIME-Version: 1.0
Subject: =?EUC-KR?B?vsa4p7TZv+4gx9Gx2w==?=
Content-Type: text/plain; charset=iso-2022-kr
Content-Transfer-Encoding: 8bit
←$)C♬>F8'4Y?n¤ ♬GQ1[
그러나 MS Internet Mail은 다국어를 지원하도록 설계된 프로그램으로 또 다른 문제점을 노정 하였다. 즉, Content-Type헤더에 charset으로 지정된 문자 설정에 지나치게 민감하여, 내용은 ISO-2022-KR로 인코딩 된 한글이거나 8bit의 KSC 5601로 이루어진 한글이라도, 헤더가 잘못되어 있는 메일의 경우8)에 ISO-2022-KR 코드의 디코딩이 이루어지지 않으며 KS 5601의 한글일 경우에도 iso-8859-1이라는 영어권 문자로 인식하여, 영문 폰트로 보여 주는 문제가 있다. 익스체인지에서도 마찬가지로 이런 경우에 디코딩이 되지 않는다. 물론 MS Internet Mail의 경우에는 언어를 한국어로 바꾸는 명령 행위를 수행하면, ISO-2022-KR의 경우 디코딩이 이루어지며 KSC 5601 8bit일 경우에도 폰트를 바꾸어서 일시적으로 한글이 보일 수 있다. 또한 수신된 메일을 "미리 보기 창"에서 직접 회신을 할 경우에 상대방의 헤더 설정과 이에 따른 언어 설정을 그대로 따라 하는 문제가 있다. 이러한 문제는 MS Internet News의 경우에도 심각하다. 뉴스 그룹은 전통적으로 MIME인코딩의 사용이 배제되어 왔다. 한 예로 Base64 인코딩의 경우 서버에서 받아들이지 않는 것이 관례로 되어 있다. 물론, Internet News의 정식 판의 경우에 MIME 사용을 체크하고, 언어를 한국어로 설정하면 다행스럽게 ISO-2022-KR이 아니라 EUC-KR로 기사가 게시된다. 그러나 News Group에 게시하는 경우에 MIME규격에 따라 EUC-KR로 게시하는 경우는 문제가 없지만 앞서 언급한 대로 이러한 기사에 대하여 편지로 회신을 하는 경우에 MS Internet Mail을 사용한다고 하여도 상대방의 헤더와 언어 설정을 그대로 따라 하는 특성으로 인하여, 인코딩이 되지 않은, 따라서 SMTP에 의하여 MSB가 잘리어 나가는 위험이 있는 한글 메일이 전송될 수 있다. 미리 보기 창에서 회신이나 전달 버튼을 사용하여도, 언어를 바꿀 수 없다. 따라서 MS Internet Mail과 News를 사용하는 사용자의 경우에 다음과 같은 사용자 대책을 사용하면 큰 무리 없이 사용이 가능하다.
먼저 MS Internet Mail 은 MIME에 인코딩은 없음, 머릿글 8bit사용 가능에 체크를 해지하며, 언어는 한국어로 설정하고, MS Internet News의 경우 uuencode로 맞춘다. News에서 uuencode로 설정하는 이유는 전통적으로 뉴스 그룹에서 MIME 헤더가 없는 텍스트 메일과 바이너리 인코딩으로 uuencode방식이 쓰인 이유 외에도 혹시 라도 있을지 모를 MS Internet News의 사용자가 이에 E-Mail을 통한 회신을 할 경우 상대방의 헤더를 따라 하는 특성에 따라, MSB가 잘리어진 메일의 전송을 예방하기 위한 것이다. 이렇게 설정을 하여도 답신하는 E-Mail을 사용하는 경우에는 Internet Mail의 설정에 따라 MIME형태의 메일 즉 ISO-2022-KR로 인코딩 된 메일을 보낼 수가 있으므로 서식을 다시 확인할 필요는 없다. 또한 잘못된 헤더, 따라서 결과적으로 안 보이는 메일이나 기사에 대해서 Internet News에서 답신을 할 때, "미리 보기 창"에서 하지 말고 "별도의 창"에서 언어를 한국어로 바꾸어 답신을 하면 제대로 된 메일을 보낼 수 있다. 그러나 Internet Mail에서는 이런 경우, "별도의 창"에서 회신을 수행하여도 언어를 바꿀 수 없다. 이 경우에는 회신(Reply)을 하지 않고 전달(Forwarding)을 하면 언어를 바꿀 수 있다. 단, 제목에 Fw:만 Re:로 바꾸면 문제를 어느 정도 극복할 수가 있다. 또한 News그룹 포스팅과 동시에 메일은 같이 보내지 않도록 한다. 그리고 현재 발견된 버그가 한가지 더 있는데, Mail에서 영문만의 편지를 쓸 때, 기본 언어를 한국어로 사용할 경우에는 charset이 us-ascii로 바뀌지 않으며, 그 결과 ESC$)C의 Designator가 앞에 붙는 문제가 있다. 이 경우 메일링 리스트에 Subscribe를 수행하는 명령어나 메일을 이용한 자동 응답 데이터베이스에 대한 Batch명령이 먹히지 않는다. 따라서 영문만의 편지를 쓸 경우에는 반드시 언어를 영어로 바꾸어 전송하도록 한다. charset이 us-ascii로 변환이 되지 않는 경우는 Netscape에도 마찬가지였지만, 넷스케이프는 RFC 1557을 지원하지 않으므로 문제가 되지는 않았다.
한가지 추가로 언급하여야 할 MUA프로그램으로 최근에 한글과 컴퓨터 사의 /한/글 프로 96에 번들 제공된 /한/메일 96이 있다. 이 프로그램은 우리 나라에서 최초로 만든 RFC 1557을 지원하는 MUA프로그램이다. 물론 시판된 프로그램은 RFC 1557의 위반을 비롯하여 많은 버그가 있음이 밝혀져서 현재 필자가 한컴에 협조하여 이 프로그램의 베타 테스트를 수행 중에 있다. 아마 독자가 이 글을 읽을 시점에는 RFC 1557을 제대로 지원하는 /한/메일 프로그램의 버그 수정 판이 나올 것이다. 현재의 수정 상태를 볼 때 자신 있게 추천할 수 있는 유일한 프로그램이 될 지도 모른다.
이 글은 비록 윈도에서의 메일 응용 프로그램에 초점을 맞추었으나 다른 시스템에서도 한글 메일을 송 수신할 수 있는 프로그램이 많이 나와 있다. 매킨토시의 경우에 김정현씨가 만든 한글 메일 1.0x의 프로그램을 이용하면, 서버에 한글 Sendmail이 설치되어 있지 않은 매킨토시에서의 Eudora나 Netscape사용자의 경우에도 RFC 1557을 따르는 한글 메일을 주고받을 수가 있다. 한글 메일과 Eudora, Netscape의 한글 패치 파일은 http://scorpion.kaist.ac.kr/에서 구할 수가 있다. 기타 이 글에서 설명이 부족한 유닉스 시스템에서의 한글 메일의 송수신 문제 등에 관하여는 필자에게도 많은 도움을 주신 신정식씨의 FAQ http://pantheon.cis.yale.edu/~jshin/faq/hmail.html 과 http://pantheon.cis.yale.edu/~jshin/faq/hancode.html을 참조하기 바란다.
마지막으로 여러 가지 인코딩 된 한글 메시지를 복원하는 프로그램이 있다. 이준희씨가 만든 윈도용 한글 메일 디코더인 Cvt8이다. 이 프로그램을 사용할 경우에는 iso-2022-kr, QP, Base64, iso-2022-xx, uuencode된 한글 메시지 뿐 아니라 MSB가 날아간 7bit의 경우에도 100%는 아니지만 어느 정도 복구할 수는 있으므로, 위에서 언급한 E-Mail프로그램과 아울러 반드시 필요한 프로그램이라고 할 수 있다. 이 프로그램을 비롯하여, 각종 hcode, hdcod, hmconv와 같은 Unix용 한글 메일 변환 프로그램과 한글 Sendmail 8.6.12h2 등은 ftp://cair-archive.kaist.ac.kr/pub/hangul에서 구할 수가 있다.
컴퓨터의 발전 방향이 개방형 시스템으로 나아갈수록 정보의 공유에 대한 요구가 높아지고 있으며, 이러한 정보 교환의 근간은 전자 우편에서부터 이루어지고 있다. 그러나 표준을 지키지 않은 많은 프로그램들이 난립할수록 정보 교환의 목적은 퇴색될 수밖에 없다. 이 글이 당면한 우리 나라 사회의 정보화를 앞당기는 데 조그만 도움이 되기를 기대할 뿐이다.
미주)
1) 8bit 전송을 허용한 ESMTP는 RFC 1651에 의하여 규정하고 있다. 그러나 현재 인터넷 메일의 표준(STD 10, RFC821)은 7bit SMTP이다. ESMTP에서도 메일의 헤더는 7bit이다. 참고로 RFC는 Request For Comment의 약어로 ISO와는 직접적인 관련이 없다. IETF(Internet Engineering Task Force)라는 인터넷 표준을 정하는 자발적인 모임의 구성원들이 인터넷 표준을 정하기 위해 여러 분야의 표준안을 제출하는 하나의 형식이다. 모든 RFC는 ftp://ftp.krnic.net/rfc 에서 구할 수 있다. [본문 위치로]
2) RFC 1521, RFC 1522에서 규정하고 있으며, RFC 1521은 MIME의 형태, 인코딩을 다루고, RFC 1522는 MIME 헤더의 규정을 다루고 있다. [본문 위치로]
3) 천리안 등 PC통신의 일부 메일은 수신자가 영문 MTA를 사용하는 경우를 고려하여 부차적으로 한글에 uuencode등의 바이너리 파일 인코딩 방법을 사용하기도 한다. 경우에 따라서는 Base64로 인코딩 하는 경우도 있다. [본문 위치로]
4) 현재 개발 중인 Microsoft의 한글 Exchange서버가 RFC 1557을 지원하지만 아직 시장에 나오지 않은 베타 판이며, MS의 메일링 리스트 등을 통하여 받은 메일을 분석해 볼 때 많은 표준 위반을 보이고 있다. [본문 위치로]
5) 한국 통신에서 운영하는 KORNET의 메일 서버에는 한글 Sendmail과는 다른 형태의 한글 지원 Sendmail이 설치되어 있는 것으로 보인다. 이 경우에는 경우에 따라서 RFC 1557을 지원하지 않은 형태, 즉 메일의 경로에 따라서 MSB를 보장하지 못하는 한글 메시지가 전달될 수 있음이 지적되고 있다. [본문 위치로]
6) 일부 영문MTA인 UNIX용 Sendmail은 MIME-Version을 RFC 1522의 규정과 달리 Mime-Version으로 고치는데, 이것도 잘못이다. [본문 위치로]
7) Eudora를 개발한 Qualcomm의 최대 고객은 이들이 개발한 디지털 통신 기술인 CDMA를 세계 최초로 상용화한 대한민국이다. [본문 위치로]
8) 즉 대부분의 경우 넷스케이프 사용자가 Document Encoding을 Korean으로 설정하지 않고, Western (Latin 1)으로 설정한 경우와, 유도라의 근본적인 헤더 잘못 (물론 ini파일에 ExtraHeaders라인을 첨가하지 않았을 경우)으로 배달된 메일의 경우 [본문 위치로]