Débarrassez-vous de l'administration SMTP/POP3/IMAP (et confiez votre messagerie à Google)

Magazine
Marque
GNU/Linux Magazine
Numéro
146
Mois de parution
février 2012
Domaines


Résumé
Disposer de son propre système de messagerie est à la fois gratifiant, éducatif et pratique. Qu'il s'agisse d'un serveur à titre personnel/privé ou pour une petite structure, le fait d'avoir la main mise sur la configuration complète d'un domaine permet toutes les variations et toutes les optimisations. Mais tout cela a un coût en termes de maintenance et d'évolution du système. Et ces deux éléments sont fortement dépendants des demandes et besoins (imaginaires ou avérés) de vos utilisateurs. On ne sait pas toujours à quoi on s'engage en installant, tout heureux, son premier serveur SMTP. Parfois (souvent ?), on le regrette amèrement.

Tout commence un jour où vous trouvez géniale l'idée de gérer vous-même votre messagerie. Initialement, comme tout particulier ou PME/PMI, votre service messagerie est fourni en package avec votre connexion Internet. Très commercialement, votre FAI vous permet d'utiliser un service vous fournissant une ou plusieurs adresses ainsi qu'un espace de stockage adéquat pour vos mails. Rapidement, en fonction de vos activités, ces adresses ne suffisent plus ou ne correspondent pas/plus à votre utilisation. L'exemple du « fromagerieleon2munster@free.fr » est un classique, d'autant plus si le domaine « fromagerie-leon.fr » est effectivement en possession de la personne ou de la structure concernée et qu'il a déjà fourni l'accès à un site web.

Le contrôle d'un domaine et de la messagerie pour ce dernier se résume aux libertés/possibilités suivantes (liste non exhaustive) :

- Définir autant d'adresses et d'alias qu'on le souhaite.

- Filtrer finement les messages avant...

Cet article est réservé aux abonnés. Il vous reste 98% à découvrir.
à partir de 21,65€ HT/mois/lecteur pour un accès 5 lecteurs à toute la plateforme
J'en profite


Articles qui pourraient vous intéresser...

mod_md : quand Apache se met à parler couramment Let's Encrypt

Magazine
Marque
Linux Pratique
Numéro
125
Mois de parution
mai 2021
Domaines
Résumé

L’autorité de certification (AC) Let’s Encrypt a ouvert son service au public le 12 avril 2016. La part du trafic web chiffré ne cessa alors d'augmenter pour représenter actuellement près de 90% du trafic total. Sur le plan technique, Let’s Encrypt a pu réaliser un tel exploit notamment grâce à ACME, son protocole normalisé par l’IETF d’obtention automatisée de certificats. De nombreux clients ACME en ligne de commandes ont été développé et ont répondu à beaucoup de cas d’usage. Plus récemment, une étape supplémentaire a été franchie avec l’intégration de l’obtention de certificats Let’s Encrypt directement au sein de composants d'infrastructures comme HAProxy, Traefik ou les serveurs web Caddy et Apache et son module mod_md. C’est de ce dernier dont nous allons parler ensemble aujourd’hui.

Netcat, l’histoire d’un couteau suisse pour le réseau

Magazine
Marque
Linux Pratique
Numéro
123
Mois de parution
janvier 2021
Domaines
Résumé

Lier le monde de l’administration système et celui du réseau n’est pas chose aisée, ni donné à tout le monde. De nombreux outils présents issus du monde de l’open source essaient désespérément d’y trouver une place. L’un d’entre eux a par ailleurs une longueur d’avance. Permettant de jouer avec la création de socket sur la couche transport du modèle OSI, Netcat rayonne dans le monde underground depuis déjà de nombreuses années. Rien de tel qu’une petite histoire pour parler de ce programme légendaire...

Définissez l'architecture de vos serveurs et installez-les

Magazine
Marque
Linux Pratique
HS n°
Numéro
49
Mois de parution
novembre 2020
Domaines
Résumé

Dans cet article, nous réfléchirons aux besoins de sécurité auxquels nos serveurs devront répondre. Il sera d’ailleurs plus question d’architecture que de serveur personnel. Pourquoi cela ? Car nos besoins vont à coup sûr évoluer dans le temps. L’approche la plus pérenne sera donc de mener une réflexion basée sur des services et non sur un serveur unique. Nous allons aussi nous attacher à assurer la résilience de nos services de base. Nos choix d’architecture auront pour objectif de pouvoir mieux détecter, contrer et éventuellement réparer les dommages causés par une attaque informatique. Nous pourrons par exemple restaurer nos services si un attaquant réussissait à prendre le contrôle du serveur. Notre plan de bataille commencera par la définition des grandes lignes de notre infrastructure, puis par la sélection de nos fournisseurs. Nous déploierons ensuite le serveur avec un premier palier de sécurisation système.