• Côté Windows Mobile, c’est « ActiveSync » qui va gérer et maintenir la connexion avec le serveur, donc rien à installer, c’est super !
• Côté serveur, nous allons utiliser « Z-Push », une implémentation open source du protocole ActiveSync, écrite par la société Zafara (en PHP).

Avant de commencer, nous aurons besoin :

• D’un serveur Linux avec PHP 5 et Apache 2 installés (et accessible depuis Internet évidemment) – Pour le test, j’ai utilisé une Debian Lenny -,
• Un serveur IMAP (local ou distant),
• Dans l’optique de la configuration d’un VirtualHost Apache, une entrée DNS spécifique, c’est plus propre, mais ce n’est pas obligatoire,
• Les sources de Z-Push,
• Un terminal Windows Mobile (testé avec Windows Mobile 6).

Z-Push

Commençons par décompresser les sources à la racine de notre serveur web :

# tar xvzf  z-push-1.2.2.tar.gz -C /var/www/

Le répertoire /var/www/z-push/state doit être accessible en écriture par l’utilisateur Apache :

# chmod 700 /var/www/z-push/state
# chown www-data:www-data /var/www/z-push/state

Editons ensuite le fichier de configuration  (/var/www/z-push/config.php)

...
// The data providers that we are using (see configuration below)
    $BACKEND_PROVIDER = "BackendIMAP";
...
    // ************************
    //  BackendIMAP settings
    // ************************
 
    // Defines the server to which we want to connect
    // recommended to use local servers only
    define('IMAP_SERVER', 'localhost');
 
    // connecting to default port (143)
    define('IMAP_PORT', 143);
 
    // best cross-platform compatibility (see http://php.net/imap_open for options)
    define('IMAP_OPTIONS', '/notls/norsh/ssl/novalidate-cert');
 
    // overwrite the "from" header if it isn't set when sending emails
    // options: 'username'    - the username will be set (usefull if your login is equal to your emailaddress)
    //        'domain'    - the value of the "domain" field is used
    //        '@mydomain.com' - the username is used and the given string will be appended
    define('IMAP_DEFAULTFROM', 'username');
 
    // copy outgoing mail to this folder. If not set z-push will try the default folders
    define('IMAP_SENTFOLDER', '');
 
...

Les paramètres ci-dessus sont adaptés au serveur imap local. Ils peuvent être ajustés à un autre serveur. Ceci devrait fonctionner avec n’importe quel serveur IMAP.

Par exemple, pour Gmail :

define('IMAP_SERVER', 'localhost');
define('IMAP_PORT', 993);
define('IMAP_OPTIONS', '/notls/norsh/ssl/novalidate-cert');
define('IMAP_DEFAULTFROM', 'username')
define('IMAP_SENTFOLDER', '');

Apache

Nous allons avoir besoin de satisfaire quelques dépendences avant d’attaquer la configuration d’Apache.  Z-Push a en effet besoin de quelques paquets pour pouvoir fonctionner correctement :

#  apt-get install pear php5-imap php5-mail php5-mail-mime php5-pear
# pear install –alldeps Mail

Nous avons ensuite deux alternatives :

• Créer un VirtualHost afin d’accéder au serveur directement par son nom : http://z-push.mondomaine.net, (plus propre à mon sens)
• Ou configurer un répertoire d’un site existant : (http://mon_serveur_ou_son_ip/z-push).

Virtualhost

Pour créer un VirtualHost, il nous faut ajouter un fichier dans /etc/apache2/sites-available. Arbitrairement, nous allons choisir z-push comme nom de fichier.

/etc/apache2/sites-available/z-push

	ServerAlias zpush.mondomaine.net
	ServerAdmin webmaster@mondomaine.net
	DocumentRoot /var/www/z-push
	Alias /Microsoft-Server-ActiveSync /var/www/z-push/index.php
 
		Options -Indexes
		AllowOverride none
		Order allow,deny
		allow from all
		php_flag magic_quotes_gpc off
		php_flag register_globals off
		php_flag magic_quotes_runtime off
		php_flag short_open_tag on
 
	ErrorLog /var/log/apache2/zpush-error.log
	LogLevel warn
	CustomLog /var/log/apache2/zpush-access.log combined
	ServerSignature Off

La commande a2ensite (Apache2 Enable Site) permet de rendre le VirtualHost actif (équivaut à faire un lien symbolique dans /etc/apache2/sites-enabled)

$ sudo a2ensite z-push
$ /etc/init.d/apache2 reload

Config par défaut ou .htaccess

La deuxième technique  consiste à ne configurer que le répertoire z-push, sans création d’un VirtualHost. Pour cela, nous ajouterons simplement les lignes suivantes dans le fichier de configuration du site par défaut (normalement /etc/apache2/sites-avaible/defaut) ou directement dans un fichier un .htaccess à la racine du site :

	Alias /Microsoft-Server-ActiveSync /var/www/z-push/index.php
 
		Options -Indexes
		AllowOverride none
		Order allow,deny
		allow from all
		php_flag magic_quotes_gpc off
		php_flag register_globals off
		php_flag magic_quotes_runtime off
		php_flag short_open_tag on

Le mobile

La configuration du serveur étant terminée, nous pouvons tester sur un terminal. Nous allons configurer ActiveSync pour qu’il se connecte au serveur.

• Dans ActiveSync : Menu -> Configurer le serveur,
  • Adresse du serveur : zpush.mondomaine.net (nom du VirtualHost ou Url complète d’accès à z-push),
  • Décôcher SSL (n’est pas encore configuré sur le serveur Apache),
  • Nom d’utilisateur : L’utilisateur Imap pour lequel nous voulons recevoir les mails,
  • Mot de passe : Mot de passe de l’utilisateur sur le serveur Imap,
  • Domaine : Domaine de messagerie,
  • Ne synchroniser que les mails : nous avons utilisé z-push pour l’Imap uniquement.
• La synchro devrait ensuite fonctionner. L’activation du mode Push peut se faire dans le « Comm Manager » en activant « Microsoft Direct Push« .

La méthode est biensûr perfectible par l’ajout du support SSL. Je ne suis pas arrivé, pour l’instant, à une solution très satisfaisante concernant ce point. A moins qu’ils ne nous soit possible de faire certifier le certificat serveur par un autorithé reconnue, il faudra importer ce cetificat sur le mobile. La chose est plutôt fastidieuse, l’option d’import n’étant pas disponible dans Internet Explorer mobile. Il est nécessaire de passer par un export au format xml, que l’on insère ensuite dans un fichier cab pour l’installer sur le terminal. Bref, du bon gros bricolage !

Références : http://andrew.tj.id.au/activesync-for-gmail/

]]> http://www.jopa.fr/index.php/2009/08/05/push-mail-sur-serveur-imap-gmail/feed/ 4 http://www.jopa.fr/index.php/2009/07/28/alias-forward-postfix-openldap/ http://www.jopa.fr/index.php/2009/07/28/alias-forward-postfix-openldap/#comments Tue, 28 Jul 2009 20:10:23 +0000 Jopa http://www.jopa.fr/?p=1563 En me basant sur l’architecture présentée dans le billet : Installation d’un serveur mail brique par brique… (OpenLDAP, Postfix, Cyrus-imap, TLS, SASL, Spamassassin, Amavis, etc…), je vais chercher, au travers de cet article, à améliorer la distribution des mails entrants. Ce que je souhaite mettre en place est assez simple d’un point de vue fonctionnel :

1. Chaque utilisateur doit pouvoir disposer de plusieurs adresses email pour une même boîte, sans que l’on ait besoin de le créer plusieurs fois dans l’annuaire (notion d’alias) ,
2. Les messages entrants doivent pouvoir être stockés sur le serveur Imap Local, transférés vers d’autres adresses (notion de forward) ou, soyons fous, les deux.

Le serveur Imap utilisé est Cyrus, mais ceci n’a pas vraiment d’importance, n’importe quel gestionnaire Imap fera l’affaire. Il en va de même pour le serveur OpenLDAP qui peut être remplacé par un autre annuaire, pourvu qu’il respecte les standards. Vous l’aurez compris, c’est bel et bien Postfix qui va permettre ces petites galipettes.

Pour l’exemple, je vais une fois de plus solliciter mon utilisateur préféré : Monsieur Dupont (Jean pour les intimes) . Ce Monsieur souhaite recevoir tous les mails adressés à :

• jean@linet.jopa.fr,
• dupont@linet.jopa.fr,
• jean.dupont@linet.jopa.fr.

Il dispose bien entendu d’une boîte Imap sur le serveur, mais souhaite qu’une copie de ses messages soient transférés sur son compte gmail :  jean.dupont@gmail.com.  C’est pas très très joli pour la sécurité de l’entreprise, mais pour l’exemple (et pour Jean), je vais fermer les yeux !

Le serveur  IMAP :

Je vous l’ai dit, sur le serveur IMAP, rien de particulier. Il faut juste s’assurer qu’il est fonctionnel et que l’utilisateur Jean y est bien présent. Dans le cas contraire, je vous invite à consulter l’article précédent pour l’installation et la configuration d’un serveur Cyrus-Imap.

# cyradm –user cyrus localhost
Password:
localhost> lm
user.jean (HasNoChildren) user.jojo (HasNoChildren)
user.joel (HasNoChildren)
localhost> quit

L’annuaire :

Dans l’annuaire, j’ai légèrement modifié le schéma pour y insérer un deuxième attribut « Mail« , nommé « maildrop ». J’ai emprunté cet attribut à la classe CourierMailAlias (fournie par courier-Imap), mais en fait, n’importe quel attribut texte peut faire l’affaire.

L’idée est d’utiliser l’attribut « Mail » pour enregistrer les adresses pour lesquelles la réception de courrier est autorisée pour l’utilisateur :

• jean@linet.jopa.fr,
• dupont@linet.jopa.fr,
• jean.dupont@linet.jopa.fr

Et l’attribut « MailDrop«  pour les adresses auxquelles le courrier va être effectivement distribué. Il faut noter que cet attribut doit correspondre à des boîtes réellement existantes. Dans sa configuration initiale, Cyrus cherche à stocker les messages dans des boîtes identifiées par le préfixe de l’adresse du destinataire (ce qui est avant le @).

• jean@linet.jopa.fr,
• jean.dupont@gmail.com

Dans cet exemple, tout message adressé  à l’une ou l’autre  des 3 adresses définies par l’attribut « Mail » devra  être distribué aux 2 adresses définies par l’attribut « MailDrop« .

Côté ldiff, ça donne ça :

 
# utilisateurs.ldif
dn: uid=jean,dc=linet,dc=jopa,dc=fr
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAlias
uid: jean
cn: Jean DUPONT
sn: Jean
mail: jean@linet.jopa.fr
mail: dupont@linet.jopa.fr
mail: jean.dupont@linet.jopa.fr
maildrop: jean@linet.jopa.fr
maildrop: jean.dupont@gmail.com
userPassword: toto

Pour utiliser l’attribut « Maildrop » de la classe CourierMailAlias, il est nécessaire de récupérer le schéma décrivant la classe et de l’intégrer à l’annuaire. Le fichier s’appelle authldap.schema et vient avec la doc de Courier-Imap. (/usr/share/doc)… Vous pouvez également le récupérer ici :

authldap.schema

Le fichier doit être copié dans le répertoire contenant les schémas ( /etc/ldap/schema logiquement) et intégré à la structure de l’annuaire dans le fichier /etc/ldap/slapd.conf

/etc/ldap/slapd.conf

# This is the main slapd configuration file. See slapd.conf(5) for more
# info on the configuration options.
 
#######################################################################
# Global Directives:
 
# Features to permit
allow bind_v2
 
# Schema and objectClass definitions
include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema
include         /etc/ldap/schema/authldap.schema
...
...

Postfix :

Le but ici, est de définir Cyrus comme agent de transport local (et virtuel) et de paramétrer les recherches dans l’annuaire LDAP. Cette recherche sera définie dans deux fichiers de configuration externes : ldap-accounts.cf pour la validation des destinataires et ldap-aliases.cf pour la gestion des alias.

/etc/postfix.main.cf

# See /usr/share/postfix/main.cf.dist for a commented, more complete version
# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
myorigin = /etc/mailname
...
...
# PARAMETRES LDAP
# Utilisateurs :
virtual_mailbox_maps = ldap:/etc/postfix/ldap-accounts.cf
# Alias :
virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf
...
...
# Agent de transport local : CYRUS
local_transport = cyrus
virtual_transport = cyrus
mailbox_transport = cyrus
...
...
...

/etc/postfix/ldap-accounts.cf

Ce fichier configure la recherche dans l’annuaire pour l’identification et la validation des destinataires. Il spécifie l’adresse email comme critère de recherche et  cas de succès, précise que c’est  l’uid de l’utilisateur qui doit être retourné.

server_host = localhost
server_port = 389
search_base = dc=linet, dc=jopa, dc=fr
query_filter = (& (objectClass=InetOrgPerson)(mail=%s))
result_attribute = uid
bind = yes
bind_dn = cn=admin,dc=linet,dc=jopa,dc=fr
bind_pw = ******************
version = 3

/etc/postfix/ldap-aliases.cf

Ce fichier permet, quant à lui, de gérer les Alias. Il définit lui aussi une recherche sur l‘adresse email (champ mail) mais cette fois, c’est l’attribut « Maildrop » que sera retourné.

server_host = localhost
server_port = 389
search_base = dc=linet, dc=jopa, dc=fr
query_filter = (& (objectClass=InetOrgPerson)(mail=%s))
result_attribute = maildrop
bind = yes
bind_dn = cn=admin,dc=linet,dc=jopa,dc=fr
bind_pw = ******************
version = 3

En résumé, encore une démonstration de la puissance du duo Postfix/Ldap, pour une fonctionnalité très pratique et relativement simple à mettre en oeuvre.

J’ai publié, en début d’année, un billet sur l’installation d’un serveur mail basé sur différentes « briques » :

• OpenLDAP,
• Postfix,
• Cyrus-imap,
• TLS,
• SALS,
• Spamassassin,
• Amavis,
• etc…

En réutilisant ce tuto pour l’installation d’un nouveau serveur, je me suis aperçu de quelques coquilles et de légères différences pour une installation sous Lenny.

L’occasion pour moi de réactualiser l’article, en tenant comptes de vos remarques et commentaires.

Installation d’un serveur mail brique par brique… (OpenLDAP, Postfix, Cyrus-imap, TLS, SASL, Spamassassin, Amavis, etc…)

Postfix, Cyrus, OpenLdap, Spamassassin, Amavis, etc… sont des logiciels qui ont largement fait leurs preuves et qui, assemblés, constituent un serveur de mails robuste et performant. Je me suis amusé, le week-end dernier, à assembler et configurer tous ces composants sur une distribution Debian Etch pour construire un tel serveur, en ajoutant en prime un poil de sécurité grâce à SASL et TLS.  La tâche est loin d’être insurmontable, à condition de prendre les choses méthodiquement et calmement. Dans le bon ordre, les briques s’assemblent à merveille et c’est un vrai bonheur à construire.

Nous allons voir, dans cet article, la mise en place d’une telle solution. Comme pour les précédents articles dédiés à Zimbra et OBM, nous allons réutiliser ma machine « labo » fraichement réinstallée avec une Debian Etch, tout ce qu’il y a de plus  classique.

Note du 28 Juillet 2009 : Mise à jour de l’article pour Debian Lenny.

1ère brique : Le serveur LDAP

Nous allons commencer par installer et configurer un petit annuaire LDAP de test. Il est bien entendu tout à fait possible de se baser sur un annuaire existant. Nous n’employerons  par la suite que 3 champs de la classe InetOrgPerson pour authentifier les utilisateurs et orienter la distribution du courrier. A savoir : uid, userPassword et mail. Il également possible d’utiliser d’autres champs en adaptant la configuration.

Allez ! C’est parti !

# aptitude install slapd ldap-utils

Le fichier de configuration de openLDAP est /etc/ldap/slapd.conf. Après l’installation, il devrait avoir la tête suivante :

/etc/ldap/slapd.conf

# Allow LDAPv2 binds
allow bind_v2
 
# Schema and objectClass definitions
include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema
 
# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile         /var/run/slapd/slapd.pid
 
# List of arguments that were passed to the server
argsfile        /var/run/slapd/slapd.args
 
# Read slapd.conf(5) for possible values
loglevel        0
 
# Where the dynamically loaded modules are stored
modulepath      /usr/lib/ldap
moduleload      back_bdb
 
# The maximum number of entries that is returned for a search operation
sizelimit 500
 
# The tool-threads parameter sets the actual amount of cpu's that is used
# for indexing.
tool-threads 1
 
#######################################################################
# Specific Backend Directives for bdb:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend         bdb
checkpoint 512 30
 
#######################################################################
# Specific Directives for database #1, of type bdb:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
database        bdb
 
# The base of your directory in database #1
suffix          "dc=linet,dc=jopa,dc=fr"
 
# Where the database file are physically stored for database #1
directory       "/var/lib/ldap"
 
# For the Debian package we use 2MB as default but be sure to update this
# value if you have plenty of RAM
dbconfig set_cachesize 0 2097152 0
 
# Number of objects that can be locked at the same time.
dbconfig set_lk_max_objects 1500
# Number of locks (both requested and granted)
dbconfig set_lk_max_locks 1500
# Number of lockers
dbconfig set_lk_max_lockers 1500
 
# Indexing options for database #1
index           objectClass eq
 
# Save the time that the entry gets modified, for database #1
lastmod         on
 
# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only
access to attrs=userPassword,shadowLastChange
        by dn="cn=admin,dc=linet,dc=jopa,dc=fr" write
        by anonymous auth
        by self write
        by * none
 
# Ensure read access to the base for things like
# supportedSASLMechanisms.  Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work
# happily.
access to dn.base="" by * read
 
# The admin dn has full write access, everyone else
# can read everything.
access to *
        by dn="cn=admin,dc=linet,dc=jopa,dc=fr" write
        by * none
#        by * read

Il est plus « sécure » de supprimer l’autorisation de lecture pour les utilisateurs non authentifiés en remplaçant « by * read » par « by * none » dans la dernière ACL.

Pour la partie cliente du serveur ldap (utile pour ldapsearch par exemple), c’est le fichier /etc/ldap/ldap.conf.

/etc/ldap/ldap.conf

# $OpenLDAP: pkg/ldap/libraries/libldap/ldap.conf,v 1.9 2000/09/04 19:57:01 kurt Exp $
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
BASE    dc=linet, dc=jopa, dc=fr
URI     ldap://localhost
#SIZELIMIT      12
#TIMELIMIT      15
#DEREF          never

Le serveur LDAP étant opérationnel, nous ajoutons quelques utilisateurs à l’annuaire. Créons un petit fichier LDIF contenant 4 utilisateurs. L’utilisateur Cyrus servira plus tard pour administrer les boites Imap.

Utilisateurs.ldif

dn: uid=cyrus,dc=linet,dc=jopa,dc=fr
uid: cyrus
cn: Administrateur Cyrus
sn: Cyrus
userPassword: MonMotDePasseSecret
objectClass: inetOrgPerson
 
dn: uid=joel,dc=linet,dc=jopa,dc=fr
uid: joel
cn: Joël PASTRE
sn: PASTRE
mail:joel@linet.jopa.fr
userPassword: LeMotDePasseDeJoel
objectClass: inetOrgPerson
 
dn: uid=jean,dc=linet,dc=jopa,dc=fr
uid: jean
cn: Jean DUPONT
sn: DUPONT
mail:jean@linet.jopa.fr
userPassword: LeMotDePasseDeJean
objectClass: inetOrgPerson
 
dn: uid=jojo,dc=linet,dc=jopa,dc=fr
uid: jojo
cn: jojo LAAAPIN
sn: LAAAPIN
mail:jojo@linet.jopa.fr
userPassword: laaaaaaaapin
objectClass: inetOrgPerson

On ajoute tout ça à l’annuaire :

# ldapadd -x -f utilisateurs.ldif -D « cn=admin,dc=linet,dc=jopa,dc=fr » -w MotDePasseAdminLDAP
adding new entry « uid=cyrus,dc=linet,dc=jopa,dc=fr »
adding new entry « uid=joel,dc=linet,dc=jopa,dc=fr »
adding new entry « uid=jean,dc=linet,dc=jopa,dc=fr »
adding new entry « uid=jojo,dc=linet,dc=jopa,dc=fr »

Voilà pour l’annuaire… penchons nous maintenant sur l’authentification…

2ème brique : SASL

# aptitude install sasl2-bin

Le fichier : /etc/saslauthd.conf (à créer de toute pièce) va permettre à saslauthd d’utiliser l’annuaire ldap comme base d’utilisateurs et de mots de passe.

/etc/saslauthd.conf

# SERVEUR LDAP
LDAP_SERVERS: ldap://localhost
 
# DOMAINE
LDAP_DEFAULT_DOMAIN: linet.jopa.fr
 
LDAP_TIMEOUT: 10
LDAP_TIME_LIMIT: 10
LDAP_CACHE_TTL: 30
LDAP_CACHE_MEM: 32768
 
# VERSION LDAP
LDAP_VERSION: 3
 
# SASL Pour l'accès au serveur
LDAP_USE_SASL: no
 
# Méthode d'authentification (bind / custom / fastbind)
LDAP_AUTH_METHOD: bind
 
# Utilisateur utilisé pour la connexion - Si vide = Anonyme
LDAP_BIND_DN: cn=admin,dc=linet,dc=jopa,dc=fr
# Et le mot de passe
LDAP_BIND_PW: MotDePasseAdminLDAP
 
# Base de départ de la recherche
LDAP_SEARCH_BASE: dc=linet,dc=jopa,dc=fr
# Et profondeur (sub / one / base )
LDAP_SCOPE: sub
 
# Filtre de recherche : uid dans notre cas
LDAP_FILTER: uid=%u
# Et nom du champ contenant le mot de passe
LDAP_PASSWORD_ATTR: userPassword

Attention : Ce fichier est créé par défaut en lecture pour tout le monde sous Debian. Il est impératif de changer ses droit pour n’autoriser la lecture qu’à l’utilisateur root.

# chmod 600 /etc/saslauthd.conf

L’activation de l’authentification sasl et l’utilisation de se fichier se font par modification de /etc/default/saslauthd.

Il faut bien penser à activer le démon (START=yes) et spécifier la méthode d’authentification utilisée par saslauthd (ldap dans mon cas).

/etc/default/saslauthd

#
# Settings for saslauthd daemon
#
# Should saslauthd run automatically on startup? (default: no)
## ICI : démarrage automatique du démon
START=yes
 
# Which authentication mechanisms should saslauthd use? (default: pam)
#
# Available options in this Debian package:
# getpwent  -- use the getpwent() library function
# kerberos5 -- use Kerberos 5
# pam       -- use PAM
# rimap     -- use a remote IMAP server
# shadow    -- use the local shadow password file
# sasldb    -- use the local sasldb database file
# ldap      -- use LDAP (configuration is in /etc/saslauthd.conf)
#
# Only one option may be used at a time. See the saslauthd man page
# for more information.
#
# Example: MECHANISMS="pam"
# ICI : Méthode d'authentification et Paramètre : Fichier saslauthd.conf
MECHANISMS="ldap"
PARAMS="-O /etc/saslauthd.conf"
 
# Additional options for this mechanism. (default: none)
# See the saslauthd man page for information about mech-specific options.
MECH_OPTIONS=""
 
# How many saslauthd processes should we run? (default: 5)
# A value of 0 will fork a new process for each connection.
THREADS=5
# Other options (default: -c)
# See the saslauthd man page for information about these options.
#
# Example for postfix users: "-c -m /var/spool/postfix/var/run/saslauthd"
# Note: See /usr/share/doc/sasl2-bin/README.Debian
 
# Nécessaire pour le chroot de Postfix (par defaut sous Debian)
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"

Démarrage du démon saslauthd:

# /etc/init.d/saslauthd start

Et test :

# testsaslauthd -u jean -p LeMotDePasseDeJean
0: OK « Success. »

# testsaslauthd -u jojo -p laaaaaaaapin
0: OK « Success. »

Bon ! Une de plus !!!

3ème brique : Cyrus

Nous voilà capable d’authentifier nos utilisateurs,  nous allons pouvoir leur créer des boites imap  (et pop accessoirement). Installons donc cyrus-imap, ses outils d’administrations, sa doc et tous les paquets nécessaires à l’authentifications sasl.

# aptitude install cyrus-admin-2.2 cyrus-clients-2.2 cyrus-imapd-2.2 cyrus-pop3d-2.2 cyrus-sasl2-doc cyrus-doc-2.2
# aptitude install libauthen-sasl-cyrus-perl libcyrus-imap-perl22 libsasl2-2  libauthen-sasl-perl libsasl2-modules

Le fichier de configuration principal est /etc/imapd.conf . Il y a juste quelques bricoles à changer :

/etc/imapd.conf

• admins: cyrus ( à décommenter : Nom de l’administrateur du serveur imapd… Si si ! C’est bien l’utilisateur cyrus que nous avons inséré dans l’annuaire),
• sasl_pwcheck_method: saslauthd (à modifier pour préciser la méthode de gestion des mots de passe),
• sasl_mech_list : PLAIN (à décommenter).

# /etc/init.d/cyrus2.2 restart

Si tout est bon, la commande : cyradm –user cyrus localhost devrait permettre la connexion au shell d’administration imap et la création des boites. Afin de garantir un nommage unique et cohérent, nous utiliserons tout simplement comme nom, l’uid de leur propriétaire.

# cyradm –user cyrus localhost
Password:
localhost> cm user.joel
localhost> cm user.jean
localhost> cm user.jojo
localhost> lm
user.jean (HasNoChildren)  user.jojo (HasNoChildren)
user.joel (HasNoChildren)
localhost> quit

Ca….C’est fait.. Il est dès à présent possible de se connecter au serveur Imap avec un client de messagerie. Bon d’accord, l’intérêt est très limité vu qu’aucun agent de distribution n’est configuré; si ce n’est pour valider le travail réalisé jusque là…

Il manque encore une brique à notre projet de maçonnerie afin de pouvoir envoyer et reçevoir des mails : C’est Postfix bien entendu…

4ème brique : Postfix

Postfix va identifier les destinataires de mails reçus en interrogeant directement l’annuaire LDAP.

Comme nous voulons que nos utilisateurs nomades puissent envoyer des mails via ce serveur, même s’ils sont à l’extérieur de mon réseau privé, nous les authentifierons sur le serveur smtp grâce à saslauthd … une fois de plus.

# aptitude install postfix postfix-tls postfix-ldap

Sur une install Debian toute neuve, aptitude détecte un conflit avec Exim4 et propose de le désinstaller. C’est bien ce qu’il faut faire !

L’installateur demande le type de serveur et le domaine de courrier. Choisissons  une configuration de type « Site Internet » et dans ce cas précis, nous travaillons sur le domaine « linet.jopa.fr ». Les réponses à ces questions n’ont pas ici, une grande importance : Nous reprendrons manuellement la configuration plus loin.

Pour que la distribution locale du courrier soit assurée par Cyrus-Imap, nous devons déclarer Cyrus comme agent de distribution. Ceci se fait par l’intermédiaire du fichier /etc/postfix/master.cf en ajoutant une ligne en fin de fichier :

/etc/postfix/master.cf

cyrus unix    -       n       n       -       -       pipe    flags=R user=cyrus argv=/usr/sbin/cyrdeliver -e -m ${extension} ${user}

Le suite se passe dans le fichier principal de configuration de postfix : /etc/postfix/main.cf

/etc/postfix/main.cf

# See /usr/share/postfix/main.cf.dist for a commented, more complete version
 
# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
 
myorigin = /etc/mailname
 
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
 
# appending .domain is the MUA's job.
append_dot_mydomain = no
 
# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h
 
# PARAMETRES TLS : Configuré automatiquement par postfix-tls
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
 
# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.
 
myhostname = labo.linet.jopa.fr
 
# PARAMETRES LDAP
mailbox_maps = ldap:/etc/postfix/ldap-accounts.cf
alias_maps = ldap:/etc/postfix/ldap-aliases.cf
 
mydestination = linet.jopa.fr, labo.linet.jopa.fr, localhost.linet.jopa.fr, localhost
relayhost =
 
# On notera que seul localhost est identifié. Les autres clients devront s'authentifier
mynetworks = 127.0.0.0/8
 
# Agent de transport local : CYRUS
local_transport = cyrus
 
recipient_delimiter = +
 
# Restrictions
smtpd_recipient_restrictions = reject_unauth_pipelining,
                                            reject_non_fqdn_recipient,
                                            reject_unauth_destination,
                                            permit_mynetworks,
                                            permit_sasl_authenticated
 
smtpd_sender_restrictions =  reject_non_fqdn_sender,
                                           reject_unknown_sender_domain,
                                           reject_unauth_pipelining,
                                           permit_sasl_authenticated,
                                           permit_mynetworks
 
# AUTHENTIFICATION SASL
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain =
 
inet_interfaces = all

Il faut particulièrement être attentif au points suivants de la configuration :

• mailbox_maps = ldap:/etc/postfix/ldap-accounts.cf et alias_maps = ldap:/etc/postfix/ldap-aliases.cf pour la validation des destinataires par recherche dans le ldap,
• mynetworks = 127.0.0.0/8 pour n’autoriser que Localhost à envoyer ou recevoir des mails (permit_mynetworks), les autres seront authentifiés via saslauthd,
• local_transport = cyrus pour déclarer Cyrus comme agent de transport local,
• et enfin, smtpd_sasl_auth_enable = yes pour activer l’authentification sasl.

Pour l’accès au LDAP, nous faisons référence à deux fichiers : /etc/postfix/ldap-accounts.cf et /etc/postfix/ldap-aliases.cf

/etc/postfix/ldap-accounts.cf

server_host = localhost
server_port = 389
search_base = dc=linet, dc=jopa, dc=fr
query_filter = (&(objectClass=InetOrgPerson)(mail=%s))
result_attribute = uid
bind = yes
bind_dn = cn=admin,dc=linet,dc=jopa,dc=fr
bind_pw = MotDePasseAdminLDAP
version = 3

/etc/postfix/ldap-aliases.cf

server_host = localhost
server_port = 389
search_base = dc=linet, dc=jopa, dc=fr
query_filter = (&(objectClass=InetOrgPerson)(mail=%s))
result_attribute = mail
bind = yes
bind_dn = cn=admin,dc=linet,dc=jopa,dc=fr
bind_pw = MotDePasseAdminLDAP
version = 3

N’oublions pas de gérer les droits de ces 2 fichiers :

# chown root:sasl ldap*.cf
# chmod 640 ldap*.cf

L’attribut en retour ici est mail (result_attribute = mail) , mais il peut être très judicieux d’ajouter à l’annuaire LDAP un champ « maildrop » qui sera retourné ici. Ce champ donnera alors une vrai fonctionnalité d’alias, permettant de transférer tout mail à destination de l’utilisateur vers une ou plusieurs autres adresses email.

De plus, il faut noter que dans la configuration actuelle et sans cette notion d’alias, une boîte cyrus doit être assiciée à chaque adresse email locale. En effet, Cyrus recherche une boîte dont le nom correspond au préfixe de l’adresse email du destinataire (ce qui est avant le @en bref).

L’authentification SASL à besoin d’un fichier : /etc/postfix/sasl/smtpd.conf . Attention, sous d’autres distributions, le fichier peut être cherché ailleur, généralement dans /usr/lib/sasl2/ ou /usr/local/lib/sasl2. Elle a également besoin que l’utilisateur « postfix » appartienne au groupe SASL.

# adduser postfix sasl
# id postfix
uid=106(postfix) gid=106(postfix) groupes=106(postfix),45(sasl)
# vi /etc/postfix/sasl/smtpd.conf

/etc/postfix/sasl/smtpd.conf

pwcheck_method: saslauthd
mech_list: plain

Note : Debian fait tourner Postfix dans un chroot. En cas de problème d’accès au socket SASL, il faut bien vérifier la ligne OPTIONS du fichier /etc/default/saslauthd.

/etc/default/saslauthd

#
# Settings for saslauthd daemon
..
# Nécessaire pour le chroot de Postfix (par defaut sous Debian)
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"

/etc/postfix/master.cf

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

Allez… Là, ça prend carrément forme. Testons sans plus attendre en configurant un serveur smtp sur notre client de messagerie préféré :

On peut remarquer que, après acceptation des certificats, la connexion sécurisée TLS fonctionne parfaitement. C’est biensûr dû à l’installation de postfix-tls qui a généré les certificats et préconfiguré Postfix. Cette fonctionnalité n’apporte malheureusement pas grand chose tant que la connexion Imap n’est pas elle aussi sécurisée, tout particulièrement dans notre cas où les noms d’utilisateurs et mots de passes sont identiques pour les deux services.

Petit retour arrière : Cyrus-Imap (TLS)

Afin d’activer le support TLS pour Cyrus-Imap, il suffit d’éditer le fichier /etc/imapd.conf et de décommenter les deux lignes suivantes (le certificat utilisé est le même que pour postfix). L’utilisateur cyrus doit appartenir au groupe ssl-cert pour pouvoir lire la clef privée.

# adduser cyrus ssl-cert

/etc/imapd.conf

tls_cert_file: /etc/ssl/certs/ssl-cert-snakeoil.pem

tls_key_file: /etc/ssl/private/ssl-cert-snakeoil.key

Il est temps maintenant de prémunir notre système contre les spams et les virus.

5ème brique : Anti-spams – GreyListing

Le greylisting (le mot anglais signifie : « inscription sur liste grise ») est une technique antipourriel très simple qui consiste à rejeter temporairement un message, par émission d’un code de refus temporaire au serveur émetteur (MTA). Dans la majorité des cas, les serveurs émetteurs réexpédient le courriel après quelques minutes. La plupart des serveurs émettant des pourriels ne prendraient pas cette peine.

( http://fr.wikipedia.org/wiki/Greylisting )

L’installation est basique, et il n’y a pas grand chose à ajouter au paramétrage par défaut.

# aptitude install postgrey

La mise en service se fait par l’ajout de la  règle « check_policy_service inet:[127.0.0.1]:60000«   à  « smtpd_recipient_restrictions » dans le fichier /etc/postfix/main.cf

/etc/postfix/main.cf

smtpd_recipient_restrictions = reject_unauth_pipelining,
permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_recipient,
reject_unauth_destination,
check_policy_service inet:[127.0.0.1]:60000

6ème brique : Anti-spams / Antivirus – Amavis / SpamAssassin / Clamav

C’est Amavis qui va être chargé du filtrage de contenus, en s’appuyant sur Spamassassin contre les spams et Clamav contre les virus. Clamav dispose d’un outil permettant la mise à jour des signatures virales : freshclam. Pour avoir des mises à jour plus régulière, il suffit d’ajouter un dépot debian-volatile à la liste des dépôts. Par exemple :

# echo « deb http://ftp2.de.debian.org/debian-volatile lenny/volatile main contrib » > /etc/apt/sources.list.d/volatile.list
# aptitude update

Passons à l’installation :

# aptitude install amavis-new clamav clamav-freshclam clamav-daemon spamassassin

L’activation du démon spamassassin se fait par l’intermédiaire du fichier « /etc/default/spamassassin » en plaçant l’option ENABLED à 1

/etc/default/spamassassin

# /etc/default/spamassassin
# Duncan Findlay
 
# WARNING: please read README.spamd before using.
# There may be security risks.
 
# Change to one to enable spamd
ENABLED=1
 
# Options
# See man spamd for possible options. The -d option is automatically added.
 
# SpamAssassin uses a preforking model, so be careful! You need to
# make sure --max-children is not set to anything higher than 5,
# unless you know what you're doing.
 
OPTIONS="--create-prefs --max-children 5 --helper-home-dir"
 
# Pid file
# Where should spamd write its PID to file? If you use the -u or
# --username option above, this needs to be writable by that user.
# Otherwise, the init script will not be able to shut spamd down.
PIDFILE="/var/run/spamd.pid"
 
# Set nice level of spamd
#NICE="--nicelevel 15"

Il faut ensuite demander à postfix d’utiliser Amavis pour le filtrage de contenus. Revenons une fois de plus dans notre fichier « /etc/postfix/main.cf » pour ajouter la directive :content_filter = smtp-amavis:[127.0.0.1]:10024

/etc/postfix/main.cf

content_filter = smtp-amavis:[127.0.0.1]:10024
 
smtpd_recipient_restrictions = reject_unauth_pipelining,
permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_recipient,
reject_unauth_destination,
check_policy_service inet:[127.0.0.1]:60000
 
smtpd_sender_restrictions =  permit_sasl_authenticated,
permit_mynetworks,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_unauth_pipelining

Afin de pouvoir utiliser l’agent de transport smtp-amavis, nous devons le définir dans le fichier « master.cf » de postfix :

/etc/postfix/master.cf

...
#CLAMAV-AMAVIS
smtp-amavis unix - - n - 2 smtp
        -o smtp_data_done_timeout=1200
        -o smtp_send_xforward_command=yes
        -o disable_dns_lookups=yes
127.0.0.1:10025 inet n - n - - smtpd
        -o content_filter=
        -o local_recipient_maps=
        -o relay_recipient_maps=
        -o smtpd_restriction_classes=
        -o smtpd_client_restrictions=
        -o smtpd_helo_restrictions=
        -o smtpd_sender_restrictions=
        -o smtpd_recipient_restrictions=permit_mynetworks,reject
        -o mynetworks=127.0.0.0/8
        -o strict_rfc821_envelopes=yes
        -o smtpd_error_sleep_time=0
        -o smtpd_soft_error_limit=1001
        -o smtpd_hard_error_limit=1000
...

Pour finir avec amavis, un brin de configuration est nécessaire pour activer le filtrage anti-spam et anti-virus.

/etc/amavis/conf.d/15-content_filter_mode

use strict;
 
# You can modify this file to re-enable SPAM checking through spamassassin
# and to re-enable antivirus checking.
 
#
# Default antivirus checking mode
# Uncomment the two lines below to enable it back
#
 
@bypass_virus_checks_maps = (
   %bypass_virus_checks, @bypass_virus_checks_acl, $bypass_virus_checks_re);
 
#
# Default SPAM checking mode
# Uncomment the two lines below to enable it back
#
 
@bypass_spam_checks_maps = (
   %bypass_spam_checks, @bypass_spam_checks_acl, $bypass_spam_checks_re);
 
1;  # insure a defined return

Il nous faudra, si cela n’est pas fait à l’installation, ajouter l’utilisateur clamav au groupe amavis.

# adduser clamav amavis

7ème brique : Anti-spams (encore) – Listes RBL

Enfin, nous pouvons utiliser des blacklistes externes pour parfaire notre filtrage anti-spam. Il en existe un paquet, mais leur utilisation est similaire. Dans l’exemple, utilisons deux « blacklist » publiques en fin de filtrage : dul.dnsbl.sorbs.net et  zen.spamhaus.org. Il faut encore une fois ajouter deux règles « smtpd_recipient_restrictions » au fichier /etc/postfix/main.cf

/etc/postfix/main.cf

smtpd_recipient_restrictions = reject_unauth_pipelining,
permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_recipient,
reject_unauth_destination,
check_policy_service inet:[127.0.0.1]:60000,
reject_rbl_client dul.dnsbl.sorbs.net,
reject_rbl_client zen.spamhaus.org

Voilà pour cet article. Même s’il reste pas mal d’améliorations possibles, d’optimisations et fonctionnalités supplémentaires à ajouter, on va dire que c’est un bon début.

Sources :

• http://flurdy.com/docs/postfix/#config-secure-auth
• http://www.luxpopuli.fr/Internet/Postfix-Cyrus-IMAP-SSL-LDAP/Cyrus-IMAP-authentification-LDAP
• http://www.bizeul.net/
  

Nous entendons par « outil collaboratif » :

• Une messagerie accessible depuis un client classique (Thunderbird par exemple) ou en webmail,
• Un annuaire commun centralisé,
• Un agenda partagé,
• Un gestionnaire de tâches,
• Et éventuellement un système de partages ou de diffusion de fichiers.

La solution doit, bien entendu être libre et sera installée et administrée par nos soins. Après un petit tour rapide, il nous est apparu que 3 produits sortaient du lot et méritaient des tests plus approfondis : e-groupware, OBM et Zimbra.

Tous ces produits disposent d’une démo en ligne, mais pour évaluer ce qui nous attends en terme de tâches d’administration quotidienne, nous avons entrepris d’installer et de mettre en test chacun d’entre eux.

La suite de ce billet est consacrée à l’installation et à la mise en route de Zimbra. Il ne sagit pas ici, de faire une présentation détaillée du logiciel ou un guide d’utilisation. E-groupware et OBM feront l’objet de futurs articles.

Présentation

Zimbra est donc un logiciel collaboratif (groupware) qui permet à ses utilisateurs de stocker, organiser et partager rendez-vous, contacts, email, liens, documents et plus.
Il a la particularité d’être développé en « Web Service » et de disposer d’une interface AJAX très réactive par rapport à un développement web « classique ».

En 2007, Zimbra a été racheté par la société Yahoo qui publie la version 5 sous licence « YPL (Yahoo Public Licence)« .  De ce côté et avant même l’installation, Zimbra perd un peu d’avantage par rapport aux autres produits sous licence GPL.

Zimbra Collaboration Suite (ZCS) est disponible en version Open Source et plusieurs déclinaisons commerciales.

Pour en savoir plus, je vous invite à consulter le site de Zimbra ou Wikipedia.

Installation

ZCS est une solution pacagée, c’est a dire qu’il s’installe sur un système quasi « vierge », ses paquets contenant la majorité des briques logicielles nécessaires (apache2, postfix, cyrus, openldap, etc…). Il est donc illusoire de penser l’installer en sur-couche de la solution de messagerie existante sur notre serveur.

Pour réaliser cette installation, nous allons donc partir d’une Debian Etch de base toute fraiche, sur laquelle nous allons installer quelques librairies et outils indispensables au bon déroulement des opérations, sans oublier de supprimer exim4 qui est installée par defaut sous Etch.

Il faut préciser, qu’en tant que serveur de mails, la machine doit disposer d’un enregistrement MX dans un DNS. Une vérification sera effectuée lors de l’installation.

A noter également que l’installation est réalisée dans /opt et qu’il faut donc prévoir un partitionnement adéquat.

# aptitude purge exim4 exim4-base exim4-config exim4-daemon-light
# aptitude install libidn11 fetchmail libpcre3 libgmp3c2 libexpat1 libxml2 libltdl3
# aptitude install openssl perl ca-certificates xml-core file sudo

Les paquets d’installation de l’édition open source sont disponibles sur cette page : http://www.zimbra.com/community/downloads.html

# wget -c http://h.yimg.com/lo/downloads/5.0.11_GA/zcs-5.0.11_GA_2695.DEBIAN4.0.20081117055537.tgz
# tar -xvzf zcs-5.0.11_GA_2695.DEBIAN4.0.20081117055537.tgz
# cd zcs-5.0.11_GA_2695.DEBIAN4.0.20081117055537
# ./install.sh
 
...
 
Select the packages to install
 
Install zimbra-ldap [Y]
Install zimbra-logger [Y]
Install zimbra-mta [Y]
Install zimbra-snmp [Y]
Install zimbra-store [Y]
Install zimbra-apache [Y]
 
Install zimbra-spell [Y]
Install zimbra-proxy [N]
Installing:
zimbra-core
zimbra-ldap
zimbra-logger
zimbra-mta
zimbra-snmp
zimbra-store
zimbra-apache
zimbra-spell
 
The system will be modified.  Continue? [N] Y
 
DNS ERROR resolving MX for labo.linet.jopa.fr
It is suggested that the domain name have an MX record configured in DNS
Change domain name? [Yes]
Create Domain: [labo.linet.jopa.fr] linet.jopa.fr
 
MX: labo.linet.jopa.fr (192.168.7.10)
 
Interface: 192.168.7.10
Interface: 127.0.0.1
...
 
Main menu
 
1) Common Configuration:
2) zimbra-ldap:                             Enabled
3) zimbra-store:                            Enabled
+Create Admin User:                    yes
+Admin user to create:                 admin@linet.jopa.fr
******* +Admin Password                        UNSET
+Enable automated spam training:       yes
 
+Spam training user:                   spam.hitallfx@linet.jopa.fr
+Non-spam(Ham) training user:          ham.fik7gntz@linet.jopa.fr
+Global Documents Account:             wiki@linet.jopa.fr
+SMTP host:                            labo.linet.jopa.fr
+Web server HTTP port:                 80
+Web server HTTPS port:                443
+Web server mode:                      http
+IMAP server port:                     143
+IMAP server SSL port:                 993
+POP server port:                      110
+POP server SSL port:                  995
 
+Use spell check server:               yes
+Spell server URL:                     http://labo.linet.jopa.fr:7780/aspell.php
+Configure store for use with reverse mail proxy: FALSE
+Configure store for use with reverse web proxy: FALSE
 
4) zimbra-mta:                              Enabled
5) zimbra-snmp:                             Enabled
6) zimbra-logger:                           Enabled
7) zimbra-spell:                            Enabled
8) Default Class of Service Configuration:
r) Start servers after configuration        yes
s) Save config to file
 
x) Expand menu
q) Quit

Il ne faut pas oublier, à cette étape, de renseigner le mot de passe administrateur ( Menu 3, puis 4 ).

Configuration et administration

L’interface d’administration est disponible en https sur le port 7071.

C’est à partir de cette interface que nous pouvons gérer les utilisateurs du système (comptes, boites aux lettre, groupes, listes de diffusion, etc…), paramétrer le serveur, afficher des états ou des statistiques et gérer les files de messagerie.

L’interface, bien que riche en fonctionnalités est claire, intuitive et sa prise en main ne pose pas de difficulté particulière.

Aperçu

Nous l’avons vu dans la présentation, zimbra intègre tous les composants indispensables à un bon groupware. L’interaction entre ces différents composants et la dynamique apportée par Ajax (cliqué déplacé, menus contextuels, etc…) nous font oublier, dès les premiers instant, que nous sommes dans une application web.

Client « lourd »

ZCS dispose de son propre client « déconnecté ». Ce qui est très pratique pour consulter ses mails, contact et agenda sans connexion internet, dans un logiciel offrant la même interface que l’application web.

Il est biensûr possible d’y connecter un client de messagerie classique. Nous allons voir un exemple avec Thunderbird et son extention calendrier : « Lightning« .

Côté boites au lettres et serveur SMTP, il est possible d’utiliser des connexions sécurisées (TLS ou mieux, SSL).

La connexion à l’annuaire ne pose pas, non plus, de difficulté particulière, à part peut-être pour la connexion SSL que je n’ai pas réussi à faire fonctionner.

La dernière étape est une connexion au calendrier grâce à l’extension Ligthning de Thunderbird et au protocole webcal.

L’url à utiliser est la suivante : webcal://Utilisateur:Mot_de_passe@Serveur-Zymbra/home/Utilisateur/Calendar

En conclusion…

Je peux dire que ZCS est un produit très complet et bien fini. Son installation et sa mise en route ne posent aucun problème et l’étendu de ses possibilités sont énormes, tant en terme d’utilisation que d’architecture et de configuration (installation multi-domaines, multi-serveurs, etc…).

On regrettera son côté un peu trop pacagé qui empêche son intégration dans un environnement existant, mais ceci a le mérite d’en faire un produit très facilement configurable et rapidement opérationnel.

Son plus gros défaut est sûrement sa licence…

Après une installation classique de postfix, quelques paramètres sont à renseigner dans le fichier /etc/postfix/main.cf

# /etc/postfix/main.cf - Exemple d'une configuration de backup smtp
...
# Le serveur va conserver les messages dans la file d'attente pendant 60 jours
# ( grosse panne du serveur principal !!!)
maximal_queue_lifetime = 60d
 
# Définition du nom du serveur
myhostname = mailbackup.jopa.fr
 
# Rien n'est délivré localement...
# à part éventuellement les messages adressés à "localhost"
mydestination = localhost
 
# On n'autorise l'utilisation du serveur SMTP qu'à la machine locale.
# Aucun autre client ne doit pouvoir envoyer des mails par ce serveur.
mynetworks = 127.0.0.0/8
 
# Adresse IP du serveur à relayer...
# Dans ce cas, l'IP du serveur principal
relayhost = 87.98.175.90
 
# Et enfin, la liste de domaines relayés
relay_domains = jopa.fr
...
# Activation des restrictions du serveur SMTP
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination

Ce n’est pas une mauvaise idée d’ajouter des filtres antispam et antivirus à la configuration, pour soulager la reprise du serveur principal.
Dans l’exemple suivant, utilisation de classiques tels que  Amavis, Greylist et interrogation de listes RBL…

...
# Amavis
content_filter = smtp-amavis:[127.0.0.1]:10024
# Activation des restrictions du serveur SMTP
smtpd_recipient_restrictions =
permit_mynetworks,
reject_unauth_destination,
check_policy_service inet:[127.0.0.1]:60000,
reject_rbl_client dul.dnsbl.sorbs.net,
reject_rbl_client zen.spamhaus.org

La dernière étape est l’ajout du serveur mail dans la zone DNS, afin qu’il soit reconnu en tant que tel sur Internet. L’enregistrement doit être fait avec un poids plus fort, pour donner la priorité au serveur principal.

...
mail 28800 IN A 87.98.175.90
mailbackup 28800 IN A 81.252.145.28
@ 28800 IN MX 10 mail.jopa.fr.
@ 28800 IN MX 20 mailbackup.jopa.fr.

Comme beaucoup de monde, je dispose de plusieurs adresses email - hum… Comment dit-on « adresse email » déjà, in french… Oh ! yes ! « adresse mèl » - Pour être sûr de ne rien manquer, je m’arrange pour que tous mes messages finissent dans la même boîte.

Oui, mais voilà, le fournisseur de ma.belle.adresse@free.fr ne propose pas de transfert automatique de messagerie…

On ne va quand même pas se laisser démonter par si peu, car heu-reu-se-ment il-y-a Fetch-mail… Fetchmail ! - ne cherchez surtout pas le rapport avec une marque de produits surgelés, il n‘y en a pas ! - Fetchmail va nous permettre d’extraire des messages accessibles en pop ou imap, pour les faire suivre vers une adresse de notre choix…En clair, réaliser un transfert. - a forward in english… -

Il nous faudra pour cela disposer d’une machine capable d’envoyer des mails et sur laquelle on aura pris soin d’installer Fetchmail. Un petit coup de aptitude, emerge, ipkg ou urpmi devrait faire l’affaire… Les possesseurs d’une distribution plus exotique pourront utiliser leur gestionnaire de paquets habituel ou télécharger les sources : http://www.fetchmail.info .

L’étape suivante va consister à paramétrer Fetchmail pour qu’il accède à notre boîte mail (celle que l’on veut faire suivre). Dans notre répertoire utilisateur (~), nous allons créer un fichier .fetchmailrc et lui insérer une ligne similaire à l’exemple suivant :

poll pop.free.fr proto pop3 user « ma.belle.adresse » password « mot_de_passe »

C’est suffisant pour le fichier .fetchmailrc, sauf si l’on souhaite traiter plusieurs boîtes mail, dans ce cas, il faudra répéter la ligne autant de fois que nécessaire.

Ai-je besoin de détailler ?

• poll pop.free.fr : pop.free.fr est le serveur que nous voulons interroger,
• proto pop3 : spécification du protocole utilisé par le serveur (pop3 dans notre cas),
• user et password pour le nom d’utilisateur et le mot de passe de messagerie.

La commande qui va permettre de traiter les messages doit être formulée de la façon suivante :

$ fetchmail -p POP3 -u ma.belle.adresse –smtpname jopa@ma.new.adress.com -a -v pop.free.fr

• -p POP3 : pour le protocole pop3,
• -u ma.balle.adresse : nom d’utilisateur (le même que dans le .fetchmailrc),
• –smtpname jopa@ma.nouvelle.adresse.com : adresse à laquelle les messages doivent suivre (attention, il y a bien 2 tirets devant smtpname),
• -a : Récupérer tous les messages (pas seulement les nouveaux),
• -v : mode verbeux – « verbose » in english - est optionnel, mais aide bien pour voir ce qu’il se passe,
• pop.free.fr: Le serveur hébergeant la boîte d’origine (le même que dans le .fetchmailrc).

Pour que cette tâche s’exécute toutes les 5 minutes, je vais tout simplement opter pour un bon petit crontab.

$ crontab -e

# m h dom mon dow command

*/5 * * * * /usr/bin/fetchmail -p POP3 -u ma.belle.adresse –smtpname jopa@ma.new.adress.com -a -v pop.free.fr