¿Hay alguna forma de solo sondeo IMAP para correos entrantes?

Soporte
2

Okay, otro miembro del equipo mencionó que la sondeo IMAP nunca funcionó correctamente, fue algo eliminado, y estas pocas configuraciones parecen ser restos de cuando se pretendía implementar.
EDIT: Encontré una declaración al respecto: IMAP support for group inboxes - #39 by martin
Parece un paso atrás, ya que para mí POP3 está obsoleto e impracticable hoy en día, donde la gente suele usar múltiples clientes de correo (mínimo teléfono + PC). Así que no veo ningún sentido en habilitar los oyentes POP3 en una instancia de Dovecot.

Sin embargo, logré implementar la API directa del receptor de correo de Discourse en nuestro Postfix existente sin el contenedor del receptor de correo e incluso sin sus scripts de Ruby, pero siguiendo principalmente la integración de Postfix utilizada en el contenedor del receptor de correo de Discourse: mail-receiver/Dockerfile at main · discourse/mail-receiver · GitHub

/etc/postfix/main.cf:

# Para la dirección de correo electrónico de respuesta de Discourse, anulamos el transporte predeterminado a través del mapeo de transporte
transport_maps=hash:/etc/postfix/transport

/etc/postfix/transport

# Se utiliza un servicio llamado "discourse" como punto final de transporte para los correos electrónicos a la dirección de respuesta de Discourse definida
forum.reply@dietpi.com discourse:

/etc/postfix/master.cf

# Definimos el servicio de transporte "discourse" como un demonio de tubería a curl que escucha en un socket UNIX (privado)
# No puede ser sin privilegios ni estar en chroot para que la tubería a curl funcione
discourse unix - n n - - pipe user=nobody:nogroup argv=/usr/bin/curl -X POST -F email=\<- -H Api-Username:system -H Api-Key:fooooobaaaaarbaaaaaaz https://dietpi.com/forum/admin/email/handle_mail
  • Entonces, el mapeo de transporte pasa los correos electrónicos a la dirección de respuesta a nuestro servicio personalizado discourse.
  • El mejor rendimiento debería ser un socket UNIX, y puede ser privado (el primer -), ya que nada más debe usarlo de todos modos. “privado” significa que el socket se encuentra en /var/spool/postfix/private/discourse, en un directorio al que solo el usuario postfix tiene acceso, dentro del directorio chroot de Postfix /var/spool/postfix.
  • Pero no puede ser sin privilegios ni estar en chroot para que pipe a curl funcione (n n).
  • Luego minimizamos los permisos usando el usuario:grupo nobody:nogroup.
  • Siguiendo la API del receptor, el correo electrónico debe adjuntarse a un campo de formulario email, lo que se puede hacer mediante la llamada <- STDIN de curl. Se deben agregar las cabeceras Api-Username y Api-Key, la primera suele ser system, la segunda se puede generar en Discourse, como una clave API granular con solo permisos receive_emails. Luego, usando el punto final HTTP respectivo.

Omitimos intencionalmente las comprobaciones de la política de rechazo rápido realizadas por el contenedor del receptor:

  • Comprueba la existencia de las cabeceras From y To, si el remitente es una dirección completa con dominio, y si está en una lista negra que se puede definir opcionalmente a través de la variable de contenedor BLACKLISTED_SENDER_DOMAINS. Y envía las direcciones del remitente y del destinatario a otro punto final de la API HTTP de Discourse que comprueba si el destinatario coincide con la plantilla de dirección de correo electrónico de respuesta configurada, y si la dirección del remitente pertenece a un usuario registrado, a menos que el foro esté configurado para crear nuevos usuarios inactivos en los correos entrantes, lo cual extrañamente estaba habilitado por defecto en nuestro caso?
  • La mayor parte de esto, y más, es comprobado por nuestro servicio receptor de SMTP público de Postfix de todos modos, y todo pasa por rspamd, lo que implica comprobaciones DKIM, SPF y DMARC.
  • Pero lo más importante es que las mismas comprobaciones las realiza el backend receptor de correo electrónico final de Discourse de todos modos. La única desventaja: los remitentes no reciben un correo electrónico de rechazo/rebote del demonio de correo, sino que los errores en caso de remitente/destinatario inválido se registran en nuestro Discourse. Pero si el remitente y el destinatario fueran correctos, solo el contenido del correo no es el esperado (especialmente falta la cabecera Message-ID), los remitentes reciben un correo electrónico adecuado de Discourse. Los correos electrónicos de rechazo/rebote SMTP faltantes están totalmente bien en mi opinión, dado que de lo contrario la implementación tiene una sobrecarga mínima, tiene una solicitud de red y un procesamiento de backend menos por correo, etc.
  • En general: tenga cuidado con los espacios en los argumentos del comando master.cf. Las comillas para mantener los espacios literales no funcionan. En su lugar, dicho argumento necesitaría ser envuelto entre llaves: {algún argumento con espacios}. Pero en este caso, ningún argumento contiene espacios, los que están entre la clave de cabecera y el valor también son opcionales.

Funciona muy bien hasta ahora, y se integra perfectamente en nuestra configuración existente con transporte virtual predeterminado a Dovecot, y el mapeo de transporte también se utiliza para enviar algunos correos electrónicos a direcciones externas, ya que no todos en el equipo quieren/requieren un buzón adicional en nuestro servidor. Si se define una dirección “catch-all” en el mapeo de alias virtual, la dirección de respuesta de Discourse debe agregarse a esa tabla, mapeándola a sí misma (como otros usuarios/direcciones virtuales locales).