Comment envoyer des emails propres depuis votre application?

Question

Lors du développement d'une application qui envoie des e-mails de notification, quelles sont les meilleures pratiques pour

1. votre hébergeur ne vous a pas signalé comme spammeur. (Couvrir l'un des :)
   • meilleure technique pour ne pas saturer un serveur de messagerie
   • meilleurs produits de serveur de messagerie, si vous deviez créer votre propre
   • envoyer des messages comme s’ils provenaient d’un utilisateur spécifique, mais toujours clairement à partir de votre application (pour que les plaintes nous parviennent, etc.) sans enfreindre la bonne étiquette de courrier électronique
   • les autres leçons apprises
2. le client du destinataire ne marque pas le spam? (Couvrir l'un des :)
   • configurer et utiliser id-expéditeur, clés-de-domaine, SPF, reverse-dns, etc. pour vous assurer que vos courriels sont bien identifiés
   • Les meilleures techniques d'en-tête SMTP pour éviter d'être signalé comme spam lors de l'envoi d'e-mails aux utilisateurs (par exemple, en utilisant les en-têtes d'expéditeur et d'expéditeur ensemble)
   • les autres leçons apprises

Une exigence supplémentaire: cette application enverrait un seul message à un seul destinataire en fonction d'un événement. Donc, les techniques pour envoyer les mêmes messages à plusieurs destinataires ne seront pas appliquées.

Answer 1

  

meilleure technique pour ne pas saturer un serveur de messagerie

vous ne pouvez pas faire grand-chose à ce sujet en plus de vérifier auprès de votre administrateur de serveur de messagerie (s’il s’agit d’un compte d’hébergement partagé / non sous votre contrôle). mais si l'exigence est un e-mail à un seul destinataire par événement, cela ne devrait pas poser trop de problème. les choses qui ont tendance à obstruer les systèmes de messagerie sont les emails avec des centaines (ou plus) de destinataires.

Si des événements se déclenchent tout le temps, envisagez peut-être de les consolider et d'envoyer un courrier électronique les résumant périodiquement.

  

envoyer des messages comme s'ils provenaient d'un utilisateur spécifique, mais toujours clairement à partir de votre application (afin de garantir le retour des plaintes, etc.) sans enfreindre la bonne étiquette de messagerie

vous pouvez y parvenir en utilisant le lien "Répondre à". En-tête, qui demandera aux clients d’utiliser cette adresse au lieu de l’adresse De lorsqu’un message électronique est en cours de composition.

vous devez également définir le " Return-Path " l'en-tête de n'importe quel email, car les emails sans cela seront souvent filtrés.

ex.

From: me@me.com
Return-Path: me@me.com
Reply-To: auto@myapp.com

  

configurer et utiliser id-expéditeur, clés-de-domaine, SPF, reverse-dns, etc. pour vous assurer que vos courriels sont bien identifiés

Tout dépend fortement de la propriété de vos serveurs de messagerie et DNS. spf / sender-id etc ... sont tous des problèmes de DNS. Vous devez donc avoir accès au DNS.

dans votre exemple, cela pourrait poser tout le problème. lorsque vous définissez le courrier comme provenant d'un utilisateur spécifique, cet utilisateur doit avoir SPF (par exemple) défini dans son DNS pour autoriser votre serveur de messagerie en tant qu'expéditeur valide. vous pouvez imaginer à quel point cela serait désordonné (si ce n’était carrément impossible) avec un certain nombre d’utilisateurs possédant différents noms de domaine.

comme pour le DNS inversé et autres, cela dépend vraiment. la plupart des clients des fournisseurs de services Internet, etc ... vérifieront simplement que le reverse DNS est défini. (Par exemple, 1.2.3.4 se résout en host.here.domain.com, même si host.here.domain.com ne se résout pas en 1.2.3.4). ceci est dû à la quantité d’hébergement partagé disponible (les serveurs de messagerie se signalant souvent comme étant le nom de domaine du client, et non le serveur de messagerie réel).

il existe quelques réseaux rigoureux qui nécessitent une correspondance inverse du DNS, mais pour ce faire, vous devez contrôler le serveur de messagerie s'il ne correspond pas.

si vous pouvez être un peu plus précis, je pourrais peut-être fournir un peu plus de conseils, mais en général, pour les personnes qui ont besoin d'envoyer un courrier de candidature et qui n'ont pas beaucoup de contrôle sur leur environnement, je le ferais. suggère ce qui suit:

• assurez-vous de définir un "quotient de retour"
• il est agréable d’ajouter vos informations d’utilisation abusive et d’application dans les en-têtes, par exemple: "X-Mailer". et " X-Abuse-To " (ce sont des en-têtes personnalisés, à des fins d'information uniquement)
• assurez-vous que le reverse DNS est défini pour l'adresse IP de votre serveur de courrier sortant

Answer 2

d'abord une correction rapide à la précédente

return-path: est un en-tête ajouté par le système de réception basé sur l'expéditeur de l'enveloppe du message entrant

pour que spf fonctionne, le chemin de retour / l'expéditeur de l'enveloppe doit être yourapp@votredomaine.com

et assurez-vous que l'enregistrement spf de votredomaine.com {ou si spf par utilisateur} pour votredomaine@votredomaine.com autorise l'envoi d'e-mails sur le serveur qui héberge l'application / envoie l'e-mail

cet expéditeur-enveloppe est l'adresse qui recevra tous les rebonds / erreurs

maintenant, l'expéditeur-id est complètement différent et le from: adresse {stockée dans le message} si envoi à partir de: hisname yourapp@votredomaine.com répondre à: son nom hisaddres@hisdomain.com

ce sera un non-problème si envoi à partir de: hisname hisaddres@hisdomain.com

ce sera et vous devez ajouter un Renvoyer-De: hisname yourapp@votredomaine.com car this spécifie d'ignorer le nom de l'expéditeur: pour les vérifications de l'identifiant de l'expéditeur, utilisez plutôt ceci car il vous a été envoyé en son nom

Answer 3

maintenant pour les autres bits qui valent la peine

Les adresses IP mentionnées sont vos serveurs de messagerie

a demandez à votre adresse IP de pointer vers un nom qui renvoie également à la même adresse IP FQDNS

b avez votre serveur helo / ehlo avec le paramètre domain.domain.com, où domain.com est identique au domaine du nom indiqué à l'étape A {pas le même nom que celui indiqué ci-dessous}

c ce que helo / ehlo nom_serveur doit également être résolu en adresse IP de votre serveur

d ajoutez l'enregistrement spf suivant à ce nom helo / ehlo "v = spf1 a -all" {signification autoriser helo / ehlo avec ce nom parmi les ip ce nom ne pointe que}}

e ajoutez les lignes id-expéditeur suivantes au nom helo / ehlo {uniquement pour compléter "spf2.0 / mfrom, pra -all" {c'est-à-dire qu'il n'y a pas d'utilisateurs @ this-domain}

f ajoutez le SPF suivant au nom de FQDNS et à tout autre nom d’hôte pour votre serveur "v = spf1 -all" {c'est-à-dire qu'aucune machine n'hélo / ehlo sous ce nom et aucun utilisateur @ this-domain}

{comme le nom fqdns peut être déterminé par les bots / infections, il vaut mieux ne jamais permettre que ce nom soit utilisé dans les salutations helo / ehlo, il suffit qu’il soit du même domaine que l’identité helo / ehlo pour prouver la validité des deux}