2026년 8월 26일에 공개된 IETF EMAILCORE 적용성 설명서 30판은 IESG 평가 단계의 활성 인터넷 드래프트입니다. SMTP 기밀성 관련 문장이 여전히 어떤 발신자 의무를 요구하는지, 운영자가 어디까지 정책을 엄격하게 설정할 수 있는지를 확인하는 것이 이 자료의 핵심입니다.
개요
draft-ietf-emailcore-as-30는 IETF 핵심 이메일 프로토콜의 적용성 설명서입니다. 30판은 이메일 전송 관련 프로토콜과 메시지에서 운영자가 적용해야 할 기준을 제시하려는 자료로, 현재는 IESG 평가가 진행 중인 단계에 있습니다.
SMTP에서 기밀성은 일반적으로 STARTTLS 협상과 연결됩니다. 수신 MTA가 발신자의 EHLO 이후 STARTTLS를 광고하면, 발신자는 TLS 핸드셰이크를 시도합니다. 협상이 성공하면 메시지는 그 보호된 연결을 통해 전달됩니다. 30판의 발신자 의무는 기밀성이 사용 가능하고 수신자가 수용할 때 발신자가 반드시 사용해야 한다는 강한 문장을 유지합니다. 이 문장은 통상적인 STARTTLS 협상을 뒷받침하면서도, 운영자가 정책을 통해 더 엄격한 실패 동작을 설정할 수 있는 여지를 두는 구조입니다.
따라서 운영자 입장에서 확인할 포인트는 단순한 STARTTLS 유무가 아닙니다. 협상이 실패하거나 수신자가 STARTTLS를 제공하지 않을 때 어떤 전달 동작을 허용할지, 특정 구간에서 평문 fallback을 막을 부가 정책이 필요한지까지 함께 살펴봐야 합니다.
적용 환경·전제조건
이 점검은 다음 조건을 전제로 합니다.
- 대상 시스템은 SMTP를 통해 메일을 주고받는 MTA 또는 그 전송 경로를 운영하는 환경입니다.
- STARTTLS가 가능할 때 사용해야 한다는 기본 의무는 인정하되, 실패 시 전달을 허용할지 중단할지 결정해야 하는 운영 정책이 필요합니다.
- DNS 및 HTTPS 공개 상태를 점검할 수 있어야 합니다. MTA-STS 같은 정책 신호가 이를 전제로 하므로, 공개가 잘못된 것처럼 보일 수 있는 구간은 실제 연결 테스트로 확인해야 합니다.
- opportunistic fallback만 의존하는 구간에 MTA-STS, DANE for SMTP, RequireTLS 중 적용할 정책을 고를 수 있어야 합니다.
전제조건이 충족되지 않으면 이 점검은 불완전해집니다. 예를 들어 대상 MX나 경로에 접근할 수 없으면 실제 협상 결과를 알 수 없고, DNS·HTTPS 공개 상태가 점검되지 않으면 MTA-STS 신호가 올바르게 전달되는지 확인할 수 없습니다.
기술 절차·판단 근거
점검은 아래 순서로 진행할 수 있습니다.
- DNS와 HTTPS 공개 상태를 먼저 확인합니다. 정책 신호가 의존하는 공개 요소가 정상인지 확인하는 단계입니다.
- 실제 SMTP 세션을 수행해 EHLO 응답에서 STARTTLS 광고가 있는지, TLS 핸드셰이크가 성공하는지, 어떤 프로토콜 버전이 협상되는지 확인합니다.
- MX가 여러 개이거나 경로를 달리할 수 있다면, 다른 경로와 다른 MX에서도 같은 결과를 보이는지 비교합니다.
- opportunistic fallback이 허용되는 구간이 있으면, MTA-STS, DANE for SMTP, RequireTLS 중 어떤 정책이 적용되는지 확인합니다.
- 정책으로 더 엄격한 실패 동작을 설정하는 경우, 어떤 발신자 또는 경로에 영향을 주는지 확인합니다.
판단 근거는 확인된 협상 결과에 있습니다. DNS와 HTTPS 공개가 올바르게 보이더라도 MX가 잘못된 인증서를 제시하거나, STARTTLS를 누락하거나, 허용 불가능한 프로토콜을 협상하거나, 다른 경로에서 다르게 동작할 수 있습니다. 따라서 공개 상태 확인만으로는 부족하고, 실제 SMTP 세션에서 협상 결과를 직접 확인하는 것이 필요합니다.
MTA-STS, DANE for SMTP, RequireTLS의 역할은 서로 다릅니다. 이들은 opportunistic fallback이 불충분한 경우를 다루며, 종단 간 암호화를 만들지는 않습니다. 대신 지원 발신자가 보호 hop을 평문으로 전달하지 않도록 정책 신호를 제공하는 역할을 합니다. MTA-STS(RFC 8461), SMTP TLS Reporting(RFC 8460), Opportunistic DANE TLS(RFC 7672)가 각각 이 영역을 정의한 기준입니다.
운영상 영향
더 엄격한 실패 동작을 설정하면 기밀성 협상 실패 시 전달 결과가 운영 방침에 따라 달라집니다. 예를 들어 TLS 협상에 실패해도 전달을 계속할지, 특정 대상에 한해 전달을 중단할지는 운영자의 실패 허용 범위에 달려 있습니다. 따라서 대상 발신자와 실패 허용 범위에 따라 전달 결과가 달라질 수 있습니다.
opportunistic fallback만 사용하는 구간에서는 보호 hop이 평문으로 전달될 수 있습니다. MTA-STS, DANE for SMTP, RequireTLS가 지원하는 발신자에서는 이를 차단하는 정책 신호가 필요할 수 있습니다. 단, 이들은 평문 hop을 막는 데 도움이 될 수 있으나, 모든 메일 경로에 적용되는 것도 아니고, 종단 간 암호화를 보장하는 것도 아닙니다.
따라서 운영에서 고려해야 할 것은 다음 두 가지입니다.
- 어떤 구간에서 fallback이 허용되는지, 어떤 구간에서 평문 전달을 허용하지 않을지 구분해야 합니다.
- 정책 변경 시 발신자 대상과 실패 허용 기준이 문서화되어 있는지, 더 엄격한 실패 동작이 실제 전달에 미치는 영향이 단계적으로 검증되고 있는지 확인해야 합니다.
탐지·대응
탐지는 실제 연결에서의 협상 결과와 정책 적용 여부 확인으로 구성할 수 있습니다.
- EHLO 응답에서 STARTTLS 광고 유무, TLS 핸드셰이크 성공과 실패, 협상된 프로토콜 버전, 다른 경로나 MX에서의 동작 차이를 점검합니다.
- DNS 및 HTTPS 공개 상태가 정확한 것처럼 보이더라도 실제 SMTP 연결에서 잘못된 인증서, STARTTLS 누락, 허용 불가능한 프로토콜 협상이 나타나는지 확인합니다.
- MTA-STS, DANE for SMTP, RequireTLS 정책이 적용된 구간에서, 지원 발신자 대상이 실제로 평문 전달을 피하고 있는지 실제 SMTP 연결과 정책 적용 여부를 점검합니다.
초기 확인과 영향 검증
즉각적인 확인이 필요한 항목은 다음입니다.
- 대상 도메인과 MX의 DNS 및 HTTPS 공개 상태를 확인한 뒤, 실제 SMTP 세션에서 EHLO 후 STARTTLS 광고와 TLS 핸드셰이크 결과를 점검하는 live SMTP 테스트를 수행합니다.
- 기존 운영 정책의 실패 동작 설정과 비교하여, 더 엄격한 실패 동작을 설정할 경우 어떤 전달 경로가 영향받는지를 확인합니다.
- opportunistic fallback만 사용하는 구간에 MTA-STS, DANE for SMTP, RequireTLS 중 어떤 정책이 적용되는지, 지원 발신자에게 어떤 신호로 전달되는지를 점검합니다.
주기 점검
장기 운영을 위한 반복 점검 항목은 다음입니다.
- live SMTP 테스트를 주기 점검 항목으로 둡니다.
- MX 변경, 인증서 갱신, 경로 변경 시점에 STARTTLS 광고와 TLS 협상 결과를 재확인합니다.
한계 및 참고자료
이번 점검에는 다음 한계가 있습니다.
- 30판이 IESG 평가 단계의 활성 인터넷 드래프트이므로, 최종 표준화 시점과 문장 변화 여부는 확정되지 않았습니다.
- DISCUSS 의견의 구체적 내용과 기밀성 문장에 미칠 영향, 최종 판 반영 여부는 공개된 근거에 포함되어 있지 않습니다.
- MTA-STS, DANE for SMTP, RequireTLS의 개별 도메인 적용 설정, 지원 발신자 범위, 평문 전달 차단 신호의 실제 동작은 운영 환경에 따라 다를 수 있습니다.
- SMTP TLS Reporting의 보고 주기, 수신 경로, 평문 전달 이벤트 분류는 이번 근거에서 상세히 확인되지 않았습니다.
참고자료
- draft-ietf-emailcore-as-30
- SMTP confidentiality in IETF EMAILCORE draft 30: What operators should review
- IETF core email draft 30 revises SMTP confidentiality requirements
- RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)
- RFC 8460: SMTP TLS Reporting
- RFC 7672: SMTP Security via Opportunistic DANE TLS
함께 읽으면 좋은 글
- CVE-2019-1068 대응 가이드: Microsoft SQL Server 원격 코드 실행 KEV 점검
- HAR와 소스맵으로 웹 애플리케이션 공격면을 점검하는 실전 가이드
- CVE-2026-77550: UniFi OS 인증 우회 취약점, 공식 권고 확인과 네트워크 접근 점검이 먼저
본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.
댓글 (0)
댓글을 작성하려면 로그인이 필요합니다.
로그인아직 댓글이 없습니다.
첫 번째 댓글을 작성해보세요!