Installation Serveur Mail Postfix, Amavisd, Mysql, Spamassassin, Dspam, Courier-IMAP
Adminstration Server Linux Add comments
Ce tutorial a été intégralement repris du site http://www.starbridge.org et a été réalisé par tonio. Il est distribué sous licence creativecommons 
Le système sur lequel est basé ce document est une DEBIAN stable (Lenny). La version ancienne Stable (Etch) à la date de rédaction présente quelques différences sur certains paquets (changement de nom lors des montées de version : voir le site Debian pour les versions équivalentes) mais cela n’entraîne aucun problème dans les fonctionnalités. Le tuto est aussi compatible avec la version Testing.
Par souci de clarté, on a detaillé chaque action le plus précisement possible, et ce pour ne pas réduire le tuto à une simple succession de commandes. Mais cela peut se réveler parfois fastidieux de créer un fichier en copier/coller puis de modifier le mot de passe. (surtout quand il faut modifier plusieurs occurences).
C’est pour cela que l’on trouvera en note en pied de page les commandes rapides pour exécuter certaines actions longues.
Un hyperlien avec un numéro est le signe de l’existence d’une commande rapide. Pratique lorsque l’on refait le tuto (ou pour les fainéants !)
Ce tuto fonctionne également sous Ubuntu mais certains paquets présentent de légères différences. On essaiera de les indiquer si possible.
On utilisera comme serveur IMAP celui de Courier, mais pour ceux qui le souhaitent, nous préciserons la marche à suivre pour installer Dovecot à la place.
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 :
aptitude update aptitude dist-upgrade
On vérifie les fichiers :
- /etc/hostname :
spike.starbridge.org
- /etc/hosts :
127.0.0.1 spike.starbridge.org localhost.localdomain localhost spike
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.
aptitude install bind9
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 :
nameserver 127.0.0.1 search starbridge.org
on relance le serveur DNS :
/etc/init.d/bind9 restart
Puis on teste la résolution avec nslookup ou dig
nslookup >server
doit retourner :
Default server: 127.0.0.1 Address: 127.0.0.1#53
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 :
aptitude install bzip2 gcc libpcre3-dev libpcre++-dev courier-authlib-dev g++ libtool libmysqlclient15-dev make libssl-dev automake autoconf
Postfix et Mysql
aptitude install postfix postfix-mysql mysql-client-5.0 mysql-server-5.0 courier-authdaemon courier-authlib-mysql libsasl2-2 libsasl2-modules sasl2-bin libpam-mysql openssl ntp tmpreaper
D’autre paquets vont s’installer en même temps. L’ancien MTA exim4 sera désintallé.
Note : pour les questions de l’installeur Debian :
- postfix configuration : SITE INTERNET. Pour le reste on répond par
défaut.
On installe apache + php5 pour gérer plus tard le tout avec l’interface postfixadmin.
aptitude install apache2 libapache2-mod-php5 php5-mysql
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.
mysqladmin -u root password '*****' mysqladmin -u root --password='*****' create postfix
Création de l’user postfix :
$ mysql -u root -p Enter password: GRANT ALL PRIVILEGES ON postfix.* TO "postfix"@"localhost" IDENTIFIED BY '******';
On crée les tables suivantes dans la base Postfix :
Evidemment on modifie la commande sed pour inclure son domaine.
wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/postfix.sql sed -i 's/starbridge.org/toto.com/g' postfix.sql mysql -u root -p < postfix.sql
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 » ($1$caea3837$gPafod/Do/8Jj5M9HehhM.)
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.
Paramétrage de Postfix
Note : on remarquera que l’on laisse Postfix chrooté et que l’on utilise le daemon proxy pour communiquer avec le socket de Mysql.
On remplace tout le /etc/postfix/main.cf par le contenu ci dessous :
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) biff = no append_dot_mydomain = no myhostname = spike.starbridge.org alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases myorigin = $mydomain mydestination = $myhostname, localhost.$mydomain, localhost mynetworks = 127.0.0.0/8 recipient_delimiter = + home_mailbox = Maildir/ notify_classes = 2bounce, bounce, delay, policy, protocol, resource, software smtpd_helo_required = yes strict_rfc821_envelopes = yes relay_domains = proxy:mysql:/etc/postfix/mysql_relay_domains_maps.cf virtual_alias_maps = proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf virtual_gid_maps = static:20001 virtual_mailbox_base = /home/virtual virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf virtual_minimum_uid = 20001 virtual_uid_maps = static:20001 proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $smtpd_recipient_restrictions $smtpd_sender_login_maps message_size_limit = 50240000 smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, permit smtpd_data_restrictions = reject_unauth_pipelining, permit
On modifie le /etc/postfix/master.cf comme ci dessous :
#
# Postfix master process configuration file. For details on the format
# of the file, see the master(5) manual page (command: "man 5 master").
#
# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
587 inet n - - - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_etrn_restrictions=reject
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
#smtps inet n - - - - smtpd
# -o smtpd_tls_wrappermode=yes
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#628 inet n - - - - qmqpd
pickup fifo n - - 60 1 pickup
-o receive_override_options=no_header_body_checks
-o content_filter=
cleanup unix n - - - 0 cleanup
qmgr fifo n - n 300 1 qmgr
#qmgr fifo n - - 300 1 oqmgr
tlsmgr unix - - - 1000? 1 tlsmgr
rewrite unix - - - - - trivial-rewrite
bounce unix - - - - 0 bounce
defer unix - - - - 0 bounce
trace unix - - - - 0 bounce
verify unix - - - - 1 verify
flush unix n - - 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - - - - smtp
# When relaying mail as backup MX, disable fallback_relay to avoid MX loops
relay unix - - - - - smtp
-o fallback_relay=
# -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq unix n - - - - showq
error unix - - - - - error
retry unix - - - - - error
discard unix - - - - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - - - - lmtp
anvil unix - - - - 1 anvil
scache unix - - - - 1 scache
#
# ====================================================================
# Interfaces to non-Postfix software. Be sure to examine the manual
# pages of the non-Postfix software to find out what options it wants.
#
# Many of the following services use the Postfix pipe(8) delivery
# agent. See the pipe(8) man page for information about ${recipient}
# and other message envelope options.
# ====================================================================
#
# maildrop. See the Postfix MAILDROP_README file for details.
# Also specify in main.cf: maildrop_destination_recipient_limit=1
#
maildrop unix - n n - - pipe
flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}
#
# See the Postfix UUCP_README file for configuration details.
#
uucp unix - n n - - pipe
flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
#
# Other external delivery methods.
#
ifmail unix - n n - - pipe
flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp unix - n n - - pipe
flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient
scalemail-backend unix - n n - 2 pipe
flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop} ${user} ${extension}
mailman unix - n n - - pipe
flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
${nexthop} ${user}
On crée le groupe et le user vmail avec l’uid et gid 20001, ainsi que le répertoire des mails :
groupadd -g 20001 vmail useradd -g vmail -u 20001 vmail -d /home/virtual -m
On sécurise :
chown -R vmail: /home/virtual chmod 770 /home/virtual
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)
cd /etc/postfix
wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/mysql_virtual_alias_maps.cf
wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/mysql_virtual_domains_maps.cf
wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/mysql_virtual_mailbox_maps.cf
wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/mysql_relay_domains_maps.cf
sed -i 's/\*\*\*\*/toto/g' mysql_virtual_alias_maps.cf mysql_virtual_domains_maps.cf mysql_virtual_mailbox_maps.cf mysql_relay_domains_maps.cf
On sécurise le tout :
chmod 640 /etc/postfix/mysql_* chgrp postfix /etc/postfix/mysql_*
Maildrop
Nous avons 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 répond lui à nos besoins :
Il s’occupera donc de la livraison des mails dans les home.
On installe maildrop
aptitude install maildrop
On applique les permissions correctement sur les exécutables et sur /var/run/courier/authdaemaon :
chown vmail: /usr/bin/maildrop chown vmail:daemon /var/run/courier/authdaemon/ chmod 750 /var/run/courier/authdaemon/
Note : Pour Ubuntu il faut modifier en plus le fichier
/etc/init.d/courier-authdaemon et remplacer
chown daemon:daemon ${run_dir} /var/run/courier par
chown vmail:daemon ${run_dir}
Note : Pour la version Testing Squeeze il faut modifier le fichier /etc/init.d/courier-authdaemon et remplacer
if [ ! -d "$rundir" ]; then mkdir -p -m 0750 $rundir fi
par
if [ ! -d "$rundir" ]; then mkdir -p $rundir chown daemon:daemon /var/run/courier chown vmail:daemon $rundir chmod 750 $rundir fi
On vérifie si maildrop est correctement installé (modules activés) :
/usr/bin/maildrop -v
devrait donner :
maildrop 2.0.4 Copyright 1998-2005 Double Precision, Inc. Courier Authentication Library extension enabled. Maildir quota extension enabled. This program is distributed under the terms of the GNU General Public License. See COPYING for additional information.
On voit que l’authentification est activée, ainsi que la gestion des quotas que nous configurerons plus tard.
On édite le fichier /etc/courier/authdaemonrc pour remplacer authmodulelist= »authpam » par authmodulelist= »authpam authmysql » :
cd /etc/courier mv authdaemonrc authdaemonrc-orig wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/authdaemonrc chown daemon: authdaemonrc chmod 660 authdaemonrc
On exécute les commandes suivantes pour créer le fichier authmysqlrc (toto étant votre password) :
cd /etc/courier mv authmysqlrc authmysqlrc-orig wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/authmysqlrc chown daemon: authmysqlrc chmod 640 authmysqlrc sed -i 's/\*\*\*\*\*/toto/g' authmysqlrc
Note : Il faut faire très attention à la syntaxe de ce fichier et bien mettre un tab entre le paramètre et sa valeur. Il ne doit y avoir aucun espace à la fin d’un paramètre. La moindre erreur entraînera le non fonctionnement de l’authentification. C’est pour cela que le fichier est directement fourni ici et ne nécessite donc aucune modification autre que celle
du mot de passe de votre base.
Maildrop est appelé par Postfix au moment de la livraison. Pour que Postfix utilise Maildrop, on ajoute au main.cf :
virtual_transport = maildrop maildrop_destination_recipient_limit = 1
et au master.cf (on efface les ligne maildrop existantes et on les remplace par celles ci) :
maildrop unix - n n - - pipe
flags=DRhu user=vmail argv=/usr/bin/maildrop -w 90 -d ${user}@${nexthop} ${extension} ${recipient} ${user} ${nexthop} ${sender}
On crée /home/virtual/.mailfilter pour activer les logs et la création automatique des maildir à la livraison (postfix ne sait pas le faire comme avec le transport par défaut « virtual », car ce n’est pas lui qui livre directement dans les répertoires) :
vi /home/virtual/.mailfilter
et on colle :
logfile "/home/virtual/.maildrop.log"
`[ -d $DEFAULT ] || (maildirmake $DEFAULT && maildirmake -f Spam $DEFAULT && maildirmake -f Sent $DEFAULT && maildirmake -f SpamToLearn $DEFAULT && maildirmake -f SpamFalse $DEFAULT)`
`test -r $HOME/$DEFAULT.mailfilter`
if( $RETURNCODE == 0 )
{
log "(==) Including $HOME/$DEFAULT.mailfilter"
exception {
include $HOME/$DEFAULT.mailfilter
}
}
On sécurise ce fichier :
chown vmail: /home/virtual/.mailfilter chmod 600 /home/virtual/.mailfilter
on redémarre le daemon d’authentification et Postfix
/etc/init.d/courier-authdaemon restart /etc/init.d/postfix restart
On teste cette première configuration de base :
authtest user@starbridge.org
doit donner :
Authentication succeeded. Authenticated: user@starbridge.org (uid 20001, gid 20001) Home Directory: /home/virtual Maildir: user@starbridge.org/ Quota: 0S Encrypted Password: $1$caea3837$gPafod/Do/8Jj5M9HehhM. Cleartext Password: (none) Options: (none)
En cas d’erreur, il est fort probable que le fichier authmysqlrc soit en cause.
Regarder les logs : /var/log/mail.log.
puis :
/usr/bin/maildrop -V 7 -d user@starbridge.org
cela devrait donner :
maildrop: authlib: groupid=20001 maildrop: authlib: userid=20001 maildrop: authlib: logname=user@starbridge.org, home=/home/virtual, mail=user@starbridge.org/ maildrop: Changing to /home/virtual
CTRL + C pour sortir
On vérifie que l’on peut envoyer un mail à user@starbridge.org :
mail 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 :
...status=sent (delivered via maildrop service)...
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) :
---> telnet localhost 25 220 [127.0.0.1] ESMTP Postfix ---> HELO localhost 250 [127.0.0.1] ---> MAIL FROM: <> 250 2.1.0 Sender OK ---> RCPT TO: <user@starbridge.org> 250 2.1.5 OK ---> DATA 354 End data with <CR><LF>.<CR><LF> ---> . 250 2.0.0 Ok: queued as 079474CE44 ---> QUIT 221 2.0.0 Bye Connection closed by foreign host
On regarde les logs pour vérifier.
- NOTE : Le fichier .mailfilter crée plus haut 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 .mailfilter dans son Maildir. On pourra par exemple rediriger des emails dans des répertoires spécifiques de cette façon.
Exemple de fichier .mailfilter personnel :
#elimine les messages en provenance de l'adresse ci-dessous
if( \
/^From: .*actu@b\.linternaute\.com/:h \
)
exception {
to "/dev/null"
}
##### annonces #####
if( \
/^From: .*alerte@avendrealouer\.fr/:h \
|| /^From: .*mailing_pap@pap\.fr/:h \
|| /^Sender: .*alertemail@pap\.fr/:h \
)
exception {
to "${DEFAULT}/.annonces/"
}
Note : Pour la création assistée et autonome (par les utilisateurs eux-mêmes) des fichiers mailfilter personnels on pourra utiliser un module du Webmail horde.
L’article sur l’installation du Webmail traite ce point en détail.
Bien sur on appliquera les mêmes droits que pour le fichier .mailfilter général à ce fichier personnel :
chown vmail: /home/virtual/user@starbridge.org/.mailfilter chmod 600 /home/virtual/user@starbridge.org/.mailfilter
Courier-Imap
Note : Pour intaller et configurer Dovecot si on a choisi celui ci, suivre ce lien
Dovecot et ne pas exécuter les instructions de cette section.
On a déjà configuré la partie la plus importante de courier-imap, c’est à dire l’authentification mysql, dans la partie sur Maildrop.
On va installer le serveur imap proprement dit
aptitude install courier-imap courier-imap-ssl fam
Note : pour les questions de l’installeur Debian :
- courier-base : Faut-il créer les répertoires nécessaires à l’administration web = NON.
On va maintenant ajouter une fonctionnalité très utile à Courier-IMAP :
le ENHANCEDIDLE
Cela permet de rafraîchir en temps réel la boîte de réception dans le client de messagerie sans besoin de la planifier ou autre.
Un nouveau message apparaîtra instantanément dans le client.
Attention :
- il faut que le client de messagerie supporte cette fonction. C’est le cas d’Outlook et de Thunderbird.
- Pour fonctionner cette fonction utilise FAM, le File Alteration Monitor. Sur des serveurs avec de très nombreuses boîtes email cela peut être un problème pour les performances.Il faut donc activer cette fonction en connaissance de cause et surveiller la charge au fil du temps.De plus FAM a tendance à planter sur de très grosses manipulations sur les boîtes (avec plusieurs milliers de mail).Dans ce cas de figure, Courier-Imap continuera à fonctionner sans problème (mais sans le temps réel bien sur) et des messages d’erreurs apparaîtront dans mail.log jusqu’au redémarrage de FAM.Il peut donc être judicieux de surveiller le process FAM et de le relancer automatiquement en cas d’arrêt. (un module Webmin fait cela très correctement)
Pour activer la fonction, rechercher ces paramètres dans /etc/courier/imapd et mettre leur valeur à 1 (IMAP_USELOCKS devrait déjà être sur 1 par défaut)
IMAP_USELOCKS=1 IMAP_ENHANCEDIDLE=1
On redémarre ensuite le daemon d’authentification et courier-imap :
/etc/init.d/courier-authdaemon restart /etc/init.d/courier-imap restart
On teste la connection depuis un client mail (outlook, thunderbird..)
Ne pas oublier de spécifier user@starbridge.org comme login de la boite et non ’user’ tout seul.
On rappelle que le password est ’secret’.
Paramétrer le SMTP sans authentification pour le moment.
On doit pouvoir consulter les mail envoyés localement tout à l’heure.
On teste un envoi de mail depuis le client sur sa propre adresse. On vérifie les logs et l’arrivée du nouveau mail dans la boîte.
Notes :
Par défaut courier IMAP est configuré pour démarrer au maximum 40 serveurs IMAP. Cela permettra à 40 utilisateurs de se connecter simultanément. (MAXDAEMONS=40)
Par défault, il limite également à 20 le nombre d’utilisateurs simultanés depuis la même IP. (MAXPERIP=20)
On modifiera donc ces paramètres en fonction du nombre de boîtes email.
/etc/courier/imapd
contient des paramètres généraux de configuration qui s’appliqueront également à imap-ssl. (par exemple le ENHANCEDIDLE). Cependant le nombre de daemons et de connections par IP se configure indépendamment dans /etc/courier/imapd et /etc/courier/imapd-ssl.
Authentification SASL
Pour le moment Postfix utilise l’adresse IP du client qui se connecte pour déterminer si il peut relayer ou non les mails (ou accepter seulement des mails pour les users locaux).
Pour pouvoir utiliser son serveur mail depuis l’extérieur (cas des laptops) on doit permettre une authentification sécurisée :
On crée le fichier /etc/pam.d/smtp :
cd /etc/pam.d wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/smtp sed -i 's/\*\*\*\*\*/toto/g' smtp
On sécurise ce fichier car le password est stocké en clair :
chmod 640 /etc/pam.d/smtp
On crée le fichier /etc/postfix/sasl/smtpd.conf :
cd /etc/postfix/sasl/ wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/smtpd.conf
On édite le /etc/default/saslauthd :
cd /etc/default mv saslauthd saslauthd-orig wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/saslauthd
On crée le répertoire du socket et on lui donne les droits adaptés :
mkdir /var/spool/postfix/var/ mkdir /var/spool/postfix/var/run/ mkdir /var/spool/postfix/var/run/saslauthd chown -R root:sasl /var/spool/postfix/var/ chmod 710 /var/spool/postfix/var/run/saslauthd adduser postfix sasl
On crée un lien symbolique au cas où :
ln -s /var/spool/postfix/var/run/saslauthd /var/run/saslauthd
On ajoute ceci au /etc/postfix/main.cf :
smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous smtpd_sasl_local_domain = broken_sasl_auth_clients = yes smtpd_sasl_authenticated_header = yes
On ajoute également « permit_sasl_authenticated » dans
« smtpd_recipient_restrictions » pour valider les restrictions (attention à bien
placer le paramètre exactement à l’endroit indiqué) :
..... permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, ......
On édite /etc/init.d/postfix, on recherche la variable FILES et on ajoute etc/postfix/sasl/smtpd.conf à la liste :
cd /etc/init.d/ sed -i 's/nss_mdns.config/nss_mdns.config etc\/postfix\/sasl\/smtpd.conf/' postfix
On redémarre Postfix et Saslauthd :
/etc/init.d/postfix restart /etc/init.d/saslauthd restart
On vérifie que les paramètres sont bien passés au daemon Saslauthd :
ps waux | grep saslauthd
doit donner plusieurs lignes avec comme paramètre :
/usr/sbin/saslauthd -a pam -c -r -m /var/spool/postfix/var/run/saslauthd -n 5
Note : Cette section SASL etant souvent sujette à problème lors de la configuration, on trouvera ici la totalité des commandes à lancer en une fois pour tout configurer :
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. (payant).
On édite la configuration de ssl pour pouvoir signer des certificats sur 10 ans, au lieu d’1 an par défaut :
vi /etc/ssl/openssl.cnf on change la ligne default_days en
default_days = 3650
On crée le Certificat Racine :
cd ~ /usr/lib/ssl/misc/CA.pl -newca
on entre les parametres requis, on choisis un pass phrase de son choix et on laisse « challenge password » vide.
CA certificate filename (or enter to create) Making CA certificate ... Generating a 1024 bit RSA private key .......++ .........................................++ writing new private key to './demoCA/private/cakey.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. Country Name (2 letter code) [AU]:FR State or Province Name (full name) [Some-State]:Paris Locality Name (eg, city) []:Paris Organization Name (eg, company) [Internet Widgits Pty Ltd]:Starbridge Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:starbridge.org Email Address []:tonio@starbridge.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: Using configuration from /usr/lib/ssl/openssl.cnf Enter pass phrase for ./demoCA/private/cakey.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 84:7c:ce:d2:f7:cf:df:6c Validity Not Before: Nov 13 16:44:33 2007 GMT Not After : Nov 12 16:44:33 2010 GMT Subject: countryName = FR stateOrProvinceName = Paris organizationName = Starbridge commonName = starbridge.org emailAddress = tonio@starbridge.org X509v3 extensions: X509v3 Subject Key Identifier: B9:04:A3:81:E5:5D:D6:82:72:F4:6E:0C:FB:3F:E2:62:1B:EF:B9:57 X509v3 Authority Key Identifier: keyid:B9:04:A3:81:E5:5D:D6:82:72:F4:6E:0C:FB:3F:E2:62:1B:EF:B9:57 DirName:/C=FR/ST=Paris/O=Starbridge/CN=starbridge.org/emailAddress=tonio@starbridge.org serial:84:7C:CE:D2:F7:CF:DF:6C X509v3 Basic Constraints: CA:TRUE Certificate is to be certified until Nov 12 16:44:33 2010 GMT (1095 days) Write out database with 1 new entries Data Base Updated
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 certificat public non signé.
mkdir ~/CERT cd ~/CERT openssl req -new -nodes -keyout starbridge-key.pem -out starbridge-req.pem -days 3650
et on entre les paramètres comme ci dessous :
Generating a 1024 bit RSA private key .............++ .............++ writing new private key to 'starbridge-key.pem' You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. Country Name (2 letter code) [AU]:FR State or Province Name (full name) [Some-State]:Paris Locality Name (eg, city) []:Paris Organization Name (eg, company) [Internet Widgits Pty Ltd]:Starbridge Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:spike.starbridge.org Email Address []:tonio@starbridge.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
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.
On signe maintenant ce certificat public avec le certificat racine :
cd ~ openssl ca -out CERT/starbridge-cert.pem -infiles CERT/starbridge-req.pem
Voici la sortie de la signature :
Using configuration from /usr/lib/ssl/openssl.cnf Enter pass phrase for ./demoCA/private/cakey.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 84:7c:ce:d2:f7:cf:df:6d Validity Not Before: Nov 13 16:51:32 2007 GMT Not After : Nov 10 16:51:32 2017 GMT Subject: countryName = FR stateOrProvinceName = Paris organizationName = Starbridge commonName = spike.starbridge.org emailAddress = tonio@starbridge.org X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 05:2A:A9:90:6F:2A:80:F7:E3:EF:2B:F9:44:9D:8E:CF:C3:16:18:EF X509v3 Authority Key Identifier: keyid:B9:04:A3:81:E5:5D:D6:82:72:F4:6E:0C:FB:3F:E2:62:1B:EF:B9:57 Certificate is to be certified until Nov 10 16:51:32 2017 GMT (3650 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated
On copie maintenant le certificat et la clé dans postfix :
mkdir /etc/postfix/tls cp demoCA/cacert.pem CERT/starbridge-key.pem CERT/starbridge-cert.pem /etc/postfix/tls/ chmod 644 /etc/postfix/tls/starbridge-cert.pem /etc/postfix/tls/cacert.pem chmod 400 /etc/postfix/tls/starbridge-key.pem chmod 400 ~/CERT/*
On ajoute ceci au /etc/postfix/main.cf :
smtp_tls_CAfile = /etc/postfix/tls/cacert.pem
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_tls_session_cache
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_key_file = /etc/postfix/tls/starbridge-key.pem
smtpd_tls_cert_file = /etc/postfix/tls/starbridge-cert.pem
smtpd_tls_CAfile = /etc/postfix/tls/cacert.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_tls_session_cache
tls_random_source = dev:/dev/urandom
Note : Pour un Postfix inférieur à la version 2.5 (dans le cadre d’une installation dans Etch par exemple), il faut modifier les 2 paramètres btree :$data_directory… par btree :$queue_directory…
On redémarre Postfix :
/etc/init.d/postfix restart
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).
Note : si l’on a installé Dovecot il faudra tester le TLS à l’étape suivante
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.
IMAPD-SSL :
Note : si on a choisi Dovecot suivre ce lien :
Dovecot et ne pas suivre cette section :
Maintenant que l’on a un certificat signé on va remplacer le certificat par défaut de courier-imap-ssl par le notre :
cd ~/CERT cat starbridge-key.pem starbridge-cert.pem >certkey.pem cp certkey.pem starbridge-certkey.pem openssl gendh >> starbridge-certkey.pem chmod 400 ~/CERT/* cp starbridge-certkey.pem /etc/courier/ chmod 600 /etc/courier/starbridge-certkey.pem chown daemon /etc/courier/starbridge-certkey.pem
vi /etc/courier/imapd-ssl
et on modifie la ligne :
TLS_CERTFILE=/etc/courier/imapd.pem
par
TLS_CERTFILE=/etc/courier/starbridge-certkey.pem
Enfin on rédémarre imapd-ssl :
/etc/init.d/courier-imap-ssl stop /etc/init.d/courier-imap-ssl start
On teste depuis un client mail en paramétrant un connection SSL pour l’IMAP (port 993)
Installation PostfixAdmin
Pour faciliter la création des users et la gestion des boîtes et des comptes, on utilise Postfixadmin.
Nous utiliserons la version 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 :
a2enmod ssl
Puis on crée le virtual host :
vi /etc/apache2/sites-available/ssl
Et on colle :
NameVirtualHost *:443 <VirtualHost *:443> ServerAdmin webmaster@starbridge.org ServerName www.starbridge.org DocumentRoot /var/www/ <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/> Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny allow from all # This directive allows us to have apache2's default start page # in /apache2-default/, but still have / go to the right place # Commented out for Ubuntu #RedirectMatch ^/$ /apache2-default/ </Directory> ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ <Directory "/usr/lib/cgi-bin"> AllowOverride AuthConfig Options ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> ErrorLog /var/log/apache2/error.log # Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn CustomLog /var/log/apache2/access.log combined ServerSignature On SSLEngine On SSLCertificateFile /etc/apache2/ssl/starbridge-certkey-www.pem SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown </VirtualHost>
On édite le fichier ports.conf pour activer le port 443.
Note :
dans les dernières versions d’Apache 2.2 sous Debian Lenny cette ligne est ajouté automatiquement lors de l’activation du module SSL :
vi /etc/apache2/ports.conf
et on ajoute la ligne
listen 443
puis on active le virtual host :
a2ensite ssl
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 :
cd ~/CERT openssl req -new -nodes -keyout starbridge-key-www.pem -out starbridge-req-www.pem -days 3650
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.
cd ~ openssl ca -out CERT/starbridge-cert-www.pem -infiles CERT/starbridge-req-www.pem chmod 400 ~/CERT/* cd CERT/ cat starbridge-key-www.pem starbridge-cert-www.pem >starbridge-certkey-www.pem mkdir /etc/apache2/ssl cp starbridge-certkey-www.pem /etc/apache2/ssl/ chmod 600 /etc/apache2/ssl/starbridge-certkey-www.pem chmod 400 ~/CERT/*
On redémarre Apache :
/etc/init.d/apache2 restart
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).
aptitude install subversion cd /var/www svn -r 629 co https://postfixadmin.svn.sourceforge.net/svnroot/postfixadmin/trunk postfixadmin chown -R www-data: /var/www/postfixadmin cd postfixadmin chmod 640 *.php cd /var/www/postfixadmin/admin/ chmod 640 *.php cd /var/www/postfixadmin/images/ chmod 640 *.png cd /var/www/postfixadmin/languages/ chmod 640 *.lang cd /var/www/postfixadmin/templates/ chmod 640 *.php cd /var/www/postfixadmin/users/ chmod 640 *.php cd /var/www/postfixadmin/
on remplace le config.inc.php par défaut par celui ci :
Note : Il faut remplacer toutes les entrées starbridge dans ce fichier par celles correspondantes à votre domaine. (toto est le password pour la base sql postfix et toto.com votre domaine) :
mv config.inc.php config.inc.php-orig wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/config.inc.txt mv config.inc.txt config.inc.php sed -i "s/password'] = '\*\*\*\*\*'/password'] = 'toto'/" config.inc.php sed -i 's/www.starbridge.org/www.toto.com/g' config.inc.php sed -i 's/starbridge.org/toto.com/g' config.inc.php
On sécurise ce fichier :
chown www-data: /var/www/postfixadmin/config.inc.php chmod 640 config.inc.php
On efface le fichier setup.php qui n’est pas nécessaire dans notre cas :
rm /var/www/postfixadmin/setup.php
On se connecte ensuite à l’interface :
https://www.starbridge.org/postfixadmin
(bien sur on remplace starbridge par votre domaine sinon vous vous connectez chez moi !!)
On s’identifie avec admin@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.
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.
La gestion des Quotas
On l’a vu, on a installé maildrop 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)
cd /etc/ wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/quotawarnmsg chown -R vmail: /etc/quotawarnmsg chmod 644 /etc/quotawarnmsg
Pour une explication détaillée du fonctionnement voir cet article :
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.
On vérifie qu’un fichier .maildirsize soit bien crée dans le Maildir du destinataire.
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 précise 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 :
smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_non_fqdn_sender, reject_unknown_recipient_domain, reject_invalid_helo_hostname, reject_unlisted_recipient, reject_unlisted_sender, permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_helo_hostname, reject_unauth_destination, check_client_access hash:/etc/postfix/internal_networks, check_sender_access hash:/etc/postfix/not_our_domain_as_sender, check_helo_access proxy:mysql:/etc/postfix/mysql-hello.cf, check_sender_access proxy:mysql:/etc/postfix/mysql-sender.cf, check_client_access proxy:mysql:/etc/postfix/mysql-client.cf, reject_rbl_client bl.spamcop.net, reject_rbl_client zen.spamhaus.org, permit
On le voit, on a aussi paramétré une RBL (des blacklists) qui filtre assez efficacement.
- 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. Cela permettra notamment d’attribuer un score et non pas de systématiquement refuser les messages.
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 = :
smtpd_sender_login_maps = proxy:mysql:/etc/postfix/mysql-sasl-sender-check.cf smtpd_sender_restrictions = reject_authenticated_sender_login_mismatch smtpd_reject_unlisted_sender = yes smtpd_restriction_classes = has_our_domain_as_sender has_our_domain_as_sender = check_sender_access hash:/etc/postfix/our_domain_as_sender, reject
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 :
cd /etc/postfix/ wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/internal_networks
On édite ce fichier et on spécifie son réseau local et son adresse publique à l’intérieur :
10.0.0 has_our_domain_as_sender
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.
cd /etc/postfix/
wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/mysql-hello.cf wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/mysql-sender.cf wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/mysql-client.cf wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/mysql-sasl-sender-check.cf wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/our_domain_as_sender wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/not_our_domain_as_sender
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/our_domain_as_sender : 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/not_our_domain_as_sender : Il sert à spécifier les domaines refusés comme MAIL FROM pour les users externes non authentifiés (c’est à dire quelqu’un de l’extérieur qui nous envoie un mail).
- Si il spécifie un de nos domaines en MAIL FROM, le message sera refusé.
On intègre son domaine dans ces fichiers (ici c’est toto.com). On ajoutera les autres domaines gérés par le serveur si nécessaire :
sed -i 's/starbridge.org/toto.com/g' /etc/postfix/our_domain_as_sender /etc/postfix/not_our_domain_as_sender
On postmape les fichiers qui le nécessitent :
postmap /etc/postfix/our_domain_as_sender postmap /etc/postfix/not_our_domain_as_sender postmap /etc/postfix/internal_networks
On modifie le password des fichiers des lookup (la commande sed permet de specifier votre password d’accès à la base, dans l’exemple ici c’est toto) :
sed -i 's/\*\*\*\*/toto/g' mysql-*
Et on sécurise les fichiers de lookup :
chown -R root:postfix /etc/postfix/mysql-* chmod 640 /etc/postfix/mysql-*
On crée les tables en question :
Evidemment on modifie la commande sed pour inclure son domaine. Ici c’est toto.com
cd ~ wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/postfix_access.sql sed -i 's/starbridge.org/toto.com/g' postfix_access.sql mysql -u root -p < postfix_access.sql
On relance postfix
postfix reload
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 :
cd /etc/postfix/ wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/body_checks.cf wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/header_checks.cf wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/mime_headers_checks.cf
On édite le /etc/postfix/main.cf et on ajoute les lignes :
header_checks = regexp:/etc/postfix/header_checks.cf body_checks = regexp:/etc/postfix/body_checks.cf mime_header_checks = regexp:/etc/postfix/mime_headers_checks.cf
On relance postfix :
postfix reload
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 :
aptitude install libdb4.6-dev file libcompress-bzip2-perl nomarch arc p7zip-full arj zoo lzop tnef pax cabextract
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
aptitude install libarchive-tar-perl libarchive-zip-perl libberkeleydb-perl libcompress-zlib-perl libconvert-tnef-perl libconvert-uulib-perl libdigest-md5-perl libio-stringy-perl libmailtools-perl libmime-base64-perl libmime-perl libnet-perl perl-modules libnet-server-perl libtime-hires-perl libunix-syslog-perl libmail-dkim-perl liblog-log4perl-perl liblog-dispatch-perl libgetopt-argvfile-perl libconvert-binhex-perl libmail-sender-perl
Note : sous etch, libmail-dkim-perl est trop ancien pour tourner avec amavisd. Il faudra l’installer depuis 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
aptitude install libhtml-parser-perl libnet-dns-resolver-programmable-perl liberror-perl libmail-spf-perl libmail-sendmail-perl libnetaddr-ip-perl libdbi-perl libdbd-mysql-perl liblocale-subcountry-perl libwww-perl libimage-base-bundle-perl libimage-base-perl libimage-info-perl libnet-cidr-lite-perl libmime-encwords-perl libemail-valid-perl libencode-detect-perl
Note : sous etch, libmime-encwords-perl et libmail-spf-perl n’existent pas. Il faudra les installer par cpan.
Installation Spamassassin
On installe SA depuis les sources :
cd ~ wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/Mail-SpamAssassin-3.2.5.tar.gz tar xvzf Mail-SpamAssassin-3.2.5.tar.gz cd Mail-SpamAssassin-3.2.5 perl Makefile.PL PREFIX=/usr make make install
Installation Amavisd
Télécharger les sources d’amavisd :
cd ~ wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/amavisd-new-2.6.4.tar.gz tar xvzf amavisd-new-2.6.4.tar.gz cd amavisd-new-2.6.4
Créer le user et le groupe amavis :
groupadd -g 1002 amavis useradd -g amavis -u 1002 amavis -d /var/amavis -m
Créer les sous répertoires dans le home d’amavis :
mkdir /var/amavis/tmp /var/amavis/var /var/amavis/db /var/amavis/home chown -R amavis: /var/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 :
tmpfs /var/amavis/db tmpfs rw,size=10m,mode=700,uid=amavis,gid=amavis 0 0 tmpfs /var/amavis/tmp tmpfs rw,size=150m,mode=700,uid=amavis,gid=amavis 0 0
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 :
mount /var/amavis/tmp mount /var/amavis/db
on vérifie par un
mount -l
Copier les exécutables :
cp amavisd-nanny /usr/sbin/ cd /usr/sbin/ wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/amavisd chown root /usr/sbin/amavisd* chmod 755 /usr/sbin/amavisd*
Copier les fichiers de conf :
cd /etc/ wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/amavisd.conf chown root:amavis /etc/amavisd.conf chmod 640 /etc/amavisd.conf mkdir /etc/amavisd cd /etc/amavisd wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/amavisd.domains wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/sender_scores_sitewide
Créer la quarantaine :
mkdir /var/virusmails chown amavis:amavis /var/virusmails chmod 750 /var/virusmails
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,
et son hostname avec $myhostname
Pour info, voici les principaux paramètres qui ont été modifiés dans le fichier fourni.
$daemon_user = 'amavis';
$daemon_group = 'amavis';
$myhostname = 'spike.starbridge.org';
$MYHOME = '/var/amavis';
$log_level = 2;
@local_domains_maps = ( read_hash("/etc/amavisd/amavisd.domains") );
@mynetworks = qw( 127.0.0.0/8 [::1] [FE80::]/10 [FEC0::]/10
10.0.0.0/24 );
$virus_admin = "admin\@$mydomain"; # notifications recip
$banned_admin = "admin\@$mydomain";
$inet_socket_port = [10024, 10026];
$notify_method = 'smtp:[127.0.0.1]:10029';
$forward_method = 'smtp:[127.0.0.1]:10025';
Il faut ensuite editer le fichier /etc/amavisd/amavisd.domains pour preciser son domaine. Les domaines supplémentaires s’ajoutent en respectant le meme 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) :
@bypass_virus_checks_maps = (1);
Démarrer amavisd en console pour voir si il manque des prérequis :
/usr/sbin/amavisd debug
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 :
smtp-amavis unix - - y - 2 smtp -o smtp_data_done_timeout=1200 -o smtp_send_xforward_command=yes -o disable_dns_lookups=yes -o max_use=20 127.0.0.1:10025 inet n - y - - 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 smtpd_data_restrictions=reject_unauth_pipelining -o smtpd_end_of_data_restrictions= -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 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_address_mappings,no_header_body_checks,no_unknown_recipient_checks -o local_header_rewrite_clients= # Amavisd Notification only (pour eviter le no_address_mapping) 127.0.0.1:10029 inet n - y - - smtpd -o content_filter= -o smtpd_delay_reject=no -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 smtpd_data_restrictions=reject_unauth_pipelining -o smtpd_end_of_data_restrictions= -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 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks -o local_header_rewrite_clients=
et on modifie toujours dans le master.cf la section sur le port 587 comme ceci :
587 inet n - - - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_etrn_restrictions=reject -o content_filter=smtp-amavis:[127.0.0.1]:10026 -o smtpd_client_restrictions=permit_sasl_authenticated,reject
(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 tres précisement de cette facon. Voir l’article suivant sur le sujet.
On édite maintenant le main.cf et on ajoute :
content_filter = smtp-amavis:[127.0.0.1]:10024
Relancer postfix :
postfix reload
Surveiller les logs :
tail -f /var/log/mail.log
Si tout est ok, lancer à nouveau amavisd debug
/usr/sbin/amavisd debug
et taper en console :
telnet 127.0.0.1 10024
Il doit répondre :
Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. 220 [127.0.0.1] ESMTP amavisd-new service ready
quit pour sortir
Pareil pour tester le retour de Postfix :
telnet 127.0.0.1 10025
Il doit répondre un truc du style :
Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. 220 spike.starbridge.org ESMTP Postfix (Debian/GNU)
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) :
---> telnet localhost 10024 220 [127.0.0.1] ESMTP amavisd-new service ready ---> HELO localhost 250 [127.0.0.1] ---> MAIL FROM: <> 250 2.1.0 Sender <> OK ---> RCPT TO: <admin@starbridge.org> 250 2.1.5 Recipient <admin@starbridge.org> OK ---> DATA 354 End data with <CR><LF>.<CR><LF> ---> From: virus-tester ---> To: undisclosed-recipients:; ---> Subject: amavisd test - simple - no spam test pattern ---> This is a simple test message from the amavisd-new test-messages. ---> . 250 2.6.0 Ok, id=30897-02, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 079474CE44 ---> QUIT 221 2.0.0 [127.0.0.1] amavisd-new closing transmission channel
L’aller-retour postfix/amavisd fonctionne bien !
(on peut arrêter le debug d’amavisd par un CTRL + C)
Installation Clamav
Prérequis :
aptitude install zlib1g zlib1g-dev libgmpxx4ldbl libgmp3-dev
Note : Sous Etch, aptitude signale qu’aucun paquet ne correspond à « libgmpxx4ldbl ». C’est normal, il s’agit d’un paquet Lenny. Ne pas en tenir compte
On compile depuis les sources :
cd ~ wget http://downloads.sourceforge.net/project/clamav/clamav/0.95.3/clamav-0.95.3.tar.gz?use_mirror=freefr tar xvzf clamav-0.95.3.tar.gz cd clamav-0.95.3 ./configure --prefix=/usr --sysconfdir=/etc --with-user=amavis --with-group=amavis --with-dbdir=/var/lib/clamav make make install ldconfig mkdir /var/run/clamav chown -R amavis: /var/run/clamav chmod -R 750 /var/run/clamav mkdir /var/lib/clamav chown -R amavis: /var/lib/clamav chmod -R 770 /var/lib/clamav
On met a jour les fichiers de configuration :
cd /etc mv clamd.conf clamd.conf.orig mv freshclam.conf freshclam.conf.orig wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/clamd.conf wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/freshclam.conf
On modifie la crontab de l’utilisateur amavis pour planifier la mise à jour de la base antivirale :
crontab -e -u amavis
et on ajoute :
0 0,6,12,18 * * * /usr/bin/freshclam
Créer :
mkdir /var/log/clamav chown -R amavis:amavis /var/log/clamav
Créer un fichier /etc/init.d/clamd
cd /etc/init.d/ wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/clamd chmod 755 /etc/init.d/clamd update-rc.d clamd defaults
insserv -v /etc/init.d/clamd
On fait la mise à jour de la base virale:
freshclam
On vérifie que les fichiers soient bien présents dans le répertoire :
ls -la /var/lib/clamav
On lance clamd :
/etc/init.d/clamd start
Et on vérifie les logs :
tail -f /var/log/clamav/clamd.log
Et on vérifie bien que Clam tourne :
ps aux | grep clam
On teste le fonctionnement (le dossier « test » est dans le répertoire clamav-0.95.3) :
cd /root/clamav-0.95.3/test/ clamdscan -l scan.txt clam-x.yz
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
aptitude install curl rsync cd /usr/sbin wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/clamav-unofficial-sigs.sh chmod 755 clamav-unofficial-sigs.sh cd /etc/ wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/clamav-unofficial-sigs.conf mkdir /var/lib/unofficial-clamav-sigs chown -R amavis: /var/lib/unofficial-clamav-sigs
On lance le script :
su -c '/usr/sbin/clamav-unofficial-sigs.sh' amavis
On vérifie que les fichiers sont bien présents dans le répertoire de Clam :
ls -l /var/lib/clamav
On doit trouver les fichiers suivants :
antispam.ndb antispam.ndb.gz daily.cvd honeynet.hdb honeynet.hdb.gz junk.ndb last-mbl-update.txt lott.ndb main.cvd mbl.db mirrors.dat MSRBL-Images.hdb MSRBL-SPAM.ndb sanesecurity-lott.ndb phish.ndb rogue.hdb scam.ndb securiteinfo.hdb securiteinfo.hdb.gz spamimg.hdb spam.ldb spear.ndb vx.hdb vx.hdb.gz
On crée une tache cron pour mettre à jour ces fichiers :
crontab -e -u amavis 5 */4 * * * /usr/sbin/clamav-unofficial-sigs.sh
Installation de ClamdMon pour la surveillance du demon clam :
installer le script de surveillance clamdmon :
cd ~ wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/clamdmon-1.0.tar.gz tar xvzf clamdmon-1.0.tar.gz cd clamdmon-1.0 make make install
puis on colle :
*/5 * * * * /usr/sbin/clamdmon.sh
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 :
cd /etc/mail/spamassassin/ mv local.cf local.cf-orig wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/local.cf
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 :
chown amavis: /etc/mail/spamassassin/local.cf chmod 640 /etc/mail/spamassassin/local.cf
SA fonctionne sur 2 types de tests :
- Heuristiques (ensemble de règles)
- Bayesiens (apprentissage et statistiques)
Pour le filtre bayesien, on va installer directement la base dans une base Mysql. Les performances sont supérieures et on s’affranchit de diverses
limitations :
On crée la base :
mysql -u root -p create database spam; GRANT SELECT, INSERT, UPDATE, DELETE ON spam.* TO 'spam'@'localhost' IDENTIFIED BY '*****'; FLUSH PRIVILEGES; quit
On modifie le password dans le local.cf à l’identique (ici votre password serait toto) :
sed -i 's/\*\*\*\*\*\*/toto/g' /etc/mail/spamassassin/local.cf
on importe la base sql :
wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/bayes_awl.sql wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/gtube.txt mysql -u root -p spam < bayes_awl.sql
On initialise la base :
su amavis -c 'sa-learn -D --spam gtube.txt'
On peut vérifier avec phpmyadmin que la base s’est bien remplie.
Pour améliorer les performances, on a désactivé le « opportunistic (automatic) Bayes auto-expiry » en spécifiant « bayes_auto_expire 0″ dans /etc/mail/spamassassin/local.cf.
Il faut donc créer une tache cron quotidienne pour effectuer l’expiration :
Un crontab de l’user amavis fera l’affaire :
crontab -e -u amavis
et on ajoute
16 3 * * * /usr/bin/sa-learn --sync --force-expire
On a activé l’Auto-Whitelist dans SA. Contrairement a Bayes, l’AWL n’a pas de mécanisme d’expiration qui évite à la base de grossir indéfiniment.
Pour cela on crée un script qui nettoira les tables régulierement :
mkdir /etc/caremail cd /etc/caremail wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/SA-awl-purgesql
puis on crée une tache cron
crontab -e -u amavis
et on ajoute :
25 4 * * * /usr/bin/mysql -u spam -p'******' spam < /etc/caremail/SA-awl-purgesql
Mise à jour des Rules de SA, ajout des Rules SARE et Starbridge :
On va mettre tout de suite à jour les règles de SA et en installer de nouvelles :
On lance l’update des règles de SA :
sa-update -D
Cela aura pour effet de télécharger les règles à jour. Elles seront installés dans un dossier différent des règles d’origine : /var/lib/spamassassin/3.002005. (ce qui correspond à la version 3.2.5 de SA)
SA considèrera désormais ce dossier comme celui par défaut.
On vérifie que tout soit OK :
su -c "spamassassin -D --lint" amavis
Il ne doit pas il y a voir de message d’erreur à la fin de l’exécution.
On prépare l’installation des rules SARE et Starbridge :
cd /etc/mail/spamassassin/ wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/GPG.KEY wget http://www.starbridge.org/updates/starbridge/GPG-eole.KEY sa-update --import GPG.KEY sa-update --import GPG-eole.KEY
wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/sare-sa-update-channels.txt
On pourra modifier ce fichier pour ne sélectionner que les RULES que l’on désire.
On met à jour :
sa-update -D --channelfile /etc/mail/spamassassin/sare-sa-update-channels.txt --gpgkey 856AA88A sa-update -D --gpgkey C0FB2D51 --channel updates.starbridge.org
Les fichiers seront placés dans /var/lib/spamassassin :
ls -la /var/lib/spamassassin/3.002005/
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 etre sur qu’elles soient présentent dans ce sous répertoire
On vérifie à nouveau que tout soit OK :
su -c "spamassassin -D --lint" amavis
Compilation des Rulesets
Depuis la version 3.2, SA est un peu plus lent dans le traitement des messages. En revanche une nouvelle fonctionnalité est apparue : la compilation des règles.
Pour celles qui le permettent, cela accélère sensiblement le traitement. Pour cela il faut installer au préalable le paquet re2c :
aptitude install re2c
on lance ensuite la commande
sa-compile -D
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 :
loadplugin Mail::SpamAssassin::Plugin::Rule2XSBody
on vérifie que tout soit ok :
su -c 'spamassassin -D --lint' amavis
Pour une mise à jour des rules et une compilation régulière (1 fois par jour maximum) on crée une tache cron spécifique :
cd /etc/caremail wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/sa-update.sh wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/sa-compile chmod 755 /etc/caremail/sa-compile chmod 755 /etc/caremail/sa-update.sh
crontab -e
et on ajoute la ligne :
15 2 * * * /etc/caremail/sa-update.sh
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.
Activation du plugin DKIM
Cela permet d’effectuer les vérifications DKIM
Editer le fichier /etc/mail/spamassassin/v312.pre
vi /etc/mail/spamassassin/v312.pre
et décommenter la ligne :
loadplugin Mail::SpamAssassin::Plugin::DKIM
- SA est prêt et fonctionnel !!
On démarre en debug-sa :
/usr/sbin/amavisd debug-sa
on doit trouver dans la liste ceci :
dbg: bayes: using username: amavis [30527] dbg: bayes: database connection established [30527] dbg: bayes: found bayes db version 3 [30527] dbg: bayes: Using userid: 1 [30527] dbg: bayes: not available for scanning, only 1 spam(s) in bayes DB < 200
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.
Par défaut Amavisd mets les spams en quarantaine, mais ce n’est pas le comportement que nous désirons.
Le amavisd.conf fourni dans ce tuto intègre les modifications nécessaires.
Pour infos voici les paramètres modifiés :
$sa_tag_level_deflt = -9999.9; # add spam info headers if at, or above that level $sa_tag2_level_deflt = 4.3; # add 'spam detected' headers at that level $sa_kill_level_deflt = 9999.9; # triggers spam evasive actions $sa_mail_body_size_limit = 400*1024; # don't waste time on SA if mail is larger $sa_spam_subject_tag = '***SPAM_SCORE_*** '; $sa_spam_report_header = 1; $final_spam_destiny = D_PASS;
Avec cette modification, on dit à amavisd de laisser passer le spam mais de le tagguer dans le header du mail. La limite Spam est fixée à un score de 4.3
On traitera le mail plus loin par Maildrop.
On crée un fichier /etc/init.d/amavis :
cd /etc/init.d/ wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/amavis chmod 755 /etc/init.d/amavis update-rc.d amavis defaults
pour la version testing utiliser à la place de update-rc.d :
insserv -v /etc/init.d/amavis
/etc/init.d/amavis start
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 paramètre Maildrop pour déposer le courier détecté comme spam dans le dossier spam de chaque utilisateur :
On édite /home/virtual/.mailfilter et on le modifie comme ceci :
#logfile "/home/virtual/.maildrop.log"
`[ -d $DEFAULT ] || (maildirmake $DEFAULT && maildirmake -f Spam $DEFAULT && maildirmake -f Sent $DEFAULT && maildirmake -f SpamToLearn $DEFAULT && maildirmake -f SpamFalse $DEFAULT)`
EXTENSION="$1"
if ( /^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*/ )
{
log "--> X-Spam-toohigh."
exception {
to /home/virtual/spamtrap@starbridge.org/
}
}
if ( /^X-Spam-Flag: YES/ )
{
log "--> X-Spam-Flag-ed."
to $HOME/$DEFAULT.Spam
}
if ( $EXTENSION eq "spam" )
{
log "--> spam-extension."
to $HOME/$DEFAULT.Spam
}
`test -r $HOME/$DEFAULT.mailfilter`
if( $RETURNCODE == 0 )
{
log "(==) Including $HOME/$DEFAULT.mailfilter"
exception {
include $HOME/$DEFAULT.mailfilter
}
}
Explications :
Le premier If permet d’envoyer le spam dont le score est au dessus de 10 dans une boite spécifique spamtrap@starbridge.org qu’il faut créer (on peut utiliser postfixadmin pour ca).
Le deuxième If permet d’envoyer le spam en dessous de 10 dans le dossier Spam de l’utilisateur.
Le 3eme permet d’intercepter les mails avec l’extension +spam, qui peuvent être utilisés par amavisd (pour Mailzu par exemple)
- Pour améliorer l’apprentissage, on crée une tache qui scanne la boîte spamtrap et les 2 dossiers d’apprentissage SpamToLearn et SpamFalse des boîtes des utilisateurs (Dossiers crées automatiquement par maildrop à la première livraison) puis envoie leur contenu vers le filtre bayesien :
On crée d’abord deux répertoires spéciaux de transit :
mkdir /home/spamtrap chown amavis: /home/spamtrap chmod 777 /home/spamtrap mkdir /home/hamtrap chown amavis: /home/hamtrap chmod 777 /home/hamtrap
on crée un fichier /etc/caremail/sa-learn :
cd /etc/caremail/ wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/sa-learn chmod 755 /etc/caremail/sa-learn
On crée une tache cron qu’on lance par root : (une fois par jour ou plus suivant la puissance de la machine, cette tache étant très gourmande en ressources)
crontab -e
et on ajoute (on change la fréquence si nécessaire) :
30 3,10,15,22 * * * /etc/caremail/sa-learn
Tout sera automatique. 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 et en fera l’apprentissage soit comme spam soit comme ham (non spam).
Attention : TOUS les mails déposés dans les dossiers SpamTolearn et SpamFalse sont déplacés c’est à dire qu’il seront EFFACES de ces dossiers.
Par sécurité on peut conserver les mails de la boite spamtrap (non consultables par les utilisateurs) un certain temps. Pour cela il suffira de changer les 2 premières lignes en copie au lieu d’un déplacement (cp). On verra plus loin pour un script de nettoyage basé sur l’âge des fichiers. On peut également enlever le -D des 2 lignes sa-learn pour limiter la sortie du script (debug). Cron envoie un mail à l’exécution de la commande, contenant la sortie.
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) :
@av_scanners = (
# ### http://www.clamav.net/
['ClamAV-clamd',
\&ask_daemon, ["CONTSCAN {}\n", "/var/run/clamav/clamd.ctl"],
qr/\bOK$/, qr/\bFOUND$/,
qr/^.*?: (?!Infected Archive)(.*) FOUND$/m ],
);
@av_scanners_backup = (
### http://www.clamav.net/ - backs up clamd or Mail::ClamAV
['ClamAV-clamscan', 'clamscan',
"--stdout --no-summary -r --tempdir=$TEMPBASE {}",
[0], qr/:.*\sFOUND$/, qr/^.*?: (?!Infected Archive)(.*) FOUND$/m ],
);
1; # insure a defined return
Pour activer Clam on commente au début du fichier :
@bypass_virus_checks_maps = (1);
On relance amavisd :
/etc/init.d/amavis stop && /etc/init.d/amavis start
L’antivirus est chargé.
On crée l’alias email : virusalert@starbridge.org vers admin@starbridge.org.
On teste le fonctionnement :
--> telnet 127.0.0.1 10024 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. 220 [127.0.0.1] ESMTP amavisd-new service ready --> MAIL FROM:<test@example.com> 250 2.1.0 Sender test@example.com OK --> RCPT TO:<postmaster> 250 2.1.5 Recipient postmaster OK --> DATA 354 End data with <CR><LF>.<CR><LF> --> Subject: test2 - virus test pattern --> --> X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* --> . --> QUIT 221 2.0.0 [127.0.0.1] (amavisd) closing transmission channel Connection closed by foreign host.
On doit voir dans les logs :
Blocked INFECTED (Eicar-Test-Signature)
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.
Maintenance de Clam et de Spamassassin :
Il faut penser à purger régulièrement le contenu de la boite spamtrap et la quarantaine de clam, c’est à dire le dossier /home/virtual/spamtrap@starbridge.org/new/. et le /var/virusmails.
Pour cela on peut utiliser un outil du genre tmpreaper.
Il se configure très simplement dans /etc/tmpreaper.conf
On modifie la ligne suivante comme ceci :
TMPREAPER_DIRS='/tmp/. /var/virusmails/. /home/virtual/spamtrap@starbridge.org/new/.'
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.
cd ~ wget http://downloads.sourceforge.net/project/dspam/dspam/dspam-3.9.0-BETA4/dspam-3.9.0-BETA4.tar.gz?use_mirror=freefr tar xvzf dspam-3.9.0-BETA4.tar.gz cd dspam-3.9.0-BETA4 ./autogen.sh ./configure --prefix=/usr --sysconfdir=/etc --with-dspam-home=/var/amavis/dspam --without-delivery-agent --with-storage-driver=mysql_drv --with-mysql-includes=/usr/include/mysql make make install
Créer la base sql :
mysql -u root -p create database dspam; GRANT SELECT, INSERT, UPDATE, DELETE ON dspam.* TO 'dspam'@'localhost' IDENTIFIED BY '******'; FLUSH PRIVILEGES; quit
On importe la base sql :
cd ~ wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/mysql_objects-4.1.sql mysql -u root -p dspam < mysql_objects-4.1.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) :
cd /etc/ mv dspam.conf dspam.conf-orig wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/dspam.conf sed -i 's/\*\*\*\*\*\*/toto/g' dspam.conf
Modifier les droits sur les exécutables (même user qu’amavisd) et le
dspam.conf
chown amavis: /usr/bin/dspam* chown amavis: /etc/dspam.conf chmod 750 /usr/bin/dspam* chmod 640 /etc/dspam.conf
Créer le répertoire de dspam dans le home d’amavisd :
mkdir /var/amavis/dspam chown -R amavis: /var/amavis/dspam
on edite le /etc/amavisd.conf et on ajoute le bloc suivant juste avant la ligne « $sa_tag_level_deflt »
$dspam = 'dspam'; @spam_scanners = ( ['SpamAssassin', 'Amavis::SpamControl::SpamAssassin'], ['DSPAM', 'Amavis::SpamControl::ExtProg', $dspam, [ qw(--stdout --classify --deliver=innocent,spam --mode=tum --tokenizer=chained,noise --user), $daemon_user ], ], );
relancer amavisd :
/etc/init.d/amavis restart
On vérifie les logs. On doit voir :
Found spam scanner DSPAM at /usr/bin/dspam
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 en dur dans le binaire d’amavisd : 3.8 pour un spam, 0.1 pour un ham. ( Il vaut mieux attendre quelques jours après l’installation de dspam afin de le laisser apprendre sur un volume de mail conséquent, avant de modifier ces valeurs
Dès que l’on estime que les tags sont pertinents dans les headers (c’est à dire que Dspam détecte bien du spam et du non-spam (ham) correctement), on pourra les ajuster.
On crée les taches de maintenance de dspam :
On crée un fichier /etc/caremail/dspam-purge-4.1.sql
cd /etc/caremail/ wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/dspam-purge-4.1.sql
Puis on crée une tache cron avec le user amavis :
crontab -e -u amavis
et on ajoute :
14 2 * * * /usr/bin/mysql -u dspam -p'******' dspam < /etc/caremail/dspam-purge-4.1.sql
On crée une tache cron de purge des log avec le user amavis :
crontab -e -u amavis
on ajoute :
3 3 1 * * /usr/bin/dspam_logrotate -a 30 -v -d /var/amavis/dspam
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 SQL
Maintenant que l’on a un système fonctionnel articulé autour d’Amavis, on peut ajouter des 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…)
Pour cela il faut que l’on associe Amavisd à une base SQL.
On crée la base :
mysql -u root -p create database amavis; GRANT SELECT, INSERT, UPDATE, DELETE ON amavis.* TO 'amavis'@'localhost' IDENTIFIED BY '******'; FLUSH PRIVILEGES; quit
On importe la base sql :
cd /root wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/amavis.sql mysql -u root -p amavis < /root/amavis.sql
On édite amavisd.conf et on ajoute/modifie les lignes suivantes :
@storage_sql_dsn = ( ['DBI:mysql:database=amavis;host=127.0.0.1;port=3306', 'amavis', '****'] ); @lookup_sql_dsn = @storage_sql_dsn;
on redémarre Amavisd et on teste l’envoi/réception d’un mail. On vérifie les logs.
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 :
INSERT INTO `mailaddr` (`id`, `priority`, `email`) VALUES (1, 5, 'toto@toto.com'); INSERT INTO `policy` (`id`, `policy_name`, `virus_lover`, `spam_lover`, `banned_files_lover`, `bad_header_lover`, `bypass_virus_checks`, `bypass_spam_checks`, `bypass_banned_checks`, `bypass_header_checks`, `spam_modifies_subj`, `virus_quarantine_to`, `spam_quarantine_to`, `banned_quarantine_to`, `bad_header_quarantine_to`, `spam_tag_level`, `spam_tag2_level`, `spam_kill_level`, `spam_dsn_cutoff_level`, `addr_extension_virus`, `addr_extension_spam`, `addr_extension_banned`, `addr_extension_bad_header`, `warnvirusrecip`, `warnbannedrecip`, `warnbadhrecip`, `newvirus_admin`, `virus_admin`, `banned_admin`, `bad_header_admin`, `spam_admin`, `spam_subject_tag`, `spam_subject_tag2`, `message_size_limit`, `banned_rulenames`) VALUES (1, 'test@starbridge.org', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', NULL, NULL, NULL, NULL, NULL, NULL, 5, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL); INSERT INTO `users` (`id`, `priority`, `policy_id`, `email`, `fullname`, `local`) VALUES (1, 7, 1, 'test@starbridge.org', NULL, NULL); INSERT INTO `wblist` (`rid`, `sid`, `wb`) VALUES (1, 1, '15.0');
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 user @starbridge.org pour prendre en compte tous les users de celui ci.
par exemple :
INSERT INTO `users` (`id`, `priority`, `policy_id`, `email`, `fullname`, `local`) VALUES (3, 6, 4, '@starbridge.org', '', 'Y'); INSERT INTO `policy` (`id`, `policy_name`, `virus_lover`, `spam_lover`, `banned_files_lover`, `bad_header_lover`, `bypass_virus_checks`, `bypass_spam_checks`, `bypass_banned_checks`, `bypass_header_checks`, `spam_modifies_subj`, `virus_quarantine_to`, `spam_quarantine_to`, `banned_quarantine_to`, `bad_header_quarantine_to`, `clean_quarantine_to`, `other_quarantine_to`, `spam_tag_level`, `spam_tag2_level`, `spam_kill_level`, `spam_dsn_cutoff_level`, `spam_quarantine_cutoff_level`, `addr_extension_virus`, `addr_extension_spam`, `addr_extension_banned`, `addr_extension_bad_header`, `warnvirusrecip`, `warnbannedrecip`, `warnbadhrecip`, `newvirus_admin`, `virus_admin`, `banned_admin`, `bad_header_admin`, `spam_admin`, `spam_subject_tag`, `spam_subject_tag2`, `message_size_limit`, `banned_rulenames`) VALUES (4, '@starbridge.org', 'N', 'N', 'Y', 'N', 'N', 'N', 'Y', 'N', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 4.3, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL);
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 mixé 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 requetes 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 :
cd /etc/caremail/ wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/amavis-purgesql
puis on crée une tache cron
crontab -e -u amavis
et on ajoute :
14 4 * * * /usr/bin/mysql -u amavis -p'******' amavis < /etc/caremail/amavis-purgesql
Note : Pour gérer plus facilement les purges sur les serveurs à fort volume, il est conseillé de partitionner la table quarantine (l’utilisation de table partitionnée est possible à partir de MySQL 5.1). Les purges pourront alors etre effectuées en droppant les partitions correspondantes à la période donnée. Les partitions seront alimentées en utilisant le champ partition_tag comme critere.
Vérification et signatures des messages par DKIM
Cette technique a tendance a se développer, 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.
Depuis la version 2.6 d’amavisd, celui ci est capable de générer une signature DKIM
La vérification DKIM des mails recus et faites par defaut dans amavisd.
On génére la clé :
mkdir /var/amavis/dkim cd /var/amavis/dkim amavisd genrsa /var/amavis/dkim/starbridge.key.pem
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 :
dkim_key('starbridge.org', 'starbridge', '/var/amavis/dkim/starbridge.key.pem');
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 Bind gère bien sûr cet enregistrement (TXT) et il suffira de l’enregistrer dans le fichier de zone et de recharger bind.
Si les DNS sont gérés par l’hébergeur, la plupart 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 :
amavisd testkeys
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
Policyd 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.
Tous les détails de ces possibilités sont dans le README dans les sources.
Policyd 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 crée un user policyd :
groupadd -g 20002 policyd useradd -g policyd -u 20002 policyd
On compile :
cd /root wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/policyd-1.82.tar.gz tar xvzf policyd-1.82.tar.gz cd policyd-1.82 make build mkdir -p /usr/policyd cp -f stats cleanup policyd /usr/policyd
note : Ne pas executer le make install !!
Créer la base sql :
mysql -u root -p GRANT SELECT, INSERT, UPDATE, DELETE ON policyd.* TO 'policyd'@'localhost' IDENTIFIED BY '*****'; FLUSH PRIVILEGES; quit
On importe la base sql :
mysql -u root -p < DATABASE.mysql
On installe le /etc/policyd.conf et on modifie le password (ici votre password serait toto) :
cd /etc/ wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/policyd.conf sed -i 's/\*\*\*\*/toto/g' policyd.conf
Tout est documenté dans le fichier, on peut donc l’adapter à ses besoins.
On sécurise le fichier :
chmod 640 /etc/policyd.conf
On crée un fichier /etc/init.d/policyd :
cd /etc/init.d/ wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/policyd chmod 755 /etc/init.d/policyd update-rc.d policyd defaults
pour la version testing utiliser à la place de update-rc.d :
insserv -v /etc/init.d/policyd
/etc/init.d/policyd start
On vérifie qu’il tourne bien et avec le bon user :
ps aux | grep policyd policyd 2740 0.7 0.2 32896 1416 ? S 11:35 0:00 /usr/policyd/policyd -c /etc/policyd.conf
On ajoute au /etc/postfix/main.cf la commande de lancement dans le stage smtpd_end_of_data_restrictions que l’on ajoute après le smtpd_data_restrictions :
En effet c’est dans ce stage que postfix peut connaitre la taille d’un message, ce qui permet à policyd d’avoir les bonnes informations.
... smtpd_data_restrictions = reject_unauth_pipelining, permit smtpd_end_of_data_restrictions = check_policy_service inet:127.0.0.1:10031
ATTENTION : dans ce stage postfix ne transmettra pas les recipients si ceux ci sont supérieurs à 1. (pour un recipient c’est ok mais pour un mail vers de multiples destinataires, non)
On ne pourra donc pas utiliser ici les fonctionnalités de policyd qui travaillent sur le destinataire du message : RECIPIENT THROTTLING et le GREYLISTING.
C’est pour cela que les fonctions en question sont désactivées dans mon fichier de configuration.
A noter que dans le cas de figure où la surveillande du nombre d’email envoyés/recus est plus importante que celle du volume de ces derniers (taille des messages), il faudra alors placer policyd dans le smtpd_recipient_restrictions.
En effet, avec policyd dans smtpd_end_of_data_restrictions, si un user envoie un mail à destination de 1000 adresses email, le système ne verrait qu’un seul email (car le nombre de destinataire n’est pas connu), ce qui fausserait le décompte et donc les limites.
A vous de voir quel est la priorité : contrôle de la taille ou bien du nombre des messages ?
Si on souhaite placer policyd dans le smtpd_recipient_restrictions, il faudra le mettre juste avant permit_mynetworks (pour qu’il prenne en compte les mails envoyés.)
Attention : dans ce cas de figure il ne faudra pas activer les fonctions de whitelisting de policyd sous peine de créer un relais ouvert. Je déconseille ce paramétrage à moins d’avoir une bonne compréhension du fonctionnement.
On peut dans ce cas réactiver les vérifications des recipient dans policyd.conf
On relance postfix :
postfix reload
On teste en envoyant un email. On doit voir des logs policyd et le mail doit être correctement livré.
On crée un tache cron pour le script de nettoyage :
crontab -e
et on ajoute :
0 * * * * /usr/policyd/cleanup -c /etc/policyd.conf
- NOTE : en cas de défaillance de policyd, postfix ne pourra plus envoyer ni recevoir de mail. Il faut donc veiller à ce que le processus tourne en permanence. On peut créer une tache cron pour surveiller ce dernier et le relancer le cas échéant. (Si l’on ne sait pas comment faire, un module webmin permet cette surveillance).
D’expérience je n’ai jamais eu de problèmes de ce style avec policyd qui est très fiable.
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 maildrop 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 inteerface graphique pour générer le code du filtre maildrop. 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 awstats
- 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 :
cd ~ wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/amavis-logwatch-1.50.00.tgz tar xvzf amavis-logwatch-1.50.00.tgz cd amavis-logwatch-1.50.00 cp amavis-logwatch /usr/share/logwatch/scripts/services/amavis cp amavis-logwatch.conf /usr/share/logwatch/default.conf/services/amavis.conf cd .. wget http://www.majorxtrem.be/wp-content/uploads/srv_mail/postfix-logwatch-1.38.01.tgz tar xvzf postfix-logwatch-1.38.01.tgz cd postfix-logwatch-1.38.01 cp postfix-logwatch /usr/share/logwatch/scripts/services/postfix cp postfix-logwatch.conf /usr/share/logwatch/default.conf/services/postfix.conf
-awstats : Après l’installation il faut configurer awstats comme ceci :
/etc/awstats/awstats.spike.starbridge.org.conf
le nom du fichier est capital. C’est la connection sur le serveur web par le FQDN spike.starbridge.org/cgi-bin/awstats.pl qui fera fonctionner awstats dans cette configuration.
On crée un fichier /etc/cron.d/awstats :
0 5,12,20 * * * root /usr/lib/cgi-bin/awstats.pl -config=spike.starbridge.org -update
-Mailgraph : Mailgraph génére des graphiques sur l’utilisation de la messagerie
aptitude install mailgraph sed -i 's/IGNORE_LOCALHOST=false/IGNORE_LOCALHOST=true/' /etc/default/mailgraph sed -i 's!) SPAM\\!) (SPAM|SPAMMY)\\!' /usr/sbin/mailgraph /etc/init.d/mailgraph restart
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/…
- 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 :
notify_classes = 2bounce, bounce, delay, policy, protocol, resource, software
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.
ne pas oublier d’activer ce script au démarrage !
février 16th, 2010 at 14 h 38 min
Bonjour
J’aimerais quelques informations concernant ce tutoriel.
Me confirme-tu que Postfix sert de MTA, MailDrop de MDA et Courier-IMAP de gestionnaire de courrier ?
Donc dans ton cas, Postfix envoie ses e-mails reçu à MailDrop qui s’occuper de les « dropper » dans des maildir en fonction de leurs validités ( passer au préalable par SpamAssassin et ClamAv) … Ensuite, Courier-IMAP s’occupe de prendre les e-mails dans les maildir pour les données aux clients qui en font la demande ?
Merci et bonne journée
février 16th, 2010 at 16 h 34 min
Oui c’est bien ça
Postfix reçoit un mail
* si c’est un domaine externe il l’envoie au serveur smtp du domaine
* si c’est un domaine internet il l’envoie a maildrop
Maildrop place le mail dans le bon repertoire
Courrier vient lire ce dossier pour que les utilisateurs puisse consulter leurs boites
février 17th, 2010 at 8 h 58 min
Arf pourquoi mon commentaire a-t-il été supprimé ?
Pourrais-tu me confirmer que :
Postfix sert de MTA
MailDrop de MDA
Courier IMAP de gestionnaire de courrier, un serveur IMAP.
Merci
février 17th, 2010 at 8 h 59 min
Désoler je n’avais pas vu ta réponse !
Merci beaucoup
février 17th, 2010 at 10 h 32 min
Salut
Dans la doc sur starbridge, tonio utilise le gestionnaire Dovecot et non pas Courier-IMAP …
Quel est la meilleur solution ? Je sais que Dovecot est le petit nouveau sur le marché mais il a un avenir prometteur …
Merci
février 17th, 2010 at 18 h 58 min
je n’ai pas encore testé dovecot mais c’est vrai que j’en entend que du bien
février 26th, 2010 at 11 h 35 min
Hey
(juste pour voir les commentaires ! )
février 26th, 2010 at 11 h 36 min
D’accord …
Je testerai Dovecot ^^
février 26th, 2010 at 11 h 40 min
Encore une petite question …
D’où sors-tu la configuration de Courier-IMAP au lieu de Dovecot ?
Et il y a un truc que je comprends pas très bien, sur ce site : http://www.lea-linux.org/documentations/index.php/Postfix-courier-mysql-quota-spamassassin-amavis
On dirait qu’ils utilisent Courier-Imap comme tu utilise MailDrop, les fichiers de configuration sont les mêmes … Or MailDrop est un MDA :S
De l’aide ?
février 26th, 2010 at 13 h 08 min
Après m’être renseigner, je conclu que et Courier-IMAP et MailDrop sont tous deux des MDA …
Peux-u m’expliquer la différence ?
février 26th, 2010 at 20 h 57 min
le serveur smtp reçois un mail, si il est local il l’envoie à maildrop qui se charge de le déposer dans la bonne boite
courrier-imap permet à l’utilisateur de lire sa boite mail
mars 1st, 2010 at 9 h 40 min
Si je comprends bien, si un client relève son courrier via internet, c’est par Courier-IMAP qu’il passera. Courier-IMAP va directement rechercher le courrier sur POstfix. Est-ce bien cela ?
Si oui, Courier-IMAP n’a aucune sécurité vu qu’il ne passe pas par clamAv etc …
mars 1st, 2010 at 12 h 04 min
courrier va directement lire la boite et il n’y a pas besoin d’antivirus car tous les mails sont déjà passé par l’antivirus avant d’arriver dans la boite
mars 11th, 2011 at 9 h 07 min
Salut,
Génial ton tuto, très pro.
Hélas, j’ai un souci. Tout marchait très bien jusqu’à ce que je test sous thunderbird en SSL sur le port 993.
A l’envoi j’ai ce message :
« An error occurred sending mail: The mail server sent an incorrect greeting: * OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE AUTH=PLAIN ACL ACL2=UNION] Courier-IMAP ready. Copyright 1998-2010 Double Precision, Inc. See COPYING for distribution information.. »
Sur le serveur je n’ai aucun message d’erreur, voila mon mail.log :
« Mar 11 09:03:34 ks35xxxx imapd-ssl: Connection, ip=[::ffff:82.234.xxx.xxx]
Mar 11 09:03:35 ks35xxxx imapd-ssl: Disconnected, ip=[::ffff:82.234.xxx.xxx], time=1, starttls=1″
Je ne trouve pas d’où ca vient. Une idée ?
Merci d’avance.
mars 11th, 2011 at 18 h 11 min
Au temps pour moi, j’ai créé une nouvelle boite et ça marche…
mars 11th, 2011 at 18 h 11 min
Slt,
Sur Thunderbird as-tu bien choisi le port 993 en SSL
Le tuto n’est pas de moi, voir le début du post.
Regarde la dernière version : http://www.starbridge.org/spip/spip.php?article12
++
mai 20th, 2011 at 11 h 43 min
salut,
merci beaucoup pour ce tutoriel, j’ai une petite question concernant cette installation
est ce que c’est possible de ce connecter au serveur smtp avec un client hors de notre domaine (hors réseau ou se trouve le serveur)
août 25th, 2012 at 15 h 50 min
Mortel ce tuto, autant dans les explications que sur la précision des commandes, merci
Au moins on comprend ce que l’on fait en installant toutes les applis.
J’ai juste galéré pour changer le mot de passe, où j’ai du passer par la fonction crypt de PHP pour en générer un, je n’ai pas trouvé d’autre moyen.