요약

  • RFC 2342의 NAMESPACE 응답은 서버가 클라이언트에게 개인, 타 사용자, 공유 우편함 이름을 어떻게 해석하기를 원하는지 공개했다.
  • 그 지도는 의도적으로 불완전하고 권한에 민감했다. 우편함 발견, 존재, 선택 가능성, 읽기 가능 상태, 표시, 사람의 주의는 각각 별도의 근거를 필요로 했다.

문이 열리기 전에 세 장의 지도가 먼저 도착했다

IMAP 클라이언트가 완벽한 응답을 받는 장면을 상상해 보자. 빈 접두어와 슬래시 구분자를 가진 개인 네임스페이스 하나, 물결표로 시작하는 타 사용자 네임스페이스 하나, 그리고 공유 네임스페이스는 없음. 구문은 완전하고 세 위치는 올바른 순서다. 클라이언트는 이제 서버의 로컬 관례를 추측하지 않고도~mark/INBOX같은 이름을 만들 수 있다.

그 응답 어디에도 Mark라는 사용자가 존재한다는 말은 없다. 그의 INBOX가 이 인증된 사용자에게 보이는지, 서버가 그것을 나열할지, SELECT가 성공할지, 메시지가 존재하는지, 누군가 하나를 읽었는지도 말하지 않는다.

그것이RFC 2342가 이룬 좁은 성취다. NAMESPACE 이전에는 클라이언트가 사용자에게 개인 또는 공유 우편함의 접두어를 직접 입력하도록 요구하는 경우가 많았다. 이 확장은 그러한 명명 규칙을 발견 가능하게 만들었다. 지도의 범례를 표준화했을 뿐, 지도에 그려진 건물들을 표준화한 것은 아니다.

이 구분이 중요한 이유는 깨끗한 제어 평면 선언이 더 강한 주장으로 승격되기 쉽기 때문이다. 클라이언트는 공유 접두어를 보고 "공유" 섹션을 렌더링한다. 운영자는 NAMESPACE 교환이 성공했다는 이유로 우편함 발견을 건강하다고 표시한다. 지원 시스템은 광고된 타 사용자 브랜치를 위임된 접근이 작동한다는 증거로 취급한다. 각 결론은 응답이 넘었다고 주장한 적 없는 경계를 넘는다.

응답은 목록이 아니라 문법을 기술했다

untagged 응답은 세 개의 순서화된 네임스페이스 필드를 담는다: 개인(Personal), 타 사용자(Other Users'), 공유(Shared). 각 필드는NIL이거나 하나 이상의 네임스페이스 설명 목록일 수 있다. 설명은 접두어와 계층 구분자 또는NIL을 제공하며, 그 뒤에 확장이 따를 수 있다.

서버는 각 클래스에서 여러 네임스페이스를 노출할 수 있다. 구분자는 그들 사이에서 다를 수 있다. 접두어에는 구분자가 전혀 없을 수도 있다. RFC 2342는 서버가 자신이 지원하는 네임스페이스의 하위 집합만 노출하고 나머지는 클라이언트가 수동 입력 접두어를 받아들이도록 남겨두는 것까지 허용한다.

이러한 설계 선택은 범위를 명시한다. NAMESPACE는 클라이언트에게 이름이 어떻게 분할되고 결합되는지 알려준다. 네임스페이스 클래스의 전체 집합은 물론 그 안의 우편함도 열거하지 않는다.

NIL도 경계가 있는 근거다. 이 연결에서 이 클래스가 이 응답에 사용할 수 없다는 것을 말할 뿐이다. 서버가 그런 네임스페이스를 구현한 적이 없다는 것, 다른 사용자가 같은 응답을 본다는 것, 수동으로 입력한 접두어가 숨겨진 브랜치에 도달하지 못할 것이라는 것을 증명하지 않는다. RFC 2342는 네임스페이스 노출이 사용자별로 달라질 수 있다고 명시한다.

Lu Heng의 조율 아티팩트와 작동하는 현실 사이의 구분이 여기서 유용하다. 접두어는 이후 명령의 입력으로만 실행 가능하다. 클라이언트가 그것을 사용하고 서버가 현재 계정, 권한, 우편함 상태에서 그 요청을 평가할 때 운영적 의미를 얻는다. 관례의 공개는 결과를 사전 승인하지 않는다.

LIST는 별개의, 손실이 있는 관찰이었다

RFC 2342는 클라이언트가 타 사용자 접두어에%를 붙여 LIST를 발행할 수 있는 방법을 보여주면서, 목록 접근 권한을 부여하지 않은 사용자를 서버가 드러내지 않도록 경고했다. 서버는 승인된 이름만 반환할 수 있다. 광범위한 패턴을NO로 거부하고 구체적인 사용자명을 요구할 수 있다. RFC 자체의 예제에서도#Users/%나열은 실패하고, 사용자가 Mike의 이름을 제공하면#Users/Mike/%는 성공한다.

이것은 모순이 아니다. 보안 설계다. 명명 도메인의 존재가 클라이언트에게 그 점유자를 열거할 권리를 주지는 않는다. 네임스페이스는 광고되면서 그 내용은 필터링되거나 부분적으로만 보이거나 와일드카드로는 발견 불가능할 수 있다.

현대 IMAP은 이 분리를 더 선명하게 만든다.RFC 9051은 LIST가 클라이언트가 이용 가능한 전체 집합에서 우편함 이름의 부분 집합을 반환하며, 0개 이상의 응답을 반환할 수 있다고 말한다. 이름은\Noselect나\NonExistent를 가질 수 있다. 구독 목록에는 더 이상 존재하지 않는 우편함의 구독 이름이 포함될 수 있다.

따라서 "NAMESPACE가 성공했다", "LIST가 이름을 반환했다", "그 이름이 구독 중이다", "우편함이 존재하며 지금 선택 가능하다"는 네 개의 서로 다른 명제다. 이들을 하나의 상태로 취급하면 권한, 수명 주기 변경, 경합이 가장 활발한 지점에서 정확히 거짓 확신이 만들어진다.

보임과 읽음은 서로 다른 권리였다

RFC 4314는 우편함 권한을 구체적 권리로 나눈다.l권리는 우편함을 LIST 또는 LSUB에 보이게 한다.r권리는 SELECT와 STATUS를 허용한다.s권리는 영속적인 Seen/Unseen 정보를 다룬다. 다른 권리들은 플래그, 삽입, 생성, 삭제, expunge, ACL 관리를 각각 별도로 제어한다.

이 분할은 흔한 지름길을 막는다. 우편함은 읽을 수 없으면서 나열될 수 있다. RFC 9051이 구체적인 사례를 준다: LIST-STATUS는 사용자가l은 있지만r는 없는 우편함을 만날 수 있으며, 응답은 그것을 선택할 수 없다는 사실을 반영해야 한다. 명명 평면, 가시성 평면, 읽기 평면은 동의어가 아니다.

s조차 사람이 읽었다는 오라클이 아니다. Seen 플래그는 프로토콜 연산으로 바뀔 수 있다. 클라이언트는 그것을 설정하는 방식으로 내용을 가져오거나, 세션을 넘어 보존하거나, 권한 규칙 아래에서 조작할 수 있다. 플래그는 서버 측 메시지 상태를 기록한다. 눈, 이해, 주의를 관찰하지 않는다.

RFC 8440은 이후 확장 LIST가 MYRIGHTS 정보를 반환하도록 했다. 이는 왕복을 줄이고 나열된 우편함 옆에 더 강한 근거를 놓을 수 있다. 그래도 상태를 합치지는 않는다. 권리는 허용된 연산을 기술할 뿐, 연산이 발생했거나 성공했거나 콘텐츠를 렌더링했거나 사람에게 도달했다는 것을 증명하지 않는다.

SELECT는 우편함을 열었지, 독자를 여는 것이 아니었다

SELECT는 NAMESPACE가 흔히 오해당하는 상태 전이다. 성공하면 연결을 selected 상태로 이동시키고 FLAGS, EXISTS, UIDNEXT, UIDVALIDITY 같은 우편함 데이터를 반환한다. 실패 시NO는 그런 우편함이 없거나 접근할 수 없다는 뜻일 수 있다.

그 교환은 접두어보다 훨씬 많은 것을 증명한다. 이 연결이 이 시점에 서버의 현재 상태 아래에서 이 우편함을 선택했다는 것을 증명한다. 그래도 이후의 영수증은 남는다: FETCH가 요청한 본문을 반환했는지, 클라이언트가 디코딩했는지, 렌더링이 성공했는지, 창이 보였는지, 사람이 그것을 읽었는지?

이 후속 사건들 중 어떤 것도 명명 규칙에서 추론할 수 없다. 서로로부터 안전하게 추론할 수도 없다. 성공한 FETCH는 백그라운드 인덱서를 먹일 수 있다. 렌더링된 메시지는 다른 창 뒤에 놓일 수 있다. Seen 플래그는 이해 없이 설정될 수 있다. 사람이 읽는 행위는 IMAP 프로토콜 상태 기계 바깥에 속한다.

지속된 교훈은 근거적 절제였다

RFC 2342는 실제 상호운용성 문제를 해결했다. 클라이언트가 서버별 우편함 루트를 하드코딩하지 않게 했다. 동시에 로컬 변형을 보존했다: 복수 루트, 사용자별 노출, 서로 다른 구분자, NIL 클래스, 확장, 권한 인지 발견.

그 절제가 역사적 교훈다. 사양은 이름 형식의 디렉터리를 목록 오라클로 바꾸지 않았다. 클라이언트에게 더 나은 질문을 구성하는 결정적 방법을 주는 한편, 답은 이후 명령과 현재 인증에 남겨두었다.

인프라 시스템을 위한 강력한 패턴이다. 스키마는 무언가를 식별하는 방법을 말할 수 있으면서 그것의 존재를 증명하지 않는다. 기능은 명령이 이해된다는 것을 말할 수 있으면서 요청된 동작이 성공할 것임을 증명하지 않는다. 성공한 제어 응답은 조사를 닫지 않고 앞으로 나아가게 할 수 있다.

서버는 세 장의 메일 지도를 그렸다. 절제된 클라이언트는 여전히 각 문을 두드려야 했다.