Est-ce une bonne pratique ou trop draconien de rejeter les e-mails des serveurs de messagerie sans RDNS


20

J'ai récemment abandonné SpamAssassin et je base maintenant le rejet du spam sur DNSRBL, la liste grise et d'autres tests de base et je me demande si je devrais également bloquer les hôtes qui n'ont pas de RDNS valide correspondant à l'EHLO?

Si je fais cela, vais-je causer des ennuis avec beaucoup de courrier légitime et déranger mes clients? J'ai entendu des gens insinuer qu'AOL faisait cela, ce qui me fait penser que c'est peut-être trop rare pour moi de le faire.

Je me demande également si je peux faire un compromis en vérifiant que RDNS est au moins réglé sur quelque chose, mais ne pas essayer de le faire correspondre à l'EHLO. Est-ce possible avec Postfix (et est-ce utile)?


4
Oui, cela se fait généralement, même si un très petit nombre de personnes ont des problèmes avec cela. Voir Lutte contre le spam - Que puis-je faire en tant qu'administrateur de messagerie, propriétaire de domaine ou utilisateur? pour une discussion plus approfondie.
Michael Hampton


Il y a plusieurs lunes, la recherche inversée sur une nouvelle installation de sendmail dans Red Hat était la valeur par défaut ... Je pense que rDNS, bien qu'il ne soit pas une norme formelle pour les serveurs de messagerie, est à peu près la norme de facto. Il visse les gens sur des adresses IP dynamiques (c'est-à-dire des maisons avec des connexions ISP de qualité grand public), mais il était une fois, la majeure partie de ces IP dynamiques avec des connexions étaient des botnets ... ne sais pas aujourd'hui.
Avery Payne du

Réponses:


10

J'ai essayé plusieurs approches avec la vérification HELO / EHLO avec une base de clients de taille assez décente entre 100 000 et 200 000 utilisateurs et j'ai finalement opté pour une solution qui fait ce qui suit:

  • Vérifiez que le HELO / EHLO contient un nom de domaine. - Cela se résume principalement à ce que le nom comporte un point. La vérification du DNS sur le nom a conduit à de nombreux serveurs défaillants car il n'est pas rare que le serveur présente un nom interne ou quelque chose que vous ne pouvez pas résoudre correctement.
  • Vérifiez que l'IP a un enregistrement DNS inversé. - Encore une fois, c'est un paramètre laxiste car nous ne le comparons pas au HELO / EHLO. La comparaison avec HELO / EHLO a créé tellement de billets que ce paramètre n'a pas duré même une seule journée.
  • Vérifiez que le nom de domaine de l'expéditeur est valide. - Il s'agit d'une vérification de base pour vous assurer que si nous devons renvoyer le message, il y aura au moins un moyen de trouver un serveur pour celui-ci.

Voici le bloc Postfix que nous utilisons pour ces vérifications:

smtpd_recipient_restrictions =
    reject_non_fqdn_sender,
    reject_unauth_destination,
    reject_unknown_reverse_client_hostname,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    reject_unknown_sender_domain,
    reject_non_fqdn_recipient

1
Une bonne approche supplémentaire consiste également à comparer le nom d'hôte à la liste des expressions rationnelles qui correspondent à divers noms attribués dynamiquement par un FAI comme xxxx.dynamic.yyy.comou 12-34-56-78.dsl.zzz.com. Tous ces hôtes doivent envoyer leur courrier via le relais du FAI et non directement au MX du destinataire. Ces hôtes sont principalement les nœuds de botnet et leurs messages que j'ai utilisés pour apprendre mes bayes.
Kondybas

On dirait que ça pourrait être la solution pour moi. Existe-t-il un moyen d'exécuter SpamAssassin et de le laisser contourner par tous, à l'exception des e-mails qui ne correspondent pas à HELO avec RDNS, alors nous ne faisons rebondir que ceux au-dessus d'un certain score? D'autres courriers continuent de contourner complètement cette étape.
Peter Snow

Avec l'exim MTA que j'ai fait de cette façon, séquentiellement: l'adr / l'expéditeur de l'expéditeur est comparé à la liste blanche. En cas de correspondance - accepté immédiatement, le reste est vérifié par rapport à la liste noire. En cas de correspondance - le drapeau variable est levé "Gotcha!" et le message est également accepté. Si le message a été transmis à travers les listes - il est transmis à la SA qui agit comme démon. Si la valeur renvoyée est suffisamment élevée, indiquez "Gotcha!" soulevé et message également accepté. Ensuite, le message est passé aux routeurs.
Kondybas

1
Si le drapeau n'est pas levé, le message est remis comme d'habitude. Sinon, une copie aveugle est produite. Le message d'origine est remis comme d'habitude, tandis que BC est transmis au routeur spécial qui a sa-learn comme transport. Un tel schéma permet de diviser le flux de messagerie en la branche définitivement spam qui apprend les SA-bayes, et suspecte le reste qui a vérifié par SA-bayes. Les messages avec le drapeau levé ont également un en-tête supplémentaire qui permet de les trier dans le "Junk"
Kondybas

J'ai vérifié ces règles par rapport à ma boîte aux lettres, et il y a des e-mails qui auraient été rejetés en raison d'HELO hors domaine ou de l'absence d'un enregistrement DNS inversé. Certes, il y en a très peu (juste quelques expéditeurs dans une boîte aux lettres avec 40 000 e-mails), mais il y a des choses importantes là-bas. En particulier, si j'avais utilisé reject_unknown_reverse_client_hostname, un e-mail avec les résultats de ma demande de visa pour un pays d'Asie du Sud-Est n'aurait pas été envoyé. Je déconseille d'utiliser reject_invalid_helo_hostnameet reject_unknown_reverse_client_hostname.
michau

12

Il est extrêmement courant de bloquer les serveurs SMTP qui n'ont pas ces bases:

  1. Le nom d'hôte dans HELO forward résout la connexion IP d'origine.
  2. L'IP d'origine des connexions est inversée vers le nom d'hôte revendiqué dans HELO.
  3. Si des stratégies SPF, DKIM ou DMARC existent, vérifiez.

Toute personne se plaignant d'être bloquée à cause de l'un d'eux devrait être goudronnée et à plumes.
Les gens qui finissent par être bloqués pour d'autres raisons, en particulier les situations qui reposent sur la conformité RFC dans des situations "anormales", j'aurai de la sympathie. Le spam est un problème tel qu'il n'y a tout simplement pas d'excuse pour manquer les bases.


2
Il n'est pas nécessaire que le nom recherché inversement corresponde à HELO. L'hôte peut exploiter de nombreux domaines tandis que la recherche inversée ne renvoie qu'un seul nom principal.
Kondybas

1
Bien sûr, vous pouvez faire ce que vous voulez. Votre serveur recevra un 511 Your rDNS doesn't match your HELOde mes serveurs, et beaucoup d'autres également. Le spam est un problème majeur auquel les concepteurs du RFC SMTP n'ont pas eu à faire face. Les exigences réalistes diffèrent nettement des RFC de peu de façons.
Chris S

Le spam n'est pas un problème lorsque le MTA est correctement configuré. Mon expérience montre que (échec du rDNS ORcorrespondant à la courte liste de regex locale ORcorrespondante) détecte 99,99% du spam. Pas de DNSBL, pas de listes grises, pas de DKIM, pas de SPF. 200k + messages entrants par mois. 1-2 faux-p, 10-20 faux-n par mois.
Kondybas

5

Je m'attendrais à ce que l'envoi de MTA ait un RDNS valide, mais insister pour faire correspondre EHLO dépendrait de qui sont les «clients». Vous pouvez trouver des directives intéressantes dans la RFC5321 :

2.3.5.

(...) Le nom de domaine donné dans la commande EHLO DOIT être soit un nom d'hôte principal (un nom de domaine qui se résout en une adresse RR) soit, si l'hôte n'a pas de nom, un littéral d'adresse (...)

4.1.4.

(...) Un serveur SMTP PEUT vérifier que l'argument du nom de domaine dans la commande EHLO correspond bien à l'adresse IP du client. Cependant, si la vérification échoue, le serveur NE DOIT PAS refuser d'accepter un message sur cette base.

mais ensuite en 7.9.

C'est un principe bien établi qu'un serveur SMTP peut refuser d'accepter du courrier pour toute raison opérationnelle ou technique qui a du sens pour le site fournissant le serveur. (...)


1
Ceci est probablement interdit car la chaîne envoyée avec EHLO, dans le monde réel, n'est souvent pas compatible RFC. J'ai vu des noms d'hôtes internes localhostet bien d'autres choses erronées envoyées ici, même avec des courriers parfaitement légitimes.
Michael Hampton

3

La recherche inversée ne pointe pas nécessairement vers le nom d'hôte fourni dans HELO. Parfois, plusieurs domaines sont hébergés sur le même hôte et tous ont la même adresse IP. Mais lorsque vous essayez de faire la recherche inversée, vous obtiendrez le nom qui a été placé dans l'enregistrement PTR. Il est évident que les deux FQDN seront différents - et c'est tout à fait acceptable.

La seule circonstance qui permet de supprimer le message est l'échec de la recherche inversée. Toute recherche réussie signifie que l'hôte est valide. Les noms ne devraient pas correspondre.


1
"Il est évident que les deux FQDN seront différents - et c'est tout à fait acceptable." Non. Vous ne pouvez configurer qu'un seul enregistrement PTR et votre serveur de messagerie ne peut annoncer qu'un seul nom d'hôte dans HELO. Il devrait donc être évident que les deux peuvent correspondre.
Chris S

2

Je me demande si je devrais également bloquer les hôtes qui n'ont pas de RDNS valide correspondant à l'EHLO?

Non, tu ne devrais pas. Bloque tout un e-mail uniquement selon un critère, c'est une mauvaise pratique.

Si je fais cela, vais-je causer des ennuis avec beaucoup de courrier légitime et déranger mes clients?

il est plus probable que vous le fassiez et perdrez du courrier légitime

Je me demande également si je peux faire un compromis en vérifiant que RDNS est au moins réglé sur quelque chose, mais ne pas essayer de le faire correspondre à l'EHLO. Est-ce possible avec Postfix (et est-ce utile)?

oui, c'est possible. Vous pouvez utiliser rejette_unknown_reverse_client_hostname au lieu de rejette_unknown_client_hostname

Malheureusement, postfix n'a pas d'options flexibles pour une "décision complexe". Dans exim, vous pouvez ajouter quelques points pour ces e-mails, par exemple

Score = 0 
1. The HELO or EHLO hostname is not in fully-qualified domain or address literal form. Score +=10
2. The HELO or EHLO hostname has no DNS A or MX record. Score +=20
3. The HELO or EHLO hostname is listed with the A record "d.d.d.d" under rbl_domain. Score +=20
4. The sender domain has no DNS A or MX record. Score +=10
5. SPF checks return softfail. Score +=10, fail, Score +=20
...

Etc. Une fois toutes les vérifications terminées et si vous avez obtenu un score> 100, vous pouvez rejeter le courrier. En fait, vous pouvez obtenir un tel comportement, mais vous devez écrire votre propre service de stratégie

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.