메일에 목숨거는 사람들

메일 운영/관리 팀이 수사에 연루되는 경우

어제 모 포털 메일팀으로 부터 연락이 왔습니다. 수사 기관으로부터 2001년도에 생성된 메일의 원문헤더가 왔는데, 그 메일이 실제로 그 포털 메일을 통해서 발송된 것이 맞느냐는 문의였습니다. 일반적으로 포털 웹메일은 웹에서 발송 버튼을 누르면 발송자의 PC IP를 메일 헤더에 첨부해서 발송을 합니다. 메일의 원문을 확보하면 그 원문에 들어 있는 IP 주소를 이용해서 다양한 형태의 '추론'을 해 볼 수 있습니다. 그 메일이 어디에서 발송되었고, 어떤 경로를 통해서 유통되었고, 유통 과정에서 어떤 S/W 가 관여 했는지에 대한 기록을 메일 원문이 가지고 있습니다.

다만 헤더 포맷은 표준으로 확실하게 지켜지는 내용이 많지 않고, 거의 대부분 비표준이므로, 기계적인 프로세싱을 하기에는 좀 무리가 있습니다. 메일에 대해서 상당한 지식을 갖춰야 메일 원문을 추적할 수 있죠. 경험적으로 봤을 때, 좀 복잡하게 경로를 탄 메일의 경우, 그 경로를 정확하게 추적하는 능력을 갖추려면 최소한 중급 이상의 실력으로 3년 이상의 메일 개발/운영 노하우를 지녀야 가능합니다.

메일이 얼마나 복잡한 경로를 타는지 예를 보여 드리겠습니다.

   PC 작성 -> 웹메일 발송 버튼 클릭 -> 발송 큐에 저장 -> 발송 전용 서버로 전달 -> 발송 스팸 서버 경유 -> 상대방 수신 측의 스팸 처리 서버 경유 -> 상대망(제2사이트) 메일 서버 수신 -> 제3의 계정으로 포워딩 일어남 -> 발송 전용 서버로 전달 -> 발송 스팸 처리 서버 경유 -> 제3의 메일 수신 서버로 전달 -> 제3의 메일 수신서버에서 디스크 Full 판단 후 에러 메일 생성 -> 발송 큐에 저장 -> 발송 서버를 통해서 최초 발송 사이트로 전달 -> 최초의 발송 사이트의 스팸 차단 서버에서 스팸으로 간주 -> 스팸 거부 메일 생성후 발송 큐에 전달 -> 제3의 메일 사이트 수신 서버로 전달 -> 제3의 메일 사이트에서 자동 예외처리 수행 -> 제3의 메일 사이트 운영자 메일로 포워딩 -> 제3의 메일 사이트 운영자 메일 인박스에 저장 -> 제3의 메일 사이트 운영자는 해당 메일을 POP3로 수신해서 자신의 PC에 저장한 후 -> 첨부메일로 EML원문을 달아서 원래의 수신측(제2의사이트)의 운영자에게 메일 전달.... 끝도 없이 이런 식으로 진행된 후에 최종 확보된 메일을 보면 경유지에만 수십개의 IP가 찍혀 있습니다.

일반적으로 이렇게 떠도는 메일들은 문제가 있거나, 문제를 경험한 메일입니다. 정상적인 메일들은 경유지가 좀 짧아서, 많아 봐야 5단계 이내입니다. 에러 메일의 경우 이런 식으로 메일이 떠 돌아 다니다가 최종적으로 운영자 또는 개발자가 확보하게 된 원문을 보면, 날짜시간/호스트명/IP/원문/에러메시지 등이 뒤섞여 있는 완전 해독 불가에 가까운 원문이 나옵니다. 이런 원문을 정확하게 디코딩해 내서, 정확하게 어느 부분이 문제이고 어떻게 문제를 풀어야 하는지를 진단해 내는 일은 상당히 고급 개발자나 운영자만이 할 수 있는 일입니다. 그래서 메일이 어려운 것이지요.

어쨌거나... 모 포털 사이트에서는 해당 메일의 원문 헤더에 찍힌 IP가 사실인지를 알고 싶어했습니다. 그런데 이게 대략 난감입니다. 2001년이면 벌써 6년이 넘은 시점이고, 그때 S/W가 어떻게 동작했는지 정확하게 알기란, 그 당시의 웹메일 소스코드를 봐야만 알 수 있는 사항이었고... 또한 메일의 헤더는 메일 기술자에 의해서 조작될 수 있는 가능성이 있기 때문입니다. 2003년에 해당 사이트는 대대적인 메일 개편 작업이 있었고, 2005년도에도 또한번의 사이트 대통합을 단행하면서 웹메일이 크게 변했습니다. 이미 상당히 오래 되어버린 시점의 과거 메일이 수사기관으로 부터 의뢰가 들어온 경우는 매우 드뭅니다. 제 경험상, 이번 건은 가장 오래 전의 메일을 수사 범위에 포함시킨 경우입니다.

일반적으로 포털 웹메일의 경우, 보간기간 설정이 있어서 2~3년 이상 오래된 메일은 보관하지 않기 때문입니다. 요즘에는 GMail의 영향으로 몇 GB 수준의 인박스에 무작정 쌓아 놓는다고 하지만, 그것도 2005년 이후에나 가능했던 일이고, 2005년 이전에는 거의 모든 메일 사이트에서 보관 정책을 매우 타이트하게 잡고 있었기 때문입니다.

저희는 2001년에 동작했던 웹메일 소프트웨어는 없었습니다만, 그 직후의 웹메일 소스를 가지고 추론해 보건데, 웹메일 발송시 PC의 IP를 찍어 두는 개념은 웹메일이 최초에 생겼던 1997년 부터 있었던 기능이므로, 해당 IP가 아마도 그 당시의 발송 PC 아이피가 확실할 것이라는 결론을 내렸습니다. 도대체 어떤 사건인지는 모르겠으나, 수사 기관이 무지무지 집요하다는 생각이 듭니다. 온라인 상의 우리 활동이 우리 상상보다 훨씬 장기간 흔적은 남기고 있다는 것을 항상 명심해야 할 것 같습니다. 요즘에는 스토리지 가격이 더 싸져서, 각종 데이타를 무작정 쌓아 놓는 분위기이니까, 앞으로는 10년 이상 지난 데이타도 수사에 활용되지 않을까 싶습니다.

미국에서는 엔론 회계 부정 사건 이후, 사베인-옥슬리법안(Sarbanes-Auxley Act)이 제정되어 회계/생명공학/제약 등의 일부 업종에 대해서는 e-Mail 데이타도 몇년간 장기 보관해야 하는 법안이 있어서, 메일 업체들이 장기간 메일 보관에 대해서 추가적인 솔루션을 도입하는 분위기입니다만, 우리나라는 아직 그런 법이 만들어질 가능성이 없으므로, 5년 이상의 장기보관을 메일 시스템 또는 서비스에서 보장해야 할 당장의 필요는 없어 보입니다.

하지만 이번 경험을 통해서 기존의 메일 운영 경험에서 충분한 장기간이라고 생각했던 '대략 3년간'이라는 기준을 파기하고, 이메일 시스템에서도 데이타 생명주기를 10년 이상으로 늘려 잡는 것을 검토해야 할 것이라고 생각합니다. (흠... 웬만한 기업의 생명보다 더 길군요.)

데이타 백업은 스토리지 한계가 있다고 하지만, 소스코드의 백업은 얼마든지 할 수 있습니다. 소스코드의 백업이 무엇보다도 중요함을 다시 절실하게 느꼈습니다.

--메일4메일, 2008-01-09.



혹시 이런 비슷한 경험을 가지신 운영자나 개발자분이 이 글을 읽으시면 댓글을 달아 주시기 바랍니다.

이 글과 관련있는 글을 자동검색한 결과입니다 [?]

• Month of PHP Bugs - 26일차 by 헐랭이
• 왜국에서 날아온 스팸(?)메일 2nd by MATARAEL