Gestion Serveur Mail Postfix, Amavisd, Mysql, Spamassassin, Dovecot

Cet article traite de la gestion d’un système de mail.
La procédure détaillée d’installation de ce système est en ligne sur ce site.

4 logiciels principaux sont utilisés pour la remise et l’envoi du courrier :
 le MTA postfix
 le filtre amavis (interface entre le mta et l’antivirus)
 le filtre spamassassin
 le filtre dspam

ordre de remise

 postfix
 amavis
 antivirus
 spamassassin
 dspam
 retour dans postfix
 lda dovecot

D’une manière générale, pour effectuer un blocage systématique, il est conseillé de le faire directement dans Postfix. (sender, client, recipient, contrôle des entêtes, body et type Mime)

La charge est très réduite dans ce cas car c’est lors de la transaction SMTP que s’effectue le blocage.

Le mail n’est donc pas encore traité. (économie de bande passante)

Un blocage effectué dans Amavis ou dans SpamAssassin sera plus gourmand en ressource.

 NOTE :

• Dans ce document on détaille la fonction de chaque point de contrôle et les réponses à apporter pour une action voulue.
• Les fichiers de lookup de Postfix sous forme de fichier texte classique (précédé de hash : dans le mail.cf) doivent être postmapés après une modification et Postfix doit également être rechargé.
• Les fichiers regexp (headers, body, mime) n’ont pas besoin d’etre postmapés mais Postfix doit toujours être rechargé
• Les valeurs contenues dans des bases SQL ont l’avantage d’être pris en compte à chaud. Aucune autre action n’est nécessaire.

Vue d’ensemble des points de filtrage :

il existe plusieurs points de contrôle à l’arrivée d’un message dans Postfix.

L’ordre global d’application est le suivant :

 SMTPD Restrictions
 Header/body Checks
 Content Filters

Postfix établit 4 étapes de tests (stages) au niveau des SMTPD Restrictions qui correspondent chacune à une commande SMTP :

Dans l’ordre :

Postfix est configuré dans notre cas pour évaluer les tests au moment de la commande RCPT TO, donc dans la section smtpd_recipient_restrictions.

C’est à dire que le blocage n’interviendra qu’au moment ou le client envoie la dernière commande.

A l’intérieur d’un restriction stage il existe des access lists (ACL).
Dès qu’une de ces access lists renvoient OK, on passe au stage suivant. (la fin d’un stage par défaut est PERMIT)

Si une access list renvoie REJECT le message est bloqué.
Si une access list ne matche pas, on passe a l’access list suivante dans le stage. (DUNNO)

Nous détaillons ci dessous notre cas de figure particulier :

 smtpd_client_restrictions =

Nous n’avons rien specifié ici donc par défaut ce stage est vide. On passe au suivant

 smtpd_helo_restrictions =

Nous n’avons rien specifié ici donc par défaut ce stage est vide. On passe au suivant

 smtpd_sender_restrictions =

Ici on a spécifié de rejeter :

• reject_authenticated_sender_login_mismatch :
  les clients authentifiés par SASL mais dont le MAIL FROM ne correspond pas à un alias valide de l’utilisateur (pour éviter le forging des adresses expéditrices et obliger les utilisateurs à utiliser nos domaines en MAIL FROM).
  • Si un user n’est pas authentifié par SASL (cas de figure d’un client extérieur qui envoie un mail au domaine) , l’access list ne matche pas, rien n’est effectué ici, on passe a la suite, c’est a dire le stage suivant.
  • Si un user est authentifié SASL et que son MAILFROM est une adresse contenue dans la liste de ces alias email, le résultat sera OK et on passe au stage suivant .
  • Si un user est authentifié SASL mais que son MAILFROM n’est pas une adresse contenue dans la liste de ces alias email, le mail sera rejeté.

A noter qu’en cas de blocage, on passe tout de meme au stage suivant car les blocages seront evalués au prochain stage. (mais le mail sera bloqué de toute facon, meme si le stage suivant se termine par OK)

Tous les autres cas de figures sont considérés comme valides, on passe donc au stage suivant.

 smtpd_recipient_restrictions =

C’est le stage le plus important.

• reject_non_fqdn_recipient :
  Rejette la requête quand le mail est destiné à une adresse (RCPT TO) qui n’est pas sous le format FQDN, par exemple tonio@starbridge (sans le .org) sera refusée.
• reject_unknown_sender_domain :
  Rejette la requête quand le mailfrom est celui d’un domaine qui ne possede pas d’entree DNS A ou MX, ou bien que la reponse est malformée. Ce rejet est temporaire (450) pour permettre de reiterer la requete en cas de probleme DNS.
• reject_non_fqdn_sender :
  idem que reject_non_fqdn_recipient mais pour le MAIL FROM
• reject_unknown_recipient_domain :
  idem que reject_unknown_sender_domain pour le RCPT TO.
• reject_invalid_helo_hostname :
  rejette la requête quand la syntaxe du HELO est invalide.
• reject_unlisted_recipient :
  cette valeur est active par défaut de manière globale pour rejeter tout destinataire qui n’existe pas dans notre base. L’avantage ici est de pouvoir positionner le rejet à un endroit précis.
• reject_unlisted_sender :
  On rejette les expediteurs vers l’extérieur et qui ne sont listés dans notre domaine. (cette règle recherche l’existence de l’utilisateur dans le MAIL FROM, dès que celui ci est dans notre domaine.)
• permit_mynetworks :
  paramètre capital, c’est de lui que peut arriver le premier OK (car c’est un permit et non un reject). il se réfère au mynetworks du main.cf et dans notre cas nous avons spécifier 127.0.0.1.
  • Donc aucun client du LAN ne sera OK sur cette règle. Seul les mails envoyés depuis le serveur de mail lui même seront OK. (ligne de commande, tache cron, Webmail par la commande sendmail... en fait tous les mails en provenance du daemon pickup de postfix).
  • Il faut donc être très vigilant sur ce point car un OK ici signifie que l’envoi est autorisé vers TOUTES les adresses emails, internes ou externes (c’est cette règle qui autorisera le relaying à un autre domaine.)
  • En pratique les clients du LAN ne pourront donc pas envoyer de mail vers l’extérieur à partir de cette règle. Ils doivent passer à la règle suivante :
• permit_sasl_authenticated :
  C’est là que les choses deviennent possibles : tout client authentifié par SASL sera autorisé immédiatement à envoyer un email vers toutes les addresses (plus aucune autre règle en dessous dans ce stage ne s’appliquera).
  • C’est le cas de figure des clients du LAN mais aussi des clients externes (Laptops) authentifiés par SASL.
    Si le client n’est pas authentifié SASL on passe a la regle suivante

• reject_non_fqdn_helo_hostname :
  rejette le HELO lorsqu’il n’est pas un FQDN. Par exemple lorsque le HELO est le hostname de la machine cliente.
  • C’est la cas de figure des clients Outlook. c’est pour cela que cette règle se situe APRES l’authentification SASL pour permettre aux clients du domaine de pouvoir envoyer un email malgré ce non respect des RFC par outlook : Les clients authentifiés ont deja pu envoyer leur mail et cette règle ne s’applique donc pas pour eux.
  • Pour les clients non authentifiés (cas de figure des clients extérieurs qui envoient un mail à l’intérieur) la règle s’applique.
  • Pour les clients internes non authentifiés, la règle s’applique également.
  • Si le HELO de ces clients est valide on passe à la suite.
• reject_unauth_destination : [rouge]
  c’est la règle la plus importante[/rouge] : toute la structure est basée la dessus.
  • Tout mail à destination (RCPT TO) d’un domaine externe au notre (donc du relaying) sera bloqué (relay access denied). Ainsi tout client non authentifié SASL et hors de 127.0.0.1 ne pourra envoyer d’email en dehors du ou des domaines que nous gérons.
  • Si le RCPT TO est notre domaine alors on applique la suite des règles :
• check_client_access hash :/etc/postfix/internal_networks :
  c’est la que cela se complique. On l’a vu, on ne spécifie nulle part le range IP de notre LAN. Seul 127.0.0.1 est renseigné. Cependant certaines vérifications ont besoin de connaitre les clients de notre LAN. Pour cela on fait appel à un fichier de lookup "internal_networks".
  • Si un client n’est pas dans notre LAN (un client externe) alors il passe à la règle suivante.
  • Si le client possède une IP dans notre LAN alors on lui applique une restriction class, c’est à dire une sorte de regroupement de règles que l’on a créees au préalable. Dans notre cas de figure il s’agit de "our_domain_as_sender". Cette restriction class exécute les vérification suivantes :
    • check_sender_access hash :/etc/postfix/our_domain_as_sender
    • reject
  • En fait le client dans notre lan se voit appliquer à nouveau une vérification du MAIL FROM :
    • si celui ci est notre ou nos domaines alors le résultat est OK.
    • Sinon c’est le refus car on passe à la règle suivante dans la restriction class, c’est à dire : REJECT. En clair, cela empèche les clients internes de spécifier un MAIL FROM différents de nos domaines. (forging)
    • Dans le cas ou le client n’est pas dans notre LAN ou réseau autorisé, on passe a la suite :
• check_sender_access hash :/etc/postfix/not_our_domain_as_sender :
  ici c’est un peu l’inverse de la règle précédente. Dans le cas de figure où dans la règle précédente le client n’est pas dans le réseau, comme on le disait, on passe à la suite, donc à cette règle. Celle ci va vérifier que ce client extérieur non authentifié ne donne pas un de nos domaines en MAIL FROM (forging). Si c’est le cas on rejette, si non on continue.
• check_helo_access proxy:mysql :/etc/postfix/mysql-hello.cf :
  cette règle permet de filtrer les HELO des clients.
  • Ici il s’agit d’une base SQL : postfix_hello. Les RFC spécifient qu’un client SMTP doit envoyer un HELO au début de la transaction SMTP qui correspond à son FQDN. On a vu plus haut des règles qui vérifient ce point. Un autre aspect est a vérifier : ce FQDN ne doit pas être le notre. En effet de nombreux spammeurs, jouant sur le fait que de nombreux serveurs de mails sont mal configurés tentent d’envoyer un email avec le FQDN de leur cible en HELO. Ici la requête se fait dans une table SQL qui contient la liste de nos domaines. (Postfix, par défaut, considère que l’entrée starbridge.org matche egalement tous les sous domaines comme spike.starbridge.org, donc le HELO du serveur de mail est bien protégé par cette regle. A noter que ce comportement peut etre modifié)
  • Ne seront autorisés à utiliser nos domaines dans le HELO que les clients qui sont dans notre réseau ou authentifiés par SASL. Et cette vérification du réseau et/ou de l’authentification a déjà été faire un peu plus haut par internal_networks et permit_sasl_authenticated. Donc si le client est dans le LAN ou authentifié, son message a déja été validé plus haut comme on l’a vu
  • sinon il arrive alors sur cette règle et s’il spécifie un des domaines dans la liste, il obtiendra un REJECT .
  • Si le client specifie un HELO qui n’est pas dans la liste, on passe a la suite. On évite ainsi le forging du HELO.
    Pour être tout à fait precis, un HELO est envoyé aussi bien par un autre serveur SMTP (qui nous envoie l’email d’un de ces clients) que par un MUA genre outlook (un nos clients). Il ne faut pas oublier qu’un serveur SMTP, par sa partie cliente, communique avec notre serveur et donc doit spécifier un HELO valide. Ce cas de figure peut se présenter en interne dans le cas d’un autre serveur qui enverrait des emails (log, cron..etc.etc). Son client SMTP devra alors spécifier un HELO correct.
• check_sender_access proxy:mysql :/etc/postfix/mysql-sender.cf :
  Cette liste est accessible dans la base SQL postfix_access sous le type sender. Elle permet de spécifier des actions selon le MAIL FROM.  Elle permet principalement de blacklister radicalement un expéditeur sur son adresse email. Le forging d’adresse email étant très aisé, cette règle est d’une utilité relative dans la lutte contre le spam, mais peut parfois être pratique. On peut aussi s’en servir pour whitelister un sender par rapport au controle par RBL qui va suivre. Mais encore une fois le forging de MAIL FROM étant facile, il faut être prudent avec cette règle, car elle rendrait le sender qui utiliserait un MAIL FROM whitelisté, totalement insensible au controle par RBL.
  • Si le résultat est le code d’erreur SMTP 554, cela donne un REJECT immediat. (on peut consulter les significations codes SMTP sur google)
  • Si le résultat est OK, le mail est accepté à ce niveau et on ne prends pas en compte les règles suivantes.
  • Si le sender n’est pas trouvé dans la liste on passe à la suite.
• check_client_access proxy:mysql :/etc/postfix/mysql-client.cf
  Cette liste est accessible dans la base SQL postfix_access sous le type client. Cette fois on va réellement se servir de cette règle pour whitelister les contrôles par RBL qui suivent. Ceux ci s’effectuent sur l’IP du client ou sur son domaine. En cas de false positive sur les RBL c’est ici qu’il faudra renseigner l’IP, le range IP ou même le reverse DNS du client.
  • Si le code retour est 554 le mail est rejeté.
  • Si c’est OK le mail est accepté immédiatement et les règles en dessous de celle ci ne sont pas prises en compte.
  • Si le client n’est pas dans la liste on passe à la suite.
• reject_rbl_client
  Il s’agit d’une suite de contrôle par des RBL. Quand un mail arrive ici le serveur contacte la 1ère RBL de la liste et vérifie que l’IP ou le domaine du client ne soient pas blacklistés.
  • Si oui : le mail est bloqué tout de suite. (code 554)
  • Si non : on passe à la suivante, donc une autre RBL, ainsi de suite jusqu’à la fin des contrôles par RBL.
    On le comprend cela est assez gourmand en temps de requêtes donc il ne faut pas abuser des RBL. (même si ces requêtes sont mises en cache)
    2 RBL seront largement suffisantes.
• check_policy_service inet:127.0.0.1:12525
  Si on l’a installé, on passe ici au contrôle par Policyd-weight, qui permet de faire des requêtes sur d’autre RBLs. La différence vient du fait que Policyd-weght appliquera un score en fonction du nombre de RBL dans lesquelles on retrouve le client.
  Cela permet de pondérer certaines listes de RBL trop restrictives.
  De plus un système de mise en cache permet de limiter les requètes réseau.
• permit
  La règle finale qui autorise le passage au stage suivant.

Evaluation des Stages CLIENT, HELO, SENDER, RECIPIENT :
A noter qu’a partir d’ici tous les stages précédents (CLIENT, HELO, SENDER, RECIPIENT) sont evalués, donc avec soit un PERMIT soit un REJECT (ou un code de rejet)

 Si c’est un REJECT le mail est définitivement rejeté avec le code d’erreur associé, au moment ou le client passe la commande RCPT TO.

 Si c’est un PERMIT alors on passe tout de même aux 2 stages suivants (commande DATA) car ils auront en quelque sorte le dernier mot si leurs ACLs rejettent un message.

Les stages DATA :
Un REJECT dans un des 2 stages DATA signifiera que le mail sera bloqué et ce MEME si il etait accepté EXPLICITEMENT dans l’évaluation des stages SENDER et RECIPIENT.

Par exemple, un utilisateur identifié SASL qui a vu son autorisation d’envoyer un mail acceptée bien plus haut dans la liste doit encore passer ces 2 stages. Et un reject signifiera que le mail est bloqué...

Un OK dans ce stage sera sans danger pour les restrictions des stages précédents car on l’a vu, en cas de REJECT dans les stages précedent le message n’arrive pas aux 2 stages DATA (rejet au moment de la commande RCPT TO donc avant que le client ne passe la commande DATA).

Donc aucun risque d’être un relais ouvert et/ou de bypasser les restrictions précedentes.

On bypassera en fait les autorisations précédentes.

 smtpd_data_restrictions =

• reject_unauth_pipelining
• permit

Cela permet de bloquer les client SMTP qui "parlent" trop tôt dans la transaction.
C’est le cas des scripts mal écrits et de quelques softs de spamming.

 smtpd_end_of_data_restrictions =

• check_policy_service inet:127.0.0.1:10031 :

c’est l’utilisation d’un policy service, c’est à dire un petit logiciel qui est chargé d’effectuer des contrôles supplémentaires et qui renvoie à Postfix le résultat.
Pour nous il s’agit de Policyd, chargé d’effectuer des contrôles de flux.
On détaillera plus loin son fonctionnement.

• • Si le policy service ne trouve aucune correspondance avec ses règles, on passe à la suite (car il renvoie un DUNNO quand rien ne matche dans ses vérifications, ce qui signifie "on passe à l’access list suivante dans le stage") qui est par defaut PERMIT dans ce stage.

Comme il s’agit du dernier stage le mail est veritablement validé ici. Policyd supplantera donc une decision de PERMIT prises plus haut et appliquera la sienne.

Comme Policyd est utilisé pour controler le flux, on gère ainsi TOUS les mails traversant le systeme.

Ci joint un schema sur l’application de ces restrictions

Whitelister un expéditeur dans Postfix

On vient de voir le fonctionnement global.

Prenons maintenant des cas pratiques en cas de blocage :

Première règle : chercher dans le message d’erreur, le message envoyé par le mailer-daemon et le log de Postfix, qu’elle est la raison du blocage.

Si on recoit un message "Postfix SMTP server : errors from :" dans la boite admin, il s’agit d’un blocage de Postfix.

NOTE :
le client ne recoit aucun message de la part de notre serveur, c’est le serveur du client qui recoit un code d’annulation de l’envoi et gère ce refus. (normalement le serveur du client avertit le sender par mail)

Il faut donc regarder quelle est le contenu du message :

Par exemple :

Il s’agit d’un blocage au niveau SMTP sur le HELO.
Le client n’a pas envoyé un HELO correct. (cela doit etre un FQDN et ici c’est une adresse IP, en l’occurence la notre, ce qui est clairement le signe d’un envoi invalide)

Dans la configuration actuelle il n’est pas prévu de laisser passer ce genre de message même pour des cas particuliers. (pas de whitelist)
Aucun serveur de mail ne doit envoyer un HELO de la sorte.

On l’a vu plus haut, une grande partie du filtrage peut se faire par l’utilisation de listes (des RBLs) sur internet, maintenues par diverses entités et qui recensent des milliers d’IP/domaines suspectés d’être à l’origine d’envois de spam.
Le problème reside dans le fait que ces listes sont plus ou moins arbitraires, (spamcop) et que leur filtrage est souvent trop brutal. (c’est pour cela qu’il est conseillé d’utiliser policyd-weight sur un serveur en production, voir l’article relatif sur Starbridge)

Pour un sender qui serait bloqué par les DNSBL ou les RBL :

Pour ce blocage on peut whitelister exceptionnellement le sender ou le client (comme on l’a dit plus haut il vaut mieux le faire sur le client par securité) :

il faut alors l’autoriser dans la table postifx_access (en précisant la nature : sender pour un email ou client pour un serveur de mail).
Ici il faudrait ajouter 59.95.12.67 en type client et action OK

Note : Ce whitelistage permet d’eviter le controle des RBL dans postfix mais aussi celle dans Policyd-weight, puisque l’access list est positionnée en amont.

Contrôle des entêtes, body et type Mime

Si on ne recoit aucun message d’erreur SMTP cela signifie que l’expéditeur et le recipient semblent valides, le message continue alors d’etre livré et Postfix vérifie son contenu.

Ce sont les tables (non SQL, dans /etc/postfix)

Note :
toute modification de ces fichiers doit être suivie de la commande :

Tout match sur des règles présentes dans ces fichiers se traduit par à nouveau un message dans la boite admin : (et dans les logs bien sur)

En cas de doute, on voit également dans les logs la nature de l’erreur (header, body, ou mime) et on peut ajuster alors le fichier correspondant si besoin est.

C’est ici qu’intervient le premier point de contrôle des pièces jointes.
Les extensions de fichiers et les types mime sont controlés.
Si un match se produit le serveur renvoit une erreur.

Note :
Il n’est pas possible de passer outre ces contrôles dans la configuration de base.
Ce controle à ces limites, notamment sur les emails encodés en base64.
C’est pour cela que les type de fichiers sont aussi controlés plus tard par Amavisd et qu’il n’est pas nécessaire de trop surcharger ces fichiers regexp.

Si l’on desire controler finement les pieces jointes, le mieux est de désactiver leur controle dans postfix et de laisser faire amavisd.

autres erreurs SMTP

Ici il s’agit d’un destinataire inconnu.

L’adresse mail n’existe pas dans notre base.

Blacklister un expéditeur ou un client

Note : Ce parametre ne peut etre modifié que par un admin.

Il faut simplement ajouter une entrée dans la table postfix_access en type sender pour bloquer une adresse mail ou en type client pour bloquer un serveur.

[rouge]Attention : il faut absolument spécifier en action le code 554 suivi d’un texte qui sera affiché au serveur qui se connecte.

Si on ne met que le code 554 le filtrage ne fonctionne pas. (ex : 554 Spam)[/rouge]

De plus il faut être certain que l’IP du client ou le MAILFROM soient corrects pour que le contrôle soit efficace.

Par exemple le HELO n’est pas forcément le domaine du client. Il faut donc regarder quel est le premier log de la transaction SMTP (connect from :)

Les logs de postfix sont le point le plus fiable pour trouver ces informations.

Note : pour bloquer un domaine et ses sous domaines en type client il faut le spécifier comme ceci :

Par exemple, pour bloquer les connections depuis les clients smtp 21.mail-out.ovh.net et 12.mail-out.ovh.net, il faut specifier en type client :

mail-out.ovh.net et action 554 Spam

bien sur, tous les autres sous domaines seront également bloqués.

Note : ceci est le cas avec les parametres par défaut dans postfix qui applique le setting : parent_domain_matches_subdomains pour les tables smtpd_access_maps.

Analyse du contenu du mail et scan antivirus : le role d’amavisd et de Clam

- Pièces Jointes

Amavisd peut bloquer les mails contenant certains types de pièces jointes. (avi, mp, dll...)
Ce scan est très fiable car le mail et la pièce jointe sont décomposés et eventuellement décompressés.
Ainsi un fichier .dll à l’intérieur d’une archive zip sera bloqué (alors qu’il ne pouvait pas l’être par le filtrage basique de Postfix)
De même, un fichier .dll renommé en txt sera également bloqué car le Type Mime du fichier sera vérifié.

Si un match se produit, il renvoit un mail d’erreur BANNED à l’expéditeur et au sender.
Et le mail est mis en quarantaine dans /var/virusmail.

 On peut whitelister un Type Mime et des extensions de fichiers dans /etc/amavisd.conf.

Pour désactiver le controle des pieces jointes dans amavisd, il faut se connecter à horde et dans les options spams, cocher les cases : Skip Banned File Checks et Receive Banned Files.

Pour rendre cette règle active au niveau d’un domaine il faut qu’un administrateur ajoute dans la base les entrées équivalentes mais pour le user @domain.com, ce qui prendra alors en compte la totalité du domaine.
Une priorité à 6 sur ce domaine dans amavisd, permettra aux règles par users de supplanter cette règle générale.

Exemple pour paramétrer finement le domaine starbridge.org dans amavisd :

Ici l’on a désactivé le contrôle des fichiers joints pour le domaine starbridge.org.
La priorité 6 permettra à un réglage personnel pour un user du domaine, de prendre le pas sur cette configuration.

Attention aux id et aux correspondances de policy, ici les numero sont des exemples.

Si cette étape est validée, le mail est scanné par l’antivirus.

- Antivirus

L’antivirus traite les mails recus ET envoyés depuis la plateforme.
C’est le filtre Amavisd qui se charge de l’envoi des mails au daemon Clamd.

Amavisd a décomposé le mail, et décompressé les pièces jointes éventuelles et il transmet ces parties à clamd qui les scanne.
Si un virus est détecté, le mail est rejeté et un message d’alerte est envoyé.
Si le message est ok, amavisd poursuit le traitement. (spamassassin + dspam).

La mise à jour de la base antivirus est automatique.

En cas de détection d’un virus, le serveur renvoit un mail d’erreur INFECTED à l’expéditeur et au sender. (sauf dans le cas de virus connus pour créer de faux expéditeurs : liste dans amavisd.conf)

On peut permettre a un utilisateur ou a un domaine complet de recevoir les virus. (non recommandé)
C’est dans la table sql d’amavisd que cela se fait, voir plus haut pour la configuration.
Par utilisateur l’option existe dans le module sam, mais elle est desactivée par défaut. On peut la rendre disponible au users mais cela est tout a fait déconseillé.

Une fois le traitement antivirus terminé, amavisd poursuit avec l’antispam.

Analyses anti Spam : Spamassassin

Tous les messages en dessous de 512 Ko sont envoyés à Spamassassin pour analyse.
La configuration de Spamassassin se trouve dans /etc/mail/spamassassin/local.cf.

Note : Vu que c’est le daemon Amavisd qui contrôle Spamassassin, il est conseillé de modifier la plupart des options dans amavisd.conf.
Cela dit le fichier local.cf de SA est toujours pris en compte, notamment pour le whitelist et le blacklist, mais certains paramètres seront ignorés.

Note : Le score minimum pour être détecté comme spam se règle dans Amavisd. (il est ignoré dans local.cf)

Pour whitelister un sender on a plusieurs possibilités :

soit on ajoute en dur dans la configuration d’amavisd des scores negatifs pour un sender donnée,
soit on parametre a nouveau la base sql d’amavisd pour un domaine donné
soit on utilise le module sam pour que chaque user gere ses whitelist et blacklist comme il le souhaite.

 Pour parametre en dur et donc rendre la configuration globale, il faut ajouter ces lignes dans amavisd.conf :

pour whitelister un domaine entier :

pour blacklister un sender :

Il s’agit de soft whitelisting ou soft blacklisting : On attribut un score négatif ou positif qui modifiera le score initial du message.

 Pour le faire au niveau du domaine grace à la base sql, il faut créer un sender dans la base, puis lié au moyen de la table wb, celui ci avec le user défini (en l’occurence @starbridge.org pour un domaine entier).
En précisant W ou B on whitelist ou on blackliste, en entrant un chiffre positif ou negatif, on attribue un score. (soft white|black listing)

 Pour le faire par utilisateur, le module sam procède exactement de la même facon, en ajoutant ces entrées dans la base, mais en utilisant comme user un type user@starbridge.org, valide uniquement pour lui meme.
A noter que pour le moment le module SAM ne precise que W ou B, il ne fait pas de soft whitelisting.

Amavisd envoie ensuite les mails à Dspam, le traitement est automatique (pas de whitelist), car SA est prioritaire sur dspam.

En effet si dspam considère qu’un message est du spam, il transmet à Amavisd le résultat et le score s’ajoute dans SA.
On peut moduler ce score dans la configuration de SA. (fichier local.cf)

Après analyse, et si le score du message dépasse 4.3, Amavisd réecrit le header du message et y ajoute les infos :

X-Spam-

et réecrit également le sujet du message avec le préfixe ***SPAM(score)***

Contrairement à un virus, les spams sont autorisés a être livrés jusqu’a un score prédéfini (par défaut 10).
Au dela ils sont mis en quarantaine directement par amavisd qui les stocke en base SQL.

Entre 4.3 et 10 les mails sont juste taggés et triés plus tard par le filtre Sieve.

Le gestionnaire de quarantaine mailzu permet de consulter les mails directement par les users
Ceux ci peuvent alors demander la libération d’un message ) un administrateur. Après validation le mail sera livré.

Cette interface gere aussi la quarantaine des virus et des fichiers bannis.

Les messages même au dela de 10 sont donc encore consultables par les destinataires, ce qui leur permet de controler au mieux leur boite aux lettres.

La durée de vie dans la quarantaine de mailzu est de 30 jours.

Dans la configuration avec mailzu, le parametre kill_level dans la base sql d’amavisd est l’elément déterminant pour le placement du message dans la quarantaine.

Il est réglé à 10 par défaut.

4.3 est le tag level, c’est à dire le point où amavisd ajoute l’entête spam dans le message, mais le livre tout de même au client.

Par défaut dans SAM, un user peut modifier son tag level, mais pas son kill level.

Cependant il est possible de lui laisser ce choix en modifiant la conf du module SAM.

On peut, à nouveau, parametrer tout ceci pour un domaine particulier dans la base sql en utilisant comme user @starbridge.org.

Remise dans les boites physiques

Une fois que toutes les étapes postfix/amavisd/SA/clam/DSPAM sont validées, la livraison continue.

Le mail revient dans postfix suite au traitement.

C’est le lda de dovecot qui se charge de la livraison dans les boîtes physiques.

Il est appelé par Postfix (/etc/postfix/master.cf).

Le langage Sieve est supporté par le lda dovecot et permet d’exécuter des actions en fonction de criteres au moment de la livraison.

Un fichier Sieve général est systématiquement exécuté pour tous les mails livrés.

Ce fichier est exécuté dans l’ordre :

 dès le premier match l’action est exécutée.
 L’élimination ou la mise en quarantaine du spam sont effectuées à ce moment de la livraison :

• Tous les messages marqués comme spam sont envoyés par sieve dans le répertoire Spam de l’utilisateur.

Pour info le fichier global.sieve contient les regles suivantes :

C’est l’extension +spam de l’adresse qui est le critere determinant. Cette extension est ajoutée par amavisd pour les mails entre 4.3 et 10.

Si le mail est OK, sieve parse le fichier sieve personnel s’il existe. (dans le répertoire qui porte le nom de l’utilisateur)

C’est ici que l’utilisateur peut indiquer des règles de messages particuliers (remise dans des répertoires définis sur des critères précis.)

 Si aucune règle ne matche, le mail est remis dans le répertoire utilisateur.
 Si une règle matche, le mail sera alors livré dans le sous dossier correspondant

Note : Dans le cas d’utilisation du POP plutot que l’IMAP pour la consultation des boites au lettre, la redirection automatique des messages détéctés comme spam
dans un repertoire predéfini devra etre désactivée (fichier /home/sieve/global.sieve).

En effet, contrairement à l’imap, il n’y a pas de notion de repertoire dans le pop.
Les users pop recevront donc leur messages + le spam détecté avec le prefixe [SPAM] dans la même boite.
Les users pop pourront créer une regle sur leur client mail pour rediriger ces messages.

Si l’on a des utilisateurs IMAP et POP dans le reseau, alors il faudra totu de meme désactiver la redirection globale et Les users imap pourront utiliser ingo dans horde pour créer un filtre de redirection
automatique personnel de ces messages dans le bon dossier imap

Si un utilisateur a besoin de blacklister un expéditeur particulier, il peut le faire par l’interface du webmail Horde qui permet de créer des regles sieve dans le fichier sieve personnel.
Ce filtrage ne concerne que l’utilisateur en question et n’impacte pas les autres utilisateurs, contrairement aux exemples de blacklistage cités plus haut dans le document.

Gestion des false positive et des spam non detectés.

Note : Ceci ne s’applique qu’aux boite IMAP.

En plus du répertoire Spam dans les boites utilisateurs, on trouve également les répertoires :

 SpamToLearn
 SpamFalse

Ces 2 dossiers permettent à l’utilisateur de signaler un email noté à tort comme spam ou l’inverse.

Pour cela, il lui suffira de copier le message en question dans le dossier de son choix :

 SpamToLearn dans le cas d’un spam non détecté.
 SpamFalse dans le cas d’un false positive.

Ces répertoires sont automatiquement scannés et vidés plusieurs fois par jour. (fréquence déterminée par la crontab)

Création d’un nouvel alias

La création d’un alias se fait dans Postfixadmin par un administrateur

On crée l’alias en spécifiant la nouvelle adresse puis l’adresse de destination finale (la boite physique en fait)

[rouge]Attention : meme s’il est possible de diriger un alias vers un autre alias qui lui même pointe vers l’adresse physique, il ne faut surtout pas utiliser une telle méthode.[/rouge]

En effet, le contrôle des MAIL FROM pour les utilisateurs authentifiés par SASL se fait justement sur la comparaison entre la boite physique (donc le compte de l’utilisateur par exemple admin@starbridge.org) et les alias existants pointant vers celle ci.

On remarquera que Postfixadmin crée toujours un alias du même nom que la boite physique : par exemple pour la boite admin@starbridge.org, il existe dès la création l’alias :

admin@starbridge.org ==> admin@starbridge.org

Ces alias "systèmes" ne sont pas visibles dans Postfixadmin par défaut pour plus de clarté mais on peut les voir dans phpmyadmin.

Lors du controle SASL/MAILFROM, la table alias est consultée et dans tous les cas on aura au moins : admin@starbridge.org ==> admin@starbridge.org.

C’est pour cette raison que chaque création d’un nouvel alias doit pointer vers l’adresse physique.

Redirection des messages (Forward)

Il existe 2 moyens de rediriger les messages recus vers un destinataire :

 l’ajout d’un alias par l’administrateur
 la regle sieve

• Pour ajouter une redirection par l’ajout d’un alias, il faut que l’admin se connecte sur postfix admin :

http://www.starbridge.org/postfixadmin/
on ajoute au mail existant l’email desiré
[rouge]Attention : ne pas modifier les options en dessous. Cela provoquerait l’impossibilité d’envoyer un email depuis ce compte. Pour faire une redirection sans conserver une copie du message dans la boite principale, il FAUT utiliser la méthode sieve ci dessous.[/rouge]

• Pour ajouter une redirection par sieve il faut modifier le le fichier sieve de l’utilisateur.
  Celui ci peut le modifier en passant par le webmail horde. (Filtres, redirection)

Il vaut mieux utiliser la redirection sieve, notamment si on ne souhaite pas recevoir les messages dans la boite d’origine.
En effet la modification de l’alias principal par la methode 1, bloquera toute possibilité d’envoi de mail par l’utilisateur, en raison du mécanisme de verification des mailfrom.

Gestion des Quotas

Il existe plusieurs type de quotas dans notre infrastructure :

 la taille maximale d’un mail (envoyé ou recu)
 la taille maximale d’une boite email
 le volume (poids/nbre) de mails reçus par heure.

 Pour la taille d’un message on trouve 1 point de controle :

• dans postfix dans le main.cf : message_size_limit = 50240000 par defaut = 50 Mo

 La taille maximale d’une boite email est gérée par dovecot et le plugin quota. Le quota est parametrable dans postfixadmin.

 Le volume des mails envoyés est controlé par policyd.
dans notre configuration, et meme si TOUS les messages sont controlés, seul les expediteurs des messages sont pris en compte par ce controle. Ils peuvent etre des users de nos domaines qui envoient vers leurs domaines ou vers l’exterieur, mais cela peut etre aussi un expediteur externe qui envoient vers votre domaine.

Par défaut les paramètres sont les suivants :

• Pour les expéditeurs :
  • Distinction par authentification SASL. Si l’expediteur n’est pas authentifié on se base sur le MAILFROM. 
  • Periode de temps = 1 heure
  • 512 messages maximum peuvent être envoyés en 1 heure par le même expéditeur.
  • un expéditeur ne peut envoyer en 1 heure qu’à un maximum de 3600 destinataires.
  • un expéditeur peut envoyer 250 Mo max par heure.

Pour modifier globalement il faut changer les paramètres dans l’interface policyd

Pour aller plus loin

pour mieux comprendre le fonctionnement de postfix on pourra consulter :
Un article très complet sur le sujet, écrit par Jim Seymour.
En bas du présent article on trouvera 2 présentations (slides) des possibilités de filtrage et de configuration de postfix. Elles ont été realisées par Patrick Koetter & Ralf Hildebrandt.