Définissez les en-têtes des e-mails afin que les e-mails renvoyés soient envoyés à une adresse spécifique

Question

À partir de notre application Rails, nous envoyons des e-mails générés par le système avec l'adresse "from" définie à [email protected]. Si ces rebonds sont renvoyés à cette adresse par notre serveur de messagerie. Cependant, ce que je voudrais faire, c'est de ne pas renvoyer les e-mails renvoyés à [email protected] mais à une adresse différente, telle que [email protected].

Y a-t-il un en-tête ou quelque chose que je peux définir dans l'e-mail pour y parvenir, sans que je doive aller enquêter sur les caprices de notre serveur de messagerie? Nous envoyons les mails en utilisant exim au cas où cela serait pertinent.

cheers, max

Answer 1

Je viens de comprendre cela moi-même dans exim4 après beaucoup de lecture sur la configuration d'exim.

Tout d'abord, vous souhaitez que votre application ajoute l'en-tête suivant:

Return-Path: <[email protected]>

Fonctionne avec ou sans supports. Exim ajoutera des parenthèses à la fin de toute façon.

Deuxièmement, c'était la partie difficile. Exim a toujours voulu remplacer mon adresse Return-Path: par l'utilisateur Unix qui l'a envoyé. Vous pouvez utiliser/etc/email-addresses dans Ubuntu pour définir un e-mail statique pour l'utilisateur de votre application Web, mais cela ignore toujours l'en-tête Return-Path. Voici comment j'ai modifié ma configuration exim pour respecter le chemin de retour de l'application Web:

Dans la zone de configuration principale, ajoutez:

return_path_remove = false

Dans la configuration de routeur appropriée (par exemple, dnslookup):

dnslookup:
  # ...
  errors_to = ${if def:h_return-path: {${address:$h_return-path:}} fail}
  headers_remove = return-path
  no_more

Exim doit maintenant copier l'adresse d'en-tête Return-Path au niveau de l'enveloppe et supprimer l'en-tête d'origine Return-Path.

J'ai essayé beaucoup d'autres directives de configuration et c'est le seul moyen qui a réellement fonctionné pour moi.

Answer 2

3 ans trop tard, mais juste au cas où quelqu'un d'autre viendrait par là. Return-Path est l'en-tête droit mais, comme James Garriss l'a souligné ci-dessus, il doit y être placé par le site effectuant la livraison finale. Vous ne pouvez pas simplement le coller en vous-même.

Si vous écrivez des e-mails en vous connectant directement à un serveur SMTP, c'est facile - la commande MAIL contient le chemin de retour. Si tu envoies

MAIL FROM:<[email protected]>

sur le serveur SMTP, puis les rebonds seront renvoyés à [email protected].

Si vous ne construisez pas SMTP et que vous exécutez un MTA (ex. Exim/etc), vous devez trouver un commutateur de ligne de commande pour votre MTA. Pour sendmail, -f [email protected] "définit l'adresse de l'expéditeur", ce qui se termine par Return-Path dans le courrier final remis, et [email protected] obtiendra les rebonds (je fais exactement cela pour les e-mails générés automatiquement). Je n'ai pas essayé cela sur exim, mais il a exactement la même option, et cela devrait fonctionner.

Answer 3

Errors-To est déconseillé, donc les serveurs de messagerie ignoreront généralement cet en-tête - la plupart des serveurs rebondiront vers l'expéditeur de l'enveloppe.

Il s'agit de l'adresse e-mail que votre client de messagerie envoie dans le cadre du serveur la connexion au SMTP (pas nécessairement l'adresse de l'expéditeur - bien qu'elle soit généralement la même).

Je ne sais pas Rails tout cela bien, mais j'ai trouvé this - bien que, pour autant que je sache, Return-Path est réinitialisé par les MTA pour correspondre au MAIL À PARTIR des informations du client, il semble donc que vous ne puissiez pas réellement les définir.

Je pense que la seule chose que vous pouvez faire est de définir l'adresse de rebond sur votre serveur.

Answer 4

Voici la solution:

Dans l'en-tête de l'e-mail, vous pouvez définir:

From: "From Name" <[email protected]>
Reply-To: [email protected]

Errors-To: <[email protected]>
Return-Path: <[email protected]>

Answer 5

Return-Path l'en-tête est écrit par le serveur de réception , pas par le serveur d'envoi. Et selon le RFC 5321 , c'est la même chose que l'adresse fournie dans MAIL FROM commande.

Même si vous définissez le Return-Path en-tête vous-même, le serveur de réception le remplacera.

Maintenant, voici le truc, l'adresse dans le MAIL FROM et l'adresse dans l'en-tête From peuvent être différentes. L'utilisateur destinataire ne voit pas le MAIL FROM adresse. Ils ne voient que l'adresse d'en-tête From.

Donc, si vous voulez ignorer les rebonds ou que vous souhaitez qu'ils aillent à une adresse spécifique, vous devez utiliser cette adresse dans le MAIL FROM commande.

Mais dans l'en-tête From, vous pouvez simplement utiliser [email protected] - l'utilisateur verra cette adresse.

---

Pour simplifier un peu plus, vous envoyez l'e-mail de [email protected] adresse. Le serveur récepteur enverra les rebonds à cette adresse.

Pour montrer à votre utilisateur le [email protected] adresse au lieu de handle_bounce... adresse, définissez l'en-tête From dans le message MIME de l'e-mail brut sur noreply... adresse.

---

J'ai récemment reçu un pas de réponse e-mail de Bitbucket. Voici le message brut:

Return-Path: <[e-mail]>
From: "Atlassian Bitbucket" <[email protected]>
To: <[email protected]>
Subject: Continuous delivery, without the headache.
Date: Wed, 28 Feb 2018 12:40:53 -0600
MIME-Version: 1.0
Reply-To: "Atlassian Bitbucket" <[e-mail]>

... message body ...

Comme vous pouvez le voir, le Return-Path est une adresse dédiée au traitement des rebonds. Mais l'adresse From est une noreply@... courrier. Ce que cela signifie, c'est que cet e-mail a été envoyé par cette adresse de gestion des rebonds, et non par l'adresse non écrite.

Vous pouvez également voir le Reply-To en-tête, dédié à la gestion des réponses, si un utilisateur répond aux e-mails sans réponse. Ces réponses sont probablement rejetées immédiatement.