어느 날 갑자기 멈춘 메일 포워딩
어느 평범한 날, 딱히 짚이는 원인 없이 우분투(Ubuntu) 18.04 비즈니스 서버가 지메일(Gmail) 주소로 메일을 전달하지 못하기 시작했습니다.
그 전날까지만 해도 로컬 서버 계정 홈 디렉터리에 만들어둔 .forward 파일(예: /home/office/.forward)은 사업용 주소로 들어오는 모든 메일을 평소 사용하는 지메일 계정으로 문제없이 넘겨주고 있었습니다. 그런데 어느 순간 갑자기 작동을 멈춘 것입니다.
문제 진단 과정
이상 신호를 인지하자마자 서버 로그를 확인했습니다. /var/log/mail.err에는 다음과 같은 메시지가 반복해서 기록되고 있었습니다.
status=deferred (delivery temporarily suspended: connect to alt2.gmail-smtp-in.l.google.com[219.8.202.27]:25: Connection timed out)서버 메일박스를 점검해 보니 메일 수신 자체는 정상적으로 이루어지고 있었지만, Postfix가 지메일 SMTP 서버와 연결을 맺지 못해 메시지를 전달하지 못하는 상황이었습니다.
당연히 Postfix부터 재시작해 봤지만 소용이 없었습니다.
sudo systemctl restart postfix이어서 다음 항목들을 차례로 확인했습니다.
- 25번 포트(SMTP)의 아웃바운드 트래픽을 막는 요인이 있는지 여부
- 도메인이 블랙리스트에 등재되었는지 여부 (다양한 온라인 도구로 손쉽게 확인 가능)
- 명령줄에서 dig 명령으로 MX 레코드 상태 점검
dig MX bootstrap-it.com결국 아무런 이상을 찾을 수 없었습니다. 모든 것이 정상으로 보였는데도 말입니다.
AWS 기반 이메일 스택으로의 전환 결정
몇 차례의 답답한 트러블슈팅 끝에 저는 포기하고 완전히 다른 방식을 시도해 보기로 했습니다.
AWS 솔루션스 아키텍트이자 Wiley/Sybex에서 AWS 관련 두 권의 책(Cloud Practitioner 시험 가이드와 Solutions Architect Associate 시험 가이드)을 공동 집필한 사람으로서, 이메일 서버 요구사항을 클라우드에서 처리할 AWS 도구 스택을 직접 구축할 의향과 능력이 있어야 마땅하지 않겠습니까?
실제로 충분한 조사와 시행착오 끝에 실행에 옮길 수 있었습니다. 필요한 작업은 다음과 같습니다.
- S3 버킷 생성: 수신 이메일이 저장될 공간을 마련합니다.
- SNS(Simple Notification Service) 토픽 생성: 새 메일이 도착할 때마다 알림 메일을 받습니다.
- SES(Simple Email Service) 구성: 이메일 도메인(bootstrap-it.com)을 SES가 인수하고 수신 메일을 처리하도록 설정합니다. 여기에는 Route 53(도메인 관리 서비스)에 MX 레코드를 추가하고 SES가 해당 도메인을 가리키도록 지정하는 작업, SES가 제어할 각 이메일 주소의 추가 및 검증, 그리고 새 메시지를 S3 버킷으로 전송하면서 동시에 SNS 토픽 알림을 트리거하도록 지정하는 작업이 포함됩니다.
- DKIM 설정: 이 서비스를 통해 메일을 발송할 계획이라면, DomainKeys Identified Mail(DKIM)로 발신 메시지에 서명하도록 SES를 구성하는 것이 좋습니다. 스푸핑 방지와 전달률 향상에 큰 도움이 됩니다.
구축 시 주의할 점들
여기서 모든 단계를 상세히 설명하지는 않겠습니다. 훌륭한 공식 문서가 이미 충분히 많기 때문입니다. 대신 실제로 부딪힐 수 있는 몇 가지 까다로운 지점만 짚어두겠습니다.
1. MX 레코드 값은 리전에 따라 다릅니다
사용 중인 각 도메인의 DNS 호스팅 영역에 MX 레코드를 추가해야 합니다. 도메인이 Amazon Route 53에서 관리되고 있더라도 레코드 값은 직접 입력해야 하는데, 이 값은 SES 리소스가 위치한 AWS 리전에 따라 달라집니다. 필자의 경우 다음과 같았습니다.
10 inbound-smtp.us-east-1.amazonaws.com2. SNS 알림은 정보가 제한적입니다
SNS 알림은 길게 이어진 한 줄 텍스트로 도착하며, 유용하지만 읽기 어려운 몇 개의 짧은 정보 조각만 담고 있습니다. 스팸 식별 정도에는 충분하지만, 대개 이것보다 더 많은 정보가 필요합니다. 필자는 이 알림을 S3 버킷에 새 메일이 도착했다는 헤드업 용도로 활용합니다.
3. S3 콘솔에서 메일을 직접 읽는 데는 한계가 있습니다
AWS 관리 콘솔에서 S3 버킷 안의 이메일을 직접 확인하는 방법은 한 달에 한두 번 정도라면 감당할 만합니다. 하지만 그보다 자주 메일이 들어온다면 더 나은 접근 및 열람 방법을 찾아야 합니다.
다만 이 과정을 자동화하는 체계를 만드는 일은 별도의 도구 세트가 필요한 로컬 운영체제 영역의 문제입니다. 필자는 AWS CLI와 Bash 스크립트를 조합해 이 문제를 해결했으며, 그 방법은 별도의 글에서 소개합니다.
마무리
자체 운영하던 메일 서버가 예고 없이 멈췄을 때, AWS의 SES·S3·SNS·Route 53 조합은 관리 부담을 크게 덜어주는 현실적인 대안이 됩니다. 초기 설정에 다소 공수가 들지만, 한 번 구축해 두면 서버 유지보수 걱정 없이 안정적으로 이메일을 운영할 수 있습니다.
더 많은 시스템 관리 노하우를 담은 도서, 강좌, 아티클은 bootstrap-it.com에서 확인하실 수 있습니다.