Je voulais savoir comment faire en sorte que mon serveur de messagerie envoie des e-mails au nom des domaines de mes clients, sans être grisé et éviter aussi les problèmes de rebond.
J'ai lu quelques autres questions ici , ici et ici mais aucune n'explore toutes les solutions possibles. Voici quelques possibilités que je voudrais comparer:
UNE.
HELO mymailserver.com
MAIL FROM<[email protected]> # mymailserver.com same IP as myapp.com
DATA
From: <[email protected]>
Sender: <[email protected]>
Question : C'est ce que fait gmail. C'est l'en-tête msg "From:" qui a un domaine différent, pas l'expéditeur d'enveloppe.
emailclients affichera "De: [email protected] via [email protected]" ou
"De: [email protected] Au nom de [email protected]" , ce qui n'est pas un problème pour moi.
Maintenant, cela affectera-t-il gravement la réputation de mon domaine, le fait que l'en-tête "De:" ait un domaine différent? (et si ce n'est pas Google qui le fait ..)
B.
HELO mymailserver.com
MAIL FROM<[email protected]>
DATA
From: <[email protected]>
# same as A, but no "Sender:"
Il semble que Google ait fait cela une fois et l'a appelé une erreur
http://groups.google.com/group/Gmail-Help-Message-Delivery-en/browse_thread/thread/f651cb1db5d9dd23/3a8bcd0548487863?lnk=gst&q=%22on+behalf + de% 22 & pli = 1
Un bogue a supprimé "l'expéditeur:" de leurs messages et le "via" ne s'est pas affiché dans l'e-mail client. (Le RFC dit qu'il DOIT être présent s'il n'est pas le même que le "De:")
C.
HELO mymailserver.com
MAIL FROM<[email protected]>
DATA
From: <[email protected]>
C'est comme si client.com envoyait le message (le MAIL FROM est également "usurpé"). Mais si le domaine client.com est bien connu ou a une entrée SPF dans son DNS, je devrais modifier son DNS, permettant à mymailserver.com d'envoyer un message en leur nom .. (Ceci est impossible pour moi à cause du nb . de clients, et certains de mes clients n'ont pas de contrôle sur leurs domaines, c'est-à-dire qu'ils utilisent eux-mêmes @ gmail.com)
RÉ.
HELO mymailserver.com
MAIL FROM<[email protected]>
DATA
From: <[email protected]>
Reply-to: <[email protected]>
Question : C'est la plus simple, j'ajouterais seulement un en-tête "Répondre à:". Est-ce vraiment pris en compte TOUT LE TEMPS par les clients de messagerie? Cela peut-il également être perçu comme une usurpation d'identité, en ajoutant différents domaines à l'en-tête "Répondre à" et avoir une mauvaise influence sur la réputation de mon domaine?
- Le RFC dit seulement que "si le champ Reply-To existe, alors la réponse DEVRAIT aller aux adresses indiquées dans ce champ et non aux adresses indiquées dans le champ From".
- Seul le libellé d'en-tête "From:" serait "usurpé":
"From: myclient.com (via myapp.com) <[email protected]>".
la source
Réponses:
Excellente question. Je viens de passer plusieurs heures à rechercher la même chose.
J'avais déjà déployé de nombreux sites Web qui utilisent l' option C pour les formulaires de courrier électronique (principalement par naïveté), mais nous rencontrons un nombre croissant de problèmes de livraison. Les fournisseurs de messagerie se resserrent progressivement. Par exemple, Yahoo a récemment modifié sa politique DMARC pour demander aux destinataires de rejeter tous les e-mails
From: [email protected]sans signature DKIM valide . La réception de serveurs SMTP qui suivent DMARC (qui comprend Gmail, et probablement Hotmail / Outlook.com et Yahoo) fera durement rebondir ces messages. eBay et Paypal ont des politiques strictes similaires, je crois, dans le but de réduire le phishing. Malheureusement, spécifier un en-tête "Expéditeur" n'aide pas.(Je me demande comment Gmail contourne ce problème lors de l'envoi de "From" à un alias Yahoo?!)
L'option A serait une meilleure option si vous savez que l'e-mail "De" n'a pas de politique DMARC stricte (vous pouvez éventuellement le confirmer via une simple requête DNS).
Bien qu'elle soit la moins attrayante visuellement, l' option D est vraiment la plus sûre et c'est ce que je recommanderai pour la plupart de nos futurs projets. Il convient de noter que PayPal précédemment utilisé l' option A, mais ont maintenant passé à l' option D .
Pour gagner en crédibilité et augmenter les chances de livraison, je voudrais envisager la mise en œuvre de SPF et / ou DKIM. Ces éléments et d'autres sont mentionnés dans les consignes relatives aux expéditeurs en masse de Google que j'ai trouvé utiles.
la source
Je ne sais pas trop ce que tu veux. Il n'y a aucun moyen «sûr» ou «dangereux» de faire ce que vous voulez.
Je préférerais toujours D). De plus, j'ajouterais des enregistrements SPF. Mais comme je l'ai dit, ce n'est pas plus sûr ou moins sûr que les autres (quoi que vous vouliez dire avec).
L'en-tête Reply-To n'a aucune influence sur la réputation. Il conseille uniquement au client d'utiliser cette adresse pour les réponses (Duh, c'est peut-être de là que vient le nom?!). Si le client suit cette recommandation n'est pas garantie.
la source
Deux solutions fiables:
la source