Exchange Server 콘텐츠 변환

  • 아티클

콘텐츠 변환은 각 받는 사람을 위해 메시지 형식을 올바르게 지정하는 프로세스입니다. 메시지에 대한 콘텐츠 변환을 수행하는 결정은 메시지의 대상 및 형식에 따라 달라집니다. Exchange 2016 및 Exchange 2019에서 발생하는 콘텐츠 변환 유형은 Exchange 2013에서 변경되지 않습니다.

  • 외부 받는 사람을 위한 메시지 변환: 이 유형의 콘텐츠 변환에는 TNEF(전송 중립 캡슐화 형식) 변환 옵션 및 외부 받는 사람에 대한 메시지 인코딩 옵션이 포함됩니다. Exchange 조직 내부의 받는 사람에게 보낸 메시지는 이러한 유형의 내용 변환이 필요하지 않습니다. 이 유형의 콘텐츠 변환은 사서함 서버의 전송 서비스에서 범주에 의해 처리됩니다. 새로 도착한 메시지가 전송 큐에 배치되고 나면 각 메시지에 대한 분류가 수행됩니다. 받는 사람 확인 및 라우팅 확인과 함께 메시지에 대한 콘텐츠 변환은 메시지가 배달 큐에 추가되기 전에 수행됩니다. 한 메시지에 받는 사람이 여러 명 포함된 경우 분류기는 각 메시지의 받는 사람에 대한 알맞은 인코딩을 결정합니다. 내용 변환 추적은 외부 받는 사람에게 보내는 메시지를 변환하기 때문에 분류기에서 발생하는 내용 변환 오류를 모두 캡처하지는 않습니다.

  • 내부 받는 사람에 대한 MAPI 변환: 이 유형의 콘텐츠 변환은 사서함 전송 서비스에서 처리됩니다. 사서함 전송 서비스는 로컬 서버의 사서함 데이터베이스와 사서함 서버의 전송 서비스 간에 메시지를 전송하기 위해 사서함 서버에 있습니다. 특히 Mailbox Transport Submission 서비스는 보낸 사람의 보낼 편지함에서 사서함 서버의 전송 서비스로 메시지를 전송합니다. Mailbox Transport Delivery 서비스는 사서함 서버의 전송 서비스에서 받는 사람의 받은 편지함으로 메시지를 전송합니다. Mailbox Transport Submission 서비스는 MAPI에서 나가는 모든 메시지를 변환하고, Mailbox Transport Delivery 서비스는 MAPI에서 들어오는 모든 메시지를 변환합니다. 내용 변환 추적은 이러한 MAPI의 변환 실패를 캡처합니다. 자세한 내용은 Managing Content Conversion Tracing를 참조하십시오.

Exchange 및 Outlook 메시지 형식

다음 목록에서는 Exchange 및 Outlook에서 사용할 수 있는 기본 메시지 형식에 대해 설명합니다.

  • 일반 텍스트: 일반 텍스트 메시지는 RFC 5322에 설명된 대로 US-ASCII 텍스트만 사용합니다. 메시지에 다른 글꼴이나 다른 텍스트 서식을 포함할 수 없습니다. 일반 문자 메시지에는 다음 두 가지 형식을 사용할 수 있습니다.

    • 메시지 헤더와 메시지 본문은 US-ASCII 텍스트로 작성됩니다. 첨부 파일은 Uuencode를 사용하여 인코딩해야 합니다. Unix-to-Unix 인코딩을 나타내는 Uuencode는 US-ASCII 텍스트 문자를 사용하여 전자 메일 메시지의 본문에 이진 첨부 파일을 저장하는 인코딩 알고리즘을 정의합니다.

    • 메시지는 MIME로 인코딩되며 , 의 Content-Type 값 text/plain과 다중 파트 메시지의 텍스트 부분에 대한 Content-Transfer-Encoding7bit 값이 있습니다. 메시지 첨부 파일은 Quoted-printable 또는 Base64 인코딩을 사용하여 인코딩합니다. 기본적으로 Outlook에서 일반 문자 메시지를 작성하고 보낼 때 메시지는 의 Content-Type 값 text/plain으로 MIME로 인코딩됩니다.

  • HTML: HTML 메시지는 텍스트 서식, 배경 이미지, 테이블, 글머리 기호 및 기타 그래픽 요소를 지원합니다. 정의에 따라 이러한 서식 요소를 유지하기 위해 HTML 형식의 메시지는 MIME로 인코딩되어야 합니다.

  • RTF(서식 있는 텍스트 형식) : RTF는 텍스트 서식 및 기타 그래픽 요소를 지원합니다. RTF는 TNEF와 동의어입니다(TNEF 및 RTF는 서로 바꿔 사용할 수 있습니다). 서식 있는 텍스트 메시지 형식은 Word에서 사용할 수 있는 서식 있는 텍스트 문서 형식과 완전히 다릅니다.

  • TNEF: 전송 중립 캡슐화 형식은 MAPI 메시지 속성을 캡슐화하기 위한 Microsoft 관련 형식입니다. TNEF 메시지에는 메시지의 일반 텍스트 버전과 메시지의 원본 서식 버전을 패키지하는 첨부 파일이 포함됩니다. 일반적으로 이 첨부 파일의 이름은 Winmail.dat입니다. Winmail.dat 첨부 파일에는 다음 정보가 포함되어 있습니다.

    • 메시지의 원래 서식이 지정된 버전(예: 글꼴, 텍스트 크기 및 텍스트 색)
    • OLE 개체(예: 포함된 그림 또는 포함된 Office 문서)
    • 특수 Outlook 기능(예: 사용자 지정 양식, 투표 단추 또는 모임 요청)
    • 원본 메시지에 있던 일반 메시지 첨부 파일

    결과 일반 텍스트 메시지는 다음 형식으로 표시될 수 있습니다.

    • Uuencode로 인코딩된 Winmail.dat 첨부 파일이 있는 US-ASCII 텍스트로만 구성된 RFC 5322 규격 메시지
    • Winmail.dat 첨부 파일이 있는 multipart MIME로 인코딩된 메시지

    TNEF를 완전히 이해하는 Outlook 및 기타 전자 메일 클라이언트는 Winmail.dat 첨부 파일을 처리하고 Winmail.dat 첨부 파일을 표시하지 않고 원본 메시지 콘텐츠를 표시합니다. TNEF를 이해하지 못하는 Email 클라이언트는 다음과 같은 방법으로 TNEF 메시지를 표시할 수 있습니다.

    • 메시지의 일반 텍스트 버전이 표시되고 메시지에는 Winmail.dat, Win.dat 또는 Att nnnn.dat 또는 Att nnnnn.eml과 같은 다른 일반 이름(nnnnn 자리 표시자가 난수를 나타내는 경우)이라는 첨부 파일이 포함됩니다.
    • 일반 텍스트 버전 메시지가 표시됩니다. TNEF 첨부 파일은 무시되거나 제거됩니다. 결과적으로 일반 텍스트 메시지가 됩니다.
    • 받는 메시지에서 TNEF 첨부 파일을 제거하도록 TNEF를 이해하는 메시징 서버를 구성할 수 있습니다. 결과적으로 일반 텍스트 메시지가 됩니다. 또한 일부 전자 메일 클라이언트는 TNEF를 이해하지 못하지만 TNEF 첨부 파일을 인식하고 무시합니다. 결과적으로 일반 문자 메시지가 됩니다.

    타사 유틸리티를 사용하여 Winmail.dat 첨부 파일을 변환할 수 있습니다.

    Exchange Server 버전 5.5 이상의 모든 Exchange 버전은 TNEF를 이해할 수 있습니다.

  • 요약 전송 STNEF(중립 캡슐화 형식): STNEF는 TNEF와 동일합니다. 그러나 STNEF 메시지는 TNEF 메시지와 다르게 인코딩됩니다. 특히 STNEF 메시지는 항상 MIME로 인코딩되며 항상 Content-Transfer-Encoding 값 Binary이 있습니다. 따라서 메시지에 일반 텍스트가 표시되지 않고 메시지 본문에 고유한 Winmail.dat 첨부 파일이 포함되지 않습니다. 전체 메시지는 이진 데이터만 사용하여 표시됩니다. Content-Transfer-Encoding 값이 Binary인 메시지는 RFC 3030에 정의된 대로 BINARYMIME 및 CHUNKING SMTP 확장을 지원하고 보급하는 메시징 서버 간에만 전송할 수 있습니다. 메시지는 항상 표준 DATA 명령 대신 BDAT 명령을 사용하여 메시징 서버 간에 전송됩니다.

    Exchange 2000 이상의 모든 Exchange 버전은 STNEF를 이해할 수 있습니다. STNEF는 조직에서 기본 모드 Exchange Server 2003 이상의 Exchange 서버 간에 전송되는 모든 메시지에 자동으로 사용됩니다.

    Exchange는 외부의 받는 사람에게 STNEF 메시지를 보내지 않습니다. TNEF 메시지만 Exchange 조직 외부의 받는 사람에게 보낼 수 있습니다.

외부의 받는 사람에 대한 내용 변환 옵션

다음 범주에서는 외부의 받는 사람에 대해 Exchange 조직에서 설정할 수 있는 내용 변환 옵션에 대해 설명합니다.

  • TNEF 변환 옵션: 이러한 변환 옵션은 Exchange 조직을 떠나는 메시지에서 TNEF를 유지하거나 제거할지 여부를 지정합니다.
  • 메시지 인코딩 옵션: 이러한 옵션은 MIME 및 MIME가 아닌 문자 집합, 메시지 인코딩 및 첨부 파일 형식과 같은 메시지 인코딩 옵션을 지정합니다.

이 변환 및 인코딩 옵션은 서로 독립적입니다. 예를 들어, TNEF 메시지가 Exchange 조직에서 나갈 수 있는지 여부는 해당 메시지의 MIME 인코딩 설정 또는 일반 텍스트 인코딩 설정과 관계가 없습니다.

다음 목록에 나와 있는 대로 Exchange 조직의 다양한 수준에서 내용 변환을 지정할 수 있습니다.

  • 원격 도메인 설정: 원격 도메인은 Exchange 조직과 외부 도메인 간에 보내는 메시지 전송에 대한 설정을 정의합니다. 특정 도메인에 대한 원격 도메인 항목을 만들지 않아도 모든 원격 주소 공간(*)에 적용되는 Default라는 이름의 미리 정의된 원격 도메인이 있습니다. 원격 도메인에 대한 자세한 내용은 원격 도메인을 참조하세요.

  • 메일 사용자 및 메일 연락처 설정: 메일 사용자와 메일 연락처는 모두 외부 전자 메일 주소를 가지고 있고 Exchange 조직 외부 사용자에 대한 정보를 포함하기 때문에 유사합니다. 주요 차이점은 메일 사용자에게 Active Directory에 로그온하고 조직의 리소스에 액세스하는 데 사용할 수 있는 계정이 있다는 것입니다. 자세한 내용은 받는 사람을 참조하십시오.

  • Outlook 설정: Outlook에서 다음 메시지 서식 및 인코딩 옵션을 설정할 수 있습니다.

    • 메시지 형식: 모든 메시지에 대한 기본 메시지 형식을 설정할 수 있습니다. 특정 메시지를 작성할 때 기본 메시지 형식을 재정의할 수 있습니다.
    • 인터넷 메시지 형식: TNEF 메시지가 원격 받는 사람에게 전송되는지 또는 TNEF 메시지가 먼저 호환되는 형식으로 변환되는지 여부를 제어할 수 있습니다. 또한 원격 받는 사람에게 보내는 메시지에 대해 다양한 메시지 인코딩 옵션을 지정할 수 있습니다. 이 설정은 Exchange 조직의 받는 사람에게 보내는 메시지에는 적용되지 않습니다.
    • 인터넷 받는 사람 메시지 형식(Outlook 2010 이하): TNEF 메시지가 연락처 폴더의 특정 연락처로 전송되는지 여부를 제어할 수 있습니다. Exchange 조직의 받는 사람에 대해서는 이 변환 옵션을 사용할 수 없습니다.
    • 인터넷 수신자 메시지 인코딩 옵션(Outlook 2010 이하): 연락처 폴더의 특정 연락처에 대한 MIME 또는 일반 텍스트 인코딩 옵션을 제어할 수 있습니다. Exchange 조직의 받는 사람에 대해서는 이 변환 옵션을 사용할 수 없습니다.
    • 국가별 옵션: 메시지에 사용되는 문자 집합을 제어할 수 있습니다.

    이러한 설정에 대한 자세한 내용은 Exchange Server TNEF 변환 옵션 및 메시지 인코딩 옵션을 참조하세요.

전자 메일 메시지의 구조 이해

외부의 받는 사람에 대한 내용 변환 옵션을 더 잘 알려면 전자 메일 메시지의 구조를 이해해야 합니다. SMTP 메시지는 일반 7비트 US-ASCII 텍스트를 기반으로 하여 전자 메일 메시지를 작성하고 보냅니다. 표준 SMTP 메시지는 다음 요소로 구성됩니다.

  • 메시지 봉투: 메시지 봉투는 RFC 5321에 정의되어 있습니다. 여기에는 메시지를 보내고 배달하는 데 필요한 정보가 포함되어 있습니다. 메시지 봉투는 메시지 전송 프로세스에 의해 생성되며 실제로는 메시지 콘텐츠의 일부가 아니기 때문에 받는 사람은 메시지 봉투를 볼 수 없습니다.

  • 메시지 내용: 메시지 콘텐츠는 RFC 5322에 정의되어 있습니다. 메시지 콘텐츠는 다음 요소로 구성됩니다.

    • 메시지 헤더: 메시지 헤더는 헤더 필드의 컬렉션입니다. 헤더 필드는 필드 이름, 그 뒤에 콜론(:) 문자와 필드 본문이 순서대로 오고 CR/LF(캐리지 리턴/라인 피드) 문자 조합으로 끝납니다.

      필드 이름은 콜론(:) 문자를 제외하고 인쇄용 US-ASCII 텍스트 문자로 작성해야 합니다. 특히 33-57 범위와 59-126 범위의 값을 가진 ASCII 문자가 허용됩니다.

      필드 본문은 CR(캐리지 리턴) 문자와 LF(라인 피드) 문자를 제외한 US-ASCII 문자로 작성할 수 있습니다. 그러나 헤더 접기에 사용할 때는 필드 본문에 CR/LF 문자 조합을 포함할 수 있습니다. 헤더 폴딩은 RFC 5322의 섹션 2.2.3에 설명된 대로 단일 헤더 필드 본문을 여러 줄로 분리하는 것입니다. 다른 필드 본문 구문 요구 사항은 RFC 5322의 섹션 3 및 4에 설명되어 있습니다.

    • 메시지 본문: 메시지 본문은 메시지 헤더 다음에 나타나는 US-ASCII 텍스트 문자 줄의 컬렉션입니다. 메시지 헤더와 메시지 본문은 CR/LF 문자 조합으로 끝나는 빈 줄로 분리됩니다. 메시지 본문은 선택 사항입니다. 메시지 본문의 텍스트 줄은 998자 미만이어야 합니다. CR 및 LF 문자는 줄 끝을 나타내는 경우에만 함께 표시할 수 있습니다.

SMTP 메시지에 일반 US-ASCII 텍스트가 아닌 요소가 포함된 경우 해당 요소를 유지하려면 메시지를 인코딩해야 합니다. MIME 표준은 텍스트가 아닌 메시지의 콘텐츠를 인코딩하는 방법을 정의합니다. MIME를 사용하면 다른 문자 집합의 텍스트, 텍스트가 없는 첨부 파일, 다중 파트 메시지 본문 및 다른 문자 집합의 머리글 필드를 사용할 수 있습니다. MIME는 RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 및 RFC 2049에 정의됩니다. MIME는 추가 메시지 특성을 지정하는 헤더 필드의 컬렉션을 정의합니다. 다음 섹션에서는 몇 가지 중요한 MIME 헤더 필드에 대해 설명합니다.

MIME-Version 헤더 필드

기본값: 1.0

이 헤더 필드는 MIME 형식 메시지에 표시되는 첫 번째 MIME 헤더 필드입니다. 이 헤더 필드는 다른 표준 RFC 5322 헤더 필드 뒤와 다른 MIME 헤더 필드 앞에 나타납니다. MIME 인식 전자 메일 클라이언트는 이 헤더 필드를 사용하여 MIME로 인코딩된 메시지를 식별합니다. 이 헤더 필드가 없으면 MIME 인식 전자 메일 클라이언트는 메시지를 일반 텍스트로 식별합니다.

Content-Type 헤더 필드

기본값: text/plain

이 헤더 필드는 RFC 2046에 설명된 대로 메시지 콘텐츠의 미디어 유형을 식별합니다. 미디어 유형은 다음으로 구성됩니다.

  • 형식:

    • 로 x- 시작하는 형식은 표준이 아닙니다. IANA(Internet Assigned Numbers Authority)는 등록된 미디어 유형 목록을 유지 관리합니다. 자세한 내용은 MIME 미디어 형식을 참조하세요.

    • multipart 미디어 유형은 다른 미디어 유형으로 정의한 섹션을 사용하여 동일한 메시지의 여러 메시지 부분에 사용할 수 있습니다. 일부 Content-Type 필드 값에는 , text/html, multipart/mixed및 multipart/alternative가 포함text/plain됩니다.

  • 하위 형식: 으로 vnd. 시작하는 하위 형식은 공급업체별로 다릅니다.

  • 하나 이상의 선택적 매개 변수: 예를 들어 charset= MIME 문자 인코딩을 정의하는 매개 변수입니다.

Content-Transfer-Encoding 헤더 필드

기본값: 7bit

이 헤더 필드는 메시지에 대한 다음 정보를 설명할 수 있습니다.

  • 메시지 본문에 있는 비 US-ASCII 텍스트 또는 이진 데이터를 변환하는 데 사용된 인코딩 알고리즘
  • 메시지 본문의 현재 상태를 설명하는 표시기

MIME 메시지에 Content-Transfer-Encoding 헤더 필드의 여러 값이 있을 수 있습니다. Content-Transfer-Encoding 헤더 필드가 메시지 헤더에 표시되면 메시지의 전체 본문에 적용됩니다. Content-Transfer-Encoding 헤더 필드가 다중 파트 메시지의 부분 중 하나에 표시되면 메시지의 해당 부분에만 적용됩니다.

메시지 본문 데이터에 인코딩 알고리즘이 적용되면 메시지 본문 데이터가 일반 US-ASCII 텍스트로 변환됩니다. 이 변환을 사용하면 메시지가 US-ASCII 텍스트의 메시지만 지원하는 이전 메시징 서버를 통과할 수 있습니다. 메시지 본문에 인코딩 알고리즘이 사용되었음을 나타내는 Content-Transfer-Encoding 헤더 필드 값은 다음과 같습니다.

  • Quoted-printable: 인쇄 가능한 US-ASCII 문자를 사용하여 메시지 본문 데이터를 인코딩합니다. 원본 메시지 텍스트가 대부분 US-ASCII 텍스트인 경우 Quoted-printable 인코딩을 통해 어느 정도 읽을 수 있는 간결한 메시지를 얻을 수 있습니다. 등호(=) 문자를 제외한 모든 인쇄용 US-ASCII 텍스트 문자는 인코딩하지 않고 나타낼 수 있습니다.

  • Base64: 주로 RFC 4648에 정의된 PEM(개인 정보 보호 강화 메일) 표준을 기반으로 합니다. Base64 인코딩은 64자 알파벳 인코딩 알고리즘 및 PEM으로 정의한 출력 패딩 문자를 사용하여 메시지 본문 데이터를 인코딩합니다. Base64로 인코딩된 메시지는 일반적으로 원본 메시지보다 33% 큽니다. 예측 가능하게 메시지 크기를 증가시키는 Base64 인코딩은 이진 데이터와 비 US-ASCII 텍스트에 사용하는 것이 좋습니다.

일반적으로 동일한 메시지에는 여러 인코딩 알고리즘을 사용하지 않습니다.

메시지 본문에 인코딩 알고리즘이 사용되지 않은 경우 Content-Transfer-Encoding 헤더 필드는 메시지 본문 데이터의 현재 상태를 식별할 뿐입니다. 메시지 본문에 인코딩 알고리즘이 사용되지 않았음을 나타내는 Content-Transfer-Encoding 헤더 필드 값은 다음과 같습니다.

  • 7bit: 메시지 본문 데이터가 이미 RFC 5322 형식임을 나타냅니다. 특히 이 값일 때는 다음 조건이 true여야 함을 의미합니다.

    • 모든 텍스트 줄이 998자 길이 미만이어야 합니다.

    • 모든 문자는 문자 값이 1-127 범위에 속하는 US-ASCII 텍스트여야 합니다.

    • CR 및 LF 문자는 텍스트의 줄 끝을 나타내는 경우에만 함께 사용할 수 있습니다.

      전체 메시지 본문은 7비트이거나 다중 파트 메시지의 메시지 본문 일부가 7비트일 수 있습니다. multipart 메시지에 이진 데이터 또는 비 US-ASCII 텍스트가 있는 다른 부분이 포함되어 있으면 Quoted-printable 또는 Base64 인코딩 알고리즘을 사용하여 메시지의 해당 부분을 인코딩해야 합니다.

      7비트 본문이 있는 메시지는 표준 DATA 명령을 사용하여 메시징 서버 간에 이동할 수 있습니다.

  • 8bit: 메시지 본문 데이터에 미국-ASCII가 아닌 문자가 포함되어 있음을 나타냅니다. 특히 이 값일 때는 다음 조건이 true여야 함을 의미합니다.

    • 모든 텍스트 줄이 998자 길이 미만이어야 합니다.

    • 메시지 본문 내 하나 이상의 문자에 127보다 큰 값이 있습니다.

    • CR 및 LF 문자는 텍스트의 줄 끝을 나타내는 경우에만 함께 사용할 수 있습니다.

      전체 메시지 본문은 8비트이거나 다중 파트 메시지의 메시지 본문 일부가 8비트일 수 있습니다. multipart 메시지에 이진 데이터가 있는 다른 부분이 포함되어 있으면 Quoted-printable 또는 Base64 인코딩 알고리즘을 사용하여 메시지의 해당 부분을 인코딩해야 합니다.

      8비트 본문이 있는 메시지는 EXCHANGE 2000 서버 이상과 같이 RFC 6152에 정의된 대로 8BITMIME SMTP 확장을 지원하는 메시징 서버 간에만 이동할 수 있습니다. 특히 이 값일 때는 다음 조건이 true여야 함을 의미합니다.

    • 8BITMIME 키워드는 서버의 EHLO 응답에 보급되어야 합니다.

    • 메시지는 여전히 SMTP 표준 DATA 명령을 사용하여 전송됩니다. 그러나 매개 변수를 BODY=8BITMIMEMAIL FROM 명령의 끝에 추가해야 합니다.

  • Binary: 메시지 본문에 미국-ASCII가 아닌 텍스트 또는 이진 데이터가 포함되어 있음을 나타냅니다. 특히 이 값은 다음 조건이 true임을 의미합니다.

    • 모든 문자 순서가 허용됩니다.

    • 줄 길이 제한이 없습니다.

    • Binary 메시지 요소를 인코딩하지 않아도 됩니다.

      이진 본문이 있는 메시지는 EXCHANGE 2000 서버 이상과 같이 RFC 3030에 정의된 대로 BINARYMIME SMTP 확장을 지원하는 메시징 서버 간에만 이동할 수 있습니다. 특히 이 값일 때는 다음 조건이 true여야 함을 의미합니다.

    • BINARYMIME 키워드는 서버의 EHLO 응답에 보급되어야 합니다.

    • BINARYMIME SMTP 확장은 CHUNKING SMTP 확장에서만 사용할 수 있습니다. Chunking을 사용하면 큰 메시지 본문을 보다 작은 여러 개의 청크에 보낼 수 있습니다. Chunking은 RFC 3030에도 정의되어 있습니다. CHUNKING 키워드는 서버의 EHLO 응답에도 보급되어야 합니다.

    • 메시지는 표준 DATA 명령 대신 BDAT 명령을 사용하여 전송됩니다.

    • BODY=BINARYMIME 메시지에 메시지 본문이 있는 경우 매개 변수를 MAIL FROM 명령의 끝에 추가해야 합니다.

값 7bit, 8bit및 Binary 는 동일한 다중 파트 메시지에 함께 존재하지 않습니다(값은 상호 배타적임). 또는 Base64 값은 Quoted-printable 7비트 또는 8비트 다중 파트 메시지 본문에 나타날 수 있지만 이진 메시지 본문에는 나타나지 않습니다. 다중 파트 메시지 본문에 7비트 및 8비트 콘텐츠로 구성된 다른 부분이 포함된 경우 전체 메시지는 8비트로 분류됩니다. 다중 파트 메시지 본문에 7비트, 8비트 및 이진 콘텐츠로 구성된 다른 부분이 포함된 경우 전체 메시지는 이진으로 분류됩니다.

Content-Disposition 헤더 필드

기본값: Attachment

이 헤더 필드는 MIME 사용 전자 메일 클라이언트에 첨부된 파일을 표시하는 방법을 알려주며 RFC 2183에 설명되어 있습니다. 유효한 값은 다음과 같습니다.

  • Inline: 첨부 파일이 메시지 본문에 표시됩니다.

  • Attachment: 첨부된 파일은 메시지 본문과 별도로 일반 첨부 파일로 나타납니다. 다른 매개 변수도 이 값(예: , FilenameCreation-date및 )을 Size사용합니다.