▲

1984년처럼 직접 이메일 서버 운영하기

 (maxadamski.com)
3P by GN⁺ 8일전 | ★ favorite | 댓글 1개
  • 직접 이메일 서버를 운영하면 저렴하게 자동화 작업 및 메일링 리스트 관리 가능함
  • 전송 신뢰도 문제가 현실적으로 존재해 대형 서비스와의 메일 송수신 실패 가능성 있음
  • Postfix와 OpenDKIM 설정만으로 기본적인 SMTP 및 인증 메일 발송 시스템 구축 가능함
  • SSL 인증서와 DKIM, SPF, DMARC 설정으로 메일 신뢰도와 전송 보안 개선 가능함
  • PTR(역방향 DNS) 레코드까지 설정하면 대형 메일 서비스로의 배달률 상승 기대 가능함

개요

직접 이메일 서버 운영은 메일링 리스트, 뉴스레터, 이메일 인증 API 등의 자동화 작업에 유용함
그러나 가장 큰 현실적 과제는 메일 전송 신뢰도로, 제대로 메일이 도착하지 않거나 수신에 실패할 수 있는 위험이 존재함
운영자는 이러한 리스크를 받아들이는 조건에서 개인 프로젝트에 이 방식을 적용하고 있음
직접 운영의 장점은 거의 추가 비용이 들지 않는다는 점인데, 기존 웹사이트에 소프트웨어만 설치하면 되고, 저장공간이나 에너지 소모도 매우 적음
이메일 서버 운영이 너무 어렵다고 생각했지만, 실제로 SaaS형 이메일 서비스 구성과 난이도가 크게 다르지 않음
설정 편의와 단순화를 위해 웹메일, 멀티유저 환경은 우선 생략하여 사용자 계정, 데이터베이스, 웹 인터페이스 구성이 필요없게 만듦
이번 설정에서는 단일 계정 운영에 적합하고, 필요시 SSH 및 mailx, sendmail, mutt 등을 통해 메일 송수신 가능함
향후 필요에 따라 확장 및 웹메일 추가도 고려할 수 있음

Postfix

기본적으로 포트 25를 개방하고, Postfix와 OpenDKIM만 설치 및 설정하면 기본 SMTP 서버 구성 가능함
대부분의 메일 서비스(Gmail 등)에 메일을 안정적으로 전달하려면 OpenDKIM(메일 인증)이 필요함
운영자는 master.cf는 기본값을 그대로 두었고, 메인 설정(main.cf) 예시에서는 TLS 암호화, DKIM 연동 등 핵심 설정만 나타남
POP3/IMAP은 설정하지 않고, 필요시 SSH로 직접 서버에 접속해 mailx 등 명령어로 메일 송수신 가능하도록 단순화함

TLS(전송 암호화)

SSL 인증서는 SMTP 서버와의 데이터 전송을 암호화하기 위해 필요함
여러 도메인마다 인증서를 발급할 필요 없이, 메일 서버가 위치한 단일 호스트(MX 레코드용)만 인증서 있으면 충분함
예를 들어, MX 레코드가 mx.example.com이면, 해당 도메인에만 Let’s Encrypt에서 무료 인증서를 받아 적용하면 됨
TLS는 서버 간 송수신 구간만 암호화하며, 실제 송신 도메인명 인증과는 별개임
따라서 이메일 주소의 From 헤더에는 원하는 값을 자유롭게 설정 가능함

DKIM, SPF, DMARC

DKIM은 메일이 진짜 본인 도메인에서 온 것임을 증명해 메일 신뢰도 확보에 이용
OpenDKIM으로 각 도메인별 키 쌍을 만들고, 공개키를 DNS TXT 레코드로 등록함
키는 자동 만료되지 않으나, 주기적 교체 권장
SPF, DMARC TXT 레코드도 DNS에 추가해, 어떤 호스트가 메일 발송 가능한지 및 DMARC 정책(예: 인증 실패시 거부) 설정
예시 설정 파일(opendkim.conf, KeyTable, SigningTable, TrustedHosts)에서 각 항목 설정법 명확히 확인 가능
DNS에는 MX, SPF, DKIM, DMARC 관련 레코드만 추가하면 됨

역방향 DNS(PTR)

PTR 레코드(역방향 DNS) 는 메일 서버 신뢰도를 높여 대형 서비스(Gmail 등)에 메일이 차단되지 않을 확률을 높임
ISP에 연락해 메일 서버용 PTR 레코드 설정 요청 필요
실제 배포 환경에서는 PTR 레코드가 없어도 Gmail, GMX, Outlook 등에서 정상적으로 수신되었고, mail-tester.com에서 10/10 점수를 받음
PTR 미설정으로 감점 요인이 있었지만 "trusted relay"로 가산점 획득
블랙리스트에도 등록되지 않아 송신 IP 신뢰도도 양호함

Gmail 전송 테스트

sendmail 명령으로 Gmail로 테스트 메일(HTML 메시지) 발송
Gmail에서 즉시 메일이 도착하고, TLS 암호화 확인됨
"Show original"로 원본 메일 보면 SPF, DKIM, DMARC 인증 통과
mailx를 이용해 로컬(서버)에서 메일 수신 내용 확인 가능
설정 문제가 있으면 DNS, 인증서, DKIM 키 접근 권한 등을 재확인 필요, 특히 OpenDKIM의 설정 파일은 오타에 예민

다음 단계

다음 글에서는 Python으로 이메일 응용 프로그램 만드는 방법 소개 예정
문의나 의견이 있다면 max@idx.cy로 연락 가능

▲
GN⁺ 8일전  [-]
Hacker News 의견

  • 20년 넘게 이메일을 직접 호스팅해왔음에 자부심을 느낌, 앞으로도 그럴 계획임. 정작 정부나 관계 부처들은 직접 이메일 시스템을 못 돌리고, 오직 국가 보안 부서만 직접 호스팅하고 있음. 운이 좋아서인지 메일 발송 문제는 거의 없었고, 최근 기억나는 건 마이크로소프트가 내 메일을 삼킨 경우였는데, 그건 오래된 exim과 outlook 쪽 TLS 인증 꼬임 때문이었음. 설정 하나 조정해서 해결함. 유지보수는 그다지 손이 많이 가지 않아서, 뭔가 건드릴 때마다 새로운 걸 배울 기회로 삼고 있음. 올해는 데비안 jessie를 Arch Linux로 갈아타고 크론 작업을 systemd 타이머로 완전히 옮겼음. 중요한 메일을 보낼 땐 서버 로그를 꼭 확인하지만, 이 역시 직접 로그를 살펴보는 좋은 습관이라고 생각함. 조언을 하자면, 직접 호스팅을 취미라고 생각하고 즐길 줄 알면 훨씬 좋음. 마지막으로, Debian에서 Exim 설정을 고안한 사람은 많은 시간을 낭비하게 만든 장본인임. Exim을 Debian에서 구축한다면, 공식 Upstream 설정으로 바꿔서 본인에게 맞게 커스터마이즈하는 게 답임

    • 요즘 SNS들이 “탈중앙화”나 “오픈”을 강조하며 자랑하지만, 사실 우리에겐 독립적으로 완전히 자립할 수 있는 도구들이 이미 있음. UX를 개선한다고 하면서, 정작 사용자 주도권이 사라지고 있다는 점을 놓치곤 함. 결국 지나치게 단순화된 시스템에 익숙해지다 보면, 미래엔 누군가 타지에서 “거래”를 허락하지 않으면 앱 하나조차 설치 못하는 세상이 옴

    • 대학 시절(WWW 이전)에 처음 이메일을 썼고, 이후엔 ISP 계정(아주 제한된 저장공간과 POP만 지원)이라 직접 메일 서버를 돌리게 됐었음. 항상 인터넷에 연결되어 있지 않을 때라 릴레이와 다이내믹 DNS로 메일 수신을 했었음. 현재는 VPS를 경유해 집 서버에서 메일을 받아 저장함. 수년 동안 아웃룩 등 메이저 메일 서비스에 IP 또는 도메인 해제를 요청해야 했던 적도 있지만, 그리 잦지 않았음. 단 두세 개 회사가 전 세계 이메일을 지배하는 세상엔 살고 싶지 않아서, 이런 직접 호스팅이 작은 저항 행위라고 생각함

    • 예전 20년 전 만큼의 동기부여가 지금 1%라도 남아 있었으면 좋겠다는 생각임. 이제는 풀타임 직장과 가족(아내와 아이)으로 시간이 없어서 그런 작업을 할 여력이 없음

    • 나 역시 한때 직접 호스팅을 멀리하게 됐는데, 시간/비용 밸런스가 달라지면서 다시 할 만한지도 생각 중임. 이메일 호스팅에서 가장 고민되는 게 스팸 관리임. 요즘은 어떻게 되고 있는지, 혹시 팁이 있다면 공유 부탁함

    • 내겐 이메일이 아주 중요한 서비스임. 15년간 직접 호스팅하다가 그만둔 이유는 1) 정기적인 백업/복구와 모니터링이 잘 안 돼서, 2) 재해 복구 플랜이 없어서 타 서비스보다 비용이 더 들었고, 3) 보안에 항상 신경 못 쓰고 있어서임. 친구 서버는 랜섬웨어에 당해서 자료를 다 날렸지만, 난 FreeBSD라 무사함(공격 타깃이 아니었음). 일반적으론 유지보수가 복잡하지 않지만, 한번 꼬이면 정말 고생스러울 수 있고, 치명적일 수도 있음

  • 예전엔 직접 이메일을 호스팅했는데, 포기한 건 평판 때문이 아니라 100% 가동시간을 피할 수 없어 메일 유실이나 블랙리스트 등록 위험이 생겼기 때문임. 이메일 프로토콜 상으로 다운타임에 강한 게 맞지만, 실제로 큰 이메일 제공업체들은 한번만 문제 생겨도 바로 메일을 거부하고 다시 시도하지 않음. 예전 GitHub도 한 번 바운스나면 “수신 불가”로 찍고 이후 메일을 아예 안 보냈었음. 지금은 개선됐지만, 최신 이메일 시스템은 “항상 온라인”이란 전제를 두고 있음

    • 내 메일 서버는 일부러 처음 온 메일을 거부하는 그레이리스트 기능을 씀. 수많은 메일을 받아봤지만, 정상적인 메일이 미전달된 사례는 한 번도 없었음. 재전송은 이메일 표준에 내장되어 있으므로, 걱정된다면 백업용 수신 메일 서버를 추가로 두고 LMTP로 백홀하면 됨. 이메일이라는 시스템 자체가 원래 24시간 항상 연결되어 있지 않은 시대를 고려해 설계된 것임

    • 이런 얘기는 과장임. 내 경우 메일이 안 오면 몇 시간이나 하루 지나 다시 도착했고, 어디서 문제 터졌는지 일반적으로 알 방법이 없음. 제대로 인증만 하면(예: dkim, spf) 직접 호스팅도 99% 이상 전달 가능성을 확보할 수 있음. 복잡함에 쫄 필요 없음. 덤으로 caldav도 사적으로 활용 가능함

    • 서버가 몇 시간 다운돼도 왜 “메일 유실” 걱정을 하는지 궁금함. 내 서버는 219일 연속 가동 중임. 우리가 평소 하는 일에 비하면 이메일 서버 운영은 정말 쉬운 일임

    • 정말로 요즘 이메일 시스템을 보면 “내 아들한테 무슨 짓을 한 거냐”는 느낌임

  • 이메일 직접 호스팅을 시작하고 싶은 분께 드리는 조언: 일단 계정 가입용으로만 직접 호스팅 이메일을 사용해보기 바람. 처음부터 개인 연락용으론 쓰지 않아도 됨. “Mail-in-a-box”를 활용하면 https://mailinabox.email./ 설치 가이드만 따라가도 몇 시간 만에 구축이 가능하고 잘 작동함. 1~2년 써보고 충분히 익숙해졌을 때 그때서야 개인 연락용을 옮겨보길 추천함

    • Stalwart https://github.com/stalwartlabs/stalwart 를 추천함. 하나의 바이너리로 완결된 메일 서비스라 의존성 없고 설치/업데이트가 너무 쉬움. 다른 프로젝트를 많이 시도해봤지만 Stalwart가 제일 간편했고, 문제 하나 없이 굴러감

    • MIAB를 클라우드에서 수년간 운용 중임. IP 평판만 깨끗하면 발송도 문제없으나, Outlook 쪽에 이메일이 안 갈 땐 Microsoft postmaster에 직접 메일을 보내 해결함. DKIM/SPF/DMARC 설정 등 익힐 수 있어서 배움에 좋아 추천함. 다만, 회원가입 이메일을 수신하는 게 정말 힘듦. MIAB의 그레이리스트가 처음 온 발신자를 거절하고 재시도를 기다리는데, 정상 사이트조차 재시도 안 하는 경우가 많음. 인증용, 2차 인증코드 메일이 오는데 시간이 한참 걸리고, 스팸필터를 잠시 꺼놓을 쉬운 방법도 없음

  • 요즘 ISP 제공 이메일도, 심지어 Google Gmail도 스팸 필터링 등에서 종종 문제가 생김. 예: Shopify를 통해 주문하면, shopify 메일이 Gmail에서 계속 스팸 처리됨. DMARC, SPF, DKIM 다 통과해도 왜 걸리는지 모를 정도임. 이메일 송수신 자체는 기술적으로 어렵지 않고, 어느 서비스를 쓰든 100% 완벽하진 않음. 악성 사용자(스패머)가 워낙 많아서, 이 시스템이 이만큼 잘 돌아가는 게 신기할 정도임

    • DMARC, SPF, DKIM 등은 인증 관련 설정일 뿐, 스팸 여부랑은 직접 상관 없음. 인증 제대로 한 쓰레기 메일도 있고, 인증 안 된 보석 같은 메일도 있음

    • Shopify 메일이 스팸으로 분류되는 이유는 Shopify가 많은 사람들이 스팸으로 지정하거나, 같이 사용하는 메일 서버에 평판이 안 좋은 사용자가 있기 때문임. 내가 계속 스팸 아님으로 표시해도, 전체 발신자 평판이 너무 안 좋으면 스팸함을 벗어나지 못함

    • 직접 이메일 호스팅을 20년가량 해왔음. 10~15년 동안은 모든 메일을 Gmail로 포워딩했지만, 중요한 메일까지 사라지는 스팸 필터에 질려서 직접 imapd를 돌리기 시작함. SPF 등 제대로만 설정하면 직접 호스팅이 훨씬 낫다고 느낌

    • 이런 필터링 정책이야말로 문제임. 직접 호스팅하거나 소규모 이메일 서비스를 쓰면 오히려 메일이 차단될 일(특히 Gmail 등의 엄격한 필터로)은 훨씬 적음. Google은 스팸의 주범인 Gmail 사용자들이 많은데도 여전히 잦은 필터링 정책을 고집함

    • 요즘 Gmail의 스팸 필터가 마케팅 메일엔 지나치게 민감하게 반응함. 10년 전엔 반대 문제였는데, 지금은 스팸함에 너무 많이 걸려서 귀찮을 정도임. 오히려 요즘 스팸의 상당수는 소규모 신규 메일 주소에서 온 콜드메일임. Gmail의 마케팅 메일은 “구독 취소” 기능이 잘 작동하지만, 이런 콜드메일에겐 소용없음

  • 완벽한 구축 및 다양한 클라이언트와 연동 가능한 IMAP 서버를 원한다면 https://workaround.org/ispmail-bookworm/ 가이드가 더 적합함. 나는 데이터베이스 대신 평문 파일로 간단하게 운용 중임. 나만 사용자라면 이렇게 해도 좋고, 위 가이드는 대규모 기업용으로도 충분히 확장 가능함

    • 나도 위 가이드를 쓰지만, 데이터베이스는 PostgreSQL로 교체해서 씀. 최근 Trixie 업그레이드 후 Dovecot 설정이 크게 바뀌어 좀 고생했지만, 지금은 문제없이 잘 돌아감

  • 직접 플러그인: 우리는 자체 호스팅 대안을 만드는 Hyvor Relay https://github.com/hyvor/relay 를 베타 테스트 중임. DKIM/SPF 모니터링과 DNS 자동화 등 가시성에 집중하고 있음. Docker compose up 한 번이면 바로 운용 가능함 https://relay.hyvor.com/hosting/deploy-easy

  • 10~15년간 저렴한 kimsufi 박스에서 opensmtp, dovecot, rspamd로 이메일 자체 호스팅을 해옴. 별 문제는 없었고, 한 번 telekom.de에 서버가 막힌 적 있지만, 정식 메일로 설명하자 곧바로 화이트리스트에 올려줌. IP를 오래 가지고 있어서 그런지, 개인적으론 다들 겪는다는 문제를 느끼지 못했음. 다만, 서버랑 IP가 내 명의로 소유 중임

  • Debian trixie기반 자가 이메일 호스팅 관련 독일어 글을 https://krei.se/Doc 에서 공유함. 직접 제대로 구축하면 정말 즐거움. 자동 업데이트와 재부팅, 맞춤 systemd로 상태 리포트를 매일 메일로 받고 있음. 2~3년은, trixie라면 최대 5년까지 손댈 필요도 없이 안정적임. 이메일 서버 소프트웨어는 이미 충분히 성숙함. 직접 호스팅을 추천함. 자율과 평온, 직접 통제가 정말 값짐

  • 10년 넘게 이메일 직접 운영 중이고, 예전 HN 댓글도 종종 링크로 남겼음(예: 39891262, 38471262). Digital Ocean 아이피가 악성으로 찍히는 바람에 발신은 Amazon SES로 대체했고, Gmail을 무료 스팸 훈련기로 써서 자체 필터에 활용하고 있음(38843288). 많은 분이 언급한 대로, 그레이리스트가 크게 도움됨. 정상 메일 서버는 반드시 재시도하니, 2차 인증 등엔 불편하지만 시스템적으로 신뢰할 만함. 다운타임이 며칠 있어도 걱정없고, 수신/저장 서버를 분리해 백업도 쉬움(38512732). 2FA 메일과 관련해 https://github.com/stevejenkins/postwhite 를 병행 쓰지만, 사실 이메일을 2FA용으로 권하고 싶지는 않음(이 주제는 별개의 논의가 필요함)

    • 최근 Amazon SES에서 보낸 중요한 메일을 스팸차단 리스트(bl.spamcop.net) 때문에 못 받았음. Amazon이 여러 아이피로 재시도하다 그레이리스트를 만나면서 결국 한 번은 거절당함. 대형 업체 간(MX에서 MX로) 송신에는 그리 문제가 없을 수도 있지만, 이런 구조도 100% 완전한 솔루션은 아님

    • 결국 길게 얘기해도, 그냥 Gmail 등 메이저 이메일 서비스 쓰는 게 낫다는 결론인 것 같음

  • UUCP는 어디 있고, 왜 주소가 bang path가 아니냐, sendmail.cf는 어디 갔냐는 궁금증임

    • 맞음. 1984년식(고전 email)으로 직접 호스팅하려 하면 모든 메일을 중계하는 오픈 릴레이가 되고, 각종 취약점에 노출되어 위험함

    • 그 시절 얘기하자면, 대학 연구실에서 Unix 워크스테이션 6대로 email을 한 서버에서 다른 서버로 이동시키면서 disk에서 나는 소리로 메일이 오가는 걸 느꼈던 추억이 있음

    • 나도 제목을 보고 bang path와 “killer!jolet!” 주소가 생각났음. 정말 그리운 시대임

    • 동감함. ‘1984’ 제목에 혹해서 들어왔는데, 정작 ‘postfix 설정’ 얘기라 실망임

답변달기