요약

  • RFC 2180은 한 IMAP 세션이 메일박스를 변경하는 동안 다른 세션이 그 메일박스를 사용 중일 때 여러 가지 규격 호환 응답을 허용했습니다. 명령이 성공했다는 사실이 모든 세션이 즉시 동일한 네임스페이스나 데이터를 본다는 증거는 아니었습니다.
  • 실질적인 타협은 클라이언트의 내성이었습니다. 소프트웨어는 한 서버의 선호 동작을 프로토콜로 굳히는 대신, 지연된 EXPUNGE 정보, 부분 결과, 고스팅된 콘텐츠, 변하는 시퀀스 번호를 조정해야 했습니다.

성공적인 삭제 후에도 읽을 수 있는 메일박스

두 클라이언트가 메일박스FOO를 선택했다고 가정해 봅시다. 첫 번째 클라이언트가DELETE FOO를 보내고 태그가 붙은OK를 받았습니다. 이어서 세 번째 클라이언트가FOO를 요청하면 존재하지 않는다는 답을 받습니다. 그러나 삭제 전에 메일박스를 선택했던 두 번째 클라이언트는 여전히 그 내용에 대해STORE나FETCH를 실행할 수 있습니다.

이것은RFC 2180이 우연히 허용해 둔 모순이 아닙니다. 문서화된 전략 중 하나입니다. 서버는 보이는 네임스페이스에서 이름을 제거하되 이미 그 메일박스를 들고 있는 세션을 위해 메일박스를 유지하고, 마지막 참조가 닫힐 때 데이터를 파기할 수 있습니다. 또는 메일박스가 사용 중인 동안 삭제를 거부할 수도 있고, 삭제를 완료하면서 다른 세션을BYE로 끊을 수도 있습니다.

각 선택은 서로 다른 운영적 속성을 보존합니다. 거부는 활성 세션을 보호하지만 인기 있는 메일박스를 사실상 삭제 불가능하게 만들 수 있습니다. 고스팅은 그 세션들의 연속성을 보존하지만 소멸을 지연시키고 이름의 즉각적인 재사용을 막습니다. 연결 끊기는 삭제를 확정하지만 세션 연속성을 희생합니다. 이 메모는 그 트레이드오프를 아키텍처로 피할 수 있다고 가장하지 않았습니다.

같은 분열은 이름 변경에서도 나타납니다. 서버는 메일박스의 이름 속성만 바꿀 수 있습니다. 이미 선택한 클라이언트는FETCH같은 명령을 계속 실행할 수 있는데, 이 명령들은 예전 이름이 아니라 선택된 상태를 참조하기 때문입니다. 그러나APPEND FOO는 실패할 수 있고, 선택적으로NEWNAME힌트를 반환할 수 있습니다. 콘텐츠 표면과 네임스페이스 표면이 갈라진 것입니다.

클라이언트가 그 이유를 알 수 있도록 허용되기 전에 시퀀스 번호는 이미 낡았다

동시 삭제(expunge)는 더 뾰족한 문제를 만듭니다. IMAP 메시지 시퀀스 번호는 현재 선택된 메일박스에서의 위치를 기술합니다. 메시지가 삭제되면 이후 위치들이 당겨집니다. 그런데RFC 2060은FETCH,STORE,SEARCH를 포함한 특정 명령이 진행 중일 때EXPUNGE응답이 끼어드는 것을 금지합니다. 따라서 두 번째 클라이언트는 자신의 시퀀스 맵이 갱신을 기다리는 동안에도 작업을 수행할 수 있습니다.

RFC 2180은 허용되는 서버 전략 몇 가지를 기록합니다. 서버는 미결FETCH에 답할 수 있을 만큼 고스트 사본을 유지할 수 있습니다. 아직 존재하는 메시지에 대해서만 데이터를 반환하고 태그가 붙은NO로 마무리할 수 있습니다. 살아남은 메시지에는 일반 데이터를, 삭제된 메시지에는 NIL 형태의 데이터를 반환하고 태그가 붙은OK로 마무리할 수 있습니다. 아니면 여러 클라이언트가 메일박스를 들고 있는 동안 삭제를 거부함으로써 상황 자체를 피할 수도 있습니다.

NIL은 특히 시사적입니다. 빈 플래그 목록이나 빈 본문은 요청한 데이터가 실제로 비어 있음을 뜻할 수 있습니다. 문서화된 실무에서는 같은 모양이, 클라이언트가 삭제를 알기 전에 사라진 메시지를 대신할 수도 있습니다. 클라이언트는 통법적으로 유효한 하나의 응답을 그것이 실제 담은 것보다 더 확실한 지식으로 바꿀 수 없습니다. 모호성이 중요한 상황이라면NOOP를 보내 미결EXPUNGE응답을 받아 시퀀스 맵을 갱신하고 재시도 여부를 판단해야 합니다.

STORE는 성공의 의미에 대한 또 다른 한계를 드러냅니다..SILENT를 사용하면 서버는 요청된 집합에서 아직 존재하는 모든 메시지를 갱신하고OK를 반환할 수 있습니다. 다른 곳에서 이미 삭제된 메시지를 가리키는 시퀀스 번호가 집합에 섞여 있더라도 말입니다. 이 접수증은 존재하는 메시지에 대해 허용된 작업이 끝났다는 뜻이지, 원래 집합이 그대로 유지됐다는 뜻이 아닙니다.

COPY는 한 명령에 대해 의미를 고정했지, 메일박스에 대해 고정하지 않았다

COPY에는 더 좁은 규칙이 적용됐습니다. 미결 삭제 통지는 COPY와 함께 올 수 있는데, 클라이언트가 다른 복사를 연이어 수행하기 전에 반드시 결과를 기다려야 하기 때문입니다. 서버는 명령 시작 시점의 시퀀스 번호를 기준으로 요청된 메시지를 식별합니다. 그 위치들은 끝날 때쯤에는 달라져 있을 수 있지만, 명령이 성공하면 시작 시점에 식별된 메시지들이 목적지에 나타나야 합니다. 복사가 실패하면 목적지는 이전 상태로 복원되어야 합니다.

이것은 얼어붙은 메일박스가 아니라 의미의 한정된 스냅샷입니다. 이것은 하나의 명령을 움직이는 색인으로부터 보호할 뿐, 원본이 더 이상 변하지 않는다는 것, 모든 클라이언트가 같은 시퀀스 맵을 공유한다는 것, 복사된 메시지가 이후 명령에서도 여전히 접근 가능하다는 것을 증명하지 않습니다.

보편적 구현 주장이 아니라 상호 운용성 노트

RFC Editor 정보 기록은 RFC 2180을 Informational로 분류합니다. 문서 자체의 서론은 이것이 IMAP4 준수를 정의하지도, 유효한 동작을 전부 열거하지도 않는다고 말합니다. RFC 2060이 여전히 준수 기준이었습니다. 이 문서는 일부 서버의 실무와 IMAP 메일링 리스트가 합리적이라고 판단한 동작들을 기록합니다.

이 범위 설정이 중요합니다. 이 메모는 현재 어떤 서비스가 무엇을 하는지 확립하지 않습니다. 채택률을 측정하거나, 배포를 증명하거나, 제품을 인증하지 않습니다. 그 역사적 기여는 더 정확합니다. 프로토콜의 자유를 보이게 하고 그 결과로 생기는 부담의 귀속을 정했다는 것입니다. 견고한 클라이언트는 익숙한 한 서버의 습관을 상대로 쓰일 수 없습니다. 프로토콜이 허용하는 전체 공간을 상대로 쓰여야 했습니다.

이후의 작업은 구체적 비용을 좁혔지만 구분 자체를 지우지는 않았습니다.RFC 2177은 대기(idle) 중인 클라이언트가 메일박스 갱신을 더 빨리 수신받도록 했지만, 여전히 모호성의 한계를 존중했습니다.RFC 7162는 수정 시퀀스,VANISHED, QRESYNC 메커니즘을 추가해 재동기화를 더 효율적으로 만들었습니다. 그러나 어느 것도 태그가 붙은OK를 즉각적 전역 수렴의 증거로 바꾸지는 못합니다.

오래 지속되는 교훈은 이것입니다. 명령 접수증, 네임스페이스 뷰, 선택된 세션의 뷰, 보존된 바이트는 서로 다른 현실의 층위에 속합니다. 이들을 혼동하면 소프트웨어가 취약해지고 삭제 약속은 기만적이 됩니다. RFC 2180은 분열된 현실을 없애지 않았습니다. 현실이 잠시 갈라졌을 때 클라이언트가 계속 나아갈 방법을 규정한 것입니다.