요약

  • 문법상 올바른USER에 대해 RFC 1204는 서버가 이름을 인식하지 못하더라도250으로 응답하도록 권고했다. 이 응답은 계정 존재를 확인하는 것이 아니라 계정 나열을 막기 위한 것이었다.
  • PASS 250은 이후 별개의 주장을 담았다: 비밀번호가 제시된 이름과 올바르게 연관된 것으로 검증되었다는 것이다.DATA 354는 본문 수신 준비만을 개시했고, 본문 뒤에 오는250이 로컬 큐 저장을 확립했다.
  • NOOP 250은 여전히 세션 중 내부 오류가 없는 투입 서버만을 기술했다. 이 숫자는 명령, 상태, 응답한 구성 요소와 결합할 때만 의미를 얻었다.

첫 성공은 의도적으로 불완전했다

프로토콜은 침묵으로만이 아니라 응답 자체로 정보를 숨길 수 있다.RFC 1204가USER명령에 대해 규정한 것이 바로 이것이다. 클라이언트는 메일 투입 서버에 이름을 제출한다. 문자열이 수용 가능하면 서버는250으로 응답할 수 있다. 그러나 문서는 그 이름이 인식되지 않을 때에도 같은 응답을 해야 한다고 덧붙인다.

목표는 돌려 말하지 않았다: 사용자 기반에 관해 과도한 정보를 제공하지 않고, 클라이언트가 특정 이름의 존재를 시험하지 못하게 하는 것이다. 따라서 서버는 완료된 인증에 대해 거짓말을 하는 것이 아니다. 이 시점에서 서버는 어떤 인증도 선언하지 않는다. 서버는 하나의 형식을 수용하고, 알려진 계정과 알 수 없는 계정이라는 두 내부 상태를 동일한 관측 가능한 표면 뒤에 유지한다.

이 분리는 로그 해석을 바꾼다. "250, 명령 성공"은 너무 빈약하다. 결과는USER가 허용한 상태 전이에 관한 것이지, 명명된 대상의 진위에 관한 것이 아니다. 이 줄을 "유효한 계정"으로 바꾸는 콘솔은 프로토콜이 구축하려 한 기밀 유지 통제를 무력화한다.

RFC Editor 공지는 Experimental 등급과 1991년 2월 발행을 그대로 유지하고 있다.Datatracker 문서 페이지는 오늘날 이 RFC가 Legacy 스트림에 속하며, 공식 소스 등록 이전의 것으로서 현재 IETF 절차에서 승인도 지위도 없음을 밝힌다. 이 문서는 역사적 제안을 증명할 뿐, 광범위한 배포나 현대적 권고를 입증하지 않는다.

중개자는 투입을 맡았지만 메일 시스템 전체가 아니었다

출발점의 문제는 그 시대의 것이었다. RFC에 따르면 마이크로컴퓨터 운영체제는 사용자 인증 메커니즘을 제공하지 않았는데, 메일은 발신자 사칭을 제한해야 했다. 서비스 호스트에 놓인 메일 투입 서버는 PC 사용자를 검증한 뒤 그 메일을 Sendmail이나 MMDF 같은 배달 시스템에 넘겨야 했다.

세 가지 책임이 이미 존재했다: 클라이언트는 데이터를 제시했고, 투입 서버는 자격 증명을 판정하고 로컬 큐를 보유했으며, 배달 시스템은 이후 단계를 수행했다. Netix 프로토콜은 TCP 포트 218을 사용하고 SMTP와 FTP의 명령/응답 문법을 차용했다.

이 혈연이DATA, 마침표 종료, 숫자 응답 클래스를 설명한다. 그러나 맥락까지 지우지는 않는다.RFC 821은 송신자와 수신자 간 순차적 SMTP 대화를 기술했다. MPP는 이 언어를 다른 경계—개인용 컴퓨터와 투입 에이전트를 잇는 경계—에 재사용했다. 익숙한 값이 서로 다른 판정을 담을 수 있었던 이유다.

비밀번호는 두 번째 시험이었다

USER의250이후 클라이언트는PASS를 보냈다. 여기서 새250은 비밀번호가 수용되었고 앞서 제시된 이름과 올바르게 연관된 것으로 검증되었음을 뜻했다.530은 이 연관 관계의 실패를 알렸고, 다른 응답들은 문법, 순서, 내부 오류를 다루었다.

시간 순서가 각 응답에 권위를 부여한다. 첫 응답은 계정 인식 여부를 드러내지 않는다. 두 번째 응답은 인증 데이터 비교를 서술한다. 둘을 합치면 나열 방지 보호와 비밀 검증이 실제로 이루어졌다는 증명 중 하나가 사라진다.

이 검증조차 로컬에 머물렀다. 키보드 앞 사람의 시민 신원, 각 문장의 저작자, 임의 목적지에 쓸 권리, 내용의 진실성을 보증하지 않았다. 투입 서버가 자기 환경 안에서 이름/비밀번호 쌍에 대해 내린 결론만을 말한 것이다.

RFC 4954는 훨씬 나중에 SASL 기반 SMTPAUTH확장을 도입했고, 메커니즘 협상과 고유 응답을 갖추었다. 이는 평문 비밀번호 메커니즘이 TLS 또는 동등한 도청 방지 보호 없이는 거부될 수 있음도 요구한다. 이 대비는 MPP의 한계를 드러낸다. 이 보호를 소급해 RFC 1204에 귀속시키거나 직계 계보를 주장해서는 안 된다.

읽을 준비가 되었다는 것은 메시지를 보관한다는 뜻이 아니었다

비밀번호가 수용되면DATA는354를 받을 수 있었다. 이 코드는 서버가 텍스트를 읽을 준비가 되었음을 알렸다. 파서 상태를 바꾸고 이후 바이트를 허용했다. 그러나 본문의 끝도, 영속적 기록도 확인하지 않았다.

클라이언트는 이어서 메시지와 SMTP에서 빌린 종료 시퀀스를 보냈다. 이 종료 이후에만250은 세 번째 의미를 갖는다: 텍스트가 성공적으로 배달 큐에 저장되었다는 것이다. 내부 오류로 큐 저장이 막히면 서버는451로 응답했다.

큐는 로컬 보호 장치를 확립했지만 최종 결과는 아니었다. RFC는 투입 서버가 수용된 메시지를 배달 시스템에 신속히 전달하려 노력할 것을 요구했다. 배달 실패는 그 시스템에 맡겨지고, 투입 서버는 개입하지 말라는 요구를 받았다.

이 분할은 큐 저장을 수신함 수신, 소프트웨어 표시, 인간의 읽기로 바꾸는 것을 금지한다. 한 구성 요소는 다음 단계를 위해 대상을 보존한다는 자기 약속을 정확히 이행하면서도, 이후 단계에 대한 관측권은 가지지 않을 수 있다.

네 번째250은 투입만을 감시했다

NOOP는 메시지에 어떤 연산도 수행하지 않았다. 그250응답은 투입 서버가 진행 중인 세션에서 내부 오류를 겪지 않았음을 나타냈다. 이 건강 상태는 배달 시스템까지 확장되지 않았다.

같은 코드는 네 가지 사실을 감싸며, 단일 라벨과는 양립할 수 없다:

  • 문법상 수용 가능한 이름에 대한 계속 진행, 인식 여부는 비밀 유지;
  • 이름/비밀번호 연관 관계 검증;
  • 완전한 본문의 로컬 큐 저장;
  • 투입 서버에서 알려진 내부 오류의 부재.

따라서 바람직한 관측 단위는 고립된 코드가 아니다. 프로토콜, 연결, 명령, 이전 상태, 새 상태, 응답한 구성 요소, 대상을 함께 유지해야 한다. 그러지 않으면 자동화는 보안상의 모호성을 인증으로, 로컬 보호 장치를 배달로, 한 에이전트의 상태를 전체 체인의 상태로 혼동한다.

현대적 투입 분리는 역할의 가치를 확인했다

RFC 6409는 이후 포트 587의 투입을 형식화했다. 사용자 소프트웨어에서 메시지를 수용해 배달하거나 릴레이하는 Message Submission Agent와, 전송을 담당하는 Message Transfer Agent를 구분한다. 이 분리는 서로 다른 보안 정책과 메커니즘을 적용할 수 있게 한다.

이 유비는 구조적 비교이지 계보가 아니다. MPP가 채택되었음을, 혹은 후속 표준을 낳았음을 증명하지 않는다. 역할 이름이 계속 필요한 이유를 보여줄 뿐이다. 투입을 수용하는 에이전트는 사용자와 로컬 큐를 알 수 있으면서도 실제 목적지를 아직 모른다. 그 성공은 실재하지만 자기 경계에 국한된다.

따라서 RFC 1204는 통제된 무지의 작은 문법으로 다시 읽을 만하다. 이 프로토콜은 첫 교환에서 계정 존재를 의도적으로 숨기고, 검증을 두 번째 교환에 남겨 두며, 로컬 큐가 배달 시스템을 대신해 말하지 못하게 했다. 세 자리 숫자는 단독으로 결코 보편적 판정이 아니었다.

출처