자체 라우팅 가능한 IPv4 블록에서 직접 이메일 호스팅하기

웹을 재야생화(rewilding)한 후, 제가 1997년부터 Nick Ludlam과 함께 운영해 온 Recoil 자체 호스팅 인프라를 업데이트했습니다. 가장 흥미로운 점은, 프랑스에 있는 친구 Thomas Gazagnaire의 도움 덕분에 저희만의 전용 IPv4 할당을 라우팅하는 '직접 이메일 보내기(email the hard way)'가 포함되었다는 것입니다!

이 게시물은 상당히 기술적이며, 자신만의 이메일 스택을 구축하는 데 관심 있는 분들을 대상으로 합니다. 왜 직접 이메일을 운영해야 하는지(IP 평판, 자체 IPv4 할당 확보, 봇 차단, Sieve 전송 포함한 이메일 수신); SPF, DKIM, DMARC 및 SRS를 사용하여 안정적으로 이메일을 보내는 방법; Dovecot IMAP과 Roundcube 웹메일을 통한 사용자 접근; 그리고 마지막으로 남은 작업 내용과 향후 연구 아이디어에 대한 성찰을 다룰 것입니다.

1 왜 직접 이메일을 운영해야 하는가?

시스템 및 네트워킹 입문자에게는 엄청나게 교육적인 경험입니다. 저의 서버를 직접 운영해 온 것이 제가 인터넷이 어떻게 작동하는지 배우고, 예전에 OpenBSD를 설치하고 PHP 버그를 수정하면서 오픈 소스에 빠져들게 된 방법이었습니다!

더 광범위하게 보면, 웹이 몇몇 플레이어들 사이에서 꾸준히 통합되면서 자신의 데이터에 대한 주권적 접근성을 확보하는 것이 자체 호스팅의 중요성입니다. 2023년 분석에 따르면 두 회사가 사용자의 이메일 트래픽 대부분을 읽을 수 있다는 결과가 나왔습니다:

결국 누가 당신의 이메일을 읽을 수 있는지에 대한 답은 -- 네 --

이메일을 직접 호스팅하는 것은 상당한 작업이지만, 꾸준히 관심을 기울이면 오랜 기간에 걸쳐 분산됩니다. Nick Ludlam과 저는 1998년경 NASA에서 여름 동안 일했을 때 저희의 호스팅 모험을 시작했습니다. 2002년에 주요 서버를 이전했던 첫 경험은 이렇습니다. Nick과 Chris Luke이 런던 외곽의 최초 인터넷 카페인 Easynet에 호스팅할 두 번째 서버를 불안해 보이는 흰색 미니밴에 싣고 있는 모습입니다.

만약 직접 시도해 보기로 결정한다면, 안정적인 인터넷 호스팅(나중에 이 게시물에서 설명할 이유 때문에 집 네트워크가 최선의 선택은 아닙니다)을 찾고 평판을 쌓아야 합니다. 다행히 요즘에는 90년대 후반보다 안정적인 인터넷을 찾는 것이 훨씬 쉬우며, 저희는 훌륭하고 신뢰할 수 있으며 지역 기반인 Mythic Beasts를 사용합니다.

이 게시물에서는 우리가 개인 이메일을 위해 높은 전송 가능 지수(deliverability index)를 쌓는 데 도움을 받기 위해 어떻게 자체 전용 IPv4 주소 블록을 얻었는지 설명하겠습니다! 대부분의 사용자에게 이메일은 하나의 서비스처럼 보이지만, 실제로는 세 가지 별개의 활동입니다: 이메일 수신(email receipt), 이메일 제출(email submission), 그리고 이메일 접근(email access). 혹시 여러분의 설정에 유용할까 하여 Recoil에서 각각이 어떻게 작동하는지 자세히 살펴보겠습니다.

2 이메일 수신 (Email receipt)

인터넷상의 모든 도메인(예: recoil.org)은 다른 서버로부터 이메일을 받을 수 있도록 SMTP 서버를 운영합니다. 해당 도메인의 'MX' DNS 레코드를 조회하여 어떤 서버인지 확인할 수 있습니다:

$ host -t mx recoil.org
recoil.org mail is handled by 10 pork.recoil.org.

이는 인터넷 호스트 pork.recoil.org가 <email>@recoil.org로 이메일을 전달하려는 모든 서버의 연결을 수락해야 함을 나타냅니다.
핵심적인 어려움은 SMTP(1980년대에 설계된, 더 신뢰하는 환경에서)가 내장된 신뢰 증명(proof of trust)을 의무화하지 않는다는 것입니다. 누구나 다른 사람인 척 주장할 수 있으며, 우리가 받는 이메일의 '발신자'(sender)는 쉽게 위조될 수 있습니다.

IETF는 시간이 지나면서 이메일 발신자가 통과해야 하거나 수신자에 의해 필터링되어야 하는 일련의 검사(checks)들을 쌓아 올렸습니다. 만약 우리가 이러한 신원 확인 절차를 망치면, 우리의 이메일은 인터넷 전반에 걸쳐 안정적으로 전달되지 못하고 서비스 자체가 그다지 유용하지 않게 됩니다.

2.1 IP 평판 및 차단 목록(denylists)

스팸은 인터넷 어디에서든 보내기가 저렴했기 때문에, 네트워크가 더 널리 채택되면서 자연스럽게 증가했습니다. Paul Vixie는 1997년에 DNS 기반의 블랙리스트를 고안해냈습니다. 그 이후로는 Spamhaus, Spamcop, Barracuda와 같은 조직들이 등장하여 봇넷(botnets), 감염된 호스트(compromised hosts), 스패머에 대한 보고서를 취합하고 이를 어떤 이메일 서버든 조회할 수 있는 목록으로 만들었습니다.

DNS 블랙리스트/화이트리스트 프로토콜(RFC 5782)은 매우 간단하며 명령줄에서 바로 질의할 수 있습니다:

$ dig 2.0.0.127.zen.spamhaus.org +short # 테스트 주소
127.0.0.2
127.0.0.10
...

이것은 로컬호스트(localhost) 테스트 주소이지만, RBL에 DNS 레코드가 존재한다는 것은 해당 서버가 의심스럽다는 것을 의미합니다. 바로 여기서 자신의 IPv4 주소를 직접 통제하는 것이 큰 이점을 발휘합니다. 이러한 RBL을 통한 이메일 평판은 도메인이 아닌 주소 자체에 쌓입니다. 이론적으로, 사용자가 자체 호스팅(self-hosted)한 이메일에 사용하는 IP 주소는 클라우드 제공업체로부터 다른 누군가에 의해 재사용되었을 수 있으며, 따라서 다른 사람들의 나쁜 행동으로 인해 오염될 수 있습니다.

(업데이트: Ryan Gibb은 이러한 목록들이 종종 IP 블록 단위로 작동하기 때문에, 멀티테넌트(multitenant) 클라우드 환경에서 인접한 IP 주소도 평판에 영향을 미칠 수 있다는 점을 지적합니다. 그는 남용을 최소화하기 위해 SMTP 서버를 수동으로 화이트리스트에 추가하는 Hetzner를 사용한다고 보고했습니다.)

2.2 자체 IPv4 주소 블록 확보하기

대조적으로, 새로운 IPv4는 중립적인 상태로 시작하여 일관되고 잘 구성된 이메일 전송을 통해 평판을 쌓습니다. 이를 완전히 통제할 수 있는 유일한 방법은 주소 공간(address space) 자체를 통제하는 것이며, 이것이 바로 Team Recoil이 자체 IPv4 주소 블록인 185.33.27.0/24를 보유하게 된 이유입니다.

!

자체 주소 할당을 받기 위해서는 IPv4 고갈 문제로 인해 매우 긴 대기열에 합류해야 했습니다. RIPE NCC는 유럽 지역 레지스트리(regional registrar)이며 2019년 11월에 미할당 IPv4 공간이 소진되었습니다. 그 이후로는 RIPE로부터 직접 할당을 받는 유일한 방법은 작은 규모의 할당을 위한 대기 목록을 이용하는 것입니다.

비록 저희가 IPv4 주소는 고갈되었지만, RIPE NCC 회원들은 여전히 단일 /24 할당(256개 주소)을 요청할 수 있습니다. [...] 요청은 대기 목록에 추가되며, 향후 IPv4 주소가 회복될 때 처리됩니다. [...] 이것은 이전에 RIPE NCC로부터 어떠한 크기의 IPv4 할당도 받은 적이 없는 LIR(Local Internet Registry)에게만 가능합니다. -- RIPE NCC, 대기 목록을 통한 /24 할당

저는 영국에서 그 대기열에 합류했고, 제 친구 Thomas Gazagnaire는 프랑스에서 같은 일을 했습니다.
그는 저보다 훨씬 먼저 자신의 대기열 맨 앞에 도착했고, 저희는 약 6개월의 기다림 끝에 자체 /24 블록을 할당받았습니다.

2.2.1 본인이 RIPE에 가입하는 방법

만약 이 과정을 스스로 진행하고 유럽에 기반을 두고 있다면, 연간 RIPE NCC 회원비를 납부하여 Local Internet Registry (LIR) 계정을 개설해야 합니다.

그 후에는 자신이 이전에 IPv4 할당을 받은 적이 없음을 확인하고, 대기 목록에 합류한 다음, 충분한 주소(예: 폐지된 LIR, 반환된 공간, 또는 취소된 할당으로부터 회복된)가 확보되어 슬롯이 생길 때까지 기다려야 합니다. 현재는 1년이나 2년 정도 걸리는 것 같으며 어느 나라에 거주하느냐에 따라 달라지는 것 같습니다.

2.2.2 자율 시스템(autonomous system)을 위한 IPv4 경로 설정하기

다음 단계는 이 할당된 주소를 공용 인터넷에 연결된 실제 장치로 라우팅하는 것이었습니다. 자체 경로를 광고하는 것도 가능하지만, 신속성을 위해 Mythic Beasts에 맡겨 피어링 처리를 담당하도록 요청하기로 결정했습니다.

RIPE를 통해 이를 수행하는 절차는 간단합니다. IPv4 블록은 그들의 데이터베이스에 'RPKI ROA'를 생성함으로써 할당됩니다. 이는 인터넷에서 IP 라우팅 블록을 연결하는 데 사용되는 PKI(Public Key Infrastructure) 신뢰 체인입니다.

자율 시스템(Autonomous System, AS)은 인터넷에서 독립적인 라우팅 정책을 구현하는 단위이며 BGP를 통해 전 세계에 공지됩니다. 특정 ASN이 실제로 누구의 소유인지 파악하는 것은 WHOIS 데이터베이스가 일관성 있게 업데이트되지 않아 놀라울 정도로 어렵지만, 도움을 줄 수 있는 제3자 데이터베이스들이 존재합니다. 저희의 경우 IP 블록은 Mythic Beasts AS44684에 연결되어 있습니다.

이 부분이 정리된 후, RIPE는 다시 한번 DNS를 사용하여 Mythic으로의 연결을 공지했습니다:

$ dig soa -x 185.33.27.0 @pri.authdns.ripe.net +noall +authority
27.33.185.in-addr.arpa. 86400 IN NS ns1.mythic-beasts.com.
27.33.185.in-addr.arpa. 86400 IN NS ns2.mythic-beasts.com.

또 다른 좋은 점은 이 IP 블록에 대한 리버스 DNS(reverse DNS)를 직접 제어할 수 있다는 것인데, 이는 이메일 평판(email reputation)을 위한 또 다른 중요한 신호입니다:

$ host pork.recoil.org
pork.recoil.org has address 185.33.27.128
pork.recoil.org has IPv6 address 2a00:1098:39c::3
...

2.3 좀비 스팸 무리를 막기

저희는 깨끗한 IPv4 블록을 얻기 위해 엄청난 노력을 기울였지만, 이것만으로는 스스로를 보호하기에 충분하지 않습니다! 저희는 또한 서버가 좀비 봇넷(zombie botnet) 무리로부터 방어하도록 구성해야 합니다.

25번 포트에서 들어오는 TCP 연결의 압도적인 대다수는 스팸을 전송하거나, 열린 릴레이를 탐색하거나, 자격 증명을 추측하거나 (또는 더 최근에는) AI 학습을 위한 데이터를 수집하려는 봇넷 시도입니다. 이러한 요청 각각의 본문(body)을 구문 분석하는 데 CPU 사이클을 사용하는 것은 모두 낭비적이고 위험하기 때문에, 좋은 설정은 가능한 한 초기에 이를 필터링하려고 노력해야 합니다.

저희는 먼저 Postfix의 postscreen을 배포했는데, 이는 첫 번째 접점으로서 25번 포트에서 수신 대기합니다. 구조적으로 이것은 TCP 연결을 수락하고 일련의 저렴한 검사(cheap checks)를 수행하는 프로토콜 프록시입니다:

• 여러 제공업체로부터 병렬 DNSBL 조회(DNSBL lookups)
• RFC 5321 §3.1에 따른 의도적인 사전 인사 지연(pre-greet pause)을 추가하여, 서버의 배너가 나타나기 전에 대화를 시작하는 봇들을 포착합니다.
• 규정 준수 여부를 확인하기 위한 몇 가지 파이프라이닝 및 비(non)-SMTP 명령어 테스트

이것은 클라이언트가 이 테스트들을 통과하여 합법적으로 보일 경우에만 실제 smtpd 프로세스로 연결을 전달합니다.
나쁜 클라이언트는 임시 실패(temporary failure)를 통해 사전 인사말(pre-greet pause) 단계에서 차단되며, 이는 나중에 허위 양성(false positives)이 재시도하도록 장려합니다.
흥미롭게도 이 프록시는 Docker for Desktop에서 우리가 하는 것과 정확히 같습니다. 여기서는 사용자 공간의 OCaml VPNKit 프록시가 컨테이너와 호스트 네트워크 사이에 중재하며, 호스트 스택을 직접 노출하지 않습니다. 곧 OxCaml에서 postscreen을 재구현할 예정입니다...

자체 서버를 구성하는 분들을 위해 관련 Postfix 설정 값(knobs)은 main.cf에 있습니다.

postscreen_dnsbl_sites = zen.spamhaus.org*3 bl.spamcop.net*2 b.barracudacentral.org*2
postscreen_dnsbl_action = enforce # DNSBL 점수가 임계값을 초과하면 거부
postscreen_greet_action = enforce # 사전 인사말 스래머(slammers)를 거부

*3와 *2 가중치(weights)는 단일 소스만을 신뢰하기보다 블록리스트들을 결합할 수 있게 합니다. 위 예시에서는 Spamhaus만 신뢰하고, 나머지 두 개의 약한 리스트가 모두 동의해야 거부합니다.

단순히 postscreen만으로도 들어오는 스팸 요청의 90% 이상을 거부하는 것 같지만, 우리가 적용할 수 있는 또 다른 트릭이 있습니다.

Nick Ludlam이 발견한 사소한 문제는 Apple의 iCloud 이메일 서비스가 postscreen과 상호 작용이 좋지 않다는 것입니다. 이메일을 전달하는 Apple의 아웃바운드 MX 풀은 동일한 IP에서 재시도하지 않기 때문에, postscreen의 해당 연결 허용 목록(allowlist)에 절대 일치하지 않아 메일이 몇 시간 동안 정체될 수 있습니다. 이것은 우리 쪽의 실제 잘못된 설정이라기보다는 사용자에게 큰 영향을 미칩니다.

해결책 (Apple이 여전히 17.0.0.0/8 전체를 소유하고 있기 때문에!)은 이 전체 범위를 postscreen_access.cidr에 미리 허용 목록으로 지정하여 프로토콜 테스트를 완전히 우회하는 것입니다. mailcow 허용 목록 가이드가 동일한 문제에 직면할 경우 구문을 안내해 주었습니다:

# /etc/postfix/postscreen_access.cidr
17.0.0.0/8 permit # Apple iCloud MX 풀은 여기에 어딘가에 있습니다

2.3.1 Greylisting

2.3.1 Greylisting

postscreen을 통과한 연결에 대해 우리의 다음 방어 계층은 greylisting(RFC 6647)이며, 이는 rspamd를 통해 구현되었습니다. 그 아이디어는 우리가 특정 출처를 처음 볼 때 메시지를 수락하는 대신 임시 실패 응답을 반환하고, 향후 참조를 위해 해당 출처를 기록하는 것입니다.