요약

  • RFC 3462는multipart/report를 최상위 MIME 컨테이너로 만들고, 사람을 위한 설명과 기계를 위한 형식화된 기록이라는 순서가 고정된 필수 파트 두 개를 요구했습니다. 세 번째 파트는 원본 메시지 전체 또는 유용한 일부를 반환할 수 있었습니다.
  • 이 봉투는 보고서를 식별 가능하게 만들었을 뿐, 신뢰 가능하게 만들지는 않았습니다. 소프트웨어는report-type으로 두 번째 파트를 식별할 수 있었지만, 위조된 보고서는 여전히 독자를 오도하거나 파괴적인 자동화를 유발할 수 있었습니다.

하나의 보고서에 두 명의 독자가 필요했다

메일 전송 실패는 다루기 곤란한 대상이었습니다. 사람은 이해할 수 있는 설명을 원했습니다: 어떤 주소가 실패했는지, 무엇을 고칠 수 있는지, 재시도가 의미가 있는지. 소프트웨어는 언어나 표현 변화에 따라 의미가 흔들리지 않는 안정적인 필드를 원했습니다. 기계 데이터를 산문에 넣으면 자동화가 취약해졌고, 기계 필드만 보여주면 보고서가 발신자에게 불필요하게 적대적이 되었습니다.

RFC 3462는 2003년 1월에 발표되어, 전송 문제가 아니라 패키징 문제를 해결했습니다.일반 텍스트 버전,RFC 편집자 기록,Datatracker 항목,문서 이력,참고 문헌,후속 인용,정오표 검색이 이 기록의 기준점이 됩니다. 이 표준은RFC 1892를 대체하면서도 핵심 아이디어를 보존했습니다: 하나의 MIME 구조가 인간의 검토와 자동 처리를 모두 지원하면서도, 두 증거 역할을 혼동하지 않을 수 있다는 것입니다.

Content-Type은 반드시multipart/report여야 했고, 메시지의 최상위 MIME 유형이어야 했습니다.RFC 2046아래의 다른 multipart 유형들처럼boundary매개변수가 필요했으며, 두 번째 본문 파트의 MIME 서브타입 이름을 지정하는report-type매개변수도 필요했습니다. 이 연계 덕분에 처리기는 본문 전체를 파싱하기 전에, 외부 헤더만 보고 어떤 기계 기록을 기대해야 하는지 알 수 있었습니다.

순서 자체가 의미의 일부였다

컨테이너는 고정된 순서로 두세 개의 파트를 담았습니다. 첫 번째 파트는 필수이며 사람을 대상으로 했습니다. 표준 트랙 MIME 유형과 적절한 문자셋 또는 언어를 사용할 수 있고,multipart/alternative로 여러 프레젠테이션을 제공할 수도 있었습니다. 이 자유는 의도된 것이었습니다. 인간의 설명은 청중, 언어, 진단 판단에 따라 달라지기 때문입니다.

두 번째 파트도 필수였지만 소프트웨어를 위한 것이었습니다. 등록된 미디어 유형으로 메시지 처리 이벤트를 기술했습니다. 전송 상태 알림에서는RFC 3464가message/delivery-status를 사용했습니다. 일반 컨테이너는 그 필드들을 정의하지 않았고, 전송 의미를 보장하지도 않았습니다. 알림 요청에 대한 SMTP 규약은RFC 3461이 다루었고, 향상된 상태 코드는RFC 3463이 제공했습니다. 이 구분은 중요합니다. RFC 3462는 기계 증거가 어디에 어떻게 식별되는지를 말할 뿐, 특정 영수증이 존재해야 하는지 여부를 말하지 않습니다.

세 번째 파트는 선택 사항이었습니다. 원본 메시지 전체 또는 진단과 상관 분석에 유용한 일부를 반환했습니다. 발신자가 반환 수준을 요청하지 않은 경우 전체 반환은 권장 기본값이었지만, 대역폭을 낭비하거나 불필요하게 내용을 노출할 수 있었습니다. 불확실한 경로가 8비트 또는 바이너리 데이터를 안전하게 전달할 수 없다면, 생성기는 원본을 합법적인 7비트 MIME으로 재인코딩하거나text/rfc822-headers만 반환할 수 있었습니다.RFC 822의 메시지 전통에 따라 정의된 이 헤더는 완전한 메시지가 아니므로,message/rfc822로 정직하게 표시될 수 없었습니다.

이 세 방향의 분리는 작은 증거 규율을 만들었습니다. 첫 번째 파트는 설명할 수 있고, 두 번째 파트는 파싱될 수 있으며, 세 번째 파트는 맥락을 제공할 수 있습니다. 어떤 것도 다른 것을 대체할 수 없었습니다. 정교한 문장은 상태 필드가 아니고, 상태 필드는 원본 메시지가 아니며, 헤더만 반환된 것은 그것이 기술하는 완전한 대상이 아니었습니다.

인식이 진위를 의미하지 않았다

최상위 배치 덕분에 탐지가 효율적이었습니다. 메일 에이전트는 Content-Type 헤더만으로 보고서를 인식하고 적절한 처리로 라우팅할 수 있었습니다.IANA 미디어 유형 레지스트리는 이 서브타입 계열에 공유된 공개 네임스페이스를 부여했습니다. 후속 보고서 형식들이 이 구조를 재사용했습니다: 메시지 처리 알림은RFC 3798에서 처음 지정되었고RFC 8098로 개정되었으며, 국제화된 전송 상태는RFC 6533에 등장했습니다.

그러나 RFC 3462는 컨테이너가 내용을 인증하지 않는다는 점을 명시적으로 경고했습니다. 위조된 부정 보고서는 자동화된 메일링 리스트나 디렉터리 관리자가 유효한 주소를 삭제하게 만들어, 편리한 정리를 서비스 거부로 바꿀 수 있었습니다. 위조된 긍정 보고서는 전송이 성공했다는 잘못된 믿음을 조장할 수 있었습니다.multipart/report구조 전체를 커버하는 서명이 이 위험을 줄일 수 있었지만, 표준은 그러한 인증을 범위 밖에 두었습니다.

이 한계는 겉보기보다 더 중요합니다. 문법 구조는 바이트가 문법에 맞음을 증명할 수 있습니다. 그 바이트를 누가 만들었는지, 기술된 이벤트가 실제로 발생했는지, 사람이 반환된 설명을 보았는지는 증명할 수 없습니다. 이 층들을 하나로 합치는 자동화는 파싱 결과를 운영상의 권위로 전환시킵니다.

Lu Heng의 후속현실 계층 규율논의는 이 분리에 이름을 붙이는 데 도움이 됩니다: 형식화된 주장, 파서의 해석, 메일 시스템의 이벤트, 운영자의 결과적 조치는 서로 다른 영수증입니다. 그의실행 코드 우선성논의는 실제 MIME 트리, 생성기, 검증기, 결과를 소비하는 자동화에 검토의 초점을 맞추도록 이끕니다. 이것들은 후대의 편집적 렌즈이며, RFC 저자의 사적 의도에 대한 증거가 아닙니다.

RFC 3462의 성과는 소박하지만 내구성 있었습니다. 설명, 기계 기록, 선택적 반환 자료를 하나의 봉투에 넣으면서도 그 의미를 병합하는 것을 거부했습니다. 형식은 조율된 처리를 가능하게 했습니다. 신뢰는 여전히 다른 곳에서 와야 했습니다.

출처