TL;DR
Le mail reste malgré tout un outil efficace pour gérer des alertes, mais s'adresser à des groupes fluctuants n'est point aisé.
Minasan est un outil opensource maison permettant d'envoyer des mails à des groupes dynamiques, définits par des projets Gitlab.
Courriels en masse
Le courrier électronique est vieux comme tout, enfin, presque aussi vieux qu'Internet.
Complètement cochonné par le spam et autre infomertial, il reste un standard de la communication asynchrone et nominative. Quelque part entre le ticket et l'archive de tchat.
Prévu pour discuter de personne à personne, le mail a rapidement était épaulé par les listes de diffusions. Sorte de point central permettant d'envoyer des messages à un groupe, message que recevront chacun des participants, avant de batailler pour de désinscrire pour essayer de contenir le flot de messages dans leurs boites aux lettres.
Dans le glorieux monde du logiciel libre, il existe les vénérables Mailman et Sympa, dont l'ergonomie et la souplesse d'administration a poussé tout le monde vers Google ou Mailchimp.
Il existe en fait deux approches du courriel massif.
La liste de diffusion, où tous les participants peuvent écrire et répondre à tous les autres.
L'envoi massif, où peu de personnes envoient un même message à beaucoup d'autres qui ne pourront pas répondre.
SMTP
Le SMTP est un des protocoles mal aimés d'Internet. Pour ne plus qu'il soit le pire de tous, XMPP a été crée, mais ça n'a pas suffi.
SMTP est un protocole vénérable et naïf, pour ne pas dire niais. Quand il a été créé, personne ne voulait enlarger personne. Personne n'avait imaginé gérer autre chose que l'anglais, ou même des pièces jointes.
Depuis, on a tout ça, le protocole et les usages ont évolué pour s'adapter à ces ajouts. On a même eut trop d'évolutions, comme SASL et STARTTLS, fort pénibles à implémenter, mal gérées par les clients, pour des fonctionnalités ringardisées par le tout TLS.
Mal normalisé, les différents serveurs ont depuis le temps pris l'habitude de jargonner entre eux, et de rendre bien pénible l'acceptation des nouveaux arrivants. Ça a permis de limiter (un peu) le spam, et de donner de la valeur aux offres AS A Service, avec un niveau de finition et de négociation entre gros hébergeurs difficilement accessible aux logiciels libres.
SMTP est un protocole connecté, alors que HTTP, le protocole star d'Internet est lui déconnecté. Cette approche différente a coupé la motivation de bien des développeurs, les libs SMTP sont globalement pénibles, et de toute façon, le protocole connecté est peu approprié aux langages synchrones.
Outillage
Postfix est un très bel outil pour envoyer des mails, personne n'ose lui contester sa place de leader, mais, même branché à une base de données, il reste extrêmement statique (et son architecture date d'un autre siècle). Postfix est tout à fait à sa place, comme gardien d'Internet, protégeant les petites choses fragiles que sont les applications mails dynamiques.
Nginx, proxy universel et pas juste HTTP est parfaitement capable de faire transiter du SMTP (et même de l'authentifier sur un service HTTP, grâce à une élégante astuce), mais il garde son rôle de passe plat, bien statique.
On a donc un protocole touffu, des langages peu adapté, et un environnement d'exécution clairement hostile.
Python a une bibliothèque SMTP dans sa stdlib qui est dans un état pathétique, ça date de l'époque sombre des architectures Java. Oui, du Python organisé comme du Java, c'est fort laid. La version asynchrone est bien plus décente, mais reste confuse comme tout le code d'asyncio. Des choses vicelardes, comme le STARTTLS sont arrivées bien tard.
Zedshaw a fait un bel effort avec Lamson maintenant forké par Salmon , mais ça reste orienté mailing list, et surtout ça reste bloqué sur du Python2. En 2018, je dis juste non à l'idée de démarrer un projet en Python 2.
Ruby garde le cul entre deux chaises avec une partie des choses faisables en event machine (asynchrone), pour remplir des files d'attente qui seront traitées par du code synchrone, comme le fait Cuttlefish.
Nodejs est asynchrone et permet de faire rapidement des maquettes, mais comme outil que l'on utilise en oubliant qu'il est là, non, rien que le travail pour suivre les montées en version me fatigue à l'avance.
Golang, grâce sa culture NIH issue de plan 9 met un point d'honneur à implémenter tout et n'importe quoi, en natif, dans la stdlib. Sa nature asynchrone lui permet d'implémenter le protocole SMTP sans saut périlleux (et fil d'attentes). Sa culture de la violence a favorisé la création d'outils de haut niveau permettant de gérer des mails entrants, comme go-guerilla .
Envoi massif, mais raisonnable
Mon besoin est simple : avoir une adresse mail derrière qui se cache un groupe de personne. Je ne souhaite pas gérer ce groupe, ni même créer les adresses. J'envoie un mail à cette adresse, et hop, tous les gens du groupe reçoivent le mail. Cette envoi d'alias est fort pratique dans les outils d'alertes, comme Alertmanager ou Kapacitor . Les outils d'alerte utilisent un alias mail comme indirection, pour ne pas avoir à mettre à jour la liste des destinataires, ou même savoir qui est d'astreinte au moment où le mail part.
La partie complexe dans la gestion des mails est la lecture du contenu. En ne travaillant que sur les entêtes et en faisant le passe plat avec le contenu, on s'épargne beaucoup de soucis.
Minasan
+---------+ +-------------+ mail -> | Minasan | -> | Relais SMTP +--+-> Alice +---+-----+ +-------------+ | | REST +-> Bob v | +---------+ +-> Charly | Gitlab | +---------+ 皆さん en VO, que l'on peut traduire du japonais par "tout le monde", mais avec en plus poli, avec le suffixe "san".
Minasan , outil maison, s'appuie sur Gitlab pour gérer les comptes mails qui pointeront vers tous les participants d'un projet, avec une simple astuce de nommage. En envoyant un message à factory.minasan tous les membres du projet minasan du groupe factory , avec le rang supérieur à observateur recevront le message. L'API REST de Gitlab permet de faire ça de manière presque élégante.
Attention, le mail n'est pas l'outil de communication universel, là, il est utilisé en complément à Sentry (gestion d'erreurs) et Mattermost (discussions web). Ayons une pensée pour les tranches d'e-arbres morts qui s'entassent dans des boites triées automatiquement mais jamais lu.
go-guerilla ne permet pas pour l'instant de gérer de l'authentification (mais il gère très bien SSL et STARTTLS), ce qui n'est pas trop grave, ce service n'a pas vocation à être exposé publiquement : le pattern ambassadeur lui va très bien. Il est imaginable de restreindre les émetteurs à un domaine et une signature GPG, ou une signature DKIM, mais bon, commençons simple.
Une fois le mail reçu, avec comme destinataire un projet existant, Minasan va envoyer autant de mail que de destinataires à un relai SMTP qui, lui, affrontera le grand Internet.
Rappelons-nous la pensée de Tyler Durden : "Nothing is static", pas même SMTP.
