요약

  • Eric Allman이 1994년에 발표한 회고에 따르면, Sendmail의 본격적인 개발은 1987년 2월 이후 중단되었다가, 벤더와 외부 기여자들이 파생 버전을 늘려가던 뒤인 1991년 7월에 재개되었습니다.
  • Allman이 복귀한 이유로는 Berkeley의 변경 요구, 버전 간 분기, 그리고 대부분의 구현에는 반영되지 않았다고 보았던 SMTP 확장을 꼽았습니다.
  • Sendmail 8.6.6은 일부 확장을 지원했지만 다른 확장은 지원하지 않았습니다. 공개된 버전은 이 한계를 검증 가능하게 만들었으나, 채택 여부나 완전한 준수를 증명하지는 못했습니다.

긴 정지가 버전 문제로 변한 이유

Sendmail은 상용 제품이 되거나 자유 소프트웨어 경제 논쟁의 상징이 되기 전에 이미 Berkeley Unix 환경의 일부였습니다. Internet Hall of Fame의 약력은 Eric Allman이 캘리포니아 대학교 Berkeley에서 INGRES 작업을 하던 중 delivermail과 Sendmail을 개발했고, 두 소프트웨어가 BSD와 함께 배포되었다고 기술합니다. 이 맥락은 공개 코드의 의미를 설명해 줍니다. 시스템 빌더들은 자신의 환경에서 메일 라우터를 검토하고 컴파일할 수 있었습니다.

Allman은 1994년 글 “Changes in Sendmail Version 8”에서 그 이후의 경과를 더 구체적으로 짚습니다. Sendmail에 대한 본격적인 작업은 사실상 1987년 2월 이후 중단되었다가, 1991년 7월에 활발히 재개되었습니다. 그 사이 다른 사람들이 최소한의 유지 보수를 담당했고, 벤더와 외부 기여자들은 파생 버전을 만들고 있었습니다. Allman은 복귀 이유로 여러 가지를 들었습니다. Berkeley는 하위 도메인 구조와 4.4BSD를 위한 진화가 필요했고, 그는 Bryan Costales의 Sendmail 책을 다시 읽었으며, 분기된 버전을 다시 통합해야 했고, SMTP 표준도 바뀌었습니다.

이는 단일 트리거를 둘러싼 전환 서사가 아니라 여러 동기의 모음입니다. 코드는 BSD의 새 버전과 함께 나아가야 했고, 갈라진 분기를 조정해야 했으며, 프로토콜의 변화에도 대응해야 했습니다. Allman은 설정 파일에서 출발한 IDA-Sendmail이 상당한 규모의 패치 집합으로 변했고, 자체적으로 소스를 빌드하던 이들에게 널리 쓰였다고 설명합니다. 또한 IDA 그룹과 대부분의 벤더가 최근의 SMTP 명세화·확장을 반영하지 않았다고 덧붙입니다. 이것은 1994년의 회고적 판단이지, 벤더나 설치 환경을 각각 독립적으로 조사한 결과가 아닙니다.

이 구분이 핵심입니다. 표준은 공표될 수 있지만 실제 운용 중인 소프트웨어는 더 오래된 가정을 유지할 수 있습니다. 구현이 비공개이거나, 파편화되어 있거나, 구하기 어렵다면 운영자에게는 규범 문서와 자신이 테스트할 수 있는 대체 버전 사이에 실행 가능한 경로가 없을 때가 있습니다. 공개 버전은 변경 사항과 한계를 보이게 만들어 이 간극을 줄일 수 있습니다. 그러나 공개만으로 벤더가 변경 사항을 릴리스하게 만들거나, 관리자가 그 버전을 설치하게 하거나, 원격 서버가 이를 수용하게 할 수는 없습니다.

버전 8은 한계를 보이게 만들었다

이 글은 지원이 이분법적이지 않다는 점을 보이기 위해 Sendmail 8.6.6을 예로 듭니다. 해당 버전은 RFC 1425가 정의한 기본 ESMTP, RFC 1427의 SIZE 확장, RFC 1426의 BODY 파라미터에 대한 제한적인 지원을 제공했다고 기술합니다. 동시에 8BITMIME은 광고(announce)되지 않았으며, 8비트 전송을 지원하지 않는 SMTP 서버를 위한 메시지 변환도 올바르게 처리되지 않았다고 밝힙니다.

이런 세부 사항은 “Sendmail 8은 새 SMTP 표준을 지원했다”는 일반적 주장보다 정확합니다. 기능을 특정 버전과 결부시키기 때문입니다. RFC 1425는 EHLO에 기반한 ESMTP 교환을 정의하고, RFC 1427은 메시지 크기를 다루며, RFC 1426은 이후 8BITMIME과 연관된 BODY 확장을 정의합니다. 원격 서버가 광고하는 기능, 발신자의 선택, 수신자의 동작이 모두 전송에 영향을 줍니다. 이 글은 설치 환경이 언제 업그레이드했는지, 이런 사례가 운용에서 얼마나 자주 발생했는지는 말하지 않습니다.

Sendmail Version 8의 변경 사항을 다룬 다른 페이지는 이 소프트웨어를 RFC 1123에 대해 “조건부로 준수(conditionally compliant)”한다고 기술하고, 충족된 요구 사항과 남아 있는 유보 사항을 나열합니다. 이 페이지는 1994년 글보다 최신 확장 RFC 번호들을 인용합니다. 따라서 두 문서를 하나의 기능 목록으로 합쳐서는 안 됩니다. 두 문서를 함께 보면, 준수 언급에는 버전과 규범 문서, 그리고 예외가 함께 명시되어야 함을 보여 줍니다.

그러므로 Allman의 기여는 단순히 주요 버전을 공개한 것이 아니었습니다. 그의 글은 구현의 인터페이스를 읽을 수 있게 만들었습니다. 어떤 확장이 있었고, 무엇이 부분적이었으며, 변환이 어디서 실패했는지가 드러났습니다. 8로의 번호 도약에는 더 소박한 설명이 있습니다. 4.4BSD 배포 파일이 이미 8.1이라는 번호를 달고 있었다는 것입니다. 이 번호는 모든 프로토콜 문제가 해결되었다는 뜻이 아니었습니다.

공개 코드는 운영자에게 검증 가능한 대상을 주었다

Lu Heng의 각주 65는 유용한 편집적 관점을 제공합니다. 공표된 표준과 실행되는 코드는 서로 다른 질문에 답합니다. 이 각주는 Allman의 동기나 Sendmail의 역사에 대한 증거가 아닙니다. 여기에 적용하면 이 구분은 실무적입니다. 표준은 시스템이 무엇을 할 수 있어야 하는지를 기술하고, 소스 버전은 구현을 검토할 수 있게 하며, 테스트와 운용 환경의 교환은 특정 시스템 쌍이 실제로 무엇을 했는지를 보여 줍니다.

공개 코드는 업무의 배분도 바꿉니다. 유지 관리자는 공통 변경 사항을 공개할 수 있고, 벤더는 패치를 포팅할 수 있으며, 운영자는 자신의 로컬 동작을 공개된 소스와 비교할 수 있습니다. 그러나 설정 차이, 비공개 패치, 오래된 패키지는 공개 이후에도 남을 수 있습니다. 공개 코드는 검토와 수리의 가능성을 여는 것이며, 유지 비용을 없애지는 못합니다.

결론은 범위를 지켜야 합니다. Allman의 회고에서 Sendmail의 중단은 진화하는 SMTP 문서와 많은 사용자가 접근할 수 있던 구현 사이의 간극을 넓혔습니다. 버전 8은 공개 비교 기준점을 제공하고 최근의 일부 확장을 반영했지만, 8.6.6에서 보듯 명시적인 한계를 그대로 안고 있었습니다. 표준도 공개도 보편적인 배포를 증명하지는 못합니다. 유용한 질문은, 소프트웨어가 부족할 때 운영자가 정확한 버전을 식별하고 동작을 테스트하며 유지 보수 경로를 선택할 수 있는지입니다.

출처