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


162

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

FROM: marketing@customer.com
TO: subscriber1@domain1.com
Return-PATH: bouncemgmt@ourcompany.com

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 (marketing@customer.com) à 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.


1
Qu'en est-il de la spécification des champs Sender: et Precedence:? J'aimerais en savoir plus sur la façon dont ils affectent les différents serveurs de messagerie en ce qui concerne les rebonds et les réponses automatiques de type hors bureau. N'importe qui?
PapaFreud

Réponses:


257

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

From: <coolstuff@mymailinglist.com>
To: <you@yourcompany.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.com>

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 coolstuff-you=yourcompany.com@mymailinglist.com. 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:<coolstuff-you=yourcompany.com@mymailinglist.com>
{S}250 2.1.0 me@mycompany.com....Sender OK
{C}RCPT TO:<you@yourcompany.com>
{S}250 2.1.5 you@yourcompany.com 
{C}DATA
{S}354 Start mail input; end with <CRLF>.<CRLF>
{C}From: <coolstuff@mymailinglist.com>
To: <you@yourcompany.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.com>

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: coolstuff-you=yourcompany.com@mymailinglist.com
From: <coolstuff@mymailinglist.com>
To: <you@yourcompany.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.com>

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.

  1. 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.

  2. 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.


C'est très utile. Merci pour votre temps. Une question. Se pourrait-il que certains rebonds soient dirigés vers la réponse au lieu du chemin de retour?
Geo

5
eh bien, techniquement, vous pouvez (mais vous n'êtes pas censé le faire) ajouter un en-tête de chemin de retour, cependant, si un en-tête de chemin de retour existe, il doit être écrasé par le serveur smtp récepteur. S'il n'en existe aucun, il doit être ajouté en haut des en-têtes.
dave wanta

7
Je ne sais pas trop comment return-pathest utilisé. Si return-pathest censée être une adresse de retour, pourquoi le serveur de messagerie du destinataire remplit-il ce champ à la place de l'expéditeur? Comment le serveur du destinataire pourrait-il savoir quoi mettre là-dedans? Cela ne semble-t-il pas à l'envers?
greatwolf

6
Le serveur de messagerie du destinataire insère l'en-tête Return-Path dans le message en copiant la valeur fournie par le serveur de messagerie de l'expéditeur dans la commande SMTP "MAIL FROM". Imaginez un employé de la salle du courrier qui ouvre le courrier - il regarde l'adresse de retour sur l'enveloppe et l'écrit en haut de la lettre (et jette l'enveloppe).
John Hascall

5
Et comment l'en- Sender:tête s'intègre-t-il dans tout cela?
Simon East le

150

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.


14
C'est une belle analogie.
Lukasz Korzybski

2
@Jesse Hobart +1 pour une belle explication, j'étais plus confus, merci de m'avoir permis de mieux me comprendre.
Abhishek

26
Je tiens à souligner que le concept principal non capturé dans cette analogie est que l'en- Return-Pathtête est ajouté par le serveur de messagerie récepteur et non par l'expéditeur . Donc c'est plus comme ça: vous pouvez écrire l'adresse que vous voulez à l'intérieur de l'enveloppe, mais pour la livrer, vous devez l'emmener au bureau de poste et leur montrer votre permis de conduire (ou autre pièce d'identité) et ils mettent cette adresse sur l'enveloppe avant de l'envoyer. En d'autres termes, l'en- Return-Pathtête est aussi fiable que les contrôles effectués par le serveur SMTP de réception, où les autres peuvent être facilement usurpés.
cdhowie

5

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.


1

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: admin@yourcompany.com 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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.