요약

  • 1982년 8월 개정판은 SMTP를 양단이 동일한 전송 서비스를 공유하지 않아도 호스트 간에 메일을 릴레이할 수 있는 신뢰성 있는 스트림 대화로 정의했습니다.
  • MAIL은 역방향 경로를, RCPT는 하나 이상의 순방향 경로를 제공했습니다. RFC 822는 텍스트 메시지 형식을 별도로 규정했으므로, SMTP 교환이 성공했다는 것 자체가 메일함 사용이나 사람의 수신을 증명하지는 않습니다.

이메일은 메시지 자체가 자신을 실어 나른 네트워크를 알지 못한 채 네트워크 경계를 넘을 수 있습니다. 1982년 8월 Jonathan B. Postel이 발표한 Simple Mail Transfer Protocol 사양에서 드러난 설계 과제가 바로 이것이었습니다. RFC 821은 특정 전송 하위 시스템을 요구하지 않았습니다. 신뢰성 있고 순서가 보장되는 데이터 스트림을 요구한 뒤, SMTP 프로세스들이 그 채널을 통해 명령과 응답을 주고받는 방식을 기술했습니다.

이 사양은 릴레이를 모델의 일부로 만들었습니다. 발신 호스트와 목적지 호스트가 동일한 전송 서비스를 공유한다면 발신 측은 수신 SMTP 프로세스에 직접 접속할 수 있었습니다. 그렇지 않다면 하나 이상의 중간 SMTP 서버가 전송 서비스 환경 사이를 이어줄 수 있었습니다. Postel은 연결의 단위에 대해 신중했습니다. 하나의 전송 서비스는 한 네트워크를, 여러 네트워크를, 혹은 한 네트워크의 일부만을 다룰 수 있었습니다. 다이어그램에서 “네트워크”와 “전송 환경”은 서로 바꿔 쓸 수 있는 상자가 아니었습니다.

트랜잭션은 릴레이 판단을 가독하게 만들었습니다. 발신 측이 양방향 채널을 열면 수신 측이 응답했습니다.MAIL은 비전달 정보가 되돌아가야 할 역방향 경로를 담아 트랜잭션을 시작했습니다. 각RCPT명령은 수신자 하나에 대한 순방향 경로를 제공했고, 명령은 반복될 수 있었습니다. 이어서DATA가 메시지를 실었습니다. 수신자의 숫자 응답은 명령 하나하나 수준에서 수용 또는 실패를 가시화했습니다. 따라서 SMTP 봉투는 메시지 안의 문장과 필드와는 별개인 전달 지시를 담고 있었습니다.

이 구분은 같은 달에 발표된 RFC 822와 RFC 821을 함께 읽을 때 중요합니다. RFC 822는 ARPA 인터넷 텍스트 메시지의 형식을 표준화했고, RFC 821은 전송 대화를 규정했습니다. 두 문서는 같은 메일 이벤트를 서로 다른 면에서 다뤘습니다.From:헤더는 메시지 표현의 일부였지만,MAIL FROM은 SMTP 전송 트랜잭션에 속했습니다. 이 둘을 혼동하면 텍스트로 적힌 주소가 경로나 전달 판단의 증거로 바뀌는데, 사양은 그런 것을 지지하지 않습니다.

RFC 821은 또한 개정판이었지 SMTP의 탄생 증서가 아니었습니다. 문서 머리말은 RFC 788, 780, 772를 대체한다고 밝히며, 1981년 11월자 RFC 788이 이미 SMTP를 규정하고 있었습니다. RFC 801의 전환 계획은 네트워크 전환의 맥락에서 SMTP 서비스를 언급하지만, 채택 수나 사용자 전달 성공에 대한 어떤 측정치도 제공하지 않습니다. 개정된 프로토콜 문서의 날짜는 모든 호스트가 이를 구현한 시점을 대신할 수 없습니다.

이 모델이 TCP 전용이었던 것도 아닙니다. RFC 821의 부록은 NCP, TCP, NITS를 포함한 서로 다른 전송 서비스를 기술하며, TCP 부록은 SMTP 소켓 번호로 25를 지정합니다. 이 세부 사항은 프로토콜을 구체화하지만, 25번 포트를 여는 것이 실제 동작 중인 메일 서비스를 증명한다는 의미는 아닙니다. 호스트는 여전히 동작 중인 수신자, 수용되는 명령, 올바른 경로, 메시지 트랜잭션, 그리고 채널 너머의 로컬 처리를 갖추어야 했습니다.

역사적 기여는 이동할 수 있는 경계였습니다. SMTP는 메일 이동을 위한 공통 대화를 정의하고, 릴레이가 전송 환경 사이의 도달 가능성을 번역하도록 허용했으며, 메시지 형식과 로컬 메일함 동작은 별개의 문제로 남겨두었습니다. Lu Heng의 Note 64를 통해 읽어보면, 이 설계는 공유 사양에 대한 유용한 한계를 보여줍니다. 교환을 상호 운용에 충분할 만큼 정밀하게 만들되, 전송 방식 선택과 배포는 그것을 운용하는 시스템에 맡기라는 것입니다. 이는 분석의 렌즈이지 RFC 저자의 의도에 대한 주장이 아닙니다.

출처