개념 사전 · 프로그램

Postfix

포스트픽스

는 로 메일을 받아 큐에 저장하고 다음 서버 또는 로컬 배달 경로로 전달하는 메일 전송 프로그램이다. 사용자의 제출을 받는 와 서버 사이 전달을 맡는 역할을 구성할 수 있으며 받은편지함 조회용 서버와는 다르다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

로고: Postfix project 공식 자료. 제품 식별을 위해 표시하며 각 상표의 권리는 권리자에게 있습니다.

01무엇이고, 어떤 일을 하나

연결에서 발신·수신자와 중계 허용 정책을 적용한다.
수락한 메일을 큐에 보관하고 전달·재시도·실패 처리를 수행한다.
등 로컬 배달 계층과 연결한다.

02어떤 순서로 동작하나

연결·정책 검사
리스너가 접속을 받고 제출용 인증 정책과 서버 간 전달 정책을 구분하여 적용한다.
수신자와 DATA 수락
봉투의 발신자·수신자를 평가하고 DATA를 받은 뒤 처리 책임을 수락한 메시지를 큐에 연결한다.
목적지 전달
큐 관리가 대상 경로를 정하고 전송 또는 로컬 배달 프로그램으로 전달한다.
재시도·완료 기록
일시 실패는 정책에 따라 재시도하고 영구 실패·완료를 기록한다. 큐 ID와 후속 배달 기록으로 상태를 추적한다.

03먼저 알아둘 용어와 구성요소

: 서버 사이에서 메일을 저장 후 전달하는 역할이다. 수신한 메일의 목적지가 로컬인지 다른 도메인인지에 따라 다음 경로가 달라진다.
: 사용자 메일 제출을 받아 인증·형식·정책을 적용하는 역할이다. 일반적으로 서버 간 중계와 별도의 리스너·정책으로 구성한다.
: 수락한 메시지와 전달 상태를 관리하는 저장 공간이다. 큐에 있다는 것은 전송 책임을 맡았다는 뜻이지 수신자가 읽었다는 뜻은 아니다.
: 다른 목적지로 메일을 중계하는 기능이다. 승인되지 않은 외부 사용자가 임의 외부 도메인으로 중계하게 하면 open 가 된다.
: 최종 배달 단계에서 수신자별 결과를 돌려받는 프로토콜로 와 의 연결에 사용할 수 있다.
: 의 MAIL FROM과 RCPT TO로 전달되는 운송 정보다. 화면의 From·To 헤더와 반드시 같은 값은 아니다.

LEARN THROUGH PRACTICE

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

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

실습 구성과 전제

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

응답 코드를 어느 명령의 결과인지 짝짓는다
- 220은 서버가 대화를 받을 준비가 되었다는 인사다. MAIL FROM 뒤의 250은 봉투 발신자 수락이며 최종 메일 배달 완료가 아니다.
- RCPT TO 뒤 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 구성이 필요하며 비밀 값은 입력하지 않는다.
확인 기준
접수, 큐 처리, 사서함 저장, 조회를 구분한다. 화면에 없는 성공을 추정해 완료로 표시하지 않는다.