개념 사전 · 프로그램

Dovecot

도브콧 · 도브코트

은 ·로 사용자의 메일함을 조회하게 하는 메일 서버 프로그램이다. 인증과 메일 저장소 접근을 연결하며 구성에 따라 로 최종 배달을 받는 역할도 수행한다.

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

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

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

· 세션을 통해 폴더·메시지·상태를 제공한다.
결과를 실제 메일 저장 경로와 권한에 연결한다.
배달·quota 등 메일함 관리 기능을 구성한다.

02어떤 순서로 동작하나

조회 연결
클라이언트가 또는 리스너에 접속하고 구성된 보호를 적용한다.
인증·사용자 조회
인증 정보와 사용자 데이터베이스를 통해 계정·UID·저장 위치 같은 실행 조건을 얻는다.
메일함 작업
허용된 저장소에서 메시지 목록·본문·플래그 같은 요청을 처리한다.
상태 반환
응답과 변경된 메일함 상태를 클라이언트에 전달하고 세션·저장 오류를 기록한다.

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

: 서버의 메일함과 메시지 상태를 원격으로 조작하는 프로토콜이다. 여러 클라이언트가 폴더·읽음 상태 등을 서버 기준으로 사용할 수 있다.
: 메일을 내려받는 동작을 중심으로 한 조회 프로토콜이다. 사용 후 삭제 여부는 명령과 클라이언트 정책에 따라 달라진다.
: MTA에서 최종 메일함 배달을 위임받는 경로에 사용할 수 있다. 중계와 달리 배달 단계의 수신자별 결과를 표현한다.
: 메시지를 개별 파일로 보관하는 저장 형식이다. 프로토콜 이름이 아니며 디렉터리 권한·소유자와 메일함 정책이 접근에 영향을 준다.
: 여러 메시지를 하나의 파일에 이어 저장하는 형식이다. 파일 잠금과 동시 접근을 지원하는 구현 규칙을 따라야 한다.
: 사용자 등의 메일 보관량을 제한하는 기능이다. 파일 시스템 전체의 여유 공간과는 별도 제한이므로 둘을 나누어 판단한다.

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 구성이 필요하며 비밀 값은 입력하지 않는다.
확인 기준
접수, 큐 처리, 사서함 저장, 조회를 구분한다. 화면에 없는 성공을 추정해 완료로 표시하지 않는다.