Suporte IMAP para caixas de entrada de grupo

martin · Agosto 12, 2020, 5:03am

Estamos removendo o suporte ao IMAP no Discourse. Consulte esta postagem para detalhes: IMAP support for group inboxes - #39 by martin .

Temos o prazer de apresentar uma versão alfa do suporte ao IMAP para caixas de entrada de grupos. Este recurso adiciona a capacidade de inserir credenciais e configurações de IMAP por grupo para sincronizar caixas de entrada de grupos com uma caixa de entrada de e-mail.

Este é um recurso em estágio alfa e, como tal, não está 100% completo e polido. É muito provável que apresente falhas; atualmente não estamos mantendo-o ou utilizando-o em produção. Use por sua conta e risco!

Benefícios

Seu grupo pode começar imediatamente a usar as caixas de entrada do Discourse, pois todos os seus e-mails existentes serão sincronizados!
Seu grupo pode ter suas mensagens sincronizadas entre o Discourse e seu provedor de e-mail, eliminando um único ponto de falha. As pessoas podem responder a partir da conta de e-mail ou dentro do Discourse, e tudo será sincronizado
Você não precisará mais configurar regras de encaminhamento complexas do seu provedor de e-mail para a caixa de entrada de entrada do Discourse.
Rótulos de e-mail serão sincronizados com tags do Discourse, mantendo tudo organizado
Você estará respondendo a pessoas que enviam e-mails para seu grupo do endereço de e-mail que configurou, mesmo que responda a partir do Discourse. Sem mais confusão!

Recursos

Todo o tráfego de entrada e saída será sincronizado entre o servidor IMAP e o Discourse, com tópicos e respostas apropriados criados com base nos e-mails analisados. Respostas podem ser criadas a partir do Discourse ou do servidor IMAP, e tudo será sincronizado!
E-mails podem ser respondidos a partir da caixa de entrada de grupo do Discourse OU da conta de e-mail.
Tags aplicadas ao tópico do Discourse serão criadas como rótulos e aplicadas ao e-mail no servidor IMAP (isso é específico do provedor).
E-mails arquivados no servidor IMAP serão arquivados na caixa de entrada do grupo.
Tópicos de mensagens privadas de grupo arquivados no Discourse serão arquivados no servidor IMAP.
E-mails excluídos no servidor IMAP excluirão o tópico na caixa de entrada do grupo.
Tópicos de mensagens privadas de grupo excluídos no Discourse serão excluídos no servidor IMAP.
E-mails enviados por grupos com este recurso habilitado terão seu endereço de resposta definido para o mesmo nome de usuário de e-mail configurado nas configurações de IMAP.

Começando

Primeiro, há algumas configurações do site que você deve configurar antes de poder configurar essa funcionalidade em um grupo.

enable imap e enable smtp precisam estar habilitados. O IMAP é usado para sincronizar com seu servidor de e-mail, e o SMTP é usado para enviar e-mails a partir do seu servidor de e-mail.
tagging enabled e allow staff to tag pms - Ambos devem estar habilitados, pois a sincronização de rótulos aplica tags a PMs.
enable imap write - Deve ser habilitado se você quiser que alterações feitas no Discourse sejam refletidas no seu servidor de e-mail (por exemplo, tags, arquivamento de tópicos e exclusão de tópicos).
enable imap idle - Permite que recebamos atualizações em tempo real do seu servidor de e-mail SE o seu servidor de e-mail suportar IDLE. Isso acelera muito a reflexão das alterações do seu provedor de e-mail no Discourse. Você deve ativá-lo (o Gmail, por exemplo, suporta). Se quiser todos os detalhes técnicos, você pode ler sobre eles no RFC para IDLE.
imap polling period mins - Se IDLE não for suportado, este é o número de minutos que aguardamos antes de verificar o servidor IMAP por alterações. Também é o tempo que aguardamos entre o envio de alterações para o servidor IMAP a partir do Discourse se enable imap write estiver habilitado. O mínimo é 1 minuto.

Essas configurações podem permanecer nos valores padrão e serem ajustadas se você estiver encontrando problemas com a sincronização:

imap polling old emails - O número máximo de e-mails antigos (processados) a serem atualizados a cada vez que uma caixa de IMAP é consultada (0 para todos).
imap polling new emails - O número máximo de e-mails novos (não processados) a serem atualizados a cada vez que uma caixa de IMAP é consultada.
imap batch import email - O número mínimo de e-mails novos que ativam o modo de importação (desativa alertas de postagem).

Se você quiser que rótulos/tags sejam sincronizados com o servidor IMAP, precisa habilitar as configurações do site tagging enabled e allow staff to tag pms.

Em seguida, você precisa ir para o grupo que deseja sincronizar com seu servidor IMAP e preencher as configurações.

Essas configurações serão específicas do provedor; consulte abaixo para mais detalhes. Após inserir as configurações e credenciais, clique em “Salvar alterações” e validaremos as credenciais contra os servidores do provedor IMAP. Se bem-sucedido, a lista de caixas de entrada será preenchida, e você precisará escolher qual deseja sincronizar (orientações sobre isso também são específicas do provedor):

Se a validação das credenciais não for bem-sucedida, uma mensagem de erro será exibida na página. Para deixar claro, o servidor SMTP inserido será usado para enviar e-mails em nome da conta inserida sob nome de usuário e senha, não o SMTP principal do Discourse configurado para e-mails em massa.

Finalmente, dentro do seu arquivo app.yml, você precisará adicionar DISCOURSE_ENABLE_EMAIL_SYNC_DEMON: true dentro da seção env e executar ./launcher rebuild. Isso permitirá que o worker em segundo plano inicie e comece a sincronizar e-mails!

Informações específicas do provedor

Gmail

Você deve gerar uma senha de aplicativo; caso contrário, precisará ativar o “Acesso de aplicativos menos seguros”, que o Google está eliminando em algum momento de qualquer forma. Use essa senha em vez da senha da sua conta do Gmail nas configurações de IMAP. Consulte Sign in with app passwords - Gmail Help para mais detalhes.
Certifique-se de usar estas configurações para SMTP e IMAP:
- Porta IMAP: 987
- Porta SMTP: 587
- Servidor IMAP: imap.gmail.com
- Servidor SMTP: smtp.gmail.com
- Use SSL tanto para SMTP quanto para IMAP
É fortemente recomendado (em breve será um recurso de interface) que você selecione apenas a caixa de entrada “[Gmail]/All Mail” para sincronizar.
Não excluímos imediatamente e-mails no Gmail; apenas os movemos para a caixa de lixo quando o tópico é excluído no Discourse. A funcionalidade de exclusão de “30 dias” dentro do Gmail assumirá a partir daí.
Tags aplicadas a tópicos do Discourse criarão Rótulos no Gmail e os aplicarão a threads de e-mail. Rótulos no Gmail também são caixas de entrada IMAP!

Limitações

Este é um recurso em estágio alfa e, como tal, não está 100% completo e polido. Portanto, as seguintes limitações atualmente se aplicam:

Apenas o Gmail é atualmente suportado como provedor IMAP. Temos alguma funcionalidade genérica de IMAP, mas não é garantido que funcione. O Outlook Online é nosso próximo grande alvo de suporte.
Ressuscitar e-mails excluídos da Lixeira do Gmail e refletir o estado no Discourse atualmente é instável.
Alterar a caixa de entrada de sincronização após os e-mails já terem sido sincronizados não é recomendado e pode levar a muitos problemas estranhos.
Apenas uma caixa de entrada pode ser sincronizada por grupo.
Comunicação de grupo para grupo é um território inexplorado e não funcionará bem (por exemplo, enviar e-mail para team@yoursite.com a partir de support@yoursite.com se cada um desses e-mails estiver configurado para um grupo diferente).

Pode haver outras armadilhas sutis e imperfeições, já que este é um recurso alfa.

Feedback e Roadmap

Adoraríamos receber feedback de qualquer pessoa usando este recurso com o Gmail. Serei a pessoa responsável por corrigir bugs e problemas. A depuração é um pouco complicada no momento, mas estou trabalhando nisso!

As próximas coisas com as quais trabalharei:

Melhorar a depuração para facilitar a visualização dos logs IMAP e identificar o que deu errado.
Melhorar a interface de e-mail do grupo para limitar as caixas de entrada que podem ser selecionadas no Gmail e também desencorajar/impedir a alteração de caixas de entrada.
Validação para evitar o uso dos mesmos detalhes IMAP para vários grupos.
Possíveis melhorias na forma como as configurações de IMAP do grupo são armazenadas e uma melhor UX para validação de credenciais.
Suporte ao Outlook.

Atualmente, enquanto resolvemos os problemas, este recurso não está disponível para nossos clientes hospedados.

Agradecimentos Especiais

Tanto @dan quanto @j.jaffeux são os principais contribuidores deste enorme recurso, que foi trabalhado por um longo tempo. Sem o trabalho incrível deles, eu não teria sido capaz de levar o recurso a este ponto e fazer este anúncio .

hellekin · Agosto 12, 2020, 7:09am

Isso é, ao mesmo tempo, uma notícia fantástica e uma notícia terrível. Deixe-me explicar. Em primeiro lugar, é ótimo ver a integração IMAP com grupos do Discourse, pois traz diversas soluções úteis para a identidade dos grupos (usando o endereço original correto), facilita o uso de uma mesma conta IMAP por múltiplos usuários (não bem suportada nativamente, por exemplo, sem estados de leitura compartilhados) e abre caminho para as caixas de entrada do ActivityPub… Mas é uma notícia terrível porque sua implementação favorece os gigantes do e-mail, que transformaram um serviço federado em um sistema amplamente centralizado. Entendo a atração de trabalhar com provedores de grande escala, mas espero que o padrão IMAP seja preferido em vez de extensões específicas do provedor, para que qualquer provedor de e-mail seja suportado assim que esse recurso atingir o estado beta.

Parabéns por tornar isso possível.

sam · Agosto 12, 2020, 8:18am

Há um grande motivo pelo qual esse recurso é considerado “alfa”

O problema com o IMAP, pelo que observei de longe, é a quantidade de “aberto à interpretação” com a qual temos que lidar.

Certamente queremos fazer isso funcionar com mais provedores; nossa necessidade interna favorece o grande Google, porque a realidade é que usamos o Google no Discourse, então quisemos resolver nosso problema primeiro.

PRs para fazer isso funcionar melhor com mais provedores são certamente bem-vindos. Na ausência deles, conforme o tempo passa e observamos mais desejo de usar isso com outros provedores, construiremos o suporte.

martin · Agosto 12, 2020, 8:52am

Essa é uma crítica válida, como @sam mencionou, focamos primeiro no Gmail porque é o que utilizamos, tornando-o o mais relevante para nós. No entanto, acredito que nosso provedor “genérico” base, embora certamente não seja 100% compatível com o RFC e não seja completo em termos de recursos, segue o protocolo IMAP de forma bastante precisa… veja https://github.com/discourse/discourse/blob/master/lib/imap/providers/generic.rb. As únicas adições que creio serem necessárias são o tratamento especial de Arquivamento e Exclusão. Atualmente, a exclusão apenas é marcada como \Deleted e um comando EXPUNGE é enviado, mas sei que alguns clientes de e-mail permitem que você escolha fazer isso ou enviar primeiro para uma pasta de lixeira e, em seguida, executar o EXPUNGE, etc. Não tenho certeza sobre o padrão de Arquivamento para IMAP. Temos uma classe específica para provedores do Gmail que substitui alguns desses métodos genéricos.

Se você tiver sugestões sobre outros servidores/provedores IMAP mais “genéricos” contra os quais eu possa testar, isso seria de grande ajuda, pois o Gmail possui seu próprio tratamento especial e exclusivo para certas coisas, além das extensões IMAP do Gmail.

Além disso, como Sam disse, qualquer PR para melhorias é bem-vindo; caso contrário, atenderemos à demanda, e prevejo que o próximo grande caso de uso para organizações que desejam esse tipo de recurso será o Outlook (o Outlook também tem suas próprias regras exclusivas… como o Arquivamento ser uma pasta/caixa de correio e não oferecer suporte a rótulos).

itsbhanusharma · Agosto 12, 2020, 8:57am

Parece muito empolgante. Nossa empresa mudou recentemente de nosso próprio servidor de e-mail para o G-Suite, e essa integração facilitará muito nossa resposta às consultas dos clientes e o gerenciamento de nossos rastreadores de progresso. Tenho uma dúvida para o @martin, no entanto. Não está claro para mim se ele usaria o SMTP do Gmail para responder às mensagens recebidas na caixa de entrada do grupo ou se usaria o SMTP em massa configurado para enviar e-mails em nome do Discourse. Vejo que o plugin menciona o SMTP do Gmail também, mas ainda assim gostaria de esclarecimentos sobre isso.

martin · Agosto 12, 2020, 8:58am

O servidor SMTP do Gmail é usado para enviar as respostas, pois você está enviando as respostas em nome da conta de e-mail usada para a sincronização IMAP! Vou adicionar uma nota a esse efeito na OP para esclarecer.

itsbhanusharma · Agosto 12, 2020, 9:02am

Isso é realmente brilhante. Consigo pensar em tantos casos de uso para isso. Parabéns @martin @dan @j.jaffeux

martin · Agosto 17, 2020, 12:10am

Uma atualização rápida aqui. Eu mesclei esses dois PRs na semana passada. Primeiro, a correção para que a marcação não precise ser habilitada para que o arquivamento e a exclusão funcionem:

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.

Segundo, agora estou gravando todos os logs do IMAP no banco de dados para facilitar a inspeção. Um job será executado diariamente para excluir logs com mais de 5 dias:

StanD · Agosto 21, 2020, 10:47pm

Isso é super legal! Obrigado.

Devo dizer que precisei criar uma senha de aplicativo na minha conta do Google para que o Discourse aceitasse meu nome de usuário e senha.

sunjam · Agosto 23, 2020, 3:25pm

Você está usando autenticação de dois fatores no lado do Google? Se sim, isso é prática padrão.

StanD · Agosto 23, 2020, 4:34pm

Sim. Acredito que fosse necessário para que eu pudesse criar a senha de aplicativo (embora não me lembre com certeza).

martin · Agosto 23, 2020, 11:40pm

Isso já foi mencionado na postagem original Caso contrário, você terá que passar por etapas absurdas para fazer sua conta do Gmail aceitar “aplicativos menos seguros”. Em algum momento, precisaremos dar suporte ao OAuth para o Google, pois parece ser o rumo que as coisas estão tomando.

StanD · Agosto 24, 2020, 1:19am

Ops! Será que eu disse que minhas habilidades de leitura são péssimas?

martin · Agosto 24, 2020, 1:25am

Tudo bem! É um ponto importante, então o movi para o topo da lista do Gmail e adicionei alguns indicadores de aviso. Obrigado por tentar avisar os outros sobre isso para poupar trabalho deles

thoka · Fevereiro 6, 2021, 1:10am

Estou tentando entender por que estou falhando ao sincronizar e-mails com um servidor IMAP do Dovecot (infelizmente sem experiência em Ruby ou Rails).

Ao ler os imap_sync_logs, o daemon de importação fica preso em um loop:

UIDVALIDITY = 1612565899 não corresponde ao esperado 0, invalidando o cache IMAP e resincronizando e-mails para a caixa de entrada INBOX

Então, estou me perguntando se @group.imap_uid_validity não deveria ser atualizado neste 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

Após uma atualização manual desse valor, o daemon de importação fica preso em outro loop.

O Dovecot não suporta 'LABELS' em

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

resultando em um Net::IMAP::BadResponseError, que, infelizmente, não aparece nos logs.

Agora estou me perguntando:

se o suporte do Dovecot a flags personalizadas é suficiente para uma sincronização bidirecional com o Discourse
como detectar o Dovecot em lib/imap/providers/detector.rb
como emular o recurso de rótulos em um provedor do Dovecot

…

martin · Fevereiro 7, 2021, 11:39pm

A sincronização IMAP para caixas de entrada de grupo ainda é um recurso em estágio inicial que atualmente suporta apenas o Gmail. Teoricamente, você poderia criar um provedor do Dovecot, mas notei há algumas semanas que existem algumas partes no código principal que utilizam recursos exclusivos do Gmail e que precisam ser movidas para código específico do provedor. Então, desculpe por isso, mas talvez você queira esperar até que isso esteja um pouco mais próximo da versão final.

thoka · Fevereiro 8, 2021, 2:54pm

IIUC, 'LABELS' é um recurso não padrão do Gmail.
Gostaria de entender a diferença entre o IMAP do Google e o IMAP padrão.

Esta é minha síntese até agora:

IMAP padrão	IMAP do Google
E-mails arquivados vivem em subpastas	Todos os e-mails vivem em uma única pasta mensagens arquivadas estão sem a etiqueta “\INBOX”
Marcas personalizadas são armazenadas junto com marcas do sistema	Armazena marcas personalizadas como etiquetas

Seria suficiente

emular etiquetas no IMAP padrão dividindo as marcas em marcas do sistema e marcas personalizadas
lidar com email_is_archived no nível do provedor (por exemplo, adicionar e testar uma marca “arquivado”)
para fazer a sincronização do IMAP padrão funcionar?

Isso afetaria estas linhas:

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

Esta linha parece estranha para mim:

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?

Todas as marcas do sistema serão sobrescritas pelas tags do Discourse.
Isso lida bem com todas as marcas IMAP (\Answered, \Deleted, \Draft, \Flagged, \Recent e \Seen / $Forwarded, $MDNSent, $SubmitPending e $Submitted)?

StanD · Março 29, 2021, 2:58am

Estou revisitando isso após um tempo longe.

Não consegui descobrir como fazer o cabeçalho reply-to funcionar corretamente. Posso configurar um grupo para sincronizar com uma conta específica do Gmail, mas quando tento responder por e-mail, o endereço reply-to é definido como o e-mail de notificação configurado no Discourse e não o endereço IMAP.

Estou esquecendo algo?

mognet · Outubro 16, 2021, 4:15pm

Acabei de testar isso com o provedor de e-mail GoDaddy, mas sem sucesso. Com o Gmail funciona muito bem, mas infelizmente queremos usar nosso próprio domínio. Há alguma atualização para que isso esteja pronto para produção?

pfaffman · Outubro 16, 2021, 5:58pm

Você pode usar seu próprio domínio com o Gmail (mediante pagamento), a propósito.

Tópico		Respostas	Visualizações
Is it possible to use Discourse for e-mail? Support	5	1428	9 de Setembro de 2021
Discourse settings: IMAP Support	1	68	14 de Agosto de 2024
Discourse as a private email support portal Feature rfc , spec	45	23284	10 de Maio de 2016
Replacing Mailing lists: Email-In Feature	67	17151	4 de Outubro de 2014
Migrate a mailing list to Discourse (mbox, Listserv, Google Groups, etc) Migrating to Discourse how-to	109	24225	3 de Abril de 2026

Benefícios

Recursos

Começando

Informações específicas do provedor

Gmail

Limitações

Feedback e Roadmap

Agradecimentos Especiais

Tópicos relacionados