Tester vos envois d'e-mails avec MailHog

Magazine
Marque
Linux Pratique
Numéro
89
Mois de parution
mai 2015
Domaines


Résumé
Vous êtes en phase de test de votre application, de maquette de votre nouvelle infrastructure, et tout cela repose sur l'envoi d'e-mails pour enregistrer des utilisateurs ou envoyer des e-mails d'alerte. Mais tester l'envoi avec votre adresse personnelle vous limite et vous ne désirez pas monter un serveur d'e-mails ni passer par un service externe.

1. Présentation

MailHog est un service pour tester l'envoi d'e-mails : il fait tourner un serveur SMTP minimal, qui intercepte tous les e-mails reçus. Il vous suffit de configurer votre application afin qu'elle utilise MailHog comme serveur SMTP, qui affichera les e-mails reçus dans une interface Web.

Il offre des fonctionnalités similaires à MailCatcher, que nous avons vu dans le dernier numéro pour tester Discourse. Mais MailHog présente l'avantage d'être écrit en Go : en plus d'être plus rapide, vous n'avez pas besoin d'installer une pile applicative Ruby comme pour MailCatcher, MailHog étant un simple binaire.

2. Installation

Je vais installer MailHog en version 0.1.6 dans une machine virtuelle, qui a pour adresse 192.168.0.11, que je veux pouvoir atteindre par le nom DNS smtp.lan.fr. On commence d'abord par ajouter une entrée sur la machine physique depuis laquelle je vais atteindre MailHog :

user@physique$ echo...

Cet article est réservé aux abonnés. Il vous reste 90% à 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.