반응형
출처: http://babyprogram.tistory.com/31 [아장아장 프로그래밍2]
// 직접 번역한 내용이라 오역 및 의역이 있을 수 있습니다. 다만 각 문장은 RFC 1939문서의 문장을 직역한 것이기 때문에 비교하면서 보면 의미 전달이 더 명확할 것입니다.
1.Introduction
인터넷의 더 작은 노드들 중 어떤 특정한 타입의 경우, message transport system(MTS)를 유지하는데 비실용적이다. 예를 들어서 workstation에 SMTP 서버를 허용하기 위해서 [RFC821], 혹은 연관되어 있는 로컬 mail delivery system이 계속해서 실행되도록 하기 위해서 필요한 cycle이나 disk space와 같은 충분한 자원이 없을 수도 있다. 비슷하게, 개인 컴퓨터를 IP-style 네트워크로 오랫동안 서로 연결된 상태로 유지하는 것은 비쌀 수도(혹은 불가능할 수도) 있다. (노드-로컬 클라이언트-가 "연결성"으로 알려진 자원을 부족하게 하고 있다)
그럼에도 불구하고 메일을 이러한 작은 노드(로컬 클라이언트)에서 관리하는 것은 매우 유용하고, 그들은 종종 메일을 핸들링하기 위해서 user agent(UA)라고 하는 것도 지원한다. 이러한 문제를 해결하기 위해서 MTS를 지원할 수 있는 로컬 클라이언트들은 maildrop 서비스를 지원한다. POP3는 동적이면서 유용한 방법으로 workstation에 서버에 있는 메일 드롭에 접근하는 것을 허가하기 위해 고안되었다. 보통, 이것은 원래 POP3 프로토콜이 서버에서 가지고 있는 메일을 워크스테이션에 가지고 오는 것을 허용하는 것이었다는 것을 의미한다.
POP3는 서버의 메일을 대량으로 조작하는 운영을 제공하기 위해서 고안되지 않았다; 일반적으로 메일은 다운받은 후에 지워진다. 더 발전한, 그리고 복잡한 프토토콜인 IMAP4는 RFC1730에서 논의되고 있다.
이 문서는 이제부터 "클라이언트 호스트"라는 용어는 POP3 서비스를 사용하는 쪽을 지칭하고, "서버 호스트"는 POP3 서비스를 제공하는 쪽을 지칭할 것이다.
2.A Short Digression
이 문서는 클라이언트 호스트가 메일을 어떻게 transport system에 보내는지 구체적으로 알아보지 않을 것이다. 하지만 그 방법은 아래와 같이 이 문서의 철학과 맥락을 같이 한다.
3.Basic Operation
- 최초에, 서버 호스트는 POP3서비스를 TCP 포트 110에서 리스닝하는 것으로 시작한다.
- 클라이언트 호스트가 서비스를 사용하려고 할 때, 그것은 서버호스트와 TCP 커넥션을 맺는다.
- 커넥션이 맺어지고 나면 POP3 서버는 greeting을 보낸다.
- 그 후에 클라이언트와 POP3서버는 커넥션이 끝나거나 혹은 파기될 때까지 서로 commands 와 responses를 주고 받는다.
- POP3에서의 command는 대소문자를 구분하지 않으며, 하나 이상의 argument를 받을 수 있다.
- 모든 커맨드는 CRLF pair에 의해서 끝난다.
- keyword와 argument는 인쇄 가능한 ASCII 문자로 구성되어 있다.
- keyword와 arguments는 공백 문자(space)로 각각 구분된다.
- keyword는 3~4개의 캐릭터 문자이다.
- 각각의 argument는 최대 40개의 캐릭터 문자까지 가능하다.
- POP3에서의 응답은 하나의 상태 지시자와 하나의 keyword, 그리고 뒤에 추가정보를 덧붙일 수 있도록 구성되어 있다.
- 모든 응답은 CRLF 페어에 의해서 끝난다.
- 응답은 제일 끝에 있는 CRLF 문자를 포함해서 최대 512자의 캐릭터 길이가 가능하다.
- 응답에는 두개의 상태 지시자가 있다. positive:("+OK") / negative: ("-ERR")
- 서버는 반드시 "+OK"와 "-ERR"를 대문자로 보내야 한다.
- 어떤 커맨드에 대한 응답은 여러 줄일 수 있다.
- 첫번째 줄의 응답과 개행문자를 받은 후에도 각각의 개행 문자 페어에 의해서 끝나는 추가된 줄이 더 들어오는 경우와 같이 명확하게 아래를 가리키고 있을 경우에는 응답이 여러줄 일 수 있다.
- 모든 라인의 응답이 보내지고 난 후, termination 옥텟(decimal code 046, ".")과 CRLF pair를 포함하고 있는 마지막 줄이 보내진다.
- 만약 여러 줄의 응답이 터미네이션 옥텟(".")으로 시작한다면 그 라인은 미리 해당 라인의 시작 부분에 터미네이션 옥텟을 덧붙여서 보내어 행이 "byte-stuffed" 된다.
- 그러므로 여러줄의 응답은 "CRLF.CRLF"로 끝난다.
- 여러 줄의 응답을 검증해 볼 때 클라이언트는 한 줄의 시작이 터미네이션 옥텟으로 시작하는지 확인한다.
- 만약 한 줄의 시작이 터미네이션 옥텟으로 시작하고, 옥텟 뒤에 CRLF가 따라붙는다면, 그 줄의 첫번째 옥텟(터미네이션)은 없앨 것이다.
- 만약 CRLF가 즉시 터미네이션 캐릭터에 따라오면 POP 서버로부터 온 그 응답은 끝난 것이고,".CRLF"를 포함하고 있는 라인은 여러줄로 구성된 응답의 일부로 고려되지 않을 것이다.
- POP3 세션은 그것의 생명주기 동안 몇 가지의 상태를 통해 진행된다.
- 일단 TCP 커넥션이 맺어지고 POP3 서버가 greeting을 보내면 세션은 'AUTHORIZATION'상태로 들어간다.
- 이 상태에서 클라이언트는 반드시 스스로 POP3 서버에 인증을 해야 한다.
- 일단 클라이언트가 이 과정을 성공적으로 넘어가면, 서버는 클라이언트의 메일드롭과 연관된 자원을 얻고, 세션은 TRANSACTION 상태로 진입한다.
- 이 상태에서는 클라이언트는 POP3 서버의 일부에 대해서 동작을 요청한다.
- 클라이언트가 QUIT 커맨드를 보내고 나면 세션은 UPDATE 상태로 진입한다.
- 이 상태에서 POP3 서버는 TRANSACTION 상태인 동안 얻었던 모든 자원을 release하고 goodbye 하고 말한다.
- 그 후에 TCP 커넥션은 닫힌다.
- 서버는 '반드시' 인정되지 않거나, 제대로 실행되지 않거나, 혹은 문법적으로 옳지 않은 커맨드에도 네거티브 상태 지시자와 함께 응답을 보내줘야 한다.
- 서버는 세션이 옳지 않은 상태에서 발행된 커맨드에도 반드시 네거티브 상태 지시자와 함께 응답해야 한다.
- 클라이언트는 서버가 추가적인 커맨드를 지원하지 않는 것과 서버가 원하지 않거나 커맨드를 수행할 수 없는 것을 구분할 방법이 없다.
- POP3 서버는 비활성화된 자동 로그아웃 타이머를 가질 수도 있다.
- 이러한 타이머는 최소 10분동안 반드시 지속 가능해야 한다.
- 클라이언트로부터 어떠한 커맨드라도 그 시간 사이에 온 것이 있다면 자동 로그아웃 타이머를 리셋하도록 해야 한다.
- 타이머가 만료되고 나면, 세션은 UPDATE 상태로 진입하지 않는다.-- 서버는 클라이언트에 어떤 메세지도 지우거나 어떠한 응답도 보내지 않고 TCP커넥션을 닫는다.
4. The AUTHORIZATION state
- 일단 POP3 클라이언트에 의해서 TCP 커넥션이 맺어지면, pop3 서버는 한 줄의 greeting을 보낸다.
- 이것은 어떠한 positive 응답이든 상관없다.
- 예를 들어 아래와 같은 것도 가능하다.
- POP3 세션은 이제 AUTHORIZATION 상태이다. 클라이언트는 이제 반드시 POP3 서버에 자신을 밝히고 인증을 받아야 한다.
- 이 문서에서는 그 인증을 받기 위해 사용 가능한 두가지 매커니즘을 서술하고 있다.
- User and PASS 커맨드 조합과 APOP command이다.
- 두 매커니즘 다 이 문서의 아래에 서술되어 있다.
- 추가적인 인증을 받는 매커니즘은 [RFC1734]에 서술되어 있다.
- 반면, 모든 POP3 서버에서 필수적인 하나의 인증 매커니즘도 없으므로 POP3 서버는 최소한 하나의 인증 매커니즘을 반드시 제공해야 한다.
- 일단 POP3서버가 클라이언트가 적절한 메일드랍에 접근하기 위해 받아야 하는 어떠한 인증 커맨드를 사용할 것을 결정하면 그 POP3 서버는 세션이 UPDATE 상태에 들어가기 전에 메세지가 수정되거나 지워지는 것을 막기 위해 그 메일드랍에 대해 배타적 접근 락을 획득한다.
- 만약 락이 얻는데 성공하면 POP3서버는 positive 상태지시자와 함께 응답을 보낸다.
- POP3 세션은 이제 어떤 메세지도 deleted 표시가 되지 않은 채로 TRANSACTION 상태에 들어간다.
- 만약 메일드랍이 어떠한 이유들로 인해 열리지 않는다면(예를 들어 락을 획득하지 못했거나 클라이언트가 적합한 메일드랍에 접근하는 것을 거부당했거나 메일드립을 파싱할 수 없을 때) POP3 서버는 negative 상태 지시자를 이용하여 응답한다.
- (만약 락을 획득했지만 POP3서버가 negative 상태 지시자를 보내는 것을 의도한다면, POP3 서버는 반드시 커맨드를 거부하기 전에 락을 먼저 해제해야 한다.)
- negative 상태 지시자를 보낸 후에 서버는 커넥션을 끊을 수 있다.
- 만약 서버가 커넥션을 끊지 않는다면 클라이언트는 새로은 인증 커맨드를 발행해서 다시 시작할 수 있고, 혹은 클라이언트에서 QUIT 커맨드를 날릴 수도 있다.
- POP3서버가 메일드랍을 열고 난 후에, 서버는 각각의 메세지에 메세지 넘버를 할당하고 각 메세지의 크기를 옥텟에 기록한다.
- 메일드랍의 첫번째 메세지에는 "1"을 할당하고, 두번째에는 "2"를 할당하는 식으로, n번째 메세지는 "n"번의 메세지 넘버를 할당한다.
- POP3 커맨드와 응답에서는 모든 메세지 넘버와 메세지 사이즈가 base-10(i.e., decimal) 형식으로 표현된다.
- 여기에 AUTHORIZATION 상태일 때 간단한 QUIT 커맨드에 대한 요약이 있다.
5. The TRANSACTION State
- 일단 클라이언트가 성공적으로 POP3서버에서 인증되고 POP3 서버가 적합한 메일드랍을 락을 걸고 열었다면 POP3 세션은 이제 TRANSACTION 상태가 된 것이다. 클라이언트는 이제 아래에 나온 어떠한 POP3 커맨드든 반복적으로 보낼 수 있다.
- 각각의 커맨드를 보낸 후에는 POP3 서버가 응답을 보낸다.
- 마침내는 클라이언트는 QUIT 커맨드를 보내고, POP3세션은 UPDATE 상태에 접어든다.
- 아래에 TRANSACTION 상태에서 사용 가능한 POP3 커맨드가 있다.
6. The UPDATE state
- 클라이언트가 TRANSACTION 상태에서 QUIT 커맨드를 보내면 POP3 세션은 UPDATE 상태로 진입한다. (만약 클라이언트가 AUTHORIZATION 상태에서 QUIT 커맨드를 발행하면 POP3 세션은 파기되지만 UPDATE 상태로 진입하지는 않는다.)
- 만약 세션이 QUIT 커맨드를 날리지 않았는데 어떠한 이유에서든 간에 파기되었을 경우, POP3 세션은 UPDATE상태로 진입하지 않고, 메일드랍의 어떤 메세지도 지우지 않아야 한다.
7. Optional POP3 Commands
- 위에서 논의된 POP3 커맨드는 POP3서버의 모든 실행에 의해서 지원되어야 한다.
- 아래에 서술된 선택적인 POP3 커맨드들은 간단한 POP3 서버에 실행을 보류하고 있는 동안 POP3 클라이언트들이 메세지 핸들링에 있어서 더 큰 자유를 누릴 수 있게 허용한다.
- 즉, 이 메모의 철학은 POP3 클라이언트가 정보를 갖기를 바라는 것이지, 서버가 갖기를 바라는 것이 아니다.
8. Scaling and Operational Considerations
- 위에 서술된 몇몇의 추가적인 커맨드들이 POP3 프로토콜에 덧붙여졌기 때문에, 대부분의 사용자들이 서로 연결되어 있지 않은 큰 규모의 상업적인 post office operation 상에서 이 추가적인 옵션 커맨드들을 사용하는 과정에서 경험이 축적되어왔다.
- 이러한 상황들에서, 그리고 사용자와 POP3 클라이언트 공급업체들은 UIDL 커맨드를 사용하는 것과 DELE 커맨드를 발행하지 않는 조합이 IMAP과 공조했을 때 약한 버전의 "mail-drop 을 준영구적인 저장소"의 기능으로 제공할 수 있다는 것을 발견했다.
- 물론 존재하는 커넥션에 대해 새롭게 도착한 메세지를 당겨오거나 서버에 있는 여러개의 폴더를 지원하는 것과 같은 IMAP의 다른 기능들은 POP3에 존재하지 않는다.
- 이 기능들이 일상적인 유저에 의해 이러한 방법으로 사용될 때, 서버에서 이미 읽은 메세지가 구분없이 다시 쌓이는 경향이 있어왔다.
- 이것은 서버운영자의 관점에서 보았을 때 명확하게 부적절한 행동 패턴이다.
- 이 상황은 POP3의 제한적인 기능이 수백 수천개의 메세지를 가지고 있는 메일드랍의 효율적인 핸들링을 허용하지 않는다는 사실에 의해서 악화된다.
- 결과적으로, 이것은 특히 사용자가 POP3만 통해서 메일드랍에 접근할 수 있을 경우의 큰 규모의 멀티유저 서버의 운영자에게 추천된다. 이 때 고려되어야 할 옵션은 이러하다:
<사용자 별 메일드랍 저장 용량과 같은 것을 부과할 때>
- 이 옵션에 대한 불리한 점은 메세지의 축적이 사용자가 메일드랍에 새로운 메세지를 받지 못하는 결과를 초래할 수 있다는 점이다.
- 이 옵션을 선택한 사이트는 반드시 사용자에게 사용자의 메일드랍이 적합한 메세지의 수신으로 인해 용량이 거의 다 찼거나 현재 꽉 찼다는 것을 알려줄 것을 보장해야 한다.
<사이트의 정책이 서버에서 메일을 보유하는 것 대하여 고려하도록 강제하라>
- 사이트들은 서버에서 읽은 혹은 읽지 않은 메세지의 저장과 보유에 대한 local policy를 세우는 것이 자유롭다.
- 예를 들어서 사이트는 서버에서 읽지 않은 메세지를 60일 이후에 지울수 있고 읽은 메세지를 7일 후에 지울 수도 있다.
- 이러한 메세지 삭제는 POP3프로토콜의 영역 밖에서 벌어지는 일이고, 프로토콜 위반을 고려하지 않는다.
- 메세지 삭제 정책을 강제하는 서버 운영자들은 반드시 모든 사용자가 이러한 정책이 유효하다는 것을 잘 알고 있도록 신경을 써야 한다.
- 클라이언트는 절대로 사이트의 정책이 자동적으로 메세지 삭제를 할 것이라고 가정해서는 안되며, 반드시 필요할 때 DELE 커맨드를 사용해서 명시적으로 메세지를 삭제하는 것을 계속해야한다.
- 이것은 사이트가 강제하는 메세지 삭제 정책이 사용자 커뮤니티에 혼란을 가져올 수도 있다는 것을 주목해야 한다. 왜냐하면 그들의 POP3클라이언트가 실제로 서버에서는 지원하지 않는데도 메일을 서버에 남기는 configuration 옵션을 포함하고 있을 수도 있기 때문이다.
- 사이트의 정책이 특별한 경우, 메세지들이 서버에서 단 한번만 다운로드되고 다운로드를 마치면 삭제되는 경우도 있다.
- 이것은 POP3 서버의 소프트웨어에서 아래와 같은 매커니즘에 의해서 수행될 수 있다. : "클라이언트에 의해서 수행되는 QUIT에 의해서 종료되는 POP3 클라이언트의 로그인은 세션이 유지되는 동안 RETR 커맨드에 의해서 다운로드한 모든 메세지를 삭제한다."
- 비정상적인 커넥션의 종료(예를 들어 QUIT이 클라이언트로부터 수신되지 않았는데)로 인해 메세지를 삭제하지 않는 것은 중요하다.
- 왜냐하면 클라이언트는 메세지를 성공적으로 받거나 저장하지 못했을 수도 있기 때문이다.
- 다운로드 후 삭제 정책을 수행하는 서버는 또한 추가적인 TOP 커맨드를 불가능하게 하거나 혹은 제한하도록 원할 수 있다.
- 왜냐하면 이것은 모든 메세지를 다운로드하는 것의 대안적인 매커니즘으로 사용될 수 있기 때문이다.
9. POP3 Command 요약
최소한의 POP3 커맨드:
추가적인 POP3 커맨드:
POP3 응답:
- STAT, LIST, UIDL 커맨드의 예외성을 기억하라.
- 모든 커맨드에 대해서 POP3 서버에 의해서 주어진 응답은 반드시 "+OK"와 "-ERR"이 명백히 주어져야 한다.
- 이 이후에 나오는 응답은 클라이언트에 의해서 무시될 수도 있다.
10. POP3 세션 예시
11. Message 형식
- POP3 세션 동안 전송된 모든 메세지들은 RFC822에서 규정된 Internet text messages의 표준 형식과 일치하는 것으로 가정한다.
- 이것은 서버 호스트에 있는 메세지의 옥텟의 count와 해당 메세지에 할당된 실제 옥텟의 count가 end-of-line에 대한 local 컨벤션의 차이로 인해서 다를 수도 있다는 점에서 중요하다.
- 일반적으로, POP3 세션의 AUTHORIZATION state에 있는 동안, POP3 서버는 메일드랍에서 각 메세지를 열 때, 그 메세지의 사이즈를 옥텟으로 계산할 수 있다.
- 예를 들어, 만약 POP3 서버 호스트가 내부적으로 end-of-line을 하나의 캐릭터 문자로 나타내면, POP3 서버는 이 메세지에 들어있는 모든 해당 캐릭터 문자에 대해서 2 옥텟으로 카운트할 것이다.
- 터미네이션 옥텟으로 시작하는 메세지에 들어있는 줄들은 두번 카운트 될 필요가 없다는(그리고 해서도 안된다는) 점에 주목하라.
- 왜냐하면 POP3 클라이언트는 멀티라인 응답을 받으면 byte-stuffed된 터미네이션 캐릭터를 삭제할 것이기 때문이다.
12. 참고문헌
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC821, USC/Information Sciences Institute, August 1982.
[RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text Messages", STD 11, RFC 822, University of Delaware, August 1982.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, April 1992.
[RFC1730] Crispin, M., "Internet Message Access Protocol - Version4", RFC 1730, University of Washington, December 1994.
[RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734, Carnegie Mellon, December 1994.
13. Security Considerations It is conjectured that use of the APOP command provides origin identification and replay protection for a POP3 session. Accordingly, a POP3 server which implements both the PASS and APOP commands should not allow both methods of access for a given user; that is, for a given mailbox name, either the USER/PASS command sequence or the APOP command is allowed, but not both. Further, note that as the length of the shared secret increases, so does the difficulty of deriving it. Servers that answer -ERR to the USER command are giving potential attackers clues about which names are valid. Use of the PASS command sends passwords in the clear over the network. Use of the RETR and TOP commands sends mail in the clear over the network. Otherwise, security issues are not discussed in this memo. 14. Acknowledgements The POP family has a long and checkered history. Although primarily a minor revision to RFC 1460, POP3 is based on the ideas presented in RFCs 918, 937, and 1081. In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff provided significant comments on the APOP command.
15. Authors' Addresses John G. Myers Carnegie-Mellon University 5000 Forbes Ave Pittsburgh, PA 15213 EMail: jgm+@cmu.edu Marshall T. Rose Dover Beach Consulting, Inc. 420 Whisman Court Mountain View, CA 94043-2186 EMail: mrose@dbc.mtview.ca.us
Appendix A. Differences from RFC 1725
This memo is a revision to RFC 1725, a Draft Standard. It makes the
following changes from that document:
- clarifies that command keywords are case insensitive.
- specifies that servers must send "+OK" and "-ERR" in
upper case.
- specifies that the initial greeting is a positive response,
instead of any string which should be a positive response.
- clarifies behavior for unimplemented commands.
- makes the USER and PASS commands optional.
- clarified the set of possible responses to the USER command.
- reverses the order of the examples in the USER and PASS
commands, to reduce confusion.
- clarifies that the PASS command may only be given immediately
after a successful USER command.
- clarified the persistence requirements of UIDs and added some
implementation notes.
- specifies a UID length limitation of one to 70 octets.
- specifies a status indicator length limitation
of 512 octets, including the CRLF.
- clarifies that LIST with no arguments on an empty mailbox
returns success.
- adds a reference from the LIST command to the Message Format
section
- clarifies the behavior of QUIT upon failure
- clarifies the security section to not imply the use of the
USER command with the APOP command.
- adds references to RFCs 1730 and 1734
- clarifies the method by which a UA may enter mail into the
transport system.
- clarifies that the second argument to the TOP command is a
number of lines.
- changes the suggestion in the Security Considerations section
for a server to not accept both PASS and APOP for a given user
from a "must" to a "should".
- adds a section on scaling and operational considerations
Appendix B. Command Index
APOP ....................................................... 15
DELE ....................................................... 8
LIST ....................................................... 6
NOOP ....................................................... 9
PASS ....................................................... 14
QUIT ....................................................... 5
QUIT ....................................................... 10
RETR ....................................................... 8
RSET ....................................................... 9
STAT ....................................................... 6
TOP ........................................................ 11
UIDL ....................................................... 12
USER ....................................................... 13반응형
'개발 > Programming' 카테고리의 다른 글
| Maven을 넘어 Gradle로 가자. (0) | 2019.09.05 |
|---|---|
| C# POP3, IMAP 메일 읽어오기 (0) | 2018.09.05 |
| [Spring3] 스프링 스케줄(scheduling) 쓰레드 (Thread), Task, @Async (1) | 2018.05.04 |
| 페이징 (전자정부프레임워크) (0) | 2018.01.04 |
| Spring security - 인증 분리 (0) | 2017.11.28 |