요약

  • 일반 SMTP 메일은 이후 배달 보고서를 위해 역방향 경로를 제공합니다. 통지 메시지는MAIL FROM:<>를 사용하므로, 통지 자체의 실패가 또 다른 통지를 요구해 오류 루프를 만들 수 없습니다.
  • 널 경로는 명시적인 봉투 상태이며, 누락된From:헤더나 익명의 정당성, 제어를 건너뛰는 허가가 아닙니다. 서브미션은 이를 지원해야 하며, SPF는 HELO를 통해 발신 호스트를 평가할 수 있습니다.
  • 구조화된 DSN은 상관 분석과 수신자별 근거를 개선했지만, 종단 발신자 개념은 그대로 유지했습니다. 원격 보고가 중단되면 책임은 사라지는 것이 아니라 로컬 로그나 포스트마스터 처리로 이동합니다.

믿을 수 있는 약속이 곤란한 두 번째 메시지를 만들다

SMTP는 발신 클라이언트가 아직 연결된 상태에서 수신자를 거부할 수 있습니다. 이 경우 부정 응답은 기존 트랜잭션 안에서 실패를 전달합니다. 클라이언트는 여전히 자신이 메시지를 소유하고 있음을 알며, 새 메일이 필요 없습니다.

더 어려운 경우는 수락 이후에 시작됩니다. 릴레이는 메시지를 저장하고 책임을 받아들였기 때문에 DATA 이후 긍정 완료를 반환한 뒤에야, 다음 시스템에 도달할 수 없거나 사서함이 사라졌거나 하류 게이트웨이가 배달을 완료할 수 없음을 발견할 수 있습니다. 원래 발신자는 더 이상 연결에 있지 않습니다. 실패 자체가 메일이 되어야 합니다.

그 두 번째 메시지에는 수신자, 즉 원본 봉투의 역방향 경로가 필요합니다. SMTP는 보통MAIL FROM에서 역방향 경로를 지정하므로, 발신자도 필요해 보입니다. 그러나 통지에 일반적인 회신 사서함을 주면 재귀적 약속이 생깁니다. 통지가 배달될 수 없으면 다음 서버는 그 통지의 발신자에게 통지를 보냅니다. 그 새 통지마저 실패하면 과정이 반복될 수 있습니다.

프로토콜은 실패를 보고하면서도 그 보고 자체의 실패를 보고하겠다는 약속을 하지 않는 방법이 필요했습니다.

빈 괄호가 긍정적 의미를 담았다

RFC 821은 1982년에 이 문제를 인식했습니다. 릴레이 작업을 수락한 뒤 배달에 실패한 서버는 원래 역방향 경로를 향해 미배달 메일 통지를 만들어야 했습니다. 또한 서버는 통지 메시지 자체의 문제에 대해 통지 메시지를 보내지 말라고 경고했습니다.

그 루프 절단 장치는 통지의 MAIL 명령에서 널 역방향 경로였습니다:

MAIL FROM:<>

꺾쇠 괄호는 로컬 부분이 비어 있는 사서함을 의미하지 않습니다. 이것은 SMTP 봉투 안의 의도적 부재를 인코딩합니다. 즉, 추가 배달 통지를 보낼 원격 사서함이 존재하지 않는다는 뜻입니다. 수신자는 여전히 메시지를 수락해 실제RCPT TO목적지로 배달할 수 있으며, 제거되는 것은 뒤로 향하는 통지 간선뿐입니다.

그래서 "발신자 없음"이라는 표현은 오해를 낳습니다. 통지는 메일 시스템이 생성했고 연결을 통해 이동했으며 추적 증거를 담을 수 있습니다. 그것에게 없는 것은 생성자가 아니라 원격 실패 목적지입니다.

제안이 호스트 요구사항이 되다

원래 SMTP 문서는 널을 루프를 막는 방법의 하나로 기술했습니다.RFC 1123은 1989년에 이 동작을 강화했습니다. 빈 역방향 경로는 반드시 지원되어야 했습니다. 수신자는 일반적인 주소가 없다는 이유만으로MAIL FROM:<>를 형식 오류로 다룰 수 없게 되었습니다.

RFC 1123은 또한 종단 규칙을 완성했습니다. 수락 이후에 발견된 실패에 대한 통지는 널 역방향 경로를 사용해야 하며, 그 통지가 보내질 주소가 이미 널이라면 수신자는 그것을 보내서는 안 됩니다.

따라서 두 가지 의무가 빈 값에서 만납니다. 유효한 인프라 메일이 이 구문을 사용하므로 시스템은 이를 수락해야 합니다. 동시에 시스템은 또 다른 통지를 고려할 때 이것을 정지 신호로 해석해야 합니다. 한쪽만 구현하면 설계가 깨집니다. 모든 널 발신자를 거부하면 정당한 보고를 잃고, 구문은 수락하면서 반송하면 재귀가 다시 만들어집니다.

봉투와 메시지는 서로 다른 대화에 속했다

역방향 경로는 SMTP 트랜잭션 값입니다. 읽는 사람을 위한From:필드가 아니고,Reply-To도 아니며, 본문을 아무도 작성하지 않았다는 주장도 아닙니다.

자동 통지는 사람이 읽을 수 있는 From 주소로 서비스 운영자를 가리킬 수 있어, 독자는 누가 만들었는지 이해하거나 오작동을 보고할 수 있습니다. 동시에 그 봉투는MAIL FROM:<>일 수 있으며, 이는 전송 소프트웨어에 이 메시지가 실패하더라도 DSN을 만들지 말라고 알려줍니다.

이 분리가 본질적입니다. 헤더 From은 사람 간 대화에 참여하고, Reply-To는 사람에게 신중한 응답의 목적지를 알려줄 수 있습니다. 봉투 역방향 경로는 배달 실패에 대한 기계 책임을 배분합니다. "이메일 주소처럼 보인다"는 이유로 한 표면을 다른 표면으로 복사하면 제어 그래프가 바뀝니다.

이 실수는 일반 자동화에서 흔합니다. 프로그램이 봉투 발신자가 없음을 보고, 눈에 보이는 From 주소를 찾아 그 주소로 답장합니다. 프로그램은 방금 메일 시스템이 루프 방지를 위해 제거한 간선을 복원한 것입니다. 구문을 이해하는 소프트웨어는 부재를 채우지 말고 그대로 보존해야 합니다.

수락 시점이 치유 방법을 결정했다

빈 역방향 경로는 SMTP의 책임 모델도 드러냅니다.RFC 5321에서 DATA 이후의 긍정 완료는 공식적인 인계입니다. 수신자는 배달, 추가 릴레이, 이후의 통지에 대한 책임을 떠안습니다. 그 응답 전이라면 발신자는 즉각적인 거부를 받고 제어권을 유지할 수 있습니다.

가장 안전한 실패는 종종 가장 이른 방어 가능한 실패입니다. 수신 시스템이 트랜잭션 중에 수신자가 무효하거나 정책이 메시지를 거부한다는 것을 판단할 수 있다면, 부정 SMTP 응답은 실제로 연결된 클라이언트에게 알립니다. 위조되었을 수 있는 역방향 경로로 향하는 별도의 반송을 만들지 않습니다.

어떤 실패는 미리 알 수 없습니다. 메일링 리스트 확장, 일시적 DNS 문제, 하류 게이트웨이, 이후의 로컬 처리는 수락 이후에야 드러날 수 있습니다. 이 경우 통지 메일은 불가피합니다. 널 발신자는 생성된 분기에 더 이상의 원격 보고 분기가 없도록 함으로써 새로운 위험을 담습니다.

이 경계는 이후 백스캐터 문제에서 중요해졌습니다. 악의적인 일반 메일이 무관한 피해자의 주소를 역방향 경로로 제공하면, 수락 후 반송 방식은 그 피해자에게 트래픽을 보냅니다. DSN의 널은 재귀적 반송을 막지만, 첫 번째 잘못 향한 통지를 되돌리지는 못합니다. 조기 거부와 발신자·호스트 인가는 인접한 부분을 각각 해결합니다.

종단이 침묵 속 폐기를 의미하지 않았다

유효한 DSN 자체가 배달될 수 없다면 어떻게 될까요? 원격 프로토콜 대화는 끝나지만 운영 책임은 남습니다.

RFC 5321은 로컬 시스템이 동일 환경 안에서 널 주소 실패에 대한 정보를 기록하거나 다른 방식으로 전달할 수 있도록 허용합니다. 또한 사이트는 실패한 통지를 메일 시스템을 수리할 수 있는 포스트마스터에게 보낼 수 있다고 명시합니다. 핵심은 이 경로가 또 다른 외부 DSN을 만들어서는 안 된다는 점입니다.

여기서 차이는 기계적 메커니즘만큼이나 거버넌스의 차이입니다. 원격 통지는 역방향 경로를 지명한 당사자에게 배달 사실을 돌려보내려 합니다. 로컬 에스컬레이션은 운영자에게 "우리의 최종 보고서가 목적지에 도달하지 못했다. 설정, 큐, 라우팅을 점검하라"고 말합니다. 하나는 책임을 도메인 너머로 옮기고, 다른 하나는 프로토콜의 종단 상태에 도달한 시스템에 책임을 유지합니다.

따라서 널은 증거를 폐기할 구실이 아닙니다. 큐 ID, 원본 봉투 데이터, 수신자 상태, 진단 결과는 운영 및 개인정보 요구에 비례해 여전히 보존되어야 합니다. 빈 경로는 운영자가 무엇을 잊어도 되는지가 아니라 누구에게 메일을 보내서는 안 되는지를 말합니다.

DSN 요청이 명시적으로 되다

초기 미배달 통지는 매우 다양했습니다. 사람이 쓴 텍스트는 제품과 언어마다 달랐고, 자동화는 보고서와 수신자를 상관 분석하기 어려웠습니다.RFC 3461은 Delivery Status Notification용 SMTP 확장을 추가했습니다.

그 매개변수들은 여러 선택을 분리했습니다.ENVID는 상관 분석을 위해 선택된 봉투 식별자를 담습니다.RET는 반환되는 보고서에 헤더만 담을지 원본 내용을 더 담을지를 요청합니다.NOTIFY는 SUCCESS, FAILURE, DELAY 보고를 요청할 수 있고,NEVER는 단독으로 아무 보고도 요청하지 않습니다.ORCPT는 재작성이나 게이트웨이 처리가 원래 수신자 주소를 잃을 수 있을 때 그 주소를 보존합니다.

이 매개변수들은 증거와 보고 선호를 기술합니다. 그렇다고 그 자체로 무효했을 수신자를 유효하게 하거나 그 반대로 만들지 않으며, 유효한 DSN 매개변수가 나타난다고 MAIL이나 RCPT 수락 결정을 바꾸도록 설계되지 않았습니다.

종단 불변식은 새로운 세부보다 강했습니다. 준수하는 MTA는 MAIL FROM이 널인 어떤 메시지에 대해서도 DSN을 발행해서는 안 되며, 메시지 헤더에 그럴듯한 발신자가 있더라도 마찬가지입니다. 추측은 전송 신호를 무너뜨립니다. 로컬 포스트마스터는 그 자체로 DSN을 만들지 않는 경로를 통해 알림을 받을 수 있습니다.

DSN이 전송될 때, 그 발신자 주소는 널이어야 합니다.RET는 DSN 자신의 트랜잭션에 사용해서는 안 되고,NOTIFY가 있다면 반드시NEVER여야 합니다. 보고서는 풍부한 배달 증거를 담으면서 자기 자신에 대한 보고를 범주적으로 거부합니다.

반송이 구조화된 보고서가 되다

RFC 3464는 DSN 형식을 정의했습니다. DSN은 보고서 유형이delivery-status인 MIMEmultipart/report입니다. 사람이 읽을 수 있는 설명, 기계가 읽을 수 있는message/delivery-status부분, 그리고 해당 반환·개인정보 규칙에 따라 원본 메시지에서 선별된 자료를 담을 수 있습니다.

하나의 DSN은 정확히 하나의 원본 메시지에 관한 것이지만 여러 수신자에 대해 별도의 블록을 담을 수 있습니다.Action필드는 failed, delayed, delivered, relayed, expanded 결과를 구별할 수 있습니다.Status는 구조화된 코드를 담습니다. 보고 MTA, 도착 데이터, 원격 MTA, 진단 정보, 재시도 기한이 조사를 지원할 수 있습니다.

이 진화가 중요한 이유는 "실패"와 "지연"이 서로 다른 주장이기 때문입니다. delayed 보고서는 시도가 계속된다고 말하고, failed 보고서는 보고 MTA가 그 수신자를 포기했다고 말합니다. 사람의 문단은 이 차이를 흐릴 수 있습니다. 구조화된 필드를 통해 사용자 에이전트나 리스트 관리자는 산문을 파싱하지 않고 상태를 갱신할 수 있습니다.

그러나 구조는 인증이 아닙니다. RFC 3464는 위조와 기밀성을 실제 문제로 다룹니다. DSN은 원본 수신자, 전달 주소, 메시지 자료를 노출할 수 있습니다. 악의적 행위자는 보고서처럼 보이는 내용을 만들어낼 수 있습니다. 이 형식은 증거의 세분성을 개선할 뿐 부인 불가능성을 제공하지 않습니다.

널 역방향 경로는 여전히 필요합니다. 더 나은 증거가 재귀를 제거하지 못하기 때문입니다. 오히려 더 큰 구조화된 보고서는 오류 루프를 더 비싸게 만들 수 있습니다.

부분 배달이 하나의 메시지를 여러 결과로 만들다

원본 메시지는 여러 수신자를 지명할 수 있습니다. 일부 배달은 성공하는 동안 다른 배달은 실패하거나 지연된 채 남을 수 있습니다. 단일 텍스트 "배달 실패"는 이 상태를 안전하게 표현할 수 없습니다.

수신자별 DSN 블록은 이 분할을 보존합니다. 운영자와 애플리케이션은 어떤 주소가 실패했는지, 무엇이 지연되었는지, 마지막 원격 응답이 무엇이었는지, 추가 시도가 계획되어 있는지를 물을 수 있습니다. 원본 봉투 식별자는 그러한 결과를 서브미션과 연결하며, 눈에 보이는 Message-ID가 유일한 전송 트랜잭션이라고 주장하지는 않습니다.

이 구별은 책임 있는 자동화를 지원합니다. 메일링 리스트는 모든 구독자를 실패로 취급하지 않고 반복적으로 실패하는 하나의 구독만 제거하거나 중단할 수 있습니다. 발신자는 한 주소를 배달된 것으로 보는 동안 다른 주소의 대기 상태를 유지할 수 있습니다.

또한 개인정보 압박을 만듭니다. 기밀 전달 주소나 확장된 모든 구성원을 드러내는 보고서는 원본 발신자가 알 권리가 없던 정보를 노출할 수 있습니다. RFC 3464는 그런 경우 생략이나 경계 변경을 허용합니다. 증거는 승인된 결정에 충분해야 하며, 프로토콜이 담을 수 있기 때문에 최대가 되어서는 안 됩니다.

휴가 자동응답기도 같은 종단 문제를 물려받았다

배달 보고서만이 유일한 자동 메시지는 아닙니다. 휴가 응답기, 그룹 서비스, 헬프 시스템, 콘텐츠 처리기도 모두 수신 메일에 응답할 수 있습니다. 두 응답기가 서로를 트리거할 수 있고, 하나의 응답기가 위조된 요청을 피해자 쪽으로 증폭할 수 있으며, 눈에 보이는 헤더에서 추측한 답장은 잘못된 사람에게 도달할 수 있습니다.

RFC 3834는 이 규율을 일반화합니다. 응답기는 목적지가 널 주소가 되는 응답을 생성해서는 안 됩니다. 자동 응답은 통상 사람 지향적인 From이나 Reply-To 필드에서 추측하지 말고 봉투의 Return-Path로 보내야 합니다.

응답 자체가 자동 응답을 받아서는 안 되는 경우,MAIL FROM:<>를 사용할 수 있습니다. DSN 확장이 가능하다면NOTIFY=NEVER가 권장됩니다. 응답기는 자신의 종단 봉투와 보고 선호를 동시에 밝힙니다.

널은 자동 응답 사슬이 계속되는 것을 막지만 증폭 문제를 해결하지는 못합니다. 반환 주소는 자주 위조됩니다. RFC 3834는 서비스 응답기가, 영향을 받은 당사자가 요청을 승인했다고 믿을 근거가 없다면 큰 답장을 보내거나 부작용을 만들지 않도록 경고합니다. 정지 비트와 인가 확인은 서로 다른 간선을 지킵니다.

서브미션은 정당한 빈 값을 수락해야 했다

어부 정책은 일반적인 봉투 발신자가 없는 모든 메시지를 거부하려는 유혹을 줄 수 있습니다. 메시지 서브미션을 릴레이와 분리하는RFC 6409는 그 지름길을 거부합니다. 널 반환 경로는 허용되며, 그것만으로 거부 사유가 되어서는 안 됩니다. 메일 사용자 에이전트는 처분 통지(disposition notification)를 포함해 널 발신자 메시지를 정당하게 생성합니다.

이 규칙은 무조건적 수락을 요구하지 않습니다. 서브미션 에이전트는 제출 계정을 인증하고, 인가·속도 제한·콘텐츠 정책을 시행하며, 일관되지 않은 사용을 거부할 수 있습니다. 할 수 없는 것은 널 값 그 자체를 남용의 증거로 쓰는 일입니다.

이것은 인터넷 설계에서 반복되는 교훈입니다. 제어를 위해 예약된 값은 보안 계층이 프로토콜 의미를 무시하면 이상으로 보입니다. 모든 이상을 적대로 취급하면 준수하는 동작이 불가능해지고, 모든 예약 값을 신뢰하면 반대 방향의 실패가 생깁니다. 시스템은 상태를 인식한 뒤 그에 적합한 제어를 적용해야 합니다.

호스트 인가는 빈 사서함을 넘어 살아남았다

봉투 사서함의 부재는 SPF에도 물음을 남겼습니다. SPF는 통상 MAIL FROM 도메인을 평가합니다.RFC 7208은 결정적 답을 정의합니다. 역방향 경로가 널일 때, MAIL FROM 식별은 HELO 식별의postmaster로 구성됩니다. 이는 발신자 사서함이 존재하지 않더라도 발신 호스트·도메인에 인가 평가면을 제공합니다.

HELO 검사는 DSN 본문을 인증하거나 보고된 실패가 실제 일어났음을 증명하지 않습니다. SPF는 도메인에 대한 호스트를 인가합니다. 인가된 서버는 잘못된 통지를 내보낼 수 있고, 위조된 DSN은 무관한 시스템을 통해 이동할 수 있으며, 유효한 보고서는 설정 문제로 SPF에 실패할 수 있습니다.

그 의미는 더 좁습니다. 널이 모든 신원·정책 평가를 사라지게 하는 것은 아닙니다. 프로토콜은 평가를 존재하지 않는 사서함에서 SMTP 클라이언트가 세션을 위해 이미 제공하는 식별로 옮깁니다.

널 MX는 다른 종류의 빈 값이었다

SMTP에는 널 모양의 또 다른 유명한 메커니즘이 있습니다. 널 MX입니다. 둘은 혼동되어서는 안 됩니다. 널 MX는 어떤 도메인이 이메일을 수락하지 않는다는 DNS 선언입니다. 널 역방향 경로는 현재 전송 중이며 수락될 수 있는 메시지의 봉투 값입니다.

하나는 어떤 도메인으로 메일을 배달하려는 시도를 억제하고, 다른 하나는 한 트랜잭션에 대한 배달 보고서의 생성을 억제합니다. 제품이 "널"을 "메일 없음"과 연관시킨다고 해서MAIL FROM:<>를 거부하면 네임스페이스 기능과 메시지 책임을 혼동하는 것입니다.

인터넷은 침묵이 모호할 때 명시적 부재를 반복적으로 사용합니다. 여기서 꺾쇠 괄호는 "발신자 필드가 잊혔다"와 "이 통지는 원격 실패 보고의 끝이다"를 구별합니다.

출처와 증거 한계

원본 미배달 메일 통지와MAIL FROM:<>루프 차단은 RFC 821에 있습니다:https://www.rfc-editor.org/rfc/rfc821.html

빈 경로 지원의 의무화와 널 반환 주소에 대한 통지 금지는 RFC 1123에 있습니다:https://www.rfc-editor.org/rfc/rfc1123.html

DSN 봉투 매개변수, 널 발신자 처리,NOTIFY=NEVER는 RFC 3461에 있습니다:https://www.rfc-editor.org/rfc/rfc3461.html

구조화된 multipart DSN, 메시지별·수신자별 필드, 개인정보·보안 한계는 RFC 3464에 있습니다:https://www.rfc-editor.org/rfc/rfc3464.html

휴가, 그룹, 서비스 응답기 규칙은 RFC 3834에 있습니다:https://www.rfc-editor.org/rfc/rfc3834.html

현재의 책임 인계, 널 발신자 메시지 클래스, 전달 규율, 로컬 포스트마스터 옵션은 RFC 5321에 있습니다:https://www.rfc-editor.org/rfc/rfc5321.html

메시지 서브미션에서의 정당한 널 발신자 동작은 RFC 6409에 있습니다:https://www.rfc-editor.org/rfc/rfc6409.html

널 역방향 경로에 대한 HELO 기반 SPF 식별은 RFC 7208에 있습니다:https://www.rfc-editor.org/rfc/rfc7208.html

이 RFC들은 프로토콜 요구사항을 확립하며, 특정 DSN의 진위성이나 현재 배포 동작을 확립하지 않습니다. 널 발신자는 정당성의 증거도 남용의 증거도 아닙니다. DSN 필드는 부인 불가능성이 아닌 보고서이며, 본 기사는 현재의 반송량, 거부율, 공급자 정책, 스팸 규모에 대해 어떤 주장도 하지 않습니다.