시스템 · 서버핵심 · 19분 읽기

메일 흐름·SMTP·IMAP와 서비스 구성

메일 발송, 서버 간 전달, 사서함 저장, 사용자 조회는 서로 다른 단계입니다. 각 단계의 책임과 로그를 연결해 전달 상태를 판단합니다.

개념부터 찾아보기

정의·역할·동작 원리를 독립 페이지에서 확인하세요. 본문의 밑줄 용어에도 설명이 있습니다.

Dovecot IMAP

Postfix Roundcube SMTP Base64

이 노트에서 설명할 수 있게 되는 것

제출·DNS 조회·SMTP 중계·사서함 저장·IMAP 조회를 순서대로 설명한다.
SMTP 봉투와 메시지 헤더, 큐 수락과 최종 전달을 구분한다.
발신·전달·저장·조회 장애의 증거를 연결한다.

먼저 알면 좋은 개념디스크·파일 시스템·LVM과 마운트 Linux 방화벽과 패킷 경로

01메일 제품 이름보다 전송·제출·배달·조회 역할을 먼저 나누기

MUAMUA는 사용자가 작성하고 읽는 프로그램, 는 인증된 사용자의 제출을 받는 역할, 는 다른 서버로 전송하고 큐를 관리하는 역할, MDA는 최종 사서함에 배달하는 역할이다.
제품과 역할의 관계제품 하나가 여러 역할을 수행할 수 있어 화살표마다 반드시 별도 컴퓨터가 필요한 것은 아니다.
서버가 연결을 받아 메시지를 수락한 뒤 다음 서버가 일시 중단되면 큐에 보관하고 정책에 따라 재시도한다.
·는 /이고 은 ·와 선택적으로 배달 등을 제공한다.
웹메일의 연결 계층는 브라우저에서 사용하는 MUA로, 사용자와의 구간은 HTTPS, 발송은 , 사서함 조회는 으로 이어진다.
웹메일 DB·메시지 저장소 DB의 주소록·설정·세션과 실제 메시지 저장소는 별도다.
- 성공 응답은 사용자가 이미 읽었다는 의미가 아니다.

MUA에서 송신 MTA, 인터넷, 수신 MTA와 MDA를 지나 수신 사용자에게 도착하는 이메일 흐름도 — 수업 원본 개요도. 제출 서버 MSA, 우편함 저장소, IMAP/POP 서버 등 일부 역할을 간략화한 그림입니다.

02DNS MX에서 전달 대상까지

발신 는 수신자 주소의 도메인에 MX를 질의하고 결과의 대상 호스트 이름을 A/AAAA로 해석한다.
MX 호스트·우선순위MX 값에는 IP 주소가 아니라 호스트 이름이 들어가고 preference 숫자가 낮은 후보를 먼저 고려한다.
- 같은 숫자는 같은 우선순위다.
MX 부재와 연결 실패MX가 전혀 없는 경우의 implicit MX와 MX는 있지만 모든 대상에 연결할 수 없는 경우는 처리 의미가 다르다.
MX·메일Null MX의 0 .은 이 도메인이 메일을 받지 않는다는 명시적 표현이다.
hosts 파일의 범위hosts 파일은 호스트 이름과 주소 조회를 보완하지만 MX를 생성하지 않는다.
- 가 선택한 대상과 사용자의 제출 서버도 다르다.
일반적으로 서버 간 전달은 25, 사용자 제출은 587 또는 implicit 465를 사용한다.
인증목적지 선택과 인증서 검증·전송 평판·스팸 정책은 각각 다른 층의 조건이다.
지정 중계 서버별도로 지정한 중계 서버를 사용하는 구성에서는 실제 다음 홉이 MX로 선택한 서버와 달라질 수 있다.
큐메시지가 이동하는 서버마다 큐와 식별자가 생길 수 있으므로 하나의 로그 번호가 전체 경로에서 같다고 가정하지 않는다.
재시도와 배달 실패일시 실패에 따른 재시도와 영구 실패·보존 기한 초과의 배달 실패 보고를 구분해 추적한다.

메일 제출제출 정책과 인증 조건을 만족한 메시지를 서버에 넘긴다.
수신 경로 조회수신 도메인의 MX와 선택된 서버의 주소를 확인한다.
서버 후보 반환수신 서버 후보와 연결에 필요한 주소를 얻는다.
전달봉투와 메시지 본문을 전송하고 수락 또는 실패 응답을 확인한다.
사서함 전달정책 검사와 로컬 전달 과정을 거쳐 사서함에 저장한다.
조회수신자가 인증 후 사서함의 메시지를 조회한다.

text

example.org.  IN MX 10 mx1.example.org.
example.org.  IN MX 20 mx2.example.org.
# 10이 우선 후보이며 mx1의 A/AAAA를 별도로 찾는다.

교육용 예시. 실제 요청·발송·설정 변경을 실행한 결과가 아니다.

설명과 함께 보는 보조 도식

메시지 순서

발신에서 수신자의 조회까지

DNS MX를 이용하는 서버 간 전달의 대표 경로다. 제출 인증과 세부 SMTP 응답은 축약했다.

전체 단계를 한 번에 읽기

01
메일 제출
제출 정책과 인증 조건을 만족한 메시지를 서버에 넘긴다.
구분
제출과 서버 간 중계
02
수신 경로 조회
수신 도메인의 MX와 선택된 서버의 주소를 확인한다.
조회 대상
봉투 수신자 도메인
03
서버 후보 반환
수신 서버 후보와 연결에 필요한 주소를 얻는다.
다음 단계
SMTP 연결
04
SMTP 전달
봉투와 메시지 본문을 전송하고 수락 또는 실패 응답을 확인한다.
수락 의미
해당 서버가 처리 책임 수락
05
사서함 전달
정책 검사와 로컬 전달 과정을 거쳐 사서함에 저장한다.
별도 단계
큐 수락과 사서함 기록
06
IMAP 조회
수신자가 인증 후 사서함의 메시지를 조회한다.
목적
읽기·상태 관리, 메일 발송 아님

학습 모식도. 대표 요청의 논리 순서이며 모든 프로토콜 메시지와 내부 처리를 그대로 나열한 것은 아니다.

03EHLO·STARTTLS·AUTH의 대화 순서

EHLO 연결 뒤 서버가 220 인사말을 보내고 클라이언트가 EHLO로 자신을 소개하면 서버가 지원하는 확장을 알린다.
--는 여러 응답 줄이 이어짐을, 마지막 공백은 해당 응답의 끝을 나타낸다.
STARTTLSSTARTTLS를 사용하면 서버의 준비 응답 뒤 를 협상하고 인증서를 검증한다.
·EHLO가 성립한 뒤에는 EHLO를 다시 하여 그 상태에서 제공되는 기능을 확인한다.
AUTHAUTH는 보통 사용자 Submission에서 계정을 인증하기 위해 사용하며 모든 인터넷 사이에서 같은 사용자 로그인을 하는 절차는 아니다.
자체의 명령 문자열이 평문 구조여도 이후 구간의 패킷 캡처에서는 암호문으로 보인다.
대화 표기아래 대화는 순서를 표현하는 문서이며 C:/S: 표시는 입력 명령이 아니다.
- 외부 중계 허용은 별도의 접근 정책이다.
인증인증된 사용자와 허용된 대상 범위를 제한하지 않으면 의도하지 않은 메일 중계 경로가 될 수 있다.

text

S: 220 mail.example ESMTP
C: EHLO client.example
S: 250-mail.example
S: 250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
[TLS 협상과 인증서 검증]
C: EHLO client.example
S: 250 AUTH ...

교육용 예시. 실제 요청·발송·설정 변경을 실행한 결과가 아니다.

원리 심화

04SMTP 트랜잭션의 봉투와 수신자별 상태

봉투 발신자은 전송 실패 통지의 반환 경로와 관련된 봉투 값이다. 메시지 본문의 From 헤더와 같을 필요가 없고 화면에 표시된 발신자만으로 봉투를 알 수 없다.
수신자 목록는 수신자마다 따로 제출한다. 한 RCPT가 거부되어도 다른 RCPT가 수락될 수 있어 메시지 한 건에 수신자별 다른 상태가 생긴다.
본문 진입DATA에 대한 는 내용을 보내라는 중간 응답이다. 아직 전체 메시지를 최종 수락했다는 뜻이 아니며 전송 끝의 최종 응답까지 읽어야 한다.
책임 이전본문 종료 뒤 을 받으면 해당 서버가 수락한 수신자에 대한 배달 또는 후속 처리 책임을 받는다. 사용자가 읽었다거나 모든 다음 홉이 배달했다는 증명은 아니다.
일시·영구 실패4yz는 해당 시도에서의 일시 실패, 5yz는 그 요청에 대한 영구 실패를 나타낸다. 인증·주소·정책·저장 용량 등 구체 원인은 코드와 부가 설명, 서버 기록을 함께 읽는다.

LEARN THROUGH PRACTICE

SMTP 수신자 거부와 STARTTLS 이후 가시성 구별하기

서버 인사·발신자 수락·수신자 거부· 전환이 서로 다른 상태라는 점을 화면으로 추적한다.

실습 구성과 전제

첫 사진은 로컬 대화의 수신자 거부, 두 번째는 별도 연결의 STARTTLS 패킷 사례다. 같은 메일 한 건을 끝까지 전송한 기록이 아니다.
실제 메일 발송이나 을 수행하지 않는 해석 실습이다. 주소는 example.test와 문서용 값으로 재구성한다.

응답 코드를 어느 명령의 결과인지 짝짓는다
- 220은 서버가 대화를 받을 준비가 되었다는 인사다. 뒤의 은 봉투 발신자 수락이며 최종 메일 배달 완료가 아니다.
- 뒤 550 5.1.1은 해당 수신자를 수락하지 않은 영구 실패 응답이다. 이 수신자가 거부되었으므로 화면을 성공 발송 사례로 설명할 수 없다.
text
```
S: 220 mail.example.test ESMTP
C: MAIL FROM:<sender@example.test>
S: 250 2.1.0 Ok
C: RCPT TO:<missing@example.test>
S: 550 5.1.1 Recipient address rejected
```
주소를 바꿔 재구성한 프로토콜 대화다. 실제 전송 명령으로 실행하는 코드가 아니다.
원본 크기로 보기 ↗
- localhost 25 연결 뒤 Postfix의 220 인사가 보인다.
- MAIL FROM은 250 2.1.0, RCPT TO는 550 5.1.1과 virtual mailbox의 user unknown 응답을 받는다.
확인 기준
수신자 주소·가상 도메인·메일박스 맵을 확인한다. 네트워크가 연결된 뒤 받은 550을 방화벽 차단으로 분류하지 않는다.
STARTTLS 응답에서 프로토콜 경계를 찾는다
- 별도 패킷 화면에서는 EHLO의 확장 목록을 받은 뒤 STARTTLS 요청과 220 응답이 이어진다. 그다음부터 핸드셰이크가 시작된다.
- 서버 인사의 220과 STARTTLS에 대한 220은 코드 숫자가 같아도 대화 시점과 의미가 다르다. 협상이 성공한 뒤에는 다시 EHLO로 세션 능력을 확인하는 흐름을 이해해야 한다.
원본 크기로 보기 ↗
- 평문 SMTP의 EHLO·250 응답 뒤 STARTTLS와 220 Ready to start TLS가 보인다.
- 이후 TLSv1.3 Client Hello·Server Hello 및 암호화된 Application Data가 나타난다.
확인 기준
이후 화면에 본문이 안 보인다는 이유로 전송이 중단되었다고 판단하지 않는다. 이 캡처만으로 인증·수신자 수락·배달 완료까지 확인할 수는 없다.
배달 성공에는 뒤의 증거가 더 필요하다
- 수신자 수락 후 DATA와 메시지 종료, 서버의 최종 접수 응답을 확인해야 큐에 받은 사실을 말할 수 있다. 그 후 실제 배달과 조회는 또 다른 단계다.
- 시험을 재구성한다면 인증정보 없이 인증서 검증과 협상 결과만 확인한다. 서버 이름과 신뢰 체인이 맞는지까지 읽어야 암호화 연결의 상대를 확인할 수 있다.
bash
```
openssl s_client -starttls smtp -connect mail.example.test:587 -servername mail.example.test -verify_hostname mail.example.test -verify_return_error -crlf
```
준비한 실습 제출 서버의 를 확인하는 재구성 예시다. 실제 서버명과 신뢰할 CA 구성이 필요하며 비밀 값은 입력하지 않는다.
확인 기준
접수, 큐 처리, 사서함 저장, 조회를 구분한다. 화면에 없는 성공을 추정해 완료로 표시하지 않는다.

실습에서 확인한 동작 원리

응답 코드는 바로 앞 명령과 연결해야 의미가 분명하다.
전환은 이후 내용의 관찰 가능성을 바꾸며, 성공과 메일 배달 성공은 별개다.

설정·출력 추가로 확인하기 32장

아래 화면을 펼쳐 위 실습의 설정값, 명령과 확인 기준을 비교해 보세요. 각 묶음은 별도 실습 기록입니다.

실습 화면 묶음 01 1장

8/27 - rkhunter, ospf(stub), Amavis · 실습·개념 참고 화면 2 — 「fail2ban」 문맥에 삽입된 원본 실습·개념 참고 화면이다. 메일 흐름·SMTP·IMAP와 서비스 구성 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

실습 화면 묶음 02 17장

Postfix 제품 표시 — 수업 원본 자료 · 메일 구성 요소·설치·DB·IMAP·SMTP·전송 테스트.

Roundcube SMTP 연결 설정 — 수업 원본 자료 · 메일 구성 요소·설치·DB·IMAP·SMTP·전송 테스트.

Roundcube SMTP 인증 테스트 — 수업 원본 자료 · 메일 구성 요소·설치·DB·IMAP·SMTP·전송 테스트.

Roundcube SMTP 전송 결과 — 수업 원본 자료 · 메일 구성 요소·설치·DB·IMAP·SMTP·전송 테스트.

Roundcube 데이터베이스 연결 설정 — 수업 원본 자료 · 메일 구성 요소·설치·DB·IMAP·SMTP·전송 테스트.

Roundcube 웹메일 · DB (6) — 수업 원본 자료 · 메일 구성 요소·설치·DB·IMAP·SMTP·전송 테스트. 원문에서 「DB」에 배치된 그림 또는 화면이다.

Roundcube 웹메일 · DB 초기화 (11) — 수업 원본 자료 · 메일 구성 요소·설치·DB·IMAP·SMTP·전송 테스트. 원문에서 「DB 초기화」에 배치된 그림 또는 화면이다.

Roundcube 웹메일 · DB 초기화 (12) — 수업 원본 자료 · 메일 구성 요소·설치·DB·IMAP·SMTP·전송 테스트. 원문에서 「DB 초기화」에 배치된 그림 또는 화면이다.

Roundcube 웹메일 · DB 초기화 (13) — 수업 원본 자료 · 메일 구성 요소·설치·DB·IMAP·SMTP·전송 테스트. 원문에서 「DB 초기화」에 배치된 그림 또는 화면이다.

Roundcube 웹메일 · IMAP → Dovecot 연결 (8) — 수업 원본 자료 · 메일 구성 요소·설치·DB·IMAP·SMTP·전송 테스트. 원문에서 「IMAP → Dovecot 연결」에 배치된 그림 또는 화면이다.

Roundcube 웹메일 · SMTP 인증 확인 (14) — 수업 원본 자료 · 메일 구성 요소·설치·DB·IMAP·SMTP·전송 테스트. 원문에서 「SMTP 인증 확인」에 배치된 그림 또는 화면이다.

Roundcube 웹메일 · 로그 디렉터리 (18) — 수업 원본 자료 · 메일 구성 요소·설치·DB·IMAP·SMTP·전송 테스트. 원문에서 「로그 디렉터리」에 배치된 그림 또는 화면이다.

Roundcube 웹메일 · 언어 설정 (10) — 수업 원본 자료 · 메일 구성 요소·설치·DB·IMAP·SMTP·전송 테스트. 원문에서 「언어 설정」에 배치된 그림 또는 화면이다.

Roundcube 웹메일 · 웹 메일 테스트 (17) — 수업 원본 자료 · 메일 구성 요소·설치·DB·IMAP·SMTP·전송 테스트. 원문에서 「웹 메일 테스트」에 배치된 그림 또는 화면이다.

Roundcube 웹메일 화면 — 수업 원본 자료 · 메일 구성 요소·설치·DB·IMAP·SMTP·전송 테스트.

Roundcube 제품 표시 — 수업 원본 자료 · 메일 구성 요소·설치·DB·IMAP·SMTP·전송 테스트.

메일 구성 요소 제품 표시 — 수업 원본 자료 · 메일 구성 요소·설치·DB·IMAP·SMTP·전송 테스트.

실습 화면 묶음 03 2장

email server · 실습·개념 참고 화면 1 — 「간단 ver」 문맥에 삽입된 원본 실습·개념 참고 화면이다. 메일 흐름·SMTP·IMAP와 서비스 구성 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

email server · 실습·개념 참고 화면 2 — 「roundcube」 문맥에 삽입된 원본 실습·개념 참고 화면이다. 메일 흐름·SMTP·IMAP와 서비스 구성 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

실습 화면 묶음 04 1장

메일 서버 구성 · mail system flow (2) — 수업 원본 자료 · Postfix·Dovecot과 메일 계정·우편함 연결. 원문에서 「mail system flow」에 배치된 그림 또는 화면이다.

실습 화면 묶음 05 1장

메일 서버 구성 · 계정 공유 방식 (1) — 수업 원본 자료 · Postfix·Dovecot과 메일 계정·우편함 연결. 원문에서 「계정 공유 방식」에 배치된 그림 또는 화면이다.

실습 화면 묶음 06 1장

학습 원본 · 메일 서버 구성과 전달 경로의 해당 절에 수록된 화면·도식이다.

실습 화면 묶음 07 1장

실습 화면 묶음 08 1장

실습 화면 묶음 09 1장

실습 화면 묶음 10 1장

실습 화면 묶음 11 1장

실습 화면 묶음 12 1장

메일 서버 구성과 전달 경로 · Mail — 학습 원본 · 메일 서버 구성과 전달 경로의 Mail에 수록된 화면·도식이다.

실습 화면 묶음 13 1장

메일 서버 구성과 전달 경로 · RoundCube(웹메일) — 학습 원본 · 메일 서버 구성과 전달 경로의 RoundCube(웹메일)에 수록된 화면·도식이다.

실습 화면 묶음 14 1장

메일 악성코드 검사와 헤더 · Amavis — 학습 원본 · 메일 악성코드 검사와 헤더의 Amavis에 수록된 화면·도식이다.

실습 화면 묶음 15 1장

메일 악성코드 검사와 헤더 · 악성코드 샘플 탐지 테스트 — 학습 원본 · 메일 악성코드 검사와 헤더의 악성코드 샘플 탐지 테스트에 수록된 화면·도식이다.

동작·명령 참고 문서

RFC 3207 · SMTP STARTTLS ↗RFC 5321 · SMTP 트랜잭션 ↗

예제로 추적

05수신자 두 명 중 한 명만 수락된 대화

반환 경로 설정아래는 example 도메인과 가상 응답으로 만든 상태 추적이다. 서버는 을 수락하여 새 봉투를 준비한다.
첫 수신자 수락첫 에 이 돌아오면 첫 수신자가 현재 의 수락 목록에 들어간다. 아직 메시지 본문을 보낸 상태는 아니다.
둘째 수신자 거부둘째 의 550은 둘째 수신자에 대한 거부다. 첫 수신자의 수락까지 취소되었다고 해석하지 않는다.
본문 최종 수락DATA의 후 내용을 보내고 마지막 을 받으면 첫 수신자에 대한 메시지가 수락된다. 둘째 수신자가 같이 배달되는 것으로 표시하면 잘못된 성공 보고다.
후속 결과 분리발신 프로그램은 수신자별 결과를 보존해야 한다. 실패 수신자를 고쳐 재전송할 때 이미 수락된 수신자에게 같은 메시지를 다시 보내지 않도록 대상을 구분한다.

text

C: MAIL FROM:<sender@example.org>
S: 250 OK
C: RCPT TO:<reader@example.net>
S: 250 OK
C: RCPT TO:<missing@example.net>
S: 550 No such recipient
C: DATA
S: 354 Send message
C: [headers and body, then terminating dot]
S: 250 Queued

가상 대화. C는 클라이언트, S는 서버이며 주소와 응답 문구는 교육용이다.

검증·예외

06중복·지연·배달 실패를 응답 경계로 찾기

마지막 응답 유실서버가 메시지를 큐에 넣은 직후 연결이 끊겨 클라이언트가 을 못 받으면 클라이언트는 수락 여부를 확정하지 못한다. 이 불확실한 구간의 재시도는 중복 배달을 만들 수 있다.
큐 식별자서버가 부여한 큐 ID는 그 서버의 처리 기록을 연결하는 단서다. 다음 서버로 넘어가면 다른 큐 ID를 받을 수 있어 전체 경로를 하나의 로컬 큐 ID로만 찾지 않는다.
Message-ID의 한계메시지 헤더의 Message-ID는 메시지 식별에 도움을 주지만 자체가 배달 성공 영수증은 아니다. 응답과 각 홉의 처리 기록이 별도로 필요하다.
큐 대기와 사서함 조회발신 큐에서 재시도 중인 문제와 사서함 배달 후 에서 보이지 않는 문제를 분리한다. 후자는 폴더·계정·배달 경로·권한 등 조회 계층을 조사한다.
재시도 범위같은 명령을 빠르게 반복해 영구 거부를 없앨 수는 없다. 일시 실패도 재시도 간격·보관 한도·실패 통지 정책 아래 처리해야 불필요한 중복과 부하를 줄일 수 있다.

07Envelope와 메시지 헤더, DATA의 종료

·과 는 전달용 를 정한다.
DATA·헤더DATA 안의 From·To 헤더는 메시지에 표시되는 정보라 와 반드시 같지 않다.
여러 로 수신자를 지정할 수 있고 Bcc는 이런 전송용 수신자와 표시 헤더가 다른 대표 사례다.
- 따라서 화면의 From 문자열만으로 실제 인증된 발송자를 판단하지 않는다.
DATADATA 뒤 응답을 받으면 헤더, 빈 줄, 본문을 보내고 CRLF 뒤 마침표 하나인 줄로 종료한다.
본문 줄본문 줄이 점으로 시작하면 점을 하나 더 붙이는 으로 종료 표시와 구분한다.
- 이후 은 그 서버가 메시지 처리 책임을 수락했음을 뜻한다.
4xx4xx는 일시 실패로 재시도 대상이 될 수 있고 5xx는 영구 실패 성격을 갖는다.
- 후속 배달 여부는 큐 ID와 다음 단계의 결과를 따라간다.

text

C: MAIL FROM:<sender@example.org>
S: 250 OK
C: RCPT TO:<receiver@example.net>
S: 250 OK
C: DATA
S: 354 Send message
From: sender@example.org
To: receiver@example.net
Subject: Study example

Hello.
.
S: 250 Queued

교육용 예시. 실제 요청·발송·설정 변경을 실행한 결과가 아니다.

08MIME·Maildir·IMAP은 서로 다른 형태를 관리한다

MIMEMIME은 텍스트의 문자셋·콘텐츠 타입·첨부 파일·멀티파트 경계를 표현한다.
첨부첨부 파일의 전송 인코딩은 크기를 늘릴 수 있으므로 원본 파일 크기와 SIZE 바이트 제한을 같은 숫자로 보지 않는다.
메일메일 라이브러리가 8BITMIME 지원 여부와 Content-Transfer- 등을 맞추는 이유도 메시지 표현과 전송 기능이 다르기 때문이다.
은 메시지별 파일을 tmp/new/cur 디렉터리에 관리하고 는 사서함의 메시지를 한 파일에 이어 저장하는 방식이다. 에서는 많은 파일이 와 디렉터리 비용을 쓰고 에서는 잠금과 큰 파일 갱신에 주의한다.
은 폴더·읽음 표시·이동·삭제 같은 서버 상태를 여러 클라이언트와 동기화한다.
의 RETR만으로 즉시 원본이 지워지는 것은 아니고 DELE·QUIT 및 클라이언트 보존 정책과 연결된다.
는 와 최종 저장소 사이의 배달 프로토콜이며 메일을 읽는 프로토콜이 아니다.

09검사 서비스 장애 정책

검사 실패 정책스팸·악성코드 검사 구성 요소가 실패했을 때 메시지를 보류할지 통과시킬지 정책이 필요하다.
검사 결과 추적로그와 테스트 메시지에서는 개인정보와 실제 대화 내용이 불필요하게 노출되지 않도록 한다.

10보냈는데 안 보이는 메일 추적하기

제출 성공의 범위발신 클라이언트의 성공 표시가 제출 성공만 뜻하는지 먼저 확인한다.
큐·송신 큐에 남아 있으면 다음 홉의 ·연결· 응답을 조사하고, 수신 서버가 수락했다면 수신 측 정책 검사와 로컬 전달 로그로 범위를 옮긴다.
저장 후 표시 문제사서함에 저장됐는데 화면에 없다면 인증·폴더·동기화·클라이언트 표시 조건을 확인한다.
중복 제출의 영향이 과정을 생략하고 같은 메시지를 반복 제출하면 늦게 도착한 원본과 함께 중복 전달될 수 있다.
메일·큐메일 큐의 크기와 가장 오래된 대기 시간은 처리 지연을 보는 단서다.
로컬 배달 실패디스크 공간이나 부족, 사용자 사서함 한도, 검사 서비스 장애로 로컬 전달이 막힐 수도 있다.
·AUTH AUTH와 는 각각 인증과 구간 보호의 역할을 하며 SPF·DKIM·DMARC 결과와도 다른 관찰 정보다.
발신 검증의 한계발신 도메인 검증 결과 하나만으로 메시지 내용이 안전하다고 판단하지 않는다.
큐조사에는 큐 ID·시각·응답 코드를 활용하고 실제 대화 내용과 주소를 불필요하게 공유하지 않는다.

구성·관찰 대상	확인 정보	판단할 차이
제출 단계	인증·수락 결과	사용자 발송과 외부 중계
송신 큐	다음 홉·응답·대기 시간	·연결·일시 실패
수신 전달	정책 검사·사서함 기록	큐 수락 후 저장 실패
·클라이언트	폴더·동기화·읽기 권한	저장됐지만 화면에 없음

학습 확인

이해했는지 확인하기

제출·중계·저장·조회 단계를 나누어 설명한다.
수락 응답과 최종 사서함 전달을 구분한다.
메일 큐·DNS·사서함 용량과 중계 정책을 확인한다.

메일 흐름·SMTP·IMAP와 서비스 구성

개념부터 찾아보기

이 노트에서 설명할 수 있게 되는 것

01메일 제품 이름보다 전송·제출·배달·조회 역할을 먼저 나누기

발송부터 우편함 저장까지의 수업 구성도

이 자료에서 읽어낼 것

02DNS MX에서 전달 대상까지

발신에서 수신자의 조회까지

메일 제출

메일 제출

수신 경로 조회

서버 후보 반환

SMTP 전달

사서함 전달

IMAP 조회

03EHLO·STARTTLS·AUTH의 대화 순서

04SMTP 트랜잭션의 봉투와 수신자별 상태

SMTP 수신자 거부와 STARTTLS 이후 가시성 구별하기

실습 구성과 전제

응답 코드를 어느 명령의 결과인지 짝짓는다

STARTTLS 응답에서 프로토콜 경계를 찾는다

배달 성공에는 뒤의 증거가 더 필요하다

실습에서 확인한 동작 원리

설정·출력 추가로 확인하기 32장

05수신자 두 명 중 한 명만 수락된 대화

06중복·지연·배달 실패를 응답 경계로 찾기

07Envelope와 메시지 헤더, DATA의 종료

08MIME·Maildir·IMAP은 서로 다른 형태를 관리한다

09검사 서비스 장애 정책

10보냈는데 안 보이는 메일 추적하기

이해했는지 확인하기

함께 확인할 공식 자료

개념부터 찾아보기

이 노트에서 설명할 수 있게 되는 것

01메일 제품 이름보다 전송·제출·배달·조회 역할을 먼저 나누기

발송부터 우편함 저장까지의 수업 구성도

이 자료에서 읽어낼 것

02DNS MX에서 전달 대상까지

발신에서 수신자의 조회까지

메일 제출

메일 제출

수신 경로 조회

서버 후보 반환

SMTP 전달

사서함 전달

IMAP 조회

03EHLO·STARTTLS·AUTH의 대화 순서

04SMTP 트랜잭션의 봉투와 수신자별 상태

실습 구성과 전제

응답 코드를 어느 명령의 결과인지 짝짓는다

STARTTLS 응답에서 프로토콜 경계를 찾는다

배달 성공에는 뒤의 증거가 더 필요하다

실습에서 확인한 동작 원리

설정·출력 추가로 확인하기 32장

05수신자 두 명 중 한 명만 수락된 대화

06중복·지연·배달 실패를 응답 경계로 찾기

07Envelope와 메시지 헤더, DATA의 종료

08MIME·Maildir·IMAP은 서로 다른 형태를 관리한다

09검사 서비스 장애 정책

10보냈는데 안 보이는 메일 추적하기

이해했는지 확인하기

함께 확인할 공식 자료

이어서 읽기