요약

  • 메시지 본문 뒤의 SMTP 단일 긍정 응답은 트랜잭션 전체를 수락하며, 수락된 한 수신자의 로컬 전송 성공과 다른 수신자의 일시적 실패를 즉시 보고할 수 없습니다.
  • RFC 2033의 LMTP는 성공한RCPT마다 하나의 순서화된 최종 응답을 반환하여, 상위 큐 관리자가 미해결 수신자를 보존하면서 전송이 완료되었는데 응답이 유실되는 경우 잔존하는 중복 위험을 노출시켰습니다.

하나의 본문이 두 개의 다른 진실을 만들었다

큐 관리자가 한 메시지를 로컬 사서함 서비스에 넘겨준다고 상상해 보십시오. 두 개의RCPT명령을 내리면 둘 다 중간 응답250을 받습니다. 중요한 작업은 전체 본문이 도착한 뒤에야 수행됩니다. 첫 번째 사서함은 메시지를 받아들입니다. 두 번째는 일시적으로 할당량을 초과했습니다.

일반 SMTP는 그 DATA 교환을250과452로 동시에 끝낼 수 없습니다. 최종 응답은 트랜잭션 전체에 적용됩니다.RFC 5321의 현재 모델에서는 데이터 종료 시점의 결정에 부분 실패 문법이 없습니다. 서버는 메시지를 전송을 위해 수락하거나 그렇지 않거나 둘 중 하나입니다. 긍정적으로 답하면 전체 책임을 지게 됩니다. 이후에 한 수신자에 대해 발견된 실패는 재시도나 별도의 통지로 처리해야 하며, 하나의 최종 상태가 두 가지 의미를 가졌던 것처럼 꾸밀 수 없습니다.

이 규칙은 네트워크로 연결된 호스트 간의 저장 후 전달 메일에는 잘 맞습니다. 수신 SMTP 서버가 큐를 소유하는 이유는 바로 지금 받아들이고 나중에 끝마칠 수 있기 때문입니다. 문제는 다른 접합부에서 생깁니다. 기존 큐 관리자에서 로컬 전송 에이전트로의 인계입니다. 그 에이전트에게 또 하나의 영구 큐를 돌리도록 요구하면, 프로토콜의 최종 응답 수가 너무 적다는 이유만으로 책임과 저장소와 복구 로직을 중복시키게 됩니다.

로컬 메일 전송 프로토콜은 인터넷 메일을 다시 설계하는 대신 그 접합부를 바꾸었습니다.

응답의 개수가 큐 경계를 옮겼다

RFC 2033은 1996년 10월에 Informational로 발표되었으며, 클라이언트가 이미 큐를 관리하고 서버는 그렇게 하지 말아야 하는 제한된 상황을 위해 LMTP를 정의했습니다. 최종 DATA 점 이후 LMTP 서버는 이전에 성공한RCPT명령마다 하나의 응답을, 그 명령들이 내려진 순서대로 반환합니다.

이 작은 변화가 관할 대장을 바꿉니다. 수신자 A가 최종250을 받으면 전송 에이전트가 A에 대한 책임을 떠안은 것입니다. 수신자 B가452를 받으면 큐 관리자는 B를 다음 시도를 위해 보존합니다. 원본 메시지를 두 번째 범용 큐에 넘길 필요가 없고, 첫 번째 큐가 이미 긍정 결과를 확인한 수신자를 다시 시도할 필요도 없습니다.

이 매핑은 위치 기반입니다.RCPT단계에서 거부된 수신자는 최종 응답 시퀀스에 없습니다. 동일한 전달 경로를 가리키는 두 개의 성공한RCPT명령도 여전히 두 개의 응답을 요구합니다. 여러 줄로 이루어진 응답도 하나의 응답입니다. 따라서 클라이언트는 성공한 수신자의 정확한 순서 목록을 보존해야 하며, 이후 주소 텍스트로 맞추는 구현은 동등하지 않습니다.

LMTP는 잠정적인RCPT수락을 전송 약속으로 바꾸지 않았습니다. 결정적인 전송은 여전히 내용이 도착하고 대응하는 최종 응답이 긍정인 경우에만 일어납니다.

다른 인사말이 다른 문법을 지켰다

LMTP는 ESMTP와 충분히 닮아 있어서 무음 혼란은 위험합니다. SMTP 결과 하나를 기대하는 클라이언트는 LMTP의 첫 수신자 응답을 트랜잭션의 끝으로 읽고 이후 응답들을 잘못된 명령에 붙일 수 있습니다. 여러 결과를 기대하는 LMTP 클라이언트는 SMTP 서버의 단일 최종 응답 뒤에서 영원히 기다릴 수 있습니다.

그래서 RFC 2033은HELO와EHLO를LHLO로 대체했습니다. LMTP 서버는 SMTP 인사말을 긍정적으로 받아들여서는 안 되며, LMTP는 SMTP 서비스 포트 25를 사용해서는 안 됩니다. 이것들은 브랜딩 세부사항이 아닙니다. 메시지가 응답 계약에 들어가기 전에 그 계약을 눈에 보이게 만드는 것입니다.

이 규격은 또한 PIPELINING과 확장 상태 코드를 요구했습니다.RFC 2920은 명령들이 사이를 기다리지 않고 전송될 때 응답 순서를 보존하고,RFC 2034와RFC 3463은 더 구조화된 실패 의미를 제공합니다. 어느 것도 수신자 대장을 대체하지 않습니다. 정밀한4.2.2스타일 상태는 클라이언트가 그것이 어느 성공한RCPT위치에 속하는지 알고 나서야 유용합니다.

CHUNKING을 사용할 수 있을 때,BDAT LAST는 동일한 수신자별 처리를 받습니다. 이전 BDAT 청크들도 각각 하나의 응답을 받습니다. 특수한 개수 규칙은 메시지의 완료에 붙으며, 그 틀의 모든 조각에 붙지 않습니다.

오래된 중복 공백은 작아졌을 뿐 사라지지 않았다

LMTP의 정밀성은 사서함 기록과 네트워크 확인 사이에 원자적 커밋을 만들지 않습니다.RFC 1047은 이미 SMTP 동기화 공백을 기술했습니다. 수신자가 메시지를 수락하거나 전송한 뒤 송신자가 긍정 응답을 받기 전까지, 양쪽이 책임에 대해 그럴듯하지만 서로 충돌하는 견해를 가질 수 있습니다. 그 지점에서 연결이 끊어지면 재시도가 메시지를 중복시킬 수 있습니다.

LMTP에서는 이 공백이 미해결 수신자마다 따로 존재합니다. A의250이 큐 관리자에 도착하여 영구적으로 처리되었다고 합시다. A는 재시도 집합에서 제거될 수 있습니다. 이제 로컬 에이전트가 B에게 전송했는데 B의 긍정 응답이 도착하기 전에 연결이 끊겼다고 합시다. 클라이언트는 B가 수락되었다는 이전 가능한 증명을 갖지 못합니다. RFC 2033은 도착한 응답들을 처리하고 나머지를 일시적 실패로 다루도록 요구합니다. B를 재시도하면 두 번째 사본이 생길 수 있습니다.

이 규격은 노출을 없앤다고 주장하는 대신 노출을 다룹니다. 서버는 각 응답을 가능한 한 빨리 보내고 다음 수신자에 상당한 시간을 쓰기 전에 플러시해야 합니다. 클라이언트는 전체 배치를 기다리지 않고 응답이 도착하는 대로 처리해야 합니다. 이 규칙들은 연결이 끊어질 때 수신자 목록의 모호한 접미부를 줄입니다.

그러나 확인이 유실된 사서함 기록을 되돌릴 수는 없습니다. 정확히 한 번의 전송은 SMTP 응답 줄의 더 나은 배열이 아니라 여러 시스템에 걸친 영구 공유 트랜잭션을 필요로 합니다.

지역성은 안전 모델의 일부였다

RFC 2033은 LMTP를 광역 네트워크에서 사용하지 말라고 권고합니다. 그 경계는 목적에서 나옵니다. 상위 큐 관리자가 영구 재시도 권한을 가지고, 하위 에이전트가 가까운 수신자별 전송을 수행합니다. 길고 실패하기 쉬운 경로는 작업이 완료되었는데 응답이 사라질 가능성을 높이고, 큐 관리자의 즉각적 지식을 덜 신뢰할 수 있게 만듭니다.

RFC는 더 나아갑니다. 모든 수신자에 대한 책임을 빠르게 수락할 수 있고 필요한 통지를 생성할 수 있는 서버는 LMTP를 구현해서는 안 됩니다. 그런 서버는 이미 큐를 소유하는 SMTP 수신기처럼 동작합니다. 수신자별 차단 응답은 유용한 큐 복잡성을 제거하지 않으면서 동기화 노출만 더합니다.

따라서 LMTP는 "더 좋은 오류 메시지를 가진 SMTP"가 아닙니다. 영구 책임이 어디에 속하는지에 대한 선언입니다. 그 이점은 클라이언트가 이미 큐를 소유하고, 서버가 더 정확한 로컬 전송 진실을 가지지만 미해결 작업을 보존해서는 안 될 때만 나타납니다.

즉각 판정은 전송 보고서가 아니었다

이후의 전송 상태 통지(DSN)는 다른 시스템이 책임을 떠안은 뒤의 사건을 기술합니다. LMTP의 최종 응답은 인계 자체에 참여합니다. 일시적 LMTP 결과는 현재 큐 관리자에게 해당 수신자에 대해 책임이 이전되지 않았다고 알립니다. 긍정적 결과는 이전되었다고 말합니다.

어느 진술도 사람이 메시지를 읽었는지, 사용자 인터페이스가 그것을 표시했는지, 그 주소가 의도된 사람을 가리키는지를 증명하지 않습니다. 이 프로토콜은 전송 책임을 다룹니다. 사서함 결과를 신원이나 주목으로 바꾸지 않습니다.

이 구분이 LMTP를 DSN의 역사와 분리합니다. 주목할 발명은 송신자를 위한 더 풍부한 보고서가 아니었습니다. 하나의 로컬 실패가 두 번째 전체 수신자 큐를 강제하지 않을 만큼 세분화된 최종 교환이었습니다.

출처와 근거의 한계

닫힌 출처 집합은RFC 1047,RFC 2033,RFC 2034,RFC 2920,RFC 3463,RFC 5321입니다. 이들은 프로토콜 문법과 책임 및 실패 경계를 정립합니다. 그러나 현재 배포 현황, 벤더 기본값, 사고 빈도나 범용 전송 소켓은 측정하지 않습니다. RFC 2033은 Informational이며, 이 글은 그 제한된 설계를 인터넷 전체의 의무로 만들지 않습니다.