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.

La quantité de documents que j’ai lus est telle que je ne pouvais tous les citer chaque fois que j’y "empruntais" des informations.
Je ne cite donc que mes deux plus importantes sources d’informations: le site de Xavier Guimard et le livre d’O’REILLY. Je ne saurais d’ailleurs trop vous en recommander la lecture. Ils me semblent un point de passage obligé pour une compréhension approfondie de Postfix.

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

:
Dans les versions récentes de Postfix, il n'existe plus de package postfix-tls car, à présent, ses fonctionnalités sont directement incluses et fournies par le package de base postfix. Pour vous en convaincre:

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 (Mail Transfert Agent/Agent de Tranfert de Mail).
• Postfix implémente le protcole SMTP (Simple Mail Transfert Protocole) 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.

Le démon master, qui est lancé au démarrage de Postfix, lit sa configuration à partir du fichier /etc/postfix/master.cf

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:	(Carbon Copy)
Bcc:	(Blind Carbon Copy) 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.

:
D’autres en-têtes peuvent être présents. Ne serait-ce que parce que chacun est libre de créer des champs étendus, commençant par la chaine de caractères "X-".
Par convention, les en-têtes X- ne sont pas standards et s’affichent uniquement à titre indicatif.

:
Les en-têtes des messages sont pratiquement tous falsifiables !!! (Vive le Spam) Donc seules les adresses d’enveloppes sont dignes de foi.
Et seul le premier Recivied: from est digne de confiance !!! Les autres sont falsifiables...

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:

~$ telnet linuxorable.net 25
Trying 82.67.66.131...
Connected to mutualite-3-82-67-66-131.fbx.proxad.net.
Escape character is ’^]’.
220 euphorie.linuxorable.net ESMTP Postfix (Debian/GNU)

$myhostname est le minimum exigé par la RFC 1869.
Dans la ligne ci-dessous, $myhostname et $mail_name font référence aux valeurs des règles myhostname et mail_name

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)

La règle myhostname (p30,41) renseigne le nom de la machine sur laquelle s’exécute (est installé) Postfix.
myhostname est liée à mydomain.
Le nom doit être pleinement qualifié !!! Si ce n’est pas le cas, Postfix prendra la valeur renvoyée par la fonction "gethostname" (p41).

myhostname = euphorie.linuxorable.net

La règle mail_name définit le nom du système de messagerie du serveur. "Salade" fera très bien l’affaire. Tout comme "Lego", "Pull over" et que sais-je encore...
Valeur par défaut:

mail_name = Postfix

La règle mydomain (p41) renseigne le nom de domaine auquel appartient la machine sur laquelle s’exécute Postfix.

mydomain est liée à myhostname.
mydomain est liée à append_dot_mydomain
mydomain est liée à masquerade_domains

$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.

Ainsi, toute adresse de destination de type roger@www ou simplement roger sera automatiquement traduite en roger@www.mondomaine.net ou en roger@mondomaine.net

mydomain = linuxorable.fr

La règle mydestination (p42) énumère tous les domaines pour lesquels le serveur Postfix acceptera les mails afin de les distribuer en local.
"distribuer en local" signifie: livrer les mails à tous les utilisateurs ayant un compte UNIX ou un compte virtuel (c’est à dire simplement une BàL) sur une machine qui appartient à l’un des domaines de la liste de la règle mydestination.
A la place de $mydomain on peut bien sûr mettre le nom de domaine en toute lettre !

:
Afin d’éviter des boucles de distribution du courrier, il faut énumérer tous les noms d’hôtes du serveur, incluant $myhostname, et localhost.$mydomain.

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.

mydestination = $myhostname, www.$mydomain, $mydomain, localhost.$mydomain

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.

myorigin est liée à append_at_myorigin

Dans un mail, le champ FROM: contiendra donc xxxx@$myorigin si cette composante domaine n’est pas renseignée par l’utilisateur.
myorigin peut prendre la valeur "$mydomain" si on ne souhaite pas voir apparaitre le nom de la machine après le "@" du champ FROM:
Ce qui donne par exemple:

roger@mondomaine.net au lieu de roger@www.mondomaine.net

Quand myorigin ne vaut pas $mydomain alors elle est de la forme < nom de machine >.< nom de domaine > (www.mondomaine.fr par exemple).

myorigin = $mydomain

• Considération sur mydomain et myorigin: (p53)

Nombre de SPAMEURS envoient des mails avec des adresses incomplètes (on parle ici du champ FROM:) qui seront donc réécrites par ces deux règles. Il est donc tentant de ne pas initialiser ces deux directives pour reconnaitre facilement de telles adresses annonçant du SPAM.
MAIS Postfix complète/réécrit les adresses des mails entrant ET sortant.
Donc si vous ne souhaitez pas complèter les adresses des mails entrant ALORS les adresses des mails sortant ne seront pas non plus correctement réécrites. OR nombre d’applications attendent des mails répondant au format RFC 2822 et c’est donc aller au devant de problèmes de rejet de vos mails que d’accepter qu’ils comportent des adresses incomplètes.

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:

@$remote_header_rewrite_domain

append_at_myorigin est liée à myorigin
Valeur par défaut:

append_at_myorigin = yes

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".

append_dot_mydomain est liée à mydomain
Dans le présent fichier, myorigin valant "$mydomain" il y a redondance entre append_at_myorigin et

append_dot_mydomain = yes

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

Cette règle accepte les listes.
Exemple: arte.television.fr, fr2.television.fr, fr3.television.fr, television.fr

Ici, une adresse de type xxx@achat.arte.television.fr deviendra xxx@arte.television.fr
Idem pour tous les sous-domaines de fr2 et fr3.television.fr
Tous les mails qui ne proviennent pas d’un de ces 3 sous-domaines (arte, fr2 et fr3) seront réduits à xxx@television.fr

Cette règle accepte les regexp (expressions régilières).
Exemple: !arte.television.fr, television.fr

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.

masquerade_domains = linuxorable.fr

La règle masquerade_exceptions (p55) définit les comptes pour lesquels ne s’appliqueront pas les règles de la directive masquerad_domains.
Les adresses de ces utilisateurs resteront donc intactes.

#masquerade_exceptions = user1, user2, user3

La règle masquerade_classes (p55) permet de masquer les adresses d’enveloppe et d’en-tête également des destinataires.

:
Si un mail est destiné à un utilisateur d’un sous-domaine et que son adresse est tronquée/masquée alors Postfix ne saura pas à qui destiner le courrier !!!!!
En effet, si au départ j’envoie un courrier à roger@arte.television.fr et que Postfix masque son adresse en roger@television.fr alors ensuite la livraison du mail devient impossible.

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)

:
Les deux règles (mynetworks et mynetworks_style) sont importantes car, mal configurées, Postfix risque fort de remplir le rôle de "relais ouvert", c’est à dire d’être exploitable par n’importe qui pour en faire un point de relais de mails. N’importe qui veut dire AUSSI les SPAMEURS!!!
Si Postfix se retrouve dans ce "mauvais rôle" il est fort probable que très vite votre serveur se retrouve sur les listes noires des DNSBL/RBL et que les mails de vos utilisateurs soient alors refusés par tous les serveurs mail de vos destinataires !!!

mynetworks = 127.0.0.0/8 est la valeur par défaut et ne permet pas à Postfix d’être un relais ouvert.

La règle mynetworks (p43) énumère les réseaux ou adresses des machines qui peuvent utiliser le serveur postfix pour envoyer/relayer du courrier vers l’extérieur.
Ce paramètre permet donc (au contraire de mynetworks_style) d’autoriser AUSSI des réseaux ou sous-réseaux qui ne dépendent pas de celui auquel appartient la machine sur laquelle est installé Postfix à envoyer du courrier par le biais du serveur Postfix.
La notation réseau/masque est autorisée: xxx.xxx.xxx.0/24 127.0.0.0/8

:
Quand mynetworks est paramétré, alors mynetworks_style est ignoré.

:
Pas de virgule entre deux entrées !!!

Telle qu’est définie, ci-dessous, la règle, seule ma machine pourra envoyer des mails vers l’extérieur.

Avantage d’un webmail:
En effet, le fait d’utiliser un webmail (i.e: IMP ou Squirrelmail) a un impact sur la configuration de la règle mynetworks et donc sur l’administration de Postfix.
Lorsqu’on utilise un webmail, la seule adresse IP qu’il faut renseigner (en plus de 127.0.0.1) est l’adresse IP de la machine sur laquelle s’exécute le webmail (la plupart du temps installé sur le même serveur que celui qui abrite Postfix).
Ceci est du au fait qu’avec l’utilisation d’un webmail, c’est ce dernier qui envoie les mails à Postfix. Quelque soit le lieu (ou la machine) à partir duquel on est logué au serveur webmail.
Donc, pour Postfix, tous les mails proviennent de la même machine: celle qui fait tourner le serveur webmail.
Par contre, avec des clients mail nomades, la donne est sensiblement différente car la connexion au serveur SMTP s’effectue directement à partir de la machine cliente. Et si cette machine est un portable connecté à internet depuis un hôtel, l’adresse IP du portable est inconnue de Postfix.
Il résulte de ceci qu’il devient alors obligatoire de renseigner toutes les adresses IP des machines nomades. Ce qui est aberrant voire impossible.
Il devient alors nécessaire d’utiliser l’authentification SASL.

On voit donc que l’utilisation d’un webmail rend l’administration du serveur de mail beaucoup plus simple et moins restrictive.
Revers de la médaille: avec un webmail il est impossible de mettre en oeuvre une politique d’authentification des clients par présentation de certificat client en raison des limitations de la librairie c-client qui ne supporte pas la fonction "passer un certificat client au serveur"

Voir "IX - DIRECTIVES RELATIVES A L’AUTHENTIFICATION SASL AU SERVEUR SMTP".

mynetworks = 82.67.66.131 127.0.0.1

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.

#mynetworks_style = host

La règle relay_domains (p24,106) indique les domaines et sous-domaines vers lesquels Postfix va relayer (faire suivre) le courrier.

:
Lire l’article Postfix : authentification SASL pour une compréhension de l’implication de cette règle avec l’utilisation de SASL.

Valeur par défaut:

relay_domains = $mydestination

La règle relayhost (p113) définit la passerelle SMTP qui est rellement connectée à Internet.
Cette règle ne concerne que les mails SORTANT.
Cette règle intervient dans la mesure où le serveur SMTP (celui sur lequel est définit cette directive) n’est pas connecté à Internet mais sert uniquement de "relais SMTP" d’un sous-domaine vers le domaine sur lequel est installée la passerelle SMTP (définie par $relayhost) qui est connectée à Internet.

:
Cette directive peut également servir si on n’a pas de nom de domaine enregistré dans un DNS.
En effet, il suffit de mettre comme valeur pour cette directive le serveur de notre FAI (eg: smtp.free.fr) et ainsi on peut envoyer du courrier à l’extérieur !!!

relayhost =

La règle transport_maps (p36,102) permet de définir quel mode de transport sera utilisé pour certains domaines ou adresses.
Exemple: AOL refuse tous les mails qui ne proviennent pas de serveurs SMTP connus.
Donc, je vais mettre dans ma table "transport-AOL" des lignes comme ceci:

mon-ami1@aol.com smtp:smtp.free.fr
mon-amie@aol.com smtp:smtp.free.fr

ou, si je souhaite une règle générale:

aol.com smtp:smtp.free.fr

ainsi, tout mail à destination de AOL sera relayé par le serveur smtpd de Free.

transport_maps = hash:/etc/postfix/transport-AOL

La règle defer_transports (p110-111) définit quel type de transport doit être utilisé et pour quel domaine lorsque l’on souhaite retarder/différer la livraison du courrier (par exemple dans le cas d’une connexion Internet non permanente).
La livraison du courrier se fera donc lorsque Postfix recevra une commande de type:

postqueue -f [nom de domaine]

postfix flush

sendmail -q

Puis une fois la file deferred vide, Postfix remettra en attente, dans la file deferred, tous les mails qu’il recevra, jusqu’à la prochaine commande de type ci-dessus.
On voit donc que même si la connexion à Internet devient active, les mails sont mis en attente.

Cette règle est associée à la règle transport_maps.
Valeur par défaut:

#defer_transports =

II - Les tables de recherche

Postfix utilise des fichiers "base de données" UNIX appelés aussi Tables de recherche (p34).
Ces fichiers, ou tables, ne sont rien d’autre que des fichiers texte (contenant les correspondances souhaitées) auxquels on applique la commande postmap /chemin/du/fichier pour obtenir une version indexée du fichier (p34).

:
Cette commande doit être lancée chaque fois que l’on modifie le fichier texte.
Il existe plusieurs formats internes pour ces fichiers. Ces formats dépendent des bibliothèques installées sur le système.
Pour connaitre tous les types de format reconnus par Postfix, il suffit de taper la commande suivante: ~# postconf -m
La commande ~# postconf default_database_type renvoie la valeur de la règle default_database_type.
Ce qui indique le type de bases de données utilisées par le serveur Postfix.

:
HASH désigne un tableau associatif dont chaque élément (des scalaires: un scalaire est indifféremment un nombre ou une chaine de caractères) est un couple "clef / valeur".
Un hash (ou tableau associatif) est indexé par une chaine de caractères et non par un nombre et contient 2xN élments: N clefs et N valeurs.
HASH désigne la méthode d’accès aux données des bases utilisées par Postfix (p35).

• Les clefs, appelées LHS pour Left Hand Side, constituent la colonne gauche des tables de recherche.
  Les clefs sont insensibles à la casse.
• Les valeurs, appelées RHS pour Right Hand Side, constituent la colonne droite des tables de recherche.

La règle default_database_type (p35,39) définit le type de base de données que l’on souhaite utiliser.
Les bases de données sont manipulées (créees et parcourues) par la commande postmap (p226)

default_database_type = hash

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:

yoyo: pascal@linuxorable.fr

donc tous les mails à destination de yoyo@linuxorable.fr seront livrés dans la BàL de pascal@linuxorable.fr

III.2/ Exemple de table d’alias (p39)

roger: roger1@xxx, roger2@yyy, roger3@zzz, ...

III.3/ Extension des tables d’alias:

La construction d’une table d’alias crée un fichier dont l’extension est .db

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 Left Hand Side), 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 Right Hand Side), 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

:
~# postmap /etc/postfix/... utilise la règle alias_maps pour savoir quel(s) fichier(s) d’alias il faut re/construire.
~# newaliases utilise la règle alias_database pour savoir quel(s) fichier(s) d’alias il faut re/construire (p39).

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.

Ne concerne que la distribution du courrier dans les BL locales !!!

alias_maps = hash:/etc/postfix/aliases

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.

:
Cette règle ne peut contenir des types de tables comme NIS, LDAP etc... (c’est le sens de ...base de données standards d’UNIX).

alias_database = hash:/etc/postfix/aliases

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.

default_privs = nobody

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".

allow_mail_to_commands =

La règle allow_mail_to_files (p40-41,201) définit dans quel cadre Postfix doit délivrer le courrier à un fichier.

Par défaut, cette règle autorise la livraison de mails à un fichier à 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".

allow_mail_to_files =

• 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

:
Toutes ces tables ne supportent pas les listes de valeurs

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.

#canonical_classes = envelope_sender, envelope_recipient, header_sender, header_recipient

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.

sender_canonical_maps = hash:/etc/postfix/sender_canonical_maps

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.

recipient_canonical_maps = hash:/etc/postfix/recipient_canonical_maps

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"

:
Avec cette règle je peux me créer autant de nom de BAL que je veux et les rediriger toutes vers une seule existante.

:
Après chaque modification du fichier texte, il faut reconstruire la table de recherche avec la commande postmap /etc/postfix/canonical_maps
Les changements seront visibles après une minute.
La commande postfix reload élimine ce delai.

:
La recherche dans la table canonique est prioritaire à la table d’alias !!! Ce qui veut dire en clair que si j’ai:

dans /etc/postfix/alias: roger: roger@mondomaine.fr
dans /etc/postfix/canonical_maps: roger roger@yahoo.fr

alors si dans le champ From: de mon mail je mets juste roger alors roger sera transformé en roger@yahoo.fr et pas en roger@mondomaine.fr

canonical_maps = hash:/etc/postfix/canonical_maps

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.

:
C’est aussi le répertoire racine des processus démons de Postfix qui fonctionne en cage chroot.

Valeur par défaut:

queue_directory = /var/spool/postfix

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:

qmgr_message_active_limit = 20000

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.

qmgr_message_recipient_minimum = 10

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:

queue_file_attribute_count_limit = 100

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

queue_minfree = 60480000

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

queue_run_delay = 600s

V.2/ Les messages différés (p60)

La règle minimal_backoff_time (p61,213) définit le délai minimum entre deux tentatives de distribution d’un message différé.
A chaque fois que la tentive de redistribution échoue, le gestionnaire de file d’attente qmgr augmente le délai avant la prochaine tentative. Ce délai ne pourra jamais être inférieur à $minimal_backoff_time

Valeur par défaut: 1000s

minimal_backoff_time = 600s

La règle miximal_backoff_time (p61,213) définit le délai maximum entre deux tentatives de distribution d’un message différé.
Ce délai ne pourra jamais être supérieur à $maximal_backoff_time

Valeur par défaut: 4000s

maximal_backoff_time = 800s

La règle maximal_queue_lifetime (p106) détermine le temps maximum durant lequel un message peut rester dans la file "deferred" avant d’être renvoyé à son expéditeur.
Unités de temps: s (secondes), m (minutes), h (heures), d (jours), w (semaines). L’unité de temps par défaut est d (days).

Valeur par défaut: 5d.

maximal_queue_lifetime = 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).

En clair cela veut dire qu’on lie/fixe, grâce à cette table, un utilisateur à une adresse d’EXPEDITEUR.
Ceci afin d’éviter toute tentative d’usurpation d’adresse.
Voir SURTOUT "XI.4/ Restrictions sur les expéditeurs".

:
Cette directive implique l’utilisation de SASL.

La table sera de la forme:

LHS: roger@mondomain.com
RHS: roger

smtpd_sender_login_maps = hash:/etc/postfix/sender_login_maps

VII - Directives relatives à la réception des messages

VII.1/ Règles générales

La règle biff (p202) initialise ou non un petit processus (biff lui-même) qui a pour fonction de prévenir les usagers locaux qu’un nouveau message est arrivé.
Cette règle trouve son utilité uniquement pour les clients mail en mode console.

biff = yes

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)

message_size_limit = 20480000

La règle smtpd_recipient_limit (p52,220) fixe le nombre maximum de destinataires pour un même message.
En clair, c’est le nombre maximum de destinataires que l’on peut mettre dans le champ CC: du mail que l’on va envoyer.

Par défaut, cette valeur vaut 1000

smtpd_recipient_limit = 100

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:

La règle smtpd_error_sleep_time (p52,220) définit le délai initial entre le traitement de deux commandes erronées.
Comme par défaut cette règle est initialisée à 1 seconde, cela veut dire, que dans un premier temps, Postfix laissera s’écouler 1 seconde avant de répondre à une nouvelle commande erronée en provenance d’un même client.

Valeur par défaut: 1s

smtpd_error_sleep_time = 5s

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

smtpd_soft_error_limit = 5

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

smtpd_hard_error_limit = 10

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:

Par défaut, l’agent de livraison des mails pour les comptes UNIX locaux (c’est à dire qui se trouvent sur la même machine sur laquelle est installé Postfix) s’appelle local. Cet agent sait utiliser les BL type UNIX, les fichiers de courrier maildir de qmail, les bases de données d’alias type Sendmail et les fichiers .forward (style Sendmail) des utilisateurs.
Si seuls des comptes locaux doivent être desservis, alors cet agent local est suffisant. Nul besoin de définir un quelqu’autre agent de distribution locale.

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

#mailbox_command = procmail -a "$EXTENSION"

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.

La règle mailbox_transport (p88,212) définit l’agent optionnel de distribution locale utilisé par l’agent de livraison local. Et ceci afin de livrer le courrier à des destinataires locaux, qu’ils soient trouvés ou non dans le fichier /etc/passwd

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

:
Puisque l’agent local est utilisé pour passer les mails à Cyrus-IMAP alors la table /etc/postfix/aliases est lue !!!
La règle mailbox_transport est un paramètre de l’agent local interprété après les alias.

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

#mailbox_transport = lmtp:unix:/var/run/cyrus/socket/lmtp
mailbox_transport = cyrus

La règle local_recipient_maps (p88,211) doit être ainsi configurée pour l’utilisation de Cyrus-IMAP.
Cette règle permet de contrôler que l’adresse mail du destinataire indiquée dans le champ RCP TO: du mail reçu par Postfix correspond bien à un utilisateur ayant une BL (compte imap) sur le serveur Cyrus-IMAP.

:
La table de recherche /etc/postfix/aliases doit contenir au moins tous les utilisateurs ayant une BL sur le serveur IMAP.
Si ce n’est pas le cas, alors gros message d’erreur et mail non livré !!!
DOIT CONTENIR au moins tous les utilisateurs ayant une BL si et seulement si local_recipient_maps = alias_maps !!! La table de recherche est lue lors de l’envoi et de la réception des mails !!!
Voir "III.1/ Rôle des alias".

:
Si l’on souhaite utiliser LDAP pour contrôler l’adresse du destinataire des mails reçus par Postfix, il faut alors commenter dans le fichier /etc/postfix/aliases les entrées de tous les utilisateurs ayant une BAL sur le serveur IMAP et utiliser la deuxième valeur ci-dessous pour la règle local_recipient_maps.
Cette deuxième valeur indique que Postfix consultera d’abord la table /etc/postfix/aliases puis lancera la requête (définie dans /etc/postfix/ldap_local_recipient.cf) sur l’annuaire LDAP.

#local_recipient_maps = $alias_maps
local_recipient_maps = $alias_maps, ldap:/etc/postfix/ldap_local_recipient.cf

La règle local_transport (p88) désigne l’agent de distribution locale qui remplacera l’agent local.
Les messages seront délivrés dans les BL de Cyrus. Ces BL sont celles d’utilisateurs qui n’ont pas forcément un compte UNIX sur le serveur sur lequel est installé Postfix (comptes virtuels).

:
Si on utilise cette règle alors la table de recherche /etc/postfix/aliases n’est pas lue car cette règle inhibe l’agent de livraison local qui, lui, lit /etc/postfix/aliases.
C’est pour cette raison que Cyrus est défini comme agent de livraison optionnel (en plus de l’agent de livraison local) avec mailbox_transport et non avec local_transport

#local_transport = cyrus

VIII - Directives relatives à la distribution des messages

VIII.1/ Format des BàL

Le format mbox implique un seul fichier contenant tous les mails et pose des problèmes de verrouillage pendant l’accès en écriture à ce fichier par Postfix et/ou Cyrus.
De plus, problème si plantage du serveur mail en pleine écriture dans ce fichier car le mail n’aura pas été écrit en entier et donc la fin du fichier ne sera pas standard rendant ce fichier (donc tous les mails !!!) difficile/impossible à lire.

Le format maildir impose plusieurs répertoires et un fichier par mail. Il a été créé pour pallier aux défaillances du format mbox.
Avec Procmail, ce format ne nécessite même pas la cération préalable du répertoire maildir dans les home directories !!!
Il sera automatiquement créé lors de la réception du premier mail.

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.

:
Cette règle est inopérante avec l’utilisation de Cyrus-IMAP qui a son propre système de BL.

Valeur par défaut: /var/mail

mail_spool_directory =

La règle home_mailbox (p84,208) définit le répertoire (si format maildir) ou le fichier (si format mbox) dans lequel Postfix doit placer les mails à destination des utilisateurs.
Par défaut, Postfix livre les mails (au format mbox) dans le répertoire de spool de mails de la distribution Linux.
Sous Debian, le spool de mails est /var/mail/

Valeur par défaut:

home_mailbox =

IX - Directives relatives à l’authentification SASL au serveur smtp

Pour de plus amples informations sur SASL et sur la résolutions de quelques problèmes liés à la mise en oeuvre de SASL voir l’article Postfix : authentification SASL

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é.

smtpd_sasl_auth_enable = yes

IX.1.1/ Authentification par mot de passe UNIX (p157) et site x.guimard

:
Cette méthode impose la circulation des mots de passe en clair. Donc utiliser TLS pour chiffrer la communication (p157).

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)

:
les processus de Postfix doivent avoir les droits lecture+exécution sur le répertoire /var/pwcheck sinon l’authentification risque d’échouer.

IX.1.1.2/ Les règles

La règle smtpd_sasl_application_name définit le nom de l’application utilisée pour l’initialisation du serveur SASL.
Ceci contrôle le nom du fichier de configuration SASL nommé /usr/lib/sasl2/smtpd.conf .

Valeur par défaut:

smtpd_sasl_application_name = smtpd

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

Sous Debian, le démarrage de ce serveur est contrôlé par le fichier /etc/default/saslauthd.
C’est dans ce fichier que l’on indique le mécanisme d’authentification que l’on souhaite utiliser.
C’est le paramètre MECHANISMS="xxxxx" qu’il faut renseigner:

• pour lecture du fichier /etc/passwd: MECHANISMS="getpwent"
• pour lecture du fichier /etc/shadow: MECHANISMS="shadow"

IX.1.2/ Authentification par PAM

:
Il ne faut pas utiliser PAM avec une authentification SASL car les mots de passe circulent en clair
Voir le fichier /etc/pam.d/imap:

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:

pwcheck_method: saslauthd
mech_list: pam

Pour utiliser PAM, initialiser les règles suivantes (ou d’autres encore):

#smtpd_sasl_application_name= smtpd <== fait référence au fichier /usr/lib/sasl2/smtpd.conf
#smtpd_sasl_local_domain =
#broken_sasl_auth_clients = yes
#smtp_sasl_security_options = noanonymous

Ensuite il faut lancer le serveur d’authentification saslauthd avec l’option suivante: -a pam

Sous Debian, le démarrage de ce serveur est contrôlé par le fichier /etc/default/saslauthd.
C’est donc dans ce fichier que l’on indique le mécanisme d’authentification que l’on souhaite utiliser.
Pour l’utilisation de PAM il faut y déclarer ceci: MECHANISMS="pam"

IX.1.3/ Authentification avec la base externe de SASL: /etc/saslbd2 (p158)

:
Conserver une version de la table sasldb2 dans /etc pour l’administration des BL !!!

:
Pour faire fonctionner /etc/sasldb2, assurez-vous d’avoir renseigné le domaine SASL (royaume) avec un nom de domaine pleinement qualifié.

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

:
Avec cette méthode, il n’est pas nécessaire que le serveur/démon d’authentification saslauthd tourne.

:
Si Postfix se lance en mode chroot (on le voit dans le fichier /etc/postfix/master.cf)
Alors il faut copier /etc/sasldb2 dans /var/spool/postfix/etc !
De plus, /etc/sasldb2 doit appartenir à root car sinon, quand on lance Postfix puis qu’on regarde si tout est correct avec la commande ci-dessous, alors on obtient:

postfix check

postfix/postfix-script: warning: not owned by root: /var/spool/postfix/etc/sasldb2

Il faut créer le fichier /etc/postfix/sasl/smtpd.conf et y mettre ceci: pwcheck_method: auxprop
Le mot-clé auxprop indique à Postfix d’utiliser un fichier de mots de passe SASL externe (p158).
Ce fichier est /etc/sasldb2
Le serveur smtpd Postfix doit avoir accès au fichier /etc/sasldb2 donc on doit revoir les permissions des groupes.
Avec le mécanisme d’authentification OTP, le serveur doit également avoir un accès en écriture sur le fichier /etc/sasldb2

:
tous les utilisateurs doivent pouvoir s’authentifier en utilisant tous les mécanismes annoncés par Postfix sinon la négociation pourrait aboutir à un mécanisme non supporté et l’authentification échouera.
Par exemple, si on configure SASL pour utiliser le serveur d’authentification saslauthd pour les authentifications via PAM (Pluggable Authentification Modules), seuls les mécanismes PLAIN et LOGIN sont supportés et ont une chance de réussir alors que la librairie SASL supporte d’autres mécanismes tels DIGEST-MD5. Ceci arrive car ces mécanismes sont connus sous forme de plugins et la librairie SASL n’a aucun moyen de savoir que la source d’authentification est PAM. On devra donc limiter la liste des mécanismes anoncés par Postfix. Ceci n’est possible qu’avec les versions 2.1.1 et suprieures de SASL.

On ajoutera donc au fichier /postfix/postfix/sasl/smtpd.conf: mech_list: plain login
La règle mech_list peut prendre toutes les valeurs renvoyées par Postfix après la commande EHLO < @IP > à savoir:

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.

:
Dans les deux cas, cette règle à un impact sur la valeur du nom de login qui faut configurer dans le client mail pour l’authentification auprès du derveur SMTP (voir l’article Postfix : authentification SASL).

smtpd_sasl_local_domain = euphorie.linuxorable.fr
ou
smtpd_sasl_local_domain =

La règle broken_sasl_auth_clients (p159) permet aux clients mail ne respectant pas le protocole d’authentification SMTP de quand même s’authentifier.
Ici ils ne pourront pas s’authentifier.

broken_sasl_auth_clients = no

La règle smtp_sasl_security_options (p160) indique les mécanismes d’authentification que l’on ne souhaite pas utiliser.
Les différentes valeurs possibles:

Par défaut, le serveur smtpd Postfix accepte les mots de passe en clair mais pas les logins anonymes.

:
Il apparait que les clients essaient les méthodes d’authentification dans l’ordre indiqué par le serveur.
Cet ordre est celui renvoyé par la ligne:

250-AUTH GSSAPI NTLM LOGIN PLAIN DIGEST-MD5 CRAM-MD5 lorsque l’on se connecte au serveur SMTP par telnet.

#smtpd_sasl_security_options = noanonymous
smtpd_sasl_security_options = noanonymous, noplaintext

X - Directives relatives au chiffrage TLS/SSL

X.1/ Généralités

• TLS (Transport Layer Security 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 (Autorité de Certification).
• 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).

:
Une clef de session ne sert qu’une seule fois.

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.

:
TLS chiffre les messages uniquement le temps de la connexion (elle même chiffrée). Le message une fois déposé sur le serveur n’est plus chiffré !!!

X.4/ TLS au niveau du serveur SMTP

Pour utiliser TLS, le serveur smtpd Postfix a besoin d’un certificat et d’une clef privée. Les deux doivent être au format .pem.
La clef privée ne doit pas être chiffrée, ce qui signifie: la clef doit être accessible sans mot-de-passe.
Le certificat et la clef privée peuvent être dans le même fichier.
Les certificats RSA et DSA sont tous deux supportés. Généralement, on n’aura que des certificats RSA issus d’une autorité de certification commerciale.
En complément, les outils fournis avec OpenSSL génèreront par défaut des certificats RSA.
On peut avoir les deux en même temps, auquel cas le chiffrement utilisé détermine le certificat présent.
Pour les clients Netscape et les clients SSL ouverts sans choix particulier de chiffrement, le certificat RSA est préféré
Pour permettre aux clients smtp distants de vérifier le certificat du serveur smtpd Postfix, le certificat de l’AC (dans le cas d’une chaine de certification, tous les certificats des autorités) doit être disponible.

La règle smtpd_use_tls (p171) définit si oui ou non on utilise le chiffrement TLS. (p171)

smtpd_use_tls = yes

La règle smtpd_enforce_tls déclare que seules les commandes avec chiffrement TLS seront acceptés.

En accord avec la RFC 2487 ceci ne doit pas être fait dans le cas d’un serveur SMTP référencé et public.
Implique smtpd_use_tls = yes

smtpd_enforce_tls = no

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.

smtpd_tls_key_file = /usr/lib/ssl/mon_AC/private/server_tls.pem

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.

smtpd_tls_cert_file = /usr/lib/ssl/mon_AC/certs/server_signed.pem

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.

smtpd_tls_CAfile = /usr/lib/ssl/mon_AC/private/mon_AC.crt

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

smtpd_tls_loglevel = 4

X.5/ TLS au niveau du client SMTP

Pour le client smtp de Postfix, on reprend les mêmes règles que pour le serveur smtpd mais au lieu de commencer par smtpd elles commencent toutes par smtp
Il est tout à fait possible de créer un jeu de clefs publique/privée spécifique au client smtp de Postfix. Ici, j’ai repris le même jeu de clefs que pour le serveur.

La règle smtp_use_tls (p175) définit si oui ou non on utilise le chiffrement TLS. (p175)

smtp_use_tls = yes

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.

Implique smtp_use_tls = yes

smtp_enforce_tls = no

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.

smtp_tls_key_file = /usr/lib/ssl/mon_AC/private/server_tls.pem

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.

smtp_tls_cert_file = /usr/lib/ssl/mon_AC/certs/server_signed.pem

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.

smtp_tls_CAfile = /usr/lib/ssl/mon_AC/private/mon_AC.crt

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

smtp_tls_loglevel = 4

XI - Directives relatives à la lutte anti-spam

XI.1/ Généralités

Postfix possède d’excellents outils pour lutter contre les courriers indésirables.
Et ces outils sont bien moins gourmands en ressources système que n’importe quel appel à des filtres externes. (p132)

:
Postfix suit un ordre bien déterminé dans sa recherche des restrictions.
Et cet ordre est indépendant de l’ordre dans lequel ces restrictions sont inscrites dans ce fichier (main.cf).
Il est donc nécessaire de faire très attention à l’ordre de lecture des restrictions que l’on souhaite mettre en place.
Et ceci afin d’éviter que des restrictions s’annulent mutuellement ou bien ne soient tout simplement pas lues.

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

:
Point n’est besoin de définir des règles pour chacune de ces étapes.
Bien souvent, les règles de restriction sont définies simplement au niveau du client (phase de connexion) avec la règle smtpd_client_restrictions

:
Lors de la lecture des restrictions, si Postfix: (p135)

• 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é.

RBL: Realtime Black List/Liste noires en temps réel.
Les RBL sont des serveurs DNS qui maintiennent à jour (ou non !) des listes d’adresses IP connues pour mettre du SPAM.

smtpd_client_restrictions =

reject_invalid_hostname
reject_non_fqdn_hostname
reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unknown_sender_domain
reject_unknown_recipient_domain
permit_mynetworks
reject_unauth_destination (Attention à cette règle: voir l’article Postfix : authentification SASL)
warn_if_reject reject_rbl_client sbl.spamhaus.org
warn_if_reject reject_rbl_client xbl.spamhaus.org
warn_if_reject reject_rbl_client list.dsbl.org
warn_if_reject reject_rbl_client bl.spamcop.net
warn_if_reject reject_rbl_client relays.ordb.org
warn_if_reject reject_rbl_client opm.blitzed.org
warn_if_reject reject_rbl_client cbl.abuseat.org
warn_if_reject reject_rbl_client dul.dnsbl.sorbs.net
permit

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:

Postfix transfert le messages:

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

Postfix est la destination finale:

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

smtpd_helo_required = yes

La règle disable_vrfy_command (p206) dfinit si oui ou non il faut désactiver la commande VRFY.
Cette commande permet au client (SPAMEURs) de vérifier un nom de destinataire.

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

disable_vrfy_command = yes

La règle strict_rfc821_envelopes (p145,222) définit si oui ou non on accepte des adresses d’enveloppe non conforme à la RFC822.
Les adresses reçues avec les commandes SMTP MAIL FROM:et RCPT TO: doivent être encadrées par des < > et contenir des commentaires style RFC 822. Ceci stoppe le courrier des logiciels mal écrits.

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

strict_rfc821_envelopes = yes

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.

:
Positionnée à yes, cette règle peut rejeter des mails légitimes !!!
Voir l’article Les messages d’erreur pour un exemple de rejet de mail par cette règle.

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

strict_7bit_headers = yes

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.

Par en-tête il faut comprendre: To, From, Object, Cc, etc...
Donc si l’un au moins de ces en-têtes comporte un motif présent dans le fichier /etc/postfix/header_checks et que ce motif est associé à l’action REJECT, alors le message sera rejeté.

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)

header_checks = regexp:/etc/postfix/header_checks

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.

Chez moi, cette règle sert à rejeter les fichiers attachés en fonction de leur extension.
Cette règle accepte les expressions régulières (regexp)

mime_header_checks = regexp:/etc/postfix/pieces_jointes_checks

XII.6/ Restriction sur le corps des messages

La règle body_checks (p145-148) définit la liste des restrictions que le serveur SMTP appliquera sur le corps des messages.
Cette règle accepte les expressions régulières (regexp)

Exemple de syntaxe: /[:alpha:][:alpha:]/ REJECT

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

body_checks = regexp:/etc/postfix/body_checks

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.

:
L’action reject_sender_login_mismatch est liée la table de recherche définie par:
smtpd_sender_login_maps = hash:/etc/postfix/sender_login_maps

smtpd_sender_restrictions =

permit_mynetworks
reject_sender_login_mismatch
reject_authenticated_sender_login_mismatch
reject_unauthenticated_sender_login_mismatch

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.

Les 2 premières restrictions ci-dessous sont relatives à l’adresse réseau ou au nom de machine du client.
La 3ème restriction est spécifique aux adresses de destination reçues avec la commande RCPT TO.

smtpd_recipient_restrictions =

permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination

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:

Postfix transfert le messages:

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

Postfix est la destination finale:

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.

:
reject_unauth_pipelining n’est pas pratique en dehors de smtpd_data_restrictions lorsque:

1) le client utilise ESMTP (EHLO au lieu de HELO)
2) avec "smtpd_delay_reject = yes" (valeur par défaut).

L’utilisation de reject_unauth_pipelining dans les autres contextes de restriction n’est pas recommandé.

smtpd_data_restrictions =

reject_unauth_pipelining
permit

XIII - Redéfinition des codes erreur renvoyés par Postfix

unknown_client_reject_code = 550
unknown_address_reject_code = 550
unknown_hostname_reject_code = 550
unverified_sender_reject_code = 550
unverified_recipient_reject_code = 550

Commentaires