[postfix-users] postgrey backup MX
Hallo,
meine Frage ist wie kann ich Postgrey auf zwei Mail-Exchanger konfigurieren natürlich sollten beide auf die gleiche Postgrey Datenbank zugreifen.
MfG Philipp Nöbauer
'Philipp Nöbauer' schrieb am 04.04.2010 17:18:
Hallo,
meine Frage ist wie kann ich Postgrey auf zwei Mail-Exchanger konfigurieren natürlich sollten beide auf die gleiche Postgrey Datenbank zugreifen.
so dass die DB der single point of failure wird und der backup MX überflüssig, oder wie soll ich mir das vorstellen?
Grüße, Florian
'Philipp Nöbauer' schrieb am 04.04.2010 17:18:
Hallo,
meine Frage ist wie kann ich Postgrey auf zwei Mail-Exchanger konfigurieren natürlich sollten beide auf die gleiche Postgrey Datenbank zugreifen.
so dass die DB der single point of failure wird und der backup MX überflüssig, oder wie soll ich mir das vorstellen?
Grüße, Florian _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Die Idee ist die das die Verzögerung verschwindet den wenn die Mail mit 450 abgeleht wird baut der Server des Absenders sofort eine Verbindung zum Backup MX auf anstatt 15-30 Minuten zu warten wie es bei nur einem MX Record ist.
MfG Philipp Nöbauer
Hallo Philipp, hallo Florian, hallo Leute,
Am Sonntag, 4. April 2010 schrieb Philipp Nöbauer:
'Philipp Nöbauer' schrieb am 04.04.2010 17:18:
meine Frage ist wie kann ich Postgrey auf zwei Mail-Exchanger konfigurieren natürlich sollten beide auf die gleiche Postgrey Datenbank zugreifen.
Die Idee ist die das die Verzögerung verschwindet den wenn die Mail mit 450 abgeleht wird baut der Server des Absenders sofort eine Verbindung zum Backup MX auf anstatt 15-30 Minuten zu warten wie es bei nur einem MX Record ist.
Und das erschlägt die übliche "Retry muss mindestens 5 Minuten später erfolgen"-Policy wie genau? ;-)
Kurzfassung, wie Florian schon (indirekt) geschrieben hatte: Du willst das nicht wirklich. Der Nutzwert ist extrem gering (IMHO nahe null) und Du baust Dir einen single point of failure ein.
Falls Du Dich doch nicht überzeugen lässt, lass das Postfix des Backup MX gleich auf Postgrey des primary MX (statt auf 127.0.0.1) zugreifen. Ob die Datenbank oder auch Postgrey der single point of failure ist, ist nämlich piepegal ;-)
Gruß
Christian Boltz
OK darüber habe bereits nachgedacht folgende Frage:
wenn man telnet localhost 60000 eintippt kann ein Verbindung aufgebaut werden. wenn man vom anderen Host telnet 60000 eintippt kann keine Verbindung aufgebaut werden.
Das sagt mir das Postgray nur eine Verbindung von localhost zulässt Firewall habe natürlich vorher gestoppt.
oder sehe ich da was Falsch
MfG Philipp Nöbauer
Hallo Philipp, hallo Florian, hallo Leute,
Am Sonntag, 4. April 2010 schrieb Philipp Nöbauer:
'Philipp Nöbauer' schrieb am 04.04.2010 17:18:
meine Frage ist wie kann ich Postgrey auf zwei Mail-Exchanger konfigurieren natürlich sollten beide auf die gleiche Postgrey Datenbank zugreifen.
Die Idee ist die das die Verzögerung verschwindet den wenn die Mail mit 450 abgeleht wird baut der Server des Absenders sofort eine Verbindung zum Backup MX auf anstatt 15-30 Minuten zu warten wie es bei nur einem MX Record ist.
Und das erschlägt die übliche "Retry muss mindestens 5 Minuten später erfolgen"-Policy wie genau? ;-)
Kurzfassung, wie Florian schon (indirekt) geschrieben hatte: Du willst das nicht wirklich. Der Nutzwert ist extrem gering (IMHO nahe null) und Du baust Dir einen single point of failure ein.
Falls Du Dich doch nicht überzeugen lässt, lass das Postfix des Backup MX gleich auf Postgrey des primary MX (statt auf 127.0.0.1) zugreifen. Ob die Datenbank oder auch Postgrey der single point of failure ist, ist nämlich piepegal ;-)
Gruß
Christian Boltz
$ rpm -q --queryformat "%{name}-%{version} %{buildtime:date}" mod_php mod_php-3.0.11 Fri 23 Jul 1999 03:25:43 PM CEST -dn'*SCNR*'h
Jaja. | grep "root" /etc/aliases kaiser_willem:root [> David Haller und Ratti in suse-linux] _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
On 04.04.2010 17:48 Philipp Nöbauer wrote:
wenn man vom anderen Host telnet 60000 eintippt kann keine Verbindung aufgebaut werden.
Weil wahrscheinlich sowas in der Art in Deiner config steht:
POSTGREY_OPTS="--inet=127.0.0.1:60000"
Gruß Markus
OK was muss ich tun
On 04.04.2010 17:48 Philipp Nöbauer wrote:
wenn man vom anderen Host telnet 60000 eintippt kann keine Verbindung aufgebaut werden.
Weil wahrscheinlich sowas in der Art in Deiner config steht:
POSTGREY_OPTS="--inet=127.0.0.1:60000"
Gruß Markus
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
--inet=0.0.0.0:60000
aber das ganze ist einwenig sinnfrei...
kommt halt auf das mailaufkommen an... du kannst dir auch einen kleinen MySQL Cluster bauen und SQLGrey nehmen... (mysql-mmm macht das ganze relativ einfach...)
Aber grundsätzlich braucht es das nicht... (Schalte postgrey auf ein retry von ca. 200-300s und lass es auf beiden laufen. Clients die direkt nochmals versuchen, sollten ja am greylisting hängenbleiben. (es ist einfacher für spammer einfach ein mx nach dem anderen zu probieren, als zu probieren dann die nachricht für 5minuten zu queuen und nochmals probieren...)
Philipp Nöbauer schrieb:
OK was muss ich tun
On 04.04.2010 17:48 Philipp Nöbauer wrote:
wenn man vom anderen Host telnet 60000 eintippt kann keine Verbindung aufgebaut werden.
Weil wahrscheinlich sowas in der Art in Deiner config steht:
POSTGREY_OPTS="--inet=127.0.0.1:60000"
Gruß Markus
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
'Philipp Nöbauer' schrieb am 04.04.2010 17:26:
Die Idee ist die das die Verzögerung verschwindet den wenn die Mail mit 450 abgeleht wird baut der Server des Absenders sofort eine Verbindung zum Backup MX auf anstatt 15-30 Minuten zu warten wie es bei nur einem MX Record ist.
Und Du meinst, die Spammer lösen nicht alle MX-Records auf und probieren sie nacheinander? Ich glaube so schlau sind die mittlerweile. Btw. Bei mir macht greylisting so einen verschwindend kleinen Anteil an den Ablehnungen aus, dass ich überlege das abzuschalten. Ca. 99% der SPAM bekomme ich per policyd mit diversen listen weg, nachdem ich vorher schon in den helo checks server ablehne, die sich als localhost oder dsl-device melden.
Ergo: Das greylisting als solches nutzt nur noch wenig, auf die Art wie Du es einsetzen willst vermutlich noch weniger. => Spar Dir die Zeit und Nerven ;)
Grüße, Florian
PS: Wenn Dich die Konfiguration des bind-parameters bei postgrey schon 'überfordert', solltest Du eventuell auch darüber nachdenken, das mailsetup nicht alleine aufzusetzen. Nutzer reagieren erfahrungsgemäß etwas allergisch, wenn irgendwas mit den Emails nicht mehr funktioniert... :)
OK danke für die Zahlreichen Antworten, verwende die zahlreichen Möglichkeiten die Postfix mitbringt wie dns Prüfungen, dies hat mir 60% der Spams vom Hals gehalten. nach implementierung der dnsbl ten.spamhaus.org blieben 90% aus, nun habe Postgrey installiert und bisher keinen Spam bekommen.
nun gut Ich werde mir überlegen was ich machen werde.
MfG Philipp Nöbauer
'Philipp Nöbauer' schrieb am 04.04.2010 17:26:
Die Idee ist die das die Verzögerung verschwindet den wenn die Mail mit 450 abgeleht wird baut der Server des Absenders sofort eine Verbindung zum Backup MX auf anstatt 15-30 Minuten zu warten wie es bei nur einem MX Record ist.
Und Du meinst, die Spammer lösen nicht alle MX-Records auf und probieren sie nacheinander? Ich glaube so schlau sind die mittlerweile. Btw. Bei mir macht greylisting so einen verschwindend kleinen Anteil an den Ablehnungen aus, dass ich überlege das abzuschalten. Ca. 99% der SPAM bekomme ich per policyd mit diversen listen weg, nachdem ich vorher schon in den helo checks server ablehne, die sich als localhost oder dsl-device melden.
Ergo: Das greylisting als solches nutzt nur noch wenig, auf die Art wie Du es einsetzen willst vermutlich noch weniger. => Spar Dir die Zeit und Nerven ;)
Grüße, Florian
PS: Wenn Dich die Konfiguration des bind-parameters bei postgrey schon 'überfordert', solltest Du eventuell auch darüber nachdenken, das mailsetup nicht alleine aufzusetzen. Nutzer reagieren erfahrungsgemäß etwas allergisch, wenn irgendwas mit den Emails nicht mehr funktioniert... :) _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Zitat von Florian Streibelt postfix@f-streibelt.de:
'Philipp Nöbauer' schrieb am 04.04.2010 17:26:
Die Idee ist die das die Verzögerung verschwindet den wenn die Mail mit 450 abgeleht wird baut der Server des Absenders sofort eine Verbindung zum Backup MX auf anstatt 15-30 Minuten zu warten wie es bei nur einem MX Record ist.
Und Du meinst, die Spammer lösen nicht alle MX-Records auf und probieren sie nacheinander? Ich glaube so schlau sind die mittlerweile. Btw. Bei mir macht greylisting so einen verschwindend kleinen Anteil an den Ablehnungen aus, dass ich überlege das abzuschalten. Ca. 99% der SPAM bekomme ich per policyd mit diversen listen weg, nachdem ich vorher schon in den helo checks server ablehne, die sich als localhost oder dsl-device melden.
So seltsam ist die Welt...
Bei uns bügelt Greylisting ca. 98% der Spam-Bots weg und hat dazu geführt das ich die RBL-Ablehnung für dynamische IP-Bereiche endlich wieder rausnehmen konnte. Die "Rest-Reject-Rate" der übrigen RBLs liegt dann nur noch bei etwa 2% d.h. eigentlich könnte ich die auch weglassen, Greylisting aber sicher nicht.
Zum Einsatz auf Secondary MX geb ich dir allerdings recht, den Aufwand das irgend wie zu syncronisieren würde ich auch nicht treiben.
Gruß
Andreas
Am 06.04.2010 10:35, schrieb lst_hoe02@kwsoft.de:
Zitat von Florian Streibelt postfix@f-streibelt.de:
'Philipp Nöbauer' schrieb am 04.04.2010 17:26:
Die Idee ist die das die Verzögerung verschwindet den wenn die Mail mit 450 abgeleht wird baut der Server des Absenders sofort eine Verbindung zum Backup MX auf anstatt 15-30 Minuten zu warten wie es bei nur einem MX Record ist.
Und Du meinst, die Spammer lösen nicht alle MX-Records auf und probieren sie nacheinander? Ich glaube so schlau sind die mittlerweile. Btw. Bei mir macht greylisting so einen verschwindend kleinen Anteil an den Ablehnungen aus, dass ich überlege das abzuschalten. Ca. 99% der SPAM bekomme ich per policyd mit diversen listen weg, nachdem ich vorher schon in den helo checks server ablehne, die sich als localhost oder dsl-device melden.
So seltsam ist die Welt...
Bei uns bügelt Greylisting ca. 98% der Spam-Bots weg und hat dazu geführt das ich die RBL-Ablehnung für dynamische IP-Bereiche endlich wieder rausnehmen konnte. Die "Rest-Reject-Rate" der übrigen RBLs liegt dann nur noch bei etwa 2% d.h. eigentlich könnte ich die auch weglassen, Greylisting aber sicher nicht.
Zum Einsatz auf Secondary MX geb ich dir allerdings recht, den Aufwand das irgend wie zu syncronisieren würde ich auch nicht treiben.
Gruß
Andreas
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
jeder hat seinen eigenen spam, jeder muss seine logs analysieren und feststellen welches Verfahren ihm den besten Erfolg bringt zumindest wenn man die standart spam filter die postfix bietet schon benutzt, eine Aussage wie greylisting filtert 90 % weg ist global nicht haltbar, ausserdem ist die sache zeitabhaengig, dh die spammer koennen ihr Verhalten jederzeit aendern
Zitat von Robert Schetterer robert@schetterer.org:
Am 06.04.2010 10:35, schrieb lst_hoe02@kwsoft.de:
Zitat von Florian Streibelt postfix@f-streibelt.de:
'Philipp Nöbauer' schrieb am 04.04.2010 17:26:
Die Idee ist die das die Verzögerung verschwindet den wenn die Mail mit 450 abgeleht wird baut der Server des Absenders sofort eine Verbindung zum Backup MX auf anstatt 15-30 Minuten zu warten wie es bei nur einem MX Record ist.
Und Du meinst, die Spammer lösen nicht alle MX-Records auf und probieren sie nacheinander? Ich glaube so schlau sind die mittlerweile. Btw. Bei mir macht greylisting so einen verschwindend kleinen Anteil an den Ablehnungen aus, dass ich überlege das abzuschalten. Ca. 99% der SPAM bekomme ich per policyd mit diversen listen weg, nachdem ich vorher schon in den helo checks server ablehne, die sich als localhost oder dsl-device melden.
So seltsam ist die Welt...
Bei uns bügelt Greylisting ca. 98% der Spam-Bots weg und hat dazu geführt das ich die RBL-Ablehnung für dynamische IP-Bereiche endlich wieder rausnehmen konnte. Die "Rest-Reject-Rate" der übrigen RBLs liegt dann nur noch bei etwa 2% d.h. eigentlich könnte ich die auch weglassen, Greylisting aber sicher nicht.
Zum Einsatz auf Secondary MX geb ich dir allerdings recht, den Aufwand das irgend wie zu syncronisieren würde ich auch nicht treiben.
Gruß
Andreas
jeder hat seinen eigenen spam, jeder muss seine logs analysieren und feststellen welches Verfahren ihm den besten Erfolg bringt zumindest wenn man die standart spam filter die postfix bietet schon benutzt, eine Aussage wie greylisting filtert 90 % weg ist global nicht haltbar, ausserdem ist die sache zeitabhaengig, dh die spammer koennen ihr Verhalten jederzeit aendern
Hab ich auch nie behauptet, ich wollte lediglich darauf hinweisen das die Aussage "Greylisting bringt nix weil es bei uns nicht funktioniert" wie vom "Vor-Poster" eingebracht falsch ist.
Gruß
Andreas
-----Original Message----- From: postfix-users-bounces+mstevens=imt-systems.com@de.postfix.org [mailto:postfix-users-bounces+mstevens=imt-systems.com@de.postfix.org] On Behalf Of lst_hoe02@kwsoft.de Sent: Tuesday, April 06, 2010 10:36 AM To: postfix-users@de.postfix.org Subject: Re: [postfix-users] postgrey backup MX
Zum Einsatz auf Secondary MX geb ich dir allerdings recht, den Aufwand das irgend wie zu syncronisieren würde ich auch nicht treiben.
Dazu sei aber gesagt, mit sqlgrey ist das kein hoher Aufwand. Weiterhin ist das eine komfortable Lösung wenn sich irgendwann Server ändern oder weitere dazu kommen.
MfG
Morten Stevens
Zitat von "Morten P.D. Stevens" mstevens@imt-systems.com:
-----Original Message----- From: postfix-users-bounces+mstevens=imt-systems.com@de.postfix.org [mailto:postfix-users-bounces+mstevens=imt-systems.com@de.postfix.org] On Behalf Of lst_hoe02@kwsoft.de Sent: Tuesday, April 06, 2010 10:36 AM To: postfix-users@de.postfix.org Subject: Re: [postfix-users] postgrey backup MX
Zum Einsatz auf Secondary MX geb ich dir allerdings recht, den Aufwand das irgend wie zu syncronisieren würde ich auch nicht treiben.
Dazu sei aber gesagt, mit sqlgrey ist das kein hoher Aufwand. Weiterhin ist das eine komfortable Lösung wenn sich irgendwann Server ändern oder weitere dazu kommen.
Es ist auch mit Postgrey zunächst kaum Aufwand, es bleibt aber ein SPOF bzw. zusätzliche Abhängigkeiten und wenn das "behoben" werden soll wird es aufwändig. Deswegen: Aufwand/Nutzen = Fragwürdig
Gruß
Andreas
* Philipp Nöbauer postfixmail@dncom.de:
meine Frage ist wie kann ich Postgrey auf zwei Mail-Exchanger konfigurieren natürlich sollten beide auf die gleiche Postgrey Datenbank zugreifen.
Dir wurde ja schon gesagt, warum das keine gute Idee ist (SPoF), aber es ist auch nicht wirklich notwendig: Nachdem ein einliefernder Server ein 4xx von MX1 bekommen hat, wird er in den meisten Fällen direkt zu MX2 weitermarschieren und sein Glück dort probieren.
Stefan
Am 04.04.2010 17:18, schrieb Philipp Nöbauer:
Hallo,
meine Frage ist wie kann ich Postgrey auf zwei Mail-Exchanger konfigurieren natürlich sollten beide auf die gleiche Postgrey Datenbank zugreifen.
MfG Philipp Nöbauer
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
indem du zb folgenden start parameter nutzt
--inet=ip.add.re.ess.e:portnummer
danach laesst sich postgrey ueber das netzwerk auf der configurierten ip und port ansprechen, am besten privates Netzwerk nehmen lokale firewalls ( iptables nutzen ) um postgrey nicht aus dem internet ansprechbar zu machen
'Robert Schetterer' schrieb am 06.04.2010 08:58:
danach laesst sich postgrey ueber das netzwerk auf der configurierten ip und port ansprechen,
Falls am Rechner eine Netzwerkkarte mit diese Adresse konfiguriert ist, wenn nicht kommt beim Start wohl eine Fehlermeldung.
am besten privates Netzwerk nehmen lokale firewalls ( iptables nutzen ) um postgrey nicht aus dem internet ansprechbar zu machen
Naja, er wollte es ja gerade aus dem Netz erreichbar haben, oder hatte ich das missverstanden?
Grüße, Florian
Am 06.04.2010 11:19, schrieb Florian Streibelt:
'Robert Schetterer' schrieb am 06.04.2010 08:58:
danach laesst sich postgrey ueber das netzwerk auf der configurierten ip und port ansprechen,
Falls am Rechner eine Netzwerkkarte mit diese Adresse konfiguriert ist,
also das hier ist eine postfix mail liste nicht wie configuriere ich mein os/netzwerk liste, also bissl mitdenken ist hier schon gefordert
wenn nicht kommt beim Start wohl eine Fehlermeldung.
am besten privates Netzwerk nehmen lokale firewalls ( iptables nutzen ) um postgrey nicht aus dem internet ansprechbar zu machen
Naja, er wollte es ja gerade aus dem Netz erreichbar haben, oder hatte ich das missverstanden?
es ist voellig wurst ob die ip privat oder oeffentlich ist solange man absichert dass sich nur gewollte cleints sich mit dem damon verbinden, einfachstes verfahren = firewall regel
Grüße, Florian
participants (9)
-
Christian Boltz -
Florian Streibelt -
lst_hoe02＠kwsoft.de -
Markus Winkler -
Morten P.D. Stevens -
Philipp Nöbauer -
Robert Schetterer -
Stefan Foerster -
tuxli＠tuxli.net