인터넷 메시지 접속 프로토콜

1. 개요

인터넷 메시지 접속 프로토콜(IMAP)은 원격 메일함에 접근하기 위한 프로토콜로, 1986년 마크 크리스핀에 의해 설계되었다. POP 프로토콜과는 달리, IMAP은 메일함의 내용을 서버에 유지하며, 여러 장치에서 이메일에 접근하고 관리할 수 있도록 설계되었다. IMAP은 IMAP2, IMAP3, IMAP2bis, IMAP4 등 여러 버전을 거쳐 발전했으며, 현재는 IMAP4rev1이 널리 사용된다. IMAP은 보안을 위해 SSL/TLS를 사용하여 암호화된 연결을 지원하며, 다양한 이메일 클라이언트, 서버, 웹메일 서비스에서 활용된다.

2. 역사

IMAP은 1986년 마크 크리스핀에 의해 원격 접근 메일함 프로토콜로 설계되었다. 이는 메일함 내용을 검색하는 프로토콜인 POP와 대조적이다. POP는 사용자가 이용 중인 서버에서 클라이언트로 이메일을 다운로드하고, 다운로드가 끝난 이메일은 서버에서 삭제하는 것을 표준적인 이용 형태로 한다. 반면 IMAP은 이메일을 이메일 서버에 저장한 채로 관리한다 이러한 특성으로 인해 웹메일이나 여러 대의 컴퓨터에서 동일한 계정의 이메일을 읽는 경우, 이메일의 읽지 않음 상태 등의 속성이나 이메일 폴더의 구성 등을 일원적으로 관리할 수 있는 장점이 있다.

현재 버전 4rev2(IMAP4)가 되기까지 여러 번의 반복 과정을 거쳤다. 초기 IMAP, IMAP2, IMAP3, IMAP2bis 등이 만들어졌고, 현재 IMAP이라고 할 때는 IMAP4를 가리키는 것이 일반적이다. 프로토콜의 사양이 복잡했기 때문에 널리 보급되지 않았지만, 넷스케이프나 인터넷 익스플로러에 기본적으로 포함된 이메일 소프트웨어가 IMAP4를 지원하고, 상호 접속 시험이나 프로토콜의 다양한 개정 및 확장에 의해 상호 운용성이 높아졌기 때문에 이용자가 늘어났다.

2.1. 초기 IMAP

최초의 임시 메일 접근 프로토콜은 제록스(Xerox) 리스프 머신 클라이언트와 TOPS-20 서버에서 구현되었다.

최초의 임시 프로토콜 규격이나 소프트웨어 사본은 현재 남아있지 않다. 일부 명령어와 응답은 IMAP2와 유사했지만, 임시 프로토콜은 명령어/응답 태깅이 없어서 다른 모든 버전의 IMAP과 문법적으로 호환되지 않았다.

2.2. IMAP2

임시 프로토콜은 1988년에 정의되고, 나중에 1990년에 업데이트된 대화형 메일 접근 프로토콜(IMAP2)로 빠르게 대체되었다. IMAP2는 명령/응답 태깅을 도입했으며, 처음으로 공개 배포된 버전이었다.

2.3. IMAP3

IMAP3는 매우 드문 IMAP 변종이다. 1991년 로 발표되었다. 이는 IMAP2에 대한 수정 사항을 제안한 에 대한 대안으로 특별히 작성되었다. IMAP3는 시장에서 결코 받아들여지지 않았다. IESG는 1993년 RFC1203 "대화형 메일 접근 프로토콜 – 버전 3"을 역사적인 프로토콜로 재분류했다. IMAP 작업 그룹은 RFC 1203(IMAP3)이 아닌 RFC 1176(IMAP2)을 시작점으로 사용했다.

2.4. IMAP2bis

MIME의 등장과 함께 IMAP2는 MIME 본문 구조를 지원하고 IMAP2에 없던 사서함 관리 기능(생성, 삭제, 이름 변경, 메시지 업로드)을 추가하도록 확장되었다. 이 실험적인 개정판은 IMAP2bis라고 불렸으며, 그 사양은 초안이 아닌 형태로 발표된 적이 없다. IMAP2bis의 인터넷 초안은 1993년 10월 IETF IMAP 작업 그룹에 의해 발표되었다. 이 초안은 미발표 IMAP2bis.TXT 문서, , 그리고 (IMAP2)와 같은 이전 사양을 기반으로 했다. IMAP2bis.TXT 초안은 1992년 12월 기준으로 IMAP2에 대한 확장의 상태를 문서화했다. 초기 버전의 파인은 IMAP2bis 지원과 함께 널리 배포되었다 (파인 4.00 이상은 IMAP4rev1을 지원한다).

2.5. IMAP4

1990년대 초 IETF에 설립된 IMAP 작업반이 IMAP2bis 설계에 대한 책임을 맡았다. IMAP 작업반은 혼란을 피하기 위해 IMAP2bis의 이름을 IMAP4로 변경하기로 결정했다.

POP는 사용자가 이용 중인 서버에서 클라이언트로 이메일을 다운로드하고, 다운로드가 끝난 이메일은 서버에서 삭제하는 것을 표준적인 이용 형태로 하는 반면, IMAP은 이메일을 이메일 서버에 저장한 채로 관리한다( 참조). 이러한 특성으로 인해 웹메일이나 여러 대의 컴퓨터에서 동일한 계정의 이메일을 읽는 경우, 이메일의 읽지 않음 상태 등의 속성이나 이메일 폴더의 구성 등을 일원적으로 관리할 수 있는 장점이 있다. 원래는 IMAP이 개발되었지만, IMAP2, IMAP3, IMAP2bis 등이 만들어졌고, 현재 IMAP이라고 할 때는 IMAP4를 가리키는 것이 일반적이다. 프로토콜의 사양이 복잡했기 때문에 그다지 널리 보급되지 않았지만, 넷스케이프나 인터넷 익스플로러에 기본적으로 포함된 이메일 소프트웨어가 IMAP4를 지원하고, 또한 상호 접속 시험이나 프로토콜의 다양한 개정 및 확장에 의해 상호 운용성이 높아졌기 때문에 이용자가 늘어났다.

3. POP와의 비교

POP 프로토콜은 상시 접속이 아닌 네트워크 접속에서 유리하며, 사용자는 이메일의 로컬 복사본을 받아 오프라인으로 이메일을 읽을 수 있다. 이메일 폴더는 MUA에 의해 관리되며 프로토콜에는 포함되어 있지 않다. 일반적으로 이메일은 서버에서 가져온 직후 삭제되므로 서버는 읽지 않은 이메일만 보관하면 되어 서버 측 저장 용량을 줄일 수 있다. 하지만 여러 단말기에서 이메일을 가져오면 다른 단말기에서 다운로드한 로컬 복사본에 접근할 수 없고, 이메일을 서버에 저장하는 방법이 없다. 이메일을 가져올 때 이메일의 일부만 가져오는 옵션이 제공된다.

IMAP은 이러한 POP의 장점을 유지하면서 단점을 해결하였다.

3.1. IMAP의 장점

IMAP은 온라인 및 오프라인에서 모두 사용할 수 있는 프로토콜이다. 오프라인 작업은 MUA(메일 사용자 에이전트) 측에서 트랜잭션 로그로 저장하고, 서버에 연결될 때 커밋하여 반영할 수 있다.

일반적으로 이메일은 서버에 항상 저장된다. 로컬 복사본을 가져올 때 서버에서 삭제할 수도 있지만, 기본적으로는 서버 측 저장 용량이 늘어난다.

여러 단말기에서 이메일 상태를 통합 관리할 수 있으며, 여러 단말기에서 같은 이메일을 읽을 수 있다.

이메일 폴더는 프로토콜의 일부로 표준화되어 있어, 이메일 소프트웨어 종류에 관계없이 폴더를 관리할 수 있다.

이메일의 일부만 가져올 수 있다. 예를 들어, 헤더만 가져오거나 멀티파트 메시지 중 텍스트 부분만 가져오는 등의 작업이 가능하다.

이메일을 서버에 저장하는 방법이 있으며, 폴더 전체의 스냅샷을 다른 서버로 전송할 수도 있다.

서버 측에서 메시지 검색을 수행하여 클라이언트 측의 부하를 줄일 수 있다.

IMAP4 이전의 IMAP은 원격 실행으로 인한 프로토콜 복잡성과 보안상 우려가 있었으나, IMAP4에서는 이러한 문제점이 개선되었다. 다만, 이메일 서버는 이메일 원본을 관리해야 하므로, 대규모 시스템에서는 막대한 양의 이메일 관리가 필요하다.

3.2. IMAP의 단점

IMAP은 POP의 많은 단점을 해결했지만, 추가적인 복잡성을 가지고 있다. 이러한 복잡성의 상당 부분은 서버 측의 메일디르(Maildir)나 데이터베이스 백엔드와 같은 해결 방법으로 보완된다.

IMAP 사양은 충분히 엄격하지 않아 유용성을 무효화하는 동작을 허용한다는 비판을 받는다. 예를 들어, 사양에서는 서버에 저장된 각 메시지에 클라이언트가 세션 간에 이미 본 메시지를 식별할 수 있도록 "고유 ID"가 있다고 명시되어 있지만, 이러한 UIDs를 거의 제한 없이 무효화할 수 있도록 허용하여 그 목적을 좌절시킨다.

관리 및 리소스 관점에서 IMAP 프로토콜은 클라우드 컴퓨팅의 초기 구현으로 볼 수 있다. IMAP은 메일 서버에 사서함 구조를 유지하는 반면, POP는 사용자의 로컬 장치에 유지한다. 따라서 IMAP은 훨씬 더 많은 서버 측 리소스를 필요로 하여 사서함당 비용이 상당히 증가한다.

서버의 메일 저장, 색인 생성 및 검색 알고리즘이 신중하게 구현되지 않으면 클라이언트는 대규모 사서함을 검색할 때 엄청난 양의 서버 리소스를 소비할 수 있다.

IMAP4 클라이언트는 새 메일 도착을 알리기 위해 IMAP 서버에 TCP/IP 연결을 유지해야 한다. 메일 도착 알림은 인밴드 시그널링을 통해 이루어지며, 이는 클라이언트 측 IMAP 프로토콜 처리의 복잡성에 기여한다. 푸시 IMAP이라는 비공개 제안은 알림 대신 전체 메시지를 보내 푸시 이메일을 구현하도록 IMAP을 확장했지만, 일반적으로 받아들여지지 않았다.

기본 IMAP 클라이언트를 사용하여 메시지를 보내고 서버 측 폴더에 사본을 저장하려면 메시지 콘텐츠를 두 번 전송해야 한다. 한 번은 SMTP를 통해 배달하고, 두 번째는 IMAP을 통해 보낸 편지함에 저장하기 위해서이다. 이는 IMAP의 URLAUTH 및 CATENATE와 SMTP-SUBMISSION의 BURL을 통해 해결된다. 쿠리어 메일 서버는 전용 보내는 편지함 폴더에 발신 메시지를 복사하여 IMAP을 사용하는 비표준 전송 방법을 제공한다.

4. 보안

IMAP을 사용하는 이메일 클라이언트는 사용자가 명시적으로 삭제하기 전까지 메시지를 서버에 남겨둔다. 이러한 작동 방식 덕분에 여러 클라이언트가 동일한 사서함을 관리할 수 있다. 대부분의 이메일 클라이언트는 메시지를 검색하기 위해 POP 외에도 IMAP을 지원한다. IMAP은 메일 저장소에 대한 접근을 제공하며, 클라이언트는 메시지의 로컬 사본을 저장할 수 있지만 이는 임시 캐시로 간주된다.

클라이언트와 서버 간 IMAP 연결을 암호화하여 보호하기 위해 TCP 포트 993을 사용하는 IMAPS를 사용할 수 있으며, 이는 SSL/TLS를 활용한다. 2018년 1월 기준으로 TLS가 권장되는 메커니즘이다.

또는, STARTTLS를 사용하여 처음에 평문을 통해 통신한 후 포트 143에 연결할 때 연결을 암호화할 수도 있다.

5. IMAP의 채용 사례

IMAP을 채용한 대표적인 사례는 다음과 같다.

5.1. 서버

* Courier-IMAP
* https://www.washington.edu/imap/ UW IMAP
* Cyrus IMAP 서버
* Dovecot

5.2. 클라이언트

IMAP을 사용하는 이메일 클라이언트는 일반적으로 사용자가 명시적으로 삭제하기 전까지 메시지를 서버에 남겨둔다. 이러한 IMAP 동작의 특성으로 여러 클라이언트가 동일한 사서함을 관리할 수 있다. 대부분의 이메일 클라이언트는 메시지를 검색하기 위해 POP 외에도 IMAP을 지원한다. IMAP은 메일 저장소에 대한 접근을 제공한다. 클라이언트는 메시지의 로컬 사본을 저장할 수 있지만, 이는 임시 캐시로 간주된다.

IMAP를 지원하는 대표적인 이메일 클라이언트는 다음과 같다.

5.3. 웹메일 클라이언트

웹메일 클라이언트에는 다음이 포함된다.

* 라운드큐브
* 스쿼럴메일

5.4. 서비스

* 모바일미 - 애플
* AIM 메일 - AOL
* 지메일 - 구글
* 아웃룩닷컴 - 마이크로소프트

6. RFC