자체 라우팅 가능한 IPv4 블록부터 시작하는 어려운 방식의 이메일 자체 호스팅

 (anil.recoil.org)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 1997년부터 운영된 Recoil 메일 인프라는 전용 IPv4 /24 블록, Postfix, Dovecot, rspamd, Roundcube 등을 조합해 수신·발신·접근을 직접 처리하는 자체 호스팅 스택으로 갱신됨
  • 자체 메일 운영은 데이터 접근권과 학습 가치가 있지만, 신뢰 기반이 약한 SMTP 위에서 IP 평판, DNS 기록, 스팸 방어를 직접 관리해야 함
  • 수신 경로는 postscreen, DNSBL, 그레이리스팅, ClamAV, 베이지안 필터링, LMTP, Sieve를 거쳐 봇 트래픽과 악성 메일을 단계적으로 줄이는 구조가 됨
  • 발신 신뢰성은 SPF, DKIM, DMARC, SRS에 의존하며, 잘못 설정하면 Gmail·Outlook 같은 수신자 측 검사에서 스팸 처리되거나 조용히 폐기될 수 있음
  • 2026년의 이메일 자체 호스팅은 여전히 가능하지만, IPv4 확보, 여러 DNS 기록, 보안 업데이트, AI 기반 취약점 악용에 대응하는 심층 방어가 필요함

왜 자체 이메일을 운영하는가

  • 자체 서버 운영은 시스템과 네트워킹을 배우는 교육적 경험이며, 인터넷 작동 방식과 오픈소스 참여를 익히는 경로가 됨
  • 웹이 소수 사업자 중심으로 통합되는 상황에서 자체 호스팅은 자기 데이터에 대한 주권적 접근을 유지하는 방법이 됨
  • 2023년 분석은 이메일 트래픽을 읽을 수 있는 주체가 대체로 Google과 Microsoft로 귀결된다고 평가함
  • 이메일은 많은 온라인 계정의 비밀번호 재설정에 연결되어 있어, 계정 탈취나 피싱이 다른 서비스 접근권까지 흔들 수 있음
  • 자체 메일 운영에는 장기간의 관리가 필요하며, 홈 네트워크보다 안정적인 인터넷 호스팅과 평판 축적이 필요함

이메일 수신 구조

  • 인터넷 도메인은 MX DNS 기록으로 메일을 받을 SMTP 서버를 지정하며, recoil.org는 pork.recoil.org가 메일을 처리함
  • SMTP는 1980년대의 더 신뢰 기반인 설계에서 출발해 발신자 신원을 기본적으로 증명하지 못하며, 수신 메일의 발신자는 쉽게 위조될 수 있음
  • IETF 대응은 여러 신원 검사를 쌓는 방식으로 발전했으며, 이 검사를 잘못 설정하면 메일 전달 신뢰성이 떨어짐
  • DNS 기반 차단 목록은 봇넷, 침해된 호스트, 스패머 정보를 집계하며, 메일 서버가 RBL을 조회해 의심 IP를 걸러낼 수 있음
  • 이메일 평판은 도메인이 아니라 IP 주소에 쌓이므로, 클라우드에서 재사용된 주소나 같은 블록의 이웃 IP가 평판에 영향을 줄 수 있음

  • 전용 IPv4 블록 확보와 라우팅

    • Recoil은 185.33.27.0/24 전용 IPv4 주소 블록을 확보해 메일 평판을 독립적으로 쌓을 수 있게 됨
    • RIPE NCC는 2019년 11월 미할당 IPv4 공간을 소진했으며, 이후 직접 할당은 소규모 /24 대기 목록을 통해 처리됨
    • /24 블록은 약 6개월 대기 후 할당됐으며, 유럽에서 직접 신청하려면 RIPE NCC 회원비를 내고 LIR 계정을 열어야 함
    • 할당받은 IPv4 블록은 RPKI ROA를 생성해 라우팅 권한을 지정하며, Recoil의 블록은 Mythic Beasts AS44684에 연결됨
    • 역방향 DNS도 직접 제어할 수 있으며, 185.33.27.128은 pork.recoil.org로 매핑되어 이메일 평판 신호가 됨

봇과 스팸 방어

  • 깨끗한 IPv4 블록 확보만으로는 충분하지 않으며, 포트 25로 들어오는 TCP 연결 대부분은 스팸 전달, 오픈 릴레이 탐색, 자격 증명 추측, AI 학습 데이터 수집 시도임
  • Postfix postscreen은 포트 25 앞단에서 DNSBL 병렬 조회, pre-greet 지연, 파이프라이닝 및 비 SMTP 명령 검사를 수행함
  • postscreen은 정상으로 보이는 클라이언트만 실제 smtpd로 넘기며, 잘못된 클라이언트는 임시 실패로 끊어 오탐이 재시도할 수 있게 함
  • Spamhaus, Spamcop, Barracuda 목록은 가중치로 조합되며, Spamhaus 단독 또는 약한 두 목록의 동시 판정으로 거부하도록 설정됨
  • Apple iCloud 발신 MX 풀은 같은 IP에서 재시도하지 않아 postscreen 허용 목록과 맞지 않으므로, 17.0.0.0/8 전체를 우선 허용해 우회하도록 설정함

  • 그레이리스팅과 콘텐츠 검사

    • 그레이리스팅은 처음 보는 발신원에 임시 실패를 반환하고, 정상 MTA가 몇 분 뒤 재시도하면 통과시키는 방식임
    • 단발성 봇넷은 실패 후 다음 대상로 이동하는 경우가 많아, 재시도 큐를 유지하는 정상 발신자와 구분됨
    • postscreen과 그레이리스팅을 통과한 뒤에는 원래 봇 트래픽의 99% 이상이 낮은 CPU 비용으로 차단됨
    • rspamd는 milter 프로토콜로 모든 메시지를 검사하며, 수상한 메일을 수락 후 반송하지 않고 발신 서버가 연결된 상태에서 거부하거나 지연시킴
    • ClamAV는 알려진 바이러스 첨부파일을 검사해 감염 메시지를 즉시 거부하며, rspamd의 베이지안 분류기는 Redis에 저장된 스팸·햄 말뭉치로 메시지를 점수화함

로컬 전달, 저장, 필터링

  • 수신 메시지는 postscreen, 그레이리스팅, rspamd, ClamAV, 베이지안 분류기를 거친 뒤 Dovecot으로 전달됨
  • Postfix가 사용자 홈 디렉터리에 직접 쓰는 대신, Dovecot에 LMTP로 넘겨 인덱싱, 할당량, 전체 텍스트 검색, Sieve 필터링을 맡김
  • virtual_alias_maps는 anything@recoil.org 같은 주소를 로컬 전달 가능한 주소로 변환함
  • 저장 형식은 1998년부터 사용한 Maildir이며, 각 이메일을 사용자 ~/Maildir 아래의 단일 파일로 저장함
  • Maildir은 tmp/, new/, cur/ 세 하위 디렉터리와 POSIX 원자적 rename을 이용해 메일함 전체 잠금 없이 새 메시지를 전달할 수 있음

  • 검색 인덱스와 Sieve

    • Stalwart 같은 현대적 메일 서버도 검토했지만, Maildir을 지원하지 않고 RocksDB 같은 사용자 지정 데이터베이스 저장을 요구해 전환하지 않음
    • Dovecot은 별도 전체 텍스트 인덱스인 Flatcurve를 통해 Maildir 저장과 검색 성능을 분리함
    • Flatcurve는 Xapian 래퍼이며, 각 메일함별 Xapian 인덱스를 ~/Maildir/fts-flatcurve 아래에 두고 새 메일 도착 시 자동 갱신함
    • Sieve는 메일 필터링 전용 선언형 언어이며, Dovecot의 Pigeonhole Sieve 플러그인이 배달 시점 사용자 필터를 실행함
    • 시스템 전체 Sieve 스크립트는 rspamd가 표시한 메일을 Junk로 보내고, 사용자별 스크립트는 폴더 분류, 휴가 규칙, 우선순위, 헤더 편집 등을 처리함

신뢰성 있는 이메일 발신

  • 메일을 안정적으로 보내려면 수신 방어만큼 발신 인증이 중요하며, 대형 수신자의 검사 중 하나라도 실패하면 스팸 폴더로 가거나 조용히 폐기될 수 있음
  • SPF는 도메인 최상위의 DNS TXT 기록으로, @recoil.org 발신을 주장할 수 있는 IP 주소를 선언함
  • Recoil의 SPF는 v=spf1 a mx -all이며, recoil.org의 MX가 가리키는 pork.recoil.org만 유효한 발신자로 간주됨
  • Postfix는 여러 IP를 가진 호스트에서 커널이 임의 주소를 고르지 않도록 smtp_bind_address와 smtp_bind_address6로 특정 발신 주소에 묶임
  • DKIM은 메시지 본문과 선택 헤더의 정규화된 형태에 암호학적 서명을 붙이고, 공개 검증 키를 DNS의 <selector>._domainkey.<domain>에 둠

  • DMARC와 SRS

    • DMARC는 SPF와 DKIM으로 인증된 도메인이 사용자가 보는 From: 헤더와 맞는지 확인하고, 실패 시 수신자가 어떻게 처리할지 알려줌
    • Recoil의 DMARC 정책은 p=quarantine이며, rua= 주소로 집계 보고서를 받아 전달성 문제를 디버깅함
    • 주요 수신자는 하루 한 번 정도 recoil.org 발신을 주장한 메시지 요약 XML 보고서를 보내며, Google, Microsoft, Yahoo, Fastmail 등이 여기에 포함됨
    • 전달 메일은 원래 발신자 도메인이 Recoil IP에서 보내지는 형태가 되어 SPF가 실패할 수 있음
    • SRS는 발신 봉투 주소를 SRS0=…=example.com=original@recoil.org 같은 형태로 다시 써서 목적지의 SPF 검사가 Recoil 도메인을 기준으로 평가되게 함

사용자 접근과 웹메일

  • 사용자는 일반 IMAP 클라이언트로 Dovecot 서버에 접속하거나, 자체 호스팅 웹메일을 브라우저로 열어 메일에 접근함
  • Dovecot은 pork의 메일함 접근을 처리하고 TLS로 리스너를 암호화해 평문 메일이나 비밀번호가 공용 네트워크를 지나가지 않게 함
  • 인증서는 LetsEncrypt를 사용하며, imap.recoil.org, smtp.recoil.org 같은 여러 호스트 별칭은 SNI로 제공됨
  • Dovecot은 Postfix의 SASL 백엔드 역할도 하며, 사용자가 IMAP 접근과 SMTP 발신에 같은 비밀번호를 사용할 수 있게 함
  • Roundcube는 Caddy TLS 리버스 프록시 뒤에서 Docker Compose 서비스로 실행되며, 일반 클라이언트처럼 TLS/IMAP으로 pork에 연결함

  • Roundcube 플러그인

    • Roundcube의 managesieve 플러그인은 브라우저에서 Sieve 필터를 편집할 수 있게 ManageSieve 프로토콜을 사용함
    • markasjunk 플러그인은 웹메일의 “Junk” 버튼을 Junk 폴더 이동으로 바꾸며, 이 이동이 햄·스팸 분류 학습을 사용자에게 보이지 않게 작동시킴
    • Roundcube ManageSieve UI는 원시 Sieve DSL을 노출하지 않음

남은 작업과 자체 호스팅의 의미

  • 현재 설정은 최근 몇 주간 일상 사용에서 꽤 견고했지만, 더 해야 할 작업이 남아 있음
  • recoil.org는 MX, A/AAAA, PTR, SPF TXT, DKIM TXT, DMARC TXT 같은 DNS 기록을 조합해 메일 수신·발신·검증을 구성함
  • MTA-STS는 다른 메일 서버가 유효한 인증서를 가진 TLS로만 통신하도록 알려 STARTTLS 다운그레이드 공격을 완화함
  • DANE/TLSA는 HTTPS 대신 DNS에 고정된 TLS 인증서 해시를 쓰지만, DNSSEC 서명된 DNS 존이 필요해 아직 배포되지 않음
  • SRS는 일부 배포됐지만 모든 전달 경로에서 검증되지는 않았으며, INRIA 관련 실패는 DMARC 실패와 도메인 평판 영향 가능성 때문에 우려 대상임

  • JMAP, 보안, 향후 자체 호스팅

    • JMAP은 HTTPS와 JSON을 사용해 현대 네트워크 클라이언트에 IMAP보다 더 잘 맞는 메일 접근 프로토콜임
    • Dovecot은 JMAP을 네이티브로 지원하지 않고, 평가한 독립 JMAP 서버들은 Maildir을 포기하고 자체 메일함 저장소를 요구함
    • 고려 중인 계획은 OCaml JMAP 구현을 Dovecot 앞에 번역 프록시로 두고, JMAP 요청을 IMAP 호출로 매핑한 뒤 JSON 응답을 돌려주는 방식임
    • 2026년에 메일 서버를 운영하려면 최소 여섯 개 DNS 기록을 정확히 맞춰야 하며, RIPE에서 IPv4 블록을 확보하는 데는 거의 1년이 걸림
    • CVE 공개와 SMTP/IMAP 리스너 대상 실제 익스플로잇 투입 사이의 간격은 이제 몇 주가 아니라 몇 시간 단위로 측정될 가능성이 있으며, 특정 주소 고정, 웹메일 컨테이너 격리, 그레이리스팅, DNSBL 같은 심층 방어가 필요함

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들

  • 수십 년 동안 해오던 일을 불가능하다고 단언하는 문지기들을 계속 관찰하게 됨
    실제로는 역방향 DNS, SPF, DMARC, MTA-STS만 설정하면 충분하고, 비용도 많이 들지 않으며 어렵지도 않다고 계속 말하는 중
    예시 메일 서버: https://poofydoof.zia.io/

    • 2008년쯤부터 직접 자가 호스팅 이메일을 운영해왔는데, 아직도 불가능하다고 말하는 사람이 많아 당황스러움
      지금은 Debian + Postfix, Dovecot, rspamd 조합이고, 내 설정보다 직장의 Google Workspace에서 문제가 더 자주 생김
    • “수십 년 동안 해오던 일”이라는 부분이 핵심이라고 봄
      역방향 DNS, SPF, DMARC, MTA-STS만 설정하면 된다는 말은 이미 평판이 좋은 도메인과 IP 주소에는 100% 맞음
      큰 사업자들에게 이미 신뢰받는 메일 서버에 새 도메인을 추가하면 평판이 빨리 쌓이고, 기존 도메인을 새 메일 서버 IP로 옮기면서 DKIM까지 설정했다면 괜찮음
      하지만 새 도메인과 새 메일 서버 IP로 처음부터 시작하면 상황이 꽤 다르다고 들었고, 대형 사업자의 기계학습 시스템이 만족할 때까지 자동으로 스팸 처리될 가능성이 큼
      그쪽 시스템 사용자들이 내 도메인으로 메일을 보내고, 스팸함에서 답장을 꺼내는 식의 행동이 흔히 잘 먹히는 듯함
    • 3년 정도 메일 서버를 운영해본 바로는 어려운 부분은 DNS, SPF, DMARC, MTA-STS 설정이 아니라, 트랜잭션 메일을 보낼 때 차단 목록에 얻어맞지 않는 것과 일부 이메일 제공자에게 허용 목록 등록이 안 되는 쪽임
      그런 걸 계속 쫓아다니는 데 시간을 쓰느니, 한 달에 5달러 정도 내고 누군가에게 맡기는 편이 낫다고 봄
    • 예시 메일 서버가 멋지고, 이것도 좋음
      https://dmesgd.nycbug.org/dmesgd?do=view&id=8929
      이 구성에 대한 세부 정보가 더 궁금함
      Mango Pi MQ-Pro는 구하기 어려워 보이는데, NetBSD/Linux 지원이 괜찮은 다른 초저가 장치가 있는지도 궁금함

  • 직접 메일 서버를 운영할 또 하나의 이유는, 누군가가 이미 내 도메인으로 스팸을 보내고 있다는 사실을 발견할 수 있기 때문임
    내 도메인 하나가 Google Domains 매각 때문에 Squarespace로 이전됐을 때, Mailgun 계정이 없었는데도 Squarespace가 Mailgun용 MX/SPF/DKIM DNS 레코드를 자동으로 추가했음
    누군가 Mailgun에서 그 계정을 차지했고, 내 도메인에서 보낸 것처럼 내게 스팸을 보냈음
    고맙다, Google

  • 특히 IPv4 할당 부분이 흥미로움
    유럽에서 직접 하려면 RIPE NCC 연회비를 내고 지역 인터넷 레지스트리(LIR) 계정을 열라고 되어 있는데, https://www.ripe.net/membership/payment/ 에 따르면 연 1800유로임
    꽤 아프지만, 더 싸면 스패머들이 더 쉽게 악용하긴 할 듯함

    • 싸지는 않지만 주소당 연 약 12파운드라서, 지역 친구와 가족 서비스에 나눠 쓰면 그렇게 나쁘진 않음
      OCaml로 BGP 서버를 작성하는 재미는 값으로 매길 수 없음 :-)

  • 이메일 송수신에 IPv6를 현실적으로 쓸 수 있는지 궁금함

    • 좋은 질문임
      글을 쓸 때 살펴봤지만, 몇 년 전 내 메일 서버에서 IPv6를 꺼둔 상태라 경험을 더 쌓을 때까지 미루기로 했음
      https://dn.org/ipv6-and-domain-reputation-in-anti-spam-filters 에 따르면 Gmail, Microsoft, Yahoo 같은 이메일 제공자는 도메인 평판과 IP 평판을 서로 다르게 가중하는 독자 스팸 필터를 쓰고, IPv6 지원도 계속 성숙 중임
      Gmail은 IPv6 메일에 유효한 PTR 레코드, SPF, DKIM을 요구하고 DMARC 사용도 적극 권장함
      이런 요소 없이 IPv6로 보낸 메일은 스팸함에 들어가거나 지연되는 경우가 많음
      Microsoft의 필터링 시스템은 IPv6를 SNDS와 JMRP 프로그램에 포함하지만, 발신 평판이 알려져 있지 않으면 IPv6 메일을 제한하거나 지연시킬 수 있음
      결국 IPv6는 또 하나의 실패 지점이고, 처음 시작할 때 IPv4/IPv6 혼합 전송 도메인을 구성하는 건 아마 좋지 않은 생각임
      아직 IPv6 전용 SMTP 종단점은 찾지 못했음
답변달기