MTA-STS·TLS-RPT 설정: TLS 강제

Problem

SMTP 암호화는 기회주의적입니다: 경로상의 공격자가 메일 서버 인사말에서 STARTTLS 제안을 벗겨내면, 발신 서버는 “이 서버는 TLS를 안 한다”와 “누군가 제안을 지웠다”를 구분하지 못해 메일을 평문으로 배달합니다. MTA-STS는 지속적인 약속 — 내 메일 서버는 유효한 인증서로 TLS를 지원한다; 그게 안 보이면 배달하지 마라 — 을 발행해 그 구멍을 막고, TLS-RPT는 그게 동작하는지 알려주는 리포트를 줍니다. 설정은 서로 일치해야 하는 작은 조각 세 개이고 실패가 조용하기 때문에, 이 가이드는 발행만큼이나 검증에 관한 것입니다.

무엇을 발행하는가

MTA-STS는 서로 맞물려야 하는 세 가지입니다:

1. 디스커버리 TXT 레코드 — _mta-sts.yourdomain에 두는 작은 레코드, v=STSv1; id=<버전>. 발신 서버에 “정책이 있다, 버전 ID는 이거다, 진짜는 가서 가져와라”라고 알리는 것 외엔 아무것도 안 합니다.
2. 정책 파일 — 고정 경로 https://mta-sts.yourdomain/.well-known/mta-sts.txt에서 HTTPS로 제공. 실제 정책이며, mta-sts. 서브도메인의 유효한 인증서가 있는 연결로 전달돼야 합니다.
3. TLS-RPT TXT 레코드 — _smtp._tls.yourdomain에 두는 별도 표준(RFC 8460). TLS 협상이 어땠는지 매일 요약을 메일로 보내달라고 발신 서버에 요청합니다.

정책 파일은 이렇게 생겼습니다:

version: STSv1
mode: testing
mx: mail.yourdomain.com
mx: *.yourdomain.com
max_age: 604800

mode가 레버입니다: testing(TLS 시도, 어쨌든 배달, 실패는 보고), enforce(목록의 MX로 TLS가 실패하면 배달 거부), none(정책 정리 중). mx는 정당한 메일 서버를 전부 나열해(와일드카드 허용) 공격자가 자기 서버로 돌리지 못하게 합니다. max_age는 발신 서버가 정책을 캐시하는 시간(초)으로, 약 1년(31557600)까지 가능합니다. MTA-STS는 2018년 RFC 8461로 표준이 됐고, Gmail이 2019년부터 발신 측 MTA-STS를 적용하기 시작했으니, 올바른 정책은 오늘날 상당한 비율의 실제 발신 서버가 존중합니다.

4단계 설정

1. 정책 호스트부터 세운다. mta-sts.yourdomain 서브도메인을 만들고, 유효한 TLS 인증서를 발급받고, 정책 파일을(시작은 mode: testing) /.well-known/mta-sts.txt에 text/plain으로 제공한다. 그 URL을 브라우저에서 인증서 경고 없이 열 수 있는지 확인 — 브라우저가 불평하면 모든 발신 서버도 가져오기에 실패한다.
2. 디스커버리 TXT를 발행한다. _mta-sts.yourdomain TXT "v=STSv1; id=20260627000000". id는 임의지만 정책 파일이 바뀔 때마다 바꿔야 하며, 타임스탬프가 항상 증가하는 가장 단순한 방식이다.
3. TLS-RPT를 발행한다. _smtp._tls.yourdomain TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain". 이게 배포를 추측에서 측정으로 바꾼다 — 없으면 눈 감고 나는 것이다.
4. testing으로 살다가 enforce로. mode: testing을 2주쯤 두고 TLS-RPT 리포트를 실제로 읽는다. 목록에서 빠진 MX나 인증서 문제가 있는 MX가 드러난다. 리포트가 깨끗해진 뒤에야 정책 파일을 mode: enforce로 바꾸고 id를 올려 발신 서버가 새 버전을 집어가게 한다.

흔한 설정 실패

• mta-sts. 인증서가 틀렸다. 만료, 자체 서명, 또는 서브도메인 미커버. 발신 서버가 신뢰 연결로 정책을 못 가져와 통째로 무시한다. DNS는 다 맞아 보이는데 정책만 적용이 안 된다.
• mx: 목록이 현실과 안 맞는다. 빠뜨린 백업 MX, 또는 마이그레이션 후 바뀐 호스트명. testing에선 무해하지만 enforce에선 미등록 서버로의 메일이 바운스된다.
• 정책은 고쳤는데 id는 안 고쳤다. 발신 서버가 max_age가 만료될 때까지 캐시된 옛 버전을 계속 쓴다. 바꾼 게 아무 효과가 없어 보인다.
• 정책 파일에 도달 불가 또는 경로 오류. 404, 리다이렉트, HTTPS 대신 HTTP, 또는 /.well-known/ 대신 루트에 둔 파일. 디스커버리 TXT는 발신 서버가 가져올 수 없는 정책을 약속한다.
• testing 중 max_age가 너무 길다. 롤백이 필요하면 발신 서버가 그 기간 내내 정책을 캐시한다. testing 동안은 max_age를 짧게(하루나 일주일) 두고, enforce에 확신이 선 뒤에만 늘린다.

Diagnose with DechoNet

• 이메일 점검은 도메인의 메일 태세 — MX 레코드, 전송 보안 신호, 인증 — 를 살펴, enforce로 넘기기 전에 정책의 mx: 호스트가 세상이 보는 MX 레코드와 맞는지 확인하게 해줍니다.
• DNS 점검으로 두 TXT 레코드가 정확한 이름 — _mta-sts.yourdomain과 _smtp._tls.yourdomain — 에서 풀리는지, 디스커버리 레코드가 기대한 id를 담고 있는지 검증하세요. 둘 중 한쪽의 누락되거나 오래된 TXT가 가장 먼저 배제할 항목입니다.

Resolution Checklist

• https://mta-sts.yourdomain/.well-known/mta-sts.txt을 브라우저에서 연다. 인증서 경고 없이 HTTPS로 로드되고 정책을 평문으로 반환해야 한다.
• _mta-sts.yourdomain이 v=STSv1; id=...로 풀리고, id가 제공하려는 정책 버전과 일치하는지 확인한다.
• _smtp._tls.yourdomain이 v=TLSRPTv1; rua=... 레코드로 풀려 실제로 리포트를 받는지 확인한다.
• 실제 MX가 전부 정책의 mx: 목록에 있는지 본다(와일드카드 포함). 빠진 백업 MX는 enforce에서 바운스된다.
• TLS-RPT 리포트가 최소 2주간 깨끗하게 돌아올 때까지 mode: testing에 머문다.
• enforce로 바꿀 때 정책 파일 과 DNS의 id를 같은 변경에서 함께 올린다 — 안 그러면 캐시된 발신 서버가 옛 모드를 유지한다.

When to Escalate

• 레코드와 인증서가 다 맞는데 TLS-RPT 리포트가 특정 MX로의 실패를 계속 보인다면, 문제는 그 메일 서버에 있습니다: 호스트명과 안 맞는 인증서, 또는 협상을 거부하는 TLS 스택. 그 서버를 운영하는 쪽에 넘기세요 — MTA-STS는 실제 전송 문제를 보고하는 것이지 유발하는 게 아닙니다.
• mta-sts. 서브도메인을 만들거나 인증서를 발급받을 수 없다면(관리형 플랫폼, 잠긴 DNS), 당신 쪽에서 배포를 끝낼 수 없습니다; 호스팅이나 DNS 운영자가 서브도메인과 인증서를 마련해야 이 모든 게 적용됩니다.