Postfix RBL : blocage par postscreen_dnsbl_sites ou smtpd_recipient_restrictions?

Support Debian
#1

Hello,

Comme tout postadmin, j’utilise RBL pour bloquer le plus gros des déchets qui circulent, mais je vois encore des choses, très peu, arriver.

A la base, dans mon setup j’avais choisi d’utiliser le blocage par Postscreen, pour éliminer l’essentiel avant de commencer tout traitement dans postfix lui même (l’intérêt, donc, de postscreen) et économiser ainsi en CPU, en utilisant des règles comme celles-ci :

postscreen_access_list                  = permit_mynetworks, cidr:/etc/postfix/postscreen_access.cidr
postscreen_blacklist_action             = drop
postscreen_dnsbl_sites                  =
        zen.spamhaus.org*3
        dbl.spamhaus.org
        bl.spamcop.net*2
        cbl.abuseat.org
        dnsbl-1.uceprotect.net
        multi.uribl.com

Mais aujourd’hui, je me demande si je ne peux pas quand même coupler ça avec smtpd_recipient_restrictions, pour traiter ce qui serait éventuellement quand même passer. J’ai donc bricolé les règles suivantes :

smtpd_recipient_restrictions =
     permit_mynetworks,
     permit_sasl_authenticated,

     reject_rhsbl_helo zen.spamhaus.org,
     reject_rhsbl_helo dbl.spamhaus.org,
     reject_rhsbl_helo rbl.realtimeblacklist.com,

     reject_rhsbl_reverse_client zen.spamhaus.org,
     reject_rhsbl_reverse_client rbl.realtimeblacklist.com,
     reject_rhsbl_reverse_client dbl.spamhaus.org,

     reject_rhsbl_sender zen.spamhaus.org,
     reject_rhsbl_sender rbl.realtimeblacklist.com,
     reject_rhsbl_sender dbl.spamhaus.org,

     reject_rbl_client zen.spamhaus.org,
     reject_rbl_client rbl.realtimeblacklist.com,
    # reject_rbl_client dbl.spamhaus.org ==> faux positif avec gmail

     reject_non_fqdn_recipient,
     reject_unauth_destination,
     reject_unknown_recipient_domain

Que pensez-vous de l’utilisation des deux ? Mieux vaut utiliser plus l’un que l’autre (dans mon esprit, Postscreen seul est sensé être plus efficace) ? Peut-on optimiser ce setup ?

#2

Bonjour,

smtpd_recipient_restrictions c’est pour filtrer sur le destinataire (RCPT TO) comme son l’indique. Ce que tu proposes n’a pas de sens.

Si tu veux filtrer les accès avec des listes noires il faut utiliser smtpd_client_restrictions, exemple :

smtpd_client_restrictions = permit_sasl_authenticated,
                            permit_mynetworks,
                            reject_rbl_client sbl.spamhaus.org,
                            reject_rbl_client bl.spamcop.net,
                            reject_rbl_client cbl.abuseat.org,
…
#3

En fait, j’utilise smtpd_recipient_restrictions plutôt que smtpd_client_restrictions pour choper un max d’info sur le client avant de le rejeter. Alors ça augmente les traitements, mais en parallèle, on a pas un traitement plus fin ?

/edit : J’ai trouvé une explication plus complète :

Note that all of the restrictions are in the recipient section because we like to have as much information as possible before rejecting an email. If you were to reject at smtpd_client_restrictions, then you would not be able to determine the helo, sender, and recipient information, which could help improve the filters.
All of the anti-UCE checks are under smtpd_recipient_restrictions , instead of having a separate smtpd_client_restrictions . This is because, unless you have set smtpd_delay_reject = no (default is « yes »), no rejecting takes place until after RCPT TO anyway. It’s easier, cleaner and more predictable when all of the anti-UCE stuff is under recipient restrictions.

#4

Je ne suis pas du tout d’accord avec cette affirmation. Merci d’indiquer ta source.
C’est plus facile, beaucoup plus clair et bien plus prévisible de mettre les restrictions dans les filtres qui sont prévus pour.
Mettre une restriction sur le helo ou le sender dans un filtre sur le recipient pour moi cela n’as pas de sens. Ce n’est pas logique et c’est le bordel dans la configuration, même si c’est considéré comme valide par la documentation de postfix.

Et puisque les restrictions sont appliquées après le RCPT TO, autant les ranger correctement, de manière lisible et logique. Et le jour où on veut utiliser `smtpd_delay_reject = no , on a pas toute la configuration à refaire.

Sinon oui il est utile de mettre un autre filtrage en aval de postscreen car certaines machines peuvent passer quand même en fonction du seuil et des coefficients appliqués.

1 J'aime
#5

Voici l’article originel : https://www.akadia.com/services/postfix_uce.html

Vos deux points de vue sont intéressants, ce serait bien de creuser la question, car initialement (avant que je mette en place postscreen pour les RBL, mes blocages étaient, comme toi, dans smtpd_client_restrictions)

#6

C’est un choix d’administration.
Au niveau fonctionnel, je pense que cela ne change rien.

#7

Si l’un comme l’autre se valent quant au résultat, que penses-tu en revanche d’utiliser conjointement cela avec Postscreen comme je le fais là via postscreen_dnsbl_sites ?

#8

À voir si tu utilises les mêmes DNSBL ou si tu en ajoutes d’autres.