Postfix : le fichier main.cf
Date de publication: le dimanche 13 mai 2007 Ă 17h16
Dernière modification: par Pascal BOYER le mercredi 26 septembre 2007 à 09h27
« Article précédent: Cyrus IMAP : authentification LDAP
» Article suivant: Postfix : authentification SASL
Remerciements
Pour réaliser cet article qui présente la configuration "détaillée" de Postfix sous Debian/Sid, j’ai eu recours à la lecture du livre Postfix - La réfrence, ed. O’REILLY , aux informations du site de Xavier Guimard ainsi qu’à celles que j’ai trouvées dans la multitude de documents que j’ai lus sur internet.
Mon ambition n’était pas de réinventer la roue mais de faire une documentation aussi claire que possible en ne perdant pas de vue qu’un débutant doit obtenir, in fine, un serveur de mail tout à fait opérationnel.
Ainsi donc, je n’ai eu aucun scrupule à faire du copier/coller de certains sites et passages du livre d’O’REILLY chaque fois que leurs indications me semblaient parfaitement claires et bien expliquées. Et c’est pourquoi, dans le fichier de configuration de Postfix ( main.cf ) les références aux pages du livre sont inscrites entre parenthèses.
Si d’aventure vous reconnaissiez des informations issues de vos documents et que vous souhaitiez que ceci soit clairement spécifié dans cet article, je n’y suis absolument pas opposé et vous pouvez m’envoyer un mail à cette adresse .
Avant propos
Je rappelle que lors de l’installation de Cyrus-IMAP un package postfix est également requis donc installé (voir ici ).
Il n’y a pas d’article sur la fin de l’installation de Postfix pour la simple raison que l’installation de ces 3 packages:
dpkg -l '*postfix*'
Souhait=inconnU/Installé/suppRimé/Purgé/H= garder | tat=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé |/ Err?=(aucune)/H= garder/besoin Réinstallation/X=les deux (état,Err: majuscule=mauvais) ||/ Nom Version Description +++-====================-==========-============================ ii postfix-doc 2.1.5-4 Postfix documentation ii postfix-ldap 2.1.5-4 LDAP map support for Postfix ii postfix-tls 2.1.5-4 TLS and SASL support for Postfix
...ne pose aucune difficulté. Aucune question n’est posée à l’utilisateur.
Il suffit de lancer la commande suivante pour les installer:
apt-get install postfix-doc postfix-ldap postfix-tls
apt-get install postfix-tls
Lecture des listes de paquets... Fait Construction de l'arbre des dépendances... Fait Le paquet postfix-tls est un paquet virtuel fourni par : postfix 2.4.0-2 Vous devez explicitement sélectionner un paquet à installer. E: Aucun paquet ne correspond au paquet postfix-tls
Donc, pour les versions récentes, votre système doit posséder au final les packages suivants:
dpkg -l '*postfix*'
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder | État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé |/ Err?=(aucune)/H=à garder/besoin Réinstallation/X=les deux (État,Err: majuscule=mauvais) ||/ Nom Version Description +++-====================-==========-============================ ii postfix 2.4.0-2 A high-performance mail transport agent ii postfix-doc 2.4.0-2 Postfix documentation ii postfix-ldap 2.4.0-2 LDAP map support for Postfix
Remarquons tout de mĂŞme deux choses:
1°/ La fin du paramétrage de postfix (2.1.5-4) et la création de l’utilisateur postfix :
Adding group `postfix' (105)... Fait. Ajout de l'utilisateur systme postfix... Adding new user `postfix' (105) with group `postfix'. Pas de création de répertoire personnel.
Cet utilisateur postfix appartient Ă ces groupes:
id postfix
uid=105(postfix) gid=105(postfix) groupes=105(postfix)
Mais pour des raisons d’accès à la base de données /ets/ sasldb2 on ajoute l’utilisateur postfix au groupe mail:
addgroup postfix mail
Ajout de l'utilisateur postfix au groupe mail... Fait.
2°/ Lors de l’installation du package postfix-ldap on lit ceci:
Adding ldap map entry to /etc/postfix/dynamicmaps.cf
Conventions d’écritures
- (p42-45) fait référence aux pages 42 à 45 du livre Postfix - La réfrence, ed. O’REILLY
- $mynetworks représente une variable dont la valeur est celle de l’attribut mynetworks
- myorigin peut prendre la valeur " $mydomain " signifie que myorigin = $mydomain est une possibilité
- # mynetworks_style = host indique une règle commentée (# en début de ligne) donc non efficiente
- BAL, Bà L et BL sont les acronymes de Boîte à /aux Lettres.
- La couleur orange est conservée pour signifier les règles qui peuvent être initiées si uniquement le serveur imapd et maintenant smtpd tournent. Ceci constituant un fonctionnement basic du serveur de mails.
- En couleur verte sont indiquées les règles relatives à la mise en oeuvre du protocole SSL/TLS pour Postfix.
Considérations générales sur Postfix
- Postfix est Ă©crit et maintenu par Wietse VENEMA .
- Postfix est sous licence GPL depuis décembre 1998 et IBM Research, qui a sponsorisé la version initiale de Postfix, contribue encore à son développement.
- Postfix est un MTA ( M ail T ransfert A gent/Agent de Tranfert de Mail).
- Postfix implémente le protcole SMTP ( S imple M ail T ransfert P rotocole) mais pas POP/IMAP.
- Postfix est compatible Sendmail.
1/ Les atouts de Postfix
- Fiabilité conservée en situation difficile: ressources mémoire/disque faibles par exemple.
- Postfix prend toujours toutes les mesures nécessaires pour maintenir un fonctionnement fiable et stable.
- Le concept sécuritaire de privilège minimum est omniprésent dans Postfix. Ce qui veut dire que les processus s’excutent avec le minimum de privilèges.
- Postfix prend garde de ne pas submerger, par sa vitesse, les autres sytèmes.
- Postfix (contrairement à Sendmail) repose sur une architecture entièrement modulaire, ce qui constitue la base essentielle de sa sécurité.
- La modularité de Postfix le rend particulièrement simple à configurer même s’il contient tout de même environ 300 paramètres de configuration (ouille... ça fait peur!!!).
- La facilité de configuration de Postfix vient en grande partie du fait que lors de sa conception, W. VENEMA s’est attaché à ne pas trop s’éloigner du sens commun des humains.
- Postfix étant compatible avec Sendmail, il peut aisément le remplacer.
- Postfix reconnait les conventions /etc/aliases et .forward
- Postfix contient un exécutable sendmail reconnaissant quasiment les mêmes paramètres en ligne de commande que la version sendmail de Sendmail.
- Cependant, toutes les fonctionnalités de courrier ne sont pas forcément implémentées de la même manière dans Postfix.
- Postfix permet de configurer des règles de restriction pour la lutte contre le SPAM.
2/ Notions sur le fonctionnement de Postfix (p19)
Comme déjà indiqué ci-dessus, Postfix est basé sur une architecture entièrement modulaire. Ceci implique que chaque tâche est effectuée par un processus spécifique. La plupart de ces programmes sont des démons .
Le premier démon à être lancé est le démon master qui lancera tous les autres démons. Ces autres démons s’exécutent puis se terminent.
A l’inverse, le démon master reste en permanence en mémoire.
Postfix intègre un serveur smtpd ET un client smtp car Postfix sera tantôt serveur tantôt client.
3/ Notions de sécurité sur Postfix (p6-7)
La plupart des processus de Postfix sont lancés par le démon principal master digne de confiance.
Ces processus ne s’exécutent pas en tant que processus fils d’un processus de l’utilisateur et sont donc immunisés contre les problèmes de sécurité liés à l’héritage et aux communications père-fils.
- Les attaques qui utilisent les signaux, la mémoire partagée, les fichiers ouverts et autres types de communication inter-processus n’ont aucun effet sur Postfix.
- Les attaques par débordement de tampon n’ont pas non plus de grands effets sur Postfix dans la mesure ou les processus s’exécutent avec le moins de droits possible et que Postfix utilise des tailles aléatoires de tampon.
- Il est possible de "chrooter" l’exécution des processus de Postfix réduisant ainsi la portée d’une compromission de ses processus.
- Postfix, de par sa conception, ne permet pas aux processus de grossir de façon incontrôlée. Les attaques par DOS sont donc peu nuisibles.
4/ Respect des standards (p13)
Postfix respecte, entre autres, les standards suivants:
- RFC 2821: Description du protocole SMTP.
- RFC 1869: Description des fonctionnalités étendues de SMTP qui devient alors ESMTP. (p17)
- RFC 2822: Description du format des emails.
5/ Quelques commandes d'administration de Postfix: (p45)
Détecter les problèmes de configurations:
postfix check
Afficher les valeurs par défaut des règles de Postfix:
postconf -d
Afficher les valeurs modifiées (qui ne sont plus celles par défaut) des règles:
postconf -n
Afficher les types de tables de recherche supportées:
postconf -m
Afficher la valeur d’une règle:
postconf -h < nom de la règle >
Forcer Postfix Ă vider la file deferred :
postfix flush (quiv. Sendmail: sendmail -q)
Ce qu’il faut savoir
Une adresse mail de la forme roger@www.mondomaine.net (conforme au RFC 2822) est composée de trois parties:
- 1ère partie: la partie locale : roger
- 2ème partie: la partie hôte : www (cette partie est très souvent omise)
- 3ème partie: la composante domaine : mondomaine.net
6/ DEFINITION: adresse d’enveloppe/en-tête de messages:
6.1/ Les en-tĂŞtes de messages: http://www.arobase.org/ecole/entetes-detail.htm
| From: |
|
| Organization: |
|
| To: |
|
| Reply-To: |
|
| Subject: |
|
| Cc: |
( C arbon C opy) |
| Bcc: |
( B lind C arbon C opy) même chose que "Cc:" sauf qu’ici le destinataire principal n’a pas connaissance de la liste des personnes qui reçoivent la copie du courrier. |
| Priority: |
Niveau de priorité du courrier (5 niveaux possibles). |
| Disposition-Notification-To: |
Adresse définie pour la réception de la confirmation de lecture. La présence de ce champ active de ce fait la confirmation de lecture. |
| X-Mailer: |
Logiciel utilisé par l’expéditeur |
| MIME-Version: |
1.0 signifie que le message utilise le protocole MIME et précise la version utilisée. |
| Content-Type: |
Type de contenu MIME présent dans le message (texte simple, texte enrichi, HTML, images, sons, etc...) et jeu de caractères utilisés. |
| Content-Transfer-Encoding: |
Codage utilisé. Valeurs possibles: 7bit (par dfaut), 8bit (binaire mais avec des lignes de taille maxi 998 octets), binary, base64, quoted-printable. |
6.2/ Les adresses d’enveloppes: http://www.arobase.org/ecole/entetes-detail.htm
| Received from... |
Trace ajoutée par un serveur SMTP ayant relayé le courriel. Chaque serveur SMTP rencontré laisse sa ligne Received . La dernière ligne Received correspond au premier serveur ayant relayé le mail. |
| Message-ID: |
Numéro d’identification unique du message. |
| Return-path: |
Adresse de retour en cas d’erreur. |
| Date: |
Date et heure d’envoi. Le dernier chiffre (+0100) correspond au fuseau horaire de l’émetteur: +0100 signifie GMT+1, -0500 signifie GMT-5. |
6.3/ Compte virtuel (p156)
Un compte virtuel est un compte mail (une BL) qui ne correspond Ă aucun compte UNIX sur le serveur Postfix.
I - Configuration de postfix
J’ai cherché à regrouper les règles par catégorie de fonctionnalités.
I.1/ Règles générales:
La règle smtpd_banner (p219) définit le message d’accueil du serveur Postfix:
Exemple de message d’accueil:
La règle mydomain (p41) renseigne le nom de domaine auquel appartient la machine sur laquelle s’exécute Postfix.
$mydomain sera ajoutée à tout champ TO: (champ du destinataire du mail) qui ne comporte que la partie hôte ou que la partie locale.
Par défaut c’est l’agent local de livraison qui recherche les destinataires dans /etc/ passwd et /etc/ aliases . Le serveur SMTP valide les adresses de destination avec $local_recipient_maps et rejette les destinataires inconnus.
La règle myorigin (p42) renseigne la partie réseau de l’adresse d’enveloppe ou d’en-tête des mails qui seront envoyés par Postfix.
Quand myorigin ne vaut pas $mydomain alors elle est de la forme < nom de machine >.< nom de domaine > (www.mondomaine.fr par exemple).
- Considération sur mydomain et myorigin : (p53)
Cependant, si tel est votre souhait, initialisez à "no" les deux règles ci-dessous pour inhiber la réécriture des adresses.
La règle append_at_myorigin (p53,202) initialise ou non (yes/no) la réécriture des adresses en ajoutant à ces adresses:
- en provenance locale:
. $myorigin Ă toute adresse qui ne contiendrait pas de composantes "hĂ´te" ET "domaine".
- en provenance extérieure:
La règle append_dot_mydomain (p53) initialise ou non la réécriture des adresses en ajoutant à ces adresses:
- en provenance locale:
. $mydomain aux adresses qui ne contiendraient pas de composante "domaine".
- en provenance de l’extrieur:
la valeur "@$remote_header_rewrite_domain".
I.2/ Masquage des noms d’hôtes (p54-55,212)
La règle masquerade_domains (p54-55) définit les règles de supression des noms d’hôtes et/ou de sous-domaines dans les adresses d’enveloppe et les en-têtes de message de l’expéditeur (et non du destinataire!!!).
Ici, seuls les mails en provenance du sous-domaine arte.television.fr ne seront pas réduits à @television.fr
Dans le présent fichier, masquerade_domains est redondant à mydomain puisque je n’ai pas de sous-réseaux.
La règle masquerade_classes (p55) permet de masquer les adresses d’enveloppe et d’en-tête également des destinataires.
masquerade_classes accepte la liste suivante: envelope_recipient , envelope_sender , header_recipient , header_sender .
I.3/ Contrôle d’accès pour le relayage (p43)
mynetworks = 127.0.0.0/8 est la valeur par défaut et ne permet pas à Postfix d’être un relais ouvert.
Telle qu’est définie, ci-dessous, la règle, seule ma machine pourra envoyer des mails vers l’extérieur.
Voir "IX - DIRECTIVES RELATIVES A L’AUTHENTIFICATION SASL AU SERVEUR SMTP".
La règle mynetworks_style (p43) ne sert à autoriser l’utilisation du serveur Postfix pour relayer du courrier que pour des hôtes appartenant au réseau de Postfix ou sous-réseaux locaux.
Valeurs possibles:
- class: relayage autorisé pour tous les hôtes de la même classe de réseau que celui de Postfix. Souvent trop permissif ! Risque de fonctionnement en relais ouvert
- subnet: relayage autorisé pour tous les hôtes du même réseau que celui de Postfix. Risque de fonctionnement en relais ouvert
- host: relayage autorisé uniquement à la machine qui héberge Postfix.
La règle relay_domains (p24,106) indique les domaines et sous-domaines vers lesquels Postfix va relayer (faire suivre) le courrier.
Valeur par défaut:
ou, si je souhaite une règle générale:
ainsi, tout mail à destination de AOL sera relayé par le serveur smtpd de Free.
postqueue -f [nom de domaine]
postfix flush
sendmail -q
II - Les tables de recherche
- Les clefs, appelées LHS pour L eft H and S ide, constituent la colonne gauche des tables de recherche. Les clefs sont insensibles à la casse.
- Les valeurs, appelées RHS pour R ight H and S ide, constituent la colonne droite des tables de recherche.
III - Fichiers d’alias - uniquement pour distribution locale !!!
Les fichiers d’alias (ou tables d’alias ou base de données d’alias) sont des tables de recherche particulières car ils ont un format compatible avec Sendmail (p38). Donc des tables d’alias créées avec Sendmail continueront à fonctionner après une migration vers Postfix (p38).
III.1/ RĂ´le des alias
Un alias est un "raccourci" (e.g: roger pour roger@mondomaine.net ) qui sera utilisé, par exemple, dans le champ TO: (champ où l’on indique le destinataire de nos mails). L’alias remplace donc, s’il est correctement défini, l’adresse mail.
C’est l’agent de distribution local qui se sert de cette table de recherche.
Avec la table des alias on peut également créer autant de nom de BL qu'on le souhaite qui toutes pointeront vers une seule, vraiment existante. En effet, il est possible de demander à ce qu’on nous écrive à l’adresse yoyo@linuxorable.fr puisque, si notre table d’alias est bien faite, il y sera incrit ceci:
III.2/ Exemple de table d’alias (p39)
III.3/ Extension des tables d’alias:
III.4/ Format des tables d’alias:
Tout comme pour les tables de recherche, les fichiers/table/base de données d’alias sont construits à partir d’un fichier texte. Mais le format des tables/fichiers/base de données d’alias est différent de celui des tables de recherche. Donc on ne peut pas utiliser la commande postmap pour les construire.
- Les clefs
, appelées LHS (pour L
eft H
and S
ide), constituent la colonne gauche des tables d’alias.
- Les clefs sont insensibles Ă la casse.
- Les clefs d’alias doivent être des adresses locales (au sens "partie locale" d’une adresse mail) et rien d’autre !!! (p40)
- Les valeurs
, appelées RHS (pour R
ight H
and S
ide), constituent la colonne droite des tables d’alias. Les valeurs peuvent être de 4 natures différentes: (p40)
- a/ une adresse locale ou de type RFC 2822
- b/ le chemin complet d’accès à un fichier qui fera office de boîte à lettres locale (format mbox uniquement ???).
- c/ une commande: eg: |/usr/bin/autoreply <== notez le symbole pipe "|"
- d/ :include: pour inclure un fichier contenant une liste de cibles suplémentaires. eg: [:include:/chemin/de/mon/fichier
III.5/ Les commandes de construction:
On utilise soit la commande:
postalias /chemin/du/fichier/aliases
soit la commande de compatibilité Sendmail:
newaliases
La règle alias_maps (p38-39,83-84,118,201) définit le type (hash, NIS, LDAP, etc...) et l’emplacement du fichier texte dont se servira la commande postalias ou newalises pour re/construire le(s) fichier(s) de base de données (.db) d’alias utilisés par l’agent de distribution local .
La règle alias_database (p39,118) définit l’emplacement des fichiers texte dont se servira la commande newaliases pour construire les fichiers base de données d’alias, c’est à dire uniquement les fichiers qui doivent être indexés par la commande newaliases.
La règle default_privs (p40,84) définit les privilèges de Postfix lors de la distribution en local à un alias.
En effet, si un alias pointe vers une BL locale alors Postfix utilise, pour délivrer le courrier, l’identité du propriétaire du fichier base de données d’alias sauf !!! si c’est root qui en est le propriétaire. Auquel cas Postfix utilisera l’identité du compte défini par default_privs .
La règle allow_mail_to_commands (p40-41) définit dans quel cadre Postfix doit délivrer le courrier à une commande.
Par défaut, cette règle autorise la livraison de mails à une commande à partir des tables d’alias et des fichiers .forward mais pas à partir des fichiers inclus (pour raison de sécurité).
Pour tout autoriser, initialiser cette règle à "alias, forward, include".
La règle allow_mail_to_files (p40-41,201) définit dans quel cadre Postfix doit délivrer le courrier à un fichier.
- La configuration par défaut des deux règles ci-dessus correspond au comportement par défaut de Sendmail.
IV - Réécriture et/ou redirection d’adresses
La règle canonical_classes définit les adresses qui seront affectées par la directive canonical_maps . Par défaut cette règle vaut: envelope_sender , envelope_recipient , header_sender , header_recipient et la réécriture canonical_maps est appliquée aux adresses d’expéditeur et de destination de l’enveloppe, et aux adresses d’expéditeur et de destination des en-têtes.
Cette règle est implémentée à partir de la version 2.2.x de Postfix.
La règle sender_canonical_maps (p54) définit la réécriture des adresses d’EXPEDITION (champ FROM: du mail que je vais envoyer) de l’enveloppe et de l’en-tête.
Cette règle peut être utilisée conjointement à la directive canonical_maps mais sera lue avant cette dernière qui sera quand même lue et appliquée! Donc attention aux règles qui s’annulent les unes les autres.
La règle recipient_canonical_maps (p54) définit la réécriture des adresses de RECEPTION (champ TO: du mail que je reçois) de l’enveloppe et de l’en-tête.
Cette règle peut être utilisée conjointement à la directive canonical_maps mais sera lue avant cette dernière qui sera quand même lue et appliquée! Donc attention aux règles qui s’annulent les unes les autres.
Avec cette règle je peux, pour un mail entrant, effectuer une redirection du mail vers N’IMPORTE QUELLE adresse.
La règle canonical_maps (p34,36,39,53,91,93,203) définit quel fichier texte sera utilisé pour construire la table de recherche au format ".db"
V - Directives relatives à la gestion des files d’attente
V.1/ Paramètres généraux:
Le gestionnaire de file d’attente qmgr de Postfix déplace les messages de la file active dans la file deferred chaque fois qu’un seveur SMTP distant reste inaccessible pendant plus de 30s (p60).
La règle queue_directory (p50,59,215) déinit l’emplacement du répertoire racine de la file d’attente de Postfix.
Valeur par défaut:
La règle qmgr_message_active_limit (p215) définit le nombre maximum de messages pouvant être présents dans la file "active".
Valeur par défaut:
La règle qmgr_message_recipient_minimum (p215) définit le nombre minimal de destinataires en mémoire pour chaque message.
Cette règle prend la priorité sur toute limite de destinataire en mémoire (c’est à dire sur qmgr_message_recipient_limit global et sur transport_recipient_limit ) si nécessaire.
La règle queue_file_attribute_count_limit définit le nombre maximum d’attribut (name=value) qui peuvent être stockés dans un fichier de la file d’attente de Postfix. Cette limite est utilisée par le serveur cleanup .
Valeur par défaut:
La règle queue_minfree (p59) définit l’espace libre (en octet) minimum nécessaire (sur le système de fichiers utilisé) pour recevoir le courrier.
Par défaut, le serveur SMTP (Postfix 2.1 et plus) rejette les commandes MAIL FROM lorsque la quantité d’espace libre est inférieure à 1.5 x $message_size_limit .
Valeur par défaut: 0
La règle queue_run_delai (p61,215) définit le délai (en seconde) entre deux LECTURES de la file deferred par qmgr .
Valeur par défaut: 1000s
V.2/ Les messages différés (p60)
Valeur par défaut: 1000s
Valeur par défaut: 4000s
Valeur par défaut: 5d.
VI - Directives relatives à l’envoi des messages
La règle smtpd_sender_login_maps (p159) définit la table de correspondances entre un nom de login SASL et une adresse d’expéditeur (MAIL FROM).
La table sera de la forme:
VII - Directives relatives à la réception des messages
VII.1/ Règles générales
La règle message_size_limit (p52,212) définit la taille maximale autorisée des mails (entrant et sortant).
Valeur par défaut: 10240000 (10Mo)
Par défaut, cette valeur vaut 1000
VII.2/ Gestion des erreurs des clients (p52)
Les erreurs répétées d’un client peuvent signifier une attaque ou tout simplement un client mal configuré.
Une attaque peut être, par exemple, l’envoi de commandes erronées afin de "planter" le serveur Postfix. Pour se prémunir de ce genre de comportements "douteux" (mais qui ne sont peut-être que le résultat d’un client mal configuré) Postfix dispose des 3 règles suivantes:
Valeur par défaut: 1s
La règle smtpd_soft_error_limit (p52,221) définit le nombre d’erreurs (en provenance d’un même client) au delà duquel le délai entre le traitement de deux commandes erronées augmentera à chaque fois.
Comme par défaut cette règle est initialisée à 10, cela veut dire, que jusqu’à la 10ème erreur, entre le traitement de chaque commande erronée, il ne s’écoulait qu’1 seconde. Mais ensuite, le délai entre le traitement de la 11ème et de la 12ème erreur sera de 10x1+1=11 secondes. Entre le traitement de la 12ème et de la 13ème commande erronée il s’écoulera 11+1=12 secondes. Et ainsi de suite...
La règle smtpd_hard_error_limit (p52) définit le nombre maximum de commandes erronées (en provenance d’un même client) au delà duquel Postfix rompt la connexion.
Valeur par défaut: 20
Pour les trois valeurs définies ci-dessus, le comportement sera le suivant:
- De la 1ère la 5ème erreur, entre chacune de ces erreurs, il s’écoule 5 secondes
- Entre la 5ème et la 6ème erreur il s’écoule 5x5+5=30 secondes
- Entre la 6ème et la 7ème erreur il s’écoule 30+5=35 secondes
- Entre la 7ème et la 8ème erreur il s’écoule 35+5=40 secondes
- Entre la 8ème et la 9ème erreur il s’écoule 40+5=45 secondes
- Entre la 9ème et la 10ème erreur il s’écoule 45+5=50 secondes
- Si la prochaine commande est erronée, alors Postfix ferme la connexion. Et ce traitement sera appliqué chaque fois que le client essaiera de se connecter en envoyant des commandes erronées.
VII.3/ Agents de distribution locale (MDA): (LOCAL/LMTP/Cyrus-IMAP/Procmail)
VII.3.1/ L’agent de distribution locale local :
Pour que l’agent local fonctionne il n’y a rien à faire !!!
VII.3.2/ L’agent de distribution locale Procmail:
Procmail est un agent externe (à Postfix) de distribution locale de mails. Procmail constitue en fait la commande que l’agent local utilisera pour délivrer le courrier. La commande est lancée avec les privilèges ID utilisateur et ID du groupe primaire du destinataire.
EXCEPTION: les livraisons pour root sont excutées avec les privilèges définis par la règle: $default_privs .
La règle mailbox_command (p211) permet de définir un agent externe de distribution locale des mails pour distribuer le courrier aux comptes locaux.
Valeur par dfaut: vide
VII.3.3/ L’agent de distribution Cyrus-IMAP:
Postfix intègre un client nommé lmtp qui parle un protocole du même nom, LMTP, et qui est optimisé pour livrer le courrier aux serveurs de BL tels Cyrus-IMAP.
En clair , l’agent de transport local qui est en service, lit la base /etc/aliases (dans notre cas ce sera /etc/postfix/aliases - voir III.5/ alias_maps: ) puis passe le mail à l’agent optionnel (ici ce sera Cyrus-IMAP).
Les deux valeurs ci-dessous (de mailbox_transport ) sont identiques mais la première impose de redéfinir les droits sur le répertoire /var/run/cyrus/socket car j’obtiens les messages suivants ( /var/log/mail.info ) lors de la réception de mes mails:
postfix/lmtp[31145]: 98A9247E4F: to=pascal@linuxorable.net, relay=none, delay=3116, status=deferred (connect to /var/run/cyrus/socket/lmtp[/var/run/cyrus/socket/lmtp]: Permission denied)
...donc, ci-dessous, j’utilise la deuxième valeur.
Valeur par défaut: vide
VIII - Directives relatives Ă la distribution des messages
VIII.1/ Format des BĂ L
VIII.2/ Format mbox/maildir (p81-83)
- Format mbox : il suffit de ne pas mettre de "/" à la fin du chemin passé en valeur à la règle home_mailbox .
- Format maildir : il suffit de mettre un "/" à la fin du chemin passé en valeur à la règle home_mailbox .
VIII.3/ Emplacement des BAL
Par défaut, et sous Debian, c’est dans /var/mail/ que se trouvent les fichiers (format mbox ) au nom de chaque login des utilisateurs (compte UNIX) créé sur le système.
VIII.4/ Règles
La règle mail_spool_directory (p84,211) définit l’emplacement des BL pour la réception des messages.
Valeur par défaut: /var/mail
Valeur par défaut:
IX - Directives relatives à l’authentification SASL au serveur smtp
IX.1/ Authentification auprès du serveur smtpd de Postfix
La règle smtpd_sasl_auth_enable (p159,164) définit si oui ou non (yes/no) le protocole SASL sera utilisé.
IX.1.1/ Authentification par mot de passe UNIX (p157) et site x.guimard
IX.1.1.1/ Le fichier smtpd.conf (p157)
Il faut créer le fichier /usr/lib/sasl2/smtpd.conf et y mettre ceci:
pwcheck_method: pwchek (lui préférer saslauthd dans la mesure du possible)
ou
pwcheck_method: saslauthd (pour version libsasl >= 1.5.26)
IX.1.1.2/ Les règles
Valeur par défaut:
Ensuite il faut lancer le serveur d’authentification saslauthd avec une de ces deux options:
- pour lecture du fichier /etc/passwd : -a getpwent
- pour lecture du fichier /etc/shadow : -a shadow
- pour lecture du fichier /etc/passwd : MECHANISMS="getpwent"
- pour lecture du fichier /etc/shadow : MECHANISMS="shadow"
IX.1.2/ Authentification par PAM
Remember that SASL (and therefore Cyrus) accesses PAM modules through saslauthd, and that SASL can only deal with plaintext passwords if PAM is used.
Mais si l’on souhaite tout de même utiliser PAM, il faut créer le fichier /usr/lib/sasl2/ smtpd.conf et y mettre ceci:
Pour utiliser PAM, initialiser les règles suivantes (ou d’autres encore):
IX.1.3/ Authentification avec la base externe de SASL: /etc/saslbd2 (p158)
Pour savoir si c’est le cas, ulitiser la commande suivante:
sasldblistusers2
test30@euphorie.linuxorable.fr: userPassword test12@euphorie.linuxorable.fr: userPassword
Et ceci doit ĂŞtre identique Ă ce que renvoit cette commande:
postconf -h myhostname
euphorie.linuxorable.net
postfix check
postfix/postfix-script: warning: not owned by root: /var/spool/postfix/etc/sasldb2
250-AUTH GSSAPI NTLM LOGIN PLAIN DIGEST-MD5 CRAM-MD5
IX.1.3.1/ Les règles
La règle smtpd_sasl_local_domain indique le nom de royaume d’authentification de SASL. Ce nom doit être le même que celui renvoyé (en gras) par la commande:
sasldblistusers2
test30@euphorie.linuxorable.fr: userPassword test12@euphorie.linuxorable.fr: userPassword
Cependant, cette règle peut également rester vide.
Par défaut, le serveur smtpd Postfix accepte les mots de passe en clair mais pas les logins anonymes.
250-AUTH GSSAPI NTLM LOGIN PLAIN DIGEST-MD5 CRAM-MD5 lorsque l’on se connecte au serveur SMTP par telnet.
X - Directives relatives au chiffrage TLS/SSL
X.1/ Généralités
- TLS ( T ransport L ayer S ecurity protocol), développé par l’IETF, est la version 3.1 de SSL.
- Transport Layer Security = Protocole de SĂ©curisation de la Couche Transport
- La RFC 3207 (STARTTLS) définit cette extension SMTP. (p167)
- TLS utilise un chiffrement par clef publique. (p169)
X.2/ Clef publique/clef privée
- La clef publique est un certificat signé par une AC ( A utorité de C ertification).
- Ces deux clefs ne servent en fait qu’ à déterminer, en début de session, les identités du client et du serveur et à chiffrer une clef de session choisie au hasard.
- C’est cette clef de session qui servira à chiffrer et signer le reste de l’échange (p169).
X.3/ Connexion TCP chiffrée
- La mise en place d’une connexion TCP chiffrée permet de préserver la confidentialité et l’intégrité des messages.
- La mise en place d’une connexion TCP chiffrée produit une commande: 250-STARTTLS
On a donc l’assurance que les messages n’ont pas été modifiés en cours de route. Ceci garantit également que les messages ne sont pas délivrés à un serveur se faisant passer pour un autre.
Utilisé conjointement à l’authentification SALS, TLS garantit le chiffrage des mots de passe.
On peut ajouter une authentification des clients mail au serveur SMTP par présentation de certificats clients. Cependant, cette méthode a un coût en assistance aux utilisateurs et en temps pour l’émission des certificats clients.
X.4/ TLS au niveau du serveur SMTP
La règle smtpd_use_tls (p171) définit si oui ou non on utilise le chiffrement TLS. (p171)
La règle smtpd_enforce_tls déclare que seules les commandes avec chiffrement TLS seront acceptés.
La règle smtpd_tls_key_file (p171) indique quel fichier contient la clef privée RSA non signée au format .pem du serveur smtpd .
La règle smtpd_tls_cert_file (p171) indique quel fichier contient la clef publique RSA non signée au format .pem du serveur smtpd .
La règle smtpd_tls_CAfile (p172) indique quel fichier contient le certificat de l’AC.
Pour vérifier la clef publique d’un serveur il est nécessaire de disposer du certificat de l’AC.
La règle smtpd_tls_loglevel définit le niveau des messages de log qui seront produits pour l’activité TLS.
Niveaux possibles: 0 (nul) 4 (très verbeux).
X.5/ TLS au niveau du client SMTP
La règle smtp_use_tls (p175) définit si oui ou non on utilise le chiffrement TLS. (p175)
La règle smtp_enforce_tls déclare que seules les commandes avec chiffrement TLS seront acceptées.
Cette règle impose que le nom de machine des serveurs SMTP extérieurs correspondent à l’information de leur certificat et que ce certificat soit issu d’une autorité reconnue par le client SMTP de Postfix. Dans le cas contraire, la livraison est retardée et le message reste en file d’attente.
La règle smtp_tls_key_file (p175) indique quel fichier contient la clef privée RSA non signée au format .pem du client smtp .
La règle smtp_tls_cert_file (p175) indique quel fichier contient la clef publique RSA non signée au format .pem du client smtp .
La règle smtp_tls_CAfile (p175) indique quel fichier contient le certificat de l’AC.
Pour vérifier la clef publique d’un serveur il est nécessaire de disposer du certificat de l’AC.
La règle smtp_tls_loglevel définit le niveau des messages de log qui seront produits pour l’activité TLS.
Niveaux possibles: 0 (nul) 4 (très verbeux).
XI - Directives relatives Ă la lutte anti-spam
XI.1/ Généralités
Cet ordre est induit par le protocole SMTP et l’ordre dans lequel se déroule la communication client/serveur:
- Etablissement de la connexion <==> smtpd_client_restrictions
- Envoi de HELO/EHLO par le client <==> smtpd_helo_restrictions
- Envoi de MAIL FROM: par le client <==> smtpd_sender_restrictions
- Envoi de RCPT TO: par le client <==> smtpd_recipient_restrictions
- Envoi de DATA par le client <==> smtpd_data_restrictions
- Envoi de TO par le client <==> header_checks
- Envoi du corps du texte par le client <==> body_checks
- rencontre l’action OK alors le parcours des restrictions continue jusqu’à la fin ou jusqu’à ce qu’une action REJECT soit rencontrée.
- rencontre l’action REJECT alors le parcours des restrictions est interrompu et la règle correspondante appliquée.
XI.2/ Restrictions sur le client (p132-145)
La règle smtpd_client_restrictions (p133) définit les clients qui ont le droit de faire des connexions SMTP sur le serveur smtpd .
Les restrictions sont appliquées dans l’ordre indiqué, la première restriction qui marche a gagné.
XI.2.1/ Explications
- reject_invalid_hostname => Rejette les requêtes lorsque la syntaxe du nom de machine passée avec HELO ou EHLO est invalide.
- reject_non_fqdn_hostname => Rejette les requêtes lorsque le nom de machine passé avec HELO ou EHLO n’est pas sous la forme pleinement qualifiée, comme requis par la RFC.
- reject_non_fqdn_sender => Rejette la requête lorsque l’adresse MAIL FROM n’est pas sous la forme pleinement qualifiée requise par la RFC.
- reject_unknown_sender_domain => Rejette la requête lorsque l’adresse MAIL FROM n’a pas d’enregistrement DNS A ou MX correspondant et Postfix n’est pas la destination finale de l’adresse d’expédition.
- reject_unknown_recipient_domain => Rejette la requête lorsque l’adresse RCPT TO ne correspond à aucun enregistrement DNS de type A ou MX et que Postfix n’est pas la destination finale de l’adresse de destination.
- permit_mynetworks => Autorise la requête si l’adresse IP du client correspond à l’une des adresses ou l’un des réseaux listé dans $mynetworks.
- reject_unauth_destination => Rejette la requête sauf si l’une des propositions suivantes est vraie:
l’adresse RCPT TO résolue correspond à $relay_domains ou l’un de leurs sous-domaines et ne contient pas de routage expéditeur (user@elsewhere@domain),
l’adresse RCPT TO résolue correspond à $mydestination , $inet_interfaces , $proxy_interfaces , $virtual_alias_domains ou $virtual_mailbox_domains , et ne contient pas de routage expditeur (user@elsewhere@domain).
- permit => Autorise la requête. Cette restriction est pratique à la fin d’une liste de restrictions, pour rendre la politique par défaut explicite.
XI.3/ Règles & Restrictions sur HELO/EHLO
XI.3.1/ Règles
La règle smtpd_helo_required (p145,220) exige que la commande HELO/EHLO du client soit suivie d’une adresse FQN c’est à dire conforme au RFC 821
Valeur par défaut: no
La chaîne en argument de la commande VRFY est un nom d’utilisateur. La réponse à cette commande pouvant inclure le nom complet de cet utilisateur et devant fournir une adresse complètement qualifiée de BL pour cet utilisateur.
Valeur par défaut: no
Voici les logs de /var/log/mail.log lors du rejet d’un mail:
postfix/cleanup[19455]: E235D47E01: message-id=<200501222052.j0MKqLZu010177@mx7.andrew.cmu.edu>
postfix/cleanup[19455]: E235D47E01: reject: mime-error improper use of 8-bit data in message header: From:
OK01???????@andrew.cmu.edu,?????@andrew.cmu.edu, ??? from LISTS2.andrew.cmu.edu[128.2.10.216];
from=<owner-info-cyrus@lists.andrew.cmu.edu> to=<pascal@linuxorable.fr>
postfix/smtpd[19453]: public/cleanup socket: wanted attribute: status
postfix/smtpd[19453]: input attribute name: status
postfix/smtpd[19453]: input attribute value: 8
postfix/smtpd[19453]: public/cleanup socket: wanted attribute: reason
postfix/smtpd[19453]: input attribute name: reason
postfix/smtpd[19453]: input attribute value: improper use of 8-bit data in message header
postfix/smtpd[19453]: public/cleanup socket: wanted attribute: (list terminator)
postfix/smtpd[19453]: input attribute name: (end)
postfix/smtpd[19453]: > LISTS2.andrew.cmu.edu[128.2.10.216]: 550 Error: improper use of 8-bit data in message header
postfix/smtpd[19453]: watchdog_pat: 0x808df78
postfix/smtpd[19453]: < LISTS2.andrew.cmu.edu[128.2.10.216]: QUIT
postfix/smtpd[19453]: > LISTS2.andrew.cmu.edu[128.2.10.216]: 221 Bye
postfix/smtpd[19453]: disconnect from LISTS2.andrew.cmu.edu[128.2.10.216] Valeur par défaut: no
La règle strict_7bit_headers (p221) définit si oui ( no ) ou non ( yes ) l’on souhaite accepter les mails dont les en-têtes comportent du texte codé sur 8 bits, c’est à dire comportant des caractères accentués.
Normalement (c’est à dire en accord avec les RFC 822 et 2822) un client mail doit utiliser Content-Transfer-Encoding: 8bit pour l’encodage des caractères accentués.
Valeur par défaut:no
XII.4/ Restriction sur les en-tĂŞtes
La règle header_checks (p38,146-147,178) définit la liste des restrictions que le serveur SMTP appliquera sur les en-têtes des messages.
Les actions possibles sont: reject , warm , ignore , hold , discard , filter .
Syntaxe du fichier /etc/postfix/header_checks :
- LHS: c’est le motif recherché. Il doit être compris entre deux slash: /mon_motif/
- RHS: c’est l’action associée au motif.
Cette règle accepte les expressions régulières(regexp)
XII.5/ Restrictions sur les fichiers attachés
La règle mime_header_checks (p38,146-147,178) définit la liste des restrictions que le serveur SMTP appliquera sur les en-têtes MIME (???) des messages.
XII.6/ Restriction sur le corps des messages
La syntaxe ci-dessus permet de rejeter tous les mails dont le corps du message contient des commentaires HTML en plein milieu d’un mot (technique utilisée par les spameurs pour déjouer les filtres de contenus).
XII.7/ Restrictions sur les expéditeurs
La règle smtpd_sender_restrictions (p133,145) définit la liste des restrictions que le serveur SMTP appliquera sur les expéditeurs dans le contexte des commandes MAIL FROM.
XII.7.1/ Explications:
- reject_sender_login_mismatch => Rejette la requête lorsque $smtpd_sender_login_maps indique un propriétaire pour l’adresse MAIL FROM, mais que le client n’est pas logué (au sens SASL) avec ce compte ou lorsque le client est logué (SASL) mais que le login utilisé ne possède pas l’adresse MAIL FROM au regard de $smtpd_sender_login_maps .
XII.8/ Restrictions sur les destinataires
La règle smtpd_recipient_restrictions (p133,137,160) définit les restrictions qui s’appliqueront aux requêtes/demandes (effectuées par un client) de connexion au serveur SMTP.
XII.8.1/ Explications:
- permit_mynetworks autorise postfix à relayer les mails... Ce qui n’est pas une mauvaise solution.
- permit_mynetworks signifie que postfix autorise à relayer les mails venant d’adresses IP contenues dans $mynetworks .
- permit_sasl_authenticated autorise la requête lorsque le client est authentifié avec succès via le protocole AUTH.
- reject_unauth_destination rejette la requête sauf si l’une des propositions suivantes est vraie:
l’adresse RCPT TO résolue correspond à $relay_domains ou l’un de leurs sous-domaines et ne contient pas de routage expéditeur (user@elsewhere@domain),
l’adresse RCPT TO résolue correspond à $mydestination , $inet_interfaces , $proxy_interfaces , $virtual_alias_domains , ou $virtual_mailbox_domains , et ne contient pas de routage expéditeur (user@elsewhere@domain).
XII.9/ Restrictions sur les données
La règle smtpd_data_restrictions (p133,219) permet de rejeter la requête lorsque le client envoie des commandes SMTP en dehors des moments où il y est autorisé ou lorsque le client envoie des commandes SMTP avant de savoir que Postfix supporte la canalisation des commandes SMTP (pipelining).
Ceci arrête les messages issus de logiciels mal écrits qui utilisent incorrectement la canalisation des commandes SMTP pour accélérer les livraisons.
L’utilisation de reject_unauth_pipelining dans les autres contextes de restriction n’est pas recommandé.
XIII - Redéfinition des codes erreur renvoyés par Postfix
Cyrus IMAP : authentification LDAP
Postfix : authentification SASL
Commentaires
