Mail-Empfänger verliert IP-zu-Hostname-Auflösung nach kürzlichem Upgrade und verhindert, dass Anti-Spam-Maßnahmen funktionieren

Unterstützung
1

Es scheint, dass das neueste Mail-Empfangs-Update (Self-hosted mail-receiver update following Let's Encrypt root certificate change) IPs nicht mehr in Hostnamen auflöst. Dies führt zu Problemen mit zuvor funktionierenden Postfix-Zugriffsbeschränkungen für Clients, die durch Hinzufügen der folgenden Zeile zu mail-receiver.yml aktiviert wurden:

  POSTCONF_smtpd_client_restrictions: 'regexp:/etc/postfix/shared/client_access_regex'

Dies ist ein Auszug aus dem Mail-Empfangs-Log, der eine eingehende Verbindung zeigt:

Oct 01 17:38:11 discourse-mail-receiver postfix/master[1]: reload -- version 3.5.6, configuration /etc/postfix
Oct 01 17:41:58 discourse-mail-receiver postfix/smtpd[151]: connect from unknown[167.71.160.115]
Oct 01 17:41:59 discourse-mail-receiver postfix/smtpd[151]: disconnect from unknown[167.71.160.115] ehlo=2 starttls=1 mail=1 quit=1 commands=5

Früher wurde dies in den Hostnamen des ursprünglichen Clients aufgelöst (www11-do.checktls.com[167.71.160.115]), jetzt bleibt es ungelöst und wird als unknown[167.71.160.115] markiert.

Dies führt zu Konflikten mit den Einträgen in der Datei client_access_regex, die so konzipiert ist, dass sie alle Hosts ohne gültigen PTR-Eintrag ablehnt (das sind im Wesentlichen alle Spam-Relays) sowie alle Hosts aus dynamischen IP-Bereichen (meist virtuelle Hosts und ebenfalls im Wesentlichen alle Spam-Relays).

Da keine IP mehr in einen Hostnamen aufgelöst wird, funktionieren keine der Regeln mehr. Noch schlimmer ist, dass die Zeile /unknown/ REJECT nun alle eingehenden E-Mails blockiert. Ich musste die Regel vorübergehend deaktivieren, um eingehende Verbindungen überhaupt zu ermöglichen, und alle anderen Regeln sind durch das Auflösungsproblem unwirksam geworden. Dadurch ist der Server wieder Spam ausgesetzt (mein Forum wurde vor der Implementierung dieser Regeln mit Spam überschwemmt, und seit ihrer Umsetzung habe ich keinen einzigen Spam mehr erhalten).

Ich kann nicht auf die alte Version als Workaround zurückgreifen (wegen der Let’s Encrypt-Probleme), und die neue Version öffnet wieder die Schleusen für Spam. Ich wäre daher sehr dankbar für eine Lösung (ich habe versucht, herauszufinden, wie man die DNS-Auflösung innerhalb des Docker-Images manuell aktiviert, aber ohne Erfolg).

Hier ist eine Referenz-Datei client_access_regex, falls jemand die gleichen wiederkehrenden Spam-Probleme hat und es ausprobieren möchte (verwenden Sie Customize direct-delivery Postfix configuration, um /etc/postfix/shared und mail-receiver.yml zu konfigurieren):

#  regex dns: ([a-zA-Z0-9]+(-[a-zA-Z0-9]+)*\\.)+[a-zA-Z]{2,}
#  regex ip: ((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)
#
#  dyn-ip-dns:
/((\\.|-|x)(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){2}((\\.|-)[a-zA-Z0-9]+)+\\.[a-zA-Z]{2,}/        REJECT
/unknown/                               REJECT
/sample-spam\\.domain\\.com/              REJECT
2

Ich habe das Problem bei einem anderen Container bereits gelöst. Man kommentiert das fehlerhafte Zertifikat einfach aus, und schon funktioniert es wieder. Allerdings bin ich mir nicht sicher, wie man den alten Container wieder hochfährt.

Die Lösung besteht darin, in den neuen Container zu gehen und das Problem dort zu beheben.

3

https://github.com/discourse/mail-receiver/pull/12

@david Dies sollte beide Probleme beheben, die in Self-hosted mail-receiver update following Let's Encrypt root certificate change - #6 by md-misko erwähnt werden.

Bitte beurteilen Sie, ob das Entfernen von Postfix aus dem Chroot-Jail irgendwelche Sicherheitsprobleme mit sich bringt (meiner Meinung nach sollte es das nicht, da Postfix bereits in einem dedizierten Docker-Image isoliert ist).