Command Palette
Search for a command to run...
Search for a command to run...
이메일(E-mail: Electronic-mail) 이란 한국어로 전자우편이라는 뜻을 가지며, 전자기기를 활용한 메시지 송수신 방식입니다. 최초의 이메일은 1971년 알파넷 네트워크에서 전송되었으며, 이때 username@hostname 주소 표기법이 등장해서 지금까지 사용되고 있습니다. 여기서 저는 1971년에 생긴 프로토콜이 과연 현재까지 안전한가 궁금해져서 현대 이메일의 동작 과정을 알아보기로 했습니다.
이메일 프로토콜은 송신과 수신으로 역할이 나뉘어져 있습니다. 현대에는 송신 프로토콜은 보통 SMTP, 수신 프로토콜은 IMAP이 자주 사용됩니다.
SMTP(Simple Mail Transfer Protocol) 은 네트워크를 통해 이메일을 전송하는 프로토콜이며, 다음과 같은 구성요소를 가집니다:
SMTP는 대화형 프로토콜이며, C(Client), S(Server)를 기준으로 통신 과정을 설명하겠습니다:
S -> C : 220 mail.example.org ESMTP
C -> S : EHLO client.example.org
// 서버는 지원하는 확장 기능을 250 응답으로 반환
S -> C : 250-mail.example.org
S -> C : 250-STARTTLS
S -> C : 250-AUTH PLAIN LOGIN
S -> C : 250 SIZE 52428800
HELO : 기본 SMTP를 시작하는 명령어EHLO : ESMTP(Extended-SMTP) 를 시작하는 명령어C -> S : STARTTLS
S -> C : 220 Ready to start TLS
이후에 핸드셰이크를 수행하며, TLS가 시작되면, EHLO를 다시 보냄.
C -> S : AUTH LOGIN
// username/password 인증
S -> C : 235 Authentication successful
AUTH LOGIN은 TLS 없이 사용하면, 중간자가 패킷을 다 들여다 볼 수 있으니, STARTTLS가 필수.
AUTH LOGIN은 대화식,AUTH PLAIN은\0username\0password를 Base64 인코딩하여 한 번에 전송합니다.
C -> S : MAIL FROM:<sender@example.org>
S -> C : 250 OK
C -> S : RCPT TO:<receiver@example.org>
S -> C : 250 OK
C -> S : DATA
S -> C : 354 End data with <CR><LF>.<CR><LF>
From: [email protected]
To: [email protected]
Subject: 메일 제목입니다.
메일 본문 내용입니다.
.
S -> C : 250 Message accepted for delivery
SMTP 세션이 종료된 후 서버는 보통 다음과 같은 작업을 수행합니다:
SMTP는 HTTP처럼 통신규약일 뿐이지, 구현체는 아닙니다. 때문에, HTTP를 구현한 Nginx나 Caddy 같은 웹 서버가 있는 것처럼, SMTP의 구현체로는 Postfix가 있습니다. 따라서 서버 내부 처리는 구현체의 책임이므로, SMTP 규약에는 해당 처리가 정의되어 있지 않습니다.
C -> S : QUIT
S -> C : 221 Bye
TCP 연결 종료
수신 프로토콜은 크게 2가지 POP3(Post Office Protocol v3), IMAP(Internet Message Access Protocol) 가 자주 사용됩니다. 둘은 모두, MDA가 저장한 메일을 MUA가 읽기 위해 사용되지만, 다음과 같은 차이점이 있습니다:
| 구분 | POP3 | IMAP |
|---|---|---|
| 메일 저장 위치 | 사용자 로컬 | 서버 |
| 멀티 디바이스 | 동기화 불가 | 동기화 가능 |
| 속도 | 초기 로딩 느림(연결 시, 본문까지 다운) | 초기 로딩 빠름(연결 시, 헤더만 먼저 다운) |
| 백업 책임 | 사용자 | 서버 관리자 |
POP3는 우체국에서 편지를 가져오는 것과 유사한 방식으로 사용자의 책임이 크며, IMAP은 서버를 파일 서버로 활용하고, 로컬에 동기화하는 방식입니다. 때문에 서버에는 사용자의 메일이 고스란히 저장됩니다.
// 인증
C -> S : USER username
S -> C : +OK
C -> C : PASS p@ssw0rd
S -> C : +OK Logged in.
C -> S : LIST // 메일 리스트 가져오기
C -> S : RETR 1 // 1번 메일 가져오기
C -> S : DELE 1 // 1번 메일 삭제 마킹
C -> S : QUIT // 연결 끊기, 삭제 마킹 메일 삭제 요청
S -> C : +OK Bye
POP3가 현실 세계의 우체국과 똑같았으면 좋겠지만, 네트워크 통신 중에는 전송 도중 끊김 상황이 자주 발생합니다. 따라서 메일을 가져가는 도중에 메일을 분실하는 경우가 발생할 수 있으며, 이를 방지하기 위해 POP3는 나갈 때 삭제 요청을 할 삭제 마킹 기법을 사용합니다. DELE 명령어로 삭제 마킹을 할 수 있으며, QUIT 시 서버에 실제 메일 데이터의 삭제를 요청합니다.
하지만, 일반적인 사용자는 개인이 메일 데이터를 관리하고 싶지 않아할 것이며, 기업을 더더욱 그럴 것입니다. 따라서 현대에는 IMAP이 표준입니다 :(
SPF(Sender Policy Framework) 은 메일 발송 서버의 IP 주소를 지정하여, 발신자 위조/수푸핑을 방어할 수 있는 기술이며, DNS TXT 레코드에서 설정 가능합니다.
SPF의 TXT 레코드 형식은 다음과 같습니다:
example.org. IN TXT "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all"
v=spf1 : SPF 버전 선언ip4/ip6 : 특정 IP 주소 또는 대역 허용include : 다른 도메인의 SPF 레코드 참조 (외부 메일 서비스 사용 시)all 처리 정책
-all : 무조건 거부~all : 승인하지만, 스팸으로 분류?all : 아무런 정책 없음하지만 이메일 전달 시, 중간 경유지 서버가 메일 대신 전달하는 경우, SPF 레코드에는 경유지 서버의 IP가 없으므로 SPF 기반 인증에 실패하게 됩니다. 이를 보완하기 위해 보통 SPF는 DKIM과 같이 사용됩니다.
DKIM(DomainKeys Identified Mail) 은 이메일 헤더에 공개키 암호화 전자서명을 활용하여 전송 중에 변조되지 않았음을 증명하는 기술이며, 마찬가지로 DNS TXT 레코드에서 설정 가능합니다.
DKIM은 메일 서버에서 생성한 공개키/비밀키 쌍이 필요하며, 메일 서버에서 비밀키로 생성한 전자서명을 수신자가 메일 서버의 공개키로 검증하는 구조입니다. 이때, DKIM에 필요한 서버의 공개키는 다음과 같이 DKIM TXT 레코드에 공개됩니다:
selector._domainkey.example.org. IN TXT "v=dkim1; k=rsa; p=..."
selector : DKIM 셀렉터
v=dkim1 : DKIM 버전1 사용 선언k=rsa : 키 알고리즘으로 RSA 사용p=... : 공개키 값이러한 정보를 가지고 수신자는 DKIM 검증을 위해 다음과 같은 절차를 거칩니다:
DKIM-Signature 헤더 확인
b), 셀렉터(s), 도메인(d) 등 DKIM 검증에 필요한 메타데이터 포함s), 도메인(d) 값을 조합해, DNS TXT 레코드를 조회 후 공개키, 알고리즘 획득DKIM-Signature 헤더에 명시된 규칙에 따라 전자서명값과 메일 본문 해시값을 공개키로 검증
passfailDKIM-Signature 헤더 자체가 없으면, noneDMARC(Domain-based Message Authentication, Reporting, and Conformance) 는 SPF와 DKIM의 검증 결과에 따라, 수신 서버에게 메일의 처리 정책을 지시하는 기술입니다. 마찬가지로 DNS TXT 레코드에서 설정 가능합니다.
DMARC의 TXT 레코드 형식은 다음과 같습니다:
_dmarc.example.org. IN TXT "v=DMARC1; p=quarantine; adkim=s; aspf=s;"
v=DMARC1 : DMARC 버전 선언p : 정책 설정
none : 차단하지 않음quarantine : 스팸함으로 격리reject : 수신 차단adkim : DKIM 정렬 방식
r : relaxed, From 도메인의 상위 도메인이면 허용s : strict, From 도메인과 완전 동일하면 허용aspf : SPF 정렬 방식
r : relaxed, From 도메인의 상위 도메인이면 허용s : strict, From 도메인과 완전 동일하면 허용rua, ruf : DMARC의 보고서 수신 주소
정렬이란, From 주소와 인증에 쓰이고 있는 도메인이 같은 지를 확인하는 것입니다.
지금까지 메일의 스푸핑, 검증에 대해서 알아봤다면, 이번 절에서는 프라이버시, 스니핑, 보안에 대해서 다룹니다.
가끔, 종단간 암호화를 지원하는 Proton Mail 같은 메일 서비스도 있습니다. 메일에서의 종단간 암호화란, 메일의 내용은 암호화 되어 전달 되며, End-User끼리만 복호화할 수 있는 암호화 방식을 뜻합니다. End-User끼리만 메일의 복호화가 가능하므로, 기술적으로 Proton 조차 메일의 내용을 열람하지 못합니다.
Proton이 E2EE를 사용하는 대표적인 방법은 PGP 사용입니다. PGP를 통해 공개키/비밀키 쌍을 기반으로 작동합니다. 수신자는 공개키를 외부에 공개해 본인에게 전송할 이메일을 이 공개키로 암호화하라고 알립니다. 이후, 수신자의 공개키로 암호화된 메일이 도착하면, 수신자는 본인의 비밀키로 해당 메일을 복호화하여 읽을 수 있습니다.
하지만, 어디까지나 Proton Mail 간 또는 종단간 암호화를 지원하는 메일 서비스가 아닌 Gmail과 같은 종단간 암호화를 지원하지 않는 메일 서비스에 Proton Mail로 메일을 전송하는 순간, 종단간 암호화가 깨집니다. 이를 방지하기 위한 Password-protected Emails 서비스도 있지만, 이는 더 이상 이메일 기술이 아닙니다.
왜 아직도 1971년의 기술을 사용하는가?
사실 이메일 말고도 VoLTE, SMS 같은 기술이 더 의심스럽긴 하지만, 오늘은 이메일을 알아봤습니다. 개인적으로 이메일이라는 기술이 아직도 사용되고 있는 이유는 통제권에 있다고 생각합니다. 기업과 같은 조직들은 자체 규칙에 따라 메신저 계정과 메시지를 관리하기를 원하며, 이를 자연스럽고 어렵지 않게 구축할 수 있는 시스템은 이메일이기 때문입니다.
따라서 비지니스 상황에서 이메일을 사용한다는 것은, "당신의 조직이 관리하는 서버로, 당신의 규칙을 준수하며 정중하게 메시지를 전달하겠다!" 라는 의미를 내포하는 행위처럼 보입니다.
반대로 비교적 가벼운 마음으로 메시지를 전송할 때, 사람들은 인스턴스 메신저를 자주 사용합니다.
그래도 SPF, DKIM, E2EE 등 다양한 보안 기술들이 같이 발전하였기에, 아직까지는 이메일을 안심하고 쓸 수 있을 것 같습니다.
로그인 후 댓글을 작성할 수 있습니다.