[postfix-users] POSTFIX v2.5.5 : fallback_relay : to many hops !
Hallo allerseits,
ich habe zwei root-Server (debian/postfix), die abgehende eMails neben ihren normalen Aufgaben gleich mit abgehend relayen sollen. Damit gibts dann auch keinen Stress mit SPAM-Filtern, denn die Bueros haengen selbst an dynamischen IPs. Dazu habe ich in den hausinternen DNS-Servern jeweils einen round-robin-Eintrag mit den beiden root-Serverm, um so eine einigermassen gleichmaessige Auslastung der beiden Satelliten zu gewaehrleisten. Es gibt allerdings einige Empfaengersysteme die zeitweise (teilweise ueber mehrere Stunden) von dem einen root-Server nicht erreichbar sind, von dem anderen dagegen schon und vice versa. Da das staendig wechselt und keiner fuer mich nachvollziehbaren Logik unterliegt, die Zustellung teilweise aber recht zeitkritisch ist (Statusmeldungen an das PDA), habe ich das jeweils andere Satellitensystem als fallback_relay konfiguriert. Das geht solange gut, bis das angeschriebene System nicht tatsaechlich mal fuer beide root-Server nicht erreichbar ist oder einfach die eMail-Annahme blockiert. Beispielsweise beim Einsatz eines POSTGREY. Einem POSTGREY-Delay koennte man ja mit einer Warteschleife so einigermassen beikommen, aber es gibt durchaus auch andere Zustaende, bei denen dieser Trick einfach nicht funktioniert. Also habe ich voruebergehend den fallback_relay aus dem einen Satellitensystem entfernt, um loops und die daraus resultierenden Unzustellbarkeiten zu vermeiden.
Wie kann ich aber auf den beiden Satellitensystemen selbst pruefen, ob die eMail nun bereits an einen fallback_relay gesendet wurde oder nicht und nur dann an den jeweiligen fallback_relay ueberstellen, wenn die eMail noch nicht relayed wurde ?
Das Handbuch habe ich schon rauf und runtergewuehlt und haenge schon seit einigen Monden an dem Problem. Auch google konnte mir bislang nicht wirklich helfen. Ich denke, mir fehlt da einfach nur der Schubs in die richtige Richtung.
Achso - die Bueros sind jeweils via VPN an die Satellitensysteme angebunden und kommunizieren auch nur ueber das VPN mit denen. Desgleichen die root-Server, die sich untereinander mit 1GBit/s ueber das VPN verstaendigen.
Ich danke jetzt schonmal allen, die ihre Gehirnwindungen auf die Reise geschickt haben,
Bye, Hansjoerg...
Zitat von POSTFIX postfix@c-bit.org:
Hallo allerseits,
ich habe zwei root-Server (debian/postfix), die abgehende eMails neben ihren normalen Aufgaben gleich mit abgehend relayen sollen. Damit gibts dann auch keinen Stress mit SPAM-Filtern, denn die Bueros haengen selbst an dynamischen IPs. Dazu habe ich in den hausinternen DNS-Servern jeweils einen round-robin-Eintrag mit den beiden root-Serverm, um so eine einigermassen gleichmaessige Auslastung der beiden Satelliten zu gewaehrleisten. Es gibt allerdings einige Empfaengersysteme die zeitweise (teilweise ueber mehrere Stunden) von dem einen root-Server nicht erreichbar sind, von dem anderen dagegen schon und vice versa. Da das staendig wechselt und keiner fuer mich nachvollziehbaren Logik unterliegt, die Zustellung teilweise aber recht zeitkritisch ist (Statusmeldungen an das PDA), habe ich das jeweils andere Satellitensystem als fallback_relay konfiguriert. Das geht solange gut, bis das angeschriebene System nicht tatsaechlich mal fuer beide root-Server nicht erreichbar ist oder einfach die eMail-Annahme blockiert. Beispielsweise beim Einsatz eines POSTGREY. Einem POSTGREY-Delay koennte man ja mit einer Warteschleife so einigermassen beikommen, aber es gibt durchaus auch andere Zustaende, bei denen dieser Trick einfach nicht funktioniert. Also habe ich voruebergehend den fallback_relay aus dem einen Satellitensystem entfernt, um loops und die daraus resultierenden Unzustellbarkeiten zu vermeiden.
Wie kann ich aber auf den beiden Satellitensystemen selbst pruefen, ob die eMail nun bereits an einen fallback_relay gesendet wurde oder nicht und nur dann an den jeweiligen fallback_relay ueberstellen, wenn die eMail noch nicht relayed wurde ?
Ich glaube nicht das der "fallback_relay" Wert als Status im Mail Record verzeichnet wird. Der normale Anwendungsfall ist auch eher x Ausgangsrelays falls Load-Balancing benötigt und 1-2 dedizierte Fallbacks für Problematische Mails. Die Hoffnung das durch das durchprobieren einer Mail von mehreren IP-Adressen die Mail schneller rausgeht ist schon eher Spammer-Technik.
Gruß
Andreas
Hallo Andreas,
Wie kann ich aber auf den beiden Satellitensystemen selbst
pruefen,
ob die eMail nun bereits an einen fallback_relay gesendet
wurde oder
nicht und nur dann an den jeweiligen fallback_relay ueberstellen, wenn die eMail noch nicht relayed wurde ?
Ich glaube nicht das der "fallback_relay" Wert als Status im Mail Record verzeichnet wird. Der normale Anwendungsfall ist auch eher x Ausgangsrelays falls Load-Balancing benötigt und 1-2 dedizierte Fallbacks für Problematische Mails. Die Hoffnung das durch das durchprobieren einer Mail von mehreren IP-Adressen die Mail schneller rausgeht ist schon eher Spammer-Technik.
Das mag sicherlich an Spammertechnik erinnern - aber Spammern ist's glaub ich unterm Strich recht egal, ob die eMail ankommt oder nicht, solange noch genuegend Adresse zur Verfuegung stehen, die man zuspammen kann. Sonst wuerden ja die Greylister nicht deutlich ueber 90% des SPAMs schonmal wegwerfen. Nein, hier geht es speziell um PushMail-Postfaecher von vodafone. Die Jungs haben moeglicherweise eine Art Lastbegrenzung auf ihren Firewalls oder MX-Connectoren selbst, die eine Anzahl n von Verbindungsversuchen von einer bestimmten IP-Range nicht zulassen. Auf Class-A-Ebene kanns nicht sein, muss also irgendwas ab Class-B sein. Unsere IP-Adressen sind bis auf Class-C-Ebene auf SPAM-Wahrscheinlichkeit in allen moeglichen Datenbanken mehrmals getestet, da finde ich kein Indiz fuer dieses Verhalten, also muss es irgendwo anders herkommen. Auch kann es an den eigenen "Versuchen" nicht liegen, da es bereits in der Einrichtungsphase auftrat und ich damals (vor knapp 2 Jahren) noch von Konfigurationfehlern auf meiner Seite ausging. Da es aber nur sporadisch auftritt und mal nur die eine IP und mal nur die andere IP trifft, muss das Problem bei vodafone liegen. Und da die jeweils andere IP ohne Probleme einen Connect erhaelt, wurde die Idee des failback geboren, die auch anstaendig funktioniert - bis zu dem Zeitpunkt, wo auf der anderen Seite wirklich ein Problem oder ein Greylister steht. Dann tillen die beiden MX ab und verwerfen die eMails halt.
Die Zustellung muss einfach garantiert werden und auch relativ zeitnah erfolgen. Die Aussendienstler (Techniker) bekommen ihre Tickets direkt auf's Handy gepustet. Eine Verzoegerung von 5-10min ist OK, aber vodafone ist von der einen IP teilweise bis zu mehreren Stunden nicht erreichbar. Und stell Dir Dich als unser Techniker vor, der morgens von Hannover nach Hamburg gegurkt ist, dort 13°° mit seinem Einsatz fertig ist, wir triggern ihm schon 12°° einen Call fuer den Rueckweg rein (suedlich von Hamburg) und den bekommt er dann erst, wenn er wieder in Hannover ist - so gegen 16°°. Einen aehnlichen Fall hatte ich erst wieder gestern und vorgestern.
Insofern hast Du schon recht: Wir spammen unsere Mitarbeiter mit Arbeit zu :-)
Bye, Hansjoerg...
Am 03.06.2010 12:06, schrieb zum Henker mit dem POSTFIX:
Hallo Andreas,
Wie kann ich aber auf den beiden Satellitensystemen selbst
pruefen,
ob die eMail nun bereits an einen fallback_relay gesendet
wurde oder
nicht und nur dann an den jeweiligen fallback_relay ueberstellen, wenn die eMail noch nicht relayed wurde ?
Ich glaube nicht das der "fallback_relay" Wert als Status im Mail Record verzeichnet wird. Der normale Anwendungsfall ist auch eher x Ausgangsrelays falls Load-Balancing benötigt und 1-2 dedizierte Fallbacks für Problematische Mails. Die Hoffnung das durch das durchprobieren einer Mail von mehreren IP-Adressen die Mail schneller rausgeht ist schon eher Spammer-Technik.
Das mag sicherlich an Spammertechnik erinnern - aber Spammern ist's glaub ich unterm Strich recht egal, ob die eMail ankommt oder nicht, solange noch genuegend Adresse zur Verfuegung stehen, die man zuspammen kann. Sonst wuerden ja die Greylister nicht deutlich ueber 90% des SPAMs schonmal wegwerfen. Nein, hier geht es speziell um PushMail-Postfaecher von vodafone. Die Jungs haben moeglicherweise eine Art Lastbegrenzung auf ihren Firewalls oder MX-Connectoren selbst, die eine Anzahl n von Verbindungsversuchen von einer bestimmten IP-Range nicht zulassen. Auf Class-A-Ebene kanns nicht sein, muss also irgendwas ab Class-B sein. Unsere IP-Adressen sind bis auf Class-C-Ebene auf SPAM-Wahrscheinlichkeit in allen moeglichen Datenbanken mehrmals getestet, da finde ich kein Indiz fuer dieses Verhalten, also muss es irgendwo anders herkommen. Auch kann es an den eigenen "Versuchen" nicht liegen, da es bereits in der Einrichtungsphase auftrat und ich damals (vor knapp 2 Jahren) noch von Konfigurationfehlern auf meiner Seite ausging. Da es aber nur sporadisch auftritt und mal nur die eine IP und mal nur die andere IP trifft, muss das Problem bei vodafone liegen. Und da die jeweils andere IP ohne Probleme einen Connect erhaelt, wurde die Idee des failback geboren, die auch anstaendig funktioniert - bis zu dem Zeitpunkt, wo auf der anderen Seite wirklich ein Problem oder ein Greylister steht. Dann tillen die beiden MX ab und verwerfen die eMails halt.
Die Zustellung muss einfach garantiert werden und auch relativ zeitnah erfolgen. Die Aussendienstler (Techniker) bekommen ihre Tickets direkt auf's Handy gepustet. Eine Verzoegerung von 5-10min ist OK, aber vodafone ist von der einen IP teilweise bis zu mehreren Stunden nicht erreichbar. Und stell Dir Dich als unser Techniker vor, der morgens von Hannover nach Hamburg gegurkt ist, dort 13°° mit seinem Einsatz fertig ist, wir triggern ihm schon 12°° einen Call fuer den Rueckweg rein (suedlich von Hamburg) und den bekommt er dann erst, wenn er wieder in Hannover ist - so gegen 16°°. Einen aehnlichen Fall hatte ich erst wieder gestern und vorgestern.
Insofern hast Du schon recht: Wir spammen unsere Mitarbeiter mit Arbeit zu :-)
Bye, Hansjoerg... _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
vorausgesetzt du hast genuegend ips zur Verfuegung wuerde ich einen guten server nehmen irgendeine virtual solution installieren 50 mal debian mit postfix installieren und dann mit deinem relay fallback einfach dei mails weiterreichen, so machen das einige newsletter versender, das ist nicht allzu teuer ( hoechstens die ips/netz ... ) greylisting muss du dabei voher abtesten ( dh wann du deine mails auf den naechsten server/ip schiebst, fuer div domains div regeln aufstellen) spf und dkim und reverse sollten stimmen, zu guter letzt bei vodaphone beschweren ( was bei dem sauladen nichts bringen wird ) alternativ wozu pushmail ,es gibt imap idle , lass deine techniker doch ihre mail abholen wenn sie es fuer richtig halten , alternativ installier die dein eigenes pushmail das kann man fuer exchange doch kaeuflich erwerben denke ich
Zitat von zum Henker mit dem POSTFIX postfix@c-bit.org:
Hallo Andreas,
Wie kann ich aber auf den beiden Satellitensystemen selbst
pruefen,
ob die eMail nun bereits an einen fallback_relay gesendet
wurde oder
nicht und nur dann an den jeweiligen fallback_relay ueberstellen, wenn die eMail noch nicht relayed wurde ?
Ich glaube nicht das der "fallback_relay" Wert als Status im Mail Record verzeichnet wird. Der normale Anwendungsfall ist auch eher x Ausgangsrelays falls Load-Balancing benötigt und 1-2 dedizierte Fallbacks für Problematische Mails. Die Hoffnung das durch das durchprobieren einer Mail von mehreren IP-Adressen die Mail schneller rausgeht ist schon eher Spammer-Technik.
Das mag sicherlich an Spammertechnik erinnern - aber Spammern ist's glaub ich unterm Strich recht egal, ob die eMail ankommt oder nicht, solange noch genuegend Adresse zur Verfuegung stehen, die man zuspammen kann. Sonst wuerden ja die Greylister nicht deutlich ueber 90% des SPAMs schonmal wegwerfen. Nein, hier geht es speziell um PushMail-Postfaecher von vodafone. Die Jungs haben moeglicherweise eine Art Lastbegrenzung auf ihren Firewalls oder MX-Connectoren selbst, die eine Anzahl n von Verbindungsversuchen von einer bestimmten IP-Range nicht zulassen. Auf Class-A-Ebene kanns nicht sein, muss also irgendwas ab Class-B sein. Unsere IP-Adressen sind bis auf Class-C-Ebene auf SPAM-Wahrscheinlichkeit in allen moeglichen Datenbanken mehrmals getestet, da finde ich kein Indiz fuer dieses Verhalten, also muss es irgendwo anders herkommen. Auch kann es an den eigenen "Versuchen" nicht liegen, da es bereits in der Einrichtungsphase auftrat und ich damals (vor knapp 2 Jahren) noch von Konfigurationfehlern auf meiner Seite ausging. Da es aber nur sporadisch auftritt und mal nur die eine IP und mal nur die andere IP trifft, muss das Problem bei vodafone liegen. Und da die jeweils andere IP ohne Probleme einen Connect erhaelt, wurde die Idee des failback geboren, die auch anstaendig funktioniert - bis zu dem Zeitpunkt, wo auf der anderen Seite wirklich ein Problem oder ein Greylister steht. Dann tillen die beiden MX ab und verwerfen die eMails halt.
Vielleicht wäre es sinnvoll das Problem dort zu lösen wo es entsteht?? Ihr bezahlt Geld an Vodafone für einen Service der nur zeitweise geliefert wird... Wenn Vodafone sich "weigert" eurer Mails anzunehmen wäre eine Nachfrage nicht schlecht wofür sie dann Geld wollen. Es macht keinen Sinn auf der Sender Seite ein Problem beheben zu wollen das beim Empfänger auftritt.
Die Zustellung muss einfach garantiert werden und auch relativ zeitnah erfolgen. Die Aussendienstler (Techniker) bekommen ihre Tickets direkt auf's Handy gepustet. Eine Verzoegerung von 5-10min ist OK, aber vodafone ist von der einen IP teilweise bis zu mehreren Stunden nicht erreichbar. Und stell Dir Dich als unser Techniker vor, der morgens von Hannover nach Hamburg gegurkt ist, dort 13°° mit seinem Einsatz fertig ist, wir triggern ihm schon 12°° einen Call fuer den Rueckweg rein (suedlich von Hamburg) und den bekommt er dann erst, wenn er wieder in Hannover ist - so gegen 16°°. Einen aehnlichen Fall hatte ich erst wieder gestern und vorgestern.
Tja, Mail ist eben Best-Effort/Store-and-Forward und mehr auf Zuverlässigkeit ausgelegt aber mit sehr geringen Echtzeitfähigkeiten ausgestattet. In eurem Fall wäre dann SMS die bessere (teurere) Alternative.
Insofern hast Du schon recht: Wir spammen unsere Mitarbeiter mit Arbeit zu :-)
Wie gesagt mal Vodafone fragen ob Mail Kunden Kunden zweiter Wahl sind.
Gruß
Andreas
participants (4)
-
lst_hoe02＠kwsoft.de -
POSTFIX -
Robert Schetterer -
zum Henker mit dem POSTFIX