Sandy Drobic schrieb:
Stefan König wrote:
Danke für den Beitrag. Ich persönlich halte das ja auch für unnötig, da normalerweise bei Ausfall eines MX die Mail dann eben später zugestellt wird. Aber "da das schon immer so war, soll das jetzt auch zukünftig so gemacht werden!". Dass in der Q mal eben 30.000 bounce mails festhängen, interessiert da keinen. Wenn der Server neu gemacht wird, sind die ja weg ;) Natürlich sollen alle Einstellungen übernommen werden. Ahja.
Nun denn, wir sind uns einig, das ist meist Unsinn, zumal die Haupt-MXe von Kunden betrieben werden und man auf deren Einstellungen keinen Zugriff hat. D.h. der Backup-MX muss erstmal allen Schrott annehmen. Was wieder zu einem SPAM/Bounce/etc Problem führt...
So ist es leider. Das einzige, was du tun kannst, ist folgendes:
- verwende reject_unverified_recipient für die Domains, für die dein Server Backup-MX sein soll und cache dieses Ergebnis für eine angemessen lange Zeit.
- setze einen gemäßigten Spamschutz ein als allgemeine Einstellung
- treffe eine Vereinbarung, dass Mails, welche dein Server annimmt, von den Endkunden auch angenommen werden müssen
Genau da liegt auch das Problem, das ist "nicht gewünscht". Der MX soll tunlichst nur das weiterleiten was auch gewollt ist.
Optional:
- setze smtpd_restriction_classes ein für Domains mit besonderen Einstellungen
- wenn die Hardware-Leistung des Servers ausreicht und das Mailvolumen nicht zu groß ist: verwende einen Proxy_filter für Spam-/Virenfilterung.
Hardware reicht aus, kein Problem. Das ganze Projekt bereitet mir jedoch aus den genannten Gründen Bauchschmerzen. Das ganze macht einfach keinen Sinn.... anyway, thx! -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org