요약

  • 1998년 RFC 2369은 메일 헤더에 구독 취소 경로를 표시할 수 있게 했다. URL 방문만으로 탈퇴를 처리하면 자동 검사와 사람의 요청이 서버에서 구별되지 않는다.
  • 2017년 RFC 8058은 List-Unsubscribe-Post: List-Unsubscribe=One-Click을 추가했다. 유효한 DKIM 서명이 두 구독 취소 헤더를 보호해야 하며 수신자는 이용자 동의를 얻은 뒤 HTTPS POST를 보낸다.
  • POST 본문에는 정해진 키와 값만 들어간다. 쿠키나 HTTP 인증에 의존할 수 없고 송신 서버는 HTTPS 리디렉션을 보내서도 안 된다. 새 헤더는 IANA 등록부에 올라 있다.

살펴본 것뿐인데 탈퇴가 됐다

RFC 2369의 목적은 간단하고 유익했다. 메일링 리스트가 List-Unsubscribe에 주소를 넣으면 수신 프로그램은 긴 메일의 맨 아래를 뒤지지 않고 나가는 길을 보여 줄 수 있다. 헤더에는 HTTPS URL도 들어갈 수 있다. 1998년의 설계는 출구를 찾게 해 주었지만, 그 URL을 여는 주체가 누구인지 판정하는 절차를 마련한 것은 아니었다.

보안 프로그램도 이 주소를 읽는다. RFC 8058은 스팸 방지 소프트웨어가 이용자 행동 없이 메일 헤더의 자원을 자동으로 가져오는 일을 문제로 적었다. 리스트 운영자가 URL 조회를 곧바로 탈퇴 명령으로 삼으면, 검사 프로그램은 사람 대신 명령을 실행한다. 송신 서버에 도착한 요청만 보면 뒤에서 수행된 검사인지 독자가 누른 버튼인지 기계적으로 가려낼 길이 없다. 독자를 보호하려던 검사가 독자를 리스트에서 지워 버리는 셈이다.

확인 화면은 급한 불을 껐다. 자동 프로그램은 첫 화면을 받아도 다음 버튼까지 누르지는 않는다. 사람은 화면을 보고 탈퇴를 끝낼 수 있다. 그러나 그때부터 한 번의 동작으로 끝내는 탈퇴는 불가능했다. 운영자는 오작동과 번거로움 사이에서 선택해야 했다. 진짜 문제는 URL이라는 안내문을 상태 변경에 대한 동의서처럼 사용한 데 있었다.

2017년의 새 헤더는 동작을 분리했다

RFC 8058은 예전 헤더를 없애지 않았다. 한 번에 탈퇴시키려는 송신자는 List-Unsubscribe에 HTTPS URI를 싣고, 별도 헤더 List-Unsubscribe-Post에 정확히 List-Unsubscribe=One-Click을 적는다. 수신 프로그램은 이용자 동의를 얻은 다음 그 고정 문자열을 본문으로 삼아 해당 URI에 HTTPS POST를 보낸다. 주소를 확인하는 조회와 구독 상태를 바꾸는 POST는 처음부터 서로 다른 요청이다.

송신자는 유효한 DKIM 서명으로 두 헤더를 모두 덮어야 한다. 서명의 h= 목록에도 두 이름이 들어간다. 수신자는 그 서명이 없는 메시지에 한 번의 동작으로 하는 탈퇴를 제공하지 않는 것이 원칙이다. 서명은 이용자의 의사를 만들어 주지 않는다. 송신자가 제시한 주소와 동작 설명이 검증 가능한 메시지에 함께 들어 있었는지를 확인한다.

사람의 의사는 별도의 조건이다. RFC는 수신자가 이용자 동의 없이 POST를 보내서는 안 된다고 명시한다. 동의를 어떤 화면에서 받을지는 정하지 않는다. 리스트 운영자가 서명된 제안을 만들고, 메일 프로그램이 행동을 보여 주고, 독자가 떠날지 결정한다. 자동 링크 검사는 그중 어느 역할도 대신할 수 없다.

서버는 내건 주소에서 일을 끝내야 한다

POST 본문은 정해진 키와 값 한 쌍이다. 쿠키, HTTP 인증, 다른 부가 정보를 담지 않는다. 따라서 URI 자체가 어느 독자를 어느 리스트에서 지울지 충분히 알려 줘야 한다. RFC는 추측하기 어려운 불투명 식별자를 권한다. 브라우저 로그인 세션에 기대는 서버라면 규격에 따른 메일 프로그램의 요청을 처리할 수 없다.

송신 서버는 POST에 HTTPS 리디렉션을 돌려줘서도 안 된다. RFC가 드는 이유는 구체적이다. 과거의 POST 리디렉션은 안정적으로 동작하지 않았고, 브라우저가 POST를 GET으로 바꾸는 경우도 있었다. 탈퇴에 사용할 동사를 명확히 가른 뒤 다른 주소로 넘겨 버리면 핵심 구별이 전송 도중 무너진다. 게시한 주소가 요청을 받아 회원 상태를 바꿔야 한다.

RFC 8058은 RFC 2369의 보통 구독 취소 URL 사용법을 바꾸지 않는다. 새 헤더가 명시된 한 번의 동작에 별도 규칙을 붙인다. IANA가 그 이름을 등록했어도 이름만으로 탈퇴가 완료되지는 않는다. 서명, 동의, 수신자의 POST, 송신자의 처리 서버가 순서대로 맞물려야 한다.

출구는 링크 하나가 아니다

2017년 개정은 짧은 헤더 하나를 더했지만 책임은 세밀하게 나눴다. 송신자는 서명과 서버를 책임지고 수신 프로그램은 표시와 요청 시점을 책임진다. 독자는 결정을 한다. 뒤에서 움직이는 보안 도구는 관찰만 한다. 이 구분이 빠진 출구는 뜻밖의 탈퇴 기계가 되거나 눌러도 끝나지 않는 장식이 된다.

세 공식 기록은 프로토콜과 등록을 증명한다. 특정 메일 서비스에서 몇 번 사용됐는지 말하려면 날짜가 있는 원본 메시지, 수신 프로그램 설명서, 송신 서버 기록이 필요하다. RFC 8058이 남긴 역사적 사실은 또렷하다. 인터넷에서는 소프트웨어가 링크를 아주 쉽게 열 수 있다. 그래서 이메일은 어떤 열기가 명령인지 정확히 정해야 했다.