Supporto IMAP per caselle di posta di gruppo

martin · 12 Agosto 2020, 5:03am

Stiamo rimuovendo il supporto per IMAP in Discourse. Consulta questo post per i dettagli: IMAP support for group inboxes - #39 by martin .

Siamo lieti di presentare una versione alpha del supporto IMAP per le caselle di posta dei gruppi. Questa funzionalità permette di inserire le credenziali e le impostazioni IMAP su base per gruppo, sincronizzando le caselle di posta dei gruppi con una casella di posta elettronica.

Questa è una funzionalità in fase alpha e, di conseguenza, non è al 100% completa e rifinita. È molto probabile che presenti malfunzionamenti; al momento non la stiamo mantenendo né utilizzandola in produzione. Usala a tuo rischio e pericolo!

Vantaggi

Il tuo gruppo può iniziare subito a utilizzare le caselle di posta di Discourse, poiché tutta la tua posta esistente verrà sincronizzata!
Il tuo gruppo può sincronizzare i messaggi tra Discourse e il tuo provider di posta elettronica, eliminando il singolo punto di guasto. Le persone possono rispondere dall’account email o direttamente da Discourse e tutto verrà sincronizzato
Non dovrai più impostare regole di inoltro complicate dal tuo provider di posta elettronica alla casella di posta in arrivo di Discourse.
Le etichette della posta elettronica verranno sincronizzate con i tag di Discourse, mantenendo tutto ordinato
Risponderai alle persone che scrivono al tuo gruppo dall’indirizzo email che hai configurato, anche se rispondi da Discourse. Niente più confusione!

Funzionalità

Tutta la posta in arrivo e in uscita verrà sincronizzata tra il server IMAP e Discourse, creando gli argomenti e le risposte ai post appropriati in base alle email analizzate. Le risposte possono essere create da Discourse o dal server IMAP e tutto verrà sincronizzato!
Le email possono essere risposte dalla casella di posta del gruppo di Discourse OPPURE dall’account email.
I tag applicati all’argomento di Discourse verranno creati come etichette e applicati all’email sul server IMAP (questo dipende dal provider).
Le email archiviate sul server IMAP verranno archiviate nella casella di posta del gruppo.
Gli argomenti di messaggi privati di gruppo archiviati su Discourse verranno archiviati sul server IMAP.
Le email eliminate sul server IMAP elimineranno l’argomento nella casella di posta del gruppo.
Gli argomenti di messaggi privati di gruppo eliminati su Discourse verranno eliminati sul server IMAP.
Le email inviate dai gruppi con questa funzionalità abilitata avranno l’indirizzo “rispondi a” impostato sullo stesso nome utente email configurato nelle impostazioni IMAP.

Per iniziare

Prima di tutto, ci sono alcune impostazioni del sito che devi configurare prima di poter impostare questa funzionalità su un gruppo.

enable imap e enable smtp devono essere entrambi abilitati. IMAP viene utilizzato per la sincronizzazione con il tuo server di posta, mentre SMTP viene utilizzato per inviare email dal tuo server di posta.
tagging enabled e allow staff to tag pms - Devono essere entrambi abilitati, poiché la sincronizzazione delle etichette applica i tag ai messaggi privati.
enable imap write - Deve essere abilitato se desideri che le modifiche apportate in Discourse si riflettano sul tuo server di posta (ad esempio tag, archiviazione e cancellazione di argomenti).
enable imap idle - Ci permette di ricevere aggiornamenti in tempo reale dal tuo server di posta SE il tuo server supporta IDLE. Questo accelera notevolmente il riflesso delle modifiche dal tuo provider di posta a Discourse. Dovresti attivarlo (ad esempio, Gmail lo supporta). Se vuoi tutti i dettagli tecnici, puoi leggere l’RFC per IDLE.
imap polling period mins - Se IDLE non è supportato, questo è il numero di minuti che attendiamo prima di controllare il server IMAP per le modifiche. È anche il tempo che attendiamo tra l’invio delle modifiche al server IMAP da Discourse se enable imap write è abilitato. Il minimo è 1 minuto.

Queste impostazioni possono essere lasciate ai valori predefiniti e modificate se riscontri problemi con la sincronizzazione:

imap polling old emails - Il numero massimo di email vecchie (elaborate) da aggiornare ogni volta che viene interrogata una casella IMAP (0 per tutte).
imap polling new emails - Il numero massimo di email nuove (non elaborate) da aggiornare ogni volta che viene interrogata una casella IMAP.
imap batch import email - Il numero minimo di email nuove che attivano la modalità di importazione (disabilita gli avvisi dei post).

Se desideri che le etichette/tag vengano sincronizzate con il server IMAP, devi abilitare le impostazioni del sito tagging enabled e allow staff to tag pms.

Successivamente, devi accedere al gruppo che desideri sincronizzare con il tuo server IMAP e compilare le impostazioni.

Queste impostazioni sono specifiche del provider; consulta i dettagli qui sotto. Una volta inserite le impostazioni e le credenziali, fai clic su “Salva modifiche” e verificheremo le credenziali contro i server del provider IMAP. In caso di successo, l’elenco delle caselle di posta verrà popolato e dovrai scegliere quella che desideri sincronizzare (le istruzioni sono anch’esse specifiche del provider):

Se la validazione delle credenziali non va a buon fine, verrà visualizzato un messaggio di errore nella pagina. Per essere chiari, il server SMTP inserito verrà utilizzato per inviare email a nome dell’account inserito sotto nome utente e password, non del server SMTP principale di Discourse configurato per le email in blocco.

Infine, all’interno del tuo file app.yml dovrai aggiungere DISCOURSE_ENABLE_EMAIL_SYNC_DEMON: true nella sezione env ed eseguire ./launcher rebuild. Questo attiverà il worker in background per avviarsi e iniziare a sincronizzare le email!

Informazioni specifiche per il provider

Gmail

Devi generare una password per l’applicazione, altrimenti devi attivare l’“Accesso a app meno sicure”, che Google sta comunque eliminando a breve. Utilizza questa password al posto della password del tuo account Gmail nelle impostazioni IMAP. Consulta Sign in with app passwords - Gmail Help per ulteriori dettagli.
Assicurati di utilizzare queste impostazioni per SMTP e IMAP:
- Porta IMAP: 987
- Porta SMTP: 587
- Server IMAP: imap.gmail.com
- Server SMTP: smtp.gmail.com
- Utilizza SSL sia per SMTP che per IMAP
Si consiglia vivamente (e presto sarà una funzionalità dell’interfaccia) di selezionare solo la casella di posta “[Gmail]/All Mail” per la sincronizzazione.
Non eliminiamo immediatamente le email su Gmail, ma le spostiamo solo nel cestino quando l’argomento viene eliminato in Discourse. La funzionalità di eliminazione “30 giorni” all’interno di Gmail prenderà il sopravvento da lì.
I tag applicati agli argomenti di Discourse creeranno Etichette su Gmail e le applicheranno ai thread di posta elettronica. Le etichette su Gmail sono anche caselle di posta IMAP!

Limitazioni

Questa è una funzionalità in fase alpha e, di conseguenza, non è al 100% completa e rifinita. Pertanto, al momento si applicano le seguenti limitazioni:

Attualmente solo Gmail è supportato come provider IMAP. Abbiamo alcune funzionalità IMAP generiche, ma non è garantito che funzionino. Outlook Online è il nostro prossimo grande obiettivo per il supporto.
Il ripristino delle email eliminate dal Cestino di Gmail e il riflesso dello stato in Discourse è attualmente instabile.
Cambiare la casella di posta sincronizzata dopo che le email sono già state sincronizzate non è consigliato e può causare molti problemi strani.
È possibile sincronizzare solo una casella di posta per gruppo.
La comunicazione da gruppo a gruppo è un territorio inesplorato e non funzionerà bene (ad esempio, inviare email a team@yoursite.com da support@yoursite.com se ciascuna di queste email è configurata per un gruppo diverso).

Potrebbero esserci anche altri piccoli problemi e imperfezioni, dato che questa è una funzionalità alpha.

Feedback e Roadmap

Apprezziamo molto il feedback di chiunque stia utilizzando questa funzionalità con Gmail. Sarò io a lavorare per risolvere eventuali bug o problemi. Il debug è un po’ complicato al momento, ma ci sto lavorando!

Le prossime cose su cui lavorerò:

Migliorare il debug per rendere più facile visualizzare i log IMAP e capire cosa va storto.
Migliorare l’interfaccia delle email del gruppo per limitare le caselle di posta selezionabili da Gmail e per scoraggiare/non permettere la modifica delle caselle di posta.
Validazione per impedire l’uso delle stesse credenziali IMAP per più gruppi.
Possibili miglioramenti su come vengono memorizzate le impostazioni IMAP del gruppo e un’esperienza utente migliore per la validazione delle credenziali.
Supporto per Outlook.

Attualmente, mentre risolviamo i problemi, questa funzionalità non è disponibile per i nostri clienti in hosting.

Ringraziamenti speciali

Sia @dan che @j.jaffeux sono i principali contributori di questa enorme funzionalità, su cui è stato lavorato per tanto tempo. Senza il loro straordinario lavoro non sarei stato in grado di portare la funzionalità a questo punto e di fare questo annuncio .

hellekin · 12 Agosto 2020, 7:09am

Questa è allo stesso tempo una notizia fantastica e una notizia terribile. Lasciate che vi spieghi. Innanzitutto, è una grande notizia vedere l’integrazione IMAP con i gruppi Discourse, poiché offre numerose soluzioni utili per l’identità dei gruppi (utilizzando l’indirizzo originale corretto), facilita l’uso dello stesso account IMAP da parte di più utenti (non ben supportato nativamente, ad esempio, nessun stato di lettura condiviso) e apre la strada alle caselle di posta ActivityPub… Ma è una notizia terribile perché la sua implementazione favorisce i giganti della posta elettronica che hanno trasformato un servizio federato in un sistema largamente centralizzato. Comprendo l’attrazione di lavorare con provider su larga scala, ma spero che lo standard IMAP sia preferito rispetto alle estensioni specifiche del provider, in modo che qualsiasi provider di posta elettronica sia supportato non appena questa funzione raggiungerà lo stato di beta.

Bravi per aver reso possibile tutto ciò.

sam · 12 Agosto 2020, 8:18am

C’è un motivo importante per cui questa funzionalità è considerata “alpha”

Il problema con IMAP, da quanto ho osservato da bordo campo, è la quantità di “interpretazione aperta” con cui dobbiamo fare i conti.

Vogliamo certamente far funzionare questa funzionalità con più provider; la nostra priorità interna è il grande ecosistema Google, perché la realtà è che usiamo Google su Discourse, quindi abbiamo voluto risolvere prima il nostro problema.

Le PR per migliorare il funzionamento con altri provider sono certamente benvenute; in assenza di queste, col passare del tempo e osservando un maggiore interesse verso l’uso con altri provider, costruiremo il supporto necessario.

martin · 12 Agosto 2020, 8:52am

Questa è una critica fondata; come ha detto @sam, ci siamo concentrati inizialmente su Gmail perché è quello che utilizziamo noi, quindi è il più rilevante per noi. Tuttavia, credo che il nostro provider “generico” di base, sebbene certamente non sia conforme al 100% alla RFC e non sia completo di tutte le funzionalità, segua il protocollo IMAP in modo piuttosto rigoroso… vedi https://github.com/discourse/discourse/blob/master/lib/imap/providers/generic.rb. Le uniche aggiunte che ritengo necessarie sono la gestione speciale di Archiviazione ed Eliminazione. Attualmente, l’eliminazione viene semplicemente contrassegnata con \Deleted e viene inviato il comando EXPUNGE, ma so che alcuni client di posta permettono di scegliere se procedere in questo modo o spostare prima i messaggi in una cartella cestino e poi eseguire EXPUNGE, ecc. Non sono sicuro di quale sia lo standard per l’archiviazione in IMAP. Abbiamo una classe specifica per il provider Gmail che sovrascrive alcuni di questi metodi generici.

Se hai suggerimenti su altri server o provider IMAP “generici” su cui posso testare, sarebbe di grande aiuto, dato che Gmail ha la sua gestione particolare e specifica (“special snowflake”) delle cose e le sue estensioni IMAP di Gmail.

Inoltre, come ha detto Sam, sono benvenute eventuali pull request per miglioramenti; altrimenti, ci adatteremo alla domanda, e prevedo che il prossimo grande caso d’uso per le organizzazioni che desiderano questo tipo di funzionalità sarà Outlook (Outlook ha le sue regole particolari e specifiche… ad esempio, l’archiviazione è una cartella o una casella di posta e non supporta le etichette).

itsbhanusharma · 12 Agosto 2020, 8:57am

Sembra molto interessante. La mia azienda ha recentemente migrato dal nostro server di posta interno a G-Suite e questa integrazione ci faciliterà molto la risposta alle richieste dei clienti e la gestione dei nostri tracker di avanzamento. Ho però una domanda per @martin. Non mi è chiaro se utilizzerà lo SMTP di Gmail per rispondere ai messaggi ricevuti nella casella di posta di gruppo o se userà lo SMTP configurato per inviare email a nome di Discourse. Vedo che il plugin menziona anche lo SMTP di Gmail, ma volevo comunque chiarimenti a riguardo.

martin · 12 Agosto 2020, 8:58am

Il server SMTP di Gmail viene utilizzato per inviare le risposte, poiché stai inviando le risposte a nome dell’account email utilizzato per la sincronizzazione IMAP! Aggiungerò una nota a tal proposito nell’OP per chiarire.

itsbhanusharma · 12 Agosto 2020, 9:02am

È davvero geniale. Posso pensare a così tanti casi d’uso per questo. Complimenti @martin @dan @j.jaffeux

martin · 17 Agosto 2020, 12:10am

Aggiornamento rapido. Ho unito queste due PR la settimana scorsa. Innanzitutto, la correzione affinché il tagging non debba essere abilitato per far funzionare l’archiviazione e l’eliminazione:

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.

In secondo luogo, ora scrivo tutti i log IMAP nel database per facilitarne l’ispezione. Un job verrà eseguito quotidianamente per eliminare i log con un’età superiore a 5 giorni:

StanD · 21 Agosto 2020, 10:47pm

È super carino! Grazie.

Devo dire che ho dovuto creare una password applicativa nel mio account Google per far sì che Discourse accettasse il mio nome utente e la mia password.

sunjam · 23 Agosto 2020, 3:25pm

Stai utilizzando l’autenticazione a due fattori sul lato Google? Se sì, questa è una pratica standard.

StanD · 23 Agosto 2020, 4:34pm

Sì. Credo che fosse necessario per creare la password dell’app (anche se non ne sono certo al 100%).

martin · 23 Agosto 2020, 11:40pm

Questo è già stato indicato nell’OP Altrimenti dovresti compiere sforzi incredibili per far accettare all’account Gmail le “app meno sicure”. Prima o poi dovremo supportare OAuth per Google, poiché sembra che sia questa la direzione verso cui si sta andando.

StanD · 24 Agosto 2020, 1:19am

Ops! Ho mai detto che le mie capacità di comprensione del testo sono pessime?

martin · 24 Agosto 2020, 1:25am

Va bene! È un punto importante, quindi l’ho spostato in cima all’elenco di Gmail e ho aggiunto alcuni indicatori di avviso. Grazie per aver cercato di avvisare gli altri per risparmiare loro problemi

thoka · 6 Febbraio 2021, 1:10am

Sto cercando di capire perché non riesco a sincronizzare le email con un server IMAP Dovecot (sfortunatamente senza esperienza in Ruby o Rails).

Leggendo i log di sincronizzazione IMAP, il daemon di importazione rimane bloccato in un ciclo:

UIDVALIDITY = 1612565899 non corrisponde al valore atteso 0, invalidando la cache IMAP e risincronizzando le email per la casella INBOX

Quindi mi chiedo se @group.imap_uid_validity non dovrebbe essere aggiornato in questo caso:

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

Dopo un aggiornamento manuale di questo valore, il daemon di importazione rimane bloccato in un altro ciclo.

Dovecot non supporta 'LABELS' in

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

generando un Net::IMAP::BadResponseError che, purtroppo, non viene registrato nei log.

Ora mi chiedo:

se il supporto di Dovecot per i flag personalizzati sia sufficiente per una sincronizzazione bidirezionale con Discourse
come rilevare Dovecot in lib/imap/providers/detector.rb
come emulare la funzionalità delle etichette in un provider Dovecot

…

martin · 7 Febbraio 2021, 11:39pm

La sincronizzazione IMAP per le caselle di posta di gruppo è ancora una funzionalità in fase iniziale che attualmente supporta solo Gmail. In teoria, potresti scrivere un provider dovecot, ma alcune settimane fa ho notato che ci sono alcune parti nel codice principale che utilizzano funzionalità specifiche di Gmail e che devono essere spostate nel codice specifico del provider. Mi dispiace, quindi, ma potresti voler aspettare che sia un po’ più pronto per il lancio ufficiale.

thoka · 8 Febbraio 2021, 2:54pm

IIUC 'LABELS' è una funzionalità non standard di Gmail.
Vorrei comprendere la differenza tra Google IMAP e IMAP standard.

Questo è il mio riassunto finora:

IMAP standard	Google IMAP
Le email archiviate vivono in sottocartelle	tutte le email vivono in una singola cartella le email archiviate mancano dell’etichetta “\INBOX”
I flag personalizzati sono memorizzati insieme ai flag di sistema	memorizza i flag personalizzati come etichette

Sarebbe sufficiente:

emulare le etichette in IMAP standard dividendo i flag in flag di sistema e flag personalizzati
gestire email_is_archived a livello del provider (ad esempio, aggiungere e verificare un flag “archived”)
per far funzionare la sincronizzazione IMAP standard?

Questo interesserebbe queste righe:

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

Questa riga mi sembra strana:

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?

Qualsiasi flag di sistema verrà sovrascritto dai tag di Discourse.
Questo gestisce correttamente tutti i flag IMAP (`\Answered, \Deleted, \Draft, \Flagged, \Recent e \Seen / $Forwarded, $MDNSent, $SubmitPending e $Submitted)?

StanD · 29 Marzo 2021, 2:58am

Sto tornando su questo argomento dopo un po’ di tempo.

Non sono riuscito a capire come far funzionare correttamente l’intestazione reply-to. Posso configurare un gruppo per sincronizzarlo con un account Gmail specifico, ma quando provo a rispondere via email, l’indirizzo reply-to viene impostato sull’email di notifica configurata in Discourse e non sull’indirizzo IMAP.

C’è qualcosa che mi sfugge?

mognet · 16 Ottobre 2021, 4:15pm

L’ho appena testato con il provider di posta GoDaddy, ma senza successo. Con Gmail funziona benissimo, ma purtroppo vogliamo usare il nostro dominio. Ci sono aggiornamenti per renderlo pronto all’uso?

pfaffman · 16 Ottobre 2021, 5:58pm

Puoi utilizzare il tuo dominio con Gmail (a pagamento), per quanto ne so.

Argomento		Risposte	Visualizzazioni
Is it possible to use Discourse for e-mail? Support	5	1428	Settembre 9, 2021
Discourse settings: IMAP Support	1	68	Agosto 14, 2024
Discourse as a private email support portal Feature rfc , spec	45	23284	Maggio 10, 2016
Replacing Mailing lists: Email-In Feature	67	17151	Ottobre 4, 2014
Migrate a mailing list to Discourse (mbox, Listserv, Google Groups, etc) Migrating to Discourse how-to	109	24226	Aprile 3, 2026

Vantaggi

Funzionalità

Per iniziare

Informazioni specifiche per il provider

Gmail

Limitazioni

Feedback e Roadmap

Ringraziamenti speciali

Argomenti correlati