SMTP는 1982년에 설계됐다. 발신자 검증이라는 개념 자체가 없었다. “From” 필드에 아무거나 넣으면 수신 서버가 그냥 받아들였다. 인터넷에 호스트가 수백 개뿐이고 서로 얼굴을 아는 시절에는 그래도 괜찮았다.
지금은 1982년이 아니다.
땜질의 시작
첫 번째 수정 시도는 SPF (2006). 아이디어는 단순했다. DNS 레코드에 “이 도메인으로 메일 보낼 수 있는 서버 목록”을 게시하고, 수신 서버가 확인해서 허가되지 않은 발신자를 거부하는 것.
주의: SPF에는 DNS 조회 10회 제한이 있다. 초과하면 SPF가 조용히 실패한다 — 메일이 스팸함으로 가는데 에러 메시지는 없다. 대부분의 SPF 검증기가 이걸 경고해주지도 않는다.
SPF에는 근본적인 결함이 하나 있다. 이메일이 포워딩되면 깨진다. 메일링 리스트로 메일을 보내면, 리스트 서버가 자기 IP에서 재발송한다 — 원래 도메인의 SPF 레코드에 없는 IP다. 정상적인 메일이 SPF 검증에 걸린다. 엣지 케이스가 아니다. 이메일이 원래 이렇게 작동한다.
그래서 DKIM (2007)을 만들었다. 발신 IP 대신 암호화 서명을 쓴다. 발신 서버가 이메일 헤더에 개인키로 서명하고, 공개키를 DNS에 게시한다. 수신 서버가 서명을 검증한다. 포워딩해도 서명이 메시지와 함께 이동하니까 깨지지 않는다.
DKIM은 작동한다. 문제는 SPF와 DKIM이 독립적으로 돌아간다는 것. 한 도메인이 SPF는 통과하고 DKIM은 실패할 수 있다. 반대도 마찬가지. 하나는 통과하고 하나는 실패할 때 뭘 해야 하는지 정해진 정책이 없다. 리포팅 메커니즘도 없다. 수신 서버에게 “둘 다 실패하면 거부해”라고 알릴 방법이 없다.
DMARC (2012) 등장. DMARC는 SPF와 DKIM 위에 올라가는 정책 레이어다. 수신 서버에게 “인증 실패 시 이렇게 처리해”라고 알려준다 — none, quarantine, reject. 리포팅도 추가돼서 누가 내 도메인으로 메일을 보내는지 볼 수 있다.
DMARC가 이야기의 끝이었어야 했다. 아니었다.
스택은 계속 쌓인다
MTA-STS (2018)는 완전히 다른 문제를 해결한다. SPF, DKIM, DMARC가 다 있어도 실제 메일 전송은 암호화 없이 일어날 수 있다. SMTP의 STARTTLS 업그레이드는 선택적이라서 중간자가 벗겨버릴 수 있다. MTA-STS는 메일 전송에 TLS를 강제한다. 웹에서 HSTS가 하는 것과 비슷하다.
MTA-STS를 쓰는 곳은 거의 없다. 대부분의 메일 관리자는 존재 자체를 모른다.
BIMI (2020)가 최신 추가분. 받은편지함에서 이메일 옆에 브랜드 로고를 보여준다 — 단, DMARC가 p=quarantine이나 p=reject일 때만. 본질적으로 DMARC 도입을 유도하기 위한 당근이다. 보안 가치는 논쟁의 여지가 있고, 마케팅 가치는 확실하다.
왜 SMTP를 교체하지 않나?
누구나 하는 질문인데 아무도 실행에 옮기지 않는다.
답은 IPv6가 1998년부터 있었는데 아직도 IPv4를 쓰는 것과 같은 이유다. 전환 비용. 전 세계 모든 이메일 서버가 SMTP를 쓴다. 교체하려면 모든 메일 사업자가 동시에 움직여야 한다. 그런 일은 일어나지 않는다.
그래서 50년 된 기반 위에 프로토콜을 계속 쌓는다. 각각은 특정 결함을 고친다. 근본 문제는 아무것도 못 고친다 — SMTP는 신뢰가 기본값인 세상을 위해 설계됐다.
현재 상황
프로토콜이 다섯 개인데, 대부분의 도메인이 전부 제대로 설정하지 못하고 있다:
| 프로토콜 | 연도 | 채택률 | 현실 |
|---|---|---|---|
| SPF | 2006 | 높음 | 잘못 설정되는 경우가 많다. 10-lookup 제한이 큰 설정을 조용히 깨뜨림 |
| DKIM | 2007 | 중간 | 기술적으로는 건전하지만, alignment 확인 없이 키만 게시하는 곳이 많음 |
| DMARC | 2012 | 중간 | p=none으로 배포하는 곳이 대부분 — “감시만 하고 차단 안 함.” 장식 |
| MTA-STS | 2018 | 매우 낮음 | well-known 파일 + DNS 레코드가 필요. 마찰이 너무 큼 |
| BIMI | 2020 | 매우 낮음 | Verified Mark Certificate 필요 (연 $1,000 이상). 사실상 대기업 전용 |
도구는 존재하는데 도입이 가용성보다 수년 뒤처지는 시스템. “RFC로 발표됨”과 “실제 배포됨” 사이의 간극에 대부분의 이메일 보안 문제가 산다.
여섯 번째 프로토콜은 오지 않는다. 지금 있는 다섯 개로 충분하다 — 사람들이 실제로 쓰기만 하면.