Forums d'entraide informatique - Astuces - Conseils

Les Directors
Un Director est un pilote chargé de déterminer comment la livraison d'un message doit être faite. Un Director dirige la livraison et ne concerne que les messages locaux (destinés aux utilisateurs de la machine qui gère les domaines dans iocai_domains). Comprenez bien qu'un Director ne fait que prendre une décision mais ne livre pas le message lui-même. Il deésigne un ou plusieurs Transports pour l'application d'une décision.
real_local:
prefix    real-
driver    localuser
transport    local_delivery
Cette première configuration désigne le Transport à utiliser pour un message réellement local. Entendez par là un message d'un utilisateur local du système à destination d'un autre utilisateur du même systè- me. Pour ce type de messages, nous utilisons le Transport local_delivery. Vous pouvez d'ailleurs en faire immédiatement le test en vous envoyant un message sur l'hôte qui héberge le serveur SMTP Dans les journaux d'activité d'exinq (/var/log/exim/mainlog) vous devriez voir appa- raître quelque chose proche de ceci
2002-01-28 14:47:43 16VC8N-00006y-00 <= denis@egon U.denis P.local S=647 id=20020128144743.A423@mon- site.com
2002-01-28 14:47:43 16VC8N-00006y-00 => denis <denis@egon> D.localuser T.local_delivery 2002-01-28 14:47:43 16VC8N-00006y-00 Completed
On voit clairement qu'exim a reçu un message de l'utilisateur denis de l'hôte local (egon) à destina- tion de denis@egon. Le Director localuser (D,...) a décidé de faire livrer le message en utili- sant local_delivery comme Transport. La men- tion Completed signale que l'opération s'est parfai- tement bien déroulée. Le code que vous voyez appa- raître entre Meure et le message est un identifiant unique permettant de suivre le déroulement de la procédure. Il figurera également dans Pen-tête du message reçu par l'utilisateur denis.
system_aliases:
driver = aliasfile
file_transport = address_file
pipe_transport = address_pipe
file = /etc/aliases
search_type    lsearch
Ce Director s'occupe des alias d'adresses. En temps normal, un utilisateur denis d'une machine rece- vra des messages destinés à denis@monsite.cor. est cependant possible de multiplier les adresses sans multiplier pour autant les comptes utilisateurs sur le système. Il suffit de créer un alias comme toto@monsite.com et les messages destinés à cette adresse arriveront également à l'utilisateur denis. Afin de traiter ces alias, nous avons besoin d'un Director spécifique qui lira, ici, le fichier /etc/aliases et y fera une recherche. Si la recherche aboutit, le Director changera le destinataire final.
Ensuite, tout dépend de ce qui se trouve dans le fichier d'alias. Sa syntaxe est très simple : pour un alias d'un nom d'utilisateur, il suffit d'ajouter, dans le cas présent, une ligne contenant toto : moi. Dans ce cas, system_aliases passera le relais à localuser qui utilisera local_delivery pour livrer le message.
2002-01-28 15:14:49 16VCYb-00007K-00 <= denis@egon U.denis P=local S.639 id.20020128151449.B423@mon- site.com
2002-01-28 15:14:49 16VCYb-00007K-00 => moi <toto@egon> D.localuser T=local_delivery 2002-01-28 15:14:49 16VCYb-00007K-00 Completed
Mais le fichier d'alias peut parfaitement contenir un nom de fichier ou un pipe vers une application, comme ici où toto: dmoi a été remplacé par toto: /tmp/totofichier dans le fichier d'alias :
2002-01-28 15:51:50 16V178Q-00009E-00 <= denis@egon U=denis P=local S.639 id=20020128155150.A563@mon- site.com
2002-01-28 15:51:50 16VD8Q-00009E-00 .> /tmp/toto- fichier <toto@egon> D=system_aliases T.address_file
2002-01-28 15:51:50 16VD8Q-00009E-00 Completed
Dans ce cas, ce sont les Transports address_file et address_pipe qui seront utilisés pour la livrai- son du message.
procmail:
driver = localuser
transport procmail_pipe
require_files ${1ocal_part}:+${home}:+${home}hprocmailrc:+/usr/ bin/procmail
no_verify
Voici le Director permettant l'utilisation de procmail. Le Transport à utiliser sera procmail_pipe, mais seulement sous certaines conditions. La directive require files définit en effet que plusieurs éléments doivent exister sur le système : l'utilisateur, le répertoire privé de l'utilisateur, un fichier procmailrc dans ce répertoire et le binaire de procmail dans /usr/bin/. Si un de ces éléments est absent, le relais sera passé à localuser qui se chargera de prendre une décision.
userforward:
driver    forwardfile
file_transport    address_file
pipe_transport address_pipe
reply_transport address_reply
no_verify
check_ancestor
file    .forward
modemask 002
filter
Ce Director est chargé de faire appliquer les décisions tirées du fichier . forward. Les Transports mis en oeuvre sont respectivement address_file, address_pipe et address_reply. Vous voyez, ci- dessous, les logs d'exim pour les trois types de foritarding :
/tmp/denisfichier dans le .forward de denis 2002-01-28 16:07:03 16VDN9-00009W-00 <= denis@egon U=denis P=local S=641 id.20020128160703.A581@monsite.com
2002-01-28 16:07:03 16VDN9-00009W-00 => /tmp/denisfichier <denis@egon> D=userforward T=address_file
2002-01-28 16:07:03 16VDN9-00009W-00 Completed
kkun@ailleur.com dans le .forward de moi 2002-01-28 16:22:44 16VDcK-0000CK-00 <= denis@egon U=denis P=local S=637 id=20020128162244.A755@monsite.com
2002-01-28 16:22:49 16VDcK-0000CK-00 => kkun@ailleur.com <moi@egon> R=lookuphost T=remote_smtp H=mail.ailleur.com [64.617.56.2991 2002-01-28 16:22:49 16VDcK-0000CK-00 Completed
I/home/moi/script.pl dans le .forward de moi 2002-01-28 16:19:36 16VDZI-0000Bs-00 <= denis@egon U=denis P=local S=637 id.20020128161936.A727@monsite.com
2002-01-28 16:19:36 16VDZI-0000Bs-00 ** I/home/moi/script.pl <moi@egon< D=userforward T=address_pipe: return message generated 2002-01-28 16:19:36 16VDZI-0000Bx-00 <= <> R.16VDZI-0000Bs-00 U.mail P=local S.1440
2002-01-28 16:19:36 16VDZI-0000Bs-00 Error    
sent to denis@egon
2002-01-28 16:19:36 16VDZI-0000Bs-00 Complete:: 2002-01-28 16:19:36 16VDZI-0000Bx-00 => denis <denis@egon> D=localuser T=local_delivery 2002-01-28 16:19:36 16VDZI-0000Bx-00 Complets:
Ce dernier extrait du journal d'activité d'exim parle d'un message d'erreur retourné à l'expéditeur du message. Il s'agit en réalité de la sortie sur stdout faite par script .pl, mais le script retourne une valeur de sortie supérieure à zéro :
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. The following address(es) failed:
moi@egon:
generated 1/home/moi/script.pl
The following text was generated during the de_-_-_- very attempt:
I/home/denis/script.pl
pouet
     This is a copy of the message, including
all the headers.    
Vous conviendrez avec moi qu'il faudra prendre de grandes précautions avec ce genre de script, tant au niveau de ce qui est perçu de la part de l'expéditeur d'un message qu'au niveau des actions du script et de ses permissions.
localuser:
driver    localuser
transport    local_delivery
end
Enfin, ce dernier Director est le fameux localuser largement utilisé. C'est lui qui se chargera de commanditer la livraison des messages pour les utilisateurs locaux.
Les hôtes virtuels
Il est possible avec un seul exini de gérer les mails de plusieurs domaines. Nous avons déjà vu la partie concernant les entrées DNS ainsi que la directive local_domains. Imaginons à présent que vous ayez les domaines monsite.com et autresite.com. Les comptes de votre machine SMTP, que nous

appellerons egon, sont tous uniques. Il ne peut, en effet, exister qu'un seul compte du même nom sur un système donné.
Le problème est donc le suivant : comment différen- cier denis@monsite.com de denis@autre- site.com ? La réponse se trouve dans les alias. Il suffit de ne créer aucun compte de ce nom, mais plutôt mdenis pour monsite.com et adenis pour autresite.com. Nous pouvons maintenant utiliser des alias pour rediriger les messages arrivant sur les adresses complètes vers les utilisateurs respectifs. Pour cela, nous ne pouvons pas utiliser un fichier d'alias unique puisque la redondance poserait éga- lement problème ici. Nous allons multiplier les fichiers d'alias autant de fois que nous avons de domaines à gérer.
Dans la partie concernant les Directors, nous allons ajouter :
virtual:
driver.aliasfile
domains.dbm;/etc/exim/domains no_more
file./etc/exim/$domain
search_type.1search
Ce nouveau Director va se servir du fichier de base de données que nous avons utilisé en début d'article. Bien sûr, vous pouvez remplacer dbm; /etc/exim/domains par la liste des domaines séparés d'un double-point. Cependant, l'utilisation d'un fichier dbm s'avère ici plus souple puisqu'il nous suffit ensuite de le modifier sans avoir à tou- cher au fichier de configuration d'exim. Lorsqu'un message arrivera sur l'un des domaines présents dans le fichier dbm, la variable $domain sera initiali- sée avec le nom de domaine en question. De ce fait, le fichier d'alias correspondant sera automatique- ment lu dans le but de trouver l'utilisateur adéquat.
I es filoc rf    'Prtte
Si votre serveur SMTP doit faire face à un gros tra- fic de messagerie, il est possible d'optimiser le fonc- tionnement d'exim. De base, les messages sont déli- vrés immédiatement, ce qui entraîne un démarrage d'exim par message. En cas de grosse charge, il est plus raisonnable de stocker les messages dans une file d'attente et de les traiter par lot à intervalles réguliers.
Vous trouverez, à ce propos, un fichier
/etc/cron.d/exim qui définit un démarrage d'exim toutes les 30 minutes sur un système Debian. Une option spécifique est utilisée, -q. Elle permet de lancer une vérification des files d'attente auto- matiquement.
Nous ne nous étendrons pas longtemps sur la confi- guration des files d'attente, car normalement, votre configuration sur ligne ADSL ou câble ne nécessi- tera pas une utilisation intensive de ce type de mécanisme. Sachez simplement que vous pouvez forcer la mise en file d'attente de tous les messages en ajoutant queue_only dans la première partie du fichier de configuration. De la même manière, queue_only_load suivi d'une valeur numérique permettra de mettre en file d'attente tous les mes- sages si la charge système dépasse la valeur donnée. Même sans files d'attente explicitement configurées, il peut arriver, en cas de problème qu'un ou plusieurs messages soient placés dans des files. Vous pourrez utiliser, en tant qu'utilisateur root, la commande mai lq pour lister le contenu de cette file d'attente : # mailq
87m 1.4K 16VDQ1-00009x-00 <> *** frozen *** denis@egon
84m 1.5K 16VDSM-0000AN-00 <> *** frozen *** denis@egon
80m 1.5K 16VDW6-0000Ar-00 <> *** frozen *** denis@egon
Nous avons ici trois messages à destination de denis@egon "gelés" dans la file d'attente depuis 87, 84, et 80 minutes. Nous pouvons afficher les infor- mations sur le traitement de ces messages grâce à leur code
# exim -Mv1 16VDW6-0000Ar-00
2002-01-28 16:16:18 1/home/denis/script.pl <denis@egon>: address_pipe transport failed: Child process of address_pipe transport returned 69 (could mean service or program unavailable) from command: /home/denis/script.pl
*** Frozen (delivery error message)
Nous pouvons en déduire que quelque chose ne fonctionne pas correctement dans le . forward ou dans le script de l'utilisateur denis. En tant qu'administrateur, nous devons informer l'utilisateur en question et régler le problème en corrigeant le script ou en éliminant tout simplement le . forward de l'utilisateur.
Nous avons fait le tour des principales fonctionnalités d'exim. Ces informations devraient vous per- mettre de mettre en place votre premier serveur