요약

  • MIMEmessage/partial은 모든 조각을 독립적으로 전송 가능한 메시지로 만들었고,id,number,total매개변수는 수신 측 사용자 에이전트에 로컬 재조립을 시도할 수 있을 만큼의 공통 구조를 제공했습니다.
  • 재조립된 결과는 내부 개체의 의미를 물려받았습니다. 단순히 '메시지 안의 메시지'가 아니었으며, 대부분의 외부 래퍼 헤더는 결정적 병합 규칙에 따라 사라졌습니다.
  • 일치하는 식별자와 완전한 번호 범위는 발신자를 인증하지 않고, 내용을 해싱하지 않으며, 동일한 중복임을 증명하지 않고, 결과가 실제로 표시되었음을 보여주지도 못했습니다. 도착 증거와 의미적 실체는 여전히 서로 다른 계층이었습니다.

메일이 전 세계를 연결했어도 상한선은 로컬이었다

SMTP는 하나의 보편적인 최대 메시지 크기를 정의하지 않았습니다. 상한선을 정한 것은 호스트, 게이트웨이, 저장소였습니다. 1989년까지RFC 1123은 메일 소프트웨어가 최소 64K바이트를 주고받아야 한다고 요구하고, 그보다 훨씬 큰 상한을 '매우 바람직한' 것으로 명시했으며, 사용자들이 이미 1메가바이트 이상의 문서를 메일로 주고받고 있음을 언급했습니다. 이 요구사항은 적합 호스트의 하한선을 기술한 것이지, 모든 경로가 같은 상한선을 공유한다는 약속이 아니었습니다.

이 불일치가 중요한 이유는 저장-전달 방식 메일이 국지적 결정들의 연쇄이기 때문입니다. 발신자는 큰 객체를 수용할 수 있고, 한 릴레이는 큐에 넣을 수 있으며, 이후의 게이트웨이는 그것을 거부할 수 있습니다. 객체는 하나의 인간적 의미를 지니지만 여러 행정적·기술적 임계값을 만나게 됩니다. 하나의 한도를 올린다고 다른 한도들도 함께 올라가지 않습니다.

그래서 초기 MIME 설계자들은 두 가지 넓은 전략 중 하나를 선택해야 했습니다. 메일 시스템 전체가 더 큰 분할 불가능한 단위를 수용하도록 요구하거나, 시스템이 이미 이해하는 더 작은 단위 안에서 응용 계층 객체가 이동하는 방식을 정의하는 것입니다. 그들은 선택적 미디어 타입으로 후자를 택했습니다. 네트워크는 메시지를 운반하고, 수신 응용 프로그램이 여러 메시지가 하나의 객체가 될 수 있는지를 판단했습니다.

MIME은 전달 단위와 의미 단위를 분리했다

1992년 6월에 발표된 최초의 MIME 명세인RFC 1341은 미디어 타입, 멀티파트 본문, 전송 인코딩으로 기억됩니다. 그러나 그 안의message/partial서브타입은 똑같이 중요한 분리를 만들어냈습니다. 이 타입으로 표시된 본문은 더 큰 메시지의 조각이었습니다. 조각은 본문이 내부 개체 전체는 아니었음에도 완전한 외부 메일 메시지로서 이동했습니다.

이것은multipart/mixed와 같지 않았습니다. 멀티파트는 하나의 전달된 메시지 안에 여러 구성요소를 담습니다.message/partial은 하나의 의도된 개체를 여러 전달된 메시지에 걸쳐 배치했습니다. 멀티파트 경계는 하나의 봉투 안에서의 구조를 기술하고, partial-message 매개변수는 독립적으로 도착한 봉투들을 이후에 연관 지었습니다.

이 구분은 완성 지점을 옮겼습니다. SMTP 서버는 조각 1과 2를 보유하지 않고도 조각 3을 수용할 수 있었습니다. 메일함은 내부 객체 없이도 두 개의 래퍼를 저장할 수 있었습니다. 재조립을 시도할 수 있는 것은 충분한 로컬 조각 집합을 가진 사용자 에이전트뿐이었습니다. 중간 기록은 전체가 이미 존재한다고 가장할 필요가 없었습니다.

세 개의 매개변수가 의도적으로 작은 공통 규칙을 이루었다

이 메커니즘은 세 개의 Content-Type 매개변수를 사용했습니다.id는 가능한 한 전 세계적으로 고유에 가깝게 생성되어 조각들을 묶었습니다.number는 조각을 순서 안에 배치했습니다.total은 조각의 총 개수를 선언했습니다. 번호는 0이 아니라 1부터 시작했고, 매개변수 순서는 의미가 없었습니다.

total주변의 비대칭은 실용적인 것이었습니다. 앞쪽 조각은 이를 생략할 수 있었지만(이후 개정판에서는 포함을 권장), 마지막 조각은 반드시 담아야 했습니다. 발신자는 최종 개수를 알기 전에 분할된 객체 전송을 시작할 수 있지만, 마지막 조각에서는 수신자가 선언된 종료점을 필요로 했습니다.

이 필드들은 제안된 집합을 기술했을 뿐 그것을 증명하지 않았습니다. 같은id를 지닌 두 래퍼는 여전히 충돌할 수 있었습니다. 같은 번호의 두 복사본은 서로 다른 바이트를 담을 수 있었습니다. 악의적인 발신자는 불가능한 총 개수를 선언하거나, 한 조각을 끌어안거나, 다른 집합과 의도적으로 충돌할 수 있었습니다. RFC는 암호학적 다이제스트나 서명자 신원, 전역 정산 기관이 아니라 상호 운용 가능한 문법을 제공한 것입니다.

그 좁음이야말로 특징이었습니다. 수신 에이전트는 객체의 존재를 부여해줄 권위자를 필요로 하지 않았습니다. 필요한 것은 결정적인 국지적 질문들이었습니다. 식별자가 일치하는가? 선언된 총 개수까지 1부터 모든 번호가 존재하는가? 중복이 로컬 정책에 따라 일관되는가? 요구되는 경계에서 이어 붙이면 유효한 MIME 개체가 만들어지는가? 기록은 검사를 가능하게 했고, 실행 중인 파서가 결과를 제공했습니다.

재조립은 비계를 제거했다

중요한 설계 선택은 의미적 투명성이었습니다. 조각들이 합쳐지면 결과는 자신의 Content-Type을 지닌 완전한 MIME 개체였습니다. 분할된 오디오 개체는 다시 오디오가 되었습니다. 내용이 우연히 오디오를 담은 또 다른 메시지인, 표시되는 래퍼가 되지는 않았습니다.

1993년 개정판인RFC 1521은 여러 운영 세부사항을 강화하면서도 이 규칙을 유지했습니다. 외부message/partial형식은 임시 비계였습니다. 그 목적은 제약된 경로를 통한 전송이었지, 내용의 정체성으로 영구히 승격되는 것이 아니었습니다.

이로 인해 두 종류의 Message-ID 형태 증거가 생겼습니다. 각 외부 래퍼는 실제 메일 메시지이므로 자신만의 일반적인 Message-ID와 전달 추적을 가질 수 있었습니다. 첫 조각 안에는 재구성되는 개체의 헤더, 존재한다면 그 자체의 Message-ID가 들어 있었습니다. 외부 식별자는 전달들을 이름 짓고, 내부 식별자는 결과 메시지를 이름 지었습니다. 하나를 다른 하나의 대체물로 다루면 조각들이 어떻게 이동했는가와 수신자가 무엇을 재구성했는가 사이의 차이가 지워집니다.

같은 분리는 타임스탬프와 Received 필드에도 적용됩니다. 조각 4가 먼저 도착할 수 있고, 조각 1이 가장 오래된 경로를 거칠 수 있습니다. 그 사실들은 전송 진단에 중요하지만 본문을 재배열하지는 않습니다. 연결 순서를 지배하는 것은number매개변수입니다. 도착 시각은 경로에 대한 증거이지 의미적 순서에 대한 권위가 아니었습니다.

첫 래퍼와 내부 메시지는 헤더를 나누었다

재조립은 본문을 이어 붙이는 것 이상을 요구했습니다. 모든 래퍼는 일반 메일 헤더를 가지며, 그것을 맹목적으로 모두 보존하면 하나의 결과 주위에 여러 경쟁하는 발신자, 제목, 날짜, 전달 추적이 생깁니다. 그래서 MIME은 병합 법칙을 명시했습니다.

분할은 행 경계에서만 이루어져야 했습니다. 재구성 시, 첫 둘러싼 메시지의 일반 헤더는 복사되지만 Content 접두어 필드와 선별된 의미 필드인 Subject, Message-ID, Encrypted, MIME-Version은 제외됩니다. 둘러싸인 메시지에서는 Content 접두어 필드와 그 선별된 의미 필드들이 덧붙여집니다. 다른 내부 헤더는 버려집니다. 두 번째 이후의 둘러싼 메시지들의 헤더는 재구성된 개체에서 폐기됩니다.

RFC 2046은 그 결과 배분을 명확히 서술합니다. 첫 래퍼가 살아남는 외부 맥락을 제공합니다. 내부 메시지는 미디어 기술과 선별된 신원 관련 필드를 제공합니다. 이후의 래퍼들은 개별 도착을 증명하지만 최종 헤더 블록에 대한 표결권은 없습니다.

이 때문에 조각 1은 단순한 첫 바이트 범위 이상입니다. 그것은 이후 조각들이 대체할 수 없는 재구성 맥락을 운반합니다. 본문은 보존하되 첫 래퍼를 만료시키는 시스템은 모든 데이터 세그먼트를 보유하고도 명세된 헤더 기초를 결여할 수 있습니다.number=1대신 가장 먼저 도착한 래퍼를 택하는 시스템은 말없이 다른 프로토콜을 발명하는 셈입니다.

버려진 헤더가 무가치한 것은 아닙니다. 메일 흐름 분석, 큐 타이밍, 악용 조사를 위해서는 원시 래퍼 안에서 여전히 가치가 있습니다. 다만 재조립으로 만들어지는 의미적 개체에는 속하지 않을 뿐입니다. 좋은 증거 보존은 두 관점을 모두 유지합니다. 출처를 위한 불변 래퍼와 사용을 위한 파생 개체입니다.

서로 다른 게이트웨이들은 콘텐츠를 최소 공통 봉투로 밀어 넣었다

MIME은 메시지 본문이 전송에 맞는 인코딩을 사용하도록 허용했지만,message/partial은 특별한 함정에 직면했습니다. 메시지 타입 본문을 외부 수준에서 base64나 quoted-printable로 감싸는 것은 단순히 허용되지 않았습니다. 바이너리 내부 메시지가 분할되면 모든 partial 래퍼가 바이너리 수용 전송을 요구하게 됩니다. 조각 하나만 만난 게이트웨이는 나머지 조각들을 기다렸다가 개체를 재조립하고 인코딩하는 것을 안전하게 할 수 없습니다. 다른 조각들은 다른 게이트웨이를 통과할 수 있기 때문입니다.

따라서 규칙은 가장 약한 공유 경로를 따랐습니다.message/partial개체는 7bit 전송 인코딩을 사용해야 했고, 내부 개체는 8bit나 바이너리 인코딩에 의존할 수 없었습니다.RFC 2045가 상보적인 전송 인코딩 프레임워크를 제공했고, RFC 2046이 partial 메시지에 더 엄격한 제약을 적용했습니다.

이것은 분산된 겸손의 한 형태였습니다. 어떤 게이트웨이도 전체 집합을 본다고 가정되지 않았습니다. 어떤 릴레이도 재구성의 주권자로 임명되지 않았습니다. 발신자는 독립적으로 라우팅되는 각 조각이 운반할 수 있는 내부 표현을 준비해야 했습니다. 상호 운용성은 하나의 중개자에게 완전한 가시성을 부여하는 대신 작은 공통 제약에서 나왔습니다.

같은 겸손이 중첩 분할을 설명합니다. 서로 다른 전송 에이전트는 서로 다른 크기 임계값을 사용할 수 있습니다. 한 집합이 재조립된 후 그 결과 자체가 또 다른message/partial개체일 수 있었습니다. 명세는 그 결과를 명시적으로 허용했습니다. 수신자는 하나의 그룹화 과정이 전체 역사를 소진한다고 가정하는 대신 계층을 인식하고 국지적 절차를 반복해야 했습니다.

SIZE는 입장을 협상했지만 재구성을 수행하지 않았다

1995년까지RFC 1870은 크기 문제에 대해 SMTP에 다른 답을 내놓았습니다. 서버는 SIZE 확장을 통해 고정 최대 크기를 광고할 수 있고, 클라이언트는 본문 전송 전에 MAIL에서 예상 메시지 크기를 선언할 수 있었습니다. 명백히 초과된 거래는 전체 경로를 소비하기 전에 실패할 수 있었습니다.

SIZE와message/partial은 단순한 대체 순서로 서술되어서는 안 됩니다. 두 메커니즘은 서로 다른 계층에서 작동했습니다. SIZE는 하나의 메시지에 대해 SMTP 클라이언트와 서버 사이의 전송 입장 신호였습니다.message/partial은 전달 이후 여러 메시지를 연관 짓는 응용 표현이었습니다. 서버가 선언된 크기를 수용했다고 해서 최종 전송이나 전달이 보장되지 않았으며, 수신 사용자 에이전트가 partial 메시지를 재구성할지 여부에 대해서는 아무 말도 하지 않았습니다.

이후의 메커니즘은 알려진 홉에서 분할할 이유를 줄일 수 있었습니다. 그러나 이질적인 하류 한도를 없애거나, 조각을 인증하거나, 헤더를 병합할 수는 없었습니다. 하나는 국지적 상한선을 더 일찍 드러냈고, 다른 하나는 의미가 여러 수용된 봉투를 넘어 살아남는 방식을 정의했습니다.

완전한 집합은 여전히 신뢰의 시작일 뿐이었다

partial 메시지 사건을 검토하는 운영자에게는 최소한 세 개의 장부가 필요합니다. 래퍼 장부는 개별 전달된 메시지마다 원시 바이트, 외부 Message-ID, Received 연쇄, 도착 시각, 메일함, 처분을 기록합니다. 집합 장부는 정규화된id,number, 선언된 총 개수, 중복 충돌, 누락 번호, 만료 결정을 기록합니다. 재구성 장부는 번호마다 선택된 조각, 연결 순서, 헤더 병합, 파서 결과, 디코딩된 미디어 타입, 그리고 추가 중첩 집합 여부를 기록합니다.

보안 판단은 식별자 안이 아니라 그 장부들 곁에 속합니다. 인증 결과는 래퍼마다 다를 수 있습니다. 완전한 번호 범위조차 적대적 콘텐츠를 운반할 수 있습니다. 파서는 서명이 실패하거나, 미디어 타입이 안전하지 않거나, 출처를 확립할 수 없는 유효한 MIME 개체를 만들어낼 수 있습니다. 표시와 사용자 주의는 그보다 더 뒤에 일어납니다.

이 설계 교훈은 구형 메일 클라이언트를 넘어섭니다. 분산 시스템은 흔히 하나의 객체를 구성한다고 주장하는 여러 기록을 수신합니다. 공유 레이블은 그것들을 조율할 수 있지만, 객체 자체나 그 뒤의 권위, 처리의 결과를 만들어낼 수는 없습니다. 공통 계층은 호환되는 재구성에 필요한 불변식만을 서술해야 합니다. 가용한 증거가 그것을 만족하는지는 로컬에서 실행되는 코드가 결정해야 합니다.