Transparence – PluMail

La confiance repose aussi sur la clarté. PluMail a donc choisi de présenter ici les grandes lignes de son fonctionnement, de son infrastructure et de ses dépendances principales.

Cette page ne détaille pas les éléments sensibles liés à la sécurité du service, mais elle permet de comprendre comment PluMail est hébergé et dans quel cadre il fonctionne.

Un service auto-hébergé

PluMail repose sur une infrastructure auto-hébergée. Le service principal est exploité sur un serveur dédié, administré directement pour le projet.

Cette approche permet de garder une maîtrise réelle de l’environnement technique, des données hébergées et des choix d’exploitation.

L’auto-hébergement implique aussi une responsabilité importante : celle de maintenir le service, de surveiller son bon fonctionnement et de mettre en place les mécanismes nécessaires à sa continuité.

Base technique du service

L’infrastructure PluMail s’appuie sur des composants reconnus et largement utilisés.

  • Hyperviseur : Proxmox VE.
  • Système principal : Debian GNU/Linux.
  • Messagerie : Mailcow et ses composants associés.
  • Pages web et inscription : développement complémentaire en PHP.

Ce choix permet de s’appuyer sur des briques robustes, documentées et cohérentes avec l’approche générale du projet.

Hébergement web et domaine

Le site principal www.plumail.net et la gestion du nom de domaine reposent sur une infrastructure externe distincte.

Certains éléments publics du projet s’appuient ainsi sur OVHcloud, notamment pour la présence web, le nom de domaine et certains services réseau complémentaires.

Ce choix permet de séparer certains rôles, d’améliorer la continuité du service et de limiter les points de dépendance uniques.

Réception et envoi des messages

Envoi des messages

L’envoi des e-mails s’appuie sur un relais SMTP fourni par retzo.net, membre du collectif CHATONS.

Ce choix a été retenu pour améliorer la délivrabilité des messages sortants tout en restant dans un cadre éthique, léger, français et cohérent avec les valeurs du projet.

Réception des messages

En complément, PluMail utilise un MX backup hébergé sur un VPS OVH.

Son rôle est limité à la continuité de réception : si le serveur principal ou la connectivité principale devient temporairement indisponible (par exemple en cas de coupure fibre), les messages entrants peuvent être mis en attente jusqu’à 10 jours avant d’être réessayés vers le serveur principal.

Cela ne remplace pas le service principal et ne constitue pas une haute disponibilité complète, mais cela réduit fortement le risque de rejet immédiat des messages entrants lors d’une panne temporaire.

Sauvegardes

Des sauvegardes régulières sont mises en place pour limiter les conséquences d’un incident technique.

  • Une sauvegarde chiffrée est réalisée quotidiennement.
  • Les sept dernières sauvegardes sont conservées localement.
  • Le stockage principal des sauvegardes est assuré par un Proxmox Backup Server dédié.
  • Une duplication est réalisée vers un NAS Synology local via rsync.
  • Une copie complémentaire est maintenue sur Synology C2.

Cette stratégie correspond à une logique de sauvegarde de type 3-2-1.

Les sauvegardes ont pour objectif de faciliter une restauration en cas de problème, sans pour autant promettre une restauration instantanée ou absolue en toute situation.

Suivi des services et incidents

Le suivi public des services, les maintenances et le journal des événements sont assurés via Cachet, déployé en Docker sous Debian 13 en local, sur le serveur principal.

La page de statut est disponible à l’adresse status.plumail.net.

Le monitoring de certaines pages importantes, comme mail.plumail.net et la page d’inscription, est réalisé via Uptime Kuma, hébergé dans un environnement local distinct sur un Dell Wyse 5070 Thin Client.

En cas d’incident, des alertes sont envoyées via ntfy sur mobile, ce qui permet une réaction rapide lorsqu’un service devient indisponible.

Protection contre les abus

La page d’inscription est protégée contre les bots par Anubis, une solution open source installée en Docker sur le serveur principal.

L’objectif est de limiter les inscriptions abusives tout en restant dans une logique cohérente avec les choix techniques du projet : privilégier des outils ouverts, compréhensibles et proportionnés.

Prestataires et dépendances

Même avec une logique d’indépendance, aucun service en ligne ne fonctionne totalement sans dépendances externes. PluMail cherche à les limiter, à les choisir avec prudence et à les assumer clairement.

À ce jour, les principales dépendances ou briques externes concernent notamment :

  • OVHcloud pour certains services d’infrastructure, la présence web et le MX backup.
  • Synology pour une partie de l’environnement de sauvegarde.
  • Synology C2 pour une copie complémentaire externalisée.
  • retzo.net pour le relais SMTP sortant.

Ces choix ne signifient pas un abandon de la logique d’indépendance. Ils correspondent à des arbitrages pragmatiques visant à maintenir un service stable, raisonnable et exploitable.

Données demandées à l’inscription

PluMail applique un principe simple : ne demander que ce qui est utile au fonctionnement du service.

Lors de l’inscription, il n’est pas demandé de nom, de prénom, de date de naissance ou d’adresse postale. La création d’un compte repose sur un identifiant et un mot de passe.

Cette approche vise à réduire la collecte de données et à conserver un cadre sobre, lisible et proportionné.

Journaux techniques et exploitation

Comme tout service de messagerie et d’hébergement web, PluMail s’appuie sur certains journaux techniques nécessaires au fonctionnement, à la sécurité et au diagnostic en cas d’incident.

Ces éléments peuvent concerner, selon les besoins techniques :

  • les connexions au service ;
  • les événements système ;
  • les opérations de sécurité ou de maintenance ;
  • les erreurs techniques liées au transport des messages.

Ces informations ne sont pas utilisées à des fins publicitaires ou commerciales. Elles servent au maintien du service, à la sécurité et à la résolution d’éventuels problèmes.

Ce que cette page ne fait pas

Par souci de sécurité, cette page ne publie pas d’informations détaillées qui faciliteraient une cartographie complète de l’infrastructure ou des mécanismes de défense du service.

La transparence ne consiste pas à exposer inutilement les éléments sensibles. Elle consiste à expliquer clairement le cadre général, les choix effectués et les limites connues.

En résumé

PluMail repose sur une infrastructure auto-hébergée, complétée par certains services externes choisis pour améliorer la continuité, la sauvegarde, la réception des messages et la délivrabilité.

  • Infrastructure principale administrée directement.
  • Base technique fondée sur Proxmox, Debian et Mailcow.
  • Sauvegardes chiffrées quotidiennes avec conservation des dernières versions.
  • Duplication locale et externalisée des sauvegardes.
  • Suivi des incidents via Cachet, Uptime Kuma et ntfy.
  • Réception renforcée par un MX backup OVH avec mise en attente jusqu’à 10 jours.
  • Envoi des messages via un relais SMTP retzo.net, membre du collectif CHATONS.

L’objectif reste le même : proposer une messagerie simple, cohérente et digne de confiance, avec un fonctionnement expliqué de manière claire.