Nous exécutons maintenant notre propre serveur de messagerie, et cela fonctionne bien pour les e-mails sortants avec Discourse. Je cherche donc maintenant à recevoir des e-mails pour répondre aux publications.
Il y a ce sondage POP3, mais notre Dovecot a POP3 désactivé, utilisant uniquement IMAP. Il existe des paramètres pour les intervalles de sondage IMAP, mais aucun pour activer le sondage IMAP, définir l’hôte, le port, les identifiants, etc., comme pour le sondage POP3. Le sondage IMAP partage-t-il simplement les paramètres du sondage POP3, et est-il alors possible de désactiver efficacement le sondage POP3 en définissant son intervalle à 0 minute ou quelque chose de similaire ?
La question a déjà été posée, mais sans réponse : Is there a way to use IMAP instead of POP3 for replies by email?
Je n’ai pas l’intention d’exécuter un second conteneur Postfix en tant que récepteur de courrier Discourse, et cela ne fonctionnerait de toute façon pas en raison de l’utilisation du port 25 sur l’hôte.
Je pourrais peut-être implémenter cela sous forme de script shell pour le canaliser conditionnellement (e-mail du destinataire), mais le maintenir à jour et fonctionnel n’est probablement pas pratique/raisonnable.
Le sondage IMAP uniquement serait donc ma solution préférée, j’espère que c’est possible.
EDIT : Ou alors nous installons simplement le runtime Ruby et copions les bibliothèques et exécutables du récepteur de courrier et du rejet rapide sur l’hôte, comme le fait le Dockerfile, et l’invoquons depuis notre Postfix via transport_maps de la même manière : mail-receiver/Dockerfile at main · discourse/mail-receiver · GitHub
Quelqu’un a-t-il essayé cela ?
D’accord, un autre membre de l’équipe a mentionné que le sondage IMAP n’a jamais fonctionné correctement, a été quelque peu supprimé, et que ces quelques paramètres semblent être des restes de l’époque où il était censé être implémenté. EDIT : J’ai trouvé une déclaration à ce sujet : IMAP support for group inboxes - #39 by martin
Cela semble être un pas en arrière, car pour moi, POP3 est obsolète et impraticable de nos jours, où les gens utilisent généralement plusieurs clients de messagerie (téléphone + PC minimum). Je ne vois donc aucun intérêt à activer les écouteurs POP3 dans une instance Dovecot.
Cependant, j’ai réussi à implémenter l’API de réception de courrier Discourse directement dans notre Postfix existant sans le conteneur de réception de courrier et même sans ses scripts Ruby, mais en suivant principalement l’intégration Postfix utilisée dans le conteneur de réception de courrier Discourse : mail-receiver/Dockerfile at main · discourse/mail-receiver · GitHub
/etc/postfix/main.cf :
# Pour l'adresse e-mail de réponse de Discourse, nous remplaçons le transport par défaut via la cartographie des transports
transport_maps=hash:/etc/postfix/transport
/etc/postfix/transport
# Un service nommé "discourse" est utilisé comme point de terminaison de transport pour les e-mails à l'adresse de réponse Discourse définie
forum.reply@dietpi.com discourse:
/etc/postfix/master.cf
# Nous définissons le service de transport "discourse" comme un démon de pipe dans curl écoutant sur un socket UNIX (privé)
# Il ne peut pas être non privilégié ou chrooté pour que le pipe dans curl fonctionne
discourse unix - n n - - pipe user=nobody:nogroup argv=/usr/bin/curl -X POST -F email=\<- -H Api-Username:system -H Api-Key:fooooobaaaaarbaaaaaaz https://dietpi.com/forum/admin/email/handle_mail
Ainsi, la cartographie des transports transmet les e-mails à l’adresse de réponse à notre service personnalisé discourse.
Les meilleures performances devraient être un socket UNIX, et il peut être privé (premier -), car rien d’autre ne doit l’utiliser de toute façon. « privé » signifie que le socket est situé dans /var/spool/postfix/private/discourse, dans un répertoire auquel seul l’utilisateur postfix a accès, dans le répertoire chroot de Postfix /var/spool/postfix.
Mais il ne peut pas être non privilégié ou chrooté pour que le pipe dans curl fonctionne (n n).
Nous minimisons ensuite les autorisations en utilisant l’utilisateur/groupe nobody:nogroup.
Conformément à l’API du récepteur, l’e-mail doit être joint à un champ de formulaire email, ce qui peut être fait via l’appel <- STDIN de curl. Les en-têtes Api-Username et Api-Key doivent être ajoutés, le premier étant généralement system, le second pouvant être généré dans Discourse, en tant que clé API granulaire avec uniquement les autorisations receive_emails. Ensuite, en utilisant le point de terminaison HTTP respectif.
Nous sautons intentionnellement les vérifications rapides de la politique de rejet effectuées par le conteneur récepteur :
Il vérifie l’existence des en-têtes From et To, si l’expéditeur est une adresse complète avec un domaine, et s’il figure sur une liste noire qui peut être définie facultativement via la variable de conteneur BLACKLISTED_SENDER_DOMAINS. Et il envoie les adresses de l’expéditeur et du destinataire à un autre point de terminaison API HTTP de Discourse qui vérifie si le destinataire correspond au modèle d’adresse e-mail de réponse configuré, et si l’adresse de l’expéditeur appartient à un utilisateur enregistré, sauf si le forum est configuré pour créer de nouveaux utilisateurs inactifs lors de la réception d’e-mails, ce qui était étrangement activé par défaut dans notre cas ?
La plupart de ces vérifications, et plus encore, sont effectuées de toute façon par notre service récepteur SMTP Postfix public, et tout passe par rspamd, ce qui implique les vérifications DKIM, SPF et DMARC.
Mais surtout, les mêmes vérifications sont effectuées de toute façon par le backend récepteur d’e-mails final de Discourse. Le seul inconvénient : les expéditeurs ne reçoivent pas d’e-mail de rejet/rebond du démon de messagerie, mais les erreurs en cas d’expéditeur/destinataire invalide sont plutôt/uniquement enregistrées dans notre Discourse. Mais si l’expéditeur et le destinataire étaient corrects, seul le contenu de l’e-mail n’est pas conforme aux attentes (en particulier l’en-tête Message-ID manquant), les expéditeurs reçoivent un e-mail approprié de Discourse. Les e-mails de rejet/rebond SMTP manquants sont tout à fait acceptables à mon avis, étant donné que sinon l’implémentation a une surcharge minimale, a une requête réseau et un traitement backend en moins par e-mail, etc.
Généralement : faites attention aux espaces dans les arguments de commande de master.cf. Les guillemets pour conserver les espaces littéralement ne fonctionnent pas. Au lieu de cela, un tel argument devrait être encapsulé dans des accolades : {un argument avec des espaces}. Mais dans ce cas, aucun argument ne contient d’espaces, ceux entre la clé d’en-tête et la valeur sont également facultatifs.
Cela fonctionne très bien jusqu’à présent et s’intègre parfaitement à notre configuration existante avec le transport virtuel par défaut vers Dovecot, et la cartographie des transports est également utilisée pour relayer certains e-mails vers des adresses externes, car tout le monde dans l’équipe ne souhaite pas/n’a pas besoin d’une boîte aux lettres supplémentaire sur notre serveur. Si une adresse universelle est définie dans la cartographie des alias virtuels, l’adresse de réponse Discourse doit être ajoutée à cette table, se mappant à elle-même (comme d’autres utilisateurs/adresses virtuels locaux).