Ich bin momentan wirklich unschlüssig, wie man die Sache mit amavisd-new (oder genereller: SMTP-fähige Inhaltsfilter) eigentlich am besten abhandelt. Die Sache mit den Miltern lasse ich aus, da kann Patrick mehr dazu sagen, aber ich würde mich generell über jede Meinung und jedes Feedback freuen.
Fangen wir mal mit der einachsten Sache an: Ein post-queue Filter. Hier stellt sich die Frage nach dem Loadbalancing auf den ersten Blick nicht. Man setzt im internen DNS eine Zone wie z.B. "filter.example.com" auf:
$ORIGIN filter.example.com . IN MX 10 filter1.example.com . IN MX 10 filter2.example.com
Für den Filter-Eintrag des entsprechenden SMTP-Servers setzt man in der master.cf dann
-o content_filter=filter:filter.example.com:10024
(NB: ohne eckige Klammern) und definiert bei dem filter-Transport passende Werte für Timeouts, Prozesszahl etc. Für amavisd-new reichen Wildcards ('smtp:*:*') oder so, die Seite mit der Doku tut hier gerade nicht) für $forward_method und schon filtert er mehr oder weniger im RR-Betrieb. Hier ist mir jetzt vor allem eine Sache unklar:
Merkt sich Postfix eigentlich, daß ein bestimmter Server tot ist? Ich weiß, daß Postfix in der Lage ist, bestimmte Ziele für tot zu erklären und alle Mail dahin erstmal in die deferred queue zu stellen, aber gilt das auch für einzelne MXe? Wo ist das dokumentiert? In der Manpage zum qmgr findet sich nur:
,----[ man 8 qmgr ] | destination status cache | The queue manager avoids unnecessary delivery | attempts by maintaining a short-term, in-memory | list of unreachable destinations. `----
"Destination" könnte aber auch durchaus eine ganze Zieldomain sein und nicht nur ein MX.
Wenn das nicht funktioniert, dann würde im dem Fall, das ein Filter ausfällt, die Hälfte der Verbindungen erstmal auf einen Timeout warten. Unübersichtlich finde ich auch das Finetuning des Filter-Transports ab einer gewissen Größe der Installation, seien es nun Trivialitäten wie (s|l)mtp_mx_session_limit oder aufwändigerer Kram wie TRANSPORTNAME_destination_concurrency_failed_cohort_limit / TRANSPORTNAME_destination_concurrency_limit. Und nicht vergessen darf man auch, daß das ja nur "RR für Arme ist" - evt. verschärft durch connection caching, was dann schonmal dazu führen kann, daß ein Filter fast immer busy ist und der andere sich langweilt (BTDT).
Noch viel unübersichtlicher wird es meiner Meinung nach bei einem smtpd_proxy_filter. Es ist auf der einen Seite zwar so, daß mit den 2.7er-Versionen endlich die nötige Funktionalität implementiert ist, mit der man eine Mail erst dann dem Proxy vorwirft, wenn sie komplett empfangen wurde, aber was immer noch nicht geht ist eine Spezifikation des Filters mit Transport- und Nexthop. Kann man hier _überhaupt_ irgendwie Redundanz erreichen (pro smtpd!), ohne einen Loadbalancer zu benutzen? Ich habe hier beisher noch jedes Mal auf solch einen zurückgegriffen (Cisco ACE, ldirectord).
Wie handhabt ihr das denn so? Und wisst ihr zufällig, wie andere MTAs (Exim, Exchange in der Edge-Rolle) das machen?
Stefan