메일 연결이 끊겼다. 서버는 6,135바이트를 이미 받았다고 했다

Summary

• 1995년의 실험적 RFC 1845는 CHECKPOINT 지원 표시와 개별 전송용 TRANSID, 수신 서버의 비휘발성 상태 저장으로 중단된 SMTP 작업을 이어 가게 했다.
• 예시의 355 6135는 저장된 메시지 데이터가 6,135바이트라는 응답이다. 발신자·수신자 명령과 SMTP의 점 채우기로 추가된 바이트는 이 숫자에 넣지 않는다.

큰 메일을 불안정한 회선으로 보낼 때 연결이 거의 끝에서 끊긴다면, 원래 SMTP는 이미 보낸 본문을 다시 보낼 수밖에 없었다. 한 번 더 끊기면 다시 처음이다. D. Crocker, N. Freed, A. Cargille이 1995년 9월 제안한 실험적 확장은 그 낭비에 영수증을 붙였다. 수신 측이 저장한 지점을 알려 주면 송신 측은 남은 부분을 보낸다. RFC의 6,135바이트는 이 절차를 설명하기 위한 예시 수치다.

영수증에는 거래 번호가 필요했다. 송신 측이 EHLO를 보냈을 때 수신 측이 CHECKPOINT를 광고해야 기능을 사용할 수 있다. 다음 MAIL FROM에는 대소문자를 구별하는 TRANSID가 붙는다. 이 번호는 메일 한 통 전체가 아니라 한 SMTP 링크를 건너가는 특정 사본의 전송에 붙는다. 메일 헤더의 Message-ID는 여러 경로로 나뉜 사본이 공유할 수 있다. 그 이름을 진도표에 쓰면 다른 사본이 저장해 둔 부분을 자기 진도라고 착각할 수 있다.

수신 서버도 책임을 진다. 번호와 최신 상태를 비휘발성 저장소에 남겨야 한다. RFC는 끊긴 작업의 상태를 적어도 48시간 보관하라고 권고하지만, 정확한 기간은 서버 운영 정책에 맡긴다. 송신 측은 기존 연결이 정리될 시간을 기다린 뒤 DNS를 다시 확인한다. 원래 접속한 주소가 여전히 유효하면 먼저 시도하고, 이어 다른 유효한 주소도 시도한다. 다른 서버에 저장 상태가 없다면 전체 작업을 다시 보낸다. 오래된 서버가 돌아오기만 무한정 기다리는 것은 허용되지 않는다.

다시 연결했을 때 송신 측은 똑같은 TRANSID로 MAIL FROM을 보낸다. 355 6135는 수신 측이 성공적으로 저장한 메시지 데이터의 바이트 수이며, 다음에 받을 바이트의 위치다. MAIL FROM과 RCPT TO는 계산 밖이다. 줄 맨 앞의 점을 보호하려고 SMTP가 덧붙인 바이트도 계산 밖이다. DATA 명령으로 보냈다면 재개 지점은 줄의 시작이어야 한다. 로컬 파일의 6,135번째 바이트를 무작정 찾아가는 방법은 이 규칙을 대신하지 못한다.

RFC의 대화는 같은 거래 번호, 355 응답, 남은 DATA, 그리고 250 OK로 끝난다. 송신 측이 전체 본문 흐름을 다시 만든 뒤 앞부분만 출력하지 않는 구현도 문서는 허용한다. 중요한 절약은 이미 저장된 앞부분을 회선에 다시 실어 보내지 않는 데 있다.

6,135라는 숫자는 수신 서버가 그 거래에 대해 보관한 앞부분의 범위만 증명한다. 사람이 메일을 읽었다는 표시는 아니다. 메일의 모든 사본을 한꺼번에 식별하는 이름도 아니다. 범위를 작고 정확하게 잡았기에, 회선이 끊긴 뒤에도 다음 동작을 정할 수 있었다.