요약

  • RFC 3974는 IPv4 전용 보조 MX가 IPv6 전용 주 MX로 릴레이할 수 없는 메일을 수락할 수 있음을 보였다. 우선순위 번호는 후보의 순서를 정할 뿐 후보 사이에 경로를 만들지 않았다.
  • DNS 응답, TCP 접속, SMTP 수락, 큐 상태, 이후 릴레이, 최종 메일 드롭 도착은 각각 별개의 접수 증명이었다. 한 계층에서의 성공이 다음 계층에서 메시지를 발이 되게 남겨둘 수 있었다.

이중화된 메일 설계에서 가장 위험한 격차는 이중화가 이미 작동한 뒤에 나타날 수 있다. 발신자가 주 서버에 닿지 못해 MX 목록을 따라가 보조 서버에 도달하고 SMTP 인계를 완료한다. 외부에서 보면 폴백은 성공적으로 보인다. 그러나 수신자 네트워크 안에서 그 보조 서버는 모든 메일이 수렴하도록 설계된 시스템으로 가는 전송 경로가 없을 수 있다.

2005년 1월에 발표된RFC 3974는 바로 이 혼합 IPv4/IPv6 실패를 기술했다. 그 예시는 주 MX를 IPv6 전용으로, 낮은 우선순위의 익스체인저들을 IPv4 전용으로 만들었다. IPv4 발신자는 백업에 도달할 수 있었다. 백업은 IPv4로도 IPv6로도 주 서버에 닿을 수 없었다. MX 우선순위는 주소 패밀리를 잇지 못했다.

우선순위는 시도의 순서를 정했을 뿐, 메시지를 전달하지 않았다

MX 레코드는 우선순위 값과 호스트 이름을 제공한다. 발신자는 후보 호스트를 우선순위로 정렬하고 주소를 확인하며 전송을 시도한다.RFC 2821은 RFC 3974 기준으로 권위 있는 SMTP 알고리즘이었으며, 이는 특이하게도 명시적인 IESG 노트가 강조한 바 있다. RFC 3974는 Informational 문서로, 새 프로토콜을 정의하지 않았고 전체 SMTP 규칙을 대체하지도 않았다.RFC 5321은 이후 RFC 2821을 대체했다.

그 후보 정렬은 전달 토폴로지가 아니다. 보조 MX는 두 이름이 하나의 DNS 응답에 함께 등장한다고 해서 모든 더 나은 우선순위 호스트로의 터널을 얻지 않는다. 첫 번째 경로는 발신자에서 선택된 MX로 간다. 별도의 경로는 메일을 수락한 MX에서 수신자의 최종 저장소 또는 처리 시스템으로 가야 한다.

RFC 3974는 이 두 번째 책임을 수신 사이트에 배정했다. 가장 쉬운 예시적 수리는 주 서버를 듀얼 스택으로 만드는 것이었다. 그러나 문서는 하나의 수리를 요구사항과 혼동하지 않도록 주의했다. UUCP, IPv4/IPv6 변환기 또는 공유 저장소도 수락된 메시지를 옮길 수 있었다. 불변 조건은 MX가 수락한 모든 메시지가 수신자의 메일 드롭에 도달해야 한다는 것이었다.

알고리즘 뒤의 역사는RFC 974와RFC 1123을 거슬러 올라간다. DNS 자체는RFC 1035가 대표하는 프레임워크에서 왔고,RFC 3596은 IPv6 주소를 위한 AAAA 레코드를 공급했다. 동일한 IN 클래스 MX 레코드가 두 프로토콜 패밀리를 모두 담당했다. 운영자는 호스트를 나열하는 것이 수락 이후에 필요한 주소 패밀리 경로를 전달한다고 가정할 수 없었다.

“레코드 없음”은 하나의 상태가 아니었다

RFC 3974는 모니터링 시스템이 종종 단일화하는 DNS 결과들도 구분했다. NODATA는 이름은 존재하나 MX 응답이 없음을 뜻하며, SMTP를 암묵적 MX 규칙으로 이끌었다. NXDOMAIN은 대상 도메인이 존재하지 않음을 뜻하며 영구 실패를 낳았다. SERVFAIL은 임시 확인 실패로 재시도가 필요했다.

이것은 초기 AAAA 배포 기간에 중요했다. 문서는 AAAA 질의에 SERVFAIL을 반환하는 고장 난 DNS 서버를 보고했다. 그러면 IPv6 준비된 MTA는 나중 시도를 위해 메일을 큐에 넣었다.RFC 4074는 이후 IPv6 주소 질의에 대한 일반적인 오동작을 문서화했다. SERVFAIL 관측은 그 도메인에 AAAA 데이터가 없다는 것, A 조회가 성공했다는 것, 또는 IPv4 폴백이 시도되었다는 것을 증명하지 않았다.

주소가 존재한 이후에도 상태 기계는 계층화되어 있었다. 발신자는 동일한 우선순위의 MX 레코드 내에서만 A와 AAAA 주소를 재정렬할 수 있었다. 그다음 TCP 25번 포트를 시도했다. 접속 실패는 다른 주소나 다른 MX로 이동시킬 수 있었다. 접속 성공은 SMTP 트랜잭션을 열었을 뿐이다. 임시 SMTP 응답은 다른 후보나 재시도로 이어졌고, 영구 오류는 더 이상의 MX 시도를 멈췄으며, 성공한 트랜잭션은 그 MTA로의 SMTP 전송을 확립했다.

그 마지막 성공조차 RFC 3974의 수신자 측 이야기의 끝이 아니었다. 그것은 수락하는 릴레이가 책임을 가져갔음을 증명할 뿐이다. 사이트가 모든 메시지가 다른 호스트에 수렴하도록 설계했다면 내부 릴레이는 여전히 필요했다. 그 호스트로의 경로와 메일 드롭 도착은 자체적인 증거를 필요로 했다.

이후 문서들은 인접한 경계를 더 정교하게 다듬었다.RFC 7505는 메일을 받지 않는 도메인을 위한 명시적 Null MX를 만들어 서비스 부재로부터의 모호한 추론을 피했다.RFC 3463과IANA 확장 상태 코드 레지스트리는 전송 상태를 분류한다.RFC 6724와RFC 8305는 이후 더 넓은 IPv6 실무에서 주소 선택과 접속 레이싱을 다루었다. 이들은 소급적으로 RFC 3974가 관측한 시스템을 측정하지 않는다.

RFC Editor 기록,정오표 검색과IETF Datatracker는 문서적 지위와 역사를 확립하며, 배포 보급률이나 손실률을 확립하지 않는다. RFC 3974는 많은 IPv6 준비 MTA가 기술된 알고리즘을 따르는 것으로 보였다고 말했지만 인구조사를 제공하지 않았다.

따라서 운영상의 독해는 경로 지향적이다. 공표된 각 MX가 그것이 담당하도록 되어 있는 발신자 모집단에서 도달 가능한지 검증하라. 그다음 메일을 수락하는 각 MX가 DNS에서의 순위와 무관하게 최종 저장소로 가는 경로를 갖는지 검증하라. DNS 응답, 선택된 주소, TCP 결과, SMTP 응답, 큐 전환, 이후 릴레이, 최종 적하를 별개의 접수 증명으로 보존하라.

백업은 메시지를 수락한 것으로 실패하지 않았다. 수신자의 설계가 수락된 책임을 갈 곳 없이 남겨둘 때에만 실패했다. RFC 3974는 그 보이지 않는 인계를 보이게 만들었다.

출처