요약

  • RFC 1428이 다룬 것은, 라벨 없는 비 MIME 8비트 메일을 내용 변경 권한을 가진 게이트웨이가 MIME/ESMTP 쪽으로 넘겨주는 제한적인 전환 경로였다. 신구 메일 시스템의 모든 조합을 하나의 방식으로 해결한 문서가 아니었다.
  • 신뢰할 수 있는 문자 집합 정보가 있으면 게이트웨이는 구체적인 charset을 붙일 수 있었다. 없으면unknown-8bit을 사용한다. 이것은 추론용 부호도 만능 문자 집합도 아니라, "여기서는 알 수 없다"는 증거의 경계였다.
  • MIME의 구조, 본문의 전송 인코딩, 헤더의 인코딩, 변환 이력, 다음 홉의 능력, 옥텟의 보존, 배달, 사람에 의한 해석은 각각 별개의 층이다. 형식상의 갱신이 의미의 확정을 보장하지 않는다.

읽을 수 있는 메일을 지탱한 것은 외부의 암묵적 합의였다

RFC 821의 SMTP는 실질적으로 7비트 전송로로 설계되어 있었다. 최상위 비트는 지워진다. 한편 사용자는 US-ASCII만으로 살지 않았다. 각국판 ISO 646, ISO 8859의 8비트 값, PC 고유의 인코딩, 일본어 메일에서 사용된 ISO 2022 이스케이프 시퀀스 등, 표준화보다 먼저 운영상의 편법이 널리 퍼져 있었다.

일부 경로는 8비트를 그대로 통과시켰다. 중간에서 변환이 일어나지 않고, 송신자와 수신자가 같은 문자 집합을 쓴다는 느슨한 사적 합의가 있으면 메일은 읽혔다. 그 성공은 본문에만 있는 것이 아니었다. 양단의 설정, 조직 내 관행, 상대에 대한 지식, 같은 소프트웨어를 쓴다는 기대가 메시지에 쓰이지 않은 의미를 보완하고 있었다.

이 메커니즘은 좁은 공동체에서는 합리적이다. 그러나 메일이 다른 환경으로 옮겨가면 암묵적 합의는 함께 옮겨지지 않는다. 저장된 파일에 8비트 값이 있어도 그것이 ISO-8859-1인지, 다른 국내 코드인지, 기기 고유 코드인지를 판단하는 칸이 없다. 작동해 온 사실은 스스로 기술적이었음을 의미하지 않았다.

MIME은 공통의 기술을 주었다

RFC 1341은 MIME-Version, Content-Type, charset 파라미터, Content-Transfer-Encoding을 도입했다. 본문이 무엇이고, 어떤 문자 집합을 가정하며, 전송로에 맞춰 어떻게 표현되었는지를 메시지 자체에 쓸 수 있게 한 것이다. quoted-printable과 base64는 7비트만 안전하게 통과시킬 수 있는 경로에서도 임의의 옥텟 열을 운반하는 방법을 제공했다.

RFC 1342는 또 하나의 영역을 담당했다. Subject나 표시 이름 등 RFC 822 헤더에 나타나는 비 ASCII 텍스트를 encoded-word의B또는Q형식으로 표현하는 것이다. 본문과 헤더는 구문상으로도 처리상으로도 별개이며, 본문용 전송 인코딩을 그대로 헤더에 유용할 수는 없다.

그래도 MIME을 이해하지 못하는 기존 시스템은 하룻밤에 사라지지 않았다. 공통의 구조가 발명되어도, 구조 없는 저장 메일과 가동 중인 송신 체계는 남는다. 전환의 실무는 완성된 표준과 갱신되지 않은 현실 사이에서 이루어진다.

RFC 1428은 하나의 경계에 국한했다

RFC 1428은 신구 송신자·수신자를 조합한 여섯 가지 상황을 표로 정리했다. 그중 본문이 다룬 것은 case 4, 즉 8비트 투과의 비 MIME 환경에서 온 메시지를 게이트웨이를 통해 MIME/ESMTP 수신 쪽으로 넘겨주는 경우였다.

이 국한은 중요하다. 문서는 "국제화 메일 일반"을 해결했다고 주장하지 않는다. 구식 쪽의 메시지에는 8비트 본문이 있지만 MIME 라벨이 없고, 신식 쪽은 구조화된 정보를 활용할 수 있다. 양자 사이에는 단순히 전송하는 MTA가 아니라, 내용을 변경해 변환할 권한을 가진 게이트웨이가 놓인다.

RFC 1428의 정의에 따르면, 그 게이트웨이는 User Agent와 같은 정도로 메시지 내용을 변경할 수 있는 transport agent이다. 이는 강한 권한이다. 중계점이 투명한 배달자가 아니라 공개되는 표현의 공동 저자가 되는 것이다. 따라서 무엇을 바꿨는지, 어떤 근거로 메타데이터를 붙였는지가 운영상의 핵심이 된다.

변환은 구조를 더한다

게이트웨이는 구식 메시지에 MIME-Version을 더하고, Content-Type과 charset을 선언하며, Content-Transfer-Encoding을 선택한다. 다음 경로가 8비트를 다룰 수 없다면 quoted-printable이나 base64로 변환할 수 있다. 다룰 수 있다면 조건에 따라 8비트 표현을 유지할 수 있다.

이 작업은 흩어져 있던 암묵적 정보를 공통 형식으로 사상한다. 수신 쪽 메일 리더는 어떤 처리를 시도해야 하는지 이전보다 많이 안다. 저장·전송·표시의 각 단계도 같은 필드를 참조할 수 있다. 전환이 가치를 가지는 것은 여기이다.

다만, 빈 칸이 있다고 해서 거기에 구체적인 값을 넣을 지식이 생기는 것은 아니다. 게이트웨이가 송신 조직, 사용자 설정, 경로, 로컬 규약 등에서 신뢰할 수 있는 charset을 얻었다면 그 값을 쓸 수 있다. 얻지 못했다면 겉모습이나 빈도만으로 단정하는 것은 구조화가 아니라 추측의 고정화가 된다.

unknown-8bit은 결함이 아니라 경계였다

RFC 1428은 신뢰할 수 있는 문자 집합 정보가 없는 경우unknown-8bit을 사용하도록 정했다. 이 값은 모든 언어와 인코딩 방식의 8비트 내용을 덮을 수 있다. 문서는 그것을 더 세분화해서는 안 된다고 했다.

따라서unknown-8bit은 하나의 문자 집합 이름이 아니다. 바이트를 문자에 대응시키는 표를 갖지 않고, 언어를 나타내지 않으며, 여러 알려진 charset을 섞은 것도 아니다. 전환을 수행한 게이트웨이가 정확한 분류를 뒷받침할 정보를 갖고 있지 않았음을 나타낸다.

또한 이것은 새 메일을 작성하는 작성자를 위한 편리한 탈출로도 아니다. 본 문서가 가정하는 것은 이미 존재하는 라벨 없는 내용을 경계에서 받아든 게이트웨이다. 처음부터 MIME 메시지를 만들 수 있는 작성자는 사용한 문자 집합을 알고, 구체적으로 기술할 책임을 진다.

미지를 명시하면 수신 쪽 메일 리더에 해석의 여지가 남는다. 사용자가 후보 문자 집합을 고르거나, 지역이나 상대를 단서로 전처리를 시도할 수 있는 경우도 있다. 그것은 자동적인 성공이 아니다. 그러나 잘못된 확정 라벨보다 나중에 정정할 수 있는 여백이 크다.

본문과 헤더에는 각각 다른 변환이 필요했다

구식 8비트 메일에서 문제는 본문에만 한정되지 않는다. Subject, 코멘트, 표시 이름 등 헤더에도 비 ASCII 옥텟이 나타날 수 있다. RFC 1428은 그것들을 RFC 1342의 encoded-word로B또는Q방식으로 변환하는 방향을 제시했다.

여기서 본문용8bit을 헤더 값으로 붙인다고 되는 것은 아니다. 헤더는 배달 제어와 구문 분석의 측면을 가지며, 줄바꿈, 구분자, 주소 구조를 깨뜨리지 않고 인코딩해야 한다. 본문과 같은 charset 문제를 안고 있어도 수송상의 처리 단위는 다르다.

이 분리는 이후의 전환 설계에도 통한다. 데이터 본체, 색인, 제목, 식별자, 표시용 라벨이 같아 보여도 같은 변환기로 안전하게 처리할 수 있다는 보장은 없다. 대상별 구문과 권한을 나누지 않으면 내용을 구하는 변환이 제어 정보를 깨뜨린다.

변환한 사실도 메시지의 일부가 되었다

게이트웨이는 형식을 바꾼 이상 그 개입을 추적 가능하게 할 필요가 있다. RFC 1428은 변환을 나타내는 trace 정보를 Received 행에 더하는 발상을 보여주고,convert rfc822-to-8bit,convert rfc822-to-base-64,convert rfc822-to-quoted-printable같은 기록 예를 들었다.

이 흔적은 원래 문자 집합을 증명하지 않는다. 무엇이 밝혀졌는지가 아니라 어떤 표현 조작이 행해졌는지를 기록한다. 변환 후 글자 깨짐이 발견되었을 때, 송신 시점부터 깨어 있었는지, 중간에 잘못된 charset을 붙였는지, base64화 전후에 변했는지를 분리하는 단서가 된다.

감사 가능성은 완전한 확실성의 대용품이 아니다. 오히려 불확실한 전환을 안전하게 운용하기 위한 별도의 증거층이다. 내용의 의미를 몰라도 처리자, 처리 시점, 실시한 변환은 기록할 수 있다.

RFC 1425와 RFC 1426은 인접한 별개의 문제를 해결했다

같은 확장 SMTP 계열에 있는 RFC 1425는 EHLO와 확장 능력의 협상 프레임워크를 정했다. RFC 1426은 8BITMIME을 정의하고, 서버가 8비트 MIME 본문을 수용할 수 있음을 알리며, 클라이언트가BODY=8BITMIME으로 그것을 신고할 수 있게 했다.

RFC 1426의 책임은 홉 단위이다. 다음 서버가 능력을 광고하지 않으면 송신 쪽은 7비트로 안전한 형식으로 변환하거나 배달을 실패시켜야 한다. 광고가 있어도 charset이 올바른지, 수신자가 읽을 수 있는지까지는 보장하지 않는다. 보장되는 중심은 허가된 경로에서 8비트 내용을 깨뜨리지 않고 주고받는 것이다.

RFC 1428은 그 앞에 남는 의미의 결여를 다룬다. 메시지가 MIME이 아니고 charset도 쓰여 있지 않다면, 경로가 8비트를 완전히 보존해도 수신자는 해석하지 못할 수 있다. 비트 보전과 의미 식별은 겹치지만 동일하지 않다.

메일 한 통에는 여러 증거층이 있었다

이 전환을 하나의 "호환성" 판정으로 줄이면 무엇이 성공했는지 보이지 않게 된다. 최소한 다음 질문은 각각 다뤄야 한다.

먼저, 게이트웨이에는 내용을 변경할 권한이 있었는가. 다음으로, MIME 구조는 구문적으로 올바른가. charset은 근거 있는 값인가, 아니면 미지의 명시인가. 본문과 헤더는 각각 적절한 방식으로 처리되었는가. 변환 이력은 남았는가. 각 홉은 필요한 표현을 수용했는가. 원래 옥텟은 보존되었는가. 최종적으로 배달되었는가. 그리고 사람이 의도한 문자로 읽혔는가.

하나가 참이어도 다음이 자동적으로 참이 되지 않는다. base64로 하면 7비트 경로를 통과할 수 있지만 charset은 판명되지 않는다. 8BITMIME으로 옥텟을 보존할 수 있어도 라벨 없는 문면은 읽을 수 없다. 올바른 MIME 구문이라도 근거 없는 구체적 라벨이 붙으면 오해를 늘린다. 배달 성공 로그는 의미 보존의 증명이 아니다.

RFC 1428이 역사적으로 흥미로운 것은 전환을 성공과 실패의 이분법으로 만들지 않은 점에 있다. 공유층에서 알 수 있는 것만 형식화하고, 알 수 없는 부분을 남기고, 국소적 독해 능력에 여지를 주었다.

표준화는 사적 합의를 한 번에 지울 수 없었다

구식 메일이 읽힌 것은 종종 송수신자가 같은 전제를 공유했기 때문이다. 새 표준은 그 전제를 공적 필드로 옮기려 했다. 그러나 경계 게이트웨이가 과거의 모든 암묵적 합의를 회수할 수는 없다.

전환의 현실적인 진행 방법은 공통 부분을 작게 유지하는 것이었다. MIME은 구조를 제공하고, ESMTP는 홉 능력을 협상하고, 게이트웨이는 아는 범위에서 변환하며,unknown-8bit은 남은 무지를 숨기지 않는다. 수신 쪽은 필요하면 로컬 지식으로 마지막 해석을 수행한다.

이것은 완전한 중앙 해결이 아니다. 그러나 가동 중인 시스템을 멈추지 않고 채택을 넓히기 위한 설계이다. 처음부터 모든 송신자를 갱신하는 조건을 걸면 도입이 진행되지 않는다. 반대로 게이트웨이에 만능 추론을 요구하면 오류가 표준화된 메타데이터로 남는다.

현대에 주는 교훈은 "변환"과 "지식"을 나누는 것이다

오래된 데이터를 새 스키마로 옮기면 칸이 늘어나고, 검증을 통과하고, 겉모습도 정돈된다. 그 순간 변환된 레코드가 원데이터보다 상세해 보인다. 그러나 새 칸의 값이 추정에 지나지 않는다면 정보가 늘어난 것이 아니라 애매함의 자리가 옮겨진 것뿐이다.

안전한 전환은 구문상의 적합, 값의 출처, 확신도, 변환 이력, 원데이터의 보존을 따로따로 다룬다. 값을 확정할 수 없을 때는 미확정을 나타내는 정규 상태를 가진다. 나중의 이용자가 다른 증거를 얻었을 때 재해석할 수 있는 길을 남긴다.

RFC 1428의unknown-8bit은 완성도가 낮은 잠정값처럼 보인다. 실제로는 공동 인프라가 지녀야 할 인식상의 절제를 나타내고 있었다. 게이트웨이에는 표현을 바꿀 권한이 있어도, 증거 없는 의미를 선언할 권한까지는 없다.

출처