요약

  • RFC 821은 발신자가 수신 우편함 앞에 명시적 릴레이 순서를 넣도록 허용했습니다. 각 릴레이는 자신의 이름을 소비하고 그 이름을 반환 경로로 옮겼습니다.
  • RFC 1123은 일반 인터넷 메일을 보편적인 도메인 이름과 DNS MX 라우팅으로 전환했습니다. 수신자는 여전히 이전 문법을 받아야 했지만, 요청된 릴레이를 버리고 최종 우편함 도메인을 사용할 수 있었습니다.
  • 현재 SMTP도 이 구분을 유지합니다. 서버는 출발지 경로를 무시하거나, 거부하거나, 의도적으로 실행할 수 있습니다. 레거시 형식을 구문 분석하는 것은 릴레이 권한 부여도 아니고 그 경로를 따를 약속도 아닙니다.

하나의 경로, 세 가지 모두 적합한 결과

클라이언트가 다음을 보낸다고 가정해 봅시다.

RCPT TO:<[relay alpha, relay beta]:[mailbox user in domain gamma]>

이 표기법에는 서로 다른 두 객체가 담겨 있습니다. 도메인 gamma의 사용자 우편함이 목적지입니다. 콜론 앞의 이름들은 제안된 릴레이 순서입니다. 서버는 이 둘을 인식하면서도 동일한 권한을 부여하지 않을 수 있습니다.

어떤 현재 서버는 alpha와 beta 릴레이 접두어를 떼어내고gamma.example쪽으로 라우팅할 수 있습니다. 다른 서버는 릴레이를 요구하는 주소를 거부할 수 있습니다. 세 번째 서버는 예외 정책에 따라 출발지 경로를 사용해 먼저alpha.example에 접촉할 수 있습니다. 세 트랜잭션에서 문법은 변하지 않았습니다. 변한 것은 다음 홉을 선택할 자격이 누구에게 있는가입니다.

이것이 낡아 보이는 주소에 숨어 있는 역사적 교훈입니다. 인터넷 프로토콜은 때로 새 시스템이 오래된 입력을 안전하게 만나도록 이전 언어를 유지합니다. 그러나 그 언어가 과거에 행사하던 모든 권력을 보존해야 하는 것은 아닙니다.

발신자가 경로표를 제공하던 시절

RFC 822는 이 구조를route-addr라고 불렀습니다. 경로 부분은 발신자가 메시지가 통과하기를 원한 호스트나 전송 서비스를 나열했고, 콜론 뒤의 주소는 전역 우편함으로 남았습니다.

RFC 821은 그 경로를 SMTP 봉투에서 작동 가능하게 만들었습니다. 이 표준의 예시는 도메인 THREE에 있는 JOE의 우편함 앞에 릴레이 ONE과 TWO를 나열하며, 우편함과 도달 지침을 의도적으로 분리했습니다. 메시지가 지정된 릴레이에 도착하면 그 릴레이는 forward-path에서 자신의 식별자를 제거하고, 그 식별자를 reverse-path 맨 앞에 넣고, 발신자가 되어 목록의 다음 SMTP에 접촉했습니다.

두 경로는 움직이는 장부였습니다. 순방향은 아직 요청된 작업을 기록했고, 역방향은 이후 실패에 대비해 발신자로 돌아가는 경로를 축적했습니다. 작업을 수락한 릴레이는 다음 전송에 대한 책임도 수락했습니다. 로컬 수신자를 거부할 수 있었던 것처럼, 릴레이는 여전히 그 작업을 거부할 수 있었습니다. 경로는 트랜잭션 안의 지침이었지, 어떤 호스트든 사용할 수 있는 보편적 권리가 아니었습니다.

RFC 821은 또한 봉투를 작성된 메시지와 구분했습니다. 이 경로들은MAIL FROM과RCPT TO에 나타났으며,To,From,CC에 나타날 필요는 없었습니다. 따라서 독자에게 보이는 주소와 전송 경로표는 서로가 서로가 되지 않은 채 갈라질 수 있었습니다.

보편적 이름이 직렬 지시를 대체하다

1989년경에는 아키텍처가 바뀌었습니다.RFC 1123은 발신 SMTP에 명시적 출발지 경로를 생성하지 말라고 했습니다. 그 설명은 이례적으로 직접적이었습니다. 인터넷 메일은 출발지 라우팅 대신 보편적 명명을 선택했다는 것입니다. SMTP는 연결성을 제공하고, DNS는 전역적으로 고유하고 위치 독립적인 이름을 공급했으며, MX 레코드가 발신자가 릴레이 순서를 직접 써야 할 것처럼 보였던 주된 경우를 처리했습니다.

그 결과가 릴레이 금지는 아니었습니다. 도메인은 여전히 메일 익스체인저를 지정할 수 있고, 하나의 메시지가 배달 전에 여러 서버를 거칠 수 있습니다. 달라진 것은 권한입니다. 발신자는 목적지 도메인을 지명하고, DNS와 참여 서버들이 현재 정책에 따라 사용 가능한 다음 홉을 결정합니다. 주소가 더 이상 발신자가 부과하는 사적인 라우팅 테이블을 겸하지 않습니다.

이 전환은 경로 복구도 지역화했습니다. 익스체인저가 바뀌면 목적지 도메인은 DNS만 갱신하면 되고, 모든 통신 상대가 새 목록을 배울 필요는 없습니다. 발신자의 영속적 기록은 어제의 토폴로지가 아니라 우편함 도메인입니다.

복종 없는 호환성

RFC 1123은 이전 형식을 단순히 문법 오류로 만들지 않았습니다. 수신 SMTP는 명시적 경로 문법을 받아들여야 했지만, 릴레이 기능을 구현하지 않은 서버는 최종 우편함 도메인을 시도해야 했습니다. 이 표준의 예시는 경로에서 릴레이 ALPHA와 BETA를 제거하고 JOE의 우편함을 도메인 GAMMA로 직접 라우팅합니다.

RFC 2821은 규칙을 더 선명하게 만들었습니다. 발신자는 출발지 경로를 만들지 않아야 합니다. 수신자는 이를 인식해야 하지만 경로를 떼어내고, 마치 경로가 제공되지 않은 것처럼 우편함에 연관된 도메인을 사용해야 합니다. 릴레이 이름은 reverse-path에 복사되어서는 안 됩니다. 호환성 파서가 익숙한 구두점을 봤다고 해서 RFC 821의 움직이는 반환 경로를 다시 재구축할 수는 없게 된 것입니다.

이 구분은 정반대의 두 실패를 막습니다. 이전 문법을 구문 분석하지 못하는 수신자는 구분자를 우편함 데이터로 착각하거나 안전하게 라우팅할 수 있었던 메일을 거부할 수 있습니다. 구문 분석된 모든 홉을 자동으로 따르는 수신자는 레거시 토큰이 현재 릴레이 정책 밖의 중간 서버를 선택하도록 놔둘 수 있습니다. 인식은 상호운용성을 보호하고, 복종하지 않음은 현대의 신뢰 경계를 보호합니다.

낡은 문법은 여전히 한정된 의미를 갖는다

RFC 5321은 규범적 경로 문법에A-d-l— 쉼표로 구분된 도메인 목록 — 을 그대로 두고 있습니다. 이 짧은 지침은 전체 타협을 담고 있습니다. 형식은 받아들여야 하고, 생성해서는 안 되며, 무시해야 합니다.

주변 규칙도 중요합니다. 서버는 릴레이 서비스를 거절하거나 경로를 포함한 주소를 거부할 수 있습니다. 경로를 무시하고 마지막 목적지를 사용할 수 있습니다. 그러나 경로를 의도적으로 사용한다면 첫 번째로 표시된 도메인으로 보내야 하고 지름길을 만들어서는 안 됩니다. 호환성이 모든 해석이 서로 바꿔 쓸 수 있다는 뜻은 아닙니다.

표준은 마이그레이션 함정도 짚습니다. 일부 발신자는 잘못된 최종 목적지 이름을 사용하고 중간 릴레이가 이를 해석해 주기를 기대했습니다. 적합한 서버가 경로를 떼어내면 그 숨겨진 의존성은 깨집니다. 문자열은 문법적으로 유효한 채 남을 수 있지만, 이전 실행 모델에 박혀 있던 가정은 무효가 됩니다.

출발지 경로는 비정상적인 디버깅이나 심각한 임시 구성 문제에 여전히 사용할 수 있습니다. 그러나 그 예외들은 출발지 경로를 다시 일상적인 발신자 권한으로 복원하지 않습니다. 경로 실행을, 그 증거와 위험이 이를 선택하는 서버에 귀속되는 명시적 운영 판단으로 만들 뿐입니다.

헤더의 역사도 같은 경계를 따랐다

RFC 5322는 폐기된 message-address 문법에 경로 형식을 유지하면서, 주소를 해석할 때 경로 부분은 무시해야 한다고 말합니다. 이 규칙은 SMTP에 인접하지만 동일하지는 않습니다. 오래된route-addr를 받아들이는 헤더 파서가 SMTP 봉투 지침을 만드는 것은 아니며,To필드가 SMTP 트랜잭션이 실제로 어떤 수신자를 담았는지 증명하지 않는 것과 마찬가지입니다.

이 분리는 아카이브에서 유용합니다. 오래된 메일은 역사적 구두점을 살아있는 전달 명령으로 취급하지 않으면서도 읽을 수 있습니다. 의미를 보존하려면 어느 계층이 그 필드를 소유했고, 그 과거 동작 중 어느 부분이 살아남았는지 알아야 합니다.

출처와 한계

이 전환은 RFC 821, RFC 822, RFC 1123, RFC 2821, RFC 5321, RFC 5322로 문서화되어 있습니다. 이 문서들은 문법과 표준상 의무를 확립할 뿐, 현대 제품이 출발지 경로를 얼마나 자주 만나거나 실행하는지는 보여주지 않습니다. 현재 공급업체 기본값, 필터링 비율, 배달 성공률은 담고 있지 않습니다.

영속적인 결과는 더 좁고 더 중요합니다. SMTP는 "당신이 쓴 경로를 이해합니다"라고 말하면서 "당신이 내 경로를 통제합니다"라고 말하지 않는 법을 배운 것입니다.