Est-ce que quelqu'un connaît des études effectuées pour montrer combien d'e-mails seront rejetés s'il n'y a pas d'enregistrement ptr pour le nom de bannière SMTP d'un serveur de messagerie?
Les vérifications inversées sont-elles toujours effectuées lorsqu'elles sont activées, ou sont-elles parfois configurées, donc si un programme de spam considère un e-mail comme "incertain", la vérification inversée est-elle effectuée?
Réponses:
J'essaierais autant que possible d'avoir la recherche inversée pour l'adresse IP de mon serveur de messagerie résoudre le nom qu'il utilise dans les conversations SMTP. Ça rend la vie plus facile.
Je n'ai aucune preuve statistique pour étayer cela, mais d'après mon expérience, de temps en temps, des messages seront rejetés par certains expéditeurs à distance pour ne pas avoir de recherche inversée correspondant au nom d'hôte utilisé dans les conversations SMTP. Plutôt que d'avoir à résoudre ce problème, il est tout simplement plus facile de commencer par la configuration de la recherche inversée. Au cours des dernières années, je viens de considérer que la recherche cohérente avant / arrière est une exigence, de sorte que je n'ai pas à faire face au problème de ne pas l'avoir.
Si vous ne l'avez pas configuré, vous recevrez un e-mail légitime signalé. Il appartient au dispositif de filtrage des spams de déterminer comment ils effectuent leurs vérifications et il n'y a pas de normes claires définies, donc c'est aléatoire. Mais dans la plupart des cas, avec un score de spam, ils ignoreront vos e-mails lorsque vous n'avez pas de recherche directe et inverse correspondante. Ce message en lui-même n'obtiendra souvent pas les blocs de messagerie (mais aucune promesse), mais une autre légère préoccupation dans le courrier électronique peut l'emporter.
Nous n'avions pas l'habitude d'avoir un enregistrement PTR spécifique pour notre serveur de messagerie et nous recevions des rebonds de craigslist.org et de certains de nos partenaires commerciaux.
Vous devez également avoir un enregistrement A spécifique pour votre entrée MX. Aucun * ou CNAMES n'est autorisé pour certains serveurs de messagerie stricts.
Lorsque vous dites "nom de bannière", c'est quelque peu trompeur. La bannière est le nom du côté serveur, qui est le côté qui décide de ce qui doit être rejeté. :) Je pense que vous voulez dire le nom que le côté expéditeur donne dans la commande HELO / EHLO?
La plupart des endroits font juste des vérifications de syntaxe et rejettent les HELO / EHLO manifestement mauvais, car il y a trop de déchets brisés. Mais si vous utilisez un serveur de messagerie légitime, vous devez simplement donner le nom d'hôte public de votre propre serveur de messagerie dans le HELO que vous envoyez. Il y en a qui vérifient. Et comme ce nom d'hôte doit avoir un DNS inversé fonctionnel, pour que votre connexion TCP ne soit pas immédiatement rejetée par de nombreux MTA, vous devez en effet avoir un DNS inversé fonctionnel pour le nom donné.
Il n'y a donc aucune difficulté de configuration à obtenir un DNS fonctionnel pour le nom d'hôte HELO au-delà du tri du DNS inverse pour une accessibilité générale de toute façon.
Comme l'a dit Evan, votre meilleur pari est de faire en sorte que votre entrée PTR soit renvoyée à l'adresse IP de votre serveur.
Cependant, si pour une raison quelconque, cela n'est pas possible, le PTR devrait suggérer que vous utilisez une adresse IP allouée statiquement, et non une ligne DSL domestique (non professionnelle). Dans le cadre de leur stratégie anti-spam, de nombreuses organisations utilisent des services de réputation (par exemple, SORBS), qui surveillent les plages d'adresses IP pour l'activité de botnet et maintiennent des listes noires de plages IP. Cependant, peu importe l'activité suspecte ou non, ils incluent généralement leurs listes d'utilisateurs dynamiques (DUL) dans leur liste noire. Pour créer ces DUL, ils utilisent des enregistrements PTR et des expressions régulières, spécialement adaptés aux schémas de dénomination de nombreux grands FAI.
Par exemple, un PTR comme cable-66-103-40-69.clarenville.dyn.personainc.netserait très probablement automatiquement mis sur liste noire (il correspond à "dyn", il doit donc être dynamique). Il y a quelques efforts de normalisation sur la dénomination DNS inversée dans l'IETF, avec un succès mitigé:
http://tools.ietf.org/html/draft-msullivan-dnsop-generic-naming-schemes
http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations
Légèrement hors sujet, les enregistrements SWIP WHOIS sont une autre source d'informations pour les listes noires / blanches .