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

This is at the same time fantastic news and terrible news. Let me explain. First is great news to see IMAP integration with Discourse groups, as it brings a number of useful solutions to group identity (using the correct original address), to facilitate multiple users using the same IMAP account (not well supported natively, e.g. no shared reading states), and it opens the path to ActivityPub inboxes… But it’s a terrible news because its implementation favors email giants who turned a federated service into a largely centralized system. I understand the attraction to work with large scale providers, but I hope IMAP standard will be preferred over provider-specific extensions so that any email provider will be supported once this feature reaches beta state.

Kudos for making this possible.

sam · 12 Agosto 2020, 8:18am

There is a big reason this feature is considered “alpha”

The trouble with IMAP from what I have observed from the sidelines is the amount of “open to interpretation” we are stuck dealing with.

We certainly want to make this work with more providers, our internal itch favors the big Google cause the reality is that we use Google at Discourse so we wanted to solve our problem first.

PRs to make this work better with more providers are certainly welcome, in absence of them as time passes and we observe more desire to use this with other providers we shall build support.

martin · 12 Agosto 2020, 8:52am

This is a fair criticism, like @sam said we focused on Gmail first because this is what we use so it is the most relevant for us. However I believe that our base “generic” provider, while certainly not nearly 100% compliant to the RFC and not feature complete, follows the IMAP protocol quite closely…see discourse/lib/imap/providers/generic.rb at main · discourse/discourse · GitHub. The only additions I think this will need are special handling of Archiving and Deleting. Deleting we currently just flag as \Deleted and send an EXPUNGE command, but I know certain email clients will let you choose to do this or send to a trash folder first then EXPUNGE etc. I am not sure what the Archiving standard is for IMAP. We have a specific Gmail provider class that overrides some of these generic methods.

If you have any suggestions on more “generic” IMAP servers/providers that I can test against that would be a great help, as Gmail has its own special snowflake handling of things and Gmail IMAP extensions.

Also, as Sam said, any PRs for improvement are welcome, otherwise we will cater to demand, which I am predicting will be Outlook next as another big use case for organizations wanting this kind of feature (Outlook has its own special snowflake rules…like Archive being a folder/mailbox and no label support).

itsbhanusharma · 12 Agosto 2020, 8:57am

Looks very exciting, My firm recently switched from our own mailserver to G-Suite and this integration will make it much easier for us to respond to client queries and manage our progress trackers. I have one query for @martin though. It isn’t clear to me whether it would use gmail smtp to reply to messages received in group inbox or would it use the mass smtp configured to send emails on behalf of Discourse? I see that the plugin mentions gmail’s smtp as well but I still wanted clarity on this.

martin · 12 Agosto 2020, 8:58am

Gmail’s SMTP server is used to send the replies, as you are sending the replies on behalf of the email account used for IMAP syncing! I will add a note to this effect in the OP to clarify.

itsbhanusharma · 12 Agosto 2020, 9:02am

That’s actually brilliant. I can think of so many use cases for this. Kudos @martin @dan @j.jaffeux

martin · 17 Agosto 2020, 12:10am

Quick update here. I merged these two PRs last week. First, the fix so that tagging does not need to be enabled for archiving and deleting to work:

https://github.com/discourse/discourse/pull/10426

Second, I am now writing all IMAP logs to the database for easier inspection. A job will be run daily to delete logs > 5 days old:

https://github.com/discourse/discourse/pull/10435

StanD · 21 Agosto 2020, 10:47pm

This is super sweet! Thanks.

I should say, I had to create an application password in my google email account for discourse to get it to accept my username/password

sunjam · 23 Agosto 2020, 3:25pm

Are you running 2-factor authentication on the Google end? If so, this is standard practice.

StanD · 23 Agosto 2020, 4:34pm

Yes. I believe it was required in order for me to create the app password (though I don’t remember for sure)

martin · 23 Agosto 2020, 11:40pm

This is noted in the OP Otherwise you have to jump through crazy hoops to make your Gmail account accept “Less secure apps”. At some point we will need to support OAuth for Google as that looks like the way things are headed.

StanD · 24 Agosto 2020, 1:19am

Oops! Did I mention that my reading comprehension skills suck?

martin · 24 Agosto 2020, 1:25am

It’s okay! It is an important point so I moved it to the top of the Gmail list and added some warning indicators. Thank you for trying to let others know about this to save them trouble

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	17150	Ottobre 4, 2014
Migrate a mailing list to Discourse (mbox, Listserv, Google Groups, etc) Migrating to Discourse how-to	109	24222	Aprile 3, 2026

Supporto IMAP per caselle di posta di gruppo

Vantaggi

Funzionalità

Per iniziare

Informazioni specifiche per il provider

Gmail

Limitazioni

Feedback e Roadmap

Ringraziamenti speciali

Argomenti correlati