요약

  • 초기 SMTP는 발신자가 DATA 객체 전체를 전송하고 수신자가 이를 폐기한 뒤에야 크기 또는 저장 공간 실패를 알 수 있었습니다.
  • RFC 1870은 서버가 EHLO에서 고정 최대값을 광고하고 클라이언트가 MAIL FROM에 추정 옥텟 수를 선언할 수 있게 했습니다. 영구 정책 위반은 552, 일시적 자원 부족은 452를 반환할 수 있었습니다.
  • 그 숫자는 의도적으로 약한 증거였습니다. 이는 DATA를 종료하지 않고, 이후 저장 공간을 모두 예약하지 않으며, 내용을 인증하지 않고, MAIL에 대한 성공 응답을 릴레이나 전달의 보장으로 만들지 않았습니다.

비용이 지불된 뒤에 오는 거부

RFC 821은 메일 전송을 하나의 절차로 만들었습니다. 발신자는MAIL로 시작하고,RCPT로 한 명 이상의 수신자를 지명한 뒤,DATA를 요청합니다. 354 응답 이후 메시지와 그 종료 줄을 전송합니다. 완성된 객체에 대한 결정적 응답은 그제서야 수신자가 내립니다.

이 절차는 트랜잭션의 명확성을 보호했지만, 일부 자원 지식을 늦게 배치시켰습니다. 서버는 자신이 고정 크기 이상의 객체를 결코 수용하지 않는다는 것을 알 수도 있습니다. 또는 특정 메시지를 버퍼링하다가 단순히 공간이 부족해질 수도 있습니다. 확장되지 않은 SMTP에서 클라이언트는 모든 옥텟을 보낸 뒤에야 이 두 사실 중 하나를 알 수 있었습니다. 서버는 그때 객체를 폐기했고, 릴레이나 사용자는 성공적으로 끝날 가능성이 전혀 없는 전송에 비용을 지불했습니다.

멀티미디어 메일이 늘어나면서 이 낭비는 단순한 예외적 사례 이상이 되었습니다. 문제는 원격 발신자에게 서버의 디스크에 대한 통제를 주는 방법이 아니었습니다. 양측이 명백히 무의미한 작업을 피할 수 있도록 충분한 로컬 증거를 공개하는 방법이었습니다.

하나의 약속이 아니라 두 개의 선언

이 확장은 1993년RFC 1427에서 처음 등장했고,RFC 1653으로 수정되었으며, 1995년 표준 트랙 형태인RFC 1870에 이르렀습니다. 이 확장의 경제성은 서로 다른 두 개의 선언을 사용하는 데 있습니다.

확장을 지원하는 수신자는 EHLO 응답에SIZE를 나열합니다. 여기에 자신이 받아들이는 가장 큰 메시지를 설명하는 10진수를 덧붙일 수 있습니다. 이는 구현이나 관리가 선택한 고정 상한입니다. 0 매개변수는 고정 최대값이 적용되지 않음을 의미합니다. 서버가 숫자 없이SIZE만 말한다면, 지원은 밝혔지만 고정 최대값에 대한 정보는 드러내지 않은 것입니다. 한계에 대한 침묵은 무한대가 아니라 불확실성입니다.

이후 발신자는MAIL FROM에SIZE매개변수를 추가할 수 있습니다. 이 두 번째 숫자는 서버의 규칙이 아니라, 전송하려는 특정 메시지에 대한 클라이언트의 추정치입니다. 이상적으로는 추정이 실제와 일치합니다. 정확한 계산이 비현실적일 때 RFC 1870은 휴리스틱을 허용하고 높게 치우치도록 권고합니다. 각 측이 서로 다른 사실의 소유권을 유지하기 때문에, 공유된 이 값이 유용한 것입니다.

전송되는 객체의 계산

상호 운용에는 추정치가 무엇을 세는지에 대한 합의가 필요했습니다. RFC 1870은 메시지 크기를 354 응답 이후에 전송되는 옥텟으로 정의합니다. 헤더, 본문, 그리고 줄 사이의 CR-LF 쌍입니다. 여기에는 마침표 하나만 있는 DATA 종료자와 SMTP 점 투명성을 위해 삽입된 추가 마침표는 제외됩니다.

이 경계는 역사적으로 중요합니다. 인접한 SMTP 프레이밍 문제는 내용이 어디서 끝나는지를 묻습니다. SIZE는 그에 답하지 않습니다. 수신자는 선언된 숫자를 DATA를 종료하는 데 사용해서는 안 됩니다. 잘못된 추정은 수용 여부에 영향을 줄 수 있지만, 파서가 내용을 명령으로 취급하게 만들 수는 없습니다. 오래된 DATA 종료자가 프레이밍에 대한 권위를 계속 유지합니다.

따라서 이 설계는 주장을 구조화하지 않으면서 측정 가능하게 만들었습니다. 운영자는 선언된 크기와 관찰된 크기를 비교할 수 있습니다. 구현은 과소 추정을 허용하거나 거부할 수 있습니다. 어느 쪽도 추정치가 정확한 바이트 계산 전송 봉투라고 가장할 필요가 없었습니다.

영구 정책과 일시적 부족

확장된 MAIL 명령을 본 서버는 일찍 결정할 수 있습니다. 선언이 자신의 고정 최대값을 초과하면552를 반환할 수 있습니다. 동일한 정책 하에서 같은 메시지를 나중에 재시도해도 도움이 되지 않는 경우입니다. 서버가 현재 자원이 부족하지만 나중에 메시지를 받아들일 수 있다면452를 반환할 수 있습니다. 클라이언트는 리셋하거나 종료하여 시도를 다시 큐에 넣어야 합니다.

이 구분은 오류 어휘 이상을 담고 있습니다. 이는 미래의 작업을 배분합니다. 영구 거부는 반복되는 릴레이 시도를 소모하는 대신 발신자 쪽으로 되돌아가야 합니다. 일시적 거부는 시간을 합법적인 회복 경로로 남겨둡니다. 둘을 혼동하면 무의미한 재시도를 낳거나 성공했을 수 있는 전달을 파괴합니다.

크기는 수신자별로 다를 수도 있습니다. 서버는 선언된 메시지 크기를 근거로 한RCPT에 대해서는 트랜잭션을 수용하고 다른 수신자에게는 452 또는 552를 반환할 수 있습니다. 따라서 하나의 전송 객체는 서로 다른 로컬 메일함 또는 채널 정책을 만나게 됩니다. 공유된 추정치가 수신자의 자율성을 평탄화하지는 않습니다.

이른 허가는 여전히 잠정적

RFC 1870은 MAIL에서의 250을 절대적 보장으로 만들기를 신중히 거부합니다. 저장 공간은 바뀔 수 있습니다. 이후의 명령이 실패할 수 있습니다. 실제 DATA 객체가 선언을 초과할 수도 있습니다. 릴레이와 최종 전달은 이른 결정의 범위 밖에 남습니다.

서버는 선언보다 큰 객체를 수용할 수 있으나 그럴 의무는 없습니다. 선언된 크기에 동의했다면, 실제 메시지가 선언을 초과한 경우가 아니라면 자신의 정상적 고정 한계만을 이유로 DATA 이후 552를 발행해서는 안 됩니다. 이는 보편적인 예약을 발명하지 않으면서 유용한 의존을 만듭니다. 매개변수 없는 SIZE 광고에는 더 강한 로컬 규칙이 있습니다. 선언된 MAIL 명령을 긍정적으로 수용하기 전에, 서버는 충분한 자원을 확인해야 하고 가능하다면 저장 공간을 예약해야 합니다.

이 절제가 이 메커니즘의 중심 성취입니다. 확장은 하나의 판정을 앞당겼지만, 모든 이후 판정을 가시적으로 남겨두었습니다. 낭비되는 바이트를 줄이면서도 용량, 정책, 프레이밍, 저장 공간, 전달을 하나의 응답 코드로 붕괴시키지 않았습니다.

불평등한 기계들을 위한 얇은 계약

RFC 5321은 이후 서버가 최소 64K 옥텟을 수용하도록 요구하고, 제한을 둬야 하는 시스템에 SIZE를 구현하도록 권고했습니다. 이는 전역적으로 허용되는 첨부 파일 크기를 확립하지 않았습니다. 메일은 서로 다른 디스크, 큐, 수신자, 정책을 가진 릴레이를 건넙니다. 유용한 공통 규칙은 그 경계를 소유하는 지점에서 그 하나의 경계를 표현하는 방법이었습니다.

확장이 없는 오래된 SMTP 피어는 계속 운영하며 늦은 실패를 받을 수 있습니다. 지원하는 클라이언트는 자신의 추정치를 선언하지 않고 광고된 상한만 사용할 수 있습니다. 더 완전한 구현은 MAIL 또는 RCPT에서 일시적 용량과 수신자별 한계를 노출할 수 있습니다. 도입은 네트워크 전체의 전환을 요구하지 않고 지역적으로 깊어질 수 있었습니다.

이 유연성은 책임성도 보존합니다. 발신자는 추정치를 소유합니다. 수신 서버는 광고된 상한과 현재 자원을 소유합니다. 각 수신자 경로는 자신의 수용을 소유합니다. 프로토콜은 구문과 재시도 가능한 거부와 최종 거부의 구분만을 소유합니다.

출처와 한계

원래의 트랜잭션과 늦은 DATA 응답은 RFC 821에서 나옵니다. 확장 계보는 RFC 1427, RFC 1653, RFC 1870입니다. RFC 1870은 현재의 계산 규칙, EHLO 상한, MAIL 추정치, 452/552 구분, 수신자별 처리, 이른 성공이 보장이 아니라는 경고를 제공합니다. RFC 5321은 이후의 기준선과 권고를 기록합니다.

이 사양들은 현재의 배포 상황이나 어떤 공급자의 한계도 측정하지 않습니다. 광고된 상한이 사용 가능한 메일함 할당량과 같음, 250 응답이 모든 다운스트림 자원을 예약함, SIZE가 메시지를 검증함을 증명하지 않습니다. 이들은 더 좁은 역사를 뒷받침합니다. 선언된 측정은 독립적으로 운영되는 릴레이들이 최종 권한을 로컬에 두고 수정 가능하게 유지하면서 일부 헛될 전송을 피할 수 있게 했다는 역사입니다.