Mbox 보관 파일 뷰어

사용법

1. .mbox 파일을 상자에 놓습니다. 업로드는 없고 이 탭에서 읽으므로 수 기가바이트짜리 Takeout 내보내기도 기기 성능만큼은 다룹니다.
2. 먼저 방식 줄을 읽습니다. 본문을 이스케이프하는 방식(mboxo/mboxrd)인지 Content-Length로 길이를 적는 방식(mboxcl)인지와 그 판단 근거를 알려 줍니다.
3. 진단 항목을 확인합니다. 헤더를 전혀 읽을 수 없는 메시지는 진짜 메시지를 둘로 쪼갠 이스케이프 누락이고, 다른 방식이라면 그었을 경계 수는 보관 파일이 얼마나 위태로운지를 말해 줍니다.
4. 표에서 오프셋과 길이를 봅니다. 올린 파일 안의 바이트 위치라서 dd나 헥스 편집기로 해당 메시지만 잘라 내 따로 검증할 수 있습니다.
5. 행 번호를 누르면 메시지 하나가 열립니다. From_ 줄과 디코딩된 헤더, 파트별 인코딩·파일 이름·디코딩 크기가 담긴 MIME 트리를 볼 수 있습니다.

자주 묻는 질문

받은 적도 없는 메시지가 왜 더 많이 나오나요?

누군가의 본문에 "From "으로 시작하는 줄이 있었는데 파일을 쓴 프로그램이 그것을 이스케이프하지 않았기 때문입니다. 리더 입장에서는 진짜 구분선과 구별할 방법이 없습니다. 둘 다 줄 맨 앞에서 "From "으로 시작하는 한 줄일 뿐입니다. 결과적으로 한 통이 둘로 쪼개지고, 뒷조각은 헤더가 하나도 없는 "메시지"가 되며 앞조각은 뒷부분을 잃습니다. 이 도구는 정확히 그 경우를 표시합니다. 헤더 블록이 빈 메시지는 진짜 메시지인 경우가 거의 없습니다. 해결은 쓰는 쪽에서 해야 하며 mboxrd 이스케이프나 Content-Length는 이를 막지만 순수한 mboxo는 대체로 막지 못합니다.

mboxo, mboxrd, mboxcl, mboxcl2는 실제로 무엇이 다른가요?

메시지의 끝을 어떻게 지키는지만 다릅니다. mboxo는 정확히 "From "으로 시작하는 본문 줄 앞에 ">"를 붙이는데, 이스케이프인지 원래 인용된 줄인지 구별할 수 없어 손실이 있습니다. mboxrd는 ">*From "에 해당하는 모든 줄 앞에 ">"를 붙여서 ">From "은 "From "에서, ">>From "은 ">From "에서 왔음을 보장하므로 되돌릴 수 있습니다. mboxcl은 본문을 그대로 두고 본문 바이트 수를 Content-Length 헤더에 적으며, mboxcl2는 같은 방식이되 원래 인코딩 그대로 저장하고 어디에도 이스케이프를 넣지 않습니다. 분할 자체는 mboxo와 mboxrd가 동일하고 리더가 무엇을 되돌려야 하는지만 다릅니다. 그래서 이 도구는 Content-Length 파일에서만 경계가 달라진다고 보고합니다.

메시지 길이가 왜 가끔 1바이트 짧게 나오나요?

두 메시지 사이의 빈 줄은 어느 쪽에도 속하지 않습니다. 그것을 앞 메시지에 포함시키면 모든 본문 끝에 불필요한 줄바꿈이 하나씩 생기므로 고전적인 구현들은 그 줄을 떼어 냅니다. 단, 그 빈 줄이 LF 하나일 때만 그렇습니다. CRLF로 쓰인 파일의 빈 줄은 2바이트라서 이 규칙이 인식하지 못하고 앞 메시지에 붙은 채 남습니다. 이 도구는 조용히 개선하는 대신 그 동작을 그대로 재현하므로, 같은 파일에 대해 참조 구현이 보고하는 오프셋과 길이가 서로 맞습니다.

제목이 원본 파일과 다르게 보이는 이유는 무엇인가요?

헤더는 ASCII만 담을 수 있어서 나머지는 =?UTF-8?B?SGVsbG8=?= 나 =?ISO-8859-1?Q?Caf=E9?= 같은 RFC 2047 인코딩 워드로 감쌉니다. 이 뷰어는 그것을 디코딩하고, 문자 집합이 같은 인접 인코딩 워드는 바이트를 먼저 이어 붙인 뒤 디코딩합니다. 두 번째 단계가 생각보다 중요합니다. 인코더가 멀티바이트 문자 하나를 두 워드에 걸쳐 자를 수 있는데, 워드를 따로 디코딩하면 그 글자가 대체 문자로 바뀌기 때문입니다. 알 수 없는 문자 집합 이름(오타나 사설 x- 이름)도 치명적이지 않습니다. UTF-8로 디코딩하며 ASCII 범위는 정확하고 정말 읽을 수 없는 부분만 표시됩니다.

HTML 파트를 왜 렌더링하지 않고 소스로 보여 주나요?

보관 파일은 신뢰할 수 없는 입력이기 때문입니다. HTML 본문을 이 페이지 안에서 렌더링하면 그 마크업과 스타일이 주변 페이지에 작용하고, 참조된 원격 이미지와 배경, 글꼴은 발신자가 정한 곳에서 내려받게 됩니다. 추적 픽셀이 주소가 살아 있음을 확인하는 방식이자, 웹메일 보관 파일에 저장된 XSS 페이로드가 브라우저를 만나는 방식이 바로 그것입니다. 소스로 보면 서식만 잃을 뿐 본문과 링크, 구조는 모두 그대로이고, 파트의 디코딩 크기를 보면 예쁜 쪽에 실제 내용이 있었는지도 알 수 있습니다.

중복 Message-ID와 Message-ID 없는 메시지는 얼마나 걱정해야 하나요?

Message-ID는 전역적으로 고유해야 하고 메시지를 처음 처리한 시스템이 한 번만 붙입니다. 한 파일에 같은 ID가 두 번 있다면 보통 같은 메시지의 사본 둘이 합쳐진 것입니다. 백업과 실사용 폴더에서, 또는 둘 다 그 메시지를 담고 있던 폴더에서 온 경우죠. ID 기준 중복 제거는 대체로 안전하지만 바이트 길이를 먼저 확인하세요. 메일링 리스트를 거친 사본은 꼬리말이 다릅니다. Message-ID가 없는 경우는 성격이 다릅니다. 초안이나 일부 자동 발신, 스크립트가 조립한 메시지는 애초에 ID가 없었습니다. 스레드로 묶을 수도 중복 제거를 할 수도 없으니, 그 수는 ID로 동작하는 모든 도구에 보관 파일의 얼마가 보이지 않는지를 알려 줍니다.

관련 도구