Esiste un modo per eseguire solo il polling IMAP per le email in arrivo

Supporto
2

Va bene, un altro membro del team ha menzionato che il polling IMAP non ha mai funzionato correttamente, è stato in parte rimosso e queste poche impostazioni sembrano essere dei residui di quando si mirava all’implementazione.
*EDIT: Trovata una dichiarazione al riguardo: IMAP support for group inboxes - #39 by martin
Sembra un passo indietro, poiché per me POP3 è obsoleto e impraticabile al giorno d’oggi, dove le persone utilizzano solitamente più client di posta (telefono + PC minimo). Quindi non vedo alcun motivo per abilitare i listener POP3 in un’istanza Dovecot.

Tuttavia, sono riuscito a implementare l’API diretta del ricevitore di posta di Discourse nel nostro Postfix esistente senza il container del ricevitore di posta e persino senza i suoi script Ruby, ma seguendo principalmente l’integrazione Postfix utilizzata nel container del ricevitore di posta di Discourse: mail-receiver/Dockerfile at main · discourse/mail-receiver · GitHub

/etc/postfix/main.cf:

# Per l'indirizzo email di risposta di Discourse, sovrascriviamo il trasporto predefinito tramite la mappatura dei trasporti
transport_maps=hash:/etc/postfix/transport

/etc/postfix/transport

# Un servizio chiamato "discourse" viene utilizzato come endpoint di trasporto per le email all'indirizzo di risposta Discourse definito
forum.reply@dietpi.com discourse:

/etc/postfix/master.cf

# Definiamo il servizio di trasporto "discourse" come pipe daemon in curl in ascolto su un socket UNIX (privato)
# Non può essere non privilegiato o chrooted affinché la pipe in curl funzioni
discourse unix - n n - - pipe user=nobody:nogroup argv=/usr/bin/curl -X POST -F email=\u003c- -H Api-Username:system -H Api-Key:fooooobaaaaarbaaaaaaz https://dietpi.com/forum/admin/email/handle_mail
  • Quindi la mappatura dei trasporti passa le email all’indirizzo di risposta al nostro servizio personalizzato discourse.
  • Le migliori prestazioni dovrebbero essere un socket UNIX, e può essere privato (il primo -), poiché nient’altro deve utilizzarlo comunque. “privato” significa che il socket si trova in /var/spool/postfix/private/discourse, in una directory a cui ha accesso solo l’utente postfix, all’interno della directory chroot di Postfix /var/spool/postfix.
  • Ma non può essere non privilegiato o chrooted affinché pipe in curl funzioni (n n).
  • Quindi minimizziamo i permessi utilizzando l’utente/gruppo nobody:nogroup.
  • Seguendo l’API del ricevitore, l’email deve essere allegata a un campo modulo email, il che può essere fatto tramite la chiamata STDIN <- di curl. Le intestazioni Api-Username e Api-Key devono essere aggiunte, la prima è solitamente system, la seconda può essere generata in Discourse, come chiave API granulare con solo i permessi receive_emails. Quindi utilizzando l’endpoint HTTP rispettivamente.

Saltiamo intenzionalmente i controlli della politica di rifiuto rapido eseguiti dal container del ricevitore:

  • Controlla l’esistenza delle intestazioni From e To, se il mittente è un indirizzo completo con dominio e se è in una blacklist che può essere opzionalmente definita tramite la variabile del container BLACKLISTED_SENDER_DOMAINS. E invia gli indirizzi del mittente e del destinatario a un altro endpoint API HTTP di Discourse che verifica se il destinatario corrisponde al modello di indirizzo email di risposta configurato e se l’indirizzo del mittente appartiene a un utente registrato, a meno che il forum non sia configurato per creare nuovi utenti inattivi in base alle email in arrivo, cosa che stranamente era abilitata per impostazione predefinita nel nostro caso?
  • La maggior parte di questo, e altro ancora, viene controllato dal nostro servizio ricevitore SMTP Postfix pubblico comunque, e tutto passa attraverso rspamd che implica controlli DKIM, SPF e DMARC.
  • Ma soprattutto, gli stessi controlli vengono eseguiti dal backend finale del ricevitore di posta di Discourse comunque. Unico svantaggio: i mittenti non ricevono un’email di rifiuto/rimbalzo dal mailer daemon, ma gli errori in caso di mittente/destinatario non validi vengono invece/solo registrati nel nostro Discourse. Ma se mittente e destinatario erano corretti, solo il contenuto dell’email non è quello previsto (in particolare manca l’intestazione Message-ID), i mittenti ricevono un’email corretta da Discourse. Le email di rifiuto/rimbalzo SMTP mancanti vanno benissimo secondo me, dato che altrimenti l’implementazione ha un overhead minimo, ha una richiesta di rete e un’elaborazione backend in meno per email, ecc.
  • In generale: fare attenzione agli spazi negli argomenti dei comandi master.cf. La quotazione per mantenere gli spazi letterali non funziona. Invece un tale argomento dovrebbe essere racchiuso tra parentesi graffe: {un argomento con spazi}. Ma in questo caso, nessun argomento contiene spazi, quelli tra la chiave dell’intestazione e il valore sono anche opzionali.

Funziona benissimo finora e si integra perfettamente nella nostra configurazione esistente con trasporto virtuale predefinito a Dovecot, e la mappatura dei trasporti utilizzata anche per inoltrare alcune email a indirizzi esterni, poiché non tutti nel team desiderano/richiedono una casella di posta aggiuntiva sul nostro server. Se un indirizzo catch-all è definito nella mappatura degli alias virtuali, l’indirizzo di risposta di Discourse deve essere aggiunto a quella tabella, mappandolo a se stesso (come altri utenti/indirizzi virtuali locali).