요약

  • RFC 821의 선택적TURN명령은 기존 SMTP 채널에서 클라이언트와 서버의 역할을 뒤바꿔, 간헐적으로 연결되는 호스트가 대기 중인 메일을 수거하는 데 도움을 주었지만, 주장된 호스트 이름이 그 메일의 목적지를 통제할 수 있게 했습니다.
  • RFC 1985의ETRN은 요청을 더 작게 만들었습니다. 호출자는 서버에 특정 큐 처리를 시작하도록 요청할 수 있었고, 서버는 로컬 권한을 유지한 채 별도의 발신 연결을 열고 배달 여부를 알기 전에 응답했습니다.

가장 값싼 연결은 두 번 일해야 했다

SMTP는 영구적인 인바운드 경로를 가정할 수 없던 시기에 설계되었습니다. 작은 사이트는 서비스 제공업체에 전화 접속해 발신 메일을 보내고, 사이트가 오프라인인 동안 쌓인 메일을 제공업체가 돌려주기를 바랄 수 있었습니다. 제공업체의 일반적인 재시도 타이머를 기다리는 것은 사이트에 연결할 수 있는 드문 시간을 낭비했습니다.

RFC 821은 경제적인 해답을 제시했습니다. 호출자가 발신자-SMTP 역할을 하고 제공업체가 수신자-SMTP 역할을 한 뒤, 호출자는TURN을 발행할 수 있었습니다. 제공업체가250으로 응답하면 두 프로그램은 같은 전송 채널에서 역할을 바꿨습니다. 호출자는 수신자가 되어 새 서비스 준비 인사말을 보내고, 제공업체가 자신의 큐를 배달하기를 기다렸습니다. 제공업체는502로 거부할 수 있었고, 이 명령은 선택 사항이었습니다.

이 메커니즘은 부족한 링크를 재사용했습니다. 또한 그 링크가 얻은 것보다 더 많은 신뢰를 재사용했습니다.

HELO에서 말한 이름은 보관 증명이 아니었다

서버는 새 수신자가 어떤 대기 메일을 받아야 하는지 결정해야 했습니다. 그러나 초기 SMTP는 피어가 제공한 호스트 이름을 인증하지 않았습니다. 악의적인 호출자는 다른 사이트의 이름을 제시하고TURN을 요청해, 서버가 그 사이트의 대기 메일을 열린 채널로 보내도록 유도할 수 있었습니다.

이는 단지 헤더에 위조된 한 줄을 넣는 문제가 아니었습니다. 저장된 메시지 전체의 보관 권한을 바꿀 수 있었습니다. RFC 1985는 나중에 이 결함을 큰 보안 허점이라고 불렀고, 많은 SMTP 및 ESMTP 구현이 주장된 원격 이름에 대한 검사를 규정하지 않은 사양 때문에TURN을 피했다고 관찰했습니다.

문제는 전환의 크기였습니다. 인증되지 않은 하나의 주장이 하나의250결정으로 호출자의 역할, 서버의 역할, 기존 연결의 방향, 대기 메일의 목적지를 바꿨습니다.

ETRN은 받지 않고 작업을 요청했다

RFC 1985는 운영상의 필요를 유지하면서 허용 범위를 좁혔습니다. 이 확장을 지원하는 서버는EHLO뒤에ETRN을 광고합니다. 클라이언트는 노드 이름을 제공하고 서버에 해당 큐 처리를 시작하도록 요청합니다. 세션이 수립된 뒤에는 요청할 수 있지만,MAIL FROM과DATA완료 사이의 메일 트랜잭션 안에서는 할 수 없습니다.

서버는 요청된 범위를 검사하고 로컬 관리 결정을 내립니다. 수락하면 재시도 큐를 시작하고 다른 SMTP 연결을 사용해 지정된 원격 사이트로 보냅니다. 원래 호출자는 계속 호출자로 남습니다. 제어 채널에서 수신자가 되지 않으며, 이름을 알고 있다는 이유만으로 저장된 봉투가 그에게 넘겨지지도 않습니다.

별도 연결이 마법 같은 인증은 아닙니다. 그것은 새로운 증거 경계입니다. DNS, 경로 선택, 수신 SMTP 트랜잭션이 서버가 어디에 연결할 수 있는지, 각 메시지가 수락되는지를 결정합니다. 이런 검사는 완벽하지 않지만, 트리거 연결의 단순한 주장과는 독립적입니다.

성공한 트리거는 영수증이 아니었다

큐 작업은 정해지지 않은 시간이 걸릴 수 있습니다. RFC 1985는 주어진 기간 안에 새 연결이 발생해야 한다는 요구를 두지 않습니다. 따라서 명령은 큐가 비워질 때까지 제어 세션을 열어 두지 않고 신속히 반환됩니다.

일반적인250응답은 요청이 만족스러웠고 큐 처리가 시작되었음을 뜻합니다. 메시지가 대기 중이었는지, 발신 연결이 성공했는지, 수신자가 메시지를 수락했는지를 증명하지는 않습니다. 선택적251,252,253응답은 점진적으로 더 많은 큐 정보를 드러낼 수 있지만, 이는 큐를 보관한 서버의 보고일 뿐 종단 간 배달 증거는 아닙니다.

이 분리는 운영상 중요합니다. ETRN250을 “메일 배달됨”으로 기록하는 모니터링 시스템은 이 확장이 보존한 불확실성 자체를 파괴합니다. 트리거 수락, 연결 시도, 메시지 전송, 최종 배달은 서로 다른 기록에 속합니다.

큐 이름은 로컬 권한 아래에 머물렀다

가장 단순한 ETRN 매개변수는 정규화된 노드 이름입니다. RFC 1985는 또한@domain을 정의해 지정된 도메인과 하위 도메인의 큐를 활성화하고,#name으로 UUCP 큐 같은 로컬 정의 큐를 선택할 수 있게 했습니다.

이런 편의는 범위를 확장합니다.@com같은 부주의한 접미사는 막대한 작업을 풀어 혼잡을 만들 수 있습니다. 로컬#이름에는 전역 사전이 없고, 프로토콜은 모든 큐를 열거하는 방법을 제공하지 않습니다. 서버는 자체 저장 모델에 맞는 호출자와 범위 조합을 승인해야 합니다.

따라서 구문은 요청을 조정하지만 큐를 국가화하지 않습니다. IANA는ETRN을 등록할 수 있지만, 어느 고객이 어느 작업량을 깨울 수 있는지는 결정할 수 없습니다.

폐지는 축소된 신뢰 예산을 기록했다

RFC 2821은TURN을 폐기했고, RFC 5321은 그 판결을 유지했습니다. SMTP 시스템은 서버가 역할 전환을 요청하는 클라이언트를 강력히 인증할 수 없는 한 이를 사용하지 않아야 합니다. 암호화만으로는 그 자격을 확립할 수 없습니다. 관련 질문은 인증된 주체가 특정 대기 메일을 받을 자격이 있는지입니다.

RFC 5321은 더 작은 최적화도 설명했습니다. 호스트에서 메일이 도착하면 서버는 그 접촉을 같은 호스트에 대기 중인 메일을 재시도하라는 힌트로 취급할 수 있습니다. 명시적인 “지금 큐를 보내라” 명령이 항상 필요한 것은 아닙니다. 이 힌트는 큐에 대한 원격 소유권이 되지 않고 로컬 스케줄링에 영향을 줄 수 있습니다.

현재 IANA 레지스트리는 두 역사적 이름을 모두 보존하면서TURN과ETRN을 메시지 제출 서비스에 부적합하다고 표시합니다. 포트 587에서 메일을 제출하는 사용자는 그로 인해 SMTP 배달 큐를 활성화할 자격을 얻는 것이 아닙니다.

인터넷 메일은 간헐적 호스트를 포기하지 않았습니다. 다만 그 편의가 하나의 과대한 역할 이전에 의존하지 않게 되었습니다. 호출자는 작업을 트리거할 수 있었습니다. 큐 보유자는 승인하고 스케줄링할 수 있었습니다. 별도의 SMTP 경로가 배달을 시험할 수 있었습니다. 그 어떤 사실도 다른 사실을 사칭할 필요가 없었습니다.

출처