Large diffusion

Postfix doit être largement diffusé et utilisé afin d'avoir un impact sensible sur les performances et la sécurité des systèmes de messagerie sur l'Internet.
C'est pourquoi Postfix est un logiciel libre sans aucune restriction.

Performance

Postfix est au moins trois fois plus rapide que son plus proche « rival » (Qmail de D.Bernstein).
Un serveur Postfix sur un PC de bureau peut envoyer et recevoir quotidiennement un million de méls différents.
Postfix utilise les « trucs » utilisés sur les serveurs Web pour réduire la création de processus, et d'autres types de « trucs » permettent de réduire l'utilisation du système de fichiers, tout ça sans compromettre les performances.

Compatibilité

Postfix a été conçu pour être compatible avec Sendmail afin de facilité la migration. Les fichiers /var[/spool]/mail, /etc/aliases, NIS, et ~/.forward sont utilisés.
Toutefois, l'administration devant être simple, Postfix n'utilise pas de fichier sendmail.cf :-).

Sûreté et robustessse

Postfix se comporte de façon rationnelle face aux nombre de tâches demandées. Si le système n'a plus de mémoire ou d'espace disque, Postfix n'endommagera pas les choses d'avantage, il a été conçu pour rester sous contrôle.

Flexibilité

Postfix est conçu de façon modulaire, une douzaine de petits programmes effectent des tâches bien précises.
Il est possible de remplacer les programmes par défaut par des produits maison, voire de supprimer certains programmes inutiles dans certains cas (un firewall ou une station de travail n'a pas besoin de livrer localement des méls).

Sécurité

Postfix utilise plusieurs niveaux de défence afin de protéger le système de toute intrusion. Chaque programme est enfermé dans sa cage (chrooté), il n'y a aucun lien direct entre le réseau et les programmes sensibles comme la livraison du courrier local. Postfix ne fait même pas confiance à ses propres files de courier. De plus, aucun des programmes n'est SUID.

Différentes solutions de transport

Outre smtp, il est possible d'implémenter d'autres solutions de transport des messages comme uucp, ²DECnet ou X400 sans avoir recours à d'autres systèmes.

Domaines virtuels

Le changement d'une seule table suffit à ajouter un domaine virtuel au système de courrier, là où plusieurs niveaux d'alias et de redirections sont nécessaires avec d'autres systèmes.

Contrôle UCE

L'accès au système Postfix est contrôlé. Les suspects usuels sont reconnus : requêtes rbl et dns sur les adresses expéditeurs, expéditeur de la commande HELO, listes noires. Le contrôle du contenu n'est pas encore implémenté.

Tables

Postfix ne possède pas encore de langage pour la réécriture des adresses mél, à la place un usage extensif de requêtes sur des tables db, dbm
et nis est réalisé. D'autres systèmes de gestion de bases de données peuvent être ajoutés de façon relativement simple (mysql).

Introduction

Files de courrier

Postfix utilise quatre files d'attentes :

maildrop
contient les messages locaux ;

incoming
contient les messages qui ont été prélevés dans maildrop par le démon pickup, puis qui ont été traités par le démon cleanup.
Cette file contient aussi les messages venant de l'extérieur. En bref, elle contient les messages qui n'ont pas encore été traités par
le gestionnaire de file d'attente qmgr ;

active est une file contenant les messages en cours de délivrance par qmgr ;

deferred
contient les messages qui n'ont pas pu être délivrés (il y en a 10 dans notre exemple ci-dessous).
De plus, le répertoire /var/spool/postfix/defer contient les mails en attente plus longue et des répertoires qui sont « hachés » afin de ne pas
avoir des répertoires contenant trop de fichiers : ainsi, le fichier 7B345AC0B1, par exemple, sera dans defer/7/B/7B345AC0B1.

À des fins de confidentialité, les processus communiquent via des piles fifo ou des sockets du type unix-domain, placés dans un répertoire protégé.

La quantité d'information passée entre les processus se limite bien souvent au nom d'un fichier file et à une liste de destinataires, ou à une information sur le statut du programme.

Pour éviter tout perte d'informations, Postfix utilise les mécanismes habituels pour s'assurer de la transmission des données, flush, fsync(), analyse des résultats d'appels système.

Introduction

Par définition, les programmes de courrier traitent des informations provenant de sources potentiellement dangeureuses.
Un système de courrier doit donc être écrit avec une grande attention quand il utilise les droits d'un utilisateur, cela même s'il n'est pas directement connecté à un réseau.

Postfix est un système complexe. La première version comprenait 30000 lignes de code, sans compter les commentaires.
Avec un programme aussi complexe, la sécurité du système ne doit pas dépendre d'un seul mécanisme. Sinon, une seule suffirait à rendre vulnérable l'ensemble du logiciel.
Postfix utilise donc plusieurs couches de défense contre des erreurs logicielles ou autres.

Moindre privilège

La plupart des démons de Postfix peuvent être lancés avec de moindres privilèges et dans un environnement fermé (chroot).
Cela est plus particulièrement vrai pour les programmes directement exposés au réseau, comme les serveurs et clients smtp.
Bien que l'enfermement et les privilèges les plus bas ne soient pas suffisants pour assurer une sécurité absoluement parfaite, cela y contribue fortement.

Isolation

Postfix utilise des processus différents afin d'isoler les activités de chacun. En particulier, il n'y a aucun lien entre le réseau et les programmes de livraison local particulièrement sensibles en terme de sécurité. Un intrus devra passer au travers de plusieurs programmes pour arriver à ce niveau.
Certaines parties du système Postfix sont multi-threadées, toutefois, aucune des parties en contact direct avec le réseau ne l'est.
La séparation des processus fournit une bien meilleure isolation que le multi-thread utilisant un espace de nom commun.

Environnement controlé

Aucun des programmes de livraison de Postfix ne nécessite de droits utilisateur. Au lieu de cela, la majorité des programmes Postfix fonctionne sous le contrôle du démon-maître (master) résident qui lui-même est dans un environnement controlé, sans aucune relation père-fils avec un quelconque processus utilisateur. Cette méthodologie permet d'exclure tout exploit utilisant les fichiers ouverts, les signaux, les variables d'environnement que les systèmes Unix passent de pères éventuellement mal-intentionnés à leurs processus fils.

Programme SUID

Aucun programme postfix n'est SUID.
L'introduction de ce concept a été la plus grosse erreur de l'histoire d'Unix. Le positionnement du bit UID pose bien plus de problèmes qu'il n'en résoud.
Chaque fois qu'une nouvelle fonctionnalité a été ajoutée au système Unix, set-uid a entrainé un problème de sécurité : librairies partagées, système de fichiers /proc, support multi-langage, pour n'en mentionner que quelques-unes. De plus, set-uid rend impossible l'utilisation de fonctionnalités qui ont rendus les successeurs d'Unix si attractifs, comme plan9 et les espaces de noms du système de fichiers par processus.

Par défaut, le répertoire de la file maildrop est accessible en écriture au monde entier, afin que les différents processus locaux puissent poster leurs courriers sans requérir l'assistance d'une commande set-uid ou du démon serveur de courrier. Ce répertoire n'est pas utilisé pour les messages venant du réseau et les fichiers de files ne peuvent pas être lus par les autres utilsateurs.

Un répertoire accessible en écriture offre des possibiltés en terme de vulnérabilité : un utilisateur local peut faire des liens durs vers les fichiers de file d'un autre utilisateur afin que cette file ne soit jamais libérée et/ou que ses messages soient livrés plusieurs fois ; un utilisateur local peut remplir le répertoire de la file maildrop de cochoneries et essayer de faire planter le système ; un utilisateur local peut aussi faire des liens durs vers les fichiers de quelqu'un d'autre pour se les faire délivrer par mél. Toutefois, les fichiers de files Postfix ont un format particulier ; la probabilité qu'un fichier non-Postfix soit reconnu comme tel est de moins d'un sur 10 puissance 12.

Si le fait que le répertoire de la file maildrop soit accessible en écriture au monde entier vous semble inacceptable, vous pouvez ne pas utiliser cette solution, révoquez les droits sur le répertoire et préférez l'activation des privilèges set-gid à un petit programme fourni (postdrop) pour permettre aux processus locaux d'envoyer leurs messages.

Confiance

Les fichiers de files ne sont pas écrits sur le disque lorsque la destination est sensible, comme pour des fichiers ou des commandes.
Au lieu de cela, les programmes tel que l'agent de livraison local essayent de prendre leurs décisions avec le souci de la sécurité sur la base des informations reçues initialement.

Bien sûr, les programmes Postfix ne font pas confiance aux données reçues du réseau. En particulier, Postfix filtre les données fournies par l'utilisateur avant de les exporter via des variables d'environnement. S'il y a une leçon à tirer de ce que les administrateurs ont appris des désastres de la sécurité des sites web, c'est bien ceci : ne laissez jamais des données reçues du réseau approcher de l'interpréteur de commandes.
Le filtrage est la meilleure des possibilités possibles.

Données volumineuses

La mémoire pour les chaînes de caractères et les tampons est affectée dynamiquement afin d'éviter tous problèmes de dépassement de tampon.

Les lignes longues dans les messages sont fractionnées en morceaux de taille raisonnable et réassemblées à la livraison.

Les diagnostics sont également fractionnés (en un seul endroit !) avant d'être passés au démon syslog afin d'éviter des dépassements de tampons sur les plateformes les plus anciennes. Toutefois, le tronçonnement des données passées aux appels système ou aux librairies n'est pas généralisé.
Sur certaines plateformes, le programme peut entraîner des problèmes de dépassements de tampon, à cause du logiciel utilisé dans les couches inférieures.

Aucun dispositif de défense contre les lignes de commande anormalement longues n'est réalisé, les noyaux Unix imposant leur propre limite, suffisante pour bloquer les programmes ou les utilisateurs mal-intentionnés.

Autres défenses

Le nombre d'instances d'un objet donné en mémoire est limité, afin d'éviter au système de devenir instable en cas de charge importante.

En cas de problème, le programme se mettra en veille avant d'envoyer un message d'erreur au client, avant de se planter sur une erreur fatale,
ou avant d'essayer de redémarrer un logiciel défaillant. L'objectif est d'éviter de détériorer davantage une éventuelle situation de problème.

Le courrier est posté localement.

Le courrier est posé sur la machine locale par les utilisateurs.
Le programme sendmail (ne pas confondre avec le MTA concurrent) de postfix appelle le programme privilégié postdrop qui dépose le message dans le répertoire de la file maildrop, où le message est pris par le démon de collecte pickup.
Ce démon fait quelques contrôles "sanitaires", afin d'éviter de polluer le reste du système de mail avec du courrier invalide.
Pour éviter des accidents, les permissions du répertoire contenant maildrop sont telles que tout le monde peut y écrire, mais aucun utilisateur n'a le droit d'effacer le contenu (sticky bit positionné).

Le courrier provient du réseau.

Le serveur SMTP Postfix (smtpd) reçoit le message et fait quelques contrôles "sanitaires", afin de protéger le reste du système Postfix.
Le serveur SMTP peut être configuré pour mettre en application des commandes d'ECU (Unsollicited Commercial Mail) sur la base de listes noires locales ou issues du réseau, de requêtes DNS (domaine de l'expéditeur) ou toute autre information concernant l'émetteur.

Autres origines possibles.

Le courrier peut aussi être généré par l'agent local de remise (local) après interrogation de la base d'alias ou du fichier .forward propre à l'utilisateur.

Enfin, le courrier est généré par le système Postfix pour avertir le postmaster d'un problème (chemin indiqué par la flèche qui n'aboutit pas).
Postfix peut être configuré pour alerter le postmaster en cas de problème de protocole SMTP,de violation de règles de sécurité UCE etc ...

Le message est livrable

Le courrier est expédié par l'agent local de la livraison local, soit par l'intermédiaire d'une entrée dans la base de données des alias, soit par l'intermédiaire d'une entrée dans le fichier .forward au niveau de l'utilisateur (ce chemin est indiqué sur le graphique par la flèche sans label).

Le démon de nettoyage cleanup met en application l'étape de traitement finale pour le nouveau courrier. Il ajoute le champ From: et d'autres en-têtes manquantes dans le message, il demande éventuellement au demon trivial-rewrite de réécrire l'adresse de réponse dans le format standard user@fully.qualified.domain, et il extrait optionnellement les adresses des destinataires de l'en-tête.
Le démon cleanup insère le résultat sous la forme d'un seul fichier dans la file d'attente incoming, et informe le gestionnaire de files d'attente queue manager (qmgr) de l'arrivée du nouveau courrier.
Le démon cleanup peut être configuré pour transformer des adresses sur la base des table de consultations canonical et virtual.

Le courrier n'est pas livrable

Un e-mail est généré automatiquement par le système Postfix, afin de renvoyer le courrier non livrable à  l'expéditeur.
Ce sont les démons bounce ou defer qui annoncent la mauvaise nouvelle.

Un autre e-mail est également généré automatiquement par le systèle Postfix pour informer le responsable de la messagerie (postmaster) en cas de problème (ce chemin est indiqué sur le graphique par la flèche sans label).

Postfix n'implémente pas encore un véritable language de réécriture des adresses. L'implémentation d'un tel langage demanderait des efforts non-justfiés, la plupart des sites n'en n'ayant pas besoin. A la place de cela, Postfix utilise des requêtes sur des tables.

Une fois qu'un message a atteint la file d'attente incoming, l'étape suivante consiste à le livrer.
La figure montre les principaux composants du système de distribution du courrier de Postfix.

Le gestionnaire de file d'attente qmgr (queue manager) est le cœur du système de messagerie Postfix.
Il contacte les agents de livraison local, smtp, lmtp ou pipe et envoie une demande de livraison avec le chemin d'accès au fichier qui contient la file d'attente, l'adresse de l'expéditeur, le nom de l'hôte à qui il faut livrer si la destination n'est pas locale, et une où plusieurs adresses de destinataires.

Le gestionnaire maintient une file d'attente deferred séparée pour chaque message qui n'a pas pu être livré (pour des raison temporaires), de manière à ce qu'un compte-rendu de livraison trop volumineux ne vienne pas ralentir l'accès des autres files.

Le gestionnaire maintient une petite file d'attente active avec juste quelques messages prêts pour la livraison.
active agit comme une petite fenêtre sur les files d'attentes incoming ou deferred.
Cette méthode évite au gestionnaire de faire des débordements de mémoire si le serveur est fortement chargé et évite ainsi de consommer trop de ressources.

Optionnellement, le gestionnaire fait "rebondir" le message pour les destinataires qui sont référencés dans la table relocated.
Cette table contient des informations sur les utilisateurs qui ont changé d'adresse.

Sur la demande du gestionnaire de file d'attente, le daemon trivial-rewrite résout les destinations.
Par défaut, il fait uniquement la distinction entre les destinations locales ou distantes.
Des informations de routage additionnelles peuvent être spécifiées dans la table transport.

Sur la demande du gestionnaire de file d'attente, les daemons bounce et defer gênèrent des rapports de non-livraison lorsqu'un message ne peut être acheminé, soit à cause d'une erreur non récupérable, soit parce que le destinataire n'est pas joignable pendant une durée trop longue.

L'agent local de la livraison sait gérer les boîtes aux lettres de type UNIX, les bases de données du type "alias" de sendmail (le MTA concurrent), les fichiers de type .forward de l'utilisateur.
De multiples agents locaux de livraison peuvent être exécutés en parallèle, mais la livraison en parallèle au même utilisateur est habituellement limitée.

Avec l'agent de livraison sendmail de Postfix qui permet de poster des courriers, l'agent de livraison local forme l'interface utilisateur familière de sendmail (le MTA concurrent).

L'agent de la livraison locale a la possibilité d'utiliser d'autres moyens de livraison locale : vous pouvez le configurer pour qu'il livre le courrier dans le répertoire home des utilisateurs, et vous pouvez même le configurer pour déléguer la livraison du courrier à une commande externe telle que le programme procmail bien connu.

Le client smtp recherche une liste d'échangeurs de courrier pour l'hôte de destination, trie la liste par préférence, et essaie chaque adresse alternativement jusqu'à ce qu'il trouve un serveur qui répond.
Sur un système postfix chargé, vous verrez plusieurs processus de client de smtp fonctionner en parallèle.

Le démon pipe est l'interface unique de sortie vers d'autres modes de transport de courrier (Le programme sendmail est l'interface d'entrée).

Le système de courrier Postfix peut par exemple livrer du courrier par l'intermédiaire du protocole UUCP.
Ce protocole vénérable est encore largement répandu.
Par défaut, Postfix comprend des adresses de type "bang path" (Rassurez-vous, ici on parle de SMTP, pas de UUCP qui n'est plus de mise sur Internet, mais seulement dans des réseaux privés).

Assez parlé de démons, pour finir, nous parlerons des utilitaires "ligne de commandes" livrées avec postfix qui vous serviront à maintenir le système.
Sans compter les commandes sendmail , mailq , et newaliases qui ont déjà été présentées, le système Postfix possède une collection de commandes très utiles.
Pour des raisons d'homogénéïté, elle seront toutes nommées postquelquechose.

La commande postfix controle le système de courrier.
C'est l'interface pour démarrer et arrêter le système, et pour quelques autres opérations administratives.
Cette commande est réservée au super-utilisateur.
Exemples :
#/etc/init.d/postfix reload force postfix à relire ses fichiers de configuration (après modif. du /etc/postfix/main.cf).
#/etc/inid.d/postfix check vérifie la configuration du système de courrier.
#/etc/inid.d/postfix flush force postfix à tenter de vider la file deferred, donc à envoyer les messages en attente.

La commande postalias sert à convertir le fichier aliases en format bases de données (*.db).
Ce programme se cache derrière la commande newaliases.

La commande postcat montre les contenu de la file d'attente de Postfix.
C'est un programme limité, il peut être remplacé par un autre plus puissant qui permettrait d'éditer les fichiers de file d'attente de Postfix.

La commande postconf montre les paramètres donnés dans le fichier main.cf de Postfix : les valeurs réelles, les valeurs par défaut, ou les paramètres qui n'ont pas de valeur par défaut.
C'est un programme limité et primaire. Ce programme peut être remplacé par un autre plus puissant qui pourrait non seulement énumérer mais également éditer le fichier main.cf.
Exemples :
#postconf -n affiche les paramètres modifiés par notre configuration.
#postconf -d affiche les paramètres par défaut.

La commande postdrop est appelée par le programme sendmail afin de déposer le courrier dans la file d'attente maildrop.

La commande postkick permet de lancer des commandes internes.

La commande postlock assure le mécanisme de verrouillage des boîtes aux lettres utilisateurs qui peut être utilisé par exemple par des shell scripts.

La commande postlog rend la journalisation de Postfix accessible aux shell scripts.

La commande postmap sert à convertir en format base de données des tables de consultation de Postfix telles que canonical , virtual et d'autres.
C'est un cousin de la commande de makemap d'UNIX.

La commande postqueue est l'utilitaire lancée par la commande de sendmail pour vider ou lister la file d'attente du courrier.

La commande postsuper sert à la maintenance de la file d'attente de Postfix.
Cette commande est lancée lors du démarrage du système de courrier.

Compilation

Le logiciel se récupère sous la forme d'un fichier .tar.gz que l'on décompresse dans un répertoire d'installation :

# tar xvzf postfix-19991231-pl08.tar.gz -C /tmp
# cd /tmp/postfix-19991231-pl08/

Dans ce répertoire se trouve un fichier INSTALL fort clair (mais en anglais) qu'il suffit de suivre pas à pas pour installer et configurer postfix.

La première étape consiste à générer les exécutables :
# make
Il faut ensuite déplacer les fichiers binaires, de configuration et les pages de manuel dans les répertoires adéquats de votre système.
Sous le répertoire d'installation, vous devez normalement avoir les répertoires : conf, bin, libexec, html et man (les autres répertoires sont ceux contenant les sources, des exemples et les fichiers objets générés par la compilation).
Pour compiler avec support MySql :
# make -f Makefile.init makefiles 'CCARGS=-DHAS_MYSQL -I/usr/include/mysql' 'AUXLIBS=-L/usr/lib/mysql -lmysqlclient -lz -lm'
# ./make

Installation de la documentation

Installation des fichiers de configuration

Création des files d'attente

Installation des exécutables

Droits d'accès à la file d'attente

Il s'agit ici de permettre l'accès des utilisateurs locaux au répertoire /var/spool/postfix/maildrop.
Par défaut, tous les sous-répertoires de /var/spool/postfix appartiennent au groupe root.
Or, lorsque les utilisateurs postent un courrier, celui-ci transite d'abord par le répertoire maildrop.

Avec les droits actuels, ces courriers seraient donc refusés.
Plusieurs possibilités, décrites dans le fichier INSTALL, sont possibles : rendre le répertoire maildrop accessible à tout le monde, ou utiliser la commande postdrop en sgid. Nous avons retenu la première solution. Pour ce faire, il suffit de modifier les droits d'accès du répertoire maildrop : # chmod 1733 /var/spool/postfix/maildrop
Cette solution suppose que vous ayez confiance en vos utilisateurs locaux...
Si ce n'est pas le cas, préférez-lui la solution du postdrop en sgid (décrite dans le fichier INSTALL).

L'invocation de la commande postdrop lors de l'envoi d'un message est réalisée automatiquement via l'appel du script postfix-script qu'il s'agit donc de rendre accessible à tout le monde :
# cp /etc/postfix/postfix-script-nosgid /etc/postfix/postfix-script

Si vous préférez utiliser des paquetages rpm (Redhat, Mandrake, etc ..) ou deb (Debian), vérifiez les emplacements des différents fichiers et adaptez les chemins utilisés ici à votre configuration.

Télécharger le package RPM de Postfix

http://www.rpmfind.net

Désactiver les dépendances de sendmail

# /etc/init.d/sendmail stop
# rpm --nodeps -e sendmail

Décompresser le package

# rpm -i postfix-20010228_pl06release-1.rpm

Le fichier de configuration de Postfix (/etc/postfix/main.cf) contient plusieurs centaines de paramètres.
Heureusement, ils ont des valeurs par défaut convenables et appropriées.
Dans la plupart des cas, pour pouvoir utiliser le système de courrier Postfix il vous suffira de renseigner deux ou trois paramètres :

• Le nom de domaine utilisé pour le courrier sortant
  
• Les domaines terminaux pour l'acheminement du courrier
• Les clients autorisés à utiliser Postfix

Le paramètre suivant déterminera le niveau et donc le nombre d'alertes envoyées au postmaster local :

• Les erreurs que nous rapportons au postmaster

D'ailleurs, si vous changez des paramètres d'un système Postfix, n'oubliez pas de lancer la commande :
# /etc/init.d/postfix reload pour que Postfix prenne en compte les nouvelles valeurs.

Si vous lancez Postfix sur une interface virtuelle du réseau, ou si votre machine lance d'autres systèmes de courrier sur des interfaces virtuelles, vous devrez renseigner les paramètres suivants :

• Le nom du serveur Postfix
• Le domaine de Postfix
• Les Réseaux de confiance
• Les adresses réseau de Postfix

Le paramètre myorigin indique le "vrai" nom du serveur qui apparaîtra dans tout courrier posté sur cette machine.
La valeur par défaut est le nom local de machine, $myhostname, qui a pour valeur par défaut le nom de la machine.
A moins de ne travailler que sur un très petit domaine, la valeur du paramètre $mydomain, qui a pour valeur par défaut le nom du domaine de la machine, peut être préférable.

Ce paramètre permet de renseigner postfix sur la machine qui a posté.

Exemples:

myorigin = $myhostname (défaut)

myorigin = $mydomain (peut être choisi)

Le paramètre mydestination indique quels sont les domaines que cette machine déservira localement, au lieu de transmettre à  une autre machine.
Le valeur par défaut la machine elle-même.

Vous pouvez indiquer aucun, un ou plusieurs noms de domaine, sous la forme /chemin/fichier et/ou la lecture de tables : type:nom, en séparant les différentes entrées par des espaces et/ou des virgules.
Un /chemin/nom est remplacé par son contenu; type:nom demande qu'une lecture de table soit faite, en général on utilise la base de données virtual.

Si votre machine est un serveur de mails pour son domaine tout entier, vous pouvez utiliser la variable $mydomain.

Exemples:

Par défaut:
mydestination = $myhostname localhost.$mydomain

Serveur de messagerie pour tout un domaine
mydestination = $myhostname localhost.$mydomain $mydomain

Machine avec multiples enregistrements A :
mydestination = $myhostname localhost.$mydomain www.$mydomain ftp.$mydomain

Attention: afin d'éviter des boucles de routage du courrier, vous devez énumérer tous les noms (hostnames) de la machine, y compris $myhostname, et localhost.$mydomain.

Par défaut, le Postfix transmettra le courrier pour des clients dans les réseaux autorisés et dans des domaines autorisés.

Les réseaux autorisés de client sont définis par le paramètre de mynetworks.
Par défaut Postfix autorise tous les clients dans les sous-réseaux d'IP attachés à la machine locale.

Les domaines autorisés de client sont définis par le paramètre de configuration de relay_domains.
Par défaut les clients de confiances sont les noms (hostnames) du domaine(s) énuméré(s) dans mydestination .

Il est d'abord nécessaire de mettre en place un alias associant le postmaster à une personne réelle.
Cet alias doit être défini, de sorte que les gens puissent signaler des problèmes de distribution du courrier.
Le système Postfix lui-même signale également des problèmes au postmaster.

Vous ne serez peut être pas intéressé par tous les types de rapports d'erreurs, ainsi ce mécanisme de reportage est configurable.
Par défaut seul les problèmes sérieux sont signalés au postmaster (ressource, logiciel) :

Par défaut:
notify_classes = resource, software

La signification des différentes classes de rapport sont les suivantes :

bounce
Une copie du courrier non livrable est envoyée au postmaster.
Si le courrier est non livrable, un prétendu avis de non-livraison simple est envoyé, avec une copie du message qui n'a pas été fourni.
Pour des raisons d'intimité, la copie de postmaster d'un avis de non-livraison simple est tronquée après les en-têtes de messages originaux.
Si un avis de non-livraison simple est non livrable, le postmaster reçoit un double avis de non-livraison avec une copie de l'avis de non-livraison simple entier. Voyez également le dispositif luser_relay.
Le message d'alerte qui accompagne la copie du message original est appelé bounce.

2bounce
Deux messages de bounce sont envoyés au postmaster.

delay
Le postmaster est informé de tout courrier qui a été retardé. Dans ce cas, le postmaster reçoit les en-têtes du message seulement.

policy
Le postmaster est informé des demandes de client qui ont été rejetées en raison des restrictions de la politique (ECU).
Le postmaster reçoit une transcription entière de la session smtp.

protocol
Le postmaster est informé des erreurs de protocole (côté de client ou de serveur) ou les tentatives d'un client d'exécuter des commandes non implémentées. Le postmaster reçoit une transcription entière de la session de smtp.

resource
Le postmaster est informé des raisons de non livraison du courrier liées à des problèmes de ressource (par exemple, une erreur lors de l'écriture dans le répertoire de la file d'attente).

software
Le postmaster est informé des raisons de non livraison de courrier suite à des problèmes logiciels.

Le paramètre myhostname décrit le nom complet et conforme (fqdn) de la machine utilisant le système Postfix.
$myhostname est la valeur par défaut ainsi que dans beaucoup d'autres paramètres de configuration de Postfix.

Par défaut, myhostname est le nom local de la machine.
Si votre nom de machine n'est pas complet et conforme, ou si vous lancez Postfix sur une interface virtuelle, il est nécessaire de préciser le nom a utiliser.
C'est sous ce nom que la machine s'annonce lors du HELO.

Exemples:

myhostname = host.local.domain (le hostname local n'est pas FQDN)

myhostname = host.virtual.domain (interface virtuelle)

myhostname = virtual.domain (interface virtuelle)

Le paramètre mydomain indique le domaine parent de $myhostname.
Par défaut, il vaut $myhostname sans la première partie du nom. (sauf si on est un "top-level-domain cad : .fr, .com, ...)

Exemples:

mydomain = local.domain

mydomain = virtual.domain (interface virtuelle)

Le paramètre mynetworks prend comme valeur la liste des réseaux de confiance de Postfix.
Cette information peut être utilisée par les dispositifs anti-UCE pour identifier les clients smtp de confiance qui sont autorisés à utiliser le relais de messagerie Postfix.

Vous pouvez indiquer la liste de réseaux de confiance dans le fichier main.cf, ou vous pouvez laisser Postfix déduire la liste pour vous.
Par défaut Postfix effectuent le travail pour vous.
Ces réseaux seront considérés comme des réseaux locaux.

Défaut:

mynetworks_style = subnet

La signification des valeurs est la suivante :

class
Clients smtp de confiance dans les réseaux de la classe A/B/C pour lesquels Postfix accepte le relayage.
Ne faites pas ceci avec un emplacement de dialup - Postfix ferait alors confiance au réseau de votre fournisseur tout entier.
Au lieu de cela, indiquez "à  la main" les réseaux explicites , comme décrit ci-dessous .

subnet (défaut)
Fait confiance aux clients smtp dans les sous-réseaux d'IP de Postfix.

host
Confiance seulement la machine locale.

Alternativement, vous pouvez indiquer les réseaux "à  la main", dans ce cas le Postfix ignore le paramètre mynetworks_style.
Pour indiquer la liste de réseaux de confiance, indiquez les plages d'adresses réseau dans la notation de CIDR (network/mask), par exemple:

mynetworks = 168.100.189.0/28, 127.0.0.0/8

Vous pouvez également indiquer le nom absolu d'un fichier de valeurs au lieu d'énumérer les valeurs dans le fichier main.cf.

Le paramètre inet_interfaces indique toutes les adresses d'interface réseau sur lesquelles le système Postfix doit écouter.
Le courrier adressé à  l'utilisateur @ [ adresse réseau ] sera fourni localement, comme si il était adressé à  un domaine énuméré dans $mydestination.

Par défaut Postfix écoute sur toutes les interfaces actives.
Si vous voulez recevoir des mails sur des interfaces virtuelles, vous devrez indiquer sur quelles interfaces vous écouter.

Vous devez indiquer les interfaces explicites de la machine pour les receptions non-virtuelle de courrier de la machine elle-même : les attentes de mails non-virtuelles ne doivent jamais écouter sur les interfaces virtuelles où vous auriez une boucle de mails.

Exemples:

Par défaut:
inet_interfaces = all

Centre serveur virtuel:
inet_interfaces = virtual.host.name (domaine virtuel)
inet_interfaces = $myhostname localhost.$mydomain (écoute non-virtuelle)
inet_interfaces = 10.0.0.1 ( avant, faire #ifconfig add eth0:1 10.0.0.1 ; route add 10.0.0.1 dev eth0:1 )

Postfix offre une variété de paramètres qui permettent de limiter la distribution de courrier publicitaire non sollicité.
(ECU : unsollicited commercial e-mail).

Par défaut, le serveur SMTP Postfix n'acceptera que le courrier venant du réseau considéré comme local, du domaine local, ou des domaines acceptés par postfix, de sorte que votre système ne puisse pas être employé comme un relais pour les courriers indésirables d'étrangers.

Le texte dans cette partie décrit comment vous pouvez installer des politiques plus ciblées d'anti-UCE qui empêcheront la livraison des e-mails non désirés, par exemple avec des listes d'accès dans le style de sendmail ou avec les noms de serveurs RBL
(real-time blackhole list ou reject black list).

Sauf indication contraire, tous les paramètres décrits ici sont dans le fichier de main.cf.
Si vous changez des paramètres d'un système Postfix, n'oubliez pas de lancer la commande reload de postfix.

Le paramètre header_checks restreint les données autorisée suivant l'entête des messages reçus.
La valeur du paramètre doit pointer vers une ou plusieurs tables décrivant des en-têtes interdits.

Par défaut :

On permet n'importe quoi dans des en-têtes de message.

Syntaxe :

Indiquez une liste de tables de consultation. Toutes les fois qu'une en-tête est listée dans une table, l'action dépend du résultat de consultation:

REJECT

Rejette le message, et note l'en-tête.

REJECT le texte...

Comme précédemment et envoie également le texte au créateur.

IGNORE

Supprime l'en-tête du message.

WARN

Note (mais ne rejette pas) l'en-tête avec un avertissement.

A ce niveau, l'indication d'un modèle d'en-tête avec OK n'est pas très utile.
Une règle avec OK affecte seulement l'en-tête étant assorti.
La prochaine en-tête peut annuler le résultat avec un REJET, ainsi, le courrier sera toujours rejeté.

Exemples (main.cf):

header_checks = regexp:/etc/postfix/header_checks

header_checks = pcre:/etc/postfix/header_checks

Avec comme fichier /etc/postfix/header_checks :

/^to: * friend@public\.com$/REJET

Le paramètre smtpd_client_restrictions permet de spécifier les clients qui ont le droit de faire des connexions smtp avec notre serveur.

Par défaut, cette restriction est appliquée lorque le client envoie la commande RCPT.
Pour que les restrictions soient prises en compte aussitôt que possible, indiquez smtpd_delay_reject = no dans le fichier de configuration main.cf de Postfix . Faire cela peut causer des résultats inattendus avec le logiciel client mal configuré.

Par défaut:

smtpd_client_restrictions =

Permette les raccordements smtp de n'importe quel client.

Syntaxe:

Indiquez une liste de restrictions, séparées par des espaces ou des virgules.
Les restrictions sont appliquées dans l'ordre indiqué, la première restriction qui marche a gagné.

Exemples:

smtpd_client_restrictions = hash:/etc/postfix/access, reject_maps_rbl

smtpd_client_restrictions = permit_mynetworks, reject_unknown_client

Restrictions:

reject_unknown_client
Rejette la connexion lorsque la résolution de nom du client est impossible.
Le paramètre unknown_client_reject_code indique le code de réponse aux requêtes rejetées (défaut: 450 ).

permit_mynetworks
Autorise toutes requêtes issues d'une machine d'un réseau listés dans $mynetworks .

check_client_access type:name
Recherche dans la table d'accès appelée le nom d'hôte du client, de domaine, l'adresse IP , ou les réseaux obtenus en dépouillant les moindres octets significatifs.
Rejette la connexion si le résultat est REJET ou "[4ou5]XX texte".
Permet la connexion si le résultat est OK ou RELAY ou numérique.
Autrement, traitez le résultat comme une autre liste de restrictions ECU.
Le paramètre d'access_map_reject_code indique le code de réponse pour le REJET (défaut: 554 ).

reject_maps_rbl
Rejete la requête lorsque l'adresse réseau du client est énumérée dans $maps_rbl_domains.
Le paramètre de maps_rbl_reject_code indique le code de réponse pour des requêtes rejetées (défaut: 554 ).

permit
reject
warn_if_reject
reject_unauth_pipelining

Voir les restrictions générales.

smtpd_helo_required est le paramètre qui détermine si les clients doivent envoyer une commande HELO ( ou EHLO) au début d'une session SMTP. Ce paramètre arrêtera le logiciel de quelques ECU.

Par défaut:
smtpd_helo_required = no

Par défaut, le serveur smtp postfix n'exige pas l'utilisation de HELO ( EHLO ).

Syntaxe:

Indiquez yes ou no .

Exemple:

smtpd_helo_required = yes

Le paramètre de smtpd_helo_restrictions permet de controler les données fournies par la commande HELO (EHLO).
Le logiciel de quelques ECU peut être arrêté en étant strict.

Par défaut, cette restriction est appliquée quand le client envoie la commande RCPT .
Pour que les restrictions soient prises en compte aussitôt que possible, indiquez smtpd_delay_reject = no dans le fichier de configuration main.cf de Postfix . Faire cela peut causer des résultats inattendus avec le logiciel client mal configuré.

Par défaut:

smtpd_helo_restrictions =

Par défaut, aucune analyse des données est effectuée.
Il y a beaucoup de logiciel defectueux ou mal configuré sur Internet.

Syntaxe:

Indiquez une liste de restrictions, séparée par des espaces ou des virgules.
Les restrictions sont appliquées dans l'ordre indiqué, la première restriction qui marche a gagné.

En plus des restrictions qui sont spécifiques aux paramètres de la commande HELO (EHLO), vous pouvez également indiquer des restrictions basées sur le nom d'hôte et l'adresse IP des clients.

Exemple:

smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname

Restrictions:

reject_invalid_hostname

Rejette la requête lorsque la syntaxe du nom d'hôte normalement fourni par la commande HELO ('EHLO) est invalide. invalid_hostname_reject_code indique le code de réponse aux requêtes rejetées (défaut: 501).

 

permit_naked_ip_address

Autorise la commande HELO (EHLO) à envoyer l'adresse IP du client "nue", sans les crochets [ ] spécifié par la RFC.
Malheureusement, de nombreux clients de courrier électronique procèdent de cette façon.

 

reject_unknown_hostname

Rejette la requête si la résolution inverse sur le nom d'hôte dans la commande HELO (EHLO) du client est impossible. unknown_hostname_reject_code indique le code de réponse aux requêtes rejetées (défaut: 450 ).

 

reject_non_fqdn_hostname

Rejette la requête si le nom d'hôte fourni par la commande HELO (EHLO) du client n'est pas complet et conforme, selon les exigences de la RFC.
non_fqdn_reject_code indique le code de réponse aux requêtes rejetées (défaut: 504 ).

check_helo_access type:nom

 

Recherche dans la table d'accès indiquée le nom d'hôte, le domaine, l'adresse IP ou de réseau de la commande HELO puis :
rejette la requête si le résultat est REJET ou "[4ou5 texte]XX ".
Autorise la requête quand le résultat est OK ou RELAY ou numérique.
Autrement, traite le résultat comme une autre liste de restrictions d'ECU.
Le paramètre access_map_reject_code indique le code de réponse pour le REJET (défaut: 554 ).

reject_maps_rbl
reject_unknown_client permit_mynetworks
check_client_access maptype:mapname

Voir les restrictions sur le nom d'hôte l'adresse IP des clients.

permit reject
warn_if_reject
reject_unauth_pipelining

Voir les restrictions générales.

Le paramètre strict_rfc821_envelopes permet de contrôler la tolérance de Postfix sur le format des adresses données dans la commande MAIL FROM ou RCPT.
Malheureusement, le programme Sendmail tolère un bon nombre de comportements non standards, ainsi beaucoup de logiciels clients de courrier pensent l'utiliser.
Être conforme à la RFC arrête non seulement le courrier non désiré, mais il bloque également le courrier légitime des applications courrier mal écrites.

Par défaut:

strict_rfc821_envelopes = no

Par défaut, le serveur SMTP Postfix accepte n'importe quelle forme d'adresse ce qui peut se comprendre, y compris les adresses qui contiennent des commantaires du style RFC 822, ou des adresses non incluses dans <>.
Il y a beaucoup de logiciels defectueux ou mal configurés sur l'Internet.

Exemple:

strict_rfc821_envelopes = yes

Le paramètre smtpd_sender_restrictions limite l'accès au système suivant l'adresse de l'expéditeur signalé par la commande MAIL FROM.

Par défaut, cette restriction est appliquée quand le client envoie la commande RCPT .
Pour que les restrictions soient prises en compte aussitôt que possible, indiquez smtpd_delay_reject = no dans le fichier de configuration main.cf de Postfix . Faire cela peut causer des résultats inattendus avec un logiciel client mal configuré.

Par défaut:

smtpd_sender_restrictions =

Par défaut, Postfix accepte le courrier quelle que soit la valeur donnée par la commande MAIL FROM.

Syntaxe:

Indiquez une liste de restrictions, séparées par des espaces ou des virgules.
Les restrictions sont appliquées dans l'ordre indiqué, la première restriction qui marche a gagné.

En plus des restrictions spécifiques sur l'adresse de l'expéditeur, vous pouvez également indiquer des restrictions basées sur l'information passée avec la commande HELO/EHLO, et sur le nom d'hôte et l'adresse IP des clients.

Exemple:

smtpd_sender_restrictions = hash:/etc/postfix/access, reject_unknown_sender_domain

Restrictions:

reject_unknown_sender_domain

Rejette la requête lorsque l'adresse de l'expéditeur fournie n'a pas de correspondance MX ou DNS.
Le paramètre unknown_address_reject_code indique le code de réponse pour des requêtes rejetées (défaut: 450 ).
La réponse est toujours 450 en cas d'erreur DNS temporaire.

 

check_sender_access type:nom

 

Recherche dans la table d'accès indiquée l'adresse de l'expéditeur, le nom d'hôte, le domaine, ou nomlocal@. puis:
Rejette la requête si le résultat est REJET ou "[4ou5]XX ".
Autorise la requête si le résultat est OK ou RELAY ou numérique.
Autrement, traite le résultat comme une autre liste de restrictions ECU.
Le paramètre access_map_reject_code indique le code de résultat pour des requêtes rejetées (défaut: 554 ).

reject_non_fqdn_sender

Rejette la requête lorsque l'adresse donnée par la commande MAIL FROM du client n'est pas complète et conforme.
non_fqdn_reject_code indique le code de réponse aux requêtes rejetées (défaut: 504 ).

 

reject_sender_login_mismatch

Rejette la requête lorsque $smtpd_sender_owner_maps indique un propriétaire dans le MAIL FROM de l'adresse, mais le client (SASL) n'est pas entré en tant que ce COURRIER de propriétaire d'adresse; ou quand le client (SASL) est entré, mais le nom d'ouverture de client ne possède pas le COURRIER de l'adresse selon $smtpd_sender_login_maps .

 

permit_naked_ip_address

reject_invalid_hostname

reject_unknown_hostname

reject_non_fqdn_hostname

check_helo_access type : nom

Voir les restrictions sur le nom d'hôte par la commande HELO (EHLO).

reject_maps_rbl

reject_unknown_client

permit_mynetworks

check_client_access type : nom

Voir les restrictions sur le nom d'hôte et l'adresse IP des clients.

permit

reject

warn_if_reject

reject_unauth_pipelining

Voir les restrictions générales.

Le paramètre smtpd_recipient_restrictions limite l'accès au système suivant l'adresse du distinataire signalé par la commande RCPT TO.

Par défaut :

smtpd_recipient_restrictions = permit_mynetworks, check_relay_domains

Par défaut, le serveur Postfix relaye le courrier :

Des clients dont l'adresse d'IP est listée dans $mynetworks.
Des clients dont le nom d'hôte (hostname) est listé dans $relay_domains ou un sous-domaine.
Des clients qui choisissent des destinations listées dans $relay_domains ou un sous-domaine, excepté les adresses qui contiennent le cheminement expéditeur-destinataire spécifié (user@elsewhere@domain).
En plus de ce qui précède, le serveur Postfix accepte, par défaut, le courrier pour lequel Postfix est la destination finale listée dans $inet_interfaces, $mydestination ou $virtual_maps.

Syntaxe :

Indiquez une liste de restrictions, séparée par des espaces ou des virgules.
Les restrictions sont appliquées dans l'ordre indiqué, la première restriction qui marche a gagné.

En plus des restrictions qui sont spécifiques à l'adresse du destinataire, vous pouvez également indiquer des restrictions basées sur l'information passée avec la commande HELO/EHLO, et sur le nom d'hôte et l'adresse IP des clients.

Exemple :

smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination

Note: vous devez indiquer au moins une des restrictions suivantes : rejet, check_relay_domains ou reject_unauth_destination. Sinon, Postfix refusera de recevoir le courrier.

Restrictions:

check_relay_domains

Accepte la requête lorsqu'une des condition suivantes est satisfaite :

• Le nom d'hôte du client (hostname) est listé dans $relay_domains ou un sous domaine de celui-ci.
• L'adresse de destination est listée dans $relay_domains ou un sous-damaine , et l'adresse ne contient pas de cheminement expéditeur-destinataire spécifié (user@elsewhere@domain).
• Postfix est la destination finale pour : toutes les destinations qui sont spécifiées par $mydestination, $inet_interfaces ou $virtual_maps.
  Autrement, il y a rejet de la requête.
  Le paramètre relay_domains_reject_code indique le code de réponse pour des requêtes rejetées (défaut: 554).

 

permit_auth_destination

Ignore le nom d'hôte du client (hostname). Accepte la requête quand une des conditions suivantes est satisfaite :

• L'adresse de destination est dans $relay_domains ou un sous-damaine , et l'adresse ne contient pas de cheminement expéditeur-destinataire spécifié (user@elsewhere@domain).
• Postfix est la destination finale pour : toutes les destinations qui sont spécifiées par $mydestination, $inet_interfaces ou $virtual_maps.
  
  

Autrement, Postfix effectue aussi les restrictions suivantes :

reject_unauth_destination

Ignore le nom d'hôte du client (hostname). Rejette la requête quand une des conditions suivantes est vraie :

• L'adresse de destination est listée dans $relay_domains ou un sous-domaine , et l'adresse ne contient pas de cheminement expéditeur-destinataire spécifié (user@elsewhere@domain),
• Postfix est la destination finale pour toutes les destinations qui sont spécifiées par $mydestination, $inet_interfaces ou $virtual_maps.

relay_domains_reject_code est le paramètre qui spécifie le code de réponse suite à un rejet (par défaut: 554 ).

permit_mx_backup

Accepte la requête lorsque le système local de courrier est le serveur MX pour la destination .
Ceci inclus le cas où le système local de courrier est la destination finale.
Cependant, le serveur de SMTP n'expédiera pas le courrier avec les adresses qui contiennent un cheminement expéditeur-destinataire spécifié (user@elsewhere@domain), employez le paramètre facultatif
permit_mx_backup_networks pour exiger également que les centres serveurs MX primaires apartiennent à une liste de plages d'adresses réseau.

 

 

Paramètres appropriés de configuration : permit_mx_backup_networks, $mydestination, $inet_interfaces.

check_recipient_access type:nom

Recherche dans la table d'accès indiquée l'adresse de destination, le domaine , ou nomlocal@. puis :
Rejette la requête si le résultat est REJET ou "[4ou5]XX ".
Permet la requête si le résultat est OK ou RELAY ou numérique.
Autrement, traite le résultat comme une autre liste de restrictions ECU.
Le paramètre access_map_reject_code indique le code de résultat pour des requêtes rejetées (défaut: 554 ).

reject_unknown_recipient_domain

Rejette la requête lorsque l'adresse de l'expéditeur fournie n'a pas de correspondance MX ou DNS..
Le paramètre unknown_address_reject_code indique le code de réponse pour des requêtes rejetées (défaut: 450).
La réponse est toujours 450 en cas d'erreur de résolution DNS temporaire.

 

reject_non_fqdn_recipient

Rejette la requête lorsque l'adresse du client renseignée dans la commande RCPT TO n'est pas complète et conforme.
(fqdn : fully-qualified domain name)

 

reject_unknown_sender_domain

reject_non_fqdn_sender

check_sender_access maptype : mapname

reject_sender_login_mismatch

Voir les restrictions sur l'adresse de l'expéditeur..

 

permit_naked_ip_address

reject_invalid_hostname

reject_unknown_hostname

reject_non_fqdn_hostname

check_helo_access type : nom

Voir les restrictions sur le nom d'hôte par la commande HELO (EHLO).

reject_maps_rbl

reject_unknown_client

permit_mynetworks

check_client_access type : nom

Voir les restrictions sur le nom d'hôte et l'adresse IP des clients.

 

permit

reject

warn_if_reject

reject_unauth_pipelining

Voir les restrictions générales.

Les restrictions de la commande d'ETRN ne sont pas vraiment des restrictions ECU.
Le paramètre smtpd_etrn_restrictions limite les domaines qui peuvent être indiqués dans des commandes ETRN, et quels sont les clients qui peuvent utiliser la commande ETRN.

Pae défaut:

smtpd_etrn_restrictions =

Par défaut, le serveur SMTP Postfix accepte n'importe quelle commande ETRN de n'importe quel client.

Syntaxe :

Indiquez une liste de restrictions, séparée par des espaces ou des virgules.
Les restrictions sont appliquées dans l'ordre indiqué, la première restriction qui marche a gagné.

 

En plus des restrictions qui sont spécifiques noms de domaine utilisant ETRN, vous pouvez également indiquer des restrictions basées sur l'information passée avec la commande de HELO/EHLO, et sur le nom d'hôte et l'adresse IP des clients.

Exemple:

smtpd_etrn_restrictions = permit_mynetworks, hash:/etc/postfix/etrn_access, reject

Restrictions:

check_etrn_access type:nom

 

Recherche dans la table d'accès indiquée le domaine spécifié avec la commande ETRN ou le domaine parent, puis :.
Rejette la requête si le résultat est REJET ou "[4ou5]XX ".
Accepte la requête si le résultat est OK ou RELAY ou numérique.
Autrement, traite le résultat comme une autre liste de restrictions ECU.
Le paramètre access_map_reject_code indique le code de résultat pour des requêtes rejetées (défaut: 554 ).

 

 

permit_naked_ip_address

reject_invalid_hostname

reject_unknown_hostname

check_helo_access type : nom

Voir les restrictions sur le nom d'hôte par la commande HELO (EHLO).

 

reject_maps_rbl

reject_unknown_client

permit_mynetworks

check_client_access type : nom

Voir les restrictions sur le nom d'hôte et l'adresse IP des clients.

 

permit

reject

warn_if_reject

reject_unauth_pipelining

Voir les restrictions générales.

Les restrictions qui suivent peuvent être utilisées pour les noms ou adresses des clients, pour le nom donné par la commande HELO (EHLO), pour les adresses des expéditeurs ou destinataires du courrier.

Restrictions:

permit

Accepte la requête. Cette restriction est habituellement utilisée à la fin de la list des restrictions pour rendre la police par défaut plus explicite.

reject

Rejet de la requête. Cette restriction est aussi habituellement utilisée à la fin de la list des restrictions pour rendre la police par défaut plus explicite. Le paramètre reject_code spécifie le code de réponse aux requêtes rejetées (par défaut: 554 ).

 

warn_if_reject

Change la signification de la prochaine restriction, de sorte qu'il note un avertissement au lieu de rejeter une requête (rechercher les fichiers journal qui contiennent " reject_warning "). C'est utile pour examiner de nouvelles restrictions dans un environnement en direct sans risquer la perte inutile de courrier.

reject_unauth_pipelining

Rejette la requête quand le client envoie des commandes SMTP avant que Postfix soutienne réellement la canalisation de commande
de SMTP.
Ceci arrête le courrier du logiciel de courrier qui utilise incorrectement la canalisation de commande SMTP pour accélérer les livraisons.

permit_mx_backup_networks

limite l'utilisation du dispositif de commande de relais permit_mx_backup aux destinations dont les serveurs MX primaires font partis de la liste des réseaux passée en paramètre.

permit_mx_backup_networks =

Tous les réseaux sont autorisés par défaut.

Syntaxe :

Indiquer une liste de plages d'adresses réseau dans la notation CIDR (network/mask), par exemple :

permit_mx_backup_networks = 168.100.0.0/16

vous pouvez également indiquer le nom absolu d'un fichier de modèle dans le fichier main.cf au lieu d'énumérer
tous les modèles.

maps_rbl_domains

Ce paramètre commande le comportement de la restriction reject_maps_rbl qui peut apparaître comme un élément d'une liste de restrictions par nom/adresse client.

 

Par défaut:

 

maps_rbl_domains = blackholes.mail-abuse.org

Note : Les consultations RBL sont neutralisées par défaut.

Syntaxe :

Domaines DNS qui mettent le client sur la liste noire d'adresses IP. Un centre serveur est mis sur la liste noire quand son adresse IP inverse est énumérée comme sous domaine dans n'importe quel domaines énumérés
dans $maps_rbl_domains.

relay_domains

Ce paramètre commande le comportement des check_relay_domains, reject_unauth_destination et des restrictions permit_auth_destination qui peuvent apparaître en tant qu' élément d'une liste de restrictions d'adresse pour la destination.

 

Par défaut:

relay_domains = $mydestination

Par défaut, le serveur SMTP Postfix relaye les e-mails :

• des clients dont l'adresse d'IP est définie dans $mynetworks,
• des clients dont le nom d'hôte (hostname) est définit dans $relay_domains, ou un sous-domaine,
• des clients pour des destinations définient dans $relay_domains ou un sous-domaine, excepté les adresses qui contiennent un cheminement expéditeur-destinataire spécifié (user@elsewhere@domain).
  
  

Syntaxe :

Spécifier aucun, un ou plusieurs noms de domaine , /dossier/nomdufichier et/ou type : nom de la table d'accès, séparés par des espaces ou des virgules. Un /dossier/nomdufichier est remplacé par son contenu, et pour type : nom une requette est faite sur la table au lieu d'une simple comparaison de chaine.

Une adresse de serveur ou de destination est compris dans $relay_domains quand son nom de domaine ou parent apparait dans la liste des noms, des fichiers ou tables d'accès énumérées dans $relay_domains.

smtpd_sender_login_maps

Ce paramètre indique la propriété du MAIL FROM des adresses, il est employé par la restriction d'adresse d'expéditeur reject_sender_login_mismatch.

 

Par défaut:

smtpd_sender_login_maps =

Syntaxe:

Spécifier aucun, un ou plusieurs type:nom table de résolution, séparées par des espaces ou des virgules.
Les restrictions sont appliquées dans l'ordre indiqué. Les tables Regexp sont permises.

Chaque entrée de table indique une adresse expéditeur et le nom de login qui possède l'adresse.
L'ordre de recherche est :

 

user@domain owner

Cette forme a la priorité la plus élevée.

 

user owner

Ceci est associé à user@site lorsque "site" est égal à $myorigin, lorsque "site" est dans $mydestination , ou lorsqu'il est dans la liste $inet_interfaces.

 

@domain owner

Ceci associe chaque adresse dans le domaine indiqué, et à la plus basse priorité.

Établir un système à  rendement élevé de distribution du courrier est une chose, la construction d'un qui ne frappe pas sur les autres en est une autre.
Quelques sytèmes de courrier souffrent du syndrome "thundering herd " et inondent littéralement d'autres systèmes avec leur courrier.

Le Postfix essaie d'être un expéditeur rapide et un bon voisin en même temps.
Du côté de la réception, le serveur SMTP Postfix se défend contre les clients malveillants ou confus.

Sauf indication contraire, tous les paramètres décrits ici sont dans le fichier de main.cf.
Si vous changez des paramètres d'un système Postfix, n'oubliez pas de lancer la commande reload de Postfix.

Le paramètre default_process_limit (défaut: 50) donne le contrôle direct des flux d'arrivée et de livraison.
Ce paramètre commande le nombre de processus concourants qui mettent en application un service de Postfix (client de smtp, serveur de smtp, livraison locale, etc.).

Sur les systèmes réduits, ou sur des systèmes reliés par l'intermédiaire des réseaux dialup, un default_process_limit de 10 est probablement mieux proportionné. Employez une plus grande valeur si votre machine doit traiter un nombre important de courrier.

Vous pouvez dépasser cet arrangement pour des démons spécifiques de Postfix en éditant le fichier master.cf.
Par exemple, si vous ne souhaitez pas recevoir 50 messages de smtp en même temps, vous pourriez indiquer:

 
# ====================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (50)
# ====================================================================
. . .
smtp      inet  n       -       -       -       5       smtpd

Imaginez que vous ayez des tonnes de disques et de mémoires et que votre serveur Postfix soit configuré pour pouvoir lancer plus de 1000 clients smtp en même temps.
Félicitations. Mais voulez-vous vraiment établir 1000 connexions simultanés avec le même système distant ? Probablement pas.

Le gestionnaire de files d'attente de Postfix vient à  votre secours.
Ce programme met en application l'analogue de la stratégie de contrôle "slow start" du flux TCP :
Lorsque Postfix délivre un site distant, il n'établi qu'un nombre restreint de connexion pour commencer, puis il augmente le débit tant que tout ce passe bien, il reviendra en arrière si il y a saturation.

Le paramètre initial_destination_concurrency (défaut: 2) indique combien de messages seront envoyés au début à  la même destination avant d'adapter le flux de la livraison.
Naturellement, cette valeur est efficace seulement s'il n'excède pas la limite des processus et la limite du nombre de connexion simultanées pour une destination sur un canal spécifique de transport de courrier.

Le paramètre default_destination_concurrency_limit (défaut: 10) indique combien de messages peuvent être envoyés à  la même destination simultanément.
Vous pouvez dépasser cette valeur pour les canaux spécifiques de livraison ( locaux, smtp, UUCP etc.).
Le fichier main.cf recommande ce qui suit:

local_destination_concurrency_limit = 2

default_destination_concurrency_limit = 10

Le paramètre local_destination_concurrency_limit indique combien de messages seront livrés simultanément au même destinataire local.
La limite recommandée est basse parce que la livraison à  la même boîte aux lettres doit se produire séquentiellement, ainsi le parallélisme massif n'est pas utile.

Une autre bonne raison de limiter la simultanéité de la livraison au même destinataire : si le destinataire a une commande shell importante
dans son fichier .forward, ou si le destinataire est une liste de diffusion, nous ne voulons pas envoyer trop d'exemplaires en même temps.

Une limite pour l'envoi simultané à une destination de 10 pour la livraison de smtp semble assez pour charger sensiblement un système sans "l'asseoir sur ses genoux".
Faites attention si vous augmentez ce nombre.

Le paramètre default_destination_recipient_limit (défaut: 50) indique le nombre maximum de destinataires pour une copie d'e-mail envoyée avec un agent de livraison Postfix ( smtp , UUCP , etc...).
Si un message a plus que $default_destination_recipient_limit destinataires pour le même site, la liste des destinataires sera cassée vers le haut en plus petites listes, et des copies multiples du message seront envoyées.

Vous pouvez dépasser cette valeur pour les agents spécifiques de la livraison Postfix ( smtp, UUCP, etc.).
Par exemple:

uucp_destination_recipient_limit = 100
limiterait le nombre de destinataires par livraison UUCP à 100.

Vous devez faire attention en augmentant cette limite; quelques serveurs smtp avortent la connexion lorsqu'ils manquent de mémoire ou quand une limite est atteinte, ainsi le courrier ne passera pas.

Le paramètre smtpd_recipient_limit (défaut: 1000) indique combien de destinataires le serveur smtp prendra par livraison.
C'est plus que n'importe quel client smtp raisonnable enverrait.
La limite existe juste pour protéger le système local de courrier contre un client malveillant ou confus.

Le paramètre defer_transports vous permet d'indiquer quel courrier devrait toujours être reporté jusqu'à ce que le Postfix soit explicitement invité à le livrer.

Un petit site qui serait connecté seulement de temps en temps, et qui veut reporter toutes les livraisons jusqu'à ce que la commande sendmail -q soit exécuté (par exemple, un petit script PPP dialout) emploierait:

defer_transports = smtp

Un ISP peut employer le dispositif defer_transports pour les clients qui sont souvent hors connexion.
Le client peut déclencher la livraison en publiant une commande ETRN au port de smtp.
Les exemples suivants montrent comment configurer un tel client:

/etc/postfix/main.cf:

defer_transports = hold

Vous pouvez indiquer tout nombre de transports ici. L'exemple en donne qu'un.

/etc/postfix/ transport :

customer.com   hold:[gateway.customer.com ]

customer.com   hold:[gateway.customer.com ]

[ ] sont nécessaires pour éviter les résolutions MX, qui pourraient se diriger vers votre machine locale.
La deuxième entrée est nécessaire seulement si vous voulez transmettre par relais le courrier pour des clients du sous-domaine.

/etc/postfix/master.cf:

hold   unix   -   -   n   -   -   smtp

C'est juste l'entrée de master.cf pour le smtp régulier, avec le premier champ changé en hold.

Lorsqu'un agent de livraison Postfix ( smtp, local, UUCP, etc...) ne peut pas livrer un message, il peut blâmer le message lui-même ou la partie réçue.

• Si l'agent de la livraison n'arrive pas à livrer le message, le gestionnaire de files d'attente marque ce message à une date future (décalage paramètrable), ainsi il sera ignoré pendant un moment par le gestionnaire de file.
  Si la deuxième tentative échoue, une nouvelle marque est déposée, le décalage correspondant au double de l'âge du message.
  Ainsi, le temps écoulé entre deux tentatives double à chaque échec. Cette méthode s'appelle l'archivage exponentielle.

• Si l'agent de la livraison n'arrive pas à livrer un message reçu (par exemple un utilisateur destinataire local, ou un hôte à distance), le gestionnaire de files d'attente marque non seulement ce message à une date future, mais il met également la partie reçue dans une liste "morte" pour qu'il soit sauté pendant un certain temps.
  
  

Comme vous pouvez le penser, ce processus entier est controlé par un groupe de petits paramètres.

 

queue_run_delay (défaut: 1000 secondes)

Temps que le gestionnaire de files attent avant de rebalayer la file d'attente pour le courrier reporté.

maximal_queue_lifetime (défaut: 5 jours)

Temps maximal qu'un message reste dans la file d'attente avant qu'il soit renvoyé comme non livrable.

minimal_backoff_time (défaut: 1000 secondes)

Temps d'attente minimal qu'un message restera sans être traité.

maximal_backoff_time (défaut: 4000 secondes)

Temps d'attente maximal après un échec de livraison.

qmgr_message_recipient_limit (défaut: 1000)

Limite la taille de la liste "morte" des destinations.

Tout d'abord, aucune défense ne vous protégera contre une attaque de type "denie of service".
Nous ne voulons pas soulever des espérances impossibles.
Mais il y a des choses simples à mettre en place afin de traiter des programmes clients confus ou malveillants.

Quelques défenses font partie d'une stratégie plus générale : par exemple, combien de temps une ligne de texte peut être prise en compte avant qu'elle soit cassée en morceaux, et quelle quantité de texte peut on porter dans une en-tête de message multiligne.
Voir la documentation sur le controle des ressources pour plus de détails.

Il y a incrémentation d'un compteur d'erreur du serveur SMTP Postfix toutes les fois qu'une demande de client est non reconnue ou non implementée, ou toutes les fois qu'une demande de client viole les restrictions ECU ou d'autres raisons.
Le compteur d'erreur est remis à  zéro quand un message est transféré avec succès.

A mesure que le compteur d'erreur augmente, le serveur smtp change de comportement.
L'idée est de limiter les dommages en ralentissant le client.

Le comportement est commandé par les paramètres suivants:

smtpd_error_sleep_time (défaut: 5 secondes)

Quand le compteur d'erreurs est petit, le serveur de smtp fait une pause seulement en signalant un problème au client. Le but est d'empêcher les clients naïfs d'entrer dans une boucle connexion-erreur-déconnexion.

 

smtpd_soft_error_limit (défaut: 10)

Quand le compteur d'erreurs dépasse cette valeur, le serveur smtp s'arrète error_count secondes avant de répondre à  une demande de client.

 

smtpd_hard_error_limit (défaut: 100)

Quand le compteur d'erreurs dépasse cette valeur, le serveur SMTP se déconnecte.

Malheureusement, le serveur SMTP Postfix ne sait pas encore limiter le nombre de raccordements du même client , autre qu'en limitant le nombre de processus pour le serveur smtp (voir limitation des processus ).
Les choses auraient pu être plus mauvaises : Il existe des serveurs de mails qui n'ont pas le moyen de limiter les processus lancés.

Le système Postfix a été conçu pour fonctionner avec un budget fini de mémoire.

Pour cela, il y a des limites configurables sur la taille des objets en mémoire tels que des fragments de lignes de texte, sur le nombre d'instances de tels objets, et le temps qu'une opération peut prendre.
En outre, les stratégies sont en place pour traiter l'épuisement de ressource.

L'idée est de continuer à fonctionner dans des conditions difficiles, sans agraver le problème d'avantage.

La première étape pour garder un budget fixe de ressource mémoire consiste à limiter la taille de chaque objet .
Une fois que la taille des objets est limitée, la consommation totale de mémoire est limitée en limitant le nombre d'objets.
Simple, non?

line_length_limit (défaut: 2048 octets)
Combien de temps une ligne de texte peut être prise en compte avant d'être cassée en morceaux.
Tous les programmes périphériques de Postfix (serveur smtp , client smtp , collecte locale et livraison locale) utilisent cette limite de longueur de ligne lorsque les données lues emmanent d'une source qui nest pas digne de confiance. Les longues lignes sont réassemblées à la livraison.

 

header_size_limit (défaut: 102400 octets)
Quelle quantité de texte peut être portée dans un en-tête de message multiligne.
Le texte de l'en-tête qui ne sera pas compris dans les $header_size_limit octets se retrouvera dans le corps du message.
Cette limite est utilisée par cleanup qui réécrit le code de l'en-tête.

 

extract_recipient_limit (défaut: 10240 destinataires)
Nombre de destinataires que Postfix extraira des en-têtes de message avant de renoncer.
Ceci limite les dommages qu'un programme pourrait faire avec la commande "sendmail - t".

Les paramètres suivants limitent la taille des fichiers stockés dans le système :

message_size_limit (défaut: 10240000 octets)
Taille maximale d'un message dans une file d'attente de Postfix, y compris l'enveloppe (expéditeur, destinataire, etc.).

queue_minfree (défaut: aucune restriction)
Combien d'espace libre en octets sont nécessaires dans le répertoire de file d'attente.
Le serveur SMTP refusera de distribuer le courrier tant que l'espace minimum n'est pas disponible.
Il n'y a aucune limite par défaut, cependant, une bonne idée est d'avoir besoin de plusieurs fois la valeur de $message_size_limit de sorte que le système de courrier ne se coince pas sur un grand message.

bounce_size_limit (défaut: 50000 octets)
Taille limite des messages non délivrés et qui seront renvoyés à  l'expéditeur.

mailbox_size_limit (défaut: 102400000 octets)
Taille maximale (en octets) d'une boite aux lettres

Une fois que le taille des objets a été limitée, la prochaine étape pour avoir un budget fini de mémoire pour Postfix est de limiter le nombre d'objets en mémoire.

 

qmgr_message_recipient_limit (défaut: 10000)

Limite supérieure sur le nombre de structures de données en mémoire associées à l'adresse du destinataire pour le gestionnaire de files d'attente.
Ce paramètre commande également le nombre d'exemplaires d'autres structures de données en mémoire.
Voyez, par exemple, la documentation sur le contrôle du taux de livraison.

 

qmgr_message_active_limit (défaut: 1000)

Limite supérieure sur le nombre de messages dans la file d'attente active.
Pour une introduction à  l'organisation de file d'attente de Postfix, voyez la partie anatomie de Postfix.

duplicate_filter_limit (défaut: 1000)

Nombre d'adresses de destinataire que l'agent de livraison local et le démon de nettoyage d'adresse cleanup se rappellent lorsqu'ils délivrent un message.
Une adresse de destinataire est ignorée lorsqu'elle est dans la liste en mémoire.

Les commandes externes doivent s'exécuter dans une limite de temps donnée.
De telles commandes sont lancées par l'agent local de livraison lorsqu'il trouve une destination de type "|command" dans la base des alias, le fichier :include:, ou le fichier .forward.
Le pipe permet le passage du mail a une commande externe.

 

command_time_limit (défaut: 1000 secondes)

Temps d'attente par l'agent local de livraison avant d'avorter la commande externe.

service_name_time_limit (défaut: $command_time_limit)

Délai pour la livraison aux commandes externes via le pipe.
service_name étant le nom du service concerné (premier champ fichier du master.cf)

 

Intérieurement, les programmes Postfix coopèrent d'une façon très disciplinée et doivent rarement combattre pour l'accès exclusif à un fichier.
Cependant, les conflits d'accès peuvent se produire sur l'extérieur, par exemple, quand le courrier doit être fourni tandis qu'un utilisateur accède à  sa boîte aux lettres.
Postfix supporte deux types de verrouillages de fichier:

• Verrouillages internes, utilisation des primitives système fcntl() ou flock().

• Verrouillages externes, utilisation des fichiers nommés fichier.lock.
  
  

Selon le système hôte, Postfix emploie une méthode ou toutes les deux.
Les paramètres suivants de configuration commandent comment Postfix traite les verrouillages de fichier:

deliver_lock_attempts (défaut: 5)

Le nombre de fois où Postfix essaie de verrouiller un fichier avant d'abandonner.

deliver_lock_delay (défaut: 1 seconde)
Combien de temps Postfix attend entre les tentatives de verrouillage d'un fichier.

stale_lock_time (défaut: 500)

Age d'un vieux fichier lock externe avant qu'il soit détruit.

 

Dans des conditions d'effort grave, les ressources système disponibles peuvent être insuffisantes pour satisfaire les besoins de Postfix.
Le système peut également sembler tomber en morceaux quand un dossier de configuration de Postfix est cassé, ou quand un programme de Postfix est défectueux.

L'approche générale adoptée face au désastre est de se terminer avec une erreur fatale (ou avec une panique en cas de problèmes logiciels), et d'essayer encore après une certaine heure (le démon principal master remettra en marche des processus après quelque temps).
Les tentatives qui ont échouées sont notées; dans le meilleur des cas, quelqu'un notera le problème et le résoudra.

Quelques stratégies de rétablissement ont été mises en application très tôt dans le développement de Postfix, et n'ont pas été rendues configurables encore.
Ce qui suit est le commencement d'une liste croissante de paramètres de commande de rétablissement:

fork_attempts (défaut: 5 fois)

Nombre de fois où Postfix essaie de créer un nouveau processus avant d'abandonner.

fork_delay (défaut: 1 seconde)
Retard entre les tentatives de création d'un nouveau processus.

transport_retry_time (défaut: 60 secondes)

La quantité de temps entre le gestionnaire de files d'attente essaye d'entrer en contact avec un service de livraison apparent ancien de Postfix.

 

Bien que le système Postfix ne possède pas encore de language de réécriture, il est capable de manipuler des adresses grâce à des requêtes sur des tables.
Lorsqu'un message traverse le système Postfix, ses adresses sont modifiées dans l'ordre décrit ci-dessous.

Le démon de nettoyage cleanup, avant de vérifier la correspondance d'une adresse avec les tables, commence par réécrire cette adresse au format standard utilisateur@domaine.complet.et.conforme en passant cette adresse au démon trivial-rewrite.
L'objectif de la réécriture au format standard est de réduire le nombre d'entrées nécessaires dans les tables.

Le démon trivial-rewrite implémente les schémas de réécriture suivants :

@hotea,@hoteb:utilisateur@site vers utilisateur@site

La fonctionnalité de routage à la source est obsolète. Postfix n'implémente pas cette fonctionnalité et doit donc supprimer la route indiquée.

site!user vers user@site

Cette fonctionnalité est controllée par le paramètre booléen swap_bangpath (activé par défaut : yes).
L'objectif est réécrire les adresses uucp dans le style domaine. Cette réécriture est utile pour les sites recevant du courrier via uucp, mais elle
n'apportera aucun problèmes aux autres.

user%domain vers user@domain

Cette fonctionnalité est controllé par le paramètre allow_percent_hack.
Généralement, elle est utilisée pour gérer les adresses du type user%domaine@autre_domaine.

user vers user@$myorigin

Cette fonctionnalité est controllée par le paramètre append_at_myorigin.
L'objectif est d'harmoniser le traitement des courriers utilisateur des machines du domaine $myorigin.
Il est déconseillé de désactiver cette fonctionalité, Postfix attendant les adresses sous la forme user@domain. Si le système Postfix n'est pas le serveur principal pour le domaine $myorigin, et que le courrier de certains utilisateurs doit être livré en local, il faut créer une entrée dans la table virtual redirigeant utilisateur@$myorigin vers utilisateur@$myhostname.

utilisateur@hote vers utilisateur@hote.$mydomain

Cette fonctionnalité est controllée par le paramètre append_dot_mydomain (activé par défaut : yes).
L'objectif est de traiter de la même façon plusieurs formes de nommage d'un même hôte. Certains jugent la réécriture de hote vers hote.$mydomain néfaste. C'est pourquoi il est possible de désactiver cette fonctionnalité.
D'autres apprécient de voir le domaine ajouté automatiquement.

utilisateur@site. vers utilisateur@site (sans le point final).

Avant de déposer les messages dans la file d'attente incoming, le démon cleanup utilise la table canonical pour réécrire toutes les adresses de l'enveloppe et de l'entête.

Cette correspondance est utile pour remplacer des nom de login utilisateurs par des adresses du style Prenom.Nom, ou pour supprimer des noms de domaine invalides éventuellement ajoutés par des systèmes de courrier illicites.

La correspondance canonique est désactivée par défaut.
Pour l'activer, il faut éditer le paramètre canonical_maps dans le fichier de configuration main.cf et lui spécifier une ou plusieurs tables.
En plus des tables canonical qui s'appliquent à la fois aux adresses expéditeur et destinataire, il est possible de déclarer des tables canoniques qui s'appliquent aux adresses expéditeur ou destinataires, respectivement avec les paramètres
sender_canonical_maps et recipient_canonical_maps.

Ces tables sont lues avant la table commune. La réécriture des adresses expéditeur est utile pour transformer des adresses laides en une forme plus agréable, tout en permettant d'écrire aux vilaines adresses sans créer de boucle de routage du courrier.

Le masquage d'adresses consiste à cacher tous les hôtes d'un domaine derrière une passrelle de courrier, et à faire apparaître le courrier comme provenant de la passerelle elle-même, au lieu de machines individuelles.

Le masquage d'adresses est désactivé par défaut.
Pour l'activer, il faut éditer le paramètre masquerade_domains dans le fichier main.cf et y spécifier un ou plusieurs domaines.

Le paramètre masquerade_exceptions indique quels noms d'utilisateur ne doivent pas être soumis au masquage d'adresses.
Par défaut, Postfix ne fait aucune exception.

Exemple :

Masquer les adresses de type user@host.domain en user@domain
masquerade_domains = $mydomain

A l'exception des messages provenant d'un utilisateur root
masquerade_exceptions = root

Attention : le masquage d'adresses ne s'applique qu'aux adresses de l'en-tête et à l'adresse expéditeur de l'enveloppe, et pas à l'adresse destinataire de l'enveloppe.

Pour appliquer un masquage sur l'adresse destinataire de l'enveloppe, il suffit d'indiquer (disponible à partir de la version 20010802 de Postfix) :

masquerade_classes = envelope_sender, envelope_recipient, header_sender, header_recipient

Si vous faites ceci, Postfix ne pourra plus envoyer le courrier à d'autres machines.

Après avoir appliqué les correspondances canoniques et de masquage, le démon cleanup utilise la table virtual pour rediriger le courrier vers les différents destinataires locaux ou distants.

Seule l'adresse destinataire de l'enveloppe est affectée par cette correspondance.
Les correspondances par recherche dans la table virtual sont utiles pour rediriger le courrier à des domaines virtuels dans des boîtes d'utilisateur réel, et pour rediriger le courrier adressé à des utilisateurs qui n'existent plus.

Les requêtes sur la table virtual peuvent aussi permettre la transformation Prenom.Nom en nom de login utilisateur réel, bien que la base d'alias local semble être plus appropriée.

La recherche de correspondance dans les tables virtual est désactivée par défaut.
Pour l'activer, il faut affecter au paramètre virtual_maps, une valeur pointant une ou plusieurs tables.

Les adresses trouvées dans les tables virtual peuvent être sujettes à une autre recherche de correspondance dans les tables virtual, mais elles ne passeront pas la recherche de correspondance canonical, afin d'éviter des boucles de routage de courrier.

Exemple :

virtual_maps = hash:/etc/postfix/virtual

L'étape suivante dans la réécriture des adresses est réalisée par le gestionnaire de files qui vérifie la corrspondance de chaque adresse destinataire avec la table relocated.

Cette table fournit les informations nécessaires pour atteindre les utilisateurs qui n'ont plus de compte et pour gérer les domaines qui n'existent plus.

Lorsqu'un message est envoyé à l'une des adresses comprises dans cette table, il est renvoyé avec un message d'information à son expéditeur .

Les recherches d'utilisateurs déplacés sont désactivées par défaut.
Pour les activer, il faut affecter une valeur de table au paramètre relocated_maps.

Exemple :

relocated_maps = hash:/etc/postfix/relocated

 

Une fois que le gestionnaire de files a établit la destination, la table transport, optionnelle, contrôle le mode de transport (elle est utilisée par le démon trivial-rewrite).

Par défaut, tout est délivré par smtp.
La table de transport peut être utilisée pour envoyer le courrier de certains sites via uucp, ou pour gérer l'envoi de courrier à des sites qui ne peuvent assurer qu'une connexion smtp à la fois.

Par défaut, cette fonctionnalité est désactivée.
C'est le paramètre transport_maps dont la valeur doit indiquer une table au moins qui permet son activation.

Exemple :

transport_maps = hash:/etc/postfix/transport

Quand le courrier doit être délivré localement, le démon local vérifie la concordance de chaque destinataire avec les entrées de la base d'alias.
La recherche de correspondance n'affecte pas les adresses de l'en-tête.
Généralement, les alias locaux sont utilisés pour créer des listes de diffusion ou pour rediriger des alias standards comme postmaster vers des utilisateurs réels.
La base peut aussi être utilisée pour faire correspondre une adresse du type Prenom.Nom à un login utilisateur.

Exemple :

alias_maps = hash:/etc/aliases

alias_maps = dbm:/etc/aliases, nis:mail.aliases

La base d'alias est activée par défaut.
Le chemin d'accés à la base configurée par défaut dépend du système d'exploitation.

 

Exemple :

alias_database = hash:/etc/aliases (4.4BSD, LINUX)

alias_database = dbm:/etc/aliases (4.3BSD, SYSV < 4)

alias_database = dbm:/etc/mail/aliases (SYSV4)

Pour des raisons de sécurité, les livraisons de courrier à des commandes ou des fichiers sont effectuées avec les droits du propriétaire de la base.
L'identifiant utilisateur correspondant au paramètre default_privs est utilisé pour les bases appartenant à root.

Les utilisateurs ont la possibilité de contrôler la livraison de leur propre courrier en indiquant la redirection de celui-ci dans le fichier .forward placé dans leur répertoire personnel.
La syntaxe de ces fichiers est la même que celle du fichier d'alias.

Lorsque le démon de livraison s'aperçoit qu'un utilisateur est inexistant, le message est renvoyé à l'expéditeur (« utilisateur inconnu »).
Parfois, il peut être souhaitable de faire suivre le courrier pour des utilisateurs inexistants à une autre machine.
Dans ce cas, il est possible de spécifier une destination au paramètre luser_relay.
Une autre alternative est de déléguer à un autre mode de transport le courrier destiné à des utilisateurs inexistants en affectant judicieusement le paramètre fallback_transport.

always_bcc = utilisateur
utilisateur recevra une copie du courrier indépendamment de l'origine et de la destination.