MIME 이메일, Outlook의 문제점 및 차이점을 파싱

Question

저는 파섹 (parsec)이라는 haskell 파싱 라이브러리를 배우고 있습니다.이 목적을 위해 이메일 메시지를 파싱해야합니다. 나는 다른 클라이언트의 다른 메시지를 비교하고, 사양을 연구 중이며, 일부 rfc를 읽는 중이다.

이 연습에서는 "보낸 사람 :"헤더와 실제 일반 텍스트 본문 만 추출하면된다. 이제 모든 클라이언트는 사양과 관련하여 정상 또는 적어도 비정상적인 메시지를 생성합니다. 유일한 차이점은 전망입니다 (나는 어떤 이유로 든 놀랍지 않습니다).

는 그래서 standad의 방법은, MYU 독서에 따라 경계 순서를하는 것입니다 말 : 멀티 파트 신체의

Content-Type: multipart/alternative; boundary=047d7b2e4e3cdc627304eb094bfe 

하고 모든 부분이 바로이 경계 순서로 구분된다? 내가 틀렸다면 나를 수정하십시오. 파서가 가능한 모든 고객과 함께 작업하기를 바랍니다.

그래서 일반적인 패턴은 이제

--boundary 
headers 
part 

--boundary 
headers 
part 

... 

, 전망 생성 된 메시지를보고, 내가 볼 다른 사진입니다. 그것은 일종의 하위 경계를 사용하며 그것이 표준인지 여부를 이해하지 못합니까? 은 전망 변형

Content-Type: multipart/related; 
    type="multipart/alternative"; 
    boundary="----_=_NextPart_001_01CEE199.851D3871" 

그런 다음 몸은 그래서 순서 002 그래서이 무엇인가와 서열 001과 외부 경계하고 내부 경계를 가지고이

------_=_NextPart_001_01CEE199.851D3871 
Content-Type: multipart/alternative; 
    boundary="----_=_NextPart_002_01CEE199.851D3871" 

----_=_NextPart_002_01CEE199.851D3871 
headers 
body part 

----_=_NextPart_002_01CEE199.851D3871 
headers 
body part 

------_=_NextPart_001_01CEE199.851D3871 

처럼 구분되어이있다? 이것은 어떤 종류의 마이크로 소프트 자신의 MIME 사양입니까, 아니면 내가 놓친 rfc입니까? 이것은 구문 분석하기가 더 복잡합니다.

Answer 1

실제로는 하위 경계가 아니며 멀티 파트 섹션 자체에 멀티 파트 콘텐츠가 포함될 수 있습니다.

즉, 경계를 재귀 적으로 파싱해야하며 콘텐츠 유형이 multipart/alternative 인 경우 자체 경계 문자열 및 부품이 포함됩니다. 이 문자열이 다른 경계와 매우 유사하다는 사실은 outlook이하는 것입니다. 그것은 완전히 분리되었을 수 있습니다.

모두

--part 
--part 
--part 

및

--part 
    --part 
    --part 
--part 
--part 

유효 구조입니다. 전망이

Content-Type: multipart/alternative; 
    boundary="firstmessage" 

--firstmessage 
content-type: multipart/alternative; 
    boundary="nestedpart" 

--nestedpart 
content-type: text/plain 

nested body one 

--nestedpart 
content-type: text/plain 

nested body two 

--nestedpart-- 
--firstmessage 
headers 

second part of first message 
--firstmessage-- 

처럼 보이는 한 경우

이 더 분명 수 있습니다