Quelle est la meilleure méthode pour envoyer des e-mails au nom des domaines de mes clients?

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<do-not-reply@myapp.com>  # mymailserver.com same IP as myapp.com
DATA
  From: <res@client.com>
  Sender: <do-not-reply@myapp.com>

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: res@client.com via do-not-reply@myapp.com" ou "De: do-not-reply@myapp.com Au nom de res@client.com" , 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<do-not-reply@myapp.com>
DATA
   From: <res@client.com>
   # 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<res@client.com>
DATA 
  From: <res@client.com>

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<do-not-reply@myapp.com>
DATA 
  From: <do-not-reply@myapp.com>
  Reply-to: <res@myclient.com>

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) <do-not-reply@myapp.com>".

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: ____@yahoo.comsans 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.

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.

Deux solutions fiables:

1. demander aux clients d'ajouter votre serveur de messagerie dans leur enregistrement de domaine SPF
2. demandez aux clients de vous fournir les informations d'identification d'un compte de messagerie (leur adresse IP de serveur de messagerie, leur nom d'utilisateur, leur mot de passe) et utilisez-les dans votre application pour vous connecter à leur serveur de messagerie et envoyer des e-mails (vous créez en fait un client de messagerie dans votre application).