DSN이 SMTP 전자 메일에 배달 상태를 소개하는 방법을 알아보십시오.
귀하가 보낸 이메일에 어떤 일이 일어 났는지 궁금한가요?
SMTP 프로토콜을 간략히 살펴 보더라도 일반적인 HELO 외에도 확장 SMTP 서버가 원래 표준을 뛰어 넘는 기능을 광고하게 만드는 EHLO가 있음을 알 수 있습니다. 이 중 하나가 DSN입니다. DSN? DNA와 DDT가 충분하지 않습니까?
전자 메일이 신뢰할 수 없다고 주장하기 위해 누군가는 " ... 서버를 더 잘 먹여서 내 메일을 먹었 어야한다"는 것이 드문 일이 아닙니다. 나는 그것을 스스로한다. 그러나 이러한 의심을 뒷받침 할 이유가별로 없습니다.
배달 상태는 RFC 821 (1982 년) 이후로 나타났습니다. SMTP 프로토콜의 DATA 부분이 끝나고 서버가 배달을 위해 전자 메일을 수락하면 서버는 전자 메일을 담당합니다. 어떠한 이유로 든 수신자에게 전달할 수없는 경우 원래 수신자에게 오류 통지와 함께 다시 보내야합니다. 이로 인해 약간의 이메일 이 나왔습니다.
그 외에도,이 오래된 컨벤션은 오류 메시지가 있거나 아무 것도 모르는 경우 아무 것도 얻지 못했음을 의미합니다. 이메일이 도착했거나 도착하지 않았을 수 있습니다. 대부분의 경우 오류 메시지는 오류 메시지없이 유용합니다. 전자 메일이 점점 더 중요 해짐에 따라 더 이상 만족스럽지 않습니다 (전에 있었던 것처럼).
SMTP에 대한 DSN 확장
RFC 1891은 SMTP 프로토콜의 일부 확장을 제안하여 더 안정적이고 사용하기 쉬운 DSN 시스템을 제공해야합니다. 이것은 MAIL 및 RCPT 명령에 대한 확장 집합입니다 ( SMTP가 작동하는 방식을 읽은 다음 여기로 돌아 오는 것을 읽지 않습니다.).
EHLO 없음, 재미 없음
먼저 서버가 DSN을 지원하는지 확인해야합니다. 따라서 우리는 그에게 EHLO를 말하고 신중하게 들어야합니다. 기능 목록에있는 DSN으로 응답하면 요청을 처리 할 수 있다고 가정 할 수 있습니다. 그렇지 않다면, 우리는 다른 서버를 시도하거나 단순히 DSN없이 이메일로 돌아갈 수 있습니다. 예를 들어 (내 입력은 파란색이고 서버의 출력은 검은 색) :
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; 일, 1997 년 8 월 24 일 18시 23 분 22 초 +0200
EHLO 로컬 호스트
Hello- localhost [127.0.0.1], 만나서 반갑습니다.
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 도움말
다행히 DSN을 찾았습니다.
DSN 보낸 사람 확장
다음 명령은 일반적으로 MAIL FROM :입니다. DSN의 경우에도 마찬가지입니다. 하지만 두 가지 추가 옵션을 사용할 수 있습니다 : RET 및 ENVID.
RET 옵션은 임의로 MAIL 명령에 포함되었지만 다른 곳에서도 마찬가지입니다. 그 목적은 전달 실패시 원본 메시지의 어느 정도를 반환할지 지정하는 것입니다. 유효한 인수는 FULL 및 HDRS입니다. 전자는 오류 메시지에 전체 메시지가 포함되어야한다는 것을 의미하며, HDRS는 오류가 발생한 메일의 헤더 만 반환하도록 서버에 지시합니다. RET가 지정되지 않으면 서버가 수행 할 작업입니다. 대부분의 경우 HDRS가 기본값이됩니다.
ENVID는 정말로 그녀 또는 (오히려) 그녀의 전자 메일 클라이언트가이 봉투 식별자 를 만드는 유일한 사람이 될 때 발신자에게 속합니다. 이 기능의 목적은 송신자에게 가능한 오류 메시지가 어느 이메일에 해당되는지 알려주는 것입니다. 이 ID의 형식은 기본적으로 발신자의 상상력에 맡겨져 있습니다. 이 예에서는 ENVID를 사용하지 않습니다 (상상력).
MAIL FROM : sender@example.com RET = HDRS
250 sender@example.com ... 발신인 확인
외관상으로는, 우리는 우리의 DSN에서만 우두머리를 돌려 받고 싶다.
DSN받는 사람 확장
RCPT TO : 확장 기능에 대한 공평한 분배 : NOTIFY 및 ORCPT.
NOTIFY는 DSN의 핵심입니다. 배달 상태 알림을 보낼 시기 를 서버에 알려줍니다. 가능한 첫 번째 값은 NEVER가 아니므로 어떤 상황에서도 DSN을 보낸 사람에게 반환해야한다는 것을 의미합니다. 이것은 DSN 없이는 불가능했습니다. 그런 다음 SUCCESS가 있습니다. SUCCESS는 우편물이 목적지에 도착했을 때 알려줍니다. FAILURE는 SUCCESS의 카운터 파트입니다 (!) : 배달 중에 arror가 발생하면 DSN이 도착합니다. 마지막 옵션은 지연입니다. 배달에 특별한 지연이있을 경우 통보를 받지만 실제 배달 결과 (성공 또는 실패)는 아직 결정되지 않았습니다. 지정하는 경우에만 유일한 인수 여야 하며 다른 세 개는 쉼표로 구분 된 목록에 나타날 수 있습니다. SUCCESS와 FAILURE는 메일에 어떤 일이 일어 났는지를 (거의) 알려주는 매우 강력한 팀을 구성합니다 (!).
ORCPT의 목적은 전자 메일 메시지의 원래 수신자를 보존하는 것입니다 (예 : 다른 주소로 전달 된 경우). 이 옵션의 인수는 주소 유형과 함께 원래 수신자의 이메일 주소입니다. 주소 유형이 먼저오고 세미콜론과 마지막으로 주소가옵니다. 예 :
RCPT TO : support@example.com NOTIFY = FAILURE, DELAY ORCPT = rfc822; support@example.com
250 support@example.com ... 수신자 확인 (대기열에 넣기)
그 다음에는 우리가 알고있는대로 DATA가 이어지고, 결국 당신에게 성공을 알리는 배달 상태 알림이되기를 바랍니다.
DSN은 작동합니까?
물론 발신자에서 수신자까지의 메일 전송 에이전트가 DSN을 지원하는 경우에만이 모든 기능이 유용합니다. 그들이 언젠가는.