요약
- RFC 3503은 대소문자를 구분하지 않는 공유
$MDNSent키워드를 만들어, 하나의 IMAP 사서함을 쓰는 여러 메일 클라이언트가 중복된 메시지 처분 통지(MDN)를 내보내지 않도록 했다. - 이 키워드는 이름보다 의도적으로 넓었다. 클라이언트는 거부 후에, 보낸 편지 사본에, 미완성 메시지에, 그리고 MDN을 보냈든 안 보냈든 일부 자동 판단 후에 이를 설정했다. 결과적으로 이것은 '보냈다'는 기록이나 '사람이 읽었다'는 기록이 아니라 억제 상태임이 드러났다.
문제의 출발점은 컴퓨터 두 대와 사서함 하나다. 첫 번째 컴퓨터의 메일 프로그램이 처분 통지 요청을 검토한다. 하나를 보내거나, 사용자가 거부한다. 프로그램은 그 판단을 로컬 설정 파일에 기록한다. 이후 두 번째 프로그램이 다른 곳에서 같은 사서함을 연다. 두 번째 프로그램은 첫 번째 프로그램의 메모리를 볼 수 없다. 메시지 자체에 공유 상태가 없다면 같은 질문이 다시 제기될 수 있고 두 번째 통지가 발송될 수도 있다.
RFC 3503은 이를 새로운 전송 수단이 아니라 조율(coordination) 문제로 다뤘다. 2003년 3월에 발표된 이 문서는 IMAP 명령도 응답도 추가하지 않았다. 대신 특수 목적 사서함 키워드인$MDNSent를 정의하고 메일 사용자 에이전트(MUA)가 이를 어떻게 사용해야 하는지 기술했다. 공유 메일스토어가, 각자 독립적인 상태를 유지하던 클라이언트들 사이의 좁은 공통 계층이 된 것이다.
이름은 잘못된 추론을 부른다. "$MDNSent(MDN sent)"는 이미 일어난 사건을 기술하는 것처럼 보인다. 그러나 규범적 동작은 훨씬 조심스럽다. 자동 처리 과정에서 MUA는 MDN을 보냈는지와 무관하게, 판단이 필요한 모든 메시지에 대해 이 키워드를 설정해야 했다. 사용자가 통지를 명시적으로 거부해도 클라이언트는 같은 키워드를 설정할 수 있었고, 그래야 다른 MUA가 다시 묻지 않았다. 보낸 편지 사본을 저장하는 프로그램도 이를 설정해야 했고, 미완성 메시지를 저장하는 프로그램도 설정해야 했다. 서로 다른 이력들이 하나의 내구성 있는 지시로 수렴했다. 이 저장된 메시지에 대해서는 MDN을 생성하지 말라는 것이다.
그래서$MDNSent는 전송 영수증이 아니라 제어 토큰이었다. 그 진실값은 미래 지향적이었다. 이를 발견한 준수 클라이언트는 동작을 멈추고, 다른 플래그를 무시하고, MDN 발송을 삼가야 했다. 이 토큰이 존재한다고 해서 어느 클라이언트가 판단했는지, 통지 객체가 작성되었는지, 제출이 성공했는지, 전송 계층이 전달했는지, 원 메시지의 수신자가 무엇을 읽었는지는 알 수 없었다.
토큰에 의존하기 전에 클라이언트는 사서함이 이를 보존할 수 있는지 물어야 했다. RFC 3503은PERMANENTFLAGS응답을 사용해$MDNSent전용 지원 또는 임의 키워드 지원을 확인하도록 했다. 역량 광고와 실행은 분리되어 있었다. 서버가 임의 키워드를 광고하더라도 사서함의 키워드 용량이 소진되면 이후STORE를 거부할 수 있었다. 예시는NO를 돌려주며 키워드를 위한 공간이 없다고 밝혔다.
이 실패에 대한 권고 응답은 설계 우선순위를 드러낸다.$MDNSent를 저장할 수 없다면 클라이언트는 MDN을 보내서는 안 된다. 내구성 있는 공유 메모리 없이 발송하면 당장의 요청은 만족하겠지만, 다른 MUA가 다시 보낼 여지를 남긴다. 규격은 통제되지 않은 중복보다 누락된 통지를 선호했다. 이는 정확히 한 번의 전달(exactly-once delivery)이 아니다. 하나의 조율 경계에서의 fail-closed 선택이다.
다른 IMAP 플래그를 함부로 재활용할 수는 없었다.\Recent는 트리거로 금지되었다. 여러 연결이 같은 사서함을 선택할 때 어느 연결이 메시지를 recent로 보는지는 정의되지 않기 때문이다. 로컬 관찰은 작업의 공유 소유권으로 쓸 수 없었다.\Seen은 발송 억제의 한 지표가 될 수 있었지만 확립된 의미가 달랐다.\Draft는 미완성 메시지를 표시하고 별도로 MDN을 막았다. 그러나$MDNSent가 있는 경우 클라이언트는 이 판단에 대해 다른 모든 플래그와 키워드를 무시해야 했다.
이 상태는 의도적으로 일방향이었다. 일단 설정되면 클라이언트는$MDNSent를 해제해서는 안 된다. 해제하면 겉보기 허가가 복원되고 과거의 판단을 재구성하지 않은 채 중복 위험이 다시 열린다. 이 단조성(monotonic) 성질은 조율을 단순하게 만들었지만, 동시에 이벤트 해석의 방어 가능성을 떨어뜨렸다. 영구 정지 비트는 감사 로그가 아니다. 누가, 언제, 어떤 동의 하에, 어떤 전송 결과로 행동했는지는 보존하지 않는다.
복사는 또 다른 경계를 만들었다. 클라이언트는 일반 IMAPCOPY가$MDNSent를 보존하는지 확인해야 했다.APPEND로 수행하는 서버 간 복사는 키워드를 정확히 함께 옮겨야 했다. 보낸 편지나 미완성 메시지가 폴더에 저장될 때도 이를 받았다. 이동 중 비트가 떨어지면, 목적지 클라이언트는 복사된 메시지를 마치 이전 억제 판단이 없었던 것처럼 마주하게 된다.
ACL 규칙은 그 보존을 이례적으로 명시적으로 만들었다. 서버가 당대의 IMAP ACL 확장을 구현한다면, 클라이언트가 플래그를 쓸 권한이 없더라도 COPY에서$MDNSent를 보존해야 하며, 동시에 클라이언트가 복사 자체를 수행할 권한이 있는지는 여전히 검사해야 했다. 복사 권한과 플래그 편집 권한은 구분되었다. 서버는 조율 속성을 선택적 사후 편집이 아니라 복사된 객체의 일부로 보존했다.
대소문자는 새 상태를 만들지 않았다.$MdnSENt,$MdnSENT,$mdnsent는 같은 키워드로 비교되어야 했다. 예시는 대소문자가 섞인 표기를 읽어오고 다른 표기로 검색했다. 이는 미학적 문제가 아니었다. 두 클라이언트가 대소문자로 하나의 공유 상태를 갈라 놓는다면 중복 억제는 표현 경계에서 실패한다.
더 넓은 MDN 체계는 서로 다른 증거를 공급했다. 원래의 RFC 2298은 기계가 처리할 수 있는 처분 보고서를 정의했다. RFC 3798이 이를 개정했고, RFC 8098은 이후 현대 규격을 인터넷 표준 STD 85로 만들었다. 처분 값은 범위가 한정되어 있다.displayed는 MUA가 사서함을 읽는 누군가에게 메시지를 표시했다는 뜻이며, 내용이 읽히거나 이해되었음을 보장하지 않는다.processed는 규칙이나 서버가 개입했을 수 있고 사람이 전혀 없었을 수도 있다.deleted는 수신자가 메시지를 본 적이 없음을 증명하지 않고, 이후 복원도 막지 못한다.
RFC 8098은 개인정보와 보안 한계도 유지한다. 사용자 동의가 중심이며, 기본값은 발송하지 않는 것이다. 주소 불일치는 확인을 요구한다. MDN은 위조될 수 있고, 유실될 수 있으며, 메일 폭탄에 악용될 수 있고, 클라이언트 정보를 노출하는 데 쓰일 수 있다. 표준은 MDN이 전달에 대한 부인 방지 증거를 제공하지 않으며, 메시지가 읽혔거나 읽히지 않았음을 보장할 수 없다고 명시한다. 따라서 실제 MDN은 출처와 전송 문제가 붙은 유형화된 주장에 머문다. 억제 키워드는 그보다 더 좁은 사실이다.
키워드의 후속 등록은 그 이름보다 진짜 의미를 더 분명하게 만들었다. RFC 5788은$MDNSent를, 주석이 달린 메시지에 대해 MDN을 보내서는 안 된다는 것을 지정하는 공유 키워드로 기술했다. 그 문장은 전기(傳記)가 아니라 금지 명령이다. 다음 행위자에게 하지 말아야 할 일을 알려준다.
JMAP은 이후 동작과 상태 사이의 결합을 더 촘촘히 만들었다. RFC 9007은MDN/send를 정의하고, 클라이언트가 대응하는$mdnsent갱신을 마련하도록 요구하며, 키워드가 설정되지 않을 작업을 서버가 거부하도록 허용하고, 비트가 이미 있는 경우의mdnAlreadySent를 정의한다. 이는 JMAP 메서드 안에서 발송과 조율 상태 사이의 간격을 줄인다. 그러나 RFC 3503을 소급적으로 바꾸지 않으며, 사람이 원 메시지를 읽었는지, 통지가 목적지에 도달했는지를 여전히 증명하지 못한다.
따라서 유용한 증거 사다리는 플래그 이름보다 길다.PERMANENTFLAGS는 저장 역량을 광고한다. 성공한STORE는 공유 억제 상태를 기록한다. 클라이언트의 판단은 MDN을 만들 수도, 만들지 않을 수도 있다. 제(submission)는 통지를 메일 전송 계층에 넘긴다. 전달은 그것을 반대편 끝에 놓는다. 처분 필드는 하나의 주장된 결과를 기술한다. 사람의 주의, 이해, 행동은 그 뒤에 별도로 따라온다. 낮은 단계의 영수증이 높은 단계의 권위를 얻지는 못한다.
이는 작은 프로토콜 교훈이면서도 내구성 있는 제도적 형태를 지닌다. 공유 시스템은 흔히 하나의 좁은 불변식을 필요로 한다. 독립적인 참여자들에 의한 반복 동작을 막는 것이다. 컴팩트한 마커가 그것을 수행할 수 있으며, 역사나 신원 증명, 결과 인증서가 될 필요는 없다. 문제는 그 편리한 라벨이 쓰기 규칙이 허용하는 것 이상으로 읽힐 때 시작된다.
RFC 3503은 공통 계층을 얇게 유지함으로써 성공했다. 클라이언트의 미래 동작을 조율했다. 수신자의 사적 판단을 지배한다거나, 발신자를 인증하거나, 메일 전송을 보장하거나, 주의를 인증한다는 주장은 하지 않았다. 정직한 해석은 이름과 거의 반대이다.$MDNSent는 멈추라고 말했다. 어떤 때는 정말로 아무것도 발송되지 않은 상태에서.
출처
- https://www.rfc-editor.org/rfc/rfc3503.html
- https://www.rfc-editor.org/rfc/rfc3503.txt
- https://www.rfc-editor.org/info/rfc3503
- https://datatracker.ietf.org/doc/rfc3503/
- https://datatracker.ietf.org/doc/rfc3503/history/
- https://www.rfc-editor.org/errata_search.php?rfc=3503
- https://www.rfc-editor.org/rfc/rfc2298.html
- https://www.rfc-editor.org/rfc/rfc3798.html
- https://www.rfc-editor.org/rfc/rfc8098.html
- https://www.rfc-editor.org/info/rfc8098
- https://www.rfc-editor.org/rfc/rfc3501.html
- https://www.rfc-editor.org/rfc/rfc9051.html
- https://www.rfc-editor.org/rfc/rfc2086.html
- https://www.rfc-editor.org/rfc/rfc4314.html
- https://www.rfc-editor.org/rfc/rfc5788.html
- https://www.iana.org/assignments/imap-jmap-keywords/imap-jmap-keywords.xhtml
- https://www.rfc-editor.org/rfc/rfc9007.html
- https://www.rfc-editor.org/rfc/rfc8621.html
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
회원 브리핑
프로필 심층 컨텍스트
올바른 멤버십 등급으로 로그인하면 전체 브리핑과 출처 노트를 볼 수 있습니다.
Strategic Circle 전용
Strategic Circle
모든 독자에게 공개됩니다. 가입 후 로그인하면 프로필 브리핑를 열람할 수 있습니다.
Strategic Circle 가입하기Leadership Alliance 전용
Leadership Alliance
자격을 갖춘 IP 자산 소유자 및 운영진을 위한 콘텐츠입니다. 로그인하면 Leadership Alliance 브리핑을 열람할 수 있습니다.
Leadership Alliance 가입하기





