[postfix-users] POSTFIX v2.5.5 : fallback_relay : to many hops !

[lst_hoe02 at kwsoft.de]

Zitat von zum Henker mit dem POSTFIX <postfix at 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
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 6397 bytes
Beschreibung: S/MIME Signatur
URL         : <http://de.postfix.org/pipermail/postfix-users/attachments/20100604/362f4139/attachment.bin>