Soporte IMAP para bandejas de entrada grupales

martin · 12 Agosto, 2020 05:03

Estamos eliminando el soporte para IMAP en Discourse. Consulte esta publicación para obtener detalles: IMAP support for group inboxes - #39 by martin .

Nos complace presentar una versión alfa del soporte IMAP para bandejas de entrada de grupos. Esta función agrega la capacidad de ingresar credenciales y configuraciones IMAP por grupo para sincronizar las bandejas de entrada de grupos con una bandeja de entrada de correo electrónico.

Esta es una función en etapa alfa y, como tal, no está 100% completa y pulida. Es muy probable que tenga errores; actualmente no la estamos manteniendo ni usando en producción. ¡Úsela bajo su propio riesgo!

Beneficios

Su grupo puede empezar de inmediato a usar las bandejas de entrada de Discourse, ¡porque todo su correo existente se sincronizará!
Su grupo puede tener sus mensajes sincronizados entre Discourse y su proveedor de correo electrónico para que no haya un único punto de falla. Las personas pueden responder desde la cuenta de correo o desde dentro de Discourse y todo se sincronizará
Ya no necesitará configurar reglas de reenvío complejas desde su proveedor de correo electrónico hacia su bandeja de entrada entrante de Discourse.
Las etiquetas de correo electrónico se sincronizarán con las etiquetas de Discourse para que todo esté bien organizado
Responderá a las personas que envían correos a su grupo desde la dirección de correo electrónico que configuró, incluso si responde desde Discourse. ¡Sin más confusiones!

Características

Todo el correo entrante y saliente se sincronizará entre el servidor IMAP y Discourse, creando los temas y respuestas de publicaciones apropiados basados en los correos analizados. Las respuestas se pueden crear desde Discourse o desde el servidor IMAP y todo se sincronizará.
Los correos se pueden responder desde la bandeja de entrada del grupo de Discourse O desde la cuenta de correo.
Las etiquetas aplicadas al tema de Discourse se crearán como etiquetas y se aplicarán al correo en el servidor IMAP (esto es específico del proveedor).
Los correos archivados en el servidor IMAP se archivarán en la bandeja de entrada del grupo.
Los temas de mensajes privados del grupo que se archivan en Discourse se archivarán en el servidor IMAP.
Los correos eliminados en el servidor IMAP eliminarán el tema en la bandeja de entrada del grupo.
Los temas de mensajes privados del grupo que se eliminan en Discourse se eliminarán en el servidor IMAP.
Los correos enviados por grupos con esta función habilitada tendrán su dirección de respuesta configurada con el mismo nombre de usuario de correo establecido en la configuración IMAP.

Para empezar

En primer lugar, hay algunas configuraciones del sitio que debe configurar antes de poder establecer esta funcionalidad en un grupo.

enable imap y enable smtp deben estar habilitados. IMAP se usa para sincronizar con su servidor de correo y SMTP se usa para enviar correos desde su servidor de correo.
tagging enabled y allow staff to tag pms - Ambos deben estar habilitados, ya que la sincronización de etiquetas aplica etiquetas a los MP.
enable imap write - Debe estar habilitado si desea que los cambios realizados en Discourse se reflejen en su servidor de correo (por ejemplo, etiquetas, archivado de temas y eliminación de temas).
enable imap idle - Nos permite recibir actualizaciones en tiempo real de su servidor de correo SI su servidor de correo admite IDLE. Esto acelera enormemente la reflexión de los cambios en su proveedor de correo electrónico hacia Discourse. Debería activarlo (Gmail lo admite, por ejemplo). Si desea todos los detalles, puede leer sobre ellos en el RFC para IDLE.
imap polling period mins - Si IDLE no es compatible, este es el número de minutos que esperamos antes de verificar el servidor IMAP en busca de cambios. También es el tiempo que esperamos entre el envío de cambios al servidor IMAP desde Discourse si enable imap write está habilitado. El mínimo es 1 minuto.

Estas configuraciones pueden dejarse en sus valores predeterminados y ajustarse si encuentra problemas con la sincronización:

imap polling old emails - El número máximo de correos antiguos (procesados) que se actualizarán cada vez que se consulte una bandeja IMAP (0 para todos).
imap polling new emails - El número máximo de correos nuevos (no procesados) que se actualizarán cada vez que se consulte una bandeja IMAP.
imap batch import email - El número mínimo de correos nuevos que activan el modo de importación (desactiva las alertas de publicaciones).

Si desea que las etiquetas se sincronicen con el servidor IMAP, debe habilitar las configuraciones del sitio tagging enabled y allow staff to tag pms.

A continuación, debe ir al grupo que desea sincronizar con su servidor IMAP y completar la configuración.

Estas configuraciones serán específicas del proveedor; consulte a continuación para obtener más detalles. Una vez que haya ingresado la configuración y las credenciales, haga clic en “Guardar cambios” y validaremos las credenciales contra los servidores del proveedor IMAP. Si es exitoso, se rellenará la lista de bandejas de entrada y deberá elegir cuál desea sincronizar (la orientación sobre esto también es específica del proveedor):

Si la validación de credenciales no fue exitosa, se mostrará un mensaje de error en la página. Para ser claros, el servidor SMTP ingresado se usará para enviar correos en nombre de la cuenta ingresada bajo nombre de usuario y contraseña, no el SMTP principal de Discourse configurado para correos masivos.

Finalmente, dentro de su archivo app.yml, necesitará agregar DISCOURSE_ENABLE_EMAIL_SYNC_DEMON: true dentro de la sección env y ejecutar ./launcher rebuild. ¡Esto habilitará el worker de fondo para iniciar y comenzar a sincronizar correos!

Información específica del proveedor

Gmail

Debe generar una contraseña de aplicación; de lo contrario, necesita activar “Acceso de aplicaciones menos seguras”, lo cual Google está eliminando en algún momento de todos modos. Use esta contraseña en lugar de la contraseña de su cuenta de Gmail en la configuración IMAP. Consulte Sign in with app passwords - Gmail Help para obtener más detalles.
Asegúrese de usar estas configuraciones para SMTP e IMAP:
- Puerto IMAP: 987
- Puerto SMTP: 587
- Servidor IMAP: imap.gmail.com
- Servidor SMTP: smtp.gmail.com
- Use SSL tanto para SMTP como para IMAP
Se recomienda encarecidamente (pronto será una función de interfaz de usuario) que solo seleccione la bandeja de entrada “[Gmail]/Todos los correos” para sincronizar.
No eliminamos inmediatamente los correos en Gmail, solo los movemos a la bandeja de entrada de basura cuando se elimina el tema en Discourse. La función de eliminación de “30 días” dentro de Gmail asumirá el control a partir de ahí.
Las etiquetas aplicadas a los temas de Discourse crearán Etiquetas en Gmail y las aplicarán a los hilos de correo. ¡Las etiquetas en Gmail también son bandejas de entrada IMAP!

Limitaciones

Esta es una función en etapa alfa y, como tal, no está 100% completa y pulida. Por lo tanto, actualmente se aplican las siguientes limitaciones:

Solo Gmail es compatible actualmente como proveedor IMAP. Tenemos alguna funcionalidad genérica de IMAP, pero no se garantiza que funcione. Outlook en línea es nuestro próximo gran objetivo para el soporte.
Resucitar correos eliminados de la Papelera de Gmail y reflejar el estado en Discourse actualmente es inestable.
No se recomienda cambiar la bandeja de entrada de sincronización después de que los correos ya se hayan sincronizado y puede provocar muchos problemas extraños.
Solo se puede sincronizar una bandeja de entrada por grupo.
La comunicación de grupo a grupo es un territorio inexplorado y no funcionará bien (por ejemplo, enviar un correo a team@yoursite.com desde support@yoursite.com si cada uno de esos correos está configurado para un grupo diferente).

También puede haber otros detalles sutiles y asperezas, ya que esta es una función alfa.

Comentarios y hoja de ruta

Nos encantaría recibir comentarios de cualquiera que esté usando esta función con Gmail. Seré yo quien trabaje en corregir errores y problemas. ¡La depuración es un poco complicada ahora mismo, pero estoy trabajando en ello!

Las próximas cosas en las que trabajaré:

Mejorar la depuración para facilitar la visualización de registros IMAP y determinar qué salió mal.
Mejorar la interfaz de correo del grupo para limitar las bandejas de entrada que se pueden seleccionar de Gmail y también desalentar/prohibir el cambio de bandejas de entrada.
Validación para evitar el uso de los mismos detalles IMAP para múltiples grupos.
Posibles mejoras en cómo se almacenan la configuración IMAP del grupo y una mejor experiencia de usuario para validar credenciales.
Soporte para Outlook.

Actualmente, mientras resolvemos los problemas, esta función no está disponible para nuestros clientes alojados.

Agradecimientos especiales

Tanto @dan como @j.jaffeux son los principales contribuyentes de esta enorme función que ha estado en desarrollo durante mucho tiempo. Sin su increíble trabajo, no habría podido llevar la función a este punto y hacer este anuncio .

hellekin · 12 Agosto, 2020 07:09

Esta es, al mismo tiempo, una noticia fantástica y una noticia terrible. Déjame explicarlo. Primero, es una gran noticia ver la integración de IMAP con los grupos de Discourse, ya que aporta varias soluciones útiles para la identidad de grupo (utilizando la dirección original correcta), facilita que múltiples usuarios usen la misma cuenta IMAP (algo que no está bien soportado de forma nativa, por ejemplo, no hay estados de lectura compartidos) y abre el camino a los inboxes de ActivityPub… Pero es una noticia terrible porque su implementación favorece a los gigantes del correo electrónico que han convertido un servicio federado en un sistema ampliamente centralizado. Entiendo la atracción de trabajar con proveedores a gran escala, pero espero que se prefiera el estándar IMAP sobre las extensiones específicas del proveedor, para que cualquier proveedor de correo electrónico sea compatible una vez que esta función llegue al estado beta.

Felicidades por hacer esto posible.

sam · 12 Agosto, 2020 08:18

Hay una gran razón por la que esta función se considera “alpha”

El problema con IMAP, según lo que he observado desde la periferia, es la cantidad de “interpretación abierta” con la que nos vemos obligados a lidiar.

Sin duda queremos que esto funcione con más proveedores; nuestra necesidad interna favorece a Google porque, en realidad, usamos Google en Discourse, así que queríamos resolver nuestro problema primero.

Las PR para que esto funcione mejor con más proveedores son bienvenidas. En su ausencia, con el paso del tiempo y a medida que observemos más interés en usarlo con otros proveedores, construiremos el soporte.

martin · 12 Agosto, 2020 08:52

Esta es una crítica justa; como dijo @sam, nos centramos primero en Gmail porque es lo que usamos, por lo que es lo más relevante para nosotros. Sin embargo, creo que nuestro proveedor “genérico” base, aunque ciertamente no cumple al 100 % con la RFC y no es completo en cuanto a funciones, sigue el protocolo IMAP bastante de cerca… consulte https://github.com/discourse/discourse/blob/master/lib/imap/providers/generic.rb. Las únicas adiciones que creo que necesitará son el manejo especial de la archivación y la eliminación. Actualmente, la eliminación simplemente se marca como \Deleted y se envía el comando EXPUNGE, pero sé que ciertos clientes de correo permiten elegir entre hacer esto o enviar primero a una carpeta de papelera y luego ejecutar EXPUNGE, etc. No estoy seguro de cuál es el estándar de archivación para IMAP. Tenemos una clase específica para el proveedor de Gmail que anula algunos de estos métodos genéricos.

Si tienes alguna sugerencia sobre más servidores/proveedores IMAP “genéricos” contra los que pueda probar, sería de gran ayuda, ya que Gmail tiene su propio tratamiento especial y único de ciertas cosas, además de las extensiones IMAP de Gmail.

Además, como dijo Sam, cualquier PR de mejora es bienvenida; de lo contrario, nos adaptaremos a la demanda, y predigo que el próximo será Outlook, otro caso de uso importante para organizaciones que desean este tipo de función (Outlook tiene sus propias reglas especiales y únicas… como que la archivación sea una carpeta o buzón y que no admita etiquetas).

itsbhanusharma · 12 Agosto, 2020 08:57

¡Parece muy emocionante! Mi firma cambió recientemente de nuestro propio servidor de correo a G-Suite y esta integración nos facilitará mucho responder a las consultas de los clientes y gestionar nuestros controladores de progreso. Tengo una pregunta para @martin. No me queda claro si utilizaría el SMTP de Gmail para responder a los mensajes recibidos en la bandeja de entrada del grupo o si usaría el SMTP masivo configurado para enviar correos en nombre de Discourse. Veo que el plugin menciona el SMTP de Gmail, pero aún así quería aclarar este punto.

martin · 12 Agosto, 2020 08:58

Se utiliza el servidor SMTP de Gmail para enviar las respuestas, ya que estás enviando las respuestas en nombre de la cuenta de correo electrónico utilizada para la sincronización IMAP. Agregaré una nota a este efecto en la publicación original para aclararlo.

itsbhanusharma · 12 Agosto, 2020 09:02

Eso es realmente brillante. Se me ocurren tantos casos de uso para esto. ¡Felicidades @martin @dan @j.jaffeux

martin · 17 Agosto, 2020 00:10

Una rápida actualización. Fusioné estos dos PRs la semana pasada. Primero, la corrección para que el etiquetado no sea necesario para que funcionen la archivación y la eliminación:

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, ahora estoy escribiendo todos los registros de IMAP en la base de datos para facilitar su inspección. Se ejecutará una tarea diaria para eliminar los registros con más de 5 días de antigüedad:

StanD · 21 Agosto, 2020 22:47

¡Esto es genial! Gracias.

Debo decir que tuve que crear una contraseña de aplicación en mi cuenta de correo de Google para que Discourse aceptara mi nombre de usuario y contraseña.

sunjam · 23 Agosto, 2020 15:25

¿Tienes la autenticación en dos pasos activada en Google? Si es así, esto es una práctica estándar.

StanD · 23 Agosto, 2020 16:34

Sí. Creo que fue necesario para que yo pudiera crear la contraseña de la aplicación (aunque no lo recuerdo con seguridad).

martin · 23 Agosto, 2020 23:40

Esto se menciona en la publicación original De lo contrario, tendrás que pasar por toda una serie de trámites absurdos para que tu cuenta de Gmail acepte «Aplicaciones menos seguras». En algún momento tendremos que implementar OAuth para Google, ya que parece ser el camino que se está tomando.

StanD · 24 Agosto, 2020 01:19

¡Ups! ¿Mencioné que mis habilidades de comprensión lectora son terribles?

martin · 24 Agosto, 2020 01:25

¡No hay problema! Es un punto importante, así que lo he movido a la parte superior de la lista de Gmail y he añadido algunos indicadores de advertencia. Gracias por intentar avisar a otros para ahorrarles problemas

thoka · 6 Febrero, 2021 01:10

Estoy intentando entender por qué falla la sincronización de correos con un servidor IMAP de Dovecot (desafortunadamente, sin experiencia en Ruby o Rails).

Al leer los imap_sync_logs, el daemon de importación se queda atrapado en un bucle:

UIDVALIDITY = 1612565899 no coincide con el esperado 0, invalidando la caché IMAP y resincronizando los correos para la bandeja INBOX

Por lo tanto, me pregunto si @group.imap_uid_validity no debería actualizarse en este 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

Tras una actualización manual de este valor, el daemon de importación se queda atrapado en otro bucle.

Dovecot no soporta 'LABELS' en

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

lo que provoca un Net::IMAP::BadResponseError, que, desafortunadamente, no aparece en los registros.

Ahora me pregunto:

si el soporte de Dovecot para banderas personalizadas es suficiente para una sincronización bidireccional con Discourse
cómo detectar Dovecot en lib/imap/providers/detector.rb
cómo emular la función de etiquetas en un proveedor de Dovecot

…

martin · 7 Febrero, 2021 23:39

La sincronización IMAP para bandejas de entrada grupales sigue siendo una función en etapas tempranas que actualmente solo admite Gmail. En teoría, podrías escribir un proveedor de dovecot, pero hace un par de semanas noté que hay algunas partes del código principal que utilizan funciones exclusivas de Gmail y que deben trasladarse a código específico del proveedor. Así que lo siento, pero quizás quieras esperar hasta que esto esté un poco más cerca de estar listo para su uso general.

thoka · 8 Febrero, 2021 14:54

Según mi entendimiento, 'LABELS' es una característica no estándar de Gmail.
Me gustaría entender la diferencia entre IMAP de Google e IMAP estándar.

Este es mi resumen hasta ahora:

IMAP estándar	IMAP de Google
Los correos archivados viven en subcarpetas	Todos los correos viven en una carpeta Los mensajes archivados carecen de la etiqueta “\INBOX”
Las marcas personalizadas se almacenan junto con las marcas del sistema	Almacena las marcas personalizadas como etiquetas

¿Sería suficiente

emular las etiquetas en IMAP estándar dividiendo las marcas en marcas del sistema y marcas personalizadas
manejar email_is_archived mediante el proveedor (por ejemplo, agregar y probar una marca “archivado”)

para lograr la sincronización con IMAP estándar?

Esto afectaría estas líneas:

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 línea me parece extraña:

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?

Cualquier marca del sistema será sobrescrita por las etiquetas de Discourse.
¿Esto maneja correctamente todas las marcas IMAP (\Answered, \Deleted, \Draft, \Flagged, \Recent y \Seen / $Forwarded, $MDNSent, $SubmitPending y $Submitted)?

StanD · 29 Marzo, 2021 02:58

Vuelvo a esto después de un tiempo de ausencia.

No he podido averiguar cómo hacer que el encabezado reply-to funcione correctamente. Puedo configurar un grupo para sincronizarlo con una cuenta de Gmail específica, pero cuando intento responder por correo electrónico, la dirección reply-to se establece en el correo de notificación configurado en Discourse y no en la dirección IMAP.

¿Hay algo que me esté pasando por alto?

mognet · 16 Octubre, 2021 16:15

Solo probé esto con el proveedor de correo de GoDaddy, pero sin éxito. Con Gmail funciona genial, pero lamentablemente queremos usar nuestro propio dominio. ¿Hay alguna actualización para que esté lista para su uso en producción?

pfaffman · 16 Octubre, 2021 17:58

Por cierto, puedes usar tu propio dominio con Gmail (de pago).

Tema		Respuestas	Vistas
Is it possible to use Discourse for e-mail? Support	5	1428	9 Septiembre 2021
Discourse settings: IMAP Support	1	68	14 Agosto 2024
Discourse as a private email support portal Feature rfc , spec	45	23283	10 Mayo 2016
Replacing Mailing lists: Email-In Feature	67	17149	4 Octubre 2014
Migrate a mailing list to Discourse (mbox, Listserv, Google Groups, etc) Migrating to Discourse how-to	109	24220	3 Abril 2026

Beneficios

Características

Para empezar

Información específica del proveedor

Gmail

Limitaciones

Comentarios y hoja de ruta

Agradecimientos especiales

Temas relacionados