Postfix: Whitelist für Backup-MX IP(s)?

killerbees19

killerbees19

Member
Ich verwende bei meinem Mailserver unter Debian Jessie zahlreiche Überprüfungen wie z.B. SPF/DKIM/DMARC/ClamAV/Spamfilter/usw. die logischerweise Mails auch komplett abweisen könnten. Einige davon sind als smtpd_*_restrictions eingebunden, andere aber wiederum als Milter. Das funktioniert soweit einwandfrei.

Für manche Domains soll zusätzlich ein Backup-MX mit identischer Konfiguration an einem anderen Standort betrieben werden. Jetzt stellt sich für mich natürlich die Frage, ob ich dessen IP-Adressen irgendwie am Hauptserver in eine Whitelist eintragen kann, damit diese ganzen Überprüfungen nicht unnötigerweise nochmals ausgeführt werden und im Falle von SPF/DMARC sogar zu einem Reject führen könnten. Zusätzlich kostet es natürlich unnötige Ressourcen.

Bei den smtpd_*_restrictions habe ich das mit einer cidr-Tabelle als Whitelist an der richtigen Stelle bereits gelöst. Gibt es diese Möglichkeit auch irgendwie für Milter? Was ich bräuchte wäre etwas wie: if(ip != xxx); then milter action;

Oder gehe ich das Problem völlig falsch an? Wie lösen das andere? Danke schon einmal für jeden Tipp! :)


MfG Christian
 
Danke für den Tipp, mir ist nur nicht ganz klar, was ich damit machen soll.

Wenn ich am primären MX anhand der Sender-IP FILTER als Aktion auslöse, und z.B. auf eine smtpd-Instanz ohne Milter weiterleite, bringt mir das nichts mehr, da die Milter dann bereits alle durchgelaufen sind. Führe ich die Milter erst After-Queue aus, kann ich kein REJECT mehr machen, da ich die Mails bereits angenommen habe und somit sinnlose Bounce-Nachrichten verschicken würde.

Oder habe ich das falsch verstanden und es geht nicht um FILTER? Oder soll ich das am Backup-MX einsetzen, um an einen anderen Postfix-Port ohne Milter zuzustellen? Sorry, ich blicke da gerade nicht ganz durch… :)


MfG Christian
 
Mit o.g. check_client_access kannst du z.B. Clients (wie den Backup-MX) Zugriff geben, ohne, dass die kompletten smtpd_*_restrictions greifen. Allerding müste der Milter dabei weiter greifen - was du ja auch nicht möchtest. Ich würde wahrscheinlich auf dem primären MX eine zusätzliche Instanz des smtpd auf einem anderen Port laufen lassen, die die diversen Checks nicht mehr durchführt, aber dafür nur Mails vom Backup-MX annimmt (z.B. per SMTP-Auth und/oder IP). Auf dem Backup-MX müsste dann entsprechend für die Domain der primäre Server inkl. Port und ggfl. den Auth-Daten konfiguriert werden.
 
danton said:
Mit o.g. check_client_access kannst du z.B. Clients (wie den Backup-MX) Zugriff geben, ohne, dass die kompletten smtpd_*_restrictions greifen.
Click to expand...
Bis zu diesem Punkt war mir das schon klar :)

danton said:
Allerding müste der Milter dabei weiter greifen - was du ja auch nicht möchtest.
Click to expand...
Exakt! :D

danton said:
Ich würde wahrscheinlich auf dem primären MX eine zusätzliche Instanz des smtpd auf einem anderen Port laufen lassen, die die diversen Checks nicht mehr durchführt, aber dafür nur Mails vom Backup-MX annimmt (z.B. per SMTP-Auth und/oder IP).
Click to expand...
Das war auch der ursprüngliche Plan, ich dachte halt es geht irgendwie eleganter. Danke für Deinen Vorschlag.

danton said:
Auf dem Backup-MX müsste dann entsprechend für die Domain der primäre Server inkl. Port und ggfl. den Auth-Daten konfiguriert werden.
Click to expand...
Ich nehme an, dass ich das am einfachsten hinbekomme, wenn die betroffenen Domains einen eigenen Transport bekommen, den ich entsprechend konfiguriere. Oder gibt es dafür noch andere Vorschläge?


MfG Christian
 
Nachdem ich das Thema letztes Jahr nicht mehr weiter verfolgt habe, hole ich den Thread jetzt nochmals heraus… ;)

danton said:
Ich würde wahrscheinlich auf dem primären MX eine zusätzliche Instanz des smtpd auf einem anderen Port laufen lassen, die die diversen Checks nicht mehr durchführt, aber dafür nur Mails vom Backup-MX annimmt (z.B. per SMTP-Auth und/oder IP).
Click to expand...
Das wollte ich nun auch so umsetzen. Ich habe mir dafür am Backup-MX einen eigenen Transport eingerichtet, der über transport_maps durch die MySQL-Tabelle als Ergebnis immer folgendes ausgibt: fnx-relay:%s:24 (%s ist immer der Domainname)

Der Transport ist entsprechend in der master.cf eingerichtet und arbeitet auch korrekt. Am primären MX ist alles korrekt eingerichtet, mit TLS-CCert-Auth und ohne jegliche SPF/DKIM/DMARC/Spam Überprüfung.

Das Problem ist nur, dass Postfix u.a. versucht die Mail an sich selbst zuzustellen! Die eigenen MX-Records ignoriert Postfix nämlich nur, wenn der Zielport 25 ist. Das habe ich durch mühsames Lesen des Quellcodes für den integrierten SMTP-Client herausgefunden. Wen es interessiert: Die dafür verantwortlichen Zeilen sind in smtp_connect.c und smtp_addr.c – siehe IPPORT_SMTP und SMTP_MISC_FLAG_LOOP_DETECT. Die Krönung an dem ganzen ist aber, dass dann nicht nur der primäre MX angesprochen wird, sondern ausnahmslos JEDER gefundene MX, also auch potentiell weitere (oder weniger priorisierte) Backup-MX, sofern welche existieren. Das ist somit unbrauchbar.

Mir gehen langsam die Ideen aus, wie man das schön lösen kann. Postfix patchen ist aktuell keine Option. Irgendwelche anderen Ideen? :(

Die MX-Records selbst mit einem Script auswerten und direkt dem Transport in der Form fnx-relay:[a.b.c.d]:24 übergeben wäre die absolut letzte Notlösung. Das verkompliziert das Setup enorm. Es muss doch auch anders gehen?


MfG Christian
 
Ich denke, du machst es dir viel komplizierter als nötig.
Wenn ich deine Intention richtig verstehe, geht es dir ja nicht um Lastverteilung sondern nur um die Absicherung, falls der Main-MX mal ausfallen sollte.
Wenn ja, sollte es doch reichen, den Backup-MX nur mit Postscreen aufzusetzen, damit an diesem Punkt schon mal das meiste an Spam außen vor gehalten wird. Wenn der Main-MX wieder erreichbar ist, werden die Mails ja dann an diesen weitergereicht und dort dann weiter gefiltert und in die Postfächer einsortiert.
 
nexus said:
Wenn der Main-MX wieder erreichbar ist, werden die Mails ja dann an diesen weitergereicht und dort dann weiter gefiltert und in die Postfächer einsortiert.
Click to expand...
Eben nicht, weil dann am primären MX alle Milter (z.B. DMARC, Spamfilter, …) anschlagen könnten und die Mail entweder abweisen (führt zu Bounces vom Backup-MX aus) oder als Spam klassifizieren, was auch nicht Sinn der Sache ist.


MfG Christian
 
Warum einfach wenn es kompliziert geht ;)

Nimm die IP-Adressen der MX in mynetworks und gegebenenfalls die postscreen whitelist auf und dann:
Code: 
smtpd_client_restrictions =
  sleep 1,
### Hier kommen Deine weiteren Checks
  permit
smtpd_data_restrictions =
  reject_unauth_pipelining,
  reject_multi_recipient_bounce,
### Hier kommen Deine weiteren Checks
  permit
smtpd_end_of_data_restrictions =
### Hier kommen Deine weiteren Checks
  permit
smtpd_etrn_restrictions =
### Hier kommen Deine weiteren Checks
  reject
smtpd_helo_required = yes
smtpd_helo_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_invalid_helo_hostname,
  reject_non_fqdn_helo_hostname,
### Hier kommen Deine weiteren Checks
  permit
smtpd_recipient_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_non_fqdn_recipient,
  reject_unknown_recipient_domain,
### Hier kommen Deine weiteren Checks
  permit
smtpd_relay_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  defer_unauth_destination,
### Hier kommen Deine weiteren Checks
  permit
smtpd_sender_restrictions =
  reject_non_fqdn_sender,
  reject_unknown_sender_domain,
### Hier kommen Deine weiteren Checks
  permit
Mit den permit_mynetworks ist das Ganze dann schon erledigt.
 
Danke Joe, das ist mir bekannt. Aber ich weiß noch immer nicht, wie mir das beim Milter weiter hilft. Die werden trotzdem noch ausgeführt, weil es da eben keine Whitelist gibt. Und genau das möchte ich ja verhindern. Oder übersehe ich da irgendetwas? :)


MfG Christian
 
killerbees19 said:
...snip...Die Krönung an dem ganzen ist aber, dass dann nicht nur der primäre MX angesprochen wird, sondern ausnahmslos JEDER gefundene MX, also auch potentiell weitere (oder weniger priorisierte) Backup-MX, sofern welche existieren.
Click to expand...
Das ist nicht "die Krönung", sondern im SMTP so festgelegt ;)
 
You must log in or register to reply here.
Back
Top