Quelle est la différence de comportement entre le chemin de retour et la réponse?

Sur notre application de mailing nous envoyons des emails avec l’en-tête suivant:

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

Le problème auquel nous sums confrontés est que certains serveurs de messagerie renverront immédiatement un message et utiliseront le chemin de retour ou de retour ([email protected]) à la place de notre serveur bounce mgmt. Nous voulons savoir si nous modifions dans l’en-tête la réponse pour qu’elle soit identique au chemin de retour si nous pouvons attraper tous les rebonds.

Toutes les autres idées sont les bienvenues?

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

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 point le serveur de messagerie relayant le message choisira d’utiliser la réponse par rapport au 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:  To:  Subject: Super simple email Reply-To:  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 des rebonds qui utilise un chemin de retour différent). Disons qu’il aura un chemin de retour de [email protected]. La session SMTP peut ressembler à:

 {S}220 workstation1 Microsoft ESMTP MAIL Service {C}HELO workstation1 {S}250 workstation1 Hello [127.0.0.1] {C}MAIL FROM: {S}250 2.1.0 [email protected] OK {C}RCPT TO: {S}250 2.1.5 [email protected] {C}DATA {S}354 Start mail input; end with . {C}From:  To:  Subject: Super simple email Reply-To:  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:  To:  Subject: Super simple email Reply-To:  This is a very simple body. 

Décrivons maintenant les différents “FROM”.

  1. La valeur Return-Path (parfois appelée Reverse-Path ou Envelope-FROM – tous ces termes peuvent être utilisés de manière interchangeable) est la valeur utilisée pendant la session SMTP. Comme vous pouvez le voir, il n’est pas nécessaire que cette valeur soit identique à celle des en-têtes de messagerie. Seul le serveur de messagerie du destinataire est supposé append un en-tête Return-Path au début de l’e-mail. Cela enregistre l’expéditeur du chemin de retour réel au cours de la session SMTP. Si un en-tête Return-Path existe déjà dans le courrier électronique, cet en-tête doit être supprimé et remplacé par le serveur de messagerie du destinataire.

    Tous les rebonds qui se produisent pendant la session SMTP doivent revenir à la valeur Return-Path. Certains serveurs peuvent accepter tout le courrier électronique, puis le mettre en queue localement, jusqu’à ce qu’il dispose d’un thread libre pour le livrer à 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 ne respectent pas cette règle. Certains serveurs de messagerie vont le renvoyer à l’adresse FROM.

  2. L’adresse FROM est la valeur réellement trouvée dans l’en-tête FROM. Ceci est supposé être qui le message est de. C’est ce que vous voyez comme “FROM” dans la plupart des clients de messagerie. Si un e-mail ne possède 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 devraient être adressées. Fondamentalement, lorsque l’utilisateur clique sur “répondre”, la valeur de réponse doit être la valeur utilisée comme destinataire du nouvel e-mail composé. La valeur Reply-To ne doit être utilisée par aucun serveur. Il est destiné à une utilisation côté client.

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

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

Une autre façon de penser à Return-Path vs Reply-To consiste à la comparer au courrier postal.

Lorsque vous envoyez une enveloppe par la poste, vous spécifiez une adresse de retour . Si le destinataire n’existe pas ou refuse votre courrier, le postmaster renvoie l’enveloppe à l’adresse de retour. Pour le courrier électronique, l’ adresse de retour est le Return-Path .

À l’intérieur de l’enveloppe, il peut y avoir une lettre et à l’intérieur de la lettre, il peut indiquer au destinataire «Envoyer une correspondance à l’ adresse exemple ». Pour le courrier électronique, l’ adresse exemple est le Reply-To .

Essentiellement, une adresse de retour d’affranchissement est comparable à l’en Return-Path tête Return-Path SMTP et l’en Reply-To tête Reply-To 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 Reply-To: adresse avec webforms. Lorsque quelqu’un remplit le formulaire, la page Web envoie un courrier électronique automatique au propriétaire de la page. the From: est l’adresse de l’expéditeur automatique du courrier, de sorte que le propriétaire sait qu’il provient du formulaire Web. mais l’adresse « Reply-To: est celle qui a été remplie dans le formulaire par l’utilisateur, de sorte que le propriétaire peut simplement appuyer sur répondre pour les contacter.

J’ai dû append 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 le véritable utilisateur à l’origine de l’action reçoive les e-mails de rebond, car il saura comment (et pas les administrateurs de l’application qui ont d’autres chats à fouetter :-)). Nous l’utilisons et cela fonctionne parfaitement avec exim sur le serveur d’applications et zimbra en tant que serveur de messagerie d’entreprise final.