Prise en charge d'IMAP pour les boîtes de réception de groupe

martin · Août 12, 2020, 5:03

Nous supprimons le support IMAP dans Discourse. Consultez ce post pour plus de détails IMAP support for group inboxes - #39 by martin .

Nous sommes ravis de présenter une version alpha du support IMAP pour les boîtes de réception de groupes. Cette fonctionnalité permet d’entrer les identifiants et paramètres IMAP par groupe pour synchroniser les boîtes de réception de groupes avec une boîte de réception email.

Il s’agit d’une fonctionnalité de stade alpha, elle n’est donc pas 100 % complète et polie. Elle est très probablement cassée, nous ne la maintenons pas actuellement ni ne l’utilisons en production. À utiliser à vos propres risques !

Avantages

Votre groupe peut démarrer immédiatement avec les boîtes de réception Discourse, car tous vos emails existants seront synchronisés !
Votre groupe peut faire synchroniser ses messages entre Discourse et votre fournisseur de messagerie afin qu’il n’y ait pas de point de défaillance unique. Les personnes peuvent répondre depuis le compte email ou depuis Discourse, et tout sera synchronisé
Vous n’aurez plus besoin de configurer des règles de transfert compliquées de votre fournisseur de messagerie vers votre boîte de réception entrante Discourse.
Les étiquettes email seront synchronisées avec les balises Discourse pour que tout soit bien organisé
Vous répondrez aux personnes qui envoient des emails à votre groupe depuis l’adresse email que vous avez configurée, même si vous répondez depuis Discourse. Finis les confusions !

Fonctionnalités

Tous les emails entrants et sortants seront synchronisés entre le serveur IMAP et Discourse, avec la création des sujets et des réponses appropriées basées sur les emails analysés. Les réponses peuvent être créées depuis Discourse ou depuis le serveur IMAP et tout sera synchronisé !
Les emails peuvent être répondus depuis la boîte de réception de groupe Discourse OU depuis le compte email.
Les balises appliquées au sujet Discourse seront créées sous forme d’étiquettes et appliquées à l’email sur le serveur IMAP (cela dépend du fournisseur).
Les emails archivés sur le serveur IMAP seront archivés dans la boîte de réception du groupe.
Les sujets de messages privés de groupe archivés sur Discourse seront archivés sur le serveur IMAP.
Les emails supprimés sur le serveur IMAP supprimeront le sujet dans la boîte de réception du groupe.
Les sujets de messages privés de groupe supprimés sur Discourse seront supprimés sur le serveur IMAP.
Les emails envoyés par des groupes avec cette fonctionnalité activée auront leur adresse de réponse définie sur le même nom d’utilisateur email configuré dans les paramètres IMAP.

Pour commencer

Tout d’abord, il y a quelques paramètres de site que vous devez configurer avant de pouvoir mettre en place cette fonctionnalité sur un groupe.

enable imap et enable smtp doivent tous deux être activés. IMAP est utilisé pour la synchronisation avec votre serveur de messagerie, et SMTP est utilisé pour envoyer des emails depuis votre serveur de messagerie.
tagging enabled et allow staff to tag pms - Les deux doivent être activés, car la synchronisation des étiquettes applique des balises aux messages privés.
enable imap write - Doit être activé si vous souhaitez que les modifications effectuées dans Discourse se reflètent sur votre serveur de messagerie (par exemple, balises, archivage de sujets et suppression de sujets).
enable imap idle - Nous permet de recevoir des mises à jour en direct depuis votre serveur de messagerie SI votre serveur de messagerie prend en charge IDLE. Cela accélère considérablement la réflexion des changements de votre fournisseur de messagerie vers Discourse. Vous devriez l’activer (Gmail le prend en charge, par exemple). Si vous voulez tous les détails techniques, vous pouvez lire à ce sujet dans la RFC pour IDLE.
imap polling period mins - Si IDLE n’est pas pris en charge, c’est le nombre de minutes que nous attendons avant de vérifier le serveur IMAP pour les changements. C’est aussi le temps que nous attendons entre l’envoi des changements au serveur IMAP depuis Discourse si enable imap write est activé. Le minimum est de 1 minute.

Ces paramètres peuvent être laissés par défaut et ajustés si vous rencontrez des problèmes de synchronisation :

imap polling old emails - Le nombre maximum d’anciens emails (traités) à mettre à jour à chaque interrogation d’une boîte IMAP (0 pour tous).
imap polling new emails - Le nombre maximum de nouveaux emails (non traités) à mettre à jour à chaque interrogation d’une boîte IMAP.
imap batch import email - Le nombre minimum de nouveaux emails qui déclenchent le mode d’importation (désactive les alertes de publication).

Si vous souhaitez que les étiquettes/balises soient synchronisées avec le serveur IMAP, vous devez activer les paramètres de site tagging enabled et allow staff to tag pms.

Ensuite, vous devez accéder au groupe que vous souhaitez synchroniser avec votre serveur IMAP et remplir les paramètres.

Ces paramètres seront spécifiques au fournisseur, consultez ci-dessous pour plus de détails. Une fois que vous avez saisi les paramètres et les identifiants, cliquez sur “Enregistrer les modifications” et nous validerons les identifiants contre les serveurs du fournisseur IMAP. En cas de succès, la liste des boîtes de réception sera remplie et vous devrez choisir celle que vous souhaitez synchroniser (les conseils à ce sujet sont également spécifiques au fournisseur) :

Si la validation des identifiants n’a pas réussi, un message d’erreur s’affichera sur la page. Pour être clair, le serveur SMTP saisi sera utilisé pour envoyer des emails au nom du compte saisi sous nom d’utilisateur et mot de passe, et non le serveur SMTP principal de Discourse configuré pour les emails en masse.

Enfin, dans votre fichier app.yml, vous devrez ajouter DISCOURSE_ENABLE_EMAIL_SYNC_DEMON: true dans la section env et exécuter ./launcher rebuild. Cela permettra au processus d’arrière-plan de démarrer et de commencer à synchroniser les emails !

Informations spécifiques au fournisseur

Gmail

Vous devez générer un mot de passe d’application, sinon vous devez activer “Accès aux applications moins sécurisées” que Google éliminera de toute façon à un moment donné. Utilisez ce mot de passe à la place de votre mot de passe de compte Gmail dans les paramètres IMAP. Consultez Sign in with app passwords - Gmail Help pour plus de détails.
Assurez-vous d’utiliser ces paramètres pour SMTP et IMAP :
- Port IMAP : 987
- Port SMTP : 587
- Serveur IMAP : imap.gmail.com
- Serveur SMTP : smtp.gmail.com
- Utilisez SSL pour SMTP et IMAP
Il est fortement recommandé (bientôt une fonctionnalité d’interface utilisateur) de ne sélectionner que la boîte de réception “[Gmail]/All Mail” pour la synchronisation.
Nous ne supprimons pas immédiatement les emails dans Gmail, nous les déplaçons simplement vers la corbeille lorsque le sujet est supprimé dans Discourse. La fonctionnalité de suppression “30 jours” dans Gmail prendra le relais à partir de là.
Les balises appliquées aux sujets Discourse créeront des étiquettes dans Gmail et les appliqueront aux fils de discussion. Les étiquettes dans Gmail sont également des boîtes de réception IMAP !

Limitations

Il s’agit d’une fonctionnalité de stade alpha, elle n’est donc pas 100 % complète et polie. Par conséquent, les limitations suivantes s’appliquent actuellement :

Seul Gmail est actuellement pris en charge en tant que fournisseur IMAP. Nous disposons d’une fonctionnalité IMAP générique, mais elle n’est pas garantie de fonctionner. Outlook Online est notre prochain grand objectif de prise en charge.
La résurrection des emails supprimés de la corbeille de Gmail et la réflexion de l’état dans Discourse est actuellement instable.
Changer la boîte de réception de synchronisation après que des emails ont déjà été synchronisés n’est pas recommandé et peut entraîner de nombreux problèmes étranges.
Une seule boîte de réception peut être synchronisée par groupe.
La communication de groupe à groupe est un territoire inexploré et ne fonctionnera pas bien (par exemple, envoyer un email à team@yoursite.com depuis support@yoursite.com si chacun de ces emails est configuré pour un groupe différent).

Il peut également y avoir d’autres pièges subtils et des aspérités, car il s’agit d’une fonctionnalité alpha.

Retour d’information & Feuille de route

Nous aimerions recevoir des retours de toute personne utilisant cette fonctionnalité avec Gmail. Je serai celui qui travaillera à corriger les bugs/problèmes. Le débogage est un peu difficile pour le moment, mais je travaille là-dessus !

Les prochaines choses sur lesquelles je vais travailler :

Améliorer le débogage pour faciliter la visualisation des journaux IMAP et identifier les problèmes.
Améliorer l’interface de messagerie de groupe pour limiter les boîtes de réception pouvant être sélectionnées dans Gmail et décourager/interdire le changement de boîtes de réception.
Validation pour empêcher l’utilisation des mêmes détails IMAP pour plusieurs groupes.
Éventuellement, des améliorations sur la façon dont les paramètres IMAP de groupe sont stockés et une meilleure expérience utilisateur pour valider les identifiants.
Prise en charge d’Outlook.

Actuellement, tandis que nous réglons les problèmes, cette fonctionnalité n’est pas disponible pour nos clients hébergés.

Remerciements spéciaux

@dan et @j.jaffeux sont les principaux contributeurs de cette énorme fonctionnalité qui a été travaillée pendant longtemps. Sans leur travail incroyable, je n’aurais pas été capable d’amener la fonctionnalité à ce stade et de faire cette annonce .

hellekin · Août 12, 2020, 7:09

C’est à la fois une nouvelle fantastique et une nouvelle terrible. Laissez-moi vous expliquer. Premièrement, c’est une excellente nouvelle de voir l’intégration IMAP avec les groupes Discourse, car elle apporte plusieurs solutions utiles pour l’identité des groupes (en utilisant l’adresse d’origine correcte), facilite l’utilisation d’un même compte IMAP par plusieurs utilisateurs (mal pris en charge nativement, par exemple pas d’états de lecture partagés), et ouvre la voie aux boîtes de réception ActivityPub… Mais c’est une nouvelle terrible car sa mise en œuvre favorise les géants de l’email qui ont transformé un service fédéré en un système largement centralisé. Je comprends l’attrait de travailler avec des fournisseurs à grande échelle, mais j’espère que la norme IMAP sera privilégiée par rapport aux extensions spécifiques aux fournisseurs, afin que tout fournisseur de messagerie soit pris en charge une fois que cette fonctionnalité atteindra l’état bêta.

Bravo pour avoir rendu cela possible.

sam · Août 12, 2020, 8:18

Il y a une bonne raison pour laquelle cette fonctionnalité est considérée comme « alpha »

Le problème avec IMAP, d’après ce que j’ai pu observer de loin, est la quantité de « ouvert à interprétation » avec laquelle nous sommes contraints de composer.

Nous souhaitons certainement que cela fonctionne avec plus de fournisseurs ; notre priorité interne penche vers le grand écosystème Google, car en réalité, nous utilisons Google chez Discourse, donc nous avons voulu résoudre notre problème en premier.

Les PR pour améliorer la compatibilité avec d’autres fournisseurs sont bien sûr les bienvenues. À défaut, au fil du temps et à mesure que nous observerons un plus grand désir d’utiliser cette fonctionnalité avec d’autres fournisseurs, nous développerons le support nécessaire.

martin · Août 12, 2020, 8:52

C’est une critique pertinente. Comme l’a mentionné @sam, nous avons d’abord ciblé Gmail car c’est celui que nous utilisons, ce qui le rend le plus pertinent pour nous. Cependant, je pense que notre fournisseur de base « générique », bien qu’il ne soit certainement pas conforme à 100 % aux normes RFC et qu’il ne soit pas complet en termes de fonctionnalités, suit le protocole IMAP de très près… voir https://github.com/discourse/discourse/blob/master/lib/imap/providers/generic.rb. Les seules modifications nécessaires, selon moi, concernent la gestion spéciale de l’archivage et de la suppression. Pour la suppression, nous marquons actuellement les messages avec \Deleted et envoyons une commande EXPUNGE, mais je sais que certains clients de messagerie permettent de choisir entre cette méthode ou d’envoyer d’abord les messages vers un dossier corbeille avant d’exécuter EXPUNGE, etc. Je ne suis pas certain de connaître la norme d’archivage pour IMAP. Nous disposons d’une classe spécifique pour Gmail qui remplace certaines de ces méthodes génériques.

Si vous avez des suggestions concernant d’autres serveurs ou fournisseurs IMAP « génériques » sur lesquels je pourrais tester, cela nous serait d’une grande aide, car Gmail a sa propre gestion particulière des choses et ses propres extensions IMAP pour Gmail.

De plus, comme l’a dit Sam, toute contribution (PR) visant à améliorer le système est la bienvenue. Sinon, nous nous adapterons à la demande, et je prédis que la prochaine grande demande viendra d’Outlook, un autre cas d’usage important pour les organisations souhaitant ce type de fonctionnalité (Outlook a également ses propres règles particulières… par exemple, l’archivage correspond à un dossier/boîte aux lettres et il n’y a pas de support des étiquettes).

itsbhanusharma · Août 12, 2020, 8:57

Cela semble très prometteur. Mon entreprise est récemment passée de notre propre serveur de messagerie à G-Suite, et cette intégration nous facilitera grandement la tâche pour répondre aux demandes des clients et gérer nos suiveurs de progression. J’ai une question pour @martin cependant. Il n’est pas clair pour moi si cela utilisera le SMTP de Gmail pour répondre aux messages reçus dans la boîte de réception de groupe, ou s’il utilisera le SMTP de masse configuré pour envoyer des emails au nom de Discourse. Je vois que le plugin mentionne également le SMTP de Gmail, mais je souhaitais tout de même avoir des éclaircissements à ce sujet.

martin · Août 12, 2020, 8:58

Le serveur SMTP de Gmail est utilisé pour envoyer les réponses, car vous envoyez les réponses au nom du compte e-mail utilisé pour la synchronisation IMAP ! J’ajouterai une note à cet effet dans le premier message pour clarifier cela.

itsbhanusharma · Août 12, 2020, 9:02

C’est vraiment brillant. Je peux penser à autant de cas d’usage pour cela. Félicitations @martin @dan @j.jaffeux

martin · Août 17, 2020, 12:10

Mise à jour rapide. J’ai fusionné ces deux PRs la semaine dernière. Premièrement, la correction pour que le balisage ne soit plus nécessaire pour activer l’archivage et la suppression :

github.com/discourse/discourse

FIX: Do not require tagging to be enabled for IMAP archive and delete (#10426)

master ← issue/imap-do-not-require-tagging-for-archive-and-delete

merged 04:04AM - 13 Aug 20 UTC

martin-brennan

+39 -9

Previously we did an early return if either SiteSetting.tagging_enabled or Site…Setting.allow_staff_to_tag_pms was false when updating the email on the IMAP server -- however this also stopped us from archiving or deleting emails if either of these were disabled.

Deuxièmement, je consigne désormais tous les journaux IMAP dans la base de données afin de faciliter leur examen. Un travail sera exécuté quotidiennement pour supprimer les journaux de plus de 5 jours :

StanD · Août 21, 2020, 10:47

C’est super sympa ! Merci.

Je dois dire que j’ai dû créer un mot de passe d’application dans mon compte Google pour que Discourse accepte mon nom d’utilisateur et mon mot de passe.

sunjam · Août 23, 2020, 3:25

Utilisez-vous l’authentification à deux facteurs côté Google ? Si oui, c’est une pratique courante.

StanD · Août 23, 2020, 4:34

Oui. Je pense que c’était nécessaire pour que je puisse créer le mot de passe d’application (bien que je ne m’en souvienne pas avec certitude).

martin · Août 23, 2020, 11:40

Ceci est noté dans le message d’origine Sinon, vous devez accomplir des exploits incroyables pour que votre compte Gmail accepte les « applications moins sécurisées ». À un moment donné, nous devrons prendre en charge OAuth pour Google, car c’est apparemment la direction dans laquelle les choses évoluent.

StanD · Août 24, 2020, 1:19

Oups ! Ai-je mentionné que mes compétences en compréhension de lecture sont nulles ?

martin · Août 24, 2020, 1:25

Ce n’est pas grave ! C’est un point important, alors je l’ai déplacé en haut de la liste Gmail et j’ai ajouté des indicateurs d’alerte. Merci d’avoir essayé d’informer les autres à ce sujet pour leur éviter des tracas

thoka · Février 6, 2021, 1:10

J’essaie de comprendre pourquoi la synchronisation des courriels avec un serveur IMAP Dovecot échoue (malheureusement sans expérience en Ruby ou Rails).

En consultant les imap_sync_logs, le daemon d’importation reste bloqué dans une boucle :

UIDVALIDITY = 1612565899 ne correspond pas à la valeur attendue 0, invalidation du cache IMAP et resynchronisation des courriels pour la boîte de réception INBOX

Je me demande donc si @group.imap_uid_validity ne devrait pas être mis à jour dans ce cas :

github.com/discourse/discourse

lib/imap/sync.rb

f34fa999a


      
          # (synced emails) and fetches new emails.
          
          # TODO: Use `Net::IMAP.encode_utf7(@group.imap_mailbox_name)`?
          @status = @provider.open_mailbox(@group.imap_mailbox_name)
          
          if @status[:uid_validity] != @group.imap_uid_validity
            # If UID validity changes, the whole mailbox must be synchronized (all
            # emails are considered new and will be associated to existent topics
            # in Email::Reciever by matching Message-Ids).
            ImapSyncLog.warn("UIDVALIDITY = #{@status[:uid_validity]} does not match expected #{@group.imap_uid_validity}, invalidating IMAP cache and resyncing emails for mailbox #{@group.imap_mailbox_name}", @group)
            @group.imap_last_uid = 0
          end
          
          if idle && !can_idle?
            ImapSyncLog.warn("IMAP server for group cannot IDLE or imap idle site setting is disabled", @group)
            idle = false
          end
          
          if idle
            raise 'IMAP IDLE is disabled' if !SiteSetting.enable_imap_idle

Après une mise à jour manuelle de cette valeur, le daemon d’importation reste bloqué dans une autre boucle.

Dovecot ne prend pas en charge 'LABELS' dans

github.com/discourse/discourse

lib/imap/sync.rb

f34fa999a


      
          
              # the email has moved mailboxes, we don't want to try marking as spam again next time
              ImapSyncLog.debug("Updating incoming ID #{incoming.id} uid data FROM [UID #{incoming.imap_uid} | UIDVALIDITY #{incoming.imap_uid_validity}] TO [UID #{matching_spam.uid} | UIDVALIDITY #{response.spam_uid_validity}] (SPAM)", @group)
              incoming.update(imap_uid_validity: response.spam_uid_validity, imap_uid: matching_spam.uid)
            end
          end
          
          def process_new_uids(new_uids, import_mode, all_old_uids_size, all_new_uids_size)
            ImapSyncLog.debug("Syncing #{new_uids.size} new emails (oldest first)", @group)
          
            emails = @provider.emails(new_uids, ['UID', 'FLAGS', 'LABELS', 'RFC822'])
            processed = 0
          
            # TODO (maybe): We might need something here to exclusively handle
            # the UID of the incoming email, so we don't end up with a race condition
            # where the same UID is handled multiple times before the group imap_X
            # columns are updated.
            emails.each do |email|
              # Synchronously process emails because the order of emails matter
              # (for example replies must be processed after the original email
              # to have a topic where the reply can be posted).

ce qui entraîne une Net::IMAP::BadResponseError qui, malheureusement, n’apparaît pas dans les journaux.

Je me demande maintenant :

si la prise en charge des drapeaux personnalisés par Dovecot est suffisante pour une synchronisation bidirectionnelle avec Discourse
comment détecter Dovecot dans lib/imap/providers/detector.rb
comment émuler la fonctionnalité d’étiquettes dans un fournisseur Dovecot

…

martin · Février 7, 2021, 11:39

La synchronisation IMAP pour les boîtes de réception de groupe est toujours une fonctionnalité en phase précoce qui ne prend actuellement en charge que Gmail. En théorie, vous pourriez créer un fournisseur dovecot, mais j’ai remarqué il y a quelques semaines qu’il existe certains endroits dans le code principal qui utilisent des fonctionnalités spécifiques à Gmail et qui doivent être déplacés dans du code spécifique au fournisseur. Je suis donc désolé pour cela, mais vous voudrez peut-être attendre que cela soit un peu plus prêt pour la production.

thoka · Février 8, 2021, 2:54

À ma connaissance, 'LABELS' est une fonctionnalité non standard de Gmail.
Je souhaiterais comprendre la différence entre Google IMAP et l’IMAP standard.

Voici mon résumé jusqu’à présent :

IMAP standard	Google IMAP
Les e-mails archivés vivent dans des sous-dossiers	Tous les e-mails vivent dans un seul dossier les e-mails archivés sont dépourvus de l’étiquette `\\INBOX`
Les drapeaux personnalisés sont stockés avec les drapeaux système	Stocke les drapeaux personnalisés sous forme d’étiquettes

Suffirait-il :

d’émuler les étiquettes dans l’IMAP standard en séparant les drapeaux en drapeaux système et personnalisés
de gérer email_is_archived au niveau du fournisseur (par exemple, ajouter et tester un drapeau « archivé »)
pour que la synchronisation IMAP standard fonctionne ?

Cela affecterait ces lignes :

github.com/discourse/discourse

lib/imap/sync.rb

f34fa999a


      
                update_email(incoming_email)
                incoming_email.update(imap_sync: false)
              end
            end
          end
          
          def update_topic_archived_state(email, incoming_email, opts = {})
            topic = incoming_email.topic
          
            topic_is_archived = topic.group_archived_messages.size > 0
            email_is_archived = !email['LABELS'].include?('\\Inbox') && !email['LABELS'].include?('INBOX')
          
            if topic_is_archived && !email_is_archived
              ImapSyncLog.debug("Unarchiving topic ID #{topic.id}, email was unarchived", @group)
              GroupArchivedMessage.move_to_inbox!(@group.id, topic, skip_imap_sync: true)
            elsif !topic_is_archived && email_is_archived
              ImapSyncLog.debug("Archiving topic ID #{topic.id}, email was archived", @group)
              GroupArchivedMessage.archive!(@group.id, topic, skip_imap_sync: true)
            end
          end

github.com/discourse/discourse

lib/imap/sync.rb

f34fa999a


      
          # don't do any of these type of updates on anything but the OP in the
          # email thread -- archiving and deleting will be handled for the whole
          # thread depending on provider
          return if post&.post_number != 1
          topic = incoming_email.topic
          
          # if email is nil, the UID does not exist in the provider, meaning....
          #
          # A) the email has been deleted/moved to a different mailbox in the provider
          # B) the UID does not belong to the provider
          email = @provider.emails(incoming_email.imap_uid, ['FLAGS', 'LABELS']).first
          return if !email.present?
          
          labels = email['LABELS']
          flags = email['FLAGS']
          new_labels = []
          new_flags = []
          
          # Topic has been deleted if it is not present from the post, so we need
          # to trash the IMAP server email
          if !topic

github.com/discourse/discourse

lib/imap/sync.rb

f34fa999a


      
            return @provider.trash(incoming_email.imap_uid)
          end
          
          # the topic is archived, and the archive should be reflected in the IMAP
          # server
          topic_archived = topic.group_archived_messages.any?
          if !topic_archived
            # TODO: This is needed right now so the store below does not take it
            # away again...ideally we should unarchive and store the tag-labels
            # at the same time.
            new_labels << "\\Inbox"
          
            ImapSyncLog.debug("Unarchiving UID #{incoming_email.imap_uid} (incoming ID #{incoming_email.id})", @group)
          
            # some providers need special handling for unarchiving too
            @provider.unarchive(incoming_email.imap_uid)
          else
            ImapSyncLog.debug("Archiving UID #{incoming_email.imap_uid} (incoming ID #{incoming_email.id})", @group)
          
            # some providers need special handling for archiving. this way we preserve
            # any new tag-labels, and archive, even though it may cause extra requests

Cette ligne me semble étrange :

github.com/discourse/discourse

lib/imap/sync.rb

f34fa999a


      
          
              # some providers need special handling for archiving. this way we preserve
              # any new tag-labels, and archive, even though it may cause extra requests
              # to the IMAP server
              @provider.archive(incoming_email.imap_uid)
            end
          
            # Sync topic status and labels with email flags and labels.
            if tagging_enabled?
              tags = topic.tags.pluck(:name)
              new_flags = tags.map { |tag| @provider.tag_to_flag(tag) }.reject(&:blank?)
              new_labels = new_labels.concat(tags.map { |tag| @provider.tag_to_label(tag) }.reject(&:blank?))
            end
          
            # regardless of whether the topic needs to be archived we still update
            # the flags and the labels
            @provider.store(incoming_email.imap_uid, 'FLAGS', flags, new_flags)
            @provider.store(incoming_email.imap_uid, 'LABELS', labels, new_labels)
          end
          
          def tagging_enabled?

Tous les drapeaux système seront écrasés par les étiquettes de Discourse.
Cela gère-t-il correctement tous les drapeaux IMAP (\Answered, \Deleted, \Draft, \Flagged, \Recent et \Seen / $Forwarded, $MDNSent, $SubmitPending et $Submitted) ?

StanD · Mars 29, 2021, 2:58

Je reviens sur ce sujet après une absence.

Je n’ai pas réussi à comprendre comment faire fonctionner correctement l’en-tête reply-to. Je peux configurer un groupe pour qu’il se synchronise avec un compte Gmail spécifique, mais lorsque j’essaie de répondre par e-mail, l’adresse reply-to est définie sur l’e-mail de notification configuré dans Discourse et non sur l’adresse IMAP.

Y a-t-il quelque chose que j’aurais manqué ?

mognet · Octobre 16, 2021, 4:15

Je viens de tester cela avec le fournisseur de messagerie GoDaddy, mais sans succès. Avec Gmail, cela fonctionne parfaitement, mais nous souhaitons malheureusement utiliser notre propre domaine. Y a-t-il des mises à jour pour que cela soit prêt pour une utilisation en production ?

pfaffman · Octobre 16, 2021, 5:58

Vous pouvez utiliser votre propre nom de domaine avec Gmail (contre paiement), pour info.

Sujet		Réponses	Vues
Is it possible to use Discourse for e-mail? Support	5	1428	Septembre 9, 2021
Discourse settings: IMAP Support	1	68	Août 14, 2024
Discourse as a private email support portal Feature rfc , spec	45	23284	Mai 10, 2016
Replacing Mailing lists: Email-In Feature	67	17150	Octobre 4, 2014
Migrate a mailing list to Discourse (mbox, Listserv, Google Groups, etc) Migrating to Discourse how-to	109	24223	Avril 3, 2026

Avantages

Fonctionnalités

Pour commencer

Informations spécifiques au fournisseur

Gmail

Limitations

Retour d’information & Feuille de route

Remerciements spéciaux

Sujets connexes