Comment fonctionne une recherche DNS inversée en ce qui concerne les filtres anti-spam?

8

J'ai entendu dire que la plupart des filtres anti-spam utilisent une recherche DNS inversée sur l'adresse IP d'origine du serveur SMTP d'envoi (ou quelque chose comme ça) dans le cadre du processus de vérification. Je veux m'assurer que mes e-mails réussiront cette vérification. Comment puis-je vérifier que mes e-mails sont corrects?

En le recherchant, j'ai remarqué que si je regarde l'en-tête d'un e-mail valide provenant de Gmail, je verrai quelque chose comme ceci:

Received: from mail-pz0-f185.google.com (mail-pz0-f185.google.com [209.85.222.185])
        by mx.google.com with ESMTP id 10si2346996pxi.164.2009.07.22.22.26.19;
        Wed, 22 Jul 2009 22:26:19 -0700 (PDT)

Lorsque je fais un nslookup sur 209.85.222.18, il répond par mail-pz0-f185.google.com, ce à quoi je m'attendrais. S'il a répondu avec un domaine différent, je suppose que cela indiquerait un problème et que la vérification échouerait.

Est-ce à cela que sert la recherche DNS inversée ou suis-je en train d'aboyer le mauvais arbre?

codeflunky
la source

Réponses:

6

Le test ne se compare pas normalement à l'enveloppe SMTP (comme vous le décrivez comme votre processus basé sur le globe oculaire), mais trouve le nom d'hôte DNS inverse de l'hôte de connexion (le cas échéant), l'exécute via le DNS direct et voit s'il est résolu en le numéro IP d'origine.

Donc, ce dont vous avez besoin est 1) d'avoir une configuration DNS inversée (pour la première étape) et 2) de la configurer correctement (pour la deuxième étape).

Rien n'empêche quiconque de comparer avec l'enveloppe SMTP également, même si cela est souvent considéré comme trop paranoïaque, vous voudrez donc également que votre nom d'hôte apparaisse dans votre transmission de courrier électronique pour utiliser le nom DNS qui apparaît dans votre DNS inversé.

le chaos
la source
4

Exactement. Vous vérifiez si le serveur de messagerie qui vient de vous parler ne prétend pas être quelqu'un d'autre en corrélant la requête DNS directe (l'enregistrement A du domaine) avec la requête inverse (l'enregistrement PTR de l'adresse IP).

S'ils correspondent, bravo. S'ils ne le font pas, sifflez.

Bien entendu, cela implique que tout serveur avec plusieurs noms d'hôte sur son adresse IP doit simplement utiliser l'adresse spécifiée dans le PTR lors de l'envoi de mails.

Towo
la source
1

L'enregistrement DNS inversé doit exister, mais je ne pense pas qu'il soit trop particulier à propos du nom d'hôte - tant que le domaine correspond.

Nous SNAT toutes nos communications sortantes de sorte que tout provient d'une seule adresse IP . Nous avons également tous les enregistrements de nos serveurs de messagerie configurés en DNS inversé, mais je pense qu'il répond simplement de manière circulaire, donc il n'y a aucune garantie quel enregistrement hôte il obtiendra.

Néanmoins, cette configuration fonctionne bien.

Brent
la source
Je pense que vous avez peut-être raison de ne pas être trop précis sur le nom d'hôte. Pendant un certain temps, j'ai exploité un serveur de messagerie qui s'est identifié comme mail.example.com même si le RDNS pour l'adresse IP est allé à www.example.com. Je n'ai jamais eu de problème pour envoyer du courrier vers Gmail.
David Z
1

Vous avez raison de déclarer qu'une requête DNS inversée ne vérifie pas le nom d'hôte du serveur SMTP. Cependant, il est important de noter que certains serveurs de messagerie vérifient réellement cela. Mon dernier emploi était dans une société d'hébergement d'échange et nous rencontrions parfois des problèmes à cause de cela. En tant que destinataire du courrier, il convient de noter dans cette discussion que le verso de cette équation devient également populaire maintenant - les enregistrements SFP. Fondamentalement, un enregistrement SPF couvre le nom d'hôte / l'adresse IP du serveur SMTP en indiquant les serveurs autorisés à envoyer des messages en tant que votre domaine. Si un serveur usurpé tente d'envoyer le destinataire refusera le message car il provient d'une adresse IP incorrecte.

Charles
la source