Installation Serveur Mail Postfix, Amavisd, Mysql, Spamassassin, Dspam, Dovecot

Préparation de l’environnement

On prendra comme base pour l’exemple le domaine starbridge.org et le hostname du serveur de mail sera spike.

On met le système à jour :

On vérifie les fichiers :

• /etc/hostname :

• /etc/hosts :

Cache DNS Local

Le fonctionnement d’un serveur de mail nécessite l’utilisation intensive de requêtes DNS.
Pour des raisons de performances, il est très fortement conseillé d’installer un cache DNS local.

La configuration de base sous Debian fournie un serveur cache (on peut bien sur le configurer pour gérer son domaine local voire son domaine public mais ce n’est pas le sujet de cet article).

On modifie le /etc/resolv.conf pour pointer en local :

on relance le serveur DNS :

/etc/init.d/unbound restart

Puis on teste la résolution avec nslookup ou dig

doit retourner :

puis :

>yahoo.fr

La résolution doit se faire correctement.

On installe ensuite les outils pour la compilation, ils seront nécessaires tout au long de l’installation :

On crée le dossier de configuration général :

Postfix et Mysql

La version stable de Debian (Jessie) utilise postfix 2.11.3.
La derniere version de Postfix est la 3.1
La version Testing de Debian utilise la version 3.1

Le fait de rester en 2.11 n’impacte pas les fonctionnalités mises en place dans le tuto (retrocompatibilité), donc pour le moment il n’est pas forcément nécessaire de passer en 3.1 pour ceux qui sont en debian stable

On lance l’installation de postfix :

l’installeur va demander l’effacement de exim que l’on valide
puis il va demander le type d’installation pour postfix, on laisse tout par défaut.

on installe ensuite les autres paquets nécessaires :

voir le sujet sur le forum concernant l’optimisation de mysql :
https://www.starbridge.org/support/viewtopic.php?f=6&t=1599

On installe apache + php5 pour gérer plus tard le tout avec l’interface postfixadmin.

Note : Il est fortement conseillé d’installer le SSL avec Apache pour sécuriser les échanges. Cette configuration sera détaillée plus loin lors de l’installation de Postfixadmin.

Pour ceux qui le préfère, on peut tout de suite installer Phpmyadmin pour effectuer l’étape suivante.
(on ne détaillera pas cette installation, en dehors du scope de ce document)

On passe donc à la création de la base sql Postfix :

Note : Si l’on a mis un password lors de l’installation du paquet mysql, il faut sauter la première commande ci dessous et exécuter directement la seconde.

Création de l’user postfix :

On crée les tables suivantes dans la base Postfix :

Evidemment on modifie la commande sed pour inclure son domaine.

Explications :
Seules 3 tables sont nécessaires à Postfix.
Le reste est pour l’interface Postfixadmin que l’on installera plus tard.

Le password (MD5) est "secret"

Le premier INSERT permet à Postfix de savoir que ce domaine est virtuel et qu’il doit donc le gérer.

Le 3ème INSERT est un alias virtuel pointant vers un user de la table mailbox. Cet alias vers lui même sera utilisé par Postfixadmin.

le 4ème INSERT est un simple alias virtuel.

Le 7ème INSERT est un compte (boite email) virtuel, qui utilise un mot de passe encrypté en MD5.

Les deux derniers INSERT permettent de créer le superadministrateur que l’on utilisera plus tard dans Postfixadmin.
#PAGINATION

Paramétrage de Postfix

On remplace tout le /etc/postfix/main.cf par le contenu ci dessous :
n’oubliez pas de remplacer myhostname = spike.starbridge.org par votre domaine

Ceux qui sont en postfix 2.10 et supérieur doivent ajouter cette ligne au dessus du bloc smtpd_recipient_restrictions

ce qui donne :

On modifie le /etc/postfix/master.cf comme ci dessous :

On crée le groupe et le user vmail avec l’uid et gid 20001, ainsi que le répertoire des mails :

On sécurise :

On crée les fichiers d’appel des tables par Postfix :
(la commande sed permet de specifier votre password d’accès à la base, dans l’exemple ici c’est toto)

On sécurise le tout :

Activation du TLS

Pour un serveur en production, il serait préférable d’utiliser un véritable certificat fourni et signé par une autorité de certification de confiance.

On édite la configuration de ssl pour pouvoir signer des certificats sur 10 ans, au lieu de 1 an par défaut :

on change la ligne default_days en

On crée le Certificat Racine :

on entre les parametres requis, on choisis un pass phrase de son choix et on laisse "challenge password" vide.

Ce certificat racine sert à signer les certificats. Il est localisé dans le répertoire /demoCA.

On crée maintenant une clé privée pour le serveur ainsi qu’un csr (Certificate Signing Request : demande de signature de certificat).

et on entre les paramètres comme ci dessous :

Note : le paramètre le plus important est le Common Name qui doit être le même que le nom avec lequel se connecte les clients sur le serveur. Ici il s’agit du FQDN : spike.starbridge.org.

cela génère 2 fichiers :
la clé privée, à protéger absolument
la demande de certificat, qui est pour faire simple un certificat public non signé

On signe maintenant notre certificat public avec le certificat racine :

Voici la sortie de la signature :

On copie maintenant le certificat et la clé dans postfix :

On ajoute ceci au /etc/postfix/main.cf :

On redémarre Postfix :

on testera le fonctionnement après l’installation de dovecot.

Dovecot : SASL, LDA, IMAP et SIEVE

De "simple" serveur imap, Dovecot est devenu un ensemble d’outils indispensables pour la messagerie :
 il permet de gérer le SASL très simplement au travers de Postfix afin de fournir à ce dernier un moyen d’authentifier les transactions SMTP,
 il fournit un agent de livraison de mail très performant et parfaitement intégré à Postfix,
 il permet de prendre en charge le langage Sieve pour le filtrage des mails lors de la livraison,
 et bien sur, il demeure un serveur imap rapide et léger.

On va détailler ici son installation, fonction par fonction.

Installation de Dovecot :

On va utiliser la version 2.2 de Dovecot.
On compilera depuis les sources.

Créer les users pour dovecot :

on compile :

On copie les fichiers de configuration nécessaires :

On indique le password de la table postfix :

on ne relance pas encore dovecot pour le moment

La livraison des emails : Dovecot LDA

 Nous avons maintenant besoin d’un MDA (mail delivery agent) pour livrer les mails dans les boîtes.
Le service de livraison Virtual de Postfix ne convient pas totalement pour notre usage.
En effet nous allons avoir besoin de capacité de filtrage sur le MDA ainsi que la possibilité de gérer les quotas, ce que ne sait pas faire Virtual.
Procmail est très bien pour le filtrage, mais ne supporte pas les users/domaines virtuels, car il ne sait pas communiquer avec une base de données.
Une méthode répandue pour les quotas est l’application du patch VDA sur Postfix, option que nous ne choisirons pas pour des raisons de fiabilité.

Maildrop convient bien, il a d’ailleurs longtemps été utilisé dans ce tuto, mais nous l’avons maintenant remplacé par le MDA inclus dans Dovecot, plus performant et surtout très bien maintenu.

C’est donc Dovecot LDA (Local Delivery Agent, le MDA de dovecot) qui s’occupera de la livraison des mails dans les home.

Il faut configurer Postfix pour qu’il utilise Dovecot comme MDA :

On ajoute ceci au /etc/postfix/main.cf :

et on ajoute un transport dovecot au /etc/postfix/master.cf :

A noter que la configuration du tuto permet de choisir son transport par domaine. Il faut pour cela choisir Dovecot dans la configuration de domaine dans Postfixadmin.
Le domaine par défaut, crée par le script sql du tuto, est déja paramétré pour utiliser Dovecot.

Dovecot est également préconfiguré pour utiliser les mêmes certificats SSL que Postfix, que l’on a généré dans l’étape précédente.
Il n’y a donc rien de particulier à configurer pour le SSL sauf si vous avez modifié les noms de fichiers des certificats ssl à l’étape postfix.

il faut maintenant créer un fichier /etc/init.d/dovecot :

On lance Dovecot :

on relance Postfix

On verifie dans les logs que tout a démarré correctement.

On teste cette première configuration de base en envoyant un mail a user@starbridge.org

note : il faut taper un . (un point seul sur la ligne) pour terminer le message.

On regarde les logs pour les erreurs.
Si tout a fonctionné on devrait trouver dans une ligne :

note : si la commande mail n’existe pas sur le système (Ubuntu par exemple) l’installer avec aptitude install mailx

Puis on teste en direct sur le port 25 :

(ce qu’il faut taper est précédé de --->, le reste c’est le retour du serveur) :

On regarde les logs pour vérifier.

on regarde dans le dossier /home/virtual/user@starbridge.org : on devrait trouver les dossiers suivants :

En regardant dans mailboxes on trouvera les dossiers par défaut qui sont crées automatiquement.

Sieve

Dovecot LDA permet d’utiliser le langage de filtrage Sieve.
Celui-ci offre la possibilité d’appliquer des règles spécifiques pour les utilisateurs (redirection dans les répertoires, etc).
Mais avant cela, nous avons besoin d’un fichier de filtre Sieve global (son utilisation est paramétrée dans dovecot.conf) qui permettra de rediriger les spams dans un dossier de l’utilisateur :

on crée le fichier global.sieve :

vi /home/virtual/sieve/global.sieve

on sécurise :

• NOTE : Le fichier global.sieve est commun à tous les comptes et sera appliqué à chaque mail. Si l’on veut appliquer des règles spécifiques à un utilisateur, il suffit de créer un autre fichier sieve dans son Maildir. On pourra par exemple rediriger des emails dans des répertoires spécifiques de cette façon. Dovecot cherche pour cela le fichier dovecot.sieve dans le maildir de l’utilisateur.

Pour la création assistée et autonome (par les utilisateurs eux-mêmes) des fichiers Sieve personnels on pourra utiliser un module du Webmail horde.
L’article sur l’installation du Webmail traite ce point en détail.

Il est également possible d’utiliser le protocole Sieve pour créer/modifier les scripts depuis un client lourd, Thunderbird propose par exemple un plugin pour la gestion des scripts Sieve.
Le port de connection par défaut est le 4190.
Les users seront ainsi totalement autonomes sur la gestion de leur paramètres de filtrage.

Consultation des emails par IMAP

On teste l’imap en TLS sur le port 143 depuis un client mail.
Si tout fonctionne correctement on doit accéder aisément aux messages de tests précédents depuis le client mail.

Prise en charge du SASL par Dovecot :

Enfin, on passe à la configuration SASL :

On ajoute ceci au /etc/postfix/main.cf :

On ajoute également "permit_sasl_authenticated" dans "smtpd_recipient_restrictions" pour valider les restrictions (attention à bien placer le paramètre exactement à l’endroit indiqué) :

on relance Postfix :

postfix reload

On vérifie le fonctionnement depuis un client mail configuré pour l’authentification SASL sur un chiffrement TLS avec les mêmes identifiants que pour la connexion IMAP (ne pas oublier le @starbridge.org).
Pour le type d’authentication, il faut sélectionner "en clair" (le terme dépend du client mail).

C’est le chiffrage de la connexion par le TLS qui sécurisera le transfert du password.
C’est pour cela qu’il ne faut pas dissocier TLS et authentification.

Note : la directive smtpd_tls_auth_only = yes impose l’usage d’une connexion sécurisée pour l’authentification SASL, ce qui limitera les erreurs de configuration des utilisateurs.

Installation PostfixAdmin

Pour faciliter la création des users et la gestion des boîtes et des comptes, on utilise Postfixadmin.

Nous utiliserons une version modifiée que nous prendrons par SVN.

Activation du SSL dans Apache

Le SSL est indispensable pour sécuriser les échanges, en particulier les mots de passe utilisateurs.

On active le SSL par la commande :

Puis on crée le virtual host :

Et on colle :

puis on active le virtual host :

Génération des certificats :

Il est important de créer un certificat avec le même nom que celui utilisé pour la connection.
Par exemple si on se connecte au serveur web par www.starbridge.org il faut créer un certificat avec un Common Name en www.starbridge.org.

On part du principe que l’on utilise www.starbridge.org.

On crée donc un certificat public non signé et une clé, puis on le signe avec le CA :

On entre les informations en prenant soin de bien spécifier le Common Name en www.starbridge.org.
Il faut également respecter les informations entrées plus tôt dans le CA.

On redémarre Apache :

On teste la connexion par

https://www.starbridge.org

Le navigateur va demander la validation du certificat car celui ci n’est pas reconnu par une autorité de confiance. Ceci est normal (c’est un certificat self-signed).

Pour un serveur en production, il serait donc préférable d’utiliser un véritable certificat (payant).

Il faut remplacer toutes les entrées starbridge dans le fichier de configuration par celles correspondantes à votre domaine.
(toto est le password pour la base sql postfix et toto.com votre domaine) :

On sécurise ce fichier :

On se connecte ensuite à l’interface :

https://www.starbridge.org/postfixadmin-relay

(bien sur on remplace starbridge par votre domaine sinon vous vous connectez chez moi !!)

On s’identifie avec @starbridge.org (on l’a créé plus tôt lors des inserts sql - on rappelle que le password est ’secret’)

On retrouvera les éléments entrés en ligne de commande au début du document.
On crée un nouvel utilisateur pour valider.

[rouge]On rappelle que l’utilisation du SSL pour se connecter à Postfixadmin est INDISPENSABLE si on doit passer par internet pour gérer la plateforme. Sur un réseau local son utilisation serait préférable.[/rouge]

La gestion des Quotas

On l’a vu, on a installé dovecot LDA qui prend en charge les quotas et on a paramétré dans la base SQL des champs pour les gérer.
Il faut maintenant les paramétrer :

On crée un message d’alerte générique pour le dépassement de quotas :
(on pensera à l’adapter a ses besoins mais il faut être prudent dans la mise en forme du fichier)

Le reste est déjà paramétré dans Dovecot.

Il suffit d’utiliser Postfixadmin pour régler un quota pour un utilisateur.
Le faire avec l’utilisateur user@starbridge.org qui par défaut n’a pas de quota.

On teste en envoyant un mail.

On regarde les logs.

Voila le serveur est configuré !

A ce stade le serveur est sécurisé mais ne filtre ni les virus, ni les spams.

Antispam / Antivirus

Paramétrage de Postfix :

Une grande majorité des spams ne respecte pas les règles d’envoi d’email : HELO incorrect, MAILFROM d’un domaine inconnu, etc, etc...

Il est très fortement conseillé de lire des documents sur ce sujet, notamment les RFC pour bien comprendre le fonctionnement.

La première chose à faire est de renforcer Postfix pour qu’il soit beaucoup plus restrictif.

Pour cela on va utiliser les smtpd_recipient_restrictions.

On ne détaillera pas ici les actions précises de chaque règle. (la documentation de Postfix est très complète sur le sujet et l’article sur la gestion du serveur de mail revient sur tous les points en les détaillant).

On édite le main.cf et on remplace tout le smtpd_recipient_restrictions par celui ci :

on va aussi paramétrer 4 RBL (des blacklists) qui filtrent très efficacement.
Pour cela, on va se servir d’une fonctionnalité apparue depuis la version 2.8 de postfix : postscreen.

Toujours dans le main.cf, on ajoute tout en bas du fichier :

Dans le master.cf, on commente la première ligne :

et on décommente les suivantes :

• ATTENTION : Il existe d’autres RBL qui peuvent rendre le filtrage encore plus restrictif mais je déconseille de les installer dans Postfix sur un serveur en production, bien que l’on puisse se servir des tables ci dessous (mysql-sender.cf et mysql-client.cf) pour whitelister certains clients ou expéditeurs).

Il vaut mieux gérer les RBL supplémentaires au travers de Spamassassin.

A noter que Postscreen effectue egalement une autre vérification (greet_action) qui est particulièrement efficace (voir la doc de Postfix pour en comprendre le fonctionnement)

 Ensuite il faut limiter les possibilités de forging des expéditeurs en vérifiant les MAIL FROM (adresses expéditrices).

Toujours dans le main.cf, on place au dessus du bloc smtpd_recipient_restrictions = :

Cela permettra d’empécher des utilisateurs de mettre une autre adresse email dans le MAIL FROM. Ils seront obligés de passer par les domaines que l’on gère.

De même, les utilisateurs authentifiés par SASL seront tenus d’utiliser comme adresse email (MAIL FROM) un alias valide de leur mail principal (on détaillera ce fonctionnement dans le document sur la gestion du serveur).

 Il faut maintenant créer les fichiers suivants :

• • On crée le fichier /etc/postfix/internal_networks :

On édite ce fichier et on spécifie son réseau local et son adresse publique à l’intérieur :

Cela permet de spécifier la ou les plages IP de notre réseau, qui seront autorisées à envoyer un mail avec nos domaines dans le MAIL FROM.
Cela permet également de préciser les IP autorisées à envoyer un mail en se présentant avec notre HELO.
On bloquera ainsi les clients SMTP extérieurs qui se présentent avec un HELO qui est le notre :

• • Ensuite on crée les fichier suivants qui appellent les tables SQL.

Pour info voici leurs fonctions :

• • • /etc/postfix/mysql-hello.cf : Cette table SQL listera les HELO de nos domaines email (on peut en posséder plusieurs dans le cas d’un serveur multidomaine).

• • • /etc/postfix/mysql-sender.cf : Il sert à blacklister ou whitelister les MAILFROM, c’est à dire les expéditeurs, selon leur adresse email ou juste le domaine de celle ci.

• • • /etc/postfix/mysql-client.cf : Il sert à blacklister ou whitelister les clients par leur connection (ip/domaine).

• • • /etc/postfix/mysql-sasl-sender-check.cf : Il sert à spécifier les adresses que les utilisateurs authentifiés par SASL peuvent utiliser comme MAIL FROM.
      On remarquera que l’on fait appel à la table alias. En effet c’est le meilleur endroit pour connaître les MAIL FROM d’un utilisateur, car un mail from valide doit être une adresse valide pour cet utilisateur. (donc un de ces alias)

• • • /etc/postfix/mysql_our_domain_as_sender.cf : Il sert à spécifier les domaines autorisés comme MAIL FROM pour les users internes authentifiés par leur IP (les clients en local peuvent envoyer un email local sans s’authentifier dans notre configuration)

• • • /etc/postfix/our_domain_as_sender : Il sert à spécifier le null sender pour la regle du dessus.

On postmape les fichiers qui le nécessitent :

On modifie le password des fichiers de lookup (la commande sed permet de spécifier votre password d’accès à la base, dans l’exemple ici c’est toto) :

Et on sécurise les fichiers de lookup :

 On crée les tables en question :

Evidemment, on modifie la commande sed pour inclure son domaine. Ici c’est toto.com

On relance Postfix

on vérifie les logs et on teste.

On a inséré des exemples de blacklist et de whitelist.

Tout le détail du fonctionnement se trouve dans le document gestion serveur de mail.

On peut utiliser PhpMyadmin pour gérer ces tables SQL.

Vérification des Headers, du Body et du Type Mime par Postfix.

Postfix peut vérifier les mails entrants très simplement en analysant le header, le body et le type mime des pièces jointes.

Ce type de blocage est très efficace, plus rapide que de laisser faire Amavisd ou SA, mais manque de souplesse.

Il s’avère cependant très efficace pour bloquer des types de fichiers par exemple sans que le mail ne soit envoyé au serveur puis traité (économie de bande passante et de CPU).

Cependant une trop grande quantité de règles et un fort trafic aurait l’effet inverse sur les performances.

Il faut donc utiliser ces règles avec précaution.

On crée les fichiers nécessaires :

On édite le /etc/postfix/main.cf et on ajoute les lignes :

On relance Postfix :

On teste en envoyant un mail classique puis un autre qui contient un des mots ou type bloqués par ces règles.

Le blocage est immédiat et se traduit par un retour d’erreur au moment de l’envoi.

Amavisd et SA

on installe les prérequis d’amavisd :

et les modules Perl :

Pour ceux qui le souhaitent, on peut installer tous les modules perl nécessaires par CPAN ce qui permet d’avoir les versions les plus récentes : Modules Perl Amavisd par CPAN

On installe les dépendances de SA :

Pour ceux qui le souhaitent, on peut installer tous les modules perl nécessaires par CPAN ce qui permet d’avoir les versions les plus récentes : Modules perl pour SA par CPAN

Note : IP ::Country n’existe pas en paquet, il faut l’installer par CPAN

Installation Spamassassin

On installe SA depuis les sources :

On lance toute de suite l’update des règles de SA (obligatoire depuis la version 3.3.0) :

Cela aura pour effet de télécharger les règles à jour. Elles seront installées dans /var/lib/spamassassin/3.004001 (ce qui correspond à la version 3.4.1 de SA)

Installation Amavisd

Télécharger les sources d’amavisd :

Créer le user et le groupe amavis :

Créer les sous répertoires dans le home d’amavis :

On crée 2 lecteur tmpfs pour héberger les répertoires db et tmp d’amavis. Cela accroît notablement les performances de traitement :

Modifier /etc/fstab :

Note : La taille de ces lecteurs tmpfs est à modifier selon la charge du serveur, la configuration et bien sur la quantité de RAM disponible.
Pour simplifier /var/amavis/tmp est dépendant du nombre d’instances d’amavisd et de la taille maximale d’un message. Les paramètres mis ici sont ok pour 5 instances et un message_size_limit de 10 Mo, ce qui est largement suffisant dans la config par défaut d’amavisd (2 instances)

Puis :

on vérifie par un

Copier les exécutables :

Copier les fichiers de conf :

Le fichier de configuration /etc/amavisd.conf fourni ici est modifié pour coller à nos besoins :

Evidemment il faut éditer tout de même ce fichier pour préciser :
son réseau local dans @mynetworks,
son domaine avec $mydomain,
et son hostname avec $myhostname

Il faut ensuite éditer le fichier /etc/amavisd/amavisd.domains pour preciser son domaine.
Les domaines supplémentaires s’ajoutent en respectant le même format, un domaine par ligne.

On désactive temporairement l’antivirus pour tester :

On décommente pour cela les lignes (au début du fichier de conf) :

Démarrer amavisd en console pour voir si il manque des prérequis :

Noter les erreurs éventuelles.
Si amavisd ne démarre pas, arrêter la et résoudre les problèmes.

Si c’est ok, arrêter amavisd par CTRL + C.

On configure Postfix :

On ajoute à la fin du master.cf :

et on modifie toujours dans le master.cf la section sur le port 587 comme ceci :

(on ajoute en fait la ligne sur le content_filter)
Cette dernière modification permettra d’utiliser une configuration distincte dans Amavisd pour les utilisateurs se connectant en SASL de l’extérieur.
En effet ceux ci sont en dehors de notre LAN et ne sont donc pas considérés par Amavisd comme locaux (MYNETS pour amavisd)

En spécifiant un port d’écoute supplémentaire pour Amavisd (10026) on se connecte avec la configuration de la policy_bank ORIGINATING, qui dispose par défaut du tag ORIGINATING comme la policy bank MYNETS, qui permet à Amavisd de savoir que le client est de confiance.

Les utilisateurs identifiés par SASL hors du lan et les utilisateurs du LAN (identifiés SASL ou pas) seront donc considérés de la même facon. (on note que l’on pourra même modifier le comportement d’Amavisd très précisement de cette facon. Voir l’article suivant sur le sujet.

On édite maintenant le main.cf et on ajoute :

Relancer postfix :

Surveiller les logs :

Si tout est ok, lancer à nouveau amavisd debug

et taper en console :

Il doit répondre :

quit pour sortir

Pareil pour tester le retour de Postfix :

telnet 127.0.0.1 10025

Il doit répondre un truc du style :

QUIT pour sortir (en majuscules)

 Si les connections sont ok :

Tester le fonctionnement de base (ce qu’il faut taper est précédé de ---> , le reste c’est le retour du serveur) :

L’aller-retour postfix/amavisd fonctionne bien !

(on peut arrêter le debug d’amavisd par un CTRL + C)

Installation de la base SQL d’amavisd

Amavisd va être couplé à une base sql pour permettre notamment la mise en quarantaine des emails.

On crée la base :

On importe la base sql :

On édite amavisd.conf et on ajoute/modifie les lignes suivantes :

Installation de la base de réputation d’amavisd

Grosse nouveauté depuis la version 2.8.2, la gestion d’une liste de réputation dans une base Redis
Pour l’installer si vous utilisez la version testing faite simplement un

si vous utilisez la version stable il faut le prendre dans les backports :
ajouter cette ligne a votre /etc/apt/sources.list

puis

rien de particulier à paramétrer pour l’usage que l’on va faire, pas de schéma à installer.

Il suffit de parametrer amavisd pour utiliser Redis :
on ajoute cela au amavisd.conf (juste sous les instructions pour le storage sql)

Installation Clamav

Prérequis :

On compile depuis les sources :

On met a jour les fichiers de configuration :

Une tache cron sera utilisée pour planifier la mise à jour de la base antivirale.
On fera cela en fin de tuto.

Créer :

Créer un fichier /etc/init.d/clamd

On fait la mise à jour de la base virale :

On vérifie que les fichiers soient bien présents dans le répertoire :

On lance clamd :

Et on vérifie les logs :

Et on vérifie bien que Clam tourne :

On teste le fonctionnement (le dossier "test" est dans le répertoire clamav-0.98) :

clamav-x.yz etant un des fichiers de test présents dans le répertoire test

Installation des signatures additionnelles pour Clam (détection du spam, phising...)

Il s’agit de fichiers supplémentaires que l’on place dans le dossier /var/lib/clamav

On lance le script :

On vérifie que les fichiers sont bien présents dans le répertoire de Clam :

On doit trouver les fichiers suivants :

Une tache cron sera utilisée pour mettre à jour ces fichiers (on le fera en fin de tuto)

Installation de ClamdMon pour la surveillance du demon clam :

installer le script de surveillance clamdmon :

Une tache cron sera utilisée (on le fera en fin de tuto)

Paramétrage Spamassassin

Les binaires de SA ont été installés à l’étape précédente.
Sa configuration de base se fait dans le fichier /etc/mail/spamassassin/local.cf mais pour la plupart des paramètres, c’est le fichier amavisd.conf qui sera prioritaire.

Lorsqu’on utilise Amavisd pour appeler SA il est inutile de lancer spamd.

On remplace le /etc/mail/spamassassin/local.cf par celui ci :

On édite le fichier pour adapter les parametres internal_networks et trusted_networks.

internal_networks et trusted_networks sont des paramètres très importants pour la pertinence de la détection. Il faut absolument les configurer correctement.

On sécurise :

SA fonctionne sur 2 types de tests :

• Heuristiques (ensemble de règles)
• Bayesiens (apprentissage et statistiques)

Pour le filtre bayesien, depuis la version 3.4 de SA, on utilise une base redis.
Le serveur redis etant deja installé, il n’y a rien a faire, le fichier local.cf est paramétré !

On initialise la base :

su amavis -c 'sa-learn -D --spam gtube.txt'

On doit voir la connexion à Redis dans la sortie.

Mise à jour des Rules et ajout des Rules Sought et Starbridge :

On prépare l’installation des rules Sought et Starbridge :

On met à jour :

Les fichiers seront placés dans /var/lib/spamassassin :

on vérifie que les rules Starbridge soient bien présentent directement dans le sous répertoire updates_starbridge_org.

Attention : ces rules Starbridge comportent des éléments essentiels pour le bon fonctionnement de l’antispam, il faut être sur qu’elles soient présentes dans ce sous répertoire

On vérifie que tout soit OK :

Compilation des Rulesets

La compilation des règles permet d’accélèrer sensiblement le traitement.
Pour cela il faut installer au préalable le paquet re2c :

on lance ensuite la commande

cela prend un certain temps avant de se terminer.
Les règles compilées seront placées dans le répertoire /var/lib/spamassassin/compiled.

Il faut maintenant activer l’usage de ces règles grace au plugin Rule2XSBody :

On édite /etc/mail/spamassassin/v320.pre et on décommente la ligne suivante :

on vérifie que tout soit ok :

Pour une mise à jour des rules et une compilation régulière (1 fois par jour maximum) on créera une tache cron spécifique en fin de tuto.

Le script mettra à jour les différentes rules et en cas de modification, lancera une compilation de ces dernieres puis relancera amavisd.
Cette tache est gourmande en ressource, il faut la planifier impérativement en dehors des heures de service.

• SA est prêt et fonctionnel !!

On démarre en debug-sa :

on doit trouver dans la liste ceci :

Bayes n’est pas encore disponible car il n’a pas analysé assez de mails pour fonctionner. Ceci est normal.

On envoie un mail et on doit voir dans le debug le bon fonctionnement.

On arrête amavisd par un CTRL + C.

Explication sur le fonctionnement global de SA

SA distingue Spammy et Spams. Un spammy est un mail qui est probablement un spam. Un message marqué comme Spam est en revanche probablement un véritable spam.
_C’est le score attribué qui décide de ce statut.

Par défaut, Amavisd mets les spams en quarantaine, c’est à dire qu’au dessus du score de 10, il envoie les mails dans un espace de stockage en base. Il ne sont donc pas livrés dans la boite du destinataire.

Au dessus de 4.3 et jusqu’à 10, les mails sont considérés comme spammy et sont tout de même livrés dans la boite de destinataire, mais avec le sujet modifié et des entêtes spécifiques.

Au dessous de 4.3, le mail est clean.

Pour faire la distinction entre mail clean et spammy, on traitera le mail plus loin par Sieve.

Lancement d’amavisd

On crée un fichier /etc/init.d/amavis :

on lance amavisd :

On regarde les logs.

On envoie un mail et on regarde l’entête de celui ci.
on doit voir les X-Spam- headers.

On rappelle que Dovecot LDA est parametré pour déposer le courier détecté comme spam dans le dossier spam de chaque utilisateur.
Il crée également les dossiers spéciaux.

le Dossier Spam recevra tous les Spammy.
Les 2 dossiers SpamToLearn et SpamFalse pourront etre utilisés pour transmettre des mails à apprendre au systeme.

L’apprentissage des bases Bayes de SA se fait automatiquement lors de la réception mais peut aussi etre fait manuellement en alimentant les dossiers spéciaux.

On crée deux boite spéciale dédiées à la gestion du spam :
spamtrap@starbridge.org
hamtrap@starbridge.org

Ces deux serviront à l’admin pour trier les mails classés par les users dans leurs dossiers spamfalse et spamtolearn

• Il faut d’abord créer un script qui scanne les 2 dossiers d’apprentissage SpamToLearn et SpamFalse des boîtes des utilisateurs (Dossiers crées automatiquement par Dovecot LDA à la première livraison) puis envoie leur contenu vers les deux boites hamtrap et spamtrap.

On crée deux boites et deux répertoires spéciaux de transit + deux répertoires de stockage :

les deux répertoires de backup permettent de disposer d’un corpus de spam/ham pour l’apprentissage en cas de migration ou de remise à zero de la base bayes.

on crée un ficher /etc/caremail/cron/sa-trap-sdbox

On modifie à l’intérieur de ce fichier les 2 boites de destination pour ajuster à son installation.

Il suffira d’indiquer aux utilisateurs de déplacer les emails non détectés comme Spam dans le dossier SpamToLearn et de copier les email légitimes détectés à tort comme Spam dans le Dossier SpamFalse.
Le script déplacera lors de son exécution tous ces emails dans les boites spamtrap et hamtrap

Une tache sera ajoutée en fin de tuto pour lancer automatiquement ce script.

Attention : TOUS les mails déposés dans les dossiers SpamTolearn et SpamFalse sont déplacés c’est à dire qu’ils seront EFFACES de ces dossiers.

L’admin pourra alors consulter ces emails, et une fois validés, il lancera un script manuellement qui fera l’apprentissage soit comme spam soit comme ham (non spam).

on crée le script d’apprentissage pour l’admin /etc/caremail/sa-dspam-learn-sdbox :

Activation de Clam dans Amavisd

Le fichier amavisd.conf fourni dans ce tuto est modifié pour ne prendre en charge que l’antivirus Clamav.

Pour info voici les paramètres modifiés (à la fin du fichier) :

Pour activer Clam on commente au début du fichier :

On relance amavisd :

L’antivirus est chargé.

On crée grace à postfixadmin l’alias email : virusalert@starbridge.org vers admin@starbridge.org.

On teste le fonctionnement :

On doit voir dans les logs :

On peut aussi tester l’envoi d’un mail infecté dans une archive (pour tester le travail de décompression) en récupérant des fichiers de test sur eicar.com et en les envoyant par email.

Dspam

Beaucoup considère Dspam comme une alternative plus performante de SA.

Je trouve qu’ils sont plutôt complémentaires.

Amavisd permet de gérer les 2 en parallèle.

Créer la base sql :

On importe la base sql :

On modifie le fichier de conf dspam.conf original (toto étant votre password d’acces a la base sql dspam que vous venez de paramétrer) :

On installe un init.d pour le nouveau demon :

On active le démarrage automatique :
insserv -v /etc/init.d/dspam

Modifier les droits sur les exécutables (même user qu’amavisd) et le dspam.conf

Sécuriser le répertoire de dspam dans le home d’amavisd :

on edite le /etc/amavisd.conf et on ajoute le bloc suivant juste avant la ligne "$sa_tag_level_deflt"

On passe les paramètres par défaut de dspam (ils vont s’insérer en base) :

On crée le user virtuel avec le meme uid qu’amavisd (ici c’est 1002) :

on active le user :

On lance le démon dspam

On verifie qu’il tourne

relancer amavisd :

On vérifie les logs. On doit voir :

On envoie un email :

On vérifie les logs, les headers des email pour les tags X-DSPAM et le remplissage de la base de données.

Principe de fontionnement :

Dans cette configuration, Dspam marque simplement les mails (il ajoute un tag dans le header).
Avant la version 2.6.3 d’amavisd, le score etait transmis à SA.
Désormais, le score est ajouté APRES Spamassassin, par amavisd.

Les scores par défaut sont inscrits en dur dans le binaire d’amavisd : 3.8 pour un spam, 0.1 pour un ham.

Actuellement l’autolearn n’est pas pris en charge dans cette implémentation.
Il faudra donc alimenter manuellement la base de dspam depuis un corpus.

On crée les taches de maintenance de dspam :

On crée un fichier /etc/caremail/dspam-purge-4.1.sql

une tache cron lancera ce script automatiquement (en fin de tuto)

Filtrage par extensions et type mime dans amavisd

On peut également renforcer le blocage des fichiers par extension et type mime dans amavisd, indépendamment de l’antivirus.

Ce blocage est très efficace et peut être complémentaire du premier blocage par Postfix sur ces fichiers (headers, body, type mime), car il utilise cette fois les capacités de décodage et de décompression d’Amavisd.

Par exemple, on pourra facilement bloquer un fichier exe à l’intérieur d’un fichier zip.

Voir mon fichier amavisd.conf pour des exemples de type mime et d’extensions de fichiers.

Voila le serveur de mail et le filtrage sont configurés !

Fonctions Avancées d’amavisd : Penpals et gestion des users

Maintenant que l’on a un système fonctionnel articulé autour d’Amavis, on peut ajouter 2 fonctions intéressantes :

 Penpals : qui permet de maintenir une liste des messages auquels un user a déjà répondu et ainsi moduler les scores en fonction
 Gestions des users dans Amavisd par Mysql : cela permet de gérer par utilisateur les grandes fonctions d’Amavisd (désactivation de l’antivirus, de l’antispam, maintien de whitelist et de blacklist personnelles...)

La base mysql est déja créée et fonctionnelle.

Pour l’instant seul penpals fonctionne automatiquement.

En revanche la fonction users demande d’être paramétrée :

Pour cela, on pourra utiliser le module SAM de horde (voir le tuto horde pour cela) soit alimenter manuellement la base SQL.

Un exemple pour un paramétrage pour un utilisateur :

Ici on a crée un parametre pour un user de notre domaine test@starbridge.org.
On voit dans la table users qu’on lui donne l’id 1 et on lui associe la policy 1.
Une policy reprend tous les paramètres présents dans amavisd.conf.
On les retrouve dans la table policy. Si la valeur est NULL alors c’est celle du fichier amavisd.conf qui sera utilisée. Sinon c’est celle de la table.
Ici on a modifié le score de détection spam (5 au lieu de 4.3)

Ensuite on a ajouté une entrée a la table mailaddr où l’on spécifie des expéditeurs, par exemple toto@toto.com avec l’id 1.
Grâce à la table wblist on pourra maintenir une liste de score à attribuer en fonction de ces adresses d’expéditeurs ET de users (le destinataire dans notre réseau), ce qui rend ces listes entièrement personnelles.

Ainsi dans notre exemple, wblist pour rid 1 (recipient id 1 = test@starbridge.org) et le sid 1 (sender id 1 =toto@toto.com) on attribue un score positif de 15.

C’est l’équivalent dans le fichier amavisd.conf du soft whitelisting/blacklisting mais cette fois uniquement pour un utilisateur et non tous les autres.
On peut aussi faire du hard whitelisting/blacklisting en specifiant W ou B au lieu du score.

On verra le module horde SAM pour laisser gérer facilement ces options par l’utilisateur lui même (SAM ne gère que le hard whitelisting/blacklisting).

On peut également utiliser cette table sql pour paramétrer finement non pas par users mais par domaine.
Pour cela il faudra juste utiliser le @starbridge.org pour prendre en compte tous les users de celui ci.

par exemple :

En résumé, on crée un user général qui englobe tous les comptes dans
starbridge.org.
On lui attribue la policy 4 qui correspond à toutes les options par
défaut, sauf les 2 options de vérification des fichiers bannis, qui sont sur bypass.
Ainsi tous les users du domaine starbridge.org pourront recevoir les fichiers bannis.

Les users qui le désirent pourront toujours personnaliser ces options dans Horde au travers du module SAM car la priorité du user général est de 6 alors que celle des users crées par le module SAM est de 7.
 Leur paramétrage personnel sera donc prioritaire à celui du user général.

On peut également mixer avec la table wblist et mailaddr pour créer des whitelist/blacklist par domaines.

Maintenance des bases SQL d’amavisd

Les tables vont grossir au fur et à mesure des réceptions, il faut donc regulièrement les purger.

On utilise le champ partition_tag comme élément de sélection, cela permet de limiter le temps des requêtes de purge.
Ce champ contient le numéro de la semaine de l’enregistrement sql. Il est inséré par amavisd pour chaque INSERT dans la base.

On crée un fichier amavis-purgesql :

Une tache cron assurera l’activation réguliere de la purge (en fin de tuto)

Mailzu

Installation du gestionnaire de quarantaine : Mailzu

Pour gérer la quarantaine et pour permettre aux utilisateurs de la consulter, on installe Mailzu.
_Il s’agit ici d’une version modifiée intégrant des patches de la communauté (gestion des admins par exemple) mais aussi des modification persos sur les requêtes SQL pour prendre en compte le partition_tag d’amavisd.

On installe les prérequis :

on installe les modules pear :

on télécharge depuis SVN :

NOTE : Cette version de mailzu est compatible avec php 5.4
pour l’utiliser avec php 5.3, il suffit de revenir sur la modification de deux lignes dans le fichier suivant :
https://smtp04.spamguard.fr/websvn/diff. ... hp&rev=237

On sécurise :

On modifie les paramètres (attention il y a 2 passwords à modifier, un pour Postfix : toto et un pour Amavisd : titi)

le parametre $conf[’auth’][’s_admins’] permet de lister les admins de site, c’est a dire ceux qui auront acces a toutes les quarantaines de tous les utilisateurs.
Modifier l’entrée admin@starbridge.org pour utiliser votre admin global et laisser l’entrée @. qui est l’admin global par défaut.

Les admins de domaine sont ceux qui ont accès à un seul domaine.
Cette version de Mailzu récupere la liste des admins depuis celle de postfixadmin.

on crée le fichier de log :

On se connecte sur l’interface :
https://www.starbridge.org/quarantine

L’utilisateur est admin@starbridge.org (c’est votre email d’administrateur admin@votredomaine.com) et le password ’secret’.

On teste la quarantaine pour voir si tout fonctionne.

DKIM

Vérification et signatures des messages par DKIM

Cette technique est désormais quasi indispensable pour assurer une meilleure délivrabilité des emails, et depuis la version 2.6, amavisd propose désormais d’exécuter l’intégralité des tâches DKIM : Vérification des messages reçus et signatures des messages sortants.

La vérification DKIM des mails recus et faites par defaut dans amavisd.

Pour la génération des signatures, il faut configurer amavisd :

On génére la clé :

les droits du fichier sont mis correctement par amavisd.

Si l’on a plusieurs domaines on répète la procédure pour chaque.

On ajoute ceci au /etc/amavisd.conf :

A partir d’ici Amavisd est capable de signer les messages sortants.
Mais le serveur destinataire ne sera pas capable de les vérifier, car il faut publier la clé publique dans les DNS :

Pour cela, on lance la commande suivante pour afficher la clé publique du ou des domaines que l’on a parametré plus haut.

amavisd showkeys

on fait un copier/coller du résultat pour le domaine et on le colle tel quel dans la zone DNS.

Le serveur DNS Unbound gère bien sûr cet enregistrement (TXT) et il suffira de l’enregistrer dans le fichier de zone et de la recharger.

Si les DNS sont gérés par l’hébergeur, la plupart d’entre eux propose de modifier les champs TXT, mais ce n’est pas le cas de tous.
Il faudra donc vérifier ce point.

On teste l’enregistrement avec une commande d’amavisd :

Depuis la version 2.7, Amavisd propose un programme externe de signature.
Pour le moment la configuration se fait directement dans le binaire amavisd-signer :

On édite les lignes suivantes :

et on ajoute juste sous les exemple de dkim_key, la même entrée que dans amavisd.conf :

On crée un init.d pour cet exécutable :

On lance le signer :

On relance amavisd.

Pour pouvoir signer les messages il faut que ceux ci proviennent pour amavisd d’une source de confiance, c’est à dire en provenance du réseau spécifié dans amavisd comme étant local (policy bank MYNETS), ou bien depuis le port 587 dans postfix en TLS + SASL (policy bank ORIGINATING).

On teste en envoyant un mail et on vérifie dans les logs que la signature s’applique bien.

On retrouvera cette signature dans les headers du message envoyé.

Notes :

 On peut aller plus loin dans la configuration d’Amavisd mais pour ne pas surcharger le tuto nous n’aborderons pas ces points ici.

 La configuration d’amavisd doit également être modifiée en fonction de la charge du serveur. Par défaut 2 instances sont actives ($max_servers = 2 ;). Le calcul du nombre d’instances nécessaires demande certains ajustements à l’usage et doit être considéré comme un prérequis sur la mise en production d’un serveur susceptible de traiter des volumes conséquents.
On peut consulter la doc d’amavisd sur ce point.

 Dans notre configuration on filtre (antispam, antivirus) sur les mails entrants ET sortants. On peut économiser des ressources systèmes en désactivant l’antispam sur les mails sortants en provenance d’utilisateurs authentifiés. Voir la configuration dans cet article

Pour info, les mails soumis localement (pickup) bypassent tous les tests : spams, AV, header/body. C’est le cas pour les mails système comme ceux de cron, logwatch ou autres. Cette configuration a été faite dans la partie pickup en début de tuto.

Policyd V2

Policyd V2 est un policy service de Postfix qui permet entre autres de contrôler les clients qui se connectent sur le serveur de mail (nombre d’email/heures....), en contrôlant le volume des email envoyés.

Policyd V2 est surtout très utile pour lutter contre les mail bombing, les ddos, les spywares et les abus en tout genre (limitation entrées/sorties)

on installe les prérequis perl :

On crée un user policyd :

On installe les fichiers :

Créer la base sql :

On importe la base sql :

On installe le /etc/cluebringer.conf et on modifie le password (ici votre password serait toto) :

On sécurise le fichier :

chmod 640 /etc/cluebringer.conf

On crée un fichier /etc/init.d/policyd2 :

On lance le daemon :

On vérifie qu’il tourne bien et avec le bon user :

et on vérifie les logs :

On ajoute plusieurs entrees policy service au /etc/postfix/main.cf :

en dessous du bloc has_our_domain_as_sender :

avant le bloc smtpd_recipient_restrictions :

on modifie l’entree du smtpd_restriction_classes :

apres le bloc smtpd_data_restrictions :

puis dans le master.cf on modifie l’entree du port 587 :

On relance postfix :

on copie l’ihm de management :

on modifie les credentials de la base dans /var/www/webui/includes/config.php
puis on sécurise le fichier :

[rouge]Attention : par défaut il n’y a pas d’authentification sur cette interface, on a donc mis un .htaccess avec un deny from all pour sécuriser l’installation, mais pour utiliser l’interface il faudra que vous modifiez ce htaccess pour accepter soit par votre ip, soit par un login/password
Dans tous les cas, bien s’assurer que l’acces ne soit pas possible directement par un navigateur !
ATTENTION : si l’on n’a pas configuré le AllowOverride All dans le virtualhost d’apache comme indiqué au début du tuto, le .htaccess ne sera pas pris en compte et l’IHM sera librement accessible !![/rouge]

on se connecte sur l’interface et on modifie les parametres comme on le souhaite (l’aide en ligne est disponible)
Un premier paramétrage est livré par défaut.

On teste en envoyant un email.
On doit voir des logs policyd et le mail doit être correctement livré.

on met en place la purge quotidienne :
On crée un fichier policydv2-purge.sql :

Une tache cron assurera le lancement. (en fin de tuto)

Maintenance et automatismes : Tâches Cron

Toutes les taches cron du tuto sont réunies pour faciliter la gestion :

il faut changer les passwords des fichiers dspam-purgesql.sh, amavis-purgesql.sh et policydv2-purgesql.sh par ceux que vous avez parametré plus tot.

puis on sécurise

Enfin on fait un lien dans /etc/cron.d :

Vacation AutoReply

On peut éventuellement activer un système de réponse automatique en cas absence.

Note : Il est fortement déconseillé d’utiliser ce genre d’autoréponse car il peut générer un trafic illégitime. (Backscatter Mails).

Voir ces liens pour plus d’informations :
http://www.spamcop.net/fom-serve/cache/329.html
http://www.rfc-editor.org/rfc/rfc3834.txt

Pour limiter ce risque il est nécessaire d’installer le mécanisme d’autoreply au plus proche de la boite email, au moment de la livraison, une fois que tous les tests antispams ont été effectués.

On utilisera donc Sieve pour cela.
Un autoreply n’ayant réellement de sens que s’il peut etre géré directement par l’utilisateurs, il faut utiliser une interface graphique pour générer le code du filtre Sieve.
Le webmail Horde propose un excellent module pour cela (ingo).
Ce point est traité dans le tuto sur horde.

Reporting et analyses des logs

Pour suivre les logs que génèrent le serveur de mail, il est conseillé d’utiliser des outils particuliers.

on installe :
aptitude install logcheck logwatch

- Logcheck :
Son utilisation est automatique après l’installation sous debian.

Toutes les heures il envoie un rapport des logs du serveurs ne contenant que les points qui doivent attirer l’attention.

- Logwatch :
son installation est également automatisé par la debian.
Il envoie un rapport journalier sur les logs.

Pour des résultats pertinent avec postfix/amavis, il faut ajouter les modifications suivantes :

-Mailgraph :
Mailgraph génére des graphiques sur l’utilisation de la messagerie

note : le dernier sed est pour la version stable du paquet mailgraph. Si on a la version testing ce n’est pas necessaire.

On se connecte pour les graphiques avec l’url :

https://www.starbridge.org/cgi-bin/mailgraph.cgi

- Volume des mails d’alertes

Au début du tuto, on a parametré Postfix pour alerter le postmaster par mail pour la plupart des évènements, en particulier les bounces.

Une fois la période de tests terminés, il est conseillé de désactiver ces options car l’on risque d’être rapidement submergé par les mails à destination du Postmaster.

Pour cela il faut éditer le main.cf et commenter la ligne suivante :

puis

postfix reload

Firewall

Il est capital de protéger le serveur par un firewall.

On utilisera iptables..
Ci dessous un exemple pour un serveur standalone.

Il faudra bien sur l’adapter à la topologie du réseau.

exemple firewall

ne pas oublier d’activer ce script au démarrage !

Versions du Document (ChangeLog)

• 8.0 14/11/2016
   General : modification du wget par svn export pour contourner la protection ddos de cloudflare

• 8.0 08/11/2015
   Dovecot mise à jour 2.2.19

• 7.9 05/5/2015
   Dovecot : modification du script sa-trap-sdbox pour s’exécuter en vmail au lieu de root
   Spamassassin : mise à jour 3.4.1

• 7.8 27/3/2015
   Dovecot mise a jour 2.2.16
   Clamav : mise à jour 0.98.6

• 7.7 2/2/2015
   Policyd : desactivation IPv6. (merci à Yvon)

• 7.6 26/11/2014
   Clamav : mise à jour 0.98.5

• 7.5 15/11/2014
   Dovecot : mise à jour 2.2.15
   Amavisd : mise à jour 2.10.1
   ajout de paramétres pour les failles SSL dans les configurations

• 7.4 28/09/2014
   Clamav : mise à jour 0.98.4
   Dovecot : mise à jour 2.2.13
   Amavisd : mise à jour 2.9.1

• 7.3 30/05/2014
   Cron:retrait du script SAawl, obsolete depuis le passage à redis pour la base bayes
   Clamav : mise à jour 0.98.3
   Dovecot : mise à jour 2.2.12
   Amavisd : mise à jour 2.9.0

• 7.2 2/05/2014
   Dovecot : modification url pigeonhole

• 7.1 4/04/2014
   Dovecot : mise à jour 2.2.12
   Amavisd : mise à jour 2.8.2-rc1
   Spamassassin : mise à jour 3.4.0
   clamav : mise à jour 0.98.1
   Amavisd et SA : utilisation de Redis

• 7.0 16/11/2013
   General : Typo
   Dovecot : Mise a jour 2.2.7
   Clamav : mise à jour 0.98

• 6.13 22/06/2013
   General : remplacement du serveur svn pour les sources du tuto

• 6.12 20/05/2013
   Dovecot : correction du dovecot.conf : ajout plugin notify
   Postfix : correction erreur dans le texte pour smtpd_recipient_restrictions

• 6.11 19/05/2013
   Mise à jour debian (prise en compte du passage en Wheezy Stable)
   Mise à jour postfix (2.10 ou 2.9.6 en fonction de la distribution + ajout du parametre smtpd_relay_restrictions pour retro compatibilité de la 2.10)
   Mise à jour dovecot 2.2.1 et Sieve Pigeonhole 0.4.0

• 6.10.0 24/04/2013
   Clamd : 0.97.8

• 6.9.0 20/04/2013
   Clamd : 0.97.7

• 6.8.9 10/02/2013
   Dovecot : mise à jour 2.1.15
   Clamav : mise à jour du script de telechargement des signatures

• 6.8.8 12/01/2013
   Dovecot : mise à jour 2.1.13

• 6.8.7 12/01/2013
   General : pb de compatibilité mysql et certains fichier de creation de table : le TYPE a disparu en 5.5, il faut utiiser ENGINE a la place : les fichiers concernés sont postfix.sql, bayes_awl.sql, policyd.mysql

• 6.8.6 28/10/2012
   General : typo et erreur de lien
   Sieve : modification du comportement du sieve global (after au lieu de before)

• 6.8.5 29/09/2012
   Dovecot : mise à jour 2.1.10, pigeonhole 0.3.3
   Clamd : 0.97.6

• 6.8.4 8/09/2012
   Spamassassin : patch pour corriger le bug mysql

• 6.8.3 26/08/2012
   Dovecot : modification de l’exemple d’arboresnce d’un maildir. Modification du global.sieve pour tenir compte du retrait du prefix INBOX.

• 6.8.2 19/08/2012
   Amavisd : modification binaire amavisd : retour au score standard pour dspam : 10 et -1. On utilise le score factor dans le fichier de conf pour moduler le score : modification du amavisd.conf score_factor pour dspam passe de 1 à 0.39

• 6.8.1 19/08/2012
   Dspam : mise à jour 3.10.2
   Dovecot : mise à jour 2.1.9, ajout plugin zlib manquant pour pop3
   Clamav : Mise a jour 0.98

• 6.8.0 16/08/2012
   Amavisd : mise à jour 2.8.0

• 6.7.9 11/08/2012
   Dovecot : ajout d’un chmod manquant
   General : ajout fichier manquant pour purge amavis

• 6.7.8 02/08/2012
   Général : remplacement des crontab par un fichier cron général et des fichiers par service dans un dossier spécifique.
   SA/DSPAM : refonte du sa-learn pour prendre en compte dspam et le format sdbox

• 6.7.7 01/08/2012
   Dovecot : migration dovecot maildir vers sdbox, activation compression, préparation à l’arrivée de solr
   General : typo, ajout lien vers optimisation Mysql
   Mailzu : mise à jour pour php 5.4

• 6.7.6 11/07/2012
   ajout paquets pour la compilation
   ajout de la compression dans la compilation dovecot
   ajout de solr dans la compilation dovecot
   passage dovecot 2.1.8
   Mise à jour policyd2

• 6.7.5 18/06/2012
   Clamav : mise a jour 0.97.5
   Mysql : indication du passage en 5.5 pour la version debian testing
   Amavisd : mise à jour 2.7.1
   Amavisd : retrait de la quarantaine /var/virusmail, plus utilisée

• 6.7.4 09/04/2012
   Postfix : fix pour les warnings sur fallback_relay dans le master.cf. Finalement il y avait bien un leger changement de conf a faire !

• 6.7.3 09/04/2012
   Clamav : mise a jour 0.97.4
   Postfix : ajustements du texte pour la version 2.9.1 : version par defaut de la debian testing et des backports stable. Pas de modification de configuration.

• 6.7.2 22/02/2012
   Dovecot : Mise a jour dovecot 2.1.1

• 6.7.1 17/02/2012
   Dovecot : Mise a jour dovecot 2.1.0, pigeonhole 0.3.0

• 6.7.0 22/01/2012
   Postfix : Mise a jour postfixadmin en version 2.4 et modification du lookup transport

• 6.6.6 18/11/2011
   Mise a jour dovecot 2.0.16, pigeonhole 0.25

• 6.6.4 27/10/2011
   Logwatch : mise à jour postfix-logwatch-1.39.07

• 6.6.3 19/10/2011
   Clamav : mise a jour 0.97.3

• 6.6.2 13/10/2011
   Général : mise en forme et typos
   SA : retrait de AWL

• 6.6.1 24/09/2011
   Logwach : mise à jour

• 6.6.0 16/09/2011
   Postfix : retour à l’installation par paquet avec les backports squeeze

• 6.5.9 16/09/2011
   Dovecot : Mise a jour dovecot et pigeonhole

• 6.5.8 16/09/2011
   Clamav : mise a jour 0.97.2
   Dspam : mise a jour 3.10.0

• 6.5.7 4/07/2011
   Amavisd 2.7.0 version finale

• 6.5.6 26/06/2011
   Spamassassin : upgrade en 3.3.2
   Typos (merci à Bouks !)

• 6.5.5 14/06/2011
   Amavisd : modification du amavisd-signer pour passer en demon

• 6.5.4 14/06/2011
   Clamav : maj en 0.97.1

• 6.5.3 14/06/2011
   postfix : mise à jour master.cf pour retrait du chroot sur tous les processes (conforme au master.cf des sources postfix)
   Mise à jour du script sql amavis (verifier les diffs)

• 6.5.2 03/06/2011
   Spamassassin : upgrade en 3.3.2 rc2

• 6.5.1 02/06/2011
   Policyd : migration en V2

• 6.5.0 31/05/2011
   Général : mise à jour pour Squeeze, retrait paquets inutiles
   Amavisd 2.7.0-rc1
   passage de bind a unbound pour les dns
   postfix 2.8.3 depuis les sources et utilisation de postscreen
   ajout pyzor et razor pour SA
   ajout dkim amavisd-signer
   maj script sql dspam

• 6.4.2 29/05/2011
   Dovecot : mise a jour 2.0.13 et sieve 0.2.3

• 6.4.1 28/05/2011
   Amavisd : modification du script sql pour utiliser le partitionning sur la table quarantine. La version 5.1 de mysql doit etre utilisée.

• 6.4.0 18/05/2011
   retrait des rules SARE desormais obsoletes et ajout des rules SOUGHT

• 6.3.0 08/03/2011
   global : mise a jour pour les changements de versions debian
   dovecot : mise a jour en version 2.0.11

• 6.2.7 05/03/2011
   Logwatch : mise a jour scripts

• 6.2.6 28/02/2011
   Clamav : mise a jour en version 0.97

• 6.2.5 09/12/2010
   Dovecot : mise à jour dovecot-2.0-pigeonhole-0.2.2

• 6.2.4 04/12/2010
   Dovecot : mise à jour en version 2.0.8

• 6.2.3 30/11/2010
   Clamav : mise a jour en version 0.96.5

• 6.2.2 25/09/2010
   Clamav : mise a jour en version 0.96.3

• 6.2.1 18/09/2010
   Dovecot : mise à jour en version 2.0.3

• 6.2.0 11/09/2010
   Global : passage de maildrop a dovecot pour la livraison des mails.
   Dovecot : passage en version 2.0.2

• 6.1.9 17/08/2010
   Clamav : mise a jour en version 0.96.2

• 6.1.8 07/06/2010
   Mise à jour script sanesecurity : v3.7.1

• 6.1.7 19/05/2010
   Clamav : mise a jour en version 0.96.1

• 6.1.6 27/04/2010 (merci à Alex)
   SA : mauvais chemin pour une commande de test
   Amavisd : ajout du parametre mydomain dans les explications des modifications du amavisd.conf

• 6.1.5 16/04/2010
   Logwatch : Mise à jour des 2 modules.

• 6.1.4 02/04/2010
   Clamav : mise a jour en version 0.96

• 6.1.3 20/03/2010
   SA : mise a jour en version 3.3.1

• 6.1.2 13/03/2010
   Postfixadmin : ajout du transport dovecot. Correction d’un bug lors de la creation d’un domaine en relay

• 6.1.1 20/02/2010
   Postfixadmin : adaptation du postfix.sql et du tuto pour créer l’utilisateur d’administratin en @starbridge.org et non plus admin@starbridge.org. Insertion dans la table postfix_helo du domaine. (Merci à Barronmonster pour la contribution !)

• 6.1.0 28/01/2010
   DSPAM : refonte du mode d’appel de DSPAM. Utilisation du demon dspam.

• 6.0.4 28/01/2010
   FIX : amavisd : passage du champ policy_name de la table amavis.policy de varchar(32) à varchar(255) pour eviter un bug avec le module sam dans le cas d’un email dépassant les 32 caracteres. (l’email etant utilisé par sam comme policy_name

• 6.0.3 26/01/2010
   SA : mise a jour en version 3.3.0

• 6.0.2 24/01/2010
   Mise à jour script sanesecurity : v3.7

• 6.0.1 16/01/2010
   Mailzu : installation initiale du gestionnaire de quarantaine

• 6.0.0 16/01/2010
   systeme : précision sur l’installation de mysql pour lenny ou squeeze (5.0 ou 5.1)
   général : retrait complet de l’installation de courier-imap pour dovecot et réorganisation des chapitres
   postfix : ajout du fichier mysql_relay_recipients_maps.cf manquants
   postfix : ajout des fichiers mysql_transport.cf et mysql_transport2.cf nécessaire pour la version de postfixadmin modifiée.
   postfix : ajout du parametre transport_maps par défaut
   Postfixadmin : mise en place de la version modifiée sous SVN, remplacement des pass par défaut en md5 hex

• 5.0.5 11/01/2010
   DSPAM : mise à jour en version finale 3.9.0

• 5.0.4 08/01/2010
   SA : activation du plugin AWL dans la conf car il est par défaut désactivé

• 5.0.3 07/01/2010
   SA : lancement de sa-update juste apres l’installation pour telecharger les rules : Celles ci ne sont plus livrées par défaut dans le package, il faut les télécharger.

• 5.0.2 06/01/2010
   FIX : amavis : correction du script de purge pour eviter l’effacement de la semaine en cours

• 5.0.1 04/01/2010
   Postfix : ajout de la gestion des aliases domains (non activés par défaut)

• 5.0.0 03/01/2010
   SA : Mise à jour en version 3.3.0 rc1
   Postfix : passage de [not_]our_domain_has_sender en requete mysql

• 4.9.8 21/12/2009
   Dspam : mise à jour en 3.9.0-RC2

• 4.9.7 15/11/2009
   Vacation autoreply : retrait du module vacation.pl, car le risque de générer du backscatter est trop important. Rajout d’une information sur le sujet et orientation à prendre.

• 4.9.6 02/11/2009
   Dspam : mise à jour en 3.9.0-BETA4

• 4.9.5 01/11/2009
   Amavisd : modification de la base SQL. Drop des contraintes et ajout d’un champ dans une clé primaire. Modification du script de purge pour utiliser le partition_tag. Modification du amavisd.conf pour insérer le partition_tag dans la base.

• 4.9.4 28/10/2009
   Clamd : Mise à jour en version 0.95.3

• 4.9.3 2/10/2009
   Général : Mise à jour des scripts init.d (clamd/amavis/policyd) pour intégrer les headers LSB. Ajout des commandes insserv dans le cas de la version testing.

• 4.9.2 12/09/2009
   Mise à jour script sanesecurity : v3.6

• 4.9.1 26/08/2009
   DSPAM : mise à jour en dspam-3.9.0-BETA1

• 4.9.0 26/08/2009
   SA : passage des regles amavis-sanesecurity sur les rules starbridge pour une mise à jour automatique avec sa-update
   Général : création d’un répertoire commun pour les scripts de maintenance. Modification des chemins.
   SA : modification du sa-update et passage de la compilation des rulesets en quotidien dans le script directement.

• 4.8.9 25/08/2009
   Logwatch : Mise à jour

• 4.8.8 05/07/2009
   SA : ajoutd’un channel starbridge pour les mises a jours des regles SA

• 4.8.7 30/06/2009
   Dspam : mise à jour paramétrage dans amavisd.conf et dans dspam.conf

• 4.8.6 27/06/2009
   Clamd : Mise à jour en version 0.95.2

• 4.8.5 26/06/2009
   Amavisd : Mise à jour du binaire et du fichier de conf en 2.6.4.
   Dspam : Mise à jour en 3.9.0 ALPHA2

• 4.8.4 11/06/2009
   Amavisd : modification du master.cf et du amavisd.conf pour ajouter le port 10029 spécifique aux notifications d’amavisd
   Dspam : mise à jour du script de création des tables MySQL.

• 4.8.3 17/05/2009
   amavisd : mise à jour prérequis libdb4.4-dev par libdb4.6-dev. Le paquet n’existe plus dans Lenny
   paragraphe antispam : modification de l’ordre d’exécution du tutorial pour eviter le message suivant au démarrage d’amavisd durant les tests" Can’t locate object method "new" via package "Amavis ::SpamControl" at /usr/sbin/amavisd line 13878."

• 4.8.2 10/05/2009
   Dspam : Mise à jour version 3.9.0
   Mise à jour script sanesecurity : v3.0

• 4.8.1 24/04/2009
   Clamav : Mise à jour script signature en 2.7.2. Changement d nom du script en :clamav-unofficial-sigs

• 4.8.0 23/04/2009
   Amavisd : mise à jour en 2.6.3. Modification du fichier de configuration pour prendre en compte le changement de gestion de Dspam par amavisd.

• 4.7.7 20/04/2009
   Dspam : ajout des outils de compilation nécessaires (automake, autoconf).

• 4.7.6 16/04/2009
   Dspam : mise à jour des liens de téléchargement vers la version de la communauté.

• 4.7.5 08/04/2009
   Clamd : Mise à jour en version 0.95.1

• 4.7.4 05/04/2009
   Mise à jour script sanesecurity : v2.7
   Amavisd : mise à jour du binaire avec 2 patches correctifs

• 4.7.3 23/03/2009
   Clamd : Mise à jour en version 0.95

• 4.7.2 15/03/2009
   courier-authdaemon : modification du /etc/init.d/courier-authdaemon pour la version testing Squeeze de debian. Le script crée désormais le répertoire run, il faut donc lui spécifier les bonnes permissions.

• 4.7.1 07/03/2009
   changement du lien de téléchargement du binaire d’amavisd pour integrer les differents patches correctifs de la version 2.6.2

• 4.7.0 21/02/2009
   Mise à jour script sanesecurity : update script + ajout du fichier de conf

• 4.6.9 24/01/2009
   Mise à jour script sanesecurity : unification des 2 fichiers

• 4.6.8 21/01/2009
   Mise à jour du script sanesecurity suite au changement de mode de telechargement

• 4.6.7 21/01/2009
   Postfixadmin : Mise a jour en 537
   Vacation.pl mise a jour

• 4.6.6 20/01/2009
   Postfixadmin : Mise a jour en 529
   Mise a jour postfix.sql : ajout champ local_part

• 4.6.5 04/01/2009
   Amavisd : Mise à jour en 2.6.2
   correction de mise en forme du tuto suite a une update SPIP

• 4.6.4 06/12/2008
   Amavisd : Mise à jour en 2.6.2-rc2

• 4.6.3 26/11/2008
   Clamd : Mise à jour en version 0.94.2
   Amavisd : Mise à jour en 2.6.2-rc1

• 4.6.2 17/11/2008
   Amavisd : Mise à jour en 2.6.2-pre1. Les nouvelles signatures Sanesecurity ont été ajouté au code, donc on les enleve du amavisd.conf.

• 4.6.1 12/11/2008
   Amavisd : modification du amavisd.conf pour utiliser des fichiers externes pour les domaines et les whitelist/blacklist. Ajout des nouvelles signatures SaneSecurity
   SA : Ajout des nouvelles signatures SaneSecurity
   SaneSecurity : Mise a jour du script
   Clamd : Mise à jour en version 0.94.1
   Postfixadmin : Mise a jour en 478

• 4.6.0 26/09/2008
   Postfix : retrait de la rbl list.dsbl.org. Celle ci est arretée définitivement.

• 4.5.9 04/09/2008
   Clamd : Mise à jour en version 0.94

• 4.5.8 03/09/2008
   Postfixadmin : mise à jour en version 458. Mise à jour de vacation.pl

• 4.5.7 02/08/2008
   Postfixadmin : mise à jour en version 432. Corrige le bug pour l’effacement du vacation_notification dans le mode admin

• 4.5.6 01/08/2008
   Postfixadmin : mise à jour vacation.pl. Remise en forme du paragraphe dans le tuto pour créer le /etc/postfix/transport par wget+sed.
   Dspam : simplification de l’import sql (wget)

• 4.5.5 31/07/2008
   Postfixadmin : mise à jour en version 431. Mise à jour du fichier config.inc.php

• 4.5.4 20/07/2008
   SA : retrait de la procédure cpan et installation des modules perl en package debian.

• 4.5.3 19/07/2008
   Amavisd : retrait de la procédure cpan et installation des modules perl en package debian.

• 4.5.2 18/07/2008
   Amavisd : Modification des options de compilation pour deplacer les binaires dans le chemin par defaut : /usr au lieu de /usr/local
   Policyd : Idem
   SA : idem. On installe SA directement par perl et non plus par CPAN.

• 4.5.1 17/07/2008
   Clamd : Modification des options de compilation pour deplacer les binaires dans le chemin par defaut : /usr au lieu de /usr/local. Meme chose pour clamdmon dont le package fourni a été modifié.
   Dspam : Idem

• 4.5.0 08/07/2008
   Clamd : Mise à jour en version 0.93.3

• 4.4.9 04/07/2008
   Postfixadmin : Mise à jour du script sql de creation des tables
   Postfix : passage des commandes de creation des fichiers de lookup sql de la partie antispam/antivirus en wget/sed.

• 4.4.8 02/07/2008
   Postfix : Modification des droits sur les lookup sql de la partie antispam. Le owner doit etre root, et non postfix.
   Maildrop : Modification de la création du fichier quotawarnmsg. On ne le place plus que dans /etc/. La creation du dossier /usr/local/courier etant inutile.

• 4.4.7 01/07/2008
   Mailfilter : Modification de la création du dossier des mails envoyés par défaut. Désormais le répertoire sera Sent, et plus sent-mail pour compatibilité avec les dernieres versions de horde et avec Thunderbird. Ajout d’une regle pour intercepter les mails avec l’extension +spam, utilisée par amavisd si il est paramétré avec Mailzu.

• 4.4.6 30/06/2008
   Policyd : précision sur la possibilité de placer la vérification dans le smtpd_recipient_restrictions dans le cas ou le controle du nombre de mails envoyés/recus est primordial.

• 4.4.5 28/06/2008
   Amavisd : Mise à jour en version 2.6.1

• 4.4.4 28/06/2008
   Amavisd : modification du script sql pour le pb d’import. Correction officielle.

• 4.4.3 25/06/2008
   Clamav : Mise à jour du script UpdateSaneSecurity.sh pour eviter le controle du repertoire /var/lib/clamav (structure differente dans les dernieres versions de clamav)

• 4.4.2 24/06/2008
   Postfix : Modification dans la mise en forme du tuto de l’insert des tables sql principales et des fichiers de lookup. (wget + sed)
   SASL : idem pour tout la section

• 4.4.1 23/06/2008
   Postfix : Mise en place des prérequis pour l’utilisation de certains domaines en relais uniquement en cochant l’option relative dans postfixadmin. (ajout du fichier /etc/postfix/mysql_relay_domains_maps.cf et modification du fichier /etc/postfix/mysql_virtual_domains_maps.cf)

• 4.4.0 16/06/2008
   Maildrop : Passage à la version par paquet debian. Au niveau fonctionnel cela modifie le comportement de maildrop lors d’un over quota : il ne rejette plus le mail générant ainsi un bounce, mais il met celui ci en queue.
   Courier/Dovecot : Mise en forme du tuto pour bien séparer les 2 installations
   Clamd : ajout de clamdmon en telechargement car il a disparu des sources de clamd 0.93.1

• 4.3.6 14/06/2008
   SA : Mise à jour en version 3.2.5

• 4.3.5 11/06/2008
   Amavisd : ajout dans le amavisd.conf fourni d’une section banned_rules, permettant de specifier dans les policies dans la base sql une liste personnalisée de fichiers bannis. Il s’agit d’exemple qui pourront bien sur etre modifiés.

• 4.3.4 11/06/2008
   Amavisd : ajout d’exemple et d’explication sur les policies dans SQL. Explication sur la possibilité de paramétrer par domaine.

• 4.3.3 09/06/2008
   Clamd : Mise à jour en version 0.93.1

• 4.3.2 02/06/2008
   Policyd : désactivation des options de verifications du HELO par défaut dans le fichier de configuration fourni. La verification du HELO est deja faite dans postfix et le controle du HELO selon l’hote peut générer des blocages. Ces 2 controles peuvent etre reactivés si l’on comprend bien leur fonctionnement.

• 4.3.1 02/05/2008
   Postfixadmin : Remplacement dans le tuto du config.inc.php par un fichier preconfiguré a télécharger.
   Postfixadmin : mise à jour en version 3.5.8. Cette version correspond a la release 2.2

• 4.3.0 23/04/2008
   Amavisd : Mise à jour en version 2.6.0. Mise à jour du fichier amavisd.conf pour ajouter le parametre d’activation de la signature dkim

• 4.2.8 22/04/2008
   Général : Uniformisation du nom du serveur dans le tuto : dans le /etc/hosts retrait du domaine seul (starbridge.org). Dans la partie TLS, modification du CN en spike.starbridge.org au lieu de starbridge.org

• 4.2.7 20/04/2008
   Amavisd : Mise à jour en version 2.6.0rc2. Mise à jour du script sql et du fichier amavisd.conf.

• 4.2.6 14/04/2008
   Clamd : Mise à jour en version 0.93. Mise à jour des fichiers de configuration.

• 4.2.5 9/04/2008
   Maildrop : mise à jour de l’url pour récupérer les sources

• 4.2.4 1/04/2008
   Amavisd : modification du tuto pour faire en sorte de recuperer le fichier de conf d’amavisd correctement modifié au début de l’installation et d’eviter ainsi les erreurs de conf.

• 4.2.3 28/03/2008
   Amavisd : prerequis Mail ::DKIM deplacé de la partie SA vers amavisd dans le tuto car c’est désormais un prérequis pour amavisd

• 4.2.2 26/03/2008
   Reporting : Ajout de mailgraph pour générer des graphiques.

• 4.2.1 26/03/2008
   Policyd : FIX pour le pb de multiple recipient : Suppression de la verification de policyd sur les recipient. (policyd.conf mis a jour)

• 4.2.0 21/03/2008
   Postfix : Nettoyage d’une ACL inutile dans le stage smtpd_sender_restrictions (reject_unknown_sender_domain) car présente ensuite dans le stage smtpd_recipient_restrictions.
   Policyd : Déplacement de la règle d’appel de policyd dans le main.cf du stage smtpd_recipient_restrictions à smtpd_end_of_data_restrictions. Cela permet à Policyd de connaitre la taille d’un message, mais aussi cela permet de faire passer au travers de policyd les senders locaux. Cela permettra donc un controle de flux pour les users internes. Mise a jour du document de gestion du serveur pour refleter ce changement.

• 4.1.1 21/03/2008
   Amavisd : Activation dans amavisd du port 10026 pour utiliser la policy bank ORIGINATING et permettre aux utilisateurs passant par le port 587 et authentifiés par SASL d’etre considérés comme locaux par amavisd, meme si ils sont en dehors du LAN.

• 4.1.0 20/03/2008
   Amavisd : Mise à jour en 2.6.0rc1. Mise à jour du script SQL d’amavisd. Ajout d’une section pour configurer la signature DKIM par amavisd.

• 4.0.4 19/03/2008
   Général : ajout de lien pour suivre l’installation de Dovecot à la place de Courier-imap dans le tuto

• 4.0.3 13/03/2008
   Amavisd : mise à jour en amavisd-new-2.5.4

• 4.0.2 11/03/2008
   Postfix : Mise à jour du master.cf de base pour la version 2.5 (ajout de proxywrite).
   Postfixadmin : Mise en jour en 311

• 4.0.1 10/03/2008
   Postfix : Mise à jour des chemins btree dans le main.cf pour prendre en compte un changement dans la version 2.5 de postfix. ( $queue_directory ==> $data_directory ). Ajout d’une note pour la compatibilité avec Postfix < 2.5

• 4.0.0 26/02/2008
   FIX : Maildrop : le mail de warning lors de l’approche du quota (90%) ne fonctionnait plus ==> Modification de la méthode d’installation du fichier quotawarnmsg et surtout de sa localisation.

• 3.9.8 12/02/2008
   Clam : Mise à jour en version 0.92.1

• 3.9.7 31/01/2008
   Clam : Mise à jour du script UpdateSaneSecurity.sh.

• 3.9.6 30/01/2008

 Logwatch : Mise à jour en amavis-logwatch-1.48.27

• 3.9.5 29/01/2008
   Courier : ajout d’une clause dans authmysqlrc pour vérifier le statut actif du compte et rendre le login imap impossible si celui ci est desactivé

• 3.9.4 29/01/2008
   Dspam : passage du fichier de configuration en wget et sed pour modification du password.

• 3.9.3 28/01/2008
   firewall : le script de firewall a été transformé en lien pour limiter la taille de la page du tuto.
   policyd : passage du fichier de configuration en wget, modification du uid/gid du user policyd en 20002 pour matcher le fichier de conf. passage du fichier init en wget

• 3.9.2 21/01/2008
   Postfixadmin : Mise à jour en révision 298

• 3.9.1 14/01/2008
   Général : modification de la procédure de création de nombreux script en wget pour faciliter la mise en oeuvre (sa-learn, sa-update, sa-compile, dspam.....)

• 3.9.0 11/01/2008
   Postfixadmin : Mise à jour en révision 291. Ajout d’un import wget pour le config.inc.php et d’une commande de substitition du nom de domaine pour faciliter l’edition de ce fichier de config.
   Postfix : ajout d’un script pour importer la table sql et commande rapide pour le changement du domaine.
   Maildrop : ajout d’un wget pour importer directement le fichier authmysqlrc et éviter ainsi les erreurs de saisie. Ajput de la commande pour modifier le password dans le fichier.

• 3.8.9 9/1/2008
   SA : Mise à jour en version 3.2.4.

• 3.8.8 31/12/2007
   Postfixadmin : Mise à jour en révision 283.

• 3.8.7 18/12/2007
   Clam : Mise à jour en version 0.92

• 3.8.6.1 18/12/2007
   SA : FIX : Correction de l’erreur sur le nom du fichier sql de la base suite à la mise à jour 3.8.4

• 3.8.6 17/12/2007
   Amavisd/Postfix : Modification du destinataire du test telnet (postmaster —> admin@starbridge.org) qui ne fonctionnait plus depuis la mise à jour du tuto 3.8.1
   Général : modification de la commande de création du user vmail. Création automatique du home "virtual".
   Maildrop : Précision pour le paquet libpcre++-dev sous etch.

• 3.8.5 14/12/2007
   Postfixadmin : Mise à jour en révision 268. Adaptation du config.inc.php.

• 3.8.4 12/12/2007
   SA : ajout du support de l’AutoWhitelist (AWL) : ajout de la table sql, modification du local.cf et ajout d’un script de purge.
   SA : modification de l’import SQL : modification du script pour prendre en compte la creation directe des tables InnoDB. Retrait de la section de conversion en InnoDB.
   Amavisd : Mise à jour en version 2.5.3

• 3.8.3 09/12/2007
   Clam : modification du fichier clamdmon.sh pour ajouter les chemins vers les binaires.

• 3.8.2 06/12/2007
   Postfix : ajout d’un paragraphe dans la section analyse des logs sur la nécessité de desactiver l’envoi de mail au postmaster pour les bounces, une fois la période de test terminée.

• 3.8.1 30/11/2007
   Postfix-Amavisd : Retrait du paramètre receive_override = no_address_mappings dans le main.cf pour le déplacer dans le master.cf sur le port 10025. Cela permettra d’utiliser pleinement les rêgles par utilisateurs dans amavisd.
   amavisd : Changement du destinataire des mails d’alerte virus (virusalert ==> admin)

• 3.8.0.1 27/11/2007
   Postfixadmin : svn : mise a jour en version 248
   typos

• 3.8.0 25/11/2007
   Amavisd : ajout d’une section sur la configuration de Penpals et des lookups SQL pour une gestion par utilisateurs

• 3.7.4 23/11/2007
   SA : /etc/sa-update.sh, ajout des chemins en dur vers les binaires, pour eviter les problèmes avec Ubuntu.
   SA : ajout du chemin dans la crontab pour le sa-learn

• 3.7.3 22/11/2007
   policyd : ajout des INSERT dans la table blacklist_helo

• 3.7.2 20/11/2007
   Postfix : Activation dans le master.cf du port 587 (submission).
   Postfix : Préparation du port 465 (smtps) mais non activé (commenté). Il peut etre nécessaire suivant les cas de figure. Ce port est considéré comme obsolète.
   Firewall : Ouverture du port 587.
   Amavisd : ajout de notes et d’un lien vers un autre article du site sur l’utilisation du port 587 pour bypasser l’antispam pour les mails sortants.

• 3.7.1 15/11/2007
   Postfixadmin : passage en révision 227.

• 3.7.0 13/11/2007
   TLS : Refonte totale de la création des certificats et de la CA.
   Postfix-TLS : modification des options relatives dans le main.cf
   Imapd-ssl : Ajout de la creation d’un certificat personnalisé et signé par la CA
   Postfixadmin-ApacheSSL : Modification du certificat.
   UpdateSaneSecurity : Changement pour la 1ere execution du script : c’est le user amavis qui la lance, a l’identique du cron.
   Postfix : Nettoyage du main.cf original (celui du debut du tuto). retrait de parametres inutiles. Pas de changement dans les fonctionnalités.

• 3.6.6 12/11/2007
   Maildrop : ajout d’une précision sur le point pour terminer un mail en ligne de commande.
   Maildrop : Ajout d’une précision sur les droits à appliquer au fichier personnel .mailfilter.
   Postfix sql : Nettoyage des scripts de création des tables postfix_hello et postfix_access. (AUTO INCREMENT)
   Postfixadmin : passage en révision 215.
   Postfixadmin : Retrait du paragraphe sur le .htaccess dans le répertoire admin car celui ci n’existe plus dans cette version. (il est vide)
   Postfixadmin : Retrait du paragraphe sur la correction de l’affichage.
   Postfixadmin : Mise à jour du config.inc.php
   Amavisd : retrait du mkdir /var/amavis, déjà crée par la commande adduser.
   sa-learn : précision sur les deplacements des emails dans les dossiers SpamFalse et SpamToLearn
   Typo

• 3.6.5 08/11/2007
   Vacation.pl : modification du script pour ne pas envoyer d’autoreply pour messages marqués comme spam par SA.

• 3.6.4 07/11/2007
   Maildrop : modification des droits appliqués sur le /var/run/courier/authdaemon. (775 ==> 750)

• 3.6.3.1 30/10/2007
   FIX clam : Modification du chmod sur le dossier /var/tmp/clamdb pour eviter une erreur de droits lors de l’exécution du script.

• 3.6.3 28/10/2007
   Clam : modification dans le tuto pour automatiquement telecharger les fichiers de configuration clamd.conf et freshclam.conf. Plus besoin de les editer manuellement.
   Freshclam : Modification du cron en edition de la crontab plutôt que par un fichier dans /etc/cron.d
   SA : ajout de 2 modules perl optionnels : Mail ::DKIM et Encode ::Detect. Ajout du package libssl-dev necessaire a la compilation, en début de tuto.
   SA : Edition du fichier /etc/mail/spamassassin/v312.pre pour activation du plugin Mail ::Dkim

• 3.6.2 27/10/2007
   Clam : modification du crontab de UpdateSaneSecurity. Il sera exécuté par le user amavis. (au lieu de root)
   Clam : Déplacement du paragraphe de UpdateSaneSecurity dans celui de l’install de clamd.
   Clam : retrait de la création du RamDisk /var/lib/clamav pour éviter le problème au redémarrage.
   clam : ajout du lancement de freshclam lors de l’init.d de clam.
   Freshclam : Retrait du lancement de freshclam en cron au boot. Retrait d’un —log-verbose en trop dans la ligne.
   Clamav : installation de clamdmon pour surveiller Clam.

• 3.6.1 25/10/2007
   vacation.pl : ajout du module Mail ::Sendmail dans les prérequis (ils se trouvent dans la partie amavisd du tuto) pour éviter un problème de dépendances.

• 3.6 24/10/2007
   postfixadmin : modification du script de sécurisation des fichiers, effacement du setup.php plus tôt dans le tuto. Rappel du password du superadmin
   postfixadmin : ajout de la modification pour la mise en page en francais
   logwatch : mise à jour des liens pour le téléchargement suite aux changements sur le site original.
   typos

• 3.5.9 17/10/2007
   postfixadmin : passage en révision 157
   postfixadmin : mise à jour vacation.pl

• 3.5.8 04/10/2007
   postfixadmin : passage en révision 132. Modification du config.inc.php
   postfixadmin : mise à jour vacation.pl

• 3.5.7 03/10/2007
   policyd : mise à jour de la version en 1.82. Modification des liens.

• 3.5.6 26/09/2007
   postfixadmin : on passe le SVN à la révision 99.
   Typo

• 3.5.6 23/09/2007
   postfixadmin : retrait de la modification du EHLO en HELO dans le fichier function.inc.php = bugs d’envoi du mail création de boite fixé.
   postfixadmin : on fixe temporairement le SVN à la révision 66, pour des bugs dans les versions supérieures à la date d’aujourd’hui.

• 3.5.5.1 20/09/2007
   postfixadmin vacation : nouvelle version de vacation.pl
   postfixadmin vacation : ajout des modules perl nécessaires.

• 3.5.5 19/09/2007
   Postfixadmin vacation : Modification du fichier vacation.pl fourni
   Postfixadmin vacation : modification de la table vacation : champ active INT (1) en active INT (4) et conversion de la table en InnoDB
   Postfixadmin vacation : Ajout de la table vacation_notification.
   Postfixadmin : Modification de la table Domain : ajout du champ quota
   Postfix Admin config.inc.php : ajout de paramètres optionnels

• 3.5.4 09/09/2007
   maildrop : retrait de GDBM extensions enabled. de l’exemple de retour d’un maildrop -v car cette extension a été désactivé dans le configure.
   maildrop : modification du configure : retrait de --enable-maildropmysql et --with-mysqlconfig=/etc/courier/maildropmysql.config devenuent obsolètes.
   maildrop : ajout d’un workaround pour l’erreur a la fin du make install de la version 2.0.4.

• 3.5.3 05/09/2007
   Postfixadmin : ajout de la commande de redémarrage d’apache à la fin de la configuration SSL.
   SASL : modification des droits sur le /var/spool/postfix/run/saslauthd de 770 en 710.

• 3.5.2 02/09/2007
   sa-learn : modification du script pour éliminer les messages d’alertes inutiles par email.

• 3.5.1 29/08/2007
   Vacation : correction d’une erreur dans le fichier /etc/postfix/transport : oubli du :

• 3.5 28/08/2007
   Postfix Mysql : correction d’une erreur dans le fichier /etc/postfix/virtual_domains_maps.cf : à la place de SELECT description il fallait lire SELECT domain

• 3.4.2 24/08/2007
   Postfixadmin : correction d’une erreur sur la commande svn (merci à ARk0 !) ( un - inutile devant le co

• 3.4.1 23/08/2007
   Général : Modification de la base debian :: on prend désormais la version testing comme référence.
   Clamav : modification des prérequis de compilation : paquet renommé dans la version lenny : libgmpxx4ldbl

• 3.4 21/08/2007
   Maildrop : modification de la version en 2.0.4.
   Maildrop : Ajout de make à la liste de packages nécessaires à l’installation.
   Maildrop : Explication sur le message d’erreur à la fin du make install et sur le temps nécessaire au ./configure.
   Maildrop : retrait du paragraphe sur le fichier obsolète maildropmysqlconfig
   Maildrop : ajout de précisions sur la procédure de test.
   TLS : ajout d’un chmod sur le dossier /etc/postfix/tls
   SASL : modification du fichier /etc/init.d/postfix pour tenir compte des mises à jour debian. (dans la ligne FILE, le fichier etc/nss_mdns.config a été ajouté par l’installeur)
   Postfix : mise à jour du master.cf original pour correspondre à la dernière version de l’installeur.
   Postfixadmin : [rouge]refonte totale[/rouge]. Installation de la version SVN. Mise à jour des commentaires.
   Postfixadmin : ajout d’une section sur l’installation du SSL dans apache
   Clamav : Mise à jour version 0.91.2 et mise à jour des fichiers de configuration d’exemple.
   Clamav : modification des prérequis de compilation. (changement de version du paquet debian libgmpxx4)
   Ramdisk : modification du mount pour les ramdisk (mount tmfs)
   Vacation : modification/simplification de la procédure (ajout de wget) et modification du lien vers postfixadmin dans cette section en https:// (ajout du ssl)

• 3.3 19/08/2007
   retrait de scores obsolètes dans local.cf pour SA : (HTML_60_70 et HTML_SHOUTING3)

• 3.2 11/08/2007
   modification de la structure des tables SQL de postfixadmin : correction des index.
   ajout de sa-compile dans l’installation de SA

• 3.1 08/08/2007
   ajout de la section sur les mises à jour des règles SA et installation des règles SARE.
   ajout de la section sur l’installation des signatures supplémentaires de Clam : sanesecurity.
   mise à jour du ficher amavisd.conf d’exemple (lien)

• 3.0 06/08/2007
   ajout d’une section Firewall avec un exemple.
   modification des liens pointant sur le tuto webmail (tuto crée ce jour)

• 2.8 30/07/2007
   retrait du paragraphe sur la modification d’amavisd 2.50 et antérieures pour fonctionner avec dspam 3.8.0. On utilise amavisd 2.52 par défaut désormais. Si nécessaire, la modification à effectuer est toujours documentée dans l’article spécifique sur DSPAM.
   typos
   précision sur le fichier maildropmysql.config dans la partie sur Maildrop

• 2.7 27/07/2007
   retrait des commandes postmap inutiles sur les fichiers de lookup Mysql
   mise à jour de certains lookup sql qui étaient notés avec l’ancienne syntaxe de postfix.

• 2.6 18/07/2007
   Mise à jour du lien pour clamav 0.91.1

• 2.5 09/07/2007
   Modification du master.cf pour eviter le filtrage et les body/header checks sur le pickup.

• 2.4 03/07/2007
   ajout de la modification de /etc/init.d/courier-authdaemon sous ubuntu pour éviter le changement des droits à chaque lancement.
   simplification du paragraphe sur les RBL. Seules 2 listes restent en fonction par défaut.

• 2.3 30/06/2007
   modification du lien de clamd pour la version 0.91rc2 en raison du bug de demarrage de la version 0.90.3.

• 2.2 29/06/2007
   ajout d’un paragraphe dans courier-imap sur l’utilisation de ENHANCEDIDLE.
   ajout d’un paragraphe dans courier-imap sur le nombre de process maximum
   ajout d’un paragraphe dans courier-imap sur le fonctionnement des fichiers de configuration imapd et imapd-ssl

• 2.1 28/06/2007
   Typo

• 2.0 27/06/2007
   Partie antispam, paramétrage de postfix (stmd_recipient_restrictions..) : Refonte complète du paragraphe pour ajouter des règles pour éviter le spoofing des adresses expéditrices.
   Postfix main.cf (au début du tuto) : ajout de $smtpd_sender_login_maps dans proxy_read_maps.
   Mise à jour des liens pour Amavisd-2.5.2

• 1.3 26/06/2007 Merci à Guillain pour son aide !
   Typos : type Mime
   Headers/body/tyme Mime : modification des noms de fichiers pour qu’ils aient tous la terminaison .cf
   SASL : Ajout du START=yes dans le /etc/default/saslauthd
   Maildrop : ajout de libpcre3-dev dans les paquets nécessaires à installer (compatibilité Ubuntu)
   Maildrop : ajout de l’installation de la commande mail pour les systèmes Ubuntu

• 1.2 06/06/2007
   Modification du script d’apprentissage SA
   ajout des boîtes email d’apprentissage Spam et Ham
   ajout des répertoires par défaut dans les boîtes imap : SpamToLearn et SpamFalse

• 1.1 31/05/2007
   Modification du Main.cf et déplacement du reject_unauth_pipelining sous smtpd_data_restrictions.
   Modification de postfixadmin pour corriger le bug d’envoi de l’email de confirmation lié a la restriction sur le pipelining.

• 1.0 Article Original