IETF EMAILCORE 30판에 따르면, SMTP 발신자는 기밀성 사용이 가능하고 수신자가 이를 수용할 때 반드시 암호화 연결을 사용해야 하며, 기본적으로 STARTTLS 협상이 실패하거나 수신자가 이를 제공하지 않을 때는 평문 전송으로 폴백(Fallback)하는 동작이 허용됩니다. 다만 MTA-STS나 DANE 같은 강제 기밀성 메커니즘이 적용된 환경에서는 정책에 따라 전달을 거부할 수 있습니다.
EMAILCORE 30판 문서 개요와 IESG 평가 단계의 의미
2026년 8월 26일에 공개된 IETF EMAILCORE 적용성 설명서 30판(draft-ietf-emailcore-as-30)은 IETF 핵심 이메일 프로토콜의 적용성을 정의하는 문서입니다. 현재 이 문서는 IESG 평가(AD Followup) 단계에 있는 활성 인터넷 드래프트이며, 향후 ‘Proposed Standard’로 전환을 목표로 하는 표준 트랙 문서입니다.
운영 엔지니어와 보안 의사결정자가 주목할 부분은 이 문서가 아직 IESG 평가 단계에 있다는 점입니다. 최종 표준화 시점의 문장 변화 여부는 완전히 확정되지 않았습니다. 그럼에도 30판은 SMTP 발신자와 수신자가 STARTTLS(RFC 3207) 확장을 반드시(MUST) 지원하도록 규정하며, 이메일 인프라의 기본 보안 수준을 끌어올리려는 방향을 분명히 하고 있습니다.
SMTP 기밀성의 두 축: 기회주의적 TLS와 강제 기밀성
SMTP 전송의 기밀성은 크게 ‘기회주의적(Opportunistic)’ 방식과 ‘강제적(Enforced)’ 방식으로 나뉩니다. 인터넷 트래픽이 능동적 공격과 수동적 감시에 노출되어 있어 SMTP 메시지 전송 역시 취약합니다. 이를 완화하려고 두 가지 접근 방식이 혼용되고 있습니다.
1. 기회주의적 기밀성 (Opportunistic Confidentiality)
기회주의적 TLS는 수신 서버가 지원한다면 암호화를 사용하되, 실패 시 평문으로 전달하는 유연한 방식입니다. 현재 인터넷 이메일 환경에서 널리 구현되어 쓰이고 있습니다. 그러나 STARTTLS를 통한 기회주의적 TLS는 중간자(MITM) 공격에 취약하며, 공격자가 STARTTLS 광고를 제거해 평문 통신으로 끌어내리는 다운그레이드 공격이 가능합니다.
2. 강제 기밀성 (Enforced Confidentiality)
강제 기밀성은 기회주의적 방식의 한계를 극복하고 기밀성을 ‘강제’하는 메커니즘입니다. 발신 서버가 TLS 연결을 설정하지 못하거나 인증에 실패했을 때 메시지 전달을 거부하도록 해서 보안성을 높입니다. 주요 기술적 기준은 다음과 같습니다.
- MTA-STS: RFC 8461로 정의된 SMTP MTA Strict Transport Security
- SMTP TLS Reporting: RFC 8460으로 정의된 보고 메커니즘
- Opportunistic DANE TLS: RFC 7672로 정의된 DANE 기반 TLS
STARTTLS 협상 절차와 협상 실패 시 평문 폴백 동작
SMTP 기밀성 협상의 표준 절차는 수신 MTA가 발신자의 EHLO 명령 이후 STARTTLS 키워드를 광고하며 시작됩니다. 발신자는 이를 확인하면 TLS 핸드셰이크를 시도하고, 성공하면 보호된 연결로 메시지를 전달합니다.
중요한 점은 기회주의적 TLS(Section 6.1.2) 환경에서의 실패 동작입니다. 수신 서버가 STARTTLS를 광고했는데도 협상이 실패하면 발신 클라이언트는 평문 전송으로 폴백해 메시지를 전달합니다. 이는 가용성을 우선시하는 SMTP의 전통적인 동작 방식이고, 30판에서도 이런 기회주의적 폴백이 선택적 기밀성을 제공하는 근거가 된다고 명시합니다.
RequireTLS, MTA-STS, DANE이 허용하는 전달 거부 조건
강제 기밀성 프로토콜들은 보호된 홉(Hop)을 평문으로 전달하지 않도록 정책 신호를 제공합니다. 다만 이 프로토콜들이 모든 메일 경로에 적용되는 것도, 종단 간 암호화(End-to-End Encryption)를 보장하는 것도 아닙니다.
강제 기밀성 메커니즘의 적용 여부와 그에 따른 발신 서버의 동작을 표로 정리했습니다.
| 구분 | 핵심 동작 및 조건 | 전달 거부 가능 여부 | 근거 |
|---|---|---|---|
| 기회주의적 TLS | STARTTLS 협상 시도 $\rightarrow$ 실패 시 평문 폴백 | 불가 (평문 전달) | |
| MTA-STS (enforce 모드) | MX 매칭 실패, 인증서 검증 실패, STARTTLS 미지원 시 전달 금지 | 가능 (MUST NOT deliver) | |
| 강제 기밀성 일반 (DANE 등) | TLS 연결 불가 또는 인증 실패 시 전달 거부 | 가능 (선택 사항) |
특히 RFC 8461에 정의된 MTA-STS의 ‘enforce’ 모드에서는 발신 MTA가 STARTTLS를 지원하지 않거나 인증서 검증에 실패한 호스트에 메시지를 전달해서는 안 됩니다. 이 경우 MTA는 해당 실패를 일시적 오류(Transient error)로 처리하고 나중에 다시 전달을 시도해야 합니다.
운영자 관점의 점검 순서 및 정책 수립 가이드
IT 운영과 보안 엔지니어라면 IETF EMAILCORE 30판의 방향성에 맞춰 다음 순서로 인프라 보안 정책을 점검하면 됩니다.
- 기본 지원 확인: 발신 및 수신 MTA가 STARTTLS(RFC 3207)를 반드시 지원하고 있는지 확인합니다.
- 인프라 전제 조건 점검: MTA-STS 같은 정책 신호는 DNS와 HTTPS 공개 상태 점검이 가능해야 한다는 게 전제입니다. 관련 공개 설정이 올바른지부터 먼저 확인합니다.
- 정책 선택 및 적용: 기회주의적 폴백에만 의존하는 구간이 있다면, 보안 요구사항에 따라 MTA-STS, DANE, RequireTLS 중 적절한 정책을 선택해 적용합니다.
- 동작 검증: 강제 기밀성 프로토콜을 도입했다면, TLS 인증 실패 시 메시지가 평문으로 유출되지 않고 정상적으로 전달 거부(또는 큐 대기) 처리되는지 검증합니다.
IETF EMAILCORE 30판은 STARTTLS의 기본 지원을 의무화하는 한편, 보안 수준을 높이려는 운영자에게는 MTA-STS와 DANE 같은 강제 기밀성 도구로 ‘평문 폴백’을 차단할 수 있는 정책적 수단을 제공합니다.