Quelle est la différence de comportement entre return-path, reply-to et from?

Sur notre application de messagerie, nous envoyons des e-mails avec l'en-tête suivant:

FROM: [email protected]
TO: [email protected]
Return-PATH: [email protected]

Le problème auquel nous sommes confrontés est que certains serveurs de messagerie vont immédiatement renvoyer un message et utiliser le chemin from ou reverse ([email protected]) à la place de notre serveur de gestion de rebond. Nous voulons savoir si nous modifions dans l'en-tête la réponse pour qu'elle soit la même que le chemin de retour si nous serons en mesure d'attraper tous les rebonds.

Toutes les autres idées sont les bienvenues?

Nous utilisons les documents suivants comme références: VERP RFC Bounce Messages

Analyse du journal SMTP pour obtenir des rebonds

EDIT 1: Quelques informations supplémentaires pour voir si nous pouvons obtenir cette résolution.

Nous voulons savoir à quel moment le serveur de messagerie relayant le message choisira d'utiliser le chemin de réponse plutôt que le chemin de retour. Nous avons remarqué que lorsque le premier serveur smtp relayant le message est rejeté, il l'envoie à la réponse, mais quand cela se produit après un saut, il l'envoie au chemin de retour.

Commençons par un exemple simple. Disons que vous avez une liste de diffusion , qui va envoyer le contenu RFC2822 suivant .

From: <[email protected]>
To: <[email protected]>
Subject: Super simple email
Reply-To: <[email protected]>

This is a very simple body.

Maintenant, disons que vous allez l'envoyer à partir d'une liste de diffusion, qui implémente VERP (ou un autre mécanisme de suivi de rebond qui utilise un chemin de retour différent). Disons qu'il aura un chemin de retour de [email protected]. La session SMTP peut ressembler à ceci:

{S}220 workstation1 Microsoft ESMTP MAIL Service
{C}HELO workstation1
{S}250 workstation1 Hello [127.0.0.1]
{C}MAIL FROM:<[email protected]>
{S}250 2.1.0 [email protected] OK
{C}RCPT TO:<[email protected]>
{S}250 2.1.5 [email protected] 
{C}DATA
{S}354 Start mail input; end with <CRLF>.<CRLF>
{C}From: <[email protected]>
To: <[email protected]>
Subject: Super simple email
Reply-To: <[email protected]>

This is a very simple body.
.

{S}250 Queued mail for delivery
{C}QUIT
{S}221 Service closing transmission channel

Où {C} et {S} représentent respectivement les commandes client et serveur.

Le courrier du destinataire ressemblerait à ceci:

Return-Path: [email protected]
From: <[email protected]>
To: <[email protected]>
Subject: Super simple email
Reply-To: <[email protected]>

This is a very simple body.

Maintenant, décrivons les différents «FROM».

1. Le chemin de retour (parfois appelé chemin inverse, expéditeur d'enveloppe ou enveloppe de - tous ces termes peuvent être utilisés de manière interchangeable) est la valeur utilisée dans la session SMTP dans la MAIL FROMcommande. Comme vous pouvez le voir, il n'est pas nécessaire que ce soit la même valeur que celle trouvée dans les en-têtes de message. Seul le serveur de messagerie du destinataire est censé ajouter un en-tête Return-Path en haut de l'e-mail. Cela enregistre l'expéditeur du chemin de retour réel pendant la session SMTP. Si un en-tête Return-Path existe déjà dans le message, cet en-tête est supprimé et remplacé par le serveur de messagerie du destinataire.

Tous les rebonds qui se produisent pendant la session SMTP doivent revenir à l'adresse Return-Path. Certains serveurs peuvent accepter tous les e-mails, puis les mettre en file d'attente localement, jusqu'à ce qu'il dispose d'un fil de discussion gratuit pour les remettre à la boîte aux lettres du destinataire. Si le destinataire n'existe pas, il doit le renvoyer à la valeur Return-Path enregistrée.

Notez que tous les serveurs de messagerie n'obéissent pas à cette règle; Certains serveurs de messagerie le rebondiront à l'adresse FROM.

2. L'adresse FROM est la valeur trouvée dans l'en-tête FROM. C'est censé être de qui vient le message. C'est ce que vous voyez comme le "FROM" dans la plupart des clients de messagerie. Si un e-mail n'a pas d'en-tête Reply-To, toutes les réponses humaines (client de messagerie) doivent retourner à l'adresse FROM.

3. L'en-tête Reply-To est ajouté par l'expéditeur (ou le logiciel de l'expéditeur). C'est là que toutes les réponses humaines doivent également être abordées. Fondamentalement, lorsque l'utilisateur clique sur "répondre", la valeur Reply-To doit être la valeur utilisée comme destinataire du courrier électronique nouvellement composé. La valeur Reply-To ne doit être utilisée par aucun serveur. Il est destiné à une utilisation côté client (MUA) uniquement.

Cependant, comme vous pouvez le constater, tous les serveurs de messagerie ne respectent pas les normes ou recommandations RFC.

J'espère que cela devrait aider à clarifier les choses. Cependant, si j'ai manqué quelque chose, faites-le moi savoir et j'essaierai de répondre.

Une autre façon de penser à Return-Pathvs Reply-Toest de le comparer au courrier postal.

Lorsque vous envoyez une enveloppe par courrier, vous spécifiez une adresse de retour . Si le destinataire n'existe pas ou refuse votre courrier, le maître de poste renvoie l'enveloppe à l'adresse de retour. Pour les e-mails, l' adresse de retour est le Return-Path.

À l'intérieur de l'enveloppe peut être une lettre et à l'intérieur de la lettre, il peut diriger le destinataire vers «Envoyer la correspondance à l' adresse d'exemple ». Pour l'e-mail, l' exemple d'adresse est le Reply-To.

En substance, une adresse de retour d'affranchissement est comparable à l'en- Return-Pathtête de SMTP et l'en- Reply-Totête de SMTP est similaire aux instructions de réponse contenues dans une lettre.

pour ceux qui sont arrivés ici parce que le titre de la question:

J'utilise l' Reply-To:adresse avec les formulaires Web. lorsque quelqu'un remplit le formulaire, la page Web envoie un e-mail automatique au propriétaire de la page. il From:s'agit de l'adresse automatique de l'expéditeur du courrier, de sorte que le propriétaire sait qu'elle provient du formulaire Web. mais l' Reply-To:adresse est celle remplie dans le formulaire par l'utilisateur, donc le propriétaire peut simplement appuyer sur répondre pour les contacter.

J'ai dû ajouter un en-tête Return-Path dans les e-mails envoyés par une instance Redmine. Je suis d'accord avec greatwolf, seul l'expéditeur peut déterminer un chemin de retour correct (non par défaut). Le cas est le suivant: Les e-mails sont envoyés avec l'adresse e-mail par défaut: [email protected] Mais nous voulons que l'utilisateur réel à l'origine de l'action reçoive les e-mails de rebond, car ce sera lui qui saura comment corriger les e-mails de mauvais destinataires (et pas les administrateurs d'application qui ont d'autres chats à fouetter :-)). Nous l'utilisons et cela fonctionne parfaitement avec exim sur le serveur d'application et zimbra comme serveur de messagerie final de l'entreprise.