왜 헤더가 중요한가?
인터넷 메시지 가운데 가장 유명한 것은 이메일과 유즈넷의 기사입니다. 이메일과 유즈넷 기사는 크게 차이가 없습니다. 이메일이 상대방에게 직접 전해지는 메시지라면 유즈넷의 기사는 뉴스서버로 보내지는 메시지입니다. 그래서 이 둘을 함께 이해해도 무리는 없습니다. 다만 이메일과 달리 유즈넷 기사는 조금 특별한 헤더를 몇가지 갖고 있습니다. 이메일에는 그 메시지가 얼마뒤에 파기될 것이라는 expires: 같은 헤더가 필요없습니다. 그러나 유즈넷 기사에는 이런 헤더가 필요할때가 있습니다. 여러분이 기억해야할 것은 이메일과 유즈넷 메시지의 구조가 거의 비슷하다는 것입니다.
여러분이 보낸 이메일은 패킷으로 변해 인터넷에 연결된 어떤 컴퓨터로 전달됩니다. 이 메시지들은 패킷이라는 작은 정보조각으로 나누어져 TCP/IP 프로토콜에 따라 인터넷에 뿌려지게 됩니다. 뿌려진 패킷에는 그것이 각각 인터넷의 어떤 컴퓨터로 가야하는지에 대한 정보가 있습니다. 패킷들은 똑같은 경로를 따라 이동하는 것이 아니라 그 시간대에 가장 빠른 경로를 따라 제멋대로 인터넷을 헤엄쳐 갑니다. 패킷들은 결국엔 도착해야할 컴퓨터에 정확히 도달합니다. 패킷을 받은 컴퓨터는 패킷에 적혀 있는 정보를 보고 원래의 메시지 형태로 재결합합니다. 만약 패킷중 몇 개가 없어져 버렸거나 잘못되었다면 다시 전송해 줄 것을 요구합니다. 그래서 마침내 모든 패킷이 정확히 도착했을 때 그것은 제대로 된 하나의 이메일로 변환됩니다.
이것이 인터넷 메시지가 패킷으로 변환되어 상대방 컴퓨터로 전달되는 과정입니다. 그런데 도대체 패킷에는 어떤 정보가 들어있길래 인터넷에 접속해 있는 수십만개의 컴퓨터 중 여러분이 전달하고자 하는 바로 그 컴퓨터를 정확히 찾아가는 것일까요? 그 비밀은 메시지의 헤더(header)에 있습니다.
메시지의 헤더는 편지봉투에 적힌 주소와 같습니다. 수신인 주소를 정확히 적었다면 편지는 정확히 수인인의 우편함에 도착하게 될 것입니다. 만약 수신인의 주소가 틀렸다면 일주일쯤 후에 다시 편지가 돌아올 것입니다. 인터넷 메시지도 이런 원리에 따라 헤더에 있는 정보를 보고 수신인이 누구인지 파악하여 전달됩니다.
인터넷 메시지의 구조
이메일과 유즈넷 기사는 동일한 구조를 갖고 있습니다. 구체적인 부분에서 이메일과 유즈넷 기사는 다소 차이가 있지만 기본 구조는 동일합니다.
헤 더 : 이메일에 대한 정보
본 문 : 이메일의 내용
맺음말 : 사용자 정의 맺음말
|
Return-Path: <leejuy@hyowon.pusan.ac.kr> |
헤더 |
|
에이리언4 |
본문 |
| -=##=-=##=-=##=--=##=--=##=--=##=--=##=--=##=- PNU - Department of Socoiology leejuy@hyowon.pusan.ac.kr 이준영 -=##=-=##=-=##=--=##=--=##=--=##=--=##=--=##=- |
맺음말 |
헤더는 언뜻 보기에도 뭔가 신비함을 간직하고 있는 듯 합니다. 여러분은 지금 당장 이것들에 대해 완벽히 이해할 필요는 없습니다. 대부분의 사람들은 헤더의 존재를 알지 못하고 이메일을 주고 받으며 뉴스그룹에 포스팅합니다.
실제로 여러분이 메일/뉴스 프로그램을 통해 보게 되는 것은 잘 다음어진 본문과 맺음말입니다. 대부분의 메일/뉴스 프로그램은 헤더를 나름의 방식으로 정형화해서 보여줍니다. 아웃룩 익스프레스의 경우 헤더의 "From:", "To:", "Subject:"를 구조화하여 메시지 창에 예쁘게 표시해 줍니다.
여러분이 어떤 메일/뉴스 프로그램을 사용하느냐에 따라 헤더를 보여주는 방식은 조금씩 다릅니다. 그러나, 어떤 프로그램이든지 헤더의 원본을 볼 수 있는 옵션을 제공하고 있습니다. 메신저와 같이 메시지 창에 직접 헤더를 보여주는 프로그램은 옵션을 사용하여 헤더를 자세히 볼 것인지 간단히 볼 것인지 선택할 수 있습니다. 이에 비해 아웃룩 익스프레스의 경우엔 메시지를 선택하여 [등록정보] 메뉴를 선택하면 메시지의 원본 헤더를 볼 수 있습니다.
헤더란 무엇인가?
헤더는 일종의 규칙입니다. 인터넷을 경유하여 전달되는 메시지가 제 각각의 헤더를 갖고 있다면 제대로 이것을 처리하는 것은 불가능할 것입니다. 따라서 메시지의 헤더를 기록하는 전세계 공통의 규약이 필요합니다.
이메일의 헤더에 대해 정의하고 있는 문서는 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:"헤더를 쓸 수도 있다는 애매한 규약이 아니라 *반드시* 그것을 써야한다는 철저한 규약입니다.
헤더는 어떻게 구성되어 있는가?
헤더의 기본구조는 "정의 문자열 : 내용"의 형식으로 이루어 집니다. 제목을 나타내는 헤더는 subject: 로 표시됩니다. 콜른(:) 뒤에 여러분이 입력한 제목이 기록됩니다. 이렇게 기록된 헤더를 보고 이메일을 처리하는 센드메일이나 유즈넷 메시지를 처리하는 뉴스 서버가 정보를 인식하게 됩니다.
메시지를 처리하는 서버는 제일 처음 메시지에서 자신이 작업을 처리하는데 필요한 헤더를 찾습니다. 만약 여러분이 누군가에게 이메일을 보냈다면 메시지에는 "To:" 라는 헤더가 있을 것입니다. 이메일을 보내고 받는 역할을 하는 센드메일 프로그램은 이 부분을 참조하여 메시지를 어디로 보낼 것인지 판단합니다. 우선 헤더에서 "To:"라는 문자열을 찾고 그 문자열이 존재하면 콜른(:) 뒤에 있는 주소로 메일을 보내게 됩니다.
헤더에는 어떤 구성요소가 있는가?
헤더는 매우 다양한 구성요소가 있습니다. 메시지를 전달하기 위해 반드시 필요한 것도 있고 꼭 필요하지 않은 것도 있습니다. 또 어떤 헤더는 여러분이 입력하지 않아도 자동으로 입력되는 것도 있습니다. 자동으로 입력되는 헤더는 다시 메일/뉴스 프로그램이 직접 기록하는 것과 서버에서 직접 기록하는 것이 있습니다.
자신이 직접 입력할 수 있는 헤더
자신이 직접 입력할 수 있는 헤더는 주로 메일 프로그램에서 새 메시지를 작성할 때 입력할 수 있는 항목과 프로그램의 설정 항목에서 작성한 내용입니다. 프로그램의 설정 항목에 기록한 내용은 이메일을 보낼때마다 자동으로 헤더에 첨부됩니다. 자신의 소속, 이메일 주소, 진짜 이름등등은 이메일을 보낼때마다 매번 기록할 필요가 없을 것입니다. 그래서 그런 것들은 프로그램 설정 항목에 기록하도록 해서 자동으로 입력할 수 있도록 하는 것입니다. 그러나 받는 사람, 제목, 참조, 숨은 참조등은 이메일을 보낼때마다 매번 바뀌는 항목이라서 매번 새롭게 입력해야 합니다.
1. 받은 사람
헤더 - To:
메시지를 보내려면 당연히 받는 사람의 주소를 적어야겠지요. To: 헤더에 아무것도 입력하지 않으면 메시지를 보낼 수 없습니다. 메일 서버는 이곳에 있는 주소로 여러분의 메시지를 보냅니다. 프로그램에서 "수신인" 또는 "받는 사람" 입력창에 입력한 내용이 To: 헤더에 기록됩니다.
2. 참조
헤더 - Cc:
Cc는 "Carbon Copy"의 약자로써 원본 메시지를 참조하는 것을 말합니다. 참조는 어떤 메시지를 여러 사람에게 보낼 때 원본 메시지와는 별도로 다른 사람이 그 메시지를 참조삼아 읽으라고 보내는 경우에 사용합니다. A라는 사람에게 보내는 메시지를 B와 C가 참조할 필요가 있다고 생각한다면 A를 받는 사람으로 지정하고 B와 C는 참조로 지정하여 메시지를 보내면 됩니다. 참조형식으로 보낸 메시지의 헤더에는 Cc: 부분에 받는 사람의 주소가 모두 표시됩니다.
3. 숨은 참조
헤더 - Bcc:
Bcc는 "Blind Carbon Copy"의 약자인데, 숨은 참조라고 합니다. 숨은 참조는 여러 사람에게 메시지를 보낼 때 누구에게 그 메시지를 보냈는지 알 수 없도록 참조인의 주소를 숨길 때 사용합니다. 참조를 나타내는 Cc: 헤더와는 달리 숨은 참조란에 기록한 주소는 헤더에 표시되지 않습니다. 100명에게 메시지를 보낼 때 참조를 이용하는 것은 좋지 못합니다. 100명은 자신에게 필요하지 않은 99명의 이메일 주소가 헤더에 포함된 이메일을 받아야할 것이니까요.
4. 제목
헤더 - Subject:
보낼 메시지의 제목을 나타내는 헤더입니다. 설령 여러분이 제목을 적지 않고 이메일을 보냈더라도 헤더는 표시됩니다. 제목을 "안녕"이라고 적었다면 "Subject: 안녕"이라고 될 것이고 제목을 적지 않았다면 단지 "Subject:"라고만 헤더에 표시될 것입니다.
프로그램의 설정 메뉴에서 기록하는 헤더
사용하는 이메일 프로그램의 설정 메뉴에서 기록한 정보는 보내는 이메일 메시지의 헤더에 자동으로 기록됩니다. 이런 정보는 늘 입력할 필요가 없는 고정된 정보입니다. 이메일을 보내며 매번 자신의 이메일 주소와 이름, 소속, 답신받을 주소를 입력할 필요는 없을 것입니다. 그런 것들은 자동으로 입력하도록 설정해 두는 것이 훨씬 편할 것입니다.
1. 전자 우편 주소
헤더 - From:
자신의 주소가 없다면 보낸 메시지가 잘못되었을 때 어디로 반송되어 올지 알 수 없을 것입니다. 자신의 이메일 주소를 적지 않으면 메시지를 작성할 수 없습니다. 정 주소를 밝히기 싫다면 가짜 주소라도 적어야 합니다. somebody@nonono.com 처럼 정체불명의 주소라도 적지 않으면 메시지를 작성할 수 없습니다. 아웃룩 익스프레스에서 From: 헤더를 설정하는 곳은 [계정] 메뉴에서 사용자 정보 입력창입니다. [전자 우편 주소]라는 곳에 입력한 정보가 From: 헤더에 기록됩니다.
2. 이름
헤더 - From:
자신의 이름을 적는 곳입니다. 이곳을 비워두면 메시지를 작성할 수 없습니다. 자기 이름을 입력해도 좋고, 이름을 밝히기 싫다면 가짜 이름 - 'SkyHawk'와 같은 별명이나 가짜 이름을 적어도 무방합니다. 여기에 적은 이름은 From: 헤더에 기록되어 다음과 같이 나타납니다.
From: "Lee JunYoung" leejuy@hyowon.pusan.ac.kr
3. 회신 주소
헤더 - Reply-To:
상대방이 여러분의 이메일에 대해 회신하기 위해 이메일 프로그램의 회신 기능을 사용할 때 이곳에 적어둔 주소로 답신이 보내집니다. 회신 주소 입력창에 굳이 주소를 적지 않아도 괜찮습니다. Reply-To 헤더가 없을 경우 '전자 우편 주소'로 답신이 보내지게 됩니다.
Reply-To: "Lee JunYoung" <leejuy@hyowon.pusan.ac.kr>
자동으로 붙는 헤더
여러분이 받은 이메일의 헤더를 잘 살펴 보십시오. 그곳에는 여러분이 설정할 수 없는 헤더들이 있을 것입니다. 이런 헤더들은 대부분 센드메일에서 이메일을 주고 받으며 붙인 헤더나 여러분이 사용중인 메일 프로그램에서 붙인 헤더입니다. 이런 헤더는 여러분이 어떻게 조정할 수 없는 것들입니다.
1. 메일이 전달된 경로
헤더 - Received:
여러분의 편지함에 도착한 메일이 어디를 거쳐서 왔는지 표시하는 헤더입니다. [from A by B for C]라는 문장으로 이루어져 있습니다. "B라는 메일 서버를 통해 A라는 메일 서버로 전송된 이메일이다. 그리고 그것은 C에게 전달되었다."라는 내용을 담고 있습니다. 이 부분의 헤더를 잘 살펴보면 메일이 어디를 거쳐서 여러분에게 전달되었는지 잘 알 수 있습니다. 여기에 그 사람이 사용하는 컴퓨터의 이름이 표시되기도 하고, 메일 서버로 어떤 프로그램을 사용하는지, 센드메일의 버전등이 표시 됩니다. 아래는 제가 받은 메일에 포함된 Received: 헤더입니다. 이것을 잘 분석해 보십시오.
Received: from hyowon.cc.pusan.ac.kr (hyowon.cc.pusan.ac.kr [164.125.9.3])
by bora.dacom.co.kr (8.8.6/8.8.6) with SMTP id BAA11063
for <social91@bora.dacom.co.kr>; Fri, 30 Jan 1998 01:47:06 +0900 (KST)
첫 라인에서 메일이 hyowon.cc.pusan.ac.kr이라는 서버에서 보내진 것임을 알 수 있습니다. 이곳의 IP 주소는 164.125.9.3이구요. 두 번째 라인에서 메일이 bora.dacom.co.kr이라는 서버로 전달되었음을 알 수 있습니다. 그리고 이 서버는 SMTP 서버로군요. 그리고, 세 번째 라인에서 1998년 1월 30일, 금요일 오전 1시 47분에 social91@bora.dacom.co.kr이라는 사용자에게 전달되었음을 알 수 있습니다. 날짜는 여러분의 메일 서버로 메일이 도착한 시간을 의미합니다. 뒤에 얘기할 Date: 헤더는 상대방이 메일을 보낸 시간을 의미하는데 이것을 보고 메일 서버간의 전달 시간을 체크해 볼 수 있습니다. "+0900 (KST)"는 한국 표준 시각을 말합니다. 그리니치 표준시보다 9시간 빠르다는 뜻이죠?
가끔 Received: 헤더가 여러개 포함된 메시지를 발견할 수 있습니다. 곧장 자신에게 전달된 메시지가 아니라 다른 몇 개의 서버를 거쳐 전달된 경우 Received: 헤더에는 거쳐온 메일 서버들이 모두 표시됩니다. 맨 아래의 Received: 헤더가 제일 처음 메일이 발송된 곳이고 그곳에서 차례대로 위쪽으로 지나온 것입니다. 제가 구독중인 온라인 잡지인 People에서 보내온 메일의 Received: 헤더를 보십시오.
(1) Received: from hyowon.cc.pusan.ac.kr (hyowon.cc.pusan.ac.kr [164.125.9.3])
by bora.dacom.co.kr (8.8.6/8.8.6) with SMTP id CAA13191
for <social91@bora.dacom.co.kr>; Fri, 30 Jan 1998 02:10:40 +0900 (KST)
(2) Received: from listserv.pathfinder.com ([204.71.242.6]) by hyowon.cc.pusan.ac.kr (8.6.11/8.6.8)
with ESMTP id CAA14694 for <leejuy@HYOWON.PUSAN.AC.KR>;
Fri, 30 Jan 1998 02:10:39 +0900
(3) Received: (from daemon@localhost) by pathfinder.com (*private*/SMI-SVR4) id
LAA21552 for peopledaily-text@listserv.pathfinder.com; Thu, 29 Jan
1998 11:44:40 -0500 (EST)
3개의 Received: 헤더가 있습니다. 여러분은 이것을 보고 어떤 정보를 얻을 수 있습니까?
(3) 의 Received: 헤더를 보세요. pathfinder.com이라는 컴퓨터에서 listserv.pathfinder.com이라는 컴퓨터에게 메일을 보내도록 지시했음을 알 수 있습니다. pathfinder.com이라는 컴퓨터는 People지의 메인 컴퓨터입니다. 여기서 온라인 신문을 구독하는 사람들을 위해 신문을 작성합니다. 그리고 실제로 메일을 보내는 컴퓨터인 listserv.pathfinder.com이라는 컴퓨터로 메시지를 보내면 이 컴퓨터가 메일 발송작업을 하는 것입니다. 메일은 미국 동부 표준시(EST) 1998년 1월 29일 오전 11시 44분에 전세계 온라인 People 구독자에게 발송되었습니다.
(2) 의 Received: 헤더에서 이 메시지가 한국 시각 1월 30일 오전 2시 10분 39초에 hyowon.pusan.ac.kr이라는 컴퓨터로 도착했음을 알 수 있습니다. 이 컴퓨터는 제가 학교에서 사용하는 계정이 있는 컴퓨터입니다. 이 주소로 도착한 메일은 즉시 bora.dacom.co.kr이라는 컴퓨터로 돌려 보내도록 설정해 두었죠.
(3)의 Received: 헤더에서 한국 시각 1월 30일 오전 2시 10분 40초에 bora.dacom.co.kr로 메시지가 도착했음을 알 수 있습니다.
메일을 보내고 받은 시각은 센드 메일에서 그리니치 표준시로 계산합니다. +0900 (KST)는 한국 표준 시각이 그리니치 표준시보다 9시간 빠르다는 말입니다. 결국 메일이 미국 동부의 People 메인 컴퓨터에서 social91@bora.dacom.co.kr까지 전달되는데 약 26분이 걸린 것을 알 수 있습니다.
Received: 헤더를 통해 여러분은 이렇게 메일이 전달되는 경로를 알 수 있을 뿐만 아니라 메일의 전달과정에 문제가 생겼을 때 도움을 받기도 합니다. 만약 메일이 전달되는 과정에서 매우 시간이 많이 걸렸거나 또는 데이터의 손실이 발생했다면 Received: 헤더를 참조하여 중간에 어떤 메일 서버를 경유했는지 확인할 수 있습니다. 그리고 그 메일 서버가 문제가 있는지 조사해 보거나 서버 담당자에게 문의할 수 있습니다. 만약 여러분이 메일을 주고 받는 메일 서버의 센드메일 버전이 너무 낮아 메일이 깨지는 문제가 발생한다면 다른 곳으로 서비스를 옮기는 것을 고려할수도 있습니다.
2. 메시지 아이디
헤더 - Message-ID
이 헤더는 메일 서버에서 메시지를 외부로 보내며 붙이는 일련번호입니다. 메시지 아이디는 다음과 같이 표시됩니다.
Message-ID: <199801291644.LAA21552@pathfinder.com>
여러분은 이것을 통해 단지 그 메시지가 어떤 컴퓨터에서 보내졌는지 알 수 있습니다. 그러나, '@' 앞에 적혀있는 이상한 문자열은 여러분을 위한 것이 아니라 컴퓨터가 그 메시지에 임의로 붙인 번호표입니다.
3. 보낸 날짜
헤더 - Date
메일을 보낸 날짜를 표시하며 다음과 같은 형식으로 표시됩니다.
Date: Thu, 29 Jan 1998 02:37:50 -0800 (PST)
시간을 표기하는 방식은 24시간 표기방식으로 마지막에 그리니치 표준시를 표시합니다. 이것을 보고 그 컴퓨터가 위치한 지역을 대략 예상해 볼 수 있습니다. 예문에 제시된 PST(Pacific Standard Timezone)는 태평양 표준시로써 미국과 캐나다에서 사용하는 표준 시간대를 의미합니다. Date: 헤더는 서버에서 직접 붙이는 경우가 있고, 사용자의 컴퓨터 시간을 따르는 경우가 있습니다. 계정에 접속하여 PINE을 통해 메일을 보내면 Date 헤더에 서버의 시계에 맞춰서 Date: 헤더가 붙습니다. 그러나, 아웃룩 익스프레스를 이용하여 메일을 보낼 경우 사용자의 컴퓨터에 있는 시계에 맞춰서 Date 헤더가 붙게 됩니다.
Received: 헤더에 나와있는 시각이 실제로 서버에 메일이 도착한 시간이라면 Date: 헤더는 메일 프로그램에서 메일이 보내진 시각을 의미합니다.
4. MIME 헤더
MIME이란 멀티미디어 메일을 위한 인터넷 표준 규약입니다. 여러분이 MIME 표준을 지원하는 메일 프로그램을 사용하며 'MIME을 사용하여 메일 보내기' 옵션을 설정하면 다음과 같은 헤더를 볼 수 있습니다.
가) MIME-Version: 1.0
MIME의 버전을 나타냅니다.
나) Content-Type:
Content-Type: 헤더는 메일 본문이 어떤 형식인지 알려 줍니다.
text/plain - 일반 문자열을 사용한 본문
multipart/ - 일반 문자열과 다른 여러 가지 인코딩 방식이 섞여 있을 경우 multipart/mixed는 일반 텍스트에 파일을 첨부했을 경우에 사용합니다. multipart/alternative는 똑같은 내용이 일반 텍스트와 html로 반복되어 있어서 둘 중 하나를 선택해서 읽을 수 있을 경우에 사용합니다. multipart/related 는 HTML 형식의 메시지를 보내며 배경그림을 첨부했을 때 사용됩니다.
다) charset="euc-kr"
charset= 부분은 본문이 어떤 언어로 작성되었는지를 나타냅니다. Content-Type 헤더에 함께 나타납니다. 한글 메일의 경우 euc-kr이란 문자셋이 표시되어야 합니다.
라) Content-Transfer-Encoding:
본문이 인코딩된 방식을 표시합니다. 한글 메시지에 8비트라고 표시되어 있으면 인코딩없이 본문을 그대로 보낸 것입니다. BASE64라든가 Quoted Printable라고 적혀 있으면 그런 방식으로 인코딩을 했다는 의미입니다.
제 멋대로 붙인 헤더
헤더는 철저히 규칙에 맞게 붙여야 합니다. 만약 헤더를 마음대로 붙인다면 컴퓨터간에 메시지 전송이 이루어질 수 없기 때문입니다. 어떤 컴퓨터는 O.K를 '좋다'는 뜻으로 이해하는데 다른 컴퓨터는 O.K를 '엉망이다'라는 뜻으로 이해하면 어떻게 되겠습니까?
그런데, 이런 엄격한 규칙을 가진 헤더지만 제 멋대로 붙일 수 있는 헤더도 있습니다. 'X-'라는 문자열로 시작하는 헤더가 그런 경우입니다. 이런 헤더는 메일 서버에서 신경을 쓰지 않고 그냥 넘겨 버립니다. 신경을 쓰지 않기 때문에 이런 헤더에 무슨 내용을 쓰더라도 메일의 전송에 영향을 끼치지 않습니다. 아웃룩 익스프레스를 사용하여 보낸 메일에는 이런 'X-'가 붙은 헤더를 몇 개 볼 수 있습니다.
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
이 헤더들은 아웃룩 익스프레스라는 프로그램이 임의로 붙인 헤더입니다. 이런 헤더들은 인터넷의 표준이 아닐뿐더러 표준으로 인정받을 필요도 없습니다. 그렇기 때문에 'X-'라는 헤더를 사용한 것이죠.
'X-' 헤더는 매우 다양한 목적으로 사용될 수 있는데, 예문에서 볼 수 있듯이 메일 프로그램을 헤더에 표시하는데 사용되기도 합니다. X-Mailer: 헤더를 통해 메일이 어떤 프로그램을 사용하여 보내졌는지 표시하고 있습니다. X-MimeOLE: 는 메일에 포함된 바이너리 파일을 윈도우의 OLE와 연결시키는 것에 대한 헤더입니다.
또는 그 메일 프로그램이 제공하는 특별한 기능을 표시하기 위해 사용되기도 합니다. 예문에 있는 X-Priority: 헤더와 X-MSMail-Priority: 헤더는 아웃룩 익스프레스를 사용하는 메일에만 붙습니다. 이것은 메일의 보내며 중요도를 설정할 때 나타납니다.
중요도 설정에 따라 헤더의 내용이 달라집니다.
| 중요도 | X-MSMail-Priority | X-Priority |
| 높 음 | High | 1 |
| 보 통 | Normal | 3 |
| 낮 음 | Low | 5 |
중요도가 높게 설정된 메시지를 받으면 메시지 표시 창에 느낌표(!)가 표시되어 그 메시지가 중요한 것임을 표시합니다. 이것은 단지 아웃룩 익스프레스에서 제공하는 특별한 기능일 뿐 메일 암호화라든가 보안문제를 해결하는 기능은 아닙니다.
본문은 어떻게 구성되어 있는가?
메일의 본문은 여러분이 새 메시지 작성창에 입력하는 실제 내용을 말합니다. 여러분은 헤더에 대해 알아보며 헤더 자체도 일반 문자열로 이루어져 있음을 보았을 것입니다. 그렇다면 메일 서버 프로그램이나 메일 프로그램은 어떻게 메일에서 헤더와 본문을 구분하는 것일까요?
정답은 '빈줄'에 있습니다. 이메일을 잘 살펴보세요. 어떤 이메일이든 헤더와 본문 사이에는 한칸 이상의 빈줄이 있습니다. 센드메일과 같은 메일 서버 프로그램이나 아웃룩 익스프레스와 같은 메일 클라이언트는 메일의 맨 처음에 있는 문자열을 '헤더'로 인식합니다. 헤더는 빈칸없이 계속 진행되다가 마침내 빈칸이 발견되면 그 다음에 나오는 문자열은 모두 본문으로 인식합니다.
즉, 메일 서버든 메일 클라이언트든 우선 헤더를 읽어서 본문이 어떤 문자열인지 어떤 식으로 인코딩되었는지 판단을 합니다. 그런 후 이것에 맞게 본문을 화면에 출력시키는 것입니다. 그러니 헤더가 본문의 성격을 규정하는 셈이 되겠지요?
여기서 본문과 헤더의 연관성에 대해 한가지 다른 생각을 해 볼 수 있습니다. 헤더가 본문을 정확히 규정하고 있다면 문제는 발생하지 않을 것입니다. 그런데, 헤더가 본문을 잘못 규정하고 있으면 어떤 일이 벌어질까요? 엉망이 될 것입니다.
그럴 가능성은 0%지만 이런 가능성을 생각해볼 수 있습니다. 실제로 본문은 BASE64로 인코딩되어 보내졌는데 메일에 포함된 헤더에는 본문 인코딩을 규정하는 헤
더인 C-T-E(Content-Transfer-Encoding)가 다음과 같이 되어 있다면?
Content-Transfer-Encoding:quoted-printable
즉 본문이 실제로 인코딩된 방식은 BASE64인데 헤더는 QP로 인코딩되었다고 엉뚱한 정보를 제공하고 있는 것입니다. 이렇게 된다면 여러분은 메시지를 제대로 볼 수 없을 것입니다. 직접 인코딩 방식을 수정하는 수밖에 없습니다.
그러나 이것은 하나의 가정일뿐 실제로 이런 일은 일어나지 않습니다. 대신에 다른 일이 자주 일어나곤 하는데 그중에 가장 흔하게 볼 수 있는 헤더의 문자셋 정보와 본문이 맞지 않는 경우입니다. 여러분이 한글 메일을 보내며 문자셋을 지정할 경우 C-T(Content-Type) 헤더에서 문자셋을 지정하는 부분에(charset:) "euc-kr"이라는 문자열이 지정되어야 합니다. 그런데 간혹 이곳에 엉뚱한 문자셋이 붙어 있는 경우가 있습니다.
Content-Type: text/plain;charset="iso-8859-1"
"iso-8859-1"은 영어(英語)를 표시하는 문자셋입니다. 이런 문자셋은 순전히 영문으로 작성된 메일일 경우에 붙게 됩니다. 한글과 같이 한글, 한자, 영문이 함께 사용되는 문서는 "euc-kr"이라는 문자셋이 지정되야 합니다. 이렇게 한글 메일에 '영어'라는 문자셋이 붙게 되면 익스플로러 3.0x에 포함된 MS 메일, 뉴스 프로그램에서 메일과 뉴스가 모두 깨져서 보이게 됩니다. MS 메일, 뉴스는 헤더에 문자셋을 나타내는 부분(charset=)이 있을 경우 이것을 기준으로 내용을 보여주기 때문입니다.
본문을 작성하기 위해서 직접 새 메시지 작성창에 문서를 타이핑해도 되고 미리 작성한 문서를 불러올 수도 있습니다. 아웃룩 익스프레스를 사용하여 미리 작성한 문서를 불러오려면 [삽입] 메뉴에서 [파일의 텍스트 내용]을 선택하면 됩니다. [파일]을 선택할 경우 내용이 직접 입력되는 것이 아니라 첨부된 파일 형식으로 덧붙여지게 됩니다.
맺음말(Signature)은 어떻게 구성되어 있는가?
맺음말은 어떤 문서를 작성한 후 자신만의 특별한 사인을 넣는 것을 말합니다. 여기에는 어떤 내용이 들어가도 무방한데, 보통 '소속, 이름, 이메일 주소, 특별한 문구'등이 들어갑니다.
이메일의 구조에 대해 설명하는 대부분의 책들은 맺음말(signature)을 이메일의 구성요소 중 하나로 설명하고 있는데 굳이 그렇게 구분지을 필요는 없습니다. 맺음말을 넣지 않는다고 해서 이메일을 보낼 수 없는 것도 아니고, 맺음말만 넣어서 이메일을 보낼 수도 있습니다. 맺음말도 본문의 구성요소로 취급되기 때문입니다.
그러나, 맺음말을 이메일의 구성요소중 하나로 분류하는 이유가 전혀 없는 것도 아닙니다. 대부분의 사람들은 이메일을 보내며 맺음말에 자신을 소개하는 간단한 문구를 넣는데 그것이 일반 텍스트인 경우도 있고, v-card처럼 특정 프로그램을 위한 코드일수도 있습니다. 어떤 이는 아스키 아트(Ascii-Art)라고 불리는 문자열로 만들어진 그림을 넣기도 합니다. 맺음말에 특별히 신경을 쓰는 사람들이 많고 그것을 제작하기 위한 유틸리티가 존재할 정도로 이메일의 특별한 구성요소로 보기도 하기 때문입니다. 그래도 역시나 맺음말은 반드시 필요한 것은 아닙니다.
맺음말을 넣는 방법은 여러 가지인데 PINE와 같은 유닉스 기반 프로그램의 경우 .sig 와 같은 파일을 만들어 두면 메일을 보낼 때 자동으로 여기에 기록한 내용이 맺음말로 첨부됩니다. 아웃룩 익스프레스와 같은 PC용 메일 프로그램에는 이것이 지정할 수 있는 옵션이 따로 존재합니다. [도구] 메뉴의 [편지지]를 선택하면 맺음말을 지정할 수 있습니다.
메시지 맺음말을 직접 입력할 수도 있고, 미리 작성한 파일을 선택할 수도 있습니다. 아웃룩 익스프레스는 메일로 보낼 메시지에 추가할 맺음말과 뉴스그룹에 포스팅할 메시지에 추가할 맺음말을 따로 설정할 수 있습니다.
맺음말로 지정한 내용은 새 메시지를 작성할 때 자동으로 추가되게 됩니다. 매번 맺음말을 복사하여 붙여넣기 하는 사람이라면 이제는 맺음말을 미리 만들어서 자동으로 넣으세요.
맺음말에 대해 많은 주의사항들이 있습니다. 특별히 주의할만한 것은 다음과 같습니다.
| 너무 긴 맺음말을 사용하지 말 것 |
|
| 괜히 쓸데없는 내용을 적지 말 것 |
|
| 누군가를 자극하는 메시지를 적지 말 것 |
|
| 맺음말은 광고창이 아니다 |
|
MIME이란 무엇인가?
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-" 뒤에 사용자가 정의한 코드의 이름을 넣어 사용할 수 있습니다.