헤더와 본문을 함께
보낸 사람, 받는 사람, 제목, 날짜 및 메시지 본문이 하나의 읽을 수 있는 페이지로 렌더링되어, 누군가 해석해야 하는 원시 덤프가 아닙니다.
문제
감사까지 모두가 잊어버리는 형식
문서 관리 시스템은 PDF와 Office를 중심으로 구축되는데, 첫 번째 실제 사건 파일에 40개의 .msg 파일이 포함되어 도착합니다. 갑자기 서버에 메일 클라이언트가 필요하거나, 누군가 실행해야 하는 변환 단계가 필요하거나, 지원 엔지니어가 증거를 노트북에 다운로드해야 하는 요구가 생깁니다.
다운로드는 세 가지 중 가장 나쁩니다. 메시지가 시스템을 떠나면 보존 정책, 감사 로그 및 접근 제어 밖에 있게 되며, 바로 나중에 가장 중요해질 가능성이 높은 자료가 됩니다.
서버 측 렌더링은 해당 시스템 내부에 서신을 보관하게 하며, 동일 사건의 PDF 및 스프레드시트와 함께 같은 뷰어를 통해 열립니다.
기능
뷰어가 메시지와 함께 수행하는 작업
Outlook 및 MIME
.msg는 Outlook용, .eml 및 .emlx는 그 외 모든 용도입니다. 동일한 열기 호출이 세 가지 모두를 처리합니다.
서식이 적용된 메일은 메일 그대로 렌더링
HTML 메시지는 서식과 인라인 이미지를 유지하며, 평문 텍스트로 축소되지 않습니다.
서버에 메일 클라이언트가 없음
Outlook 설치, MAPI 프로필, COM 자동화가 전혀 필요하지 않습니다 — Word 사례가 인터옵을 피하는 이유와 동일합니다.
파일의 다른 부분과 동일한 뷰어
이메일, 계약서, 스프레드시트 및 도면을 포함한 사건은 하나의 구성 요소를 통해 열립니다. 사용자는 하나의 인터페이스만 배우면 됩니다.
메시지는 그대로 유지
검토자는 페이지를 읽습니다. .msg 파일은 절대 아카이브를 떠나지 않으므로 보존 및 감사가 의미 있게 유지됩니다.
통합
메시지 열기
실제로 가치는 이메일 지원 자체가 아니라, 사건 파일이 세 개의 다른 뷰어와 다운로드 버튼을 필요로 하지 않게 된다는 점입니다.
지원되는 확장자
.eml.emlx.msg
csharp
// Outlook and MIME messages open like any other document
string token = await viewer.OpenDocumentAsync("cases/2026-114/correspondence/thread-08.msg");
// The same viewer instance handles the rest of the matter —
// contracts, spreadsheets, drawings — through identical calls세부 정보
이메일 세부 사항
- 렌더링 호스트에 Outlook, MAPI 프로필 또는 메일 클라이언트가 필요하지 않습니다.
- 메시지 내부의 첨부 파일은 메시지 파일의 일부입니다 — 애플리케이션이 추출한 후 별도의 문서로 열 수 있습니다.
- 메시지 본문 전체에 대한 텍스트 검색은 AdvancedSearch 플러그인이 필요합니다.
자주 묻는 질문
.msg 파일을 렌더링하려면 Outlook을 설치해야 하나요?
아니요. 파싱과 렌더링은 네이티브이며, 이는 메일 클라이언트를 설치할 수 없는 Linux 컨테이너나 보안이 강화된 Windows 서버에서도 사용할 수 있게 합니다.
첨부 파일도 렌더링되나요?
메시지는 메시지 자체로 렌더링됩니다. 첨부 파일을 표시하려면 자체 코드로 추출한 뒤 별도의 문서로 열어야 합니다 — 이는 뷰어가 이미 지원하는 형식 중 하나입니다.
왜 모든 것을 미리 PDF로 변환하지 않나요?
Converter 플러그인을 사용하면 가능합니다. 하지만 변환은 누군가가 관리하고 재실행해야 하는 배치 작업이며, 저장 용량이 두 배가 됩니다. 필요 시 렌더링은 증거의 한 사본만 유지하고 관리 파이프라인이 필요 없습니다.