요약

  • SMTP의 DATA 단계는 마침표 하나만 있는 줄에서 끝나므로, 사용자 메시지 안에 동일한 줄이 있을 경우 되돌릴 수 있는 투명성 규칙이 필요했습니다.
  • 송신 측은 줄 맨 앞의 마침표를 모두 하나씩 복제했고, 수신 측은 마침표 하나뿐인 종결 줄을 인식한 뒤 그 밖의 해당 줄에서 마침표 하나를 제거했습니다.
  • 이후 CHUNKING은 메시지 데이터를 정확한 옥텟 수와 명시적 마지막 청크로 프레이밍하여 금지된 시퀀스를 없애고 바이트 계산을 권위 있는 기준으로 만들었습니다.

하나의 채널이 역할을 바꿔야 했다

RFC 821의 SMTP 대화는 의도적으로 로크스텝 방식입니다. 송신 측이 명령을 보내면 수신 측이 응답하고, DATA는 그 동일한 순서화된 스트림을 일시적으로 메일 본문으로 바꿉니다. 프로토콜은 이제 본문이 끝나고 명령이 다시 시작될 수 있는 명확한 지점이 필요합니다.

선택된 표식은 단순했습니다. 마침표만 있는 줄입니다. 단순성 덕분에 세션이 읽기 쉽고 구현이 작게 유지되었습니다. 그러나 동시에 프로토콜적 의미를 사용자 텍스트의 네임스페이스 안에 넣어버렸습니다. 완전히 평범한 줄이 제어 메시지와 똑같이 보일 수 있었던 것입니다.

투명성은 양방향 약속이었다

SMTP는 그런 텍스트를 금지하지 않았습니다. 전송 전에 송신 측은 각 줄을 검사하여 첫 문자가 마침표이면 하나를 더 삽입합니다. 수신 시에는 마침표 하나만 있는 줄이 DATA를 끝내고, 그 밖에 마침표로 시작하는 줄은 첫 마침표를 잃습니다.

이 연산은 훗날 닷 스터핑(dot stuffing)으로 알려졌습니다. 중요한 성질은 가역성입니다. 전송 형태는 사용자의 메시지와 다르지만, 규격을 준수하는 종단은 전달 전에 메시지를 복원합니다. RFC 821은 중계 과정에서 적용되는 변환은 반드시 가역적이어야 한다고 경고했습니다.

이 규칙은 책임을 균등하게 배분합니다. 송신 측은 모호해질 수 있는 본문을 보호하고, 수신 측 단독으로 표식을 해석하며 보호를 해제합니다. 어느 한쪽이 자기 몫을 건너뛰면 메시지가 조기 종료되거나 문자 하나가 추가될 수 있습니다.

작은 예외가 모든 줄 스캐너의 일부가 되었다

RFC 5321은 수십 년 뒤에도 같은 투명성 절차를 유지합니다. 심지어 복제된 추가 마침표는 1000옥텟 텍스트 줄 최대 길이에 포함되지 않는다고 명시합니다.

이 예외는 프레이밍이 파싱을 넘어선다는 것을 보여줍니다. 버퍼 한도, 중계기, 로깅, 테스트 케이스는 자신이 관찰하는 것이 저장된 메시지인지, 정규화된 SMTP 텍스트인지, 아니면 투명성 처리 이후의 와이어 형태인지 알아야 합니다. "마침표 하나 더"는 바이트로는 작지만 상태로는 큽니다.

바이트 수가 금지된 줄을 없앴다

RFC 3030의 CHUNKING 확장은 DATA의 대안으로 BDAT를 도입했습니다. BDAT 명령은 뒤따르는 옥텟의 정확한 개수를 선언하고, 선택적 LAST는 마지막 청크를 표시합니다. 수신 측은 더 이상 본문을 스캔해 종결자를 찾지 않으므로, 마침표만 있는 줄은 그 청크 안에서 어떤 특별한 힘도 갖지 않습니다.

이것이 보편적 대체는 아닙니다. 서버는 EHLO를 통해 CHUNKING을 광고하고, 클라이언트는 그 선언 이후에만 이를 선택하며, 이를 지원하는 서버는 DATA도 계속 받아들여야 합니다. 기능 협상은 상대의 입력을 재정의하는 대신 오래된 피어를 보전합니다.

센티넬에서의 해방이 계산을 주권적 기준으로 만들었다

길이 기반 프레이밍은 실패 양상을 바꿉니다. 송신 측은 정규화된 옥텟 수를 정확히 계산해야 합니다. 선언된 크기와 전송된 바이트가 다르면 수신 측의 경계가 움직입니다. 데이터가 청크 안으로 삼켜지거나 명령 파서에 노출될 수 있습니다.

따라서 BINARYMIME은 CHUNKING에 의존합니다. 임의의 옥텟은 DATA의 줄 지향 센티넬을 안전하게 사용할 수 없습니다. BINARYMIME을 수락한 수신 측은 BDAT를 통과하는 모든 비트를 보존할 것을 약속하고, 송신 측도 정확한 프레이밍과 정규화된 MIME 요구를 준수해야 합니다.

새로운 방식이 신뢰를 없앤 것은 아닙니다. 신뢰를 본문 변환에서 산술과 사전 기능 합의로 옮겼을 뿐입니다.

출처와 한계

이 역사는RFC 821,RFC 5321,RFC 3030에 기록되어 있습니다. 이 문서들은 요구사항을 확립할 뿐, 채택률이나 사건 빈도는 담고 있지 않습니다. DATA는 CHUNKING을 지원하는 서버에서 여전히 필수이며, 닷 투명성은 프레이밍이지 암호화, 인증, 메시지 무결성 보호가 아닙니다.