요약

  • RFC 1036은 모더레이션 뉴스그룹 게시물에Approved:줄을 요구했으며, 모더레이터가 메일 주소를 추가하도록 규정해 승인이 뉴스 소프트웨어에 드러나도록 했습니다.
  • 이 헤더는 암호학적 자격 증명이 아니라 라우팅·허가 신호였습니다. 이후의 역사적 초안은 명시적으로, 주장된 승인은 인증할 수 없다고 밝혔습니다.

승인 결정이 게시물과 함께 이동해야 했습니다

유즈넷은 최종 승인본을 받는 단일 서버가 아니었습니다. 게시물은 선택한 뉴스그룹을 교환하고 자체 로컬 저장소를 유지하는 여러 사이트 사이를 이동했습니다. 따라서 모더레이션 규칙은 모더레이터를 직접 알지 못할 수 있는 소프트웨어를 거치는 여정을 견뎌야 했습니다. 게시물에는 일반 전파 준비가 되었는지, 아니면 여전히 검토 대기열에 속하는지에 대한 기계 판독 가능한 표시가 필요했습니다.

1987년 12월 유즈넷 메시지 교환 표준으로 발표된 RFC 1036은 그 표시에 짧은 이름을 붙였습니다. 바로Approved입니다. 이 필드는 선택 헤더 목록에 나왔지만, 모더레이션 그룹에 대한 규칙에서는 필수였습니다. 모더레이터가 "해야" 추가하며, 값은 모더레이터의 메일 주소여야 했습니다. 주소는 유용했습니다. 책임 있는 사람에게로 돌아가는 경로를 식별하고 소프트웨어가 인식할 수 있었기 때문입니다. 이 문서는 수신 사이트가 그 주소를 검증할 수 있는 서명, 키 또는 신뢰할 수 있는 디렉터리를 설명하지 않았습니다.

독자들이 쉽게 혼동할 수 있었음에도, 이 표현은 두 가지 역할을 구분해 두었습니다. 모더레이션된 게시물은 사람의 결정 지점을 통과한 것으로 기대되었습니다. 헤더는 그 결정이 게시물에 반영되었음을 소프트웨어에 알렸습니다. 헤더는 검토 자체를 보여주지 않고, 모더레이터가 적용한 기준을 말하지 않으며, 누가 결정했는지 증명하지도 않습니다. "Approved"는 상태를 명명했고, 주소는 연락처를 명명했습니다. 어느 쪽도 인증된 행위의 영수증이 아니었습니다.

하나의 필드가 게시물과 그룹 제어 메시지를 모두 처리했습니다

RFC 1036의 예시는 이 표시의 구체적 모습을 보여줍니다. 1986년 10월 1일자 독자 요약이news.lists와news.groups에 교차 게시되며, 모더레이터의 주소를 지명하는Approved필드가 붙어 있습니다. 함께 실린Xref는seismo호스트의 로컬 게시물 번호를 기록합니다. 이 예시는 주소 형태의 승인 표시가 평범한 뉴스 게시물의 일부로 이동하는 모습을 보여줍니다. 모더레이터가 이 필드를 얼마나 자주 사용했는지, 각 사이트가 이를 어떻게 확인했는지는 알려주지 않습니다.

이 헤더는 더 중대한 상황에서도 등장했습니다. RFC 1036은 그룹 생성을 요청할 수 있는newgroup제어 메시지를 설명하며, 모더레이션된 그룹으로 만드는 옵션도 포함합니다. 사이트들은 이러한 메시지의 헤더에Approved가 없으면 무시하도록 지시받았습니다. 모든 호스트에서 그룹 삭제를 요청하는rmgroup메시지도 같은 요건을 적용받았습니다. RFC는 삭제가 네트워크 전역 범위를 갖기 때문에 신중을 강조했습니다. 여기서 이 표시는 뉴스 소프트웨어가 평범한 제어 메시지와 승인 주장을 담은 메시지를 구분하도록 도왔습니다. 그럼에도 암호학적으로 검증된 권위를 식별하지는 못했습니다.

이 재사용은 설계상 긴장을 드러냈습니다. 메시지 형식은 결정을 자체 인증 가능하게 만들지 않고도 분산 시스템 전반에서 결정을 판독 가능하게 만들 수 있었습니다. 각 사이트는 필드가 존재해야 한다는 규칙을 적용할 수 있었지만, 필드의 존재만으로는 지명된 메일박스가 공인된 모더레이터나 그룹 관리자의 것임을 입증할 수 없었습니다. 프로토콜은 공통 검사점을 제공했고, 그 뒤의 신뢰는 로컬 조치가 공급했습니다.

이후 초안이 신뢰 격차를 명명했습니다

"Son of 1036"의 역사는 날짜를 신중하게 따져야 합니다. RFC 1849는 1990년대 초에 널리 유통되어, 저자에 따르면 뉴스 소프트웨어 구현자들에게 사실상 참고 문서가 된 초안을 보존하기 위해 2010년 3월 Historic 문서로 발표되었습니다. 이 문서는 스스로 현재 구현 지침이 아니라 역사적 배경 자료라고 명시합니다.

그 회고적 문서는 소프트웨어 경계를 더 명확히 했습니다. 포스팅 에이전트는 로컬 사용자의 제출을 처리합니다. 게시물을 준비하고, 규격 준수 여부를 확인하고, 배포로 넘길 수 있습니다. 릴레이어는 다른 릴레이어로부터 이미 준비된 게시물을 받아 사본을 전달합니다. 모더레이션 그룹의 경우Approved가 없는 게시물은 포스팅 에이전트가 모더레이터에게 보내야 하는 독자 기고입니다. 릴레이어는 승인되지 않은 게시물을 이메일 요청으로 바꾸지 말고 폐기해야 합니다. 같은 프로그램이 두 역할을 모두 수행할 수 있지만, 책임은 서로 교환 가능하지 않습니다.

이 초안은 한계를 직접 서술했습니다.Approved헤더를 인증하여 주장된 승인이 실제로 이루어졌음을 확인할 방법이 없고, 적법한 승인자의 최신 목록을 확립하는 유지 관리되는 메커니즘도 없다는 것입니다. 초안은 암호학적 인증을 가치 있는 확장으로 제안하면서, 실시간으로 키 서버에 접근할 수 없는 시스템에서는 문제가 어렵다고 언급했습니다. 이 관찰은 초안의 서술에 국한되며, 특정 위조가 발생했거나 모든 사이트가 위조된 필드를 받아들였다는 증거가 아닙니다.

이후의 프로토콜인 RFC 5537은 주입 경로를 형식화했습니다. 주입 에이전트는 승인되지 않은 게시물을 가장 왼쪽 모더레이션 그룹의 모더레이터에게, 관행상 이메일로 전달합니다. 승인과 주입은 일상적 릴레이와 별개로 유지됩니다. 이후의 사양은 이 분업을 명시적으로 만들 수 있음을 보여줍니다. 그러나 이를 1980년대 모든 뉴스 설치에 그대로 투영해서는 안 됩니다.

이 표시가 이룬 것과 남겨 둔 것

Approved:줄은 암호학적 증명이 없다는 이유로 무의미하지 않았습니다. 멀리 떨어진 뉴스 소프트웨어에 게시물 처리를 위한 공유 조건과 실용적인 모더레이션 주소를 제공했습니다. 편집 결정을 분산 출판 시스템과 함께 이동할 만큼 휴대 가능하게 만들었습니다. 그러나 그 휴대성은 헤더를 둘러싼 신뢰 조치의 경계에서 멈췄습니다.

이 구분이 역사적 요점입니다. 네트워크는 승인에 대한 주장을 전달할 수 있었지만, 텍스트만으로 주장 이면의 권위를 추론할 수 없었습니다. 사람의 검토, 주소 관리, 로컬 정책, 소프트웨어 처리는 서로 다른 절차의 부분으로 남았습니다. 표준은 결정이 나타날 자리를 만들었지, 누가 결정했는지 증명하는 보편적 메커니즘을 만들지 않았습니다.

출처