반응형
C로 구현하는 MIME Parser (3)
MIME Message를 이해하자.
이번 호에서는 지난 호에서 살펴보았던 내용들을 토대로 MIME Message를 어떻게 구성하는지, 또 구성된 MIME Message에서 어떻게 우리가 원하는 데이터를 끄집어내는지에 대해서 자세히 살펴볼 계획이다. 이번 호가 끝나면 MIME Parser를 구현하기 위한 기본 내용을 모두 숙지하게 된다. 이를 기초로 하여 마지막 호인 다음 호에서는 실제로 MIME Parser를 구현해 보도록 하자.
(주)넷사랑컴퓨터 조한열
hanyoul@netsarang.com
1. 제일 간단한 MIME Message
리스트 1의 메일 메시지는 MIME Message이다. 왜? 이유는 단 한가지이다. MIME-Version이란 MIME 헤더가 RFC822 헤더(From, To, Subject)와 함께 들어있기 때문이다.
메일 메시지 헤더에 MIME-Version이란 헤더가 들어있다면 메일 메시지는 MIME Message로 해석이 되어야 한다. 그렇다면 리스트 1의 메일 메시지를 MIME Message로 간주하고 해석해보도록 하자.
리스트 1 : MIME Message 예
From: hanyoul@netsarang.com
To: anyone@somehost.com
Subject: The Simplest MIME Message
MIME-Version: 1.0
Hi! Everybody.
Thank you
MIME Message를 해석하기 위해서 없어서는 안될 MIME 헤더는 2가지가 있다. 바로 Content-Type과 Content-Transfer-Encoding이다. 지난 호를 유심히 살펴본 독자라면 이미 이 두가지 헤더의 의미를 알겠지만 다시 한 번 이 두가지 헤더에 대한 의미를 간략히 살펴보자.
Content-Type 헤더는 MIME Message가 포함하고 있는 내용 혹은 데이터(Content)가 어떤 타입인지를 가리키는 헤더이다. Plain text이나 GIF image등의 타입이 여기에 기술되어 있다. 만약 Content-Type이 텍스트라면 Content-Type에는 부가 정보로 Character Set에 대한 정보가 기술되어 있다.
Content-Transfer-Encoding 헤더는 8bit 데이터를 어떤 방식을 통해 7bit 데이터로 변환시켰는지를 알려주는 헤더이다. Content-Transfer-Encoding 헤더의 값으로는 7bit, 8bit, binary, quoted-printable, base64등이 있다. 위의 값 중에서 7bit, 8bit, binary는 그 어떤 변환도 하지 않음을 말해준다. 그냥 메일을 보낸 시점의 데이터가 변환되지 않고 그대로 메일 메시지에 실려왔음을 말해주는 것이다.
이제 리스트 1의 MIME Message를 다시 한 번 살펴보자. 그러나, MIME-Version이라는 헤더만 있을 뿐, Content-Type이나 Content-Transfer-Encoding 헤더는 보이지 않는다. 그렇다면 MIME Message를 어떻게 해석할 수 있을까. 정답은 간단하다. Content-Type 헤더가 없을 때에는 Content-Type이 plain text라고 간주하면 된다. 또한 이 Content의 character set은 US-ASCII(일반 영자)라고 생각하면 된다. Content-Transfer-Encoding 헤더가 없을 때에는 기본적으로 7bit 인코딩으로 간주된다. 따라서 위의 간단한 MIME Message는 리스트 2와 동일하다.
리스트 2 : 7bit로 간주된 MIME Message
From: hanyoul@netsarang.com
To: anyone@somehost.com
Subject: The Simplest MIME Message
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7but
Hi! Everybody.
Thank you
그러므로 리스트 1의 MIME Message의 Content는 데이터변환이 없는(7bit 인코딩이니까) 영문으로 된 텍스트(text/plian; charset=us-ascii)라는 것을 알 수 있다.
이번엔 조금 복잡한 MIME Message를 살펴보자. 역상 부분이 MIME 헤더라는 것은 이제 너무도 쉽게 알 수 있을 것이다. 리스트 3의 MIME Message에 대한 설명을 보기 전에 독자 여러분이 스스로 MIME Message를 MIME 헤더 정보(역상부분)를 이용하여 해석해 보는 것도 좋을 것이다.
리스트 3 : MIME Message
From: hanyoul@netsarang.com
To: anyone@somehost.com
Subject: JPEG image file
MIME-Version: 1.0
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
/9j/4AAQSkZJRgABAgAAZABkAAD//gASQWRvYmUgSW1hZ2VSZWFkef/sABFEdWNreQABAAQAAAAu
AAD/7gAOQWRvYmUAZMAAAAAB/9sAhAAKBwcHBwcKBwcKDgkICQ4QDAoKDBATDw8QDw8TEg4QDw8Q
DhISFRYXFhUSHR0fHx0dKSkpKSkvLy8vLy8vLy8vAQoJCQoLCg0LCw0QDQ4NEBQODg4OFBcPDxEP
DxcdFRISEhIVHRocFxcXHBogIB0dICAoKCYoKC8vLy8vLy8vLy//wAARCADUARsDASIAAhEBAxEB
/8QAqgAAAgIDAQAAAAAAAAAAAAAAAAECBQMEBgcBAAEFAQEAAAAAAAAAAAAAAAABAgQFBgMHEAAB
AwIFAgQEBAQEBQQDAAABABECIQMxQRIEBVFhcYEiBpGhMhOxwUIU0eFSI/DxFQdicpIzFoKiwlNU
NRcRAAEDAgQCBwYEBQUAAAAAAAEAAgMRBCExQRJxBVFhgZEiMhOhwdFCUhSxckMV8OHxMwZigsIj
JP/aAAwDAQACEQMRAD8A5wFsii2SLhBpV1mk0Q8pae5KwCQne1ROoHA5KEcitjzED0W447x71ebM
kgMa5KW6
아마도 지난 호의 내용과 앞에서 설명한 내용을 잘 이해했다면 무리없이 해석할 수 있을 것이다. 아직 이해가 되지 않는 독자들을 위해 리스트 3의 MIME Message를 해석해보자.
'MIME-Version: 1.0' 이라는 헤더를 통해 우리는 위의 메일을 MIME Message라고 간주해야 한다. Content-Type이 image/jpeg이므로 MIME Message가 포함하고 있는 Content는 jpeg형식의 image 파일이다. image 파일은 binary 파일이므로 8bit 데이터이다. 8bit 데이터를 7bit 데이터로 변환하여 메일을 전송하는 것이 안전하기 때문에(이유는 1회에서 설명하였다.) 7bit로 인코딩했다는 것을 예측할 수 있다. 그러므로 Content-Transfer-Encoding이 무엇인지를 살펴봐야 한다. Content-Transfer-Encoding 헤더는 인코딩 방식이 base64 방식임을 말해주고 있다. 즉, MIME Message가 포함하고 있는 Content는 base64 방식으로 인코딩되어 있기 때문에, 원래의 데이터를 얻기 위해서는 base64 방식에 의거하여 인코딩되 Content를 디코딩해야 한다.
/9j/4AAQSkZ........ 로 시작되는 부분이 바로 Content인데, 이것이 base64 방식으로 인코딩 된 것이다. 이를 지난 호에서 설명한 base64 방식에 의거하여 디코딩하면 원래의 jpeg image를 얻을 수 있는 것이다.
2. Multipart MIME Message
만약에 메일을 통해 위에서 보았던 jpeg image를 보내면서 이 image 파일에 대한 설명을 같은 메일에 함께 보내려면 어떻게 하면 될까? 이럴 때는 Multipart MIME Message를 만들면 된다. 처음 들어보는 말이라고 해서 너무 어렵게 생각할 필요는 없다. Multipart MIME Message란 두 개 이상의 Content를 하나의 MIME Message에 붙여넣는 것이다. 이 때, 각 Content 마다 MIME 헤더를 붙이고 난 후 각 Content를 구분할 수 있는 경계선을 표시해 넣는 것이다. 말로 설명하면 더욱 어려워질 것 같으니, 직접 Multipart MIME Message를 살펴보도록 하자.
리스트 4의 Multipart MIME Message는 image 파일과 image 파일에 대한 설명을 담은 text를 함께 묶어 구성한 것이다.
리스트 4 : Multipart MIME Message
From: hanyoul@netsarang.com
To: anyone@somehost.com
Subject: JPEG image file
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="MIME-boundary1--------DC128F5642CA"
--MIME-boundary1--------DC128F5642CA
Content-Type: text/plain; charset=us-ascii
Hi!
I will send you a good image. This image is my favorite picture.
--MIME-boundary1--------DC128F5642CA
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
/9j/4AAQSkZJRgABAgAAZABkAAD//gASQWRvYmUgSW1hZ2VSZWFkef/sABFEdWNreQABAAQAAAAu
AAD/7gAOQWRvYmUAZMAAAAAB/9sAhAAKBwcHBwcKBwcKDgkICQ4QDAoKDBATDw8QDw8TEg4QDw8Q
DhISFRYXFhUSHR0fHx0dKSkpKSkvLy8vLy8vLy8vAQoJCQoLCg0LCw0QDQ4NEBQODg4OFBcPDxEP
DxcdFRISEhIVHRocFxcXHBogIB0dICAoKCYoKC8vLy8vLy8vLy//wAARCADUARsDASIAAhEBAxEB
/8QAqgAAAgIDAQAAAAAAAAAAAAAAAAECBQMEBgcBAAEFAQEAAAAAAAAAAAAAAAABAgQFBgMHEAAB
AwIFAgQEBAQEBQQDAAABABECIQMxQRIEBVFhcYEiBpGhMhOxwUIU0eFSI/DxFQdicpIzFoKiwlNU
NRcRAAEDAgQCBwYEBQUAAAAAAAEAAgMRBCExQRJxBVFhgZEiMhOhwdFCUhSxckMV8OHxMwZigsIj
JP/aAAwDAQACEQMRAD8A5wFsii2SLhBpV1mk0Q8pae5KwCQne1ROoHA5KEcitjzED0W447x71ebM
kgMa5KW6
--MIME-boundary1--------DC128F5642CA--
먼저 Content-Type을 살펴보면 multipart/mixed라는 것을 알 수 있다. 주 카테고리인 multipart는 위의 메일이 Multipart MIME Message 포맷이라는 것을 나타내고 있다. 또한 multipart의 부 카테고리는 Content 간의 관계를 나타내는 것이 일반적인데, 여기서는 부 카테고리가 mixed임을 알 수 있다. mixed는 multipart로 묶여진 Content들이 서로 독립적이지만 Content들의 순서에 의미가 있을 때 사용한다.
Content-Type이 multipart일 때는 Content-Type의 부가정보인 boundary가 무엇보다도 중요하다. Content-Type의 부가정보인 boundary는 Content들을 구분하는 구분경계를 표시하는 것이기 때문이다. boundary 정보가 있어야만 올바르게 Multipart MIME Message를 원래의 데이터들로 파싱하는 것이 가능하다는 것은 당연할 것이다.
boundary는 메일 메시지에 등장하지 않을 만한 문자열로 만들어야 한다. 만약 Content 내용에 boundary에 해당하는 문자열이 들어있어 엉뚱하게 파싱이 되는 것을 막기 위해서이다.
실제로 boundary 문자열을 이용하여 경계를 표시할 때는 하이픈(-)을 덧붙이는 것이 규칙이다. boundary 문자열 앞에 하이픈(-) 두 개를 덧붙여 Content의 경계를 표시한다. 리스트 4의 메일에서 boundary가 "MIME-boundary1--------DC128F5642CA"(따옴표는 제외)이므로 경계를 표시하기 위한 실제 문자열은
"--MIME-boundary1--------DC128F5642CA"(따옴표 제외)
가 된다. 어떤 줄의 첫 시작이 "--MIME-boundary1--------DC128F5642CA"라면 그 다음 줄부터는 새로운 Content이다.
boundary 문자열의 앞뿐만 아니라 뒤에도 하이픈(-)이 붙은 문자열이 존재하는 데, 이는 Multipart MIME Message의 끝을 나타낸다. boundary 문자열의 앞뒤에 하이픈(-)이 두 개씩 붙은 문자열은 그 문자열의 뒤로는 Content가 더 이상 없다는 것을 뜻한다. 위의 메일에서 맨 마지막 줄을 보면 "--MIME-boundary1--------DC128F5642CA--"(따옴표 제외)가 있는데, boundary 문자열인 "MIME-boundary1--------DC128F5642CA"(따옴표 제외)의 앞뒤에 하이픈(-)이 두 개씩 붙어있음을 알 수 있고, 이 문자열을 끝으로 Multipart MIME Message가 끝난다는 것을 알 수 있다.
--boundary 문자열과 그 다음에 나오는 --boundary 문자열(혹은 --boundary-- 문자열) 사이에 있는 것이 하나의 MIME Content라는 것은 수차에 걸쳐 이야기했다. 이 MIME Content는 처음에 살펴본 간단한 MIME Message와 마찬가지로 헤더와 데이터로 구성되어 있다. MIME Content의 헤더가 데이터의 정보를 나타내고 있다는 것을 이제는 쉽게 알 수 있을 것이다. 헤더와 데이터는 하나의 빈 줄로 구분된다. 헤더가 나오고 한 줄이 비어지고 그 다음에 데이터가 나오는 것이다. 위의 메일에는 모두 두 개의 Content가 있는데, 첫 번째 Content의 Content-Type은 text/plain이면 두 번째 Content-Type은 image/jpeg라는 것을 알 수 있다. 또한 위의 첫 번째 Content의 헤더에 Content-Transfer-Encoding이 없으므로 디폴트 값인 7bit 인코딩이 되었음을 알 수 있고, 두 번째 Content는 base64 방식으로 인코딩 되어있음을 알 수 있다.
그런데 여기에서 의문이 생길 수가 있다. 어디가 Content의 마지막인가 이다. 무슨 말인지 의아하겠지만 다음을 한 번 살펴보자. 아래는 위 Multipart MIME Message의 한 부분이다. 첫 번째 Content가 끝나고 두 번째 Content를 구분하기 위한 --boundary 문자열이 나타나는 곳이다.
Hi!
I will send you a good image. This image is my favorite picture.
[CRLF]
--MIME-boundary1--------DC128F5642CA
Content-Type: image/jpeg
역상부분으로 나타낸 [CRLF](줄바꿈)표시는 과연 첫 번째 Content에 포함되는가, 아닌가 하는 질문에 대답해보자.
text 기반의 데이터라면 그것이 그렇게 중요하지 않을 수도 있지만 만약 binary 데이터라면 [CRLF]가 데이터에 포함되는지 포함되지 않는지는 무척 중요한 문제이다.
MIME을 설명하고 있는 RFC문서에서는 --boundary 문자열(혹은 --boundary-- 문자열) 앞에 붙어있는 [CRLF] 문자를 --boundary 문자열(혹은 --boundary-- 문자열)에 속한 것으로 정의하고 있다. 즉 Content 데이터에 포함되지 않는다는 것이다.
3. Multipart Content를 내부에 포함한 Multipart MIME Message
Multipart MIME Message 안에 들어있는 Content가 또 다시 Multipart MIME Message가 될 수도 있다. 계속 재귀적으로 multipart가 중첩된 구조를 가질 수 있다는 것이다.
From: hanyoul@netsarang.com
To: anyone@somehost.com
Subject: JPEG image file
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="MIME-boundary1--------DC128F5642CA"
--MIME-boundary1--------DC128F5642CA
Content-Type: text/plain; charset=us-ascii
This message include another multipart message.
--MIME-boundary1--------DC128F5642CA
Content-Type: multipart/mixed;
boundary="MIME-boundary2--------DC128F5642CA"
--MIME-boundary2--------DC128F5642CA
Content-Type: text/plain; charset=us-ascii
Hi!
I will send you a good image. This image is my favorite picture.
--MIME-boundary2--------DC128F5642CA
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
/9j/4AAQSkZJRgABAgAAZABkAAD//gASQWRvYmUgSW1hZ2VSZWFkef/sABFEdWNreQABAAQAAAAu
AAD/7gAOQWRvYmUAZMAAAAAB/9sAhAAKBwcHBwcKBwcKDgkICQ4QDAoKDBATDw8QDw8TEg4QDw8Q
DhISFRYXFhUSHR0fHx0dKSkpKSkvLy8vLy8vLy8vAQoJCQoLCg0LCw0QDQ4NEBQODg4OFBcPDxEP
DxcdFRISEhIVHRocFxcXHBogIB0dICAoKCYoKC8vLy8vLy8vLy//wAARCADUARsDASIAAhEBAxEB
/8QAqgAAAgIDAQAAAAAAAAAAAAAAAAECBQMEBgcBAAEFAQEAAAAAAAAAAAAAAAABAgQFBgMHEAAB
AwIFAgQEBAQEBQQDAAABABECIQMxQRIEBVFhcYEiBpGhMhOxwUIU0eFSI/DxFQdicpIzFoKiwlNU
NRcRAAEDAgQCBwYEBQUAAAAAAAEAAgMRBCExQRJxBVFhgZEiMhOhwdFCUhSxckMV8OHxMwZigsIj
JP/aAAwDAQACEQMRAD8A5wFsii2SLhBpV1mk0Q8pae5KwCQne1ROoHA5KEcitjzED0W447x71ebM
kgMa5KW6
--MIME-boundary2--------DC128F5642CA--
--MIME-boundary1--------DC128F5642CA--
위에서 역상부분이 중첩된 Multipart MIME Message이다. 중첩된 Multipart MIME Message는 새로운 boundary 문자열(MIME-boundary2--------DC128F5642CA)을 가지고 있다. 그러므로 "--MIME-boundary2--------DC128F5642CA--"(따옴표 제외)로 끝날 때까지가 하나의 Content인 것이다.
이런 중첩된 구조는 multipart뿐만이 아니라 multipart를 포함한 메일 메시지 자체(message/rfc822)를 포함할 수도 있다. 이는 메일 서버가 서버 관리자에게 에러를 보고할 때 에러가 난 메일 자체를 포함시킨 에러 보고 메일(Error Reporting Mail)을 보낼 때 자주 사용된다.
4. 눈여겨봐야할 MIME 타입
4.1 multipart/mixed
기본적인 multipart 타입이 바로 multipart/mixed이다. multipart/mixed 타입은 multipart로 묶여진 Content들이 서로 독립적임을 나타낸다. 하지만 Content들이 들어있는 순서에 의미가 있다. 화일을 첨부하여 메일을 보낼 때 주로 사용되는데, 이 때 처음에 들어있는 Content가 메일 본문이고 다음부터 나오는 Content들이 첨부화일이다. 메일 본문과 첨부화일의 순서처럼 순서에 의미가 있는 경우에 사용하는 것이 multipart/mixed 타입이다. 또한 부 카테고리가 어떤 타입인지를 모르는 multipart 타입은 모두 multipart/mixed로 해석한다.
4.2 multipart/alternative
multipart/alternative 타입은 multipart로 묶여진 Content들이 서로 같은 내용을 담고 있지만 표현 형식이 다를 때 사용한다. 예를 들어 메일을 보낼 때, html 형식으로 보내고 싶지만 상대방 메일 클라이언트가 html을 지원하지 않는 프로그램일지도 모른다는 걱정이 들 때 multipart/alternative 타입을 사용한다. 아래의 메일을 보자.
From: hanyoul@netsarang.com
To: anyone@somehost.com
Subject: alternative multipart example
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary=boundary1234
--boundary1234
Content-Type: text/plain; charset=us-ascii
...여기에는 plain text 형식의 메시지가 들어간다...
--boundary42
Content-Type: text/html
...여기에는 위의 메시지와 같은 내용을 가지고 있지만, 형식이 html인 메시지가 들어간다...
--boundary42--
위의 예에서 살펴보면 같은 내용의 메시지를 text/plain 형식과 text/html 형식으로 만들어서 함께 보냈음을 알 수 있다. 이 때, 받는 사람의 메일 클라이언트가 html을 지원하면 두 번째 Content를 보여주고, html을 지원하지 않는다면 첫 번째 Content를 보여주게 된다. 여기서 하나 더 알아두어야 할 것은 multipart/alternative 타입에서도 Content들 간의 순서가 중요하다는 것이다. 보내는 사람이 더 선호하는 형식을 뒤에 놓게 되어 있다. 위의 예에서 보내는 사람이 text/html 형식을 text/plain 보다 뒤에 배치했기 때문에 받는 사람은 보낸느 사람이 html 형식으로 보기를 바란다는 것을 알 수 있는 것이다. 그러므로 multipart/alternative 타입으로 묶여진 모든 Content들의 형식을 받는 메일 프로그램이 모두 다 알고 있을 때에는 맨 마지막 Content를 보여주면 되는 것이다.
4.3 multipart/digest
multipart/digest 타입은 multipart/mixed 타입과 거의 차이가 없지만. multipart로 묶여진 Content들이 Content-Type 헤더를 갖고 있지 않을 때의 디폴트 타입이 text/plain이 아니라 message/rfc822 타입이라는 차이점이 있다.
4.4 multipart/parallel
multipart/parallel 타입은 multipart/mixed 타입과 똑같은 타입이지만, multipart로 묶여진 Content들 간의 순서에 별 의미가 없다는 것에 차이점이 있다.
4.5 multipart/report
multipart/report 타입은 메일 서버가 메일 에러 보고를 할 때 사용하는 타입이다. 만약 어떤 사용자가 메일을 보냈는데, 받는 사람의 메일 주소가 틀려서(없는 메일 주소일 때 등등) 메일을 보낼 수가 없다면 메일 서버는 메일을 보낸 사용자에게 메일을 보낼 수 없다는 에러 보고 메일을 보내게 된다. 이 때 보내는 에러 보고 메일의 형식은 RFC 1892에서 정의되고 있다. 에러 보고 메일은 2개의 꼭 필요한 Content와 그 외의 부가적인 Content를 multipart로 묶어 구성한다. 첫 번째 Content(꼭 필요함)는 에러 원인에 대한 메시지를 담고 있다. 이 메시지는 사람이 쉽게 읽을 수 있어야 한다. 첫 번째 Content가 multipart/alternative로 구성될 수도 있다. 두 번째 Content(꼭 필요함)는 컴퓨터(메일 처리 프로그램)가 알아보기 쉬운 에러 원인에 대한 메시지이다. 컴퓨터가 쉽게 파싱할 수 있어야 하며 파싱된 정보를 통해 컴퓨터가 에러 원인을 정확히 알 수 있어야 한다. 그래야 자동 에러 처리가 가능하니까. 리스트 5는 multipart/report 의 예이다.
리스트 5 : multipart/report 의 예
Date: Thu, 7 Sep 2000 18:18:35 +0900
From: Mail Delivery Subsystem <MAILER-DAEMON@netsarang.com>
Message-Id: <200009070918.SAB04287@netsarang.com>
To: hanyoul@netsarang.com
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="SAB04287.968318315/netsarang.com"
Content-Transfer-Encoding: 8bit
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
--SAB04287.968318315/netsarang.com
The original message was received at Thu, 7 Sep 2000 18:18:35 +0900
from hanyoul@localhost
----- The following addresses had permanent fatal errors -----
badman@badhost.com
----- Transcript of session follows -----
550 badman@badhost.com... User unknown
554 /dead.letter... cannot open /dead.letter: Permission denied
--SAB04287.968318315/netsarang.com
Content-Type: message/delivery-status
Reporting-MTA: dns; netsarang.com
Arrival-Date: Thu, 7 Sep 2000 18:18:35 +0900
Final-Recipient: RFC822; badman@badhost.com
Action: failed
Status: 5.1.1
Last-Attempt-Date: Thu, 7 Sep 2000 18:18:35 +0900
--SAB04287.968318315/netsarang.com--
4.6 message/external-body
만약 어떤 사람이 20M나 되는 MP3 파일을 메일로 보내려고 한다고 치자. 그런데 받는 사람의 메일 계정 용량이 10M밖에 안된다면 메일을 받지 못할 것이다. 또 메일 계정 용량이 충분하더라도 20M가 되는 메일을 받는 것을 꺼리는 사람도 있을 것이다. 이럴 때 사용할 수 있는 것이 바로 message/external-body 타입이다. message/external-body 타입은 Content를 직접 메일 안에 첨부하는 것이 아니라, 외부에 두고 메일 안에는 그 Content에 대한 정보(URL, 파일명등)만을 포함하는 MIME 타입이다. message/external-body 타입은 RFC 2046에 정의되어 있다. message/external-body 타입은 Content-Type의 부가정보로 access-type이라는 정보를 꼭 포함하고 있어야 한다. access-type은 외부에 있는 Content를 어떠한 방식에 의해 접근해야 할 지를 알려준다. 그 종류로는 FTP, ANON-FTP, TFTP, LOCAL-FILE, MAIL-SERVER등이 있다. 또한 Content-Type의 부가정보로 expiration이라는 정보를 포함할 수도 있다. expiration 정보는 외부에 있는 Content가 유효한 시간을 가리키는 정보이다. 또 size라는 정보 역시 포함될 수 있는데, size는 외부에 있는 Content의 크기를 가리킨다. 각각의 access-type은 그 종류에 따라 각각의 부가 정보를 가질 수 있다. 이에 대한 간단히 살펴보자.
FTP와 TFTP는 name, site 그리고 directory라는 정보를 가지고 있다. name은 Content 파일의 이름을 가리킨다. site는 Content가 있는 곳의 도메인 이름이다. 이 이름은 완전한 도메인 이름의 형식을 가져야 한다. directory는 Content가 있는 디렉토리를 가리킨다. access-type이 FTP(TFTP)라면 site가 가리키는 컴퓨터에 FTP(TFTP) 프로토콜을 이용해 접속하여 directory 아래에 있는 name 파일을 가져오면 된다.
ANON-FTP는 FTP와 유사하지만 ftp로 접근할 수 있는 유저ID와 패스워드를 묻지 않을 경우에 사용한다. 이 때는 anonymous ID와 사용자의 메일주소를 사용하여 접속한다.
LOCAL-FILE은 site라는 부가정보가 가리키는 컴퓨터 안에 name이라는 이름으로 저장되어 있는 Content를 가리킨다.
MAIL-SERVER는 외부에 있는 Content를 메일 서버를 통해 얻어올 수 있다는 것을 말해준다. MAIL-SERVER access-type은 server라는 부가정보와 subject라는 부가정보를 가지고 있다. server는 Content를 얻을 수 있는 메일 서버를 가리킨다. subject라는 부가정보를 가지고 있다라면 server가 가리키는 메일 서버에게 subject가 가리키는 제목으로 메일을 보낼 때 우리가 원하던 Content를 얻을 수 있음을 말해준다.
리스트 6은 message/external-body 타입의 예이다.
리스트 6 : message/external-body 타입의 예
From: hanyoul@netsarang.com
To: anyone@somehost.com
Subject: External-body Type
MIME-Version: 1.0
Content-type: message/external-body;
access-type=local-file;
name="/u/nsb/Me.jpeg"
Content-type: image/jpeg
Content-ID: <id42@guppylake.bellcore.com>
Content-Transfer-Encoding: binary
THIS IS NOT REALLY THE BODY!
4.7 message/partial
message/partial 타입은 용량이 큰 메일을 보낼 때 유용하게 사용할 수 있다. message/partial 타입은 용량이 큰 메일을 여러개로 쪼개어 보내는 방법을 사용할 때 쓰이는 MIME 타입이다. 메일 클라이언트가 이렇게 보내진 메일을 다시 하나로 합치게 하면 원래의 메일이 된다.
message/partial 타입은 id, number, total이라는 부가정보를 가지고 있다. id는 쪼개진 Content를 가리키는 문자열이다. 다시 말해서 id가 같은 메일을 모아야 다시 합칠 수 있다는 말이다. number는 이 메일이 쪼개진 Content의 조각 가운데 몇번째 조각인지를 가리키는 것이고, total은 모두 몇 개의 조각으로 쪼개졌는가를 가리키는 것이다. 리스트 7이 message/partial 타입의 예이다.
[첫번째 메일]
From: hanyoul@netsarang.com
To: anyone@somehost.com
Subject: 쪼개진 메시지 (part 1 of 2)
Message-ID: <id1@host.com>
MIME-Version: 1.0
Content-type: message/partial;
id="ABC@host.com";
number=1;
total=2
Message-ID: <anotherid@foo.com>
Subject: GIF 그림
MIME-Version: 1.0
Content-type: image/gif
Content-transfer-encoding: base64
... GIF 이미지 파일의 첫 번째 조각(총 2개) ....
[두번째 메일]
From: hanyoul@netsarang.com
To: anyone@somehost.com
Subject: 쪼개진 메시지 (part 2 of 2)
MIME-Version: 1.0
Message-ID: <id2@host.com>
Content-type: message/partial;
id="ABC@host.com";
number=2;
total=2
... GIF 이미지 파일의 두 번째 조각(총 2개) ....
[메일 클라이언트에 의해 합쳐진 메일]
From: hanyoul@netsarang.com
To: anyone@somehost.com
Subject: GIF 이미지
Message-ID: <anotherid@foo.com>
MIME-Version: 1.0
Content-type: image/gif
Content-transfer-encoding: base64
... GIF 이미지 파일의 첫 번째 조각(총 2개) ....
... GIF 이미지 파일의 두 번째 조각(총 2개) ....
리스트 7의 역상부분을 살펴보면 첫 번째 쪼개진 메시지의 Content-Type, Content-Transfer-Encoding, Subject들이 합쳐진 메일의 것과 같음을 알 수 있다. message/partial 타입은 원래 메일의 Content-Type, Content-Transfer-Encoding, Subject들을 첫 번째 조개진 메시지에 포함시키고 있음을 알 수 있다.
지금까지 우리는 MIME에 대한 기본적인 내용을 모두 살펴보았다. 이제 이 내용을 가지고 실제로 MIME Parser를 구현하는 일만이 남았다. 앞에서도 이야기했듯이 마지막 호인 다음 호에서는 실제 MIME Parser를 구현해볼 것이다.
5. MIME 참고 자료
RFC 2045 - "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"
RFC 2046 - "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types"
RFC 2047 - "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text"
RFC 2048 - "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures"
RFC 2049 - "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples"
MIME Message를 이해하자.
이번 호에서는 지난 호에서 살펴보았던 내용들을 토대로 MIME Message를 어떻게 구성하는지, 또 구성된 MIME Message에서 어떻게 우리가 원하는 데이터를 끄집어내는지에 대해서 자세히 살펴볼 계획이다. 이번 호가 끝나면 MIME Parser를 구현하기 위한 기본 내용을 모두 숙지하게 된다. 이를 기초로 하여 마지막 호인 다음 호에서는 실제로 MIME Parser를 구현해 보도록 하자.
(주)넷사랑컴퓨터 조한열
hanyoul@netsarang.com
1. 제일 간단한 MIME Message
리스트 1의 메일 메시지는 MIME Message이다. 왜? 이유는 단 한가지이다. MIME-Version이란 MIME 헤더가 RFC822 헤더(From, To, Subject)와 함께 들어있기 때문이다.
메일 메시지 헤더에 MIME-Version이란 헤더가 들어있다면 메일 메시지는 MIME Message로 해석이 되어야 한다. 그렇다면 리스트 1의 메일 메시지를 MIME Message로 간주하고 해석해보도록 하자.
리스트 1 : MIME Message 예
From: hanyoul@netsarang.com
To: anyone@somehost.com
Subject: The Simplest MIME Message
MIME-Version: 1.0
Hi! Everybody.
Thank you
MIME Message를 해석하기 위해서 없어서는 안될 MIME 헤더는 2가지가 있다. 바로 Content-Type과 Content-Transfer-Encoding이다. 지난 호를 유심히 살펴본 독자라면 이미 이 두가지 헤더의 의미를 알겠지만 다시 한 번 이 두가지 헤더에 대한 의미를 간략히 살펴보자.
Content-Type 헤더는 MIME Message가 포함하고 있는 내용 혹은 데이터(Content)가 어떤 타입인지를 가리키는 헤더이다. Plain text이나 GIF image등의 타입이 여기에 기술되어 있다. 만약 Content-Type이 텍스트라면 Content-Type에는 부가 정보로 Character Set에 대한 정보가 기술되어 있다.
Content-Transfer-Encoding 헤더는 8bit 데이터를 어떤 방식을 통해 7bit 데이터로 변환시켰는지를 알려주는 헤더이다. Content-Transfer-Encoding 헤더의 값으로는 7bit, 8bit, binary, quoted-printable, base64등이 있다. 위의 값 중에서 7bit, 8bit, binary는 그 어떤 변환도 하지 않음을 말해준다. 그냥 메일을 보낸 시점의 데이터가 변환되지 않고 그대로 메일 메시지에 실려왔음을 말해주는 것이다.
이제 리스트 1의 MIME Message를 다시 한 번 살펴보자. 그러나, MIME-Version이라는 헤더만 있을 뿐, Content-Type이나 Content-Transfer-Encoding 헤더는 보이지 않는다. 그렇다면 MIME Message를 어떻게 해석할 수 있을까. 정답은 간단하다. Content-Type 헤더가 없을 때에는 Content-Type이 plain text라고 간주하면 된다. 또한 이 Content의 character set은 US-ASCII(일반 영자)라고 생각하면 된다. Content-Transfer-Encoding 헤더가 없을 때에는 기본적으로 7bit 인코딩으로 간주된다. 따라서 위의 간단한 MIME Message는 리스트 2와 동일하다.
리스트 2 : 7bit로 간주된 MIME Message
From: hanyoul@netsarang.com
To: anyone@somehost.com
Subject: The Simplest MIME Message
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7but
Hi! Everybody.
Thank you
그러므로 리스트 1의 MIME Message의 Content는 데이터변환이 없는(7bit 인코딩이니까) 영문으로 된 텍스트(text/plian; charset=us-ascii)라는 것을 알 수 있다.
이번엔 조금 복잡한 MIME Message를 살펴보자. 역상 부분이 MIME 헤더라는 것은 이제 너무도 쉽게 알 수 있을 것이다. 리스트 3의 MIME Message에 대한 설명을 보기 전에 독자 여러분이 스스로 MIME Message를 MIME 헤더 정보(역상부분)를 이용하여 해석해 보는 것도 좋을 것이다.
리스트 3 : MIME Message
From: hanyoul@netsarang.com
To: anyone@somehost.com
Subject: JPEG image file
MIME-Version: 1.0
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
/9j/4AAQSkZJRgABAgAAZABkAAD//gASQWRvYmUgSW1hZ2VSZWFkef/sABFEdWNreQABAAQAAAAu
AAD/7gAOQWRvYmUAZMAAAAAB/9sAhAAKBwcHBwcKBwcKDgkICQ4QDAoKDBATDw8QDw8TEg4QDw8Q
DhISFRYXFhUSHR0fHx0dKSkpKSkvLy8vLy8vLy8vAQoJCQoLCg0LCw0QDQ4NEBQODg4OFBcPDxEP
DxcdFRISEhIVHRocFxcXHBogIB0dICAoKCYoKC8vLy8vLy8vLy//wAARCADUARsDASIAAhEBAxEB
/8QAqgAAAgIDAQAAAAAAAAAAAAAAAAECBQMEBgcBAAEFAQEAAAAAAAAAAAAAAAABAgQFBgMHEAAB
AwIFAgQEBAQEBQQDAAABABECIQMxQRIEBVFhcYEiBpGhMhOxwUIU0eFSI/DxFQdicpIzFoKiwlNU
NRcRAAEDAgQCBwYEBQUAAAAAAAEAAgMRBCExQRJxBVFhgZEiMhOhwdFCUhSxckMV8OHxMwZigsIj
JP/aAAwDAQACEQMRAD8A5wFsii2SLhBpV1mk0Q8pae5KwCQne1ROoHA5KEcitjzED0W447x71ebM
kgMa5KW6
아마도 지난 호의 내용과 앞에서 설명한 내용을 잘 이해했다면 무리없이 해석할 수 있을 것이다. 아직 이해가 되지 않는 독자들을 위해 리스트 3의 MIME Message를 해석해보자.
'MIME-Version: 1.0' 이라는 헤더를 통해 우리는 위의 메일을 MIME Message라고 간주해야 한다. Content-Type이 image/jpeg이므로 MIME Message가 포함하고 있는 Content는 jpeg형식의 image 파일이다. image 파일은 binary 파일이므로 8bit 데이터이다. 8bit 데이터를 7bit 데이터로 변환하여 메일을 전송하는 것이 안전하기 때문에(이유는 1회에서 설명하였다.) 7bit로 인코딩했다는 것을 예측할 수 있다. 그러므로 Content-Transfer-Encoding이 무엇인지를 살펴봐야 한다. Content-Transfer-Encoding 헤더는 인코딩 방식이 base64 방식임을 말해주고 있다. 즉, MIME Message가 포함하고 있는 Content는 base64 방식으로 인코딩되어 있기 때문에, 원래의 데이터를 얻기 위해서는 base64 방식에 의거하여 인코딩되 Content를 디코딩해야 한다.
/9j/4AAQSkZ........ 로 시작되는 부분이 바로 Content인데, 이것이 base64 방식으로 인코딩 된 것이다. 이를 지난 호에서 설명한 base64 방식에 의거하여 디코딩하면 원래의 jpeg image를 얻을 수 있는 것이다.
2. Multipart MIME Message
만약에 메일을 통해 위에서 보았던 jpeg image를 보내면서 이 image 파일에 대한 설명을 같은 메일에 함께 보내려면 어떻게 하면 될까? 이럴 때는 Multipart MIME Message를 만들면 된다. 처음 들어보는 말이라고 해서 너무 어렵게 생각할 필요는 없다. Multipart MIME Message란 두 개 이상의 Content를 하나의 MIME Message에 붙여넣는 것이다. 이 때, 각 Content 마다 MIME 헤더를 붙이고 난 후 각 Content를 구분할 수 있는 경계선을 표시해 넣는 것이다. 말로 설명하면 더욱 어려워질 것 같으니, 직접 Multipart MIME Message를 살펴보도록 하자.
리스트 4의 Multipart MIME Message는 image 파일과 image 파일에 대한 설명을 담은 text를 함께 묶어 구성한 것이다.
리스트 4 : Multipart MIME Message
From: hanyoul@netsarang.com
To: anyone@somehost.com
Subject: JPEG image file
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="MIME-boundary1--------DC128F5642CA"
--MIME-boundary1--------DC128F5642CA
Content-Type: text/plain; charset=us-ascii
Hi!
I will send you a good image. This image is my favorite picture.
--MIME-boundary1--------DC128F5642CA
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
/9j/4AAQSkZJRgABAgAAZABkAAD//gASQWRvYmUgSW1hZ2VSZWFkef/sABFEdWNreQABAAQAAAAu
AAD/7gAOQWRvYmUAZMAAAAAB/9sAhAAKBwcHBwcKBwcKDgkICQ4QDAoKDBATDw8QDw8TEg4QDw8Q
DhISFRYXFhUSHR0fHx0dKSkpKSkvLy8vLy8vLy8vAQoJCQoLCg0LCw0QDQ4NEBQODg4OFBcPDxEP
DxcdFRISEhIVHRocFxcXHBogIB0dICAoKCYoKC8vLy8vLy8vLy//wAARCADUARsDASIAAhEBAxEB
/8QAqgAAAgIDAQAAAAAAAAAAAAAAAAECBQMEBgcBAAEFAQEAAAAAAAAAAAAAAAABAgQFBgMHEAAB
AwIFAgQEBAQEBQQDAAABABECIQMxQRIEBVFhcYEiBpGhMhOxwUIU0eFSI/DxFQdicpIzFoKiwlNU
NRcRAAEDAgQCBwYEBQUAAAAAAAEAAgMRBCExQRJxBVFhgZEiMhOhwdFCUhSxckMV8OHxMwZigsIj
JP/aAAwDAQACEQMRAD8A5wFsii2SLhBpV1mk0Q8pae5KwCQne1ROoHA5KEcitjzED0W447x71ebM
kgMa5KW6
--MIME-boundary1--------DC128F5642CA--
먼저 Content-Type을 살펴보면 multipart/mixed라는 것을 알 수 있다. 주 카테고리인 multipart는 위의 메일이 Multipart MIME Message 포맷이라는 것을 나타내고 있다. 또한 multipart의 부 카테고리는 Content 간의 관계를 나타내는 것이 일반적인데, 여기서는 부 카테고리가 mixed임을 알 수 있다. mixed는 multipart로 묶여진 Content들이 서로 독립적이지만 Content들의 순서에 의미가 있을 때 사용한다.
Content-Type이 multipart일 때는 Content-Type의 부가정보인 boundary가 무엇보다도 중요하다. Content-Type의 부가정보인 boundary는 Content들을 구분하는 구분경계를 표시하는 것이기 때문이다. boundary 정보가 있어야만 올바르게 Multipart MIME Message를 원래의 데이터들로 파싱하는 것이 가능하다는 것은 당연할 것이다.
boundary는 메일 메시지에 등장하지 않을 만한 문자열로 만들어야 한다. 만약 Content 내용에 boundary에 해당하는 문자열이 들어있어 엉뚱하게 파싱이 되는 것을 막기 위해서이다.
실제로 boundary 문자열을 이용하여 경계를 표시할 때는 하이픈(-)을 덧붙이는 것이 규칙이다. boundary 문자열 앞에 하이픈(-) 두 개를 덧붙여 Content의 경계를 표시한다. 리스트 4의 메일에서 boundary가 "MIME-boundary1--------DC128F5642CA"(따옴표는 제외)이므로 경계를 표시하기 위한 실제 문자열은
"--MIME-boundary1--------DC128F5642CA"(따옴표 제외)
가 된다. 어떤 줄의 첫 시작이 "--MIME-boundary1--------DC128F5642CA"라면 그 다음 줄부터는 새로운 Content이다.
boundary 문자열의 앞뿐만 아니라 뒤에도 하이픈(-)이 붙은 문자열이 존재하는 데, 이는 Multipart MIME Message의 끝을 나타낸다. boundary 문자열의 앞뒤에 하이픈(-)이 두 개씩 붙은 문자열은 그 문자열의 뒤로는 Content가 더 이상 없다는 것을 뜻한다. 위의 메일에서 맨 마지막 줄을 보면 "--MIME-boundary1--------DC128F5642CA--"(따옴표 제외)가 있는데, boundary 문자열인 "MIME-boundary1--------DC128F5642CA"(따옴표 제외)의 앞뒤에 하이픈(-)이 두 개씩 붙어있음을 알 수 있고, 이 문자열을 끝으로 Multipart MIME Message가 끝난다는 것을 알 수 있다.
--boundary 문자열과 그 다음에 나오는 --boundary 문자열(혹은 --boundary-- 문자열) 사이에 있는 것이 하나의 MIME Content라는 것은 수차에 걸쳐 이야기했다. 이 MIME Content는 처음에 살펴본 간단한 MIME Message와 마찬가지로 헤더와 데이터로 구성되어 있다. MIME Content의 헤더가 데이터의 정보를 나타내고 있다는 것을 이제는 쉽게 알 수 있을 것이다. 헤더와 데이터는 하나의 빈 줄로 구분된다. 헤더가 나오고 한 줄이 비어지고 그 다음에 데이터가 나오는 것이다. 위의 메일에는 모두 두 개의 Content가 있는데, 첫 번째 Content의 Content-Type은 text/plain이면 두 번째 Content-Type은 image/jpeg라는 것을 알 수 있다. 또한 위의 첫 번째 Content의 헤더에 Content-Transfer-Encoding이 없으므로 디폴트 값인 7bit 인코딩이 되었음을 알 수 있고, 두 번째 Content는 base64 방식으로 인코딩 되어있음을 알 수 있다.
그런데 여기에서 의문이 생길 수가 있다. 어디가 Content의 마지막인가 이다. 무슨 말인지 의아하겠지만 다음을 한 번 살펴보자. 아래는 위 Multipart MIME Message의 한 부분이다. 첫 번째 Content가 끝나고 두 번째 Content를 구분하기 위한 --boundary 문자열이 나타나는 곳이다.
Hi!
I will send you a good image. This image is my favorite picture.
[CRLF]
--MIME-boundary1--------DC128F5642CA
Content-Type: image/jpeg
역상부분으로 나타낸 [CRLF](줄바꿈)표시는 과연 첫 번째 Content에 포함되는가, 아닌가 하는 질문에 대답해보자.
text 기반의 데이터라면 그것이 그렇게 중요하지 않을 수도 있지만 만약 binary 데이터라면 [CRLF]가 데이터에 포함되는지 포함되지 않는지는 무척 중요한 문제이다.
MIME을 설명하고 있는 RFC문서에서는 --boundary 문자열(혹은 --boundary-- 문자열) 앞에 붙어있는 [CRLF] 문자를 --boundary 문자열(혹은 --boundary-- 문자열)에 속한 것으로 정의하고 있다. 즉 Content 데이터에 포함되지 않는다는 것이다.
3. Multipart Content를 내부에 포함한 Multipart MIME Message
Multipart MIME Message 안에 들어있는 Content가 또 다시 Multipart MIME Message가 될 수도 있다. 계속 재귀적으로 multipart가 중첩된 구조를 가질 수 있다는 것이다.
From: hanyoul@netsarang.com
To: anyone@somehost.com
Subject: JPEG image file
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="MIME-boundary1--------DC128F5642CA"
--MIME-boundary1--------DC128F5642CA
Content-Type: text/plain; charset=us-ascii
This message include another multipart message.
--MIME-boundary1--------DC128F5642CA
Content-Type: multipart/mixed;
boundary="MIME-boundary2--------DC128F5642CA"
--MIME-boundary2--------DC128F5642CA
Content-Type: text/plain; charset=us-ascii
Hi!
I will send you a good image. This image is my favorite picture.
--MIME-boundary2--------DC128F5642CA
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
/9j/4AAQSkZJRgABAgAAZABkAAD//gASQWRvYmUgSW1hZ2VSZWFkef/sABFEdWNreQABAAQAAAAu
AAD/7gAOQWRvYmUAZMAAAAAB/9sAhAAKBwcHBwcKBwcKDgkICQ4QDAoKDBATDw8QDw8TEg4QDw8Q
DhISFRYXFhUSHR0fHx0dKSkpKSkvLy8vLy8vLy8vAQoJCQoLCg0LCw0QDQ4NEBQODg4OFBcPDxEP
DxcdFRISEhIVHRocFxcXHBogIB0dICAoKCYoKC8vLy8vLy8vLy//wAARCADUARsDASIAAhEBAxEB
/8QAqgAAAgIDAQAAAAAAAAAAAAAAAAECBQMEBgcBAAEFAQEAAAAAAAAAAAAAAAABAgQFBgMHEAAB
AwIFAgQEBAQEBQQDAAABABECIQMxQRIEBVFhcYEiBpGhMhOxwUIU0eFSI/DxFQdicpIzFoKiwlNU
NRcRAAEDAgQCBwYEBQUAAAAAAAEAAgMRBCExQRJxBVFhgZEiMhOhwdFCUhSxckMV8OHxMwZigsIj
JP/aAAwDAQACEQMRAD8A5wFsii2SLhBpV1mk0Q8pae5KwCQne1ROoHA5KEcitjzED0W447x71ebM
kgMa5KW6
--MIME-boundary2--------DC128F5642CA--
--MIME-boundary1--------DC128F5642CA--
위에서 역상부분이 중첩된 Multipart MIME Message이다. 중첩된 Multipart MIME Message는 새로운 boundary 문자열(MIME-boundary2--------DC128F5642CA)을 가지고 있다. 그러므로 "--MIME-boundary2--------DC128F5642CA--"(따옴표 제외)로 끝날 때까지가 하나의 Content인 것이다.
이런 중첩된 구조는 multipart뿐만이 아니라 multipart를 포함한 메일 메시지 자체(message/rfc822)를 포함할 수도 있다. 이는 메일 서버가 서버 관리자에게 에러를 보고할 때 에러가 난 메일 자체를 포함시킨 에러 보고 메일(Error Reporting Mail)을 보낼 때 자주 사용된다.
4. 눈여겨봐야할 MIME 타입
4.1 multipart/mixed
기본적인 multipart 타입이 바로 multipart/mixed이다. multipart/mixed 타입은 multipart로 묶여진 Content들이 서로 독립적임을 나타낸다. 하지만 Content들이 들어있는 순서에 의미가 있다. 화일을 첨부하여 메일을 보낼 때 주로 사용되는데, 이 때 처음에 들어있는 Content가 메일 본문이고 다음부터 나오는 Content들이 첨부화일이다. 메일 본문과 첨부화일의 순서처럼 순서에 의미가 있는 경우에 사용하는 것이 multipart/mixed 타입이다. 또한 부 카테고리가 어떤 타입인지를 모르는 multipart 타입은 모두 multipart/mixed로 해석한다.
4.2 multipart/alternative
multipart/alternative 타입은 multipart로 묶여진 Content들이 서로 같은 내용을 담고 있지만 표현 형식이 다를 때 사용한다. 예를 들어 메일을 보낼 때, html 형식으로 보내고 싶지만 상대방 메일 클라이언트가 html을 지원하지 않는 프로그램일지도 모른다는 걱정이 들 때 multipart/alternative 타입을 사용한다. 아래의 메일을 보자.
From: hanyoul@netsarang.com
To: anyone@somehost.com
Subject: alternative multipart example
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary=boundary1234
--boundary1234
Content-Type: text/plain; charset=us-ascii
...여기에는 plain text 형식의 메시지가 들어간다...
--boundary42
Content-Type: text/html
...여기에는 위의 메시지와 같은 내용을 가지고 있지만, 형식이 html인 메시지가 들어간다...
--boundary42--
위의 예에서 살펴보면 같은 내용의 메시지를 text/plain 형식과 text/html 형식으로 만들어서 함께 보냈음을 알 수 있다. 이 때, 받는 사람의 메일 클라이언트가 html을 지원하면 두 번째 Content를 보여주고, html을 지원하지 않는다면 첫 번째 Content를 보여주게 된다. 여기서 하나 더 알아두어야 할 것은 multipart/alternative 타입에서도 Content들 간의 순서가 중요하다는 것이다. 보내는 사람이 더 선호하는 형식을 뒤에 놓게 되어 있다. 위의 예에서 보내는 사람이 text/html 형식을 text/plain 보다 뒤에 배치했기 때문에 받는 사람은 보낸느 사람이 html 형식으로 보기를 바란다는 것을 알 수 있는 것이다. 그러므로 multipart/alternative 타입으로 묶여진 모든 Content들의 형식을 받는 메일 프로그램이 모두 다 알고 있을 때에는 맨 마지막 Content를 보여주면 되는 것이다.
4.3 multipart/digest
multipart/digest 타입은 multipart/mixed 타입과 거의 차이가 없지만. multipart로 묶여진 Content들이 Content-Type 헤더를 갖고 있지 않을 때의 디폴트 타입이 text/plain이 아니라 message/rfc822 타입이라는 차이점이 있다.
4.4 multipart/parallel
multipart/parallel 타입은 multipart/mixed 타입과 똑같은 타입이지만, multipart로 묶여진 Content들 간의 순서에 별 의미가 없다는 것에 차이점이 있다.
4.5 multipart/report
multipart/report 타입은 메일 서버가 메일 에러 보고를 할 때 사용하는 타입이다. 만약 어떤 사용자가 메일을 보냈는데, 받는 사람의 메일 주소가 틀려서(없는 메일 주소일 때 등등) 메일을 보낼 수가 없다면 메일 서버는 메일을 보낸 사용자에게 메일을 보낼 수 없다는 에러 보고 메일을 보내게 된다. 이 때 보내는 에러 보고 메일의 형식은 RFC 1892에서 정의되고 있다. 에러 보고 메일은 2개의 꼭 필요한 Content와 그 외의 부가적인 Content를 multipart로 묶어 구성한다. 첫 번째 Content(꼭 필요함)는 에러 원인에 대한 메시지를 담고 있다. 이 메시지는 사람이 쉽게 읽을 수 있어야 한다. 첫 번째 Content가 multipart/alternative로 구성될 수도 있다. 두 번째 Content(꼭 필요함)는 컴퓨터(메일 처리 프로그램)가 알아보기 쉬운 에러 원인에 대한 메시지이다. 컴퓨터가 쉽게 파싱할 수 있어야 하며 파싱된 정보를 통해 컴퓨터가 에러 원인을 정확히 알 수 있어야 한다. 그래야 자동 에러 처리가 가능하니까. 리스트 5는 multipart/report 의 예이다.
리스트 5 : multipart/report 의 예
Date: Thu, 7 Sep 2000 18:18:35 +0900
From: Mail Delivery Subsystem <MAILER-DAEMON@netsarang.com>
Message-Id: <200009070918.SAB04287@netsarang.com>
To: hanyoul@netsarang.com
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="SAB04287.968318315/netsarang.com"
Content-Transfer-Encoding: 8bit
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
--SAB04287.968318315/netsarang.com
The original message was received at Thu, 7 Sep 2000 18:18:35 +0900
from hanyoul@localhost
----- The following addresses had permanent fatal errors -----
badman@badhost.com
----- Transcript of session follows -----
550 badman@badhost.com... User unknown
554 /dead.letter... cannot open /dead.letter: Permission denied
--SAB04287.968318315/netsarang.com
Content-Type: message/delivery-status
Reporting-MTA: dns; netsarang.com
Arrival-Date: Thu, 7 Sep 2000 18:18:35 +0900
Final-Recipient: RFC822; badman@badhost.com
Action: failed
Status: 5.1.1
Last-Attempt-Date: Thu, 7 Sep 2000 18:18:35 +0900
--SAB04287.968318315/netsarang.com--
4.6 message/external-body
만약 어떤 사람이 20M나 되는 MP3 파일을 메일로 보내려고 한다고 치자. 그런데 받는 사람의 메일 계정 용량이 10M밖에 안된다면 메일을 받지 못할 것이다. 또 메일 계정 용량이 충분하더라도 20M가 되는 메일을 받는 것을 꺼리는 사람도 있을 것이다. 이럴 때 사용할 수 있는 것이 바로 message/external-body 타입이다. message/external-body 타입은 Content를 직접 메일 안에 첨부하는 것이 아니라, 외부에 두고 메일 안에는 그 Content에 대한 정보(URL, 파일명등)만을 포함하는 MIME 타입이다. message/external-body 타입은 RFC 2046에 정의되어 있다. message/external-body 타입은 Content-Type의 부가정보로 access-type이라는 정보를 꼭 포함하고 있어야 한다. access-type은 외부에 있는 Content를 어떠한 방식에 의해 접근해야 할 지를 알려준다. 그 종류로는 FTP, ANON-FTP, TFTP, LOCAL-FILE, MAIL-SERVER등이 있다. 또한 Content-Type의 부가정보로 expiration이라는 정보를 포함할 수도 있다. expiration 정보는 외부에 있는 Content가 유효한 시간을 가리키는 정보이다. 또 size라는 정보 역시 포함될 수 있는데, size는 외부에 있는 Content의 크기를 가리킨다. 각각의 access-type은 그 종류에 따라 각각의 부가 정보를 가질 수 있다. 이에 대한 간단히 살펴보자.
FTP와 TFTP는 name, site 그리고 directory라는 정보를 가지고 있다. name은 Content 파일의 이름을 가리킨다. site는 Content가 있는 곳의 도메인 이름이다. 이 이름은 완전한 도메인 이름의 형식을 가져야 한다. directory는 Content가 있는 디렉토리를 가리킨다. access-type이 FTP(TFTP)라면 site가 가리키는 컴퓨터에 FTP(TFTP) 프로토콜을 이용해 접속하여 directory 아래에 있는 name 파일을 가져오면 된다.
ANON-FTP는 FTP와 유사하지만 ftp로 접근할 수 있는 유저ID와 패스워드를 묻지 않을 경우에 사용한다. 이 때는 anonymous ID와 사용자의 메일주소를 사용하여 접속한다.
LOCAL-FILE은 site라는 부가정보가 가리키는 컴퓨터 안에 name이라는 이름으로 저장되어 있는 Content를 가리킨다.
MAIL-SERVER는 외부에 있는 Content를 메일 서버를 통해 얻어올 수 있다는 것을 말해준다. MAIL-SERVER access-type은 server라는 부가정보와 subject라는 부가정보를 가지고 있다. server는 Content를 얻을 수 있는 메일 서버를 가리킨다. subject라는 부가정보를 가지고 있다라면 server가 가리키는 메일 서버에게 subject가 가리키는 제목으로 메일을 보낼 때 우리가 원하던 Content를 얻을 수 있음을 말해준다.
리스트 6은 message/external-body 타입의 예이다.
리스트 6 : message/external-body 타입의 예
From: hanyoul@netsarang.com
To: anyone@somehost.com
Subject: External-body Type
MIME-Version: 1.0
Content-type: message/external-body;
access-type=local-file;
name="/u/nsb/Me.jpeg"
Content-type: image/jpeg
Content-ID: <id42@guppylake.bellcore.com>
Content-Transfer-Encoding: binary
THIS IS NOT REALLY THE BODY!
4.7 message/partial
message/partial 타입은 용량이 큰 메일을 보낼 때 유용하게 사용할 수 있다. message/partial 타입은 용량이 큰 메일을 여러개로 쪼개어 보내는 방법을 사용할 때 쓰이는 MIME 타입이다. 메일 클라이언트가 이렇게 보내진 메일을 다시 하나로 합치게 하면 원래의 메일이 된다.
message/partial 타입은 id, number, total이라는 부가정보를 가지고 있다. id는 쪼개진 Content를 가리키는 문자열이다. 다시 말해서 id가 같은 메일을 모아야 다시 합칠 수 있다는 말이다. number는 이 메일이 쪼개진 Content의 조각 가운데 몇번째 조각인지를 가리키는 것이고, total은 모두 몇 개의 조각으로 쪼개졌는가를 가리키는 것이다. 리스트 7이 message/partial 타입의 예이다.
[첫번째 메일]
From: hanyoul@netsarang.com
To: anyone@somehost.com
Subject: 쪼개진 메시지 (part 1 of 2)
Message-ID: <id1@host.com>
MIME-Version: 1.0
Content-type: message/partial;
id="ABC@host.com";
number=1;
total=2
Message-ID: <anotherid@foo.com>
Subject: GIF 그림
MIME-Version: 1.0
Content-type: image/gif
Content-transfer-encoding: base64
... GIF 이미지 파일의 첫 번째 조각(총 2개) ....
[두번째 메일]
From: hanyoul@netsarang.com
To: anyone@somehost.com
Subject: 쪼개진 메시지 (part 2 of 2)
MIME-Version: 1.0
Message-ID: <id2@host.com>
Content-type: message/partial;
id="ABC@host.com";
number=2;
total=2
... GIF 이미지 파일의 두 번째 조각(총 2개) ....
[메일 클라이언트에 의해 합쳐진 메일]
From: hanyoul@netsarang.com
To: anyone@somehost.com
Subject: GIF 이미지
Message-ID: <anotherid@foo.com>
MIME-Version: 1.0
Content-type: image/gif
Content-transfer-encoding: base64
... GIF 이미지 파일의 첫 번째 조각(총 2개) ....
... GIF 이미지 파일의 두 번째 조각(총 2개) ....
리스트 7의 역상부분을 살펴보면 첫 번째 쪼개진 메시지의 Content-Type, Content-Transfer-Encoding, Subject들이 합쳐진 메일의 것과 같음을 알 수 있다. message/partial 타입은 원래 메일의 Content-Type, Content-Transfer-Encoding, Subject들을 첫 번째 조개진 메시지에 포함시키고 있음을 알 수 있다.
지금까지 우리는 MIME에 대한 기본적인 내용을 모두 살펴보았다. 이제 이 내용을 가지고 실제로 MIME Parser를 구현하는 일만이 남았다. 앞에서도 이야기했듯이 마지막 호인 다음 호에서는 실제 MIME Parser를 구현해볼 것이다.
5. MIME 참고 자료
RFC 2045 - "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"
RFC 2046 - "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types"
RFC 2047 - "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text"
RFC 2048 - "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures"
RFC 2049 - "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples"
