meilleure technique
pour ne pas inonder un serveur de messagerie
pas beaucoup que vous pouvez faire à ce sujet au-delà de la vérification avec l'administrateur de votre serveur de messagerie (si elle est un compte d'hébergement partagé/pas dans votre contrôle). mais si l'exigence est d'un courriel à un seul destinataire par événement, cela ne devrait pas poser trop de problèmes. les choses qui tendent à obstruer les systèmes de messagerie sont des emails avec des centaines (ou plus) de destinataires.
Si vous avez des événements se déclenchant tout le temps, pensez à les consolider et à envoyer un e-mail qui les résume périodiquement.
envoyer des messages comme si d'un utilisateur spécifique, mais encore clairement de votre application (pour assurer des plaintes, etc revenir à vous) sans casser la bonne étiquette e-mail
vous pouvez accomplir cela en utilisant le " Reply-To "en-tête, qui aura alors les clients utilisent cette adresse au lieu de l'adresse De lors de la composition d'un message électronique.
Vous devez également définir l'en-tête "Return-Path" de tout e-mail, car les e-mails ne seront souvent pas filtrés.
ex.
From: [email protected]
Return-Path: [email protected]
Reply-To: [email protected]
configuration et l'utilisation émetteur-id, les clés de domaine, SPF, reverse-dns, etc pour vous assurer que vos e-mails sont correctement identifiés
cela est fortement dépendante de la quantité de propriété vous avez de votre courrier et des serveurs DNS. spf/sender-id etc ... sont tous des problèmes DNS, vous devez donc avoir accès au DNS. Dans votre exemple, cela pourrait poser un problème. Comme vous définissez le courrier à partir d'un utilisateur spécifique, cet utilisateur doit avoir un SPF (par exemple) défini dans son DNS pour autoriser votre serveur de messagerie en tant qu'expéditeur valide. vous pouvez imaginer comment désordonné (sinon carrément impossible) cela arriverait avec un certain nombre d'utilisateurs avec différents noms de domaine. En ce qui concerne DNS inverse et autres, cela dépend vraiment. la plupart des ISP clients, etc ... vont simplement vérifier que le DNS inverse est activé. (c.-à-d. que 1.2.3.4 résout d'héberger.here.domain.com, même si host.here.domain.com ne résout pas en 1.2.3.4). cela est dû à la quantité d'hébergement partagé là-bas (où les serveurs de messagerie se signaleront souvent comme le nom de domaine du client, et non le vrai serveur de messagerie).
Il existe quelques réseaux rigoureux qui nécessitent un DNS inverse correspondant, mais cela nécessite que vous ayez le contrôle sur le serveur de messagerie s'il ne correspond pas en premier lieu. Si vous pouvez être un peu plus précis, je peux vous donner un peu plus de conseils, mais en général, pour les personnes qui ont besoin d'envoyer un courrier d'application, et qui n'ont pas un tas de contrôle sur leur environnement, je ne sais pas. d suggérer les éléments suivants:
- assurez-vous de définir un « Return-Path »
- il est bon d'ajouter votre application et les informations de l'abus et les en-têtes à savoir: « X-Mailer » et « X-Abuse- À "(il s'agit d'en-têtes personnalisés, à titre purement informatif)
- Assurez-vous que DNS inversé est défini pour l'adresse IP de votre serveur de messagerie sortant
oh tout cela et plus sur http://www.alandoherty.net/info/mailservers/ –