단순 우편 전송 프로토콜편집자 확인

단순 우편 전송 프로토콜은 기본적으로 클라이언트-서버 모델에 기반하여 동작한다. 이 모델에서 메일 전송 에이전트 역할을 하는 SMTP 서버는 메일을 수신하고 중계하는 서비스 제공자이며, SMTP 클라이언트는 메일을 보내려는 발신자의 메일 프로그램이나 다른 서버이다. 통신은 항상 클라이언트가 서버에게 연결을 시작하고 일련의 텍스트 기반 명령어를 보내는 방식으로 이루어진다.

전형적인 세션에서 클라이언트는 서버의 잘 알려진 포트(기본적으로 25번 포트)에 TCP 연결을 설정한다. 연결이 수립되면 서버는 준비 상태를 알리는 환영 메시지(예: 220 응답 코드)를 보낸다. 이후 클라이언트는 HELO 또는 EHLO 명령어로 자신을 소개하고 세션을 시작한다. 이 초기 교환을 통해 서버는 클라이언트를 식별하고, ESMTP 지원 여부와 같은 확장 기능을 협상할 수 있다.

명령어와 응답의 흐름은 엄격한 순서를 따른다. 클라이언트는 MAIL FROM: 명령어로 발신자 주소를, 이어서 하나 이상의 RCPT TO: 명령어로 수신자 주소를 지정한다. 서버는 각 단계에서 해당 작업의 성공 또는 실패를 나타내는 숫자 코드 응답(예: 250 OK)을 즉시 회신한다. 모든 수신자가 확인되면 클라이언트는 DATA 명령어로 메일 본문 전송을 시작하고, 메시지 종료를 나타내는 특수한 줄(<CRLF>.<CRLF>)로 전송을 마친다. 최종적으로 QUIT 명령어로 세션을 종료한다.

이 모델에서 서버는 수동적인 역할만 수행하지 않는다. 메일을 최종 수신자에게 배달하기 위해, 서버는 자신이 또 다른 서버에 대한 클라이언트가 되어 중계 작업을 수행할 수 있다. 이는 메일 전송 에이전트가 DNS의 MX 레코드를 조회하여 다음 홉 서버를 찾고, 그 서버에 대해 동일한 클라이언트-서버 절차를 반복함으로써 이루어진다.

SMTP 세션은 클라이언트와 서버 간의 일련의 핸드셰이킹과 명령어 교환을 통해 이루어진다. 이 과정은 크게 연결 수립, 메일 거래, 연결 종료의 세 단계로 나눌 수 있다. 각 단계에서 클라이언트는 특정 명령어를 서버에 보내고, 서버는 그에 대한 숫자 코드와 설명문으로 구성된 응답을 반환한다.

연결이 수립되면, 클라이언트는 HELO(또는 EHLO) 명령어를 사용해 자신을 식별하고 세션을 시작한다. 이후 실제 메일 전송을 위한 거래(Transaction) 단계가 시작된다. 클라이언트는 MAIL FROM: 명령어로 발신자 주소를, 하나 이상의 RCPT TO: 명령어로 수신자 주소를 지정한다. 모든 수신자가 확인되면 DATA 명령어로 메일 본문 전송을 시작한다는 신호를 보낸다. 서버가 준비되었음을 알리는 응답을 보내면, 클라이언트는 메일 헤더와 본문을 전송하고, 한 줄에 마침표(.)만 있는 줄로 데이터 전송의 끝을 표시한다.

이 명령어 흐름은 하나의 메일을 한 번의 거래로 전송하는 기본 모델이다. 여러 수신자에게 동일한 메일을 보낼 경우, 여러 개의 RCPT TO: 명령어를 연속해서 사용할 수 있다. 모든 단계에서 서버의 응답 코드를 확인하는 것이 중요하며, 예를 들어 4xx 또는 5xx 오류 코드가 반환되면 해당 단계가 실패한 것이고, 전송 과정이 중단되거나 재시도된다.

메일 전송 과정은 메일 전송 에이전트(MTA)와 메일 배달 에이전트(MDA)의 협력으로 이루어진다. 발신자의 메일 사용자 에이전트(MUA, 예: Outlook, Gmail 웹 클라이언트)는 메시지를 작성하여 발신 측 MTA로 전송한다. 발신 MTA는 수신자의 도메인을 확인하기 위해 DNS에서 MX 레코드를 조회하여 수신 측 MTA의 주소를 찾아낸다. 이후 발신 MTA는 수신 MTA와 SMTP 세션을 수립하고 메시지를 전송한다.

수신 측 MTA는 메시지를 받은 후, 최종 목적지인 사용자의 메일박스로 배달하는 역할을 수행한다. 이때 MTA는 로컬 사용자인지 원격 사용자인지를 판단한다. 수신자가 로컬 도메인에 속하면 MTA는 메시지를 MDA에게 넘긴다. MDA는 메일 배달 에이전트로서, 메시지를 사용자의 개인 메일 저장소(예: 서버의 Maildir 또는 mbox 파일)에 실제로 기록하는 책임을 진다. 대표적인 MDA로는 프로cmail과 프로메일이 있다.

전체 과정을 단순화하면 다음과 같은 흐름으로 정리할 수 있다.

이 과정에서 하나의 메시지는 여러 MTA를 거쳐 릴레이될 수 있다. 각 MTA는 envelope 정보(MAIL FROM, RCPT TO)를 기반으로 다음 홉을 결정하며, 메시지 본문(DATA)은 릴레이 과정에서 변경되지 않는다. 최종 배달은 MDA에 의해 완료되어 수신자는 자신의 MUA를 통해 메일함에서 메시지를 확인하게 된다.

단순 우편 전송 프로토콜의 핵심 통신은 클라이언트가 서버에 일련의 텍스트 기반 명령어를 보내고, 서버가 숫자 코드로 응답하는 방식으로 이루어진다. 기본 명령어 세트는 메일 전송의 필수 단계를 정의하며, 모든 SMTP 구현체가 지원해야 하는 최소한의 기능을 구성한다.

주요 기본 명령어와 그 역할은 다음과 같다.

명령어는 순차적으로 실행되어야 하며, 각 명령어 후 서버는 250 OK 같은 성공 응답 코드를 보내 다음 단계로 진행할 수 있음을 알린다. 예를 들어, HELO로 연결을 설정한 후 MAIL FROM으로 발신자를, RCPT TO로 수신자를 지정한다. 그 후 DATA 명령어를 보내면 서버는 354 Start mail input; end with <CRLF>.<CRLF>로 응답하며, 클라이언트는 실제 메일 헤더와 본문을 전송한다. 모든 전송이 완료되면 QUIT 명령어로 세션을 마친다.

이러한 텍스트 기반의 단순한 명령어 체계는 SMTP의 초기 설계 철학을 반영하며, 광범위한 호환성을 가능하게 했다. 그러나 이 기본 명령어만으로는 발신자 인증이나 암호화 통신이 불가능하다는 한계가 존재한다. 이러한 보안 및 기능적 한계를 극복하기 위해 EHLO나 STARTTLS 같은 확장 명령어가 후에 개발되었다.

SMTP의 기본 명령어는 기능이 제한적이어서, 인증, 보안, 효율성 향상을 위한 확장이 필요하게 되었다. 이러한 요구를 충족시키기 위해 ESMTP가 도입되었으며, EHLO 명령어를 통해 클라이언트가 서버의 확장 기능을 확인하고 사용할 수 있다. STARTTLS는 TLS를 이용한 암호화 연결로의 전환을 가능하게 하는 핵심 보안 확장 명령어이다.

EHLO는 "Extended Hello"의 약자로, 기존 HELO 명령어를 대체한다. 클라이언트가 EHLO 명령어를 서버에 보내면, 서버는 자신이 지원하는 ESMTP 확장 목록을 응답 코드 250과 함께 나열하여 회신한다. 이 목록을 통해 클라이언트는 서버가 SMTP-AUTH 인증, 8BITMIME, SIZE 제한, 그리고 STARTTLS 등을 지원하는지 확인할 수 있다.

STARTTLS 명령어는 클라이언트가 서버에 평문(암호화되지 않은) 연결을 TLS 암호화 연결로 업그레이드하도록 요청할 때 사용한다. 이 명령어가 성공하면(응답 코드 220), 이후의 모든 통신(예: 사용자 인증 정보, 메일 내용)은 암호화되어 전송된다. 이는 중간자 공격과 같은 보안 위협을 방지하는 데 중요한 역할을 한다. STARTTLS는 포트 25나 587에서 사용되며, 포트 465는 암호화 연결을 처음부터 수립하는 SMTPS 방식에 주로 사용된다[1].

이 두 확장 명령어는 현대적인 이메일 시스템에서 보안과 기능성을 보장하는 필수 요소로 자리 잡았다.

SMTP 서버는 클라이언트의 명령어에 대해 항상 숫자 코드와 텍스트 메시지로 구성된 응답을 반환한다. 이 응답 코드는 3자리 숫자로 이루어지며, 첫 번째 숫자가 응답의 범주를 나타낸다. 이 체계는 RFC 5321에 정의되어 있으며, 명령 처리 상태를 명확히 전달하여 자동화된 메일 전송 과정을 가능하게 한다.

응답 코드는 첫 번째 숫자에 따라 네 가지 주요 클래스로 분류된다. 각 클래스는 특정한 의미를 지닌다.

가장 일반적인 응답 코드의 예를 들면 다음과 같다. 250 코드는 "요청한 메일 작업이 OK이거나 완료되었다"는 성공 응답이다. 354는 DATA 명령에 대한 응답으로, "메일 데이터 입력을 시작하라. <CRLF>.<CRLF>로 종료하라"는 중간 완료 응답이다. 일시적 실패인 421은 "서비스를 사용할 수 없음"을, 450은 "메일박스를 사용할 수 없음"을 의미한다. 영구적 실패의 대표적인 예는 550으로, "메일박스를 사용할 수 없거나 접근이 거부되었다"는 의미를 가진다.

이 체계는 메일 전송 에이전트(MTA)가 전송 실패 시 즉시 중단할지(5xx), 일정 시간 후 재시도할지(4xx)를 판단하는 근거가 된다. 예를 들어, 수신자 서버의 일시적 과부하로 인한 452 "저장 공간 부족" 응답을 받으면, 송신 MTA는 일정 시간 간격을 두고 메일 전송을 재시도한다. 반면, 존재하지 않는 도메인에 대한 550 응답을 받으면 즉시 영구적 실패로 처리하고 바운스 메일을 생성한다.

ESMTP는 단순 우편 전송 프로토콜의 기능적 한계를 극복하고 새로운 기능을 추가하기 위해 설계된 확장 프로토콜이다. 기본 SMTP는 RFC 821에 정의된 원래 명령어 집합만을 지원하여, 인증이나 8비트 데이터 전송 등 현대적인 요구사항을 충족시키지 못했다. ESMTP는 RFC 1869에서 처음 표준화되었으며, 클라이언트와 서버가 확장 기능을 협상할 수 있는 메커니즘을 제공한다. 이를 통해 프로토콜의 핵심 구조를 변경하지 않고도 새로운 기능을 점진적으로 도입할 수 있게 되었다.

ESMTP 세션은 클라이언트가 기본 SMTP의 HELO 명령 대신 EHLO 명령으로 시작한다. 서버가 ESMTP를 지원하면, EHLO 명령에 대한 응답으로 사용 가능한 확장 목록을 반환한다. 이 목록은 각 확장의 키워드와 선택적 매개변수로 구성된다. 이후 클라이언트는 필요한 확장 기능을 선택적으로 사용할 수 있다. 이 협상 과정은 하위 호환성을 유지하며, 서버가 EHLO를 인식하지 못하면 클라이언트는 자동으로 기본 HELO 명령으로 폴백하여 일반 SMTP 세션을 진행한다.

ESMTP를 통해 표준화된 주요 확장 기능은 다음과 같다.

이러한 확장은 스팸 메일 방지, 보안 강화, 대용량 메일 처리, 국제화 문자 지원 등 현대 이메일 시스템의 필수 요구사항을 해결하는 데 기여했다. 특히 AUTH와 STARTTLS는 무단 접근과 도청을 방지하는 데 핵심적인 역할을 한다. ESMTP는 현재 거의 모든 현대 메일 전송 에이전트에서 표준으로 채택되어 운영되고 있다.

SMTP 인증은 단순 우편 전송 프로토콜 서버가 메일 클라이언트의 사용자를 인증하는 메커니즘이다. 초기 SMTP는 서버 간 릴레이를 전제로 설계되어 발신자의 신원을 검증하지 않았으며, 이는 스팸 메일과 메일 스푸핑의 주요 악용 경로가 되었다. SMTP 인증은 이러한 익명성 문제를 해결하기 위해 도입되었으며, 클라이언트가 메일을 보내기 전에 사용자 이름과 비밀번호 같은 자격 증명으로 자신을 증명하도록 요구한다.

인증 과정은 일반적으로 확장 단순 우편 전송 프로토콜 세션에서 이루어진다. 클라이언트는 EHLO 명령으로 세션을 시작한 후, 서버가 지원하는 인증 방식을 확인한다. 이후 AUTH 명령을 사용하여 선택한 인증 메커니즘을 시작한다. 널리 사용되는 인증 방식으로는 평문 자격 증명을 사용하는 LOGIN, CRAM-MD5 챌린지-응답 방식, 그리고 더 강력한 SASL 프레임워크 기반 메커니즘이 있다.

SMTP 인증은 주로 메일 제출 포트(587)에서 사용되며, 인터넷 서비스 제공자나 기업 메일 서버가 외부 네트워크에서도 합법적인 사용자만 메일을 릴레이할 수 있도록 제어하는 데 필수적이다. 이는 무단 릴레이 사용을 방지하고 발신자 책임을 명확히 하는 데 기여한다. 그러나 인증 자체만으로는 메일 내용의 기밀성을 보장하지 않으므로, 전송 계층 보안과 결합하여 사용하는 것이 권장된다.

STARTTLS는 SMTP 세션 도중에 전송 계층 보안을 협상하여 암호화된 연결로 업그레이드하는 명령어입니다. 클라이언트가 EHLO 명령 후 STARTTLS 명령을 보내면, 서버가 이를 지원할 경우 220 응답 코드로 준비 완료를 알립니다. 이후 TLS 핸드셰이크가 수행되고, 성공하면 모든 후속 통신이 암호화됩니다. 이 방식은 기존의 비암호화 포트(예: 25번)에서도 보안 연결을 구축할 수 있게 해주어 유연성을 제공합니다.

반면 SMTPS는 SMTP over SSL/TLS를 의미하며, 연결 시작부터 암호화된 채널을 사용합니다. 주로 465번 포트를 사용하는 이 방식은 암호화 협상 없이 즉시 TLS 연결을 수립합니다. 역사적으로 SMTPS는 비표준 방식으로 시작되었으나, 이후 인터넷 할당 번호 관리기관에 의해 공식 포트로 등록되었습니다.

두 방식의 주요 차이점은 연결 초기화와 사용 포트에 있습니다. 다음 표는 핵심 특성을 비교한 것입니다.

현대 이메리 시스템에서는 메일 제출(클라이언트→서버)을 위해 587번 포트와 STARTTLS를 조합하거나, 465번 포트와 SMTPS를 사용하는 것이 일반적입니다. 두 방법 모두 도청과 중간자 공격으로부터 메일 내용과 인증 정보를 보호하는 데 효과적입니다. 서버 간 메일 릴레이에는 25번 포트와 STARTTLS가 권장되며, 상대 서버가 지원하지 않을 경우 평문으로 전송될 수 있습니다[4].

메일 전송 에이전트는 SMTP를 사용하여 이메일을 송수신하는 소프트웨어 애플리케이션이다. 이는 메일 시스템의 핵심 구성 요소로, 발신자로부터 메일을 수신하고 최종 수신자의 메일 박스 또는 다음 MTA로 메일을 전달하는 역할을 담당한다. MTA는 주로 서버 환경에서 동작하며, Sendmail, Postfix, Exim 등이 널리 사용되는 구현체이다. MTA의 주요 임무는 RFC 5321 등 관련 표준을 준수하며 메일을 정확한 경로로 라우팅하는 것이다.

MTA의 기본 작동은 DNS 조회와 밀접하게 연관되어 있다. 메일을 수신하면 MTA는 수신자 도메인의 MX 레코드를 질의하여 해당 도메인을 책임지는 MTA의 주소를 찾는다. 이후 발신 MTA는 수신 MTA와 SMTP 세션을 수립하고 메일을 전송한다. 만약 수신자가 로컬 도메인에 속하면, MTA는 메일을 로컬 메일 전송 에이전트나 메일 저장소에 직접 배달한다.

다양한 MTA 구현체는 설계 철학과 기능에서 차이를 보인다. 역사적으로 가장 유명한 MTA인 Sendmail은 높은 유연성을 제공하지만 구성이 복잡한 것으로 알려져 있다. 반면, Postfix는 모듈화된 설계와 보안성을 중시하며, Exim은 구성의 유연성과 다양한 기능을 강점으로 삼는다. 이들의 선택은 시스템 관리자의 요구 사항과 운영 환경에 따라 달라진다.

MTA는 단순한 전송뿐만 아니라 스팸 메일 필터링, 바이러스 검사, 메일 큐 관리, 전송 보안 적용 등 다양한 부가 기능을 수행할 수 있다. 현대의 MTA는 ESMTP 확장을 지원하고, SMTP-AUTH를 통한 인증과 STARTTLS를 통한 암호화를 구현하여 보안을 강화한다.

단순 우편 전송 프로토콜은 특정 TCP/IP 포트를 통해 통신하며, 용도와 보안 수준에 따라 여러 포트가 사용된다. 가장 잘 알려진 표준 포트는 포트 25이다. 이 포트는 메일 전송 에이전트 간의 서버 대 서버 메일 릴레이를 위해 설계되었다. 그러나 이 포트는 종종 스팸 발송에 악용되기 시작했고, 많은 인터넷 서비스 제공업체는 이 포트에서의 발신 연결을 차단하는 경우가 많다.

사용자 클라이언트(예: 이메일 클라이언트)가 메일 서버로 메일을 제출할 때는 주로 포트 587이 사용된다. 이 포트는 메일 제출 에이전트 포트로 지정되어 있으며, 반드시 SMTP 인증을 요구하도록 설계되었다. 이를 통해 합법적인 사용자만 메일을 보낼 수 있게 하여 스팸을 줄이는 데 기여한다. 또한 이 포트에서는 STARTTLS 명령을 사용하여 암호화된 연결을 협상하는 것이 일반적이다.

포트 465는 원래 SMTPS를 위해 할당되었으나, 공식적으로는 폐기되었다가 나중에 다시 사용 목적이 변경되었다. 초기에는 SSL 암호화를 통한 SMTP 통신을 위해 사용되었지만, IETF는 STARTTLS 방식을 표준으로 채택하며 이 포트의 공식 할당을 취소했다. 그러나 많은 메일 서비스 제공업체와 클라이언트가 여전히 암호화된 연결을 위한 대체 포트로 포트 465를 사용하고 있으며, 이 경우 연결 시작부터 TLS/SSL 암호화가 적용된다[6].

사용되는 포트는 다음과 같이 정리할 수 있다.

현대적인 메일 시스템에서는 보안과 정책 준수를 위해 포트 587을 통한 인증 및 암호화된 제출이 표준으로 권장된다. 서버 관리자는 방화벽 규칙과 DNS 레코드(MX 레코드 등)를 적절히 구성하여 이러한 포트들을 관리해야 한다.

DNS 레코드는 SMTP를 통한 이메일 전달의 정확성, 신뢰성 및 보안을 보장하는 핵심 구성 요소이다. 메일 서버는 발신자의 신원을 확인하고 수신 서버를 찾으며, 스팸과 피싱 공격을 방지하기 위해 다양한 DNS 레코드를 조회한다.

가장 기본적인 레코드는 MX 레코드이다. 이 레코드는 특정 도메인(예: example.com)으로 발송된 이메일을 수신할 메일 서버의 호스트명과 우선순위를 지정한다. 발신 MTA는 수신자의 도메인에 대한 MX 레코드를 질의하여 메시지를 전달할 정확한 서버를 결정한다. 우선순위 값이 낮은 서버가 먼저 시도된다.

스팸 및 사기 메일을 방지하기 위한 보안 강화 DNS 레코드가 발전했다. SPF 레코드는 특정 도메인을 대신해 이메일을 보낼 수 있는 권한을 가진 메일 서버의 IP 주소 목록을 공개한다. 수신 서버는 발신 서버의 IP가 SPF 레코드에 등록되어 있는지 검증한다. DKIM은 디지털 서명을 활용한다. 발신 서버는 메일 헤더와 본문에 암호화 서명을 추가하고, 공개 키는 도메인의 DKIM 레코드에 게시한다. 수신 서버는 이 공개 키로 서명을 검증하여 메일이 전송 중 변조되지 않았음을 확인한다.

DMARC 레코드는 SPF와 DKIM 정책을 조율하고 도메인 소유자가 수신 서버에게 인증 실패 메일을 어떻게 처리할지(거부, 격리, 무시) 지시한다. 또한 정기적인 보고서를 받을 수 있는 이메일 주소를 지정하여, 해당 도메인이 어떻게 사용되고 있는지 모니터링할 수 있게 한다. 이 세 가지 레코드(SPF, DKIM, DMARC)는 함께 작동하여 이메일 발신자의 신원을 검증하고, 도메인 스푸핑을 막는 데 기여한다.

단순 우편 전송 프로토콜은 설계 당시 네트워크가 신뢰할 수 있는 폐쇄된 환경을 가정했기 때문에, 본질적으로 인증과 보안 기능이 부족합니다. 이로 인해 스팸 메일 발송과 다양한 보안 공격에 악용되는 취약점을 내포하고 있습니다. 발신자의 신원을 기본적으로 검증하지 않아, 누구나 자신을 임의의 발신자로 위장하여 메일을 보낼 수 있습니다. 이는 이메일 스푸핑 공격의 근본적인 원인이 되며, 피싱 메일과 같은 사회공학적 공격의 발판을 제공합니다.

초기 SMTP는 통신 구간의 암호화를 제공하지 않아, 메일 내용과 인증 정보가 평문으로 전송됩니다. 이는 네트워크 스니핑을 통해 메시지를 탈취하거나 사용자 자격 증명을 도난당할 위험을 초래합니다. 또한, 오픈 릴레이로 구성된 서버는 인증 없이 제3자의 메일 전송을 허용하여, 스팸 발송자들에게 유용한 경로로 악용됩니다.

이러한 한계를 극복하기 위해 SPF, DKIM, DMARC 같은 보강 기술이 도입되었습니다. 각 기술의 역할은 다음과 같습니다.

이러한 기술들은 상호 보완적으로 작동하여 발신자 도메인의 신뢰성을 높이고 스팸 및 피싱을 차단하는 데 기여합니다. 그러나 이들은 SMTP 프로토콜 자체를 대체하는 것이 아닌, 추가적인 검증 레이어로서 동작합니다. 프로토콜의 근본적인 보안 취약성, 예를 들어 STARTTLS 명령어를 사용한 강제 암호화의 부재 등은 여전히 과제로 남아 있습니다.

SMTP는 인터넷 이메일 전송의 근간이지만, 현대적인 웹 애플리케이션과 모바일 환경에서는 몇 가지 한계를 보입니다. 이러한 한계를 극복하고, OAuth 인증 및 RESTful API와 같은 현대적인 웹 기술을 통합하기 위해 등장한 것이 HTTP 기반 메일 API입니다. 대표적인 예로 구글의 Gmail API가 있으며, 마이크로소프트의 Microsoft Graph API (Outlook.com 및 Exchange Online 포함)도 유사한 범주에 속합니다.

이러한 API는 SMTP와 근본적으로 다른 접근 방식을 취합니다. SMTP가 메일을 *전송*하는 프로토콜이라면, HTTP 기반 메일 API는 메일함을 *관리*하는 데 초점을 맞춥니다. API를 통해 사용자는 메일 전송뿐만 아니라 메시지 읽기, 라벨/폴더 관리, 쓰레드 조회, 연락처 동기화 등 포괄적인 기능을 수행할 수 있습니다. 통신은 HTTPS를 통해 암호화되며, 인증은 OAuth 2.0을 사용하여 애플리케이션에 제한된 권한만 부여하는 방식으로 이루어집니다[7]. 이는 SMTP의 평문 인증(예: PLAIN, LOGIN)보다 훨씬 안전한 모델입니다.

HTTP 기반 메일 API의 주요 장점과 사용 사례는 다음과 같습니다.

이러한 API는 주로 웹 애플리케이션, 모바일 앱, 크론잡을 통한 자동화된 알림 시스템, 또는 G Suite / Microsoft 365와 같은 클라우드 기반 생산성 도구와의 통합에 사용됩니다. 반면, 전통적인 메일 서버(Postfix, Exim 등) 간의 표준 통신이나, 범용 메일 클라이언트(Thunderbird, Outlook)의 기본 설정에서는 여전히 SMTP가 널리 사용됩니다. 따라서 HTTP 기반 메일 API는 SMTP를 대체하기보다, 특정 플랫폼에 종속된 고급 기능과 보안이 요구되는 현대적 애플리케이션 시나리오를 보완하는 역할을 합니다.

JMAP(JSON Meta Application Protocol)은 IMAP과 SMTP를 대체하기 위해 설계된 현대적인 이메일 프로토콜이다. 2010년대 중반에 개발이 시작되어 IETF(인터넷 엔지니어링 태스크 포스)에 의해 표준화되었다. JMAP의 핵심 목표는 이메일, 연락처, 일정 등 다양한 데이터를 효율적이고 빠르게 동기화할 수 있는 단일 API를 제공하는 것이다. 기존 프로토콜이 가진 비효율성과 복잡성을 해결하며, 특히 모바일 환경과 웹 애플리케이션에 적합하도록 설계되었다.

JMAP는 JSON을 기반으로 한 HTTP/1.1 또는 HTTP/2를 사용하여 통신한다. 이는 텍스트 기반의 복잡한 명령어를 사용하는 IMAP이나 SMTP와 달리, 구조화된 데이터 교환을 가능하게 한다. 클라이언트는 단일 HTTP 요청에 여러 명령어를 배치하여 서버에 전송할 수 있으며, 서버는 이 명령어들을 병렬로 처리한 후 하나의 응답으로 결과를 돌려준다. 이 방식은 네트워크 왕복 횟수를 크게 줄여 지연 시간을 최소화하고 대역폭 사용을 효율적으로 만든다.

JMAP의 주요 특징은 다음과 같다.

SMTP와 IMAP은 여전히 전 세계적으로 널리 사용되지만, JMAP는 이들을 대체할 수 있는 강력한 대안으로 주목받고 있다. 특히 FastMail과 Cyrus IMAP 서버와 같은 일부 공급자들이 JMAP를 지원하기 시작했다. 그러나 기존 인프라의 광범위한 도입과 레거시 클라이언트 호환성 문제로 인해 보급 속도는 점진적일 것으로 예상된다. JMAP는 이메일 생태계를 더 빠르고, 안전하며, 개발자 친화적으로 진화시키는 데 기여할 잠재력을 가지고 있다.