Postfix Configuration · 13 min read · Nov 14, 2025
Filtre anti-spam Postfix utilisant Ubuntu Dapper, MailScanner, SpamAssassin, Razor, Pyzor, DCC et ClamAV - Page 3
2.3 Paramètres Anti-Spam de Postfix
Notes préliminaires :
Lorsque un client (un ordinateur essayant de nous envoyer un mail) se connecte à Postfix et commence une session de communication, Postfix enregistre des informations sur cette session. Avant le moment où Postfix accepte le mail de cette session pour livraison, nous avons la possibilité d’évaluer la session et de rejeter le mail en définissant certaines restrictions dans main.cf. Ce lien illustre ce qui se passe lors d’une session SMTP typique : http://helpdesk.islandnet.com/pep/smtp.php. Les restrictions ci-dessous aident à repousser certains spams et à empêcher notre système de devenir un relais ouvert. Ces restrictions font que certains mails sont rejetés par Postfix dès la “porte d’entrée”. Cela économisera des ressources système car le mail ne rentrera pas dans notre système et ne sera donc pas scanné par MailScanner (et par la suite par SpamAssassin). C’est à la fois bon et mauvais. Cela économise des ressources système, mais cela ne vous permet pas de voir le mail rejeté. Tout ce que vous verrez, c’est une ou deux entrées de log de Postfix disant essentiellement “Hé, un serveur de mail nommé “xxxxxxxx” à l’adresse IP X.X.X.X a essayé d’envoyer du mail, mais il a enfreint la règle XYZ, donc je l’ai rejeté”. Cela pourrait avoir été du spam (les spammeurs ne suivent souvent pas intentionnellement les RFC pour atteindre leurs objectifs) mais si c’était un mail “légitime”, disons d’un client dont le département informatique a simplement mal configuré son serveur de mail (cela arrive), vous pourriez avoir quelques plumes froissées à gérer.
Si vous souhaitez permettre à TOUS les mails adressés à nous d’entrer par la porte d’entrée, et donc permettre à MailScanner/SpamAssassin de gérer tout le contrôle du spam au sein du système, vous devrez modifier quelques-uns des paramètres ci-dessous. Personnellement, je trouve qu’une combinaison de Postfix et de SpamAssassin pour le contrôle anti-spam est la meilleure. Au minimum, vous devez vous assurer de ne pas désactiver le contrôle anti-relai par défaut intégré dans Postfix ( smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination).
La configuration ci-dessous est en fait très conservatrice, permettant à la plupart des emails d’entrer par la porte d’entrée afin que MailScanner et SpamAssassin aient leur chance. Pour moi, cela (en toute sécurité) rejette environ 35% des emails destinés à mes utilisateurs, donc je pense que ces paramètres sont assez précieux. Je recommande cette approche pour commencer. Ajouter des restrictions supplémentaires augmentera la probabilité de rejeter des emails valides provenant d’ordinateurs mal configurés. Si vous décidez d’ajouter/retirer des permissions/restrictions à l’avenir, faites-le une à la fois et donnez-vous suffisamment de temps pour évaluer l’effet du changement. Je vous suggère fortement d’avoir une bonne compréhension de la façon dont ces restrictions fonctionnent avant de modifier les entrées ci-dessous. Entre autres choses, se tromper sur ces éléments pourrait rejeter des mails légitimes et/ou nous faire devenir un relais ouvert. Notez que les restrictions ne restreignent pas toujours, certaines permettent également.
Si vous souhaitez mieux comprendre ces paramètres, de bonnes ressources sont http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt, http://www.postfix.org/SMTPD_ACCESS_README.html, http://www.securitysage.com/antispam/, le quelque peu daté (2001) http://www.mengwong.com/misc/postfix-uce-guide.txt, et ce livre excellent. Vous remarquerez que j’utilise seulement quelques-uns des mêmes paramètres que ceux-ci, donc cette configuration n’est pas aussi restrictive. Gardez à l’esprit que SpamAssassin et MailScanner entreront en jeu un peu plus tard, et nous fourniront des options beaucoup plus flexibles et configurables pour reconnaître et manipuler le spam.
2.3.1 smtpd_helo_required
Faites en sorte que tout serveur de mail se connectant effectue un “handshake” smtp approprié et annonce son nom. Les RFC Internet l’exigent, donc nous le faisons aussi.
postconf -e "smtpd_helo_required = yes"Préface : Les étapes de restriction de Postfix sont les suivantes, et sont traitées dans l’ordre suivant :
smtpd_client_restrictions
smtpd_helo_restrictions
smtpd_sender_restrictions
smtpd_recipient_restrictions
smtpd_data_restrictionsNous allons seulement placer des entrées dans les trois dernières étapes de restriction. Les étapes de restriction sont traitées dans cet ordre, indépendamment de l’ordre énuméré dans main.cf.
2.3.2 smtpd_sender_restrictions
Cette étape de restriction limite les adresses d’expéditeur que ce système accepte dans les commandes MAIL FROM : (l’expéditeur de l’enveloppe). Nous allons placer trois tests (restrictions) dans cette étape de restriction.
Une étape de restriction contient une liste de restrictions (tests). Typiquement, les tests évaluent à DUNNO, REJECT ou OK. DUNNO signifie “Je ne sais pas quoi faire, laissez le prochain test décider”. REJECT rejette simplement le mail. OK signifie qu’aucun autre test n’est effectué dans cette étape de restriction, les tests continuent avec la prochaine étape (s’il y en a une). Les tests de type Reject* évaluent généralement à REJECT ou DUNNO. Les tests de type Permit évaluent généralement à OK ou DUNNO, et les tests de type check__access peuvent effectuer une variété d’actions. L’illustration montre la logique de base.
Session SMTP
|
V
étape de restriction-------------
test ---------------REJECT->
| \
| DUNNO
| \
| V
| prochain test------REJECT->
| | \
OK OK DUNNO
| | \
| | V
V V
prochaine étape de restriction------->2.3.2.1 check_sender_access
Voir http://www.postfix.org/access.5.html. Ici, nous demandons à Postfix de comparer l’expéditeur de l’enveloppe aux entrées dans une base de données /etc/postfix/sender_access et d’agir sur ces entrées si une correspondance est trouvée. Nous définissons également quelle action est prise là (OK, DUNNO, REJECT, etc.) sur une base expéditeur par expéditeur. Si l’expéditeur n’est pas listé dans le fichier, le test évalue à DUNNO, et le prochain test est effectué. Je fournirai des exemples un peu plus tard. Un usage de ce fichier est de placer une liste d’expéditeurs (adresses email, domaines, adresses réseau, etc.) à partir desquels nous ne souhaitons pas recevoir de mail (les mettre sur liste noire). Nous aurons également la possibilité de mettre des expéditeurs sur liste noire dans MailScanner et SpamAssassin, mais cela économisera des ressources si nous les mettons sur liste noire ici. Nous utiliserons également ce fichier pour permettre à des expéditeurs spécifiques de contourner les deux tests suivants dans cette étape de restriction. Si nous leur donnons un OK ici, aucun autre test n’est effectué dans cette étape de restriction, les tests continuent dans la prochaine étape de restriction ( smtpd_recipient_restrictions). Notez que si nous devions placer ce paramètre dans l’étape de restriction smtpd_recipient_restrictions avant le test reject_unauth_destination, et que nous devions donner à quelqu’un l’OK là, le test reject_unauth_destination situé là serait contourné. Cela serait mauvais car quiconque à qui nous avons donné l’OK pourrait alors utiliser notre serveur comme un relais ouvert. Les restrictions d’accès sont évaluées dans le même ordre que nous les listons, et si une correspondance est trouvée, cela influencera comment (si) d’autres restrictions sont évaluées.
2.3.2.2 reject_non_fqdn_sender
Rejette lorsque l’adresse mail de l’expéditeur de l’enveloppe n’est pas au format approprié. Rappelez-vous, l’”expéditeur de l’enveloppe” est ce que le serveur de mail expéditeur donne dans la ligne “MAIL FROM:” pendant la session SMTP, pas la ligne d’en-tête “From:”. “Joe” n’est pas autorisé à nous envoyer de mail (car nous ne pouvons pas répondre à “Joe”) mais “[email protected]” est au moins une adresse email. Si l’expéditeur n’est pas rejeté à ce stade, ce test évalue à “DUNNO”.
2.3.2.3 reject_unknown_sender_domain
Rejette lorsque la partie domaine de l’adresse mail de l’expéditeur de l’enveloppe n’a pas d’enregistrement DNS “A” ou “MX”. Ce paramètre rejette environ 35% des mails entrant dans mon serveur de mail. Il est courant que les spammeurs utilisent un nom de domaine faux pour ne pas avoir à gérer le retour des mails rejetés. Il est également important pour nous de ne pas remplir notre file d’attente avec des avis de retour qui ne peuvent jamais être livrés en raison du fait que le domaine de l’expéditeur n’existe même pas. Si le domaine de l’expéditeur a un enregistrement “A” ou “MX”, ce test évaluera également à “DUNNO”. Parfois, vous verrez dans un rapport que quelqu’un dont vous souhaitez recevoir le mail a été rejeté par ce paramètre. Une cause possible de cela est lorsque des expéditeurs légitimes utilisent délibérément des noms de domaine faux afin que vous ne leur répondiez pas. C’est là que la liste d’accès des expéditeurs devient utile. Vous pouvez leur donner un OK là, et ce test sera contourné.
Maintenant pour mettre en œuvre ces trois restrictions :
postconf -e "smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/sender_access, reject_non_fqdn_sender, reject_unknown_sender_domain"2.3.3 smtpd_recipient_restrictions
Les restrictions d’accès que le serveur SMTP Postfix applique dans le contexte de la commande RCPT TO : Cela fait référence au “destinataire de l’enveloppe” qui est ce que le client a donné dans la ligne “RCPT TO:” pendant la session SMTP, pas la ligne d’en-tête “To:”. smtpdrecipient_restrictions est une autre étape de restriction qui contient une liste de restrictions spécifiques. D’autres étapes de restriction qui sont évaluées avant smtpd_recipient_restrictions sont smtpd_client_restrictions, smtpd_helo_restrictions et smtpd_sender_restrictions (dans cet ordre). Les restrictions qui iraient normalement dans ces étapes de restriction précédentes peuvent alternativement être placées dans smtpd_recipient_restrictions. Par conséquent, certaines personnes préfèrent placer toutes les smtpd*_restrictions qui iraient normalement dans les étapes de restriction précédentes dans smtpd_recipient_restrictions (dans le bon ordre) et laisser les étapes précédentes non configurées (vides). Dans notre cas, il est plus sûr d’utiliser smtpd_sender_restrictions et smtpd_recipient_restrictions. Examinons ces restrictions spécifiques (tests) que nous plaçons dans smtpd_recipient_restrictions :
2.3.3.1 permit_mynetworks
Permet aux machines listées dans “mynetworks” de sauter le reste des tests dans cette étape de restriction (permit = OK). En d’autres termes, cela sort de cette étape et est testé dans la prochaine étape (smtpd_data_restrictions). Parce que permit_mynetworks est placé devant reject_unauth_destination, cela signifie que les machines dans $mynetworks sont autorisées à relayer des mails vers n’importe quel domaine. Sans cela, nous ne pourrions envoyer des mails qu’à nos propres domaines. Si l’adresse IP de l’expéditeur n’est pas listée dans $mynetworks, le test évalue à “DUNNO” et continue au test suivant (reject_unauth_destination).
2.3.3.2 reject_unauth_destination
Ceci, avec permit_mynetworks, est utilisé pour le contrôle de relais. Ce paramètre, en essence, signifie que les mails destinés à n’importe quel domaine pour lequel nous n’avons pas configuré notre machine pour accepter des mails seront rejetés. Dans notre cas, Postfix utilisera le paramètre relay_domains (ou table) que nous avons configuré plus tôt pour déterminer quels domaines sont concernés. Voir http://www.postfix.org/postconf.5.html#reject_unauth_destination pour des détails supplémentaires. Si le domaine est listé dans relay_domains, ce test évalue à “DUNNO” et la session est autorisée à continuer au test suivant (s’il y en a un). Tout comme “mynetworks”, ce paramètre est extrêmement critique. En plaçant permit_mynetworks directement devant reject_unauth_destination, nous sommes assurés que nous pouvons envoyer des mails à des domaines autres que les nôtres, mais nous n’accepterons que des mails adressés à nous provenant d’ordinateurs en dehors de notre réseau, ainsi permit_mynetworks et reject_unauth_destination fonctionnent en équipe.
2.3.3.3 reject_unauth_pipelining
Rejette les expéditeurs en masse qui tentent d’utiliser le pipelining pour accélérer la livraison, sans vérifier si cela est pris en charge au préalable (non-RFC, courant parmi les spammeurs).
Maintenant pour mettre en œuvre ces trois restrictions :
postconf -e "smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unauth_pipelining"2.3.4 smtpd_data_restrictions
Restrictions d’accès optionnelles que le serveur SMTP Postfix applique dans le contexte de la commande SMTP DATA : Comme smtpd_recipient_restrictions, c’est une étape de restriction.
2.3.4.1 reject_unauth_pipelining
Je répète ce paramètre dans smtpd_data_restrictions car il n’est pas toujours efficace lorsqu’il est placé dans smtpd_recipient_restrictions. Je l’inclus dans smtpd_recipient_restrictions car j’aime le placer avant tout serveur de politique. Notez qu’il n’y a que quelques restrictions qui font bon usage de smtpd_data_restrictions.
postconf -e "smtpd_data_restrictions = reject_unauth_pipelining"2.3.5 Fichiers de contrôle de filtrage de contenu Postfix :
http://www.postfix.org/header_checks.5.html - /etc/postfix/header_checks et /etc/postfix/body_checks
Ces fichiers listeront certaines “chaînes” de texte, et diront à Postfix quoi faire avec les mails s’il rencontre ces chaînes dans les en-têtes d’email ou le corps du message. Des fichiers d’exemple sont déjà créés pour nous, avec des commentaires expliquant quoi mettre dedans. Vous pouvez les modifier à votre convenance. Notez que ces fichiers nécessitent l’utilisation du “format d’expression régulière”. “regexp” est quelque chose que vous voudrez apprendre pour vivre dans le monde *nix. Obtenez un livre ou recherchez-le sur le Net un de ces jours. Pour un exemple d’un fichier header_checks élaboré d’une personne avec une attitude, jetez un œil à http://www.geekounet.org/filters/header_checks. Mais ne suivez pas aveuglément cela, c’est juste un exemple ! Voici un exemple d’un fichier body_checks : http://www.securitysage.com/files/body_checks. Il vaudrait la peine de consulter http://www.securitysage.com/guides/postfix_uce.html lorsque vous avez un moment de loisir. Plus précisément http://www.securitysage.com/antispam/hedchek.html et http://www.securitysage.com/antispam/bodchek.html. Je recommande de ne pas apporter un grand nombre de modifications à une partie de Postfix sans vous donner suffisamment de temps pour évaluer les effets. Comme une tortue, allez lentement, vivez longtemps.
2.3.5.1 header_checks & body_checks
Allons-y et mettons ces deux dans main.cf. header_checks est requis car il nous permet de retenir tous les emails entrants afin que MailScanner puisse faire son travail :
postconf -e "header_checks = pcre:/etc/postfix/header_checks"
postconf -e "body_checks = pcre:/etc/postfix/body_checks"Éditez header_checks :
vi /etc/postfix/header_checksAjoutez cette ligne au fichier header_checks, sans elle MailScanner ne fonctionnera pas :
/^Received:/ HOLDNotez que nous n’avons pas besoin de postmap pour les tables de type pcre. Elles restent en texte brut et Postfix les utilise “telles quelles”.
Vous pourriez également configurer mime_header_checks et nested_header_checks avec header_checks et body_checks. Si vous devenez trop créatif avec le filtrage de contenu dans Postfix (en utilisant header_checks et body_checks), cela peut avoir un impact significatif sur les performances.
2.3.5.2 /etc/postfix/sender_access http://www.postfix.org/access.5.html
Nous avons référencé ce fichier dans smtpd_sender_restrictions. Nous utilisons ce fichier pour vérifier l’expéditeur dès la porte d’entrée. Dans ce fichier, nous listerons certains expéditeurs/domaines/plages d’adresses IP pour un traitement spécial. Ci-dessous se trouvent des exemples fictifs, créez les vôtres comme bon vous semble. Veuillez lire /etc/postfix/sender_access pour plus d’informations. Bien que vous puissiez utiliser ce fichier à diverses fins, compte tenu de la façon dont nous l’avons configuré dans smtpd_sender_restrictions, je suggère de l’utiliser pour soit mettre des expéditeurs sur liste noire, soit permettre à certains expéditeurs de contourner les tests restants dans smtpd_sender_restrictions.
vi /etc/postfix/sender_access#Exemple de fichier de carte d'accès des expéditeurs
[email protected] 550 Pas de MLM merci
allspam.tld 550 Le spam n'est pas accepté ici
badguy.net REJECT
[email protected] REJECT
newsletter-favorite-lug.org OK
my-really-l337-test-domain.com OKPuisque c’est une table de hachage, vous devez la postmapper comme d’habitude :
postmap /etc/postfix/sender_access2.3.6 Dernière vue sur l’installation de Postfix
Revoyez les changements :
less /etc/postfix/main.cfVérifiez le contenu du fichier pour des erreurs et réparez si nécessaire. Lancez Postfix :
postfix startVérifiez que Postfix répond :
telnet 127.0.0.1 25Vous devriez voir :
220 [yourFQDNhere] ESMTP Postfix (Ubuntu)appuyez sur [enter] quelques fois ; puis tapez quit pour sortir.
S’il ne répond pas de cette manière, ouvrez une autre fenêtre de terminal et arrêtez Postfix postfix stop. Assurez-vous d’avoir exécuté newaliases et toutes les commandes postmap ci-dessus. Vérifiez tous les paramètres dans main.cf et master.cf. Il y a un bon document sur le dépannage de Postfix à http://www.postfix-book.com/debugging.html mais gardez à l’esprit que notre système n’est pas prêt à relayer des mails à ce stade (ils finiront dans la file d’attente).
Chaque fois que vous apportez des modifications à master.cf ou main.cf ou aux tables de données, la plupart du temps (pas toujours), il est nécessaire de recharger Postfix avec :
postfix reloadMaintenant que nous avons une configuration de base de Postfix, http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall et http://www.postfix.org/BASIC_CONFIGURATION_README.html sont de bons endroits pour mieux comprendre certains des paramètres que nous avons utilisés et à ce stade ces README auront plus de sens.
Par défaut, notre Postfix fonctionne en chroot. Si vous ne savez pas ce que cela signifie, cela n’aura pas beaucoup d’importance à ce stade. Je vous laisse le soin de rechercher ce que signifie chroot à un moment ultérieur. Certains des fichiers système dont Postfix a besoin pour fonctionner correctement ont été copiés dans la prison chroot de Postfix ( /var/spool/postfix) lors de l’installation. Parfois, les fichiers originaux seront modifiés, et Postfix se plaindra que la copie qu’il a n’est pas la même que l’original. Lorsque cela se produit, vous pouvez manuellement copier le(s) fichier(s) dont Postfix s’est plaint dans la prison chroot, ou nous pouvons simplement exécuter un script fourni avec le code source de Postfix (appelé LINUX2) qui copiera à nouveau tous les fichiers dont Postfix a besoin à l’endroit où il en a besoin.
cd /usr/local/src/postfix-2.3.3/examples/chroot-setup
postfix start
chmod +x LINUX2
cp LINUX2 /usr/bin
LINUX2
cd
postfix checkCela rend le script LINUX2 exécutable, le copie dans un répertoire de notre chemin, puis l’exécute. LINUX2 résoudra généralement tous les problèmes ou soucis avec Postfix si vous voyez des erreurs dans les journaux concernant l’accès de Postfix aux fichiers de configuration ou aux répertoires.
Recevez de nouveaux articles dans votre boîte de réception.
Aucun spam. Désabonnez-vous à tout moment.