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’utilisateurpostfixa 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
pipedanscurlfonctionne (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êtesApi-UsernameetApi-Keydoivent être ajoutés, le premier étant généralementsystem, le second pouvant être généré dans Discourse, en tant que clé API granulaire avec uniquement les autorisationsreceive_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
FrometTo, 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 conteneurBLACKLISTED_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).