요약

  • 2011년 3월의 RFC 6154는 IMAP LIST 응답에 넣을 수 있는 특별 용도 속성을 정의했다. 앱은 화면에 보이는 이름을 짐작하지 않고 \Sent, \Drafts, \Trash 같은 역할을 찾을 수 있다.
  • \Sent는 서버가 보낸 메일 사본을 자동 보관하는 폴더일 수도, 앱이 거기에 사본을 저장하라는 안내일 수도 있다. 폴더 하나에 여러 속성이 붙을 수 있고 같은 속성이 여러 폴더에 붙을 수도 있다.
  • 확장 LIST는 SPECIAL-USE를 알릴 수 있다. 선택적인 CREATE와 METADATA로 역할을 요청하거나 바꿀 수 있지만 서버는 지원하지 않는 요청을 거절할 수 있다. IANA 속성 등록부가 공통 이름을 기록한다.

폴더 이름을 설정 규칙으로 삼았던 시절

한 계정을 두 메일 앱에서 연다. 첫 앱은 그럴듯한 이름의 폴더에 보낸 메일을 저장한다. 둘째 앱은 그 이름을 알아보지 못하고 새 폴더를 만든다. 사용자가 보낸 기록은 둘로 갈라진다. 반대로 두 앱이 모두 서버가 알아서 사본을 넣을 것이라고 생각하고, 서버는 앱을 기다릴 수도 있다. 화면에서는 사소한 설정처럼 보이지만, 나중에 자신이 보낸 메일을 찾을 때 기록의 빈자리가 드러난다.

1999년의 IMAP 구현 권고는 ‘Sent Mail’이나 ‘Trash’ 같은 관례적 이름을 다뤘다. 관례는 사람이 읽기 좋지만 프로그램 사이의 약속으로는 약하다. 서버는 다른 이름을 쓸 수 있고 사용자는 다시 이름을 붙일 수 있다. 그 표시만으로는 서버가 사본을 자동으로 넣는지도 알 수 없다. 앱은 사람을 위한 이름에서 저장 절차를 거꾸로 추론하고 있었다.

RFC 6154는 폴더의 용도를 LIST 응답 안으로 옮겼다. 처음 정의한 속성은 \All, \Archive, \Drafts, \Flagged, \Junk, \Sent, \Trash 일곱 가지다. 서버는 다른 폴더 속성과 함께 이를 돌려줄 수 있다. 폴더의 화면 이름은 사용자 취향대로 남겨 두고 앱은 표준화된 용도를 읽는다.

이 변화는 누가 설명해야 하는지를 바로잡았다. 새로 접속한 앱은 서버의 폴더 배치를 모른다. 서버는 자신이 지정한 역할을 안다. 서버가 그 정보를 내보내면 사용자가 앱을 옮길 때마다 이름을 해석해 줄 필요가 줄어든다. 서버의 설명은 선택의 출발점이며, 메일을 실제로 넣었다는 작업 기록은 별개다.

\Sent 표식은 손을 움직이지 않는다

RFC 6154는 \Sent를 두 방식으로 설명한다. 어떤 서버는 보낸 메일의 사본을 자동으로 넣는다. 다른 서버는 앱에 여기로 저장하라고 알려 준다. 앱이 후자의 서버를 전자처럼 믿으면 폴더는 비어 있다. 서버가 이미 넣는데 앱도 넣으면 중복 사본이 생길 수 있다. 속성은 어느 폴더가 논의 대상인지 알려 준다. 한 통의 실제 이동이 누가 보관했는지 보여 준다.

다른 역할도 같은 내부 동작을 보장하지 않는다. \All은 가상의 전체 보기일 수 있고 \Trash나 \Junk의 메일을 뺄 수 있다. \Archive의 뜻은 서버에 달렸다. \Drafts는 초안 표시가 붙은 메시지의 가상 모음일 수도, 앱이 초안을 넣는 목적지일 수도 있다. \Trash는 서버의 삭제 모델이나 IMAP의 \Deleted 표시를 앱이 사용하는 방식과 맞물린다. 공통 어휘는 차이를 읽게 해 준다.

폴더에 특별 속성이 아예 없을 수도 있고 하나 또는 여러 개가 있을 수도 있다. 두 폴더에 같은 \Sent가 붙을 수 있다. 역할은 사용자별로 달라질 수 있다. 두 사람이 물리적으로 같은 폴더를 공유해도 두 사람 모두 그 폴더를 자신의 보낸 편지함으로 정했다고 볼 수 없다. 속성 하나를 본 뒤 언제나 유일한 답이라고 믿으면 이름 추측의 실수를 되풀이한다.

IANA의 IMAP 폴더 속성 등록부는 이름과 정의 문서를 모아 둔다. 한 통의 메일이 어디에 저장됐는지, 누가 저장했는지는 적지 않는다. 등록부는 언어를 맞추고 서버와 앱이 실제 기록을 만든다.

발견과 지정 사이에는 서버의 승인 단계가 있다

RFC 6154는 확장 LIST 틀을 이용했다. 지원 서버는 CAPABILITY에 SPECIAL-USE를 알린다. 앱은 특별 속성이 붙은 폴더만 나열하도록 하거나 응답에 속성을 포함하도록 요청할 수 있다. 앞의 선택은 뒤의 반환을 포함한다. 보통 LIST 응답에도 속성이 나올 수 있는데, 그 방식에는 별도의 능력 문자열이 없다. 통신 기록은 한 줄만 보고 결론을 내릴 수 없다.

새 폴더를 원하는 앱은 선택적 CREATE USE로 역할까지 요청할 수 있다. 서버가 CREATE-SPECIAL-USE를 따로 알릴 때 가능한 방식이다. 서버는 충돌을 거절하거나, 기존 폴더에서 역할을 옮기거나, 같은 역할을 둘에 허용할 수 있다. 요청한 역할을 붙여 만들 수 없다면 폴더를 만들지 않고 CREATE 전체를 거절해야 한다. 앱이 요청했다는 사실과 서버가 받아들였다는 사실은 다르다.

IMAP METADATA를 지원하는 서버는 /private/specialuse에 기존 폴더의 역할을 나타내고 변경을 허용할 수 있다. 서버는 변경 내용을 검증해야 한다. 표시 이름 변경, 역할 지정, 메일 이동은 각각 별도의 명령과 응답을 남긴다.

속성에 자동 처리까지 연결되면 권한 문제가 생긴다. RFC 6154는 \Junk를 예로 든다. 서버가 스팸으로 판단한 메일을 이 폴더로 자동 보낼 때, 공유 폴더에 그 역할을 부여하도록 허용하면 잘못 분류된 정상적인 개인 메일이 다른 사람에게 보일 수 있다. 작은 표식이 서버의 행동을 바꾸므로 서버가 요청을 받아들일지 판단해야 한다.

RFC와 등록부는 역할을 알리고 요청하는 방법을 보여 준다. 특정 계정에서 보낸 사본이 어디에 도착했는지는 날짜가 남은 CAPABILITY/LIST, CREATE나 METADATA의 결과, 실제 메일의 위치로 확인해야 한다. 폴더 이름은 그중 가장 약한 단서다.