Postfix throw_unknown_reverse_client_hostname: remplacez default_client_reject_code (450) par 550 par défaut. Pourquoi / quand je ne devrais pas?

Dans la bataille quotidienne contre le SPAM, il y a eu plusieurs fois où j'ai été tenté d'appliquer fortement les exigences DNS des clients se connectant à partir d'Internet sauvage.

En détail, j'aurais ajouté le paramètre throw_unknown_reverse_client_hostname dans ma section smtpd_client_restrictions , comme dans:

smtpd_client_restrictions = 
            permit_sasl_authenticated
            check_client_access hash:/etc/postfix/access 
            check_policy_service inet:127.0.0.1:4466
            reject_unknown_reverse_client_hostname
            reject_unauth_pipelining 

Quoi qu'il en soit, j'ai remarqué qu'en frappant une telle restriction, le comportement de Postfix est assez "doux" car la valeur par défaut pour le unknown_client_reject_code450 est. Par conséquent, le client est invité à continuer de réessayer.

En recherchant une réponse 550, j'ai rencontré la déclaration suivante, sur la documentation officielle de Postfix :

Je ne suis absolument pas un expert de l'ensemble de la RFC 5321 , mais en tant que personne assez âgée pour connaître la RFC 821 , je ne vois vraiment pas pourquoi, une réponse 550 au lieu de 450, pourrait avoir un impact sur mon instance Postfix au niveau SMTP maximum ( briser la conformité RFC), d'autant plus qu'en cas d'erreurs temporaires, Postfix s'en tiendra à un 450 quel que soit le réglage explicite.

Alors, quelqu'un peut-il m'aider à comprendre quel est le problème avec un tel remplacement?

PS: en attendant, je termine avec une restriction "détendue":

smtpd_client_restrictions = 
            permit_sasl_authenticated
            check_client_access hash:/etc/postfix/access 
            check_policy_service inet:127.0.0.1:4466
            warn_if_reject reject_unknown_reverse_client_hostname
            reject_non_fqdn_helo_hostname
            reject_unauth_pipelining 
            reject_invalid_helo_hostname 

Je vais commencer par deux réponses pratiques

1. La première et la plus évidente réponse est que dans le cas où il y a une erreur DNS temporaire, un rebond temporaire permettra au serveur de messagerie de l'expéditeur de réessayer jusqu'à ce que l'erreur DNS soit corrigée. Dans ce cas, un rebond permanent empêchera le courrier de jambon réel de vous atteindre.

2. La deuxième réponse est que beaucoup de spams sont envoyés via des boîtes de botnet qui n'ont aucune forme de programmes fonctionnels réels pour envoyer le courrier. Ils pulvériseront leur courrier indésirable une seule fois et n'essaieront pas de renvoyer des messages, que ce message reçoive une erreur temporaire ou permanente. Donc, en utilisant une erreur temporaire, vous bloquez définitivement un grand pourcentage du spam, mais vous autorisez toujours le jambon à réessayer. (Soit dit en passant, c'est pourquoi la liste grise fonctionne toujours et attrape toujours beaucoup de spam.)

En plus de ceux-ci, il y a aussi une réponse qui porte plus sur la théorie et le RFC

Le RFC dit dans la section 4.2.1. cette:

Une règle générale pour déterminer si une réponse entre dans la catégorie 4yz ou 5yz (voir ci-dessous) est que les réponses sont 4yz si elles peuvent réussir si elles sont répétées sans aucun changement dans le formulaire de commande ou dans les propriétés de l'expéditeur ou du destinataire (c'est-à-dire , la commande est répétée à l'identique et le récepteur ne met pas en place une nouvelle implémentation).

Dans le cas d'un échec de recherche inversée, il serait possible que le message soit acceptable sans aucune modification dans le message lui-même, à condition que l'erreur DNS soit corrigée. Par conséquent, cela devrait être une erreur temporaire.

Dans le cas où le message n'est pas du spam, le serveur de messagerie émetteur sysadmin peut remarquer le message d'erreur et résoudre le problème DNS, afin que le message puisse être remis sans que l'utilisateur n'ait à intervenir et à renvoyer le message. Et à moins que l'utilisateur qui envoie l'e-mail soit également en charge du serveur de messagerie et / ou de ses entrées DNS, même s'il obtient directement un rebond permanent, il ne pourra rien faire avec - contrairement par exemple au cas d'une faute d'orthographe adresse.

Bien sûr, vous êtes toujours en droit de refuser tout e-mail pour quelque raison que ce soit.