15장 SPF(Sender Policy Framework)를 사용하여 위조된 전자 메일 처리

스팸 제작자와 전자 메일 사기범은 가짜 도메인 이름과 전자 메일 주소 또는 합법적인 도메인 이름과 전자 메일 주소를 사용하여 전자 메일을 위조함으로써 사용자가 알고 있는 회사에서 온 메일인 것처럼 위장합니다. 예를 들어, president@whitehouse.gov와 같은 전자 메일 주소를 사용해서 전자 메일을 보내면 사용자는 실제로 메일이 그 주소에서 왔다고 믿을 수 있습니다. 전자 메일을 위조하는 기법은 사용자가 신청하지 않은 메일을 열게 만들거나 엉뚱한 곳에 정보를 제공하게 만드는 일에 사용됩니다. 또한, 스팸 발송자들은 전자 메일을 RBL 목록에 없는 합법적인 도메인에서 보내고 싶어 합니다.

SPF(Sender Policy Framework)는 SMTP 대화 중에 위조된 전자 메일을 감지하여 거부할 수 있는 기술입니다. SPF는 도메인 이름을 사용할 수 있는 호스트를 도메인에서 명시적으로 인증하도록 허용하는 프로토콜입니다. 이 인증 정보를 확인하도록 받는 호스트를 구성할 수도 있습니다. 이러한 방식으로 SPF는 위조된 전자 메일의 수를 줄일 수 있습니다.

• 15.1 작동 원리

• 15.2 제한

• 15.3 배포 전 고려 사항

• 15.4 기술 설정

• 15.5 참조 정보

• 15.6 spfquery를 사용하여 SPF 테스트

• 15.7 SRS(Sender Rewriting Scheme)를 사용하여 SPF에서 전달된 메일 처리

15.1 작동 원리

Messaging Server에 메시지가 오면 MTA는 SPF 쿼리를 통해 주소가 실제로 주소에 있는 도메인으로부터 왔는지 확인합니다. SPF 쿼리에서는 DNS를 참조하여 메시지의 도메인(domain)에 속한 TXT 레코드를 찾습니다. Domain은 HELO 또는 EHLO(spfhelo 채널 키워드를 사용하는 경우) 인수로 지정한 도메인 이름이거나 MAIL FROM: 명령으로 지정한 발송자 주소의 도메인 이름입니다(보통 @ 문자 뒤에 오는 부분). 도메인 이름이 지정되지 않았거나 도메인 이름을 사용할 수 없는 경우에는 HELO/EHLO를 사용하는 동안 지정된 값이 domain으로 사용됩니다. 대부분의 ISP는 도메인과 일치하는 인증된 IP 목록을 배포합니다. IP 주소가 도메인 이름과 일치하지 않는 경우에는 메시지가 위조된 것으로 간주됩니다.

보통은 DNS를 쿼리하기 전에 SPF_LOCAL 매핑 테이블에서 일치하는 도메인을 확인합니다. 일치하는 항목이 발견되면 해당 항목을 먼저 사용합니다.

매핑 테이블에서 찾은 레코드에 redirect=domain 절이 포함되어 있으면 DNS 쿼리를 통해 도메인으로 리디렉션해서 반복적인 매핑 파일 확인을 건너뜁니다.

결과 TXT 레코드의 예는 다음과 같습니다.

v=spf1 +mx a:colo.siroe.com/28 -all

이 RFC에서 지원되는 SPF 레코드에는 v=spf1 토큰이 필요합니다.

+mx는 MX 레코드에서 domain을 검사하고 이 SMTP 연결의 소스 IP 주소가 domain의 MX 쿼리 결과로 얻은 IP 주소 중 하나와 일치하는지 확인하도록 지시합니다. 일치하는 항목이 있는 경우 표시되는 +는 결과가 Pass임을 의미합니다.

a:colo.siroe.com/28은 colo.siroe.com의 A 레코드를 검사한 후 28비트만을 비교하여(255.255.255.240에 대해 마스크 처리됨) 이 SMTP 연결의 소스 IP 주소가 A 레코드에 지정된 것과 동일한 CIDR 서브넷에 있는지 확인합니다. 한정자가 지정되지 않았기 때문에 기본값은 결과가 Pass임을 의미하는 +입니다.

마지막으로 -all은 다른 모든 부분을 일치시키고 결과로 Fail을 결정합니다. SPF 레코드에 대한 자세한 내용은 http://www.ietf.org/rfc/rfc4408.txt에 있는 RFC 4408을 참조하십시오.

SPF 처리 결과는 여러 항목 중 하나일 수 있습니다. 아래 표에는 결과와 그 설명이 표시됩니다.

SPF 처리가 완료되고 나면 메시지에 Received-SPF: 헤더가 기록되어 SPF 처리의 결과를 나타냅니다. 이 헤더는 시브(Sieve) 처리 중에 쿼리하여 이후의 고려에 반영할 수 있습니다. option.dat 파일에서 MTA 옵션 MM_DEBUG를 활성화한 경우(>0) 본격적인 디버깅을 사용할 수 있습니다.

15.2 제한

SPF는 스팸 방지를 위해 사용할 수 있는 도구 중 하나에 불과하며, 모든 문제를 처리할 수는 없습니다. 스팸 발송자가 도메인을 만들고 도메인이 합법적인 것처럼 보이게 만드는 SPF TXT 레코드를 추가하는 일은 쉽습니다. 한편, SPF 실패를 피할 수 있는 TXT 레코드는 많지만, 잘 알려진 ISP에서 위조된 전자 메일이 오는 경우 SPF에서 효과적으로 감지할 수 있습니다.

15.3 배포 전 고려 사항

모든 메시지에 대해 DNS 쿼리를 수행해야 하기 때문에 매우 빠른 DNS 서버를 갖추는 것이 중요합니다.

15.4 기술 설정

SPF 기술 설정은 두 단계를 통해 이루어집니다.

• 받는 TCP 채널에 채널 키워드를 포함합니다. 보통은 tcp_local 채널이 사용되지만 tcp_local에서 다른 채널로 채널 전환을 허용하는 경우에는 다른 채널을 사용할 수도 있습니다. 표 15–2를 참조하십시오.

• option.dat 파일에서 옵션을 설정합니다. 표 15–3을 참조하십시오.

15.5 참조 정보

이 절에서는 SPF 채널 키워드와 SPF MTA 옵션에 대한 참조 정보를 제공합니다. SPF 지원은 받는 tcp_* 채널(보통은 tcp_local)에 적용되는 네 개의 채널 키워드를 통해 구현됩니다. 다음 표에는 키워드와 해당 설명이 나와 있습니다.

spfmailfrom과 spfrcptto는 혼동되기 쉬운 키워드이기 때문에 채널에는 두 키워드 중 하나만 지정해야 합니다. 하지만 spfhelo를 spfmailfrom 또는 spfrcptto와 함께 사용하면 두 종류의 SPF 검사를 모두 수행할 수 있습니다.

SPF 처리를 제한하고 다양한 SPF 결과(Fail, SoftFail, PermError 및 TempError 포함)에 따라 SMTP 명령을 받을 것인지, 4xx 회신과 함께 실패할 것인지(임시 실패) 또는 5xx 회신과 함께 실패할 것인지(영구 실패) 제어하는 추가 지원이 있습니다.

option.dat에서 다음 MTA 옵션을 사용하여 SPF 처리에 제한을 적용할 수 있습니다.

또한, option.dat에서 다음 MTA 옵션을 구성하여 SPF 결과(Fail, SoftFail, PermError 및 TempError)에 대한 회신으로 SMTP 서버의 동작을 제어할 수 있습니다. 각 결과에 대해 SMTP 서버는 2xx(성공) 응답, 4xx(임시 실패) 또는 5xx(영구 실패)를 반환할 수 있습니다. 또한 Fail 및 SoftFail의 경우 MTA는 SPF 결과를 "모든" 기법의 결과와 기타 방법으로 명시적으로 참조된 일치로 구분할 수 있습니다. 그런 다음 특정 결과와 SPF 레코드의 기본 결과로 구분할 수 있습니다. 이 모든 옵션에서 유효한 값은 2, 4 또는 5입니다. 2, 4 또는 5 값은 특정 SPF 상태를 가져온 결과로 SMTP에서 나타나는 2xx, 4xx 또는 5xx 응답에 해당됩니다. 따라서, 예를 들어 SPF_SMTP_STATUS_FAIL=2와 SPF 레코드가 "-a:192.168.1.44"(이쪽 IP 주소)를 사용하여 명시적으로 차단하는 경우 5xx 응답을 보내기 전에 대신 "250 OK"로 주소를 받습니다.

15.6 spfquery를 사용하여 SPF 테스트

이 테스트 유틸리티를 사용하여 SPF 처리를 테스트할 수 있습니다.

spfquery는 SPF 구성을 테스트하지 않습니다. 여기서는 SPF 처리를 활성화하는 경우에 반환되는 내용을 테스트합니다.

요구 사항: Messaging Server 이진 실행 액세스 권한과 루트 또는 mailsrv 등의 라이브러리에 대한 액세스 권한이 있는 사용자로 실행해야 합니다.

위치: msg-svr-base/sbin/

15.6.1 구문

spfquery [-i ip-address] [-s sender-email] [-h helo-domain]
  [-e none | neutral | pass | fail | temperror | permerror] [-v] [-V] [?] domain

다음 표에는 spfquery 옵션과 해당 설명이 표시되어 있습니다.

-?

15.6.2 디버깅을 사용하는 경우의 예

# /opt/SUNWmsgsr/sbin/spfquery -v -i 192.168.1.3 11.spf1-test.siroe.com
    Running SPF query with:
      IP address: 192.168.1.3
          Domain: 11.spf1-test.siroe.com
          Sender: postmaster@11.spf1-test.siroe.com (local-part: postmaster)
     HELO Domain: 11.spf1-test.siroe.com

    15:30:04.33: ----------------------------------------------------------------
    15:30:04.33: SPFcheck_host called:
    15:30:04.33:       source ip = 192.168.1.3
    15:30:04.33:          domain = 11.spf1-test.siroe.com
    15:30:04.33:          sender = postmaster@11.spf1-test.siroe.com
    15:30:04.33:      local_part = postmaster
    15:30:04.33:     helo_domain = 11.spf1-test.siroe.com
    15:30:04.33:
    15:30:04.33:   Looking up "v=spf1" records for 11.spf1-test.siroe.com
    15:30:04.35:     DNS query status: Pass
    15:30:04.35:       "v=spf1 mx:spf1-test.siroe.com                  -all"
    15:30:04.35:
    15:30:04.35:   Parsing mechanism: " mx : spf1-test.siroe.com"
    15:30:04.35:     Assuming a Pass prefix
    15:30:04.35:     Processing macros in spf1-test.siroe.com
    15:30:04.35:     Comparing against 192.168.1.3
    15:30:04.35:     Looking for MX records for spf1-test.siroe.com
    15:30:04.41:       mx02.spf1-test.siroe.com:
    15:30:04.41:         192.0.2.22 - No match
    15:30:04.41:         192.0.2.21 - No match
    15:30:04.41:         192.0.2.20 - No match
    15:30:04.41:         192.0.2.23 - No match
    15:30:04.41:       mx01.spf1-test.siroe.com:
    15:30:04.42:         192.0.2.13 - No match
    15:30:04.42:         192.0.2.11 - No match
    15:30:04.42:         192.0.2.12 - No match
    15:30:04.42:         192.0.2.10 - No match
    15:30:04.42:       mx03.spf1-test.siroe.com:
    15:30:04.42:         192.0.2.32 - No match
    15:30:04.42:         192.0.2.30 - No match
    15:30:04.42:         192.0.2.31 - No match
    15:30:04.42:         192.168.1.3 - Matched
    15:30:04.42:   Mechanism matched; returning Pass
    15:30:04.42:
    15:30:04.42:   Parsing mechanism: "- all : " (not evaluated)
    15:30:04.42:
    15:30:04.42: SPFcheck_host is returning Pass
    15:30:04.42: ----------------------------------------------------------------

15.7 SRS(Sender Rewriting Scheme)를 사용하여 SPF에서 전달된 메일 처리

위에서 설명한 대로, SPF는 메일 FROM:(봉투의 From) 주소에서 도메인과 연결된 특수 TXT 레코드를 조회하여 전자 메일 위조를 방지하는 기법입니다. 실제로는 여러 DNS 조회가 수행될 수 있는 이 작업은 결과적으로 도메인으로부터 메일을 보낼 수 있는 권한이 부여된 IP 주소의 목록을 만듭니다. 이 목록에 대해 SMTP 클라이언트의 IP 주소를 검사하며, 해당 IP 주소가 발견되지 않으면 메시지가 사기로 간주될 수 있습니다. SPF 지원은 Messaging Server 버전 6.3에서 구현되었습니다.

SPF는 메일 전달 서비스를 제공하는 사이트(예: 졸업생에게 서비스를 제공하는 대학교 또는 회원들에게 서비스를 제공하는 전문 기관)에서 심각한 문제가 됩니다. 전달자는 임의의 발송자로부터 온 메일을 보내게 됩니다. 이 발송자에는 SPF 정책을 구현한 발송자와 전달 시스템의 IP 주소를 도메인의 주소를 사용하도록 허용된 주소로 나열하지 않은 발송자도 포함될 수 있습니다.

SRS(Sender Rewriting Scheme)는 이 문제에 대한 해결책을 제시합니다. SRS는 전달자의 도메인을 사용하여 원래 보낸 사람의 주소를 새 주소로 캡슐화하여 작동합니다. 전달자 자체의 도메인만 SPF 검사를 위해 공개됩니다. 이 주소를 사용할 경우 메일(일반적으로 알림)을 전달자에게 라우팅하며, 전달자는 주소 캡슐화를 제거한 다음 실제 대상에게 메시지를 보냅니다.

물론 주소 캡슐화가 완전히 새로운 개념은 아닙니다. 소스 경로가 RFC 822에 정의되었으며, 백분율 핵 라우팅 및 뱅 경로와 마찬가지로 이러한 기능을 제공합니다. 그러나 이러한 기법 사용을 허용하면 시스템이 열린 중계가 되므로 지금의 인터넷 환경에서는 문제가 될 수 있습니다.

SRS는 캡슐화 형식에 키가 지정된 해시와 타임스탬프를 추가하여 이 문제를 처리합니다. 이 주소는 일정한 기간 동안만 유효하며, 그 기간 이후에는 사용할 수 없습니다. 해시는 타임스탬프나 캡슐화된 주소가 수정되는 것을 방지합니다.

또한 SRS는 주소 길이를 지나치게 늘리지 않으면서 멀티홉 전달을 처리하는 기법을 제공합니다. 그러기 위해서는 SRS 주소 형식 지정 중 일부가 SRS를 구현하는 모든 시스템에서 동일한 방식으로 수행되어야 합니다.

SRS 지원은 6.3P1 릴리스에 대해 구현되었습니다. 다음 MTA 옵션이 추가되었습니다.

• SRS_DOMAIN이 옵션은 SRS 주소에서 사용할 도메인으로 설정되어야 합니다. 이 도메인으로 보낸 전자 메일은 해당 도메인에 대해 SRS 작업을 수행할 수 있는 시스템으로 라우팅되어야 합니다. SRS 처리는 일반 주소 처리 위에 중첩으로 처리되므로, 사이트가 주 도메인을 SRS 도메인으로 사용하는 것을 방지할 수 없습니다.

• SRS_SECRETS이는 SRS 주소 인코딩 및 디코딩에 사용되는 비밀 키를 쉼표로 구분한 목록입니다. 목록 중 첫 번째 키는 무조건적으로 인코딩에 사용됩니다. 디코딩의 경우, 다른 해시 값을 생성하기 위해 각각의 값을 시도합니다. 해시 중 일치하는 것이 있으면 디코딩 작업이 진행됩니다.

  여러 키를 사용할 수 있으므로 서비스 중단 없이 비밀을 변경하는 것이 가능합니다. 두 번째 키를 추가하고, 이전에 발급한 주소가 모두 시간 초과될 때까지 기다린 다음 첫 번째 키를 제거합니다.

• SRS_MAXAGE선택적으로 메시지가 시간 초과되기 전 경과될 시간(일)을 지정합니다. 이 옵션이 지정되지 않은 경우 기본값은 14일입니다.

  선택된 SRS 도메인을 위해 전자 메일을 처리하는 모든 시스템은 SRS 처리에 대해 구성되고 세 가지 SRS 옵션이 모두 동일하게 설정되어야 합니다.

이 옵션만 설정하면 SRS 주소 디코딩이 가능해집니다. 인코딩은 또 다른 문제로서, 전달 작업과 연관된 봉투 From: 주소에 인코딩되어야 합니다. SRS 인코딩은 여섯 개의 새로운 채널 키워드, 즉 addresssrs, noaddresssrs, destinationsrs, nodestinationsrs, sourcesrs 및 nosourcesrs에 의해 제어됩니다.

SRS 인코딩이 수행되려면 세 가지 조건이 충족되어야 합니다.

(1) 현재 소스 채널이 sourcesrs로 표시되어야 합니다. (nosourcesrs가 기본값임).

(2) 현재 대상 채널이 destinationsrs로 표시되어야 합니다(nodestinationsrs가 기본값임).

(3) 현재 주소는 다시 쓰여질 경우 addresssrs로 표시된 채널과 일치해야 합니다(noaddress가 기본값임).

이 조건이 모두 충족될 경우에만 인코딩이 이루어집니다. 가장 단순한 설정은 모든 메시지가 tcp_local 채널에서 들어오고 나가고 로컬이 아닌 주소는 모두 SRS 처리가 필요한 순수 전달 설정입니다. 그러한 설정에서는 tcp_local이 세 키워드, 즉 sourcesrs, destinationsrs 및 addresssrs로 표시됩니다.

마지막으로, imsimta test -rewrite는 어떤 주소가 입력되든지 SRS 인코딩 및 디코딩 결과를 표시하도록 향상되었습니다. 예를 들어, foo@example.com이라는 주소는 다음과 유사한 출력을 생성할 수 있습니다.

SRS encoding = SRS0=dnG=IS=example.com=foo@example.org

이 인코딩된 주소를 다시 쓰면 다음과 같은 출력을 생성합니다.

SRS decoding = foo@example.com

또한 imsimta test -rewrite는 SRS 디코딩 중에 발생하는 모든 오류를 표시합니다.