[펌] MIME (Multipurpose Internet Mail Extensions)

목차~

 

1. 전자우편 약사(略史)

2. MIME 개관

3. 개체(Entities)-MIME의 구성

4. 내용형식(Content Types)

5. 전송부호화(Transfer Encoding) 형식

6. MIME 구현의 예

7. S/MIME(RFC 2311, S/MIME 버전2 메시지 명세, 98.3)

..more

>접기

1. 전자우편 약사(略史)

컴퓨터의 출현을 통한 값싸고 빠른 네트웍상의 의사소통 수단으로 전자우편(e-mail)은 폭발적으로 성장하였다. 전자우편은 전체 내용을 보내는데 그다지 많은 바이트를 차지하지 않으며, 게다가 전자우편의 전송은 곧바로 할 필요가 없기에 시스템은 적절한 시간에 전송함으로써 네트웍의 부하를 줄이며 일괄적으로 메시지를 전송할 수 있다.

인터넷상에서 X.400이나 SMTP와 같은 전자우편의 표준은 아스키형의 텍스트 메시지를 전송할 수 있었다. 그러나, 이러한 시스템에서는 비영문자나 비로마자로 구성된 메시지를 사용할 수 없었다. 또한 다양한 폰트를 사용하였거나, 여러 텍스트 스타일로 만든 메시지나, 정지화상(이미지), 소리, 기타 다중매체의 전송은 불가능하였다.

UUENCODE(Unixt to Unix Encoding)/UUDECODE와 같은 표준은 기존의 전자우편 시스템에서 실행파일이나 그림과 같은 아스키 형태가 아닌 이진 파일을 아스키형으로 전송할 수 있지만, 이 방법은 일반적이지 못하고, 이를 사용하려면 이용자는 유닉스와 관련된 약간의 전문지식이 필요하다.

이러한 문제를 해결하기 위해 RFC 1521에 의해 다목적용 인터넷 전자우편 확장(MIME; Multipurpose Internet Mail Extensions) 표준이 제안되었다. MIME 표준을 사용하면 현재 메일시스템에 다양한 문자로 구성된 파일이나, 그림, 이진파일, 소리, 동영상(video)을 사용할 수 있다.

 

2. MIME 개관

RFC 822(ARPA 인터넷 텍스트 메시지의 형식 표준, 82.08.13)에 기술된 전자우편 표준의 한계-7비트의 아스키 메시지를 작성하도록 규정-를 극복하기 위해 1991년 보렌스타인(Borenstein)과 프리드(Freed)가 RFC 1521에서 전자우편의 새로운 형태인 MIME을 제안하였다.

RFC 822에 따르면, 전자우편은 여러 가지 머리말(header)- To, From, Date 등-을 가질 수 있다. MIME은 이러한 머리말에 메시지의 내용형식(Content-Type)과 내용전송부호화 형식(Content-Transfer-Encoding) 등을 추가하여 기술하고 있다. 이 방법을 이용하면, 정형화된(formatted) 텍스트, 비영문자로 구성된 텍스트, 정지화상, 소리, 동화상, 그림 등을 포함하고 있는 텍스트와 같은 상이한 형태의 객체로 구성된 메시지를 전송할 수 있다.

MIME 표준을 사용하여 파일을 보내고 받는 전자우편 프로그램('MIME Compliant'라 칭한다)은 비아스키 파일을 보낼 때 아스키 형태로 부호화시키고, 받을 때 원래의 형태로 변환시켜 재현시키거나(display) 내려받기(download)할 수 있도록 하고 있다.

내용형식은 전자우편 판독기(reader)가 몸말(body)을 어떤 방법으로 해석해야 할지를 알려준다. 전송-부호화 형식에서는 비정형의 이진 데이터와 현재 사용중인 메일서버에서 요구하는 제한된 길이의 평범한 아스키 메시지간의 변환을 기술하고 있다. MIME 표준은 일반적으로 웹 서버에서 웹 클라이언트로 보내는 파일을 식별하기 위해 사용된다.

MIME은 93년 9월에 RFC 1521과 RFC 1522라는 두 개의 상정안(draft 표준)으로 IETF(Internet Engineering Task Force)에 의해 승인되었다. 현재 MIME은 MIME 메시지의 구조를 기술하는데 사용되는 여러 몸말을 명시하고 있는 ▶RFC 2045(인터넷 메시지 몸말의 형식)와 MIME 매체 형식의 구조를 다루는 ▶RFC 2046(매체 형식), 인터넷 전자우편 머리말 부분에서 비아스키형 데이터를 허용하고 있는 RFC 822의 확장에 대해 기술하고 있는 ▶RFC 2047(비아스키 텍스트에 대한 메시지 머리말 확장), MIME을 사용하기 위해 다양한, IANA(Internet Assigned Numbers Authority)의 등록 절차를 명시하고 있는 ▶RFC 2048(등록 절차), 마지막으로 MIME 메시지 형식의 실례와 감사문, 관련 서지사항, 부록과 MIME 형식과의 일치를 위한 기준을 기술하고 있는 ▶RFC 2049(MIME 형식과의 일치를 위한 기준과 사례) 등 크게 다섯 개의 RFC로 나누어져 있다. RFC 2045, 2047은 부분적으로 갱신되어 RFC2231(MIME 변수값(parameter value)과 부호화된 단어의 확장, 97.11.)이 마련되어져 있다.

 

3. 개체(Entities)-MIME의 구성

개체는 MIME 메시지를 구성하는 기본 블록을 말한다. 하나의 개체는 하나의 머리말과 몸말로 구성되는데, 머리말은 메시지의 내용형식과 전송부호화 형식을 결정한다. 전송데이터에 관한 정보를 표시하기 위해 MIME에서는 여러 가지 머리말 부분(header field)를 가진다. MIME의 머리말 부분을 살펴보면 아래와 같다(내용형식과 내용전송부호화 머리말 부분은 따로 다룬다).

① MIME 버전 머리말 부분:

서로 다른 MIME UA(user agent)로 하여금 송수신된 메시지를 적절히 해석할 수 있도록 MIME의 버전을 기술한다. 현재 사용되고 있는 버전은 1.0이다.

② 내용형식 머리말 부분:

전송데이터의 형식과 하위형식을 표시한다. 내용형식으로는 rich text, 정지화상, 소리 등과 같은 기본적인 형식이거나 복합적인 형식(multipart)으로 7개가 지정되어 있으며, 각 내용형식은 하위형식을 가진다. 전자우편에서는 text/plain을 주로 사용한다.

③ (내용)전송부호화 머리말 부분:

전송 데이터의 몸말을 부호화하는 방법을 명시한다. 전송부호화는 비아스키 데이터가 메일 시스템을 통하여 아스키 형태로 전송되도록 한다. 한 예로, 어떤 개체가 내용형식이 image/gif으로 지정되었으면, 몸말에서 정지화상 파일은 아스키 형태로 변환된 이진 파일 형태로 구성된다.

④ 내용 ID 머리말 부분 / 내용기술 머리말 부분:

선택적인 부분이다.

⑤ 부가적인 MIME 머리말 부분:

차후에 첨가될 수 있는 머리말 부분을 위한 것으로 아래의 구문과 같이 "Content-"로 시작해야 한다.

MIME-extension-field :=<Any RFC 822 header field which begins with the string "Content-">

 

4. 내용형식(Content Types)

내용형식은 몸말이 어떻게 해석되는지, 이용자에게 텍스트나, 그림, 실행 파일 등 어떤 식으로 표현되는지를 지정하고 있다. 각각의 내용형식은 매체형식/하위형식(media type/subtype)의 쌍으로 이루어지며, MIME 표준이 발전할수록 새로운 매체형식과 그에 따른 하위형식을 추가할 수 있는 확장성을 제공하고 있다. 그래서, MIME 형식으로 공식화되지 않은 것은 IANA에 공식적인 등록을 거칠 때까지 해당 매체형식에서 하위형식으로 "x-하위형식"으로 지정하면 된다. 예를 들면, "audio/x-aiff"는 AIFF의 소리 정보 포맷으로 아직 MIME 형식으로 등록되지 않았음을 나타낸다. IANA에 등록이 되면 "audio/aiff"로 지정될 수 있다.

RFC 2046(매체형식)에서는 <표 1>과 같은 7개의 상위 매체형식을 지정하고 있다(등록된 최신 정보를 보려면 도움글에서 Media Types를 연결하는 사이트를 참조하라).

<표 1> MIME에서의 매체형식/하위형식의 예

매체형식	하위형식	설 명
text	plain	기본값으로 지정.
	richtext
	enriched	아스키형의 문자, 문단을 마크업 태그를 사용, 간단히 변화를 준 형태.
	:
image	jpeg	기본값으로 jpeg, gif가 설정
	gif
	:
audio	basic	아직까진 일치된 포맷 없음.
	:
video	mpeg	기본값으로 mpeg가 설정
	:
application	postscript	포스트스크립 파일을 표시함
	octet-stream	2진 파일을 표시함.
	:
multipart :서로 다른 형식의 데이터를 갖는 몸말을 하나의 메시지로 조합하여 전송	mixed	몸말 부분이 각각 독립적인 형식으로 일정한 순서를 지닐 때.
	alternative	같은 정보에 대한 다른 버전을 각각의 몸말로 두는 경우(예: text/plain, text/enriched). 수신측 시스템에서 가장 최선의 형식을 취함.
	digest	여러 메시지의 묶음(collections of messages)를 전송할 때.
	parallel	몸말의 여러 내용을 동시에 보여 주려 할 때.
	:
message :메시지를 캡슐화할 경우	rfc822	rfc822 형식의 메시지로 캡슐화.
	partial	전송할 메시지를 여러 개로 쪼개어 전송할 때. 수신 측 UA에서 재결합하고 이 형식으로 보낼 때는 파라미터로 메일id, 분할된 것 중 몇 번째인지를 나타내는 number, 총 몇 개로 분할되었는지의 total이 추가된다.
	external-body	실제적인 몸말의 데이터는 제외하고 단지 참조할 때 사용하는데, 외부데이터에 접근할 수 있는 방법을 파라미터를 통해 기술해 주고 있다.
	:

넷스케이프의 메뉴 가운데 편집의 환경설정에 들어가면 <그림 1>과 같이 각각의 응용프로그램이 MIME을 지원하기 위해 어떤 식으로 지정되어 있는지 알 수 있다.

5. 전송부호화(Transfer Encoding) 형식

X.400, SMTP를 사용하는 메일시스템은 텍스트를 7비트의 아스키형으로 제한하고 있다. MIME의 전송부호화 형식은 이진 데이터를 대부분의 메일 게이트웨이를 통해 전송될 수 있는 포맷(아스키형)으로 전환시켜, 클라이언트 측에서 원래의 형태로 복제하는 알고리듬이다. 유닉스 계열에서 많이 사용하는 UUENCODE 프로그램도 비아스키형 데이터를 아스키형으로 전환시키지만, 기술적인 제약과 상호운용성의 문제를 지니고 있기 때문에 MIME이 메시지 전송에 있어 UUENCODE를 대체할 것으로 보인다.

전송부호화 머리말 부분에서 지정하고 있는 전송부호화 형식은 <표 2>와 같다.

<표 2> MIME에서의 전송부호화 형식

부호화 방법	설 명
7bit	기본값. 아스키 문자만 사용한 텍스트 메시지에 사용. 메시지가 이미 7비트로 되어 있어야 한다(실제 부호화는 일어나지 않는다). 내용은 한 줄에 1000자 이하가 되어야 한다.
8bit	비아스키 문자를 포함한 메시지에 사용. 전송 데이터가 8비트임을 나타내고 실제 부호화는 일어나지 않는다.
binary	메시지에 이진 데이터를 포함시키는데 사용. 길이에 제약이 없으며, 실제 데이터에 대한 부호화는 일어나지 않는다.
base64	24비트(3바이트)를 입력받아서, 이를 6비트씩 쪼개 4바이트씩 묶어 아스키 형태로 출력하는 부호화 방법. 데이터의 크기는 원래보다 33% 커진다.
quoted-printable	포스트스크립 파일처럼 아스키 텍스트에 약간의 비아스키 문자가 첨가된 텍스트를 부호화하는 방법으로 16진수가 오는 형태로 나타남.
x-token	사용자가 정의한 코드를 사용할 수 있도록 한 것. "x-"뒤에 코드명을 넣어 사용.

6. MIME 구현의 예

<그림 2>는 넷스케이프 상에서 메일과 함께 딸려 온 파일이 있을 때의 한 예이다. 내용형식과 전송부호화 방식이 제시되어 있다. <표 3>에서는 pine에서 송수신된 메시지를 보여 주고 있는데, 한글 파일과 그림 파일이 몸말에 첨가되어 있는 상태이다. 여기에서는 전송부호화 형식을 알 수는 없는데, more나 cat 명령을 사용하여 보면 <표 4>와 같이 머리말 부분에 들어가는 MIME의 머리말 요소(MIME 버전, id, 내용형식, 전송부호화형식, 내용기술 등)이 제시되어 있다.

<표 3> pine에서 송수신된 메시지를 볼 때

PINE 3.91 MESSAGE TEXT Folder: INBOX Message 1 of 1 Date: Sat, 06 Jun 1998 15:37:32 +0900 From: 김태우 <drf13385@bubble.yonsei.ac.kr> To: redheart@bubble.yonsei.ac.kr Subject: test Parts/attachments: 1 Shown 1 lines Text 2 117 KB Application/X-UNKNOWN-CONTENT-TYPE-HWPFILE 3 1 MB Image ---------------------------------------- mime content type and content transfer encoding testing message! [Part 2, Application/X-UNKNOWN-CONTENT-TYPE-HWPFILE 117KB] [Can not display this part. Use the "V" command to save in a file] [Part 3, Image/X-MS-BMP 1MB] [Can not display this part. Use the "V" command to save in a file] ? Help M Main Menu P PrevMsg - PrevPage D Delete R Reply O OTHER CMDS V ViewAttch N NextMsg Spc NextPage U Undelete F Forward

<표 4>pine에서 saved-messages나 sent-mail를 볼 때

[bubble]mail 13 > more saved-messages From redheart@bubble Tue Jun 6 15:34:00 1998 Status: RO X-Status: Received: from bubble.yonsei.ac.kr ([165.132.84.173]) by bubble.yonsei.ac.kr (8.8.8H1/8.8.8) with ESMTP id PAA27973 for <redheart@bubble.yonsei.ac.kr>; Sat, 6 Jun 1998 15:34:08 +0900 (KST) Message-ID: <3578E3AC.E8C3F373@bubble.yonsei.ac.kr> Date: Sat, 06 Jun 1998 15:37:32 +0900 From: "김태우" <drf13385@bubble.yonsei.ac.kr> X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: redheart@bubble.yonsei.ac.kr Subject: test Content-Type: multipart/mixed; boundary="------------57494B7B9793891C52454B2C" Content-Length: 1131340 This is a multi-part message in MIME format. --------------57494B7B9793891C52454B2C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit mime content type and content transfer encoding testing message! --------------57494B7B9793891C52454B2C Content-Type: application/x-unknown-content-type-hwpfile; name="Mime.hwp" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Mime.hwp" SFdQIERvY3VtZW50IEZpbGUgVjMuMDAgGgECAwQFMwAAAAMAN1IiOoQDCAcIBwgHhAOEAw AAAAAAAAQAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkATUlN RShN

7. S/MIME(RFC 2311, S/MIME 버전2 메시지 명세, 98.3)

전자우편에 보안과 관련된 기술이 없다면 봉함이 없는 우편엽서를 보내는 것과 같아 누구나 그 내용을 볼 수 있게 될 것이다. S/MIME(Secure MIME)는 전자메시지의 보안성에 관련된 명세(specification)로, 1995년 여러 소프트웨어 회사가 모여 전자우편의 위조(forgery)와 방해(interception)에 관련된 문제를 해결하기 위하여 만들었는데, 1996년에 전자우편의 보안에 대한 업계의 표준으로 자리잡았다. S/MIME는 전자우편의 표준 양식으로 자리잡은 MIME에 암호화에서 표준적이 자리를 확보하고 있는 PKCS(Pulbic Key Cryptography Standards)를 결합하여 보안을 유지할 수 있도록 하였다. MIME 형식의 전자우편에서는 몸말의 서식 구조가 정해져 있어 특수한 형태의 글이나 그림, 소리, 그밖에 규정된 서식 구조에 따라 여러 가지를 넣을 수 있게 만들어졌지만, MIME 자체로서는 어떠한 보안 장치가 마련되어 있지 않았다. S/MIME의 목적은 기존의 MIME의 메시지에 PKCS #7의 전자서명이나 암호화같은 보안 장치를 제공하는 것이다.

S/MIME를 지원하는 전자우편 프로그램을 사용하면, 프라이버시와 데이터의 무결성을 유지하며, 인증을 보장받을 수 있다. S/MIME이 짧은 시간에 부상하게 된 이유로는 여러 업체가 공동으로 참여하여 만들어 상호운용성을 높였으며, 국가적 보안 사항으로 묶여 있던 암호화 기술 가운데 간단한 종류는 해외로 유통시킬 수 있게 되어 국제적인 표준으로 상호운용할 수 있으며, 사용자 입장에서 쉽게 보안을 걸 수 있도록 하였기 때문이다.

앞으로 S/MIME는 전자우편의 영역에서 뿐 아니라 EDI나 전자상거래 등에도 두루 쓰여질 전망이다.

< 도 움 글 >

<MIME 관련 자료>

멀티미디어 전자메일 Mime. <http://physics.hallym.ac.kr/resource/ibook/Mime.html> (98.06.01)

질문 131. S/MIME은 무엇인가?(What is S/MIME?). <http://www.hongik.com/~netusers/FAQen/crypto/faq131.html> (98.05.30)

한글 전자우편 시스템 개요. <http://asadal.cs.pusan.ac.kr/step2000/step96/step96.mailintro.html> (98.05.29)

Duss, Steve. S/MIME: Anatomy of a Secure E-mail Standard. <http://www.ema.org/html/pubs/mmv2n4/s-mime.htm> (98.05.28)

FAQ: X.400. 1997. <http://www.alvestrand.no/domen/x400/faq-mhsnews.html> (98.06.01)

Hood, Earl. 1998. MIME(Multipurpose Internet Mail Extentions). <http://www.oac.uci.edu/indiv/ehood/MIME/MIME.html> (98.05.28)

Media Types. <http://www.isi.edu/in-notes/iana/assignments/media-types/media-types> (98.05.28)

MIME Index. <http://www.mathcs.carleton.edu/students/pollatsd/MIME/index.html> (98.05.28)

S/MIME Central. <http://www.rsa.com/smime/> (98.05.28)

<통신 관련 용어 찾기 도움틀>

전자신문 용어 찾기: <http://www.etnews.co.kr/etnews/word>

ILC Glossary of Internet Terms(Internet Literacy Consultants): <http://www.matisse.net/files/glossary.html>

Glossary of Internet Terms: <http://whatis.com>

<RFC 모은데(아카이브)>

RFC Archive: <http://sunsite.auc.dk/RFC/>

 

 

 

참조 : http://dewey.yonsei.ac.kr/network/khg.htm