Même un bref aperçu du protocole SMTP vous fera remarquer qu’outre le HELO habituel, il existe également EHLO, ce qui rend le Élargi Le serveur SMTP annonce ses capacités au-delà de la norme d'origine. Un de ceux-ci est DSN. DSN? L'ADN et le DDT ne suffisent-ils pas?
Argumenter que le courrier électronique n'est pas fiable, que quelqu'un devrait " … nourrir leur serveur mieux; il a mangé mon courrier … "n’est pas rare. Pourtant, il n’ya pas beaucoup de raisons d’appuyer ces soupçons.
Livraison S tatus N La notification a été autour depuis RFC 821 (de 1982). Dès que la partie DATA du protocole SMTP est terminée et que le serveur a accepté le courrier électronique pour la livraison, il en est responsable. Si, pour une raison quelconque, il ne peut pas le faire parvenir au destinataire, il doit le renvoyer avec une notification de l'erreur à l'expéditeur d'origine. Cela a abouti à un courrier électronique obscur.
En dehors de cela, cette ancienne convention signifiait que soit vous aviez un message d'erreur, soit vous aviez rien dans quel cas tu savais rien : l'e-mail est peut-être arrivé ou non. Dans de nombreux cas, les messages d’erreur étaient aussi utiles qu’aucun message d’erreur. Avec l'email qui devient de plus en plus important, ce n'est plus satisfaisant (comme si c'était avant).
Extensions DSN vers SMTP
La RFC 1891 propose des extensions du protocole SMTP qui devraient aboutir à un système DSN plus fiable et plus utilisable. C'est un ensemble d'extensions aux commandes MAIL et RCPT.
Pas d'EHLO, pas de plaisir
Premièrement, nous devons nous assurer que le serveur prend en charge DSN. Nous devons donc lui dire EHLO et écouter attentivement. S'il répond avec DSN quelque part dans la liste des fonctionnalités, nous pouvons supposer qu'il sera en mesure de répondre à nos demandes. Si non, alors non: nous pouvons essayer un autre serveur ou simplement nous replier sur le courrier électronique sans DSN. Par exemple:
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Dim., 24 août 1997 18:23:22 +0200EHLO localhost250-larose.magnet.at Bonjour localhost 127.0.0.1, heureux de faire votre connaissance250-EXPN250 VERBES250-8BITMIMETAILLE 250250-DSN250-ONEX250-ETRN250-XUSR250 HELP Heureusement, entre autres choses, nous retrouvons DSN. La commande suivante est généralement MAIL FROM. Avec DSN, ce n'est pas différent. Mais vous pouvez émettre deux options supplémentaires: RET et ENVID. L'option RET a été placée assez arbitrairement dans la commande MAIL, mais elle convient ici aussi bien que partout ailleurs. Le but est de spécifier quelle quantité de votre message d'origine doit être renvoyée en cas d'échec de livraison. Les arguments valides sont FULL et HDRS. La première signifie que le message complet doit être inclus dans le message d'erreur. HDRS demande au serveur de ne renvoyer que les en-têtes du courrier en échec. Si RET n'est pas spécifié, le serveur décide ce qu'il doit faire. Dans la plupart des cas, HDRS sera la valeur par défaut. ENVID appartient vraiment à l'expéditeur, car c'est lui (ou plutôt) son client de messagerie qui en fait le seul usage. identifiant de l'enveloppe . Son but est d'indiquer à l'expéditeur à quel courrier électronique correspond un message d'erreur éventuellement émis. Le format de cet identifiant est essentiellement laissé à l'imagination de l'expéditeur. Nous n'utiliserons pas ENVID dans notre exemple: MAIL FROM: [email protected] RET = HDRS250 expé[email protected] … Expéditeur ok Apparemment, nous voulons seulement récupérer les en-têtes dans notre DSN. Le RCPT TO: obtient également son lot d'extensions: NOTIFY et ORCPT. NOTIFY est le véritable cœur du DSN. Il raconte le serveur quand envoyer une notification de statut de livraison. La première valeur possible est NEVER, ce qui signifie qu'en aucun cas un DSN ne doit être renvoyé à l'expéditeur. Ce n'était pas possible sans DSN. Ensuite, il y a SUCCESS, qui vous avertira lorsque votre courrier est arrivé à destination. FAILURE est la contrepartie de SUCCESS: un DSN arrivera si une erreur survient lors de la livraison. La dernière option est DELAY: vous serez averti en cas de retard inhabituel dans la livraison, mais le résultat réel de la livraison (succès ou échec) n’a pas encore été décidé. JAMAIS doit être le seul argument s'il est spécifié, les trois autres peuvent apparaître dans une liste, délimitée par une virgule. SUCCESS et FAILURE forment ensemble une équipe assez forte, qui vous dit dans (presque) tous les cas ce qui est arrivé à votre courrier. ORCPT a pour but de préserver la original destinataire d'un message électronique, par exemple, s'il est transféré à une autre adresse. L'argument de cette option est l'adresse électronique du destinataire d'origine ainsi que le type d'adresse. Le type d'adresse vient en premier, suivi d'un point-virgule et enfin de l'adresse. Par exemple: RCPT TO: [email protected] NOTIFY = ECHEC, DELAY ORCPT = rfc822; [email protected]250 [email protected] … Le destinataire est ok (va faire la queue) Viennent ensuite les DONNÉES telles que nous les connaissons et éventuellement, nous espérons, une notification sur l’état de la livraison vous informant de votre succès. Bien sûr, toute cette beauté et cela ne fonctionnera que si les agents de transport de courrier de l'expéditeur au destinataire prennent en charge DSN. Un jour ils le feront. Extensions d'expéditeur DSN
Extensions de destinataire DSN
Est-ce que DSN fonctionne?
