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

• 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 같은 심층 방어가 필요함