요약

  • Newsgroups는 현재 글이 게시된 위치를 나타내고,Followup-To는 새로 작성되는 후속 글이 어디로 가야 하는지 요청합니다. 원본 글은 게시된 곳에 그대로 남습니다.
  • 특별한 소문자 값poster는 기본 응답 매체를 바꿉니다. 응답은 뉴스그룹에 게시하는 대신Reply-To로, 회신 주소가 없으면From으로 이메일로 보내야 합니다.
  • RFC 5537은 두 형태 모두 새로 게시하는 사람이 재정의할 수 있는 게시 에이전트 기본값으로 다룹니다.References는 계보를,Distribution은 배포 범위를 각각 보존하므로, 목적지는 계보도 접근 통제도 아닙니다.

한 글이 두 방에, 답장 하나는 세 번째 방에

두 기술 뉴스그룹에 교차 게시된 공지를 상상해 보십시오. 양쪽 독자 모두 같은 원본 글을 볼 수 있습니다. 그 글의Followup-To는 토론 전용 세 번째 뉴스그룹을 지목합니다. 독자가 “후속 작성”을 선택하면 클라이언트는 그 세 번째 방으로 올릴 새 글을 준비합니다.

처음 두 뉴스그룹에서 아무것도 회수되지 않았습니다. 독자들은 접근을 잃지 않았고, 원본 글도 위치가 바뀌지 않았습니다. 달라진 것은 미래의 글에 제안되는 목적지뿐입니다.

이것은 반복되는 문제에 대한 간결한 해답이었습니다. 교차 게시는 한 공지를 여러 커뮤니티에 보이게 할 수 있지만, 모든 응답을 그 모든 곳에 복사하면 트래픽이 배로 늘고 주의가 분산됩니다. 이식 가능한 답장 기본값을 두면 탐색 범위는 넓게 유지하면서 대화는 한곳으로 모을 수 있었습니다.

첫 번째 분리는 이미 명시적이었다

RFC 850은Followup-To에Newsgroups와 같은 뉴스그룹 목록 형식을 부여했습니다. 이 필드가 있으면 후속 글은 그 목록의 뉴스그룹에 게시되도록 했고, 없으면 보통 원본 글의 뉴스그룹으로 돌아갔습니다. 다만 초기 특수 사례로, 광범위한net.general그룹으로 들어오는 답장은net.followup으로 우회되었습니다.

이 오래된 예외는 역사적으로 시사하는 바가 큽니다. 일반 필드가 널리 쓰이기 전에도, 네트워크는 공지를 읽기에 가장 좋은 장소가 그 토론을 진행하기에 가장 좋은 장소일 필요는 없음을 인식하고 있었습니다.

이 필드는 현재 글의Newsgroups값을 다시 쓰지 않았습니다. 다음 글의 구성에 영향을 주었을 뿐입니다. 이 구분 덕분에 원본 글의 게시 기록은 안정적으로 유지되면서 대화가 다른 운영 장소를 갖도록 할 수 있었습니다.

단어 하나가 매체를 바꿀 수 있었다

RFC 1036은 뉴스그룹 재지향을 유지하면서 특별 키워드poster를 도입했습니다. 이 경우 후속 글은 게시하지 않고, 대신 응답을 제출자에게 메일로 보내야 했습니다.

RFC 5536은 이 요청을 더 정확하게 만듭니다.Followup-To는 게시자가 후속 글의 게시 장소로 요청한 곳을 지정하며, 단순히Newsgroups를 반복할 때는 보통 생략해야 합니다. 필드가 없으면 이미 “원래 장소로 돌아간다”는 기본 동작이 담겨 있습니다.

소문자 토큰poster는 뉴스그룹 이름이 아니라 예외적인 문법입니다. 클라이언트에게 응답을 직접 이메일로 보내라고 요청하며,Reply-To가 있으면 그 주소를, 없으면From을 사용합니다. 원본 글은 자신의 뉴스그룹에서 계속 공개 상태입니다. 새 응답의 기본 동작만이 Netnews에서 메일로 넘어갑니다.

메일에는 자체적인 주소 지정 권한이 있었다

이 대체 경로가 Netnews 안에 이메일 의미론을 새로 발명한 것은 아닙니다.RFC 5322는Reply-To를 작성자가 회신을 권장하는 주소로 따로 정의합니다. 이 필드가 없으면 회신은 보통From을 사용해야 하며, 회신을 작성하는 사람이 다르게 선택하는 경우는 예외입니다.

이 계층화가 중요합니다.Followup-To: poster는 매체를 선택하고 글의 회신 주소 근거를 가리킵니다.Reply-To나From이 우편함 목적지를 제공합니다. 메일 전송 계층이 배달 성공 여부를 결정합니다. 어떤 단일 필드도 우편함 소유권, 도달 가능성 또는 수신을 증명하지 못합니다.

또한 이 비공개 기본값이 원본 글을 기밀로 만들지는 않습니다. 원본을 읽을 수 있었던 모든 사람은 여전히 읽을 수 있습니다. 독자는 그 글을 다른 곳에 인용할 수 있고, 다음 게시자는 기본값을 재정의할 수 있습니다. 이 토큰은 기대되는 행동을 정리할 뿐, 프라이버시 경계를 만들지 않습니다.

다음 게시자는 여전히 새 게시물을 소유했다

RFC 5537은 후속 글 작성을 일련의 기본값으로 설명합니다. 원본 글이poster라고 하면 게시 에이전트는 기본적으로 게시해서는 안 되며 대신 이메일 회신을 준비합니다. 사용자는 이 선택을 재정의할 수 있고, 그러면 클라이언트는 그 필드가 없는 것처럼 진행합니다.

뉴스그룹 목록 값의 경우, 새 글의Newsgroups는 원본 글의Followup-To를 상속해야 합니다. 필드가 없으면 원본의Newsgroups를 상속합니다. 역시 게시자는 제출 전에 초기 내용을 바꿀 수 있습니다.

권한 배분은 의도적입니다. 첫 게시자는 토론에 유용한 장소를 요청할 수 있습니다. 읽기 에이전트는 그 선택을 안전하게 제시할 수 있습니다. 응답을 작성하는 사람은 새 게시물의 독자층에 대해 책임을 유지합니다. 이전 글의 헤더가 모든 후손을 영구히 입법할 수는 없습니다.

목적지, 계보, 범위는 서로 독립적으로 남았다

후속 글은 자신을 원본 글에 연결하는References도 반드시 담아야 합니다. 새 글이 다른 뉴스그룹에 게시되더라도 그 계보는 유지됩니다. 토론을 옮기는 것이 그 토론의 출처를 지우지는 않습니다.

Distribution은 별도의 규칙을 통해 상속됩니다. 새 뉴스그룹 목적지가 자동으로 더 넓은 전파를 허가하지 않고, 좁은 배포 범위가 어느 뉴스그룹이 답장을 받을지 결정하지도 않습니다. 주제, 독자, 계보, 범위는 서로 관련되지만 어느 한 필드도 네 가지를 모두 대신하지 못합니다.

이 분리는 악용도 드러냅니다. RFC 5537은 관련 없는 뉴스그룹으로 후속 글을 요청하면 그 뉴스그룹을 혼란에 빠뜨릴 수 있다고 경고합니다. 유효한 이름이 목적지의 주제 적합성을 증명하지는 못합니다. 클라이언트와 사용자는 상속된 값을 조용히 따르기보다, 전환을 전송 전에 확인해야 합니다.

등록은 경로가 아니라 요청을 안정화했다

현재IANA 메시지 헤더 레지스트리는Followup-To를 RFC 5536을 참조하는 표준 Netnews 필드로 등재합니다. 구현체들은 이름과 문법에 대해 합의할 수 있습니다.

그러나 레지스트리는 오늘날의 클라이언트 지원을 확립하거나, 사용자가 목적지를 검토했음을 증명하거나, 회신 우편함을 인증하거나, 게시나 메일 배달을 보장하지 않습니다. 공식 문서는 프로토콜 역사와 기본값을 정의할 뿐, 현재의 채택 상황을 정의하지 않습니다.

역사적 성취는 대화의 인수인계를 의무처럼 가장하지 않고 보이게 만든 것이었습니다. 글은 독자가 읽던 곳에 머물 수 있었습니다. 응답은 더 적절한 곳에서 시작될 수 있었습니다. 그 둘 사이의 경계는 새 저자의 결정이었고, 이전 글은 그 결정을 도왔을 뿐 소유하지 않았습니다.