요약

  • DELIVERBY는 메일의 외부에 있던 기한을 SMTP envelope 조건으로 만들었다. 기한이 지난 후 시도를 중단하는 Return과, 지연을 보고하면서 계속하는 Notify를 별개의 판단으로 표현했다.
  • 대응하는 중계는 경과 시간을 차감해 남은 초를 다음으로 넘긴다. 이는 우선 처리, 기한 내 전달, 평소보다 긴 보관, 기한 내에 돌아오는 DSN 중 어느 것도 보장하지 않는다.

메일이 두 MTA 사이를 이동하는 순간, 책임은 단순히 복사되지 않는다. 발신 측이 보유하던 queue의 시간, 재시도 이력, 다음 경로 후보는 그대로 수신 측의 현실이 되지 않는다. 그래도 하나의 정보만은 같은 의미로 전달되어야 한다. 앞으로 몇 초라면 이 메일을 계속 배달하는 것이 옳은가 하는 정보이다.

RFC 2852는 업무 시간 이후에 pager를 울리고 싶지 않다는 예를 들었다. 17시 전에는 유용한 메시지도 그 이후에는 불쾌하거나 잘못된 조작이 된다. 평범한 SMTP queue는 일시적 실패라면 나중에 재시도한다. 그것은 배달 규칙으로서 옳아도 메시지의 용도는 모른다.

2000년 6월의 Deliver By SMTP Service Extension은 용도의 기한을 queue에 가져왔다. 다만 발신자에게 원격 queue의 지배권은 주지 않았다. 각 MTA가 조건을 받아들이거나 거부하고, 받아들인 경우에만 남은 시간을 승계한다. 이 경계가 단순한 "urgent" 표시와의 차이이다.

최소 시간의 광고는, 약속보다 먼저 거부를 놓았다

대응 서버는 EHLO에DELIVERBY를 표시한다. 나아가 Return mode로 받아들여지는 고정된 최소 by-time을 숫자로 광고할 수 있다. 클라이언트는MAIL FROM에BYparameter를 더한다. 새로운 SMTP verb는 없다.

이 최소값은 성능 선전이 아니라 admission control이다. 남은 90초의 메시지에 대해 다음 MTA가 최소 240초를 필요로 한다고 밝히고 있다면, 그 경로는 같은 의무를 떠맡을 수 없다. 중계가 숫자를 무시하고 넘기면, 대응하는 것처럼 보이면서 기한을 잃는다.

반대로, DELIVERBY를 받아들여도 queue의 우선순위를 올릴 의무는 없다. RFC는 특별한 처리를 요구하지 않으며, DSN조차 빠르게 돌아온다고 하지 않는다. 발신자는 "기한이 지나면 무엇을 할 것인가"를 선택할 수 있지만, "다른 메일보다 먼저 처리하라"고 명할 수는 없다.

절대 시각이 아니라 차분을 넘긴 이유

BY는 부호 있는 십진 초,R또는N, 필요하다면 trace의T로 이루어진다. 초수의 범위는 마이너스 999,999,999에서 플러스 999,999,999까지이다.

absolute timestamp가 아니라 delta를 쓰기 때문에, 별개의 운영 주체가 같은 wall clock을 공유할 필요는 없다. 수신한 MTA는 자신의 현재 시각에 초수를 더해 local한 deliver-by-time을 가진다. 다음MAIL FROM을 보내기 직전에 그까지의 남은 값을 계산한다.

물론 완전하지 않다. 명령은 순간적으로 도착하지 않고, 각 hop의 latency 때문에 유효한 기한은 조금 늘어난다. RFC 2852는 이 오차가 누적된다고 명시한다. 메커니즘이 보존하는 것은 시간의 완전한 동일성이 아니라, 소비한 예산을 돌려받지 않는다는 관계이다.

by-time은 deliver-after도 아니다. 미래의 어느 시각까지 보류하라는 기능이 아니라, 그 시간 안에 배달하라는 조건이다. 또한 보통의 message retention을 늘리지 않는다. local policy가 더 일찍 단념한다면 기한 전에 실패를 돌려줄 수도 있다.

Return과 Notify는 "지연"의 의미를 나누었다

R는 Return을 나타낸다. 0 이하는 부적당하며, deliver-by-time까지 배달 또는 중계하지 못하면 추가 시도를 해서는 안 된다. 대상 recipient에는 5.4.7, delivery time expired의 failed DSN을 낸다. 여기서 기한은 관측값이 아니라 보관을 끝내는 명령 조건이 된다.

N은 Notify이다. 기한이 지나도 local policy에 따라 배달을 계속하고, 대상 recipient에는 4.4.7의 delayed DSN을 낸다. 0이나 음수도 올바르다. 이미 지난 기한은 배달 권한을 지우지 않더라도 지연의 증거로 남기 때문이다.

같은 지연을 한 단어로 다루지 않는 점이 중요하다. 회의 참가 URL처럼 늦으면 무의미해지는 정보도 있고, 청구서처럼 늦어도 전달할 가치가 있는 정보도 있다. 전자에는 정지가 필요하고 후자에는 가시화가 필요하다. 프로토콜은 용도 그 자체를 판정하지 않고, 발신 측이 선택한 결과를 queue의 동작에 연결한다.

대응 hop은 잔액을 승계했다

다음 서버도 DELIVERBY를 광고하는 경우, 중계 클라이언트는 mode를 유지하고 남은 초를 다시 계산한BY를 보내야 한다. 원래의 값을 재사용해서는 안 된다. 여러 관리 영역을 지날수록 같은 deadline의 잔액은 줄어든다.

Return mode는 capability chain을 요구한다. 미대응 서버에는 중계할 수 없고, 상대의 minimum이 남은 값보다 큰 경우에도 넘길 수 없다. 다른 정당한 MX를 시도할 여지는 있지만, 대응하는 상대가 없다면 undeliverable로 다룬다. 기한을 잃은 배달은 Return의 위임을 실행한 것이 아니다.

Notify mode는 미대응 hop으로 진행할 수 있다. 기한 이후의 시도를 허락하는 mode이기 때문이다. 다만 경계는 숨길 수 없다. 중계 측은 적용되는 recipient에 relayed DSN을 내고, 하류가 DSN에 대응하는 경우 delay 통지를 이어받는다. 메시지는 앞으로 진행시키더라도 잃어버린 시간 semantics를 존재하는 것처럼 꾸밀 수 없다.

이 차이는 thin coordination의 실례이다. IETF가 queue를 운영하는 것이 아니다. 운영자의 local policy도 통일하지 않는다. 다만, 독립된 운영자 사이에서 같은 제약을 내세운다면, 남은 값, mode, capability loss의 evidence만은 정확하게 넘기도록 요구한다.

하나의 SMTP transaction 안에서도 지식은 단계적이었다

서버는MAIL FROM을 250으로 받은 뒤,RCPT TO,DATA, 또는 end-of-data에서 기한을 지킬 수 없다고 판단할 수 있다. recipient와 message body를 보기 전에는 알 수 없는 제약이 있기 때문이다.

따라서 첫 긍정 reply는 모든 recipient의 기한 내 배달을 보장하지 않는다. 그 단계에서 parameter를 구문상, 초기 정책상 받아들였다는 evidence에 지나지 않는다. SMTP의 단계적 정보 공개를 무시하고 하나의 250을 end-to-end promise로 바꿔서는 안 된다.

DSN은 시계의 바깥을 보고했다

DELIVERBY는 Delivery Status Notification과 결합되어 failed, delayed, relayed를 전한다. 보고에는Deliver-By-Date를 더할 수 있고, arrival date도 권장된다.T가 있다면 중계마다 relayed DSN을 요구할 수 있고, 그것들은 terminal result가 아니다.

여기서 DSN과 DELIVERBY의 역할은 다르다. DSN은 MTA가 취한 action을 구조화한다. DELIVERBY는 기한 시점에 어떤 action이 필요한가를 정한다.R은 시도 지속 가능 여부를 바꾸고,N은 지연 evidence의 생성을 요구한다.

반송되는 DSN은 별개의 메일이고, 별개의 queue를 거친다.BY=60;R이 60초 후 실패를 확정하더라도, 그 보고가 60초 안에 sender에 도착한다는 보장은 없다. forward path의 deadline을 정의하는 것과 모든 관측을 동시에 통제하는 것은 별개이다.

짧은 기한은 관측 장치이기도 했다

trace는 mail path의 handoff를 드러낸다. 나아가 서로 다른 짧은 by-time을 가진 메시지를 반복해 보내고 거부나 DSN을 비교하면, 투박한 route나 latency 추정에 쓸 수 있다. RFC 2852는 이 probing risk를 security considerations에 기록했다.

결과는 신중하게 읽어야 한다. Notify의 음수는 local에서 기한이 지났음을 보여주지만, 지연을 만든 hop은 정하지 않는다. Return의 5.4.7은 의무를 계속할 수 없음을 보여주지만, 게으름이나 congestion을 증명하지 않는다. relayed는 handoff의 evidence이며, final delivery가 아니다.

현재의 IANA SMTP registry는 DELIVERBY를 RFC 2852와 함께 게재하고 requirement level을 MAY로 한다. 이는 표준화된 선택지가 남아 있다는 사실이며, deployment survey가 아니다.

DELIVERBY가 역사에 남긴 것은 시간을 message property로 만든 것만이 아니다. 독립된 운영자를 거치는 제약은, 받는 쪽이 거부할 수 있고, 소비에 따라 줄어들고, 지속 불가능한 지점에서 evidence를 남겨야 한다는 설계이다. 중계가 리셋하지 못했던 것은 시계가 아니다. 이미 떠맡고, 이미 소비한 책임이었다.

출처