[SMTP] 6. 메일은 어디에 남아야 할까

지난 글에서는 DATA 명령을 구현했다.이제 SMTP 클라이언트는 서버에게 봉투를 건넨 뒤, 실제 메일 내용을 보낼 수 있게 되었다.이 흐름만 보면 꽤 그럴듯하다.서버는 MAIL FROM으로 봉투 발신자를 받았다.RCPT TO로 봉투 수신자도 받았다.DATA 이후에는 제목과 본문이 들어 있는 메일 내용도 받았다.그리고 마지막 마침표 한 줄을 만나면 250 OK를 돌려줬다.하지만 지난 구현에는 중요한 빈틈이 있었다.메일을 받기는 했지만, 그 메일은 어디에도 남지 않았다.로그에 찍히고 끝이었다.메일 수신 완료:From: Alice To: Bob Subject: HelloHello SMTP. 서버 화면에는 보인다.하지만 서버를 종료하면 사라진다.로그를 지우면 사라진다.다시 꺼내볼 방법도 없다.그렇다면 이 서버..

• format_list_bulleted Deep Dive/기타
• · 2026. 5. 7.
• textsms

[SMTP] 5.5. 부록-메일을 보내지는 않지만 필요한 명령들

이번 글에서는 DATA까지 구현했다.이제 서버는 SMTP 클라이언트와 인사하고, 봉투를 받고, 본문을 받은 뒤, 마침표 한 줄로 메일 데이터가 끝났다는 것도 알아볼 수 있다.여기까지 오면 메일 한 통을 받는 가장 중요한 흐름은 대략 보인다.하지만 RFC 5321의 최소 구현 목록을 보면 아직 몇 가지 명령이 더 남아 있다.이번에 추가한 것은 RSET, NOOP, VRFY다.이 명령들은 MAIL FROM, RCPT TO, DATA처럼 메일을 직접 구성하는 주인공은 아니다.대신 SMTP 세션 중간에서 상태를 정리하거나, 연결이 살아 있는지 확인하거나, 주소 확인을 요청하는 보조 명령에 가깝다.RSET: 지금 쓰던 편지는 취소하겠습니다먼저 RSET이다.C: RSETS: 250 OK RSET은 현재 진행 중인 ..

• format_list_bulleted Deep Dive/기타
• · 2026. 5. 7.
• textsms

[SMTP] 5. 본문은 언제 끝났다고 말할까

지난 글에서는 메일의 봉투를 만들었다.SMTP 서버와 인사를 나눈 뒤, 클라이언트는 먼저 봉투 발신자를 말했다.C: MAIL FROM:S: 250 OK그리고 봉투 수신자를 말했다.C: RCPT TO:S: 250 OK이때까지 우리는 아직 메일 본문을 보내지 않았다.제목도 없었다.내용도 없었다.사용자가 실제로 읽을 수 있는 문장도 없었다.하지만 서버는 이미 중요한 정보를 알고 있었다.이 메일은 누구에게서 왔는가이 메일은 누구에게 배달되어야 하는가이제 남은 것은 편지 내용이다.메일 화면에서 우리가 보는 것들.From:, To:, Subject: 같은 헤더.그리고 실제 본문.이제 드디어 그것을 서버에게 건네볼 차례다.그런데 여기서 새로운 질문이 생긴다.본문은 언제 끝났다고 말할까?DATA는 편지지를 건네겠다는 ..

• format_list_bulleted Deep Dive/기타
• · 2026. 5. 7.
• textsms

[SMTP] 4. 봉투와 편지는 다르다.

지난 글에서는 SMTP 서버와 처음으로 대화해봤다.TCP 연결을 열면 클라이언트가 먼저 말하는 것이 아니라, 서버가 먼저 인사했다.S: 220 localhost Simple Mail Transfer Service Ready 그다음 클라이언트는 자신이 누구인지 말했다.C: EHLO client.localS: 250-localhost greets client.localS: 250 HELP 아주 짧은 대화였지만, 이때부터 이메일은 조금 다르게 보이기 시작했다.이전까지 이메일은 화면에서 보는 것이 전부인 줄 알았다.보내는 사람, 받는 사람, 제목, 본문.메일 앱에서 보이는 그 정보들이 곧 이메일이라고 생각했다.하지만 SMTP 서버와 직접 대화해보니 순서가 조금 달랐다.서버와 인사를 마친 뒤, 클라이언트는 곧바로..

• format_list_bulleted Deep Dive/기타
• · 2026. 5. 7.
• textsms

[SMTP] 3. SMTP 서버와 첫 대화: 서버가 먼저 인사한다

지난 글에서는 이메일이 어디에서 어디로 이동하는지 대략적인 지도를 그려봤다. 그리고 gmail과의 통신도 짧게나마 살펴보았다.처음에는 단순히 이렇게 생각했다.보내는 사람 → 받는 사람 하지만 조금만 안쪽으로 들어가보니 그 사이에는 여러 역할이 있었다. 메일을 작성하는 프로그램이 있고, 메일을 전달하는 서버가 있고, 중간에서 다시 전달하는 서버가 있고, 최종적으로 사용자의 메일함에 저장하는 서버가 있었다.그리고 그 흐름 어딘가에서 SMTP가 등장했다.SMTP는 메일을 읽는 기술도 아니고, 메일 화면을 보여주는 기술도 아니었다. SMTP는 메일을 다른 곳으로 전송하기 위한 약속에 가까웠다.그렇다면 이제 다음 질문으로 넘어갈 수 있다.SMTP 서버와 실제로 대화하려면 무엇부터 해야 할까?메일을 보내려면 먼저 ..

• format_list_bulleted Deep Dive/기타
• · 2026. 5. 7.
• textsms

[SMTP] 2. SMTP 지도 그리기: 메일은 어디에서 어디로 가는가

1. 지난 글에서 남은 질문이전글에서 우리는 이런 질문으로 출발했다.우리 서버가 직접 이메일을 보낼 수 있을까?하지만 이 질문에 바로 답하려고 하면 조금 막막하다.이메일을 “보낸다”는 말이 생각보다 넓기 때문이다. 사용자가 메일을 작성하는 것도 보내는 과정처럼 보이고, 우리 서버가 다른 서버에 전달하는 것도 보내는 과정처럼 보이고, 수신자가 메일함에서 읽는 것도 전체 흐름 안에 들어있다.그래서 구현을 시작하기 전에 먼저 지도를 그려보려고 한다.메일은 어디에서 출발해서 어디까지 가는 걸까?메일은 어디에서 출발해서 어디까지 가는 걸까?그리고 그중에서 SMTP는 정확히 어느 구간을 담당하는 걸까?2. 이메일에는 여러 역할이 있다처음에는 이메일 시스템이 단순하게 보인다.보내는 사람 → 받는 사람하지만 실제로는 ..

• format_list_bulleted Deep Dive/기타
• · 2026. 5. 7.
• textsms