요즘 간간히 받는 질문입니다.
“SPF 출판하고 KISA 화이트 도메인 등록 다 했는데 정작 발송한 메일은 스팸편지함으로 들어가요.”
그런 경우는 대표적인 두가지 이유가 있는데, 일단은 공통적으로는 SPF(Sender Policy Framework) 스펙 위반입니다. 되는대로 DNS에 SPF 레코드 등록하고 KISA 화이트 도메인 등록된다고 장땡이 아니란 말씀되겠습니다.
SPF 레코드를 출판한다는 것 자체가 “발송자 메일 주소에 A 도메인을 사용하는 메일은 B IP 주소에서만 발송됩니다. B IP 주소가 아닌 다른 IP 주소에서 발송되면 스팸으로 처리해주십시오”라는 의사의 표명입니다. 즉, 발송자의 의지란 얘기가 되겠죠. SPF 적용전 각 메일 수신단에서 도메인 사칭 필터를 운용하던 때와는 정반대의 입장이 됩니다.
각 메일 수신단(웹메일 같은…)에서 사칭 필터를 운용하던 때는 메일 수신 불가에 대한 책임 소재의 일정 부분은 수신단에 있었습니다. 발송 측에서 발송 서버를 미리 알려주지 않는다면 스팸 신고된 결과물을 토대로 사칭 필터를 운용할 수 밖에 없는데, 발송 서버야 수시로 변경될 수도 있고, C 내용을 담고 있는 메일은 D 서버에서 발송되고, E 내용을 담고 있는 메일은 F 서버에서 발송되는 등 변수가 많아 그만큼 오차단이 발생할 수 밖에 없었습니다. 국내 부지런한 회사들이야 비정기적으로 메일 발송 서버 목록을 통보해주는 등 조치를 했습니다만, 뭐 여러가지 문제가 많았죠.
SPF를 도입하면서부터 상황이 바뀌었습니다. 수신단은 더 이상 기존 개념의 도메인 사칭 필터를 운용할 필요가 없어졌습니다. 발송 메일 주소 도메인에 심겨져있는 SPF 레코드와 발송 서버의 IP를 매칭하여 맞으면 PASS, 안 맞거나 오류가 있을 경우 Fail 또는 SoftFail 처리하면 됩니다. 거기에 SPF 레코드의 스위치는 SPF 레코드와 발송 서버의 IP가 매칭되지 않는 메일에 대해 스팸편지함으로 넣느냐, 아니면 아예 반송 처리하느냐에 대해 발신자가 스스로 처리 방법을 지정할 수 있도록 하고 있습니다. 수신단은 그에 맞게 처리만 하면 됩니다(참고로 2008년 11월 현재 국내 대부분의 웹메일에서는 -all 등의 Fail 오류에 대해서도 반송 처리하지 않고 ~all 등의 SoftFail 와 같게 스팸 편지함으로 분류하고 있습니다).
SPF 레코드는 초기에는 인식이 덜 되어 도입에 난항을 겪었으나, 2006년 9월 28일부터 국내 10개 포털 메일 사업자가 KISA(한국정보보호진흥원)에 각사별 화이트 IP를 통합 위탁 운영하는 KISA 화이트 도메인 제도가 본격적으로 시작되면서부터 많은 도메인에 SPF 레코드가 출판되기 시작했습니다. KISA 화이트 도메인에 등록하기 위해서는 SPF 레코드의 출판이 필수 조건이기 때문입니다.
SPF 관련하여 가장 많은 문의가 들어오는 두가지 경우가 있습니다.
※ SPF 레코드는 nslookup에서 set type=txt를 주면 조회할 수 있습니다.
① SPF 레코드에 정의된 IP와 실제 발송 서버가 다를 때
예를 들어 위에 언급한 KISA의 도메인 주소인 kisa.or.kr 에 정의되어있는 KISA의 메일 발송 IP 주소가 아닌 다른 IP 주소로부터 @kisa.or.kr 도메인을 발송자 메일 주소로 사용하여 메일을 발송하는 경우입니다. kisa.or.kr 에 정의되어있는 SPF 레코드는 2008년 11월 현재 아래와 같습니다.
“v=spf1 ip4:211.252.150.22 ip4:211.252.150.23 ip4:211.252.150.33 ip4:211.252.150.47 ip4:211.252.150.16 ip4:221.143.30.34 ip4:123.251.254.2 ip4:114.31.57.34 ip4:114.31.57.35 ip4:203.237.66.13 ip4:203.237.66.6 -all”
그런데 메일을 발송할 때 발송 서버가 위에 있는 IP 주소가 아닌, 가령 123.123.123.123라는 IP 주소를 가졌다면 SPF 레코드의 IP 주소와 불일치합니다. 이 때, -all 이라는 스위치에 의하여 Fail 처리되어, 원칙적으로는 반송 처리하게 됩니다(물론 위에서 얘기했듯 대부분의 웹메일에서는 스팸 편지함으로 분류합니다).
해결 방법은 SPF 레코드에 발송 서버의 IP 주소를 추가하거나 변경하면 됩니다.
② SPF 레코드를 다중으로(Multiple) 출판했을 때
의외로 이런 경우가 있더군요. SPF 스펙상 다중으로 SPF 레코드가 출판되면 SPF 레코드의 인증이 되지 않아 PermError 처리됩니다. 수신단의 처리에 따라 반송 처리될 수도 있습니다.
SPF Records – Publishing – Multiple DNS Records
3.1.2. Multiple DNS Records
A domain name MUST NOT have multiple records that would cause an authorization check to select more than one record.
예를 들어 kisa.or.kr 의 SPF 레코드가 위의 모양이 아닌 아래처럼 되어있으면 PermError가 발생합니다.
“v=spf1 ip4:211.252.150.22 ip4:211.252.150.23 ip4:211.252.150.33 ip4:211.252.150.47 ip4:211.252.150.16 ip4:221.143.30.34 ip4:123.251.254.2 -all”
“v=spf1 ip4:114.31.57.34 ip4:114.31.57.35 ip4:203.237.66.13 ip4:203.237.66.6 -all”
해결 방법은 여러개로 나뉘어져있는 SPF 레코드를 한개로 합쳐주면 됩니다. 단, IP가 너무 많아 SPF 레코드의 문자열이 255자를 넘는다 그러면 클래스 단위로 정의하시거나, include 또는 redirect 스위치를 사용할 수 있습니다(참고 : 구글 앱스 이메일에 SPF 레코드 출판하기).
참고로, 국내 굴지의 모 보안업체(안철수연구소라고 말 못함)는 제가 작년 10월 중순 경 ②번에 해당하는 현상에 대해 설명 및 조치 방법을 담은 변경 요청 메일을 보내드렸음에도 불구하고 괜시리 서버 호스팅하는 LG데이콤을 통해서 이상하게 따지더니 여전히 해결 안하고 계십니다. 사용자 컴플레인이 심해서 일단 SPF 레코드 위반에도 불구하고 정상 수신되도록 해놓긴 했는데, 그러면서 뭔 보안 사업을 한다는건지 솔직히 이해할 수가 없습니다. 제품 기능 중에 안티 스팸도 있으면서. 😛 ⓣ
