HMTP: 기존 웹 표준을 사용하여 현대적인 이메일 후계자 설계하기
HMTP: 기존 웹 표준을 사용하여 현대적인 이메일 후계자 설계하기
HMTP는 기존 웹 표준의 모듈형 스택을 사용하여 SMTP를 대체합니다
HMTP (Hypertext Mail Transfer Protocol)는 노후화된 Simple Mail Transfer Protocol (SMTP)를 검증된 웹 기술의 조합으로 교체하여 이메일을 재구상하는 설계 실험입니다. 새로운 프로토콜을 발명하는 대신, HMTP는 HTTP, WebFinger, ActivityPub와 같은 기존 표준을 조합하여 이메일 전달, 신원 확인 및 암호화의 구조적 결함을 제거합니다.
HMTP 기술 스택
HMTP는 이미 대규모로 배포되어 사용 중인 표준화된 기술들로 구성된 "자재 명세서(bill of materials)"를 활용합니다:
| 문제 | 사용된 기술 | 구현 예시 |
|---|---|---|
| 전송 및 상태 코드 | HTTP | The Web |
| 전송 암호화 | TLS + Let's Encrypt | The Web |
| 사용자 검색 | WebFinger (RFC 7033) | Mastodon / Fediverse |
| 메시지 전달 | HTTP POST | ActivityPub |
| 발신자 검증 | Webmention / DKIM pattern | IndieWeb |
| 서명 | Ed25519 | SSH, Signal |
| 콘텐츠 암호화 | HPKE (RFC 9180) | MLS, TLS ECH |
| 신원 연속성 | Sigchains | ATProto (Bluesky) |
| 읽기 및 동기화 | JMAP (RFC 8620) | Fastmail |
| 푸시 알림 | SSE / WebPush | Modern Browsers |
| 첫 연락 동의 | Message Requests | Signal, Instagram |
| 첨부 파일 | Content Addressing | Git, IPFS, Matrix |
핵심 아키텍처 개선 사항
검색 및 사용자별 위임
HMTP는 DNS 기반의 MX 레코드를 정적 검색 문서로 대체합니다. 발신자는 GET https://example.com/.well-known/hmtp/user를 요청함으로써 수신자의 인박스 URL과 공개 키를 검색할 수 있습니다. 이를 통해 사용자별 위임이 가능해지며, 동일한 도메인 내의 서로 다른 메일박스를 DNS 레코드를 수정하지 않고도 서로 다른 제공업체에서 호스팅할 수 있습니다.
암호화 신원 및 키 로테이션
HMTP의 신원은 연속성을 보장하기 위해 특정 키와 분리되어 있습니다. 다음 두 가지 주요 앵커를 사용합니다:
- 암호화 연속성: 각 새 키가 이전 키에 의해 서명되는 "sigchain"을 사용하여 사용자가 신원을 잃지 않고 키를 교체할 수 있도록 합니다.
- 도메인 제어 폴백: 키를 분실한 경우, 도메인 소유자는 즉각적인 하이재킹을 방지하기 위해 의무적인 공지 기간을 거친 후 새 키를 선언할 수 있습니다.
멱등적 전달 및 Store-and-Forward
HMTP는 MUA (User Agent)와 MTA (Transfer Agent)의 SMTP 분리 구조를 유지합니다. 클라이언트는 자신의 서버로 인증된 POST를 보내며, 서버는 대기열을 처리하고, 지수 백오프(exponential backoff)를 적용하여 재시도하며, HTTP Retry-After 헤더를 준수합니다. 응답 실패로 인한 중복 이메일을 방지하기 위해 모든 메시지는 콘텐츠의 해시로 식별되며, 이를 통해 구조적으로 재시도가 멱등적(idempotent)이 되도록 합니다.
종단간 암호화 및 검증
메시지는 단순한 텍스트가 아닌 서명된 객체로 취급됩니다. 이 아키텍처는 다음과 같은 이점을 제공합니다:
- 보관 중 인증성: 암호화 증명이 메시지와 함께 전달되어, 전달(forward) 과정을 통해서도 위조가 불가능합니다.
- 출처 검증: 수신자는 발신자의
.well-known문서에서 공개 키를 가져와 발신자를 검증합니다. - 기본 E2E 암호화: HPKE를 사용하여 메시지 본문은 수신자용으로 암호화되는 반면, 봉투(메타데이터)는 라우팅을 위해 공개된 상태로 유지됩니다.
- 콘텐츠 주소 지정 첨부 파일: 첨부 파일은
{hash, url, size}참조 형식으로 저장됩니다. 수신자는 필요할 때 이를 다운로드하므로 메일박스의 base64 인코딩 오버헤드를 제거할 수 있습니다.
스팸 문제 해결
HMTP는 현재의 IP 평판 및 차단 목록(blocklists) 의존도를 대체하기 위해 계층적 방어 전략을 구현합니다:
- 신원 비용: 신원을 도메인에 고정함으로써 대량의 신원 생성에 대한 경제적 장벽(sybil cost)을 만듭니다.
- 첫 연락 동의: 알 수 없는 발신자는 "요청(requests)"함으로 이동됩니다. 사용자가 낯선 사람의 요청을 명시적으로 수락해야만 스레드가 기본 인박스로 이동합니다.
- 경제적 억제력: 서버는 첫 연락 시도에 대해 HTTP
402 Payment Required코드로 응답할 수 있어, 무차별 스팸 발송에 대해 설정 가능한 비용을 도입할 수 있습니다.
커뮤니티 통찰 및 기술적 비판
HMTP 제안이 SMTP에 대한 현대적인 대안을 제시하지만, 기술적 논의에서는 채택 및 구현과 관련된 몇 가지 과제가 강조됩니다:
- 네트워크 효과 및 호환성: 비판론자들은 이메일의 보편성 때문에 하위 호환성이 없는 대체제가 성공할 가능성은 낮다고 주장합니다. 일부는 SMTP에 대한 점진적인 개선(MTA-STS와 같은)이 더 실용적이라고 제안합니다.
- 메모리 관리: 일부 개발자들은 전체 이메일 문서에 순수 JSON을 사용하는 것에 대해 경고하며, 많은 JSON 파서가 문서 전체를 RAM에 로드한다는 점을 지적합니다. 그들은 스트리밍을 허용하기 위해 JSON 헤더 뒤에 MIME 본문을 사용하는 하이브리드 방식을 제안합니다.
- 메일링 리스트 호환성: 콘텐츠 주소 지정(ID를 위해 메시지 해싱)은 구독 관리를 위해 헤더를 자주 수정하는 전통적인 메일링 리스트를 깨뜨릴 수 있습니다.
- "스팸 솔루션"의 역사: 일부 관찰자들은 스팸에 대한 유사한 "궁극적인 해결책"들이 1990년대에도 제안되었으나, 인간 커뮤니케이션의 복잡성과 문제의 규모 때문에 실제로는 작동하지 않았음을 지적합니다.
"악마는 예외 케이스(corner cases)에 있습니다. 그것들은 수십 년 동안 서로 다른 당사자에 의해 서로 다른 방식으로 해결되어 왔습니다... 직접 경험해보지 않았다면, 당신도 똑같은 실수를 반복할 운명입니다."
구현 상태
HMTP의 작동하는 프로토타입이 Python으로 구현되었습니다 (github.com/tanrax/hmtp). 이 프로토타입은 서명된 전달, 출처 검증, E2E 암호화, 첫 연락 동의 및 지수 백오프를 포함한 재시도 대기열을 시연합니다.