[DNS] SPF

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

 - 메일서버 정보를 사전에 DNS에 공개 등록함으로써 수신자로 하여금 이메일에 표시된 발송자 정보가 실제 메일서버의 정보와 일치하는지를 확인할 수 있도록 하는 인증기술

 

 * 대다수 스팸발송자가 자신의 신원을 감추기 위하여 발송자 주소나 전송경로를 허위로 표기하거나 변경하는 경우가 많다는데 착안

 

SPF를 이용한 이메일 인증절차

 - 발신자 : 자신의 메일서버 정보와 정책을 나타내는 SPF 레코드를 해당 DNS에 등록

 - 수신자 : 이메일 수신시 발송자의 DNS에 등록된 SPF 레코드를 확인하여 해당 이메일에 표시된 발송IP와 대조하고 그 결과 값에 따라 수신여부를 결정(메일서버나 스팸차단솔루션에 SPF 확인기능이 설치되어있어야함)

 

SPF 개발 및 도입 현황

 - 1998년 Paul Vixie의 'Repudiating Mail From'에서 처음으로 아이디어가 제안된 이후 Pobox.com의 Meng Weng Wong에 의해 SPF가 개발됨

 - 2004년 2월 IETF(Internet Engineering Task Force)에 공식 RFC(request For Comments)로 제안되었으며, 2004년 12월 SPF의 모든 기술적 내용들이 최종 완성됨

 - SPF는 타 인증기술에 비해 적용이 용이하고 호환성이 좋으며 오픈소스를 기반으로 하므로 전 세계적으로 폭넓은 지지기반을 확보하고 있음

 - 한국을 비롯한 미국, 캐나다 일본 등 여러 국가들이 정부차원에서 사업자들을 대상으로 SPF 레코드 출판 및 확인 기능 도입을 통한 스팸차단 활용을 적극 권고하고 있음

 

SPF Record Syntax

 - 도메인은 0개 이상의 메커니즘(mechanisms)을 정의할 수 있다. 메커니즘이란 해당 도메인에서 발송서버로 지정된 호스트의 질의 형식이라고 생각하면 된다.

   all   ip4   ip6   a   mx   ptr   exists   include

위와 같이 총 8개의 메커니즘이 존재한다.

 

메커니즘 앞에는 다음과 같은 4개의 수식자(qualifiers)가 붙을 수 있다. 기본 값은 + 이다.

"+" Pass

"-" Fail

"~" SoftFail

"?" Netural

 

메커니즘은 순차적으로 평가되며 매치되는 항목이 없을 경우 기본 결과값은 Netural이다.

 

어떤 도메인 SPF 값을 DNS서버에 등록해 놓지 않은 경우 그 결과값은 None이다. DNS 처리 과정에서 일시적인 에러가 발생하였다면 결과값은 TempError이다. 문법적으로 잘못된 SPF 정보가 등록되었을 경우 결과값은 PermError이다.

 

 

 - "all" 메커니즘

이 메커니즘은 항상 매치된다. 주로 SPF 레코드의 가장 마지막에 온다.

 

EX)

"v=spf1 mx -all"

해당 도메인(SMTP 명령어 중 MAIL FROM에 사용되는 이메일 주소의 @ 뒷부분)의 MX서버를 질의하여 발송서버의 IP가 MX서버의 IP와 일치하면 수신허용. 그렇지 않은 모든 경우는 수신거부

 

"v=spf1 -all"

해당 도메인은 어느 서버에서도 메일을 발송하지 않음

 

"v=spf1 +all"

해당 도메인은 SPF레코드가 쓸모없다고 생각하며 전혀 신경쓰지 않음.(어떤 IP에서 접촉하든 수신허용이라는 뜻이므로)

 

 - "ip4" 메커니즘

ip4: <ip4-address>

Ip4:<ip4-network>/<prefix-length>

 

Ip4 mechanism 인자값은 IPv4의 네트워크 범위이다. Prefix-length가 정의되지 않았다면 기본값은 /32이다.

 

EX)

"v=spf1 ip4:192.168.0.1/16 -all"

192.168.0.1 와 192.168.255.255 사이의 IP주소만 pass하고 나머지는 fail

 

 - "ip6" 메커니즘

Ip6:<ip6-address>

Ip6:<ip6-network> / <prefix-length>

 

"ip6:" mechanism 인자값은 IPv6 네트워크 범위이다. Prefix-length가 정의되지 않았다면 기본값은 /128이다.

 

EX)

"v=spf1 ip6:1080::8:800:200C:417A/96 -all"

1080::8:800:00000000와 1080::8:800:FFFF:FFFF 사이의 IP주소만 pass, 나머지는 fail.

 

 - "a" 메커니즘

a

a/<prefix-length>

a:<domain>a:<domain>/<prefix-length>

 

해당도메인의 모든 A 레코드를 테스트한다. 발송서버의 IP가 그 중하나라도 일치하면 pass

 

"v=spf1 a -all"

현재 도메인을 테스트한다.

 

"v=spf1 a:example.com -all"

현재 도메인이 example.com이라면 위와 동일하다.

 

"v=spf1 a:mailers.example.com -all"

mailers.example.com 의 A레코드를 질의하여 나온 IP주소가 발송서버의 IP주소와 일치하면 통과

 

 - mx메커니즘

a 메커니즘과 유사하게 DNS에 각각 A대신 MX와 PTR레코드를 질의하여 그 결과값으로 판단한다.

 

 - ptr 메커니즘

ptr

ptr:<domain>

 

발신서버의 IP주소에 대한 PTR 질의를 통해 호스트명을 찾아낸 후 호스트명을 가지고 판단한다. 찾아낸 호스트의 A레코드 중 최소 하나이상이 발신서버의 IP와 일치하여야한다. 도메인 명이 명시되지 않았다면 현재 도메인이 사용된다. 가능하다면 이 메커니즘은 사용을 피해야하는데 과도한 DNS질의를 수행하게 되기 때문이다.

 

EX)

"v=spf1 ptr -all"

모든 서버를 직접 관리하는 ㅗ메이의 경우 이 모든 서버들로부터 메일이 발송되는 것을 허용할 수 있다. 예를 들어 hotmail.com이나 paypal.com은 이와같은 SPF를 정의할 수도 있다.

 

"v=spf1 ptr:otherdomain.com -all"

도메인 명이 otherdomain.com으로 끝나는 모든 호스트명을 지정

 

 - "exists" 메커니즘

주어진 도메인에 대한 A 타입 질의를 수행하여 결과가 나온다면 통과.

결과로 나온 IP주소가 어떠한 것이든 상관없다.

 

EX)

다음 예에서 발신서버의 IP주소는 1.2.3.4 이고 현재 도메인은 example.com이다.

"v=spf1 exists:example.com -all"

만약 example.com에 대한 A 질의가 실패한다면 결과도 실패이다. 질의결과가 성공이면(A레코드가 발견되면) 통과이다.

 

 - "include" 메커니즘

Include:<domain>

 

주어진 도메인에 대한 SPF질의를 수행한다. 만약 해당 도메인이 유효한 SPF정보를 가지고 있지 않다면 결과는 permanent error이다.

 

EX)

다음 예에서 발신서버의 IP주소는 1.2.3.4이고 현재 도메인은 example.com이다.

"v=spf1 include:example.com -all"

 

example.com 이 SPF 정보를 가지고 있지 않다면 결과는 PermError이다.

example.com의 SPF record정보가 "v=spf1 a -all"인 경우를 가정해보면 example.com의 A타입 질의를 수행한 결과가 1.2.3.4 라면 통과이다.

 

만약 매치되는 결과가 없다면 include는 실패이고 이 에에서 전체적인 결과도 실패이다.

 

신뢰관계 - include 메커니즘은 도메인 간의 상호 관리 범위를 의미한다. Include를 사용할 경우에는 악의적 사용자에게 이용되지 않도록 주의하여야한다. 정의된 외부 도메인에 악의정 사용을 제한할 수 있는 기술적 장치가 없다면 inlcude 앞에 "?"를 붙임으로써 이러한 방법이 가능하며 이런 모양이 될 것이다.

"v=spf1 ?include:example.com -all"

 

[중요]KISA에서 관리하는 통합 White Domain List에 등록하기 위해서는 ipv4 메커니즘만 사용해야한다.