직접 이메일 서버를 운영할 때 필요한 조건과 보안 수칙

이메일 서버를 직접 운영하면 수신 메시지가 스팸함으로 가거나 사라지는 일을 줄일 수 있지만, 송신에는 도메인과 DNS 인증 설정이 필요하다. 글쓴이는 서버 요건과 스팸 대응, 보안 수칙을 개인 운영 경험을 바탕으로 설명한다.

이메일은 평판만큼 어렵지 않다는 것이 글쓴이의 견해다. 대형 기술 기업의 메일 서비스도 메시지를 스팸으로 보낼 때가 있고, 유료 서비스를 쓴다고 전달이 보장되는 것도 아니라고 말한다. 글쓴이의 경험으로는 같은 서비스 안의 메일은 대체로 안전하지만, 서로 다른 대형 기술 기업 사이에서는 전달될 가능성이 약 75%라고 한다.

직접 메일 서버를 운영하면 상대가 보낸 메일이 알 수 없는 이유로 사라지지 않으리라고 확신할 수 있다는 설명이다. 답장이 스팸으로 분류될 수는 있지만, 그때는 이미 대화가 시작돼 문제를 해결할 수 있다고 덧붙인다. 다른 방법으로는 대형 기술 기업 계정으로 대화를 시작하되 reply-to 헤더를 직접 운영하는 서버 주소로 지정하고, 연락처로도 그 주소를 알려주는 방식을 제안한다.

메일을 받으려면 외부에서 연결할 수 있는 IPv4 주소와 서버가 필요하며, 도메인은 선택 사항이다. 서버가 항상 가동될 필요는 없다. 2026년에도 IPv6를 지원하지 않는 메일 서버가 많아 공인 IPv4 주소를 구해야 한다. 인터넷 서비스 제공자가 이를 제공하지 않으면 데이터센터 공간을 임대하는 것이 사실상 유일한 선택지이며 비용이 든다. VPS가 직접 메일 서비스를 실행할 필요는 없고, 집에 있는 장비로 트래픽을 전달할 수도 있다.

메일 서버 하드웨어는 특별할 필요가 없다. 이메일 한 통은 보통 몇 메가바이트에 불과하고, 사람들은 하루에 몇 통만 보내기 때문이다. 다만 여러 사용자가 쓸 계획이라면 디스크 용량을 고려해야 한다. 메일 서버는 중단된 동안에도 전달을 재시도하고, 며칠이 지난 뒤에야 포기한다. 전달에 실패하면 발신자에게 오류 알림을 보내므로 메일이 조용히 사라지지는 않는다고 설명한다.

도메인 없이도 ihavenoname@[65.109.172.162]처럼 IP 주소를 포함한 유효한 메일 주소를 만들 수 있다. 다만 이 방식은 정체성을 호스팅 업체나 인터넷 서비스 제공자에 묶는다. 도메인은 대략 월 1달러가 들지만, 갱신을 놓치면 다른 사람이 도메인을 사서 기존 주소를 차지할 수 있다. 글쓴이는 도메인 비용을 평생 800달러로 생각하고, 부수 프로젝트용 도메인을 또 살 때는 신중해야 한다고 말한다. 메일을 받으려면 MX 레코드도 설정해야 한다.

메일을 보내려면 PTR 레코드가 있는 IP 주소와 도메인이 필요하다. 발신 도메인은 패킷의 신뢰성을 증명하는 DNS 레코드를 설정해야 하며, 여기에는 SPF와 DKIM이 포함된다.

; SPF record
@ TXT "v=spf1 ip4:65.109.172.162 ip6:2a01:4f9:c011:841a::1 -all"

SPF는 지정한 IP 주소에서 온 메일만 받도록 하고 나머지는 거부하라고 수신 서버에 알린다. IP 주소가 여러 개라면 메일 서버가 특정 주소를 사용하도록 설정해야 한다. SPF 레코드가 없을 때 대부분의 서버는 모든 메일을 거부하는 것으로 처리한다. 루트 도메인에 SPF가 있더라도 공격자가 존재하지 않는 하위 도메인에서 온 것처럼 메일을 위조할 수 있기 때문이다.

DKIM은 DNS에 공개한 암호화 서명 키를 이용하는 인증 방식이다. 아래는 글쓴이의 키이며, 직접 운영하려면 별도의 키를 생성해야 한다.

2020._domainkey TXT "v=DKIM1;h=sha256;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBi
QKBgQDcysWHfXhdjsK3jWRnUKa3cdNF7gfl0EP/Xe2r5Ixqp7htPRVx7sntLgF1S5fODBM9o9xWSTwu
TuuFF0DLvkvi2fiddiSFa+0IXMb7sevhYIGha6Ewpk5h4vHkRIEGG7MDTlnXovgQpq5Q6MUymU6Z+Or
H6xXBaiwf8wOfZtRIYwIDAQAB"

대부분의 메일 서비스 제공자는 발신 IP 주소의 역방향 DNS도 요구한다. 메일 발신에 쓰는 도메인과 같을 필요는 없지만, 서버와 연결된 공개 호스트 이름이어야 한다.

스팸은 예상보다 큰 문제가 아니었다고 글쓴이는 말한다. 모든 주소로 메일을 받는 설정과 공개 웹사이트에 연락처 주소를 올린 조건에서도 SPF 검사만 하고 차단은 강제하지 않았으며, 간단한 주소 난독화와 도메인 및 IP 주소 12개를 차단하는 블랙리스트로 대응했다. 인증되지 않은 메일도 허용하는 데 따른 위조 위험은 주소를 무제한으로 만들 수 있어 크게 걱정하지 않는다고 설명한다. 예를 들어 블로그 댓글 주소로 호스팅 업체의 청구서인 척하는 메일이 오면, 보낸 사람 표시와 본문이 어떻든 가짜임을 알 수 있다는 것이다.

SPF를 느슨하게 적용해도 스팸을 상당수 걸러낼 수 있었다고 한다. 성가신 스패머 상당수는 SPF 레코드가 있는 잘 알려진 도메인에서 온 것처럼 메일을 위조하기 때문이다. 글쓴이는 HTML을 읽지 않는 스팸 봇이 많아 간단한 난독화만으로도 이를 피할 수 있다고 설명한다.

<!-- A random comment -->
blog@maurycyz<!--.example-->.com

<!-- Or needless percent encoding -->
<a href=mailto:blog@%6daurycyz.com>email</a>

이 방식은 모든 브라우저에서 작동하고 화면 낭독기와 호환되며, 사람이 직접 주소를 알아내기도 어렵지 않다고 한다. 글쓴이는 더 극단적인 방법을 쓸 필요는 없다고 본다. 스팸을 완전히 없애려면 블랙리스트에 긴 목록이 필요하지만, 자신은 도메인 7개와 IP 주소 5개를 막아 주당 약 3건으로 줄였다고 설명한다. 중요한 메일이 차단되지 않도록 스팸을 어느 정도 남겨두는 편이 합리적인 대가라는 견해다.

이메일 계정이 침해되면 개인정보 유출뿐 아니라 여러 서비스의 비밀번호 재설정과 계정 복구까지 위험해진다. 기술적 공격뿐 아니라 허술한 비밀번호도 문제가 되므로, 좋은 비밀번호를 쓸 자신이 없다면 키 기반 인증을 설정하라고 조언한다.

취약점 방어에는 모든 소프트웨어를 최신 상태로 유지하고 서비스를 격리하는 것이 중요하다고 글쓴이는 말한다. 자동 업데이트를 설정한 뒤 한 달 후 제대로 작동했는지 확인하고, 서비스마다 권한이 제한된 별도 사용자를 써야 한다. 웹 서버가 침해되더라도 공격자가 이메일을 읽지 못하도록 분리하라는 설명이다.

이메일 서버는 IP 주소가 스팸 발신에 이용되면 평판을 회복하기 어렵다는 점에서 특히 발신 트래픽을 제한해야 한다. 웹 서버는 외부 연결이 필요 없고, 마인크래프트 서버는 사용자 인증을 위해 HTTPS와 DNS가 필요하지만 그 밖의 접근 권한은 없어도 된다고 예를 든다. 외부로 25번 포트에 연결할 수 있는 서비스는 메일 서버로 제한하고, 로컬에서 메일을 제출하는 경로도 제한해야 한다. 이런 방화벽 설정은 일반적인 보안에도 도움이 된다. 글쓴이는 Java 애플리케이션의 원격 코드 실행 취약점인 log4shell이 공격자 서버에서 페이로드를 내려받아야 하므로 적절한 방화벽 설정으로 악용을 막을 수 있다고 설명한다.