예전 네이버 블로그에서 썼던 포스트를 다시 한번 올려봅니다. 약간 수정했지만 사실 재탕입니다. -_-;
메일을 위시한, 인터넷 메시지 포맷을 정의한 RFC 5322 문서에 보면, 3.6.7 절에 Trace fields 라는 것이 정의되어있습니다. 사전적인 의미로 Trace를 직역하자면, “자취” 또는 “발자국”이라는 뜻을 가지고 있으며, 메일 헤더부분에서는 메일이 전송되는 경로를 추적할 수 있는 필드를 뜻합니다. 메일은 A에서 B 서버로 바로 전달되는 것이 원칙이지만, 현재는 서버 관리/스팸필터링/바이러스체크 등의 이유로 이런 저런 서버를 거쳐(릴레이) 메일은 전송됩니다.
간단하게, 한 사용자가 메일을 작성하고 배달되어 다른 사용자가 메일을 확인할 때까지 거치는 과정을 간략하게 표현하면 다음과 같습니다.
이러한 일련의 과정은 메일을 받은 후 원문보기 기능을 이용하면 어느 정도 파악이 가능합니다. 예를 들어 Gmail에서 DreamWiz로 메일을 전송했을 때의 원문의 헤더는 아래와 같이 작성됩니다.
Return-Path: <widelake@gmail.com>
Received: from [10.0.10.131] ([10.0.10.131])
by pmail0.dreamwiz.com (NetMDA/4.10P03) id 2006092516121287C7
for <widelake@dreamwiz.com>; Tue, 26 Sep 2006 01:12:12 +0900 (KST)
X-DreamWiz-Address: <widelake@dreamwiz.com>
X-DreamWiz-SpamCenter: C=1,M=1,R=1,RS=0,BR=0,BRS=0,BRT=0,T=1/2,
SPF=pass,DKIM=neutral(no signature),SA=pass(spf),
PTR=ok,SPAM=-35(green),VC=pass(ClamAV:1943)
X-DreamWiz-Peer-IP: [66.249.82.230]
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230])
by mx-r1.dreamwiz.com (8.13.8/8.13.8) with ESMTP id k8PGCAK0079920
for <widelake@dreamwiz.com>; Tue, 26 Sep 2006 01:12:11 +0900 (KST)
Received: by wx-out-0506.google.com with SMTP id s7so1922579wxc
for <widelake@dreamwiz.com>; Mon, 25 Sep 2006 09:12:10 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=beta; d=gmail.com;
h=received:message-id:date:from:to:subject:mime-version:content-type;
Received: by 10.70.125.11 with SMTP id x11mr7395570wxc;
Mon, 25 Sep 2006 09:12:09 -0700 (PDT)
Received: by 10.70.97.2 with HTTP; Mon, 25 Sep 2006 09:12:09 -0700 (PDT)
Message-ID: <5def9a530609250912w388966e1me2258be23cc4684@mail.gmail.com>
Date: Tue, 26 Sep 2006 01:12:09 +0900
From: "Taeyeon Kim" <widelake@gmail.com>
To: widelake@dreamwiz.com
Subject: =?EUC-KR?B?xde9usau?=
* DomainKey-Signature에는 content-type; 부분이 더 있습니다만 너무 길어서 제거했습니다.
Received: by 로 시작하는 필드들은 내부 릴레이를 뜻합니다. 아래부터 위까지 시간 순서대로 진행됩니다. 위의 내용에서 Received: by 필드만 모아보겠습니다.
1. Received: from [10.0.10.131] ([10.0.10.131])
by pmail0.dreamwiz.com (NetMDA/4.10P03) id 2006092516121287C7
for <widelake@dreamwiz.com>; Tue, 26 Sep 2006 01:12:12 +0900 (KST)
2. Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230])
by mx-r1.dreamwiz.com (8.13.8/8.13.8) with ESMTP id k8PGCAK0079920
3. Received: by wx-out-0506.google.com with SMTP id s7so1922579wxc
for <widelake@dreamwiz.com>; Mon, 25 Sep 2006 09:12:10 -0700 (PDT)
4. Received: by 10.70.125.11 with SMTP id x11mr7395570wxc;
Mon, 25 Sep 2006 09:12:09 -0700 (PDT)
5. Received: by 10.70.97.2 with HTTP; Mon, 25 Sep 2006 09:12:09 -0700 (PDT)
5번에서 1번 순서로 진행됩니다.
제가 Gmail에서 메일을 작성한 후, Send를 클릭한 시점이 5번입니다. 웹클라이언트 환경이었으니 제 IP는 기록되지 않고, 웹클라이언트를 뿌려주고 있던 서버의 내부 IP – 10.70.97.2(5번) 에서 시작합니다. 10.70.97.2는 제 메일을 10.70.125.11 이라는 서버로 보냅니다(4번). 그런 후 10.70.125.11 서버는 제 메일을 실제 아웃바운딩 서버 – 발송 서버인 wx-out-0506.google.com 으로 보내서, 수신자인 widelake@dreamwiz.com 쪽으로 메일을 실제 보낼 채비를 합니다(3번). wx-out-0506.google.com 은 DreamWiz의 메일 수신 서버인 mx-r1.dreamwiz.com 으로 Connect 한 후 메일을 던집니다(2번). 이 시점에서 Gmail의 역할은 종료되고, 웹클라이언트에서는 무사히 메일을 보냈다는 메시지를 띄웁니다. DreamWiz는 mx-r1으로 들어온 메일의 헤더를 읽어 수신자인 widelake@dreamwiz.com 이 소속되어있는 메일 서버로 보낸 후, INBOX에 넣고 종료합니다(1번).
Received 필드를 포함, 일련의 메일 전송 과정을 볼 수 있는 필드가 Trace fields 입니다. 이 필드 중, 가장 윗 줄에 보시면 Return-path 라는 항목이 있습니다. 리턴 패스는 실제 발송자가 누구냐?를 가릴 수 있는 필드 중 하나로, 현재 모든 웹메일은 리턴 패스를 변경할 수 없으며, 아웃룩 익스프레스를 위시한 대부분의 메일 클라이언트에서도 마찬가지입니다. 다소 용도가 변형되어 쓰이고는 있지만 누가 보냈는지를 확인할 수 있기 때문에 변조를 방지하기 위한 목적입니다. 그러나, 스패머들이 이용하는 메일 발송기나 또는 회사에서 사용하는 대량메일전송기(EMS)에서는 이 리턴패스를 변경할 수 있으며, 대량 메일 전송기가 아니다 하더라도 메일 서버 데몬의 설정을 조금만 변경하면 리턴패스를 변경할 수 있습니다.
이 리턴패스에 지정된 메일 주소는 상대방이 메일을 수신하지 못하는 경우 또는 거절하는 경우 반송사유가 명기된 반송메일을 수신하는 용도로도 사용하게 됩니다. 즉, 상대방에서 내가 이용하는 서버에서 발송된 메일은 스팸이기 때문에 아예 거절한다(reject)는 의사 표명을 하거나, 내가 보낸 메일이 바이러스에 감염된 경우, 서버간 접속 문제때문에 메일을 전송하지 못하는 경우 발송서버는 해당 반송메일을 return-path에 명기된 메일 주소로 전송하게 됩니다.
그렇기 때문에 여기서 발생하는 문제는 – 스패머는 일단 접어두기로 하지요 – 특정 회사나 개인의 홈페이지에서 리턴패스를 다른 포털 메일 서비스의 메일로 지정하는 경우입니다. 만약 해당 서버에서 발송한 메시지가 수신 거절되어 반송될 경우, 이 반송 메일은 리턴패스에 지정한 포털 메일 서비스의 메일로 들어오게 됩니다.
간단히 실물 우편의 경우를 들어 말하자면, 요즘 쇼핑몰이라던지 홈쇼핑 업체에서 보내는 카달록이나 카드사, 이동통신사에서 보내는 요금 청구서는 보내는 사람 외에도 반송처를 따로 명기하고 있습니다. 만약, 수신하는 사람이 이사를 갔다던지 받지 않겠다고 할 경우, 요금 청구서의 경우는 개인정보의 유출 문제도 있을 수 있으니 해당 우편물을 반송처로 배달을 해달라는 뜻이지요. 즉, 실물 우편에서의 “반송처”는, 이메일에서의 “return-path”와 같습니다(단어도 완벽히 같지요).
그런데 만약, C 회사에서 D 고객에서 보낸 실물 우편의 겉봉에, 반송처를 전혀 관계없는 엉뚱한 E 회사로 지정을 한다면 어떻게 될까요? E 회사는 C 회사와는 아무런 관련도 없으며, D 고객과도 전혀 거래 관계가 없는 업체입니다. 만약 D 고객이 C 회사의 우편물을 수신 거절하게 되면 우체국에서는 해당 우편물을 반송처에 써 있는 E 회사로 배달하게 될터인데, 그것이 한두건이면 실수라고나 생각하겠지만, 만약 수천수만통이 E 회사로 오게 된다면 과연 E 회사는 어떻게 생각할까요? 아마 업무 방해로 C 회사를 고소라도 하게 될 겁니다.
그럼, 이메일로 다시 눈을 돌려봅시다. F 라는 사이트에서 G 라는 고객에게 메일을 보냈습니다. 그런데 Return-path를 F 사이트의 메일 주소로 설정하지 않고 H 라는 메일 서비스 업체의 메일 주소로 설정을 했네요. 이 경우 앞서와 같이 F 사이트와 H 메일 서비스 업체는 아무런 관련도 없으며, G 라는 고객은 H 메일 서비스를 사용하지도 않습니다. 그런데 G 고객이 F 사이트의 메일을 수신 거절하거나 서버상 네트웍 문제로 반송하게 된다면, 그 반송 메일은 H 메일 서비스로 들어오게 됩니다. 실물 우편과 마찬가지로 한통 두통이면 문제가 안되겠지만, 그것이 수만~수십만통이 쏟아져 들어오게 된다면 과연 H 메일 서비스 업체는 F라는 사이트에 대해서 어떻게 생각할까요? 도의상 안되는 일 아닐까요?
도의적 책임을 무시한다 하더라도, 현재 한국정보보호진흥원과 제휴하여 국내 대부분의 포털에서 시행하고 있는 SPF(Sender Policy Framework)라는 정책은 이 리턴패스를 기준으로 하게 됩니다.
SPF가 수신단에 적용되어있는 메일 서버는 리턴패스에 적혀있는 메일 주소의 DNS서버(즉, return-path에 widelake@dreamwiz.com 으로 적혀있다면 드림위즈의 DNS 서버)에게 IP 123.123.123.123 이라는 곳에서 온 메일의 리턴패스가 widelake@dreamwiz.com 인데, “이거 니네꺼 맞냐? 틀리면 이거 어떻게 처리할까?”라는 질의를 하게 됩니다. 그러면 DNS 서버는 “음? 이거 우리꺼 아냐. 스팸편지함으로 넣어버려”라는 답변을 하게 되지요(또는 “그냥 거절하고 반송시켜버려”라는 답변을 할 수도 있습니다만, 아직 대부분의 국내 메일 서비스 업체는 스팸편지함으로 넣으라는 답변만 합니다). 그러면 수신메일 서버는 DNS 서버의 응답대로 그 메일을 스팸편지함으로 넣어버리지요. 결국 메일을 사용자의 INBOX에 넣어야한다는 해당 메일의 목적은 달성되지 못하는 것입니다.
이 SPF는 앞서 말한대로 국내 대부분의 포털에 적용되어있으며, 앞으로 관공서, 대기업, 호스팅 서비스 등을 중심으로 점차 확산될 예정이기도 하고, 9월 27일에 보도자료가 나가겠지만 9월 28일부로 국내 포털과 한국정보보호진흥원에서 시행하는 통합 White Domain 등록제에 등록하기 위해서는 이 SPF 레코드의 출판이 필수적입니다. 이 정책은 어디까지나 스팸을 감소시키기 위한 노력의 일환이지만, 어떻게 보면 남의 메일 서비스를 정당치 못하게 이용하는 “얌체”를 걸러내기 위한 방법이 될 수도 있겠네요.
하지만, SPF니 뭐니 하는 정책 때문에 얌체짓을 그만하는 것이 아니라, 기업간 매너, 또는 사용자와 기업간의 지켜야할 선을 지켜야하기 때문에 리턴패스를 포털 메일 서비스로 지정하는 행동은 그만해야하지 않을까 싶습니다. 그리고, 이런 행동은 어디까지나 전 포털 메일 서비스에서 금하고 있는 메일 서비스의 상업적 이용에 해당하는 행위이고, 때문에 해당 서버가 필터링된다 하더라도 포털에서는 면책을 할 수 있는 항목입니다. 자기 메일 서버 널널하게 쓰겠다고, 해당 포털 메일을 쓰는 다른 사용자들을 불편하게 한다면, 양심이 없는거죠.
PS.
“답장을 받으려고…” 하는 분도 있었습니다만, 답장을 받기 위해서는 회신주소, 즉 Reply-to를 지정하면 됩니다. 앞으로 DKIM, Sender-ID 등 다른 정책 등이 실행되는 곳에서는 From도 체크하기 때문에 회신 주소의 설정을 위해서는 반드시 Reply-to를 이용해야합니다. 더군다나 대부분 DM은 발신전용이기 때문에 답장을 받기 위함이는 얘기 자체가 변명꺼리 밖에 되지 않지요.
쏟아지는 반송메일을 보지 않고 버리기 위해서라면, 차라리 메일 서버에서 반송메일로 들어오는 메일들은 읽지 않고 바로 지워버리면 그만입니다. 그거 하기 싫다고, 다른 회사 메일 서비스의 메일 주소로 리턴패스를 지정하는 건, 정말 얌체죠. 자기 편하겠다고 남 회사 트래픽만 잔뜩 안겨주는데, 이 행동이 과연 자기 사무실 쓰레기를 다른 회사 우편 수발함에 가져다 부어넣는 행위와 다른 바가 있을까요? ⓣ
