어느 좋은 날, 뚜렷한 이유 없이 내 Ubuntu 18.04 비즈니스 서버가 내 Gmail 주소로 메일을 전달하는 것을 중단했습니다.
바로 전날, /home/office/.forward와 같이 이메일에 사용하는 로컬 서버 계정의 홈 디렉토리에 생성한 .forward 파일이 내 비즈니스 주소를 겨냥한 모든 메일을 내 일일 주소로 유쾌하게 리디렉션했습니다. - Gmail 계정을 사용합니다. 그러다가 갑자기 멈췄습니다.
뭔가 잘못되었다는 것을 알았을 때, 나는 즉시 내 서버 로그를 참조했습니다. /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가 Gmail에 연결하여 메일을 내 주소로 전달할 수 없다고 합니다.
당연히 Postfix를 다시 시작했지만 소용이 없었습니다.
sudo systemctl restart postfix나가는 메시지가 포트 25(SMTP)에서 내 서버를 떠나는 것을 차단하는 것이 없음을 확인했습니다. 그런 다음 내 도메인이 블랙리스트에 포함되지 않았는지 확인하고(이를 수행할 수 있는 수많은 온라인 도구가 있음) 명령줄에서 dig를 실행하여 내 MX 레코드의 상태를 엿봤습니다.
dig MX bootstrap-it.com아무것도 하지 않습니다. 모든 것이 확인된 것 같았습니다.
몇 번의 실망스러운 문제 해결 세션 후에 나는 포기하고 완전히 다른 것을 시도할 것이라고 생각했습니다.
AWS 솔루션 아키텍트가 되어 Wiley/Sybex on AWS에 대한 두 권의 책(한 권은 Cloud Practitioners 시험 가이드, 다른 한 권은 Solutions Architect Associate 시험)을 공동 저술했는데, 스스로 스택을 구축할 의지와 능력이 있어야 하지 않을까요? 클라우드에서 내 이메일 서버 요구 사항을 처리할 AWS 도구는 무엇입니까?
글쎄, 나는 기꺼이 그리고 - 약간의 진지한 연구와 시행착오를 거친 후에 - 가능하다는 것이 밝혀졌습니다. 완료하려면 다음이 필요합니다.
- 수신 이메일을 저장할 S3 버킷 생성
- SNS(Simple Notification Service) 주제를 만들어 새 이메일이 도착할 때마다 알림을 이메일로 보냅니다.
- 내 이메일 도메인(bootstrap-it.com)을 인수하고 수신 메일을 처리하도록 Amazon의 Simple Email Service(SES)를 구성합니다. 여기에는 Route 53(내 도메인이 관리되는)에 MX 레코드를 추가하고 SES를 내 도메인으로 지정하는 작업이 포함됩니다. SES가 제어할 각 이메일 주소를 추가하고 확인합니다. 그런 다음 SES에 내 S3 버킷으로 새 메시지를 보내도록 지시하는 동시에 SNS 주제에 대한 알림도 트리거합니다.
- 보내기도 원한다고 가정 DKIM(DomainKeys Identified Mail)을 사용하여 보내는 메시지에 서명하도록 SES를 구성하는 것도 좋은 생각입니다.
여기에서 모든 단계를 자세히 설명하지는 않겠습니다. 이에 대한 훌륭한 문서가 많이 있습니다. 그러나 발생할 수 있는 몇 가지 문제점에 대해 간략하게 언급하겠습니다.
사용 중인 각 도메인의 DNS 호스팅 영역에 MX 레코드를 추가해야 합니다. 도메인이 Amazon의 Route 53 내에서 관리되는 경우에도 레코드 값을 제공해야 합니다.
해당 값에 사용하는 것은 SES 리소스가 있는 AWS 리전에 따라 다릅니다. 제 경우에는 다음과 같았습니다.
10 inbound-smtp.us-east-1.amazonaws.comSNS 알림은 유용하지만 가독성이 떨어지는 정보에 대한 짧은 단편 몇 개만 포함하는 긴 텍스트 문자열 하나로 도착합니다. 스팸을 식별하는 데는 충분하지만 일반적으로 여기에서 찾을 수 있는 것보다 더 많은 정보가 필요합니다. 내 S3 버킷에 새 메일이 있음을 알리는 헤드업으로 알림을 사용합니다.
AWS Management Console을 통해 S3 버킷 내에서 이메일 자체를 보는 것이 한 달에 한 번 또는 두 번만 발생한다면 세상의 끝이 아닙니다. 그러나 그보다 더 빨리 수신되는 경우 메시지에 액세스하고 메시지를 읽을 수 있는 더 나은 방법을 찾아야 합니다.
그러나 해당 프로세스를 자동화하기 위한 프로토콜을 만드는 것은 완전히 다른 도구 집합이 필요한 로컬 운영 체제 문제입니다. AWS CLI와 멋진 Bash 스크립트를 사용하여 문제를 직접 해결했습니다. 내가 어떻게 했는지 보고 싶다면 이 기사를 클릭하세요.
내 bootstrap-it.com에서 제공되는 책, 과정 및 기사의 형태로 훨씬 더 많은 관리 장점이 있습니다.