편지는 우체국으로, 사서함은 내가 비운다 — SMTP와 POP3는 왜 따로 있는가

메일 프로그램에 계정을 등록하면 서버 주소를 두 개 넣으라고 합니다. 하나는 수신 서버, 다른 하나는 발신 서버. 여기에 pop3.example.com, smtp.example.com 같은 주소를 씁니다.

왜 하나면 안 될까요. 이유는 단순합니다. 메일은 한 방향으로 흐르지 않습니다. 보내는 일과 받는 일은 반대 방향의 다른 작업이고, 그래서 다른 프로토콜이 필요합니다.

메일 한 통의 경로. SMTP는 보내는 쪽에서 서버로 밀어 넣고, POP3는 받는 쪽이 서버에서 당겨옵니다. — 도해 직접 작성

SMTP — 밀어 넣는 프로토콜

SMTP(Simple Mail Transfer Protocol)는 보내는 프로토콜입니다. 정확히는 메일을 전달(transfer)하는 프로토콜입니다. 1980년에 제안됐고, 지금 쓰이는 판은 RFC 5321로 정리되어 있습니다.

작동 방식의 핵심은 push입니다. 보내는 쪽이 서버에 밀어 넣습니다. 받는 쪽이 가져가는 게 아닙니다. 이 차이가 POP3와의 결정적 차이입니다.

실제 대화는 텍스트 명령입니다. 서버가 먼저 인사를 하고, 클라이언트가 응답합니다.

S: 220 smtp.example.com ESMTP
C: HELO relay.example.org
S: 250 Hello relay.example.org
C: MAIL FROM:<[email protected]>
S: 250 OK
C: RCPT TO:<[email protected]>
S: 250 OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>

여기서 눈여겨볼 것이 DATA입니다. 이 명령 뒤에 본문이 오고, 마지막에 마침표 하나만 있는 줄을 보내면 끝납니다. 즉 본문의 끝을 알리는 신호가 마침표입니다.

봉투와 편지가 따로 있다

SMTP를 이해하는 열쇠는 '봉투(envelope)'와 '내용(content)'의 분리입니다.

MAIL FROM과 RCPT TO는 봉투입니다. 실제 우편으로 치면 겉봉에 적는 보낸 사람·받는 사람입니다. 반면 DATA 뒤에 오는 From:, To:, Subject: 헤더는 편지지 안쪽에 적힌 내용입니다.

이 둘은 일치하지 않아도 됩니다. 그래서 겉봉의 보낸 주소(MAIL FROM)와 본문 헤더의 From이 다른 메일이 존재할 수 있습니다. 스팸과 피싱의 상당 부분이 이 틈에서 나옵니다. 수신 서버가 SPF·DKIM·DMARC로 검사하는 것이 바로 이 부분입니다.

서버끼리는 릴레이다

메일은 보내는 사람의 서버에서 받는 사람의 서버로 직접 가지 않습니다. 중간 서버들을 거칩니다. 이것을 릴레이(relay)라고 합니다.

보내는 서버는 받는 사람의 도메인을 보고 DNS에서 MX 레코드를 조회합니다. MX(Mail eXchange)는 '이 도메인의 메일은 어느 서버가 받는다'는 정보입니다. 그 서버에 접속해 SMTP로 넘깁니다.

그리고 큐(queue)가 있습니다. 받는 서버가 응답하지 않으면 메일을 버리지 않고 쌓아둡니다. 그리고 나중에 재시도합니다. 우리가 메일을 보냈는데 몇 분 뒤에 도착하는 경우가 이 때문입니다.

포트가 세 개인 이유

SMTP는 포트가 여러 개입니다. 이게 처음에는 헷갈립니다.

25번 — 서버와 서버 사이의 릴레이용입니다. 원래 SMTP의 기본 포트입니다.
587번 — 인증된 사용자가 메일을 제출(submission)할 때 씁니다. RFC 8314에서 표준으로 정리됐습니다.
465번 — 처음부터 TLS로 암호화하는 제출용입니다.

왜 나뉘었을까요. 25번은 원래 인증이 없습니다. 서버끼리 신뢰한다는 전제였습니다. 그런데 이걸 개인이 쓰면 누구나 아무 서버로 메일을 보낼 수 있는 통로가 됩니다. 그래서 대부분의 인터넷 제공자가 25번 아웃바운드를 막습니다. 대신 587번에서 인증을 거쳐 제출하게 합니다.

POP3 — 당겨오는 프로토콜

POP3(Post Office Protocol version 3)는 가져오는 프로토콜입니다. 받는다기보다 내려받는다는 표현이 정확합니다. 규격은 RFC 1939입니다.

역사가 흥미롭습니다. POP1은 1984년 RFC 918, POP2는 1985년 RFC 937, POP3는 1988년 RFC 1081에서 시작해 RFC 1939로 정리됐습니다. 즉 SMTP(1980)보다 늦게 나왔습니다. 보내는 일이 먼저 표준화되고, 받는 일은 나중에 정리된 것입니다.

POP3의 설계 사상 — '연결해서 가져오고, 끊는다'

POP3를 이해하려면 1980년대의 통신 환경을 봐야 합니다. 그때는 전화선 모뎀이었고, 인터넷은 필요할 때만 연결했습니다.

그래서 POP3는 이렇게 설계됐습니다. 접속해서 모든 메일을 내려받고, 서버에서 삭제하고, 끊습니다. 이후에는 오프라인에서 메일을 읽습니다. 요금이 연결 시간에 비례하던 시대에 맞는 구조입니다.

실제 대화는 이렇습니다.

S: +OK POP3 server ready
C: USER mrose
S: +OK User accepted
C: PASS (비밀번호)
S: +OK mrose's maildrop has 2 messages (320 octets)
C: STAT → S: +OK 2 320
C: RETR 1 → S: +OK 120 octets (본문 전송)
C: DELE 1 → S: +OK message 1 deleted
C: QUIT → S: +OK ... signing off

응답이 +OK 또는 -ERR로 시작하는 것에 주목하세요. SMTP의 3자리 숫자 코드(220, 250, 354)와 다릅니다. 같은 메일 시스템인데 응답 형식이 다릅니다. 서로 다른 시기에 다른 사람들이 만들었기 때문입니다.

삭제가 기본값이라는 함정

POP3의 기본 동작은 내려받고 서버에서 삭제입니다. 이게 지금은 심각한 문제가 됩니다.

휴대폰과 노트북에서 같은 계정을 쓰면 어떻게 될까요. 먼저 접속한 기기가 메일을 가져가고 서버에서 지웁니다. 그러면 다른 기기에서는 그 메일이 없습니다. 즉 기기 간 동기화가 안 됩니다.

그래서 '서버에 남기기' 옵션이 있습니다. 이 모드에서는 삭제하지 않고, UIDL 명령으로 새 메일만 구분해 내려받습니다. UIDL은 메일마다 부여된 고유 식별자입니다.

하지만 이건 임시방편입니다. 폴더 관리, 읽음 표시, 여러 기기 동기화는 POP3가 설계 목표로 삼지 않은 기능입니다. 그래서 등장한 것이 IMAP입니다. IMAP은 처음부터 서버에 메일을 두고 관리하는 것을 전제로 만들어졌습니다.

반전: POP3는 죽지 않았다

보통 '요즘은 IMAP을 쓴다'고 말합니다. 맞습니다. 하지만 POP3가 사라진 건 아닙니다.

POP3가 여전히 유리한 경우가 있습니다.

1) 서버 용량이 작을 때. POP3는 내려받고 지우니 서버에 쌓이지 않습니다. 오래된 메일함이 수십 기가바이트가 되는 것을 막습니다.

2) 오프라인 보관이 필요할 때. 모든 메일의 완전한 사본이 내 컴퓨터에 남습니다. 서버가 사라져도 로컬에 남습니다.

3) 연결이 느리거나 불안정할 때. POP3는 접속 시간이 짧습니다. 내려받고 끊으면 끝입니다. IMAP은 화면을 열 때마다 서버와 통신합니다.

즉 POP3는 '보관형', IMAP은 '동기화형'입니다. 용도가 다릅니다.

보안 — 둘 다 평문에서 시작했다

두 프로토콜의 원래 버전은 암호화가 없었습니다. 비밀번호가 평문으로 오갔습니다.

지금은 두 가지 방식으로 보완합니다.

① 암묵적 TLS(implicit TLS) — 처음부터 암호화된 연결. POP3S는 995번, SMTPS는 465번입니다.
② STARTTLS — 평문으로 시작한 뒤 명령으로 암호화를 요청. POP3는 STLS 명령, SMTP는 STARTTLS 명령을 씁니다.

흥미로운 것은 SMTP의 확장 방식입니다. 클라이언트가 EHLO를 보내면 서버가 자기가 지원하는 기능 목록을 응답에 실어 보냅니다. 이 목록에 STARTTLS, 8BITMIME, SIZE, SMTPUTF8 같은 항목이 있습니다. 즉 프로토콜이 자기 자신을 설명하는 구조입니다.

메일 한 통의 경로. SMTP는 보내는 쪽에서 서버로 밀어 넣고, POP3는 받는 쪽이 서버에서 당겨옵니다. — 도해 직접 작성

둘을 나란히 놓으면

정리하면 이렇습니다.

SMTP — 보내는 프로토콜. push. 서버가 서버로 릴레이. 실패하면 큐에 쌓고 재시도. 포트 25(릴레이) / 587(제출) / 465(TLS). 응답은 3자리 숫자.
POP3 — 가져오는 프로토콜. pull. 기본은 내려받고 삭제. 포트 110(평문) / 995(TLS). 응답은 +OK / -ERR.

가장 중요한 차이는 방향입니다. SMTP는 보내는 쪽이 능동이고, POP3는 받는 쪽이 능동입니다. 그래서 같은 메일이라도 두 개의 다른 연결을 거칩니다.

이름이 알려주는 것

프로토콜 이름을 다시 보면 재밌습니다.

SMTP의 'Simple'은 겸손한 이름입니다. 실제로 지금의 SMTP는 확장이 계속 붙어 단순하지 않습니다. 이름은 1980년의 단순함을 기억하는 것입니다.

POP의 'Post Office'는 우체국입니다. 그런데 실제 동작은 '우체국에 가서 편지를 전부 받아오고, 우체국 사서함을 비우는' 것입니다. 즉 사서함(maildrop)이라는 표현이 더 정확합니다. 실제로 RFC에도 maildrop이라는 단어가 나옵니다.

여러분에게

혹시 메일 계정 설정에서 POP3와 IMAP 중에 고르라는 화면을 본 적 있나요. 대부분 IMAP을 권장하지만, 왜 그런지는 잘 설명하지 않습니다.

이제 답을 아실 겁니다. POP3는 '내 컴퓨터에 보관'이고, IMAP은 '서버에 두고 여러 기기에서 함께'입니다. 휴대폰과 노트북을 같이 쓰면 IMAP이 맞고, 한 대에서만 쓰고 서버 용량을 아끼고 싶으면 POP3가 맞습니다.

그리고 한 가지 더. 메일을 보낼 때와 받을 때 다른 서버를 쓴다는 사실은 인터넷이 원래 '서로 다른 일을 하는 서로 다른 기계들'의 연결이라는 걸 보여줍니다. 하나의 앱처럼 보이지만, 뒤에서는 최소 네 개의 프로그램이 각자 자기 일을 합니다.

참고 자료

• SMTP — RFC 5321. 1980년 제안, ARPANET 전자우편(1971)에서 발전. 포트 25(릴레이)·587(인증 제출)·465(TLS 제출, RFC 8314)
• POP3 — RFC 1939. POP1(RFC 918, 1984)·POP2(RFC 937, 1985)·POP3(RFC 1081, 1988) → RFC 1939. 확장 RFC 2449, 인증 RFC 1734
• POP3 포트 110(TCP), 암호화는 STLS 명령 또는 POP3S 995번(TLS/SSL)
• POP3 기본 동작: 세션 시작 시 maildrop의 메일을 확인하고, RETR로 내려받고, DELE로 삭제 표시. QUIT 시 실제 삭제
• 서버 보관 모드에서는 UIDL(고유 식별자 목록)로 새 메일만 구분해 내려받음
• SMTP 명령: HELO/EHLO, MAIL FROM(봉투 발신자), RCPT TO(봉투 수신자), DATA, QUIT. DATA는 서버가 354로 응답하고 <CR><LF>.<CR><LF>로 종료
• SMTP 확장: STARTTLS(RFC 3207), SIZE(RFC 1870), 8BITMIME, SMTPUTF8(RFC 6531), PIPELINING(RFC 2920), AUTH
• MX 레코드로 수신 서버를 조회하고, 실패 시 큐에 보관 후 재전송
• 봉투(MAIL FROM·RCPT TO)와 헤더(From·To)는 별개이며, 불일치가 스팸·피싱의 통로가 됨. SPF·DKIM·DMARC가 이를 검사
• POP4는 2003년 이후 비공식 제안 상태로 개발이 진행되지 않음
• 본 글은 공개된 RFC와 표준 문서를 정리한 것이며, 서버 설정값은 제공자 정책에 따라 다릅니다.