SPF(Sender Policy Framework) : 메일서버등록제

현재, 한국정보보호진흥원(KISA)의 주도로, 국내 각 포털 메일 서비스는 SPF(Sender Policy Framework), 번역하여 메일서버등록제에 참여하고 있습니다. 2005년 8월부터 준비 및 시행이 되었으니 벌써 2년이 다 되어갑니다.

SPF는 간단히 말해서, @A.com 이라는 도메인을 발신 주소의 도메인을 사용하는 메일은 반드시 특정 IP에서만 발송된다라는 것과, 특정 IP에서 발신되지 않은 메일에 대한 처리 방법을 발신 도메인의 DNS에 기록하고, 수신쪽에서 DNS에 기록된 SPF 레코드를 참조하여 실제 메일이 발송된 IP와 SPF 레코드 상의 발신 서버가 일치하는지 여부를 판단하여, 일치하지 않는 경우 SPF 레코드에 기록된 처리 방법에 따라 해당 메일을 처리하는 일련의 절차를 뜻합니다.

SPF가 나오게 된 배경은, 메일 전송시 기본적으로 사용하는 SMTP(Simple Mail Transfer Protocol)이 이름 그대로 너무나 간단하여 실제 발송자를 인증할 수 있는 기능이 없기 때문에 이를 보완하고자 하는 일련의 움직임에서 비롯되었습니다. SPF가 막 시장의 주목을 획득할 무렵 MS의 SIDF(Sender-ID Framework), Yahoo!의 DomainKeys(이후 CISCO의 Identified Internet Mail와 결합하여 DomainKeys Identified Mail(DKIM)로 발전하였으며, DKIM은 2007년 5월 22일 IETF에 의해 RFC 4871로 표준 채택/2011년 1월 현재 RFC 5672로 개정되었습니다) 등이 등장했습니다만, 현재의 발송자 인증 기술의 표준 채택은 DKIM이 먼저 앞서나가기 시작했습니다(2011년 1월 현재까지 SPF는 RFC 4408로 Experimental 트랙에 머물러 있습니다)

간단하게, SPF 레코드가 어떻게 작성되어있는지 몇몇 샘플을 보겠습니다. 시작 – 실행 – cmd 로 들어가셔서 커맨드 콘솔로 들어가신 후, nslookup을 실행시킨 다음 set type=txt 를 줘서 txt 필드를 조회할 수 있게 하고 도메인을 치면 나옵니다.

hanmail.net     text =
“v=spf1 ip4:211.43.197.0/24 ptr ~all”
 
naver.com       text =
“v=spf1 ip4:220.95.234.208 ip4:61.74.70.0/23 ip4:222.122.16.0/24 ip4:220.73.156.0/24 ip4:211.218.150.0/24 ip4:211.218.151.0/24 ip4:211.218.152.0/24 ip4:218.145.30.0/24 ip4:220.95.237.0/24 ~all”
 
dreamwiz.com   text =
“v=spf1 ip4:211.39.128.0/24 ip4:211.39.129.0/24 ip4:222.122.42.0/25 ~all”
 
aol.com text =
“v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all”
“spf2.0/pra ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all”
 
gmail.com       text =
“v=spf1 redirect=_spf.google.com”
 
hotmail.com     text =
“v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com include:spf-d.hotmail.com ~all”

업체별로 명기되어있는 IP 갯수도 다르고 처리 방법도 다르고, 표기하는 방법도 다릅니다. 옵션이 몇가지 있기 때문입니다. 옵션은 공식홈페이지(http://www.openspf.org)를 참고하세요.

위의 예시들 중 한메일은 이렇게 해석할 수 있습니다.

“v=spf1 ip4:211.43.197.0/24 ptr ~all”

해석: hanmail.net을 발신 메일 주소의 도메인으로 지정한 메일 중 PTR(Pointer Record)이 부여되어있는 211.43.197.0/24 C클래스(211.43.197.0~211.43.197.255)에서 발송되지 않은, 즉 다른 IP 대역에서 발송되었거나 해당 클래스 내에서도 PTR이 없는 IP에서 발송된 메일은 스팸처리하세요. 단, 완전히 반송시키지는 말고 grey 처리하여 광고(스팸)편지함으로 분류해주세요.

그렇다면 아주아주 간단하게 써있는 Gmail은 어떻게 될까요.

gmail.com       text =
“v=spf1 redirect=_spf.google.com”

역시 Gmail 답게 심플하게 레코드를 적어…. 둔 것 같죠? redirect 스위치가 붙어있습니다. 즉, SPF 레코드가 이중으로 구성되어있으며, _spf.google.com의 레코드를 다시 참조해야합니다.

_spf.google.com text =
“v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ?all”

해석: Gmail.com을 발신 메일 주소의 도메인으로 지정한 메일 중 216.239.32.0/19, 64.233.160.0/19, 66.249.80.0/20, 72.14.192.0/18, 209.85.128.0/17, 66.102.0.0/20 에서 발송되지 않은, 즉 다른 IP 대역에서 발송된 메일은 그냥 내버려두세요(?all). 참 오지랖 넓군요. -_-;

참고로 Gmail에서 발송IP로 지정한 IP는… /17(32,768개) * 1대역, /18(16,384개) * 1대역, /19(8,192개) * 2대역, /20(4,096개) * 2대역으로… 32,768 + 16,384 + 16,384 + 8,192 = 총 73,728개의 IP가 메일을 발송할 수 있는 서버 IP로 지정되어있습니다. 한가지 더, google.com의 SPF 레코드는 “v=spf1 ptr ?all” 로 발송IP의 PTR만 존재하면 google.com에서 보낸 메일이 맞다고 판단하면 된다는 뜻입니다.

* PTR 레코드는 nslookup에서 type을 ptr로 준 다음(set type=ptr), 아이피를 뒤집은 다음 .in-addr.arpa를 붙여서 쿼리하면 됩니다.

> set type=ptr

> 25.203.14.72.in-addr.arpa

Server:  UnKnown

Address:  192.168.0.1

25.203.14.72.in-addr.arpa       name = smtp1.google.com

203.14.72.in-addr.arpa  nameserver = NS3.google.com

203.14.72.in-addr.arpa  nameserver = NS4.google.com

203.14.72.in-addr.arpa  nameserver = NS1.google.com

203.14.72.in-addr.arpa  nameserver = NS2.google.com

NS3.google.com  internet address = 216.239.36.10

NS4.google.com  internet address = 216.239.38.10

NS1.google.com  internet address = 216.239.32.10

NS2.google.com  internet address = 216.239.34.10

SPF가 SMTP의 발신자 인증 기술의 결여를 채워주는 것은 맞습니다만, 완전하지 못합니다. 그렇기 때문에 아직 RFC에 Proposed standard도 아닌 Experimental 으로 올라가 있고, 여러가지를 결합하여 발신자를 판단하는 DKIM은 Standard Track에 올라간 것입니다. SPF는 현 상태에서 어디까지나 보조적인 역할로만 사용해야하며, 그나마도 예전 YES24의 경우처럼 잘못 설정되어있는 경우가 많기 때문에 100% 신뢰하기는 현 시점에서는 어렵습니다.

그러나 간단하고 적용하기 쉽다는 점에서만은 어떠한 발신자 인증 기술보다도 경쟁력이 있습니다. DNS의 text 필드만 업데이트해주면 되니까요(물론 메일을 수신하는 쪽은 데몬을 설치하고 SPF 레코드에 따른 필터링 규칙을 넣는 등 일이 좀 생깁니다만은). 간단한 만큼 Sender-ID처럼 타 기술과 결합하여 보완해줄 수 있는 보완재 역할은 충분히 해줄 수 있습니다. 그러니까 아무 쓸모없다고 마냥 구박하기에는 뭔가 미안하기도 할 뿐더러, 처음에 얘기했듯이 국내 대부분의 포털 메일에는 수신단에 SPF 레코드를 체크할 수 있는 데몬이 설치되어있으며, 각 포털 메일의 White IP 등록제를 통합한 KISA(한국인터넷진흥원)의 KISA White Domain 등록제에 등록하기 위한 필수요건이 SPF 레코드의 설정이기 때문에 메일을 보내시는 분들은 반드시 참고하시는게 좋겠습니다. ⓣ