IMAP-Unterstützung für Gruppen-Postfächer

martin · 12. August 2020 um 05:03

Wir entfernen die Unterstützung für IMAP in Discourse. Weitere Informationen finden Sie in diesem Beitrag: IMAP support for group inboxes - #39 by martin .

Wir freuen uns, eine Alpha-Version der IMAP-Unterstützung für Gruppen-Posteingänge vorstellen zu können. Diese Funktion ermöglicht es, IMAP-Anmeldedaten und Einstellungen pro Gruppe einzugeben, um Gruppen-Posteingänge mit einem E-Mail-Postfach zu synchronisieren.

Dies ist eine Funktion im Alpha-Stadium und daher noch nicht zu 100 % vollständig und ausgereift. Es ist sehr wahrscheinlich, dass Fehler auftreten. Wir pflegen sie derzeit nicht und nutzen sie nicht in der Produktion. Nutzung auf eigene Gefahr!

Vorteile

Ihre Gruppe kann sofort mit der Nutzung von Discourse-Posteingängen beginnen, da alle Ihre vorhandenen E-Mails synchronisiert werden!
Ihre Gruppe kann ihre Nachrichten zwischen Discourse und Ihrem E-Mail-Anbieter synchronisieren, sodass es keinen einzelnen Ausfallpunkt gibt. Personen können entweder vom E-Mail-Konto oder innerhalb von Discourse antworten, und alles wird synchronisiert.
Sie müssen keine verrückten Weiterleitungsregeln von Ihrem E-Mail-Anbieter zu Ihrem Discourse-Eingangs-Postfach mehr einrichten.
E-Mail-Labels werden mit Discourse-Tags synchronisiert, sodass alles ordentlich organisiert bleibt.
Sie antworten Personen, die Ihre Gruppe per E-Mail kontaktieren, von der E-Mail-Adresse, die Sie eingerichtet haben, auch wenn Sie von Discourse aus antworten. Keine Verwirrung mehr!

Funktionen

Alle ein- und ausgehenden E-Mails werden zwischen dem IMAP-Server und Discourse synchronisiert. Dabei werden basierend auf geparsten E-Mails entsprechende Themen und Post-Antworten erstellt. Antworten können entweder von Discourse oder vom IMAP-Server erstellt werden, und alles wird synchronisiert!
E-Mails können entweder vom Discourse-Gruppenposteingang ODER vom E-Mail-Konto aus beantwortet werden.
Tags, die auf das Discourse-Thema angewendet werden, werden als Labels erstellt und auf der IMAP-Serverseite auf die E-Mail angewendet (dies ist anbieterabhängig).
Auf dem IMAP-Server archivierte E-Mails werden im Gruppenposteingang archiviert.
Gruppen-Private-Nachrichten-Themen, die in Discourse archiviert werden, werden auf dem IMAP-Server archiviert.
Auf dem IMAP-Server gelöschte E-Mails löschen das Thema im Gruppenposteingang.
Gruppen-Private-Nachrichten-Themen, die in Discourse gelöscht werden, werden auf dem IMAP-Server gelöscht.
E-Mails, die von Gruppen gesendet werden, bei denen diese Funktion aktiviert ist, haben als Antwortadresse denselben E-Mail-Nutzernamen, der in den IMAP-Einstellungen eingerichtet wurde.

Erste Schritte

Zunächst müssen einige Site-Einstellungen konfiguriert werden, bevor Sie diese Funktion für eine Gruppe einrichten können.

enable imap und enable smtp müssen beide aktiviert sein. IMAP wird für die Synchronisierung mit Ihrem Mailserver verwendet, und SMTP wird zum Senden von E-Mails von Ihrem Mailserver verwendet.
tagging enabled und allow staff to tag pms – Beide müssen aktiviert sein, da die Label-Synchronisierung Tags auf private Nachrichten anwendet.
enable imap write – Muss aktiviert sein, wenn Änderungen in Discourse auf Ihrem Mailserver widergespiegelt werden sollen (z. B. Tags, Archivieren von Themen und Löschen von Themen).
enable imap idle – Ermöglicht uns den Empfang von Live-Updates von Ihrem Mailserver, WENN Ihr Mailserver IDLE unterstützt. Dies beschleunigt die Übertragung von Änderungen von Ihrem E-Mail-Anbieter auf Discourse erheblich. Sie sollten dies aktivieren (Gmail unterstützt es beispielsweise). Wenn Sie alle Details wissen möchten, können Sie dazu im RFC für IDLE nachlesen.
imap polling period mins – Wenn IDLE nicht unterstützt wird, ist dies die Anzahl der Minuten, die wir warten, bevor wir den IMAP-Server auf Änderungen prüfen. Es ist auch die Zeit, die wir zwischen dem Senden von Änderungen an den IMAP-Server von Discourse aus warten, wenn enable imap write aktiviert ist. Das Minimum beträgt 1 Minute.

Diese Einstellungen können bei ihren Standardwerten belassen und angepasst werden, wenn Sie Probleme mit der Synchronisierung feststellen:

imap polling old emails – Die maximale Anzahl alter (verarbeiteter) E-Mails, die bei jeder Abfrage eines IMAP-Postfachs aktualisiert werden (0 für alle).
imap polling new emails – Die maximale Anzahl neuer (nicht verarbeiteter) E-Mails, die bei jeder Abfrage eines IMAP-Postfachs aktualisiert werden.
imap batch import email – Die Mindestanzahl neuer E-Mails, die den Importmodus auslöst (deaktiviert Post-Benachrichtigungen).

Wenn Sie möchten, dass Labels/Tags mit dem IMAP-Server synchronisiert werden, müssen Sie die Site-Einstellungen tagging enabled und allow staff to tag pms aktivieren.

Als Nächstes müssen Sie in die Gruppe gehen, die Sie mit Ihrem IMAP-Server synchronisieren möchten, und die Einstellungen ausfüllen.

Diese Einstellungen sind anbieterspezifisch. Weitere Einzelheiten finden Sie weiter unten. Nachdem Sie die Einstellungen und Anmeldedaten eingegeben haben, klicken Sie auf „Änderungen speichern". Wir validieren die Anmeldedaten dann gegen die Server des IMAP-Anbieters. Bei Erfolg wird die Liste der Postfächer aufgefüllt, und Sie müssen auswählen, welches Sie synchronisieren möchten (Hinweise dazu sind ebenfalls anbieterspezifisch):

Wenn die Validierung der Anmeldedaten nicht erfolgreich war, wird eine Fehlermeldung auf der Seite angezeigt. Um es klarzustellen: Der eingegebene SMTP-Server wird verwendet, um E-Mails im Namen des unter Benutzername & Passwort eingegebenen Kontos zu senden, nicht der für Massen-E-Mails konfigurierte Haupt-SMTP von Discourse.

Schließlich müssen Sie in Ihrer app.yml-Datei DISCOURSE_ENABLE_EMAIL_SYNC_DEMON: true im Abschnitt env hinzufügen und ./launcher rebuild ausführen. Dadurch wird der Hintergrundworker gestartet und beginnt mit dem Synchronisieren von E-Mails!

Anbieterspezifische Informationen

Gmail

Sie müssen ein App-Passwort generieren, andernfalls müssen Sie den „Zugriff weniger sicherer Apps" aktivieren, den Google ohnehin irgendwann abschaffen wird. Verwenden Sie dieses Passwort anstelle Ihres Gmail-Kennworts in den IMAP-Einstellungen. Weitere Details finden Sie unter Sign in with app passwords - Gmail Help .
Stellen Sie sicher, dass Sie diese Einstellungen für SMTP und IMAP verwenden:
- IMAP-Port: 987
- SMTP-Port: 587
- IMAP-Server: imap.gmail.com
- SMTP-Server: smtp.gmail.com
- Verwenden Sie SSL für SMTP und IMAP
Es wird dringend empfohlen (bald eine UI-Funktion), dass Sie nur das Postfach „[Gmail]/Alle E-Mails" zur Synchronisierung auswählen.
Wir löschen E-Mails in Gmail nicht sofort, sondern verschieben sie nur in den Papierkorb, wenn das Thema in Discourse gelöscht wird. Die „30-Tage"-Löschfunktion in Gmail übernimmt dann den Rest.
Tags, die auf Discourse-Themen angewendet werden, erstellen Labels in Gmail und wenden sie auf E-Mail-Threads an. Labels in Gmail sind auch IMAP-Postfächer!

Einschränkungen

Dies ist eine Funktion im Alpha-Stadium und daher noch nicht zu 100 % vollständig und ausgereift. Daher gelten derzeit folgende Einschränkungen:

Nur Gmail wird derzeit als IMAP-Anbieter unterstützt. Wir haben einige generische IMAP-Funktionen, aber es ist nicht garantiert, dass sie funktionieren. Outlook Online ist unser nächstes großes Ziel für die Unterstützung.
Das Wiederherstellen gelöschter E-Mails aus dem Gmail-Papierkorb und das Spiegeln des Status in Discourse ist derzeit fehleranfällig.
Es wird nicht empfohlen, das Synchronisierungs-Postfach zu ändern, nachdem E-Mails bereits synchronisiert wurden. Dies kann zu vielen seltsamen Problemen führen.
Pro Gruppe kann nur ein Postfach synchronisiert werden.
Die Kommunikation zwischen Gruppen ist Neuland und wird nicht gut funktionieren (z. B. das Senden einer E-Mail von support@yoursite.com an team@yoursite.com, wenn jede dieser E-Mails für eine andere Gruppe eingerichtet ist).

Da es sich um eine Alpha-Funktion handelt, können es auch andere subtile Fallstricke und Ecken und Kanten geben.

Feedback & Fahrplan

Wir würden uns über Feedback von allen freuen, die diese Funktion mit Gmail nutzen. Ich werde diejenige sein, die sich um die Behebung von Fehlern/Problemen kümmert. Das Debugging ist derzeit etwas schwierig, aber ich arbeite daran!

Als Nächstes werde ich an folgenden Punkten arbeiten:

Verbesserung des Debuggings, um IMAP-Protokolle einfacher einsehen und Fehlerquellen identifizieren zu können.
Verbesserung der Gruppen-E-Mail-Schnittstelle, um die aus Gmail auswählbaren Postfächer einzuschränken und das Ändern von Postfächern zu erschweren/unzulässig zu machen.
Validierung, um die Verwendung derselben IMAP-Details für mehrere Gruppen zu verhindern.
Mögliche Verbesserungen daran, wie die Gruppen-IMAP-Einstellungen gespeichert werden, und eine bessere Benutzererfahrung für die Validierung von Anmeldedaten.
Outlook-Unterstützung.

Während wir die Mängel beheben, ist diese Funktion derzeit für unsere gehosteten Kunden nicht verfügbar.

Besonderer Dank

Sowohl @dan als auch @j.jaffeux sind die Hauptbeitragsleistenden dieses riesigen Features, das über einen langen Zeitraum entwickelt wurde. Ohne ihre hervorragende Arbeit hätte ich das Feature nicht an diesen Punkt bringen und diese Ankündigung machen können .

hellekin · 12. August 2020 um 07:09

Das ist gleichzeitig fantastische und schreckliche Nachricht. Lassen Sie mich das erklären. Erstens ist es großartig, die IMAP-Integration mit Discourse-Gruppen zu sehen, da sie eine Reihe nützlicher Lösungen für die Gruppenidentität bietet (unter Verwendung der korrekten ursprünglichen Adresse), das Arbeiten mehrerer Benutzer mit demselben IMAP-Konto erleichtert (was nativ nicht gut unterstützt wird, z. B. keine gemeinsamen Lesezustände), und den Weg zu ActivityPub-Inboxen öffnet… Aber es ist eine schreckliche Nachricht, da ihre Implementierung E-Mail-Giganten begünstigt, die einen federierten Dienst in ein weitgehend zentralisiertes System verwandelt haben. Ich verstehe die Anziehungskraft, mit großen Anbietern zu arbeiten, aber ich hoffe, dass der IMAP-Standard provider-spezifischen Erweiterungen vorgezogen wird, damit jeder E-Mail-Anbieter unterstützt wird, sobald dieses Feature den Beta-Status erreicht.

Großartige Arbeit, das möglich zu machen.

sam · 12. August 2020 um 08:18

Es gibt einen großen Grund, warum dieses Feature als „Alpha

martin · 12. August 2020 um 08:52

Das ist eine berechtigte Kritik. Wie @sam bereits sagte, haben wir uns zunächst auf Gmail konzentriert, da wir es selbst nutzen und es für uns daher am relevantesten ist. Ich bin jedoch der Meinung, dass unser grundlegender „generischer

itsbhanusharma · 12. August 2020 um 08:57

Das sieht sehr spannend aus! Mein Unternehmen ist kürzlich von unserem eigenen Mailserver auf G-Suite umgestiegen, und diese Integration wird es uns ermöglichen, viel einfacher auf Kundenanfragen zu antworten und unsere Fortschrittsverfolger zu verwalten. Ich habe jedoch eine Frage an @martin: Mir ist nicht ganz klar, ob die Antwort auf in der Gruppen-Posteingang empfangene Nachrichten über den Gmail-SMTP oder über den für Discourse konfigurierten Mass-SMTP gesendet wird. Der Plugin-Hinweis erwähnt zwar den Gmail-SMTP, aber ich wollte hier noch einmal Klarheit.

martin · 12. August 2020 um 08:58

Der Gmail SMTP-Server wird verwendet, um die Antworten zu versenden, da du die Antworten im Namen des E-Mail-Kontos versendest, das für die IMAP-Synchronisierung verwendet wird! Ich werde eine entsprechende Anmerkung im OP hinzufügen, um dies zu verdeutlichen.

itsbhanusharma · 12. August 2020 um 09:02

Das ist tatsächlich genial. Mir fallen so viele Anwendungsfälle dafür ein. Respekt an @martin @dan @j.jaffeux

martin · 17. August 2020 um 00:10

Kurzes Update: Ich habe diese beiden PRs letzte Woche zusammengeführt. Erstens die Korrektur, damit das Tagging nicht mehr aktiviert sein muss, um Archivierung und Löschung zu ermöglichen:

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.

Zweitens schreibe ich jetzt alle IMAP-Protokolle in die Datenbank, um die Überprüfung zu erleichtern. Täglich wird ein Job ausgeführt, um Protokolle älter als 5 Tage zu löschen:

StanD · 21. August 2020 um 22:47

Das ist wirklich nett! Danke.

Ich sollte erwähnen, dass ich in meinem Google-E-Mail-Konto ein App-Passwort erstellen musste, damit Discourse meinen Benutzernamen und mein Passwort akzeptiert.

sunjam · 23. August 2020 um 15:25

Verwendest du auf Google-Seite eine Zwei-Faktor-Authentifizierung? Wenn ja, ist dies übliches Vorgehen.

StanD · 23. August 2020 um 16:34

Ja. Ich glaube, das war erforderlich, um das App-Passwort zu erstellen (obwohl ich mich nicht mehr sicher daran erinnere).

martin · 23. August 2020 um 23:40

[quote=“martin, Beitrag:1, Thema:160588”]
Sie müssen ein App-Passwort erstellen, andernfalls müssen Sie den „Zugriff für weniger sichere Apps

StanD · 24. August 2020 um 01:19

Ups! Habe ich erwähnt, dass mein Leseverständnis zu wünschen übrig lässt?

martin · 24. August 2020 um 01:25

Ist schon in Ordnung! Das ist ein wichtiger Punkt, daher habe ich ihn an den Anfang der Gmail-Liste verschoben und einige Warnhinweise hinzugefügt. Vielen Dank, dass du versucht hast, andere darauf hinzuweisen, um ihnen Ärger zu ersparen

thoka · 6. Februar 2021 um 01:10

Ich versuche zu verstehen, warum die Synchronisierung von E-Mails mit einem Dovecot-IMAP-Server fehlschlägt (leider habe ich keine Erfahrung mit Ruby oder Rails).

Beim Lesen der imap_sync_logs hängt der Import-Daemon in einer Schleife:

UIDVALIDITY = 1612565899 stimmt nicht mit dem erwarteten Wert 0 überein, IMAP-Cache wird ungültig gemacht und E-Mails für das Postfach INBOX werden erneut synchronisiert

Daher frage ich mich, ob @group.imap_uid_validity in diesem Fall nicht aktualisiert werden sollte:

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

Nach einer manuellen Aktualisierung dieses Werts hängt der Import-Daemon in einer anderen Schleife.

Dovecot unterstützt 'LABELS' nicht:

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).

Dies führt zu einem Net::IMAP::BadResponseError, der leider nicht in den Logs erscheint.

Jetzt frage ich mich:

Ist die Unterstützung benutzerdefinierter Flags durch Dovecot für eine bidirektionale Synchronisierung mit Discourse ausreichend?
Wie kann Dovecot in lib/imap/providers/detector.rb erkannt werden?
Wie kann die Label-Funktion in einem Dovecot-Provider emuliert werden?

…

martin · 7. Februar 2021 um 23:39

Die IMAP-Synchronisierung für Gruppenpostfächer ist noch eine Funktion im frühen Stadium, die derzeit nur Gmail unterstützt. Theoretisch könntest du einen Dovecot-Provider schreiben, aber ich habe vor ein paar Wochen festgestellt, dass es im Hauptcode einige Stellen gibt, die nur für Gmail spezifische Funktionen verwenden und die in providerspezifischen Code verschoben werden müssen. Es tut mir leid, aber du solltest vielleicht warten, bis dies etwas produktionsreifer ist.

thoka · 8. Februar 2021 um 14:54

Soweit ich das verstehe, ist 'LABELS' eine nicht-standardkonforme Funktion von Gmail.

Ich möchte den Unterschied zwischen Google IMAP und Standard-IMAP verstehen.

Hier ist meine bisherige Zusammenfassung:

Standard-IMAP	Google-IMAP
Archivierte E-Mails leben in Unterordnern	Alle E-Mails leben in einem Ordner archivierte Nachrichten fehlt das Label “\INBOX”
Benutzerdefinierte Flags werden zusammen mit System-Flags gespeichert	Benutzerdefinierte Flags werden als Labels gespeichert

Wäre es ausreichend

Labels in Standard-IMAP zu emulieren, indem Flags in System- und benutzerdefinierte Flags aufgeteilt werden
email_is_archived vom Provider zu handhaben (z. B. ein “archived”-Flag hinzufügen und testen)
um die Synchronisierung mit Standard-IMAP in Gang zu bringen?

Dies würde diese Zeilen betreffen:

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

Diese Zeile scheint mir seltsam:

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?

Alle System-Flags werden von Discourse-Tags überschrieben.
Werden damit alle IMAP-Flags korrekt behandelt (\Answered, \Deleted, \Draft, \Flagged, \Recent und \Seen / $Forwarded, $MDNSent, $SubmitPending und $Submitted)?

StanD · 29. März 2021 um 02:58

Ich schaue das nach einiger Zeit wieder an.

Ich habe nicht herausfinden können, wie man den reply-to-Header korrekt einrichtet. Ich kann eine Gruppe so einrichten, dass sie mit einem bestimmten Gmail-Konto synchronisiert wird, aber wenn ich versuche, per E-Mail zu antworten, wird die reply-to-Adresse auf die konfigurierte Benachrichtigungs-E-Mail aus Discourse und nicht auf die IMAP-Adresse gesetzt.

Fehlt mir hier etwas?

mognet · 16. Oktober 2021 um 16:15

Wir haben das gerade mit dem E-Mail-Anbieter GoDaddy getestet, leider ohne Erfolg. Mit Gmail funktioniert es hervorragend, aber wir möchten gerne unsere eigene Domain nutzen. Gibt es dazu bereits Updates, damit es einsatzbereit ist?

pfaffman · 16. Oktober 2021 um 17:58

Du kannst deine eigene Domain mit Gmail verwenden (gegen Gebühr), falls es dich interessiert.

Thema		Antworten	Aufrufe
Is it possible to use Discourse for e-mail? Support	5	1428	9. September 2021
Discourse settings: IMAP Support	1	68	14. August 2024
Discourse as a private email support portal Feature rfc , spec	45	23284	10. Mai 2016
Replacing Mailing lists: Email-In Feature	67	17150	4. Oktober 2014
Migrate a mailing list to Discourse (mbox, Listserv, Google Groups, etc) Migrating to Discourse how-to	109	24223	3. April 2026

Vorteile

Funktionen

Erste Schritte

Anbieterspezifische Informationen

Gmail

Einschränkungen

Feedback & Fahrplan

Besonderer Dank

Verwandte Themen