email 전달 경로와 인코딩 규칙.

이메일 작성 → SMTP 서버로 전달 → SMTP 서버에서 패킷으로 변환 → 여러 경로를 통해 받은 메일 서버로 전달 → 받은 메일 서버에서 패킷을 재정렬 → 받을 사람에게 완성된 메일을 전달

'플라이'라는 영화에서 파리 한 마리가 끼어들어 물질 전송이 엉망이 되었다는 얘기를 했습니다. 이메일도 이런 일이 벌어질 수 있습니다. 이메일의 안정적 전송을 위해 MIME라든가 각종 인코딩을 사용하게 됩니다. 그런데 그런 방식이 인터넷 표준이 아니라면 이메일은 전달되면서 돌연변이가 됩니다. 메일 서버 프로그램이 오래된 것이라서 이런 표준을 잘 지키지 못하거나 매우 융통성이 없다면 - 특히 한글과 같은 8비트 문자에 대하여 융통성이 없는 경우라면 메일은 중간에 정보를 잃고 원래 자신의 모습을 기억하지 못하게 될 수 있습니다. 받은 메일의 내용이 깨지거나 포함된 이미지의 영상이 찌그러져 나오거나 혹은 데이터를 읽을 수 없는 경우가 있습니다.

이런 돌연변이를 막는 것은 올바른 메일 프로그램을 사용하고 제대로 사용법을 익히는 것입니다. 더 중요한 것은 수만명 또는 수십만명의 이메일을 관리하는 메일 서버 프로그램을 제대로 관리하는 것입니다. 그러나 메일 서버 관리는 우리의 영역이 아닙니다. 만약 여러분이 정말 운이 없는 사용자라면 잘못되거나 오래된 메일 서버의 문제점을 지적하기 위해 몇일을 연구해야할지도 모릅니다. 부디 그런 일이 일어나지 않길.



----------------------------------------------------------
SMTP는 메일을 보내는 규약이라고 했습니다. 실제로 메일을 보내고 받는 작업을 하는 소프트웨어는 센드메일(sendmail)이라는 프로그램이 담당합니다. 센드메일 대신 다른 프로그램을 사용하는 경우도 있지만 대부분의 서버는 이 프로그램을 사용합니다. 센드메일이 메일을 보낼때는 SMTP라는 규약에 근거해서 메일을 보내게 됩니다. 여러분이 계정이나 하이텔, 천리안의 메뉴에서 이메일을 보내게 되면 곧장 센드메일이 작업을 하여 이메일을 보내게 됩니다.

하지만 다른 이메일 프로그램을 사용하여 메일을 보내는 것은 조금 다릅니다. 아웃룩 익스프레스와 같은 이메일 프로그램을 사용하여 이메일을 보내려면 모뎀을 통해 메일을 보낼 수 있는 서버로 접속해야 합니다. 접속한 후 메일 프로그램은 "메일을 보내주세요"라고 메일 서버에게 요청합니다. 어떤 메일 서버는 그런 요청을 한 사람이 자신과 같은 서비스 가입자인지 판단한 후 작업을 실행합니다. 다른 메일 서버는 어떤 곳에서 메일을 보내달라고 요청하든 그 작업을 처리해 줍니다. 그렇게 외부에서 메일을 보내줄 것을 요구할 수 있는 서버를 SMTP 서버라고 부릅니다.


------------------------------------------------------
POP 서버를 통해 메일 요청하기

POP란 "Post Office Protocol의 줄임말로 사용자가 서버로부터 이메일을 읽을 수 있도록 고안된 우체국 통신규약을 말합니다. 계정 접속으로 이메일을 읽는 것은 서버에 저장되어 있는 메시지를 직접 억세스하여 읽는 것임에 반해 POP 서버를 통해 이메일을 읽는 것은 서버에서 이메일 복사본을 다운로드하는 것입니다.

메일 프로그램에서 POP 서버의 주소를 기입한 후 자신의 아이디와 비밀번호를 입력하면 프로그램은 POP서버에게 "나 왔어~"라고 인사한 후 "새로 도착한 메일중 내꺼만 몽땅 내놔!"라고 요구합니다. 서버에 받은 메일을 저장할 것인지 받은 다음에 지울 것인지는 메일 프로그램에서 지정할 수 있습니다.

POP 서버를 통해 이메일을 받는 것은 매우 편리하기도 하고 한편으론 불편하기도 합니다. 매번 텔넷을 이용하여 메일 서버에 접속한 후 새로운 메일을 검사하느니 필요할 때 POP서버에 접속하여 새로 도착한 메일만 받으면 되니 사용자 입장에서는 편리합니다.

그에 비해 불편한 점은 POP 서버에 접속하여 메일을 받으려면 그것이 뭐든간에 우선 받아야한다는 것입니다. 그게 여러분에게 욕설을 퍼붓는 메일이든 1천원을 투자하여 1억을 벌 수 있다는 허황된 광고메일이든 10메가짜리 동영상이든 무조건 받아야 한다는 것입니다. 또한 계정에 로긴한 상태에서는 메일이 도착하면 즉시 그것을 알 수 있지만 POP 서버를 통해 메일을 받을 경우엔 사용자가 "접속하라"고 메일 프로그램에 명령할 때 비로소 새로운 메일의 도착을 알 수 있다는 점입니다. 분초를 다툴 정도의 급한 것이라면 이메일보다는 직접 전화를 하거나 삐삐를 치는게 더 낫겠지만요.

--------------------------------------------------------


IMAP는 "Internet Message Access Protocol의 약자로서 로컬 서버로부터 e-mail을 읽기 표준 프로토콜을 말합니다. 최신 버전은 IMAP4이며 POP와는 달리 메일의 제목이나 보낸 사람만 보고 메일을 다운로드할 것인지 선택할 수 있습니다.

IMAP서버를 사용하면 폴더나 메일함을 서버에 만들수 있으며 메일함의 메시지에 직접 접근하여 지우거나 검색을 할 수도 있죠. IMAP는 리모트 파일 서버(메일 서버에 접속하여 메시지를 관리하는)로 비유할 수 있고, POP는 "저장하고 전달하는" (다운로드만 하는) 메일 서비스로 비유할 수 있습니다.

IMAP는 이런 경우에 매우 효과적입니다. 만약 학교나 직장에서는 인터넷에 항상 접속된 컴퓨터를 사용하며 메일을 체크하고 집에서는 전화로 전자우편을 체크한다면, POP3는 불편할때가 많습니다. 받았던 메일을 또 받아야되고, 또한 답신을 한 것인지 그렇지 않은 것인지 체크하기도 어렵기 때문입니다. 혹은 POP3 서버에서 메일을 받은 후 서버에서 삭제해 버렸다면 메일 박스나 개별 메일을 FTP등으로 전송해야 하는 불편함이 있습니다.

IMAP는 이런 POP의 단점을 보완하기 위해 제안되었습니다. POP 대신 IMAP를 받는 메일 서버로 사용할 경우 계층적 폴더 관리와 원격 폴더 조작이나 메일 폴더 공유가 가능합니다. IMAP가 POP를 대체하는 인터넷의 새로운 전자우편 이용을 위한 프로토콜로 부상하고 있기는 하지만, 아직은 이를 지원하는 메일 서비스가 그리 많은 편은 아닙니다. 그럼에도 불구하고 최근에 나오는 대부분의 메일 클라이언트들은 IMAP 서비스를 지원하고 있습니다.

IMAP를 제대로 사용하려면 최신의 IMAP4를 서버에서 지원해야 하고, 메일 클라이언트가 또한 이것을 잘 지원해야 합니다. Outlook Express의 경우 현재 나와 있는 4.x의 경우 IMAP4를 지원하고 있기는 하지만 플래그(flag)나 메시지 삭제등을 제대로 지원하지 못하고 있습니다. 그러나 Outlook Express 5.0은 IMAP4 규약을 좀 더 확실히 지원합니다. Netscape 4.5PR2에 포함된 메일러인 Messenger의 경우 최신의 IMAP4를 잘 지원하는 편이며, IMAP4 서버를 사용할 경우 다중 계정을 지원합니다. 한편, 유닉스 호환 서버에서 대중적으로 사용하는 메일러인 Pine은 이전 버전부터 IMAP4를 잘 지원해 왔습니다. 최신 버전인 Pine 4.03의 경우 IMAP4와 POP3 모두 리모트에서 접속할 수 있는 기능을 제공하고 있습니다.


--------------------------------------------------------
헤더란 무엇인가?
　


헤더는 일종의 규칙입니다. 인터넷을 경유하여 전달되는 메시지가 제 각각의 헤더를 갖고 있다면 제대로 이것을 처리하는 것은 불가능할 것입니다. 따라서 메시지의 헤더를 기록하는 전세계 공통의 규약이 필요합니다.

이메일의 헤더에 대해 정의하고 있는 문서는 RFC 822라는 인터넷 문서입니다. RFC 822 에는 인터넷 메일이 무엇이며 그것의 헤더는 어떤 식으로 구성되어야 하는지 상세히 기술하고 있습니다. 이것을 기초로 한 다양한 RFC 문서가 이메일의 헤더에 대해 정의하고 있습니다. 여러분이 이 문서를 읽어볼 필요는 없습니다. 사실 RFC와 같은 문서는 기술적 정의와 규약을 다루고 있는 매우 전문적인 문서입니다. 그리고 그것을 철저히 지켜야할 것은 이메일을 보내고 받는 사용자가 아니라 이메일 프로그램을 개발하는 프로그래머와 메일 서버를 운영하는 운영자입니다.

만약 어떤 프로그래머가 이메일 헤더에 대해 매우 무지하여 자신이 만든 메일 프로그램의 헤더 표기법을 멋대로 만들었다면 어떻게 될까요? 모든 이메일은 받는 사람 주소를 표시하는 "TO:"라는 헤더를 사용하고 있습니다. 그런데 이 프로그래머는 받는 사람의 주소를 표시하는 헤더로 "TOGETHER:"라는 것을 사용하도록 프로그래밍했던 겁니다. 여러분은 이 프로그램을 사용하여 이메일을 보낼 수 있을까요? 절대 보낼 수 없을 것입니다.

여러분이 "TOGETHER:social91@cholian.net"라는 헤더를 포함하여 이메일을 보냈다면 센드메일은 이것을 받아서 보내기 전에 "어디로 보낼까?"하고 고민하게 될 것입니다. 그런데 아무리 찾아봐도 "TO:" 헤더가 보이지 않으니 이건 잘못된 이메일이라고 판단하여 반송시켜 버립니다. 프로그래머는 왜 자신이 만든 메일 프로그램이 제대로 작동하지 않느냐고 화를 내며 센드메일을 수정해 버릴수도 있습니다. 센드메일을 수정해서 헤더에 "TOGETHER:"에 있는 정보를 기준으로 이메일을 보내도록 해 버린 것입니다.

그렇게 한다면 이메일이 보내지기는 할 것입니다. 그러나, 이메일은 다시 반송되어 버립니다. 이메일을 받은 곳에서 "TOGETHER:"이라는 헤더는 본적도 없고 그것이 무엇을 의미하는지 알수 없기 때문입니다.

이 멍청한 프로그래머는 2가지 선택을 할 수 있습니다. 첫 번째는 전세계의 센드메일을 수정하도록 요구하는 것이고, 다른 하나는 자신이 만든 프로그램을 수정하는 것입니다. "TO:" 헤더 대신에 "TOGETHER:"라는 헤더를 사용하고 싶다고 해서 자기 마음대로 할 수 있는 것이 아닙니다. RFC라는 문서가 하는 역할이 바로 그런 것입니다. 전세계의 모든 이메일에서 "TO:" 헤더가 하는 역할은 "받는 사람의 주소"를 의미하는 것이라고 규약을 정하고 모두 그것을 지켜야하는 것입니다. 만약 그것을 다른 어떤 헤더로 바꾸려면 자신이 RFC 문서를 만들어서 제안을 해야 합니다. 물론 "TO:" 헤더를 "TOGETHER:"헤더로 바꾸자는 요청이 받아들여질 확률은 0% 겠지만요.

헤더는 매우 엄격히 지켜지며 그것을 마음대로 바꿀 수 없습니다. 엄격하기 때문에 인터넷이라는 복잡한 세계에서 이메일들이 자신이 가야할 곳을 정확히 찾아갈 수 있는 것입니다. "TO:" 헤더 대신에 "TOGETHER:"라든가 "HELLO:"헤더를 쓸 수도 있다는 애매한 규약이 아니라 *반드시* 그것을 써야한다는 철저한 규약입니다.


---------------------------------------------------------
MIME이란 "Multi-purpose Internet Mail Extentions"의 약자인데 문장 자체가 의미하듯 다양한 목적을 위한 인터넷 메일의 확장 규격입니다. MIME는 7비트/ascii 문자만을 위한 인터넷 메일 표준 규약의 문제점을 해결하기 제안되었습니다. 8비트 문자와 다양한 바이너리 파일을 이메일을 통해 올바르게 처리하려면 이 규약을 잘 지켜야 합니다. MIME은 메시지를 안전하게 전송하기 위해 메시지와 관련된 여러 가지 사항을 정의하고 있습니다. MIME에서 규정하고 있는 전송 데이터 타입은 아래와 같습니다.

text
특정 문자셋(Charset)으로 구성된 텍스트 정보나, 포스트스크립트 같은 formatted text 정보 전송에 사용

multipart
서로 다른 타입의 데이터를 갖는 여러 "body" 를 하나의 메시지로 조합하여 전송

application
application 데이터나 binary 데이터 전송

message
다른 전자 우편의 내용을 인캡슐레이션하여 전송

image
still image 데이터의 전송

audio
audio 데이터의 전송

video
video 데이터의 전송 (audio 를 부분으로 가질 수 있다)


MIME의 헤더 구성요소
　


MIME은 전송 데이터에 관한 정보를 표시하기 위해 여러 가지 헤더를 가집니다. 이 헤더는 데이터에 대한 정보임과 동시에 데이터의 안전성을 보장하기 위한 보증수표와 같은 것입니다. 헤더의 정확한 정보를 통해 데이터의 손실없이 전세계 어디로 움직이는 데이터라도 원형을 유지할 수 있습니다.

MIME-Version:
전송 데이터가 따르고 있는 MIME 의 버전을 나타냅니다.

Content-Type:
전송 데이터의 형식과 세부형식을 표시합니다. 위에서 열거한 일곱 가지가 형식이 가능하며, 각 형식은 나름의 세부형식을 가지게 됩니다. 즉, text 는 세부형식으로 plain과 richtext 등을 가집니다.

Content-Transfer-Encoding:
전송 데이터의 본문을 인코딩한 방법을 표시합니다.

MIME에서 사용하는 인코딩
　


MIME 표준에서 권장하는 인코딩 방법은 다음과 같습니다. 이곳에 uuencode가 없음을 주목하십시오. uuencode는 유닉스 환경에서 오래전부터 사용되는 고전적 인코딩 방법이며 현재도 많이 사용되고 있습니다. 그러나, 앞으로 uuencode를 사용하여 데이터를 송수신하지 말아야 합니다. 더 이상 uuencode로 인코딩된 데이터에 대해 누구도 안전한 전달을 보장하지 못합니다. 인터넷을 통해 안전한 데이터의 송수신을 보장받으려면 MIME 규약을 지켜야 합니다. 현재 MIME을 지원하는 응용 프로그램에서 주로 사용 되는 것은 7 bit, 8 bit, base64, QP 이고 나머지 두 방식은 거의 사용되지 않습니다. 아웃룩 익스프레스또한 4가지 인코딩 방식만 지원합니다.

7 bit
디폴트 인코딩 방법으로, 전송 데이터의 본문은 미리 7bit로 되어 있어야 하며, 전송 데이터에 대해 실제 인코딩은 하지 않고, 단지 데이터가 7 bit mail-ready representation으로 되어 있다는 것만 나타냅니다.

8 bit
전송 데이터가 8bit, 즉, ASCII 문자뿐만 아니라, non-ASCII 문자를 포함하고 있음을 나타내고, 역시 실제 데이터에 대한 인코딩은 하지 않습니다.

binary
SMTP에서는 한 라인에 1,000 문자를 넘지 못하도록 규정하고 있는데, 7bit와 8bit는 이를 따르지만, binary 는 길이에 제약이 없고, 역시 실제 데이터에 대한 인코딩은 하지 않습니다.

Base64
24bit(3byte)를 입력 받아서, 이를 6bit 씩 잘라 4byte를 출력하는 인코딩 방법입니다. ISO646 모든 버젼과 EBCIDIC 모든 버젼의 문자셋과 알파벳을 똑같이 표현할 수 있습니다. Base64 인코딩은 Base64에서 정하는 딜리미터 (SPACE, TAB, CRLF 등)에 의해 구분되는 단위에 따라 하게 됩니다. 이를 encoded-word라고 하는데 encoded-word는 "=?charset?encoding?encoded-text?=" 로 표현되며, 문자셋은 인코딩의 대상이 되는 데이터의 문자셋을 나타냅니다.

QP(Quoted-Printable)
MSB가 1 인 문자를 "0123456789ABCDEF" 를 사용해서 "=" 다음에 부호값에 해당하는 십육진수가 오는 형태로 인코딩하고, 부호값이 33에서 60, 62 에서 126까지인 문자는 ASCII 문자로 나타내고, 9에서 32까지의 부호값을 가지는 문자는 MSB가 1 인 문자와 같은 방식으로 인코딩합니다. 이 방식으로 인코드된 데이터는 한 라인에 76 글자를 넘을 수 없습니다.

x-token
이 방식은 사용자가 정의한 코드를 사용할 수 있도록 고려한 것으로, "x-" 뒤에 사용자가 정의한 코드의 이름을 넣어 사용할 수 있습니다.