이메일 헤더 분석

RFC 5322 이어짐 줄을 펼치고, From/To/Subject/Date/Message-ID를 뽑아내고, 모든 Received 줄을 파싱해 시간순으로 뒤집은 다음 인접한 홉 사이의 실제 경과 시간을 계산하며, Authentication-Results에서 spf/dkim/dmarc 판정을 추출합니다. 메일이 스팸으로 간 이유를 진단하거나, 위조된 Received 사슬을 찾아내거나, 어느 MTA가 지연을 만들었는지 짚을 때 씁니다.

Received 헤더는 앞에 덧붙는 방식이라 가장 최근 홉이 원문 맨 위에 오고 경로가 거꾸로 읽힙니다. 이것을 뒤집어야 지연이 눈에 들어오지만, 시각은 서로 무관한 기계들의 시계에서 오기 때문에 가끔 홉이 음수 시간을 쓴 것처럼 보입니다. 작은 음수 간격은 두 서버의 시계가 몇 초 어긋났다는 뜻이지 메일이 거꾸로 갔다는 뜻이 아닙니다. 큰 음수는 들여다볼 가치가 있는데, 조작된 헤더도 같은 모습을 만들기 때문입니다.

애초에 신뢰할 수 있는 것은 자기 인프라 안쪽의 홉뿐입니다. 자신이 통제하는 첫 서버 이전의 내용은 메일을 보낸 쪽이 쓴 것이고, 그럴듯한 Received 사슬을 앞쪽에 위조하는 데는 특별한 도구가 필요하지 않습니다. 경계 MTA에서 바깥쪽으로 사슬을 읽고 나머지는 주장으로 취급하십시오.

Authentication-Results에는 같은 단서가 더 날카롭게 적용됩니다. 이것은 어느 호스트든 쓸 수 있는 평범한 헤더입니다. 자기 수신 서버가 붙였을 때와 메일과 함께 도착했을 때의 의미가 전혀 다르며, 특히 DKIM 서명 실패는 메일이 서명된 내용과 일치하지 않는다는 뜻이지 누가 보냈는지를 알려 주지 않습니다. SPF는 수신자가 보는 From 주소가 아니라 봉투 발신자를 인증한다는 점도 기억해야 하는데, DMARC 정렬이 존재하는 이유가 바로 그 틈입니다.

분석은 텍스트 기반이고 로컬에서 이루어집니다. 실시간 조회를 하지 않으므로, 게시된 SPF 레코드가 특정 중계를 여전히 허용하는지 같은 DNS 의존 질문은 따로 확인해야 합니다.