요약

  • RFC 1425는 SMTP 서비스 확장을 위한 공통 발견 지점으로EHLO를 도입했습니다. 성공적인 응답은 한 세션에 대한 기능을 기술했으며, 클라이언트가 그 정보를 다음 세션을 위해 캐시하는 것은 명시적으로 금지되었습니다.
  • 이 명세는 깔끔한 호환성 경로를 제시했습니다. 구형 서버는EHLO를 거부하면서도 접속 상태를 유지하고HELO를 허용할 수 있었습니다. 그러나 RFC 1651은 그 대신 접속을 끊거나 거부 후HELO를 거부하는 배포 중인 서버들을 문서화했습니다.
  • 역사적 기록은 등록된 확장, 세션 광고, 사용 가능한 폴백, 수락된 명령, 완료된 메일 트랜잭션, 그리고 전달을 서로 구분합니다. 어느 것도 다음 단계의 증거로 사용될 수 없습니다.

1993년 2월, 인터넷 메일은 모든 메일 서버가 동시에 바뀌지 않고도 변화할 수 있는 방법을 필요로 했습니다.

SMTP가 십여 년 넘게 살아남은 것은 부분적으로 그 대화가 작고 예측 가능했기 때문이었습니다. 클라이언트는 접속하고, 인사말을 받고,HELO로 자신을 소개하고, 봉투를 제공한 뒤 본문을 보냈습니다. 새로운 요구가 쌓여가고 있었지만, 각각을 무관한 명령이나 사적 관례로 추가하는 것은 그 공유된 대화를 방언들의 집합으로 만들 위험이 있었습니다.

RFC 1425는 얇은 공통 계층을 제안했습니다. 이는 모든 미래의 확장을 정의하지 않았습니다. 대신 확장된 클라이언트가 한 서버가 지원한다고 말하는 기능을 어떻게 발견할 수 있는지를 정의했습니다. 즉 세션을EHLO로 시작하고, 등록된 키워드와 선택적 매개변수를 담은 응답을 받으며, 양쪽이 그 경로를 선택하는 경우 키워드 뒤에 있는 별도의 명세를 사용하는 것입니다.

이것은 레지스트리이자 문법이자 공개의 순간이었습니다. 보편적인 업그레이드는 아니었습니다.

하나의 응답은 하나의 세션을 기술했다

시간 경계는 이례적으로 명시적이었습니다. 클라이언트가 확장 기능에 대한 정보가 필요하다면, 각 SMTP 세션의 시작에서EHLO를 발행해야 했습니다. 이전에 성공한EHLO가 반환한 정보를 캐시해서는 안 되었습니다.

이 규칙은 어제의 관찰이 오늘의 권위가 되는 것을 막았습니다. 동일한 호스트 이름이 다른 프로세스, 구성, 경로, 유지 보수 상태 또는 서버로 이어질 수 있었습니다. 아무것도 바뀌지 않았더라도 프로토콜은 여전히 현재의 전송 채널 안에서 새로운 선언을 요구했습니다.

성공적인EHLO는250응답을 사용했습니다. 또한 특정 상태를 확립했습니다. 클라이언트와 서버는 시작 지점에 있고, 메일 트랜잭션은 진행 중이 아니며, 상태 테이블과 버퍼는 비어 있었습니다. 그 후 다중 행 응답이 키워드를 열거할 수 있었습니다. 키워드 인식은 대소문자를 구분하지 않았습니다. 등록된,X가 아닌 키워드는 확장 명세에 연결되었고, 로컬로 합의된 키워드는 그 시대의X관례를 사용했습니다.

이 목록은 완료된 작업에 대한 보고가 아니었습니다. 더 좁은 질문에 답했습니다. 이 서버가 지금 이곳에서 어떤 확장된 동작을 광고하는가? 클라이언트는 여전히 확장을 선택하고, 자체 RFC가 정의한 명령이나 매개변수를 구성하고, 관련 응답을 받아야 했습니다.

RFC 1426은 이 구분을 구체적으로 만들었습니다.EHLO응답에서8BITMIME을 보는 것이BODY=8BITMIME을 담은MAIL FROM을 보내는 것보다 앞섰습니다. 그 확장 명령의 수락이DATA보다 앞섰습니다. 메시지에 대한 책임이 어떤 다음 홉 결정보다 앞섰습니다. 비트 보존 규칙은 RFC 1425가 아닌 RFC 1426에 속합니다. 증거 순서는 양쪽에 속합니다.

깔끔한 폴백은 보존된 상태를 가정했다

확장 발견은RFC 821만 알던 서버들과 공존해야 했습니다. RFC 1425는 예상되는 만남을 기술했습니다. 구형 서버는EHLO를 인식하지 못하고 오류를 반환하며 계속 사용 가능한 상태로 있을 것이었습니다. 클라이언트는 리셋하거나HELO를 보내고 더 오래된 SMTP 규칙 아래에서 계속할 수 있었습니다.

문서 위에서는 이것이 신중한 호환성 설계였습니다. 새로운 클라이언트는 새로운 어휘를 시험했습니다. 실패가 구형 상대에게 구현을 강요하지 않았고, 거부가 상대를 결함이 있는 것으로 표시하지도 않았습니다. 양측은 단순히 공통 호환성 집합을 선택했습니다.

그러나 이 전환은 응답 코드보다 더 많은 것에 의존했습니다. 서버가 전송 채널을 열어 두는 것에 의존했습니다. 알 수 없는 단어 이후 서버의 명령 상태가 유효하게 남아 있는 것에 의존했습니다. 뒤따르는RSET또는HELO가 표준이 기대한 상태에서 해석되는 것에 의존했습니다.

이 의존성들은 실행 가능한 사실이었으며, 구문 다이어그램의 속성이 아니었습니다.

다음 RFC는 결여된 현실을 기록했다

1994년 7월,RFC 1651이 RFC 1425를 폐지했습니다. 확장 프레임워크의 많은 부분은 익숙한 채로 남았습니다. 그러나 새로운 절이 '부적절하게 구현된 서버'를 다루었습니다. 그 존재가 이 개정판의 계시적인 부분입니다.

일부 알려진 서버들은EHLO를 받으면 SMTP 전송 채널을 닫았습니다. 이 닫힘은 즉시 또는 응답 이후에 일어날 수 있었습니다. RFC 821은 채널이QUIT까지 정상적으로 열려 있어야 한다고 했으므로, 이는 새로 허가된 변형이 아니었습니다. 그러나 상호 운용성은 준수 서버가 해야 할 일을 반복하는 것으로 복원될 수 없었습니다.

이제 클라이언트는 채널 자체를 관찰해야 했습니다. 접속이 닫히면, 확장 없이 작업이 성공할 수 있는지 판단해야 했습니다. 그렇다면 새 접속을 열고HELO를 사용할 수 있었습니다. 이 재시도는 원래 상상된 연속이 아니었습니다. 새 인사말, 새 상태, 별도의 결과를 가진 두 번째 세션이었습니다.

다른 서버들은 접속을 유지했지만EHLO를 거부한 후에는HELO를 수락하지 않았습니다. 일부의 경우HELO전에RSET을 보내는 것이 작동할 수 있었습니다. 그러나 거기서도 이 수리는 또 다른 이상을 누적했습니다. 구현이 그RSET에503 Bad sequence of commands로 응답할 수 있었고, RFC는 이 좁은 임시방편에서는 그것을 무시할 수 있다고 말했습니다.

1995년 11월에 RFC 1651을 대체한RFC 1869는 이 운영상의 경고를 유지했습니다. 실제 호환성 문제는 표준의 역사적 기억의 일부가 되었습니다.

교훈은 명세가 쓸모없다는 것이 아닙니다. 개정판은 건강한 명세가 해야 할 일을 정확히 했습니다. 첫 설계가 이미 준수하는 동작을 만들어냈다고 가장하지 않으면서 배포로부터의 증거를 흡수한 것입니다. 운영 코드가 텍스트를 훈련시켰습니다.

폴백은 레이블이 아니라 사슬이다

이 교환을 'ESMTP 미지원, SMTP 폴백 성공'으로 기록하고 싶은 유혹이 있습니다. 그 문장은 서로 다른 여러 사건을 감출 수 있습니다.

TCP 접속은 열렸을 수 있습니다.220인사말이 도착했을 수 있습니다. 클라이언트는EHLO를 보냈을 수 있습니다. 서버는 응답을 반환했을 수도, 응답 전에 닫았을 수도, 응답 후에 닫았을 수도 있습니다. 채널이 살아남았다면RSET은 수락, 거부 또는 무시되었을 수 있습니다. 그다음HELO가 성공했을 수 있습니다. 메일 봉투가 수락되었을 수 있습니다. 본문이 수신되었을 수 있습니다. 릴레이가 책임을 맡았을 수 있습니다. 목적지가 메시지를 전달했을 수도, 그렇지 않았을 수도 있습니다.

각 기록은 자신의 정체성과 시간을 가집니다. 두 번째 접속은 첫 번째를 조용히 덮어써서는 안 됩니다. 성공적인HELO재시도가 이전 채널을 연속적으로 만들지는 않습니다. 광고된 키워드가 그 명령이 수락될 것임을 증명하지는 않습니다.DATA이후의250이 누군가 메시지를 읽었다는 증거가 되지는 않습니다.

이것이 RFC 1425의 캐시 금지 규칙의 더 깊은 가치입니다. 기능은 인벤토리에서 호스트에 붙는 내구성 있는 속성이 되도록 의도된 적이 없었습니다. 그것은 세션 안에서의 선언이었습니다. 채널이 닫히면 그 광고는 의미를 부여한 맥락과 함께 만료되었습니다.

얇은 확장 지점은 위험을 지우는 대신 옮겼다

RFC 1425는 옵션이 적은 프로토콜은 보편화되는 경향이 있고, 옵션이 많은 프로토콜은 obscure해지는 경향이 있다고 경고했습니다. 그리고 모든 확장이 구현, 배포, 상호 운용성 비용과 함께 평가되어야 한다고 요구했습니다. 확장 프레임워크는 작은 공통 발견 표면을 유지하고 구체적인 동작을 별도의 RFC에 할당함으로써 그 비용을 관리했습니다.

이 설계는 구형 서버를 의무적인 전체 대규모 업그레이드로부터 보호했습니다. 또한 호환성 작업을 클라이언트 쪽으로 옮겼습니다. 넓은 도달 범위를 원하는 클라이언트는 다중 행 응답을 구문 분석하고, 오류 경로를 구별하고, 낡은 기능 상태를 폐기하고, 발견 자체에 잘못 반응하는 상대를 생존해야 했습니다.

이 배치는 실용적인 의미에서 분산적이었습니다. 등록은 키워드에 공통 의미를 부여했지만 배포를 만들지는 않았습니다. 서버는 로컬로 어떤 확장을 실행할지 선택했습니다. 클라이언트는 로컬로 어떤 광고된 경로를 사용할 수 있는지 선택했습니다. 전환 기계가 실제로 작동하는 경우, 구형과 신형 상대는 더 작은 공유 언어로 계속할 수 있었습니다.

'실제로'라는 단어가 역사를 담고 있습니다. 공표된 폴백은 의도된 상태 기계를 기술할 수 있습니다. 두 참여자 모두 그 안에 존재했음을 보여줄 수 있는 것은 관찰된 순서뿐입니다.