SPF, 간편한 배치와 폭넓은 지원으로 1차전 우승
센더 ID, 라이선싱 분쟁으로 주춤 … DKIM, 구성 복잡

시만텍의 보안위협보고서(Security Threat Report)와 포레스터 리서치의 최근 통계에 의하면 전체 인터넷 이메일 트래픽의 67%가 스팸이라고 한다. 다시 말해 네트워크로 들어오는 메시지들 10개 가운데 세 개만이 볼 가치가 있는 것들이라는 얘기다. 이번에는 이러한 번거로운 스팸 메일들의 흐름을 둔화시키는 데 있어 효과를 발휘한다는 세 가지 이메일 인증 기술을 평가했다.

최근에 스팸과 싸우는 기술로 인기를 끌고 있는 방법은 각 사용자들에 대해 어떤 것이 스팸이고 어떤 것이 스팸이 아닌지를 판단해주는 소프트웨어를 이용하는 것이다. 이러한 필터링 소프트웨어는 분명 도움이 되긴 하지만 아직 이 제품이 100% 정확한지에 대해서는 확신할 수가 없다. 적법한 이메일을 스팸으로 오해할 경우에는 부작용이 생기게 된다. 이메일 송신자 인증 기술을 필터링 소프트웨어와 결합시킴으로써 골치아픈 스패머들에게 또 하나의 보안 계층을 추가할 수는 없을까? 그 방법을 찾아보기로 했다.

스패머들의 생각
이메일과 SMTP는 보안을 염두에 두고 만들어진 것이 아니다. 이메일과 우편 메일 사이의 유사성을 생각해 보라. 글로 쓴 편지를 보낼 때는 정확한 수신, 혹은 회신 주소를 봉투에 적어야 하거나, 특정 우체국에서 이것을 보내야 하거나, 혹은 심지어는 봉투 안에 제대로 된 편지를 넣어야 한다는 제한이 없다.
마찬가지로 이메일 시스템도 송신자가 이메일 주소를 정확히 써야 하거나, 정확한 회신 이메일 주소를 넣어야 하거나, 메시지를 송신할 때 특정 이메일 서버를 이용해야 하거나, 혹은 메시지 내용에 제대로 된 글을 넣어야 한다는 법칙은 없다. 스패머들은 예를 들어 이런 한계를 이용해 결코 정확한 회신 주소를 이용하지 않는다. 이들은 수십만 개의 이메일 어드레스로 된 리스트를 관리하면서 무분별한 접근을 시도해 가능한 많이 전달되기를 바란다. 물론 모두가 큰 성공을 거두고 있음은 말할 나위도 없다.
스패머들은 오픈 릴레이(Open Relay: 비 로컬 사용자용으로 메일을 전달해 주는 메일 서버)를 선호하는데, 그 이유는 이러한 릴레이가 스패머의 신분을 가리기 쉽게 해주기 때문이다. 책임감 있는 메일 관리자들 가운데는 시스템에서 이러한 오픈 릴레이를 폐쇄시키는 경우가 점점 늘어나고 있다. 실시간 블랙리스트(real-time blacklist)라고 하는 오픈 릴레이 추적 서비스와 함께 이런 소스들로부터 오는 이메일을 차단하는 이메일 서버 소프트웨어를 이용함으로써 오픈 릴레이 수를 줄이고 스패머들로 하여금 다른 방도를 찾도록 만들 수 있다.
늘어나는 광대역 채택과 느슨해지는 종단지점 보안 덕분에 스패머들은 언제나 켜져 있는 수십만 대의 고속 접속 컴퓨터로 액세스를 확보할 수 있게 됐다. 언제나 트로이 목마나 바이러스에 감염된 개인 PC를 통해서지만 일단 취약성이 악용이 되면 스패머들은 이메일 릴레이 소프트웨어를 설치해 무고한 개인 컴퓨터를 오픈 릴레이 이메일 서버로 곧잘 바꿔 놓는다. 이에 대항하기 위해 ISP는 다른 ISP DHCP 풀에서 오는 IP 어드레스들을 블랙리스팅하기 시작했는데, 그 이유는 ISP는 자신들의 아웃바운드 SMTP 서버를 이용해 메일을 중계해야 하기 때문이다. 하지만 그런 다음부터 스패머는 이메일을 대신 아웃바운드 SMTP 서버로 보내도록 자신들의 이메일 릴레이 소프트웨어를 개선했다. 이렇게 되면 다른 ISP에서 이메일을 모두 분해하지 않는 한 이런 서버들을 차단할 수 없다는 사실을 알기 때문이다.
스패머들은 또한 콘텐츠 필터를 통과하도록 하기 위해 단어와 문구를 바꿈으로써 메시지를 랜덤화한다. 이들은 보통 예를 들어 잘 알려진 공개된 콘텐츠를 멍청한 필터에 추가시킨다. 피싱(phishing) 공격은 스팸을 양산하는 막대한 보안 위협이며 ID 절도에 공헌하고 있다.

세 가지 인증 방안
이메일 발신자 인증 기술은 이런 노출들을 일부 수정(fix)하는 것을 목표로 하고 있다. 다양한 기초 이행안들이 IETF(Internet Engineering Task Force)에 심의를 받기 위해 제출된 상태다. SPF(Sender Policy Framework), 센더(Sender) ID 및 DKIM(Domain Keys Idenified Mail) 등이 모두 주요 경쟁의 물망에 올라 있다.
이메일 어플라이언스 업체인 아이언포트(IronPort)에서는 2003년 다른 이메일 인증 기술인 SMTPi에 대한 정보를 발표한 바 있는데, 이 곳은 현재 여기에 대한 어떤 정보든 구할 수 있는 유일한 곳이다. 단 이 정보를 얻기 위해서는 웹 아카이브 검색 엔진을 통해야 할 것이다.
발신자 인증으로는 스팸을 제거할 수 없으며, 이것 때문에 나온 기술도 아니다. 전체 인터넷 이메일 커뮤니티에서 이메일 발신자 인증을 채택한다면 스팸이 급격히 줄어들긴 하겠지만, 그렇다고 해서 스패머들로 하여금 발신자 인증 군단으로 합류하지 못하게 하지는 못한다. 그러나 ‘발신(from)’ 주소를 위조하고, 감염된 광대역 컴퓨터를 이용하는 등과 같은 간단한 기술들의 성공은 크게 줄어들 것이다.
게다가 리턴 패쓰(Return Path)의 본디드 센더 프로그램(Bonded Sender Program)이나 하비스(Habeas)의 동명의 서비스 같은 레퓨테이션 서비스(reputation service)들은 각 이메일 도메인에서 스팸을 배포할 수 있는 가능성을 프로파일링한다. 일단 발신자 인증이 널리 확산된다면 이런 서비스는 도메인의 명성을 보다 정확하게 판단해 줌으로써, 사용자의 필터링 소프트웨어가 메시지의 ‘스팸성(spamminess)’에 대해 보다 근거 있는 추측을 할 수 있게 해줄 것이다.

SPF란
SPF 기록들, 특히 잘 만들어진 DNS TXT 기록들은 다른 이메일 서버에게 ‘역(reverse) MX’ 기록 같은 것에서 오는 아웃바운드 이메일을 허용하고 있는 메일 서버를 알려준다. SPF 기록에는 또한 이메일 수신 시스템이 신빙성(authenticity)을 판단할 수 있게 도와주는 신뢰도(confidence level)가 포함돼 있다.
SPF 기록에 따라 수신 이메일 서버가 작동할 수 있게 하는 데는 어떤 비용도 들지 않는다. 하지만 이메일 서버가 다른 SPF 기록을 읽고 여기에 따라 작동하게 하려면 이메일 소프트웨어를 변경해야 한다. SPF는 많은 이메일 보안 프론트 엔드와 안티스팸 장비, 그리고 일상적인 MTA(Message Transfer Agent) 소프트웨어에서 지원이 되는데, 이들 모두 약간의 조정을 거쳐야 SPF가 작동이 된다.
SMTP 게이트웨이가 SPF를 지원하지 않는다면 사러 나서야 할 때가 됐다. 포레스터에 따르면 전체 이메일 도메인들 가운데 25~30%가 SPF 기록을 퍼블리싱하고 있어 가장 널리 채택되는 발신자 인증 기술로 자리잡고 있다.
SPF는 엔벌로프(envelope) 발신자, 즉 SMTP 프로토콜에 있는 ‘프롬(from)’ 주소가 실제로 송신 서버에서 이메일을 보내도록 허용된 것인지를 검증해 준다. 예를 들어 AOL용의 아웃바운드 메일 서버는 핫메일 엔벌로프 발신자 주소와 함께 메시지를 송신해서는 결코 안 된다. SPF 지원 수신 메일 서버가 이런 메시지를 받으면 이것은 핫메일용 SPF 기록을 조사해 발신 AOL 서버가 핫메일을 대표해 이메일을 보내도록 허용되지 않았다고 판단한다. 이에 대해 수신 이메일 서버는 SPF 질의가 있는 신뢰도 핫메일 DNS 서버 회신 기능을 이용해 적절한 조치를 취할 수 있다.
모든 SPF 기록들은 v=spf1으로 시작하는데, 이것은 SPF 기록이라는 것을 나타낸다. 초기설정 문자열(initialization string) 바로 다음에는 허가된 발신 이메일 서버 목록이 있다. SPF는 ptr나 mx 같은 키워드를 지원하는데, ptr은 확인되는 도메인 이름 끝부분의 모든 호스트를 정의하고, mx는 모든 MX 호스트를 정의한다. 이러한 키워드들은 이런 키워드에 맞는 호스트를 자동으로 추가함으로써 관리자를 수월하게 해준다.
SPF 엔트리의 마지막 부분은 신뢰도를 나타내는 것으로(실패, 부족, 통과, 혹은 무관) 수신 이메일 서버에게 결정을 내릴 수 있는 유효 정보를 제공한다.
SPF 기록은 AOL, 핫메일 및 로드러너(RoadRunner) 등과 같은 이메일 사업자들뿐만 아니라 뱅크 오브 아메리카(Bank of America), e베이(eBay) 및 티켓마스터(Ticket master)와 같은 대형 회사들에 의해 퍼블리싱되고 있다. 티켓마스터는 실패(fail) 신뢰도를 돌려보내며, AOL은 무관(neutral) 등급을 돌려보낸다. 그리고 다른 모든 곳에서는 자신들 각각의 SPF 기록을 확인하는 누구에게든 부족(softfail) 신뢰도를 돌려보내고 있다.
누구든 DNS 질의 툴을 이용해 SPF 기록을 룩업할 수 있으며, 자원 기록 유형을 TXT 같은 것으로 지정할 수 있다. 예를 들어 뱅크 오브 아메리카의 SPF 기록을 보자면 다음과 같다.

$ host -t txt bankofamerica.com
bankofamerica.com text "v=spf1 a:sfmx02.bankofamerica. com a:sfmx04.bankofamerica.com a:vamx04.bankofamerica. com a:vamx02.bankofamerica.com a:txmx02.bankofamerica. com a:txmx04. bankofamerica. com a:cr-mailgw.bankofamerica. com a:cw-mailgw.bankofamerica.com ~all"

SPF의 이점은 명확하다. 즉 DNS 엔트리를 간단히 추가함으로써 다른 이들이 SPF를 검증할 수 있으며, 추가 SPF 인지 소프트웨어를 이용해 MTA를 향상시키는 게 가능하고, 다른 사람의 SPF 기록을 이용해서 잘못된 SMTP 서버로부터 잘못된 엔벌로프 회신 주소가 있는 이메일을 보내는 일상적인 스패밍 기술을 못 쓰도록 만들 수 있게 해준다.
비록 모든 사람들로 하여금 도메인용 SPF 엔트리를 구성하라고 말하긴 하지만(결국 손해볼 건 없으니까) 이 시스템에도 나름대로의 한계는 있으며, 그 중에서 가장 중요한 한계로 이 시스템이 피싱 이메일을 충분히 막지 못하는 것을 꼽을 수 있다. 그 이유는 이것이 점검하는 것은 엔벌로프 회신 주소지 사용자들이 이메일 클라이언트에서 보게 되는 ‘프롬’ 주소가 아니기 때문이다. 이것은 기본 설계상의 문제다. 즉 스패머들은 제대로 된 엔벌로프 ‘프롬’ 주소와 아웃바운드 이메일 서버를 이용하면서도 잘못된 콘텐츠와 ‘프롬’ 주소가 사용자들의 메일 클라이언트에 나타나도록 이들을 속이는 피싱 공격으로 SPF를 우회해갈 수 있다.
SPF는 또한 자신들이 이용하고 있는 ISP를 기반으로 아웃바운드 SMTP 서버를 바꾸는 모바일 사용자들에게서도 문제가 있다. 엔벌로프 발신자는 자신들이 이용하는 ISP의 SPF 기록을 맞춰보지 않을 것이며, 이들의 이메일은 차단될 것이다. 이러한 문제는 SMTP AUTH를 이행함으로써 해결할 수 있기 때문에 사용자는 자신들의 이름과 패스워드를 이용해 아웃바운드 SMTP 서버로 인증을 할 수 있다. SPF는 또한 대학의 동창 계정 등과 같은 이메일 포워딩(forwarding) 서비스에도 문제를 낳는다. 이러한 사업자들은 효과적이 되도록 엔벌로프 발신자를 다시 써야 하는데, 즉 리메일링(remailing)이라는 기술이다.

>> www.openspf.org/index.html : SPF 기록을 만들 수 있도록 도와주는 마법사가 있다. 2005년 11월 현재 170만 개 이상의 도메인에서 SPF 기록을 퍼블리싱했다. IETF 초안은 www.ietf.org/internet-drafts/draft-schlist-spf-classic-02.text 참조.

센더 ID
후방 호환이 가능한 SPF의 확장판인 센더 ID는 마이크로소프트에서 후원하는 발신자 인증 방안으로, 핫메일과 MSN 서비스에서 사용되고 있다. 이러한 서비스는 웹 메일 인터페이스에서 센더 ID 결과를 보여주는데, 공식 명칭은 콜러(Caller) ID로 돼 있다. 그리고 SPF에서 필요로 하는 것과 같은 DNS 텍스트 자원을 이용한다. SPF와 센더 ID의 가장 큰 차이는 센더 ID 사양에서는 SMTP 계층에서 제시되는 것 대신 본문에 포함된 ‘프롬’ 주소를 확인한다는 점이다.
센더 ID는 피싱 공격을 막는다는 측면에서 SPF보다 나은데, 그 이유는 이것이 사용자가 자신들의 이메일 클라이언트에서 보게 되는 ‘프롬’ 주소를 확인하기 때문이다. 그리고 SPF와 마찬가지로 시작하는 데는 전혀 돈이 들지 않는다. 그냥 DNS 기록을 추가해서 다른 사람들이 당신의 기록에 따라 행동하도록 하면 된다. 하지만 SPF와 마찬가지로 센더 ID는 포워딩 서비스와, 다른 SMTP 서버를 채택한 모바일 이용자에게서 문제를 발생시킬 것이다.
센더 ID에서 가장 큰 걱정거리는 마이크로소프트의 로열티 프리 센더 ID 페이턴트 라이선스 어그리먼트(Royalty-Free Sender ID Patent License Agreement)를 중심으로 한 것이다. 아파치 소프트웨어 파운데이션(Apache Software Foundation), AOL, FSF(Free Software Founda tion) 및 OSI(Open Source Initiative) 등 조직들은 라이선싱 언어에 대한불만을 IETF에 제기했으며, 이로 인해 센더 ID의 기세가 주춤해진 듯 보인다. 이들 집단은 그 어떤 회사도 핵심 인터넷 사양에 대해 지적재산권을 가져서는 안 된다는 입장이다.
마이크로소프트와 오픈소스 사업자들은 경쟁 업체들이 센더 ID를 리브랜딩하거나 재배포할 때 마이크로소프트와 접촉을 하도록 요구함으로써 이들의 사업적 의도에 대해 소중한 정보를 얻을 수 있게 해주는 ‘이적불가, 서브라이선스 불가’와 같은 용어 및 언어에 집착하는 듯하다.
우리는 SPF를 이행하고, 특허권 분쟁이 해결될 때까지 기다리기를 권하는 바다. SPF와 센더 ID는 모두 IETF 초안 상태지만 SPF가 더 강세를 보이는 듯하기 때문에 우리는 SPF가 먼저 IETF 표준이 되리라 믿고 있다.

>> www.microsoft.com/mscorp/safety/technologies/
senderid/default.mspx : 센더 ID 기술에 대한 오버뷰를 구할 수 있다. IETF 초안은 www.ietf.org/internet-drafts/draft-lyon=
senderid-pra-01과 www.ietf.org/internet=drafts/draft-lyon-senderid-core-01에서.

DKIM
야후의 도메인 키(Domain Keys)가 시스코에서 개발한 유사 사양인 인터넷 아이덴티파이드 메일(Internet Identi fied Mail)과 합쳐져 이제 DKIM이라는 이름으로 불리고 있다. 이 두 회사는 2005년 중반 합작을 발표하고, 최소 십여 개의 주요 회사들이 후원하는 업데이트된 문서를 IETF로 제출했다.
DKIM 발신자 인증 방안은 아웃바운드 메시지에 전용 키로 서명을 하는 것이다. 수신 이메일 서버는 DNS에서 사용 가능한 공중 키를 이용해 이메일이 알려진 소스에서 오는지를 확인할 수 있으며, 메시지의 무결성도 또한 확인할 수 있다(SPF와 센더 ID에는 없는 기능). DKIM 사양은 아직 표준이 되지 않은 상태다.
DKIM 인지 이메일 인프라를 구성하려면 SPF와 센더 ID 이행에서보다 더 많은 과정이 포함된다. 아웃바운드 이메일은 전자적으로 서명돼야 하기 때문에, 아웃바운드 서버 이메일 소프트웨어는 반드시 메시지의 컴퓨팅 및 변경을 허용하게끔 변경돼야 한다. SPF나 센더 ID에서와 마찬가지로 DKIM 메시지를 확인하고 싶을 경우에는 수신 이메일 시스템도 마찬가지로 변경이 돼야 한다. 이행은 일반적으로 사용되는 MTA(Message Transfer Agent)용으로 사용 가능하다. DKIM을 이용하려면 이메일 서버 소프트웨어를 업그레이드해야 할 것이다.
아웃바운드 이메일 메시지 서명을 지원하려면 DKIM 인지 아웃바운드 이메일 소프트웨어가 설치돼야 한다. 기존의 소프트웨어에서는 얼마간의 변경 작업을 통해 지원이 가능할 것이다. 여기에는 또한 이메일 메시지가 전자적으로 서명이 될 수 있도록 공중-전용 키 쌍이 만들어져야 한다. 공중 키는 서브도메인 도메인키(domainkey) 아래 있는 TXT 자원 기록 안으로 입력이 된다. 야후는 이메일 메시지 서명용으로 s1024라는 정책을 쓰고 있기 때문에, 그 공중 키는 s1024._ domainkey.yahoomail.com에서 찾을 수 있다. 전용 키는 DKIM 인지 이메일 소프트웨어로 로딩돼어 정책과 연관됨으로써 전자적으로 이메일에 서명하는 데 사용될 수 있다.
사용자가 DKIM 인지 아웃바운드 메일 서버를 이용해 이메일을 보낼 때 서버는 메시지의 특정 헤더(header)와 본문 문구(body text)를 이용해 메시지에 서명을 한다. 사용된 헤더와 암호화 알고리즘이 무엇인지를 설명하는 정보와 함께 전자 서명은 하나의 헤더로 이메일 메시지에 삽입된다. DKIM 이메일 헤더는 다음과 같다.

DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=s1024; d=yahoo.com;
h=Message-ID:Received:Date:From:Subject:To:MIME-
Version:Content-Type:Content-Transfer-Encoding;
b=o3PMxZIlFKjVfLJUugi1uubwjHnE0IIu1tsDG/c6SwXYfW842s1df01f
R+UF0QmnVhVCaTa3xNiGZZeqSITw6oLLNv5zvdCqd6BrkkkuucPPxvTV/VuM9Uhw
5R9bNU50Fg+B89/RmkciPJkluHEX+RLaZ3d/P1adg+ed
L1Pwxbo= ;

일단 메시지가 DKIM을 인지하는 수신 이메일 시스템에 도달하면, 이것은 이 헤더를 사용해서 메시지를 검증할 수 있다. 도메인키-시그니처(DomainKey-Signature)에 있는 정보를 이용해 수신 서버에서는 DNS의 공중 키를 검색하며, 그런 다음 s1024._domainkey.yahoo.com용으로 DNS에서 TXT 자원 기록을 검색한다.
DNS에 있는 공중 키와 정확한 알고리즘(a=), 그리고 이메일 메시지에 있는 특정 헤더(h=)를 이용해 수신 서버는 전자 서명을 만들고 비교할 수 있다. 이를 통해 수신 시스템은 이메일이 실제로 발신 시스템으로부터 전송이 됐는지와 발신이 허용됐는지 여부를 검증할 수 있다. 서명이 검증될 경우 수신 이메일 시스템은 사용자에게 메시지를 전달하거나, 혹은 서명이 일치하지 않을 경우 메일을 유실, 거절, 혹은 격리할 수 있다.
스팸과 피싱 공격을 막기 위해 수신 이메일 서버는 알려진 이메일 사업자들에게서 오는 비 DKIM 이메일에게는 DKIM 사용을 불허하는 정책을 만들 수 있다. 예를 들어 이메일이 DKIM 기술을 채택한 야후로부터 왔다고 주장하는 DKIM 헤더가 없이 도달을 할 경우, 이 메시지는 안전하게 거부, 혹은 삭제될 수 있다. 야후나 구글 같은 주요 이메일 사업자들은 모두 DKIM 기술을 사용하고 있다.
DKIM의 가장 큰 단점은 이것이 아웃바운드와 인바운드 DKIM 인지 이메일 서버를 모두 필요로 한다는 것이다. DKIM은 SPF나 센더 ID에 있는 포워딩 문제, 즉 스패머들로 하여금 계속해서 원치 않는 이메일을 퍼뜨리게 하는 문제를 수정(fix)한다. 하지만 스패머는 DKIM 인지 서버를 통해 이메일을 보낸 다음 이 메시지를 다른 사용자에게 포워딩하거나 재생할 수 있다. 이것은 유효 서명을 갖고 있는 듯 보이겠지만 수상한 소스에서 오는 것이기 때문에, 이런 위조 행동을 탐지하기 위해서는 인바운드 이메일 서버에 더 많은 인핸스먼트가 필요하다.
DKIM은 또한 이메일 프로세싱에 오버헤드를 추가하기 때문에 더 많은 DNS 룩업을 필요로 하며, 서명 확인에 막대한 프로세싱 자원이 필요하기 때문에 서버가 처리할 수 있는 이메일 양을 감소시킨다.

>> DKIM에 대한 설명은 antispam.yahoo.com/doainkeys에서. IETF 초안은 www.ietf.org/internet-drafts/draft-aliman-dkim-base-01.txt, www.ietf.org/internet-drafts/draft-aliman-dkim-ssp-01.txt, 그리고 www.ietf.org/internet-drafts/draft-delany-domainkeys-base-03.txt 참조.

이메일 인증 기술 >>>

세 가지 발신자 인증 방안들 사이의 선점권 전쟁에서 우선은 SPF(Sender Policy Framework)가 승리를 거두고 있으며, 앞으로도 1년 이상은 이 자리를 유지할 것으로 보인다. 이 사양은 배치가 간편하기 때문에 모든 사람이 SPF 기록을 신속하게 배치할 수 있게 해주며, 그 기록 확인은 거의 모든 e-메일 서버 업체들에 의해 지원이 된다.
마찬가지로 센더 ID는 발신과 수신측에서 모두 이행과 프로비저닝이 간편하다. 하지만 이것은 타 업체들의 발걸음을 망설이게 만드는 라이선싱 분쟁에 휘말려 있다.
마지막으로 DKIM (Domain Keys Identified Mail)은 효과가 있긴 하지만 복잡한 구성으로 인해 인바운드와 아웃바운드 e-메일 소프트웨어에 모두 큰 변경이 필요하며, 사이트들간의 DNS 트래픽에 막대한 성능 패널티를 가져온다.
당신이 어떤 인증 방식을 선택하든 사용자와 인터넷 커뮤니티는 앞서게 될 것이다. 스패머들의 발길을 멈추게 할 수 있다면 어떤 것이든 우리는 승자라고 본다.

용어정리 >>>

- 블랙리스트(blacklist) : 알려진 악성 IP 주소들의 목록을 관리하며, 여기서 보내온 메일은 e-메일 서버로부터 거부된다
- 프롬(from) : e-메일 메시지 본문에 포함된 SMTP 헤더로서, 사용자들은 자신들의 메일 클라이언트에서 ‘from’ 필드로 보게 된다.
- HELO/EHLO : e-메일 대화를 시작하는 송신 e-메일 서버용으로 수신 e-메일 서버로 보내지는 초기 정보
- 메일 프롬(mail from;엔벌로프 센더) : STMP 협상 과정에서 주어지는 회신 주소로, 악성 e-메일을 튕겨내는데 사용되지만 사용자가 자신들의 e-메일 클라이언트에서 보게 되지는 않는다.
- 리플라이-투(replay-to) : e-메일 클라이언트가 e-메일에 답장을 보낼 때 서로 다른 회신 주소를 식별하는 SMTP 헤더
- 레퓨테이션(reputation) : 특정 도메인에서 오는 e-메일이 적법하고 원하는 것이라는 신뢰성
- 화이트리스트(whitelist) : 알려진 IP 어드레스 목록을 만들며, 여기서 오는 e-메일은 e-메일 서버가 언제나 수용한다.