On peut donc créer une file spéciale dans le master.cf de postfix et une règle de transport pour ces domaines, avec un débit réduit. Du moment où j’ai rechargé la configuration postfix et relancer le traitement de la file, magie, en 1 heure, les 5000 mails étaient distribués.

Pour ce faire, j’ai utilisé les documentations suivantes et adapté au contexte « configuration postfix définie dans MySQL », comme expliqué dans mes articles précédents, toujours d’actualité.

• http://linuxnet.ca/postfix/dedicated_transport.html
• http://www.zapoyok.info/2011/01/01/orangewanadoo-et-%C2%AB-too-many-connections-slow-down-ofr004_104-104-%C2%BB/

Dans master.cf

slow unix – – n – 5 smtp
-o syslog_name=postfix-slow
-o smtp_destination_concurrency_limit=3
-o slow_destination_rate_delay=1

Dans main.cf

slow_destination_recipient_limit = 20
slow_destination_concurrency_limit = 2

Dans la table « transport » niveau MySQL

Sur une conf « non SQL », il suffirait de jouer avec le fichier de transport, sans oublier le « postmap » qui va bien.
Dans mon cas, le fichier de transport est défini comme ceci : transport_maps = proxy:mysql:/etc/postfix/mysql-virtual_transports.cf.
Donc, pour ajouter une route particulière pour ces 4 domaines, on ajoute en base :

INSERT INTO `transport` (domain, transport)
VALUES (‘wanadoo.fr’,'slow’),
VALUES (‘wanadoo.com’,'slow’),
VALUES (‘orange.fr’,'slow’),
VALUES (‘orange.com’,'slow’)
;

Enfin, on relance postfix et la file d’attente avec ses X messages bloqués avec un postqueue -f.

Monitoring de la file d’attente sous Nagios

Du coup, j’ai trouvé qu’il me manquait une surveillance de la file d’attente « postqueue » d’un serveur via Nagios. Je signale simplement ce script (http://exchange.nagios.org/directory/Plugins/Email-and-Groupware/Postfix/check_postqueue-2Esh/details)
Il semble faire le boulot simplement.
A rapprocher de ce document si l’ajout d’un contrôle via NRPE ne vous est pas familier.

Et voilà.

• « sympa » en mode multi-domaine, arrêtez-moi si je me trompe, sur une installation postfix « virtuelle » (utilisateurs en base MySQL), c’était loin d’être gagné. Mal documenté à mon goût sur la partie multi-domaine.
• « mailman » semblait pouvoir faire tout ça, avec une interface web (et ligne de commande) assez ancestrale, mais suffisante, efficace et qui marche

Deux points de détails à bien regarder, qui m’ont fait faire cet article afin de ne pas oublier tout ça et que ça puisse resservir :

• l’interconnexion de mailman avec la partie Mysql de postfix
• le multi-domaine, afin de pouvoir gérer des listes genre liste1@domaine1.fr et liste2@domaine2.com, ces 2 domaines étant hébergés sur la même machine, la même installation postfix

Allez hop, c’est parti pour l’installation et les détails de configuration.
Voyez d’abord mes articles sur l’installation complète postfix/mysql/amavis/spamassassin/etc histoire de situer de quoi je parle.

Contexte

On installe ça sur une Debian Squeeze, appelée « monserveur.fr » ayant plusieurs noms de domaine : « serveur.fr » et aussi « autredomaine.fr »
On voudra créer des mailing-lists sur l’un ou l’autre des domaines.

Installation

aptitude

J’ai préféré opter pour la version packagée plutôt que la dernière version officielle en .tar.gz, histoire de simplifier les migrations de Debian. Ca commence comme bien souvent :

monserveur:~# aptitude install mailman
Les NOUVEAUX paquets suivants vont être installés :
  mailman
0 paquets mis e jour, 1 nouvellement installés, 0 e enlever et 0 non mis e jour.
Il est nécessaire de télécharger 9 642 ko d'archives. Après dépaquetage, 44,3 Mo seront utilisés.
Prendre : 1 ftp://ftp.fr.debian.org/debian/ squeeze/main mailman amd64 1:2.1.13-5 [9 642 kB]
 9 642 ko téléchargés en 1s (8 576 ko/s)
Lecture des champs des paquets... Fait
Lecture de l'état des paquets... Fait
Récupération des rapports de bogue... Fait
Analyse des informations Trouvé/Corrigé... Fait
Bogues de gravité serious sur mailman (-> 1:2.1.13-5) 
 #611804 - Astonishing header mangling
Résumé :
 mailman(1 bogue)
Êtes-vous certain de vouloir installer/mettre e jour les paquets ci-dessus ? [Y/n/?/...]
Préconfiguration des paquets...
Sélection du paquet mailman précédemment désélectionné.
(Lecture de la base de données... 57308 fichiers et répertoires déje installés.)
Dépaquetage de mailman (e partir de .../mailman_1%3a2.1.13-5_amd64.deb) ...
Traitement des actions différées (« triggers ») pour « man-db »...
Paramétrage de mailman (1:2.1.13-5) ...
Looking for enabled languages (this may take some time) ... done.
Installing site language en ............................................ done.
Configuring mailman for domain monserveur.fr ...
Mise e jour de la version 0x0 vers 0x2010df0
suppression des anciens fichiers sources
Mise e jour de la liste de diffusion mailman
Mise e jour de la base de donnees des requetes en attente.
- mise e jour de l'ancien fichier mbox prive
Rien e faire.
- Mise e jour de l'ancien fichier mbox public
Rien e faire.
Reparation des modeles de langue : mailman

Mise e jour des filigranes Usenet
- rien e mettre e jour ici
Rien e faire.
mise e jour des anciens fichiers qfiles
Starting Mailman master qrunner: mailmanctl.

Un seul écran à noter :

Pas de liste du site                                                                                                                                                      ¦
  ¦                                                                                                                                                                           ¦
  ¦ Mailman a besoin d'une liste du site (« site list »). Elle permet d'envoyer les rappels pour les mots de passe, etc. Elle doit être créée avant le lancement de Mailman.  ¦
  ¦                                                                                                                                                                           ¦
  ¦ Pour créer cette liste, exécuter « newlist mailman » et suivez les instructions qui apparaissent e l'écran. Il est ensuite nécessaire de redémarrer mailman avec la       ¦
  ¦ commande « /etc/init.d/mailman start ».

L’installation créera cette liste de diffusion appelée « mailman » (et j’avoue que je ne comprends pas son utilité…)

permissions

Il faut vérifier/adapter les permissions qui ne semblent pas bonnes après installation :

monserveur:~# check_perms
Les repertoires doivent etre au moins en 02775 : /var/lib/mailman/logs
Mauvais gid pour /var/lib/mailman/cgi-bin (Obtenu: root, Attendu list)
Mauvais gid pour /var/lib/mailman/locks (Obtenu: root, Attendu list)
Mauvais gid pour /var/lib/mailman/scripts (Obtenu: root, Attendu list)
Mauvais gid pour /var/lib/mailman/mail (Obtenu: root, Attendu list)
Mauvais gid pour /var/lib/mailman/Mailman (Obtenu: root, Attendu list)
Mauvais gid pour /var/lib/mailman/cron (Obtenu: root, Attendu list)
Mauvais gid pour /var/lib/mailman/templates (Obtenu: root, Attendu list)
Mauvais gid pour /var/lib/mailman/logs (Obtenu: root, Attendu list)
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages
Mauvais gid pour /var/lib/mailman/icons (Obtenu: root, Attendu list)
Mauvais gid pour /var/lib/mailman/bin (Obtenu: root, Attendu list)
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/gl
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/pt
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/ko
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/ro
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/it
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/ca
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/cs
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/vi
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/he
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/ia
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/eu
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/de
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/ar
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/zh_TW
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/ru
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/zh_CN
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/uk
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/pt_BR
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/sv
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/fi
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/da
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/sr
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/tr
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/et
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/ja
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/fr
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/lt
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/hr
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/ast
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/nl
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/sl
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/hu
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/sk
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/es
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/no
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/pl
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/gl/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/pt/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/ko/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/ro/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/it/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/ca/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/cs/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/vi/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/he/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/ia/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/eu/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/de/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/ar/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/zh_TW/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/ru/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/zh_CN/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/uk/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/pt_BR/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/sv/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/fi/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/da/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/sr/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/tr/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/et/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/ja/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/fr/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/lt/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/hr/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/ast/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/nl/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/sl/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/hu/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/sk/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/es/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/no/LC_MESSAGES
Les permissions sur les repertoires doivent etre de 02775 : /var/lib/mailman/messages/pl/LC_MESSAGES
Problemes trouves : 84
Re-executer en tant que list (ou root) avec l'option -f pour reparer

On execute la même commande avec le paramètre -f et on recontrôle :

Mauvais gid pour /var/lib/mailman/cgi-bin (Obtenu: root, Attendu list)
Mauvais gid pour /var/lib/mailman/locks (Obtenu: root, Attendu list)
Mauvais gid pour /var/lib/mailman/scripts (Obtenu: root, Attendu list)
Mauvais gid pour /var/lib/mailman/mail (Obtenu: root, Attendu list)
Mauvais gid pour /var/lib/mailman/Mailman (Obtenu: root, Attendu list)
Mauvais gid pour /var/lib/mailman/cron (Obtenu: root, Attendu list)
Mauvais gid pour /var/lib/mailman/templates (Obtenu: root, Attendu list)
Mauvais gid pour /var/lib/mailman/logs (Obtenu: root, Attendu list)
Mauvais gid pour /var/lib/mailman/icons (Obtenu: root, Attendu list)
Mauvais gid pour /var/lib/mailman/bin (Obtenu: root, Attendu list)
Problemes trouves : 10

MAIS : il s’agit de liens symboliques et l’outil contrôle les permissions des liens, pas des fichiers visés. Bref, c’est bon.

Conf mailman

Une partie de la doc d’installaiton est dans /usr/lib/mailman/bin/postfix-to-mailman.py qui est un lien vers /etc/mailman/postfix-to-mailman.py. Attention, cette doc doit être transposée au contexte « serveur virtuel avec conf en MySQL » – ce que je fais dans cet article.

Dans /etc/mailman/mm_cfg.py, j’adapte ces paramètres là :
DEFAULT_SERVER_LANGUAGE = ‘fr’
MTA=’Postfix’

Codes d’accès à mailman

Remarque :
« mailman » peut s’utiliser en ligne de commande, voir la liste des commandes possibles (éventuellement pratique pour scripter) : dpkg -L mailman | grep bin. Ca permet de découvrir la liste des outils : rmlist, list_lists, add_members, newlist etc…

L’accès à l’interface mailman ne se fait pas avec un identifiant et un mot de passe, mais juste avec un mot de passe.
Pour créer des « comptes » de la sorte, c’est l’outil mmsitepass.

Conf apache

Par défaut, le script mailman d’interface web est accessible sur http://votre.serveur/cgi-bin/mailman/admin/. Si vous n’aimez pas les répertoires standards, vous pouvez adapter le fichier /etc/mailman/apache.conf en adaptant /cgi-bin/mailman/ et /pipermail/ et en conséquence le fichier /etc/mailman/postfix-to-mailman.py, paramètres DEFAULT_URL_PATTERN et PRIVATE_ARCHIVE_URL.

Configuration postfix

« pipe » postfix : interface postfix <-> binaires mailman

En fait, tout est déjà OK à la base – avant même l’installation de mailman !. C’est marrant ça, l’outil doit être bien ancré dans le monde UNIX…

monserveur:~# grep mailman /etc/postfix/*
/etc/postfix/master.cf:mailman   unix  -       n       n       -       -       pipe
/etc/postfix/master.cf:  flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py

On voir qu’on a un canal de communication « mailman » qui renvoie vers un script python qui fera le boulot

transport : interface postfix <-> « pipe »

Dans ma table « transport » (voir cet article), j’ajoute :

insert into transport values ('list.serveur.fr','mailman'),('list.autredomaine.fr','mailman');

Ceci prépare le terrain : si on écrit à une adresse @list.serveur.fr ou @list.autredomaine.fr (comme je disais au début de la doc), alors postfix passera le relai au « pipe » nommé « mailman » (issu du master.cf de postfix), donc aux scripts mailman.
Rien de nécessaire dans la table « domains » ; comme pour le répondeur vacation (voir précédent article).

Multi-domaine

J’ai déclaré ceci dans le fichier /etc/mailman/mm_cfg.py :

add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
add_virtualhost('list.serveur.fr','monserveur.fr')
add_virtualhost('list.autredomaine.fr','monserveur.fr')

Pour gérer le multi-domaine, c’est aussi simple que ça (et les bons transports SQL). J’y reviendrai un peu plus tard tout de même.

main.cf

La doc dit d’ajouter mailman_destination_recipient_limit=1 dans /etc/postfix/main.cf ; soit.

Relance de tout ça

reload apache
restart mailman
reload postfix

Rien dans amavis, comme pour les répondeurs vacation

Créer une liste

On veut créer une liste « mesabonnes@serveur.fr ».

Au niveau SQL

On déclare tout ça :

insert into forwardings values ('mesabonnes-admin@serveur.fr','mesabonnes-admin@list.serveur.fr');
insert into forwardings values ('mesabonnes-bounces@serveur.fr','mesabonnes-bounces@list.serveur.fr');
insert into forwardings values ('mesabonnes-confirm@serveur.fr','mesabonnes-confirm@list.serveur.fr');
insert into forwardings values ('mesabonnes-join@serveur.fr','mesabonnes-join@list.serveur.fr');
insert into forwardings values ('mesabonnes-leave@serveur.fr','mesabonnes-leave@list.serveur.fr');
insert into forwardings values ('mesabonnes-owner@serveur.fr','mesabonnes-owner@list.serveur.fr');
insert into forwardings values ('mesabonnes-request@serveur.fr','mesabonnes-request@list.serveur.fr');
insert into forwardings values ('mesabonnes-subscribe@serveur.fr','mesabonnes-subscribe@list.serveur.fr');
insert into forwardings values ('mesabonnes-unsubscribe@serveur.fr','mesabonnes-unsubscribe@list.serveur.fr');

Et bien sûr :

insert into forwardings values ('mesabonnes@serveur.fr','mesabonnes@list.serveur.fr');

C’est bien ici qu’on voit comment le lien entre la liste et mailman est fait : les adresses sont renvoyées vers un domaine bidon (pas nécessaire de le déclarer dans un DNS, c’est interne à postfix), domaine pour lequel un « transport » particulier est créé afin d’envoyer le courrier vers le pipe unix => script mailman.

Enfin, au niveau de mailman

En tant que root, newlist mesabonnes. On met un responsable de la liste et un code d’accès.

Administration de la liste par le web (hors ligne de commande, donc)

L’outil principal listant toutes les listes est là : http://serveur.fr/cgi-bin/mailman/admin/ si vous n’avez pas changé les adresses. Une fois une liste sélectionnée, on obtient l’interface suivante :

Ensuite, c’est le festival des options.
Il faut bien les lire une fois et noter celles qui vous intéressent : masquer l’expéditeur, limiter la taille des messages, fixer les règles de modération, éviter les doublons (lorsqu’une personne de la liste répond à la liste, doit-elle recevoir le mail, simplement un accusé ?), Il y a des outils pour abonner des gens en masse (sans les prévenir ou en les prévenant) etc etc.
La seule chose que je vais mentionner, par rapport au multi-domaine, c’est l’option « Le nom d’hôte préféré par cette liste de diffusion pour le courriel. » du menu « [Options Générales] » afin d’indiquer le vrai serveur sous lequel est utilisé la liste : serveur.fr et pas autredomaine.fr dans l’exemple.

Voilà, normalement ça marche

Remarques

multi-domaine

On a vu rapidement que le multi-domaine marchait facilement : les transports dans la table SQL + quelques lignes dans mm_cfg.py et les alias qui vont bien.
MAIS : l’identifiant de la liste ne tient pas compte du nom de serveur. Donc les noms devront être différents d’un domaine à l’autre (je suppose), impossible donc d’avoir liste1@serveur.fr et liste1@autredomaine.fr pointant vers la même installation mailman.
On peut imaginer plein d’autres méthodes pour contourner ça. J’en mentionne une car je l’ai testée et la contrainte d’avoir des noms différents ne me gêne pas.
Je peux passer par des noms de listes intermédiaires pour éviter les problèmes, exemple :
- liste1@serveur.fr ==forward==> interne_liste1@list.monserveur.fr
- liste1@autredomaine.fr == forward ==> interne_liste2@list.monserveur.fr
Et donc avoir déclaré avec « newlist » les listes interne_liste1/2
Ca marche. Sauf que mailman considère qu’il y a une forme de redirection et tous les messages sont soumis à modération (même pour une liste non modérée) pour signaler à l’administrateur que quelqu’un a fait un alias de cette liste.
Ici on s’en fout, mais imaginons que quelqu’un crée un simple alias « labandedabrutis@cabalance.fr » pointant vers votre liste, la bande d’abrutis en question sera ravie de ne pas être connue sous ce nom là…

lien avec spamassassin

Je n’ai pas cherché longtemps, c’est bien fait de base (sûrement un paramétrage – ou l’ordre ? – qui va bien dans /etc/postfix/master.cf) qui fait que le mail passe par toute la chaîne amavis/spamassassin/clamav. Ca se voit nettement dans les logs.

générer les alias facilement

Utilisez ce script :

#!/bin/bash
if test -z $1
then
        echo Usage: $0 liste serveur
        exit -1
fi
if test -z $2
then
        echo Usage: $0 liste serveur
        exit -1
fi

for i in admin bounces confirm join leave owner request subscribe unsubscribe
do
        echo insert into forwardings values \(\'$1-$i@$2\',\'$1-$i@list.$2\'\)\;
done
echo insert into forwardings values \(\'$1@$2\',\'$1@list.$2\'\)\;

Voilà, c’est complet je pense. Amusez-vous bien.

[30926] warn: rules: failed to run CG_FUJI_JPG test, skipping:
[30926] warn: (Can’t locate object method « image_name_regex » via package « Mail::SpamAssassin::PerMsgStatus » at (eval 1466) line 856.
[30926] warn: )
[30926] warn: rules: failed to run CG_DOUBLEDOT_GIF test, skipping:
[30926] warn: (Can’t locate object method « image_name_regex » via package « Mail::SpamAssassin::PerMsgStatus » at (eval 1466) line 986.
[30926] warn: )
[30926] warn: rules: failed to run CG_SONY_JPG test, skipping:
[30926] warn: (Can’t locate object method « image_name_regex » via package « Mail::SpamAssassin::PerMsgStatus » at (eval 1466) line 1602.
[30926] warn: )
[30926] warn: rules: failed to run CG_CANON_JPG test, skipping:
[30926] warn: (Can’t locate object method « image_name_regex » via package « Mail::SpamAssassin::PerMsgStatus » at (eval 1466) line 2704.
[30926] warn: )

Je commente l’appel à ces règles dans /etc/spamassassin/imageinfo.cf.
Et enfin je désactive la mise à jour via sa-update, en commentant mes lignes /etc/spamassassin/channels.txt.

A suivre.

Principe

On va créer une voie de transport dans postfix afin de « router » les messages de certains utilisateurs vers un pipe particulier appelant procmail dans sa forme à peu près basique.
« procmail » tournera au nom de l’utilisateur gérant les « Maildir » virtuels, utilisateur « vmail » (dans mes docs précédentes) et lira un procmail général avant de passer le relai à un procmail par utilisateur (si besoin), pour trier. En décrivant proprement l’environnement pour procmail, on livrera où il faut dans un Maildir sous « vmail », donc dans un Maildir d’un domain virtuel pour un utilisateur virtuel dans un sous-répertoire de sa boîte Maildir.
Mouais, bon, c’est pas hyper clair, mais ça va le devenir

pipe postfix

Dans /etc/postfix/master.cf, on déclare le « pipe suivant » :

procmailpipe    unix    -       n       n       -       10      pipe
  flags=ROq user=vmail argv=/usr/bin/procmail --m USER=${user} EXTENSION=${extension} NEXTHOP=${nexthop} /etc/postfix/procmail.global.rc

Bien noter le « NEXTHOP » qui nous indiquera le domaine (pratique lorsqu’on en gère plusieurs en virtuel.
Je rappelle que dans ma conf, l’utilisateur hébergeant les boites mails est « vmail », dont le home est /vmailboxes/. On trouve donc là-dedans des répertoires comme /vmailboxes/mon_domaine.com/mon_user/cur|tmp|new et autres sous répertoires commençant par .sous-rep/[cur|new|tmp]/.
Pour accompagner le flag « O » dans ce pipe, la doc postfix indique de bien positionner dans le /etc/postfix/main.cf :

procmail_destination_recipient_limit = 1

Alias d’un utilisateur vers son procmail

Dans mes tables SQL (à priori « transport » et « forwardings »), j’indique ceci :

transport : procmail.mon_domaine.com => procmailpipe
forwardings : mon_user@mon_domaine.com => mon_user@procmail.mon_domaine.com

Ainsi, un mail arrive à mon_user@mon_domaine.com suivra vers mon_user@procmail.mon_domaine.com (qui n’existe pas au sens DNS) et sera donc routé vers le « pipe » postfix nommé « procmailpipe » décrit dans master.cf.

procmailrc global

Le « pipe » postfix ira lire /etc/postfix/procmail.global.rc en passant quelques variables comme on l’a vu.
Dans ce fichier, on trouve exactement ça :

serveur:~# cat /etc/postfix/procmail.global.rc
SHELL=/bin/sh
MAILDIR="$HOME/$NEXTHOP/$USER"
DEFAULT="$MAILDIR/"
#VERBOSE=ON
#LOGFILE="$HOME/procmail/$NEXTHOP.$USER.log"
NL="
"
WS=" "
SWITCHRC="$HOME/procmail/$NEXTHOP.$USER.rc"

Pour NL et WS, c’est une question de séparateur de mot, de ligne etc. (je crois )
Pour VERBOSE et LOGFILE, vous activerez au début quand ça ne fonctionnera pas, afin de pouvoir déverminer.
Toute la beauté du bazar réside en fait dans le « MAILDIR » et « SWITCHRC ».
Dans mon exemple, MAILDIR vaudra :

$HOME = home de vmail = /vmailboxes
$NEXTHOP = procmail.mon_domaine.com
$USER = mon_user

Enfin, on ira lire un fichier procmailrc par utilisateur. Si on ne trouve pas de fichier « /vmailboxes/procmail/procmail.mon_domaine.com.mon_user.rc« , on finira donc directement dans une MAILDIR nommée « /vmailboxes/procmail.mon_domaine.com/mon_user/ » (attention au « / » de fin dans DEFAULT pour indiquer un format Maildir et pas mailbox). Presque parfait me direz-vous car dans mes domaines virtuels hébergés, j’avais prévu « /vmailboxes/mon_domaine.com » et pas « procmail.mon_domaine« .
Je n’ai pas trouvé de variable type NEXTHOP rappelent le domaine d’origine. Par contre un lien symbolique de « /vmailboxes/procmail.mon_domaine.com/ » vers « /vmailboxes/mon_domaine.com/ » règle joliment le problème.

Enfin, procmailrc par utilisateur

J’ai donc regroupé mes différents procmailrc dans /vmailboxes/procmail/
Ces fichiers contiendront donc des règles procmail habituelles, en considérant pour « MAILDIR/DEFAULT » de travail, qu’on est bien placé dans « /vmailboxes/[procmail.]mon_domaine.com/mon_user/« . Ainsi :

:0
* Subject:.*testprocmail
.test/

…ira bien placer votre mail dans le sous-répertoire « test » de l’utilisateur. Donc dans « /vmailboxes/mon_domaine.com/mon_user/.test/new/ »

Débuggage

Pendant la phase de tests, notez que les mails allant dans des Maildir n’existant pas finiront dans le home de l’utilisateur « vmail ». Donc, vous verrez peut-être apparaître /vmailboxes/[cur|new|tmp] et pourrez aller à la pêche.

• configurer postfix pour gérer des utilisateurs virtuels
• monter une architecture complète « postfix / postgrey / amavisd-new / clamav / spamassassin »

Il manque cependant un morceau : la possibilité de faire appel à des « procmail » personnalisés pour ces utilisateurs virtuels.

Lorsqu’on n’est pas avec des utilisateurs virtuels, chaque utilisateur réel (ayant un compte utilisateur, donc) utilise généralement son ~/.procmailrc pour trier un peu ou - cas qui m’intéresse particulièrement – activer son répondeur d’absence, « vacation«  pour ne pas le nommer.
Dans le cas d’utilisateurs virtuels, c’est sensiblement différent. C’est ce que je décrirai dans cet article. Ce n’est au final pas compliqué, mais il faut comprendre le rôle de chaque composant et les limites de fonctionnement de chaque outil.
En effet, je n’ai pas trouvé de doc ultra-claire sur le sujet sur le web, surtout les bricoles de chacun. Avec un peu de recul, et, voyant ma propre solution, j’ai l’impression qu’il y a tellement de configurations possibles (maildrop et pas procmail, mes utilisateurs virtuels comme ci, pas comme ça, il utilise postfixadmin et pas moi etc) qu’il est impossible d’écrire un truc qui n’est pas spécifique.
Le plus dur est donc de comprendre ce qu’on fait pour transposer à sa conf. Je tâcherai donc, comme d’hab, d’expliquer ce que je fais plutôt que de copier-coller les fichiers de conf.

Allez, let’s go pour la mise en place sur la base d’une archi postfix & co comme décrite dans les docs mentionnées en début de cet article.

Ah, dernier point : à la base, et tel que je le décris, l’utilisateur ne pourra pas mettre lui même son répondeur en place. Dans mon cas, ce n’est pas important. En effet, j’utilise des utilisateurs virtuels car il s’agit d’un serveur frontal de mails (qui trie le spam, en gros), livre les messages dans des arborescences virtuelles en attendant d’être POPées depuis un backend de mails quelconque (un vilain Exchange ). Donc, le répondeur d’absence des utilisateurs « physiques » est géré par eux-mêmes dans Outlook « normalement », et je n’applique ce principe de répondeur qu’exceptionnellement, à quelques boîtes mails IMAP génériques, qui n’ont pas vraiment de notion de « vacances ». Des boîtes partagées entre plusieurs personnes, si vous voulez, mais stockées sur le frontal et pas dans le backend, pour diverses raisons dont on se moque ici. Après vous pourrez toujours bricoler un truc pour que tout un chacun accède à son procmail ou son message d’asbence pour le mettre, l’enlever etc.

Le principe

On veut activer le répondeur de toto@domaine.fr en utilisant l’outil « vacation » qui gère très bien les réponses. « vacation » ne joue qu’avec des comptes utilisateurs existants. Premier problème.

Pour y arriver, on va créer des alias pour ce compte virtuel « toto@domaine.fr » afin que postfix « forward » (du nom de la table « forwardings » gérant les alias des utilisateurs virtuels) tout mail à destination de toto@domaine.fr vers 2 endroits :

• le réel toto@domaine.fr, histoire de délivrer le mail quand même, au final
• et en plus vers un certain toto@vacation.domaine.fr qui n’existe pas

Ce dernier nom « vacation.domaine.fr » n’a pas besoin d’exister au sens DNS et ne correspond pas non plus à un MX réel. On va juste créer un « transport » (du nom de la table MySQL qu’on a créée avec les docs précédentes) particulier afin de router les messages à destination du domaine « vacation.domaine.fr » vers un « pipe » particulier de postfix qu’on va créer pour l’occasion.
Ce « pipe » UNIX, composant qu’on ajoute à la chaîne postfix, gèrera en fait l’appel à procmail configuré d’une manière globale (un gros procmailrc générique, si vous voulez).
Ce procmail fera ensuite un tri sur le nom du destinaire et appellera « vacation » lorsqu’on le veut avec un message personnalisé.

C’est ce procmail global qu’il conviendrait de découper (avec des INCLUDE), ainsi que les fichiers de messages d’absence qui vont avec, si on voulait donner la main d’une manière pas super pratique (FTP ? samba ?) à des utilisateurs réels sur leur répondeur de compte virtuel…

Je me suis basé sur pas mal de docs bizarroïdes, et surtout sur les quelques explications trouvées ici. Le cheminement y est, mais c’est pas détaillé sur le principe et le type propose son propre script de répondeur ; script qui peut générer une belle boucle infinie entre répondeurs, à mon humble avis. Ce risque n’existe pas avec « vacation« , car il garde une liste des gens « déjà répondus », sauf si vous forcez à répondre à chaque fois.

Mise en place

Paquets, utilisateur etc

Au besoin, suivant l’état de votre installation :

aptitude install procmail vacation

Ensuite, j’ai expliqué que « vacation » ne travaillait que sur un compte réel. Je lui dédie donc un compte :

useradd -m vacation -s /bin/nologin -c "Utilisateur vacation"

Création du pipe UNIX

On crée le processus qui sera en charge de router (de manière interne à postfix) les messages arrivant dans un pipe qu’on nomme « repondeur » vers procmail (lui même appelant le cas échéant le programme de répondeur « vacation« ).
Dans /etc/postfix/master.cf, à la fin (peu importe), on définit ce pipe comme suit :

#ajout d'un appel à procmail pour gérer certains 'vacation' sur les boites IMAP
#attention, l'appel à ce pipe est géré dans la table des transports virtuels + des forwardings qui vont bien
repondeur   unix    -       n       n       -       10      pipe
  flags=Rq user=vacation argv=/usr/bin/procmail -Y -m /etc/postfix/procmail-global-repondeur.rc ${sender} ${recipient}

Les espaces avant « flags » sont importants, c’est ce qui explique à postfix qu’il s’agit d’option du pipe nommé « repondeur ».
Je décrirai le fichier /etc/postfix/procmail-global-repondeur.rc plus tard. C’est lui qui contiendra les appels aux « vacation » de tels et tels utilisateurs.
J’avoue ne pas être super sûr des flags utilisés, voyez man pipe au besoin.

transport virtuel

Si votre base MySQL est exactement celle que je décris dans mes précédentes documentations, insérez une ligne dans la table « transport » afin d’avoir :

mysql> select * from transport;
+---------------------+-----------+
| domain              | transport |
+---------------------+-----------+
| vacation.domaine.fr | repondeur |
+---------------------+-----------+
1 row in set (0.00 sec)

Pour bien relier cette table à votre configuration « virtuelle », la table « transport » dont je parle est celle décrite comme ça dans postfix :

[extraits de fichiers]
main.cf:transport_maps = proxy:mysql:/etc/postfix/mysql-virtual_transports.cf
mysql-virtual_transports.cf:query = SELECT transport FROM transport WHERE domain='%s'

Création des alias pour router vers le « pipe » « repondeur »

Pour chaque utilisateur virtuel qui devra avoir un répondeur actif (ou potentiellement actif), il faudra ajouter 2 alias le concernant dans la table des alias (« forwardings » dans mon cas, là encore, ça dépend de votre conf de « postfix virtuel »). Ajoutez donc les lignes pour avoir :

mysql> select * from forwardings where source like 'j%doma%';
+--------------------+-----------------------------+
| source             | destination                 |
+--------------------+-----------------------------+
| jacques@domaine.fr | jacques@domaine.fr          |
| jacques@domaine.fr | jacques@vacation.domaine.fr |
+--------------------+-----------------------------+
2 rows in set (0.00 sec)

J’ai eu un souci pour insérer ces 2 lignes, car il y a une contrainte de clef primaire sur « source », ce qui semble logique, mais qui est en fait bloquant pour nous et inutile dans un cas normal d’alias d’utilisateurs virtuels (on pourrait faire une liste de diffusion en créant plusieurs lignes pour une même source car postfix gère très bien le fait d’avoir plusieurs destination pour une même source).
Bref, j’ai fait sauté la contrainte PK que j’avais mise dans mes docs précédents :

ALTER TABLE forwardings
DROP PRIMARY KEY;

Rassurez-vous, ça ne fait pas sauter les entrées déjà stockées dans la table si vous en avez.

procmailrc et vacation

On y est presque.
Reste à définir le procmail global appelant vacation :
Dans mon « pipe« , j’appelle ce fichier :

servr:/etc/postfix# cat /etc/postfix/procmail-global-repondeur.rc
SHELL=/bin/sh

:0c
* ^(To|Cc).*jacques@domaine.fr
| vacation -f /home/vacation/jacques@domaine.fr.db -m /home/vacation/jacques@domaine.fr.msg -a jacques@domaine.fr vacation

:0c
* ^(To|Cc).*autre_type@domaine.fr
| vacation -f /home/vacation/autre_type@domaine.fr.db -m /home/vacation/autre_type@domaine.fr.msg -a autre_type@domaine.fr vacation

:0
/dev/null

Alors, c’est presque le plus compliqué car ce fichier est plein de petites ruses. Il vous montre comment procéder lorsque vous aurez plusieurs boîtes concernées par un vacation.
Je rappelle que de cette manière, c’est un peu pénible à maintenir car c’est l’admin qui gère. Là il s’agit de boîte IMAP partagées et peu nombreuses, donc c’est gérable.

Le détail est donc :

• Je stocke tous mes messages de « vacances » dans ~vacation/
• -f : pour indiquer dans quelle « base de données » on stocke les gens à qui on a déjà répondu
• -m : pour indiquer le mail de réponse d’un utilisateur donné, je le détaille plus bas
• -a : hyper important : en effet, vacation ne travaille que sur un utilisateur réel. Donc obligé de spécifier un utilisateur réel en fin de commande vacation, c’est l’utilisateur « vacation » himself qui figure en dernier argument de la ligne de commande. Donc, pour que vacation travaille, j’explique aussi que cet utilisateur réel peut être connu sous l’alias (-a) jacques@domaine.fr (ou autre_type@domaine.fr dans la 2è règle). Sinon aucune règle ne s’appliquera jamais.
• « :0c » : OUI : il faut activer le « carbon copy ». J’ai constaté ça à force de tests. En effet, un message arrivant dans postfix a un ID, il est dédoublé avec le même ID, l’un part vers l’utilisateur réel pour livraison, l’autre vers le « pipe« , puis procmail, puis vacation. « vacation » arrête les règles (si on ne met pas le « c » de carbon copy) dès que ça « match ». Si un expéditeur envoi un unique mail à en même temps jacques@domaine.fr et autre_type@domaine.fr, la première règle va marcher, donc procmail arrêtera de bosser. Résultat : pas de répondeur pour « autre_type ». On ne sait pas qu’il est en vacances.
• Et enfin, le piège des « carbon copy » : si on ne fait pas une dernière règle virant vers /dev/null tout message au final, un message légitime auquel on aura répondu par « vacation » sortira de procmail et continuera sa route : il sera donc livré. Mais c’est un utilisateur complètement bidon, untel@vacation.domaine.fr, domaine inexistant => erreur de livraison => log dans /var/log/mail.info et surtout, mail d’erreur bien crade informant l’expéditeur…

fichier .msg de vacation

Voici à quoi doit ressembler un fichier de réponse minimaliste :

servr:/etc/postfix# cat ~vacation/jacques\@domaine.fr.msg
From: jacques@domaine.fr (Jacques)
Subject: Re: $SUBJECT
Precedence: Bulk

Votre mail a bien été reçu, blablablabla
-- Jacques

reload postfix et tests

A la fin, /etc/init.d/postfix reload et zou, testez des envois de mails, de réenvois de mails (pour n’avoir qu’une fois la réponse etc).
Le plus risqué dans cette manip’ sur un serveur en production, c’est que tout les adresses normales commencent à merdouiller. Le plus rapide pour annuler tout ça le temps de réfléchir, est de commenter les 2 lignes définissant le pipe et de rechargez postfix.

Autres remarques

Réinit d’un répondeur

A une époque, il me semblait qu’en modifiant le fichier .msg, vacation détectait le changement et donc ne tenait plus compte des expéditeurs « déjà répondus ». Après quelques tests, je n’en suis plus si sûr. Le plus simple pour relancer un répondeur « pour tous » : supprimez le fichier .db correspondant.

Permissions

Attention, j’ai interdit le login pour l’utilisateur vacation. Donc tout ce que vous créerez dans ~vacation/*msg sera sûrement au nom de « root », par exemple. Pensez à changer les droits.
Si vous avez raté un truc, les logs sont très explicites dans /var/log/mail.info.
Je crois aussi me rappeler que si vacation ne voit pas le fichier .msg, il ne fera rien. A vérifier, mais c’est une méthode simple (et crade car ça va faire du log à coup sûr) pour activer/désactiver un répondeur

un log complet pour illustrer

Si tout se passe bien, vous avez ça :
Connexion du serveur expéditeur :

Jun 14 17:10:21 servr postfix/smtpd[20107]: connect from expediteur.org[xx.yy.zz.tt]
Jun 14 17:10:21 servr postgrey[12166]: action=pass, reason=client AWL, client_name=expediteur.org, client_address=xx.yy.zz.tt, sender=exped@expediteur.org, recipient=jacques@domaine.fr
Jun 14 17:10:21 servr postfix/smtpd[20107]: C2B829C4081: client=expediteur.org[xx.yy.zz.tt]
Jun 14 17:10:21 servr postfix/cleanup[20065]: C2B829C4081: message-id=<20100614151021.AF0F0EEC57C@mail.expediteur.org>
Jun 14 17:10:21 servr postfix/qmgr[19547]: C2B829C4081: from=, size=515, nrcpt=2 (queue active)
Jun 14 17:10:21 servr postfix/smtpd[20107]: disconnect from expediteur.org[xx.yy.zz.tt]
Jun 14 17:10:23 servr postfix/smtpd[20208]: connect from localhost.localdomain[127.0.0.1]
Jun 14 17:10:23 servr postfix/smtpd[20208]: 8A0E69C4085: client=localhost.localdomain[127.0.0.1]
Jun 14 17:10:23 servr postfix/cleanup[20065]: 8A0E69C4085: message-id=<20100614151021.AF0F0EEC57C@mail.expediteur.org>
Jun 14 17:10:23 servr postfix/smtpd[20208]: disconnect from localhost.localdomain[127.0.0.1]
Jun 14 17:10:23 servr postfix/qmgr[19547]: 8A0E69C4085: from=, size=1045, nrcpt=3 (queue active)

Pas de greylisting, car c’est un pote. Analyse par amavis OK, on dédouble le message vers jacques@domaine.fr et jacques@vacation.domaine.fr.
Chaque file suivra alors sa route :

Jun 14 17:10:23 servr amavis[18918]: (18918-18) Passed CLEAN, [xx.yy.zz.tt] [xx.yy.zz.tt]  -> ,, Message-ID: <20100614151021.AF0F0EEC57C@mail.expediteur.org>, mail_id: uuW4XqNAoH7S, Hits: 1.714, size: 515, queued_as: 8A0E69C4085, 1902 ms
Jun 14 17:10:23 servr postfix/smtp[20190]: C2B829C4081: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=1.9, delays=0.03/0/0/1.9, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=18918-18, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 8A0E69C4085)
Jun 14 17:10:23 servr postfix/smtp[20190]: C2B829C4081: to=, orig_to=, relay=127.0.0.1[127.0.0.1]:10024, delay=1.9, delays=0.03/0/0/1.9, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=18918-18, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 8A0E69C4085)
Jun 14 17:10:23 servr postfix/qmgr[19547]: C2B829C4081: removed

La partie « utilisateur virtuel de postfix » traite le « mail normal » => « delivered to maildir ». Ca roule :

Jun 14 17:10:23 servr postfix/virtual[20212]: 8A0E69C4085: to=, relay=virtual, delay=0.3, delays=0.15/0.01/0/0.14, dsn=2.0.0, status=sent (delivered to maildir)

La partie « vacation » (pipe repondeur) route vers le « relay=repondeur ». Le job s’accomplit correctement « (delivered via repondeur service) ». Là on n’a pas d’autre erreur, sinon on pourrait voir vacation ou procmail pas content :

Jun 14 17:10:23 servr postfix/pickup[19550]: ECF179C408A: uid=5001 from=
Jun 14 17:10:23 servr postfix/pipe[20209]: 8A0E69C4085: to=, orig_to=, relay=repondeur, delay=0.41, delays=0.15/0/0/0.25, dsn=2.0.0, status=sent (delivered via repondeur service)
Jun 14 17:10:23 servr postfix/pipe[20209]: 8A0E69C4085: to=, relay=repondeur, delay=0.41, delays=0.15/0/0/0.25, dsn=2.0.0, status=sent (delivered via repondeur service)
Jun 14 17:10:23 servr postfix/cleanup[20065]: ECF179C408A: message-id=<20100614151023.ECF179C408A@domaine.fr>
Jun 14 17:10:23 servr postfix/qmgr[19547]: 8A0E69C4085: removed
Jun 14 17:10:24 servr postfix/qmgr[19547]: ECF179C408A: from=, size=343, nrcpt=1 (queue active)

Deux secondes plus tard, « vacation » a détecté qu’il fallait répondre à « exped@expediteur.org », donc on envoit un mail :
(le champ From sera jacques@domaine.fr, seul Return-Path sera à vacation@domaine.fr)

Jun 14 17:10:26 servr postfix/smtpd[20208]: connect from localhost.localdomain[127.0.0.1]
Jun 14 17:10:26 servr postfix/smtpd[20208]: 174A99C4081: client=localhost.localdomain[127.0.0.1]
Jun 14 17:10:26 servr postfix/cleanup[20065]: 174A99C4081: message-id=<20100614151023.ECF179C408A@domaine.fr>
Jun 14 17:10:26 servr postfix/qmgr[19547]: 174A99C4081: from=, size=770, nrcpt=1 (queue active)
Jun 14 17:10:26 servr amavis[20202]: (20202-01) Passed CLEAN,  -> , Message-ID: <20100614151023.ECF179C408A@domaine.fr>, mail_id: xw6dpgfdz+b5, Hits: -0.001, size: 343, queued_as: 174A99C4081, 2197 ms
Jun 14 17:10:26 servr postfix/smtp[20190]: ECF179C408A: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=2.3, delays=0.14/0/0/2.2, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=20202-01, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 174A99C4081)
Jun 14 17:10:26 servr postfix/qmgr[19547]: ECF179C408A: removed
Jun 14 17:10:26 servr postfix/smtp[20219]: 174A99C4081: to=, relay=mail.expediteur.org[xx.yy.zz.tt]:25, delay=0.21, delays=0.14/0/0.02/0.05, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 4337FEEC560)
Jun 14 17:10:26 servr postfix/qmgr[19547]: 174A99C4081: removed

aptitude install isoqlog mailgraph

Il n’y a rien à dire sur le paramétrage de mailgraph. Dans le cas d’une installation standard de Debian, vous trouverez le rapport temps réel sur http://le.serveur/cgi-bin/mailgraph.cgi.

Si vous avez désactivé l’alias /cgi-bin/ de la conf standard Apache, débrouillez-vous pour accéder au script /usr/lib/cgi-bin/mailgraph.cgi.
Voici le genre de rapport que l’on obtient : http://www.stat.ee.ethz.ch/mailgraph.cgi.

Pour isoqlog, il ne vous demande que des choses faciles pendant l’installation : nom du domaine, type de logs (postfix, exim etc). Les rapports tournent en crontab journalière, résultats dans /var/www/isoqlog/. Par défaut, c’est donc http://le.serveur/isoqlog/ pour accéder.

Voilà, statistiquez bien.

Hop,
Après ma doc d’initiation Debian, où un rapide chapitre est consacré au montage d’un serveur postfix, spamassassin, greylisting etc, dans une configuration simple,
Après cet article sur le montage complet cette fois, en incluant amavisd-new, anti-virus etc,
=> Voici le complément idéal, par exemple en PME (et même plus gros) :

• Gestion d’utilisateurs virtuels, entendez par là « utilisateurs définis en base de données et non pas utilisateurs réels de l’OS ».
• Mise en place de tout ce qu’il faut pour lire les mails (POP3, POP3S, IMAP, IMAPS) via les outils « courier-* »
• Authentification via SASL
• Mise en place d’authentification sécurisée plus forte pour l’envoi (TLS).

Pour le webmail, j’en ai parlé déjà quelques fois sur mon blog et dernièrement, la version 0.3 de roundcubemail a fait de gros progrès par rapport à la 0.1. Ca s’installe en 3 clics. Si j’ai le temps je ferai un article, mais c’est mal barré.

Situation de départ

Avoir un serveur postfix correctement monté, avec (ou pas) amavis, spamassassin, un anti-virus, du greylisting, un nom correct etc. Bref, un serveur qui fonctionne et qui accepte les mails correspondant à des Maildir d’utilisateur de l’OS. En gros, ce qui est expliqué là .
Je ne parlerai pas d’ouverture de ports réseaux etc, mais ça tombe sous le sens. Ni du fait qu’il vous faudra une base MySQL en état de marche.

Je n’ai pas trouvé de doc officielle sur le sujet. En gros, on a postfix-mysql qui permet de faire le lien entre le serveur de mails et la base, mais rien dans un gros fichier README qu’on a habituellement avec ce genre de paquet. Ou alors je l’ai loupé.
Le « postfix mysql howto » est juste résumé à ça : http://www.postfix.org/MYSQL_README.html et ça : http://www.postfix.org/mysql_table.5.html. Et pour le coup, ce n’est pas très sexy.

J’ai donc compilé tout un tas de différents articles le sujet, parfois incomplet, parfois des articles décrivant des méthodes à grand coup de compilation-c-est-pénible-et-stupide-pour-suivre-les-mises-à -jour etc. Parfois sans gestion de quota, parfois avec. Et en général, en expliquant rien du tout. Donc dans mon cas, je tâche d’expliquer ce qu’on fait.

Alors, comme à mon habitude, je laisserai trainer 2/3 bugs que j’ai pu rencontrer (de ma faute), ça peut permettre d’aider si vous faites les mêmes erreurs. Et on y apprend l’existence de quelques outils pour tester en ligne de commande.

Remarque pour la partie quota qui ne fonctionne pas nativement dans postfix, je la passe sous silence volontairement au début et y consacre un chapitre à la fin. En effet, c’est relativement dissocié de tout le reste et ça implique de recompiler postfix (ou d’utiliser un .deb fourni par je ne sais qui, mais vous êtes dépendant de lui pour les mises à jour). Comme certains se moqueront des quotas, je le traite à la fin. Beaucoup de guides de mise en place mélangent tout et prévoient des fonctions qu’ils n’exploitent pas. J’essaye pour ma part de faire des briques dissociables.

J’ai aussi tout installé sur un unique serveur. Ce n’est pas une nécessité, sur une grosse installation par exemple.

Autres documentations

A ce propos, j’ai lu à peu près tout ce qui suit (et plein d’autres) pour monter le serveur, notamment les 2 premiers lien. J’ai même en gros simplement repompé, traduit et expliqué :

• http://library.linode.com/email-guides/postfix/postfix-courier-mysql-debian-5-lenny
• http://www.howtoforge.com/virtual-users-domains-postfix-courier-mysql-squirrelmail-debian-lenny
• Quelques survols de docs ici : http://www.postfix.org/docs.html
• Un psycho de la recompilation : http://www.phparchitecture.com/howto_show.php?id=2, mais y’a 2/3 trucs à prendre

Grandes étapes de la procédure

En gros, on va :

• 1) Installer les applicatifs,
• Créer la structure en base,
• Décrire cette structure à postfix pour qu’il sache l’interroger
• 2) Créer ce qu’il faut pour stocker les boites virtuelles
• Faire quelques tests de livraison de mails pour valider la partie « utilisateurs définis en base »
• 3) Paramétrer les outils pour récupérer les mails (courier-POP, IMAP et versions sécurisées par SSL)
• Tester ces protocoles pour la récupération des mails
• Voir l’analyse de quelques erreurs sur la partie « courier »
• 4) Paramétrer les mécanismes d’authentification pour l’envoi (SASL, TLS)
• Tester l’envoi, en TLS ou pas
• Voir l’analyse de quelques erreurs sur la partie authentification pour l’envoi
• 5) Optionnel : activer les quotas
• Et enfin, voir ce que je n’ai pas traité

Installation des paquets

Pour une fois, tout ne descend pas par dépendance, car les différents modules d’authentification (identification via une base MySQL) ne sont pas obligatoires, donc pas de dépendance. Donc pour une fois il faut absolument tout copier-coller. Pour illustrer, installer courier-authlib n’amène pas forcément courier-authlib-mysql.

On a donc :

aptitude install postfix-mysql courier-pop courier-pop-ssl courier-imap courier-imap-ssl postfix-tls  libsasl2-2 libsasl2-modules libsasl2-modules-sql sasl2-bin libpam-mysql openssl courier-authdaemon courier-authlib-mysql

Vous pouvez à la limite zapper certains, comme le POP, si vous ne comptez pas l’utiliser. Notez que les webmails tapent en IMAP, si vous ne le saviez pas.

Connexion postfix <-> MySQL

Création de la base de données

J’ai vu des définitions de base hyper complète, pour désactiver le POP (ou je ne sais quoi d’autre) par utilisateur. Sachez qu’il sera toujours temps d’ajouter une colonne à une table, de mettre des valeurs par défaut et d’ajouter une règle dans postfix pour prendre en compte une nouvelle fonctionnalité (c’est d’ailleurs ce qu’on fera pour les quotas de boîtes mails). Donc faisons simple au début.

On crée une base et un utilisateur dédié, avec des droits pas trop larges. Une fois connecté en root dans votre base (exemple : mysql -u root -p), on crée la base et donne des droits à cet utilisateur qu’on crée au passage :

mysql> create database postfix;
Query OK, 1 row affected (0.00 sec)

mysql> grant select,insert,update,delete on postfix.* TO 'mail_adm'@'localhost' identified by 'monpassadmin';
Query OK, 0 rows affected (0.00 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

ATTENTION : dans toute la suite, le nom de la base, le nom des tables, les identifiants etc sont à modifier pour refléter votre installation. Attention à ne pas copier-coller trop vite.

Ensuite, dans la base « postfix », on crée quelques tables :

use postfix;

CREATE TABLE domains (
        domain varchar(50) NOT NULL,
        PRIMARY KEY (domain)
);
CREATE TABLE forwardings (
        source varchar(80) NOT NULL,
        destination TEXT NOT NULL,
        PRIMARY KEY (source)
);
CREATE TABLE users (
        email varchar(80) NOT NULL,
        password varchar(20) NOT NULL,
        PRIMARY KEY (email)
);
CREATE TABLE transport (
        domain varchar(128) NOT NULL default '',
        transport varchar(128) NOT NULL default '',
        UNIQUE KEY domain (domain)
);

Ces 4 tables permettront, dans l’ordre, de :

• définir la liste des domaines qu’on gère
• créer des alias (renvoyer toto@domaine.fr vers tata@blabla.com + titi@blibli.com)
• définir nos comptes et leurs propriétés
• définir une table de transport, au besoin

Création des requêtes pour savoir comment interroger ces tables

Le principe est le suivant : on a créé des tables avec des noms de colonnes et de tables libres (on aurait pu tout changer), on doit donc indiquer à postfix comment vérifier un mot de passe, voir s’il y a un forward etc. Pour chaque action, on a une directive dans /etc/postfix/main.cf et un fichier de conf décrivant la base et la requête.
Le truc énorme, c’est qu’on pourrait ajouter n’importe quelle colonne (attribut) pour ajouter un test. Exemple stupide : le password est OK entre 8h et 20h, sinon impossible de relever ses mails.
On ajouterait une colonne et une clause supplémentaire dans le WHERE, tenant compte de l’heure et d’horaires autorisés pour tel utilisateur.

Voici les 4 fichiers de conf pour les 4 tables précédement créées :
Fichier /etc/postfix/mysql-virtual_domains.cf :

user = mail_adm
password = monpassadmin
dbname = postfix
query = SELECT domain AS virtual FROM domains WHERE domain='%s'
hosts = 127.0.0.1

Fichier /etc/postfix/mysql-virtual_forwardings.cf :

user = mail_adm
password = monpassadmin
dbname = postfix
query = SELECT destination FROM forwardings WHERE source='%s'
hosts = 127.0.0.1

Fichier /etc/postfix/mysql-virtual_mailboxes.cf :

user = mail_adm
password = monpassadmin
dbname = postfix
query = SELECT CONCAT(SUBSTRING_INDEX(email,'@',-1),'/',SUBSTRING_INDEX(email,'@',1),'/')
        FROM users WHERE email='%s'
hosts = 127.0.0.1

Fichier /etc/postfix/mysql-virtual_transports.cf :

user = mail_adm
password = monpassadmin
dbname = postfix
query = SELECT transport FROM transport WHERE domain='%s'
hosts = 127.0.0.1

Ensuite on sécurise ces fichiers qui contiennent des infos sensibles sur la base d’authentification de mails :

chown root:postfix /etc/postfix/mysql*cf
chmod 640 /etc/postfix/mysql*cf

Création de la structure de stockage des boîtes

Le principe est le suivant : on indique un répertoire racine, avec un utilisateur dédié sous lequel tout est stocké.
On aura une belle arborescence de ce type :

/ma/racine/des/maildirs/
        - /mon.domaine.fr/
                - user1
                        - cur
                        - new
                        - tmp
                        + .autre.sous.rep.de.maildir.genre.Sent
                + user2
        - /autre.domaine.a.moi.fr/
                + userX

Donc, disons que que le répertoire racine de stockage des boîtes mails sera /vmailboxes. On crée l’utilisateur avec un ID arbitraire :

groupadd -g 5000 vmail
useradd -g vmail -u 5000 vmail -d /vmailboxes -m

Attention, vous allez aussi recopier le contenu de /etc/skel dans /vmailboxes, le home de « vmail ». Ce n’est pas forcément utile. Adaptez au besoin.

On indique tout ça à postfix

Dans un premier temps, je n’ajoute pas toute la conf dans /etc/postfix/main.cf. On va y aller progressivement vu ce qu’on vient d’installer. On ajoute donc :

virtual_alias_domains =
virtual_alias_maps = hash:/etc/postfix/virtual,proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual_domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailboxes.cf
virtual_mailbox_base = /vmailboxes
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
virtual_create_maildirsize = yes
virtual_maildir_extended = yes
transport_maps = proxy:mysql:/etc/postfix/mysql-virtual_transports.cf
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

Les fichiers de conf MySQL en « mode proxy » (si on peut dire) permettent d’optimiser les accès en conservant en mémoire le contenu. Pratique pour éviter une tonne d’accès disque inutile.

N’oubliez pas de générer le fichier virtual.db, la « version base de données » associée au fichier « virtual ». Il vous sert à faire suivre par exemple certains comptes locaux vers d’autres adresses e-mails. Pour centraliser vos remontées de serveur autre part.

Rechargez postfix, ça devrait bien se passer. Allez voir dans /var/log/mail.info ou syslog sinon.
On va pouvoir tester.

Quelques tests de livraison de mails

Pour créer une boîte, il faudra au minimum :

• Avoir déclaré le domaine qu’on gère
• Avoir déclaré le compte
• Avoir envoyé un mail de bienvenue, localement, pour forcer la création de boîte (arborescence
• Eventuellement avoir ajouté des sous-répertoires pour que le webmail (si vous en mettez un) soit content : Sent, Trash, Drafts, Junk.
  

Ajout d’un domaine

Tout comme en postfix « normal », on indique dans « mydestination » la liste des noms de domaines gérés, il faut ici les indiquer dans la base. Et les supprimer de « mydestination » si vous les gériez localement jusqu’alors. On crée simplement un enregistrement en base :

INSERT INTO domains (domain) VALUES ('mxtest.mondomaine.fr');

(Je suppose que mxtest.mondomaine.fr existe et que l’enregistrement MX existe aussi et pointe vers notre serveur.

Création d’un utilisateur

Simplissime, dans la base aussi :

INSERT INTO users (email, password) VALUES ('jacques@mxtest.mondomaine.fr', ENCRYPT('mon_pass_en_clair'));

Initialisation de sa boîte mail

Connecté localement, par exemple, sur la machine, envoyez un mail en ligne de commande, avec mailx, mutt. Ce que vous voulez.
Là , ô magie, vous devriez voir l’arborescence /vmailboxes se peupler, par exemple avec /vmailboxes/mxtest.mondomaine.fr/jacques/
C’est une arborescence « Maildir » classique, avec cur, new, tmp.
Si le mail est arrivé, on peut pour l’instant le lire en ligne de commande en allant dans le répertoire, tout bêtement.

Création des autres sous-répertoires

Dans cette procédure de création d’un compte, je suggère d’ajouter, pour le webmail, la création des répertoires habituels d’un compte en IMAP. Si vous ne comptez livrer que des boîtes récupérables en POP, ne vous cassez pas la tête, c’est inutile.
Sinon :

su - vmail
cd /vmailboxes/mxtest.mondomaine.fr/jacques
for i in Sent Trash Drafts Junk
do
        maildirmake .$i #le . est important
done

Vous devriez voir les sous-répertoires .Sent, .Junk etc avec à chaque fois le cur/tmp/new et des permissions restreintes à l’utilisateur vmail.

Voilà , la boîte sait recevoir et postfix sait gérer nos comptes virtuels, pour livrer le courier dans les boîtes virtuelles.

Abonnement aux répertoires IMAP ; pour le webmail ou la consultation IMAP

Si besoin, pensez à inclure la création du fichier suivant dans votre procédure de création de boîte mail :

mxtest:/vmailboxes/mxtest.mondomaine.fr/jacques# cat courierimapsubscribed
INBOX
INBOX.Sent
INBOX.Drafts
INBOX.Trash
INBOX.Junk

Annexe : création d’un alias

Dans la table forwardings, à base de :

INSERT INTO forwardings VALUES ('mon_alias@bla.fr', 'dest1@toto.fr', 'dest2@tata.fr');

Actif immédiatement. Pas plus compliqué que ça .

Partie lecture des mails, via « courier-* » utilisant MySQL pour l’authentification

Ici, on voit créer les services POP, IMAP et leurs versions sécurisées. Le tout sur fond d’authentification des utilisateurs définis en base MySQL.

Indiquer au « daemon » courier d’utiliser MySQL

Simplement, dans /etc/courier/authdaemonrc, changer la liste des modules utilisés pour l’authentification :

#authmodulelist="authpam"
authmodulelist="authmysql"

Dans /etc/courier/authmysqlrc, il faut positionner les variables suivantes :
MYSQL_SERVER localhost
MYSQL_USERNAME mail_adm
MYSQL_PASSWORD monpassadmin
MYSQL_PORT 0
MYSQL_DATABASE postfix
MYSQL_USER_TABLE users
MYSQL_CRYPT_PWFIELD password
MYSQL_UID_FIELD 5000
MYSQL_GID_FIELD 5000
MYSQL_LOGIN_FIELD email
MYSQL_HOME_FIELD « /vmailboxes »
MYSQL_MAILDIR_FIELD CONCAT(SUBSTRING_INDEX(email,'@',-1),’/',SUBSTRING_INDEX(email,'@',1),’/')
#MYSQL_NAME_FIELD name # NE PAS LAISSER CETTE VARIABLE, voir plus bas, cas d’erreur pour moi

Ici, bien évidemment, les valeurs indiquées reflètent les noms choisis en base.

Générer les certificats pour le POP3S et IMAPS

Cette partie est optionnelle, si vous ne voulez pas du POP3S et IMAPS. Dans ce cas vous pouvez aussi désinstaller courier-*-ssl.

On modifie les fichiers de conf de génération des certificats des daemon POP et IMAP sécurisés :

mxtest:/etc/courier# cat pop3d.cnf

RANDFILE = /usr/lib/courier/pop3d.rand

[ req ]
default_bits = 1024
encrypt_key = yes
distinguished_name = req_dn
x509_extensions = cert_type
prompt = no

[ req_dn ]
C=FR
ST=France
L=PARIS
O=Courier Mail Server
OU=Automatically-generated POP3 SSL key
CN=mondomaine.fr
emailAddress=certif@mondomaine.fr

[ cert_type ]
nsCertType = server

Et pour, l’IMAP :

mxtest:/etc/courier# cat imapd.cnf

RANDFILE = /usr/lib/courier/imapd.rand

[ req ]
default_bits = 1024
encrypt_key = yes
distinguished_name = req_dn
x509_extensions = cert_type
prompt = no

[ req_dn ]
C=FR
ST=France
L=PARIS
O=Courier Mail Server
OU=Automatically-generated IMAP SSL key
CN=mondomaine.fr
emailAddress=certif@mondomaine.fr

[ cert_type ]
nsCertType = server

Et on génère les certificats à partir de ces modèles. Ca ne fait que connaître à l’avance certains paramètres :

mxtest:/etc/courier# mkimapdcert
cp: not writing through dangling symlink `/usr/lib/courier/imapd.pem'
chmod: cannot operate on dangling symlink `/usr/lib/courier/imapd.pem'
chown: ne peut effectuer une déférence sur `/usr/lib/courier/imapd.pem': Aucun fichier ou répertoire de ce type
Generating a 1024 bit RSA private key
................++++++
....++++++
writing new private key to '/usr/lib/courier/imapd.pem'
-----
1024 semi-random bytes loaded
Generating DH parameters, 512 bit long safe prime, generator 2
This is going to take a long time
..............+.....................................................................................+..+.....................
.........+.............................+....+...+........+...................................................................
.............+..........+...........+..+...+..............................+....................+......................+......
........................+.....+.+......+..........................................................+..........................
.........................................................+...........+.........+.......................+.....................
..+..........++*++*++*++*++*++*
subject= /C=FR/ST=France/L=PARIS/O=Courier Mail Server/OU=Automatically-generated IMAP SSL 

key/CN=mondomaine.fr/emailAddress=certif@mondomaine.fr
notBefore=Oct  7 15:17:54 2009 GMT
notAfter=Oct  7 15:17:54 2010 GMT
SHA1 Fingerprint=9D:62:E6:CF:B7:39:80:C8:4E:F9:09:9C:61:36:14:8F:0B:EF:3C:6E

Et :

mxtest:/etc/courier# mkpop3dcert
cp: not writing through dangling symlink `/usr/lib/courier/pop3d.pem'
chmod: cannot operate on dangling symlink `/usr/lib/courier/pop3d.pem'
chown: ne peut effectuer une déférence sur `/usr/lib/courier/pop3d.pem': Aucun fichier ou répertoire de ce type
Generating a 1024 bit RSA private key
..++++++
..................++++++
writing new private key to '/usr/lib/courier/pop3d.pem'
-----
1024 semi-random bytes loaded
Generating DH parameters, 512 bit long safe prime, generator 2
This is going to take a long time
...............+..........................++*++*++*++*++*++*
subject= /C=FR/ST=France/L=PARIS/O=Courier Mail Server/OU=Automatically-generated POP3 SSL 

key/CN=mondomaine.fr/emailAddress=certif@mondomaine.fr
notBefore=Oct  7 15:18:10 2009 GMT
notAfter=Oct  7 15:18:10 2010 GMT
SHA1 Fingerprint=DD:8D:7C:0D:87:9D:19:9D:62:BE:5B:9A:B2:D8:43:80:CF:47:E2:14

Redémarrer tout ce bazar

Ayé, tout est prêt, les certificats sont générés, on redémarre tout ce monde :

/etc/init.d/courier-authdaemon restart
/etc/init.d/courier-imap restart
/etc/init.d/courier-imap-ssl restart
/etc/init.d/courier-pop restart
/etc/init.d/courier-pop-ssl restart

Tests pour l’envoi, quelques erreurs analysées

Déjà , faites un telnet sur chaque port, 143, 993, 110, 995 pour voir si ça répond bien.
Ensuite, testez chaque protocole. Par exemple avec Thunderbird. Sur un poste Windows, pensez à la version « portable » qui n’interfèrera pas avec votre actuel Thunderbird. Sous Linux, vous pouvez jouer avec vos ~/.mozilla-thunderbird (j’ai plus le nom précis en tête) pour ne pas abîmer votre conf actuelle.

Erreurs rencontrées

Ces erreurs m’ont permis de découvrir la commande authtest pour faire des tests d’aut

Oubli de package

J’ai commencé par tester l’authentification IMAP en local (depuis un webmail, roundcube, installé sur la même machine). Ca ne passait pas. J’ai testé depuis Thunderbird, pareil (pas étonnant), mais cette fois ça a généré un message dans les logs, genre syslog ou mail.info je ne sais plus :

Oct  8 16:10:32 ns305192 authdaemond: libauthmysql.so: cannot open shared object file: No such file or directory

Oops, il manquait le package courier-authlib-mysql.
Heureusement, ce ne sera pas votre cas, c’est bien écrit dans le aptitude install du début.

Erreur sur MYSQL_NAME_FIELD

Ensuite, j’ai eu le droit à une vraie erreur :

Oct  8 16:53:56 serveur imapd: authentication error: Input/output error

C’est l’occasion de mentionner la commande authtest (faites man authtest. Ca peut aider :

authtest ducon@lajoie.fr monpasswd
Authentication FAILED: Input/output error

Activez le debug dans /etc/courier/authdaemonrc avec DEBUG_LOGIN=1, redémarrez le service et allez voir les logs. Ca m’a permis de voir les erreurs SQL :

Oct  8 18:39:21 ns305192 authdaemond: mysql_query failed, reconnecting: Unknown column 'name' in 'field list'

En cherchant un peu, j’ai vu qu’il restait le champ MYSQL_NAME_FIELD dans /etc/courier/authdaemonrc. Une fois modifié, ça passe :

mxtest:/etc/courier# !auth
authtest bla@bla.fr monpassword
Authentication succeeded.

     Authenticated: bla@bla.fr (uid 5000, gid 5000)
    Home Directory: /vmailboxes
           Maildir: mondomaine.fr/jacques/
             Quota: (none)
Encrypted Password: OXXXXgfT0lXjI
Cleartext Password: monpassword
           Options: (none)

A ce moment là, tout marche pour la récupération, webmail aussi (puisque IMAP aussi).

Partie authentification des utilisateurs, pour l’envoi

Pour bien comprendre, on va activer 2 modes : SASL et TLS – encore que le mode TLS reste optionnel. Vous pourriez dans ce cas désinstaller les paquets concernés.
Le premier (SASL) pour avoir un mécanisme d’authentification pour le SMTP « normal », port 25.
Le deuxième (TLS) pour avoir un mécanisme plus sécurisé, avec certificat etc, en TLS (anciennement SMTPS, ou SMTP avec SSL). C’est aussi sur le port 25 (pas 465), et, de ce que j’en ai compris, ça tend à remplacer le SMTPS, sur port 465. C’est expliqué là et j’ai peut-être un peu abrégé l’explication violemment.

Paramétrage de toute la chaîne postfix/sasl/pam/mysql

Pour ne pas se perdre, il faut comprendre que postfix va déléguer l’authentification à une couche d’abstraction, SASL. On va dire à SASL de se baser sur le mécanisme PAM (Pluggable Authentication Module) et on va dire à PAM de contrôler les logins/passwords dans une base MySQL, en lui décrivant cette base. Pigé ?

Dire à SASL d’utiliser PAM pour l’authentification

SASL est chrooté (je ne me souviens plus bien, mais c’est le boxon, j’ai dû en parler dans des posts précédents)
On crée son environnement de « chroot » :

mkdir --parents /var/spool/postfix/var/run/saslauthd

Ensuite, on paramètre le daemon SASL correctement :
Positionner START=yes dans /etc/default/saslauthd
et modifier la fin du fichier comme suite :

#OPTIONS="-c -m /var/run/saslauthd"
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd -r"

Le reste du fichier par défaut doit être bon (DESC= »SASL Authentication Daemon », NAME= »saslauthd », MECHANISMS= »pam », MECH_OPTIONS= »", THREADS=5).

Vous pourrez voir au passage qu’on indique (via le paramètre MECHANISMS) à SASL d’utiliser PAM.
Maintenant, on va dire à PAM d’utiliser MySQL.

Demander à PAM d’utiliser MySQL en décrivant notre structure

Dans /etc/pam.d/smtp (à créer je crois), on indique qu’on va utiliser le module MySQL pour PAM :

mxtest:/etc/pam.d# cat smtp
auth    required   pam_mysql.so user=mail_adm passwd=monpassadmin host=127.0.0.1 db=postfix table=users usercolumn=email passwdcolumn=password crypt=1
account sufficient pam_mysql.so user=mail_adm passwd=monpassadmin host=127.0.0.1 db=postfix table=users usercolumn=email passwdcolumn=password crypt=1

Ensuite, dire à postfix de faire confiance à SASL pour l’authentification

Maintenant que SASL sait faire le boulot en base de données, on configure postfix pour authentifier les utilisateurs via SASL/PAM/MYSQL.
Dans /etc/postfix/sasl/, s’assurer du contenu de smtpd.conf :

pwcheck_method: saslauthd
mech_list: plain login
allow_plaintext: true
auxprop_plugin: mysql
sql_hostnames: 127.0.0.1
sql_user: mail_adm
sql_passwd: monpassadmin
sql_database: postfix
sql_select: select password from users where email = '%u'

Ajoutez l’utilisateur postfix au groupe sasl :

adduser postfix sasl

Enfin, expliquer à postfix de bien vouloir relayer les envois d’utilisateurs authentifiés via SASL. Ce qui donne par exemple dans /etc/postfix/main.cf :

smtpd_sender_restrictions = permit_sasl_authenticated
        reject_unauth_pipelining
        permit_mynetworks
        reject_unauth_destination
        reject_unknown_sender_domain
        reject_non_fqdn_sender
        check_policy_service inet:127.0.0.1:60000

C’est surtout le « permit_sasl_authenticated » qui nous intéresse là.
Voilà, postfix sait maintenant contrôler les expéditeurs avec l’aide de SASL. Ils doivent se signer et exister dans la base.
Maintenant on met en place le TLS, si vous voulez utiliser du vrai cryptage SSL pour l’authentification.

TLS : certificat et configuration

Dans /etc/postfix/,on crée les clefs de cryptage :

mxtest:/etc/postfix# openssl req -new -outform PEM -out smtpd.cert -newkey rsa:2048 -nodes -keyout smtpd.key -keyform PEM -days 3650 -x509
Generating a 2048 bit RSA private key
................................................+++
................................................+++
writing new private key to 'smtpd.key'
-----
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]:France
Locality Name (eg, city) []:PARIS
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MASOCIETE
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:mondomaine.fr
Email Address []:certif@mondomaine.fr

IMPORTANT : le « Common Name » doit correspondonre à votre /etc/mailname
Protégez la clef privée : chmod 640 smtpd.key
J’ai mis 10 ans, on aurait pu mettre plus ou moins, c’est le paramètre 3650 dans la ligne de commande.

On ajoute pour finir la conf suivante pour activer le TLS et indiquer le certificat à utiliser. Dans /etc/postfix/main.cf toujours :

smtpd_tls_cert_file=/etc/postfix/smtpd.cert
smtpd_tls_key_file=/etc/postfix/smtpd.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes # à  voir, ça peut interdire certains outlook buggés, je crois, de tête.
smtpd_sasl_authenticated_header = yes

C’est fini, on relance tout ça

Redémarrez postfix et saslauthd via les /etc/init.d/saslauthd restart et /etc/init.d/postfix restart qui vont bien.

Tests pour l’envoi, quelques erreurs analysées

Après un rapide telnet sur le port 25 (quand même), testez avec un « ehlo mailhost » puor voir si le TLS est activé :

250-STARTTLS

Ensuite, comme pour la réception des mails, testez avec un client mail correct, en mode SMTP normal et avec TLS.

Erreurs rencontrées

Fausse manip dans /etc/pam.d/smtp

Tous les tests SMTP, avec et sans TLS étaient KO. Dans les logs, simplement ça :

Oct 14 13:52:39 ns305192 postfix/smtpd[6759]: connect from bla.fr[81.Y.67.X]
Oct 14 13:52:41 ns305192 postfix/smtpd[6759]: warning: SASL authentication failure: Password verification failed
Oct 14 13:52:41 ns305192 postfix/smtpd[6759]: warning: bla.fr[81.Y.67.X]: SASL PLAIN authentication failed: authentication failure
Oct 14 13:52:41 ns305192 postfix/smtpd[6759]: warning: bla.fr[81.Y.67.X]: SASL LOGIN authentication failed: authentication failure
Oct 14 13:52:43 ns305192 postfix/smtpd[6759]: disconnect from bla.fr[81.Y.67.X]

Je me souviens avoir utilisé saslfinger pour tester et debugger. Essayez-le.
Au final, je m’étais simplement trompé dans le mot de passe MySQL du fichier /etc/pam.d/smtp

Quotas

Sujet totalement optionnel. J’ai besoin dans mon cas de pouvoir affecter des quotas par utilisateur.
Postfix ne gère pas les quotas nativement, il faut appliquer un patch. Donc recompiler. Ou trouver une source, mais au niveau mise à jour de sécurité, vous dépendez alors du type qui maintient le dépôt.
J’ai préféré appliquer moi-même le patch.
Le patch est donné par ce projet : http://vda.sourceforge.net. Il est disponible pour toutes les versions postfix, notamment la 2.5.5, actuellement celle de Debian/Lenny. 32 ou 64 bits.

Ajout du dépôt de sources

D’abord, dans mon cas, j’ajoute un dépôt de sources, via la ligne suivante dans /etc/apt/sources.list :

deb-src ftp://ftp2.fr.debian.org/debian/ lenny main

Après un aptitude update, on va télécharger les sources et tout le bazar pour compiler.

Récupération des sources

serv:/etc/postfix# apt-get build-dep postfix
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les NOUVEAUX paquets suivants seront installés :
  build-essential comerr-dev debhelper dpkg-dev g++ g++-4.3 gettext hardening-wrapper html2text intltool-debian libcdb-dev libcdb1 libdb-dev libdb4.6-dev libfile-remove-perl
  libkadm55 libkrb5-dev libldap2-dev libmail-box-perl libmail-sendmail-perl libmime-types-perl libmysqlclient15-dev libobject-realize-later-perl libpcre3-dev libpcrecpp0
  libpq-dev libsasl2-dev libssl-dev libstdc++6-4.3-dev libuser-identity-perl lsb-release po-debconf tinycdb zlib1g-dev
0 mis à jour, 34 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 22,7Mo dans les archives.
Après cette opération, 69,1Mo d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer [O/n] ?

Ensuite, on récupère les sources de postfix :

serv:/etc/postfix# cd /usr/src
serv:/usr/src# apt-get source postfix

Ca download et décompresse (et gueule car je n’ai pas mis la clef GPG blablabla pour vérifier la signature du paquet, tout ça).

Récupération du patch, compilation

On récupère le patch qui va bien pour notre version postfix et on génère les .deb

cd /usr/src
wget http://vda.sourceforge.net/VDA/postfix-2.5.5-vda-ng.patch.gz
gunzip postfix-2.5.5-vda-ng.patch.gz
cd postfix-2.5.5
patch -p1 < ../postfix-2.5.5-vda-ng.patch
dpkg-buildpackage

Remplacement du postfix officiel

Une fois placé dans /usr/src, un simple dpkg -i postfix_2.5.5-1.1_i386.deb postfix-mysql_2.5.5-1.1_i386.deb suffit à remplacer postfix et son extension mysql. Ca ne flingue même pas la conf actuelle. Bref, nickel.

On ajoute le champ quota, on indique à postfix et courierauth

Dans la base de données, on ajoute la colonne. J'ai choisi 20 Mo par défaut.

mysql> alter table users add quota bigint (20) default '20971520' after password;
Query OK, 1 row affected (0.10 sec)
Records: 1  Duplicates: 0  Warnings: 0

mysql> desc users;
+----------+-------------+------+-----+----------+-------+
| Field    | Type        | Null | Key | Default  | Extra |
+----------+-------------+------+-----+----------+-------+
| email    | varchar(80) | NO   | PRI | NULL     |       |
| password | varchar(20) | NO   |     | NULL     |       |
| quota    | bigint(20)  | YES  |     | 20971520 |       |
+----------+-------------+------+-----+----------+-------+
3 rows in set (0.00 sec)

Le alter s'est occupé de mettre la valeur par défaut sur les comptes existants

On crée alors la requête qui vérifie les quotas :

mxtest:~# cat /etc/postfix/mysql-virtual_mailbox_limit_maps.cf
user = mail_adm
password = monpassadmin
dbname = postfix
query = SELECT quota FROM users WHERE email='%s'
hosts = 127.0.0.1

Pensez à priver l'accès à ce fichier.

Et on ajoute cette notion de limite dans notre postfix-qui-sait-gérer-les-quotas, dans /etc/postfix/main.fr :

virtual_mailbox_limit_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailbox_limit_maps.cf
virtual_mailbox_limit_override = yes
virtual_maildir_limit_message = "The user you are trying to reach is over quota - L'utilisateur que vous cherchez a contacter a depasse son quota de mails"
virtual_overquota_bounce = yes

Sans oublier d'ajouter "$virtual_mailbox_limit_maps" dans la variable "proxy_read_maps".

Indication des quotas à "courier"

On précise à courier qu'il y a des quotas en créant ou décommentant la variable suivante :

mxtest:~# grep quota /etc/courier/authmysqlrc
MYSQL_QUOTA_FIELD       quota

On recharge le tout, on teste, on se congratule. Youpi, c'est fini.

Ce que je n'ai pas traité

j'ai pas joué avec les transports

Pas besoin dans mon cas.

Avoir un procmailrc par utilisateur ?

Aucune idée, je verrai plus tard.
En effet, où doit-on stocker le .procmailrc ??? ou alors faire un /etc/procmailrc général qui éventuellement trie par destinataire... lourd.

Désactivation de protocole par utilisateur

Exemple, besoin de désactiver le webmail ou le POP pour un utilisateur ? A priori, avec les "critères supplémentaires" que l'on peut passer dans les fichiers .cf de description de requêtes, ça doit être jouable. Je n'ai pas cherché car pas encore eu besoin.
Evidemment, il faudra ajouter une/des colonne dans la table, sûrement un booléen indiquant si le protocole est accepté pour l'utilisateur X.

Alerte sur les dépassements de quota

Pas eu encore le temps, mais il faudra y penser pour détecter les boulets qui ont des boîtes pleines et ne comprennent pas pourquoi ils ne reçoivent rien.
Je n'ai pas encore regardé : chapitre 11 dans cette page.
Voilà, j'espère que ça roulera pour votre installation et que vous aurez ainsi une belle plateforme de mails.

Ce type d’installation peut tout à fait convenir pour des petites et moyennes entreprises (quelques centaines de personnes), sur un serveur moyennement puissant. Pour faire simple.

Encore une doc sur ce sujet ?

Oui on s’excuse, mais comme d’habitude avec Debian, tout est déjà prêt à fonctionner et pourtant, on trouve généralement des docs de personnes mettant en place l’outil en recompilant les sources, en prenant des fichiers de conf à droite à gauche, en démolissant le beau travail déjà accompli par les packageurs Debian.
Mon approche reste la même : Debian a fait le boulot pour moi, j’en profite.
Au final, cet article est simplement brodée autour du README.Debian de chaque paquet qu’on va installer (surtout amavisd-new) et de quelques autres docs glanées sur le web expliquant tel ou tel paramètre, un peu plus que la doc officielle.
Mais comme rares sont les gens qui lisent les README, mon article devrait quand même intéresser quelques lecteurs, je l’espère.

Ce dont je ne parle pas

Je ne parle pas de l’aspect lecture des mails (en POP, en IMAP, renvoi vers un autre backend (Exchange ?)), mais juste au nettoyage et au blocage amont des spams et virus.
Je pars d’ailleurs d’une machine avec un postfix minimaliste sachant envoyer et recevoir des mails.
Vous pouvez vous reporter à ma doc Debian pour ce cas là, elle décrit en plus de postfix :
- la mise en place de postgrey (voyez l’intérêt ici)
- la mise en place de quelques blocages par blacklists (RBL & co)
- procmail
Je ne parle pas non plus du montage d’un backup MX. Probablement lors d’un prochain article.

Enfin, je colle tous les éléments de ce serveur sur une unique machine physique. Vous pourriez séparer les éléments. A ce moment-là, un peu de raisonnement et une lecture des documentations officielles que je cite me paraît judicieux. Cet article se limiterait alors,pour vous, à comprendre le rôle de chaque morceau, à appréhender la configuration de base et à partir du coup dans la bonne direction.

Comme à mon habitude, je décris aussi quelques bêtises et oublis que j’ai pû rencontrer, ça aidera à débugger et ça explique des choses.

Pré-requis

Etre sur une Debian stable (Lenny) avec le dépôt Debian « volatile » opérationnel (pour les mises à jour de clamav).
Le dépôt « volatile », c’est ça :

moi@srv:~$ cat /etc/apt/sources.list | grep vola
deb http://volatile.debian.org/debian-volatile lenny/volatile main contrib non-free

C’est un dépôt créé pour palier aux problèmes des applications mises à jour constamment (les bases anti-virus par exemple, tout autant que des outils de mssageries instantanées qui voient les protocoles sous-jascents évoluer régulièrement). Si on restait sur le rythme Debian (tous les 2 ans ; bientôt 6 mois), on aurait des applications inutiles.

Rôle de chaque élément

D’abord le schéma qui va bien :

Cheminement du mail

1. Postfix reçoit donc la connexion d’un serveur voulant envoyer un mail.
2. Grâce à postgrey, il va filtrer déjà un bon paquet de spams qui n’atteindra pas la suite des composants (et donc pas de charge réseau/cpu inutile).
3. Donc au besoin, le mail revient plus tard, suite à greylisting.
4. Postfix passe le relai à amavisd-new qui orchestre les appels à :
5. ClamAV qui fait ce qu’il a à faire
6. et à spamassassin, lui-même gérant pyzor/razor
7. Retour du mail nettoyé (disons, avec les en-têtes qui vont bien) vesr postfix
8. Postfix livre le mail (dans la boîte de l’utilisateur, au backend, à je ne sais quel autre élément en aval.

Doc officielle, doc complémentaire

Lire /usr/share/doc/amavisd-new/README.postfix.gz est un passage obligé, je trouve. Je me base dessus et je fais certains choix qui pourraient ne pas être les votres. Je n’invente pas grand chose, tout est quasiment dedans.
Si vous êtes sur une installation déjà en production, vous pourriez être intéressés par le paramètre soft_bounce, voyez ici via un :
postfix -e "soft_bounce = yes"

Autre doc intéressante : http://www200.pair.com/mecham/spam/spamfilter20090215.html. A noter : l’auteur n’utilise pas trop le boulot de Debian, donc beaucoup de choses à reparamétrer dans son cas, sans compter les manips à la main : récupérer le fichier de conf X, prendre tel binaire postfix plutôt que celui de la distrib. Bref, pas très Debian-style à mon goût.
Mais au moins il donne une bonne explication de certains paramètres, à vous de voir.
Enfin, cette doc décrit le montage complet d’une Debian, installation, serveur DNS etc. On s’en fout pas mal dans le cas présent. Commencez donc à lire cette doc à partir du mot « postfix anti-spam settings: ». A peu près au milieu.
Vous verrez passer dans les chapitres qui suivent cet endroit quelques paramètres importants sur le comportement des différents outils, les destinataires des notifications de mails vérolés etc, quelques optimisations sur les niveaux de spam acceptables etc. Mon article reprend certaines de ces suggestions et de ma propre expérience.
Cette doc va aussi plus loin : installation de DCC (Distributed Checksum Clearinghouses) et des outils de statistiques. Je n’en parle pas (pour l’instant), on verra avec des articles ultérieurs.

Bon, allez, on installe tout ça.

Installation des logiciels

aptitude install clamav clamav-daemon clamav-freshclam
aptitude install amavisd-new
aptitude install lha arj rar unrar nomarch lzop cabextract razor pyzor p7zip-full pax zip unzip lha zoo

Certains des paquets ici sont discutables, pour les pros du ça-pue-c-est-pas-libre-(tm). Moi je veux simplement analyser un maximum de contenu de mails, pièces jointes en format moins courants y compris.
Les outils type « décompression » serviront à ClamAV pour analyser les contenus de pièces jointes.

Les parties postfix, postgrey, spamassassin et les Maildir sont déjà expliqués dans mes docs/blog à différents endroits.
Deux nuances tout de même :
Je suppose enfin que votre spamassassin est en mode daemon (donc « spamd » tourne) car vous avez mis à 1 le paramètre ENABLED dans /etc/default/spamassassin.
Par rapport à ce que j’explique sur procmail, j’ai opté pour une conf standard pour tous dans /etc/procmailrc plutôt que dans chaque ~/.procmailrc.

Paramétrage de base

Configuration postfix <=> amavis

D’abord, on configure un canal de communication postfix => amavis en mode SMTP et pas LMTP (voir le /usr/share/doc/amavisd-new/README.postfix.gz). J’ajoute à la fin de /etc/postfix/master.cf des lignes suivantes :

amavisfeed unix    -       -       n       -       2     smtp
     -o smtp_data_done_timeout=1200
     -o smtp_send_xforward_command=yes
     -o smtp_tls_note_starttls_offer=no

Le nom « amavisfeed » est libre. Mais c’est le nom du tuyau que vous venez de créer. Il faudra utiliser ce nom plus bas (dans main.cf)

Puis le canal retour (message reinjection), toujours à la fin de /etc/postfix/master.cf :

127.0.0.1:10025 inet n    -       n       -       -     smtpd
     -o content_filter=
     -o smtpd_delay_reject=no
     -o smtpd_client_restrictions=permit_mynetworks,reject
     -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 smtpd_restriction_classes=
     -o mynetworks=127.0.0.0/8
     -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,no_milters
     -o local_header_rewrite_clients=
     -o smtpd_milters=
     -o local_recipient_maps=
     -o relay_recipient_maps=

Enfin, on active le tuyau postfix => amavisd-new pour permettre l’analyse : (pas de tri, on balance tout ; on pourrait restreindre par domaine, adresse émettrice etc). C’est dans /etc/postfix/main.cf :

content_filter=amavisfeed:[127.0.0.1]:10024

Dans cette configuration par défaut, il faut que les ports 10024 et 10025 (localement) soient libres. Les paramètres sont décrits dans la doc en .gz mentionnée ci-dessus. L’idée, en gros, est de créer un autre serveur SMTP, local uniquement sur le port 10024, avec une conf postfix indépendante et vierge – en gros – car on sait que les messages arrivant là seront passés par amavis, donc ils seront propres/nettoyés. Cette seconde instance postfix sera la porte d’entrée pour les retours d’amavisd-new.

Tests des briques de la communication postfix <=> amavisd-new

Là, on peut tenter un /etc/init.d/postfix reload.

Ecoute de amavis

Le 10024 répondait déjà (car c’est le port d’écoute de amavis, lancé depuis qu’on l’a installé) :

# telnet localhost 10024
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
220 [127.0.0.1] ESMTP amavisd-new service ready

Ecoute du 2è postfix (la voie de retour d’amavis)

Le port 10025 ne fonctionne qu’après la conf dans master.cf et un postfix reload :

# telnet localhost 10025
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
220 srv.net ESMTP Postfix (Debian/GNU)

Tests des décodeurs de pièces jointes

On peut voir les « décodeurs » qu’il manque dans /var/log/mail.log.

/var/log/mail.log:Aug 25 17:18:21 srv amavis[28164]: No decoder for       .lha

Dans le cas ci-dessus, on peut conclure que le paquet lha n’est pas installé.
Attention, la doc dit quelque part de se méfier des décodeurs pour analyse des TNEF. Vous risquez de perdre les mails écrits en RTF par Outlook-le-casse-couipied.

Test du retour de mails

On teste un envoi de mail à amavis, et donc le retour :

# telnet localhost 10024
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
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:

250 2.1.5 Recipient
 OK
data
354 End data with .
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.0.0 Ok, id=28165-03, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 5FD7D9C4057
quit
221 2.0.0 [127.0.0.1] amavisd-new closing transmission channel
Connection closed by foreign host.

Résultats dans /var/log/mail.log (le retour à postfix prend quelques secondes) :

# tail /var/log/mail.log
Aug 27 11:37:43 srv postfix/smtpd[681]: connect from localhost.localdomain[127.0.0.1]
Aug 27 11:37:43 srv postfix/smtpd[681]: 5FD7D9C4057: client=localhost.localdomain[127.0.0.1]
Aug 27 11:37:43 srv postfix/cleanup[683]: 5FD7D9C4057: message-id=<20090827093743.5FD7D9C4057@srv.net>
Aug 27 11:37:43 srv postfix/qmgr[30259]: 5FD7D9C4057: from=<>, size=724, nrcpt=1 (queue active)
Aug 27 11:37:43 srv amavis[28165]: (28165-03) Passed BAD-HEADER, <> ->
, quarantine: 5/badh-5kHJ7I-xUr2T, mail_id: 5kHJ7I-xUr2T, Hits: -, size: 175, queued_as: 5FD7D9C4057, 81992 ms
Aug 27 11:38:39 srv postfix/local[684]: 5FD7D9C4057: to=, orig_to=
, relay=local, delay=56, delays=0.14/0/0/56, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail -a "$EXTENSION")
Aug 27 11:38:39 srv postfix/qmgr[30259]: 5FD7D9C4057: removed

Activation de l’appel amavisd-new <=> ClamAV+Spamassassin

Enlevez les commentaires, c’est tout

C’est expliqué ici : /usr/share/doc/amavisd-new/README.Debian.
Comme d’hab, les fichiers de conf pré-machés par Debian sont très bien et attention à ne pas tenir trop compte de documentation de bidouilleurs qui paramètrent tout ça à la sauce pas-très-Debian.
D’après le README cité ci-dessus, la conf s’active dans /etc/amavis/conf.d/15-content_filter_mode. Il suffit de décommenter les 4 lignes suivantes dans /etc/amavis/conf.d/15-content_filter_mode : (2 pour ClamAV, 2 pour spamassassin)

@bypass_virus_checks_maps = (
   \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re);
@bypass_spam_checks_maps = (
   \%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);

En faisant celà, on active la conf définie dans les autres fichiers de /etc/amavis/conf.d/, exemple 15-av_scanners pour les anti-virus. Il s’agit là aussi de modèle de configuration standard de tout un tas d’outils connus (une bonne 15aine d’anti-virus dont NOD32, F-Prot, Grisoft, KAV, du symantec etc). Amavisd-new va donc charger les AV qu’il trouve. De même pour spamassassin.

Petit oubli pour ClamAV

On se paye une erreur :

Aug 27 16:03:09 mon_srv amavis[17143]: (17143-01) (!!)run_av (ClamAV-clamd) FAILED - unexpected , output="/var/lib/amavis/tmp/amavis-20090827T160309-17143/parts: lstat() failed: Permission denied. ERROR\n"
Aug 27 16:03:09 mon_srv amavis[17143]: (17143-01) (!!)ClamAV-clamd av-scanner FAILED: CODE(0x90a9148) unexpected , output="/var/lib/amavis/tmp/amavis-20090827T160309-17143/parts: lstat() failed: Permission denied. ERROR\n" at (eval 86) line 527.
Aug 27 16:03:09 mon_srv amavis[17143]: (17143-01) (!!)WARN: all primary virus scanners failed, considering backups

L’utilisateur clamav doit être dans le groupe amavis, on fait ce qui est dit dans le README.Debian de amavisd-new :

# adduser clamav amavis
Ajout de l'utilisateur « clamav » au groupe « amavis »...
Ajout de l'utilisateur clamav au groupe amavis
Terminé.

Et on contrôle le paramètre suivant dans la conf ClamAV : AllowSupplementaryGroups true. C’est déjà positionné dans le /etc/clamav/clamd.conf fraîchement dépaqueté. Vérifiez tout de même.
Et on redémarre ClamAV évidemment.

On peaufine certains paramètres

Destinataires des alertes

Pensez à bien ajuster les destinataires de « abuse », « postmaster » et « root » de votre serveur. Soit en modifiant les variables comme :

$virus_admin
$banned_admin
$mailfrom_notify_admin OU recip OU spamadmin
$hdrfrom_notify_sender

Soit en étant sûr que ces comptes par défaut (et obligatoires, surtout postmaster) font bien suivre les mails vers une adresse que vous lisez/survolez.

Voyez la doc mentionnée plus haut pour des suggestions à propos des variables $virus_admin & co.

Resctrictions de base de postfix

Je n’en parle pas trop, mais pensez à la conf de base de postfix, notamment votre paramètre smtpd_sender_restrictions dans /etc/postfix/main.cf.
Utilisez un service web quelconque sur Google pour valider que votre serveur n’est pas un open-relay.

Pièces jointes

Dans /etc/amavis/conf.d/20-debian_defaults, je suggère d’élargir la liste des pièces jointes interdites (par extension). Plus besoin de sanitizer, c’est intégré dans amavisd-new. Exemple :

### JACQUES
#  qr'.\.(exe|vbs|pif|scr|bat|cmd|com|cpl)$'i, # banned extension - basic
 qr'.\.(ade|adp|app|bas|bat|chm|cmd|com|cpl|crt|emf|exe|fxp|grp|hlp|hta|
        inf|ins|isp|js|jse|lnk|mda|mdb|mde|mdw|mdt|mdz|msc|msi|msp|mst|
        ops|pcd|pif|prg|reg|scr|sct|shb|shs|vb|vbe|vbs|
        wmf|wsc|wsf|wsh)$'ix,  # banned ext - long
###

# qr'.\.(mim|b64|bhx|hqx|xxe|uu|uue)$'i,  # banned extension - WinZip vulnerab.

  qr'^\.(exe-ms)$',                       # banned file(1) types
# qr'^\.(exe|lha|tnef|cab|dll)$',         # banned file(1) types
### JACQUES
  qr'^\.(exe|lha|cab|dll)$', # OK pour TNEF, merci outlook
###

Comportement lors de détection de spam

EDIT 08/10/2009. Quelques variables importantes à positionner (écraser par rapport à la conf par défaut) :

[...]
serveur:/etc/amavis/conf.d# cat 50-user
$final_spam_destiny = D_DISCARD; # pour eviter de renvoyer des notifications inutiles a des zombies
$sa_tag_level_deflt  = undef; # pour toujours avoir le tag dans les headers, même si c'est pas du spam
$sa_tag2_level_deflt = 5.0; # d'habitude je mets 5, na !
$sa_kill_level_deflt = 12.0; # d'experience, a 10 on est deja bien bien sur que c'est du spam
[...]

Enfin, j’avais oublié un point important, la variable « @local_domains_acl ». Elle défini la liste des domaines sur lesquels spamassassin va intervenir. Les domaines non listés ici ne sont tout simplement pas pris en compte, donc pas analysés, donc pas « flaggés »…
Je ne l’avais pas vu au début car avec un seul domaine qui est le nom de la machine etc, tout va bien avec le choix par défaut de Debian dans 05-domain_id:@local_domains_acl = ( ".$mydomain" );.
Là où ça se complique, c’est quand vous gérez plusieurs domaines, suivant comment votre bousin est défini. Par exemple avec des domaines virtuels, gérés en base de données, c’est mort (prochain article à venir sur la gestion de domaines et d’utilisateurs virtuels).
J’ai donc forcé cette variable dans le fichier /etc/amavis/conf.d/50-user :

@local_domains_acl = ( ".maboite.fr", "un.autre.alias.net" );

A noter que là, je prends en charge les éventuels sous-domaines « toto.maboite.fr » (c’est voulu, grâce au point devant « maboite ») et uniquement « un.autre.alias.net », mais pas un domaine de mails qui s’appellerait « encore.un.autre.alias.net ». Pigé ?

Quarantaine

Où doivent aller les mails vérolés ? Par défaut, je suggère de ne rien toucher au paramètre $virus_quarantine_to, ainsi les mails vérolés vont dans une arborescence de /var/lib/amavis/virusmails. Jetez-y un oeil une fois des tests de détection effectués (voir ci-dessous, dernier chapitre).
Et documentez vous sur amavisd-release.

Décodeurs, suite et fin

Dans /etc/amavis/conf.d/01-debian, jouez avec les variables $unrar et autres qui vous intéressent (oui oui, unrar c’est pas libre, tout ça, installez le paquet vrms). Il vous faut les applications correspondantes. Voyez le log /var/log/mail.log pour savoir ce qu’il manque par rapport à votre conf.

spamassassin

If you use spamassassin with the Bayes database system, you should make sure
that the spamassassin configuration option « bayes_auto_expire 0″ is set in
spamassassin configure files. This disables the automatic expiration of tokens
which causes problems for amavisd-new when activated. The amavisd-new package
includes cron jobs that take care of syncing and expiring the token database
frequently.

Je ne mesure pas trop l’impact, à vrai dire, mais je suppose qu’il vaut mieux le faire, donc ajoutez bayes_auto_expire 0 dans la conf /etc/spamassassin/local.cf.

Mise à jour de l’anti-virus

Le programme freshclam est planifié automatiquement lors de l’installation de ClamAV. Vous pouvez contrôler sa bonne exécution (il tourne une fois par heure) dans :

srv:/etc# tail /var/log/clamav/freshclam.log
Received signal: wake up
ClamAV update process started at Thu Sep 10 15:25:18 2009
main.cvd is up to date (version: 51, sigs: 545035, f-level: 42, builder: sven)
daily.cld is up to date (version: 9791, sigs: 77548, f-level: 43, builder: guitar)
--------------------------------------
Received signal: wake up
ClamAV update process started at Thu Sep 10 16:25:18 2009
main.cvd is up to date (version: 51, sigs: 545035, f-level: 42, builder: sven)
daily.cld is up to date (version: 9791, sigs: 77548, f-level: 43, builder: guitar)
--------------------------------------

Testez avec EICAR

EICAR est un virus inoffensif. Essayez de vous envoyer des mails avec différentes pièces jointes fournies ici : http://securite-informatique.info/virus/eicar/. Vous validerez ainsi la réaction de votre serveur.
J’ai eu une erreur dans le mail.info lors de la détection du virus. Le serveur tente d’informer l’admin des virus, mais avec une légère erreur de syntaxe sur l’expéditeur :

Sep 21 15:33:37 ns305192 postfix/smtpd[20381]: warning: Illegal address syntax from localhost.localdomain[127.0.0.1] in MAIL command:

J’ai alors modifié la liste des expéditeurs de mails d’alertes. Dans le fichier /etc/amavis/conf.d/50-user :

$mailfrom_notify_admin='postmaster@chezmoi.fr';
$mailfrom_notify_recip='postmaster@chezmoi.fr';
$mailfrom_notify_spamadmin='postmaster@chezmoi.fr';
$mailfrom_to_quarantine='postmaster@chezmoi.fr';

J’ai trouvé la liste de toutes les adresses émettrices d’alertes sur ce site : http://www.radical-spam.org/documentations/amavisd-new.html. Il y a de belles explications sur les modèles de mails et d’autres trucs. Bref, à survoler.
Je n’ai pas trouvé comme pour postfix une commande permettant de voir les variables en mémoire d’amavisd-new. Si ça existe, je suis preneur.

Pour ceux qui n’utiliseraient pas encore de greylisting pour limiter le nombre de spams en entrée de ses serveurs de mails, j’explique comment mettre en place dans ma doc Debian et dans plusieurs articles sur ce blog.

Voici donc une capture d’un échange dans /var/log/mail.[info|log] d’un serveur envoyant un mail à cette architecture postfix/postgrey. Vous pouvez l’imprimer et l’afficher au-dessus de votre lit, c’est joli.

Rappel de la théorie

Le greylisting demande à l’émetteur de renvoyer le mail plus tard, disons 5 minutes. C’est un comportement normal et possible d’un serveur SMTP. Si l’expéditeur est complètement bidon (un zombie par exemple), cette réponse n’arrive jamais. Le mail – qui est un spam ou venant d’un serveur configuré avec les pieds – ne reviendra jamais et n’ira donc pas plus loin que la porte d’entrée du serveur. Pas de traitement anti-spam, rien. Economie de charge CPU etc.
Au bout de quelques mails effectivement reçus de la part de tel serveur, alors on le whiteliste car il semble au moins digne de confiance (je n’ai pas dit qu’il n’envoyait pas du spam). Attention au délai de réception pendant une journée ou 2.

Let’s go

Prise de contact

Aug 27 15:51:05 mon_srv postfix/smtpd[17150]: connect from le.nouvel.expediteur.fr[10.20.30.40]
Aug 27 15:51:06 mon_srv postgrey[12790]: action=greylist, reason=new, client_name=le.nouvel.expediteur.fr, client_address=10.20.30.40, sender=exped@iteur.fr, recipient=destin@mon_srv.fr
Aug 27 15:51:06 mon_srv postgrey[12790]: cleaning up old logs...
Aug 27 15:51:06 mon_srv postfix/smtpd[17150]: NOQUEUE: reject: RCPT from le.nouvel.expediteur.fr[10.20.30.40]: 450 4.2.0 : Sender address rejected: Greylisted, see http://postgrey.schweikert.ch/help/mon_srv.ovh.net.html; from= to= proto=ESMTP helo=
Aug 27 15:51:06 mon_srv postfix/smtpd[17150]: disconnect from le.nouvel.expediteur.fr[10.20.30.40]

On voit l’action de postgrey (action=greylist) au motif que ce serveur n’a pas encore été whitelisté (reason=new)
Avant dernière ligne : on informe le serveur expéditeur qu’il est greylisté, on en profite pour expliquer à l’admin d’en face qui (peut-être) lit les logs ce qu’est le greylisting.
Sous-entendu, on lui dit via le code retour 450 que la boite a un problème temporaire, sous-entendu, retente plus tard. Attention, on ne dit pas code 550 qui signifierait « la boite est morte définitivement ».

Maintenant on attend de voir s’il nous recontacte

Il revient, mais trop tôt

Une minute plus tard, on a :

Aug 27 15:52:06 mon_srv postfix/smtpd[17150]: connect from le.nouvel.expediteur.fr[10.20.30.40]
Aug 27 15:52:06 mon_srv postgrey[12790]: action=greylist, reason=early-retry (239s missing), client_name=le.nouvel.expediteur.fr, client_address=10.20.30.40, sender=exped@iteur.fr, recipient=destin@mon_srv.fr
Aug 27 15:52:06 mon_srv postfix/smtpd[17150]: NOQUEUE: reject: RCPT from le.nouvel.expediteur.fr[10.20.30.40]: 450 4.2.0 : Sender address rejected: Greylisted, see http://postgrey.schweikert.ch/help/mon_srv.ovh.net.html; from= to= proto=ESMTP helo=
Aug 27 15:52:06 mon_srv postfix/smtpd[17150]: disconnect from le.nouvel.expediteur.fr[10.20.30.40]

L’action est de le greylister à nouveau au motif qu’il est trop tôt (reason=early-retry (239s missing)). Le temps doit être donné dans la réponse d’indisponibilité temporaire mais ça ne se voit pas au niveau des logs).
Et on le renvoit dans ses pénates.
Le revoilà, mais encore trop tôt.< méchanceté gratuite>C’est un serveur Exchange, il ne doit rien comprendre à ce qu’on dit< /méchanceté gratuite>.

Aug 27 15:53:06 mon_srv postfix/smtpd[17150]: connect from le.nouvel.expediteur.fr[10.20.30.40]
Aug 27 15:53:08 mon_srv postgrey[12790]: action=greylist, reason=early-retry (177s missing), client_name=le.nouvel.expediteur.fr, client_address=10.20.30.40, sender=exped@iteur.fr, recipient=destin@mon_srv.fr
Aug 27 15:53:08 mon_srv postfix/smtpd[17150]: NOQUEUE: reject: RCPT from le.nouvel.expediteur.fr[10.20.30.40]: 450 4.2.0 : Sender address rejected: Greylisted, see http://postgrey.schweikert.ch/help/mon_srv.ovh.net.html; from= to= proto=ESMTP helo=
Aug 27 15:53:08 mon_srv postfix/smtpd[17150]: disconnect from le.nouvel.expediteur.fr[10.20.30.40]

̉Trop c’est trop : anvil

Maintenant, c’est simplement le processus « anvil » de postfix, le « contrôleur de nombre de sessions et taux de bourrinage » qui détecte que le serveur en face est un peu trop insistant (il vient trop souvent) :

Aug 27 15:56:28 mon_srv postfix/anvil[17153]: statistics: max connection rate 1/60s for (smtp:10.20.30.40) at Aug 27 15:51:05
Aug 27 15:56:28 mon_srv postfix/anvil[17153]: statistics: max connection count 1 for (smtp:10.20.30.40) at Aug 27 15:51:05
Aug 27 15:56:28 mon_srv postfix/anvil[17153]: statistics: max cache size 1 at Aug 27 15:51:05

On ferme carrément la connexion. Reviens plus tard on te dit.

Là il est calmé

Aug 27 16:03:09 mon_srv postfix/smtpd[17159]: connect from le.nouvel.expediteur.fr[10.20.30.40]
Aug 27 16:03:09 mon_srv postgrey[12790]: action=pass, reason=triplet found, delay=724, client_name=le.nouvel.expediteur.fr, client_address=10.20.30.40, sender=exped@iteur.fr, recipient=destin@mon_srv.fr

J’accepte son mail comme on voit ci-dessous (action=pass) au motif qu’on l’a déjà bien embêté (reason=triplet found). Au final, il y a aura eu pour ce mail 724 secondes de délai. Rappelez-vous que ça peut être gênant lors d’une mise en place sur un serveur déjà en prod.

La suite est l’enchaînement logique postfix :

Aug 27 16:03:09 mon_srv postfix/smtpd[17159]: 1E6B29C4057: client=le.nouvel.expediteur.fr[10.20.30.40]
Aug 27 16:03:09 mon_srv postfix/cleanup[17164]: 1E6B29C4057: message-id=<8DDA8A0D37FFCE449E93D51188CDBE5BEDA572@intern.srv.fr>
Aug 27 16:03:09 mon_srv postfix/qmgr[15006]: 1E6B29C4057: from=, size=6905, nrcpt=1 (queue active)
Aug 27 16:03:09 mon_srv postfix/smtpd[17159]: disconnect from le.nouvel.expediteur.fr[10.20.30.40]

On arrive dans amavisd-new :

Aug 27 16:03:09 mon_srv amavis[17143]: (17143-01) (!!)run_av (ClamAV-clamd) FAILED - unexpected , output="/var/lib/amavis/tmp/amavis-20090827T160309-17143/parts: lstat() failed: Permission denied. ERROR\n"
Aug 27 16:03:09 mon_srv amavis[17143]: (17143-01) (!!)ClamAV-clamd av-scanner FAILED: CODE(0x90a9148) unexpected , output="/var/lib/amavis/tmp/amavis-20090827T160309-17143/parts: lstat() failed: Permission denied. ERROR\n" at (eval 86) line 527.
Aug 27 16:03:09 mon_srv amavis[17143]: (17143-01) (!!)WARN: all primary virus scanners failed, considering backups

Aaaaah, ça foire (normal j’ai juste installé clamav, il est détecté par amavis, mais je n’ai rien configuré. Je dois avoir un problème de droits/groupes, ce genre-là. On verra dans mon prochain article qui décrira toute la mise en place.

Aug 27 16:03:10 mon_srv postfix/smtpd[17169]: connect from localhost.localdomain[127.0.0.1]
Aug 27 16:03:10 mon_srv postfix/smtpd[17169]: C2A8D9C405B: client=localhost.localdomain[127.0.0.1]
Aug 27 16:03:10 mon_srv postfix/cleanup[17164]: C2A8D9C405B: message-id=<8DDA8A0D37FFCE449E93D51188CDBE5BEDA572@intern.srv.fr>
Aug 27 16:03:10 mon_srv postfix/qmgr[15006]: C2A8D9C405B: from=, size=7349, nrcpt=1 (queue active)
Aug 27 16:03:10 mon_srv amavis[17143]: (17143-01) Passed CLEAN, [10.20.30.40] [10.20.30.40]  -> , Message-ID: <8DDA8A0D37FFCE449E93D51188CDBE5BEDA572@intern.srv.fr>, mail_id: xmX0C24kDlYt, Hits: -, size: 6905, queued_as: C2A8D9C405B, 1764 ms
Aug 27 16:03:10 mon_srv postfix/smtp[17165]: 1E6B29C4057: to=, orig_to=, relay=127.0.0.1[127.0.0.1]:10024, delay=1.9, delays=0.11/0/0/1.8, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=17143-01, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as C2A8D9C405B)
Aug 27 16:03:10 mon_srv postfix/qmgr[15006]: 1E6B29C4057: removed

Ci-dessus on a le baratin standard d’un amavis sans clamav (avec son anti-virus interne) qui finit par accepter le mail et le délivrer.

Voilà, c’est beau, on dirait du Rimbaud.

quel.qu.un@tele2.fr le 26/08/2009 16:06
            Le système de messagerie n'a pas pu remettre ce message mais n'a pas signalé de raison particulière. Vérifiez l'adresse du destinataire et réessayez d'envoyer le message. Dans le cas d'un nouvel échec, contactez votre administrateur système.
            < mailfe09.swip.net #4.0.0>

J’ai d’abord pensé à un problème passager lié sûrement au rachat par SFR/NEUF/CEGETEL. Mais le problème dure dans le temps…
Puis j’ai pensé à une sorte de blacklist où le serveur en face ne se donnerait même pas la peine de m’expliquer pourquoi il me jette.
Donc j’ai contacté postmaster@tele2.fr pour demander ; en anglais, car il y a un renvoi vers des bal @swip.net qui ne sont pas des français.

Réponse claire : suite au rachat, migration en cours, les clients sont informés, les boîtes n’existent plus.

Hello Jacques,
Tele2 Europe has divested its french operations.
We are in the middle of a migrationprocess with the buyer(www.sfr.se) of our french operations right now.

This involves that the customers chooses a new emailadress in SFR mailsystem.
The mailadress you are trying to reach has been moved to their system.

Best Regards
Jonas Johnsson
Postmaster
Tele2 Europe

(Et démerdez-vous pour contacter les gens qui se cachaient derrière cette adresse ; et si ce sont des clients tant pis)

Je ne connais personne « chez » tele2.fr, donc je n’ai pas d’information du client lambda.
Si vous en avez, n’hésitez pas à faire un commentaire.

Je doute qu’il suffise de remplacer tele2 par SFR dans l’adresse. Les clients vont sûrement en choisir une nouvelle. Risque de téléscopage trop gros avec les abonnés déjà existants chez SFR.

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  ducon.lajoie@aol.com
    SMTP error from remote mailer after initial connection:
    host mailin-04.mx.aol.com [64.12.138.57]: 554- (RTR:CH)  http://postmaster.info.aol.com/errors/554rtrch.html
    554  Connecting IP: xx.yy.zz.tt

------ This is a copy of the message, including all the headers. ------

Return-path: 

En allant voir sur http://postmaster.info.aol.com/errors/554rtrch.html, vous allez vite atterrir sur un merveilleux formulaire de « déblacklistage ».
ATTENTION : c’est de la merde en barre !!! (et je pèse mes mots)
Il y a notamment un fabuleux « test DNS » dont il faut copier le résultat.
Voici ce qu’il va vous arriver ensuite :

• si vous comptiez faire un « host -t MX aol.com », oubliez, le formulaire ne reconnait pas la réponse, il attend du nslookup à priori
• vous vous résignez alors à faire un « nslookup -q=mx aol.com » depuis un PC dans le coin, le formulaire n’en veut toujours pas
• OK, j’enlève mon C:\blabla\nslookup et je mets comme eux sur l’exemple « c:\nslookup… », toujours pas bon
• Google, peut-être qu’un autre mec a eu affaire à ce formulaire à chier, oui. Allez le voir, c’est la solution
• Ah, il faut supprimer la ligne avec C:\, toujours pas bon
• ahahah, je suis sur un XP français, je remplace « serveur » par « server », toujours pas bon
• Bon bordel, je vire tout, je copie le baratin exact de ce site (ci-dessus), je remplace l’IP XX.XX.XX.XX par l’IP de mon serveur blacklisté et comme ça, l’autre abruti de formulaire va lire ce qu’il attend. De toute manière, j’ai déjà vérifié que ma résolution MX était bonne, c’est juste ce formulaire pourri qui veut rien savoir.

Magie, ça passe !!! Maintenant, j’attends le retour…

J’aimerais bien discuter avec le mec qui a pondu un tel mécanisme daubesque…

Je recopie la réponse attendue, elle vaut cher :

Server:  ns3.o1.com
Address:  XX.XX.XX.XX <----- changez ça !!!!!!!!!!!!

Non-authoritative answer:
aol.com MX preference = 15, mail exchanger = mailin-02.mx.aol.com
aol.com MX preference = 15, mail exchanger = mailin-03.mx.aol.com
aol.com MX preference = 15, mail exchanger = mailin-04.mx.aol.com
aol.com MX preference = 15, mail exchanger = mailin-01.mx.aol.com
aol.com nameserver = dns-07.ns.aol.com
aol.com nameserver = dns-01.ns.aol.com
aol.com nameserver = dns-02.ns.aol.com
aol.com nameserver = dns-06.ns.aol.com
mailin-01.mx.aol.com    internet address = 205.188.156.248
mailin-01.mx.aol.com    internet address = 205.188.159.57
mailin-01.mx.aol.com    internet address = 64.12.139.249
mailin-02.mx.aol.com    internet address = 205.188.249.91
mailin-02.mx.aol.com    internet address = 64.12.137.89
mailin-02.mx.aol.com    internet address = 64.12.138.120
mailin-02.mx.aol.com    internet address = 205.188.155.72
mailin-03.mx.aol.com    internet address = 205.188.109.56
mailin-03.mx.aol.com    internet address = 205.188.252.17
mailin-03.mx.aol.com    internet address = 64.12.138.153
mailin-04.mx.aol.com    internet address = 64.12.138.57
mailin-04.mx.aol.com    internet address = 64.12.138.88
mailin-04.mx.aol.com    internet address = 205.188.159.216
dns-01.ns.aol.com       internet address = 64.12.51.132
dns-02.ns.aol.com       internet address = 205.188.157.232
dns-06.ns.aol.com       internet address = 149.174.54.153
dns-07.ns.aol.com       internet address = 64.236.1.107

Allez zou, mise en place de la chose sur un serveur avec Squid, pour en faire profiter tout le monde.

Quelques remarques par rapport à Debian

Je ne connais pas trop le rythme d’update des règles de privoxy. Ce que j’en ai compris, c’est qu’elles sont intégrées au package privoxy. A mon sens, ça devrait être dissocié, par exemple dans le dépôt « volatile ».
Ca ne l’est pas. Et comme les pubs évoluent, j’ai un peu hésité.

EDIT : j’ai changé d’avis sur ce qui suit : j’ai pris la version officielle Debian. Cf. les commentaires

Finalement, j’ai opté pour la version packagée Debian sur le site de privoxy plutôt que la version officielle dans la « stable ». Moins pratique pour mettre à jour, mais je n’aimerais pas qu’un nouveau genre de pubs ne soit pas filtré ou à l’inverse, trop de coups de haches sur certains sites.
En « stable », on est en 3.0.9 si je ne dis pas de bêtise, contre 3.0.12 en .deb sur le site.

J’ai aussi essayé de trouver une méthode facile pour convertir les expressions régulières d’Adblock Plus pour privoxy. J’ai lâché l’affaire. Si quelqu’un sait faire, ça peut être intéressant.

Quelques chiffres après 2 semaines d’utilisation

Histoire de mettre l’eau à la bouche. 100 personnes surfant raisonnablement ont vus (façon de parler) 10% de leurs requêtes bloquées par privoxy. C’est toujours ça d’économisé, mais c’est surtout le gain sur la pollution visuelle qui vaut le coup.
Je n’ai pas vu de différences sur quelques sites où j’avais l’habitude d’aller via « Firefox+AdBlockPlus » par rapport à « n’importe quel navigateur+privoxy sans adblock plus évidemment ».

Mise en place sur Debian

Installation

Installez donc le package Debian , précédemment téléchargé, avec la commande suivante :

dpkg -i privoxy_3.0.12-1_i386.deb

Paramétrage et tests de base

Tout se passe dans /etc/privoxy/config. Vous n’avez qu’une chose à modifier pour tester votre privoxy en direct :

listen-address  localhost:8118

Si le service est sur un serveur (et pas votre PC), changez « localhost » en « * » ou l’IP de la machine sur le LAN et relancez via /etc/init.d/privoxy restart
Bien sûr, il faut indiquer à votre navigateur d’utiliser le proxy sur cette machine, port 8118.
A la fin : faites bien attention à la valeur choisie (ou à vos règles de firewall si elles filtrent l’accès au serveur squid/privoxy), il ne faudrait pas qu’un utilisateur puisse adresser en direct privoxy en court-circuitant squid…

Interco avec Squid

La doc officielle de privoxy dit de chaîner dans l’ordre : PC -> squid -> privoxy
Il doit y avoir une raison, peut-être pour ne pas court-circuiter les éventuelles ACL de Squid, qui permettraient par exemple un certain traitement suivant l’IP source de la requête.
Bon bref, c’est donc au niveau de Squid qu’il faut paramétrer. Cherchez le mot « squid » dans la doc http://www.privoxy.org/user-manual/config.html. En résumé, ajoutez où il faut dans /etc/squid/squid.conf :

cache_peer 127.0.0.1 parent 8118 7 no-query
acl ftp proto FTP
always_direct allow ftp
never_direct allow all

Dans l’exemple, 127.0.0.1 indique que privoxy est sur la même machine que squid, sinon mettez l’IP de privoxy, et son port, par défaut 8118.
A noter que squid fait proxy FTP dans mon exemple, sinon adaptez.
Relancez squid, un /etc/init.d/squid reload doit suffire.

Pour voir les stats vite fait

http://p.p/
Ca peut servir pour configurer l’outil aussi, si vous avez activé ce qu’il faut
Evidemment, vous serez gentils de whitelister michauko.org. Je me suis pas tapé la mise en place de Google AdSense pour rien ouais bon, ça va… c’est pour financer un jour quelques mois de mon serveur…

A suivre

L’article SquidGuard, l’ami de Squid quand l’accès Internet est un peu trop surchargé par 99% d’inutile.

Je vois que le soft est en version 0.2… j’attendrai la 1.0 avant de jeter un oeil à ce truc à nouveau… ou un paquet Debian, ce qui sera une bonne preuve de fiabilité je pense…

Conclusion ? y’aurait beaucoup à dire, je retiendrai seulement : évitez roundcube, c’est « beau » mais c’est troué ; évitez les applis à la con ; évitez d’être trop ouvert dans vos règles réseaux firewall -> net etc etc… et vive une petite nuit pourrie pour en profiter pour remettre au carré certains détails qu’on remet toujours à demain….

Merci à Toinator qui a noté mon activité réseau débordante tout à fait par hasard (j’avais rien vu – ouuups, je remets quelques sondes là…). Le plus fun, c’est qu’il lui était arrivé la même chose…. avec le même logiciel….

Maintenant, j’ai découvert ce plug-in pour Thunderbird : « Copy Sent to current« .

Ca permet de choisir à l’envoi (ou pendant la rédaction) dans quel répertoire conserver le mail envoyé : le même que le répertoire courant ? la poubelle ? le « Sent » normal ? ou un répertoire utilisé fréquemment et accessible en une touche de raccourci ?
Sympa, indispensable.

Pour le paramétrer, pensez à 2 choses :
1. Dans les propriétés du compte IMAP, menu « copies et dossiers », il y aura un nouveau menu assez explicite
2. Dans les options du module pour les raccourcis et le nombre de répertoires récents à se « souvenir »

J’ai eu à déplacer l’outil sympa – très bien pour gérer des mailings-lists avec modération – d’un serveur à un autre.
L’outil était sur le backend de mail, avec la conf apache de sympa, la base de données de sympa et évidemment les binaires (le package sympa).
Le but était de déplacer la partie binaire, apache et base de données ; en conservant les boîtes mails et alias sur le backend de départ.

Je vous livre un petit retour d’expérience car c’est un poil plus compliqué que de déplacer une application LAMP classique.
Je partais d’une version Debian/stable, donc package sympa 5.2.3-1.2+etch1 et la cible était la même.

Je considère que vous avez déjà un Apache2 et MySQL sur la machine cible – et une machine cible capable de relayer des mails (recevoir et envoyer) sur postfix

La migration classique

La base reste la même :
1) Sur la machine cible, installez l’application – même version évidemment, packagée.
2) Reprenez (à la main ou en écrasant) la conf /etc/apache2/conf.d/sympa d’un serveur à l’autre
3) Reprenez ou adaptez /etc/sympa
4) Exportez/importez la base de données « sympa », comme une brute, par exemple :

machine_depart:$> mysqldump -u votre_user_qui_va_bien -p -B sympa > migr_sympa.sql
puis
machine_cible:$> mysql -u user -p < migr_sympa.sql

5) Assurez-vous d'avoir les bons identifiants de login de l'application sympa dans les tables "mysql" de Mysql (= les tables du schéma mysql. Pigé ? il doit y avoir notamment une ligne dans la table mysql.user concernant le User sympa) :

use mysql ; SELECT * from user where User = 'sympa';

La partie spécifique "sympa"

Ce qui est ci-dessus est ce que vous auriez à faire avec une appli LAMP typique qui stocke tout en base.
Manque de chance, sympa - au moins dans la version 5.2 (actuellement 5.4 dispo, pas essayé) - stocke tout un tas d'informations dans /var/lib/sympa, /usr/lib/sympa etc. Sans compter les alias mails qui permettent de transmettre les mails aux processus de gestion de sympa.
Donc il vous reste à faire :

La redirection des alias mail

Normalement, sur votre serveur de départ, vous devriez avoir tout un tas d'alias de mail dans /etc/aliases, genre :

sympa:             "| /usr/lib/sympa/bin/queue sympa"
listmaster:        "| /usr/lib/sympa/bin/queue listmaster"
sympa-request:     postmaster
sympa-owner:       postmaster
maliste1:          "| /usr/lib/sympa/bin/queue maliste1"
maliste1-request:  "| /usr/lib/sympa/bin/queue maliste1-request"
maliste1-owner:    "| /usr/lib/sympa/bin/bouncequeue maliste1"
maliste2.....

Il faut reprendre cette configuration telle quelle sur la machine cible et s'assurer sur la première - qui reste la machine de backend de mail (mon MX en gros), donc celle qui reçoit le mail - qu'elle sache faire suivre tout ça à la machine cible qui est devenue celle qui gère sympa.
Donc dans la machine de départ, vous trafiquerez tout de la sorte :

sympa:             "sympa@machinecible.com"
listmaster:        "listmaster@machinecible.com"
sympa-request:     postmaster (j'ai laissé tel quel, c'est un choix)
sympa-owner:       postmaster (j'ai laissé tel quel, c'est un choix)
maliste1:  "maliste1@machinecible.com"
maliste1-request:  "maliste1-request@machinecible.com"
maliste1-owner:  "maliste1-owner@machinecible.com"
maliste2.....

A la recherche du bordel éparpillé partout

Ensuite, je m'étais arrêté là - ahahah, erreur.
Sur l'interface web (la nouvelle), je ne voyais plus mes listes. La raison est que "sympa" stocke les listes, les archives etc hors de la base, dans des répertoires comme /usr/lib/sympa et /var/lib/sympa.
Donc, il faut reprendre tout ça sur la machine cible (des bêtes "tar" avec conservation des permissions suffisent).
Finalement, j'ai opté pour un joli :

dpkg -L sympa | less

De là, je suis passé dans tous les répertoires nommés (sauf les doc, le "man" etc - faut pas pousser) et je me suis assuré qu'il n'y ait pas de différence - attention à certains droits en setuid/setgid au nom de "sympa:sympa".

Ensuite, vous envoyez la purée auprès de vos utilisateurs pour leur indiquer que le système est à nouveau dispo, sur une liste modérée tant qu'à faire, afin de bien faire tous les tests.
Si rien n'arrive, c'est pas grave, vous avez raté un truc.
Si vous recevez la demande de modération, c'est que ça semble bien parti

Le nettoyage

Lorsque vous ferez le DROP DATABASE sympa sur l'ancienne machine et le aptitude purge sympa, ça vous confirmera ce que je vous racontais sur le stockage des archives, des listes etc :

J’utilise Squirrelmail comme client webmail pour les comptes en IMAP. C’est parfaitement fonctionnel, mais aussi très moche.
On peut certes changer le look si on adore le CSS, ou en trouver d’autres sur le web (mais ça se cantonne à changer la palette de couleur), ou enfin, pour 100/150 € on peut en payer un super-jouli avec des fleurs bleues dans les coins, au look de MS-LookOut.

Il y aussi Horde/IMP, très utilisé et complet. Et Roundcube, qui monte : très très joli (en AJAX-qui-tâche) mais pas encore 100% fonctionnel (bal IMAP partagées KO par exemple).

Sinon il y a aussi IlohaMail. C’est moins moche (sans être beau) et aussi simple à installer.
Par contre, le développement semble bien arrêté (depuis 2006). Sur une debian testing, on est en 0.8.6-rc3sid là où la .0.8.6 est officiellement sortie et la 0.9 en beta depuis 2 ans. Pas un message depuis 2 ans sur le blog.
Si vous êtes toujours en train de lire, c’est que cette vieillerie ne vous fait pas peur ; ça tombe bien vu que l’IMAP a pas du évoluer des masses depuis longtemps.
Comme Squirrelmail, les « thèmes » sont en options, voire rares, voire moches, voire payants….
Bon je critique, mais pour le prix, j’en suis content.

Allez, mise en place de la chose (au besoin, la mise en place de squirrelmail est décrite dans ma doc Debian qu’il-faut-que-je-mette-à-jour-un-de-ces-quatre).

Pré-requis

Idéalement, un serveur IMAP pour accéder à vos boîtes aux lettres, le PHP, un Apache2 et optionnellement une base de données (ex: MySQL). Regardez ma doc si vous n’avez rien de tout ça, sauf une grosse envie de monter une Debian.

Installation

Ca commence sur un air connu :

root@linux:~# sudo aptitude install ilohamail
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Lecture de l'information d'état étendu
Initialisation de l'état des paquets... Fait
Lecture des descriptions de tâches... Fait
Les NOUVEAUX paquets suivants vont être installés :
  aspell{a} aspell-en{a} dictionaries-common{a} ilohamail libaspell15{a}
0 paquets mis à jour, 5 nouvellement installés, 0 à enlever et 4 non mis à jour.
Il est nécessaire de télécharger 1550ko/1799ko d'archives. Après dépaquetage, 8889ko seront utilisés.
Voulez-vous continuer ? [Y/n/?]

Ensuite, vous aurez 2 questions :

Si votre installation Apache2 n’est pas trop en ruine, alors ça fera ce qu’il faut tout seul.

La deuxième question – je n’ai pas gardé la photo – vous demande quel alias utiliser pour accéder à l’application, par défaut « /IlohaMail ». Ca se change plus tard.

Utilisation

Normalement, moyennant un rechargement Apache, vous devriez avoir l’application qui fonctionne en allant sur votre http://votre.serveur/IlohaMail/ :

A la première connexion, il y a un paramétrage des préférences. On peut choisir quel est le répertoire d’envoi et de poubelle, ça peut être bien :

Paramétrage un peu plus avancé

Dans /etc/apache2/conf.d/ilohamail, vous pourrez corriger l’alias si mal choisi, exemple :

Alias /mail /usr/share/IlohaMail/source

< DirectoryMatch /usr/share/IlohaMail/source/>#sans espace avant DirectoryMatch
Options +FollowSymLinks
DirectoryIndex index.php
AllowOverride None
order allow,deny
allow from all
< /DirectoryMatch> # sans espace non plus

Dans /etc/IlohaMail, il y a plusieurs fichiers sympa. Tous les fichiers sont commentés, pratique pour comprendre les paramètres.

/etc/IlohaMail/conf.php

$backend="DB" au lieu de « FS » si vous voulez stocker les données en base de données plutôt qu’en fichiers. Dans ce cas, il faudra aller dans le fichier db_conf.php pour finir la conf base de données (je ne l’ai pas fait).
Notez ceux là :
$AUTH_MODE["imap"] pour les méthodes d’authentification
$SMTP_SERVER défaut à localhost
$MAX_SESSION_TIME
$DISABLE_CALENDAR
$DISABLE_BOOKMARKS