요약

  • 초기 SMTP에서251은 폐기된 수신자를 수락하면서 전달 책임을 수신 서버가 지도록 했고,551은 그 수신자를 거부하면서 발신자가 시도할 수 있는 대체 경로를 돌려주었습니다.
  • 이후 표준들은 대체 경로를 공개하지 않고도 같은 운영 선택을 하도록 허용했습니다. 수락하는 서버는250으로, 거부하는 서버는550으로 응답할 수 있습니다.
  • 수정된 경로는 개인 신원의 증명도 전 세계적 이름 변경도 아니었습니다. 자동적인 미래 재라우팅에는 신뢰할 수 있는 서버 근거와 저장된 주소 데이터의 소유자가 내리는 별도의 결정이 필요했습니다.

같은 주소를 알고 있던 두 가지 응답

이동한 메일박스를 향한RCPT TO명령 하나를 생각해 봅시다. 서버 A는 대체 주소를 알고251을 돌려줍니다. 서버 B도 같은 대체 주소를 알지만551을 돌려줍니다. 대시보드가 둘 다 “사용자가 이동했다”고 표시한다면, SMTP가 가장 중요하게 여긴 사실이 지워집니다.

251의2는 수신자 단계가 성공했음을 말합니다. 서버 A는 현재 트랜잭션에서 구 주소를 수락했고, 메시지를 다음 지점까지 전달할 책임을 떠안았습니다.551의5는 수신자 단계가 영구적으로 실패했음을 말합니다. 서버 B는 책임을 받아들이지 않았으며, 다음 시도를 구성할지 실패를 보고할지는 발신 측이 결정해야 합니다.

각 코드 뒤에 출력되는 경로는 동일할 수 있습니다. 책임은 그렇지 않습니다.

원래 프로토콜은 이 분기점을 명시적으로 만들었다

RFC 821은 1982년 두 응답을 모두 도입했습니다. 그 전달 섹션은 제공된 forward-path가 잘못되었지만 수신 SMTP가 올바른 목적지를 알고 있는 경우를 다루었습니다. 호스트, 사용자 이름, 또는 둘 모두가 다를 수 있었습니다.

251 User not local; will forward의 경우 수신자는 향후 사용을 위한 수정된 경로를 제공하고 현재 메시지의 전달을 명시적으로 책임졌습니다.551 User not local; please try의 경우 그 수신자를 위한 메일을 거부했습니다. 발신자에게는 두 가지 선택이 있었습니다. 정보에 따라 경로를 바꾸거나, 원 발신 사용자에게 오류를 돌려보내는 것입니다.

이는 단지 편리한 메시지 한 쌍 이상이었습니다. 저장-전달 네트워크에서 보관(custody)이 바뀌는 지점에 대해 정직하게 유지해 준 것입니다. 수락에 붙은 힌트를 거부에 붙은 힌트처럼 처리할 수는 없었습니다. 첫 번째의 현재 트랜잭션은 계속되었고, 두 번째는 그렇지 않았습니다.

현재 트랜잭션은 주소록 편집이 아니었다

클라이언트가 대체 주소를 저장하지 않더라도 이 구분은 유지됩니다.251이후에는 구 수신자를 수락된 것으로 취급해야 합니다. 같은 메시지를 제안된 주소로도 즉시 보내면 중복이 생길 수 있습니다.551이후 구 수신자를 수락된 것으로 취급하면 메시지가 조용히 사라질 수 있습니다.

미래 행동은 별개의 영역입니다. 클라이언트는 새 경로를 사람에게 보여줄 수도, 한 번의 재시도만을 위해 기억할 수도, 별칭을 추가할 수도, 연락처를 갱신할 수도, 무시할 수도 있습니다.RFC 5321은 어느 코드를 쓰든 서버가 클라이언트가 주소 정보를 갱신하거나 사용자에게 돌려주리라 가정해서는 안 된다고 말합니다.

이러한 가정 거부는 내구성 있는 설계 선택입니다. SMTP는 지금 자신이 소유한 결과를 말할 수 있습니다. 모든 원격 연락처 데이터베이스가 새로운 신원 문자열로 수렴하도록 만들 수는 없습니다.

프라이버시가 침묵을 유효한 전달 정책으로 만들었다

RFC 2821이 2001년 SMTP를 재정립할 무렵에는 침묵 속 전달이 흔했습니다. 기업 별칭은 주소를 단순화했고, 개인 전달은 낡은 메일박스를 새 메일박스에 연결했습니다. 그러나 최종 목적지를 노출하면 내부 호스트, 개인 계정, 또는 발신자가 직접 닿을 수 없는 주소가 드러날 수 있었습니다.

프로토콜은 그래서 책임과 공개를 분리했습니다. 수락하는 서버는 전달하면서 수정된 주소를 드러내지 않고 평범한250을 돌려줄 수 있습니다. 거부하는 서버는 대체 정보 없이550을 돌려줄 수 있습니다.RFC 5321은 두 선택을 모두 유지하며,251이나551을 제한해야 하는 사이트를 위한 설정 제어를 권고합니다.

네 가지 결과가 가능해집니다. 수락하고 공개, 수락하고 숨김, 거부하고 공개, 거부하고 숨김. 프라이버시 정책은 발신자에게 공개되는 증거를 바꿀 뿐, 전달의 소유자가 누구인지를 거짓으로 만들 필요는 없습니다.

일부 이동한 메일박스에는 공개 경로가 없다

확장 상태 코드 어휘는 이 경계를 더 명확히 만듭니다.RFC 3463은 전달 주소 없이 이동한 목적지 메일박스를 위한X.1.6을 정의했습니다. 현재의IANA SMTP Enhanced Status Codes Registry는 그 설명을 영구 실패 상태로 보존하고 있습니다.

“전달 주소 없음”은 존재하지 않음, 이 서버가 사용할 수 없음, 이 영역에서 공개되지 않음을 모두 의미할 수 있습니다. 이는 클라이언트가 헤더, 오래된 전달 흔적 또는 서드파티 디렉터리에서 목적지를 추론하도록 허락하지 않습니다. 참조의 부재는 추측으로 메워야 할 빈틈이 아니라 완전한 프로토콜 상태입니다.

RFC 3464는 배달 보고서 쪽에서 같은 경계에 닿습니다. DSN은 위조될 수 있다고 경고하고, 목적지를 드러내지 않기를 원하는 채 자동 전달하는 사용자를 인정합니다. 구현은 그 주소를 기밀로 유지할 방법을 제공해야 합니다. 메시지는 더 멀리 여행하면서 원 발신자는 더 적게 알게 될 수 있습니다.

기계가 읽는 경로가 재라우팅 공격을 만들었다

SMTP 응답 텍스트 대부분은 사람을 위한 것이며 달라질 수 있습니다.251과551의 수정된 경로는 예외입니다. 클라이언트가 이를 바탕으로 행동하려면 구문 분석이 필요합니다. 이는 응답을 운영상 유용하게 만드는 동시에 보안에 민감하게 만듭니다.

RFC 5321은 클라이언트가 주소록 갱신처럼 미래 행동을 자동으로 바꾸기 전에 서버의 진위성을 확실히 해야 한다고 경고합니다. 끼어든 공격자가 메일박스를 바꿔치기하면 이 메시지뿐 아니라 위조된 “수정”이 저장된 이후의 모든 메시지가 방향을 바꿀 수 있습니다.

인증은 여전히 많은 인터페이스가 암시하는 것보다 적은 것을 증명합니다. 어느 서버가 응답을 제공했는지는 확립할 수 있습니다. 새 메일박스가 같은 사람에게 속한다는 것, 변경이 영구적이라는 것, 또는 한 관리자가 다른 사람의 정식 연락처 기록을 덮어쓸 수 있다는 것은 증명하지 않습니다. 전송 진위성은 자동화에 필요한 증거이지 보편적인 명명 권한이 아닙니다.

전달은 수신자를 바꿨지 작성된 메시지가 아니었다

RFC 5598은 이후 인터넷 메일을 역할들의 집합으로 기술했습니다. 일반 릴레이는 봉투 주소를 바꾸지 않고 메시지를 옮깁니다. 별칭은 다릅니다. 원래 메시지와 보통 원래 회신 주소를 유지하면서 하나 이상의 대체 수신자를 향해 다시 제출합니다.

이 작은 봉투 변경은 큰 의미적 결정을 실어 나릅니다. 지정된 수신자가 다른 수신자를 선택한 것입니다. 나중에 전달이 실패하면 보고서가 원 저자에게 돌아갈 수 있으며, 저자는 숨겨진 별칭이 존재했음을 모릅니다. 따라서 전달은 보이는To필드나 저자가 의도한 메시지 신원을 다시 쓰지 않으면서 운영 책임을 재분배합니다.

이것이 수정된 SMTP 경로를 인터넷 전체의 이름 변경으로 묘사해서는 안 되는 이유입니다. 그것은 한 사이트가 하나의 봉투 수신자를 어떻게 처리하거나 거부할지에 관한 그 사이트 자체의 진술입니다. 메시지 헤더, 주소록, 개인 신원, 미래 라우팅은 독립적으로 관리되는 기록으로 남습니다.

이 역사는 경계가 있는 수정에 대한 교훈이다

251과551의 우아한 부분은 새 주소를 드러냈다는 점이 아닙니다. 세 가지 질문을 분리해 둔 점입니다. 이 수신자가 수락되었는가? 다음으로 누가 행동해야 하는가? 대체 주소를 공개해도 되는가?

이후 보안 실무는 네 번째를 더했습니다. 누가 이 변경을 영구적으로 만들 수 있는가? 가장 안전한 클라이언트는 현재의 숫자 결과를 먼저 반영하고, 경로를 보호된 증거로 취급하며, 미래 서신을 바꾸기 전에 더 강한 권한 부여를 요구합니다.

SMTP는 그 사람의 이름을 바꾼다고 주장하지 않으면서 메시지가 사람을 따라가도록 도울 수 있었습니다. 이 절제 덕분에 최종 주소가 응답에서 사라져야 하는 경우에도 전달은 여전히 유용했습니다.