Différences

Ci-dessous, les différences entre deux révisions de la page.

--- txs:infra-a18-1:docu [2018/09/26 15:50] – thomas
+++ txs:infra-a18-1:docu [2018/11/26 16:16] (Version actuelle) – contenu redondant -> suppression cdrom1
@@ Ligne 1: / Ligne 1: @@
-=====Documentation=====
-==== Fonctionnement du mail ====
-  * [[https://fr.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol]]
-  * [[https://tools.ietf.org/html/rfc1870 (RFC : pas une doc mais une spécification)]]
-  * [[https://fr.sendinblue.com/blog/smtp-definition-protocole-serveurs/]]
-Les emails sont transférés de serveur en serveur via le protocole SMTP. Mais l'ouverture d'une boîte de réception se fait via IMAP, POP3 ou encore un webmail qui utilise un de ces deux protocoles.
-Sur le serveur de Picasoft, nous hébergerons à la fois  *
-  * un MTA (Mail Transfer Agent) chargé de relayer des mails via le protocole SMTP (il sera le début de la chaîne pour l'envoi d'un email sortant de picasoft)
-  * et un MDA (Mail Delivery agent) chargé de stocker des messages entrants dans une boîte de réception (il est à la fin de la chaîne pour la réception) et de permettre leur lecture aux utilisateurs autorisés, potentiellement distants (POP3, IMAP).
-Voici des MTA et MDA "de référence". On pourra trouver dans [[https://pad.picasoft.net/p/tx-infra-A18-I|le pad de suivi]] une comparaison de plusieurs MTA/MDA correspondant plus ou moins aux besoins de l'asso.
-=== MTA ===
-Le MTA "de référence" sur Linux est Postfix. Ce logiciel est activement maintenu et très documenté. Il supporte [[http://www.postfix.org/LDAP_README.html#config|l'authentification LDAP]], ce qui est une demande de l'association.
-Il a beaucoup d'autres fonctionnalités grâce à son [[https://en.wikipedia.org/wiki/Postfix_(software)#Architecture|architecture modulaire]].
-=== MDA ===
-Il existe beaucoup de MDA en concurrence pour Linux, avec leurs avantages et inconvénients liés à la maintenabilité, la facilité d'utilisation pour l'adminsys et les utilisateurs, la sécurité, la modularité, les fonctionnalités offertes, etc.
-[[https://en.wikipedia.org/wiki/Mail_delivery_agent#List_of_MDA_software_for_Unix-like_platforms|Cette page wikipédia]] liste quelques MDA.
-Dovecot est un des MDA les plus utilisés. Il est modulaire et est connu pour être robuste du point de vue de la sécurité. Il [[https://wiki2.dovecot.org/AuthDatabase/LDAP|implémente LDAP]] avec la possibilité de configurer le "bind" (opération d'effectuer le lien entre un utilisateur mail et un utilisateur LDAP).
-== DKIM ==
-DKIM permet d'authentifier le MTA de début de chaîne, et de confirmer l'intégrité du message. Comme c'est le MTA de début de chaîne qui décide ou non de signer le message, seuls les utilisateurs autorisés par ce MTA auront la signature.
-Il s'agit d'un protocole qui modifie le comportement:
-  * du MTA en début de chaîne: ajout d'une signature dans l'en-tête du mail;
-  * et des MTA transmettant le mail: vérification de la signature. Les clefs publiques sont publiées via le DNS.
-DKIM modifie le protocole SMTP au niveau du contenu du fichier mail qui est transmis (couche application).
-  * [[https://tools.ietf.org/html/rfc6376|La spécification officielle de DKIM]]
-  * [[http://www.opendkim.org/|Une implémentation de DKIM]]
-Noter que sous debian, openDKIM s'intègre automatiquement dans le flux de données de Postfix.
-=== SPF ===
-SPF permet au DNS d'indiquer à tous les MTA quels MTA sont autorisés à émettre des mails avec un certain domaine. Il suffit d'indiquer quelles adresses IP sont autorisées à émettre. Les serveurs participant à SPF peuvent donc rejeter des mails ne provenant pas d'une adresse IP autorisée. Cependant, la participation à SPF n'est pas obligatoire. Un email frauduleux peut donc traverser toute une chaîne de MTA et arriver dans une boîte de réception si aucun n'implémente SPF.
-  * [[http://www.openspf.org/|Site officiel de SPF]]
-  * [[https://tools.ietf.org/html/rfc7208|Spécification]]
-  * [[https://fr.wikipedia.org/wiki/Sender_Policy_Framework|Article wikipédia : résumé court]]
-Il sera possible d'automatiser la mise en place de SPF en écrivant un script simple (éditant le DNS).
-=== DMARC ===
-DMARC tire parti de SPF et DKIM pour définir des politiques à appliquer sur les mails entrants. Elle permet au propriétaire du domaine expéditeur d'indiquer quels mécanismes de protection sont en vigueur (SPF, DKIM) et que faire en cas d'échec de l'authentification (les faire passer quand même, prévenir l'admin par mail, etc.).
-DMARC permet aussi d'autres vérifications, la plus importante est l'//alignment//. "L'alignement" renforce SPF et DKIM:
-  * Pour SPF, la procédure consiste à lire l'email pour en extraire le champ "from" et vérifier que le domaine de l'adresse de l'expéditeur correspond au domaine qui a été authentifié via SPF (donné par la commande MAIL FROM, dans le protocole SMTP. Donc c'est aussi une vérification de la cohérence entre deux couches).
-  * DKIM ne vérifie que si les signatures des mails sont valides. Avec DMARC, le domaine ayant signé le mail doit correspondre au domaine du champ "from".
-Les politiques de l'expéditeur sont publiées via DNS, et les politiques sur les mails entrants (qui peuvent remplacer les politiques de l'expéditeur ou en être complémentaires) sont définies via la configuration des logiciels utilisés (sur le MDA par exemple).