MIME
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
MIME(Multipurpose Internet Mail Extensions)은 인터넷을 통해 전송되는 이메일의 형식을 정의하는 표준이다. MIME은 원래 앤드류 메시징 시스템을 위해 개발되었으며, MIME 헤더, Content-Type, Content-Disposition, Content-Transfer-Encoding, Encoded-Word, multipart 메시지 등 다양한 구성 요소로 이루어져 있다. MIME은 이메일뿐만 아니라 HTTP와 같은 인터넷 프로토콜에서도 사용되며, IANA에서 MIME 타입을 관리한다.
더 읽어볼만한 페이지
- 표현 계층 프로토콜 - XML
XML은 태그 중첩 방식 구문을 사용하는 범용 언어로서, 인터넷을 통한 구조화된 문서 및 데이터 공유를 용이하게 하고, 웰 폼 및 유효 XML 문서 개념을 통해 구문 정확성을 검사하며, 데이터 교환 등 다양한 분야에서 널리 사용된다. - 표현 계층 프로토콜 - 애플 파일링 프로토콜
애플 파일링 프로토콜(AFP)은 애플 기기 간 파일 공유를 위해 개발된 프로토콜로, AppleTalk에서 TCP/IP를 지원하며 유니코드, POSIX 권한, Time Machine 등을 지원한다. - 인터넷 표준 - DNSSEC
DNSSEC는 DNS의 보안 취약점을 개선하기 위해 도메인 정보에 디지털 서명을 추가하여 응답 레코드의 무결성을 보장하고 DNS 위장 공격을 막는 기술로, RRSIG, DNSKEY 등 다양한 리소스 레코드 유형을 사용하여 인증 체인을 구성하며 공개 키 암호 방식을 활용한다. - 인터넷 표준 - IPv6
IPv6는 IPv4 주소 고갈 문제를 해결하고자 개발된 차세대 인터넷 프로토콜로, 128비트 주소 체계를 통해 사실상 무한대에 가까운 IP 주소를 제공하며, 주소 자동 설정, 패킷 처리 효율성 향상, 보안 기능 강화 등의 특징을 갖는다.
| MIME | |
|---|---|
| MIME (Multipurpose Internet Mail Extensions) | |
| 종류 | 인터넷 표준 |
| 설명 | 다양한 형식의 파일 및 데이터를 전자 메일 메시지에 첨부하고 전송할 수 있도록 하는 인터넷 표준 |
| 개발 | IETF |
| 최초 발표 | 1993년 |
| 최신 버전 | RFC 2045 (1996년 11월) |
| 표준 | RFC 2046 RFC 2047 RFC 4288 RFC 4289 RFC 2048 RFC 2049 RFC 1521 RFC 1522 |
2. 역사
MIME은 카네기 멜론 대학교(CMU)에서 개발된 앤드류 프로젝트의 일부인 앤드류 메시징 시스템에서 유래되었으며, 앤드류 전용 데이터 형식에 대한 플랫폼 간 대안으로 개발되었다.[1]
3. MIME 헤더
3. 1. MIME-Version
이 헤더는 해당 메시지가 MIME 형식임을 나타낸다. 현재 사용되는 값은 "1.0"이므로 아래와 같이 사용할 수 있다.[2]
```
MIME-Version: 1.0
```
이 헤더 필드의 존재는 메시지가 MIME 형식임을 나타낸다. 값은 일반적으로 "1.0"이다.[2] MIME 공동 제작자인 나다니엘 보렌스타인에 따르면, 이 버전 번호는 후속 버전에서 MIME 프로토콜 변경을 허용하기 위해 도입되었다.[2] 그러나 보렌스타인은 이 기능의 구현을 방해하는 명세의 단점을 인정했다. "우리는 미래의 MIME 버전을 처리하는 방법을 적절하게 명시하지 못했습니다. ... 따라서 1.0을 알고 있는 것을 작성했다면, 2.0 또는 1.1을 만났을 때 어떻게 해야 할까요? 저는 그것이 분명하다고 생각했지만, 모든 사람이 다른 방식으로 구현했습니다. 그 결과 인터넷에서 2.0 또는 1.1을 정의하는 것은 거의 불가능할 것입니다."[2]
기존의 RFC 5322 (RFC 822, RFC 2822) 준수 메시지와의 구별, 또는 미래에 MIME이 확장되었을 때 버전을 구별하기 위한 헤더이다. 현재는 1.0만 규정되어 있다.[2]
3. 2. Content-Type
Content-Type 헤더는 메시지 내용의 미디어 유형을 나타내며, '타입'과 '서브타입'으로 구성된다. 예를 들어, `text/plain`에서 `text`는 타입, `plain`은 서브타입이다.
MIME은 `multipart` 타입을 사용하여 메시지가 트리 구조로 배열된 부분을 가질 수 있게 한다. 이 방식을 통해 다음과 같은 다양한 메시지 구조를 지원한다.
타입에는 `text`, `application`, `image`, `audio`, `video` 등이 있으며, 각 타입마다 미지의 서브타입 처리 방식이 규정되어 있다. 수신 측은 자신이 처리할 수 없는 서브타입이라도 최소한의 처리가 가능하도록, `text`는 `text/plain`, `application` 등은 `application/octet-stream`으로 취급한다. `multipart`의 경우, 알 수 없는 subtype은 `multipart/mixed`로 처리한다.
Content-type 헤더와 MIME 타입은 전자 우편을 위해 정의되었지만, HTTP, SIP와 같은 인터넷 프로토콜에서도 함께 사용되고 있다. MIME 타입 등록은 IANA에서 관리한다.
`text` 타입은 `charset` 인자를 가질 수 있으며, 이는 문자 인코딩을 지정한다. 예를 들어 `text/html; charset=UTF-8`은 HTML 텍스트를 UTF-8로 인코딩한 것이다.
3. 3. Content-Disposition
Content-Disposition 헤더 필드는 RFC 2183에 추가되어 메시지의 표현 방식을 지정한다. MIME 파트는 ''inline''과 ''attachment'' 속성을 가질 수 있다. ''inline'' content disposition은 메시지가 표시될 때 자동으로 표시되어야 함을 의미한다. ''attachment'' content disposition은 자동으로 표시되지 않으며 사용자가 열기 위해 어떤 형태의 조치를 취해야 한다.
''Content-Disposition'' 필드는 파일 이름, 생성 날짜, 수정 날짜를 지정하기 위한 매개변수도 제공한다. 이러한 정보는 첨부 파일을 저장하기 위해 리더의 메일 사용자 에이전트에서 사용할 수 있다. 파일 이름은 RFC 2231에 정의된 대로 인코딩될 수 있다.
다음은 RFC 2183에서 가져온 예시이다.
```
Content-Disposition: attachment; filename=genome.jpeg;
modification-date="Wed, 12 Feb 1997 16:29:51 -0500";
```
2010년 현재, 대다수의 이메일 클라이언트는 이 지침을 완전히 따르지 않고 있다.[3] 널리 사용되는 모질라 썬더버드 메일 클라이언트는 메시지의 ''content-disposition'' 필드를 무시하고 MIME 파트를 자동으로 표시하도록 선택하기 위해 독립적인 알고리즘을 사용한다.[3] 많은 메일 사용자 에이전트는 ''Content-Disposition'' 헤더 필드의 ''filename'' 매개변수 대신 ''content-type'' 헤더의 ''name'' 매개변수에 파일 이름을 보내기도 하는데, 이는 권장되지 않는 방식이다.[4]
HTTP에서, 응답 헤더 필드 ''Content-Disposition: attachment''는 일반적으로 클라이언트에게 응답 본문을 다운로드 가능한 파일로 제공하도록 하는 힌트로 사용된다. 웹 브라우저는 ''filename''이 기본 파일 이름을 제안하면서 사용자가 내용을 파일로 저장하도록 요청한다.
3. 4. Content-Transfer-Encoding
MIME(RFC 2045)은 바이너리 데이터를 ASCII 텍스트 형식으로 변환하는 여러 방법을 정의하며, `content-transfer-encoding` MIME 헤더를 통해 변환 방식을 지정한다.
8BITMIME 확장을 사용하여 SMTP 전송을 통해 임의의 바이너리 데이터를 전송하도록 명시적으로 설계된 인코딩은 정의되어 있지 않다. 따라서 BINARYMIME이 지원되지 않는 경우, base64 또는 quoted-printable(관련된 비효율성 포함)이 여전히 유용할 수 있다. 이 제한은 MIME 첨부 파일이 있는 웹 서비스 또는 MTOM과 같은 다른 MIME 사용에는 적용되지 않는다.
4. Encoded-Word
RFC 2822에 따르면 메시지 헤더와 그 값은 항상 ASCII 문자를 사용해야 한다. ASCII가 아닌 헤더 값은 MIME의 '''encoded-word''' 문법(RFC 2047)에 따라 인코딩해야 한다. 이 문법은 원본 문자 인코딩("문자셋")과 원본 데이터를 ASCII 문자로 변환하는 데 사용한 인코딩 방식을 포함한다.
encoded-word의 형식은 다음과 같다.
`=?`문자셋`?`인코딩 방식`?`인코드된 데이터`?=`
- 문자셋은 보통 utf-8을 사용한다. 하지만 IANA에 등록된 어떤 문자셋도 사용 가능하다.
- 인코딩 방식은 quoted-printable 인코딩 방식과 비슷한 Q-encoding 방식을 나타내는 "
Q"나 base64 인코딩을 나타내는 "B" 중 하나를 사용할 수 있다. - 인코드된 데이터는 인코딩 방식에 의해 변환된 데이터이다.
- ''인코딩된 단어''는 ''charset'', ''encoding'', ''encoded text'' 및 구분 기호를 포함하여 75자를 넘을 수 없다. 75자의 ''인코딩된 단어''에 맞지 않는 더 많은 텍스트를 인코딩하려는 경우 여러 ''인코딩된 단어''(CRLF SPACE로 구분)를 사용할 수 있다.
RFC 2047에 따르면, encoded-word는 공백 문자(white space)를 포함해서는 안 된다. 따라서 ASCII 코드로 20h(iso-8859-1에서의 스페이스)인 문자는 인코딩을 거쳐야 한다. ASCII 20h(20h가 공백이 아닐지라도)인 문자는 보통 "_" 문자(ASCII 5Fh)로 변환한다. 공백을 "=20"으로 인코딩한 것보다 이 방식이 인코드된 데이터의 가독성을 높여준다.물음표("?")와 등호("=")의 아스키 코드는 인코딩된 단어를 구분하는 데 사용되므로 직접적으로 표현될 수 없다.
예를 들어, "Subject: ¡Hola, señor!"를 인코딩하면 다음과 같다.
`Subject: =?utf-8?Q?=C2=A1Hola,_se=C3=B1or!?=`
encoded-word 형식은 헤더 이름에는 사용할 수 없다. 헤더 이름은 항상 US-ASCII로 표현해야 한다.
"
""로 둘러싸인 안에서 이러한 부호화된 단어를 해석할 수 없다고 규정하고 있다. 따라서 ""=?ISO-2022-JP?B?GyRCRnxLXDhsGyhC?=""는 "=?ISO-2022-JP?B?GyRCRnxLXDhsGyhC?="로 해석해야 하며, 이를 "일본어"로 해석하는 것은 규격 위반이다. 그러나 Microsoft Outlook Express 등 일부 MUA가 이러한 잘못된 부호화를 구현하여 널리 사용되었기 때문에, 이를 규격 위반으로 알고 있는 MUA 제작자도 이에 대응할 수밖에 없게 되었다.5. Multipart 메시지
MIME multipart 메시지는 "Content-type:" 헤더에 `boundary` 파라미터를 포함한다. 이 `boundary`는 각 메시지 파트를 구분하는 역할을 하며, 메시지의 시작과 끝부분에도 나타난다.
```text
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=frontier
This is a message with multiple parts in MIME format.
- -frontier
Content-Type: text/plain
This is the body of the message.
- -frontier
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==
- -frontier--
```
각 파트는 `Content-`로 시작하는 자신만의 헤더와 본문을 갖는다. 그리고 multipart 메시지는 중첩 가능하다. 각 파트는 자신만의 문자셋과 인코딩 방식(Content-Transfer-Encoding)을 파트 헤더에서 정의하고 있다. Multipart 메시지에는 아래와 같은 종류가 있다.
첫 번째 `boundary` 전에 나오는 내용은 MIME을 지원하지 않는 클라이언트를 위해 제공된다. MIME 호환 클라이언트는 이 내용을 무시한다. Boundary를 선택하는 것은 전자 우편을 전송하는 클라이언트의 몫이다. 보통 무작위의 문자를 선택함으로써 메시지의 본문과 충돌을 피한다.
MIME 멀티파트 메시지는 헤더 필드 `Content-Type:`에 경계를 포함한다. 이 경계는 어떤 파트에서도 발생하지 않아야 하며, 파트 사이와 메시지 본문의 시작과 끝에 배치된다.
각 파트는 자체 내용 헤더(0개 이상의 `Content-` 헤더 필드)와 본문으로 구성된다. 멀티파트 내용은 중첩될 수 있다. 멀티파트 유형의 `Content-Transfer-Encoding`은 여러 수준의 디코딩으로 인해 발생할 수 있는 복잡성을 피하기 위해 항상 "7bit", "8bit" 또는 "binary"여야 한다. 멀티파트 블록 전체에는 문자 집합이 없다. 파트 헤더의 비ASCII 문자는 인코딩된 단어 시스템으로 처리되며, 파트 본문은 내용 유형에 적절한 경우 문자 집합을 지정할 수 있다.
참고:
- 첫 번째 경계 앞에는 MIME 호환 클라이언트에서 무시되는 영역이 있다. 이 영역은 일반적으로 오래된 비MIME 클라이언트 사용자에게 메시지를 넣는 데 사용된다.
- 본문 텍스트와 충돌하지 않는 경계 문자열을 선택하는 것은 메일 클라이언트를 보내는 것이다. 일반적으로 긴 임의 문자열을 삽입하여 수행된다.
- 마지막 경계는 끝에 두 개의 하이픈이 있어야 한다.
5. 1. Multipart 하위 유형
MIME 표준은 메시지 부분의 특성과 상호 관계를 지정하는 다양한 멀티파트 메시지 하위 유형을 정의한다. 하위 유형은 전체 메시지의 `Content-Type` 헤더 필드에 지정된다. 예를 들어, digest 하위 유형을 사용하는 멀티파트 MIME 메시지는 `Content-Type`을 "multipart/digest"로 설정한다.RFC는 처음에는 mixed, digest, alternative 및 parallel의 네 가지 하위 유형을 정의했다. 최소한의 호환성을 갖춘 응용 프로그램은 mixed와 digest를 지원해야 하며, 다른 하위 유형은 선택 사항이다. 응용 프로그램은 인식할 수 없는 하위 유형을 "multipart/mixed"로 처리해야 한다. signed 및 form-data와 같은 추가 하위 유형은 이후 다른 RFC에서 별도로 정의되었다.
- Mixed
Multipart/mixed는 다른 "Content-type" 헤더를 갖는 파일을 전송하는 데 사용한다. 그림이나 쉽게 읽을 수 있는 파일을 전송할 때, 대부분의 전자 우편 클라이언트는 이를 직접 화면에 표시할 것이다. 그렇지 않을 경우 해당 데이터는 첨부 파일의 형태로 표시된다. "Content-disposition" 헤더는 첨부 파일의 이름을 표시하는 데 사용한다.[5]
- Digest
RFC 2049에 명시되어 있듯이 multipart/mixed와 multipart/digest는 최소한 지원해야 할 MIME 타입이다. mixed 파트의 기본 content-type은 text/plain이며, digest의 경우 message/rfc822이다. Multipart/digest는 하나 이상의 메시지를 포워딩 하기 위한 간편한 방법이다.[6] `multipart/digest`는 여러 개의 텍스트 메시지를 전송하는 간단한 방법이다. 각 부분의 기본 콘텐츠 유형은 "message/rfc822"이다.
- Alternative
`multipart/alternative` 메시지는 동일한 내용을 다른 형식으로 표현할 때 사용된다. 각각의 파트는 서로 다른 "Content-type" 헤더를 가지며, MIME을 지원하지 않는 클라이언트에서 처리를 쉽게 하고자 표현하기 쉬운 형식에서 복잡한 형식 순으로 메시지에 나타난다. 따라서 메일 클라이언트는 각 파트를 순서대로 검색하여 자신이 표현할 수 있는 마지막 파트를 선택하게 된다.[7] 일부 클라이언트는 이런 순서를 무시한 채 자신이 선호하는 형식을 표시하기도 한다. 일반적으로 오래된 클라이언트를 위해 `text/plain` 타입의 파트가 먼저 나오고 최신 클라이언트를 위해 `text/html` 타입의 파트가 나온다.
예전 스팸 방지 필터는 `text/html` 파트보다 파싱이 쉽다는 이유로 메시지의 `text/plain` 파트 만을 검사했다.[8] 스패머들은 이러한 점을 악용해 메시지의 `text/plain` 파트에는 평범한 내용을 넣고 대신 `text/html`에는 광고를 포함하였다. 이런 방식을 막기 위해 스팸 방지 소프트웨어는 `multipart/alternative` 메시지 중 각 파트가 매우 상이한 내용을 가질 경우 이를 스팸 메시지로 처리하는 식으로 해당 메시지를 걸러낸다.[8]
`multipart/alternative` 서브타입은 각 부분이 동일하거나 유사한 콘텐츠의 "대안" 버전이며, 각 버전은 "Content-Type" 헤더로 표시된 서로 다른 형식임을 나타낸다. 파트의 순서가 중요하며, RFC1341은 선호도 증가 순으로 본문 파트를 배치해야 한다고 명시하고 있다. 즉, 선호하는 형식이 마지막에 오도록 배치해야 한다.[7]
시스템은 처리할 수 있는 "최상의" 표현을 선택할 수 있는데, 일반적으로 시스템이 이해할 수 있는 마지막 파트가 되지만, 다른 요인도 영향을 미칠 수 있다.
클라이언트는 일반 텍스트 버전보다 충실도가 낮은 버전을 보내고 싶어하지 않으므로, 이 구조는 일반 텍스트 버전(있는 경우)을 먼저 배치한다. 이렇게 하면 multipart 메시지를 이해하지 못하는 클라이언트 사용자가 더 쉽게 사용할 수 있다.
가장 일반적으로 `multipart/alternative`은 두 부분, 즉 하나는 일반 텍스트(`text/plain`)이고 다른 하나는 HTML (`text/html`)로 구성된 이메일에 사용된다. 일반 텍스트 파트는 이전 버전과의 호환성을 제공하는 반면 HTML 파트는 서식 및 하이퍼링크 사용을 허용한다. 대부분의 이메일 클라이언트는 사용자가 HTML보다 일반 텍스트를 선호하도록 선택할 수 있는 옵션을 제공한다. 이는 애플리케이션이 메시지의 "최상의" 파트를 표시하는 방식을 지역 요인이 어떻게 영향을 미칠 수 있는지 보여주는 예이다.
메시지의 각 파트가 동일한 콘텐츠를 나타내도록 의도되었지만, 표준에서는 이를 강제할 것을 요구하지 않는다. 한때 스팸 방지 필터는 `text/plain` 파트가 `text/html` 파트보다 구문 분석하기 쉽기 때문에 메시지의 `text/plain` 파트만 검사했다.[8] 그러나 스패머는 결국 이를 악용하여 무해한 모습의 `text/plain` 파트와 `text/html` 파트의 광고가 있는 메시지를 만들었다. 스팸 방지 소프트웨어는 결국 이 트릭을 따라잡아 `multipart/alternative` 메시지에서 텍스트가 매우 다른 메시지에 대해 페널티를 부과했다.[8]
이 유형은 RFC 2046에 정의되어 있다.[9]
- Related
`multipart/related`는 상호 연관된 여러 개의 파트들로 구성된 메시지이다. 각각의 파트들은 root 타입을 중심으로 내부적으로 연결되며, 각 파트를 참조하기 위해서 일반적으로 파트의 content-ID를 사용한다. `Multipart/related`의 type 파라미터는 root 파트의 content-type을 지정하며 필수 파라미터이다. Start 파라미터는 root 파트의 content-ID를 지정하며 start 파라미터가 없을 경우에는 가장 먼저 나오는 파트가 root 파트가 된다.
`multipart/related`의 사용 예로 이미지가 포함된 HTML 문서를 들 수 있다. 이 경우 root 파트는 HTML 문서가 되며 HTML에 포함된 이미지들은 뒷따르는 파트로 구성하고 HTML 내부에서 이를 참조하는 식으로 표현할 수 있다. `multipart/related`는 각 메시지 부분이 전체 집합체의 구성 요소임을 나타내는 데 사용된다. 여러 상호 관련된 구성 요소로 구성된 복합 객체를 위한 것으로 구성 요소를 개별적으로 표시해서는 제대로 표시할 수 없다. 메시지는 다른 부분을 인라인으로 참조하는 루트 부분(기본적으로 첫 번째 부분)으로 구성되며, 이 부분은 다시 다른 부분을 참조할 수 있다. 메시지 부분은 일반적으로 ''Content-ID''로 참조된다. 참조 구문은 지정되지 않으며 대신 부분에서 사용되는 인코딩 또는 프로토콜에 의해 결정된다.
이 하위 유형의 일반적인 사용 사례 중 하나는 이미지를 포함한 웹 페이지를 단일 메시지로 전송하는 것이다. 루트 부분에는 HTML 문서가 포함되며, 후속 부분에 저장된 이미지를 참조하기 위해 이미지 태그를 사용한다.
이 유형은 RFC 2387에 정의되어 있다.
- Report
`multipart/report`는 메일 서버가 읽을 수 있도록 형식화된 데이터를 포함하는 메시지 유형이다. 이 유형은 `text/plain`(또는 다른 `content/type`으로 쉽게 읽을 수 있는 형식)과 메일 서버가 읽을 수 있도록 형식화된 데이터를 포함하는 `message/delivery-status`로 나뉜다.
이 유형은 RFC 6522에 정의되어 있다.
- Signed
`multipart/signed`는 메시지에 디지털 서명을 첨부하는 데 사용된다. 이는 본문 파트와 서명 파트, 정확히 두 개의 본문 파트로 구성된다. MIME 필드를 포함한 전체 본문 파트는 서명 파트를 생성하는 데 사용된다. `application/pgp-signature`(RFC 3156) 및 `application/pkcs7-signature`(S/MIME)와 같은 다양한 서명 유형이 가능하다.[10]
- Encrypted
`multipart/encrypted` 메시지는 암호화된 메시지이다. 암호화된 데이터와 해독 정보를 포함하는 두 부분으로 구성된다.[11]
첫 번째 부분은 `application/octet-stream` 형태의 두 번째 부분을 해독하는 데 필요한 제어 정보를 담고 있다. 서명된 메시지와 유사하게, 제어 부분을 위한 별도의 콘텐츠 유형으로 식별되는 다양한 구현 방식이 있다. 가장 일반적인 유형은 "application/pgp-encrypted" (RFC 3156)와 S/MIME에서 사용하는 "application/pkcs7-mime"이다.
- form-data
`multipart/form-data`는 폼을 통해 제출된 값을 표현하는 데 사용된다. 원래 HTML 4.0의 일부로 정의되었으며, HTTP를 통해 파일을 제출하는 데 가장 일반적으로 사용된다. 이는 RFC 2388을 대체하는 RFC 7578에 명시되어 있다.
- x-mixed-replace
multipart/x-mixed-replace 콘텐츠 유형은 서버 푸시와 HTTP를 통한 스트리밍을 에뮬레이션하기 위한 기술의 일부로 개발되었다.
혼합 대체 메시지의 모든 부분은 동일한 의미를 갖는다. 그러나 각 부분은 완전히 수신되는 즉시 이전 부분을 무효화하고 "대체"한다. 클라이언트는 전체 메시지가 완료될 때까지 기다리지 않고 개별 부분을 도착하는 즉시 처리해야 한다.
원래 넷스케이프에서 개발되었으며,[12] 현재 파이어폭스, 사파리, 오페라에서 지원된다. IP 카메라에서 MJPEG 스트림의 MIME 유형으로 일반적으로 사용된다.[13] 2013년까지는 Chrome에서 주요 리소스에 대해 지원되었으나 (이미지는 여전히 이 콘텐츠 유형을 사용하여 표시할 수 있음).[14]
- byterange
multipart/byterange는 단일 메시지의 비연속 바이트 범위를 나타내는 데 사용되며, HTTP에서 서버가 여러 바이트 범위를 반환할 때 사용되며 RFC 2616에 정의되어 있다.
5. 1. 1. Mixed
Multipart/mixed는 다른 "Content-type" 헤더를 갖는 파일을 전송하는 데 사용한다. 그림이나 쉽게 읽을 수 있는 파일을 전송할 때, 대부분의 전자 우편 클라이언트는 이를 직접 화면에 표시할 것이다. 그렇지 않을 경우 해당 데이터는 첨부 파일의 형태로 표시된다. "Content-disposition" 헤더는 첨부 파일의 이름을 표시하는 데 사용한다.[5]5. 1. 2. Digest
RFC 2049에 명시되어 있듯이 multipart/mixed와 multipart/digest는 최소한 지원해야 할 MIME 타입이다. mixed 파트의 기본 content-type은 text/plain이며, digest의 경우 message/rfc822이다. Multipart/digest는 하나 이상의 메시지를 포워딩 하기 위한 간편한 방법이다.[6] `multipart/digest`는 여러 개의 텍스트 메시지를 전송하는 간단한 방법이다. 각 부분의 기본 콘텐츠 유형은 "message/rfc822"이다.5. 1. 3. Alternative
`multipart/alternative` 메시지는 동일한 내용을 다른 형식으로 표현할 때 사용된다. 각각의 파트는 서로 다른 "Content-type" 헤더를 가지며, MIME을 지원하지 않는 클라이언트에서 처리를 쉽게 하고자 표현하기 쉬운 형식에서 복잡한 형식 순으로 메시지에 나타난다. 따라서 메일 클라이언트는 각 파트를 순서대로 검색하여 자신이 표현할 수 있는 마지막 파트를 선택하게 된다.[7] 일부 클라이언트는 이런 순서를 무시한 채 자신이 선호하는 형식을 표시하기도 한다. 일반적으로 오래된 클라이언트를 위해 `text/plain` 타입의 파트가 먼저 나오고 최신 클라이언트를 위해 `text/html` 타입의 파트가 나온다.예전 스팸 방지 필터는 `text/html` 파트보다 파싱이 쉽다는 이유로 메시지의 `text/plain` 파트 만을 검사했다.[8] 스패머들은 이러한 점을 악용해 메시지의 `text/plain` 파트에는 평범한 내용을 넣고 대신 `text/html`에는 광고를 포함하였다. 이런 방식을 막기 위해 스팸 방지 소프트웨어는 `multipart/alternative` 메시지 중 각 파트가 매우 상이한 내용을 가질 경우 이를 스팸 메시지로 처리하는 식으로 해당 메시지를 걸러낸다.[8]
`multipart/alternative` 서브타입은 각 부분이 동일하거나 유사한 콘텐츠의 "대안" 버전이며, 각 버전은 "Content-Type" 헤더로 표시된 서로 다른 형식임을 나타낸다. 파트의 순서가 중요하며, RFC1341은 선호도 증가 순으로 본문 파트를 배치해야 한다고 명시하고 있다. 즉, 선호하는 형식이 마지막에 오도록 배치해야 한다.[7]
시스템은 처리할 수 있는 "최상의" 표현을 선택할 수 있는데, 일반적으로 시스템이 이해할 수 있는 마지막 파트가 되지만, 다른 요인도 영향을 미칠 수 있다.
클라이언트는 일반 텍스트 버전보다 충실도가 낮은 버전을 보내고 싶어하지 않으므로, 이 구조는 일반 텍스트 버전(있는 경우)을 먼저 배치한다. 이렇게 하면 multipart 메시지를 이해하지 못하는 클라이언트 사용자가 더 쉽게 사용할 수 있다.
가장 일반적으로 `multipart/alternative`은 두 부분, 즉 하나는 일반 텍스트(`text/plain`)이고 다른 하나는 HTML (`text/html`)로 구성된 이메일에 사용된다. 일반 텍스트 파트는 이전 버전과의 호환성을 제공하는 반면 HTML 파트는 서식 및 하이퍼링크 사용을 허용한다. 대부분의 이메일 클라이언트는 사용자가 HTML보다 일반 텍스트를 선호하도록 선택할 수 있는 옵션을 제공한다. 이는 애플리케이션이 메시지의 "최상의" 파트를 표시하는 방식을 지역 요인이 어떻게 영향을 미칠 수 있는지 보여주는 예이다.
메시지의 각 파트가 동일한 콘텐츠를 나타내도록 의도되었지만, 표준에서는 이를 강제할 것을 요구하지 않는다. 한때 스팸 방지 필터는 `text/plain` 파트가 `text/html` 파트보다 구문 분석하기 쉽기 때문에 메시지의 `text/plain` 파트만 검사했다.[8] 그러나 스패머는 결국 이를 악용하여 무해한 모습의 `text/plain` 파트와 `text/html` 파트의 광고가 있는 메시지를 만들었다. 스팸 방지 소프트웨어는 결국 이 트릭을 따라잡아 `multipart/alternative` 메시지에서 텍스트가 매우 다른 메시지에 대해 페널티를 부과했다.[8]
이 유형은 RFC 2046에 정의되어 있다.[9]
5. 1. 4. Related
`multipart/related`는 상호 연관된 여러 개의 파트들로 구성된 메시지이다. 각각의 파트들은 root 타입을 중심으로 내부적으로 연결되며, 각 파트를 참조하기 위해서 일반적으로 파트의 content-ID를 사용한다. `Multipart/related`의 type 파라미터는 root 파트의 content-type을 지정하며 필수 파라미터이다. Start 파라미터는 root 파트의 content-ID를 지정하며 start 파라미터가 없을 경우에는 가장 먼저 나오는 파트가 root 파트가 된다.`multipart/related`의 사용 예로 이미지가 포함된 HTML 문서를 들 수 있다. 이 경우 root 파트는 HTML 문서가 되며 HTML에 포함된 이미지들은 뒷따르는 파트로 구성하고 HTML 내부에서 이를 참조하는 식으로 표현할 수 있다. `multipart/related`는 각 메시지 부분이 전체 집합체의 구성 요소임을 나타내는 데 사용된다. 여러 상호 관련된 구성 요소로 구성된 복합 객체를 위한 것으로 구성 요소를 개별적으로 표시해서는 제대로 표시할 수 없다. 메시지는 다른 부분을 인라인으로 참조하는 루트 부분(기본적으로 첫 번째 부분)으로 구성되며, 이 부분은 다시 다른 부분을 참조할 수 있다. 메시지 부분은 일반적으로 ''Content-ID''로 참조된다. 참조 구문은 지정되지 않으며 대신 부분에서 사용되는 인코딩 또는 프로토콜에 의해 결정된다.
이 하위 유형의 일반적인 사용 사례 중 하나는 이미지를 포함한 웹 페이지를 단일 메시지로 전송하는 것이다. 루트 부분에는 HTML 문서가 포함되며, 후속 부분에 저장된 이미지를 참조하기 위해 이미지 태그를 사용한다.
이 유형은 RFC 2387에 정의되어 있다.
5. 1. 5. Report
`multipart/report`는 메일 서버가 읽을 수 있도록 형식화된 데이터를 포함하는 메시지 유형이다. 이 유형은 `text/plain`(또는 다른 `content/type`으로 쉽게 읽을 수 있는 형식)과 메일 서버가 읽을 수 있도록 형식화된 데이터를 포함하는 `message/delivery-status`로 나뉜다.이 유형은 RFC 6522에 정의되어 있다.
5. 1. 6. Signed
`multipart/signed`는 메시지에 디지털 서명을 첨부하는 데 사용된다. 이는 본문 파트와 서명 파트, 정확히 두 개의 본문 파트로 구성된다. MIME 필드를 포함한 전체 본문 파트는 서명 파트를 생성하는 데 사용된다. `application/pgp-signature`(RFC 3156) 및 `application/pkcs7-signature`(S/MIME)와 같은 다양한 서명 유형이 가능하다.[10]5. 1. 7. Encrypted
`multipart/encrypted` 메시지는 암호화된 메시지이다. 암호화된 데이터와 해독 정보를 포함하는 두 부분으로 구성된다.[11]첫 번째 부분은 `application/octet-stream` 형태의 두 번째 부분을 해독하는 데 필요한 제어 정보를 담고 있다. 서명된 메시지와 유사하게, 제어 부분을 위한 별도의 콘텐츠 유형으로 식별되는 다양한 구현 방식이 있다. 가장 일반적인 유형은 "application/pgp-encrypted" (RFC 3156)와 S/MIME에서 사용하는 "application/pkcs7-mime"이다.
5. 1. 8. form-data
`multipart/form-data`는 폼을 통해 제출된 값을 표현하는 데 사용된다. 원래 HTML 4.0의 일부로 정의되었으며, HTTP를 통해 파일을 제출하는 데 가장 일반적으로 사용된다. 이는 RFC 2388을 대체하는 RFC 7578에 명시되어 있다.5. 1. 9. x-mixed-replace
multipart/x-mixed-replace 콘텐츠 유형은 서버 푸시와 HTTP를 통한 스트리밍을 에뮬레이션하기 위한 기술의 일부로 개발되었다.혼합 대체 메시지의 모든 부분은 동일한 의미를 갖는다. 그러나 각 부분은 완전히 수신되는 즉시 이전 부분을 무효화하고 "대체"한다. 클라이언트는 전체 메시지가 완료될 때까지 기다리지 않고 개별 부분을 도착하는 즉시 처리해야 한다.
원래 넷스케이프에서 개발되었으며,[12] 현재 파이어폭스, 사파리, 오페라에서 지원된다. IP 카메라에서 MJPEG 스트림의 MIME 유형으로 일반적으로 사용된다.[13] 2013년까지는 Chrome에서 주요 리소스에 대해 지원되었으나 (이미지는 여전히 이 콘텐츠 유형을 사용하여 표시할 수 있음).[14]
5. 1. 10. byterange
multipart/byterange는 단일 메시지의 비연속 바이트 범위를 나타내는 데 사용되며, HTTP에서 서버가 여러 바이트 범위를 반환할 때 사용되며 RFC 2616에 정의되어 있다.6. RFC 문서
- RFC 1426, ''8비트 MIME 전송을 위한 SMTP 서비스 확장'', J. 클렌신, N. 프리드, M. 로즈, E. 스테퍼루드, D. 크로커, 1993년 2월.
- RFC 1847, ''MIME을 위한 보안 멀티파트: Multipart/Signed 및 Multipart/Encrypted''.
- RFC 3156, ''OpenPGP를 사용한 MIME 보안''.
- RFC 2045, ''MIME 파트 1: 인터넷 메시지 본문 형식''.
- RFC 2046, ''MIME 파트 2: 미디어 유형'', N. 프리드, 나다니엘 보렌스타인, 1996년 11월.
- RFC 2047, ''MIME 파트 3: 비 ASCII 텍스트를 위한 메시지 헤더 확장'', 키스 무어, 1996년 11월.
- RFC 4288, ''MIME 파트 4: 미디어 유형 사양 및 등록 절차''.
- RFC 4289, ''MIME 파트 4: 등록 절차'', N. 프리드, J. 클렌신, 2005년 12월.
- RFC 2049, ''MIME 파트 5: 적합성 기준 및 예시'', N. 프리드, N. 보렌스타인, 1996년 11월.
- RFC 2183, ''인터넷 메시지에서 프레젠테이션 정보 전달: Content-Disposition 헤더 필드'', 트루스트, R., 도너, S. 및 K. 무어, 1997년 8월.
- RFC 2231, ''MIME 매개변수 값 및 인코딩된 단어 확장: 문자 집합, 언어 및 연속'', N. 프리드, K. 무어, 1997년 11월.
- RFC 2387, ''MIME Multipart/Related 콘텐츠 유형''.
- RFC 1521, ''인터넷 메시지 본문 형식을 지정하고 설명하기 위한 메커니즘''.
- RFC 7578, ''양식에서 값 반환: multipart/form-data''.
참조
[1]
웹사이트
Messages - a Multi-Media Mailer
https://www.cs.cmu.e[...]
1996-05-27
[2]
웹사이트
History of MIME
https://www.networkw[...]
Network World
2011-02-00
[3]
웹사이트
Forcing Thunderbird to treat outgoing attachments properly
http://www.oreillyne[...]
O'Reilly mac devcenter
2010-04-01
[4]
웹사이트
name and filename parameters
https://mailarchive.[...]
2017-04-03
[5]
웹사이트
RFC 2046, Section 5.1.3
https://tools.ietf.o[...]
[6]
웹사이트
RFC 2046, Section 5.1.5
https://tools.ietf.o[...]
[7]
웹사이트
RFC1341 Section 7.2 The Multipart Content-Type
http://www.w3.org/Pr[...]
2014-07-15
[8]
논문
Overview of Anti-spam filtering Techniques
https://www.irjet.ne[...]
2020-02-20
[9]
웹사이트
RFC 2046, Section 5.1.4
https://tools.ietf.o[...]
[10]
웹사이트
RFC 1847, Section 2.1
https://tools.ietf.o[...]
[11]
웹사이트
RFC 1847, Section 2.2
https://tools.ietf.o[...]
[12]
웹사이트
An Exploration of Dynamic Documents
http://fishcam.netsc[...]
Netscape
[13]
웹사이트
WebCam Monitor setup documentation
http://www.deskshare[...]
DeskShare
[14]
웹사이트
249132 - Remove support for multipart/x-mixed-replace main resources - chromium - Monorail
https://bugs.chromiu[...]
2017-10-10
[15]
웹사이트
IETF RFC 2048
[16]
문서
''는, 이중 인용부호가 아닌, 2개의 단일 인용부호이다.
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com