Amavis

Amavis est un filtre de contenu open source pour le courrier électronique , qui permet le transfert des messages électroniques, le décodage, certains traitements et vérifications, et l'interfaçage avec des filtres de contenu externes pour assurer une protection contre le spam , les virus et autres logiciels malveillants . Il peut être considéré comme une interface entre un expéditeur de courrier ( MTA , Mail Transfer Agent) et un ou plusieurs filtres de contenu .

Amavis peut être utilisé pour :

• détecter les virus, les spams, les types de contenu interdits ou les erreurs de syntaxe dans les messages électroniques
• bloquer, étiqueter, rediriger (en utilisant un sous-adressage ) ou transférer le courrier en fonction de son contenu, de son origine ou de sa taille
• mettre en quarantaine (et libérer) ou archiver les messages électroniques dans des fichiers, des boîtes aux lettres ou une base de données relationnelle
• désinfecter les messages transmis à l'aide d'un désinfectant externe
• générer des signatures DKIM
• vérifier les signatures DKIM et fournir une liste blanche basée sur DKIM

Caractéristiques notables :

• fournit des statistiques SNMP et une surveillance de l'état à l'aide d'un MIB étendu avec plus de 300 variables
• fournit un journal d'événements structuré au format JSON
• Le protocole IPv6 est pris en charge dans l'interface et les formulaires d'adresse IPv6 dans la section d'en-tête du courrier
• respecte correctement les paramètres par destinataire, même dans les messages multi-destinataires, tout en analysant un message une seule fois.
• prend en charge le courrier électronique international (RFC 6530, SMTPUTF8 , EAI , IDN )

Une installation de filtrage de courrier classique avec Amavis comprend Postfix comme MTA, SpamAssassin comme classificateur de spam et ClamAV comme protection antivirus, tous fonctionnant sous un système d'exploitation de type Unix . De nombreux autres antivirus (environ 30) et d'autres scanners de spam ( CRM114 , DSPAM, Bogofilter ) sont également pris en charge, ainsi que d'autres MTA.

Trois topologies d'interfaçage avec un MTA sont prises en charge. Le processus amavisd peut être intercalé entre deux instances d'un MTA, ce qui donne une configuration classique de filtrage de courrier après la file d'attente amavisd peut être utilisé comme filtre proxy SMTP dans une configuration de filtrage avant la file d'attente , ou le processus amavisd peut être consulté pour fournir une classification de courrier mais pas pour transférer un message électronique par lui-même, auquel cas le client consultant reste responsable de la transmission du courrier. Cette dernière approche est utilisée dans une configuration Milter (avec certaines limitations), ou avec un programme client historique amavisd-submit .

Depuis la version 2.7.0, une configuration avant la file d'attente est préférée, car elle permet de rejeter un transfert de message électronique pendant une session SMTP avec un client expéditeur. Dans une configuration après la file d'attente, le filtrage a lieu après qu'un message électronique a déjà été reçu et mis en file d'attente par un MTA, auquel cas un filtre de courrier ne peut plus rejeter un message, mais peut seulement le délivrer (éventuellement étiqueté), ou le supprimer, ou générer une notification de non-délivrance, ce qui peut provoquer une rétrodiffusion indésirable en cas de retour d'un message avec une fausse adresse d'expéditeur.

L'inconvénient d'une configuration avant la file d'attente est qu'elle nécessite des ressources (CPU, mémoire) proportionnelles au taux de transfert de courrier actuel (de pointe), contrairement à une configuration après la file d'attente, où un certain délai est acceptable et l'utilisation des ressources correspond au taux de transfert de courrier moyen. Avec l'introduction d'une option smtpd_proxy_options=speed_adjust dans Postfix 2.7.0, les besoins en ressources pour un filtre de contenu avant la file d'attente ont été considérablement réduits

Dans certains pays la législation n'autorise pas le filtrage du courrier électronique pour rejeter un message électronique une fois qu'il a été accepté par un MTA, ce qui exclut une configuration de filtrage après la file d'attente avec rejet ou mise en quarantaine des messages, mais laisse la possibilité de délivrer des messages (éventuellement étiquetés) ou de les rejeter dans une configuration avant la file d'attente (proxy SMTP ou milter).

Amavis peut recevoir des messages électroniques d'un MTA via un ou plusieurs sockets des familles de protocoles PF_INET ( IPv4 ), PF_INET6 ( IPv6 ) ou PF_LOCAL ( socket de domaine Unix ), via les protocoles SMTP , LMTP ou un simple protocole privé. AM.PDP peut être utilisé avec un programme d'assistance comme amavisd-milter pour s'interfacer avec les milters . Côté sortie, les protocoles SMTP ou LMTP peuvent être utilisés pour transmettre un message à une instance MTA back-end ou à un LDA , ou un message peut être transmis à un processus généré via un canal Unix . Lorsque SMTP ou LMTP sont utilisés, une session peut éventuellement être chiffrée à l'aide d'une extension TLS STARTTLS (RFC 3207) du protocole. Le pipeline de commandes SMTP (RFC 2920) est pris en charge dans le code client et serveur.

Lorsque l'analyse anti-spam est activée, un processus démon amavisd est conceptuellement très similaire à un processus spamd d'un projet SpamAssassin . Dans les deux cas, les processus enfants dupliqués appellent directement les modules Perl de SpamAssassin , leurs performances sont donc similaires.

La principale différence réside dans les protocoles utilisés : Amavis utilise généralement un protocole SMTP standard pour communiquer avec un MTA, tandis que dans le cas de spamc/spamd, un MTA génère généralement un programme spamc qui lui transmet un message via un canal Unix, puis le processus spamc transfère le message à un démon spamd en utilisant un protocole privé, et spamd appelle ensuite les modules Perl SpamAssassin.

Les priorités de conception d' amavisd-new (ci-après simplement appelé Amavis ) sont : la fiabilité, la sécurité, le respect des normes, les performances et la fonctionnalité.

Afin d'éviter toute perte de message électronique en raison d'événements inattendus tels que des échecs d'E/S, un épuisement des ressources et des arrêts de programme inattendus, le programme amavisd vérifie méticuleusement l'état d'achèvement de chaque appel système et opération d'E/S. Les événements inattendus sont enregistrés si possible et traités avec plusieurs niveaux de gestion des événements. Amavis ne se décharge jamais de la responsabilité de la livraison d'un message électronique d'un MTA : l'état de réussite final est signalé à un MTA uniquement après que le message a été transmis à l'instance MTA back-end et que la réception a été confirmée. En cas d'échec fatal lors du traitement ou du transfert d'un message, le message en cours de traitement reste simplement dans une file d'attente de l'instance MTA front-end, pour être réessayé ultérieurement. Cette approche couvre également les éventuelles défaillances inattendues de l'hôte, les plantages du processus amavisd ou de l'un de ses composants.

L'utilisation des ressources du programme, comme la taille de la mémoire, les descripteurs de fichiers, l'utilisation du disque et la création de sous-processus, est contrôlée. Les messages électroniques volumineux ne sont pas conservés en mémoire, de sorte que la taille de la mémoire disponible n'impose pas de limite à la taille des messages électroniques pouvant être traités, et les ressources mémoire ne sont pas gaspillées inutilement.

Une grande attention est accordée aux aspects de sécurité, requis par le traitement de données potentiellement malveillantes, non standard ou simplement brouillées dans les messages électroniques provenant de sources non fiables.

Le processus qui gère les messages électroniques s'exécute avec des privilèges réduits sous un identifiant utilisateur dédié. Il peut éventuellement être exécuté en mode chroot . Les risques de dépassement de tampon et de bugs d'allocation de mémoire sont largement évités en implémentant toute la gestion du protocole et du traitement du courrier en Perl , qui gère la gestion dynamique de la mémoire de manière transparente. On veille à ce que le contenu des messages traités ne se propage pas par inadvertance au système. Perl fournit un filet de sécurité supplémentaire avec son marquage des données contaminées provenant de la nature, et Amavis prend soin d'utiliser cette fonctionnalité de Perl à bon escient en évitant la dépollution automatique des données ( use re "taint" ) et en ne les dépolluant explicitement qu'à des points stratégiques, tard dans un flux de données.

Amavis peut utiliser plusieurs programmes externes pour améliorer ses fonctionnalités. Il s'agit de désarchiveurs , de décompresseurs , d' antivirus et de scanners de spam . Comme ces programmes sont souvent implémentés dans des langages comme C ou C++ , il existe un risque potentiel qu'un message électronique transmis à l'un de ces programmes puisse provoquer son échec ou même ouvrir une faille de sécurité. Le risque est limité en exécutant ces programmes sous un identifiant d'utilisateur non privilégié, et éventuellement chrootés. Néanmoins, les programmes externes comme les désarchiveurs non maintenus doivent être évités. L'utilisation de ces programmes externes est configurable et ils peuvent être désactivés de manière sélective ou en groupe (comme tous les décodeurs ou tous les scanners de virus).

Bien qu'il soit implémenté dans un langage de programmation interprété Perl , Amavis lui-même n'est pas lent. Les bonnes performances de la fonctionnalité implémentée par Amavis lui-même (sans parler des composants externes) sont obtenues en traitant les données en gros morceaux (c'est-à-dire pas ligne par ligne), en évitant la copie de données inutile, en optimisant les chemins de code fréquemment parcourus, en utilisant des structures de données et des algorithmes appropriés, ainsi que par certaines optimisations de bas niveau. Les goulots d'étranglement sont détectés pendant le développement en profilant le code et en effectuant des tests comparatifs. Un rapport de synchronisation détaillé dans le journal peut aider à reconnaître les goulots d'étranglement dans une installation particulière.

Certains modules ou programmes externes comme SpamAssassin ou certains scanners de virus en ligne de commande peuvent être très lents, et leur utilisation constituerait une grande majorité du temps écoulé et des ressources de traitement, ce qui rend les ressources utilisées par Amavis lui-même proportionnellement assez faibles.

Les composants tels que les décodeurs de courrier électronique externes, les scanners de virus et les scanners de spam peuvent être désactivés de manière sélective s'ils ne sont pas nécessaires. Il reste les fonctionnalités implémentées par Amavis lui-même, comme le transfert de messages électroniques depuis et vers un MTA à l'aide d'un protocole SMTP ou LMTP , la vérification de la validité de la section d'en-tête du courrier, la vérification des types de contenu de courrier interdits, la vérification et la génération de signatures DKIM .

En conséquence, les tâches de traitement du courrier électronique telles que la signature et la vérification DKIM (avec d'autres vérifications de courrier électronique désactivées) peuvent être exceptionnellement rapides et peuvent rivaliser avec les implémentations dans les langages compilés. Même les vérifications complètes à l'aide d'un antivirus rapide mais avec l'analyse anti-spam désactivée peuvent être étonnamment rapides.

L'implémentation des protocoles et des structures de messages suit de près un ensemble de normes applicables telles que RFC 5322, RFC 5321, RFC 2033, RFC 3207, RFC 2045, RFC 2046, RFC 2047, RFC 3461, RFC 3462, RFC 3463, RFC 3464, RFC 4155, RFC 5965, RFC 6376, RFC 5451, RFC 6008 et RFC 4291. Dans plusieurs cas, certaines fonctionnalités ont été réimplémentées dans le code d'Amavis même si un module Perl public ( CPAN ) existe, mais manque d'attention aux détails dans le suivi d'une norme ou manque de vérification et de gestion suffisantes des erreurs.

Amavis est sous licence GPLv2 . Cela s'applique au code actuel ainsi qu'aux branches historiques. Une exception à cela concerne certains programmes de support (comme la surveillance et les rapports statistiques), qui sont couverts par une licence New BSD .

Le projet a débuté en 1997 sous la forme d'un script shell Unix destiné à détecter et bloquer les messages électroniques contenant un virus . Il était destiné à bloquer les virus au stade MTA (agent de transfert de courrier) ou LDA (distribution locale), fonctionnant sur une plate-forme de type Unix , en complément d'autres mécanismes de protection antivirus fonctionnant sur les ordinateurs personnels des utilisateurs finaux.

L'outil a ensuite été réimplémenté sous forme de programme Perl , qui a ensuite évolué vers un processus démonisé . Une douzaine de développeurs se sont relayés pendant les cinq premières années du projet, développant plusieurs variantes tout en gardant un objectif commun, le nom du projet et une partie de l'infrastructure de développement.

Depuis décembre 2008 (jusqu'au 09/10/2018), la seule branche active était officiellement amavisd-new , qui était développée et maintenue par Mark Martinec depuis mars 2002. Cela a été convenu entre les développeurs de l'époque dans une correspondance privée : Christian Bricart, Lars Hecking, Hilko Bengen, Rainer Link et Mark Martinec. Le nom du projet Amavis est largement interchangeable avec le nom de la branche amavisd-new .

De nombreuses fonctionnalités ont été ajoutées au fil des ans, comme l'ajout d'une protection contre le spam et d'autres contenus indésirables, en plus de la protection antivirus d'origine. L'accent est mis sur la fiabilité, la sécurité, le respect des normes et les performances.

Le domaine amavis.org utilisé par le projet a été enregistré en 1998 par Christian Bricart, l'un des premiers développeurs, qui maintient toujours l'enregistrement du nom de domaine. Le domaine est désormais entièrement dédié à la seule branche active. La liste de diffusion du projet a été déplacée de SourceForge vers amavis.org en mars 2011 et est hébergée par Ralf Hildebrandt et Patrick Ben Koetter. La page Web du projet et le site de distribution principal étaient situés à l' Institut Jožef Stefan , à Ljubljana, en Slovénie (jusqu'à la remise en 2018), où la majeure partie du développement a eu lieu entre 2002 et 2018.

Le 9 octobre 2018, Mark Martinec a annoncé sur la liste de diffusion de soutien général et de discussion sa retraite du projet et également que Patrick Ben Koetter continuera d'être le nouveau chef du projet.

Je connais Ben personnellement, il est l'un des deux auteurs de The Book of Postfix, et utilise également Amavis dans sa vie professionnelle, donc je pense que le projet sera entre de bonnes mains.

—Marc  Martinec

Après cela, Patrick a notifié la migration du code source vers un référentiel GitLab public et son plan pour les prochaines étapes concernant le développement du projet.

Au cours de l'histoire du projet, le nom du projet ou de ses branches a quelque peu varié. Au départ, l'orthographe du nom du projet était AMaViS (A Mail Virus Scanner), introduit par Christian Bricart. Avec une réécriture en Perl, le nom du programme était Amavis-perl . Les versions démonisées ont d'abord été distribuées sous le nom amavisd-snapshot puis sous le nom amavisd . Une réécriture modulaire par Hilko Bengen a été appelée Amavis-ng .

En mars 2002, la branche amavisd-new a été introduite par Mark Martinec, initialement comme un correctif contre amavisd-snapshot-20020300 . Elle a ensuite évolué vers un projet autonome, qui est maintenant la seule branche survivante et activement maintenue. De nos jours, le nom d'un projet s'écrit de préférence Amavis (tandis que le nom du programme lui-même est amavisd ). Le nom Amavis est désormais principalement interchangeable avec amavisd-new .