GN⁺: 2세대 이메일에 대한 공개적 고찰
(gabrielsieben.tech)Note: 이 글은 단순히 내 생각을 정리한 것임. 깊이 생각해본 것이 아니며, 좋은 아이디어라고 생각할 필요는 없음. 기대치를 최대한 낮추고 읽어보길 바람.
이메일의 문제점
- 많은 오래된 기술들이 여전히 사용되고 있지만, 이메일은 사용할 때마다 나를 짜증나게 함.
- 사용자 입장에서 이메일은 꽤 잘 작동함. 가끔 스팸으로 너무 많은 이메일을 보내기도 하지만, 이메일은 오래되고 신뢰할 수 있으며 이해하기 쉽고 검색도 비교적 쉬움.
- 그러나 이메일의 백엔드는 엉망임.
이메일 백엔드의 문제점
- 많은 이메일 기능에는 명확한 사양이 없음. 예를 들어, 답장을 보낼 때 메시지의 상단에 답장을 보내는지 하단에 답장을 보내는지 명확하지 않음.
- 이메일에 어떤 HTML을 넣을 수 있는지 명확하지 않음. Microsoft Outlook이 Microsoft Word HTML 렌더러를 남용하는 경우가 있음.
- 이메일을 암호화하는 방법도 명확하지 않음. OpenPGP라는 것을 발명했지만 거의 사용되지 않았고, 큰 결함이 있음.
- 이메일의 진위를 항상 확인할 수 없었음. 그래서 SPF를 발명했지만, SPF도 모든 문제를 해결하지 못했음. 그래서 DKIM을 발명했지만, DKIM도 모든 문제를 해결하지 못했음. 그래서 DMARC를 발명했지만, DKIM 자체에 큰 결함이 있어 DMARC도 우회됨.
- BIMI라는 또 다른 계층을 추가했는데, 이것도 DMARC에 의존하고, DMARC는 DKIM에 의존하며, DKIM에는 결함이 있음.
- DMARC가 있는 경우에도 68.2%의 기록이
p=none으로 설정되어 있음. 이는 DMARC가 기본적으로 아무것도 하지 않음을 의미함. - 위의 모든 것과 공격적인 스팸 방지 정책 때문에 자체 호스팅 이메일이 매우 어려움.
- 마지막으로, IP 평판 관리가 있음. 일부 IP 주소는 다른 주소보다 "깨끗함". 특히 SendGrid나 AWS SES와 같은 공유 시스템에서. 이는 대량 메일 계정을 등록하는 것을 복잡하게 만들고, 정당한 이메일이 스팸으로 분류되는 경우가 많음.
2세대 이메일에 대한 가설
- 새로운 DNS 레코드
MX2를 생성함. 대부분의 이메일 서비스는MX2와MX레코드를 가짐. 오래된 서비스는MX만 가짐. - 20년 된 오래된 이메일 클라이언트가 메시지를 보내려고 하면
MX레코드를 찾아 메시지를 보냄. 현대 클라이언트는MX2를 보고 메시지를 보냄. -
MX2를 구현한 이메일 서비스는 공개 날짜를 게시하고, 그 날짜 이후로는MX레코드로 보내진 모든 메시지를 스팸으로 자동 분류함.
2세대 이메일의 우선순위
- 이메일을 위한 표준화된 HTML 사양과 적합성 테스트 스위트를 제공함.
- 이메일 체인 선호도 또는 기타 이메일 관련 선호도를 위한 헤더를 제공함.
- HTML 보기와 함께 텍스트 전용 비HTML 복사본을 제공함.
- 모든
MX2레코드는 공개 키를 포함해야 함. - 이메일의 진위와 무결성을 확인하기 위해 해시를 생성하고, 이를 암호화하여 헤더에 추가함.
- SPF, DKIM, DMARC를 제거하고
MX2레코드 하나로 표준화하여 자체 호스팅 이메일 스택을 단순화함. - IP 주소가 아닌 도메인에 대해 이메일을 인증함.
-
MX2를 구현하는 클라이언트는 OpenPGP를 대체할 수 있는 새로운 암호화 스킴을 선택할 수 있음.
추가 생각
- 대용량 파일을 공유할 수 있는 방법이 필요함.
- Google과 Microsoft가 참여하지 않으면
MX2는 절대 실현되지 않을 것임. - SMTP를 HTTP와 표준화된 REST API 및 JSON 본문으로 대체하는 것도 고려할 수 있음.
- HTML을 사용하는 것 자체가 논란이 될 수 있음. 이메일은 원래 HTML을 위해 설계되지 않았음.
- 새로운 표준을 엄격하게 시행할 수 있는 기회가 있음.
GN⁺의 의견
- 이메일 시스템의 복잡성과 보안 문제를 해결하려는 시도는 매우 흥미로움. 특히, 이메일의 진위와 무결성을 보장하는 새로운 방법을 제안하는 것은 유용할 것임.
- 그러나 새로운 표준을 도입하는 것은 매우 어려운 일임. 특히 Google과 Microsoft와 같은 주요 플레이어의 참여가 필수적임.
- HTML을 사용하는 것에 대한 논란은 여전히 존재함. 보안 문제를 해결하기 위해 다른 마크업 언어를 고려할 필요가 있음.
- 새로운 표준을 엄격하게 시행하는 것은 이상적이지만, 현실적으로는 어려울 수 있음. 표준의 드리프트와 구현 오류를 방지하기 위한 추가적인 메커니즘이 필요함.
- 이메일 시스템의 중앙 집중화는 새로운 표준을 도입하는 데 도움이 될 수 있지만, 동시에 특정 기업에 대한 의존성을 높일 수 있음.
적어도 렌더링 개선 관련해선 Google과 Microsoft가 이미 투자를 했죠... 둘 다 AMP Email 프로젝트에 참여하고 지원했으니까요.
JSON 처럼 데이터 표준을 만드는 것은 좋은데요.
렌더링 스펙도 같이 논의되어야해서 쉽지 않을 것 같습니다.
HTML 을 선택했던 이유도
HTML+CSS 렌더링 스펙에 무임승차하기 위한 것이 아니었을까요?
이미 윗분들이 극단적인 사례로 샵메일을 이야기해주셨네요. 개인적으로는 이미 잘 굴러가는 프로토콜을 대놓고 "deprecated"로 분류하고 (호환되지 않는 어떤 새로운) 프로토콜 표준만을 호환되도록 만드는 것 자체를 상당히 회의적으로 보고있습니다.
- 모든 MX2 레코드는 공개 키를 포함해야 함.
이게 좀 의아스러운게, 서비스 제공자들이 이 공개키를 사용자가 제출한 공개키로 하는것이 아니라 자신들이 만든 공개키로 할 것 같단 말이죠...
Hacker News 의견
해커뉴스 댓글 모음 요약
-
이메일 시스템의 복잡성과 상호운용성
- 인터넷 이메일 서비스 운영 경험을 바탕으로, 이메일 시스템은 복잡하지만 보편적으로 채택되고 상호운용성이 뛰어남.
- 새로운 시스템 도입은 기존 시스템의 막대한 R&D 투자와 경쟁해야 하는 어려움이 있음.
- 새로운 이메일 시스템을 제안하려면 IETF나 M3AAWG 같은 곳에서 제안하는 것이 좋음.
-
이메일의 모호성과 문제점
- 이메일의 헤더가 중복되거나 상충되는 값으로 인해 혼란이 발생할 수 있음.
- ASCII만 사용해야 하는 헤더에 8비트 값이 포함될 때의 문제 등 다양한 문제가 존재함.
- 이메일 스레드 관리 방식도 표준화되지 않아 문제를 일으킴.
-
이메일의 중앙화 문제
- 이메일의 중앙화는 바람직하지 않음. 기업들은 인류에게 최선이 아닌 자신들에게 유리한 방향으로 행동할 가능성이 큼.
- 자체 호스팅 이메일은 어렵지 않으며, 신뢰할 수 있는 제공자를 통해 쉽게 호스팅 가능함.
-
HTML 이메일의 문제점
- HTML 이메일은 피싱, 사기 등의 문제를 일으킬 수 있음.
- 이메일을 재설계한다면 HTML을 배제하고, Markdown 같은 형식을 사용하는 것이 좋을 것이라는 의견.
-
이메일의 비동기성 유지 필요성
- 이메일은 비동기적이어야 하며, 이는 24시간 근무를 방지하는 마지막 기술적 방어선임.
- 사람들이 더 나은 시스템을 채택하지 않는 이유는 이 때문임.
-
이메일 서버 운영의 어려움
- 이메일 서버 운영이 점점 더 어려워지고 있음. 대형 제공자들의 요구사항을 충족해야 하기 때문임.
- 소규모 서버는 대형 제공자나 스팸 발송자들에 의해 도태되고 있음.
-
정당한 이메일의 정의
- 정당한 이메일의 정의는 주관적임. 스팸은 인터넷을 망치고 있으며, 이를 막기 위해 비용을 부과하는 방법이 필요함.
-
이메일 시스템의 개선 필요성
- 이메일 시스템을 재설계하더라도 현재의 이메일 시스템을 유지하면서 개선하는 것이 바람직함.
- 현대적인 암호화 시스템 도입과 발신자 인증 시스템 도입이 필요함.
-
스팸 방지 체크리스트
- 스팸 방지를 위한 몇 가지 구현 수정이 필요함.
- 메일 포워더와 SMTP 서버는 가능한 한 빨리 포워딩하고, 스팸 필터링은 SMTP 수준에서 거부하는 것이 좋음.