J’ai été confronté à un problème que j’ai mis un peu de temps à résoudre et vu le peu de doc en français que j’ai trouvé à ce sujet j’ai décidé d’en publier le résultat.
Contexte
J’ai, au boulot, deux serveurs de mail (ce n’est pas tout à fait exact mais c’est suffisant à savoir pour le problème en question).
Le premier reçoit les mails de l’extérieur, fait une vérification antivirus et antispam en marquant les mails avec les entêtes idoines, envoie ensuite le mail à un compte archive local qui, comme son nom l’indique, archive le mail — faudra que je vous fasse un topo sur cet archivage automatisé un de ces quatre — si le mail est propre
, sinon le stocke dans un dossier Spam et le conserve pendant 30 jours (au cas où un faux positif s’y trouverait) si celui-ci est marqué comme Spam, ou, dans le cas de virus, le stocke dans un dossier spécial à fin d’analyse.
Le mail est aussi envoyé sur un deuxième serveur où se connecteront les clients pour relever leurs mails respectifs via IMAP ou POP3.
Le premier serveur est un Mac Mini récent, tournant avec la version 10.8 d’OS X et 2.2 de Server.app, que je suis en train de configurer pour remplacer un vieillissant Mac Pro tournant avec Mac OS X Server 10.4 (depuis 2006). Le second est un Mac Pro de 2009 tournant avec Mac OS X Server 10.5.
Problématique
Sur le premier serveur les mails étaient correctement marqués avec les entêtes X-Spam* lorsque le ceux-ci étaient considérés comme tel. C’était vérifiable avec l’application Mail.app qui me permet de gérer l’archivage (et l’apprentissage bayésien du filtre, mais ça fera l’objet d’un autre article). J’avais pour ceux-ci une entête du style :
X-Spam-Status: Yes, score=2.743…
Par contre, sur le second serveur, je perdais systématiquement toutes les entêtes, ce qui empêchait les clients de filtrer rapidement sur celles-ci. J’ai pendant un temps utilisé le marquage du sujet avec un ***JUNK MAIL*** de rigueur mais je trouvais que ça n’était pas très élégant d’avoir ce genre de mention sur les quelques faux-positifs que je recevais.
Analyse et solution
Après quelques premières recherches, j’ai trouvé que postfix, le process chargé de la gestion SMTP du transport des mails, pouvait être configuré pour filtrer certaines entêtes.
postfix/main.cf
Le réglage en question se trouve dans le fichier de configuration main.cf (habituellement dans le dossier /etc/postfix/ sur les anciennes versions de Mac OS X Server, et dans le dossier /Library/Server/Mail/Config/postfix/ de Server.app). Vous y trouverez une ligne du type (commentée par défaut pour Mac OS X Server) :
#header_checks = regexp:/etc/postfix/header_checks
Ou, pour Server.app (OS X 10.8) :
header_checks = pcre:/Library/Server/Mail/Config/postfix/custom_header_checks
Le fichier /Library/Server/Mail/Config/postfix/custom_header_checks contenant par défaut cela :
/^subject: *$/ REJECT empty subject header
Ce qui a pour effet de rejeter les mails dont le sujet est vide. La documentation associée à cette gestion des entêtes est disponible via un man header_checks.
Mes fichiers de configuration n’ayant pas été modifiés dans ce cas, ce réglage ne pouvait expliquer la disparition de mes entêtes X-Spam*.
amavisd.conf
La suite (et fin) de mon enquête m’a amené à m’intéresser au process amavisd chargé de gérer les filtres antivirus et antispam sur les serveurs Mac OS X. La configuration de ce process est géré via le fichier amavisd.conf et comporte entre autre un réglage qui permet de spécifier le score minimum de l’antispam pour que les entêtes correspondantes soient conservées (ou intégrées).
Le fichier se trouve dans le répertoire /etc/ pour les versions Mac OS X Server et dans le répertoire /Library/Server/Config/Mail/amavisd/ pour Server.app.
Il faut savoir que même si les filtres antivirus et/ou antispam sont désactivés, amavisd filtre quoi qu’il arrive les entêtes des mails qui passent par lui. Pour les anciennes versions de Mac OS X Server (10.4), le paramètre en question est :
$remove_existing_spam_headers = 0; # Leave existing X-Spam* headers alone
Ce qui permet de conserver intact les entêtes des mails reçus. Par contre sur les versions 10.5 et suivantes, ce paramètre n’est pas défini et c’est un autre qui est utilisé :
$sa_tag_level_deflt = 2.0; # add spam info headers if at, or above that level
Et dans ce cas, puisque le filtre antispam était désactivé sur le second serveur, amavisd supprimait tout bonnement les entêtes en question puisqu’aucun mail n’était considéré comme du spam. De plus je n’ai pas trouvé comment faire en sorte que spamassassin (le filtre antispam utilisé par amavisd) tienne compte des entêtes déjà positionnées dans le mail reçu.
Une modification en :
$sa_tag_level_deflt = -9999; # was 2.0; # add spam info headers if at, or above that level
Permet de les conserver quoiqu’il arrive. J’en ai profité pour faire le même réglage sur le premier serveur, ce qui fait que dorénavant tous les mails sont marqués, via leurs entêtes, et transportent l’état de spam et le score associé.
Cela permet maintenant aux clients de paramétrer des règles spécifiques en testant ces entêtes particulières. Exemple pour un mail considéré comme du spam :
X-Spam-Flag: YES X-Spam-Score: 1.825 X-Spam-Level: * X-Spam-Status: Yes, score=1.825 tagged_above=-9999 required=0 tests=[DKIM_SIGNED=0.1, HTML_IMAGE_RATIO_02=0.805, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.919] autolearn=no
Autre exemple pour un mail sain
:
X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-9999 required=0 tests=[RP_MATCHES_RCVD=-0.001] autolearn=ham
Voilà le détail des entêtes en question, ainsi que leur signification :
- X-Spam-Status : Résumé de l’état du mail (score, tests positifs et leur poids, …).
- X-Spam-Level : Contient n caractère(s) ‘*’, n étant la partie entière du score.
- X-Spam-Score : Score du mail.
- X-Spam-Flag : État Spam (YES ou NO).
Addendum du 12 février 2013
J’ai appris que SpamSieve, le filtre antispam pour Mac OS X (il fonctionne de concert avec Mail.app), se servait des entêtes X-Spam-Status et X-Spam-Report si celles-ci étaient présentes pour analyser les mails et enrichir sa base de connaissance. L’entête X-Spam-Status est déjà positionnée, par contre j’ai eu quelques difficultés à trouver comment faire ajouter l’entête X-Spam-Report par amavisd sur le serveur.
Pour ajouter cette entête il faut, dans le fichier amavisd.conf, ajouter la ligne suivante :
$allowed_added_header_fields{lc('X-Spam-Report')} = 1;
Vous pouvez utiliser la même commande avec n’importe laquelle des autres entêtes (X-Spam-Status, …) et la valeur 0 pour empêcher l’insertion d’une entête générée par défaut.
Le paramètre $sa_spam_report_header, utilisé historiquement, n’étant plus pris en charge par les version 2.8.0 et suivantes de amavisd-new.
Puis dans le fichier local.cf, ajouter la ligne suivante :
add_header all Report _REPORT_
Une fois les deux modifications effectuées, un arrêt et un redémarrage du serveur de mail permet la prise en compte des modifications :
sudo serveradmin stop mail sudo serveradmin start mail
Notez que l’entête X-Spam-Report n’est insérée dans le mail que si celui-ci est considéré comme indésirable par spamassassin.