Il est donc nécessaire qu'un utilisateur soit actif. Dès qu'il y a un utilisateur actif, le lancement du programme peut être automatisé par un lien /Start/Startup.

Un service ne dispose pas d'une interface avec l'utilisateur (un service pouvait créer un interface avec les versions plus anciennens de Windows, mais ce n'est plus possible à partir de Vista). Toute la configuration de Mercury s'effectue justement via l'interface avec l'utilisateur, ce qui fait qu'une transformation en service n'est pas pour bientôt.

Il est possible d'utiliser un programme de chargement (par exemple Fire Daemon) qui lance automatiquement Mercury. Cela fonctionne très bien, sauf sur les dernières versions de Windows.

Lancer Mercury en mode service n'est nécessaire que dans le cas où vous avez un vrai serveur (où vous ne vous connectez jamais).

En attendant, il y a plusieurs initiatives indépendantes de Mercury qui sont disponibles, par exemple IMP de Horde et Squirrelmail qui sont les plus connus. Ce ne sont malheureusement pas des applications stand-alone (indépendantes), mais des applications PHP qui ont donc besoin d'un serveur web avec support PHP. C'est une formule que je ne recommande pas, car les applications PHP sont souvent difficiles à protéger. De plus, il faut un serveur web complet, alors qu'il aurait été plus simple de fournir un petit module qui s'intègre à Mercury.

Cela ne pose aucun problème dans un environnement LAN ou les utilisateurs envoient leurs mails directement au serveur du fournisseur d'accès (solution de facilité). Il est également possible d'autoriser toutes les adresses locales (voir exemple).

Ce sont les utilisateurs en déplacement qui posent problème. Pour envoyer des mails, il doivent à chaque fois reconfigurer leur application selon le réseau sur lequel ils se trouvent. C'est plus facile de configurer une seule fois l'application mail en indiquant l'adresse de son propre serveur. Voici la procédure à suivre:

• Sur le serveur: il faut ajouter un port alternatif car les fournisseurs d'accès bloquent le port 25 sortant (c'est une configuration très simple, car Mercury peut d'office utiliser un second port).
• Sur le serveur également, il faut définir tous les utilisateurs qui peuvent utiliser le serveur pour les mails sortants. Il est possible de définir un seul utilisateur fictif (avec login et mot de passe). Tous les utilisateurs emploient cette configuration pour envoyer les mails, puisque les protocoles SMTP (envoi) et POP/IMAP sont indépendants au niveau du serveur.

• Au niveau du client, il faut configurer chaque utilisateur pour utiliser ce port alternatif avec le login et mot de passe spécifique pour l'envoi de courriers. Les programmes de messagerie permettent tous de définir un identifiant différent pour l'envoi du courrier.

L'inconvénient du système à identifiant unique, c'est que quand un utilisateur quitte la firme, il faut modifier le login et/ou mot de passe de tous les utilisateurs en déplacement.

les utilisateurs sont globaux

En pratique, cela ne posera aucun problème, car les utilisateurs qui ont une adresse avec nom de domaine en ***.be ont la même adresse avec nom de domaine en ***.com. Tous les mails pour jean.dupont arrivent à la même boite postale, que l'adressage se fasse jean.dupont@entreprise.be ou jean.dupont@company.com

Il n'est malheureusement pas possible de créer deux comptes séparés s'ils ont le même identifiant (la partie avent l'arobase ou “a crolle” comme on dit chez nous).

Les domaines supplémentaires indiquent simplement que le serveur peut accepter du courriel pour ces domaines.

Par contre, il est possible de définir une boite à lettres de domaine (domain mailbox) chez le fournisseur d'accès et faire parvenir tous les courriels de ce domaine chez un seul utilisateur.

La liste de distribution peut être interessante même s'il n'y a qu'un seul utilisateur qui utilise la liste. Il ne faut pas ajouter toutes les adresses en Bcc. Le serveur dispose d'une fonction fan out qui découpe le mailing et limite le nombre de destinataires. C'est une fonction qui peut être utile, car de nombreux fournisseurs d'accès limitent le nombre de destinataires d'un mail. Le serveur mail local va alors créer automatiquement un nombre de messages, avec un nombre maximal de destinataires.

Une liste de distribution est idéale pour envoyer des messages publicitaires. Une seule personne tient la liste à jour. Le nombre de listes de distribution n'est pas limité (interessant si vous faites de la promotion multi-langue).

Les possibilités des listes de distribution sont relativement limitées en comparaison d'un serveur mail professionel (comme Merak), mais suffisant pour une PME.

Le fonctionnement est asynchrone, c'est à dire que l'envoi du courriel est déconnecté de l'exécution du programme, qui ne doit pas attendre (idéal pour toutes les applications web qui ne peuvent pas attendre).