[SMTP]Transport Events Sink 를 이용한 SMTP 서비스의 효율적 사용 1
2004. 12. 17. 08:50ㆍ일 이야기
1. 들어가며
강좌가 늦었습니다. 그럼 이제 CDO2.0을 즐겨볼까요?
당분간은 새로운 삶의 터전이 생길때까지는 cnu97@hanmail.net이 제 주소랍니다.
2. MIME는 어떻게 작동할까?
RFC822는 일반적인 메시지 포맷과 약간의 표준 헤더정보에 대해서 기술하고 있을 뿐이며 메시지의 body가 ASCII text 라는 점을 제외하고는 메시지의 body에 관하여 아무것도 기술하고 있지 않다.
MIME(마임)은 body text에 대하여 일정한 형식을 추가하여 사용한다. 그리고 MIME를 위한 약간의 헤더라인을 정의하고 있다.
중요한 점은 body는 여전히 ASCII text 덩어리에 불과하다는 점이다.
body에 관해서는RFC822에 의해서 제정된 어떠한 룰도 변경되지 않았다.(단지 ASCII text면 된다.)
이러한 점이 의미하는 것은RFC822에 적합한 메시지 전송시스템은 어떠한 변경없이 MIME 메시지를 핸들링 할 수 있다는 점이다.
메시지 전송시스템은 메시지가 7bit-text일것으로 생각한다.
또한 MIME는 행복하게도 이러한 규칙에 부합한다.
메시지 전송시스템은 약 50-700라인의 텍스트가 실행파일인지 나타내는 것인지, 어떤지에 대하여 전혀 알지 못한다.
실제로 MIME메시지가 아닌 텍스트 덩어리에 시스템을 붕괴시키는 코드가 있던 무었이든 메일전송시스템은 관여하지 않는다.
본문이 다만 7bit-ascII이면 된다. 물론 메시지를 받는 client는 text가 바이너리(이진)파일로 convert되는지에 대해서는 상당한 주의를 기울인다. MIME규칙을 해석할 메일리더기만이 이것들을 알 수 있다.
3. MIME Headers MIME는 약 여섯가지 부가적인 헤더라인을 가지고 있다.
이 다섯가지 헤더라인은 메시지를 받는 클라이언트에게 이 7bit-text가 어떻게 해석되어야 할 지 알려준다.
헤더라인이 의미하는 것.
MIME-Version : 메시지 인코딩의 MIME수준(level), 즉 UA(혹은 MUA->2개를 혼용하여 사용한다.)가
이 메시지가 MIME 메시지로 취급되어야 함을 알려준다.
Content-Type : 메시지에 포함되어 있는 데이터 타입.
Content-Type-Encoding : 데이터가 어떤 방법으로 7bit-text로 전환되었는지에 대한 방법
Content-ID : bodypart를 구별하는 유일값.(나중에 설명)
Content-Description : MIME 응용프로그램에서는 무시되며, 단지 User가 메시지의 내용을 읽는데 도움을 주는 string.
Content-Desposition : MIME메시지의 bodypart에 속해 있는 메시지는 메시지에 포함되어 디스플레이되나 일반적으로 메시지와 분리되어 첨부파일로 표현하는 것이 대부분이다.
이 헤더는 순차적으로 저장되어 파일로 액세스 할 수 있도록 UA에게 알려준다.
여기에서 가장 중요한 것은 Content-Type과 Content-Type-Encoding 헤더이다.
(1) Content-Type
Content-Type 헤더는 Message Body에 포함되어 있는 데이터가 어떤종류인지 Decoder 에게 알려준다.
예)
Content-Type:multipart/mixed;boundary="----=_NextPart_000_0042_01C0B72C.6EEDDBE0"
Content-Type: text/html; charset="ks_c_5601-1987"
Content-Type: image/gif; name="face.gif"
Content-Type: text/plain; charset="iso-8859-1"
Content-Type은 "/"식별자를 이용하여, "일반적인 데이터/일반적인 테이터에 따른 세부사항"의 형식으로 데이터의 종류를 기술하며, 데이터 타입의 정보에 따라, name=value 쌍으로 이루어진 부가적인 parameter를 가질 수 있다. 각각은 ";"으로 구분되어진다.
메일리더(전에 MUA-mail user agent 라고 하였다.)는 보다 많은 형태의 content-type을 핸들링 할 수 있다. OutLook은 text/html을 지원하며, 이것은 유저에게 디스크에 기록없이 직접 HTML메시지를 보여준다. 또한 image/jpeg를 지원하며, 메시지에 올바르게 이미지를 보여줄 수 있다.
메일리더가 지원하지 못하는 어떠한 Content type라도 디스크에 저장되어 질 수 있으며, 유저는 이것을 핸들링할 무언인가를(주로 프로그램이겠지요?)가지고 이 Content type에 따른 데이터를 열어 볼 수 있다.
다른말로 file attachment와 같은 데이터 타입은 존재하지 않는다. 이미지, 오디오 등의 데이터 타입은 존재하지만 file attachment라는 데이터 타입이 이세상에 어디에 있는가? 오직 존재하는 것은 인코딩, 디코딩된 Content-Type만 존재할 뿐이다. 메일리더가 application/zip과 같은 content-type을 해석할 수 있는가? 해석 할 수 있다면 이진 데이터 블럭을 unzip할 것이고, 그렇지 않다면, 디스크에 저장하여, user가 그것을 file attachment로 생각하게 할 것이다.(설명이 조금 어렵군요. 그러나 끝까지 읽어보면 대강 느낌이 올것 같습니다.)
(2) Content-Transfer-Encoding 이 헤더는 디코더가 메시지의 body를 원래의 포맷으로 바꾸기 위해 사용하는 메커니즘이다. 중요한 것들은 7bit, 8bit, Binary, Quoted-Printable 그리고 BASE64이다. content-type이 무엇이든지 상관없이 메일 리더는 가장 먼저는 메시지를 decoding할 수 있어야 한다. 만약 메일리더가 image/gif를 지원하지 않는다 할지라도 앞에서 언급한 것처럼 디스크에는 기록될 수 있어야 한다. 프로그램이 모든 인코딩 매커니즘을 다룰 수 없다면, 이것은 불가능하다.
운좋게도, 단지 BASE64encoding만이 사소한 문제가 있을 뿐(아마 old unix버전의 mail reader가 그럴 것이다.)이다.
4. Multi-Part Messages
MIME는 body에 이미지가 들어있다던지, 아님 첨부파일이 있다던지, 하는 것을 처리하기 위해 각각의 영역을 part로 분할 하여 놓았으며, 이 part가 전부 합쳐져 메시지의 본문을 구성한다. 이러한 형태의 MIME 메시지를 Multi-Part 메시지라 한다.
< P>예)<br> Content-Type:multipart/mixed;boundary="----=_NextPart_000_0042_01C0B72C.6EEDDBE0"
Content-Type: image/jpeg;boundary="Myimagebound"
------=_NextPart_000_0042_01C0B72C.6EEDDBE0
위에서 언급된 boundary 스트링을 보고 이 부분을 찾아서 MIME를 해석한다.
------=_NextPart_000_0042_01C0B72C.6EEDDBE0-- --Myimagebound
여기에 이미지가 인코딩되어있는 문자열이 들어간다.(넘 당연한 소리인가?)
--Myimagebound--
boundary 스트링은 Content-Type header의 특별히 정의된 파라미터이다. 이 스트링을 보고, MIME는 각각의 Part를 인식한다.
boundary의 value로 "--"문자열을 사용해서는 안된다. 이것은 bodypart의 시작과, 끝을 나타낼때 사용한다.
----,나 ------등은 상관없다. 또한 part가 끝날때에는 마지막에 "--"을 덧붙인다.
개인적으로 outlook은
Content-Type:multipart/mixed;boundary="----=_NextPart_000_0042_01C0B72C.6EEDDBE0"
이렇게 복잡하게 하는데 개인적으로는 좀더 줄여서 NextPart_000_0042이정도만 표현해도 좋을것 같다.
(솔직히 인간MUA가 되어서 해석하기에는 너무 짱난다.)
boundary의 value값을 정하는데에는 규칙은 없으며, 다만 그 메시지에서 중복되지 않는 String값이면 된다.
이제부터는 아웃룩에서 메시지 하나를 뽑아낸후 그 헤더와 본문을 유심히 살펴보아야 이 강좌가 이해가 될 것이다.)
강좌가 늦었습니다. 그럼 이제 CDO2.0을 즐겨볼까요?
당분간은 새로운 삶의 터전이 생길때까지는 cnu97@hanmail.net이 제 주소랍니다.
2. MIME는 어떻게 작동할까?
RFC822는 일반적인 메시지 포맷과 약간의 표준 헤더정보에 대해서 기술하고 있을 뿐이며 메시지의 body가 ASCII text 라는 점을 제외하고는 메시지의 body에 관하여 아무것도 기술하고 있지 않다.MIME(마임)은 body text에 대하여 일정한 형식을 추가하여 사용한다. 그리고 MIME를 위한 약간의 헤더라인을 정의하고 있다.
중요한 점은 body는 여전히 ASCII text 덩어리에 불과하다는 점이다.
body에 관해서는
RFC822에 의해서 제정된 어떠한 룰도 변경되지 않았다.(단지 ASCII text면 된다.) 이러한 점이 의미하는 것은
RFC822에 적합한 메시지 전송시스템은 어떠한 변경없이 MIME 메시지를 핸들링 할 수 있다는 점이다.메시지 전송시스템은 메시지가 7bit-text일것으로 생각한다.
또한 MIME는 행복하게도 이러한 규칙에 부합한다.
메시지 전송시스템은 약 50-700라인의 텍스트가 실행파일인지 나타내는 것인지, 어떤지에 대하여 전혀 알지 못한다.
실제로 MIME메시지가 아닌 텍스트 덩어리에 시스템을 붕괴시키는 코드가 있던 무었이든 메일전송시스템은 관여하지 않는다.
본문이 다만 7bit-ascII이면 된다. 물론 메시지를 받는 client는 text가 바이너리(이진)파일로 convert되는지에 대해서는 상당한 주의를 기울인다. MIME규칙을 해석할 메일리더기만이 이것들을 알 수 있다.
3. MIME Headers MIME는 약 여섯가지 부가적인 헤더라인을 가지고 있다.
이 다섯가지 헤더라인은 메시지를 받는 클라이언트에게 이 7bit-text가 어떻게 해석되어야 할 지 알려준다.
헤더라인이 의미하는 것.
MIME-Version : 메시지 인코딩의 MIME수준(level), 즉 UA(혹은 MUA->2개를 혼용하여 사용한다.)가
이 메시지가 MIME 메시지로 취급되어야 함을 알려준다.
Content-Type : 메시지에 포함되어 있는 데이터 타입.
Content-Type-Encoding : 데이터가 어떤 방법으로 7bit-text로 전환되었는지에 대한 방법
Content-ID : bodypart를 구별하는 유일값.(나중에 설명)
Content-Description : MIME 응용프로그램에서는 무시되며, 단지 User가 메시지의 내용을 읽는데 도움을 주는 string.
Content-Desposition : MIME메시지의 bodypart에 속해 있는 메시지는 메시지에 포함되어 디스플레이되나 일반적으로 메시지와 분리되어 첨부파일로 표현하는 것이 대부분이다.
이 헤더는 순차적으로 저장되어 파일로 액세스 할 수 있도록 UA에게 알려준다.
여기에서 가장 중요한 것은 Content-Type과 Content-Type-Encoding 헤더이다.
(1) Content-Type
Content-Type 헤더는 Message Body에 포함되어 있는 데이터가 어떤종류인지 Decoder 에게 알려준다.
예)
Content-Type:multipart/mixed;boundary="----=_NextPart_000_0042_01C0B72C.6EEDDBE0"
Content-Type: text/html; charset="ks_c_5601-1987"
Content-Type: image/gif; name="face.gif"
Content-Type: text/plain; charset="iso-8859-1"
Content-Type은 "/"식별자를 이용하여, "일반적인 데이터/일반적인 테이터에 따른 세부사항"의 형식으로 데이터의 종류를 기술하며, 데이터 타입의 정보에 따라, name=value 쌍으로 이루어진 부가적인 parameter를 가질 수 있다. 각각은 ";"으로 구분되어진다.
메일리더(전에 MUA-mail user agent 라고 하였다.)는 보다 많은 형태의 content-type을 핸들링 할 수 있다. OutLook은 text/html을 지원하며, 이것은 유저에게 디스크에 기록없이 직접 HTML메시지를 보여준다. 또한 image/jpeg를 지원하며, 메시지에 올바르게 이미지를 보여줄 수 있다.
메일리더가 지원하지 못하는 어떠한 Content type라도 디스크에 저장되어 질 수 있으며, 유저는 이것을 핸들링할 무언인가를(주로 프로그램이겠지요?)가지고 이 Content type에 따른 데이터를 열어 볼 수 있다.
다른말로 file attachment와 같은 데이터 타입은 존재하지 않는다. 이미지, 오디오 등의 데이터 타입은 존재하지만 file attachment라는 데이터 타입이 이세상에 어디에 있는가? 오직 존재하는 것은 인코딩, 디코딩된 Content-Type만 존재할 뿐이다. 메일리더가 application/zip과 같은 content-type을 해석할 수 있는가? 해석 할 수 있다면 이진 데이터 블럭을 unzip할 것이고, 그렇지 않다면, 디스크에 저장하여, user가 그것을 file attachment로 생각하게 할 것이다.(설명이 조금 어렵군요. 그러나 끝까지 읽어보면 대강 느낌이 올것 같습니다.)
(2) Content-Transfer-Encoding 이 헤더는 디코더가 메시지의 body를 원래의 포맷으로 바꾸기 위해 사용하는 메커니즘이다. 중요한 것들은 7bit, 8bit, Binary, Quoted-Printable 그리고 BASE64이다. content-type이 무엇이든지 상관없이 메일 리더는 가장 먼저는 메시지를 decoding할 수 있어야 한다. 만약 메일리더가 image/gif를 지원하지 않는다 할지라도 앞에서 언급한 것처럼 디스크에는 기록될 수 있어야 한다. 프로그램이 모든 인코딩 매커니즘을 다룰 수 없다면, 이것은 불가능하다.
운좋게도, 단지 BASE64encoding만이 사소한 문제가 있을 뿐(아마 old unix버전의 mail reader가 그럴 것이다.)이다.
4. Multi-Part Messages
MIME는 body에 이미지가 들어있다던지, 아님 첨부파일이 있다던지, 하는 것을 처리하기 위해 각각의 영역을 part로 분할 하여 놓았으며, 이 part가 전부 합쳐져 메시지의 본문을 구성한다. 이러한 형태의 MIME 메시지를 Multi-Part 메시지라 한다.
< P>예)<br> Content-Type:multipart/mixed;boundary="----=_NextPart_000_0042_01C0B72C.6EEDDBE0"
Content-Type: image/jpeg;boundary="Myimagebound"
------=_NextPart_000_0042_01C0B72C.6EEDDBE0
위에서 언급된 boundary 스트링을 보고 이 부분을 찾아서 MIME를 해석한다.
------=_NextPart_000_0042_01C0B72C.6EEDDBE0-- --Myimagebound
여기에 이미지가 인코딩되어있는 문자열이 들어간다.(넘 당연한 소리인가?)
--Myimagebound--
boundary 스트링은 Content-Type header의 특별히 정의된 파라미터이다. 이 스트링을 보고, MIME는 각각의 Part를 인식한다.
boundary의 value로 "--"문자열을 사용해서는 안된다. 이것은 bodypart의 시작과, 끝을 나타낼때 사용한다.
----,나 ------등은 상관없다. 또한 part가 끝날때에는 마지막에 "--"을 덧붙인다.
개인적으로 outlook은
Content-Type:multipart/mixed;boundary="----=_NextPart_000_0042_01C0B72C.6EEDDBE0"
이렇게 복잡하게 하는데 개인적으로는 좀더 줄여서 NextPart_000_0042이정도만 표현해도 좋을것 같다.
(솔직히 인간MUA가 되어서 해석하기에는 너무 짱난다.)
boundary의 value값을 정하는데에는 규칙은 없으며, 다만 그 메시지에서 중복되지 않는 String값이면 된다.
이제부터는 아웃룩에서 메시지 하나를 뽑아낸후 그 헤더와 본문을 유심히 살펴보아야 이 강좌가 이해가 될 것이다.)