SMTP
Simple Mail Transfer Protocol · 메일 전송 프로토콜
는 메일을 제출하거나 서버 사이에 전달하기 위한 명령·응답 프로토콜이다. 운송용 봉투와 메시지 헤더를 구분하며 수신자별 수락 상태와 DATA 이후 최종 응답으로 처리 책임의 이전을 판단한다.
밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.
01무엇이고, 어떤 일을 하나
- 메일 발신자·수신자와 메시지 내용을 순서 있게 전달한다.
- 확장 기능· 승격·을 협상한다.
- 일시 실패·영구 실패·수락 결과를 응답 코드로 표현한다.
02어떤 순서로 동작하나
- 인사와 확장
서버의 220 뒤 EHLO로 기능을 확인한다. STARTTLS를 사용하면 준비 응답· 협상 뒤 EHLO를 다시 수행한다.
- 제출 인증
사용자 제출 경로에서는 정책에 따라 AUTH를 수행한다. 일반적인 MTA 간 전달에 같은 을 일괄 요구하지 않는다.
- 봉투 지정
과 수신자별 를 보낸다. 각 수신자의 수락·거부 결과를 따로 관리한다.
- 본문과 최종 응답
DATA의 뒤 헤더·빈 줄·본문·종료 표시를 보내고 마지막 응답을 확인한다. 은 해당 서버의 책임 수락이지 수신자의 읽음 증거가 아니다.
03먼저 알아둘 용어와 구성요소
- 은 전송 실패 통지의 반환 경로와 관련된 봉투 값이다. 메시지 본문의 From 헤더와 같을 필요가 없고 화면에 표시된 발신자만으로 봉투를 알 수 없다.
- 는 수신자마다 따로 제출한다. 한 RCPT가 거부되어도 다른 RCPT가 수락될 수 있어 메시지 한 건에 수신자별 다른 상태가 생긴다.
- DATA에 대한 는 내용을 보내라는 중간 응답이다. 아직 전체 메시지를 최종 수락했다는 뜻이 아니며 전송 끝의 최종 응답까지 읽어야 한다.
- 본문 종료 뒤 을 받으면 해당 서버가 수락한 수신자에 대한 배달 또는 후속 처리 책임을 받는다. 사용자가 읽었다거나 모든 다음 홉이 배달했다는 증명은 아니다.
- 4yz는 해당 시도에서의 일시 실패, 5yz는 그 요청에 대한 영구 실패를 나타낸다. 인증·주소·정책·저장 용량 등 구체 원인은 코드와 부가 설명, 서버 기록을 함께 읽는다.
- 본문 줄이 점으로 시작하면 점을 하나 더 붙이는 으로 종료 표시와 구분한다. 이후 은 그 서버가 메시지 처리 책임을 수락했음을 뜻한다.
SMTP 수신자 거부와 STARTTLS 이후 가시성 구별하기
서버 인사·발신자 수락·수신자 거부· 전환이 서로 다른 상태라는 점을 화면으로 추적한다.
실습 구성과 전제
- 첫 사진은 로컬 대화의 수신자 거부, 두 번째는 별도 연결의 STARTTLS 패킷 사례다. 같은 메일 한 건을 끝까지 전송한 기록이 아니다.
- 실제 메일 발송이나 을 수행하지 않는 해석 실습이다. 주소는 example.test와 문서용 값으로 재구성한다.
응답 코드를 어느 명령의 결과인지 짝짓는다
- 220은 서버가 대화를 받을 준비가 되었다는 인사다. 뒤의 은 봉투 발신자 수락이며 최종 메일 배달 완료가 아니다.
- 뒤 550 5.1.1은 해당 수신자를 수락하지 않은 영구 실패 응답이다. 이 수신자가 거부되었으므로 화면을 성공 발송 사례로 설명할 수 없다.
textS: 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와 메시지 종료, 서버의 최종 접수 응답을 확인해야 큐에 받은 사실을 말할 수 있다. 그 후 실제 배달과 조회는 또 다른 단계다.
- 시험을 재구성한다면 인증정보 없이 인증서 검증과 협상 결과만 확인한다. 서버 이름과 신뢰 체인이 맞는지까지 읽어야 암호화 연결의 상대를 확인할 수 있다.
bashopenssl s_client -starttls smtp -connect mail.example.test:587 -servername mail.example.test -verify_hostname mail.example.test -verify_return_error -crlf준비한 실습 제출 서버의 를 확인하는 재구성 예시다. 실제 서버명과 신뢰할 CA 구성이 필요하며 비밀 값은 입력하지 않는다.
확인 기준접수, 큐 처리, 사서함 저장, 조회를 구분한다. 화면에 없는 성공을 추정해 완료로 표시하지 않는다.
실습에서 확인한 동작 원리
- 응답 코드는 바로 앞 명령과 연결해야 의미가 분명하다.
- 전환은 이후 내용의 관찰 가능성을 바꾸며, 성공과 메일 배달 성공은 별개다.
04예제로 따라가기
- 수신자 A의 RCPT는 , B의 RCPT는 550이라면 같은 메시지라도 B까지 정상 수락됐다고 집계하지 않는다.
- 메시지의 To 헤더에 표시되지 않은 Bcc 수신자도 envelope의 에는 포함될 수 있다.
- 서버가 큐에 넣은 뒤 마지막 이 연결 단절로 사라지면 발신 측에는 수락 여부가 불명확하여 재시도가 중복 배달로 이어질 수 있다.
05혼동하기 쉬운 점과 확인 기준
- 서버가 부여한 큐 ID는 그 서버의 처리 기록을 연결하는 단서다. 다음 서버로 넘어가면 다른 큐 ID를 받을 수 있어 전체 경로를 하나의 로컬 큐 ID로만 찾지 않는다.
- 메시지 헤더의 Message-ID는 메시지 식별에 도움을 주지만 자체가 배달 성공 영수증은 아니다. 응답과 각 홉의 처리 기록이 별도로 필요하다.
- 같은 명령을 빠르게 반복해 영구 거부를 없앨 수는 없다. 일시 실패도 재시도 간격·보관 한도·실패 통지 정책 아래 처리해야 불필요한 중복과 부하를 줄일 수 있다.
06상세 노트 · 실습 자료
헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.
공식 문서 · 표준
기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.