요약

  • SMTP AUTH는 클라이언트와 서버가 메일 트랜잭션에 앞서 SASL 메커니즘을 협상할 수 있게 하여, 제출 서버가 포트 25에 도달할 수 있는 임의의 호스트가 아니라 인증·인가된 신원에게 릴레이 권한을 부여하도록 했다.
  • 이 확장의 가장 강력한 규칙은 한계였다. 성공적인 인증은 세션 경계 한 곳에서의 제출만을 다룬다. 봉투 발신자, 주장된 원 제출자, 헤더 작성자, 메시지 본문은 별개의 주장으로 남는다.

옛 관문은 여행자가 아니라 연결을 알아봤다

SMTP는 협력하는 기계들 사이에서 메일을 이동시키기 위해 설계되었다. 서버는 접속 주소를 검사하고, 로컬 수신자에게 온 메일을 받아들이며, 다른 곳으로 릴레이할지 판단할 수 있었다. 신뢰가 작은 네트워크나 보호된 사이트를 따라가던 시절에는 이것으로 충분했다. 그러나 공개 서버가 단순한 접근 가능성을 발송 허가로 취급하는 순간 위험해졌다.

발신 주소 규칙은 모바일 사용자에게도 좋은 답이 아니었다. 여행 중인 사용자는 유효한 계정을 갖고 있으면서도 낯선 네트워크에서 접속하는 것처럼 보일 수 있었다. 반대로 허용된 주소 범위 안의 기계가 반드시 발신자 신원을 사용할 권한을 가진 사람인 것은 아니었다. POP-before-SMTP는 다른 프로토콜의 최근 로그인을 차용하려 했지만, 제출 행위 자체가 아니라 주소와 타이머로 두 세션을 연결했다.

1999년의 SMTP 인증 확장, 이후 RFC 4954로 대체된 확장은 이 질문을 SMTP 안으로 옮겼다. 서버는 EHLO 응답에 SASL 메커니즘 목록과 함께AUTH를 광고했다. 클라이언트는 메커니즘 하나를 선택하고 메일 트랜잭션을 시작하기 전에 챌린지-응답 교환을 완료했다. 성공은 세션 사실을 만들었다. 서버가 인증 교환을 수락하고 로컬 정책에 따라 인가 신원을 도출했다는 사실이었다.

그 사실은 릴레이 접근을 정당화할 수 있었다. 그러나 메시지를 누가 썼는지는 말해주지 않았다.

인증과 인가는 다른 이름이었다

SASL이 핵심 구분을 제공했다. 인증 신원은 자격 증명에 속한다. 서버가 검증하는 계정, 인증서 또는 다른 주체다. 인가 신원은 클라이언트가 그 신원으로 행동할 권한을 요청하는 신원이다. 서버는 자격 증명을 가진 신원이 요청된 역할을 수행할 수 있는지를 판단해야 한다.

이 구분은 의례적이지 않다. 한 관리자가 공유 서비스 계정을 운영할 수 있다. 하나의 메일 큐는 여러 사용자가 원래 제출한 메시지를 릴레이하면서 서버로서 인증할 수 있다. 위임받은 비서는 특정 사서함에 대해서는 제출할 수 있고 다른 사서함에는 그렇지 않을 수 있다. 유출된 자격 증명은 올바르게 인증되면서도 원래 수행하도록 의도되지 않은 동작을 요청할 수 있다.

따라서 SMTP는 로그인 문자열을MAIL FROM, 표시되는From헤더 또는 인간 작성자와 동등하게 만들지 않았다. 대신 인가 결정을 수신 서버가 강제할 수 있을 만큼 명시적으로 만들었다. 자격 증명은 "이 메커니즘으로 이 세션을 수립한 사람은 누구인가?"에 답한다. 로컬 정책은 "그 신원이 여기서 무엇을 할 수 있는가?"에 답한다. 봉투와 본문은 그 다음의 질문을 던진다.

제출은 하나의 독립된 경계가 되었다

RFC 6409는 이 논리를 별개의 서비스로 만들었다. 포트 587은 메일 사용자 에이전트(MUA)에서 메시지 제출 에이전트(MSA)로의 메시지 제출을 식별한다. MSA는 사용자 대면 클라이언트로부터 새 메시지를 받아 특정 로컬 오류를 수정하거나 거부한 뒤, 배달하거나 MTA 네트워크로 릴레이한다. MTA 간 공개 전송은 여전히 다른 관계다.

기본적으로 MSA는 세션에 SMTP AUTH나 보호된 서브넷 같은 독립적으로 수립된 인가가 없을 때 인증 필요 상태로MAIL명령을 거부해야 한다. 이는 인터넷상의 모든 메일 릴레이가 모든 상위 피어에게 사용자로서 인증을 요구하는 것보다 좁은 범위다. 공급자와 제출 클라이언트가 직접적인 관계를 갖는 지점에 강한 접입 정책을 배치한다.

이 경계 덕분에 로밍이 실용적으로 가능해졌다. 클라이언트는 권한을 증명하기 위해 더 이상 공급자의 접속 네트워크에서 접속할 필요가 없었다. 제출 서비스를 통해 인증하고 그 계정에 부속된 릴레이 권한만을 받으면 되었다. 동시에 인바운드 MTA는 임의의 목적지에 대한 오픈 릴레이가 되지 않으면서 자기 도메인으로 오는 메일은 계속 수용할 수 있었다.

권한은 MSA의 정책에 속한다. IANA의 레지스트리는AUTH키워드와 SASL 메커니즘 이름을 등록할 수 있다. 그러나 어떤 자격 증명이 재무 사서함으로 발송할 수 있는지, 메일링 리스트를 운영할 수 있는지, 인터넷 전체로 릴레이할 수 있는지는 결정할 수 없다.

하나의 세션이 여러 발신자 신원을 실을 수 있었다

RFC 4954는AUTH라는 단어의 두 번째 용법을 추가했다.MAIL FROM에 붙는 선택적 매개변수다. AUTH 명령은 세션을 인증한다.AUTH=봉투 매개변수는 하나의 메시지를, 배달 시스템에 제출했다고 주장되는 신원과 연관 짓는다.

두 값은 같을 필요가 없다. 표준은 하나의 인증된 신원이 많은 인가된 신원을 위해 메시지를 실을 수 있음을 명시적으로 허용하며, 큐 처리 서버가 가장 명확한 예시다. 릴레이는 자기 자신으로 로그인하지만 각 메시지는 서로 다른 원 제출자를 유지할 수 있다. 이는 위임이지 모순이 아니다.

이 규칙은 불확실성에도 표현을 준다.AUTH=<>는 원 제출자가 알려지지 않았거나 충분히 인증되지 않았음을 뜻한다. 수신 서버는 현재 인증된 릴레이가 원 작성자였다고 가정해 그 빈틈을 메우면 안 된다. 상위 주장이 신뢰되지 않는다면, 상위 연결이 성공적으로 인증되었더라도 안전한 값은 '알 수 없음'이다.

신뢰된 환경에서 협력하는 에이전트 사이에서는 서버가 릴레이할 때 제공된 제출자 사서함을 유지할 수 있다. 그 관계 밖에서는 이 문법이 신뢰를 만들지 않는다.AUTH=안의 사서함은 그 권한이 인증된 상위 서버와 수신자의 구성 정책에서 나오는 주장이지, 꺾쇠 괄호에서 나오는 것이 아니다.

암호화는 교환을 보호했지, 의미를 보호하지 않았다

인증 메커니즘이 자격 증명을 보호하는 방식은 모두 같지 않다. RFC 4954는 TLS나 다른 보호 계층이 활성화되어 있지 않는 한 평문 비밀번호 메커니즘을 제외하는 구성을 서버가 지원하도록 요구한다. 광고된 메커니즘 목록은 STARTTLS 이후 달라질 수 있다. 평문에서 안전하지 않은 메커니즘이 보호된 채널 안에서는 수용 가능해질 수 있기 때문이다.

현대의 제출 지침은 사용자 에이전트와 제출 서버 사이의 모든 트래픽에 TLS를 권장한다. 포트 587은 흔히 제출과 STARTTLS를 결합하고, 포트 465는 SMTP 명령에 앞서 암묵적 TLS를 시작한다. 올바른 인증서 검증은 클라이언트가 어떤 서버가 자격 증명을 받는지 알 수 있게 하고, 암호화는 수동적 관찰자가 자격 증명을 읽지 못하게 한다.

이 성질들은 실질적이지만 한정적이다. TLS는 하나의 연결을 보호할 수 있다. SASL은 자격 증명을 검증하고 때로 자체 보안 계층을 협상할 수 있다. 그러나 어느 쪽도 표시된 헤더에 이름이 적힌 사람이 본문을 썼다는 것, 메시지가 제출 경계 이후 변경되지 않았다는 것, 이후 모든 릴레이가 암호화를 사용했다는 것을 증명하지 못한다. RFC 4954는 이 구분을 직접 말한다. SMTP AUTH는 메시지 본문의 작성이 아니라 제출을 인증한다.

추적 기록은 한 홉을 기록했지, 생애를 기록하지 않았다

인증에 성공한 뒤 서버는ESMTPA나ESMTPSA같은 등록된Received전송 토큰을 사용할 수 있다. 이 토큰은 SMTP AUTH, 또는 SMTP AUTH에 TLS를 더한 조건이 그 서버가 해당 홉을 수용할 때 적용되었음을 기록한다. 이는 가치 있는 운영 증거다. 인증된 제출 경로를 인증되지 않은 인바운드 전송과 구분하고 어뷰즈나 정책 실패를 진단하는 데 도움이 된다.

추적 토큰은 이전 줄들을 신뢰할 수 있게 만들거나 이후 홉들을 안전하게 만들지 않는다. 그것은 한 서버가 자기 경계에서 일어났다고 말하는 일을 기록할 뿐이다. 소비자는 여전히 어떤 서버가 그 필드를 생성했는지, 그 서버가 관리 신뢰 도메인 안에 있는지를 알아야 한다. 홉 증거는 필터가 그것을 보편적 신원 주장으로 격상시킬 때 위험해진다.

같은 절제는 상태 코드에도 적용된다. 235 응답은 인증 성공을 기록한다. 530 거부는 요청된 동작에 인증이 필요함을 말한다. 535 응답은 제시된 자격 증명이 유효하지 않거나 불충분함을 말한다. 어느 것도 헤더 주소가 진실이거나 메시지가 배달받을 자격이 있음을 말하지 않는다. 접입, 발신자 인가, 내용 진위성, 수신자 정책은 별개의 결정으로 남는다.

레지스트리는 계정 선택 없이 선택지를 표준화할 수 있었다

SMTP AUTH는 확장의 성장이 상호운용 가능하도록 두 개의 레지스트리를 사용했다. SMTP 레지스트리는AUTH확장과 그 명령·매개변수 표면을 기록한다. SASL 레지스트리는 참조와 사용 상태와 함께 메커니즘 이름을 기록한다. 서버는 클라이언트가 이해하는 목록을 광고할 수 있고, SMTP 안에 하나의 영구 비밀번호 방식을 박아 넣지 않아도 된다.

대체 가능성은 보안 기능이었다. SMTP 확장이 남아 있는 동안 메커니즘은 제한되거나 구식이 될 수 있다. SASL을 사용하는 모든 애플리케이션 프로토콜을 재설계하지 않고도 더 강한 메커니즘을 등록할 수 있다. 공통 계층은 선택지에 이름을 붙이고, 로컬 운영자는 무엇을 제공할지, 클라이언트는 무엇을 수용할지 결정하며, 양쪽 모두 낡은 구성의 결과를 감당한다.

레지스트리는 계정 데이터베이스를 운영하지 않는다. 릴레이 권한을 부여하거나, 자격 증명을 사서함에 매핑하거나, 메시지 뒤의 사람을 인증하지 않는다. 그 권한은 공통 어휘와 참조에서 끝난다. 실제 시스템이 최종 인가 결정을 보유한다.

유용한 로그인은 관문에서 멈춘 로그인이었다

SMTP AUTH는 구조적 빈틈을 메우는 데 기여했다. 메일 제출은 클라이언트의 현재 네트워크 주소를 그 신원으로 취급하지 않으면서 클라이언트를 인식하는 휴대 가능한 방법을 필요로 했다. SASL은 대체 가능한 인증 메커니즘과 자격 증명과 허용된 행동 사이의 구분을 제공했다. 제출 프로토콜은 그 관계를 공급자가 통제하는 경계에 배치했다. 메시지별 매개변수는 신뢰가 정당화할 때만 주장된 제출자를 보존하고, 그렇지 않을 때는 불확실성을 보존했다.

이 설계가 작동하는 이유는 성공적인 로그인이 서명보다 작게 남기 때문이다. 릴레이 접근을 열고, 정책 집합을 선택하고, 감사 가능한 홉 증거를 만들 수는 있다. 그러나 모든 발신자 필드, 인간의 의도, 본문의 바이트, 이후의 릴레이를 인증할 수는 없다. 자격 증명은 메시지에 서명하지 않았다. 한 서버가 그 메시지를 받아들일지 결정하기에 충분한 것만을 증명했다.

출처