Gibt es eine Möglichkeit, nur IMAP-Polling für eingehende E-Mails zu verwenden

Unterstützung
2

Okay, ein anderes Teammitglied erwähnte, dass das IMAP-Polling nie richtig funktionierte, teilweise entfernt wurde und diese wenigen Einstellungen einige verbleibende Artefakte aus der Zeit zu sein scheinen, als es implementiert werden sollte.
EDIT: Habe eine Aussage dazu gefunden: IMAP support for group inboxes - #39 by martin
Scheint ein Rückschritt zu sein, da POP3 für mich heutzutage veraltet und undurchführbar ist, wo Leute normalerweise mehrere E-Mail-Clients (mindestens Telefon + PC) verwenden. Daher sehe ich keinen Sinn, POP3-Listener überhaupt in einer Dovecot-Instanz zu aktivieren.

Ich habe es jedoch geschafft, die direkte Discourse Mail Receiver API in unser bestehendes Postfix zu implementieren, ohne den Mail Receiver Container und sogar ohne dessen Ruby-Skripte, aber hauptsächlich nach der Postfix-Integration, die im Discourse Mail Receiver Container verwendet wird: mail-receiver/Dockerfile at main · discourse/mail-receiver · GitHub

/etc/postfix/main.cf:

# Für die Discourse-Antwort-E-Mail-Adresse überschreiben wir den Standardtransport über die Transportzuordnung
transport_maps=hash:/etc/postfix/transport

/etc/postfix/transport

# Ein Dienst namens "discourse" wird als Transportendpunkt für E-Mails an die definierte Discourse-Antwortadresse verwendet
forum.reply@dietpi.com discourse:

/etc/postfix/master.cf

# Wir definieren den "discourse"-Transportdienst als Pipe-Daemon in Curl, der auf einem (privaten) UNIX-Socket lauscht
# Er kann nicht unprivilegiert oder gechrootet sein, damit die Pipe in Curl funktioniert
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
  • Die Transportzuordnung leitet also E-Mails an die Antwortadresse an unseren benutzerdefinierten discourse-Dienst weiter.
  • Die beste Leistung sollte ein UNIX-Socket sein, und er kann privat sein (erste -), da nichts anderes ihn ohnehin verwenden muss. “privat” bedeutet, dass sich der Socket in /var/spool/postfix/private/discourse befindet, in einem Verzeichnis, auf das nur der postfix-Benutzer Zugriff hat, innerhalb des Postfix-Chroot-Verzeichnisses /var/spool/postfix.
  • Aber er kann nicht unprivilegiert oder gechrootet sein, damit pipe in curl funktioniert (n n).
  • Wir minimieren dann die Berechtigungen mit dem Benutzer/Gruppe nobody:nogroup.
  • Gemäß der Receiver-API muss die E-Mail an ein email-Formularfeld angehängt werden, was über den <- STDIN-Aufruf von curl erfolgen kann. Die Header Api-Username und Api-Key müssen hinzugefügt werden, wobei der erste normalerweise system ist, der zweite kann in Discourse generiert werden, als granulärer API-Schlüssel nur mit receive_emails-Berechtigungen. Dann wird der jeweilige HTTP-Endpunkt verwendet.

Wir überspringen absichtlich die schnellen Ablehnungsrichtlinienprüfungen, die vom Receiver-Container durchgeführt werden:

  • Er prüft auf das Vorhandensein von From- und To-Headern, ob der Absender eine vollständige Adresse mit Domäne ist und ob er auf einer Blacklist steht, die optional über die Container-Variable BLACKLISTED_SENDER_DOMAINS definiert werden kann. Und er sendet Absender- und Empfängeradressen an einen weiteren Discourse HTTP API-Endpunkt, der prüft, ob der Empfänger mit der konfigurierten Discourse-Antwort-E-Mail-Adressvorlage übereinstimmt und ob die Absenderadresse zu einem registrierten Benutzer gehört, es sei denn, das Forum ist so konfiguriert, dass neue inaktive Benutzer bei eingehenden E-Mails erstellt werden, was in unserem Fall seltsamerweise standardmäßig aktiviert war?
  • Die meisten dieser Prüfungen und mehr werden ohnehin von unserem öffentlichen Postfix SMTP Receiver-Dienst durchgeführt, und alles läuft über rspamd, was DKIM-, SPF- und DMARC-Prüfungen beinhaltet.
  • Am wichtigsten ist jedoch, dass die gleichen Prüfungen ohnehin vom endgültigen Discourse E-Mail Receiver Backend durchgeführt werden. Der einzige Nachteil: Absender erhalten keine Mailer-Daemon-Ablehnungs-/Bounce-E-Mail zurück, sondern Fehler im Falle eines ungültigen Absenders/Empfängers werden stattdessen/nur in unserem Discourse protokolliert. Wenn jedoch Absender und Empfänger korrekt waren, nur der E-Mail-Inhalt nicht wie erwartet ist (insbesondere fehlt der Message-ID-Header), erhalten Absender eine ordnungsgemäße E-Mail von Discourse. Die fehlenden SMTP-Ablehnungs-/Bounce-E-Mails sind meiner Meinung nach völlig in Ordnung, da die Implementierung ansonsten mit minimalem Overhead erfolgt, weniger Netzwerkanfragen und Backend-Verarbeitung pro E-Mail usw. hat.
  • Generell: Seien Sie vorsichtig mit Leerzeichen in den master.cf-Befehlsargumenten. Anführungszeichen, um Leerzeichen wörtlich zu halten, funktionieren nicht. Stattdessen müsste ein solches Argument in geschweifte Klammern gesetzt werden: {some arg with spaces}. In diesem Fall enthält jedoch kein Argument Leerzeichen, die zwischen Header-Schlüssel und Wert sind ebenfalls optional.

Funktioniert bisher hervorragend und integriert sich nahtlos in unser bestehendes Setup mit dem Standard-Virtual-Transport zu Dovecot, und die Transportzuordnung wird auch verwendet, um einige E-Mails an externe Adressen weiterzuleiten, da nicht jeder aus dem Team eine zusätzliche Mailbox auf unserem Server möchte/benötigt. Wenn eine Catch-all-Adresse in der virtuellen Alias-Zuordnung definiert ist, muss die Discourse-Antwortadresse zu dieser Tabelle hinzugefügt werden und sich selbst zugeordnet werden (wie andere lokale virtuelle Benutzer/Adressen).