요약

본 문서는 1993년에 처음으로 쓰여졌으며, 최근 업데이트 된 "Comparison Two Approaches to Remote Mailbox Access: IMAP vs. POP"이라는 문서의 제세한 설명이다. 본 문서의 목적은 메시지 접근 패러다임과 프로토콜에 대한 보다 자세한 배경이론을 제공하는 것이며 온라인 동작에 관련하여 인터넷의 Post Office Protocol(POP)과 Internet Message Access Protocol(IMAP)을 조직적으로 비교하는 것이다.

원격지 메시지 저장소(예, mailbox)에 접근하기 위한 세가지 서로 다른 패러다임이 존재한다. 바로 오프라인, 온라인, 그리고 disconnected이다. "오프라인" 동작에서는 메일 클라이언트 프로그램(MAU,Mail User Agent)은 메일 서버로부터 메일 프로그램이 동작중인 컴퓨터로 메시지를 가져온 후 서버에서 메시지를 삭제한다. 온라인 동작에서는 메시지는 서버에 남겨져 있으면서 원격 클라이언트 프로그램에 의하여 처리된다. 그리고, disconnected 동작에서는 메일 클라이언트는 메일 서버에 연결하고, 선택된 메시지의 사본을 만들고, 서버와의 연결을 끊는다. 그리고, 이후에 메일 서버에 다시 접속하여 동기(헤더 비교)를 맞춘다. 온라인과 단절 접근 방식 모두는 메일이 서버에 남겨진다는 공통점이 있으나 서로 다른 시간, 서로 다른 컴퓨터를 사용하는 사람에게 이러한 방식 차이는 매우 크게 나타난다.

6-7 개의 클라이언트-서버 프로토콜에서 중에서 어떤 하나는 원격지의 메시지 저장소에 접근하기 위하여 사용될 수 있으며 NFS와 같은 다목적 파일 엑세스 프로토콜과 보통 사람들이 많이 동작시키는 벤더 제한적인 그들만의 다양한 프로토콜로 구성된다. 각 프로토콜은 서로 장단점을 가지지만 이들 모두에 대하여 이야기하는 것은 본 문서의 목적과는 다르기 때문에 여기서는 단지 IMAP(Internet Message Access Protocol)과 POP(Post Office Protocol)에 대하여서만 다루겠다. 당신이 오프라인 접근에만 관심있다면 IMAP을 살펴보는 것은 당신에게 영양과잉을 초래할 수도 있다.

본 문서의 테마는 (a)온라인과 disconnected 접근 메쏘드 지원은 메일 사용자가 증가되고 있는 상황에서 매우 필요한 것이며, (b) POP는 온라인과 disconnected 접근에는 적당하지 않다는 것과 IMAP이 세가지 접근 패러다임 모두를 훌륭히 지원한다는 것을 보여주는 것이다. 그렇다고 필자가 POP에 대하여 전적인 비난의 의도는 없으며 POP는 오프라인 메일 처리에 중점을 두고 디자인 되었으며 이러한 메일 처리 방식은 매우 만족할 만한 것이라고 생각한다. 다시 본 문서의 목적에 대하여 말하고자 한다면, 본 문서에서는 온라인과 disconnected 동작의 중요성에 대하여서 설명하고 있으며 왜 IMAP이 위에서 이야기한 세가지 패러다임에대한 좋은 해답인가에 대한 설명을 하고 있다.

여기에 POP에는 없고 IMAP에는 있는 온라인과 오프라인 접근을 위해서 필요한 몇 가지 기능을 나타냈다:

원격 폴더 처리:

• 원격 폴더에 메시지 덧붙임 기능
• 표준 또는 사용자 정의 메시지 상태 플래그 설정 기능
• 공유 폴더에서 동시적인 정보 갱신과 발견 정보 갱신 지원 기능
• 새 메일 알림

• INBOX 뿐만 아닌 다른 원격 폴더 처리 기능
• 원격 폴더 관리(리스트/생성/삭제/이름변경)
• 계층 구조의 폴더 지원
• 비 이메일 데이터 접근에 적합; 예, NetNews, 다큐먼트.

• 전체 메시지 다운로드 없이 메시지 구조 결정을 선행함
• 개별적인 MIME 바디 부분에 대한 선택적 취득
• 서버기반에서의 검색과 데이터 전송량을 최소화하기 위한 선택

최종적으로, IMAP은 협의-확장판을 위한 선행자가 있어서 새로운 요구가 발생되면 IMAP의 기능은 지속적으로 확장될 수 있다.

그러므로 우리의 결론은 a) 단지 offline 접근만을 제공하는 메시지 기술은 지금 요구되고 있는 그러한 요청에는 적합하지 않다; b) IMAP은 offline 동작 뿐만 아니라 보다 우수한 online과 disconnected 동작도 제공하고 있다; c) IMAP과 같이 특정-응용 프로토콜은 일반적 파일 시스템 프로토콜 보다 주요한 이점을 제공한다. 그리고, (d) IMAP은 POP를 포함하는 더 큰 집합이라는 점이며 실재 POP가 우월한 점이라고는 현재로서는 IMAP 보다 POP를 지원하는 소프트웨어가 더 많다는 것이다.

초창기 이메일 사용 행태는 메시지는 조직체 내의 단일 시분할 공유 컴퓨터로 저장되는 전형을 보이며, 모든 사용자는 그들의 메일을 읽기 위해서 그 컴퓨터로 로그인하여야만 하였다. 이러한 모델은 아직도 널리 사용되고 있지만, 이러한 방법은 큰 두 가지 제한요소를 가진다: 첫째, 사용자 수의 증가에 따른 확장성을 가지지 못한다. 둘째, Mac과 PC에서 사용하는 메시지 처리 응용프로그램을 사용하지 못한다. 먼저 언급한 것은 시스템 관리자의 입장에 따른 것이며 나중에 언급된 것은 시스템 유용성에 관한 직접적인 영항을 주제로 놓고 본 것이다. 여기서 공통적으로 위에서 언급된 주제는 개인 사용자의 프로그램 도구와 호환되면 또한 그렇게 보이는 그래픽 사용자 인터페이스(GUI)를 제공하는가와 메일 시스템과 데스크탑 또는 랩탑 컴퓨터와의 데이터 교환이 쉽도록 하는 편리성을 제공하는가에 따른것이다.

따라서, 개인 컴퓨터 사용 형태를 충족시키는 분산 메시지 처리 구조에 관심이 모아진다. 그러나, 먼저 그러한 구조를 지원하는 클라이언트-서버의 사양을 고려하기 전에, 한번은 이용되었을 클라이언트와 서버의 메시지를 처리하는 다른 여러 방법을 이해하는 것이 선결되어야 한다.

인터넷 문서 RFC-1733은 세가지 동작 모드(메시지 처리 패러다임)를 분산 메시지 시스템상에서 정의하고 있다.

• 오프라인
• 온라인
• Disconnected

오프라인 동작에서, 메시지는 일반적으로 공유 서버라 불리는 장소로 배달되며 워크스테이션 또는 개인용 컴퓨터 사용자는 일정 시간 간격을 두고 서버에 연결하여 지정된 메시지를 클라이언트 머신으로 모두 다운로드한다. 좀더 정확히 말하자면, 메일 클라이언트 프로그램(또는 MUA(Mail User Agent)), 서버로부터 클라이언트에서 메일 프로그램을 구동하여 메시지를 가져온 후 서버에 있는 메시지를 지운다. 즉, 모든 메시지 처리는 클라이언트 머신 내에서 이루어진다.

"온라인" 동작에서는 메시지는 서버에 남겨지며 메일 클라이언트 프로그램은 한번에 몇 번씩 그리고 몇 번의 시간을 통해서 메시지를 원격 조작한다.

Disconnected 동작에서, 메일 클라이언트는 메일 서버에 연결하고, 지정된 메시지의 캐시를 만들고 나서 서버와의 연결을 종료한다. 그런 얼마 후에 서버와 재 연결한 후 다시 동기를 맞춘다. 사용자는 "오프라인" 상태에서 캐시만을 가지고 작업할 수 있으나 이러한 모델은 원래의 "오프라인" 모델과는 서버에 primary 메시지 복사본을 남겨놓는다는 점에서 차이가 있으며 메일 클라이언트 프로그램이 후에 서버에 다시 연결하여 서버와 클라이언트 메시지 캐시와의 메시지 상태를 재동기하여 맞춘다는 점에서 차이가 있다. 온라인과 disconnected 동작은 서로 보완관계에 있으며 사용자는 그들을 선택적으로 번갈아가며 사용할 수 있다; 그렇지만, 어느 하나도 오프라인 동작과는 호환성이 없으며, 왜냐하면 오프라인 동작은 메시지가 클라이언트 머신의 하드디스크로 복사된 이후로 서버에서 그 메시지들이 지워지도록 정의 되었기 때문이다.

당신은 오프라인 동작이 저장-포워딩 서비스(store-and-forward service)라도 생각할 수 있으며 여기서 마직만 전송 단계는 최종 목적지 호스트 상에서 메일 프로그램을 통한 사용자로부터 유도된다. 오프라인 동작은 매개 서버(drop point)로부터 일단의 목적지 장치(일반적으로, PC 또는 Mac)로 (사용자의 요구가 있으면) 메시지를 이동하도록 설계되었다. 사용자 컴퓨터에의 성공적 전송 후에 메시지는 서버에서 삭제된다.

오프라인 모델은 사용자가 항상 하나의 컴퓨터로부터 그의 메일에 접근하고 그 컴퓨터에 만 그들의 메시지의 첫번째 복사본만이 있는것에 만족한다는 것을 나타낸다. 그렇지만 만일, 다른 시간 다른 컴퓨터에서 그들의 메시지 저장소에 접근할 필요가 있게 된다거나, 또는 그들이 직접적으로 작동하는 컴퓨터가 달라서 그들의 메일이 저장되는 머신을 다르게 하고 싶다면, 오프라인 모델은 이러한 경우에 좋은 해답을 줄 수 없을 것이다.

숫적인 증가를 보이는 이메일 사용자는 직장에서 그들의 컴퓨터를 가지고 있으며 집에서도 다른 컴퓨터를 가지고 있거나 또한 여행 중에 사용할 수 있는 랩톱 컴퓨터를 가질 수도 있다. 우리는 우리가 그러한 사용자이고 우리에게 그러한 기회가 주어진다면 온라인 접근과 단절(disconnected) 접근 패러다임을 선택하리라 보고 있으며, 단지 연결 시간과 그리고(또는) 서버 자원이 매우 월등하다면 오프라인 접근을 선택할 수도 있다고 생각한다. 어찌 되었든 온라인 접근은 오프라인보다 더 많은 연결 시간을 제공하며, disconnected 사용은 오프라인 접근과 거의 비슷한 연결시간을 요구한다.

노트: "메시지 저장소", "메일박스", 그리고 "폴더"는 본 문서에서는 의미의 구분 없이 서로 교환되어 사용되었으나 "메시지 폴더"는 하나 이상의 "메일박스"나 "메일 폴더"를 포함할 수도 있다.

대부분의 사람들은 개인용 컴퓨터로 직접 배달되는 메시지를 받을 수 없으며 대신 항상 작동 중인(저자 : "always up") 메일 서버에 의존하여 메일을 수신한다. 보통 이러한 서버는 그 조직체의 다른 사람들과 공유되어 있다. 메일은 어떤 컴퓨토로 배달될 되지만 다른 컴퓨터에서 읽혀지는 경우에 있어서 네트워크 포로토콜이 서버의 메시지에 접근할 필요가 있다. 정책 결정은 이용자의 메시지가 계속적으로 남아 있는 장소(예를 들면, 개인, 워크 그룹, 부문 서버 또는 중앙 서버)에 의하여 이루어지며 다음의 질문 내용을 수반한다. 먼저 어느 프로토콜이 다른 컴퓨터를 사용할 때 메시지 데이터에 접근하는데 사용되어져야 하는가? 이러한 질문은 수신 메시지 폴더(예, 메인 INBOX)와 사용자의 저장-메시지 폴더(saved-message folders) 모두에 적용된다. 수신 메시지 폴더를 읽을 경우 일반적인 동작은 아카이브(archive) 폴더에 메시지를 저장하는 것인데 이러한 경우에 있어서 둘 모두의 데이터 셋(set)은 동시에 유용함을 보여야 한다. 메시지의 두 계층에 접근하는데 사용되는 프로토콜이 꼭 같아야만 하지는 않지만 대부분의 경우에 있어서는 같도록 하는 것이 좋다.

프로토콜 선택 시 고려사항:

• 일반적인 원격 파일 시스템 접근 프로토콜(예, NFS, SMB)
• 특정-응용 메시지 접근 프로토콜(예, POP, IMAP)

모든 형태의 컴퓨터에서 사용 가능한 단일 범용 파일 시스템 프로토콜은 존재하지 않는다.

파일 시스템 프로토콜은 운영체제에 매우 직접적으로 연관되어 있으며 프로토콜 인스톨이 항상 가능한 것이 아니다.

대부분의 파일 시스템 프로토콜은 새로운 라인을 언급하거나 운영체제들 간에 있는 일반적인 차이점을 기록하는 것이 쉽지 않다. 왜냐하면, 서버의 파일 시스템은 일반적으로 정형화되어있지 않기 때문이며 파일 변환 시 일반적 파일 접근 프로토콜에 전적으로 의존하여 파일 변환을 진행하는 것은 불가능하다. 그러므로, 메일 클라이언트 프로그램은 서버의 특수한 저장 형태를 인식하고 여기에 종속된다.

파일 고정과 보안 문제는 어떤 특정한 파일 시스템에서 문제를 일으킬 수 있다는 점이 판명되었다.

파일 시스템 프로토콜에 대한 의존성은 네트워크 대역폭의 부족을 가져온다. 언제 이러한 현상이 발생되냐 하면 ,특별한 문자열의 존재 여부를 결정하기 위하여 모든 네트웍상의 모든 파일이 전송될 경우에서 발생된다.

반대로, 특정-응용 프로토콜은 다음이 가능하다:

• 특수 응용처에서 최대 성능을 내도록 조정.
• 네트웍간에 전송되는 데이터량을 줄이기 위한 클라이언트와 서버간의 논리적인 프로세싱 조각을 허용
• 특별한 권한을 가지지 않고 종종 인스톨 됨
• 서버에서 이용되는 파일 포맷으로부터 클라이언트 프로그램을 분리

• 선호/특정-벤더 솔루션,
• X.400 P7 메시지 접근 프로토콜,
• 셋 중 하나인 메시지 접근 프로토콜.

또한, 다음의 이유로 인하여 X.400에의 접근도 거부된다: 첫째, P7 프로토콜은 매우 심각한 기술적 결함을 가지고 있으며 게다가 P7은 인터넷 메시지 처리 기술이라기 보다는 X.400 메시지 헤더와 전송 기술로 보이기 때문이다. X.400 기술은 일반인과 인터넷에 게이트웨이와 일련의 X.400 O/R 주소를 다루는 시스템 관리자들을 어렵게 만든다. – 위 두 난점은 어떠한 경우에라도 없어져야 한다고 생각한다. (인터넷과 X.400 메시지 처리 기술의 비교는 본 문서의 한계를 벗어나 있지만, 이용자가 인터넷 프로토콜로서 큰 규모의 목적에 민감한 메시지를 처리하는 것은 명확히 틀린 것이라는 것은 종종 듣는 클레임에 걸리는 말이라 할 수 있다.)

위의 사실들은 인터넷 기반의 메시지 처리 프로토콜인 POP, DMSP와 IMAP을 우리에게 남겨준다.

셋 중에 가장 오래되고 가장 널리 알려진 프로토콜은 POP(Post Office Protoco)이며 RFC-918에 1984년 10월에 정의되었다. 다른 패러다임과 마찬가지로 POP도 초기 바디 구축 후 여러 번의 갱신 과정을 거치었다. 여기서 기술된 POP3는 RFC-1725에 근간을 둔 버전이며 인터넷 흐름에 따른 최신의 POP3도 존재한다. 최근에 덧붙여진 것들로는 향상된 인증 기법과 유일 메시지 인증자가 있으며 이 모두는 IMAP 버전 4.0에서 작동되던 것을 따온 것이다. POP는 오프라인 접근 패러다임을 지원하도록 특별히 설계되었다; 그렇지만, 매우 심각한 한계를 가지고 있는데 그것은 다른 두 패러다임에 적용되어 왔다.

분산 메일 시스템 프로토콜(DMSP, Distributed Mail system Protocol)은 1986년 3월 RFC-984에서 정의되었다. POP와는 다르게 DMSP는 그리 널리 사용되지 않으며 PCMAIL과 같이 단일 응용 목적으로만 제한된다. DMSP는 PCMAIL에서 단절(disconnected) 동작을 원활히 지원하기 위하여 특별히 설계되었으며 또한 그렇게만 알려졌다.

인터넷 메시지 접근 프로토콜(IMAP, Internet Message Access Protocol)은 스탠포트 대학에서 1986년에 만들어졌지만 1988년 7월에 와서야 RFC-1064에 문서화되었다. IMAP 역시 만들어진 후에 많은 갱신을 가졌으며 현재의 버전은 RFC-1733에 정의된 IMAP4이다. IMAP은 온라인 접근 모델을 지원하기 위한 목적으로 만들어졌다; 사실, 초기에 "IMAP"은 "Interactive Mail Access Protocol"을 나타낸 것이었지만 그 이름은 IMAP의 현재 가지고 있는 기능을 충분히 나타내기 위하여 1993년 IETF 표준화 노력의 결과로서 바뀌게 되었다. IMAP은 – 문법적인 말은 아직까지는 아니지만 – POP 능력의 기능적 수퍼셋이기 때문에 POP이 오프라인 접근을 충분히 지원하는 것처럼 IMAP도 지원하며 IMAP4에서도 disconnected 동작을 지원한다. 고로, IMAP은 POP와 DMSP의 기능을 내재한 프로토콜이다.

온라인 메시지 접근 프로토콜은 마치 로칼에 있는 것처럼 원격지에 있는 메시지 저장소를 다루는 능력을 가지고 당연히 가지고 있어야 한다. 앞에서도 언급되었든 이유로 볼 때, 완전한 솔루션은 일반 파일 시스템 프로토콜에 의존하지 않고 구축되어져야 한다. 그렇다면 만일 이용자가 고 품질의 클라이언트-서버 메시지 처리 시스템을 지원하는 프로토콜(또는, 프로토콜 패밀리)을 설계하려 한다면 어떤한 기능이 필요로 될까? 아마도 이것은 아래의 기능을 제공하여야 한다:

• 오프라인, 온라인, 그리고 disconnected 동작.
• 원격 파일 프로토콜에 의존하지 않는 유동적(데이터 없는) 클라이언트
• 메시지의 전송, 수신, 그리고 저장
• 원격 폴더 관리
• 메시지별 상태 정보의 수신 및 갱신
• 개인 설정 정보의 수신 및 갱신
• 공유 메일 박스(다중 사용자) 지원.
• 온라인 성능 최적화.
• 어떠한 메일 게이트웨이를 가지는 것을 피하는데 적합한 인터넷 표준과의 완벽한 호환성.

Disconnected 동작은 온라인 동작과 비슷한 요구사항을 가지며 거기에 추가하여 폴더의 존재 시간 동안 계속해서 메시지가 특정한 폴더에서 유일하게 구별되어져야 함을 요구한다. 이것은 클라이언트와 서버가 주기적으로 특정 메시지의 상태에 재 동기하기 때문이다.

위 프로토콜들은 서로 호환성을 가지지 아니하고 몇몇 중대한 방법상의 차이점이 존재하지만 거기에는 다음과 같은 공통된 성질을 포함하고 있다:

• 메일 접근만을 다룬다; 메일 전송은 SMTP에 의존한다.
• 매일의 배달은 보통 공유 서버라 불리는 "always up" 메일 서버로 배달된다.
• 다양한 종류의 클라이언트 플랫폼 형태로부터 새로운 메일에 접근을 허용한다.
• 네트웍상의 어느 장소에서도 새로운 메일에 대한 접근을 허용한다.
• 오프라인(다운로드 후 삭제) 접근 모델을 완벽히 지원한다.
• Disconnected 사용을 위한 계속적인 메시지 식별자를 지원한다.
• 소스파일까지 포함하여 자유롭게 실장하는 것이 가능하다.
• PC, Mac, 그리고 유닉스 머신을 위한 클라이언트 프로그램이 존재한다.
• 상업적 실장이 가능하다.
• RFC 문서에 의하여 정의된 공개 프로토콜이다.
• 어떠한 게이트웨이도 필요없는 순수 인터넷 프로토콜이다.

POP 기반의 메일러를 사용하는 사용자와 벤더는 오프라인 접근 패러다임의 한계점에 맏닦트리기 때문에 온라인과 disconnected 모드 모두에서 POP를 이용하기 위한 시도에 관심이 기울여져 왔다. 일반적으로 이것은 POP 메일러가 클라이언트 머신으로 메시지를 복사한 후에 그것을 지우는 대신 "서버에 메일을 남겨두도록" 설정되었다. 그러나, POP는 고품질의 온라인 또는 disconnected 클라이언트를 위해서 매우 필수적인 몇가지 기능들을 제공하지 못한다. 이러한 기능은 다음의 세가지 범주로 나뉜다:

• 원격 폴더 조작
• 다중 폴더 지원
• 온라인 성능 최적화

온라인 모드에서 POP의 제한점에 대한 예로서 메시지 별로 상태 정보를 갱신하는 것(예, Answered라고 표시)이 있다. 클라이언트 메일 프로그램은 이러한 중요 기능을 생략하며 또한 POP 밖에서 이러한 것들은 이루어진다. 왜냐하면 POP는 이러한 기능에 대한 원초적 해결방법을 제공하지 못하기 때문이다. 사실, 개별 메시지 상태 정보는 정형적으로 메시지 자체로부터 분리되어 저장되어야 되며 POP 클라이언트가 이 데이터를 갱신하기 위하여서는 마치 로컬에 파일이 있는 것처럼 접근하기 때문이다.

다른 예로서 개인 아카이브 폴더에 메시지를 저장하는 것이 있다. 아카이브 폴더에 저장하는 것은 항상 로컬 폴더에 저장하는 것처럼 보이지만 사실 클라이언트-서버 메시지 처리의 주요 가정은 서로 다른 시간상에서 서로 다른 클라이언트를 사용할 필요가 있다는 점이다. 즉, 메시지 저장 아카이브는 하나 이상의 컴퓨터보다 많은 로컬에 있을 수 없다.

그렇지만, POP가 의사 온라인 모드에서 사용될 때 그러한 온라인 메시지 처리동작은 실제로 원격 파일 시스템 프로토콜을 경유하여 "로컬" 아카이브 폴더로 보이는 곳에서 수행되는 것처럼 보이게하여 의사 온라인 모드에서 동작중인 것을 은폐한다. 이용자는 만일에 일반적인 매우 유용성 있는 원격 파일 접근 프로토콜을 소유하여 이것에 의존할 수 있다면 이용자는 더 이상 POP가 필요없을 수 도 있다.

POP는 온라인 메시지 처리 프로토콜로 설계되지 않았기 때문에 온라인 영역에서 보이는 심각한 기능 저하에 그리 놀랄 필요는 없다. Disconnected 동작에 필요한 사항으로는 온라인 접근의 기능적 요구에 대한 엄밀한 수퍼셋이 있다. 또한 POP는 최신의 POP 명세서에는 보이는 고유한 그리고 disconnected 동작에 필요 불가결한 도구인 지속적 메시지 식별자를 포함한다 할지라도 disconnected 메시지 프로토콜에 비하여는 기능면에서 매우 부족한 점이 많다.

온라인/disconnected 동작에서 기능면에서 보았을 때 POP는 약하게보이나 IMAP은 근본적으로 온라인 접근을 목적으로 설계 되었기 때문에 매우 강함을 보인다. POP에 대한 IMAP의 세세한 이점은 다음과 같다:

원격 폴더 조작:

• 원격 폴더에 메시지 지정 기능
• 규격화된 메시지 상태 상태 플래그와 사용자 정의 메시지 상태 플래그 기능
• 공유 폴더에서 동시적 갱신과 발견에 대한 갱신 기능
• 새 메일 표시

• INBOX 외의 원격 폴더 조작기능
• 원격 폴더 관리(리스트/생성/삭제/이름변경)
• 계층적 폴더 구조 지원
• 비 이메일 데이터 접근에 적합; 예, NetNews, 문서

• 전체 메시지의 다운로드 없이 메시지 구조를 파악하여 제공
• 개별적인 MIME 바디 부분을 선택적으로 가져옴
• 서버에 기반을 둔 검색 기능과 데이터 전송량을 줄이는 선택 기능
• 게다가 IMAP은 확장의 여지를 제공하고 있어서 그 기능은 계속적으로 성장할 수 있다.

"원격 폴더에 메시지를 지정하는 기능"이라 함은 당신이 하나의 아카이브 폴더에 메시지를 저장할 수 있다는 것을 의미하며 심지어 당신의 INBOX에 아카이브 폴더로부터 메시지를 되돌려 놓는 것을 의미한다. 메시지 저장은 메시지 관리면에서 의미가 깊다.

"규격화된 또는 사용자 정의 메시지 상태 플래크를 설정"하는 기능이 의미하는 것은 메일 프로그램이 특정한 메시지에 대한 상태 정보를 기록 할 수 있다는 것이다; 예를 들면, 그것이 응답되었거나, 또는 사용자로부터 중요하다고 지정되었거나, 또는 삭제 된 표시를 가지고 있다는 사실을 말한다. IMAP은 표준 플래그의 작은 묶음도 허락하며 게다가 사용자 정의 상태 플래그도 허락한다.

"공유 폴더에서 동시적 갱신과 발견에 대한 갱신을 지원"한다는 것은 여러 사람이 같은 메일 박스에 도착하는 메시지를 다루는 상황에서 매우 중요하다. 예를 들면, 헬프 데스크는 단일 메일 박스로 여러 사람들의 처리 요구를 담당한다. 이러한 요구는 메시지 접근 프로토콜과 메일 박스의 형태 모두를 나타낸다. 특히, 메일 박스 형태는 서로 다른 세션으로부터 발생되는 현재의 상태 플래그 갱신을 허락하여야 하며 메시지 접근 프로토콜은 상태 플래그가 변경되었을 때 각 사용자의 세션에 이를 표시하는 기능을 제공하여야 한다. IMAP은 서버로부터 받는 응답이 이용자 자신의 클라이언트로부터 발생된 요청의 직접적인 결과가 아닐 수 도 있다라는 점에서 다른 많은 클라이언트-서버 프로토콜과는 구분된다; 서버는 메일 박스의 상태가 변경되었다라는 것을 알리는 요청되지 않은 데이터를 클라이언트로 보낼 수 있어야만 한다. 실제로 공유 폴더 지원은 프로토콜이 다중 폴더에 접근하는 것을 허가한다는 것에 주목하자.

메일 박스의 상태 변화에 대한 다른 예는 "새 메일 알림(new mail notification)"이다. IMAP에서 클라이언트 프로그램이 메일 박스상에서 어떠한 동작을 수행할 때, 서버는 자동적으로 마지막 알림 이후로 도달된 새로운 메일에 대한 알림을 응답 속에 포함한다.

다중 폴더 지원을 실장…

온라인과 disconnected 동작의 중요 목적은 서로 다른 시간 서로 다른 컴퓨터로부터의 메시지 접근을 지원하는데 있다. 이것은 개인에게 할달 된 로칼 저장 매체를 가지지 않는 실험실 컴퓨터에 의지하여야만 하는 교환 학생 뿐만 아니라 회사와 가정에서 서로 다른 컴퓨터를 사용하는 정신 노동자도 포함된다.

그러므로, "INBOX 외의 원격 폴더 처리" 기능은 온라인 및 disconnected 동작의 기반이된다. 이것은 이용자의 폴더로부터 다른 폴더로 메시지를 저장할 수 있는 것이며, 일련의 저장 메시지에 접근할 수 있다는 것이며, 다중 도착 메시지 폴더를 허락한다는 것을 의미한다. "다중 도착메시지 폴더"에의 접근은 전송 필터를 이용하거나 또는 다른 목적으로 만들어진 서로 다른 계정을 가짐으로써 도달하는 메일 스트림을 구분 지어왔던 사람들에게 유용하다. 이용자의 INBOX를 위한 온라인 도는 disconnected 접근 모델을 논의하는 것과 같은 동일 프로토콜 이슈는 다른 메시지 폴더가 "incoming" 또는 "archive"가 되도록 적용된다.

"원격 폴더 관리(리스트/생성/삭제/이름변경)"는 하나 이상의 폴더에 접근하고 조작할 필요성 때문에 나타났다. 또한 IMAP version 4에서는 폴더 셋(set) 생성을 허락하는 "계층 구조의 폴더를 지원"한다. 클라이언트 메일 프로그램이 폴더 이름과 디렉토리 이름을 구분할 수 있는 능력이 있기 때문에 이것은 프로토콜 결과로서 보여지는 것이다.

IMAP의 추가적 이점은 "비 이메일 데이터에 접근하기에 적합"; 예, NetNews, 문서. 이러한 기능은 서로 다른 정보 체계를 통합하려는 요구가 있는 경우에 효과적이다.

이용자는 IMAP 클라이언트 도구와 시스템 관리자가 요구하는 메일 아키텍쳐에 의존함에도 불구하고 이용자는 메시지를 클라이언트 컴퓨터 내에 저장할 수도 서버에 저장할 수도 있으며 , 또한 둘 다 선택할 수도 있다.

온라인 성능 최적화 연결

메일 클라이언트가 메일 서버에 연결될 때마다, 온라인 모드에서나 또는 disconnected 모드에서 캐시 재동기를 진행하는 과정에서는 네트워크 성능 저하에 대한 이슈가 존재한다 – 이것은 클라이언트와 서버간의 연결 속도가 매우 낮을 때 강하게 나타난다. IMAP은 클라이언트와 서버간의 전송되는 데이터량을 거짓말처럼 상당히 많이 줄이는데 사용될 수 있는 몇 가지 기능을 제공한다.

첫째, "전체 메시지의 다운로드 없이 메시지 구조를 결정할 수 있는 도구 제공"이다. 이것은 메시지의 전송 없이 메일 클라이언트가 MIME 메시지 덧붙임 파일에 대한 정보를 표시하게끔 허락한다.

게다가, "개별 MIME 바디 부분에 대한 선택적 가져오기"는 다음을 의미한다. 만일 어떤 사람이 당신에게 10MB 짜리 비디오 파일을 단지 두 줄의 텍스트 메시지와 같이 전송하였다면 당신의 메일 클라이언트가 당신이 특별히 덧붙인 파일을 요청하지 않는 이상은 단지 텍스트로된 두 줄짜리 메시지만을 선택하여 전송할 수 있다는 것이다. 만일 호텔에서 다이얼업 모뎀으로 연결되어 있는 경우에는 이것은 매우 커다란 이점으로 작용할 것이다. MIME 메시지의 효율적인 처리는 POP에 대한 IMAP의 주요한 이점이다. (MIME은 Multipurpose Internet Mail Extensions의 머리글자에서 따왔다. 인터넷 메일 메시지와 호환되는 RFC-822과 SMTP에 덧붙여진 임의의 인코딩된 파일에 대해서 기술적 우수성을 가진다.) 같은 줄기로서 볼 때, IMAP4도 또한 특정 메시지 헤더의 선택적 해석 기능을 제공한다.

결론적으로, "서버 기반의 검색과 데이터 전송량을 줄이기 위한 선택"을 이용하기 위한 IMAP 소프트웨어의 능력은 평가절하되어서는 안되다는 것이다. 이것은 일반 목적의 파일 접근 프로토콜(또는 의사 온라인 모드에서의 POP)과 비교하여서 특정-응용 메시지 처리 프로토콜이 가지는 주요한 이점이다. 클라이언트-서버 프로토콜은 서버가 검색하도록 요청하는 방아쇠 역할을 가지지 못하였을 때 검색은 전 네트웍에 걸쳐 클라이언트로 모든 데이터가 전송되도록 함을 의미한다. 서버로 하여금 서버의 로컬 파일을 검색하여 적합한 메시지를 찾도록 요청하는 것은 매우 커다란 IMAP의 이점이다.

IMAP은 POP와 비교하여 볼 때 다음의 두 가지 약점을 가진다:

• 프로토콜이 조금 더 복잡하여 인스톨 하기가 조금 더 수고스럽다.
• POP 소프트웨어에 비하여 유용한 IMAP 소프트웨어는 그리 많지 않다.

아직까지는 POP가 IMAP 보다 더 많은 지원을 받고 있지만 거기에는 이미 IMAP 소프트웨어 (참조섹션 보시오) 에서 사용되는 기초 목록이 적용되고 있으며 많은 POP 소프트웨어 벤더는 가능하면 빨리 IMAP을 지원하는 작업을 진행하고 있다. 현재 20개의 서로 다른 IMAP 클라이언트가 유용한 상태이며 최소한 일곱 개 이상이 개발 중에 있다.

IMAP이 중앙 컴퓨팅을 채택하고 있다고 생각하는 일반적인 오해가 있다. 보통 이러한 것은 현재 얼마나 많은 개인용 컴퓨터의 성능이 향상이 있으며 중앙 컴퓨팅이 현재는 주제에서 벗어나 있다는 것으로 이야기된다. 이용자의 중앙 컴퓨팅 주제에 대한 선호도 밑 믿음에 관계없이 그러한 주제는 IMAP과 아무런 관련이 없다. 사실, IMAP은 개인, 워크그룹, 부서, 또는 엔터프라이즈-와이드 서버로서 사용된다. 여기서 정책결정은 이용자의 메시지 데이터가 남겨지는 장소에서 결정되며 관계된 질문은 다음과 같다: 다른 컴퓨터로부터 메시지에 접근하는데 사용되어질 프로토콜을 어떠한 것으로 정하나? 그리고 대부분의 가족은 다른 컴퓨터가 있다: 컴퓨터 사용자를 관리하는 것은 모든 상황에서 하나의 컴퓨터만을 사용하는 일상에 걸쳐 존재한다.

POP는 부족하고 IMAP은 그리 가치가 높지 않다는 말이 들린다. 왜냐하면, IMAP은 메시지 대상에 대하여 원격 접근만을 언급하고 있기 때문이며 이용자가 원격 접근을 원하게 될지도 모르는 다른 계층의 데이터가 존재하기 때문이다. IMAP이 모든 원격 데이터 접근을 위한 해결사가 되지 못한다는 것은 사실이지만 다른 면에서 볼 때는 단일 일반적 목적 원격 파일 접근 프토콜로 세상의 관심이 모인다는 어떠한 증거도 없다. Sun의 NFS, Transarc의 AFS, OSF의 DFS, Apple의 AFT, 마이크로소프트의 SMB, 그리고 Novell의 NCP가 현재로서 그기고 앞으로도 범용 플랫폼 독립적인 원격 파일 접근 프로토콜이 되기는 어렵게 보인다. 단일 프로토콜이 이러한 요구에 부합된다 할지라도 거기에는 아직도 응용-명세 프로토콜을 고려하는 성능상의 이유가 존재한다. 또한, 리얼타임 메시지 처리 환경 하에서 그러한 파일/대상 고정 문제는 특정-응용 프로토콜상에서 문제를 해결하는 것이 때때로 쉽다. IMAP은 모든 일을 처리하지 못하기 때문에 POP로 충분하다"라는 논제의 아이러니는 만일 이용자가 널리 퍼진 원격 파일 접근 프로토콜의 존재를 가정한다면 POP는 더 이상 필요 없게 된다는 말이다.

변화된 같은 주제는 거의 모든 사람은 그들과 관련된 개인 파일을 이동한다는 가정이며 그래서 단일 메일 떨굼 외의 다른 원격 접근은 그리 필요하지 않다는 것이다. 당신의 중요한 데이타의 캐시 복사본을 이동하는 것이 매우 유용하다 할 지라도 이용자는 얼마나 많은 사람들이 그 사람들 상에서 데이터 모음이 *primary* 복사본이 되는지 궁금해한다. 이용자가 키를 잃어버릴 때와 동시에 이용자의 이메일을 잃는다는 생각은 잘못된 생각이다. 왜냐하면, 제작자가 그러한 의도를 가지지 않았으며 그러한 질문이 의미를 가질 때는 저장 기술의 발전이 없었던 약간은 과거의 일이다. 게다가, 무선 기술이 연결성을 보장하며 개인에게 할당된 저장 매체에 대한 요구를 막아준다고 생각하기 쉽다. 여기서 개인에게 할당된 저장 매체에 대한 요구를 막는다는 것은 저속 연결 하에서 주요한 응용 처리를 위한 기능을 수행하는 원격 접근 프로토콜이 필수적이 될 수 있다는 것이다.

어떤 이들은 어떠한 메일 응용 프로토콜도 계속해서 증가되는 메일 클라이언트 프로그램의 복잡성으로부터 야기된 증가된 요구를 만족시킬 수 없다는 것을 알게 되었다. 그들은 메일 서버에서 실행되어지는 프로그램을 작성하는 그런 언어를 정의하기 위하여 논의하고 있으며 그러한 논의는 클라이언트의 요구를 변경하기 위한 충분한 일반성을 제공하는 방법을 찾는데 급급하다. 다시 말하자면, IMAP이 가지는 것과 비슷한 협의된 확장기능을 가지는 형태와 마찬가지로 고정 프로토콜은 곧 고전이 될 것이다라는 말이다. 반대되는 논의는 선택 가능한 언어로서 표현 가능한 어떠한 프로그램을 실행시키기 위하여 서버를 개방한다는 것은 시스템 관리자에게는 악몽으로 다가온다는 것이다. 왜냐하면, 온건한 응답 시간을 유지하는 것과 성장을 위하여 계획하는 것을 더욱 어렵게 만들기 때문이다. 또한, 양 단이 개방된 매크로 기능은 구조적 충돌을 야기할 수 있다. 다운로드 코드를 허용하는 프로토콜을 이용자가 가진다 할 지라도 이용자는 서버상에서의 유용한 선행조건과 프로토콜이 제시하는 모델에 의하여 제한된다. 예를 들면, 만일 프로토콜이 메시지 텍스트를 수정토록 허용한다면 클라이언트는 메시지 텍스트를 온당히 캐시에 저장 할 수 없다. 다른 말로 말하자면, 프로토콜 일반성은 때때로 과잉 적용되며, 프로토콜상에서 특정-응용 기능의 상대적 고착 분야를 가지는 것은 종종 매우 불행한 제한점을 가진 것처럼 보인다.

지금은 World Wide Web의 출현에 관심이 집중되어 있으며 그것과 관련된 HTTP(Hyper Text Transfer Protcol)라는 것에도 관심이 집중되어있다. HTTP가 IMAP을 관심 없게 만들까? 위 둘 모두 상호 협동 관계로서 살아 남으리라 생각한다. Web 설계자는 현명하게도 현재의 기술과 그들을 결합하여 URL 문법으로 이용키로 결정하였으며 외부 표현 도구과 접근 방법을 위해서 날카로운 도구를 제공하기로 결정하였다. IMAP과 HTTP는 동시에 공존할 수 있으며 그러한 주제에서 상호 보조적 관계를 가질 수 있다. 일반 WWW 브라우저가 HTTP 만을 통하여 이메일에 접근하는 것을 허용하는 매우 관심있는 작업이 수행되어 왔지만 IMAP의 특정-응용 선행자는 아직도 중요한 성능을 보이고 순수 HTTP 접근에 비하여 나은 기능적 이점을 나타내고 있다.

결론적으로, 이용자는 다음과 같은 질문을 할 수 있다: POP와 IMAP을 동시에 사용하면 안되는가? 사실, 이러한 전략은 초기 메일 사용자 에이전트와의 호환성을 유지하기 위한 IMAP의 이점을 제공하기 위하여 많은 사이트에서 성공적으로 채택되어왔다. 거기에는 메일 서버상에서 동시에 두 프로토콜을 제공하는 것에 대한 특별한 기술적 제한은 두 데몬이 같은 메일 박스 포맷과 같은 파일 고정 원칙을 이용하는 경우에 있어서 그러한 기술 제한은 없다. 그러나, 거기에는 단지 하나의 프로토콜을 지원하기 위한 비 기술적 이유가 있다: IMAP을 지원하거나 또는 POP을 지원하거나 하는 몇 개의 사용자 메일 에이전트가 있으나 동시에 지원하는 프로토콜은 존재하지 않는다; 그러므로, 만일 두 서비스가 동시에 유용하다면 클라이언트 서비스의 스태프는 분산(diversity) 충격을 감내하여야만 한다. 자원을 지원하는 것이 매우 엷게 퍼져있는 상태에서 그들 전체를 평균적으로 제공하기 보다는 메일러의 집단중에서 하나를 선태하는 것이 필요할 것이다.

본 문서의 키 포인트는 다음과 같다:

• "오프라인" 메시지 접근 패러다임은 현재의 요구에 부족하다; "온라인"과 "disconnected" 접근 지원은 필수적이다
• POP와 비교하여 볼 때, IMAP은 동등한 "오프라인"을 지원하며 게다가 월등한 수준의 "온라인"과 "disconnected" 동작을 지원한다.

IMAP은 그러한 특정-응용 프로토콜이다; 클라이언트-서버 메시지 처리 프로토콜은 마치 원격 메일 박스가 로컬에 있는 것처럼 조작하는 것을 허용토록 설계되었다. 오프라인 접근 패러다임을 충분히 지원하는 것에 덧붙여서 IMAP은 합당한 온라인 메시지 접근을 위하여 필요한 기능을 제공하여 준다. 이러한 기능은 POP 메일러가 메시지 아카이브와 메시지 상태 정보에 위치 독립적으로 접근할 수 있는 일반 파일 시스템 프로토콜을 사용하지 않는 이상 위에서 말한 기능을 수행할 수는 없다.

당연한 결론은 다음과 같다. IMAP에 대한 POP가 가지는 단 하나의 이점은 보다 많은 유용한 POP 소프트웨어가 있다는 점이다. 그러나, 이러한 현상은 매우 급격히 변화되고 있으며 IMAP의 POP에 대한 기능적 이점이 이런 것을 보상하고도 남는다.

본 문서가 기초가 된 초기의 문서인 "Comparing Two Approaches to Remote Mailbox Acccess: IMAP vs. POP"는 다음의 URL에서 찾을 수 있다:

http://www.imap.org/imap.vs.pop.brief.html

RFC-1730에 정의된 IMAP version 4. 다음의 URL에 RFC 문서가 있다:

ftp://ftp.internic.net/rfc/rfc1730.txt

IMAP에 대한 추가적인 정보를 가지는 URL은 다음에 있다:

http://www.imap.org/imap.docs.html http://www.imap.org/products.html

다음의 URL에 있는 디렉토리에 있는 유용한 것들:

ftp://ftp.cac.washington.edu/mail/

위 링크에 있는 많은 조각들은 IMAP 서버와 일반 POP 서비스를 추가로 제공하며 IMAP 서버에 명령을 전달 하여 현재의 POP 클라이언트가 IMAP 서버에 접근할 수 있도록 허가하는 POP 서버로 이루어져 있다.

IETF에 의하여 고려되고 있는 POP 명세에 대한 약간의 변형이 존재하나, 본 문서의 작성 시점에서는 이러한 것은 고려 되지 않았다. 최신의 non-draft POP 버전 명세는 RFC-1725에 정의되어 있으며 ftp://ftp.internic.net/rfc/rfc1725.txt에 나타나 있다.