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

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)?

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

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.

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. (...)

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.

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