요약

  • 8BITMIME은 SMTP 클라이언트가 MIME 본문에 상위 비트 옥텟이 포함되어 있음을 선언할 수 있게 했지만, 현재 홉의 수신 서버가 그 기능을 광고한 뒤에만 가능했습니다.
  • 수락은 비트 보존 관리 의무를 부과했습니다. 다음 홉이 기능을 갖추지 못한 릴레이는 무손실이고 유효한 7비트 MIME을 만들거나 실패해야 했으며, DATA 프레이밍과 행 길이 제한은 여전히 임의의 바이너리를 배제했습니다.

메시지와 그 길은 서로 다른 계약이었다

MIME은 전자우편에 미디어 타입, 문자 집합, 전송 인코딩을 위한 어휘를 제공했습니다. 이는 기술(記述) 문제를 해결한 것입니다. 메시지는 자신의 본문이 무엇을 의미하는지, 그 표현을 어떻게 디코딩해야 하는지 말할 수 있게 되었습니다. 그러나 이것이 SMTP가 메시지를 운반하는 그 길 자체를 넓혀준 것은 아닙니다.

예전의 길은 7비트였습니다.RFC 2045는7bit,8bit,binary전송 도메인을 구분합니다. 악센트 문자를 담은 본문은 MIME으로서 완전히 의미 있을 수 있지만, 그 옥텟의 상위 비트를 다음 SMTP 릴레이가 보존하겠다고 약속한 적은 없을 수 있습니다. 콘텐츠의 정체성과 전송 허가는 별개의 사실입니다.

그렇기 때문에 8BITMIME의 역사는 단순히 비영어권 전자우편의 역사가 아닙니다. 이는 책임 소재를 확정한 역사입니다. 알 수 없는 경로상의 모든 기계가 8비트 데이터를 견딜 것을 바라는 대신, 발신자와 수신자는 각 연결마다 좁은 계약을 만들어냈습니다.

세 개의 문서가 하나의 작은 약속을 정착시켰다

RFC 1426이 1993년 2월에 8bit-MIMEtransport 확장을 발표했습니다.RFC 1652가 1994년 7월에 이를 대체했고,RFC 6152가 2011년 3월에 RFC 1652를 대체하여 현재 등록된 사양으로 남아 있습니다. 이 문서 계보는 개정을 기록하면서, 문서의 나이를 현재 배포 현황의 증거로 바꾸지는 않습니다.

메커니즘은 의도적으로 간결하게 유지되었습니다. 서버는 성공적인EHLO응답에8BITMIME을 추가합니다.IANA SMTP 서비스 확장 레지스트리는 이 키워드를 기록하고, EHLO 매개변수가 없음을 밝히며, RFC 6152를 가리킵니다. 새로운 SMTP 동사는 등장하지 않습니다.

클라이언트는MAIL FROM에 선택적 매개변수 하나를 추가합니다. 즉BODY=7BIT또는BODY=8BITMIME입니다. 이 매개변수는 이어서 전송될 콘텐츠 본문의 옥텟 도메인을 수신자에게 알립니다. 언어, 문자 집합, 미디어 타입, 애플리케이션을 지칭하지 않습니다. UTF-8 텍스트 파트와 8비트 이미지 인코딩은 둘 다 상위 비트를 마주친다고 해서 의미상 동등해지는 것이 아닙니다.

허가는 광고에 앞서 이루어졌다

8비트 MIME 본문을 보내려는 클라이언트는 먼저EHLO를 발행해야 합니다.8BITMIME을 포함한 성공적인 250 응답만이 그 연결에서 확장된MAIL FROM선언과 이후의 상위 비트 본문 전송을 승인합니다.

부재도 의미를 갖습니다. 서버가 EHLO에 성공적으로 응답하지 않거나 키워드 없이 응답하면, 클라이언트는 US-ASCII 범위를 벗어나는 옥텟을 보내서는 안 됩니다. 관용은 이전 세션, 제품 이름, TCP 자체가 임의의 바이트를 운반한다는 사실에서 추론할 수 없습니다. 관련 증거는 현재 피어의 현재 광고입니다.

이는 전역 인증이 아니라 국소적 권한입니다. 수신 릴레이는 자신의 다음 홉이 그렇지 않더라도 8BITMIME을 광고하고 본문을 수락할 수 있습니다. 첫 약속은 첫 전송에만 구속력을 가집니다. 그 약속에 동당하지 않은 기계들을 대변하지 않습니다.

수락은 모든 비트의 관리 의무를 만들었다

이를 지원하는 서버가 8비트 본문을 수락하면, RFC 6152는DATA를 통해 전달되는 모든 옥텟의 모든 비트를 보존할 것을 요구합니다. 배달이나 이후의 릴레이도 이를 보존해야 합니다. 따라서 이 키워드는 단순한 파싱 힌트가 아니라, 내부 경계에서 상위 비트를 깎아내지 않겠다는 운영상의 약속입니다.

이 의무는 구현의 접합부까지 미칩니다. 큐 기록기, 콘텐츠 스캐너, 스풀 형식, 릴레이 프로세스는 SMTP 프런트엔드가 기능을 광고했다는 이유만으로 본문을 몰래 정규화할 수 없습니다. 실행 중인 코드는 해당 서버가 커버하는 관리 경로 전체에서 이 약속을 지켜야 합니다.

의무는 정확하지만 좁습니다. 이는 발신자를 인증하지 않고 콘텐츠의 안전성을 증명하지 않습니다. 수신 애플리케이션이 선언된 문자 집합을 이해한다는 보장도 없습니다. 이는 다만 이 SMTP 참여자가 협상된 전송 규칙 아래 옥텟에 대한 책임을 수락했음을 증명할 뿐입니다.

8비트는 바이너리가 아니었다

이 이름은 과대한 주장을 부릅니다. 8BITMIME은 DATA를 임의의 옥텟 터널로 바꾸지 않습니다. 통상적인 SMTP 점(dot) 투명성은 여전히 적용됩니다. 점만으로 이루어진 행은 DATA를 종료하고, 행 선두의 점은 전송을 위해 두 배로 늘어납니다. 마지막 점 앞의 CRLF는 여전히 콘텐츠의 일부입니다.

행 길이 제한도 유지됩니다. RFC 6152는 서버가 한 행에 CRLF를 포함해 최저 1,000옥텟까지의 제한을 둘 수 있음을 언급합니다. MIME8bit데이터는 여전히 행을 가지며, MIMEbinary는 그럴 필요가 없는 바이트 열을 허용합니다. 이 확장은 SMTP의 행 문법을 보존하기 때문에8bit콘텐츠 전송 인코딩은 지원하지만binary는 지원하지 않습니다.

이 경계는 여러 역사를 분리해 놓습니다. MIME은 콘텐츠를 명명하고 인코딩합니다. 점 투명성은 대역 내 종결자를 보호합니다. 8BITMIME은 행 지향 운반체를 그대로 둔 채 옥텟의 허용 값을 넓힙니다. CHUNKING과 BINARYMIME은 이후 서로 다른 프레이밍 문제를 다룹니다.

다음 홉은 문제를 다시 열 수 있었다

릴레이 A가BODY=8BITMIME을 수락하고 메시지를 온전히 저장한 뒤 릴레이 B에 연결한다고 가정해 봅시다. B가 8BITMIME을 광고하지 않는다면, A는 본문을 그냥 보내고 기대할 수 없습니다. RFC 6152는 두 가지 선택지를 남깁니다.

릴레이는 메시지를 유효한 7비트 MIME으로 변환할 수 있습니다. 그 변환은 정보를 잃어서는 안 되며, 적절한 경우 quoted-printable이나 base64 같은 MIME 전송 인코딩을 사용할 수 있습니다. 또는 릴레이는 이 장벽을 영구적인 배달 오류로 취급할 수 있습니다.

표준은 의도적으로 변환 방식을 지정하지 않습니다. 이 절제는 변환이 중립적인 바이트 조작이 아니기 때문에 중요합니다. 헤더, 멀티파트 경계, 정규 행 끝, 전송 인코딩 레이블은 일관성을 유지해야 합니다. 독자에게 보이는 콘텐츠를 바꾸거나 서명을 훼손하거나 유효하지 않은 MIME을 만드는 변환은, 출력 바이트가 모두 7비트라고 해서 무손실 규칙을 만족한 것이 아닙니다.

따라서 신뢰할 수 있는 변환이 없을 때는 실패가 더 정직한 결과일 수 있습니다. 공통 계약은 경계를 명시하지만, 모든 운영자에게 동일한 게이트웨이를 강제하지는 않습니다.

선언은 증거였지 마법의 진실이 아니었다

BODY=8BITMIME은 클라이언트가 제공합니다. 서버는 이를 사용해 능력을 갖춘 경로를 선택하거나 지원되지 않는 도메인을 조기에 거부할 수 있지만, 이 매개변수는 수신자가 실제 도착하는 것을 관찰해야 할 의무를 면제해 주지 않습니다.BODY=7BIT라고 임의의 형식 오류 본문이 안전해지는 것도 아닙니다. 프로토콜 선언은 책임을 조직할 뿐, 검증을 중단시키지 않습니다.

운영자에게는 두 가지 별개의 기록이 필요합니다. 피어가 광고한 것과 발신자가 선언한 것입니다. 여기에 측정된 본문 도메인과 다음 홉 경계에서의 조치를 더하면 경로가 설명 가능해집니다. 그 장부가 없으면, 목적지에서 발생한 문자 손상을 발신자 오류, 안전하지 않은 다운그레이드, 내부 8비트 제거 결함, 렌더링 문제 중 어느 것과 구분할 수 없습니다.

이 교훈은 메일보다 큰 영역에서 인정받고 있습니다. 확장 협상은 누가 무엇을 약속했는지를 한정할 때 유용합니다. 국소적 기능 토큰이 종단 간 속성처럼 취급될 때 위험해집니다.

출처와 한계

문서 계보는RFC 1426에서RFC 1652를 거쳐RFC 6152로 이어집니다.RFC 2045는 MIME 전송 도메인의 구분을 제공하며,IANA SMTP 레지스트리는 현재 키워드 기록을 제공합니다. 이 출처들은 프로토콜 동작과 역사를 정의합니다. 그러나 현대의 채택률, 벤더 기본값, 메시지 볼륨, 다운그레이드 빈도는 측정하지 않습니다.